PŘÍLOHA

Technická specifikace pro interoperabilitu subsystému pro telematické aplikace v nákladní dopravě transevropského konvenčního železničního systému

OBSAH:

1.

ÚVOD

1.1	Technická oblast působnosti

1.2	Místní oblast působnosti

1.3	Obsah této TSI

2.	DEFINICE SUBSYSTÉMU A OBLAST PŮSOBNOSTI

2.1	Funkce spadající do oblasti působnosti TSI

2.2	Funkce spadající mimo oblast působnosti TSI

2.3	Stručný popis subsystému

2.3.1

Zúčastněné subjekty

2.3.2

Uvažované procesy

2.3.3.

Obecné poznámky

3.	ZÁKLADNÍ POŽADAVKY

3.1	Vyhovění základním požadavkům

3.2	Základní požadavky

3.3	Obecné požadavky

3.3.1

Bezpečnost

3.3.2

Spolehlivost a dostupnost

3.3.3

Ochrana zdraví

3.3.4

Ochrana životního prostředí

3.3.5

Technická kompatibilita

3.4	Specifická hlediska týkající se subsystému „Využití telematiky v nákladní dopravě“

3.4.1

Technická kompatibilita

3.4.2

Spolehlivost a dostupnost

3.4.3

Ochrana zdraví

3.4.4

Bezpečnost

4.	POPIS SUBSYSTÉMU

4.1

Úvod

4.2	Funkční a technické specifikace subsystému

4.2.1

Údaje nákladního listu

4.2.2

Žádost o trasu

4.2.3

Příprava vlaku

4.2.4

Prognóza jízdy vlaku

4.2.5

Informace v případě narušení provozu

4.2.6

Umístění vlaku

4.2.7

ETI/ETA zásilky

4.2.8

Pohyb vozu

4.2.9

Vykazování výměny

4.2.10

Výměna údajů za účelem zlepšení kvality

4.2.11

Hlavní referenční údaje

4.2.12

Různé referenční soubory a databáze

4.2.13

Předávání dokumentů v elektronické podobě

4.2.14

Sítě a komunikace

4.3	Funkční a technické specifikace rozhraní

4.3.1

Rozhraní s TSI pro subsystém „Infrastruktura“

4.3.2

Rozhraní s TSI pro subsystém „Řízení a zabezpečení“

4.3.3

Rozhraní se subsystémem „Kolejová vozidla“

4.3.4

Rozhraní s TSI pro subsystém „Provoz a řízení dopravy“

4.4	Provozní předpisy

4.4.1

Kvalita údajů

4.4.2

Provoz centrálního datového skladu

4.5	Pravidla pro údržbu

4.6	Odborné kvalifikace

4.7	Zdravotní a bezpečnostní podmínky

4.8	Registry infrastruktury a kolejových vozidel

5.	PRVKY INTEROPERABILITY

5.1

Definice

5.2	Seznam prvků

5.3	Výkon a specifikace prvků interoperability

6.	POSUZOVÁNÍ SHODY NEBO VHODNOSTI PRO POUŽITÍ PRVKŮ INTEROPERABILITY A OVĚŘOVÁNÍ SUBSYSTÉMŮ

6.1	Prvky interoperability

6.1.1

Postupy posuzování

6.1.2

Modul

6.2	Subsystém „Využití telematiky v nákladní dopravě“

7.	UPLATŇOVÁNÍ

7.1	Způsoby použití této TSI

7.1.1

Úvod

7.1.2

Strategický evropský plán zavádění (Strategic European Deployment Plan, SEDP)

7.1.3

Způsoby použití

7.2	Strategie přechodu

7.3	Řízení změn

7.3.1

Úvod

7.3.2

Stanovování základních vývojových úrovní

7.3.3

Zveřejňování základních vývojových úrovní

7.3.4

Zavádění nových základních vývojových úrovní

7.3.5

Proces řízení změn – požadavky

7.3.6

Plán řízení konfigurace – požadavky

7.4	Zvláštní případy

7.4.1

Úvod

7.4.2

Seznam zvláštních případů

PŘÍLOHA A

SEZNAM DOPROVODNÉ DOKUMENTACE

PŘÍLOHA B

SLOVNÍČEK POJMŮ

TABULKY:

Tabulka 1:

Žádost o trasu

Tabulka 2:

Zrušení trasy železničním podnikem

Tabulka 3:

Zrušení trasy provozovatelem infrastruktury

Tabulka 4:

Potvrzení o přijetí

Tabulka 5:

Příprava vlaku

Transevropský konvenční železniční systém

Technická specifikace pro interoperabilitu subsystému „Využití telematiky v nákladní dopravě“

1.   ÚVOD

1.1   Technická oblast působnosti

Tato TSI se týká subsystému „Využití telematiky v nákladní dopravě“ uvedeného v seznamu v bodě 1 písm. b) přílohy II směrnice 2001/16/ES.

Komerční provoz vlaků, vozů a intermodálních jednotek v celé transevropské železniční síti vyžaduje efektivní výměnu informací mezi jednotlivými provozovateli infrastruktury, železničními podniky a jinými poskytovateli služeb. Na této kompatibilitě a vzájemné výměně informací závisí nejen výkon, bezpečnost a kvalita služeb a nákladů, ale také zejména interoperabilita transevropského konvenčního železničního systému.

Tato technická specifikace pro interoperabilitu má vliv i na podmínky využívání železniční dopravy uživateli. V tomto směru se pojmem uživatelé rozumí nejenom provozovatelé infrastruktury nebo železniční podniky, ale i všichni další poskytovatelé služeb, jako jsou držitel vozů, provozovatelé intermodální dopravy, a dokonce i zákazníci.

Interoperabilita konvenčního železničního systému by navíc měla vytvořit podmínky pro větší interoperabilitu mezi jednotlivými druhy dopravy, zejména mezi konvenční železniční dopravou a kombinovanou železniční dopravou.

Účelem této TSI je zajistit, aby výměna informací byla po kvalitativní a kvantitativní stránce vždy co nejlépe přizpůsobena měnícím se požadavkům, a proces dopravy tak mohl zůstat co nejschůdnější z ekonomického hlediska a nákladní železniční doprava si mohla zachovat své postavení na trhu i tváří v tvář vysoké konkurenci, které musí čelit.

To vše znamená, že je třeba budovat a modernizovat transevropský konvenční železniční systém pro konvenční železniční dopravu a intermodální dopravu. Potřeba takovéto modernizace železniční části dopravního systému je patrná i při porovnání kritických míst (rozhraní mezi jednotlivými zúčastněnými partnery) v silniční nákladní dopravě a v železniční nákladní dopravě pro jednu zjednodušenou modelovou situaci, jak je ukázáno v příloze A indexu 5 kapitole 1.1.

Konečným cílem této TSI je zvládat správu zásilek za podmínek existence mnoha rozhraní prostřednictvím výměny informací na základě směrnic Evropského parlamentu a Rady 2001/14/ES (1) a 2001/16/ES.

Toto stručné vysvětlení oblasti působnosti TSI subsystému „Využití telematiky v nákladní dopravě“ konvenčního železničního systému též ukazuje její rozdílnost oproti TSI pro subsystém „Provoz a řízení dopravy“. TSI pro subsystém „Provoz a řízení dopravy“ se týká – zejména po bezpečnostní stránce – postupů a souvisejících zařízení umožňujících souvislý provoz jednotlivých strukturálních subsystémů, včetně řízení vlaků a plánování a řízení dopravy, které jsou hlavní náplní práce železničního podniku podle jeho definice (viz kapitola 2.3: Stručný popis subsystému).

TSI subsystému „Využití telematiky“ se týká využití telematiky pro nákladní dopravu a řízení její návaznosti na jiné druhy dopravy, což znamená, že se vedle samotného provozu vlaků zaměřuje na dopravní služby železničního podniku obecně. Po bezpečnostní stránce se zabývá pouze existencí datových prvků, např. nesprávnými nebo neaktuálními hodnotami, které mohou mít vliv na bezpečnost provozu vlaku.

1.2   Místní oblast působnosti

Místní oblastí působnosti této TSI je transevropský konvenční železniční systém, jak je popsán v příloze I směrnice 2001/16/ES. Tuto TSI lze však použít na celou nákladní železniční síť členských států EU, s tím omezením, že požadavky TSI nejsou závazné pro nákladní dopravu přijíždějící ze třetí země nebo jedoucí do třetí země.

1.3   Obsah této TSI

V souladu s čl. 5 odst. 3 směrnice 2001/16/ES tato TSI:

a)	stanoví zamýšlenou oblast působnosti subsystému„Využití telematiky v nákladní dopravě“ – kapitola 2: Definice subsystému a oblast působnosti;

b)	stanoví základní požadavky na tento subsystém a jeho rozhraní s dalšími subsystémy – kapitola 3: ;

c)	stanoví funkční a technické specifikace, které musí splňovat subsystém a jeho rozhraní s dalšími subsystémy – kapitola 4: Popis subsystému ;

d)	určuje prvky interoperability a rozhraní, které musí být předmětem evropských specifikací, včetně evropských norem, a které jsou nezbytné v zájmu dosažení interoperability transevropského konvenčního železničního systému – kapitola 5: Prvky interoperability ;

e)

stanoví v každém zvažovaném případě postup, který má být použit při posuzování shody nebo vhodnosti pro použití. To zahrnuje zejména moduly definované v rozhodnutí Rady 93/465/EHS (2) nebo případně zvláštní postupy, které mají být použity při posuzování shody nebo vhodnosti pro použití prvků interoperability a „ES“ ověřování subsystémů – kapitola 6: Posuzování shody nebo vhodnosti pro použití prvků interoperability a ověřování subsystémů ;

f)	stanoví strategii pro uplatňování této TSI. Zejména je nezbytné stanovit etapy postupného přechodu od současných podmínek sítě ke stavu, kdy síť vyhovovuje TSI – kapitola 7: Uplatňování;

g)	stanoví pro příslušné zaměstnance odborné kvalifikace a podmínky ochrany zdraví a bezpečnosti při práci vyžadované pro provoz a údržbu tohoto subsystému, jakož i pro uplatňování této TSI – kapitola 4: Popis subsystému.

Navíc v souladu s čl. 5 odst. 5 stanoví zvláštní případy pro tuto TSI; ty jsou uvedeny v kapitole 7.4: Zvláštní případy.

A nakonec tato TSI také obsahuje – v kapitole 4 (Popis subsystému) – požadavky na provoz a údržbu specifické pro oblast působnosti uvedenou v odstavcích 1.1 (Technická oblast působnosti) a 1.2 (Místní oblast působnosti) výše.

2.   DEFINICE SUBSYSTÉMU A OBLAST PŮSOBNOSTI

2.1   Funkce spadající do oblasti působnosti TSI

Subsystém „Využití telematiky v nákladní dopravě“ je definován přílohou II směrnice 2001/16/ES, oddíl 2.5 písm. b).

Zahrnuje zejména:

—	využití v nákladní dopravě, včetně informačních systémů (sledování nákladů a vlaků v reálném čase),

—	systémy seřaďování a přidělování, přičemž systémem seřaďování se rozumí řazení vlaků,

—	rezervační systémy, kterými se rozumí rezervace tras vlaků,

—	zabezpečování spojení s jinými druhy dopravy a pořizování elektronických průvodních dokumentů.

2.2   Funkce spadající mimo oblast působnosti TSI

Platební a fakturační systémy pro zákazníky nespadají do oblasti působnosti této TSI, stejně jako systémy pro platby a fakturaci mezi různými poskytovateli služeb, jako jsou železniční podniky nebo provozovatelé infrastruktury. Systém výměny dat podle kapitoly 4.2 (Funkční a technické specifikace subsystému) však poskytuje informace potřebné jako základ pro platby plynoucí z dopravních služeb.

Dlouhodobé plánování jízdních řádů také spadá mimo oblast působnosti této TSI pro subsystém „Využití telematiky“. Nicméně na některých místech se TSI odvolávají na výsledek dlouhodobého plánování, má-li vazbu na účinnou výměnu informací potřebných pro provoz vlaků.

2.3   Stručný popis subsystému

2.3.1   Zúčastněné subjekty

Tato TSI bere v úvahu současné poskytovatele služeb a nejrůznější možné budoucí poskytovatele služeb v oblasti nákladní dopravy, kteří se zabývají činnostmi souvisejícími s (tento výčet není vyčerpávající):

—

vozy,

—	lokomotivami,

—	strojvůdci,

—	posunováním,

—	prodejem segmentů,

—	řízením zásilek,

—	seřazováním vlaků,

—	provozem vlaků,

—	monitorováním vlaků,

—	kontrolou vlaků,

—	monitorováním zásilek,

—	inspekcemi a opravami vozů a lokomotiv,

—	celním odbavením,

—	provozem terminálů pro intermodální dopravu,

—	řízením silniční nákladní dopravy.

Ve směrnicích 2001/14/ES a 2001/16/ES jsou výslovně definováni někteří zvláštní poskytovatelé služeb. Vzhledem k tomu, že je třeba zohlednit obě tyto směrnice, tato TSI přihlíží zejména k definicím následujících pojmů (viz též příloha A index 6):

Na základě této definice považuje tato TSI provozovatele infrastruktury za poskytovatele služeb spojených s přidělováním tras vlaků, kontrolou/monitorováním vlaků a podáváním zpráv v souvislosti s vlaky/trasami.

Podle směrnice 2001/14/ES je subjekt nebo podnik, kterému PI přiděluje trasy, označován jako žadatel.

Na základě této definice považuje tato TSI železniční podnik za poskytovatele služeb pro provoz vlaků.

Pokud jde o přidělování tras vlaků pro provoz vlaků, je třeba vzít v úvahu také článek 13 směrnice 2001/14/ES:

Pokud jde o různé varianty komunikace mezi provozovateli infrastruktury a žadateli při faktické realizaci dopravy („režim realizace“), je nutné brát v úvahu pouze PI a ŽP, a nikoli všechny typy žadatelů, které mohou být relevantní při plánování. V režimu realizace je vždy jasně dán vztah mezi PI a ŽP, pro nějž tato TSI specifikuje výměnu a uchovávání informací. Definice žadatele a možností výsledného přidělení tras zůstávají nedotčeny.

Jak již bylo řečeno, v nákladní dopravě je třeba poskytovat nejrůznější služby. Jednou z nich je kupříkladu poskytování vozů. Tato služba může být vztažena ke správci vozového parku. Je-li tato služba nabízena železničním podnikem, vystupuje ŽP také jako správce vozového parku. Správce vozového parku může spravovat své vlastní vozy a/nebo vozy jiného provozovatele (jiného poskytovatele služeb pro nákladní vozy). Potřeby tohoto typu poskytovatele služeb jsou zohledněny nezávisle, bez ohledu na to, zda je správcem vozového parku ŽP, nebo jiný subjekt.

Tato TSI nevyváří nové právní subjekty a nenutí ŽP najímat externí poskytovatele služeb na služby, které ŽP nabízí sám, ale kde je to třeba, odvolává se v souvislosti se službou na označení poskytovatele této služby. Nabízí-li službu ŽP, rozumí se poskytovatelem dané služby on sám.

Vezmeme-li v úvahu potřeby zákazníka, jednou ze služeb je organizovat a řídit dopravu v souladu s jeho zájmy. Tuto službu zajišťuje „hlavní železniční podnik“ (hlavní ŽP nebo HŽP). HŽP je jediným kontaktním místem pro zákazníka. Je-li v dopravním řetězci zapojen více než jeden ŽP, HŽP odpovídá také za koordinaci s ostatními ŽP.

Tuto službu může rovněž vykonávat dopravce nebo jakýkoli jiný subjekt.

Role ŽP jako HŽP se může lišit mezi jednotlivými typy dopravních toků. V intermodální dopravě provádí řízení kapacity ucelených vlaků a přípravu nákladních listů integrátor intermodální dopravy, který by se pak stal zákazníkem HŽP.

Nejdůležitější je ale to, že železniční podniky a provozovatelé infrastruktury a všichni ostatní poskytovatelé služeb (ve výše definovaném smyslu) musejí pracovat společně, ať už prostřednictvím spolupráce nebo otevřeného přístupu, a též prostřednictvím efektivní výměny informací, chtějí-li zákazníkovi poskytovat souvislé služby.

2.3.2   Uvažované procesy

Tato TSI pro nákladní železniční dopravu je podle směrnice 2001/16/ES omezena pouze na PI a ŽP/HŽP ve vztazích k jejich přímým zákazníkům.

Při poskytování služeb nákladní dopravy začíná činnost HŽP, pokud jde o zásilku, převzetím nákladního listu od jeho zákazníka a, kupříkladu pro ucelené vozové zásilky, okamžikem připravení vozů k odsunu. HŽP vytvoří předběžný plán přepravy pro jízdu (na základě zkušeností resp. smlouvy). Hodlá-li HŽP ponechat ucelenou vozovou zásilku ve vlaku v režimu otevřeného přístupu (HŽP provozuje vlak po celou dobu jízdy), je předběžný plán přepravy zároveň plánem konečným. Hodlá-li HŽP umístit ucelenou vozovou zásilku do vlaku, na němž spolupracují jiné ŽP, musí napřed zjistit, které ŽP má oslovit a kdy může nastat výměna mezi dvěma na sebe navazujícími ŽP. Poté HŽP připraví pro každý ŽP zvlášť předběžné vozové příkazy, které jsou součástí celého nákladního listu. Vozové příkazy jsou specifikovány v kapitole 4.2.1 (Údaje nákladního listu).

Oslovené ŽP si ověří dostupnost zdrojů pro provoz vozů a dostupnost trasy vlaku. Odpovědi od jednotlivých ŽP umožní HŽP doladit plán přepravy nebo začít nové dotazování – třeba i u jiných ŽP – dokud plán přepravy nevyhoví požadavkům zákazníka.

Železniční podniky/hlavní železniční podniky musí mít obecně schopnost přinejmenším:

—	DEFINOVAT služby, pokud jde o cenové podmínky a doby přepravy, nabídku vozů (je-li to vhodné), informace o vozech/intermodálních jednotkách (poloha, stav a předpokládanou dobu příjezdu (ETA) vozu/intermodální jednotky), místa, kde mohou být zásilky naloženy do prázdných vozů, kontejnerů atd.,

—	POSKYTOVAT stanovené služby spolehlivým, nerušeným způsobem prostřednictvím využití společných obchodních postupů a vzájemně provázaných systémů. ŽP, PI a jiní poskytovatelé služeb a zúčastnění partneři, jako je celní správa, si musejí být schopni vyměňovat informace elektronickou cestou,

—	POROVNAT kvalitu poskytnuté služby s tím, co bylo stanoveno, tj. shodu fakturované ceny s cenou nabízenou, shodu skutečné doby průjezdu oproti přislíbené, počet objednaných a dodaných vozů, doby ETA a skutečné časy příjezdu,

—	FUNGOVAT produktivním způsobem, pokud jde o využívání kapacity vlaků, infrastruktury a vozového parku, prostřednictvím vhodných vnitropodnikových postupů, systémů a výměny dat potřebných pro plánování vozů/intermodálních jednotek a vlaků.

ŽP/HŽP jako žadatelé musí rovněž zajistit (prostřednictvím smluv s provozovateli infrastruktury) požadovanou trasu vlaku a musí zajistit provoz vlaku po příslušnou část jízdy. Pro trasu vlaku mohou využít již rezervované (v režimu plánování) trasy nebo si mohou vyžádat ad hoc trasu vlaku od provozovatele (provozovatelů) infrastruktury, jemuž (jimž) přináleží příslušná (příslušné) část jízdy, ve které ŽP vlak provozuje. V příloze A indexu 5 kapitole 1.2 je uveden příklad týkající se žádosti o trasu.

Vlastnictví trasy je důležité také pro komunikaci mezi PI a ŽP v průběhu jízdy vlaku. Při komunikaci je vždy třeba používat číslo vlaku a trasy sdělené provozovatelem infrastruktury železničnímu podniku, který si rezervoval trasu vlaku na infrastruktuře tohoto PI (viz též příloha A index 5 kapitola 1.2).

Zajišťuje-li ŽP celou jízdu z bodu A do bodu F (otevřený přístup ŽP bez účasti dalších železničních podniků), pak každý PI, kterého se cesta týká, komunikuje pouze s tímto ŽP. Tento „otevřený přístup“ ŽP lze realizovat rezervováním kompletní trasy vlaku najednou („pod jednou střechou“ – tzv. One Stop Shop) nebo po částech přímo s každým PI. Tato TSI zohledňuje oba případy, jak je vidět v kapitole 4.2.2.1: Žádost o trasu, Úvodní poznámky.

Průběh dialogu mezi železničními podniky a provozovateli infrastruktury ohledně vytvoření trasy vlaku pro nákladní vlak je popsán v kapitole 4.2.2 (Žádost o trasu). Tento dialog se vztahuje k čl. 23 odst. 1 směrnice 2001/14/ES. Součástí dialogu nejsou obstarání licence pro ŽP poskytující služby podle směrnice Evropského parlamentu a Rady 2001/13/ES (3), osvědčení podle směrnice 2001/14/ES ani přístupová práva podle směrnice Rady 91/440/EHS (4).

V kapitole 4.2.3 (Příprava vlaku) je definována výměna informací týkajících se řazení vlaku a postupů souvisejících s odjezdem vlaku. Výměna údajů v průběhu jízdy vlaku v případě normálního provozu je popsána v kapitole 4.2.4 (Prognóza jízdy vlaku) a hlášení pro výjimečné případy jsou definována v kapitole 4.2.5 (Informace v případě narušení ). Informace potřebné pro vystopování polohy vlaku jsou definovány v kapitole 4.2.6 (Umístění vlaku). Všechny tyto informace si vyměňují ŽP a PI o jednotlivých vlacích.

Pro zákazníka je nejdůležitější informací vždy předpokládaná doba příjezdu (ETA) jeho zásilky. ETA lze vypočítat z informací, které si vyměňuje HŽP a PI (v případě otevřeného přístupu). V případě spolupráce s různými ŽP lze stanovit ETA a též předpokládané doby střídání železničních podniků (ETI) z informací, které si vyměňují železniční podniky a provozovatelé infrastruktury a které jsou poskytovány železničními podniky hlavnímu ŽP (kapitola 4.2.7).

Z výměny informací mezi PI a ŽP ví HŽP také kupříkladu:

—	kdy vozy odjely ze seřaďovacího nádraží nebo přijely na seřaďovací nádraží nebo kdy odjely z/přijely do určitých míst (kapitola 4.2.8 vozu) nebo

—	kdy přešla odpovědnost za vozy v dopravním řetězci z jednoho ŽP na druhý (kapitola 4.2.9 výměny).

Z údajů vyměňovaných mezi PI a ŽP ve spojení s údaji vyměňovanými mezi železničními podniky a HŽP lze odvodit nejrůznější statistické informace:

—	pro – ve středně dlouhém období – podrobnější plánování přepravního procesu a

—	pro – v dlouhém období – strategické plánování a studie kapacity (např. analýzy sítě, vymezení vedlejších kolejí a seřaďovacích nádraží, plánování vozového parku), ale především

—	pro zlepšení kvality dopravní služby a produktivity (kapitola 4.2.10 Výměna údajů za účelem zlepšení kvality).

Manipulace s prázdnými vozy je důležitá zejména tehdy, jde-li o vozy, které může používat více subjektů. V zásadě není rozdíl mezi manipulací s naloženými a prázdnými vozy. Přeprava prázdných vozů vychází také z vozových příkazů, u kterých je za zákazníka objednávajícího tyto prázdné vozy považován správce vozového parku.

2.3.3   Obecné poznámky

Kvalita každého informačního systému závisí na spolehlivosti údajů v něm obsažených. Proto hrají údaje rozhodující úlohu při zpracování zásilky; každý vůz nebo kontejner musí být v systému zachycen přesně a hospodárně – to znamená, že by údaje o něm měly být do systému zadány pouze jednou.

Proto aplikace a zprávy této TSI odstraňují nutnost opakovaně ručně zadávat údaje prostřednictvím přístupu k již uloženým údajům, např. referenčním údajům o kolejových vozidlech. Požadavky týkající se referenčních údajů o kolejových vozidlech jsou vymezeny v kapitole 4.2.11 (Hlavní referenční údaje). Uvedené referenční databáze kolejových vozidel musejí umožňovat snadný přístup k technickým údajům. Obsah databází musí být přístupný na bázi diferencovaných přístupových práv všem PI, ŽP a správcům vozového parku, zejména pro účely správy a údržby kolejových vozidel. Databáze musí obsahovat všechny rozhodující technické údaje pro dopravu, jako jsou:

—	identifikace kolejových vozidel,

—	technické údaje/údaje o konstrukci,

—	posouzení kompatibility s infrastrukturou,

—	posouzení charakteristik důležitých pro nakládku,

—	posouzení brzdných vlastností,

—	údaje o údržbě,

—	ekologické charakteristiky.

Při intermodální dopravě se vůz na různých místech (označovaných jako terminály) nejenom přeřazuje na jiný vlak, ale intermodální jednotku lze překládat z vozu do vozu. V důsledku toho nestačí pracovat pouze s plánem přepravy pro vozy, ale musí být vypracován také plán přepravy pro intermodální jednotky.

V kapitole 4.2.12 (Různé referenční soubory a databáze) jsou uvedeny některé referenční soubory a různé databáze, mj. provozní databáze vozů a intermodálních jednotek. Tato databáze obsahuje údaje o provozním stavu kolejových vozidel, informace o hmotnosti a nebezpečných věcech, informace týkající se intermodálních jednotek a informace o poloze. V kapitole 4.2.13 (Předávání dokumentů v elektronické podobě) jsou stanoveny požadavky na předávání dokumentů v elektronické podobě.

TSI pro subsystém „Využití telematiky v nákladní dopravě“ definuje požadované informace, které si musejí vyměňovat jednotliví partneři zapojení do dopravního řetězce, a umožňuje zavedení povinného standardního postupu výměny údajů. Ukazuje též vhodnou strukturu a architekturu pro tuto komunikaci. Ty jsou popsány v kapitole 4.2.14 (Sítě a komunikace) s přihlédnutím k:

—	rozhraní se subsystémem „Provoz a řízení dopravy“ transevropského konvenčního železničního systému dle čl. 5 odst. 3 směrnice Rady 2001/16/ES,

—	požadavkům na obsah zprávy o síti, které jsou stanoveny v článku 3 a příloze I směrnice 2001/14/ES,

—	informacím dostupným o nákladních vozech a požadavkům týkajícím se údržby dle TSI pro subsystém „Kolejová vozidla“.

Ze subsystému „Využití telematiky v nákladní dopravě“ nedochází k přímému přenosu údajů do vlaku, k strojvůdci nebo do částí subsystému „Řízení a zabezpečení“ a fyzická přenosová síť je zcela oddělena od sítě používané subsystémem „Řízení a zabezpečení“. Systém ERTMS/ETSC používá GSM-R. Specifikace ETCS pro tuto otevřenou síť stanoví, že bezpečnosti se dosahuje vhodným managementem rizik otevřených sítí v protokolu EURORADIO.

Rozhraní se strukturálními subsystémy „Kolejová vozidla“ a „Řízení a zabezpečení“ jsou zajišťována pouze přes referenční databáze kolejových vozidel (kapitola 4.2.11.3: Referenční databáze kolejových vozidel), které spravují jejich držitelé. Rozhraní se subsystémy „Infrastruktura“, „Řízení a zabezpečení“ a „Energie“ jsou zajišťována prostřednictvím definice tras (kapitola 4.2.2.3: Zpráva Údaje o trase) od PI, kde jsou specifikovány hodnoty pro vlak, které se týkají infrastruktury, a prostřednictvím informací poskytovaných provozovateli infrastruktury o omezeních na infrastruktuře (kapitola 4.2.11.2: Databáze informací o omezeních na infrastruktuře).

3.   ZÁKLADNÍ POŽADAVKY

3.1   Vyhovění základním požadavkům

Podle čl. 4 odst. 1 směrnice 2001/16/ES musí transevropský konvenční železniční systém, subsystémy a jejich prvky interoperability vyhovovat základním požadavkům stanoveným ve všeobecných podmínkách v příloze III směrnice.

V oblasti působnosti této TSI bude splnění odpovídajících základních požadavků na subsystém uvedených v kapitole 3 této TSI zajištěno splněním specifikací popsaných v kapitole 4: Popis subsystému.

3.2   Základní požadavky

Základní požadavky se týkají:

—	bezpečnosti,

—	spolehlivosti a dostupnosti,

—	ochrany zdraví,

—	ochrany životního prostředí,

—	technické kompatibility.

Podle směrnice 2001/16/ES mohou být základní požadavky obecně použitelné na celý transevropský konvenční železniční systém nebo mohou být specifické pro každý subsystém a jeho prvky.

3.3   Obecné požadavky

V případě subsystému „Využití telematiky v nákladní dopravě“ se uplatňují tato obecná hlediska:

3.3.1   Bezpečnost

V souladu s přílohou III směrnice 2001/16/ES se na subsystém „Využití telematiky v nákladní dopravě“ vztahují tyto základní požadavky týkající se bezpečnosti:

—

Základní požadavek 1.1.1 přílohy III směrnice 2001/16/ES: „Návrh, konstrukce nebo montáž, údržba a kontrola konstrukčních částí zásadně důležitých pro bezpečnost, a zejména konstrukčních částí souvisejících s jízdou vlaku, musí zaručovat bezpečnost na úrovni odpovídající cílovým záměrům stanoveným pro síť, včetně cílových záměrů pro řešení situací za zhoršených podmínek.“ Tento základní požadavek není pro subsystém „Využití telematiky“ relevantní.

—	Základní požadavek 1.1.2 přílohy III směrnice 2001/16/ES: „Parametry související se stykem kolo-kolejnice musí splňovat požadavky na stabilitu nezbytné k zaručení bezpečné jízdy při nejvyšší dovolené rychlosti.“ Tento základní požadavek není pro subsystém „Využití telematiky“ relevantní.

—

Základní požadavek 1.1.3 přílohy III směrnice 2001/16/ES: „Použité konstrukční části musí odolat každému stanovenému normálnímu nebo výjimečnému namáhání po celou dobu provozu. Důsledky veškerých náhodných poruch pro bezpečnost musí být omezeny vhodnými prostředky.“ Tento základní požadavek není pro subsystém „Využití telematiky“ relevantní.

—	Základní požadavek 1.1.4 přílohy III směrnice 2001/16/ES: „Konstrukce pevných zařízení a kolejových vozidel a volba použitých materiálů musí směřovat k omezení vzniku, šíření a účinků ohně a kouře v případě požáru.“ Tento základní požadavek není pro subsystém „Využití telematiky“ relevantní.

—

Základní požadavek 1.1.5 přílohy III směrnice 2001/16/ES: „Veškerá zařízení určená k tomu, aby jimi manipulovali uživatelé, musí být navržena tak, aby neohrozila jejich bezpečnost, jsou-li používána předvídatelným způsobem, který není v souladu s vyznačenými pokyny.“ Tento základní požadavek není pro subsystém „Využití telematiky“ relevantní.

3.3.2   Spolehlivost a dostupnost

Tento základní požadavek je splněn těmito kapitolami:

Kapitola 4.2.11: Hlavní referenční údaje,

Kapitola 4.2.12: Různé referenční soubory a databáze,

Kapitola 4.2.14: Sítě a komunikace.

3.3.3   Ochrana zdraví

—

Základní požadavek 1.3.1 přílohy III směrnice 2001/16/ES: „Materiály, které mohou na základě způsobu jejich používání představovat ohrožení pro zdraví osob, které k nim mají přístup, nesmějí být ve vlacích a v železniční infrastruktuře používány.“ Tento základní požadavek není pro subsystém „Využití telematiky“ relevantní.

—

Základní požadavek 1.3.2 přílohy III směrnice 2001/16/ES: „Všechny materiály musí být vybírány, rozmísťovány a používány takovým způsobem, aby byla omezena emise škodlivého a nebezpečného kouře nebo plynů, zejména v případě požáru.“ Tento základní požadavek není pro subsystém „Využití telematiky“ relevantní.

3.3.4   Ochrana životního prostředí

—

Základní požadavek 1.4.1 přílohy III směrnice 2001/16/ES: „Ve fázi návrhu systému musí být posouzen a zohledněn vliv stavby a provozu transevropského vysokorychlostního železničního systému na životní prostředí v souladu s platnými předpisy Společenství.“ Tento základní požadavek není pro subsystém „Využití telematiky“ relevantní.

—

Základní požadavek 1.4.2 přílohy III směrnice 2001/16/ES: „Materiály používané ve vlacích a v infrastruktuře musí zabraňovat emisi kouře nebo plynů, které jsou pro životní prostředí škodlivé a nebezpečné, zejména v případě požáru.“ Tento základní požadavek není pro subsystém „Využití telematiky“ relevantní.

—

Základní požadavek 1.4.3 přílohy III směrnice 2001/16/ES: „Kolejová vozidla a napájecí systémy musí být navrženy a vyrobeny takovým způsobem, aby byly elektromagneticky kompatibilní s instalacemi, zařízeními a veřejnými nebo soukromými sítěmi, s nimiž by se mohly vzájemně rušit.“ Tento základní požadavek není pro subsystém „Využití telematiky“ relevantní.

—	Základní požadavek 1.4.4 přílohy III směrnice 2001/16/ES: „Při provozu transevropského konvenčního železničního systému musí být dodržovány stanovené meze hluku.“ Tento základní požadavek není pro subsystém „Využití telematiky“ relevantní.

—

Základní požadavek 1.4.5 přílohy III směrnice 2001/16/ES: „Provoz transevropského konvenčního železničního systému nesmí za normálního stavu údržby vyvolávat nepřípustné úrovně zemních vibrací působících na činnosti a prostředí v blízkosti infrastruktury.“ Tento základní požadavek není pro subsystém „Využití telematiky“ relevantní.

3.3.5   Technická kompatibilita

—

Základní požadavek 1.5 přílohy III směrnice 2001/16/ES: „Technické vlastnosti infrastruktury a pevných zařízení musí být kompatibilní jak navzájem, tak s vlastnostmi vlaků, které mají být používány v transevropském vysokorychlostním železničním systému. Jestliže se dodržování těchto vlastností ukáže být na určitých úsecích sítě obtížné, mohou být zavedena dočasná řešení, která zajistí kompatibilitu v budoucnu.“ Tento základní požadavek není pro subsystém „Využití telematiky“ relevantní.

3.4   Specifická hlediska týkající se subsystému „Využití telematiky v nákladní dopravě“

3.4.1   Technická kompatibilita

—

Základní požadavek 2.7.1 přílohy III směrnice 2001/16/ES: „Základními požadavky na využití telematiky musí být zaručena minimální jakost služeb v oblasti přepravy cestujících a v oblasti nákladní dopravy, zejména s ohledem na technickou kompatibilitu. Je třeba přijmout opatření, která zajistí: — aby databáze, programové vybavení a datové komunikační protokoly byly vypracovány způsobem umožňujícím co nejrozsáhlejší vzájemnou výměnu dat mezi různými aplikacemi a provozovateli, s výjimkou důvěrných obchodních údajů, — aby uživatelé měli snadný přístup k informacím.“ Tento základní požadavek je splněn zejména těmito kapitolami: — Kapitola 4.2.11: Hlavní referenční údaje, — Kapitola 4.2.12: Různé referenční soubory a databáze, — Kapitola 4.2.14: Sítě a komunikace.

3.4.2   Spolehlivost a dostupnost

—

Základní požadavek 2.7.2 přílohy III směrnice 2001/16/ES: „Metodami používání, řízení, aktualizace a udržování těchto databází, programového vybavení a datových komunikačních protokolů musí být zaručena účinnost těchto systémů a kvalita služeb.“ Tento požadavek je splněn zejména těmito kapitolami: — Kapitola 4.2.11: Hlavní referenční údaje, — Kapitola 4.2.12: Různé referenční soubory a databáze, — Kapitola 4.2.14: Sítě a komunikace. Nicméně tento základní požadavek, zejména to, aby metody používání zaručovaly účinnost a kvalitu služeb, je podstatou celé TSI a neomezuje se pouze na uvedené kapitoly.

3.4.3   Ochrana zdraví

—

Základní požadavek 2.7.3 přílohy III směrnice 2001/16/ES: „Rozhraní mezi těmito systémy a uživateli musí vyhovovat minimálním pravidlům pro ergonomii a ochranu zdraví.“ Tato TSI nestanoví žádné doplňující požadavky k existujícím vnitrostátním a evropským předpisům o ergonomii a ochraně zdraví pro rozhraní mezi těmito systémy a uživateli.

3.4.4   Bezpečnost

—

Základní požadavek 2.7.4 přílohy III směrnice 2001/16/ES: „Pro uchovávání a přenos informací vztahujících se k bezpečnosti musí být zajištěny vhodné úrovně integrity a spolehlivosti.“ Tento požadavek je splněn zejména těmito kapitolami: — Kapitola 4.2.11: Hlavní referenční údaje, — Kapitola 4.2.12: Různé referenční soubory a databáze, — Kapitola 4.2.14: Sítě a komunikace.

4.   POPIS SUBSYSTÉMU

4.1   Úvod

Transevropský konvenční železniční systém, na který se vztahuje směrnice 2001/16/ES a jehož součástí je subsystém „Využití telematiky“, je integrovaný systém, u něhož musí být ověřována soudržnost. Toto ověřování soudržnosti se týká zejména základních parametrů subsystému, jeho rozhraní se systémem, jehož je součástí, a předpisů pro provoz a údržbu.

Při uvážení všech příslušných základních požadavků je subsystém „Využití telematiky v nákladní dopravě“ charakterizován takto:

4.2   Funkční a technické specifikace subsystému

Ve světle základních požadavků v kapitole 3 (Základní požadavky) jsou funkční a technické specifikace subsystému stanoveny takto:

—	údaje na nákladním listu,

—	žádost o trasu,

—	příprava vlaku,

—	prognóza jízdy vlaku,

—	informace v případě narušení provozu,

—	poloha vlaku,

—	ETI/ETA vozu/intermodální jednotky,

—	pohyb vozu,

—	vykazování střídání,

—	výměna údajů za účelem zlepšení kvality,

—	hlavní referenční údaje,

—	různé referenční soubory a databáze,

—	předávání dokumentů v elektronické podobě,

—	sítě a komunikace.

Podrobné specifikace jsou nastíněny v dalším textu. Další informace o formátech zpráv najdete v příloze A indexu 1.

Obecné poznámky ke struktuře zpráv

Zprávy jsou strukturovány do dvou skupin:

—	řídící údaje: vysvětlení viz níže,

—	informační údaje: informace aplikací.

Kontrolní údaje obsahují tyto prvky:

—	stav: zpráva může mít některý z těchto statutů: — „nová zpráva“, jde-li o novou zprávu, — „změna“, jde-li o pozměněnou verzi dříve zaslané zprávy, — „výmaz“, má-li být dříve zaslaná zpráva vymazána,

—	identifikační údaje o zprávě s těmito prvky: — typ zprávy: např. „žádost o trasu“ nebo „dotaz ohledně jízdy vlaku“, — datum a čas: datum a čas, kdy byla zpráva odeslána, — číslo zprávy: číslo přidělené zprávě odesílatelem,

—

identifikační údaje související zprávy, je-li zpráva odpovědí na obdrženou dřívější zprávu (totožné s identifikačními údaji obdržené zprávy), s těmito prvky: — typ související zprávy: typ obdržené zprávy, — datum a čas související zprávy: datum a čas obdržené zprávy, — číslo související zprávy: číslo obdržené zprávy,

—	odesílatel zprávy,

—	příjemce zprávy.

Další kapitoly se týkají hlavně „nových zpráv“. Kapitola 4.2.2 Žádost o trasu se týká též „výmazů“.

4.2.1   Údaje nákladního listu

4.2.1.1   Nákladní list zákazníka

Nákladní list zasílá zákazník hlavnímu ŽP. Na nákladním listu musí být vyznačeny všechny informace potřebné pro přepravu zásilky od odesílatele k příjemci. HŽP musí k těmto údajům doplnit další informace. Tyto údaje, včetně doplněných, jsou uvedeny v tabulce v příloze A indexu 3 (popis údajů viz příloha A index 3); v řádku „Údaje na nákladním listu“ je udáno, zda jsou povinné, nebo volitelné a zda je dodává odesílatel, nebo HŽP.

V případě otevřeného přístupu má hlavní ŽP jednající se zákazníkem všechny informace včetně doplňujících údajů. Nepotřebuje si vyměňovat žádné zprávy s jinými ŽP. Tyto údaje tvoří též základ pro rychlou žádost o trasu, je-li to zapotřebí pro provedení přepravy.

Následující zprávy jsou určeny pro případ, kdy se nejedná o tzv. otevřený přístup. Obsah těchto práv může být též základem pro rychlé žádosti o trasu, je-li to zapotřebí pro splnění nákladního listu.

4.2.1.2   Vozové příkazy

Vozový příkaz je primárně podmnožinou informací na nákladním listu. Musí být předán železničním podnikům zapojeným do dopravního řetězce, neboť by se mohl stát podkladem pro ad hoc žádost o trasu (kapitola 4.2.2: Žádost o trasu). Vozový příkaz musí obsahovat náležité informace, které potřebuje ŽP k uskutečnění dopravy, za niž zodpovídá, až do předávky dalšímu ŽP. Proto obsah příkazu závisí na úloze, kterou má ŽP sehrát: výchozí, tranzitní nebo cílový ŽP (ORU, TRU, DRU).

—	vozový příkaz pro výchozí ŽP (Origin Railway Undertaking, ORU),

—	vozový příkaz pro tranzitní ŽP (Transit Railway Undertaking, TRU),

—	vozový příkaz pro dodací ŽP (Delivery Railway Undertaking, DRU).

Údaje na vozových příkazech podle jednotlivých úloh ŽP jsou podrobně uvedeny v příloze A indexu 3, s vyznačením, zda se jedná o údaje povinné, nebo nepovinné. Podrobné formáty těchto zpráv jsou stanoveny v příloze A indexu 1.

Hlavní obsah těchto vozových příkazů tvoří následující údaje:

—	informace o odesílateli a příjemci,

—	informace o směrování,

—	identifikace zásilky,

—	informace o vozu,

—	časové a místní údaje.

Vybrané údaje z nákladního listu musí být navíc přístupné všem partnerům (např. PI, držiteli…) v dopravním řetězci včetně zákazníků. Jde zejména o tyto údaje týkající se jednotlivých vozů:

—	hmotnost nákladu (hrubá hmotnost nákladu),

—	číslo CN/HS,

—	informace o nebezpečných věcech,

—	přepravní jednotka.

4.2.2   Žádost o trasu

4.2.2.1   Úvodní poznámky

Dlouhodobé plánování

Prvek „trasa vlaku“ definuje údaje, které je třeba uchovávat, o vyžádané, schválené a skutečné trase vlaku a charakteristiky vlaku pro každý úsek této trasy. V dalším textu najdete popis informací, které musí mít k dispozici PI. Podrobnější popis viz příloha A index 4.

Tyto informace musejí být aktualizovány, kdykoli dojde ke změně.

Hlavní údaje o trase:

—	Identifikace trasy vlaku (číslo trasy). Trasu může představovat buď naplánované využití kapacity v určitém úseku trati, nebo skutečné provozování vlaku po stanovené koleji v určitém úseku trati. Přesná povaha tohoto prvku závisí na procesech používaných v PI.

—	Výchozí bod trasy, což je místo, kde trasa začíná, společně s datem a časem odjezdu vlaku na tuto trasu.

—	Cíl trasy vlaku, což je místo, kde trasa končí, společně s datem a časem řádného příjezdu do tohoto místa určení.

—

Popis úseku jízdy, který definuje údaje poskytované provozovatelem infrastruktury pro každý schválený úsek jízdy – z výchozí stanice do první nácestné stanice, dalších nácestných stanic a z poslední nácestné stanice do koncového bodu schválené jízdy. Tento popis může obsahovat tyto údaje: — nácestné stanice nebo jiné určené body podél navrhované trasy spolu s datem a časem příjezdu, odjezdu nebo průjezdu těmito průjezdními body a spolu s kódem činnosti popisujícím činnost, která má být v daném průjezdním bodu trasy prováděna, — identifikace PI odpovědného za řízení dopravy na daném úseku jízdy a identifikace PI odpovědného za řízení dopravy na navazujícím úseku, — popis zařízení (řídicí a kontrolní systém, radiotelefonní systém apod.), kterými má být vlak vybaven; tato zařízení musí být kompatibilní s infrastrukturou, aby umožňovala trakci, kontrolu a komunikaci mezi vlakem a řídicím místem PI, — údaje týkající se vlaku pro daný úsek jízdy: max. hmotnost, max. délka, max. rychlost, max. hmotnost na nápravu, min. brzdná síla, max. hmotnost na metr délky, informace o překročené ložné míře, označení nedovolených nebezpečných věcí, — číslo trasy, — dodatečná doba průjezdu úsekem trati vyhrazená na vyrovnání zpoždění, potíže na trase apod.

Smlouva o realizaci trasy: před průjezdem vlaku musí být úsek jízdy aktualizován a doplněn o aktuální hodnoty. Režim realizace je nezávislý na režimu plánování.

Rychlá žádost o trasu

V důsledku výjimek nastalých v průběhu jízdy vlaku nebo v důsledku poptávky po dopravě oznámené s malým časovým předstihem musí mít ŽP možnost získat ad hoc trasu v síti.

V prvním případě je třeba podniknout okamžité kroky, přičemž je známo skutečné řazení vlaku na základě výkazu vozidel vlaku.

Ve druhém případě musí ŽP poskytnout provozovateli infrastruktury všechny potřebné údaje o tom, kdy a kudy je potřeba, aby vlak jel, společně s fyzickými charakteristikami, které se týkají infrastruktury. Tyto údaje jsou předkládány hlavně v přiloženém nákladním listu, resp. ve vozových příkazech.

Dohoda o přidělení trasy s malým časovým předstihem vychází z dialogu mezi železničními podniky a provozovateli infrastruktury. Do tohoto dialogu jsou zapojeny všechny ŽP a PI, kterých se týká pohyb vlaku po požadované trase, avšak každý z nich může k nalezení trasy přispět jiným způsobem. Podle článku 13 směrnice 2001/14/ES existují v zásadě dvě obecně platné modelové situace pro nákladní dopravu provozovanou na infrastrukturách několika PI (viz též příloha A index 5 kapitola 1.3).

—	Modelová situace A: ŽP kontaktuje všechny dotčené PI přímo (případ A) nebo využije OSS (One Stop Shop, „pod jednou střechou“) (případ B), aby zorganizoval trasy pro celou jízdu. V tomto případě ŽP také podle článku 13 směrnice 2001/14/ES zajišťuje provoz vlaku po celou dobu jízdy.

—	Modelová situace B: Každý ŽP podílející se na přepravní jízdě kontaktuje místní provozovatele infrastruktury přímo nebo prostřednictvím OSS, aby si vyžádal trasu pro úsek jízdy, na kterém zajišťuje provoz vlaku.

Poznámka: Jak již bylo řečeno v kapitole 2 (Definice subsystému a oblast působnosti), v režimu realizace vždy PI komunikuje s ŽP, který si zarezervoval trasu. Proto je pro výměnu informací během jízdy vlaku důležité „vlastnictví trasy“.

V obou situacích dochází k rezervování trasy s malým časovým předstihem na základě dialogu mezi zúčastněným ŽP a PI, popsaného na další stránce.

Následující tabulka ukazuje zprávy používané při dialogu v souvislosti s žádostí o trasu:

Tabulka 1

Žádost o trasu

Zpráva	Vysvětlení
Zprávy používané při dialogu v souvislosti s žádostí o trasu
Žádost o trasu	Tuto zprávu musí zaslat ŽP zúčastněnému (zúčastněným) PI, chce-li si narychlo vyžádat trasu.
Údaje o trase	Touto zprávou musí potvrdit PI železničnímu podniku údaje o trase v odpovědi na žádost ŽP o trasu, v případě potřeby se změněnými hodnotami nebo, nemůže-li PI žádosti o trasu vyhovět, se sdělením „Nejsou k dispozici žádné alternativy“.
Trasa potvrzena	Touto zprávou musí potvrdit ŽP provozovateli infrastruktury, že souhlasí s „údaji o trase“, které obdržel od PI v reakci na svou původní žádost.
Údaje o trase odmítnuty	Tuto zprávu musí zaslat ŽP provozovateli infrastruktury, když nepřijímá „údaje o trase“, které obdržel od PI v reakci na svou původní žádost, obsahují-li tyto údaje změněné hodnoty, které ŽP nemůže akceptovat.

Tento dialog končí potvrzením trasy ze strany ŽP nebo stažením žádosti o trasu (zpráva Žádost o trasu se statutem „výmaz“, viz kapitola 4.2: Funkční a technické specifikace subsystému, Obecné poznámky ke struktuře zpráv). Na zprávu „Údaje o trase odmítnuty“ od ŽP musí vždy navazovat nová zpráva Údaje o trase. Nemůže-li PI vyhovět žádosti o trasu novým návrhem údajů o trase, musí železničnímu podniku zaslat zprávu Údaje o trase obsahující sdělení „Nejsou k dispozici žádné alternativy“, která končí dialog.

Ať už byla trasa rezervována v rámci dlouhodobého plánování, nebo narychlo, musí mít ŽP vždy možnost rezervaci zrušit. Ke zrušení rezervace je třeba použít následující zprávu.

Tabulka 2

Zrušení trasy železničním podnikem

Zpráva	Vysvětlení
Zpráva ke zrušení rezervace trasy železničním podnikem
Trasa zrušena	Touto zprávou sděluje ŽP provozovateli infrastruktury, že má zrušit rezervaci trasy nebo její části.

Na základě dohody o trase může ŽP očekávat, že mu bude rezervovaná trasa k dispozici. Dojde-li k události, v jejímž důsledku není rezervovaná trasa k dispozici, PI o tom musí ŽP informovat, jakmile se o této skutečnosti dozví. Příčinou nedostupnosti rezervované trasy může být kupříkladu přerušení na trase. K takové situaci může nastat kdykoli mezi okamžikem nasmlouvání trasy vlaku a odjezdem vlaku. PI je povinen zaslat alternativní nabídku společně se zprávou, že „trasa není k dispozici“. Není-li toto možné, musí PI poslat nabídku co nejdříve. Zprávou „Trasa není k dispozici“ zahajuje PI dialog o nové trase.

Zprávy používané při dialogu v souvislosti se zrušením rezervované trasy ze strany PI.

Tabulka 3

Zrušení trasy provozovatelem infrastruktury

Zpráva	Vysvětlení
Zprávy používané v souvislosti se zrušením trasy ze strany PI
Trasa není k dispozici	Touto zprávou oznamuje provozovatel infrastruktury železničnímu podniku, že rezervovaná trasa není k dispozici.
Údaje o trase	Touto zprávou musí PI navrhnout železničnímu podniku alternativní trasu poté, co mu sdělil, že rezervovaná trasa není k dispozici.
Trasa potvrzena	Touto zprávou musí ŽP potvrdit provozovateli infrastruktury, že souhlasí s trasou navrženou ve zprávě Trasa není k dispozici.
Údaje o trase odmítnuty	Tuto zprávu musí zaslat ŽP provozovateli infrastruktury, když nepřijímá návrh PI ve zprávě Trasa není k dispozici. V takovém případě musí PI zaslat nový návrh. Tento dialog končí ŽP související zprávou „Trasa zrušena“ vztaženou ke zprávě PI „Trasa není k dispozici“.

Nemůže-li příjemce odpovědět na žádost nebo dotaz v reálném čase, musí to sdělit odesílateli zprávy (kupříkladu tehdy, nemůže-li PI okamžitě odpovědět na Žádost o trasu zprávou Údaje o trase). Činí tak prostřednictvím této zprávy:

Tabulka 4

Potvrzení o přijetí zprávy

Zpráva	Vysvětlení
Tato zpráva má obecnou platnost
Potvrzení o přijetí zprávy	Tuto zprávu musí zaslat příjemce zprávy jejímu odesílateli, nemůže-li dát požadovanou odpověď v termínu stanoveném v kapitole 4.4 (Další požadavky na databáze), odstavci „včasnost“.

V kapitolách, které následují, jsou popsány hlavní body těchto zpráv. Podrobné formáty těchto zpráv jsou stanoveny v příloze A indexu 1. Logický sled těchto zpráv je vyznačen ve schématech v příloze A indexu 5 kapitola 2.1 až 2.3.

4.2.2.2   Zpráva Žádost o trasu

Jde o žádost o trasu vlaku, kterou podává ŽP provozovateli infrastruktury. Žádost o trasu musí obsahovat tyto náležitosti:

—	místo odjezdu: místo, kde začíná navrhovaná trasa,

—	datum/čas odjezdu: datum/čas požadovaného odjezdu na trasu,

—	cíl trasy vlaku: cíl trasy vlaku pro požadovanou trasu,

—	datum/čas příjezdu do místa určení: datum/čas, kdy má navrhovaný vlak dorazit do místa svého určení,

—

změněný úsek jízdy: — nácestné stanice nebo jiná určená místa podél navrhované trasy spolu s datem/časem příjezdu do průjezdního místa a datem/časem odjezdu z průjezdního místa. Prázdná položka znamená, že vlak nebude v tomto místě zastavovat, — dostupné vybavení vlaku: typ trakce, řídicí a kontrolní systém včetně radiotelefonního zařízení ve vlaku, — hmotnost vlaku, — délka vlaku, — použitý brzdný systém a brzdný výkon, — maximální rychlost vlaku, — maximální hmotnost na nápravu vlaku, — maximální hmotnost na metr délky, — informace týkající se překročené ložné míry, — čísla UN/RID týkající se případných nebezpečných věcí, — definice činností, které mají být provedeny v nácestných stanicích po cestě, — odpovědný ŽP: identifikace ŽP odpovědného za vlak v daném úseku jízdy, — odpovědný PI: identifikace PI odpovědného za vlak v daném úseku jízdy, — další odpovědný PI: identifikace PI odpovědného za vlak v (případném) navazujícím úseku jízdy.

Pro doplnění informací pro žádost o trasu může ŽP nahlédnout do příslušné zprávy o síti, aby si ověřil, zda jsou údaje o chystaném vlaku v souladu s infrastrukturou. Je též zapotřebí přihlédnout k takovým údajům, jako jsou informace o nebezpečných věcech.

Držitelé vozů musejí poskytnout železničním podnikům přístup k technickým údajům o vozech.

ŽP si musejí samy zajistit přístup k referenčním souborům, např. referenčnímu souboru o nebezpečných věcech, je-li třeba.

4.2.2.3   Zpráva Údaje o trase

Tato zpráva je odpovědí PI na „Žádost o trasu“ od ŽP. Nemůže-li PI žádosti o trasu vyhovět, musí zaslat ŽP tuto zprávu se sdělením „Nejsou k dispozici žádné alternativy“. Jinak musí na žádost ŽP odpovědět zasláním čísla trasy společně se stejnými údaji, jaké byly uvedeny v žádosti o trasu; může však změnit hodnoty.

Navrhuje-li PI jinou alternativu, musí zaslat tyto údaje:

—	Nové číslo trasy,

—	Místo odjezdu: místo, kde začíná navrhovaná trasa,

—	Datum/čas odjezdu: datum/čas navrhovaného odjezdu na trasu,

—	Cíl trasy vlaku: Cíl trasy vlaku pro navrhovanou trasu,

—	Datum/čas příjezdu do místa určení: datum/čas, kdy má vlak dorazit do místa svého určení,

—

Upravený úsek jízdy: — nácestné stanice nebo jiná určená místa na navrhované trase spolu s datem/časem příjezdu do průjezdního místa a datem/časem odjezdu z průjezdního místa. Prázdná položka znamená, že vlak nebude v tomto místě zastavovat, — požadované vybavení vlaku: typ trakce, řídicí a kontrolní systém včetně radiotelefonního zařízení ve vlaku, — hmotnost vlaku, — délka vlaku, — použitý brzdný systém a brzdný výkon, — maximální rychlost vlaku, — maximální hmotnost na nápravu vlaku, — maximální hmotnost na metr délky, — informace týkající se překročené ložné míry, — čísla UN/RID týkající se případných nebezpečných věcí, — definice činností, které mají být provedeny v nácestných stanicích po cestě, — odpovědný ŽP: identifikace ŽP odpovědného za vlak v daném úseku jízdy, — odpovědný PI: identifikace PI odpovědného za vlak v daném úseku jízdy, — další odpovědný PI: identifikace PI odpovědného za vlak v (případném) navazujícím úseku jízdy.

4.2.2.4   Zpráva Trasa potvrzena

Touto zprávou potvrzuje ŽP provozovateli infrastruktury, že přijímá trasu navrženou provozovatelem infrastruktury v reakci na původní žádost ŽP. Touto zprávou je trasa zarezervována. Zpráva obsahuje zejména tyto náležitosti:

—	číslo trasy k identifikaci trasy,

—	místo odjezdu: místo odjezdu vlaku,

—	datum/čas odjezdu: datum/čas navrhovaného odjezdu na trasu,

—	cíl trasy vlaku: cíl trasy vlaku pro navrhovanou trasu,

—	datum/čas příjezdu do místa určení: datum/čas, kdy má navrhovaný vlak dorazit do místa svého určení,

—	sdělení, že ŽP navrhovanou trasu přijímá.

4.2.2.5   Zpráva Údaje o trase odmítnuty

Odmítá-li ŽP navrhovanou trasu tak, jak je uvedena ve zprávě „Údaje o trase“, kterou obdržel od PI, musí provozovateli infrastruktury zaslat tuto zprávu, kterou mu sděluje, že navrhovanou trasu tak, jak je uvedena ve zprávě „Údaje o trase“, nepřijímá. Zpráva obsahuje zejména:

—	číslo trasy k identifikaci trasy,

—	sdělení, že ŽP nepřijímá údaje o trase.

Jako doplňující informace může ŽP zaslat tyto údaje:

—	místo odjezdu: místo odjezdu vlaku,

—	datum/čas odjezdu: datum/čas požadovaného odjezdu na trasu,

—	cíl trasy vlaku: cíl trasy vlaku pro požadovanou trasu,

—	datum/čas příjezdu do místa určení: datum/čas, kdy má navrhovaný vlak dorazit do místa svého určení.

4.2.2.6   Zpráva Trasa zrušena

Touto zprávou sděluje ŽP provozovateli infrastruktury, že má zrušit dříve zarezervovanou trasu. Společně se sdělením o zrušení rezervace (odpovídá typu zprávy) musí zaslat číslo trasy pro účely její jednoznačné identifikace. Postup je vždy stejný, bez ohledu na to, zda byla trasa rezervována v rámci dlouhodobého plánování, nebo narychlo:

—	číslo trasy k identifikaci trasy,

—	číslo vlaku (je-li již známo),

—	sdělení, že ŽP ruší rezervaci trasy.

Jako doplňující informace může ŽP zaslat tyto údaje:

—	místo odjezdu: místo odjezdu vlaku,

—	datum/čas odjezdu: datum/čas požadovaného odjezdu na trasu,

—	cíl trasy vlaku: cíl trasy vlaku pro požadovanou trasu,

—	datum/čas příjezdu do místa určení: datum/čas, kdy má navrhovaný vlak dorazit do místa svého určení.

4.2.2.7   Zpráva Trasa není k dispozici

Jakmile se PI dozví, že vlaková trasa není k dispozici, musí tuto skutečnost okamžitě oznámit ŽP. Zprávu Trasa není k dispozici může zaslat kdykoli mezi okamžikem nasmlouvání trasy vlaku a odjezdem vlaku. Příčinou zaslání této zprávy může být kupříkladu přerušení na trase. Tato zpráva obsahuje zejména tyto náležitosti:

—	číslo trasy, která není dostupná,

—	číslo vlaku pro zrušenou trasu (je-li již PI známo),

—	místo odjezdu s datem a časem, na něž byla trasa rezervována,

—	cíl trasy vlaku s datem a časem, kdy měl vlak dorazit do místa svého určení,

—	sdělení, že trasa není k dispozici,

—	uvedení příčiny.

Společně s touto zprávou nebo co možná nejdříve musí PI železničnímu podniku zaslat, aniž by o to ŽP musel žádat, alternativní návrh. Učiní tak prostřednictvím související zprávy „Údaje o trase“ vztažené ke zprávě „Trasa není k dispozici“.

4.2.2.8   Zpráva Potvrzení o přijetí zprávy

Tuto zprávu musí zaslat příjemce zprávy jejímu odesílateli, nemůže-li vydat požadovanou odpověď v termínu stanoveném v kapitole 4.4 (Provozní předpisy). V této zprávě musí být uvedeno referenční číslo zprávy, s níž tato zpráva souvisí (údaje v související zprávě viz kapitola 4.2: Funkční a technické specifikace subsystému, Obecné poznámky o struktuře zpráv), plus sdělení (aplikační úroveň):

—	potvrzení o přijetí zprávy: značí, že příjemce zprávu obdržel a zachová se, jak je třeba.

4.2.3   Příprava vlaku

4.2.3.1   Obecné poznámky

Tato kapitola stanoví zprávy, které se vyměňují během fáze přípravy vlaku až do jeho vypravení. Zprávy jsou shrnuty v tabulce 5 níže.

Aby ŽP mohl připravit vlak, musí mít přístup k informacím o omezeních na infrastruktuře, k technickým údajům o vozech (referenční databáze kolejových vozidel, kapitola 4.2.11.3: Referenční databáze kolejových vozidel), k referenčnímu souboru o nebezpečných věcech a k aktuálním informacím o stavu vozů (kapitola 4.2.12.2: Jiné databáze: Provozní databáze vozů a intermodálních jednotek). To platí o všech vozech ve vlaku. Na závěr musí ŽP zaslat informace o řazení vlaku dalším na něj navazujícím ŽP. Tuto zprávu musí ŽP zaslat také provozovateli (provozovatelům) infrastruktury, u něhož (nichž) si rezervoval část trasy, vyžaduje-li to TSI pro subsystém „Provoz a řízení dopravy“ konvenčního železničního systému nebo smlouva (smlouvy) mezi ŽP a PI.

Změní-li se v nějakém místě jízdy řazení vlaku, musí odpovědný ŽP znovu rozeslat tuto zprávu s aktualizovanými informacemi.

V každém místě, např. v místě odjezdu a ve výměnném místě, kde se mění odpovědnost na straně ŽP, je třeba zahájit dialog mezi PI a ŽP „Vlak připraven – Informace o jízdě vlaku“.

Při tomto dialogu spojeném se zahájením jízdy vlaku se používají tyto zprávy:

Tabulka 5

Příprava vlaku

Zpráva		Vysvětlení
Řazení vlaku		Tuto zprávu zasílá ŽP povinně provozovateli infrastruktury podle výše uvedeného popisu.
	Obdržel-li PI zprávu o řazení vlaku zaslanou povinně železničním podnikem, může na ni PI zareagovat těmito zprávami:
	Vlak akceptován	PI železničnímu podniku: tato zpráva je dobrovolná, není-li mezi PI a ŽP dohodnuto jinak.	Příprava vlaku může být dokončena.
	Vlak nevyhovuje	PI železničnímu podniku: tuto zprávu může zaslat PI, shledá-li, že vlak nevyhovuje.	Možnosti ŽP:   upravit řazení vlaku nebo   zrušit trasu vlaku a vyžádat si novou trasu
Vlak připraven		ŽP provozovateli infrastruktury, tato zpráva je povinná
Poloha vlaku		PI železničnímu podniku, zpráva určuje, kdy a kde přesně se musí vlak v síti nacházet. Tato zpráva se může zasílat v závislosti na vnitrostátních předpisech.
Vlak vyjel		ŽP může tuto zprávu zaslat PI, aby dal najevo, že vlak zahájil svou jízdu, v reakci na zprávu Poloha vlaku. Tato zpráva se může zasílat v závislosti na vnitrostátních předpisech.
Informace o jízdě vlaku		PI železničnímu podniku, tato zpráva se zasílá povinně pro informaci, že vlak dorazil na infrastrukturu.

V kapitolách, které následují, jsou popsány hlavní body těchto zpráv. Podrobné formáty těchto zpráv jsou stanoveny v příloze A indexu 1. Logický sled těchto zpráv je vyznačen ve schématech v příloze A indexu 5 kapitola 3.

Poznámka: Během přípravy vlaku se může vyskytnout též zpráva Trasa není k dispozici, neboť tato zpráva může být zaslána kdykoli mezi okamžikem nasmlouvání trasy vlaku a odjezdem vlaku. Příslušný postup je popsán v kapitole 4.2.2 (Žádost o trasu).

4.2.3.2   Zpráva Řazení vlaku

Tuto zprávu povinně zasílá ŽP dalšímu na něj navazujícímu ŽP a oznamuje jí řazení vlaku. Tuto zprávu musí ŽP zaslat také provozovateli (provozovatelům) infrastruktury, vyžaduje-li to TSI pro subsystém „Provoz a řízení dopravy“ konvenčního železničního systému nebo smlouva mezi ŽP a PI. Dojde-li ke změně řazení vlaku, musí odpovědný ŽP zaslat tuto aktualizovanou zprávu všem zúčastněným stranám.

Informace, které musí být zaslané a přístupné:

—	číslo vlaku a číslo trasy pro identifikaci trasy,

—	místo odjezdu s datem a časem, na nějž je trasa požadována,

—	cíl trasy vlaku s datem a časem, kdy má navrhovaný vlak dorazit do místa svého určení,

—	identifikace lokomotiv(y) a pozice lokomotiv(y) ve vlaku,

—	délka vlaku, hmotnost vlaku, max. rychlost vlaku,

—	řazení vlaku s posloupností identifikačních čísel vozů,

—	řídicí a kontrolní systém včetně typu radiotelefonního zařízení,

—	informace o překročené ložné míře,

—	UN/RID čísla nebezpečných věcí,

—	informace o tom, zda budou vezena živá zvířata a lidé (kromě posádky vlaku),

—	použitý brzdný systém,

—	údaje o vozech.

Po obdržení zprávy o řazení vlaku může PI porovnat údaje ve zprávě s nasmlouvanou trasou, umožňuje-li to výslovně kontrakt mezi PI a ŽP. V takovém případě musí mít PI snadný přístup k informacím o případných omezeních na příslušné infrastruktuře, technickým údajům o vozech (kapitola 4.2.11.3:), k referenčnímu souboru o nebezpečných věcech a k aktuálním informacím o stavu vozů (kapitola 4.2.12.2: : Provozní databáze vozů a intermodálních jednotek). To platí o všech vozech ve vlaku. V takovém případě je to také PI, kdo spravuje své trasy vlaků a aktualizuje informace o stavu tras a kdo musí přidat údaje ze zprávy o řazení vlaku k údajům o trase a vlaku uvedeným v kapitole 4.2.2.1 (Žádost o trasu, Úvodní poznámky).

4.2.3.3   Zpráva Vlak akceptován

V závislosti na smluvních ujednáních mezi PI a ŽP a na zákonných požadavcích může PI také potvrdit ŽP vhodnost řazení vlaku pro rezervovanou trasu. To se provádí právě pomocí této zprávy.

Tato zpráva obsahuje zejména následující údaje:

—	číslo vlaku a číslo trasy,

—	místo odjezdu s datem a časem, na nějž je trasa požadována,

—	cíl trasy vlaku s datem a časem, kdy má navrhovaný vlak dorazit do místa svého určení,

—	sdělení, že PI schválil řazení vlaku jako vhodné po dohodnutou trasu.

4.2.3.4   Zpráva Vlak nevyhovuje

Není-li vlak vhodný pro dříve dohodnutou trasu, může o tom PI informovat ŽP pomocí této zprávy. V takovém případě si musí ŽP překontrolovat řazení vlaku. Tato zpráva obsahuje zejména tyto údaje:

—	číslo vlaku a číslo trasy,

—	místo odjezdu s datem a časem, na nějž je trasa požadována,

—	cíl trasy vlaku s datem a časem, kdy má navrhovaný vlak dorazit do místa svého určení,

—	sdělení Vlak nevyhovuje, které značí, že vlak nevyhovuje přidělené trase, a proto po ní nemůže jet,

—	uvedení příčiny.

4.2.3.5   Zpráva Vlak připraven

Tuto zprávu zasílá povinně ŽP provozovateli infrastruktury, aby mu oznámil, že vlak je připraven vyjet do železniční sítě. Zpráva obsahuje zejména tyto údaje:

—	číslo vlaku a číslo trasy,

—	místo odjezdu s datem a časem, na nějž je trasa požadována,

—	cíl trasy vlaku s datem a časem, kdy má navrhovaný vlak dorazit do místa svého určení,

—	sdělení Vlak je připraven, které značí, že vlak byl připraven a může vyjet,

—	volací znak kontaktní osoby řídicího střediska pro veškerou komunikaci mezi vlakem a okolím,

—

nevyžadují-li smluvní ujednání mezi ŽP a PI vyměnění zprávy „Poloha vlaku/Vlak vyjel“, musí být v této zprávě uveden údaj Datum/čas zahájení jízdy, který informuje PI o předpokládaném datu/času, kdy vlak vyjede do železniční sítě. Je-li povinná zpráva „Poloha vlaku/Vlak vyjel“, nesmí být tento datový prvek ve zprávě „Vlak připraven“ obsažen.

4.2.3.6   Zpráva Poloha vlaku

V této zprávě může PI sdělit ŽP, kdy a kde přesně by měl vlak vyjet do železniční sítě, v reakci na zprávu o připravenosti vlaku. To, zda se tato zpráva zasílá, závisí na smluvních ujednáních mezi ŽP a PI. Je-li zaslání této zprávy požadováno, obsahuje tato zpráva zejména tyto údaje:

—	číslo vlaku a číslo trasy,

—	místo odjezdu s datem a časem, na nějž je trasa požadována,

—	cíl trasy vlaku s datem a časem, kdy má navrhovaný vlak dorazit do místa svého určení,

—	identifikace koleje, která sděluje železničnímu podniku identifikační číslo koleje, přes kterou by měl vlak vjet na infrastrukturu,

—	datum/čas zahájení jízdy, které sdělují ŽP přesné datum a čas, kdy by měl vlak vyjet do železniční sítě,

—	identifikační údaje kontaktní osoby řídicího střediska.

4.2.3.7   Zpráva Vlak vyjel

Tuto zprávu může zaslat ŽP provozovateli infrastruktury poté, co obdržel od PI zprávu „Poloha vlaku“, aby mu sdělil, že vlak zahájil svou jízdu. Tato zpráva musí obsahovat identifikační údaje zprávy, s níž souvisí, a sdělení:

—	vlak vyjel: datum a čas, kdy vlak skutečně zahájil svou jízdu.

4.2.3.8   Informace o jízdě vlaku

Jakmile vlak vjede na infrastrukturu PI, což znamená, že opustil výchozí stanici, PI zasílá tuto zprávu ŽP, který u něj má rezervovanou danou trasu. Tato zpráva je popsána v kapitole 4.2.4 (Prognóza jízdy vlaku).

4.2.4   Prognóza jízdy vlaku

4.2.4.1   Obecné poznámky

Tato kapitola stanoví zprávy, které se vyměňují během normální jízdy vlaku bez jakéhokoli přerušení.

Jde o tyto zprávy:

prognóza jízdy vlaku,

informace o jízdě vlaku.

Tato výměna informací mezi železničními podniky a provozovateli infrastruktury probíhá vždy mezi odpovědným PI a ŽP, který má rezervovanou trasu, po níž vlak momentálně jede. V případě otevřeného přístupu, což znamená, že si trasy pro celou jízdu zarezervoval jeden ŽP (který současně provozuje vlak po celou dobu jízdy), jsou všechny zprávy zasílány tomuto ŽP. Totéž platí i tehdy, rezervoval-li si trasy pro celou jízdu jeden ŽP prostřednictvím OSS.

Nyní si na několika modelových situacích ukážeme různé komunikační vztahy mezi železničními podniky a provozovateli infrastruktury, které mohou nastat při jednotlivých možnostech rezervace zmíněných v kapitole 4.2.2.1 (Žádost o trasu, Úvodní poznámky, modelová situace A a B):

—	Vlak přijíždí do místa předávky mezi PI n1 a na něj navazujícím PI n2

Předpokládá se, že místo předávky mezi PI není zároveň výměnným místem, kde probíhá střídání mezi ŽP (pouze modelová situace B), ani místem, v němž dochází k manipulaci. Místo předávky je tedy místem na rezervovaných trasách jednoho ŽP a tento ŽP již zaslal řazení vlaku provozovateli infrastruktury n2 a současně zasílá tuto zprávu provozovateli infrastruktury n1.

PI n1 musí po odjezdu vlaku u výchozího bodu (5) zaslat prognózu jízdy vlaku provozovateli infrastruktury n2 spolu s předpokládanou dobou předávky (ETH). Tuto zprávu zasílá současně ŽP.

Když vlak v místě předávky opouští infrastrukturu PI n1, tento PI zašle Informaci o jízdě vlaku se skutečným časem předávky v tomto místě ŽP, který u něj má tuto trasu nasmlouvanou.

Když vlak v místě předávky vjede na infrastrukturu PI n2, tento PI zašle Informaci o jízdě vlaku se skutečným časem předávky v tomto místě ŽP, který u něj má tuto trasu nasmlouvanou.

—	Vlak přijíždí do výměnného místa, kde má proběhnout střídání mezi ŽP 1 a na něj navazujícím ŽP 2 (pouze modelová situace B)

Ve smlouvě o trase musí být vždy stanoveno, že výměnné místo je místem, kde musí proběhnout výměna informací („místo hlášení“). (PI generují doby TETA v místech hlášení, jak je stanoveno v jejich smlouvách s železničními podniky.)

Pro toto místo posílá odpovědný SI, jakmile vlak opustí předchozí místo hlášení, zprávu Prognóza jízdy vlaku s TETA pro následující výměnné místo železničnímu podniku, který u něj má tuto trasu nasmlouvanou (např. ŽP 1). ŽP 1 předá tuto zprávu na něj navazujícímu ŽP (např. ŽP 2), která má od něj vlak převzít. Kromě toho se tato zpráva zasílá případnému hlavnímu ŽP (HŽP), je-li to stanoveno ve smlouvě o spolupráci mezi oběma ŽP.

Je-li výměnné místo zároveň místem předávky mezi např. PI n1 a PI n2, PI n1 zasílá PI n2 prognózu jízdy vlaku již po odjezdu z výchozího místa nebo z předchozího výměnného místa spolu s předpokládanou dobou předávky (ETH). Tato zpráva se zasílá též ŽP, který má trasu nasmlouvanou, např. ŽP 1. Pro ŽP je ETH shodný s TETA ve výměnném místě. ŽP 1 předá tuto zprávu na něj navazujícímu ŽP 2 a případnému hlavnímu ŽP, je-li to stanoveno ve smlouvě o spolupráci mezi oběma ŽP.

Když vlak dorazí do výměnného místa, PI musí zaslat Informaci o jízdě vlaku spolu se skutečným časem příjezdu do této stanice ŽP, který u něj má danou trasu nasmlouvanou.

Než vlak opustí výměnné místo, musí ŽP 2 zaslat novou zprávu o řazení vlaku PI, který mu přidělil trasu, a dodržet postup pro odjezd stanovený v kapitole 4.2.3 (Příprava vlaku).

—	Vlak přijíždí do místa, kde s ním ŽP manipuluje (modelová situace A)

Ve smlouvě o trase musí být vždy stanoveno, že každé manipulační místo je místem hlášení.

Pro toto místo musí odpovědný SI poslat zprávu Prognóza jízdy vlaku s TETA pouze tehdy, je-li to stanoveno ve smlouvě mezi PI a ŽP.

Je-li však manipulační místo zároveň místem předávky, kupříkladu mezi PI n1 a PI n2, musí PI n1 po odjezdu z výchozí stanice nebo předchozího výměnného místa zaslat PI n2 zprávu Prognóza jízdy vlaku spolu s předpokládanou dobou předávky (ETH). Tato zpráva se zasílá též ŽP. Pro ŽP je ETH shodný s TETA v manipulačním místě.

Když vlak dorazí do manipulačního místa, PI musí zaslat Informaci o jízdě vlaku spolu se skutečným časem příjezdu do tohoto místa ŽP.

Než vlak opustí manipulační místo, musí ŽP a PI dodržet postup pro odjezd stanovený v kapitole 4.2.3 (Příprava vlaku).

—	Příjezd vlaku do místa určení

Když vlak dorazí do svého místa určení, odpovědný PI zašle zprávu Informace o jízdě vlaku spolu se skutečným časem příjezdu ŽP, který u něj má danou trasu nasmlouvanou.

Poznámka: Ve smlouvě o trase mohou být stanovena i jiná místa, v nichž jsou požadovány zprávy Prognóza jízdy vlaku s TETA a Informace o jízdě vlaku se skutečným časem. Odpovědný PI zašle zprávy o těchto místech tak, jak je uvedeno ve smlouvě. Další vyhodnocování a zpracování předaných časů ETH a TETA je popsáno v kapitolách 4.2.7 (ETI / ETA zásilky) až 4.2.9 (výměny).

V kapitolách, které následují, jsou popsány hlavní body zpráv „Prognóza jízdy vlaku“ a „Informace o jízdě vlaku“. Podrobné formáty těchto zpráv jsou stanoveny v příloze A indexu 1. Logický sled těchto zpráv v jednotlivých modelových situacích je vyznačen ve schématech v příloze A indexu 5 kapitola 4 s tím, že pokud jde o komunikační vztah mezi ŽP a provozovateli infrastruktury v souvislosti s jízdou vlaku, jsou obě modelové situace popisující varianty žádosti o trasu, tj. modelová situace A (případ A) a A (případ B) (kapitola 4.2.2.1: Žádost o trasu, Úvodní poznámky) totožné, protože v obou případech znají provozovatelé infrastruktury pouze jeden ŽP, např. ŽP1, který provozuje celou trasu a odpovídá též za řazení vlaků v manipulačních místech.

4.2.4.2   Zpráva Prognóza jízdy vlaku

Tuto zprávu je povinen zaslat PI pro místa předávky, výměnná místa a pro místa určení vlaku, jak je popsáno v kapitole 4.2.4.1 (,).

Kromě toho musí PI tuto zprávu zaslat ŽP pro všechna další místa hlášení stanovená ve smlouvách mezi ŽP a PI (např. manipulační místa).

Zpráva obsahuje zejména tyto údaje:

—	číslo trasy a číslo vlaku,

—	datum a čas odjezdu ze stanice PI podle jízdního řádu (nebo čas předání dalšímu PI podle jízdního řádu),

—	identifikace místa hlášení,

—	předpokládané datum/čas v místě hlášení.

4.2.4.3   Zpráva Informace o jízdě vlaku

Tato zpráva se povinně zasílá při:

—	odjezdu z výchozího místa, příjezdu do místa určení,

—

příjezdu a odjezdu do/z míst předávky, výměnných míst a dohodnutých míst hlášení dle smlouvy (např. manipulačních míst). Zpráva obsahuje zejména tyto údaje: — číslo trasy a číslo vlaku, — datum a čas odjezdu ze stanice PI podle jízdního řádu, — identifikace posledního místa hlášení, — skutečný čas v místě hlášení, — stav vlaku v místě hlášení (příjezd, odjezd, průjezd, neuveden, odjezd z výchozí stanice, příjezd do místa určení), — příjezdová kolej v místě, — odjezdová kolej v místě, — povolená časová odchylka od jízdního řádu v minutách, — aktuální časový plán, došlo-li k více změnám, — pro každou odchylku od jízdního řádu v daném místě hlášení: — kódové(á) označení příčin(y), — odchylka pro tuto příčinu (za každé místo hlášení lze uvést více příčin), — případný doplňující text týkající se odchylky.

4.2.5   Informace v případě narušení provozu

4.2.5.1   Obecné poznámky

Když se ŽP dozví o narušení provozu v průběhu jízdy vlaku, za který zodpovídá, musí tuto skutečnost okamžitě sdělit příslušnému PI (zpráva se nepředává elektronickou cestou, ale předává ji např. ústně strojvůdce). Je-li to nutné, ŽP provede aktualizaci provozní databáze vozů a intermodálních jednotek. Je-li to nutné, PI provede aktualizaci údajů o infrastruktuře v databázi informací o omezeních na infrastruktuře a/nebo trase, resp. databázi vlaků.

Překročí-li zpoždění x minut (tato hodnota musí být stanovena ve smlouvě mezi ŽP a PI), musí PI zaslat ŽP zprávu Prognóza jízdy vlaku pro příští místo hlášení.

Je-li vlak zrušen, zašle PI zprávu Jízda vlaku přerušena specifikovanou níže.

Ve výjimečných případech, kdy ŽP nebo PI nejsou schopni dopravit vlak v předpokládaném čase, musí být dojednána nová trasa podle kapitoly 4.2.2 (Žádost o trasu).

4.2.5.2   Zpráva Jízda vlaku přerušena

Je-li vlak zrušen, PI zasílá tuto zprávu na něj navazujícímu PI a ŽP, který si u něj nasmlouval trasu.

Zpráva obsahuje zejména tyto údaje:

—	číslo trasy a číslo vlaku,

—	identifikace místa,

—	datum a čas odjezdu z tohoto místa podle jízdního řádu,

—	důvod přerušení,

—	popis omezení.

4.2.6   Umístění vlaku

4.2.6.1   Úvod

Tato kapitola popisuje možnosti, jak získat informace pro vystopování umístění vlaku. ŽP se může kdykoli obrátit na PI s dotazem ohledně svých vlaků. ŽP se může tázat na:

—	jízdu vlaku (poslední zaznamenané místo, zpoždění, důvody zpoždění),

—	průběh jízdy vlaku (zpoždění, důvody zpoždění, místa vzniku zpoždění),

—	všechny identifikační údaje konkrétního vlaku,

—	prognózu vlaku v konkrétním místě,

—	všechny prognózy jízdy vlaků pro konkrétní místo.

Přístup k těmto informacím musí být nezávislý na komunikaci mezi ŽP a PI během jízdy vlaku, což znamená, že ŽP musí mít samostatný (6) přístup k těmto informacím. Tyto informace vycházejí zejména z již popsané zaevidované výměny zpráv.

4.2.6.2   Dotazy ohledně jedoucího vlaku

Účel	:	ŽP se může informovat o posledním zaznamenaném stavu (místě, zpožděních a důvodech zpoždění) konkrétního vlaku na infrastruktuře konkrétního PI.
Dotaz	:	Hlavní datové prvky: — provozní číslo vlaku, — identifikátor PI, — datum a čas odjezdu ze stanice PI podle jízdního řádu.
Odpověď	:	Informační údaje: — poslední místo hlášení, — skutečný čas v místě hlášení, — stav vlaku v místě hlášení (příjezd, odjezd, průjezd, neuveden, odjezd z výchozí stanice, příjezd do místa určení), — příjezdová kolej v místě, — odjezdová kolej v místě, — stanovený čas podle jízdního řádu, — povolená časová odchylka od jízdního řádu, — změněný čas (oproti aktuálnímu časovému plánu, došlo-li k více změnám), — pro každou odchylku od jízdního řádu v daném místě hlášení: — kódové označení příčiny a délka zpoždění způsobeného touto příčinou.

4.2.6.3   Dotazy ohledně zpoždění/průběhu jízdy vlaku

Účel	:	ŽP se může informovat o všech zpožděních konkrétního vlaku u konkrétního PI.
Dotaz	:	Hlavní datové prvky: — provozní číslo vlaku, — identifikátor PI, — datum a čas odjezdu ze stanice PI podle jízdního řádu.
Odpověď	:	Informační údaje (stejné informace jako u dotazů ohledně jízdy vlaku, nejen v posledním místě, ale v každém místě hlášení vlaku na infrastruktuře daného PI): — pro každé místo hlášení: — poslední místo hlášení, — skutečný čas v místě hlášení, — stav vlaku v místě hlášení (příjezd, odjezd, průjezd, neuveden, odjezd z výchozí stanice, příjezd do místa určení), — příjezdová kolej v místě, — odjezdová kolej v místě, — stanovený čas podle jízdního řádu, — povolená časová odchylka od jízdního řádu, — změněný čas (oproti aktuálnímu časovému plánu, došlo-li k více změnám), — pro každou odchylku od jízdního řádu v daném místě hlášení: — kódové označení příčiny a délka zpoždění způsobeného touto příčinou.

4.2.6.4   Dotazy ohledně identifikace vlaku

Účel	:	ŽP se může informovat o aktuálních a dřívějších identifikačních údajích vlaku. Pro dotaz lze použít jakýkoli z identifikátorů vlaku.
Dotaz	:	Hlavní datové prvky: — známé provozní číslo vlaku, — identifikátor PI, — datum a čas odjezdu ze stanice PI podle jízdního řádu.
Odpověď	:	Informační údaje: — aktuální identifikátor vlaku: — provozní číslo vlaku, — datum a čas odjezdu ze stanice PI podle jízdního řádu, — pro každý jiný identifikátor vlaku: — provozní číslo vlaku, — datum a čas odjezdu ze stanice PI podle jízdního řádu.

4.2.6.5   Dotazy na PI ohledně prognózy vlaku

Účel	:	ŽP se může informovat o předpokládaném času průjezdu konkrétního vlaku konkrétním místem hlášení nebo, neuvede-li místo hlášení, o předpokládaném času předávky od PI.
Dotaz	:	Hlavní datové prvky: — provozní číslo vlaku, — datum a čas odjezdu ze stanice PI podle jízdního řádu, — identifikátor místa hlášení (Místo hlášení, pro něž je požadována prognóza. Identifikátor je volitelný; není-li uveden, týká se odpověď posledního místa hlášení daného PI pro daný vlak.).
Odpověd'	:	Informační údaje: — kód PI, — identifikace místa hlášení, — předpokládané datum a čas v místě hlášení.

4.2.6.6   Dotazy na PI ohledně vlaků v místě hlášení

Účel	:	ŽP se může informovat o všech svých vlacích v konkrétním místě hlášení na infrastruktuře konkrétního PI.
Dotaz	:	Hlavní datové prvky: — kód PI, — identifikace místa hlášení (Místo hlášení, pro něž je požadována prognóza. Identifikátor je volitelný; není-li uveden, týká se odpověď posledního místa hlášení daného PI pro daný vlak.).
Odpověd'	:	Informační údaje: — pro každý vlak tazatele: — provozní číslo vlaku, — datum a čas odjezdu ze stanice PI podle jízdního řádu nebo datum předávky podle jízdního řádu, — kód PI, — identifikace místa hlášení, — předpokládané datum a čas v místě hlášení.

4. 2.7   ETI/ETA zásilky

4.2.7.1   Úvodní poznámka

Kapitoly 4.2.2 (Žádost o trasu) až 4.2.6 (Umístění vlaku) popisovaly především komunikaci mezi ŽP a PI. Vzhledem k tomu, že úkolem PI je monitorovat a kontrolovat provoz vlaků, je klíčovým prvkem této komunikace číslo vlaku. Část zprávy o řazení vlaku, která obsahuje informace o vozech, je důležitá pro ověření souladu řazení vlaku se smlouvou mezi PI a ŽP a také ve všech mimořádných případech.

Tato výměna informací nezahrnuje individuální sledování vozů nebo intermodálních jednotek. Toto sledování je prováděno ŽP/HŽP na základě zpráv týkajících se vlaku a je popsáno v kapitolách 4.2.7 (ETI / ETA zásilky) až 4.2.9 (Vykazování výměny).

Výměnu a aktualizaci informací týkajících se vozů nebo intermodálních jednotek usnadňuje uchovávání „plánů přepravy“ a „jízd vozů“ (kapitola 4.2.12.2: Jiné databáze).

Jak již bylo řečeno v kapitole 2.3.2 (Uvažované procesy), pro zákazníka je nejdůležitější informací vždy předpokládaná doba příjezdu (ETA) jeho zásilky. ETA vozu a též ETI jsou rovněž základními údaji při komunikaci mezi HŽP a ŽP. Tyto údaje jsou hlavním nástrojem, jehož prostřednictvím může HŽP sledovat fyzickou přepravu zásilky a kontrolovat splnění závazku vůči zákazníkovi.

Předpokládané časy ve zprávách o vlacích se všechny vztahují k příjezdu vlaku do určitého místa, ať už jde o místo předávky, výměnné místo, cíl trasy vlaku nebo jiné místo hlášení. Jsou to všechno předpokládané doby příjezdu vlaku (TETA). Pro jednotlivé vozy nebo intermodální jednotky ve vlaku mohou mít tyto TETA rozdílné významy. Kupříkladu TETA pro výměnné místo může být předpokládanou dobou střídání (ETI) pro některé vozy nebo intermodální jednotky. Pro ostatní vozy, které zůstávají ve vlaku k další přepravě stejným ŽP, nemusí mít tato TETA žádný význam. Je proto úkolem ŽP, který TETA obdrží, aby tuto informaci identifikoval a zpracoval, uložil ji jako pohybový údaj do provozní databáze vozů a intermodálních jednotek a sdělil ji HŽP, není-li vlak provozován v režimu otevřeného přístupu. S tím také počítáme v kapitolách, které následují.

4.2.7.2   Výpočet ETI/ETA

Výpočet ETI/ETA vychází z informací od příslušného PI, který zasílá ve zprávě Prognóza jízdy vlaku předpokládanou dobu příjezdu vlaku (TETA) pro stanovená místa hlášení (v každém případě pro místa předávky, výměnná místa nebo místa určení včetně intermodálních terminálů) na dohodnuté trase vlaku, např. pro místo předání jedním PI jinému (v tomto případě je TETA totožná s ETH).

ŽP musí pro výměnná místa nebo jiná stanovená místa hlášení na dohodnuté trase vlaku vypočítat příštímu ŽP v dopravním řetězci předpokládanou dobu střídání (ETI) pro vozy a/nebo intermodální jednotky.

Protože ŽP může mít ve vlaku vozy s různými místy určení a od různých HŽP, mohou se výměnná místa pro výpočet ETI pro jednotlivé vozy lišit. To je vysvětleno ve dvou zjednodušených příkladech, které následují (schematické znázornění těchto příkladů najdete v příloze A indexu 5 kapitola 1.4 a schéma logické posloupnosti založené na příkladu 1 pro výměnné místo C je uvedeno v příloze A indexu 5 kapitola 5).

Příklad 1	:	ŽP1 má v jednom vlaku vozy č. 1 a 2 od HŽP1 a vozy č. 3 až 5 od HŽP2. Ve výměnném místě C přebírá vozy 1 a 2 k další přepravě ŽP2 a vozy 3 až 5 ŽP3. V tomto případě musí ŽP1 vypočítat pro výměnné místo C čas ETI pro vozy 1 a 2 a musí je zaslat HŽP1. ŽP1 musí také pro stejné výměnné místo C vypočítat ETI pro vozy 3 až 5 a zaslat je HŽP2.
Příklad 2	:	ŽP1 má v jednom vlaku vozy č. 1 a 2 od HŽP1 a vozy č. 3 až 5 od HŽP2. Ve výměnném místě C přebírá vozy 3 až 5 k další přepravě ŽP3, zatímco vozy 1 a 2 zůstávají ve vlaku ŽP1 až do výměnného místa E, kde odpovědnost za tyto vozy přechází na ŽP2. V tomto případě musí ŽP1 vypočítat pro výměnné místo C pouze ETI pro vozy 3 až 5 a musí tyto hodnoty zaslat HŽP2. Pro vozy 1 a 2 není výměnné místo C důležité. Dalším výměnným místem relevantní pro tyto vozy je stanice E, pro kterou musí ŽP1 vypočítat ETI a zaslat je HŽP1.

Navazující ŽP vyjde z ETI, které obdrží od předchozího ŽP, a na jejich základě vypočte pro jednotlivé vozy dobu ETI pro další výměnné místo. Tyto kroky provádí každý další ŽP. Když poslední ŽP (např. ŽP n) v dopravním řetězci vozu obdrží ETI od předešlého ŽP (ŽP n-1) pro střídání vozu mezi ŽP n-1 a ŽP n, musí poslední ŽP (ŽP n) vypočítat předpokládanou dobu příjezdu vozu do konečného místa určení. Musí při tom zajistit přistavení vozů podle vozového příkazu a příslibu daného HŽP jeho zákazníkovi. Tento čas představuje ETA pro vůz a musí být zaslán HŽP. ETA musí být uložen v elektronické podobě spolu s pohybovými údaji o vozu. HŽP musí umožnit zákazníkovi přístup k údajům, které jsou pro něj důležité, v souladu s podmínkami smlouvy.

Poznámka k intermodálním jednotkám: Pro intermodální jednotky na voze představují ETI vozu zároveň ETI pro intermodální jednotky. Pokud jde o ETA pro intermodální jednotky, je třeba říci, že ŽP není schopen vypočítat ETA po ukončení části přepravy realizované po železnici. Proto může ŽP poskytnout pouze ETI týkající se intermodálního terminálu.

Hlavní ŽP provádí porovnání ETA se smluvním závazkem vůči zákazníkovi.

Odchylky ETA od smluvního závazku vůči zákazníkovi se musí řešit v souladu se smlouvou a mohou být důvodem pro to, aby HŽP použil výstražný řídící postup. Výsledky tohoto postupu předává ve formě varovné zprávy, jak je popsáno níže.

Aby HŽP mohl použít výstražný řídící postup, musí mít možnost informovat se o odchylkách. Tento dotaz HŽP a odpověď ŽP jsou také popsány v dalším textu.

4.2.7.3   Zpráva ETI/ETA vozu

Účel	:	Jeden ŽP zašle ETI nebo aktualizovanou ETI druhému ŽP, který na něj navazuje v dopravním řetězci. Poslední ŽP v dopravním řetězci vozů zasílá ETA nebo aktualizovanou ETA HŽP.
Hlavní datové prvky	:	— identifikace ŽP, který poskytl ETI nebo ETA, — výchozí nebo předchozí výměnná stanice (ETI nebo čas odjezdu z výchozí stanice), — číslo vlaku za výchozí nebo předchozí výměnnou stanicí (od ETI nebo okamžiku odjezdu z výchozí stanice), — skutečné datum a čas odjezdu vlaku, — konečná nebo příští výměnná stanice (ETI/konečná ETA), — číslo vlaku přijíždějícího do konečné stanice, pro niž je stanoven ETI/ETA (konečná nebo příští výměnná stanice), — datum a čas příjezdu vozu (ETI nebo ETA).

4.2.7.4   Varovná zpráva

Účel	:	Po porovnání ETA se závazkem vůči zákazníkovi může HŽP zaslat zúčastněným ŽP varovnou zprávu.
Hlavní datové prvky	:	— číslo vozu, — závazek vůči zákazníkovi: datum a hodina příjezdu, — aktuální ETA: datum a čas.

Poznámka: V případě otevřeného přístupu představuje výpočet ETI a ETA interní vnitropodnikový proces ŽP. V tomto případě je ŽP totožný s HŽP.

4.2.7.5   Dotazy na odchylky vozů

Účel	:	HŽP se může informovat o odchylkách ohledně konkrétního vozu.
Dotaz	:	Hlavní datové prvky: — číslo vozu, — identifikace HŽP.
Odpověď	:	Informační údaje: — pro každé místo hlášení — místo hlášení, — stav vozu v místě hlášení (odjezd, příjezd na seřaďovací nádraží, odjezd z seřaďovacího nádraží, příjezd do výměnného místa, příjezd na konečné seřaďovací nádraží), — odpovědný ŽP v místě hlášení a podle stavu vozu v místě hlášení, — změněný čas (oproti aktuálnímu časovému plánu, došlo-li k více změnám), — ETI, je-li místo hlášení výměnným místem, — skutečný čas v místě hlášení, — pro každou odchylku v daném místě hlášení: — kódové označení příčiny a délka zpoždění způsobeného touto příčinou.

4.2.8   Pohyb vozu

4.2.8.1   Předběžné poznámky

Aby bylo možno podávat zprávy o pohybu vozů, je zapotřebí uchovávat a zpřístupňovat v elektronické podobě níže uvedené údaje. Tyto údaje musejí být také obsaženy ve zprávách poskytovaných na základě smlouvy oprávněným stranám. Podrobné formáty jsou stanoveny v příloze A indexu 1.

—	Oznámení o připravenosti vozu k odsunu

—	Oznámení o odjezdu vozu

—	Zpráva o příjezdu vozu do seřaďovacího nádraží

—	Zpráva o odjezdu vozu ze seřaďovacího nádraží

—	Zpráva o výjimkách týkajících se vozů

—	Oznámení o příjezdu vozu

—	Oznámení přistavení vozu příjemci

—	Potvrzení přistavení vozu příjemci

—	Zprávy o střídání vozů budou popsány samostatně v kapitole 4.2.9: Vykazování

4.2.8.2   Oznámení o připravenosti vozu k odsunu

Účel	:	HŽP železničnímu podniku: Hlavní ŽP nemusí být nutně prvním ŽP v dopravním řetězci. V takovém případě musí HŽP sdělit odpovědnému železničnímu podniku, že vůz bude připraven k odtažení na vlečce zákazníka (místo odjezdu, k němuž se zavázal HŽP) v uvedeném čase připravení vozů k odsunu (datum a čas odjezdu). Informace o těchto událostech musejí být uchovávány v provozní databázi vozů a intermodálních jednotek.
Hlavní datové prvky	:	— číslo vozu, — místo, datum a čas odjezdu (místo, z něhož má být zahájena přeprava). ŽP a HŽP musejí mít snadný přístup k těmto údajům uloženým v databázích: — přepravní jednotka, identifikace, velikost a typ, — využitá kapacita jednotky, — celková hmotnost (rezervovaná/skutečná celková hmotnost zboží, včetně obalů a vybavení dopravce), — údaje o nebezpečných věcech.

4.2.8.3   Oznámení o odjezdu vozu

Účel	:	ŽP hlavnímu železničnímu podniku: ŽP musí sdělit HŽP skutečné datum a čas, kdy byl vůz odtažen z místa odjezdu. Informace o těchto událostech musejí být uchovávány v provozní databázi vozů a intermodálních jednotek. Po vyměnění této zprávy přechází odpovědnost za vůz ze zákazníka na ŽP.
Hlavní datové prvky	:	— číslo vozu, — místo, datum a čas odjezdu (místo, z něhož má být zahájena přeprava). ŽP a HŽP musejí mít snadný přístup k těmto údajům uloženým v databázích: — přepravní jednotka, identifikace, velikost a typ, — využitá kapacita jednotky, — celková hmotnost (rezervovaná/skutečná celková hmotnost zboží, včetně obalů a vybavení dopravce), — údaje o nebezpečných věcech.

4.2.8.4   Zpráva o příjezdu vozu do seřaďovacího nádraží

Účel	:	ŽP musí sdělit hlavnímu ŽP, že vůz dorazil na jeho seřaďovací nádraží. Tato zpráva může vycházet ze zprávy „Informace o jízdě vlaku“ z kapitoly 4.2.4 (Prognóza jízdy vlaku). Informace o této události musejí být uloženy v provozní databázi vozů a intermodálních jednotek.
Hlavní datové prvky	:	— číslo vozu, — identifikace příjezdového seřaďovacího nádraží, — datum a čas příjezdu na seřaďovací nádraží.

4.2.8.5   Zpráva o odjezdu vozu ze seřaďovacího nádraží

Účel	:	ŽP musí sdělit hlavnímu ŽP, že vůz opustil jeho seřaďovací nádraží. Tato zpráva může vycházet ze zprávy „Informace o jízdě vlaku“ z kapitoly 4.2.4 (Prognóza jízdy vlaku). Informace o této události musejí být uloženy v provozní databázi vozů a intermodálních jednotek.
Hlavní datové prvky	:	— číslo vozu, — identifikace výchozího seřaďovací nádraží, — datum a čas odjezdu ze seřaďovacího nádraží.

4.2.8.6   Zpráva o vozové mimořádnosti

Účel	:	ŽP musí informovat HŽP, stane-li se s vozem něco mimořádného, co by mohlo mít vliv na ETI/ETA nebo co vyžaduje nějaké další kroky. Tato zpráva vyžaduje ve většině případů také vypočtení nové ETI/ETA. Rozhodne-li HŽP, že je třeba stanovit novou ETI/ETA, zašle železničnímu podniku zpět zprávu se sdělením „Požadována ETI/ETA“ (Zpráva: Žádost o novou ETI / ETA na základě zprávy ). Nový výpočet ETI/ETA musí proběhnout podle postupu popsaného v kapitole 4.2.7 (ETI / ETA zásilky). Tyto informace musejí být uloženy v provozní databázi vozů a intermodálních jednotek.
Hlavní datové prvky	:	— číslo vozu, — místo, datum a čas narušení (místo, kde během dopravy došlo k něčemu neočekávanému), — důvod narušení a jeho kódové označení. Kromě toho musejí být v databázích snadno přístupné tyto údaje: — identifikace přepravní jednotky, — údaje o nebezpečných věcech.

4.2.8.7   Žádost o novou ETI/ETA na základě zprávy o vozové mimořádnosti

Účel	:	HŽP může zaslat tuto zprávu aktuálnímu ŽP, který mu zaslal „Zprávu o mimořádnosti“, aby si vyžádal novou ETI/ETA. HŽP zasílá tuto zprávu všem dalším ŽP, aby je informoval o odchylkách. Rozhodnutí, zda je zapotřebí stanovit novou ETI/ETA, záleží na HŽP, a stanovení nové ETI/ETA není nutné vždy.
Hlavní datové prvky	:	— číslo vozu, — místo, datum a čas narušení (místo, kde během dopravy došlo k něčemu neočekávanému), — důvod narušení a jeho kódové označení, — žádost o novou ETI/ETA. Kromě toho musejí být v databázích snadno přístupné tyto údaje: — identifikace přepravní jednotky, — údaje o nebezpečných věcech.

4.2.8.8   Oznámení o příjezdu vozu do stanice určení

Účel	:	Poslední ŽP v řetězci přepravy vozu nebo intermodální jednotky musí sdělit HŽP, že vůz dorazil na jeho seřaďovací nádraží (stanice ŽP).
Hlavní datové prvky	:	— číslo vozu, — identifikace seřaďovacího nádraží ŽP, — datum a čas příjezdu.

4.2.8.9   Oznámení o přistavení vozu příjemci

Účel	:	Poslední ŽP v řetězci přepravy vozu musí sdělit HŽP, že vůz byl umístěn na vedlejší kolej příjemce.
Hlavní datové prvky	:	— číslo vozu, — identifikace vedlejší koleje příjemce, na niž byl vůz umístěn (místo, zóna, kolej, segment), — datum a čas umístění.

Oznámení o přistavení vozu příjemci může být podruhé zasláno jako „Potvrzení o přistavení vozu příjemci“ spolu s dalším údajem:

—	identifikace zákazníka.

Poznámka: V případě otevřeného přístupu představuje popsaný pohyb vozu interní vnitropodnikový proces ŽP (HŽP). Přesto však musí být provedeny všechny výpočty a uloženy všechny údaje tak, jak to požaduje smlouva HŽP se zákazníkem.

Schéma logické posloupnosti těchto zpráv založené na příkladu 1 pro výpočet pro vozy 1 a 2 (viz kapitola 4.2.7.2 Výpočet ETI / ETA) je součástí schématu pro vykazování střídání v příloze A indexu 5 kapitola 6.

4.2.9   Vykazování výměny

4.2.9.1   Úvodní poznámka

Tato kapitola popisuje zprávy související s přechodem odpovědnosti za vůz mezi dvěma ŽP, ke kterému dochází ve výměnných místech. Zároveň ukládá novému ŽP povinnost provést výpočet ETI a dodržet postup popsaný v kapitole 4.2.7 (ETI / ETA zásilky).

Při výměně dochází k výměně těchto zpráv:

—	oznámení o předání vozu ve výměnném místě,

—	oznámení o převzetí vozu ve výměnné stanici,

—	vůz ve výměnném místě přijat,

—	vůz ve výměnném místě odmítnut.

Informační údaje z těchto zpráv musejí být uchovávány v provozní databázi vozů a intermodálních jednotek. V případě jakékoli odchylky musí být vypočtena nová ETI/ETA podle postupu popsaného v kapitole 4.2.7: ETI / ETA zásilky. Schéma logické posloupnosti těchto zpráv je obsaženo spolu se zprávami o pohybu vozů v příloze A indexu 5 kapitola 6.

Oznámení o předání vozu ve výměnné stanici, oznámení o převzetí vozu ve výměnné stanici a též zprávy o přijetí vozu lze předávat ve formě přehledu za více vozů, zejména tehdy, jsou-li všechny tyto vozy součástí jednoho vlaku. V takovém případě mohou být všechny vozy uvedeny v jediné zprávě.

V případě otevřeného přístupu neexistují žádná výměnná místa. Ani v manipulačním místě se odpovědnost za vozy nemění. Proto nejsou zapotřebí žádné zvláštní zprávy. Na základě údajů získaných ze zprávy Informace o jízdě vlaku v místech hlášení však musejí být údaje týkající se vozů a intermodálních jednotek – poloha a datum/čas příjezdu a odjezdu – zpracovány a uloženy v provozní databázi vozů a intermodálních jednotek.

Obsah těchto zpráv je takovýto:

4.2.9.2   Oznámení o předání vozu ve výměnné stanici

Účel	:	Pomocí zprávy „Oznámení o předání vozu ve výměnné stanici“ se táže železniční podnik (ŽP 1) dalšího ŽP v dopravním řetězci (ŽP 2), zda přebírá odpovědnost za vůz. Pomocí „Oznámení o převzetí vozu ve výměnné stanici“ ŽP 2 informuje svého PI, že odpovědnost převzal.
Hlavní datové prvky	:	— číslo vozu, — číslo vlaku (pouze tehdy, je-li vůz zapojen ve vlaku), — místo, datum a čas výměny. Kromě toho musejí být v databázích snadno přístupné tyto údaje: — identifikace přepravní jednotky (číslo, velikost a typ), — celková hmotnost (rezervovaná/skutečná celková hmotnost zboží, včetně obalů a vybavení dopravce), — využitá kapacita jednotky, — údaje o nebezpečných věcech, identifikace.

4.2.9.3   Oznámení o převzetí vozu ve výměnné stanici

Účel	:	Pomocí „Oznámení o převzetí vozu ve výměnné stanici“ sděluje ŽP 2 provozovateli infrastruktury, že převzal odpovědnost za konkrétní vůz.
Hlavní datové prvky	:	— číslo vozu, — číslo vlaku (pouze tehdy, je-li vůz zapojen ve vlaku), — místo, datum a čas výměny. Kromě toho musejí být v databázích snadno přístupné tyto údaje: — údaje o nebezpečných věcech, identifikace.

4.2.9.4   Zpráva o převzetí vozu ve výměnné stanici

Účel	:	Pomocí zprávy „Zpráva o převzetí vozu ve výměnné stanici“ sděluje ŽP 2 železničnímu podniku 1, že přebírá odpovědnost za konkrétní vůz.
Hlavní datové prvky	:	— číslo vozu, — místo, datum a čas výměny.

4.2.9.5   Zpráva o odmítnutí vozu ve výměnné stanici

Účel	:	Pomocí zprávy „Zpráva o odmítnutí vozu ve výměnné stanici“ sděluje ŽP 2 železničnímu podniku 1, že není ochoten převzít odpovědnost za daný vůz.
Hlavní datové prvky	:	— číslo vozu, — místo, datum a čas výměny, — kódové označení příčiny odmítnutí, — další popis (volitelně).

4.2.10   Výměna údajů za účelem zlepšení kvality

Aby byl evropský železniční průmysl konkurenceschopný, musí svým zákazníkům poskytovat kvalitnější služby (viz též článek 2.7.1 přílohy III směrnice 2001/16/ES).

Ve fázi po skončení dopravy jsou nezbytným předpokladem zlepšování kvality služeb nejrůznější měření.

Vedle měření kvality služby poskytnuté zákazníkovi musejí HŽP, ŽP a PI měřit kvalitu jednotlivých částí služby, které dohromady tvoří celý produkt dodaný zákazníkovi.

Proces měření začíná tím, že si provozovatelé infrastruktury a železniční podniky (zejména jde-li o HŽP) zvolí jednotlivé parametry, trasu nebo místo a sledované období, v němž se budou skutečné výsledky poměřovat s předem stanovenými kritérii, která obvykle bývají stanovena ve smlouvě.

Výsledky procesu měření musejí jasně ukazovat míru splnění cílů vytyčených smluvními stranami.

Zprávy o měřeních musejí být dostatečně podrobné, aby umožňovaly analýzu místa vzniku a pravděpodobné příčiny poklesu kvality, např. zpoždění. Při opakovaných problémech s kvalitou je nutné provést analýzu hlavních příčin, aby smluvní strany mohly určit vhodné nápravné kroky.

PI a ŽP jsou povinni poskytnout údaje, podílet se – případně ve spolupráci se třetími stranami – na analýze hlavních příčin a podniknout případné dohodnuté nápravné kroky.

Proces měření se stále opakuje.

K měření kvality lze použít již popsané zprávy, které lze rozdělit do těchto šesti skupin:

1.   HŽP/zákazník: délka trvání přepravy, ETA, řešení odchylek

Ve smlouvách mezi železničními podniky zastávajícími úlohu integrátorů služeb (HŽP) a zákazníky mohou být (individuálně) stanoveny závazky, pokud jde o délku trvání přepravy, ETA a řešení odchylek. Pro tento typ měření kvality se používají zejména tyto zprávy:

oznámení o připravenosti vozu k odsunu,

oznámení o odjezdu,

oznámení o příjezdu vozu do stanice určení.

2.   HŽP/poskytovatelé služeb: doba trvání přepravy a manipulace, časy ETA, ETI, kódová označení příčin

V smlouvách mezi HŽP a ostatními poskytovateli dopravních služeb mohou být stanoveny závazky, pokud jde o dobu trvání přepravy (v hodinách) u jednotlivých poskytovatelů služeb, takto:

doba na uvolnění/odtažení na místo předávky,

od vyzvednutí k bráně,

od brány k naložení,

od přijetí ve výměnném místě po dodání ve výměnném místě

od přijetí ve výměnném místě po umístění/konstruktivní umístění,

od vyložení po dodání.

Pro tento typ měření kvality se používají zejména tyto zprávy

oznámení o připravenosti vozu k odsunu,

oznámení o odjezdu,

oznámení o příjezdu na seřaďovací nádraží

oznámení o odjezdu ze seřaďovacího nádraží

oznámení o příjezdu

oznámení o příjezdu vozu do výměnného místa,

vůz ve výměnném místě přijat,

vůz ve výměnném místě odmítnut.

3.   ŽP/PI: průběh jízdy vlaku, ETA (TETA) vlaku, ETH

Ve smlouvách mezi železničními podniky a provozovateli infrastruktury může být stanovena požadovaná míra přesnosti dodržení jízdního řádu v určených místech hlášení a též přesnost ETA a ETH vlaku. Pro tento typ měření kvality se používají zejména tyto zprávy:

prognóza jízdy vlaku

informace o jízdě vlaku,

dotaz/odpověď ohledně zpoždění/průběhu jízdy vlaku.

4.   ŽP/PI: dostupnost trasy/plánovaná trasa

Ve smlouvách mezi železničními podniky a provozovateli infrastruktury musí být jasně popsána dostupnost trasy vlaku, pokud jde o časové rozpětí ve stanovených místech. Tyto smlouvy rovněž obsahují specifikace vlaku, pokud jde o jeho maximální délku a hrubou hmotnost, ložnou míru apod. Touto stránkou věci se budeme zabývat v bodě 6 (PI/ŽP: Kvalita řazení vlaku).

V těchto smlouvách jsou též zahrnuty postupy a termíny pro potvrzení využití trasy a zrušení rezervované trasy a míra, do jaké lze trasu využít mimo stanovený časový rámec (dříve či později). Pro tento typ měření kvality se používají zejména tyto zprávy:

trasa zrušena,

trasa není k dispozici.

5.   ŽP/PI: dostupnost trasy narychlo

Když chce ŽP jet s vlakem mimo časová omezení stanovená pro naplánovanou trasu, musí zaslat příslušnému (příslušným) PI rychlou žádost o trasu (jak je stanoveno ve směrnici 2001/14/ES).

ŽP pravidelně porovnává žádosti o trasu s údaji obsaženými v odpovědích za účelem sestavení těchto statistických výkazů:

dodržení časové lhůty pro odpověď stanovené v rámcové dohodě,

počet tras dodaných v určitých termínech v požadované lhůtě,

počet zamítnutých žádostí o trasu.

Pro tento typ měření kvality se používají zejména tyto zprávy:

žádost o trasu,

údaje o trase,

údaje o trase odmítnuty,

trasa zrušena,

trasa není k dispozici.

6.   PI/ŽP: kvalita řazení vlaku

Zprávy o připravenosti vlaku a/nebo výkazy vozidel vlaku, které zasílá ŽP provozovateli (provozovatelům) infrastruktury nebo jiným ŽP, musejí vyhovovat specifikacím vlaku obsaženým v příslušné smlouvě. Pro kontrolu souladu se smlouvou, a tedy pro měření kvality řazení vlaku, se používají zejména tyto zprávy

řazení vlaku,

vlak nevyhovuje.

4.2.11   Hlavní referenční údaje

4.2.11.1   Úvod

Údaje o infrastruktuře (zprávy o síti a údaje uložené v databázi informací o omezeních na infrastruktuře) a údaje o kolejových vozidlech (v referenčních databázích kolejových vozidel a v provozní databázi vozů a intermodálních jednotek) jsou nejdůležitějšími údaji pro provoz nákladních vlaků na evropské síti. Oba tyto typy údajů společně umožňují posoudit kompatibilitu kolejových vozidel s infrastrukturou, pomáhají bránit několikanásobnému zadávání dat, což přispívá ke zvýšení kvality dat v systému, a poskytují jasný obrázek o dostupných instalacích a zařízeních, který je kdykoli k dispozici pro rychlé rozhodování v průběhu provozu.

4.2.11.2   Databáze informací o omezeních na infrastruktuře

Každý PI zodpovídá za vhodnost trasy na jeho infrastruktuře a ŽP si je povinen překontrolovat charakteristiky vlaku s hodnotami uvedenými v údajích o trase pro trasu, kterou má smluvně dojednanou.

Aniž jsou dotčeny podmínky pro využití trasy ve zprávách o síti nebo povinnosti v případě jakýchkoli omezení na infrastruktuře vysvětlené v TSI pro subsystém „Provoz a řízení dopravy“, ŽP musí vědět před zahájením přípravy vlaku, zda jsou na úsecích trati nebo ve stanicích (uzlech) nějaká omezení mající vliv na řazení jeho vlaku uvedené ve smlouvě o trase.

Pro tyto účely musejí PI zřídit a vést aktuální databáze informací o omezeních na infrastruktuře. Struktura těchto databází je popsána v příloze A indexu 2. Položky těchto databází vycházejí z úseků tratí s příslušnými zprávami o síti, s přidáním informací o omezeních. Tyto databáze musejí být přístupné přes společné rozhraní (4.2.14.1: Obecná architektura a 4.2.14.7: Společné rozhraní).

ŽP je povinen zohlednit všechna omezení v databázi informací o omezeních na infrastruktuře, která mají vliv na jízdu jeho vlaku a která se vyskytnou v databázi do období bezprostředně před odjezdem (pre-departure period). Není-li ve smlouvě mezi PI a ŽP stanoveno jinak, začíná období bezprostředně před odjezdem jednu hodinu před odjezdem dle jízdního řádu.

Nastanou-li během období bezprostředně před odjezdem nějaké důležité změny v databázi informací o omezeních na infrastruktuře, musí o nich PI informovat ŽP přímo.

4.2.11.3   Referenční databáze kolejových vozidel

Držitel kolejových vozidel odpovídá za uchovávání údajů o kolejových vozidlech v referenční databázi kolejových vozidel.

Informace, které musejí být obsaženy v jednotlivých referenčních databázích kolejových vozidel, jsou podrobně popsány v příloze A indexu 2. Databáze musejí obsahovat všechny údaje o:

—	identifikaci kolejových vozidel,

—	posouzení slučitelnosti s infrastrukturou,

—	posouzení charakteristik majících význam pro nakládku,

—	posouzení brzdných vlastností,

—

údržbě,

—	ekologických charakteristikách.

Referenční databáze kolejových vozidel musí umožňovat snadný přístup (jediný společný přístup poskytovaný přes společné rozhraní) k technickým údajům, aby se omezil objem dat přenášených při každé operaci. Obsah databází musí být přístupný na bázi diferencovaných přístupových práv všem poskytovatelům služeb (PI, ŽP, logistickým firmám a správcům vozového parku), zejména pro účely správy a údržby vozového parku.

Záznamy v referenční databázi kolejových vozidel lze rozdělit do dvou skupin:

—

Správní údaje, které se týkají certifikace a registrace, například odkazy na záznamy o registraci v ES, identifikační údaje o oznámeném subjektu apod.; mohou zahrnovat historické údaje o vlastnictví, pronájmu apod. Je potřeba uvážit tyto kroky — certifikace v ES, — registrace v „domovském“ státě, — datum uvedení do provozu ve státě, kde byla udělena registrace, — registrace v jiných zemích pro použití na jejich vnitrostátní síti, — bezpečnostní certifikace pro všechna kolejová vozidla, která nevyhovují TSI pro subsystém „Kolejová vozidla“. Držitel je povinen zajistit, aby tyto údaje byly k dispozici a aby byly prováděny postupy, které s nimi souvisejí.

—

Konstrukční údaje, které zahrnují všechny podstatné (fyzické) prvky kolejových vozidel, včetně vlastností týkajících se životního prostředí, a všechny informace, o nichž se předpokládá, že zůstanou v platnosti po celou dobu životnosti kolejových vozidel – tato část může obsahovat historii větších úprav, větší údržby, generálních oprav apod.

4.2.11.4   Provozní údaje o kolejových vozidlech

Vedle referenčních údajů o kolejových vozidlech jsou nejdůležitějšími údaji pro provozní účely údaje o aktuálním stavu kolejových vozidel.

Součástí těchto údajů jsou dočasné údaje, například o omezeních, aktuální a připravované údržbě, počítadla km a poruch apod.; a všechny údaje, které by se daly považovat za „stavové“ (dočasná omezení rychlosti, údaje o brzdách, údaje o potřebě oprav a popis závad apod.).

Při používání provozních údajů o kolejových vozidlech je zapotřebí uvažovat tři různé entity, které reprezentují jednotlivé strany odpovědné za kolejová vozidla v průběhu dopravní operace:

—	železniční podnik jako odpovědný subjekt během doby, kdy má na starosti přepravu,

—	držitel kolejových vozidel a

—	uživatel (nájemce) kolejových vozidel.

Provozní údaje o kolejových vozidlech za všechny tři strany musejí být přístupné autorizovaným uživatelům do předem stanovené úrovně oprávnění na základě jedinečného klíče, kterým je identifikační číslo vozu.

Provozní údaje o kolejových vozidlech jsou součástí celoevropské provozní databáze vozů a intermodálních jednotek popsané v kapitole 4.2.12.2 Jiné databáze.

4.2.12   Různé referenční soubory a databáze

4.2.12.1   Referenční soubory

Pro provoz nákladních vlaků na evropské síti musejí být všem poskytovatelům služeb (PI, ŽP, logistickým firmám a správcům vozového parku) zpřístupněny níže uvedené referenční soubory. Údaje v nich musejí vždy odrážet aktuální stav.

Lokálně uchovávané a spravované:

—	referenční soubor služeb poskytovaných v mimořádných situacích, s vazbou na typ nebezpečných věcí.

Centrálně uchovávané a spravované:

—	referenční soubor kódů pro všechny PI, ŽP, poskytovatele služeb,

—	referenční soubor kódů pro přepravce,

—	referenční soubor kódů lokalit (primární, druhotná a zóna-kolej-místo),

—	referenční soubor kódů lokalit zákazníků,

—	referenční soubor všech existujících systémů řízení vlaků,

—	referenční soubor nebezpečných věcí, čísla UN a RID,

—	referenční soubor všech typů lokomotiv,

—	referenční soubor všech kódů CN a HS pro zboží,

—	referenční soubor všech evropských opraven,

—	referenční soubor všech evropských kontrolních orgánů,

—	referenční soubor všech evropských licencovaných operátorů včetně příslušného seznamu udělených národních bezpečnostních osvědčení.

Připravuje se kódování PI, ŽP, dopravců a zákazníků a též lokalit (primární, druhotné…) včetně lokalit zákazníků.

4.2.12.2   Jiné databáze

Aby se umožnilo sledování pohybu vlaků a vozů, musí být zavedeny níže uvedené databáze, které jsou aktualizovány při každé relevantní události v reálném čase. Oprávněné subjekty, jako jsou držitelé a správci vozového parku, musejí mít přístup k údajům, které potřebují pro plnění svých smluvních povinností.

—	Provozní databáze vozů a intermodálních jednotek

—	Plán přepravy pro vůz/intermodální jednotku

Tyto databáze musejí být přístupné přes společné rozhraní (4.2.14.1: a 4.2.14.7:).

Provozní databáze vozů a intermodálních jednotek

Komunikace mezi HŽP a železničními podniky v režimu spolupráce je založena na číslech vozů, resp. intermodálních jednotek. Proto musí ŽP, který komunikuje s provozovateli infrastruktury na úrovni vlaku, rozložit tyto informace na informace o jednotlivých vozech a intermodálních jednotkách. Tyto informace týkající se vozů a intermodálních jednotek musejí být uchovávány v provozní databázi vozů a intermodálních jednotek. S novými informacemi o pohybu vlaku dochází k vytváření nových záznamů/aktualizaci stávajících záznamů v provozní databázi vozů a intermodálních jednotek, které slouží pro informaci zákazníka. Pohybová část záznamu o vozu nebo přepravní jednotce pro kombinovanou dopravu se v databázi vytváří nejpozději v okamžiku obdržení času připravenosti vozu nebo přepravní jednotky k odsunu od zákazníka. Tento čas připravenosti je prvním pohybovým údajem o vozu zadávaným do provozní databáze vozů a intermodálních jednotek v souvislosti se skutečnou jízdou. Zprávy o pohybu vozu jsou definovány v kapitolách 4.2.8 (Pohyb vozu) a 4.2.9 (Vykazování ). Tato databáze musí být přístupná přes společné rozhraní (4.2.14.1: Obecná architektura a 4.2.14.7: Společné rozhraní).

Provozní databáze vozů a intermodálních jednotek je nejdůležitější databází pro sledování vozů, a tedy pro komunikaci mezi zúčastněnými ŽP a hlavním ŽP. Tato databáze popisuje pohyb vozu a intermodální jednotky od odjezdu až po konečné dodání na vedlejší kolej zákazníka včetně ETI a skutečných časů v různých místech až po ETA konečného dodání. Tato databáze též ukazuje stav kolejových vozidel:

—	Stav: nakládka

Tento stav se používá při výměně informací mezi ŽP a provozovateli infrastruktury a dalšími ŽP, které se podílejí na konkrétní jízdě.

—	Stav: naložený vůz na cestě

Tento stav se používá při výměně informací mezi PI a ŽP a jinými PI a ŽP, které se podílejí na konkrétní jízdě.

—	Stav: prázdný vůz na cestě

Tento stav se používá při výměně informací mezi PI a ŽP a jinými PI a ŽP, které se podílejí na konkrétní jízdě.

—	Stav: vykládka

Tento stav se používá při výměně informací mezi ŽP v místě určení a HŽP.

—	Stav: prázdný vůz v rukou správce vozového parku

Tento stav se používá k získání informací o dostupnosti vozu stanovených vlastností.

Databáze plánů přepravy vozů

Vlaky běžně vozí vozy od různých zákazníků. HŽP (ŽP zastávající úlohu integrátora služeb) musí pro každý vůz vypracovat a aktualizovat plán přepravy, který na úrovni vlaku odpovídá trase vlaku. Při nové trase vlaku – např. v případě narušení přepravy – dochází k přepracování plánu přepravy příslušných vozů. Plán přepravy se vytváří v okamžiku přijetí nákladního listu od zákazníka.

Plány přepravy vozů musí každý HŽP uchovávat v databázi. Tyto databáze musejí být přístupné přes společné rozhraní (4.2.14.1: a 4.2.14.7:).

Poznámka:

Kromě uvedených povinných databází si může vést každý PI databázi vlaků.

Tato databáze vlaků provozovatele infrastruktury koresponduje s pohybovou částí provozní databáze vozů a intermodálních jednotek. Hlavními datovými položkami jsou údaje o vlaku ze zprávy o řazení vlaku od ŽP. Databázi je zapotřebí aktualizovat při každé události související s vlaky. Alternativní možností uchovávání těchto údajů je databáze tras (kapitola 4.2.2:). Tyto databáze musejí být přístupné přes společné rozhraní (4.2.14.1: a 4.2.14.7:).

4.2.21.3   Další požadavky na databáze

Tato kapitola shrnuje další požadavky na databáze.

Tyto požadavky jsou následující:

1.	Ověřování Každá databáze musí podporovat ověřování uživatelů systémů před umožněním přístupu k databázi.

2.	Zabezpečení Každá databáze musí mít zabezpečení ve smyslu kontroly přístupu k databázi. Šifrování samotného obsahu databáze není požadováno.

3.	Konzistence Každá databáze musí zaručovat vlastnosti ACID (Atomicity, Consistency, Isolation, Durability, tj. atomicita, konzistence, oddělenost, trvalost).

4.

Řízení přístupu Každá databáze musí umožňovat přístup k datům pouze uživatelům nebo systémům majícím příslušné oprávnění. Řízení přístupu musí být zajištěno až do úrovně jednotlivých atributů datových záznamů. Databáze musí umožňovat nakonfigurování uživatelských přístupových práv pro vkládání, aktualizaci nebo mazání datových záznamů.

5.	Vystopování Každá databáze musí podporovat evidenci všech činností prováděných s databází, aby se umožnilo podrobné vystopování vložených dat (kdo kdy provedl jakou změnu obsahu databáze).

6.	Strategie uzamčení Každá databáze musí používat strategii uzamčení, která umožňuje přístup k datům, i když jiní uživatelé současně provádějí úpravu záznamů.

7.	Přístup více uživatelů Každá databáze musí umožňovat současný přístup více uživatelů a systémů k datům.

8.	Spolehlivost Databáze musí být natolik spolehlivá, aby zaručovala požadovanou dostupnost.

9.	Dostupnost Databáze musí být dostupná na vyžádání v nejméně 99,9 % případů.

10.	Udržovatelnost Udržovatelnost databáze musí umožňovat dosažení požadované dostupnosti.

11.	Bezpečnost Databáze se samy o sobě nedotýkají bezpečnosti. Proto je bezpečnostní stránka irelevantní. To ovšem nic nemění na skutečnosti, že data v databázi – např. nesprávná nebo neaktuální – mohou mít vliv na bezpečnost provozu vlaku.

12.	Kompatibilita Každá databáze musí podporovat některý běžně rozšířený jazyk pro manipulaci s daty, např. SQL nebo XQL.

13.	Funkce importu Každá databáze musí být vybavena funkcí, která umožňuje import formátovaných dat, která lze použít k naplnění databáze namísto ručního zadávání.

14.	Funkce exportu Každá databáze musí být vybavena funkcí, která umožňuje vyexportování celého obsahu databáze nebo jeho části v podobě formátovaných dat.

15.	Povinná pole Každá databáze musí obsahovat povinná pole, která musejí být vyplněna, aby mohl být každý jednotlivý vkládaný záznam uznán jako platný záznam do databáze.

16.	Kontroly věrohodnosti Každá databáze musí umožňovat nakonfigurování kontrol věrohodnosti před uznáním vložení, aktualizace nebo výmazu datových záznamů.

17.	Reakční doby Každá databáze musí mít reakční dobu, která umožňuje uživatelům vkládat, aktualizovat nebo mazat datové záznamy včasným způsobem.

18.	Otázky výkonnosti Každá databáze musí podporovat dotazy nezbytné pro realizaci asi 60 000 jízd vlaků za 24 hodin. Počítá se s tím, že cca 50 % těchto jízd se uskuteční v rozpětí 2 hodin. Počet a druh dotazů nebo aktualizací na jeden vlak závisí na celkovém způsobu plánování a provozování vlaků.

19.	Otázky kapacity Každá databáze musí podporovat uchovávání důležitých údajů o všech nákladních vozech resp. síti. Kapacitu musí být možno jednoduše rozšířit (např. přidáním dalších paměťových kapacit a počítačů). Rozšíření kapacity si nesmí vyžádat náhradu subsystému.

20.	Historická data Databáze musí podporovat správu historických dat ve smyslu zpřístupnění údajů, které již byly přesunuty do archívu.

21.	Strategie zálohování K dispozici musí být strategie zálohování, která zajistí, aby bylo možno obnovit kompletní obsah databáze za posledních až 24 hodin.

22.	Komerční otázky Pokud jde o použitý databázový systém, půjde o běžně komerčně dostupný (COTS) nebo volně šiřitelný (Open Source) produkt.

Poznámky:

Uvedené požadavky musejí být řešeny prostřednictvím standardního systému řízení báze dat (DBMS).

Používání databází je součástí jednotlivých pracovních toků popsaných v předchozím textu. Pracovní toky mají obecně formu mechanismu žádost – odpověď, kdy si příslušná strana vyžádá informace z databáze přes společné rozhraní (4.2.14.1: Obecná architektura a 4.2.14.7: Společné rozhraní). DBMS zareaguje na tuto žádost buď poskytnutím vyžádaných dat, nebo odpovědí, že nelze poskytnout žádná data (buď taková data neexistují, nebo k nim není povolen přístup).

4.2.13   Předávání dokumentů v elektronické podobě

V kapitole 4.2.14 (Sítě a komunikace) je popsána komunikační síť pro výměnu údajů. Tato síť a popsané zabezpečení umožňují jakýkoli typ síťového přenosu, jako e-mail, přenos souboru (ftp, http) apod. O typu elektronického přenosu dokumentů mohou rozhodovat strany účastnící se přenosu informací, které se mohou kupříkladu dohodnout, že použijí ftp.

4.2.14   Sítě a komunikace

4.2.14.1   Obecná architektura

Tento subsystém časem čeká rozmach a interakce velkého a složitého interoperabilního železničního telematického společenství čítající stovky partnerů (železniční podniky, provozovatelé infrastruktury, …), kteří spolu budou soutěžit, resp. spolupracovat na plnění potřeb trhu.

Síťová a komunikační infrastruktura, o níž se bude toto interoperabilní železniční telematické společenství opírat, bude založena na společné „Architektuře výměny informací“, kterou budou znát a kterou přijmou všechny zúčastněné strany.

Navrhovaná „Architektura výměny informací“:

—	je zkonstruována tak, aby sladila nesourodé informační modely prostřednictvím sémantické transformace dat vyměňovaných mezi jednotlivými systémy a prostřednictvím sjednocení rozdílů v protokolech na úrovni podnikových procesů a aplikací,

—	má minimální dopad na existující IT architektury jednotlivých partnerů,

—	chrání dosavadní investice do IT.

Architektura výměny informací upřednostňuje hlavně rovnocennou (Peer-to-Peer) interakci mezi všemi partnery, a přitom zaručuje prostřednictvím souboru centralizovaných služeb celkovou integritu a konzistentnost interoperabilního železničního společenství.

Model Peer-to-Peer interakce umožňuje nejlepší rozdělení nákladů mezi jednotlivé partnery na základě skutečného využívání a povede obecně k menším problémům při rozšiřování. Schématické znázornění obecné architektury najdete v příloze A indexu 5 kapitole 1.5.

4.2.14.2   Síť

Sítí a prací v síti se v tomto případě rozumí způsob a filozofie komunikace a nikoli fyzická síť.

Interoperabilita železničního systému je založena na společné „Architektuře výměny informací“, kterou znají a akceptují všechny zúčastněné strany, což snižuje překážky a napomáhá vstupu nových subjektů, zejména zákazníků.

Problematiku zabezpečení proto neřeší síť (VPN, tunelování, ...), ale výměna a správa zpráv, které jsou bezpečné samy ze své podstaty. Není proto zapotřebí VPN síť (správa velké VPN sítě by byla složitá a nákladná), čímž jsou odbourány problémy s odpovědností a určováním vlastnictví. Pro dosažení potřebné úrovně zabezpečení není nutné tunelování.

Pokud však některé zúčastněné subjekty mají zavedeny nebo chtějí zavést vyšší stupně zabezpečení na vybraných částech sítě, mohou tak učinit.

Přes veřejnou internetovou síť je možné implementovat hybridní Peer-to-Peer model s „centrálním datovým skladem“ a „společným rozhraním“ na uzlu každého partnera.

Nejprve se navazuje kontakt s centrálním datovým skladem, ze kterého lze získat metainformace, jako jsou údaje o totožnosti partnera, které jsou v něm uloženy, nebo kde lze ověřit bezpečnostní oprávnění. Poté probíhá rovnocenná (peer-to-peer) komunikace přímo mezi jednotlivými partnery.

4.2.14.3   Protokoly

Smějí se používat pouze protokoly náležející do soustavy protokolů TCP/IP.

4.2.14.4   Zabezpečení

Aby se dosáhlo vysoké úrovně zabezpečení, musejí být všechny zprávy samostatné, což znamená, že informace ve zprávě jsou zabezpečeny a příjemce si může ověřit pravost zprávy. To lze vyřešit pomocí systému šifrování a podpisů podobného šifrování elektronické pošty. Šifrování umožní využívat jakýkoli typ síťového přenosu, včetně e-mailu, přenosu souborů (ftp, http) apod. Strany, mezi nimiž probíhá výměna informací, se pak mohou samy rozhodnout pro konkrétní typ přenosu, který chtějí použít.

4.2.14.5   Šifrování

Je třeba používat buď asymetrické šifrování, nebo hybridní řešení na bázi symetrického šifrování s veřejným klíčem, neboť sdílení společného tajného klíče mezi více partnery musí po nějaké době nevyhnutelně selhat. Vyšší úrovně zabezpečení se snadno dosáhne, pokud každý partner převezme odpovědnost za svůj vlastní pár klíčů, i když v takovém případě je zapotřebí vyšší úrovně integrity centrálního datového skladu (hlavního serveru pro správu klíčů).

4.2.14.6   Centrální datový sklad

Centrální datový sklad musí být schopen pracovat s:

—	metadaty, což jsou strukturovaná data popisující obsah zpráv,

—	infrastrukturou veřejných klíčů (Public Key Infrastructure, PKI),

—	orgánem vydávajícím certifikáty (Certification Autority, CA),

—	adresářem („telefonním seznamem“), který obsahuje všechny informace o zúčastněných partnerech potřebné pro výměnu zpráv.

Za správu centrálního datového skladu by měla zodpovídat nezisková celoevropská organizace.

4.2.14.7   Společné rozhraní

Společné rozhraní je povinné pro každého partnera, který se chce zapojit do interoperabilního železničního společenství.

Společné rozhraní musí být schopno zvládat:

—	formátování odchozích zpráv v souladu s metadaty,

—	podepisování a šifrování odchozích zpráv,

—	adresování odchozích zpráv,

—	ověření pravosti příchozích zpráv,

—	dešifrování příchozích zpráv,

—	kontroly shody příchozích zpráv podle metadat,

—	jednotný společný přístup k jednotlivým databázím.

Každá instance společného rozhraní musí mít přístup ke všem údajům vyžadovaným podle TSI pro každý ŽP, PI atd., bez ohledu na to, zda jsou příslušné databáze centrální, nebo individuální (viz též příloha A index 5 kapitola 1.6).

Na základě ověření pravosti příchozích zpráv lze zavést kvitanci:

i)	kladná kvitance ACK, byla-li pravost uznána,

ii)	záporná kvitance NACK, nebyla-li pravost uznána.

Společné rozhraní používá informace v centrálním datovém skladu k řízení výše uvedených úkolů.

Každý partner si může v zájmu zkrácení časů odezvy zavést místní „zrcadlo“ centrálního datového skladu.

4.3   Funkční a technické specifikace rozhraní

Ve světle základních požadavků stanovených v kapitole 3 jsou funkční a technické specifikace rozhraní stanoveny takto:

4.3.1   Rozhraní s TSI pro subsystém „Infrastruktura“

Subsystém „Infrastruktura“ zahrnuje systémy pro řízení dopravy a sledovací a navigační systémy: technické instalace pro zpracování dat a telekomunikace, které jsou určeny pro služby dálkové osobní a nákladní dopravy po železniční síti a které mají zaručit bezpečný a harmonický provoz sítě a efektivní řízení dopravy.

Subsystém „Využití telematiky v nákladní dopravě“ využívá údaje požadované pro provozní účely, které jsou uvedeny ve smlouvě o trase, případně aktualizovány PI v databázi informací o omezeních. Neexistuje tedy žádné přímé rozhraní mezi touto TSI a TSI pro subsystém „Infrastruktura“.

4.3.2   Rozhraní s TSI pro subsystém „Řízení a zabezpečení“

Jediná vazba na řízení a zabezpečení je přes

—	smlouvu o trase, kde jsou v popisu úseku trati uvedeny příslušné informace o použitelných řídicích a zabezpečovacích zařízeních, a přes

—	různé referenční databáze kolejových vozidel, kde musejí být uloženy údaje o řídicích a zabezpečovacích zařízeních kolejových vozidel.

4.3.3   Rozhraní se subsystémem „Kolejová vozidla“

Subsystém „Využití telematiky v nákladní dopravě“ stanoví technické a provozní údaje, které musejí být k dispozici o kolejových vozidlech.

TSI pro subsystém „Kolejová vozidla“ stanoví vlastnosti vozů. Dojde-li ke změně vlastností vozu, musí být v rámci běžné údržby databáze provedena aktualizace příslušných údajů v referenčních databázích kolejových vozidel. Neexistuje tedy žádné přímé rozhraní mezi touto TSI a TSI pro subsystém „Infrastruktura“.

4.3.4   Rozhraní s TSI pro subsystém „Provoz a řízení dopravy“

Subsystém „Provoz a řízení dopravy“ stanoví postupy a související vybavení umožňující hladkou spolupráci jednotlivých strukturálních subsystémů, a to jak při běžném, tak při zhoršeném provozu, včetně zejména řízení vlaků a plánování a řízení dopravy.

Subsystém „Využití telematiky v nákladní dopravě“ vymezuje hlavně využití pro nákladní dopravu včetně sledování nákladu a vlaků v reálném čase a řízení vazeb na jiné druhy dopravy.

Aby byla zajištěna konzistentnost mezi oběma TSI, použije se tento postup:

Při rozšíření nebo změně specifikací TSI pro Provoz a řízení dopravy, které se dotýkají požadavků této TSI, musí být konzultován orgán odpovědný za tuto TSI.

Při jakékoli změně specifikací této TSI, které se dotýkají požadavků TSI pro Provoz a řízení dopravy, musí být konzultován orgán odpovědný za TSI pro Provoz a řízení dopravy.

4.4   Provozní předpisy

Ve světle základních požadavků stanovených v kapitole 3 jsou provozní předpisy specifické pro subsystém upravený touto TSI stanoveny takto:

4.4.1   Kvalita údajů

Aby byla zabezpečena kvalita údajů, odpovídá autor jakékoli TSI zprávy za správnost údajů v ní obsažených v době odeslání zprávy. Jsou-li k dispozici zdrojová data z databází podle této TSI, musejí být tato data použita.

Nejsou-li k dispozici zdrojová data z databází stanovených podle této TSI, musí provést autor zprávy kontrolu kvality údajů z vlastních zdrojů.

Součástí zabezpečení kvality údajů jsou srovnání s údaji z databází stanovených podle této TSI, jak je popsáno výše, plus případné logické kontroly, které mají zaručit včasnost a kontinuitu údajů a zpráv.

Kvalita údajů závisí na jejich vhodnosti pro zamýšlené použití, čímž se rozumí, že:

—	jsou bezchybné: dostupné, přesné, včasné, kompletní, konzistentní s jinými zdroji apod., a že

—	mají požadované vlastnosti: jsou relevantní, komplexní, náležitě podrobné, snadno čitelné, snadno interpretovatelné apod.

Kvalita údajů je charakterizována zejména:

—	přesností,

—

úplností,

—	konzistentností,

—	včasností.

Přesnost:

Požadované informace (údaje) musejí být zachyceny co možná nejekonomičtěji. To je možné jedině tehdy, jsou-li primární údaje, které hrají ústřední úlohu v přepravě zásilky, zaznamenávány za celou dobu přepravy pouze jedinkrát. Proto by měly být primární údaje zadávány do systému co možná nejblíže jejich zdroji, např. na základě nákladního listu vypracovaného v okamžiku, kdy je vůz nebo zásilka předán k přepravě, aby mohly být kompletně použity při jakémkoli dalším zpracování.

Úplnost:

Před zasláním zprávy je třeba zkontrolovat její úplnost a syntaxi oproti metadatům. Tím se zabrání zbytečnému posílání informací po síti.

Také u všech příchozích zpráv je zapotřebí zkontrolovat jejich úplnost oproti metadatům.

Konzistentnost:

Obchodní pravidla (business rules) musejí zaručovat konzistentnost. Měla by bránit dvojímu zadávání a jasně stanovit osobu odpovědnou za data.

To, jakým způsobem budou tato pravidla realizována v praxi, závisí na jejich složitosti. U jednoduchých pravidel postačují databázová omezení a spouštěcí mechanismy. V případě složitějších pravidel, která vyžadují data z různých tabulek, musí být zavedeny validační postupy, které kontrolují číslo verze dat, než dojde k vygenerování dat pro rozhraní a uvedení nové verze dat do provozu. Musí být zaručeno, aby byl ověřen soulad přenesených dat se stanovenými obchodními pravidly.

Včasnost:

Je důležité, aby informace byly poskytovány v okamžiku, kdy jsou potřeba. Pokud dává podnět k uložení údajů nebo odeslání zprávy přímo IT systém, není včasnost problémem, je-li systém navržen správně a vyhovuje-li potřebám obchodních procesů. Jenže ve většině případů dává podnět k odeslání zprávy operátor nebo přinejmenším nový údaj zadaný operátorem (kupříkladu zaslání řazení vlaku nebo aktualizace údajů o vlaku či vozu). Pro splnění požadavků na včasnost je zapotřebí, aby byla aktualizace údajů prováděna co možná nejdříve, a zprávy automaticky odesílané systémem tak mohly obsahovat aktuální údaje.

Obecně musejí být splněny tyto požadavky:

Reakční doba na dotazy nesmí být delší než 5 minut. Všechny aktualizace a výměny dat se musejí provádět co možná nejdříve. Reakční a přenosová doba systému při aktualizacích by měla být kratší než 1 minuta.

Měřítka kvality údajů

Úplnost povinných dat (procento datových polí, v nichž jsou zadány hodnoty) a konzistentnost údajů (procento hodnot odpovídajících si mezi tabulkami, soubory resp. záznamy) musí být 100 %.

Pokud jde o včasnost údajů (procento údajů dostupných ve stanoveném prahovém termínu), musí být dosaženo 98 % úspěšnosti. Nejsou-li prahové termíny stanoveny v této TSI, musejí být stanoveny ve smlouvách mezi zúčastněnými stranami.

Přesnost (procento uložených hodnot, které odpovídají skutečné hodnotě) musí být vyšší než 90 %. Přesná hodnota a kritéria musejí být stanoveny ve smlouvách mezi zúčastněnými stranami.

4.4.2   Provoz centrálního datového skladu

Funkce centrálního datového skladu jsou vymezeny v kapitole 4.2.14.6 (Centrální datový sklad). Aby byla zaručena kvalita, měl by subjekt provozující centrální datový sklad odpovídat za aktualizaci a kvalitu metadat a adresáře i za správu přístupu (veřejné klíče). Pokud jde o kvalitu metadat, musí být dosaženo 100 % spolehlivosti, konzistentnosti, včasnosti a přesnosti.

4.5   Pravidla pro údržbu

Ve světle základních požadavků stanovených v kapitole 3 jsou pravidla pro údržbu specifická pro subsystém upravený touto TSI stanovena takto:

Kvalita dopravní služby musí být zaručena i v případě úplné nebo částečné poruchy zařízení pro zpracování dat. Je proto vhodné nainstalovat zdvojené systémy nebo počítače s mimořádně vysokou spolehlivostí, pro něž je zaručen nerušený provoz i během údržby.

Otázky údržby jednotlivých databází jsou zmíněny v kapitole 4.2.12.3 (Další požadavky na databáze), bodech 10 a 21.

4.6   Odborné kvalifikace

Odborné kvalifikace pracovníků potřebné pro provoz a údržbu subsystému a pro uplatňování této TSI jsou stanoveny takto:

Uplatňování této TSI nevyžaduje zcela nový hardwarový a softwarový systém s novými pracovníky. Realizace požadavků této TSI vede pouze ke změnám, aktualizacím nebo funkčnímu rozšíření provozu, který zvládají dosavadní pracovníci. Proto nejsou stanoveny žádné další požadavky ke stávajícím vnitrostátním a evropským předpisům o odborných kvalifikacích.

Je-li to třeba, nemělo by se doplňující školení pracovníků omezit pouze na ukázku obsluhy zařízení. Pracovníci musejí znát svou úlohu, kterou hrají v celém dopravním procesu, a rozumět jí. Musí si být zejména vědomi toho, že je třeba, aby neustále podávali vysoký pracovní výkon, neboť to je rozhodujícím předpokladem spolehlivosti informací, jež budou zpracovávány v návazných krocích.

Odborné kvalifikace potřebné pro řazení a provoz vlaků jsou stanoveny v TSI pro subsystém „Provoz a řízení dopravy“.

4.7   Zdravotní a bezpečnostní podmínky

Zdravotní a bezpečnostní podmínky požadované pro provoz a údržbu předmětného subsystému (nebo pro technickou oblast působnosti vymezenou v odstavci 1.1) a pro uplatňování této TSI jsou stanoveny takto:

Nejsou stanoveny žádné doplňující podmínky ke stávajícím vnitrostátním a evropským předpisům o ochraně bezpečnosti a zdraví při práci.

4.8   Registry infrastruktury a kolejových vozidel

Podle čl. 24 odst. 1 směrnice 2001/16/ES „členské státy zajistí zveřejňování a každoroční aktualizaci registrů infrastruktury a registrů kolejových vozidel. Tyto registry musí uvádět hlavní charakteristické znaky každého subsystému nebo částí dotyčného subsystému a jejich vztah k charakteristickým znakům stanoveným použitelnými TSI. Za tímto účelem musí být v každé TSI přesně uvedeno, jaké informace musí být do registru infrastruktury a do registru kolejových vozidel zařazovány.“

Vzhledem k tomu, že jsou tyto registry aktualizovány a zveřejňovány jednou ročně, nejsou pro subsystém „Využití telematiky v nákladní dopravě“ použitelné. Proto se tato TSI těchto registrů netýká.

5.   PRVKY INTEROPERABILITY

5.1   Definice

Podle čl. 2 písm. d) směrnice 2001/16/ES se:

prvky interoperability rozumějí „veškeré základní konstrukční části, skupiny konstrukčních částí, podsestavy nebo úplné sestavy zařízení, která jsou nebo mají být v budoucnu zahrnuta do subsystému a na nichž přímo nebo nepřímo závisí interoperabilita transevropského konvenčního železničního systému. Pojetí ‚prvku‘ zahrnuje jak hmotné předměty, tak nehmotné předměty, jako je programové vybavení“.

5.2   Seznam prvků

Prvků interoperability se týkají příslušná ustanovení směrnice 2001/16/ES.

Subsystém „Využití telematiky v nákladní dopravě“ neobsahuje žádné prvky interoperability.

Pro splnění požadavků této TSI je zapotřebí pouze standardní IT vybavení, bez jakéhokoli konkrétního zaměření na interoperabilitu v železničním prostředí. To platí pro použité hardwarové komponenty i pro standardní programové vybavení, jako jsou operační systém a databáze. Aplikační programové vybavení každého uživatele je individuální a může být přizpůsobeno a zdokonaleno podle skutečné individuální funkčnosti a potřeb. Navrhovaná „architektura aplikační integrace“ počítá s tím, že aplikace nemusejí být založeny na stejném interním informačním modelu. Aplikační integrace je definována jako proces, který umožňuje vzájemnou spolupráci nezávisle navržených aplikačních systémů.

5.3   Výkon a specifikace prvků interoperability

Viz kapitola 5.2, pro subsystém „Využití telematiky v nákladní dopravě“ není relevantní.

6.   POSUZOVÁNÍ SHODY NEBO VHODNOSTI PRO POUŽITÍ PRVKŮ INTEROPERABILITY A OVĚŘOVÁNÍ SUBSYSTÉMŮ

6.1   Prvky interoperability

6.1.1   Postupy posuzování

Postup posuzování shody nebo vhodnosti pro použití prvků interoperability musí vycházet z evropských specifikací nebo specifikací schválených podle směrnice 2001/16/ES.

Při posuzování vhodnosti pro použití musí tyto specifikace obsahovat všechny parametry, které je třeba měřit, monitorovat nebo sledovat, a popisovat příslušné testovací metody a postupy měření, ať už na zkušebním zařízení, nebo v reálném železničním prostředí.

Postupy pro posuzování shody a/nebo vhodnosti pro použití:

Seznam specifikací, popis testovacích metod:

Pro TSI pro subsystém „Využití telematiky v nákladní dopravě“ není relevantní.

6.1.2   Modul

Na žádost výrobce nebo jeho zplnomocněného zástupce usazeného ve Společenství provede oznámený subjekt postup podle ustanovení příslušných modulů uvedených v rozhodnutí Rady 93/465/EHS, jak je stanoven, pozměněn a doplněn v příloze této TSI.

Moduly by měly být kombinovány a používány selektivně podle konkrétního prvku.

Pro TSI pro subsystém „Využití telematiky v nákladní dopravě“ není relevantní.

6.2   Subsystém „Využití telematiky v nákladní dopravě“

Na žádost zadavatele nebo jeho zplnomocněného zástupce usazeného ve Společenství provede oznámený subjekt ES postup ověřování podle přílohy VI směrnice 2001/16/ES.

Podle přílohy II směrnice 2001/16/ES jsou subsystémy rozčleněny na strukturální a provozní oblast.

Posuzování shody je povinné pro TSI ve strukturální oblasti. Subsystém „Využití telematiky v nákladní dopravě“ náleží do provozní oblasti a tato TSI nestanoví žádné moduly pro posuzování shody.

Centrální datový sklad a společné rozhraní v uzlu každého partnera jsou však oporou aplikační integrace. Model výměny informací je založen na centralizovaném datovém skladu pro integraci aplikací, který soustřeďuje metadata potřebná pro vzájemnou interakci do jediného fyzického místa. Metadata obsahují informace o komunikačním obsahu (tj. o tom, co je obsaženo v zasílaných datech), identifikační údaje o odesílatelích a příjemcích a protokoly pro proces vzájemné interakce.

Je třeba zdůraznit tyto skutečnosti:

—	Centrální datový sklad obsahuje adresář (telefonní seznam) všech zúčastněných partnerů, kteří se podílejí na výměně zpráv. Tento adresář musí být vždy aktuální. Případné chyby se okamžitě projeví. Není zapotřebí žádný postup posuzování shody.

—	Centrální datový sklad obsahuje také orgán vydávající certifikáty (otevřená CA PKI). Jde především o administrativní akt, který je fyzicky implementován. Případné chyby se okamžitě projeví. Není zapotřebí žádný postup posuzování shody.

—

Centrální datový sklad obsahuje metadata pro zprávy (v souladu s přílohou A indexem 1), která jsou základem pro výměnu zpráv v heterogenním informačním prostředí. V centrálním datovém skladu musí probíhat správa a aktualizace metadat. Jakákoli nekompatibilita ve struktuře zprávy nebo dat obsažených v odesílané či přijímané zprávě je okamžitě odhalena a přenos je zamítnut. Není zapotřebí žádný postup posuzování shody.

—

Společné rozhraní v uzlu každého partnera obsahuje hlavně lokální „zrcadlo“ centrálního datového skladu pro účely zkrácení reakční doby a snížení zátěže datového skladu. Je třeba zajistit, aby vždy souhlasily verze dat v centrálním datovém skladu a ve společném rozhraní. Proto je zapotřebí provádět aktualizace dat na centrální úrovni a stahovat nové verze odtamtud. Není zapotřebí žádný postup posuzování shody.

7.   UPLATŇOVÁNÍ

7.1   Způsoby použití této TSI

7.1.1   Úvod

Tato TSI má zajistit IT podporu pro podnikové procesy v oblasti nákladní železniční dopravy, která může znamenat podstatné zkvalitnění dopravních služeb. Její použití je nezávislé na nové/modernizované nebo stávající infrastruktuře nebo kolejových vozidlech, jak je běžné u jiných TSI požadovaných směrnicí 2001/16/ES.

Vzhledem ke své všeprostupující povaze bude mít tato TSI velký dopad na podnikové a provozní postupy celého evropského železničního odvětví. Pro trvalý růst mezinárodní nákladní dopravy je navíc zapotřebí celoevropského přístupu k managementu informací. Z těchto důvodů je zapotřebí vytvořit ucelený transevropský plán pro uplatňování této TSI. Tento plán by měl stanovit jednak vizi toho, čeho se má uplatňováním této TSI dosáhnout, a jednak způsob a načasování přechodu od současného systému roztříštěných informačních systémů ke komplexní celoevropské informační dálnici, která může být přínosem pro všechny subjekty, jež mají co do činění s železniční dopravou – provozovatele infrastruktury, železniční podniky, dopravce a nakonec i zákazníky.

Na tomto pozadí vznikla koncepce strategického evropského plánu zavádění (Strategic European Deployment Plan, SEDP). SEDP vymezuje cílový systém, kterého má být dosaženo, aby bylo možno uplatňovat tuto TSI, a nastiňuje základní plán zavádění popsaný v následujícím odstavci.

7.1.2   Strategický evropský plán zavádění (Strategic European Deployment Plan, SEDP)

7.1.2.1   Cíle SEDP

SEDP má tři cíle:

1.	poskytnout vizi pro uplatňování TSI pro subsystém „Využití telematiky v nákladní dopravě“ (TAF TSI) v evropském železničním odvětví;

2.	vymezit tuto vizi z technického hlediska a z hlediska ekonomické proveditelnosti;

3.	objasnit činnosti, které jsou považovány za nezbytné pro realizaci této vize.

Vedle návodu pro uplatňování TAF TSI a zviditelnění celého procesu uplatňování by měl SEDP poskytnout vhodná měřítka pro monitorování pokroku jednotlivých partnerů – provozovatelů infrastruktury, železničních podniků, dopravců a nakonec i zákazníků – způsobem, který může zaručit ochranu jejich zájmů. To se týká zejména požadovaných investic, které by měly být vloženy provozovateli infrastruktury a železničními podniky do případné modernizace a integrace jejich stávajících IT systémů a schopnosti systémů založených na TAF TSI účinně reagovat na neustále se vyvíjející potřebu informací ze strany dopravců i klientů.

SEDP vychází z těchto předpokladů a měl by představovat nástroj, který umožní celému evropskému železničnímu odvětví soustředit se na vyvinutí panevropského informačního systému a který podpoří synergické efekty, zabrání roztříštění a umožní soustředění omezených zdrojů na prioritní záležitosti a lepší plnění hlavních cílů v oblasti kvality dopravních služeb.

7.1.2.2   Požadavky SEDP

Vypracování takového plánu vyžaduje systematickou analýzu příslušných technických, provozních, ekonomických a institucionálních hledisek, o něž se opírá proces uplatňování TAF TSI. Tato analýza zahrnuje zejména:

1.	určení vhodných stávajících IT aplikací, které by mohly vytvořit základ, na němž by mohl být vystavěn panevropský systém schopný vyhovět požadavkům TAF TSI (dále jen „systém TAF“);

2.	definici funkčních a souvisejících požadavků na data a výkon, potřebných pro splnění TAF TSI;

3.	nástin architektury systému TAF. Ten musí vycházet z analýzy systémových konfigurací potenciálně schopných sjednotit stávající IT vybavení a současně zajistit požadovanou funkčnost a výkon – např. centralizované nebo distribuované architektury klient-server, architektury agentů;

4.	stanovení technických požadavků na systém TAF a jeho potenciální subsystémy/klientské systémy a stanovení požadavků na rozhraní těchto systémů;

5.

vypracování celkového plánu vývoje systému TAF od koncepce až po realizaci. Tento plán by měl poskytnout vodítka k postupu a rozvržení případné integrace stávajícího vybavení a též vodítka k posouzení rizika rozhodujících fází tohoto plánu. Kromě toho by se měl zabývat probíhajícím a plánovaným vývojem stávajícího vybavení;

6.	určení příslušných struktur, o něž se opírá vývoj systému TAF a jeho provoz po celou dobu jeho životnosti;

7.	posouzení nákladů na celý životní cyklus (LCC) spojených se zavedením a provozem systému TAF společně s plánem dalších investic.

Tato analýza by neměla ani tak sledovat předem daný postup, jako by se spíš měla vyvíjet na základě iterativního přístupu zaměřeného na nalezení optimální strategie zavedení systému. Hledání by mělo nakonec přispět k dosažení těchto výsledků:

—	kompletní soubor funkčních, výkonnostních, systémových a technických specifikací pro systém TAF,

—	program zavedení od koncepce po realizaci. Ten musí zahrnovat podrobné rozvržení všech těch fází projektu a hlavních individuálních aktivit, které přispívají k dosažení konečných cílů,

—	definice struktury, metod a postupů řízení (7), o něž se opírá rozvoj, validace a provoz systému,

—	investiční plán a následný finančně inženýrský přístup umožňující jeho realizaci.

7.1.3   Způsoby použití

Způsoby použití této TSI jsou podřízeny uvedeným požadavkům SEDP.

V souvislosti s přípravou SEDP se použijí tyto požadavky:

—	Železniční podniky a provozovatelé infrastruktury musí přispět poskytnutím funkčních a technických informací o svém stávajícím individuálním využití telematiky v nákladní dopravě (8).

—

Reprezentativní subjekty železničního odvětví, které jednají na evropské úrovni, vymezené v čl. 3 odst. 2 nařízení (ES) č. 881/2004, musí vypracovat SEDP, jak bylo popsáno v předchozím odstavci. Tento strategický plán musí zaslat členským státům a Komisi do jednoho roku od data zveřejnění tohoto nařízení. Nebude-li po tomto období zaznamenán žádný podstatný pokrok, bude Evropské komisi svěřen úkol dodatečně předložit návrh právních aktů pro uplatňování této TSI.

—

Po vypracování strategického plánu musí být zkoumána ospravedlnitelnost všech činností souvisejících s uplatňováním subsystému „Využití telematiky v nákladní dopravě“ oproti tomuto plánu. Jakákoli odchylka navrhovaná některým ŽP nebo PI by měla být odůvodněna v prováděcích dokumentech předložených příslušnému členskému státu, Evropské železniční agentuře a EK.

7.2   Strategie přechodu

Je zapotřebí vypracovat strategie přechodu, které se použijí v období přechodu od současného systému nestejnorodých informačních systémů k systému vyhovujícímu této TSI, jak stanoví SEDP.

Pro tento účel byly v rámci této TSI vypracovány koncepce zacházení s informacemi, které by měly přechod usnadnit. Tyto koncepce umožňují postupné budování cílového panevropského systému TAF TSI, zejména prostřednictvím takových nástrojů, jako je peer-to-peer komunikace založená na koncepci souhrnných datových skladů (zahrnujících metadata pro zprávy, adresář dat a orgán vydávající certifikáty).

V dalším textu uvádíme názorný příklad, jak by mohla v praxi probíhat taková výměna informací mezi ŽP a PI. Tento příklad ukazuje pouze logické komunikační závislosti uvnitř systému, v členění po jednotlivých krocích, bez zohlednění případných konkrétních potřeb, které by mohly mít v průběhu přechodu jednotlivé systémy. K těmto individuálním potřebám by mělo být náležitě přihlédnuto při přípravě SEDP.

Krok 1: Obecná architektura popsaná v kapitole 4.2.14.1 (Obecná architektura) zahrnuje koncepci „centrálního datového skladu“ provozovaného neutrálním a nezávislým subjektem. U každého účastníka komunikační sítě je stanovena vrstva rozhraní pro interoperabilitu, která může zahrnovat systém výměny zpráv a která může být vystavěna centrálně nebo individuálně. Pokud jde o „sítě a komunikaci“, jsou tyto části jedinými provozními aspekty, které jsou zapotřebí pro interoperabilitu. Jsou též základními předpoklady pro celoevropskou výměnu údajů. Proto musejí být realizovány a instalovány před zprovozněním jakékoli další funkce.

Po tomto kroku již lze realizovat předávání dokumentů v elektronické podobě (kapitola 4.2.13: Předávání dokumentů v elektronické podobě) nezávisle na logickém sledu ostatních kroků.

Vlastnosti dostupné po tomto kroku pro
PI	ŽP
Jsou vytvořeny základy pro výměnu informací. Výhoda:   Je umožněno elektronické předávání dokumentů v konečném prostředí.   Lze provádět testy dalších kroků v reálném prostředí.

Krok 2: Současně s krokem 1 nebo krátce po něm musí být k dispozici referenční databáze kolejových vozidel a provozní databáze vozů a intermodálních jednotek (kapitola 4.2.11.3: Referenční databáze kolejových vozidel a kapitola 4.2.12.2: Jiné databáze). Neobsahují-li již databáze všechny údaje, musí být alespoň umožněno ručně zadat do provozní databáze vozů a intermodálních jednotek – za každý vůz v jedoucím vlaku – údaje potřebné pro železniční dopravu, jako jsou uvedeny v příloze A indexu 2).

Vlastnosti dostupné po tomto kroku pro
PI	ŽP
V provozní databázi vozů a intermodálních jednotek a v referenčních databázích kolejových vozidel jsou dostupné základní informace. Lze provádět manuální aktualizaci příslušných údajů. Výhoda:   Je zajištěna IT podpora pro žádost o trasu a pro řazení vlaku.   Třetí strany, např. správci vozového parku, mají snadný přístup k údajům o kolejových vozidlech.

Krok 3: Současně s krokem 2 nebo krátce po něm musí být realizováno a uplatněno společné rozhraní umožňující přístup k jednotlivým databázím zvnějšku.

Vlastnosti dostupné po tomto kroku pro
PI	ŽP
Je připravena databáze pro uchovávání informací o trasách/vlacích. Zadávání dat může začít manuálně. Je k dispozici online spojení s existujícími systémy PI, které umožňuje automatické zadávání a aktualizaci. Výhoda:   Údaje z příchozích zpráv mohou být uchovávány jako v konečné verzi.	Jsou připraveny databáze pro pohyb vozů/intermodálních jednotek a náklad (hmotnost, nebezpečné věci), společně s potřebnými referenčními soubory. Od této chvíle mohou být příslušné údaje z dodaných nákladních listů (vozových příkazů) a/nebo z výkazů vozidel vlaku vyplňovány buď manuálně, nebo již automaticky přes interní napojení ŽP na existující systémy pro evidenci nákladních listů a řazení vlaků. Lze provádět kontrolu údajů o vozech s referenčními databázemi kolejových vozidel a porovnávat údaje o vlaku s údaji o infrastruktuře. Výhoda:   Podpora při seřazování vlaku.   Údaje z příchozích zpráv mohou být uchovávány jako v konečné verzi.

Pokud jde o další kroky, je důležité zmínit, že navrhovaná architektura umožňuje hladké zprovoznění jednotlivých funkcí potřebných pro splnění požadavku subsystému „Využití telematiky v nákladní dopravě“. Díky centrálnímu datovému skladu (metadata pro zprávy, adresář a orgán vydávající certifikáty) lze umožnit individuální výměnu údajů mezi dvěma partnery v závislosti na typu zprávy.

Krok 4: Žádosti o trasu lze implementovat nezávisle na dalších krocích, ale pro krok 6 je nezbytné, aby již měla každá trasa přiřazeno číselné označení.

Vlastnosti dostupné po tomto kroku pro
PI	ŽP
Automatické zadávání dat do databáze pro uchovávání informací o trasách/vlacích. Telematická podpora pro definici tras v kombinaci s databázemi informací o omezeních na infrastruktuře. Výhoda:   Rychlejší reakce na žádosti o trasy, lepší využívání tras s větší orientací na poptávku, vyšší spolehlivost údajů o vlastnostech tras (aktuální stav v databázích informací o omezeních na infrastruktuře), zlepšení využívání infrastruktury.	Možnost žádat o trasu i s malým časovým předstihem. Výhoda:   Lze žádat o trasy podle poptávky. Rychlejší reakce PI na žádosti o trasy, vyšší spolehlivost údajů o vlastnostech tras. Zkrácení doby oběhu vozů.

Krok 5: Vozové příkazy obsahují podkladové informace pro řazení vlaku, a proto by tyto zprávy měly být zprovozněny před krokem 6.

Vlastnosti dostupné po tomto kroku pro
PI	ŽP
Žádné další vlastnosti.	Automatické přebírání údajů z nákladních listů do databází zprovozněných v kroku 3. Automatické generování a zasílání vozových příkazů spolupracujícím železničním podnikům. Výhoda:   Rychlejší distribuce vozových příkazů, kratší manipulační doby ve výměnných místech.   Podpora pro používání mezinárodních prodejních/kupních smluv.

Krok 6: Dalším krokem je zprovoznění zpráv o řazení vlaku, jehož součástí je zpráva Řazení vlaku, která by měla být realizována jako první.

Vlastnosti dostupné po tomto kroku pro
PI	ŽP
Obdrží řazení vlaku s předstihem. Vyšší spolehlivost údajů. Jasné zaznamenání výchozího času, který je počátkem využívání trasy. Automatická aktualizace databáze pro uchovávání informací o trasách/vlacích. Výhoda:   Optimalizace využívání trasy, jasná odpovědnost ve výchozím čase.	Zasílání řazení vlaku převážně automatické, vysoká spolehlivost údajů, automatická aktualizace databáze zprovozněné v kroku 3. Výhoda:   Jasná odpovědnost ve výchozím čase pro službu PI, spolehlivé určení výchozího času pro vozy/dodávky.   Podpora snížení výdajů a nákladů prostřednictvím omezení evidence na hranicích.   Podpora urychlení zásilek prostřednictvím garantovaného přejímání vlaků na straně ŽP a PI   Podpora minimalizace rizik během předávky vozů.

Krok 7: Nejpozději před krokem 8 by měly být na úrovni ŽP realizovány funkce pro pohyb vozů Oznámení o připravenosti vozu k odsunu a o odjezdu vozu, Zpráva o příjezdu vozu do seřaďovacího nádraží, Zpráva o odjezdu vozu ze seřaďovacího nádraží, Oznámení o příjezdu vozu a Oznámení o příjezdu vozu do stanice určení/Potvrzení příjezdu vozu do stanice určení, společně s funkcí plánování přepravy.

Vlastnosti dostupné po tomto kroku pro
PI	ŽP
Žádné další vlastnosti.	Umožněna IT podpora pro plánování přepravy vozů a intermodálních jednotek. Systém je připraven počítat, zasílat a přijímat zprávy o pohybu vozů a přepravních jednotek. Výhoda:   První krok k umožnění sledování a vystopování vozů a zásilek v mezinárodním měřítku.

Krok 8: Pro další krok by měly být realizovány zprávy Jízda vlaku a Prognóza jízdy vlaku. S pomocí zprávy Prognóza jízdy vlaku lze zaslat předpokládanou dobu příjezdu (TETA resp. ETH), která je základem pro výpočet ETI a ETA pro vozy/zásilky. Tento krok také zahrnuje realizaci dotazů/odpovědí ohledně jízdy vlaku a prognózy.

Vlastnosti dostupné po tomto kroku pro
PI	ŽP
Zprávy Jízda vlaku a Prognóza jízdy vlaku mohou být zasílány v reálném čase sousedním PI a ŽP. Výhoda:   Možnost lepšího a spolehlivějšího plánování, které umožňuje efektivnější využívání tras.   Zkrácení zastávek na hranicích, podpora využívání tras na základě poptávky.	K dispozici jsou údaje o poloze vlaku a předpokládaném čase vlaku, které tvoří základ pro výpočet ETI/ETA pro vůz/zásilku. Výhoda:   Nástroj, který je schopen vyhovět přání zákazníka být informován, nastanou-li během přepravy problémy.   Společně se završením kroku 4 napomáhá minimalizaci výdajů a nákladů prostřednictvím využívání tras podle poptávky.   Možnost lepšího a spolehlivějšího plánování.   Urychlení zásilek prostřednictvím zkrácení zastávek na hranicích.   Přispění k minimalizaci rizik během předávek vlaků.

Krok 9: Současně s krokem 8 nebo krátce po něm by mělo být zprovozněno vykazování výměn (kapitola 4.2.9:) a funkce popisované v kapitole 4.2.7 . To je důležité zejména pro železniční podniky.

Vlastnosti dostupné po tomto kroku pro
PI	ŽP
Znalost, kde přesně se nachází vůz na infrastruktuře PI a který ŽP je za něj odpovědný, dokonce i když vůz není zapojen ve vlaku. Výhoda:   Znalost polohy vozu a subjektu odpovědného na seřaďovacím nádraží.	Výpočet ETI a ETA na základě hodnot TETA, automatická aktualizace pohybových údajů v provozní databázi vozů a intermodálních jednotek. Plně realizován mezinárodní management prázdných vozů. Dokončeno mezinárodní plánování přepravy. Výhoda:   Možnost sledování a vystopování zásilek v mezinárodním měřítku.   Urychlení obrátek vozů.   Podpora pro mezinárodní management prázdných vozů.   Podpora pro zásilky do zahraničí a rezervace nabízených služeb.   Umožnění zlepšení kvality mezinárodní dopravy.   Podpora pro mezinárodní plánování přepravy.

Krok 10: Krok 10 zahrnuje zprovoznění funkce „informací v případě narušení provozu“ a realizaci dotazů/odpovědí ohledně zpoždění vlaku, identifikátoru vlaku a vlaku v místě hlášení. Na základě informací o narušení provozu by mohla být zprovozněna zpráva o vozové mimořádnosti na úrovni ŽP (kapitola 4.2.8.6: vozové mimořádnosti a kapitola 4.2.8.7:).

Vlastnosti dostupné po tomto kroku pro
PI	ŽP
Zvládání narušení a podávání zbývajících zpráv pro železniční podniky. Výhoda:   Zlepšení kvality služby.	Zvládání výjimek a zbývajících dotazů. Výhoda:   Možnost sledování a vystopování dodávek v mezinárodním měřítku.   Urychlení obrátek vozů.

Krok 11: Po fázi konsolidace by mohlo být zavedeno vyhodnocování předávaných a uchovávaných dat pro účely zlepšování kvality.

Vlastnosti dostupné po tomto kroku pro
PI	ŽP
Dostupnost vyčerpávající statistické databáze. Výhoda:   Poskytování vstupních dat pro zlepšení kvality dopravní služby.

7.3   Řízení změn

7.3.1   Úvod

Změna je běžnou stránkou všech počítačových systémů používaných v reálném světě. Dávají k ní podnět nové požadavky nebo změny existujících požadavků v důsledku chyb zaznamenaných v provozu nebo potřeba zlepšit výkon či funkční vady.

Změna však musí být řízená, neboť při ní musí být zaručena kontinuita služeb a zpětná kompatibilita, aby si vyžádala minimální čas a zatížila provoz stávajícího IT vybavení zajišťujícího funkce TAF co nejmenšími režijními náklady. Je proto nezbytné stanovit jasnou strategii, jak zavést a řídit změnu stávajícího IT vybavení, aby se zabránilo narušení železničního provozu a ohrožení kontinuity služeb a interoperability. Stanovení takové strategie se opírá o dva stěžejní aspekty:

—	vytvoření obecného rámce pro řízení konfigurace, který stanoví standardy a postupy pro řízení vývoje systému. Tento rámec by měl zahrnovat to, jak evidovat a provést navrhované změny systému, jak vztáhnout tyto změny ke komponentům systému a jak sledovat verze systému,

—	politika pro určování základních vývojových úrovní.

7.3.2   Stanovování základních vývojových úrovní

Základním předpokladem pro to, aby uplatňování a zavedení systému mohlo být realistické, je stabilita systému. Tato potřeba stability se týká všech stran:

—	provozovatelů infrastruktury a železničních podniků, které se budou muset umět vypořádat s různými verzemi systémů poskytujících funkce TAF,

—	odvětví, které potřebuje čas, aby mohlo stanovit, vyvinout a projevit trvalou interoperabilitu.

Základní vývojová úroveň v podstatě představuje stabilní jádro, pokud jde o funkčnost, výkon a jiné nefunkční charakteristiky (např. RAM) (9). Zkušenosti se systémy tohoto typu z minulosti však ukazují, že pro dosažení stabilní základní vývojové úrovně vhodné pro implementaci je zapotřebí vydání několika verzí (10). Tento poznatek lze znázornit jako takovýto stupňovitý proces:

Tento proces je díky zpětným smyčkám hodně propletený. Dílčí procesy proto nemohou probíhat souběžně, to by vedlo k nestabilním a zmatečným situacím, které by narušovaly provoz. Základní vývojové úrovně se proto musí vypracovávat postupně, nikoli souběžně, jak je ukázáno v následujícím schématu:

7.3.3   Zveřejňování základních vývojových úrovní

Podle současných zkušeností lze odhadnout časový odstup mezi dvěma základními vývojovými úrovněmi na cca čtyři až pět let.

Každá nová základní vývojová úroveň by měla být v zásadě vázána na významné změny funkčnosti nebo výkonu systému. Může jít kupříkladu o:

—	zapracování souboru dnešních vnitrostátních funkcí nějaké země, které lze zevšeobecnit, do interoperabilního jádra,

—	jiné budoucí služby poskytující přidanou hodnotu.

Každá základní vývojová úroveň by měla zahrnovat i funkce předchozí úrovně. Dolaďovací verze, které napravují vady systému nebo bezpečnostní nedostatky, by měly být řešeny jako nové verze téže základní vývojové úrovně. Nebrání-li tomu bezpečnostní důsledky, musí být takové nové verze téže základní vývojové úrovně zpětně kompatibilní.

Rozšíření funkcí v dalších základních vývojových úrovních má nutně za následek, že jednotlivé základní vývojové úrovně nejsou zpětně kompatibilní. Aby se však co možná nejvíce usnadnil přechod mezi jednotlivými základními vývojovými úrovněmi a jeho technické řešení, měly by jednotlivé základní vývojové úrovně obsahovat společné jádro funkcí, u nichž by měla být zpětná kompatibilita zaručena. Toto společné jádro by mělo představovat minimální základ umožňující interoperabilní datové služby s přijatelným výkonem.

7.3.4   Zavádění nových základních vývojových úrovní

Provozovatelé infrastruktury a železniční podniky nikdy nebudou schopni přejít z jedné základní vývojové úrovně na jinou přes noc. Každá základní vývojová úroveň proto musí být vyvíjena ruku v ruce s vhodnou strategií přechodu na ni. Tato strategie musí řešit takové problémy, jako je současná existence TAF zařízení kompatibilních s různými verzemi specifikací TAF, upřednostňované pořadí přechodu (např. napřed traťová zařízení, napřed kolejová vozidla nebo současně) a též přibližné časové horizonty a priority pro přechod.

7.3.5   Proces řízení změn – požadavky

Jak již bylo řečeno, změna je pro velké softwarové systémy osudem. Proto by měly být postupy řízení změn navrženy tak, aby zajistily, že budou náležitě zanalyzovány náklady a přínosy změny a že změny budou zavedeny kontrolovaným způsobem. To vyžaduje přesně vymezený proces řízení změn a související nástroje, které zajistí, aby změny byly efektivně evidovány a náležitě zohledňovaly specifikace. Bez ohledu na konečné konkrétní detaily by měl být proces řízení změn zhruba založen na tomto přístupu:

Celý proces řízení změn popsaný výše by se měl opírat o plán řízení konfigurace obsahující soubor standardů a postupů pro řízení změn. Obecné požadavky na takový plán jsou popsány v odstavci 7.3.6 níže. Strategie zavedení schválených změn by měla být formálně rozpracována (na základě náležitého postupu a dokumentace) do podoby plánu řízení změn, který zahrnuje zejména:

—	identifikaci technických překážek, o něž se změna opírá,

—	určení odpovědnosti za postupy související se zavedením změny,

—	postup pro potvrzení změn, které mají být zavedeny,

—	politiku řízení, zveřejnění, přechodu a zavádění změn.

Jednou z důležitých součástí procesu řízení změn je určení odpovědnosti za stanovení specifikací a za zabezpečení jakosti změn a řízení konfigurace. Počítá se s tím, že většina těchto úkolů bude svěřena Evropské železniční agentuře (zřízené nařízením ES č. 881/2004), až agentura zahájí provoz, nebo pod dohled této agentury. Proces řízení změn by měl být formálně popsán v dokumentech stanovených v příloze A.

Nakonec je nezbytné zajistit, aby výbor pro kontrolu změny (Change Control Board, CCB), který by měl působit jako komplexní systémový orgán, byl složen z reprezentativního průřezu všemi zainteresovanými stranami – tj. provozovateli infrastruktury, železničními podniky, stranou nabídky, oznámenými subjekty i regulačními orgány. Toto spojení různých stran by mělo zajistit dostatečně široký pohled na připravované změny a komplexní posuzování jejich dopadů. Funkce CCB bude posléze svěřena pod záštitu Evropské železniční agentury.

7.3.6   Plán řízení konfigurace – požadavky

Plán řízení konfigurace by měl popisovat soubor standardů a postupů pro řízení změn a měl by obsahovat zejména:

—	definici subjektů, které je třeba řídit, a formální plán pro identifikaci těchto subjektů,

—	určení odpovědnosti za postupy spojené s řízením konfigurace a za podřízení kontrolovaných subjektů rozhodovací struktuře pro oblast řízení konfigurace,

—	politiku řízení konfigurace, kterou je třeba použít pro udržení kontroly nad změnou a pro správu verzí,

—	popis záznamů, které by měly být vedeny o procesu řízení konfigurace,

—	popis nástrojů, které by měly být použity k řízení konfigurace, a postupu, který by měl být při použití těchto nástrojů uplatněn,

—	definici databáze konfigurací, ve které se budou evidovat informace o konfiguraci.

Konkrétní podrobnosti o postupech řízení konfigurace musejí být stanoveny prostřednictvím specifikací zahrnutých v seznamu specifikací uvedených v příloze A této TSI.

7.4   Zvláštní případy

7.4.1   Úvod

Následující zvláštní ustanovení jsou povolena v níže uvedených zvláštních případech.

Tyto zvláštní případy spadají do dvou kategorií: ustanovení se použijí buď trvale (případ „P“), nebo dočasně (případ „T“). V dočasných případech je doporučeno, že by dotyčné členské státy měly dosáhnout shody s příslušným subsystémem buď do roku 2010 (případ „T1“), což je cíl stanovený v rozhodnutí Evropského parlamentu a Rady č. 1692/96/ES ze dne 23. července 1996 o hlavních směrech Společenství pro rozvoj transevropské dopravní sítě (11), nebo do roku 2020 (případ „T2“). Případ „T open“ je definován jako nespecifikované období, které bude stanoveno v některé z dalších verzí této TSI.

7.4.2   Seznam zvláštních případů

7.4.2.1   Zvláštní případ pro členské státy EU, které hraničí s třetími zeměmi

Na územích členských států EU, které hraničí s třetími zeměmi, nejsou požadavky této TSI závazné pro přepravu, která přijíždí přímo z těchto třetích zemí nebo jede přímo do těchto třetích zemí (případ „T open“).

Zasáhne-li však dopravní jízda do jiného členského státu EU, musí se požadavky této TSI plně použít, není-li mezi dotyčnými státy nebo mezi železniční podniky či provozovateli infrastruktury působícími na území těchto členských států uzavřena jiná bilaterální nebo multilaterální dohoda.

7.4.2.2   Zvláštní případ pro Řecko

Na dopravní jízdu provozovanou na tratích s rozchodem 1 000 mm se použijí vnitrostátní předpisy.

---

(1)  Úř. věst. L 75, 15.3.2001, s. 29. Směrnice naposledy pozměněná směrnicí 2004/49/ES (Úř. věst. L 164, 30.4.2004, s. 44; opraveno v Úř. věst. L 220, 21.6.2004, s. 16).

(2)  Úř. věst. L 220,30.8.1993, s. 23.

(3)  Úř. věst. L 75, 15.3.2001, s. 26.

(4)  Úř. věst. L 237, 24.8.1991, s. 25. Směrnice naposledy pozměněná směrnicí Evropského parlamentu a Rady 2004/51/ES (Úř. věst. L 164, 30.4.2004., s. 164, opraveno v Úř. věst. L 220, 21.6.2004, s. 58).

(5)  Pojmem výchozí bod se rozumí počáteční bod trasy, kterým může být místo odjezdu vlaku na cestu, nebo výměnné místo. Místo předávky je konečným bodem trasy.

(6)  Tj. přístup k těmto informacím musí být nezávislý na tom, který PI uložil informace nebo jejich část.

(7)  Např. standardy zabezpečení jakosti, metodologie vývoje systému, metodologie testování, rozvržení dokumentace.

(8)  Stávajícím využitím telematiky v nákladní dopravě se rozumí využití telematiky v nákladní dopravě, které bylo zavedeno do praxe již před vstupem této TSI v platnost.

(9)  Základní vývojová úroveň funguje jako referenční výchozí bod pro kontrolované řízení vývoje systému.

(10)  Vydanou verzí se rozumí verze systému, která je distribuována železničním zákazníkům. Verze systému mohou mít různé funkce a různý výkon nebo mohou opravovat vady systému nebo nedostatky v bezpečnosti či zabezpečení.

(11)  Úř. věst. L 228, 9.9.1996, s. 1. Rozhodnutí naposledy pozměněné rozhodnutím č. 884/2004/ES (Úř. věst. L 167, 30.4.2004, s. 1; opraveno v Úř. věst. L 201, 7.6.2004, s. 1).