12.12.2014   

BG

Официален вестник на Европейския съюз

L 356/438

РЕГЛАМЕНТ (ЕС) № 1305/2014 НА КОМИСИЯТА

от 11 декември 2014 година

относно техническата спецификация за оперативна съвместимост по отношение на подсистемата „Телематични приложения за товарни превози“ на железопътната система на Европейския съюз и за отмяна на Регламент (ЕС) № 62/2006

(текст от значение за ЕИП)

ЕВРОПЕЙСКАТА КОМИСИЯ,

като взе предвид Договора за функционирането на Европейския съюз,

като взе предвид Директива 2008/57/ЕО на Европейския парламент и на Съвета от 17 юни 2008 г. относно оперативната съвместимост на железопътната система в рамките на Общността (1), и по-специално член 6, параграф 1 от нея,

като има предвид, че:

(1)

Съгласно член 2, буква д) от Директива 2008/57/ЕО, железопътната система се подразделя на структурни и функционални подсистеми. За всяка една от подсистемите следва да има техническа спецификация за оперативна съвместимост (ТСОС).

(2)

С Регламент (ЕО) № 62/2006 на Комисията (2) бяха въведени технически спецификации за оперативна съвместимост, отнасящи се за телематичните приложения в подсистемата за товарни превози на трансевропейската железопътна система.

(3)

През 2010 г. Европейската железопътна агенция (наричана тук „Агенцията“) получи мандат да преразгледа техническите спецификации за оперативна съвместимост (ТСОС) за подсистемата„Телематични приложения за товарни превози“ (ТПТП) в съответствие с член 6, параграф 1 от Директива 2008/57/ЕО.

(4)

На 10 декември 2013 г. Агенцията издаде препоръка ERA/REC/106 — 2013/REC за актуализация на приложение А към Регламент (ЕО) № 62/2006.

(5)

ТСОС ТПТП не следва да налага използването на специфични технологии или технически решения, с изключение на случаите, в които това е необходимо за осигуряване на оперативната съвместимост на европейската железопътна система.

(6)

Представителните органи от железопътния сектор са съставили генерален план за прилагането на ТСОС ТПТП. В този генерален план са посочени етапите, необходими за преминаване от фрагментарен национален подход към безпрепятствен информационен обмен в рамките на европейската железопътна система.

(7)

ТСОС ТПТП се основава на най-добрите налични експертни познания. При все това, развитията в техническата и експлоатационната област биха могли да породят необходимост от допълнителни изменения в настоящата ТСОС ТПТП. За тази цел следва да бъде подготвена процедура за управление на измененията, която да се използва за консолидиране и актуализиране на разпоредбите на ТСОС ТПТП.

(8)

Всички действащи лица, особено малките оператори в областта на товарните превози, които не членуват в представителните органи на европейския железопътен сектор, следва да бъдат информирани за техните задължения във връзка с ТСОС ТПТП.

(9)

Поради горепосочените причини Регламент (EО) № 62/2006 следва да бъде отменен.

(10)

Мерките, предвидени в настоящия регламент, са в съответствие със становището на Комитета, учреден съгласно член 29, параграф 1 от Директива 2008/57/ЕО,

ПРИЕ НАСТОЯЩИЯ РЕГЛАМЕНТ:

Член 1

Предмет

С настоящото се приема техническата спецификация за оперативна съвместимост (ТСОС) за подсистемата „Телематични приложения за товарни превози“ на европейската железопътна система, както е определена в приложението.

Член 2

Обхват

1.   Техническата спецификация за оперативна съвместимост се отнася за подсистемата „Телематични приложения“ на железопътната система в Европейския съюз, както е определена в точка 2.6, буква б) от приложение II към Директива 2008/57/ЕО.

2.   Техническата спецификация за оперативна съвместимост се отнася за следните мрежи:

а)

мрежата на трансевропейската конвенционална железопътна система, както е определена в приложение I, раздел 1.1 от Директива 2008/57/ЕО;

б)

мрежата на трансевропейската железопътна система за високоскоростни влакове, както е описана в раздел 2.1 от приложение I към Директива 2008/57/ЕО;

в)

други части на мрежата на железопътната система в ЕС.

В Техническата спецификация за оперативна съвместимост не са включени случаите, посочени в член 1, параграф 3 от Директива 2008/57/ЕО.

3.   Техническата спецификация за оперативна съвместимост се отнася за мрежи със следните номинални междурелсия: 1 435 mm, 1 520 mm, 1 524 mm, 1 600 mm и 1 668 mm.

Член 3

Актуализиране и докладване на технически документи

Агенцията трябва да осигурява достъп посредством своята интернет страница до кодовете за местоположение (Location codes) и кодовете на железопътните предприятия (Company codes), посочени в точка 4.2.11.1, букви б) и г), както и до техническите документи, посочени в раздел 7.2 от приложението и трябва да докладва на Комисията за напредъка при тяхното разработване.

Комисията ще информира държавите членки за този напредък чрез Комитета, създаден съгласно член 29, параграф 1 от Директива 2008/57/ЕО.

Член 4

Спазване на изискванията във връзка с мрежи в държави извън ЕС

По отношение на услугите за товарни железопътни превози, осъществявани от или до трети държави, условие за спазването на изискванията по ТСОС, както е определена в приложението, е наличието на информация от съответните организации извън ЕС, освен ако посредством двустранни споразумения е осигурен съвместим с настоящата ТСОС информационен обмен.

Член 5

Изпълнение

1.   Агенцията трябва да оцени и да осъществи надзор върху въвеждането в изпълнение на настоящия регламент, с цел да определи дали са постигнати определените цели и срокове, и трябва да подаде доклад за оценка до Управляващия комитет за телематичните приложения за товарни превози, посочен в раздел 7.1.4 от приложението.

2.   Управляващият комитет за телематичните приложения за товарни превози трябва да оцени въвеждането в изпълнение на настоящия регламент въз основа на подадения от Агенцията доклад за оценка и да приеме съответни решения за по-нататъшни действия от страна на сектора.

3.   Държавите членки трябва да осигурят информираност за настоящия регламент на всички железопътни предприятия, управители на инфраструктури и ползватели на железопътни вагони, които са установени на тяхна територия, и да определят национален център за контакти за неговото прилагане, както е описано в допълнение III.

4.   Държавите членки трябва в срок до 31 декември 2018 г. да изпратят на Комисията доклад за изпълнението на настоящия регламент. Този доклад ще бъде обсъден в Комитета, учреден съгласно член 29, параграф 1 от Директива 2008/57/ЕО. В съответните случаи, при които това е уместно, техническата спецификация за оперативна съвместимост, формулирана в приложението към настоящия регламент, ще бъде актуализирана.

Член 6

Отмяна

Регламент (ЕО) № 62/2006 се отменя от деня на влизане в сила на настоящия регламент.

Член 7

Влизане в сила и прилагане

Настоящият регламент влиза в сила на двадесетия ден след деня на публикуването му в Официален вестник на Европейския съюз.

Прилага се от 1 януари 2015 г.

Настоящият регламент е задължителен в своята цялост и се прилага пряко във всички държави членки.

Съставено в Брюксел на 11 декември 2014 година.

За Комисията

Председател

Jean-Claude JUNCKER

(1)  ОВ L 191, 18.7.2008 г., стр. 1.

(2)  Регламент (ЕО) № 62/2006 на Комисията от 23 декември 2005 г. относно техническата спецификация за оперативната съвместимост на подсистемата „Телематични приложения за превоз на товари“ на Трансевропейската конвенционална железопътна система(ОВ L 13, 18.1.2006 г., стр. 1).

ПРИЛОЖЕНИЕ

СЪДЪРЖАНИЕ

1.

 ВЪВЕДЕНИЕ 443

1.1.

 Съкращения 443

1.2.

 Цитирани документи 444

1.3.

 Технически обхват 445

1.4.

 Географски обхват 445

1.5.

 Съдържание на настоящата ТСОС ТПТП 445

2.

 ДЕФИНИРАНЕ НА ПОДСИСТЕМАТА И ОБХВАТА 446

2.1.

 Функции, влизащи в обхвата на настоящата ТСОС 446

2.2.

 Функции извън обхвата на ТСОС 446

2.3.

 Общо описание на подсистемата 446

2.3.1.

 Участващи стопански субекти 446

2.3.2.

 Разгледани процедури 448

2.3.3.

 Общи бележки 449

3.

 СЪЩЕСТВЕНИ ИЗИСКВАНИЯ 450

3.1.

 Съответствие със съществените изисквания 450

3.2.

 Аспекти на съществените изисквания 450

3.3.

 Аспекти, свързани с изискванията от общ характер 451

3.3.1.

 Безопасност 451

3.3.2.

 Надеждност и разполагаемост 451

3.3.3.

 Здравеопазване 451

3.3.4.

 Защита на околната среда 451

3.3.5.

 Техническа съвместимост 451

3.4.

 Аспекти, отнасящи се специално за подсистемата „Телематични приложения за товарни превози“ 451

3.4.1.

 Техническа съвместимост 451

3.4.2.

 Надеждност и разполагаемост 451

3.4.3.

 Здраве 452

3.4.4.

 Безопасност 452

4.

 ОПРЕДЕЛЯНЕ НА ХАРАКТЕРИСТИКИТЕ НА ПОДСИСТЕМАТА 452

4.1.

 Въведение 452

4.2.

 Функционални и технически спецификации на подсистемата 452

4.2.1.

 Данни в товарителницата 453

4.2.2.

 Заявка за маршрут 454

4.2.3.

 Подготовка на влак 455

4.2.4.

 Прогноза за движението на влака 456

4.2.5.

 Информация за смущение в превоза 457

4.2.6.

 ОЧПР/ОЧП (очаквани часове на прехвърляне/очакван час на пристигане) на товара 458

4.2.7.

 Движение на вагоните 459

4.2.8.

 Отчитане на прехвърляне 460

4.2.9.

 Обмен на данни за подобряване на качеството 461

4.2.10.

 Основните справочни данни 462

4.2.11.

 Разни справочни файлове и бази данни 463

4.2.12.

 Работа в мрежа и комуникации 466

4.3.

 Функционални и технически спецификации на интерфейсите 468

4.3.1.

 Интерфейси с ТСОС „Инфраструктура“ 468

4.3.2.

 Интерфейси с ТСОС „Контрол/управление и сигнализация“ 468

4.3.3.

 Интерфейси с подсистема „Подвижен състав“ 468

4.3.4.

 Интерфейси с ТСОС „Експлоатация и управление на трафика“ 468

4.3.5.

 Интерфейси с подсистемата „Телематични приложения за пътнически превози“ 469

4.4.

 Правила за експлоатация 469

4.4.1.

 Качество на данните 469

4.4.2.

 Управление на централния архив 471

4.5.

 Правила за поддръжка 471

4.6.

 Професионални квалификации 471

4.7.

 Здравословни и безопасни условия 471

5.

 СЪСТАВНИ ЕЛЕМЕНТИ НА ОПЕРАТИВНАТА СЪВМЕСТИМОСТ 471

5.1.

 Определение 471

5.2.

 Списък на съставните елементи 471

5.3.

 Работни показатели и спецификации на съставните елементи 472

6.

 ОЦЕНКА НА СЪОТВЕТСТВИЕТО И/ИЛИ ГОДНОСТТА ЗА ИЗПОЛЗВАНЕ НА СЪСТАВНИТЕ ЕЛЕМЕНТИ И ПРОВЕРКА НА ПОДСИСТЕМАТА 472

6.1.

 Елементи на оперативна съвместимост 472

6.1.1.

 Процедури за оценка 472

6.1.2.

 Модул 472

6.1.3.

 Подсистема „Телематични приложения за товарни превози“ 472

7.

 ПРИЛАГАНЕ 473

7.1.

 Изисквания относно прилагането на настоящата ТСОС 473

7.1.1.

 Въведение 473

7.1.2.

 Първи етап — подробни ИТ спецификации и генерален план, 473

7.1.3.

 Етап 2 и 3– Разработване и внедряване 473

7.1.4.

 Управление, роли и отговорности 473

7.2.

 Управление на измененията 475

7.2.1.

 Процедура за управление на измененията 475

7.2.2.

 Специфична процедура за управление на измененията в документи, изброени в допълнение I към настоящия регламент 475

Допълнение I:

 Списък на техническите документи 476

Допълнение II:

 Терминологичен речник 477

Допълнение III:

 Задачи на Националния център за контакти (НЦК) по телематичните приложения за пътнически и за товарни превози (ТППП/ТПТП) 488

1.   ВЪВЕДЕНИЕ

1.1.   Съкращения

Таблица 1

Съкращения

Съкращение

Цялостно наименование

ANSI

Американски национален институт за стандартизация

ОИ

Общ интерфейс

ИП

Искане за промяна

ЕК

Европейска комисия

ЕЖА

Европейска железопътна агенция (наричана също и Агенцията)

ERTMS

Европейска система за управление на железопътното движение

ETCS

Европейска система за контрол на влаковете

УИ

Управител на инфраструктура

ISO

Международна организация по стандартизация

LAN

Локална мрежа

LCL

Частично натоварване на контейнери

ВЖПП

Водещо железопътно предприятие

ONC

Open Network Computing (изчисления в отворена компютърна мрежа)

OTIF

Междуправителствена организация за международни железопътни превози

PVC

Permanent Virtual Circuit (постоянна виртуална верига)

RISC

Комитет по оперативна съвместимост и безопасност на железопътната система

ЖПП

Железопътно предприятие

ТПТП

Телематични приложения за товарни превози

ТППП

Телематични приложения за пътнически превози

TCP/IP

Transmission Control Protocol (мрежов протокол за управление на предаването на данни)/Internet Protocol (използван в Интернет протокол)

TEN

Трансевропейска мрежа

ТСОС

Технически спецификации за оперативна съвместимост

WK

Ползватели на вагони

WP

Работна група, организирана от ЕЖА

1.2.   Цитирани документи

Таблица 2

Цитирани документи

№

Означение на документа

Заглавие

Последно издание

[1]

Директива 2008/57/ЕО

Директива 2008/57/ЕО на Европейския парламент и на Съвета от 17 юни 2008 г. относно оперативната съвместимост на железопътната система в рамките на Общността (ОВ L 191, 18.7.2008 г., стр. 1)

17.6.2008 г.

[2]

Регламента за ТСОС ТППП — Регламент (ЕС) № 454/2011

Регламент (ЕС) № 454/2011 на Комисията от 5 май 2011 г. относно техническата спецификация за оперативна съвместимост на подсистемата „Телематични приложения за пътнически услуги“ на трансевропейската железопътна система (ОВ L 123, 12.5.2011 г., стр. 11)

5.5.2011 г.

[3]

Директива 2012/34/EC

Директива 2012/34/ЕС на Европейския парламент и на Съвета от 21 ноември 2012 г. за създаване на единно европейско железопътно пространство (ОВ L 343, 14.12.2012 г., стр. 32)

21.11.2012 г.

[4]

ERA-TD-105

ТСОС ТППТ — ПРИЛОЖЕНИЕ Г.2: ДОПЪЛНЕНИЕ Е — МОДЕЛ НА ДАННИ И СЪОБЩЕНИЯ В ТСОС ТПТП

22.3.2013 г.

[5]

Регламента за ТСОС ТПТП — Регламент (ЕС) № 62/2006

Регламент (ЕО) № 62/2006 от 23 декември 2005 г. на Комисията относно техническата спецификация за оперативната съвместимост на подсистемата „Телематични приложения за превоз на товари“ на Трансевропейската конвенционална железопътна система (ОВ L 13, 18.1.2006 г., стр. 1)

18.1.2006 г.

[6]

Регламент (ЕС) № 280/2013 на Комисията

Регламент (ЕС) № 280/2013 на Комисията от 22 март 2013 г. за изменение на Регламент (ЕО) № 62/2006 относно техническата спецификация за оперативната съвместимост на подсистемата „Телематични приложения за превоз на товари“ на Трансевропейската конвенционална железопътна система (ОВ L 84, 23.3.2013 г., стр. 17)

22.3.2013 г.

[7]

Регламент (ЕС) № 328/2012 на Комисията

Регламент (ЕС) № 328/2012 на Комисията от 17 април 2012 г. за изменение на Регламент (ЕО) № 62/2006 относно техническата спецификация за оперативната съвместимост на подсистемата „Телематични приложения за превоз на товари“ на Трансевропейската конвенционална железопътна система (ОВ L 106, 18.4.2014 г., стр. 14)

17.4.2012 г.

[8]

C(2010) 2576 окончателен

Решение на Комисията от 29 април 2010 г. относно мандат за Европейската железопътна агенция да разработва и преразглежда техническите спецификации за оперативна съвместимост с цел разширяване на техния обхват за цялата железопътна система в Европейския съюз

29.4.2010 г.

[9]

Директива 2004/49/ЕО

Директива 2004/49/ЕО на Европейския парламент и на Съвета от 29 април 2004 г. относно безопасността на железопътния транспорт в Общността и за изменение на Директива 95/18/ЕО на Съвета относно лицензирането на железопътните предприятия и Директива 2001/14/ЕО относно разпределяне на капацитета на железопътната инфраструктура и събиране на такси за ползване на железопътната инфраструктура и за сертифициране за безопасност (Директива относно безопасността на железопътния транспорт) (ОВ L 164, 30.4.2004 г., стр. 44)

28.11.2009 г.

[10]

Директива 2001/13/ЕО

Директива 2001/13/ЕО на Европейския парламент и на Съвета от 26 февруари 2001 г. за изменение на Директива 95/18/ЕО на Съвета относно лицензиране на железопътните предприятия (ОВ L 75, 15.3.2001 г., стр. 26)

26.2.2001 г.

1.3.   Технически обхват

Настоящата техническа спецификация за оперативна съвместимост (наричана по-долу ТСОС ТПТП) се отнася за елемента „Приложения за товарни услуги“ на подсистемата „Телематични приложения“, включен във функционалната област на списъка в приложение II към Директива 2008/57/ЕО [1].

Предназначението на настоящата ТСОС ТПТП е да се осигури ефективен обмен на информация чрез задаването на съответна техническа рамка, както и да се постигне възможно най-ефективен от икономическа гледна точка транспортен процес. Тя обхваща приложенията в областта на товарните транспортни услуги и управлението на връзките с други видове транспорт, което означава, че е насочена и към транспортните услуги на дадено железопътно предприятие, а не само към експлоатацията на влакове. Аспектите по безопасността са разгледани само във връзка с наличието на елементи от данни; сами по себе си, съответните стойности нямат въздействие върху безопасната експлоатация на даден влак и спазването на изискванията на ТСОС ТПТП не може да се счита за спазване на изисквания по безопасността.

ТСОС ТПТП оказва също така влияние върху условията на използване на железопътния транспорт от ползвателите. Във връзка с това понятието „ползвател“ означава не само управителите на инфраструктура или железопътните предприятия, но също така и всички доставчици на съответни услуги, като например производителите на вагони, операторите на интермодален транспорт и дори клиентите.

Техническият обхват на настоящата ТСОС е определен допълнително в член 2, параграф 1 и член 2, параграф 3 от настоящия регламент.

1.4.   Географски обхват

Географският обхват на настоящата ТСОС съответства на мрежата на цялостната железопътна система, която включва:

—

Мрежата на трансевропейската конвенционална железопътна система (TEN), както е описана в приложение I, раздел 1.1 „Мрежа“ от Директива 2008/57/ЕО [1].

—

Мрежата на трансевропейската високоскоростна железопътна система (TEN), както е описана в приложение I, точка 2.1 „Мрежа“ от Директива 2008/57/ЕО [1].

—

Други части на цялостната железопътна система, включени след разширението на обхвата, както е описано в приложение I, точка 4 от Директива 2008/57/ЕО [1].

Изключват се случаите, посочени в член 1, параграф 3 от Директива 2008/57/ЕО [1].

1.5.   Съдържание на настоящата ТСОС ТПТП

Съдържанието на настоящата ТСОС ТПТП е в съответствие с член 5 от Директива 2008/57/ЕО [1].

Също така, настоящата ТСОС включва в глава 4 (Определяне на характеристиките на подсистемата) специфичните изисквания относно експлоатацията и поддръжката, отнасящи се за обхвата, посочен съответно в параграф 1.1 (Технически обхват) и параграф 1.2 (Географски обхват).

2.   ДЕФИНИРАНЕ НА ПОДСИСТЕМАТА И ОБХВАТА

2.1.   Функции, влизащи в обхвата на настоящата ТСОС

Подсистемата „Телематични приложения за товарни превози“ е определена в приложение II към Директива 2008/57/ЕО [1], точка 2.5, буква б).

Тя включва по-специално:

—

Приложения за товарни превози, включително информационни системи (проследяване в реално време на товарите и влаковете),

—

Системи за разпределение и композиране, като в случая „системи за композиране“ означава системите за композиране на влаковете,

—

Системи за резервиране (в смисъл на резервиране на маршрути),

—

Управление на връзките с други видове транспорт и създаване на електронни придружаващи документи.

2.2.   Функции извън обхвата на ТСОС

Обхватът на настоящата ТСОС не обхваща системите за плащане и фактуриране, използвани по отношение на клиентите, нито тези, които се прилагат между различните доставчици на услуги, като например железопътните предприятия или управителите на инфраструктура. При все това, системата за обмен на информация съгласно глава 4.2 (Функционални и технически спецификации на подсистемата) е разработена по такъв начин, че да предоставя необходимата информация за плащанията, произтичащи от транспортните услуги.

Дългосрочното планиране на разписанията също е извън обхвата на настоящата ТСОС за телематичните приложения. От друга страна, на някои места е споменат резултатът от дългосрочното планиране, доколкото той е свързан с ефективния обмен на информация, необходим за движението на влаковете.

2.3.   Общо описание на подсистемата

2.3.1.   Участващи стопански субекти

Настоящата ТСОС взема предвид настоящите и различни потенциални бъдещи доставчици на услуги, участващи в превоза на товари, по-специално посредством (списъкът не е изчерпателен):

—

Вагони

—

Локомотиви

—

Машинисти

—

Стрелки и разпределителни гърбици

—

Продажба на часови интервали

—

Управление на товарите

—

Композиране на влаковете

—

Експлоатация на влаковете

—

Мониторинг на движението на влаковете

—

Управление на движението на влаковете

—

Мониторинг на пратките

—

Инспекции и ремонт на вагоните и/или локомотивите

—

Освобождаване на товари от митниците

—

Експлоатация на интермодални терминали

—

Осигуряване на автомобилно извозване.

Някои доставчици на услуги са изрично дефинирани в Директиви 2012/34/ЕС [3], 2008/57/EО [1] и 2004/49/ЕО [9]. Тъй като тези директиви трябва да бъдат взети под внимание, настоящата ТСОС е съобразена по-специално със с дефинициите на:

 

Управител на инфраструктура (УИ) (Директива 2012/34/EС [3]) означава всяка организация или дружество, отговарящи по-специално за изграждането, управлението и поддръжката на железопътна инфраструктура, включително ръководството на движението и контрола, управлението и сигнализацията; функциите на управител на инфраструктурата на дадена мрежа или част от мрежа могат да бъдат поверени на различни органи или дружества. Когато управителят на инфраструктура не е независим от железопътни предприятия по отношение на юридическата си форма, организация или функции по вземане на решения, функциите, посочени в глава IV, раздели 2 и 3, се изпълняват съответно от начисляващ таксите орган и от разпределящ орган, които са независими по отношение на юридическата си форма, организация и вземане на решения от железопътните предприятия.

Въз основа на това определение в настоящата ТСОС управителят на инфраструктура се разглежда като доставчик на услуги, натоварен с предоставянето на маршрутите, управлението на движението и проследяването на влаковете, както и с докладването относно влаковете и маршрутите.

 

Заявител (съгласно Директива 2012/34/ЕС [3]) означава железопътно предприятие или международна група железопътни предприятия, или други лица или юридически лица, като например компетентни органи съгласно Регламент (ЕО) № 1370/2007 и товароизпращачи, спедитори и оператори на комбиниран транспорт, които си набавят инфраструктурен капацитет с цел осигуряване на обществена услуга или от търговски интерес;

 

Железопътно предприятие (съгласно Директива 2004/49/ЕО [9]) означава железопътно предприятие по смисъла на Директива 2001/14/ЕО, както и всяко друго публично или частно предприятие, чиято дейност се състои в осигуряване на железопътен превоз на товари и/или пътници, като предприятието осигурява теглителната сила; това включва и предприятия, които предоставят само теглителна сила;.

Въз основа на това определение настоящата ТСОС приема железопътното предприятие като доставчик на услуги за експлоатация на влаковете.

Що се отнася до предоставянето на маршрути, под внимание трябва да бъде взет също член 38 от Директива 2012/34/ЕС [3]:

Разпределянето на инфраструктурен капацитет се извършва от управителя на инфраструктура. Веднъж разпределен на един заявител, той не може да се прехвърля от получателя на друго предприятие или за друг вид услуги.

Всякакво търгуване с инфраструктурен капацитет е забранено и води до изключване от по-нататъшно разпределяне на капацитет.

Не се счита за прехвърляне използването на капацитет от дадено железопътно предприятие в случаите, когато извършва дейността на заявител, който не е железопътно предприятие.

Във връзка със сценариите за комуникация между управители на инфраструктура и заявители при режима на изпълнение на транспорт се вземат под внимание единствено управителите на инфраструктура (УИ) и железопътните предприятия (ЖПП), а не всички видове заявители, които могат да имат отношение към режима на планиране. При режима на изпълнение винаги се задава дефинирано взаимоотношение УИ — ЖПП, за което са специфицирани в настоящата ТСОС съответно обменът на съобщения и съхранението на информация. Това не оказва никакво влияние на определянето на кандидата, нито на възможностите за предоставяне на маршрути, които произтичат от него.

Товарният транспорт е свързан с предоставянето на различни видове услуги. Една такава услуга е например предоставянето на вагони. Тази услуга може да е свързана с управител на железопътен парк. Ако тази транспортна услуга е една от услугите, предлагани от ЖПП, то това ЖПП действа също като управител на железопътен парк. Управителят на железопътен парк може да стопанисва свои собствени вагони и/или вагони на друг ползвател (друг доставчик на услуги за предоставяне на товарни вагони). Нуждите на този вид доставчик също се вземат под внимание, независимо от това дали управителят на железопътния парк е ЖПП или не.

Настоящата ТСОС не създава нови юридически лица и не принуждава нито едно ЖПП да привлича външни доставчици на услуги за извършване на услугите, което то самото предлага, но в нея се назовава, когато е необходимо, даден вид услуга посредством названието на съответния неин доставчик. Ако услугата се предоставя от ЖПП, то действа като доставчик на тази услуга.

Когато поради съответни нужди на клиента една от услугите се състои в организирането и управляването на транспортната верига в съответствие с ангажиментите, поети по отношение на клиента, тази услуга се предоставя от водещото железопътно предприятие (водещо ЖПП или ВЖПП). ВЖПП е единствената точка за контакти за клиента. Ако транспортната верига включва участие на няколко железопътни предприятия, ВЖПП отговоря също така за координацията между тях.

Тази услуга може също така да бъде изпълнявана от спедитор или от всяка друга организация.

Ролята на едно ЖПП в качеството му на ВЖПП зависи от типа на транспортния поток. Що се отнася до интермодалната дейност, управлението на капацитета на маршрутните влакове и изготвянето на пътните листове се извършва от интегратор на интермодални услуги, който би могъл да бъде и клиент на ВЖПП.

Въпреки това е от първостепенно значение ЖПП, УИ и всички други доставчици на услуги (в посочения по-горе смисъл) да работят заедно, в сътрудничество и/или в режим на свободен достъп, както и посредством ефективен обмен на информация, с цел предоставянето на цялостни услуги на клиентите.

2.3.2.   Разгледани процедури

В съответствие с Директива 2008/57/ЕО [1], настоящата ТСОС относно железопътния товарен транспорт е насочена само към УИ и ЖПП/ВЖПП, във връзка с техните преки клиенти. ВЖПП трябва по съответно договорно споразумение да предоставя на клиентите следните видове информация:

—

Информация за маршрута.

—

Информация за движението на влаковете по договорени за докладване точки от маршрута, включващи като минимум точките на заминаване, на прехвърляне/предаване на влака и на пристигане в рамките на договорен транспорт.

—

Очакваният час на пристигане (ОЧП) в крайното местоназначение, включително разпределителни гари и интермодални терминали.

—

Прекъсване на превоза В случай, че водещото ЖПП научи за смущение в превоза, то трябва своевременно да я предаде на клиента.

Съответните съобразени с ТПТП съобщения за предаването на тази информация са дефинирани в глава 4.

В рамките на услугите по превоз на товари дейността на дадено водещо ЖПП започва с приемането на товарителницата, издадена от неговия клиент, и например ако се отнася до товарни вагони — от датата и часа на тяхното предоставяне на разположение. Водещото ЖПП изготвя предварителен пътен план (въз основа на своя опит и/или договор) за транспортното пътуване. Ако водещото ЖПП има намерение да разположи товарния вагон във влак с режим на свободен достъп (като експлоатира влака по време на цялото пътуване), то тогава предварителният пътен план е окончателен. Ако водещото ЖПП има намерение да разположи товарния вагон във влак, чиято експлоатация включва сътрудничество и с други ЖПП, водещото ЖПП трябва най-напред да установи с кои ЖПП следва да влезе в контакт и в кой момент от времето може да стане прехвърлянето между две последователни ЖПП. След това водещото ЖПП подготвя предварителни заявки за транспорт, поотделно за всяко ЖПП, като части от цялостната товарителница. Заявките за транспорт на вагони са описани в глава 4.2.1 (Данни в товарителниците).

ЖПП, с които е осъществен контакт, проверяват разполагаемостта на необходимия капацитет за експлоатация на вагоните и разполагаемостта на маршрута. Техните отговори дават възможност на водещото ЖПП да уточни своя пътен план или да направи отново запитване — като евентуално се обърне към други ЖПП — докато най-накрая този план започне да съответства на изискванията на клиента.

Най-общо ЖПП/ВЖПП трябва като минимум да имат способност да изпълняват следните дейности:

—

ДА ДЕФИНИРАТ услугите по отношение на тарифите и времето на транзитиране, осигуряването на вагони (в съответните случаи), информацията относно вагоните и интермодалните транспортни единици (местоположение, състояние и очаквания час на пристигане — наричан по-нататък „ОЧП“), мястото на натоварване на товарите на празни вагони, в контейнери и т. н.;

—

ДА ИЗПЪЛНЯВАТ дефинираната услуга по надежден и безпрепятствен начин, като използват общоприложими стопански процедури и свързани системи. ЖПП, УИ и останалите доставчици на услуги и участници, като например митниците, трябва да имат възможност да обменят информация по електронен път;

—

ДА ИЗМЕРВАТ качеството на предоставената услуга в сравнение с дефинираното, т.е. реално определени разходи спрямо обявената цена, реалните времена на транзитиране спрямо поетите ангажименти, поръчаните вагони спрямо осигурените, очакваните часове на пристигане спрямо реалните часове на пристигане;

—

ДА ЕКСПЛОАТИРАТ с висока продуктивност от гледна точка на неговото ползване влаковия, инфраструктурния и парковия капацитет, като прилага стопански процеси, системи и средства за обмен на данни, необходими за подпомагане на определянето на графика за вагоните/интермодалните транспортни единици.

В качеството си на заявители ЖПП/ВЖПП също така трябва да осигуряват (чрез договори с УИ) необходимите маршрути и да експлоатират влака по своя участък от пътуването. Те могат да използват вече резервирани (в режим на планиране) маршрути или да поискат от съответния(-ите) управител(-и) на инфраструктура(-и) специален за целта маршрут за участъка (участъците) от пътя, по които съответното ЖПП експлоатира влака. В приложение I е даден пример за сценарий за заявка на маршрут.

Притежанието на маршрут също така има важно значение за комуникацията между ЖПП и УИ по време на движението на влака. Комуникацията трябва винаги да се основава на номера на влака и на маршрута, които ЖПП е резервирало в инфраструктурата на УИ (виж също приложение I).

Ако дадено ЖПП осигурява изцяло пътя A–F (в режим на свободен достъп за ЖПП и без участие на друго ЖПП), всеки заинтересован УИ трябва да комуникира пряко и единствено с него. Този „свободен достъп“ може да бъде осигурен чрез резервиране на маршрут на „едно гише“, или пряко от всеки УИ за отделните участъци от пътя. В настоящата ТСОС са взети предвид и двете възможности, както е посочено в глава 4.2.2.1. Заявка за маршрут, предварителни бележки.

Процедурата на диалог между ЖПП и УИ за определянето на маршрут на товарен влак е описана в глава 4.2.2 (Заявка за маршрут). Тази функция се основава на член 48, параграф 1 от Директива 2012/34/ЕС [3]. Процедурата на диалог не включва получаването на лиценз за ЖПП, предоставящо услуги съгласно Директива 2001/13/ЕО [10], получаването на сертификат съгласно Директива 2012/34/ЕС [3], и правата за достъп съгласно Директива 2012/34/ЕС [3].

Обменът на информация относно композирането и процедурата по потегляне на влаковете е описан в глава 4.2.3 (Подготовка на влака). Обменът на данни по време на движението на влака при нормална експлоатация е описан в глава 4.2.4 (Прогнозиране на движението на влака), а съобщенията относно извънредните ситуации са описани в глава 4.2.5 (Информация за прекъсване на услугата). Всички тези съобщения се обменят между ЖПП и УИ и се базират на съответните влакове.

Най-важната информация за клиента при всички случаи е очакваният час на пристигане (ОЧП) на неговите стоки. Очакваният час на пристигане може да бъде изчислен въз основа на обмена на информация между водещото ЖПП и УИ (в случай на режим на свободен достъп). В случай на сътрудничество между няколко ЖПП, очакваният час на пристигане и очакваните часове на прехвърляне (ОЧПР) могат да бъдат определени въз основа на обменените съобщения между ЖПП и УИ, които са предоставени от водещото ЖПП на ЖПП (глава 4.2.6 „Очакван час на прехвърляне/Очакван час на пристигане на товара“).

Този обмен на информация позволява също така на водещото ЖПП да е информирано например по следните въпроси:

—

кога вагоните са тръгнали от или пристигнали в разпределителната гара или на определено място (глава 4.2.7 Движение на вагоните)

—

кога отговорността за вагоните е била прехвърлена от едно ЖПП на друго в рамките на транспортната верига (глава 4.2.8. Доклади за прехвърляне).

От информацията, обменяна между УИ и ЖПП, както и между ЖПП и водещото ЖПП, е възможно да се получат различни статистически данни, които да послужат както следва:

—

в средносрочен план — за по-подробно планиране на работния процес и

—

в дългосрочен план — за стратегическо планиране и проучвания относно капацитета (напр. анализи на мрежите, определяне на коловозите, използвани със служебна цел и на разпределителните гари, планиране на подвижния състав), но най-вече

—

за подобряване на качеството на транспортната услуга и на производителността (глава 4.2.9 Обмен на данни за подобряване на качеството).

Начинът на процедиране с празните вагони придобива особено значение при наличие на оперативно съвместими вагони. По принцип няма разлика между начина на процедиране с натоварени и празни вагони. Транспортът на празни вагони също се базира на заявки за транспорт, и поради това управителят на парка за тези празни вагони трябва да бъде разглеждан като клиент.

2.3.3.   Общи бележки

Качеството на информационната система зависи от достоверността на съдържащите се в нея данни. Ето защо данните, които играят определяща роля при изпращането на дадена пратка, вагон или контейнер, трябва да бъдат точни и да са придобити по икономически ефективен начин, което означава данните да се въвеждат в системата само веднъж.

По този начин приложенията и съобщенията съгласно настоящата ТСОС дават възможност да се избегне ръчното и повторно въвеждане на данни посредством достъп до вече записана информация, например справочната информация относно подвижния състав. Изискванията относно справочните данни за подвижния състав са определени в глава 4.2.10 (Основни справочни данни). Специфицираните справочни бази данни за подвижния състав трябва да дават възможност за лесен достъп до техническата информация. Въз основа на структурираните права за достъп в зависимост от правомощията, съдържанието на тези бази данни трябва да бъде достъпно за всички УИ, ЖПП и управители на паркове, по-специално за целите на управлението на парковете и поддръжката на подвижния състав. Те трябва да съдържат всички технически данни, които са необходими за транспорта, като например:

—

Идентификация на подвижния състав,

—

Технически/проектни данни,

—

Оценка на съвместимостта с инфраструктурата,

—

Оценка на съответните товарни характеристики,

—

Съответните спирачни характеристики,

—

Данни за поддръжката и ремонта,

—

Характеристики във връзка с околната среда.

При интермодалния транспорт на някои специфични места (наричани преходни точки) е възможно не само вагонът да бъде прикачен към друг влак, но също така и интермодалната единица да бъде преместена от един вагон в друг. Следователно не е достатъчно да се работи единствено с пътен план на вагоните; необходимо е също така да се изготви такъв план и за интермодалните единици.

В глава 4.2.11 (Разни справочни данни) са посочени някои справочни файлове и различни бази данни, между които и Оперативната база данни за вагоните и интермодалните единици (Wagon and Intermodal Unit Operational Database.). Тази база данни съдържа данни относно функционалното състояние на подвижния състав, информация за теглото и опасните стоки, информация във връзка с интермодалните единици и информация за местонахождението.

ТСОС на подсистемата „Телематични приложения за товарни превози“ дефинира необходимата информация, която трябва да бъде обменяна между различните участващи в транспортната верига партньори, и дава възможност за въвеждане на стандартизирана и задължителна процедура за обмен на данни. Тя показва също така стратегия за архитектурата на такава комуникационна платформа. Това е разгледано в глава 4.2.12 (Работа в мрежа и комуникации), където са взети предвид:

—

интерфейсът към подсистемата „Експлоатация и управление на движението“, спомената в член 5, параграф 3 от Директива 2008/57/ЕО [1],

—

изискванията относно съдържанието на референтния документ за железопътната мрежа, които са зададени в член 27 и в приложение IV към Директива 2012/34/ЕС [3],

—

наличната информация относно товарните вагони и изискванията по поддръжката, определени в ТСОС „Подвижен състав“.

Няма пряко предаване на данни от подсистемата „Телематични приложения за товарни превози“ във влака, към машиниста или към елементи от подсистемата „Контрол, управление и сигнализация“ и при това съответната предавателна мрежа е физически напълно независима от мрежата, използвана от подсистемата „Контрол, управление и сигнализация“. Системата ERTMS/ETCS (Европейска система за управление на железопътното движение/Европейска система за управление на влаковете) използва GSM-R (Глобалната система за мобилна комуникация на железниците). В тази отворена мрежа спецификациите на ETSC показват, че сигурността се гарантира чрез съответното управление в протокола EURORADIO на рисковете в отворените мрежи.

Интерфейсите към структурните подсистеми „Подвижен състав“ и „Контрол и управление“ се дават само посредством справочните бази данни за подвижния състав (глава 4.2.10.2: Справочни бази данни за подвижния състав), които се управляват от ползвателите на подвижния състав. Интерфейсите към подсистемите „Инфраструктура“, „Контрол и управление“ и „Енергия“ се дават с дефинирането на маршрута (глава 4.2.2.3: Съобщение с подробни данни за маршрута) от УИ, в което се уточняват свързаните с инфраструктурата параметри за влака, както и с предоставяната от УИ информация относно ограниченията в инфраструктурата (глава 4.2.2 Заявка за маршрут и глава 4.2.3 Подготовка на влака).

3.   СЪЩЕСТВЕНИ ИЗИСКВАНИЯ

3.1.   Съответствие със съществените изисквания

Съгласно член 4, параграф 1 от Директива 2008/57/EО [1], трансевропейската железопътна система, подсистемите и съставните елементи на оперативна съвместимост трябва да отговарят на съществените изисквания, посочени в общ вид в приложение III към тази директива.

В рамките на настоящата ТСОС, спазването на спецификациите, описани в глава 4, осигурява спазване и на посочените в глава 3 съществени изисквания за подсистемата. Определяне на характеристиките на подсистемата.

3.2.   Аспекти на съществените изисквания

Съществените изисквания се отнасят до:

—

Безопасност,

—

Надеждност и разполагаемост,

—

Опазване на здравето,

—

Защита на околната среда.

—

Техническа съвместимост.

Съгласно Директива 2008/57/ЕО [1] съществените изисквания могат да се прилагат по принцип за цялата трансевропейска железопътна система или да са специфични за всяка подсистема и нейните съставни елементи.

3.3.   Аспекти, свързани с изискванията от общ характер

Наличието на значимост на изискванията от общ характер към подсистемата „Телематични приложения за товарни превози“ се определя както следва:

3.3.1.   Безопасност

Съществените изисквания 1.1.1, 1.1.2, 1.1.3, 1.1.4 и 1.1.5 от приложение III към Директива 2008/57/ЕО [1] не се отнасят за подсистемата „Телематични приложения“.

3.3.2.   Надеждност и разполагаемост

„Контролирането и поддържането на неподвижните или подвижните елементи, участващи в движението на влаковете, трябва да се организира и провежда и да е количествено определено по начин, осигуряващ функционирането им при определените условия.“

Това съществено изискване се изпълнява посредством посоченото в следните глави:

—

Глава 4.2.10: Основни справочни данни,

—

Глава 4.2.11: Разни справочни файлове и бази данни,

—

Глава 4.2.12: Работа в мрежа и комуникации.

3.3.3.   Здравеопазване

Съществените изисквания 1.3.1 и 1.3.2 от приложение III към Директива 2008/57/ЕО [1] не се отнасят за подсистемата „Телематични приложения“.

3.3.4.   Защита на околната среда

Съществените изисквания 1.4.1, 1.4.2, 1.4.3, 1.4.4 и 1.4.5 от приложение III към Директива 2008/57/ЕО [1] не се отнасят за подсистемата „Телематични приложения“.

3.3.5.   Техническа съвместимост

Същественото изискване 1.5 от приложение III към Директива 2008/57/ЕО [1] не се отнася до подсистемата „Телематични приложения“.

3.4.   Аспекти, отнасящи се специално за подсистемата „Телематични приложения за товарни превози“

3.4.1.   Техническа съвместимост

Същественото изискване 2.7.1 от приложение III към Директива 2008/57/ЕО [1]:

„Съществените изисквания за телематични приложения гарантират минимално качество на услугата за пътници и превозвачи на стоки, по-специално по отношение на техническата съвместимост.

Трябва да се предприемат мерки за осигуряване както следва:

—

базата данни, софтуерът и протоколите за комуникация на данни да са изготвени така, че да гарантират максимални възможности за обмен на данни, от една страна, между различните приложения и, от друга страна, между различните експлоатационни предприятия, като се изключват търговските и поверителните данни,

—

да има лесен достъп до информацията за потребителите.“

Това съществено изискване се изпълнява по-специално посредством посоченото в следните глави:

—

Глава 4.2.10: Основни справочни данни,

—

Глава 4.2.11: Разни справочни файлове и бази данни,

—

Глава 4.2.12: Работа в мрежа и комуникации.

3.4.2.   Надеждност и разполагаемост

Същественото изискване 2.7.2 от приложение III към Директива 2008/57/ЕО [1]:

„Методите на използване, управление, актуализация и поддържане на тези бази данни, софтуера и протоколите за предаване на данни трябва да гарантират ефективността на системите и качеството на обслужването.“

Това съществено изискване се изпълнява по-специално посредством посоченото в следните глави:

—

Глава 4.2.10: Основни справочни данни,

—

Глава 4.2.11: Разни справочни файлове и бази данни,

—

Глава 4.2.12: Работа в мрежа и комуникации.

Това съществено изискване, и по-специално използваният метод за гарантиране на ефективността на тези телематични приложения и на качеството на услугата, представлява основата на цялата ТСОС, а не се ограничава само до посоченото в главите 4.2.10, 4.2.11 и 4.2.12.

3.4.3.   Здраве

Същественото изискване 3.7.2 от приложение III към Директива 2008/57/ЕО [1]:

„Интерфейсите между тези системи и потребителите трябва да бъдат в съответствие с минималните изисквания за ергономичност и правилата за здравеопазване.“

В настоящата ТСОС не са определени изисквания, допълнителни в сравнение със съществуващите национални и европейски нормативи в областта на минималните изисквания за ергономия и опазване на здравето, що се отнася до интерфейса между тези телематични приложения и потребителите.

3.4.4.   Безопасност

Същественото изискване 2.7.4 от приложение III към Директива 2008/57/ЕО [1]:

„Трябва да бъдат осигурени подходящи нива на цялостност и надеждност за съхранението или предаването на информация, свързана с безопасността.“

Това съществено изискване се изпълнява по-специално посредством посоченото в следните глави:

—

Глава 4.2.10: Основни справочни данни,

—

Глава 4.2.11: Разни справочни файлове и бази данни,

—

Глава 4.2.12: Работа в мрежа и комуникации.

4.   ОПРЕДЕЛЯНЕ НА ХАРАКТЕРИСТИКИТЕ НА ПОДСИСТЕМАТА

4.1.   Въведение

Железопътната система, която е предмет на Директива 2008/57/ЕО и част от която е подсистемата „Телематични приложения“, е интегрирана система, чиято последователност трябва да бъде проверявана. Тази последователност трябва да бъде проверявана по-специално по отношение на спецификациите на подсистемата, на нейните интерфейси към системата, в която е интегрирана, както и на правилата за експлоатация и за поддръжка.

Като се имат предвид всички приложими съществени изисквания, подсистемата „Телематични приложения за товарни превози“ се характеризира от:

4.2.   Функционални и технически спецификации на подсистемата

В съответствие със съществените изисквания в глава 3 (Съществени изисквания), функционалните и технически спецификации на подсистемата обхващат следните параметри:

—

Данни в товарителницата,

—

Заявка за маршрут,

—

Подготовка на влак,

—

Прогноза за движението на влака,

—

Информация за смущение в превоза,

—

ОЧПР/ОЧП (очаквани часове на прехвърляне/очакван час на пристигане) на вагоните/интермодалните единици,

—

Движение на вагоните

—

Доклади за извършено прехвърляне

—

Обмен на данни за подобряване на качеството,

—

Основните справочни данни,

—

Разни справочни файлове и бази данни,

—

Работа в мрежа и комуникации.

Подробните спецификации на данните са дефинирани в пълния Каталог на данните. Задължителните формати на съобщенията и на данните от този каталог са дефинирани в документа „ТСОС ТПТП — приложение Г.2: допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, който е включен в списъка в допълнение I. Освен това могат да се използват за същата цел и други съществуващи стандарти, ако има конкретно споразумение между участващите страни за разрешаване на ползването на тези стандарти, по-специално на териториите на държави членки на ЕС, граничещи с трети държави.

Общи бележки относно структурата на съобщенията

Съобщенията се структурират под формата на два блока от данни:

—   Контролни данни: дефинирани посредством задължителната антетка на съобщенията от каталога.

—   Информационни данни: дефинирани посредством задължителното/незадължителното съдържание на всяко съобщение и задължителния/незадължителния набор от данни в каталога.

Ако дадено съобщение или елемент от данните са дефинирани в настоящия регламент като незадължителни, участващите страни решават дали да ги използват. Използването на тези съобщения и елементи от данни трябва да бъде част от договорно споразумение. Ако някои незадължителни елементи в каталога на данните стават при известни условия задължителни, това трябва да бъде посочено в каталога на данните,

4.2.1.   Данни в товарителницата

4.2.1.1.   Товарителница на клиента

Товарителницата трябва да се изпрати от клиента до водещото ЖПП. Тя трябва да съдържа цялата информация, необходима за транспортирането на пратката от изпращача до получателя в съответствие с „Единните правила за договора за международен железопътен превоз на товари (CIM)“, „Единните правила за договорите за използване на подвижен състав в международното железопътно съобщение (СUV) и действащите национални правила“. Водещото ЖПП трябва да добави допълнителна информация. Съответен подраздел от данните в товарителницата, включващ допълнителни данни, в описан в допълнение I, ТСОС ТППП — ПРИЛОЖЕНИЕ Г.2: ДОПЪЛНЕНИЕ А (ПЛАН ЗА ПЪТУВАНЕ НА ВАГОНИ/ИНТЕРМОДАЛНИ ТОВАРНИ ЕДИНИЦИ — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП [4], посочено в таблицата в допълнение I към настоящия регламент.

При режим на свободен достъп водещото ЖПП, което е в договорни отношения с клиента, разполага с цялата информация, след като допълнителните данни бъдат налице. Не е необходим никакъв обмен на съобщения с други ЖПП. Тези данни служат също така като основа за съставянето на бърза заявка за маршрут, ако това е необходимо за изпълнение на товарителницата.

Разгледаните по-долу съобщения са необходими в случай, че не се използва режим на свободен достъп. Тяхното съдържание може също така да служи като основа за бързите заявки за маршрут, ако това е необходимо за изпълнение на товарителницата.

4.2.1.2.   Заявки за транспорт

Заявката за предоставяне на вагони е преди всичко част от информацията, съдържаща се в товарителницата. Тя трябва да бъде изпратена на ЖПП, участващи в организираната от водещото ЖПП транспортна верига. Заявката за транспорт трябва да съдържа съответната информация, необходима на дадено ЖПП за извършването на превоза по участъка за който то отговаря, до прехвърлянето на отговорността за товара на следващото ЖПП. Следователно съдържанието ѝ зависи от дейността, която ЖПП трябва да извърши: дали е първо ЖПП, транзитиращо ЖПП или извършващо доставката ЖПП.

Структурата от задължителни данни в заявката за транспорт и подробните образци за това съобщение са посочени в раздела „Съобщение за заявка за транспорт“ в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

Основното съдържание в тези заявки за транспорт е::

—

Информация относно изпращача и получателя,

—

Информация относно маршрута,

—

Идентификация на товара,

—

Информация за вагона,

—

Информация относно мястото, датата и часа.

Някои данни от товарителницата трябва също така да бъдат достъпни за всички партньори (напр. УИ, ползвателя на вагоните, ...) в транспортната верига, включително клиентите. Те са по-специално данни за отделните вагони както следва:

—

Тегло на товара (брутно тегло),

—

Кодов номер по Комбинираната номенклатура/Хармонизираната система,

—

Информация относно опасните товари,

—

Коя е транспортната единица.

По изключение може да се използва копие на хартиен носител, само ако тази информация не може да бъде изпратена чрез дефинираните по-горе съобщения.

4.2.2.   Заявка за маршрут

4.2.2.1.   Предварителни бележки

Влаковият маршрут определя заявените, приетите и действителни данни, които трябва да бъдат съхранени относно маршрута на влака, както и характеристиките на влака за всеки участък от този маршрут. Следва описание на информацията, която трябва да бъде на разположение на управителя на инфраструктурата. Тази информация трябва да бъде актуализирана винаги при настъпване на промяна. Следователно по отношение на годишната маршрутна информация е необходимо да има възможност за извличане на данни с цел внасяне на краткосрочни изменения. По-специално е необходимо клиентът да бъде съответно информиран (ако има последици за него) от водещото ЖПП.

Краткосрочна заявка за предоставяне на маршрут

При извънредни ситуации при експлоатацията на влака или в случай на спешни транспортни заявки железопътното предприятие трябва да има възможност да получи маршрут в мрежата специално за конкретен случай.

В първия случай трябва да се предприемат незабавни мерки, които да позволят да се узнае каква е действителната влакова композиция въз основа на предоставения списък на влаковите композиции.

Във втория случай железопътното предприятие трябва да предостави на управителя на инфраструктурата всички необходими данни относно датата, часа и мястото на движение на влака, както и неговите физически характеристики, доколкото те си взаимодействат с инфраструктурата.

Основният параметър „Краткосрочни заявки за маршрут“ се урежда съвместно от ЖПП и от управителя на инфраструктура (УИ). В този основен параметър терминът УИ може да означава няколко управители на инфраструктура и, в съответните случаи — разпределящи органи (вж. Директива 2012/34/ЕС [3]).

Тези изисквания са валидни за всички бързи заявки за маршрут.

Този основен параметър [ОП] не включва въпроси по управление на движението. Срокът, по който бързо заявените маршрути се различават от измененията в маршрути по линия на управлението на движението, е предмет на споразумения на местно равнище.

Железопътното предприятие (ЖПП) трябва да предостави на управителя на инфраструктура (УИ) всички необходими данни относно времето и мястото, за които се иска възможност за движение на влака, както и неговите физически характеристики, доколкото те си взаимодействат с инфраструктурата.

Всеки управител на инфраструктура отговаря за пригодността на маршрута в рамките на своята инфраструктура, а железопътното предприятие е длъжно да сверява характеристиките на влака със стойностите, указани в подробните данни за договорения от него маршрут.

Без да се нарушават условията за използване на даден маршрут, представени в референтните документи за мрежата или отговорностите в случай на ограничения по отношение на инфраструктурата, указани в ТСОС „Експлоатация и управление на движението“, ЖПП трябва да има информация преди подготовката на влака за съществуването на ограничения по определени участъци от линията или в гарите (железопътните възли), засягащи влаковата композиция, описана в договора за предоставяне на маршрута.

Споразумението относно маршрута в случай на бързо заявено движение на влак трябва да се извърши чрез диалог между всички участващи ЖПП и УИ. Заявките за инфраструктурен капацитет могат да се подават от заявители. За да могат да използват този инфраструктурен капацитет заявителите определят железопътно предприятие, което да сключи споразумение с управителя на инфраструктура в съответствие с Директива 2012/34/EС [3]. В диалога трябва да участват всички ЖПП и УИ, участващи в движението на влака по желания маршрут, но е възможно да имат различен принос в процедурата по определяне на маршрут.

4.2.2.2.   Съобщение за заявяване на маршрут

Това съобщение се изпраща от ЖПП до управителя на инфраструктура (УИ) с цел заявяване на маршрут.

Дефиницията на задължителната структура на това съобщение и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.2.3.   Съобщение с подробни данни за маршрута

УИ изпраща това съобщение на подалото заявка ЖПП в отговор на заявката за маршрут.

Дефиницията на задължителната структура на съобщението с подробни данни за маршрута и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.2.4.   Съобщение за потвърждение на приемането на маршрута

Подаващото заявка ЖПП използва това съобщение за да резервира/потвърди маршрута, предложен от УИ.

Дефиницията на задължителната структура на съобщението за потвърждение на приемането на маршрута и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.2.5.   Съобщение за отказ на подробни данни за маршрута

Подаващото заявка ЖПП използва това съобщение за да отхвърли подробни данни, предложени от съответния управител на инфраструктура.

Дефиницията на задължителната структура на съобщението за отказ на подробни данни за маршрута и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.2.6.   Съобщение за отмяна на маршрут

Това съобщение се използва от ЖПП за отмяна на цял резервиран маршрут или на част от него.

Дефиницията на задължителната структура на съобщението за отмяна на маршрут и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.2.7.   Съобщение, че маршрутът не е разполагаем

Този вид съобщение се изпраща от УИ на сключилото договор ЖПП, в случай че резервираният от ЖПП маршрут е престанал да бъде разполагаем.

Дефиницията на задължителната структура на съобщението „маршрутът не е разполагаем“ и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.2.8.   Съобщение за потвърждение на получаване

Това съобщение се изпраща от получателя на дадено съобщение до неговия автор, с което получателя потвърждава, че неговата протоколираща система е получила съобщението в определения времеви интервал.

Дефиницията на задължителната структура на съобщението за потвърждение на получаване и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.3.   Подготовка на влак

4.2.3.1.   Общи бележки

Този основен параметър описва съобщенията, които трябва да бъдат обменени по време на етапа на подготовка на влака до неговото тръгване.

Подготовката на влака включва проверка на съвместимостта на влака и маршрута. Проверката се извършва от ЖПП въз основа на информацията, предоставена от съответните УИ относно описанието и ограниченията на инфраструктурата.

По време на подготовката на влака ЖПП трябва да изпрати данни за влаковата композиция на следващите ЖПП. Съгласно договорните споразумения, това споразумение трябва да бъде изпратено също на УИ, с който (с които) е договорен участък от маршрута.

Ако влаковата композиция бъде променена в определена точка, това съобщение трябва да се изпрати още веднъж от отговорното ЖПП, като се отбележат извършените промени.

За да може да подготви влака, ЖПП трябва да има достъп до информацията за ограниченията на инфраструктурата, до техническите данни на вагоните (от справочните бази данни за подвижния състав, глава 4.2.10.2: Справочни бази данни за подвижния състав), до информацията за опасните товари и до текущата актуализирана информация за вагоните (глава 4.2.11.2: Други бази данни: Оперативна база данни за вагоните и интермодалните единици). Това се отнася за всички вагони на влака. И накрая ЖПП трябва да изпрати данните за влаковата композиция на следващите ЖПП. Това съобщение трябва да бъде изпратено също от ЖПП на УИ, от който (които) е резервирало участък от маршрута, когато това се изисква съгласно ТСОС „Експлоатация и управление на движението“ за конвенционалните железопътни линии или съгласно договора (договорите) между ЖПП и УИ.

Ако влаковата композиция бъде променена в определена точка, това съобщение трябва да се изпрати още веднъж с актуализирана информация от отговорното ЖПП.

Във всяка точка, например начална точка и точка на прехвърляне, в която отговорността за товара се прехвърля на друго ЖПП, е задължително провеждането на начална процедура на диалог „Готовност на влак — Информация за движението на влака“ между УИ и ЖПП.

4.2.3.2.   Съобщение относно влаковата композиция

Това съобщение, дефиниращо композицията на влака, трябва да бъде изпратено от ЖПП до следващото ЖПП. Съгласно референтния документ за железопътната мрежа, това съобщение се изпраща също от ЖПП на съответния (съответните) УИ. В случай на промяна на влаковата композиция по време на пътуването, извършилото промяната ЖПП трябва да актуализира съобщението и да го изпрати на всички участващи страни.

Дефиницията на задължителната структура на съобщението за влаковата композиция и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

Минимално необходимите елементи, които трябва да присъстват в обмена на съобщения между ЖПП и УИ във връзка с влаковата композиция са дефинирани в глава 4.2.2.7.2 от Решение 2012/757/ЕС, ТСОС „Експлоатация и управление на движението“.

4.2.3.3.   Съобщение за готовност на влака

Железопътното предприятие трябва да изпраща на управителя на инфраструктурата съобщение „влакът е готов“ всеки път, когато даден влак е готов да потегли след подготовка на влака, освен ако съгласно националните правила управителят на инфраструктурата приема разписанието като съобщение „влакът е готов“.

Дефиницията на задължителната структура на съобщението за готовност на влака и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I. Освен това за същата цел могат да бъдат използвани други съществуващи стандарти, ако участващите страни са сключили конкретно споразумение, разрешаващо използването на тези стандарти.

4.2.4.   Прогноза за движението на влака

4.2.4.1.   Общи бележки

Този основен параметър определя предоставянето на информация и прогноза за движението на влака. Чрез него трябва да се предпише как да се поддържа диалогът между управителя на инфраструктурата и железопътното предприятие, за да се обменят данни и прогнози за движението на влака.

Този основен параметър определя как управителят на инфраструктурата трябва своевременно да изпраща информация относно движението на влака на железопътното предприятие и на управителя на следващата съседна инфраструктура, участваща в експлоатацията на влака.

Информацията за движението на влака служи за предоставяне на подробности за текущото състояние на влака в съгласувани пунктове за отчитане.

Прогнозата за движението на влака се използва за предоставяне на информация относно очакваното време в съгласувани пунктове за отчитане. Това съобщение трябва да бъде изпратено от управителя на инфраструктурата до железопътното предприятие и управителя на съседната инфраструктура, участваща в движението.

В договорните споразумения трябва да се уточняват пунктовете за отчитане на движението на влака.

Този обмен на информация между железопътни предприятия и управители на инфраструктура се извършва винаги между съответния отговорен УИ и ЖПП, което е резервирало маршрута, по който се движи влакът.

Съгласно съответно договорно споразумение, водещото ЖПП предоставя на клиента прогноза за движението на влака и информация за движението на влака. Точките на отчитане се договарят от двете договорни страни.

4.2.4.2.   Съобщение за прогноза за движението на влака

Това съобщение трябва да бъде изпращано от УИ до експлоатиращото влака ЖПП по отношение на точките на предаване, точките на прехвърляне и местоназначението на влака, както това е описано в глава 4.2.4.1 (Прогноза за движението на влака, общи бележки).

УИ също така трябва да изпраща това съобщение на ЖПП за други точки за отчитане в съответствие с договорите ЖПП/УИ (напр. точка или гара за прекомпозиране).

Прогноза за движението на влака може да се изпрати и преди потеглянето на влака. За допълнителни закъснения, възникващи между два пункта за отчитане, железопътното предприятие и управителят на инфраструктура определят прагова стойност, при чието надхвърляне трябва да се изпрати първоначална или нова прогноза. Ако големината на закъснението не е известна, управителят на инфраструктура трябва да изпрати „съобщение за смущение в превоза“ (вж. точка 4.2.5 Информация за смущение в превоза).

В съобщението с прогнозата за движението на влака трябва да се посочва предвижданото време за достигане на съгласуваните пунктове за отчитане.

Дефиницията на задължителната структура на съобщението с прогноза за движението на влака и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.4.3.   Съобщение с информация за движението на влака и съобщение за причината за закъснение.

Такова съобщение трябва да бъде изпращано от УИ на експлоатиращото влака ЖПП в следните случаи:

—

Потегляне на влака от отправната точка и при пристигането му на местоназначението,

—

Пристигане и отпътуване на влака във и от точките на предаване, прехвърляне и отчитане, които са предвидени в договора (например в точките за прекомпозиране).

Ако е известна причината за закъснението (като първоначално предположение), тя трябва да бъде изпратена в отделно съобщение за причината за закъснение на влака.

Дефиницията на задължителната структура на съобщението с информация за движението на влака и на съобщението за причината за закъснение на влака и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.5.   Информация за смущение в превоза

4.2.5.1.   Общи бележки

Този основен параметър определя как информацията за смущение в превоза се обменя между железопътното предприятие и управителя на инфраструктурата.

Когато дадено ЖПП научи за смущение в услугата по време на експлоатацията на влака, за който отговаря, то трябва да информира незабавно съответния УИ (това трябва да бъде извършено посредством гласово съобщение от страна на ЖПП). Ако е прекъснато движението на влака, управителят на инфраструктура трябва да изпрати съобщение „прекъснато движение на влака“ до сключилото договор ЖПП и до съседния УИ, участващ в движението на влака.

Ако продължителността на закъснението е известна, управителят на инфраструктура трябва вместо това да изпрати съобщение с прогноза за движението на влака.

4.2.5.2.   Съобщение за прекъсване на движението на влака

Ако движението на влака е прекъснато, УИ изпраща този вид съобщение до следващия съседен УИ, участващ в движението на влака, както и до ЖПП.

Дефиницията на задължителната структура на съобщението за прекъсване на движението на влака и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.6.   ОЧПР/ОЧП (очаквани часове на прехвърляне/очакван час на пристигане) на товара

4.2.6.1.   Предварителна бележка

В глава 4.2.2 (Заявка за маршрут) е описана главно комуникацията между ЖПП и УИ. Този обмен на информация не обхваща индивидуалния мониторинг на вагоните или интермодалните единици. Това се извършва на равнище ЖПП/водещо ЖПП въз основа на съобщенията относно влаковете и е описано в следващите глави — от глава 4.2.6 (ОЧПР/ОЧП на товара) до глава 4.2.8 (Отчитане на прехвърлянията).

Обменът и актуализирането на информацията относно вагоните или интермодалните единици се основават най-вече на записаните данни от„пътните планове“ и „движението на вагоните“ (глава 4.2.11.2: Други бази данни).

Както вече бе споменато в глава 2.3.2 (Разгледани процедури), най-важната информация за клиента при всички случаи е очакваният час на пристигане (ОЧП) на неговия товар. Отнасящите се за вагоните очаквани часове на пристигане, както и очакваните часове на прехвърляне представляват основните данни в комуникацията между водещото ЖПП и ЖПП. Те представляват основният инструмент, позволяващ на водещото ЖПП да осъществява мониторинг на физическия превоз на даден товар и да контролира спазването на поетите към клиента ангажименти.

Всички очаквани часове, фигуриращи в съобщенията относно влака, се отнасят до пристигането на влака на определено място, независимо дали става дума за точка на предаване, точка на прехвърляне или точка за отчитане. Всички те представляват очаквани часове на пристигане на влака (ОЧПВ). За различните вагони или интермодални единици в даден влак такива ОЧПВ могат да имат различни значения. Даден ОЧПВ в точка на прехвърляне например може да бъде очакван час за прехвърляне (ОЧПР) на някои вагони или интермодални единици. За други вагони, които остават влака за допълнително транспортиране от същото ЖПП те биха могли да нямат никакво значение. Задача на ЖПП е при получаването на ОЧПВ да идентифицира и да обработи тази информация, да я съхрани като данни за движение на вагони в Оперативната база данни за вагоните и интермодалните единици и да я изпрати на водещото ЖПП, ако влакът не се движи в режим на свободен достъп. Тази процедура е разгледана в следващите глави.

По договорно споразумение водещото ЖПП осигурява на клиента данни за очакваното време на пристигане (ОЧП) и за очакваното време на прехвърляне (ОЧПР) на ниво пратка. Степента на подробности се договаря от двете договорни страни.

По отношение на интермодалния транспорт в съобщенията с данни, съдържащи идентификаторите на товарните транспортни единици (напр. контейнери, сменяеми контейнери — swap-bodies, полуремаркерта) се използва или код BIC, или код ILU, съответно по ISO 6346 или EN 13044.

4.2.6.2.   Изчисляване на ОЧПР/ОЧП (очаквани часове на прехвърляне/очакван час на пристигане)

Изчисляването на ОЧПР/ОЧП се основава на информацията от отговорния управител на инфраструктура, който в рамките на съобщението за прогноза на движението на влака изпраща очаквания час на пристигане на влака (ОЧПВ) в определени точки за отчитане (във всички случаи в точките на предаване, прехвърляне или пристигане, включително в интермодалните терминали) в рамките на договорения маршрут, например за точката на предаване от един УИ към следващия УИ (като в този случай ОЧПВ съвпада с очаквания час на предаване — ОЧПРЕД).

За точките прехвърляне или за други точки на отчитане, определени по договорения маршрут, ЖПП трябва да изчисли за следващото ЖПП от транспортната верига очаквания час на прехвърляне (ОЧПР) на вагоните и/или интермодалните единици.

Тъй като дадено ЖПП може да разполага с вагони, които трябва да преминат различен път и които зависят от различни водещи ЖПП в рамките на един и същ влак, точката за прехвърляне при изчисляването на ОЧП може да е различна за отделните вагони. (Графично представяне на тези сценарии и примери е дадено в документа „ТСОС ТПТП — Приложение А.5 Фигури и диаграми на последователността на съобщенията по ТСОС ТПТП“, глава 1.4, който документ е включен в списъка в допълнение I, а диаграмата на база на пример 1 за точката на прехвърляне С е показана в документа „ТСОС ТПТП — Приложение А.5 Фигури и диаграми на последователността на съобщенията по ТСОС ТПТП“, глава 5, който документ е включен в списъка в допълнение I).

Следващото ЖПП изчислява на свой ред ОЧПР на вагона в следващата точка за прехвърляне, въз основа на данните за ОЧПР, получени от предходното ЖПП. Тази процедура се прилага от всяко ЖПП. Когато последното ЖПП (тоест ЖППn) от транспортната верига на даден вагон получи от страна на предходното ЖПП (тоест ЖППn–1) ОЧПР на този вагон в точката за прехвърляне между двете ЖПП, ЖППn трябва да изчисли очаквания час на пристигане на вагоните в крайното местоназначение. Това позволява осигуряване на местоположението на вагоните в съответствие със заявката за транспорт, както и в съответствие с ангажиментите, които водещото ЖПП е поело спрямо своя клиент. Така се получава ОЧП на вагона и съответната информация трябва да бъде изпратена на водещото ЖПП. Тя трябва да бъде записвана на електронен носител в течение на движението на вагона. Водещото ЖПП трябва да осигурява съответни данни на клиента съгласно договорните условия.

Забележка относно интермодалните единици: За интермодалните единици, натоварени на даден вагон, ОЧПР на вагона са също така и ОЧПР на интермодалните единици. Що се отнася до ОЧП на тези интермодални единици, трябва да се има предвид, че ЖПП може да ги изчислява само що се отнася до частта, свързана с железопътния превоз. Следователно то може единствено да предоставя ОЧПР, отнасящи се за интермодалния терминал.

Водещото ЖПП отговаря за сравняването на ОЧП с ангажимента към клиента.

Евентуалните отклонения на ОЧП от този ангажимент трябва да се уреждат в съответствие с договора и могат да доведат до започване от страна на водещото ЖПП на процедура по преодоляване на тревожна ситуация. За предаването на информация за резултата от тази процедура е предвидено съобщение за тревожна ситуация.

Въз основа на процедурата за преодоляване на тревожна ситуация водещото ЖПП трябва да има възможност да отправи искане за информация относно евентуалните отклонения, свързани с даден вагон. Това искане на водещото ЖПП и съответният отговор от ЖПП също са специфицирани по-долу.

4.2.6.3.   Съобщение за ОЧПР/ОЧП на вагона

Предназначението на това съобщение е да се изпращат данните за ОЧПР или за актуализирания ОЧПР от дадено ЖПП на следващото ЖПП в транспортната верига. Последното ЖПП в транспортната верига на вагоните изпраща ОЧП (или актуализиран ОЧП) на водещото ЖПП. Дефиницията на задължителната структура на съобщението за ОЧПР/ОЧП на вагон и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.6.4.   Съобщение за тревожна ситуация

Въз основа на сравнение между ОЧП и ангажимента към клиента, водещото ЖПП може да изпраща до съответните ЖПП съобщение за тревожна ситуация. Дефиницията на задължителната структура на съобщението за тревожна ситуация и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

Забележка: В случай на режим на свободен достъп изчисляването на ОЧПР и ОЧП е вътрешна процедура за съответното ЖПП. В такъв случай това ЖПП е водещо ЖПП.

4.2.7.   Движение на вагоните

4.2.7.1.   Предварителни бележки

За целите на отчитане на движението на даден вагон е необходимо включените в тези съобщения данни да се съхраняват и да са достъпни по електронен път. Те трябва също така да бъдат обменяни в съобщения, изпращани на упълномощени страни в съответствие с договорни разпоредби.

—

Известие за освобождаване на вагон

—

Известие за заминаване на вагон

—

Пристигане на вагон в разпределителна гара

—

Заминаване на вагон от разпределителна гара

—

Съобщение за изключване на вагон

—

Известие за пристигане на вагон

—

Известие за доставка на вагон

—

Отчитането на прехвърлянето на вагони е описано отделно в глава 4.2.8: Отчитане на прехвърляне

Водещото ЖПП трябва по договорно споразумение да осигурява на клиента информация за движението на вагоните, като използва описаните по-долу съобщения.

4.2.7.2.   Известие за освобождаване на вагон

Водещото ЖПП не е непременно първото ЖПП в транспортната верига. В случай, че то не е първо, водещото ЖПП трябва да информира съответното първо ЖПП, че вагонът е готов да потегли от разпределителните коловози на клиента (мястото на потегляне зависи от поетите от водещото ЖПП ангажименти), в указания момент на освобождаване (дата и час на потегляне).

Данни за тези събития трябва да бъдат съхранени в Оперативната база данни за вагоните и интермодалните единици. Дефиницията на задължителната структура на известието за освобождаване на вагон и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.7.3.   Известие за заминаване на вагон

Съответното ЖПП трябва информира водещото ЖПП, за действителната дата и час, в които вагонът е бил изтеглен от мястото на заминаване.

Данни за тези събития трябва да бъдат съхранени в Оперативната база данни за вагоните и интермодалните единици. С изпращането на това съобщение отговорността за вагона се прехвърля от клиента върху съответното ЖПП. Дефиницията на задължителната структура на известието за заминаване на вагон и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.7.4.   Съобщение за пристигане на вагона в разпределителна гара

ЖПП трябва да информира водещото ЖПП, че вагонът е пристигнал в неговата разпределителна гара. Това съобщение може да се основава на съобщението за информация относно движението на влака, описано в глава 4.2.4 (Прогнозиране на движението на влака). Данни за това събитие трябва да бъдат съхранени в Оперативната база данни за вагоните и интермодалните единици. Дефиницията на задължителната структура на съобщението за пристигане на вагона в разпределителна гара и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.7.5.   Известие за заминаване на вагона от разпределителна гара

Съответното ЖПП трябва да информира водещото ЖПП, че вагонът е напуснал неговата разпределителна гара. Това съобщение може да се основава на съобщението за информация относно движението на влака, описано в глава 4.2.4 (Прогнозиране на движението на влака). Данни за това събитие трябва да бъдат съхранени в Оперативната база данни за вагоните и интермодалните единици. Дефиницията на задължителната структура на съобщението за заминаване на вагона от разпределителна гара и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.7.6.   Съобщение за изключване на вагон

Съответното ЖПП трябва да информира водещото ЖПП за всяко неочаквано събитие с даден вагон, което би могло да окаже влияние върху ОЧПР/ОЧП или да налага предприемането на допълнителни мерки. В по-голямата част от случаите това съобщение трябва да бъде придружено от ново изчисление на ОЧПР/ОЧП. Ако водещото ЖПП реши да се приемат нови ОЧПР/ОЧП, то отговаря със съобщение до съответното ЖПП, изпратило първоначалното съобщение, с указание „искане за ОЧПР/ОЧП“ (съобщение: Съобщение за изключване на вагон: искане на нови ОЧПР/ОЧП). Изчислението на нови ОЧПР/ОЧП трябва да се извършва в съответствие с процедурата, описана в глава 4.2.6. (ОЧПР/ОЧП на товара).

Тази информация трябва да бъде съхранена в Оперативната база данни за вагоните и интермодалните единици. Дефиницията на задължителната структура на съобщението за изключване на вагон и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.7.7.   Известие за пристигане на вагон

Последното ЖПП от транспортната верига при превоза на вагон или на интермодална единица трябва да информира водещото ЖПП, че вагонът е пристигнал в неговата разпределителна гара (в местоположението на ЖПП). Дефиницията на задължителната структура на известието за пристигане на вагон и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.7.8.   Известие за доставяне на вагон

Последното ЖПП от транспортната верига трябва да информира водещото ЖПП, че вагонът е поставен на маневрените коловози на получателя.

Забележка: В случай на режим на свободен достъп описаното движение на вагона е вътрешна процедура за съответното ЖПП. При все това то трябва да извършва всички изчисления и съхраняването на данни в качеството му на водещо ЖПП, имащо договор с клиента и съответен ангажимент към него.

Диаграмата на последователността на тези съобщения, базираща се на пример № 1 относно изчисляването на ОЧПР на вагони № 1 и № 2 (виж глава 4.2.6.2: Изчисляване на ОЧПР/ОЧП), е включена в диаграмата относно отчитането на прехвърляне в документа „ТСОС ТПТП — Приложение А.5 Фигури и диаграми на последователността на съобщенията по ТСОС ТПТП“, глава 6, който документ е включен в списъка в допълнение I.

4.2.8.   Отчитане на прехвърляне

4.2.8.1.   Предварителна бележка

По отношение на отчитането на прехвърляне са описани съобщенията, свързани с прехвърлянето на отговорността за даден вагон между две железопътни предприятия в точките за прехвърляне. Това също така задължава новото ЖПП да изчисли ОЧПР и да продължи да следва процедурата, описана в глава 4.2.6 (ОЧПР/ОЧП на товара).

Трябва да се изпратят следните съобщения:

—

Известие за прехвърляне на вагон,

—

Допълнително известие за прехвърляне на вагон,

—

Потвърждение за приемане на вагон в точката за прехвърляне,

—

Отказ за приемане на вагон в точката за прехвърляне.

Данните, съдържащи се в тези съобщения, трябва да бъдат съхранявани в Оперативната база данни за вагоните и интермодалните единици. В случай на каквото и да е отклонение от графика трябва да бъдат генерирани и изпратени нови ОЧПР/ОЧП в съответствие с процедурата, описана в глава 4.2.6: ОЧПР/ОЧП (очаквани часове на прехвърляне/очакван час на пристигане) на товара. Схемата на последователността на тези съобщения е дадена във връзка със съобщенията за движението на вагоните в документа „ТСОС ТПТП — Приложение А.5 Фигури и диаграми на последователността на съобщенията по ТСОС ТПТП“, включен в списъка в допълнение I.

Известията за прехвърляне на вагон и допълнителните известия за прехвърляне на вагон, както и потвържденията за приемане на вагон могат да включват списък от няколко вагона, особено ако тези вагони са в един и същ влак. В този случай всички вагони могат да бъдат включени в едно-единствено съобщение.

При експлоатация в режим на свободен достъп няма точки на прехвърляне. Отговорността за вагоните не се променя в точките за прекомпозиране. Поради това не е необходимо изпращането на съответно специално съобщение. Но въз основа на информацията за движението на влака в тази точка за отчитане е необходимо информацията относно вагоните или интермодалните единици — по отношение на място, дата и час на пристигане или тръгване да бъде обработвана и съхранявана в Оперативната база данни за вагоните и интермодалните единици.

Водещото ЖПП трябва по договорно споразумение да осигурява на клиента информация за прехвърлянето на вагоните, като използва описаните по-долу съобщения.

Дефиницията на задължителната структура на тези съобщения е дадена в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.8.2.   Известие за прехвърляне на вагон

С известието за прехвърляне на вагон дадено железопътно предприятие (ЖПП № 1) пита следващото железопътно предприятие (ЖПП № 2) от транспортната верига дали приема да поеме отговорността за даден вагон. Чрез допълнителното известие за приемане на вагон ЖПП № 2 информира УИ, че е приело тази отговорност. Дефиницията на задължителната структура на известието за прехвърляне на вагон и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.8.3.   Допълнително известие за прехвърляне на вагон

С допълнителното известие за прехвърляне на вагон ЖПП № 2 информира УИ, че е поело отговорността за определен вагон. Дефиницията на задължителната структура на допълнителното известие за прехвърляне на вагон и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.8.4.   Потвърждение за приемане на вагон в точката за прехвърляне

С потвърждението за приемане на вагон в точката за прехвърляне ЖПП № 2 информира ЖПП № 1, че приема да поеме отговорността за вагона. Дефиницията на задължителната структура на потвърждението за приемане на вагон в точката за прехвърляне и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.8.5.   Отказ за приемане на вагон в точката за прехвърляне

С отказа за приемане на вагон в точката за прехвърляне ЖПП № 2 информира ЖПП № 1, че не желае да поеме отговорността за вагона. Дефиницията на задължителната структура на отказа за приемане на вагон в точката за прехвърляне и елементите, които трябва да бъдат спазени, са описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.9.   Обмен на данни за подобряване на качеството

За да бъде конкурентоспособен, европейският отрасъл на железопътния транспорт трябва да предоставя на своите клиенти висококачествени услуги (вж. също така приложение III, член 2.7.1 към Директива 2008/57/ЕО [1]). Провеждането на процедура на измерване на качествени показатели е съществена последваща транспорта процедура, която способства за подобрения на качеството. Освен измерването на качеството на предоставената на клиента услуга, водещото ЖПП, останалите ЖПП и УИ трябва да измерват качеството на отделните компоненти на услугата, които заедно съставят предоставяния на клиента продукт. При тази процедура УИ и ЖПП (особено ако са водещи ЖПП) избират определен качествен параметър и съответно маршрут или място и период на измерване, за които измерват действителните резултати в съпоставка с предварително определени критерии, които обикновено са договорно зададени. Резултатите от тази процедура на измерване трябва да покажат ясно степента на съответствие на предоставяните услуги по отношение на договорената между страните по договора цел.

4.2.10.   Основните справочни данни

4.2.10.1.   Въведение

Данните относно инфраструктурата (референтните документи относно мрежата и известията за ограничения на инфраструктурата) и данните относно подвижния състав (в справочните бази данни относно подвижния състав и в оперативната база данни за вагоните и интермодалните единици) са от най-голямо значение за експлоатацията на товарните влакове по европейската мрежа. Те позволяват извършването на оценка на съвместимостта на подвижния състав с инфраструктурата и допринасят за избягване на двойното въвеждане на данни, като това по-специално увеличава качеството на данните и те дават ясна картина на всички налични инсталации и оборудване във всеки един момент, което позволява вземането на бързи решения по време на експлоатацията.

4.2.10.2.   Справочни бази данни за подвижния състав

Ползвателят на подвижния състав е отговорен за съхраняването на данните за подвижния състав в справочна база данни.

Информацията, която трябва да бъде включена в индивидуалните справочни бази данни за подвижния състав, е описана в приложение I, допълнение В. Те трябва да съдържат всички елементи за:

—

Идентификация на подвижния състав,

—

Оценка на съвместимостта с инфраструктурата,

—

Оценка на съответните товарни характеристики,

—

Съответни спирачни характеристики,

—

Данни за поддръжката и ремонта,

—

Характеристики във връзка с околната среда.

Справочните бази данни за подвижния състав трябва да дават възможност за лесен достъп (единен общ достъп чрез общ интерфейс) до техническите данни и по този начин да свеждат до минимум обема на предаваните данни при всяка операция. Въз основа на структурираните права за достъп в зависимост от правомощията, съдържанието на тези бази данни трябва да бъде достъпно за всички доставчици на услуги (УИ, ЖПП, доставчиците на логистични услуги и управителите на ж.п. паркове), по-специално с цел управление на парка и поддържане на подвижния състав.

Въвежданите данни в справочната база данни за подвижния състав могат да бъдат групирани както следва:

—

Административни данни във връзка със сертифицирането и регистрирането, по-специално файлът за регистрация „ЕО“, информация относно нотифицирания орган и т. н.; тези данни могат да включват архивни данни във връзка със собствеността, наемните отношения и др. Също така, съгласно Регламент ЕС 445/2011 на Комисията, член 5, стопаните на вагони могат да записват сертификационния номер на отговарящата за поддръжката и ремонта организация (ECM) в индивидуалните справочни бази данни за подвижния състав. Вземат се под внимание следните елементи:

—

Сертифициране „ЕО“,

—

Регистрацията в държавата по произход,

—

Дата на пускане в експлоатация в държавата по регистрация,

—

Регистрация в други държави с цел използване на техните национални мрежи,

—

Сертифицирне за безопасност на подвижния състав, която не съответства на ТСОС „Подвижен състав“.

Ползвателят е длъжен да осигурява разполагаемост на тези данни и провеждане на свързаните с тях процедури.

—

Проектни данни, които трябва да включват всички съставни (физически) елементи на подвижния състав, включително характеристиките, свързани с околната среда, както и цялата информация, която се очаква да остане валидна по време на целия период на експлоатация на подвижния състав — тази част може да включва информация относно историята на извършени значителни промени, важните ремонти, основен ремонт и др.

4.2.10.3.   Оперативни данни за подвижния състав

Освен справочните данни за подвижния състав, най-важно значение за целите на експлоатацията имат данните, показващи реалното състояние на подвижния състав.

Тази информация включва данни с временен характер, като например ограниченията, текущите и планираните дейности за ремонт и поддръжка, километража, авариите и т. н.; а също и всички данни, отнасящи се за състоянието (временни ограничения на скоростта, изолирани спирачки, необходими ремонти и описания на авариите, и т. н.).

Във връзка с използването на оперативните данни за подвижния състав трябва да се имат предвид три отделни потребителя, като се имат предвид различните страни, носещи отговорността за подвижния състав по време на транспортните дейности:

—

Железопътното предприятие, което носи отговорност докато транспортът е под негов контрол,

—

Ползвателят на подвижния състав, и

—

Ползвателят (наемателят) на подвижния състав.

По отношение на всичките три участващи страни оперативните данни за подвижния състав трябва да бъдат достъпни за съответния упълномощен потребител, в зависимост от предварително определените му права за достъп, посредством идентификатора на вагона, тоест неговия номер.

Оперативните данни за подвижния състав са част от Оперативната база данни за вагоните и интермодалните единици, описана в глава 4.2.11.2 Други бази данни.

4.2.11.   Разни справочни файлове и бази данни

4.2.11.1.   Справочни файлове

За експлоатацията на товарните влакове по европейската мрежа следните справочни файлове трябва да бъдат на разположение на всички доставчици на услуги (УИ, ЖПП, доставчици на логистични услуги и управители на ж.п. паркове). Данните трябва да представят действителното състояние във всеки един момент. В случай, че даден справочен файл се използва съвместно и за нуждите по ТСОС „Телематични приложения за пътнически услуги“ [2], допълнителното разработване и измененията трябва да бъдат съгласувани с ТСОС „Телематични приложения за пътнически услуги“ [2], с оглед постигане на оптимални синергии.

Файлове, които се съхраняват и управляват локално:

а)

Справочен файл за аварийните услуги, свързани с вида опасни товари.

Файлове, които се съхраняват и управляват централизирано:

б)

Справочен файл за кодиране на всички дружества, които са УИ, ЖПП и доставчици на услуги,

в)

Справочен файл за кодиране на клиентите на железопътни товарни превози,

г)

Справочен файл за кодиране на местоположенията (първични и допълнителни),

Европейската железопътна агенция ще съхранява копие на справочния файл за кодовете за местоположение и фирмените кодове. По индивидуално искане и без това да засяга правата за интелектуална собственост, тези данни ще са публично достъпни.

Други кодови списъци са дефинирани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.11.2.   Други бази данни

За да може да се извършва проследяване на движението на влака и вагоните, необходимо е да се инсталират посочените по-долу бази данни и те да се актуализират в реално време при всяко важно събитие. Упълномощените организации като стопаните на вагони и управителите на ж.п. паркове трябва да имат достъп до необходимите данни при изпълнение на своите функции, в съответствие с двустранни споразумения.

—

Оперативна база данни за вагоните и интермодалните единици,

—

Пътен план за вагон/интермодална единица

Тези бази данни трябва да бъдат достъпни чрез общия интерфейс (глави 4.2.12.1: Цялостна архитектура и 4.2.12.6: Общ интерфейс).

По отношение на интермодалния транспорт в съобщенията с данни, съдържащи идентификаторите на товарните транспортни единици (напр. контейнери, сменяеми контейнери — swap-bodies, полуремаркерта) се използва или BIC код, или ILU код, съответно по ISO 6346 или EN 13044.

Оперативна база данни за вагоните и интермодалните единици

Комуникацията между водещото ЖПП и другите ЖПП в режим на сътрудничество се базира на номерата на вагоните и/или на интермодалните единици. Следователно ЖПП, което комуникира с различните УИ по отношение на даден влак, трябва да направи разбивка на тази информация, така че тя да бъде съотнесена с отделните вагони и интермодални единици. Тази отнасяща се за вагоните и интермодалните единици информация трябва да се съхранява в Оперативната база данни за вагоните и интермодалните единици. Информацията относно движението на влаковете води до нови въвеждания/актуализации в Оперативната база данни за вагоните и интермодалните единици за информация на клиентите. Свързаната с движението част от данните за даден вагон или интермодална единица в базата данни се създава най-късно когато се получи времето на освобождаване на вагона или интермодалната единица от клиента. Този час на освобождаване е първата информация за движението на вагона, въведена в Оперативната база данни за вагоните и интермодалните единици във връзка с дадено реално транспортно пътуване. Съобщенията относно движението на вагоните са дефинирани в глави 4.2.8 (Движение на вагоните) и 4.2.9 (Отчитане на прехвърляне). Тази база данни трябва да бъде достъпна чрез Общия интерфейс (глави 4.2.12.1: Цялостна архитектура и 4.2.12.6: Общ интерфейс).

Оперативната база данни на вагоните и интермодалните единици е най-важната такава за проследяване на вагоните и следователно за комуникациите между участващите ЖПП и водещото ЖПП. Тази база данни показва движението на даден вагон или интермодална единица от момента на тръгване до крайното доставяне на коловозите на клиента, заедно с данни за ОЧПР и действителните часове на пристигане в различни местоположения до ОЧП за крайната доставка. Тя представя също така различните видове състояние на подвижния състав, като например:

—

Състояние: товарене на подвижния състав

Това състояние е необходимо за обмена на информация между ЖПП и различните УИ, както и с други участващи в транспортния процес железопътни предприятия.

—

Състояние: натоварен вагон на път

Това състояние е необходимо за обмена на информация между УИ и съответното ЖПП, както и с други управители на инфраструктура и други участващи в транспортния процес железопътни предприятия.

—

Състояние: празен вагон на път

Това състояние е необходимо за обмена на информация между УИ и съответното ЖПП, както и с други управители на инфраструктура и други участващи в транспортния процес железопътни предприятия.

—

Състояние: разтоварване на подвижния състав

Това състояние е необходимо за обмена на информация между ЖПП, действащо при местоназначението и водещото ЖПП за превоза.

—

Състояние: празен вагон, под контрола на управителя на ж.п. парк

Това състояние е необходимо за получаване на информация относно разполагаемостта на вагон с определени характеристики.

Бази данни относно пътния план на вагоните

Влаковете могат да са композирани с вагони за различни клиенти. За всеки вагон водещото ЖПП (т.е. ЖПП, което действа като обединител на транспортната услуга) трябва да изготвя и актуализира пътен план, съответстващ на влаковия маршрут на ниво влак. Възприемането на нови маршрути за даден влак— например в случай на прекъсване на услугата — налага ревизиране на пътните планове на съответните вагони. Датата и часа на създаване на пътния план е датата и часа на получаване на товарителницата от клиента.

Пътните планове на вагоните трябва да бъдат съхранени от всяко водещо ЖПП в съответна база данни, Тези бази данни трябва да са достъпни чрез Общия интерфейс (глави 4.2.14.1: Цялостна архитектура и 4.2.12.6: Общ интерфейс).

Забележка:

Освен отбелязаните по-горе задължителни бази данни, всеки УИ може да създаде база данни относно влаковете.

Тази база данни на управителя на инфраструктура съответства на Оперативната база данни за вагоните и интермодалните единици. Тя съдържа основно данните, които съответстват на предаваното от ЖПП съобщение за влаковата композиция. Всички промени относно влака налагат актуализирането на тази отнасяща се за влаковете база данни. Също така е възможно тази информация да се записва в базата данни относно маршрута (глава 4.2.2: Заявка за маршрут). Тези бази данни трябва да са достъпни чрез Общия интерфейс (глави 4.2.12.1: Цялостна архитектура и 4.2.12.6: Общ интерфейс).

4.2.11.3.   Допълнителни изисквания относно базите данни

В следващите точки са изброени изисквания за функционални възможности, които трябва да бъдат поддържани от различните бази данни.

Те са:

1.

Заверка

Базата от данни трябва да осигурява удостоверяване на автентичността на потребителите на системите, преди те да получат достъп до базата от данни.

2.

Сигурност

Базата данни трябва да поддържа аспектите по осигуряване на сигурност, изразяващи се в контрол на достъпа до нея. Евентуалното криптиране на съдържанието на самата база данни не е задължително.

3.

Последователност

За избраната база от данни трябва да се прилага принципът ACID (Atomicity, Consistency, Isolation, Durability — завършеност, съгласуваност, изолираност и устойчивост).

4.

Контрол на достъпа

Базата данни трябва да разрешава достъп на потребителите или системите, които са упълномощени за това. Контролът на достъпа трябва да бъде прилаган до нивото на единичен атрибут на запис от данни. Той трябва да бъде конфигуриран в зависимост от потребителите за въвеждане, актуализиране или изтриване на данните.

5.

Проследяване

Базата данни трябва да поддържа проследяване на всички извършени промени, за да позволи проследяване на въвежданата информация (автор, предмет и момент на извършване на промяната).

6.

Стратегия за блокиране

Базата данни трябва да позволява прилагането на стратегия на блокиране, която да позволява достъпа до съдържанието ѝ дори когато други потребители в същия момент извършват промени в записаните данни.

7.

Едновременен достъп на няколко потребители

Базата данни трябва да поддържа едновременен достъп на няколко потребители или системи.

8.

Надеждност

Надеждността на базата от данни трябва да осигурява изискваната разполагаемост на данните.

9.

Разполагаемост

Достъпността на базата данни трябва да е такава, че заявките да бъдат удовлетворявани в най-малко 99,9 % от случаите.

10.

Пригодност за поддържане

Пригодността за поддържане на базата данни трябва да осигурява изискваната разполагаемост.

11.

Безопасност

Самите бази данни не са пряко свързани с безопасността. Следователно аспектите по безопасността не са от значение. Това обаче не означава, че самите данни — например ако са неверни или остарели — не могат да окажат влияние върху безопасността при експлоатацията на влака.

12.

Съвместимост

Базата от данни трябва да поддържа общоприет език за манипулиране на данни, като например SQL или XQL.

13.

Помощна програма за импортиране на данни

Базата от данни трябва да разполага с помощна програма, която да позволява импортирането на форматирани данни, използваеми за попълване на базата, вместо те да бъдат въвеждани ръчно.

14.

Помощна програма за експортиране на данни

Базата данни трябва да разполага с помощна програма, която да позволява експортирането на цялото ѝ съдържание или на част от него във форматиран вид.

15.

Задължителни полета

Базата данни трябва да съдържа задължителни полета, които да се попълват преди приемането на новите данни в базата.

16.

Контролиране на правдоподобността на данните

Базата от данни трябва да поддържа функция с възможност за конфигуриране на контрол за правдоподобността на данните преди да се потвърди въвеждането, актуализирането или изтриването на записи от данни.

17.

Време на отговор

Базата от данни трябва да реагира достатъчно бързо, така че потребителите да могат оперативно да въвеждат, актуализират или изтриват записи от данни.

18.

Аспекти на производителността

Справочните файлове и базите от данни трябва да осигуряват ефективно по отношение на разходите информационно търсене, необходимо за ефективно извършване на всички съответни движения на влакове, които попадат в обхвата на настоящата ТСОС.

19.

Аспекти относно капацитета

Базата данни трябва да позволява записването на необходимите данни за всички товарни вагони по цялата мрежа. Трябва да бъде възможно лесното увеличаване на капацитета (напр. чрез добавянето на още запаметяващи устройства и компютри). Увеличаването на капацитета не трябва да налага подмяна на подсистемата.

20.

Данни с исторически характер

Базата данни трябва да позволява управление на данните с исторически характер, тоест възможността за консултиране на данните, които вече са били архивирани.

21.

Стратегия за резервиране на данните (backup)

Стратегията за архивиране на данните трябва да гарантира възстановяването на всички данни максимум от последните 24 часа.

22.

Търговски аспекти

Използваната система трябва да бъде предлаган в търговската мрежа продукт или безплатен софтуер (с отворен код).

Забележки:

Горепосочените критерии трябва да бъдат прилагани от стандартна система за управление на бази данни (DBMS).

Използването на базите данни се основава на различните описани по-горе операции. Тяхното общо функциониране се базира на механизъм от въпроси/отговори, при който потребителят подава заявка за получаване на информация от базата данни чрез общия интерфейс (глави 4.2.12.1 Цялостна архитектура и 4.2.12.6: Общ интерфейс). Системата за управление на бази данни отговаря на тази заявка: тя или предоставя исканата информация, или отговаря, че не е налична никаква информация (информацията не съществува или достъпът до нея е отказан).

4.2.12.   Работа в мрежа и комуникации

4.2.12.1.   Цялостна архитектура

С течение на времето тази подсистема ще бъде изправена пред нарастване и взаимодействие на голяма и комплексна общност в областта на железопътната телематична оперативна съвместимост, със стотици участници (ЖПП, УИ ...), които ще се конкурират и/или сътрудничат при обслужване на пазарните потребности.

Мрежовата и информационна инфраструктура, обезпечаваща тази общност в областта на железопътната оперативна съвместимост, ще се базира на обща архитектура на информационния обмен, известна и възприета от всички участващи партньори.

Предложената архитектура на информационния обмен има следните характеристики:

—

проектирана е да съчетава хетерогенни информационни модели чрез семантично трансформиране на данните, които се обменят между системите, и чрез намаляване на различията между стопанските процеси и протоколите на ниво „приложение“;

—

има минимално въздействие върху съществуващите информационно-технологични (IT) архитектури, използвани от всеки от участниците;

—

не засяга вече направените инвестиции в областта на информационните технологии.

Архитектурата на информационния обмен се основава най-вече на взаимодействието между всички участници от типа Peer-to-Peer, като същевременно се гарантира общата цялост и съгласуваност на действията на общността в областта на железопътната оперативна съвместимост чрез предоставяне на пакет от централизирани услуги.

Моделът на взаимодействие Peer-to-Peer позволява да се направи най-доброто разпределение между различните участници на базата на действителното ползване на системата и като цяло ще поражда по-малко проблеми във връзка с различията в мащаба. Графично представяне на цялостната архитектура е дадено в документа „ТСОС ТПТП — Приложение А.5 Фигури и диаграми на последователността на съобщенията по ТСОС ТПТП“, глава 1.5, който документ е включен в списъка в допълнение I.

4.2.12.2.   Мрежа

Терминът „работата в мрежа“ в настоящия текст означава метода и философията на комуникация, а не физическа мрежа.

Оперативната съвместимост в железопътния транспорт се основава на обща архитектура на информационния обмен, известна и възприета от всички партньори, като по този начин се насърчава и се намаляват съответните препятствия за присъединяването на нови участници, по-специално клиентите.

Аспектите относно сигурността не се реализират на мрежово ниво (ВЧМ — виртуална частна мрежа, тунелиране и т.н.), а чрез обмена и използването на съобщения с вътрешно присъща сигурност. Следователно не е необходимо да се използва ВЧМ (управлението на този тип мрежа в толкова голям мащаб би било сложно и скъпо) и по този начин се избягват проблемите, свързани с отговорностите и разпределението на собствеността. Тунелирането не се счита за необходимо за постигане на подходящото ниво на сигурност.

При все това, ако някои участници вече разполагат или желаят да въведат различни нива на сигурност в избрани сектори от мрежата, те могат да го направят.

В публичната мрежа Интернет е възможно да се приложи хибриден модел Peer to Peer с общ интерфейс във всеки възел на участник и централен сертифициращ орган.

След това между съответните участници се осъществява комуникация от вида с равноправни възли (Peer to Peer).

Комуникацията от вида с равноправни възли (Peer to Peer) се базира на технически стандарти за общ интерфейс, описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.

4.2.12.3.   Сигурност

За да се постигне високо ниво на сигурност информацията, съдържаща се в съобщенията, трябва да бъде защитена и получателят трябва да има възможност да провери тяхната автентичност. Това осъществи чрез използването на система за криптиране и на подписи, подобно на системата, използвана за криптиране на електронна поща.

4.2.12.4.   Криптиране

Трябва да се използва или асиметрично криптиране или хибридно решение на базата на симетрично криптиране с публичен ключ, тъй като използването на един и същ секретен ключ от много участници в даден момент ще доведе до проблеми. По-високо ниво на сигурност може да се постигне лесно, ако всеки участник поеме отговорност за своя собствен чифт ключове, независимо че това налага високо ниво на цялостност на централния архив (сървъра за ключовете).

4.2.12.5.   Централен архив

Централният архив трябва да осигурява:

—

метаданни — структурираните данни, описващи съдържанието на съобщенията,

—

инфраструктура с публичен ключ (PKI),

—

сертифициращ орган (СА),

Отговорността за управлението на централния архив трябва да се възложи на нетърговска общоевропейска организация. В случай, че централният архив се използва съвместно и за нуждите по ТСОС „Телематични приложения за пътнически превози“ [2], разработването на изменения трябва да бъде съгласувано с ТСОС „Телематични приложения за пътнически услуги“ [2], с оглед постигане на оптимални синергии.

4.2.12.6.   Общ интерфейс

Общият интерфейс е задължителен за всеки участник, желаещ да се присъедини към общността за оперативна съвместимост в железопътния транспорт.

Общият интерфейс трябва да може да осигурява:

—

форматиране на изходящи съобщения в съответствие с метаданните,

—

подписване и криптиране на изходящи съобщения,

—

адресиране на изходящите съобщения,

—

проверка на автентичността на входящите съобщения,

—

декриптиране на входящите съобщения,

—

проверки за съответствие на входящите съобщения по отношение на метаданните,

—

общ единен достъп до различните бази данни.

Всяка инстанция на Общия интерфейс ще има достъп до всички данни, изискващи се съгласно настоящата ТСОС, в рамките на всеки ползвател на вагони, всяко водещо ЖПП, всяко ЖПП, всеки УИ и т.н., независимо дали съответните бази данни са централни или индивидуални (вж. също документа „ТСОС ТПТП — Приложение А.5 Фигури и диаграми на последователността на съобщенията по ТСОС ТПТП“, глава 1.6, който документ е включен в списъка в допълнение I).

В случай, че даден справочен файл се използва съвместно и за нуждите по ТСОС „Телематични приложения за пътнически услуги“ [2], допълнителното разработване и измененията трябва да бъдат съгласувани с ТСОС „Телематични приложения за пътнически услуги“ [2], с оглед постигане на оптимални синергии. На база резултатите от проверката за автентичност на входящите съобщения, може да бъде въведено минимално ниво на потвърждение за получено съобщение както следва:

i)

положително потвърждение за получено съобщение,

ii)

отрицателен отговор за неполучено съобщение.

Общият интерфейс управлява горепосочените задачи, като използва информацията от централния архив.

Участникът може да използва местен „огледален сървър“ на централния архив, за да скъси времената за реакция.

4.3.   Функционални и технически спецификации на интерфейсите

В светлината на съществените изисквания в глава 3, функционалните и технически спецификации на интерфейсите са както следва:

4.3.1.   Интерфейси с ТСОС „Инфраструктура“

Инфраструктурната подсистема включва системите за управление на движението, проследяване и навигация: технически устройства за обработка на данни и телекомуникации, предназначени за използване при услугите по превоз на пътници и товари на далечно разстояние по железопътната мрежа, с оглед да се гарантира безопасна и безпроблемна експлоатация на железопътната мрежа, както и ефективното управление на движението.

Подсистемата „Телематични приложения за товарни превози“ използва необходимите за оперативни цели данни, както са посочени в маршрутния договор, с възможни допълнения от данни за ограниченията на инфраструктурата, както са дадени от УИ. Следователно не съществува пряк интерфейс между настоящата ТСОС и ТСОС„Инфраструктура“.

4.3.2.   Интерфейси с ТСОС „Контрол/управление и сигнализация“

Единствената връзка с ТСОС „Контрол/управление и сигнализация“ е посредством

—

маршрутния договор, в който е дадена съответната информация относно оборудването за контрол, управление и сигнализация, използвано в съответния участък от линията, и

—

разни справочни бази данни за подвижния състав, в които трябва да се съхраняват данните относно оборудването за контрол, управление и сигнализация на подвижния състав.

4.3.3.   Интерфейси с подсистема „Подвижен състав“

В подсистемата „Телематични приложения за превоз на товари“ се идентифицират техническите и оперативните данни, които трябва да бъдат на разположение по отношение на подвижния състав.

В ТСОС „Подвижен състав“ са определени характеристиките на даден вагон. Когато те се променят, справочните бази данни относно подвижния състав трябва да бъдат актуализирани в съответствие с процедурата, прилагана относно поддръжката на базите данни. Следователно не съществува никакъв пряк интерфейс между настоящата ТСОС и ТСОС „Подвижен състав“.

4.3.4.   Интерфейси с ТСОС „Експлоатация и управление на трафика“

Подсистемата „Експлоатация и управление на трафика“ уточнява процедурите и съответното оборудване, позволяващи съгласуваното взаимодействие на различните структурни подсистеми както при нормално, така и при влошено функциониране, и основно засяга управлението на влаковете, планирането и управлението на трафика.

Подсистемата „Телематични приложения за превоз на товари“ включва главно приложенията, свързани с услугите по превоз на товари, по-специално мониторинга в реално време на товарите и влаковете и управлението на връзките с други видове транспорт.

С цел осигуряване на съгласуваното функциониране на двете ТСОС се прилага следната процедура.

Когато се съставят и/или изменят спецификации към ТСОС „Експлоатация и управление на движението“, свързани с разпоредбите на настоящата ТСОС, трябва да се провеждат консултации с органа, отговарящ за настоящата ТСОС.

Също така в случай на промяна на спецификациите на настоящата ТСОС, свързани с разпоредбите, определени в ТСОС „Експлоатация и управление на движението“, трябва да се провеждат консултация с органа, отговарящ за ТСОС „Експлоатация и управление на движението“.

4.3.5.   Интерфейси с подсистемата „Телематични приложения за пътнически превози“

Интерфейс

Точка в ТСОС „Телематични приложения за товарни превози“

Точка в ТСОС „Телематични приложения за пътнически превози“

Влакът е готов

4.2.3.3

Съобщение „Влакът е готов“

4.2.14.1

Съобщение „Влакът е готов“ за всички видове влакове

Прогноза за движението на влака

4.2.4.2

Съобщение за прогноза за движението на влака

4.2.15.2

Съобщение „Прогноза за движението на влака“ за всички видове влакове

Съобщение за информиране относно движението на влака

4.2.4.3

Съобщение с информация за движението на влака

4.2.15.1

Съобщение „Информация за движението на влака“ за всички видове влакове

Съобщение до УИ за прекъснато движение на влака

4.2.5.2

Прекъснато движение на влака

4.2.16.2

Съобщение „Прекъснато движение на влака“ за всички видове влакове

Третиране на краткосрочни данни относно разписанието

4.2.2

Искане за маршрут

4.2.17

Третиране на краткосрочни данни относно разписанието на влаковете

Общ интерфейс

4.2.12.6

Общ интерфейс

4.2.21.7

Общ интерфейс за комуникации ЖПП/УИ

Централен архив

4.2.12.5

Централен архив

4.2.21.6

Централен архив

Справочни файлове

4.2.11.1

Справочни файлове

4.2.19.1

Справочни файлове

4.4.   Правила за експлоатация

Във връзка със съществените изисквания в глава 3, по-долу са представени правилата относно експлоатацията на подсистемата, разгледана в настоящата ТСОС.

4.4.1.   Качество на данните

С цел осигуряване на качеството на данните, авторът на дадено съобщение носи отговорност за верността на данните в съобщението към момента на изпращането му. Когато изходните данни, които могат да послужат за целите на осигуряване на качеството, са налични в базите данни, предоставени с ТСОС, необходимо е за осигуряване на качеството на данните да бъдат използвани именно данните от тези бази данни.

Ако в предоставените с ТСОС бази данни липсват такива изходни данни, които да послужат за осигуряване на качеството, авторът на съобщението трябва да провери качеството на данните въз основа на свои собствени ресурси.

Осигуряването на качеството на данните включва също така сравнение, където това е приложимо, с информацията, съдържаща се в свързаните с ТСОС бази данни, и проверка на навременността и последователността на данните и съобщенията.

Данните са с високо качество, когато са подходящи за употребата, за която са предназначени, тоест:

—

не съдържат грешки: те са достъпни, точни, съответстващи по време, пълни, в съответствие с данните от други източници и т.н., и

—

притежават желаните характеристики: те са съответстващи, пълни, достатъчно подробни, лесни за четене и за тълкуване и т.н.

Качеството се основава на следните основни критерии:

—

Точност,

—

Пълнота,

—

Съгласуваност,

—

Навременност.

Точност:

Събирането на необходимата информация (данни) трябва да бъде с възможно най-малки разходи. Това може да се постигне единствено с еднократно записване на първичните данни за целия транспорт, ако това е възможно. Поради това първичните данни следва да бъдат въвеждани в системата със стойности колкото е възможно по-близки до тези в източника, така че да могат да бъдат изцяло използвани при всякаква последваща обработка.

Пълнота:

Преди да се изпрати съобщението е необходимо неговата пълнота и синтаксис да се проверят въз основа на метаданните. Благодарение на това също така се избягва ненужният информационен поток по мрежата.

Всички входящи съобщения трябва също да бъдат проверявани за пълнота въз основа на метаданните.

Съгласуваност:

Необходимо е да бъдат прилагани работни правила за осигуряването на съгласуваност. Следва да се избягва двойното въвеждане и притежателят на данните трябва да е ясно идентифициран.

Начинът на прилагане на тези работни правила зависи от тяхната сложност. По отношение на простите правила са достатъчни ограниченията и разпоредбите, прилагани относно базите от данни. Когато правилата са по-сложни и включват данни от различни таблици, трябва да се прилагат процедури за валидиране, с цел да се проверява съгласуваността на данните, преди генерирането на интерфейсни данни и преди новата версия на данните да влезе в действие. Също така е необходимо да се проверява дали валидирането на предадените данни отговаря на дефинираните работни правила.

Навременност:

Важен въпрос е информацията да се осигурява навреме. Доколкото записването на данните и изпращането на съобщенията зависят пряко от информационно-технологичната система, навременното изпращане не представлява никакъв проблем, когато системата е добре замислена в зависимост от нуждите на работните процеси. В повечето случаи обаче изпращането на съобщението се извършва от оператор или най-малкото включва намесата на оператор (например изпращането на съобщение за влаковата композиция или актуализирането на данните относно влака или вагона). За да се спазват изискванията за навременност, необходимо е данните да се актуализират в най-кратки срокове, за да се гарантира че автоматично изпращаните от системата съобщения съдържат верните данни.

Показатели за качеството на данните

Що се отнася до пълнотата на задължителните данни (процент на попълнените полета за данни) и непротиворечивостта на данните (процент на съответствие на данните в таблици/файлове/записи), необходимо е да се постигне 100 % пълнота.

По отношение на навременността на данните (процент на данните, които са разполагаеми в определен прагов времеви интервал), процентът трябва да достига 98 %. Доколкото в настоящата ТСОС не са определени такива прагови стойности, те трябва да бъдат определени в договора между участващите страни.

Изискваната точност (процент на записаните данни, които са верни в съпоставка с реалните стойности) трябва да надхвърля 90 %. Точните стойности и критериите трябва да бъдат определени в договора между участващите страни.

4.4.2.   Управление на централния архив

Функциите на централния архив са определени в глава 4.2.12.5 Централен архив. За целите на осигуряване на качеството на данните, органът, поддържащ централния архив, трябва да бъде отговорен за актуализирането и качеството на метаданните, както и за администрирането на контрола върху достъпа. По отношение на качеството на метаданните от гледна точка на пълнота, непротиворечивост, навременност и точност, той трябва да осигури правилно функциониране за целите на настоящата ТСОС.

4.5.   Правила за поддръжка

Във връзка със съществените изисквания в глава 3, по-долу са представени правилата за поддръжка на подсистемата по настоящата ТСОС както следва:

Необходимо е качеството на транспортните услуги да бъде гарантирано дори в случай на пълна или частична повреда на оборудването за обработка на данните. Следователно е препоръчително инсталирането на дублиращи системи или компютри, които имат изключително високо ниво на надеждност и които могат да гарантират непрекъсваемост на услугата по време на периодите на ремонт.

Аспектите, свързани с поддръжката на различните бази данни, са посочени в глава 4.2.11.3 (Допълнителни изисквания относно базите данни), точки 10 и 21.

4.6.   Професионални квалификации

Професионалните квалификации на персонала, необходими за осигуряване на експлоатацията и поддръжката на подсистемата и за прилагане на ТСОС, са както следва:

Прилагането на настоящата ТСОС не изисква придобиването на нова компютърна техника и програмно осигуряване, или наемането на нов персонал. Тя налага само извършването на промени, актуализиране или разширяване на операциите, извършвани от съществуващия персонал. Следователно няма никакви допълнителни изисквания към националните и европейското законодателство по отношение на професионалната квалификация.

Допълнителното обучение на персонала, ако такова е необходимо, не трябва да се ограничава само до усвояване на функционирането на оборудването. Персоналът трябва също така да познава и разбира специфичната роля, която играе в цялостния транспортен процес. По-специално той трябва да осъзнава необходимостта от поддържане на високо ниво на качество на работата, тъй като става дума за елемент с определяща роля за надеждността на информацията, която впоследствие ще трябва да бъде обработвана.

Професионалните квалификации, необходими при композирането и експлоатацията на влаковете, са определени в ТСОС „Експлоатация и управление на движението“.

4.7.   Здравословни и безопасни условия

Съществуват следните условия относно опазването на здравето и безопасността на персонала, които трябва да се спазват по време на експлоатацията и поддръжката на съответната подсистема (или област на техническо приложение, определена в параграф 1.1) и при прилагането на ТСОС:

Няма никакви допълнителни изисквания към националните и европейското законодателство по отношение на опазването на здравето и безопасността.

5.   СЪСТАВНИ ЕЛЕМЕНТИ НА ОПЕРАТИВНАТА СЪВМЕСТИМОСТ

5.1.   Определение

Съгласно член 2, буква е) от Директива 2008/57/ЕО [1],

съставни елементи на оперативната съвместимост са: „всеки елементарен компонент, група от компоненти, подкомплект или комплект от оборудване, включени или предназначени за включване в подсистема, от която оперативната съвместимост на железопътната система зависи пряко или косвено. Понятието „съставен елемент“ включва както материални обекти, така и нематериални обекти, като например софтуер“.

5.2.   Списък на съставните елементи

Съставните елементи на оперативната съвместимост се разглеждат в съответните разпоредби на Директива 2008/57/ЕО [1].

По отношение на подсистемата „Телематични приложения за товарни превози“ няма определени съставни елементи на оперативната съвместимост.

За изпълнението на изискванията на настоящата ТСОС е необходимо само стандартно информационно-технологично оборудване, без каквито и да са специфични аспекти във връзка с областта на железопътния транспорт. Това се отнася за използваните хардуерни компоненти и стандартен софтуер, като например операционна система и бази данни. Приложният софтуер е индивидуален за всеки ползвател и може да бъде адаптиран и подобряван в съответствие с функционалността и нуждите на всеки от тях. В предлаганата „архитектура за интегриране на приложни програми“ е прието, че при различните приложни програми не се използва един и същ вътрешен информационен модел. Интегрирането на приложните програми се дефинира като процес, осигуряващ съвместната работа на приложни програми, проектирани независимо една от друга.

5.3.   Работни показатели и спецификации на съставните елементи

Вж. глава 5.2., въпросът не е от значение във връзка с ТСОС „Телематични приложения за товарни превози“.

6.   ОЦЕНКА НА СЪОТВЕТСТВИЕТО И/ИЛИ ГОДНОСТТА ЗА ИЗПОЛЗВАНЕ НА СЪСТАВНИТЕ ЕЛЕМЕНТИ И ПРОВЕРКА НА ПОДСИСТЕМАТА

6.1.   Елементи на оперативна съвместимост

6.1.1.   Процедури за оценка

Процедурата по оценяване на съответствието или на пригодността за употреба на съставните елементи на оперативната съвместимост трябва да се основава на европейските спецификации или на спецификациите, приети по силата на Директива 2008/57/EО [1].

Що се отнася до пригодността за употреба, в тези спецификации се посочват всички параметри, които трябва да бъдат измервани, подложени на мониторинг или наблюдавани, и се описват методите за изпитване и процедурите за измерване, които трябва да се прилагат, независимо дали става дума за симулация в лабораторни условия или за реални железопътни условия.

Процедури по оценяване на съответствието и/или на пригодността за употреба:

Списък на спецификациите, описание на изпитвателните методи:

Не са от значение във връзка с ТСОС „Телематични приложения за превоз на товари“.

6.1.2.   Модул

По искане на производителя или на установен в Общността негов представител, изпитвателната процедура се провежда от нотифициран орган, в съответствие с разпоредбите за необходимите модули, описани в Решение 2010/713/ЕС на Комисията, така както те са определени, изменени и допълнени в допълнението към настоящата ТСОС.

Модулите трябва да бъдат комбинирани и използвани в зависимост от изпитвания елемент.

Не са от значение във връзка с ТСОС „Телематични приложения за товарни превози“.

6.1.3.   Подсистема „Телематични приложения за товарни превози“

По искане на възложителя или на неговия упълномощен представител на територията на Общността, нотифицираният орган прилага процедурата по проверка „ЕО“ съгласно приложение VI към Директива 2008/57/ЕО [1].

Съгласно приложение II към Директива 2008/57/ЕО [1] подсистемите се разделят в структурна и функционална области.

Оценяването на съответствието е задължително за техническите спецификации за оперативна съвместимост в структурната област. Подсистемата „Телематични приложения за товарни превози“ е част от функционалната област и настоящата ТСОС не определя никакви модули за извършване на оценка на съответствието.

От друга страна, централният архив и общият интерфейс на всеки възел на участниците образуват опорната мрежа на интегрирането на приложението. Моделът за обмен на информация се съдържа в централния архив, интегриращ приложението, който съдържа метаданните на интерфейса в рамките на едно физическо местоположение. Метаданните съдържат информация за съдържанието на комуникацията (за това, което се изпраща), идентификационна информация за точките на комуникация на изпращачите и получателите и търговските протоколи на ниво приложение, участващи в процеса на интеграция.

От значение са следните особености:

—

Централният архив съдържа също така и данните относно сертифициращия орган (Отворена инфраструктура с публичен ключ и сертифициращ орган — Open CA PKI). Това е главно администраторска дейност, която се прилага физически. Погрешните въвеждания се откриват незабавно. Не е необходима никаква процедура по оценка.

—

Централният архив съдържа метаданните на съобщенията (съгласно документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП, включен в списъка в допълнение I“) като база за обмен на съобщения в разнородна информационна среда. Метаданните трябва да бъдат администрирани и актуализирани в рамките на този архив. Всяка несъвместимост в структурата на съобщенията или съдържанието им се открива своевременно и предаването се отказва. Не е необходима никаква процедура по оценка.

—

Общият интерфейс на всеки възел на участниците съдържа основно местния „огледален сървър“ на централния архив, който служи за скъсяване на сроковете на отговор и намаляване на заетостта на архива. Необходимо е да се следи версиите на данните в този архив и в общия интерфейс да бъдат винаги еднакви. За тази цел данните трябва да се актуализират на централно ниво, като новите версии се изтеглят от това ниво. Не е необходима никаква процедура по оценка.

7.   ПРИЛАГАНЕ

7.1.   Изисквания относно прилагането на настоящата ТСОС

7.1.1.   Въведение

Настоящата ТСОС се отнася до подсистемата „Телематични приложения за товарни превози“. Съгласно приложение II към Директива 2008/57/ЕО [1], тази подсистема е с функционален характер. Следователно прилагането на настоящата ТСОС не се основава на концепция за нова, обновена или модернизирана подсистема, както е обичайно за техническите спецификации за оперативна съвместимост относно структурни подсистеми, освен когато това е посочено в ТСОС.

Настоящата ТСОС се въвежда поетапно както следва:

—

първи етап подробни ИТ спецификации и генерален план;

—

втори етап: разработване;

—

трети етап: внедряване.

7.1.2.   Първи етап — подробни ИТ спецификации и генерален план,

Спецификациите на функционалните изисквания, които се използват за основа на горепосочената техническа архитектура по време на разработването и внедряването на компютризираната система, са дадени в допълнения A—Е, включени в списъка в допълнение I към настоящия регламент.

Задължителният генерален план от концепцията до предаването на компютризираната система, който се основава на Стратегическия европейски план за развитие (SEDP), подготвен от железопътния сектор, включва компонентите на базовата архитектура на системата и установяването на основните дейности, които следва да бъдат изпълнени.

7.1.3.   Етап 2 и 3 — Разработване и внедряване

Железопътните предприятия, управителите на инфраструктури и стопаните на вагони разработват и внедряват компютризираната система на ТПТП в съответствие с разпоредбите в настоящата глава.

7.1.4.   Управление, роли и отговорности

Разработването и внедряването се поставят под управлението на структура за управление със следните участници.

Управляващ комитет

Управляващият комитет има следните роли и отговорности:

Управляващият комитет осигурява структурата за стратегическо управление с цел ефикасно да се управлява и координира работата по прилагането на ТСОС TПТП. Това включва определяне на политиката, стратегическото направление и приоритетите. В този процес управляващият комитет отчита също интересите на малките предприятия, новите участници и железопътните предприятия, предоставящи специализирани услуги.

Управляващият комитет наблюдава напредъка на прилагането. Той докладва редовно на Европейската комисия, най-малко четири пъти годишно, относно постигнатия напредък по отношение на генералния план. Управляващият комитет предприема необходимите действия за коригиране на горепосоченото разработване в случай на отклонение от генералния план.

1.

Управляващият комитет се състои от:

—

определените в член 3, параграф 2 от Регламент (ЕО) № 881/2004 на Европейския парламенти и на Съвета (1) представителни органи от железопътния сектор на европейско ниво (наричани по-долу „представителните органи от железопътния сектор“),

—

Европейската железопътна агенция, и

—

Комисията.

2.

Този управляващ комитет се председателства съвместно от а) Комисията и б) лице, предложено от представителните органи от железопътния сектор. Комисията, подпомогната от членовете на Управляващия комитет, изготвя правилник за дейността на този Управляващ комитет, който трябва да бъде приет от Управляващия комитет.

3.

Членовете на Управляващия комитет могат да предлагат на Управляващия комитет включването на други организации като наблюдатели, когато съществуват сериозни технически и организационни причини за това.

Заинтересовани страни

Железопътните предприятия, управителите на инфраструктури и стопаните на вагони създават ефективна структура за управление на проекта, която дава възможност за ефективно разработване и внедряване на системата ТПТП.

Горепосочените заинтересовани страни:

—

осигуряват необходимите усилия и ресурси за прилагането на настоящия регламент,

—

спазват принципите за достъп до общите компоненти на ТСОС ТПТП, които се предоставят на разположение на всички пазарни участници при унифицирана, прозрачна и с възможно най-ниска стойност на услугите структура,

—

гарантират, че всички пазарни участници имат достъп до всички обменяни данни, необходими за изпълнение на правните им задължения и за осъществяване на функциите им в съответствие с функционалните изисквания за ТСОС ТПТП,

—

защитават поверителността на отношенията с клиентите,

—

създават механизъм, който ще даде възможност на дошлите по-късно участници да се присъединят към разработването на TПТП и да се възползват от постигнатите разработки на TПТП, свързани с общите компоненти, по начин, удовлетворяващ едновременно горепосочените заинтересовани страни и новодошлите участници, по-специално с оглед на справедливото поделяне на разходите,

—

докладват на Управляващия комитет за ТПТП относно постигнатия напредък във връзка с плановете за прилагане. Това докладване включва също — в съответните случаи — и докладване на отклоненията от генералния план.

Представителни органи

Представителните органи от железопътния сектор на европейско ниво, определени в член 3, параграф 2 от Регламент (ЕО) № 881/2004, имат следните роли и отговорности:

—

представляват отделните заинтересовани страни, членуващи в тях, в Управляващия комитет за ТСОС TПТП,

—

повишават осведомеността на своите членове относно техните задължения във връзка с прилагането на настоящия регламент,

—

осигуряват на всички горепосочени заинтересовани страни своевременен текущ и пълен достъп до информация за състоянието на работата на Управляващия комитет и всички други групи с цел да се защитят интересите на всеки представител при прилагането на ТСОС TПТП,

—

осигуряват ефикасен информационен поток от отделните заинтересовани страни, членуващи в тях, към Управляващия комитет за ТПТП, за да бъде надлежно взет предвид интересът на заинтересованите страни при решенията, засягащи разработването и внедряването на ТПТП,

—

осигуряват ефикасен информационен поток от управителния комитет за ТППТ към отделните заинтересовани страни, членуващи в тях, за да бъдат надлежно информирани заинтересованите страни относно решенията, засягащи разработването и внедряването на ТППТ.

7.2.   Управление на измененията

7.2.1.   Процедура за управление на измененията

Процедурите за управление на измененията трябва да бъдат проектирани така, че да гарантират надлежен анализ на разходите и ползите от тези изменения и контролираното им осъществяване. Тези процедури се определят, въвеждат, поддържат и управляват от Европейската железопътна агенция и включват:

—

идентификация на техническите ограничения, които са в основата на измененията,

—

изявление кой носи отговорност за процедурите по осъществяване на измененията,

—

процедура по валидиране на измененията, които трябва да се осъществят,

—

политиката на управление на измененията, по тяхното прилагане, по извършване на прехода и по осигуряване на развитие,

—

разпределение на отговорностите за управление на подробните спецификации, както и за осигуряване на качеството им и управлението на конфигурирането.

Съветът за контрол на измененията (CCB — Change Control Board) включва Европейската железопътна агенция, представителни органи от железопътния сектор и национални органи по безопасността. Това участие на страните гарантира общ поглед върху измененията, които е необходимо да се направят, както и цялостна оценка на последиците от тях. Комисията може да добавя други страни към Съвета за контрол на измененията, ако тяхното участие се преценява като необходимо. Впоследствие Съветът за контрол на измененията ще премине под егидата на Европейската железопътна агенция.

7.2.2.   Специфична процедура за управление на измененията в документи, изброени в допълнение I към настоящия регламент

Управлението на измененията в документите, изброени в допълнение I към настоящия регламент, се въвежда от Европейската железопътна агенция в съответствие със следните критерии:

1.

Заявките за изменения в документите се представят или чрез националните органи по безопасността, или посредством представителните органи от железопътния сектор на европейско равнище, определени в член 3, параграф 2 от Регламент (ЕО) № 881/2004, или чрез Управляващия комитет за ТСОС TППТ. Комисията може да добавя и други изразяващи мнение страни, ако тяхното мнение се преценява като необходимо.

2.

Европейската железопътна агенция събира и съхранява заявките за изменения.

3.

Европейската железопътна агенция представя заявките за изменения на специализираната работна група към нея, която ги оценява и подготвя предложение, придружавано при необходимост от икономическа оценка.

4.

След това Европейската железопътна агенция представя заявката за изменение и съответното предложение на Съвета за контрол на измененията, който валидира или отхвърля заявката за изменение, или отлага вземането на решение по нея.

5.

Ако заявката за изменение не бъде валидирана, Европейската железопътна агенция съобщава на заявителя причината за отхвърлянето или поисква от него допълнителна информация относно заявката за изменение.

6.

Измененията в документите се правят въз основа на валидираните заявки за изменение.

7.

Европейската железопътна агенция представя на Комисията препоръка за актуализация на допълнение I, заедно с проект на новия текст на документа, заявките за изменение и тяхната икономическа оценка.

8.

Европейската железопътна агенция публикува на своята интернет страница проекта на новия текст на документа и валидираните заявки за промяна.

9.

След публикуване на актуализацията на допълнение I в Официален вестник на Европейския съюз, Европейската железопътна агенция публикува на своята интернет страница новия текст на документа.

Когато управлението на измененията засяга елементи, които се използват съвместно с ТСОС „Телематични приложения за пътнически услуги“ [2], измененията трябва да са съобразени в максималната възможна степен с тази вече прилагана ТСОС, за да се постигнат оптимални полезни взаимодействия.

(1)  Регламент (ЕО) № 881/2004 на Европейския парламент и на Съвета от 29 април 2004 г. за създаване на Европейска железопътна агенция („Регламент за създаване на Агенция“) (ОВ L 164, 30.4.2004 г., стр. 1).

Допълнение I

Списък на техническите документи

№

Означение

Заглавие

Версия

Дата

1

ERA-TD-100

ТСОС ТПТП — ПРИЛОЖЕНИЕ A.5: ФИГУРИ И ДИАГРАМИ НА ПОСЛЕДОВАТЕЛНОСТТА НА СЪОБЩЕНИЯТА ПО ТСОС ТПТП

2.0

17.10.2013 г.

2

ERA-TD-101

ТСОС на TППТ — Приложение Г.2: Допълнение A (Пътно планиране за вагони/интермодални товарни единици — ИТЕ)

2.0

17.10.2013 г.

3.

ERA-TD-102

ТСОС на TППТ — Приложение Г.2: Допълнение Б — Оперативна база данни за вагони и интермодални единици (WIMO)

2.0

17.10.2013 г.

4.

ERA-TD-103

ТСОС на TППТ — Приложение Г.2: Допълнение В — Справочни файлове

2.0

17.10.2013 г.

5.

ERA-TD-104

ТСОС на TППТ — Приложение Г.2: Допълнение Д — Общ интерфейс

2.0

17.10.2013 г.

6.

ERA-TD-105

ТСОС на TППТ — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС TППТ

2.0

17.10.2013 г.

Допълнение II

Терминологичен речник

Термин

Описание

Автомобилно извозване (Haulage)

Транспортиране с автомобил

Архив (Repository)

Архивът е подобен на база данни и речник на данни; обикновено включва обаче цялостна среда за система за управление на информацията. Той трябва да включва не само описания на структурите от данни (например обекти и елементи), но и метаданни, които представляват интерес за предприятието, формуляри за показване на данни върху екрана, отчети, програми и системи Обикновено той включва и вътрешен набор от софтуерни инструменти, система за управление на базата данни, метамодел, въведени метаданни и софтуер за зареждане и извличане, осигуряващ достъп до данните в архива.

ACID

Завършеност, съгласуваност, изолация, устойчивост

Става въпрос за четирите основни съставки на всяка трансакция:

 

Завършеност (Atomicity) При трансакция, в която участват най-малко два информационни елемента, или всички елементи се вземат под внимание, или нито един от тях.

 

Съгласуваност (Consistency) една трансакция или създава ново валидно състояние на данни, или при неуспех възстановява всички данни в началното им състояние.

 

Изолация (Isolation) трансакция, която е в процес на протичане и все още не е валидирана, трябва да остане изолирана от всяка друга трансакция.

 

Устойчивост (Durability) Валидираните данни се записват в системата по такъв начин, че да остават на разположение в нормално им състояние, дори при изключване и повторно пускане на системата.

Концепцията за ACID е описана в стандарта ISO/IEC 10026-1:1992 г., раздел 4. Всяко от горепосочените свойства може да бъде измерено спрямо базова стойност за сравнение. По принцип прилагането на тази концепция е задължение на управителя или следящия трансакцията. В разпределени системи един начин за прилагане на ACID е чрез валидиране на два етапа (2PC), което гарантира, че или всички участващи в трансакцията сайтове трябва да се ангажират с нейното завършване, или никой от тях — в такъв случай трансакцията се анулира

Бруто тегло на товара (Gross weight of load)

Заявено/действително общо тегло (маса) на стоките, включително опаковката, но без оборудването на превозвача.

Бърза заявка за маршрут (Short notice path request)

Означава отделната заявка за маршрут, подадена съгласно член 23 от Директива 2001/14/ЕО поради допълнителни искания за превоз или експлоатационни нужди.

Вагонен товар (Wagon load)

Единичен товар, при който единицата е вагон.

Влаков маршрут (Train path)

Пътят на влака, определен във времето и пространството.

Влаков маршрут/времеви интервал (Train Path/Slot)

Описание на пътя на влака по отношение на времето и местата (съгласно километричните указатели) в които пътуването ще започне и приключи, заедно с подробни данни за съответните места по пътя, през които той ще премине или ще спре в тях. Подробните данни могат да включват също евентуални дейности по време на пътуването на влака, като например смяна на влаковата бригада, на локомотива, или други съответни промени.

Водещо железопътно предприятие (Lead Railway Undertaking)

Отговорно железопътно предприятие, което организира и управлява транспортната линия в съответствие с ангажимента към клиента. То е единственото място за контактуване от страна на клиента. Ако транспортната верига включва участие на няколко железопътни предприятия, водещото ЖПП отговоря също така за координацията между различните железопътни предприятия. В случай на интермодален транспорт, клиентът може да бъде обединител на интермодална транспортна услуга.

Водещо ЖПП (LRU)

Вж. водещо железопътно предприятие

VPN

Виртуална частна мрежа (Virtual Private Network)

Терминът „виртуална частна мрежа“ се използва за описване на почти всеки вид система за дистанционно свързване, като например публичната телефонна мрежа и постоянните виртуални вериги за ретранслация на кадри (Frame Relay PVC's).

С въвеждането на Интернет терминът VPN стана синоним на дистанционното мрежово ползване на данни въз основа на IP. Просто казано, VPN се състои от две или повече частни мрежи, които комуникират по защитен начин по публична мрежа.

VPN може да съществува между отделна машина и частна мрежа (клиент до сървър) или между отдалечена локална мрежа и частна мрежа (сървър до сървър). Частните мрежи могат да се свързват чрез тунелиране. Дадена VPN обикновено използва Интернет като базова преносна мрежа, но с криприране на данните, изпращани между клиент VPN и шлюз VPN, така че те да не могат да бъдат четени ако бъдат прихванати по време на преноса им.

GGP

Gateway to Gateway Protocol (протокол за трансфер на данни между шлюзови устройства).

Вж. също IP

Дата/час на освобождаване (Release date/time)

Дата/часа, когато се очаква стоките да бъдат освободени или са били освободени от клиента.

Действителна дата/действителен час на заминаване (Departure date/time, actual)

Действителната дата (и действителния час) на заминаване на превозното средство.

Директен влак (Direct train)

Влак със съответни вагони, който се движи между две точки на товарене и разтоварване (първоначална изходна точка — крайно местоназначение) без междинно преразпределяне на вагоните.

Доставчик на услуги (Service Provider)

Превозвач, който отговаря за съответния специфичен етап от превоза. Страна, която е получила и ползва резервацията.

Единичен товар (Unit Load)

Няколко отделни пакета, които са свързани, палетизирани или завързани заедно, така че да образуват обща единица за по-ефективно манипулиране с механични съоръжения.

Цял влак (блок влак) (Unit train)

Товарен влак, изпратен само с една товарителница и само един вид стоки и който се състои от еднакви вагони, движещи се от изпращача до получателя без междинно преразпределяне на вагоните.

XDR (Външно представяне на данни)

External Data Representation (външно представяне на данни)

Протоколът XDR е специфициран в стандарта за външно представяне на данни [RFC1832].

XDR представлява стандарт за описание и криптиране на данни. Той е полезен за пренос на данни между компютри с различна архитектура. XDR съответства на представителния слой по ISO и е приблизително аналогичен по своето предназначение на X.409, ISO Abstract Syntax Notation. Основната разлика между тях е, че XDR използва неявно типизиране, докато X.409 използва явно типизиране. XDR използва език за описване на форматите на данните. Езикът може да се използва само за описване на данни; той не е програмен език. Този език дава възможност да се описват сложни формати на данни по кратък начин. Алтернативната възможност да се използват графични представяния (които сами по-себе си са неформален език) бързо става неразбираема при увеличение на сложността. Що се отнася до езика XDR, той е подобен на езика С. Протоколи като например ONC RPC (процедура за дистанционно повикване) и NFS (мрежов достъп до файлови системи) използват XDR за описване на формата на техните данни. В стандарта XDR се прави следното допускане: че байтовете (наричани още октети) са преносими, като един байт съдържа 8 бита данни. Дадено хардуерно устройство трябва да кодира байтовете в различни среди по такъв начин, че другите хардуерни устройства да могат да декодират байтовете без загуба на информация.

XQL

Extended Structured Query Language (разширен език за структурирани запитвания)

XML-RPC (протокол за отдалечено извикване на процедура)

XML-RPC е разширяем маркиращ езиков протокол за отдалечено извикване на процедура, който работи в Интернет. Той дефинира разширяем маркиращ езиков формат (XML формат) за съобщения, които се предават между клиенти и сървъри, използващи протокол за трансфер на хипертекст (HTTP). Дадено съобщение XML-RPC кодира или процедура, която да бъде извикана от сървъра заедно с параметрите, които да се използват при повикването, или резултата от повикване. Параметрите и резултатите от процедурата могат да бъдат скалари, числа, низове, дати и др.; също така те могат да бъдат комплексни структури със записи и списъци. В този документ е определено как да се използва BEEP (разширяем протокол за обмен на блокове) за пренос между клиенти и сървъри на съобщения, кодирани в XML-RPC формат.

Еталонен модел OSI (OSI reference model)

Стандартно описание на начина, по който следва да се предават съобщенията между всеки две точки от дадена мрежа. В модела OSI са дефинирани 7 слоя от функции, които се провеждат в края на дадена комуникация. Тези слоеве представляват единствената международно възприета рамка на стандарти за комуникация.

Железопътно предприятие — ЖПП (Railway Undertaking — RU)

Железопътно предприятие (съгласно Директива 2004/49/ЕО [9]) означава железопътно предприятие по смисъла на Директива 2001/14/ЕО, както и всяко друго публично или частно предприятие, чиято дейност се състои в осигуряване на железопътен превоз на товари и/или пътници, като предприятието трябва да осигурява теглителната сила; това включва и предприятия, които осигуряват само теглителна сила.

ЖПП

Вж. железопътно предприятие

Заинтересовани страни (Stakeholders)

Всяко лице или организация с основателен интерес към предоставянето на влакови услуги, като например:

 

Железопътно предприятие (ЖПП),

 

Организация, осигуряваща проследяване на експедирането,

 

Организация, осигуряваща локомотиви,

 

Организация, осигуряваща вагони,

 

Организация, осигуряваща машинисти/влакови бригади,

 

Организация, осигуряваща разпределителни паркове,

 

Организация, осигуряваща маневриране,

 

Обединител на услугата,

 

Организация, предоставяща времеви интервали (УИ),

 

Отговарящ за контролирането на влакове (УИ),

 

Управляващ движението,

 

Управител на подвижен състав,

 

Организация, осигуряваща фериботи,

 

Инспектор на вагони, локомотиви,

 

Организация, осигуряваща ремонт на вагони, локомотиви,

 

Управляващ експедирането,

 

Организация, осигуряваща маневрирането и разпределянето,

 

Организация, осигуряваща логистични услуги,

 

Получател,

 

Изпращач,

Допълнителни термини при интермодален транспорт:

 

Организация, осигуряваща контейнери,

 

Оператор на интермодален терминал,

 

Организация, осигуряваща товарно-транспортни операции/дружество, изпълняващо автомобилно извозване,

 

Организация, осигуряваща транспорт по вода,

 

Организация, осигуряваща баржови линии.

Заявител (Applicant)

Означава железопътно предприятие или международна група железопътни предприятия, или други лица или юридически лица, като например компетентни органи съгласно Регламент (ЕО) № 1370/2007 и товароизпращачи, спедитори и оператори на комбиниран транспорт, които си набавят инфраструктурен капацитет с цел осигуряване на обществена услуга или от търговски интерес (Директива 2012/34/ЕС [3]). За разпределящ орган вж. дефиницията на УИ.

Заявка за транспорт (Consignment order)

Подраздел на товарителницата, който съдържа информацията, необходима на дадено железопътно предприятие за извършване на превоз на негова отговорност до прехвърлянето на товара на следващото железопътно предприятие.

Инструкция за транспортирането на вагонна пратка.

Използван капацитет на транспортната единица (Unit capacity used)

Показател за степента на натоварване на транспортната единица (напр. пълна, празна, натоварване, по-малко от контейнерното — LCL).

Изпращач (Consignor)

Страна, която по договор с обединителя на услугата изпраща стоките със съответния превозвач или му ги предава.

Синоними: Търговец, изпращащ стоки или изпращач на стоки.

Интермодална единица (Intermodal Unit)

Товарна единица, която може да бъде превозвана чрез различни видове транспорт, напр. контейнер, сменяем контейнер, полуремарке, ремарке.

Интермодален терминал (Intermodal terminal)

Обект, в който са осигурени пространство, съоръжения и работно оборудване за прехвърлянето на интермодалните товарни единици (контейнери за транспорт на товари, сменяеми контейнери, полуремаркета или ремаркета).

Интермодален транспорт (Intermodal transport)

Превоз на стоки в една и съща товарна единица или возило, при който се използват последователно няколко вида транспорт, без да се претоварват самите стоки при преминаването към друг вид транспорт.

Интернет (Internet)

—

Всяка голяма мрежа, включваща множество по-малки мрежи;

—

група от мрежи, които са взаимносвързани, така че да образуват една непрекъсната голяма мрежа и да може да се установява връзка с тях безпрепятствено чрез мрежовия слой от модела OSI посредством маршрутизатори;

—

техническо наименование на мрежата, използвана като базово средство за електронна поща и за онлайн разговор в световен мащаб.

IP

Интернет протокол

Интернет протоколът се използва за услуги за предаване на дейтаграми между главни (хост) компютри в система от взаимосвързани мрежи.

Устройствата за свързване на мрежите се наричат шлюзове. Шлюзовете комуникират помежду си с цел извършване на контрол посредством протокол за трансфер на данни между шлюзови устройства (GGP).

ICMP

Internet Control Message Protocol (ICMP) — протокол за изпращане на контролни съобщения

Понякога даден шлюз (вж. GGP) или главен компютър (хост) на краен получател (вж. IP) комуникира с хостa източник, напр. за да съобщи за грешка в обработката на дейтаграма. За такива цели се използва горепосоченият протокол — Internet Control Message Protocol (ICMP). ICMP използва базовото осигуряване на IP все едно че е протокол от по-високо ниво, но в същото време ICMP е съставна част от IP и трябва да се прилага от всеки IP модул. Съобщения от типа ICMP се изпращат при редица ситуации, например когато дадена дейтаграма не може да достигне до своето местоназначение, когато шлюзът няма достатъчно буферна памет за препращане на дейтаграма, и когато шлюзът може да насочи хоста да изпрати трафик по по-кратък маршрут. Интернет протоколът не е проектиран да гарантира абсолютна надеждност. Предназначението на тези контролни съобщения е да осигуряват обратна информация за проблеми в комуникационната среда, а не да направят IP надежден. Все още няма гаранции, че ще бъде доставена дадена дейтаграма или че ще се върне съответно контролно съобщение. Възможно е някои дейтаграми да не бъдат доставени без да се получи съобщение за тяхното загубване. Протоколите от по-високо ниво, използващи IP, трябва да изпълняват свои собствени процедури за надеждност, в случай че се изисква надеждна комуникация. Съобщенията ICMP обикновено докладват за грешки в обработката на дейтаграмите. За да се избегне пораждането на безкрайна поредица от съобщения за съобщенията, не е възможно изпращането на съобщения ICMP за съобщения ICMP. Също така, съобщенията ICMP се изпращат само за грешки при боравенето с нулевия фрагмент на фрагментирани дейтаграми. (Нулевият фрагмент е с отместване, равно на нула).

Клиент (Customer)

е субектът, който издава товарителницата и я предава на водещото железопътно предприятие.

Код по Комбинираната номенклатура — код по КН (CN-code)

8-цифров код от списък с кодове на продуктите, използван от митниците

Код по Хармонизираната система (HS code)

6-цифров код в списък от продукти, използван от митниците, същия като първите 6 цифри от кода по Комбинираната номенклатура

Комбиниран автомобилно-железопътен транспорт (Combined road — rail transport)

Интермодален транспорт, в който по-голямата част от пътуването в Европа е със железопътен транспорт и всеки първоначален и/или краен участък, изпълняван с автомобилен транспорт, е възможно най-кратък.

Криптиране (Encryption)

Кодиране на съобщения

Декриптиране: означава преобразуване на криптирани данни в техния първоначален вид

Маршрут (Path)

Означава инфраструктурния капацитет, необходим за движението на даден влак между две местоположения за определен период от време (път, определен във времето и пространството).

Маршрутен влак (Block train)

Специфичен вид директен влак с точно необходимия брой вагони, който се движи между две точки на претоварване без междинно преразпределяне на вагоните.

Маршрутен път (Route)

Географският път, който трябва да бъде изминат от началната точка до местоназначението.

Междинна точка (Intermediate point)

Означава местонахождението на начална или крайна точка на участък от пътуването. Такава точка може да бъде например точка на прехвърляне, предаване или прекомпозиране.

Международна спогодба за взаимно използване на товарни вагони (RIV)

Правилници за взаимното ползване на товарните вагони в международния транспорт.

Правилници за взаимното ползване на товарачни съоръжения, контейнери и палети в международния транспорт.

Местоназначение (Place of destination)

Място, където превозното средство трябва да пристигне или е пристигнало.

Синоним: Място на пристигане;

Метаданни (Metadata)

Просто казано — данни за данните. Метаданните описват данни, софтуерни услуги и други компоненти, съдържащи се в информационната система на предприятието. Примери за различни видове метаданни включват: определения за стандартни данни, информация за местонахождение и маршрут, както и метаданни за управление на синхронизацията при разпространението на обменяни данни

МОЖЕ (MAY)

Тази дума или прилагателното „НЕЗАДЪЛЖИТЕЛНО“ означава, че разглежданият елемент е наистина незадължителен. Даден доставчик може да реши да включва в услугата си съответния елемент тъй като някой определен пазар го изисква или защото доставчикът смята, че този елемент подобрява продукта, а в същото време друг доставчик може да реши да не включва в услугата си този елемент.

Дадена реализация, която не включва определен незадължителен елемент ТРЯБВА да е готова за съвместна работа с друга реализация, която включва този елемент, макар и с намалена функционалност. Аналогично дадена реализация, която включва определен незадължителен елемент

ТРЯБВА да е готова за съвместна работа с друга реализация, която не включва този елемент (с изключение, разбира се, на характеристиката, осигурявана от този елемент).

Място на доставяне (Place of delivery)

Място, където се извършва доставянето (посочва се и отправната гара). Място, където се променя отговорността за вагона.

Място на отпътуване (Place of departure)

Място, откъдето е планирано да отпътува или е отпътувало дадено превозно средство.

Надеждност, разполагаемост, ремонтопригодност, безопасност (RAMS)

Надеждност— възможността за започване и продължаване на експлоатация при определените експлоатационни условия за определен период от време, изразена математически;

Разполагаемост— времето в експлоатация, сравнено с времето извън експлоатация, изразено математически;

Ремонтнопригодност— пригодността на дадена система да бъде върната в експлоатация след отказ, изразена математически;

Безопасност— вероятността за пораждане от системата на опасно събитие, изразена математически.

Наемател (Hirer)

Всяко физическо или юридическо лице, определено като наемател от ползвателя/собственика на даден вагон.

НЕ СЛЕДВА (SHOULD NOT)

Този израз или изразът „НЕ СЕ ПРЕПОРЪЧВА“ означават, че би могло да съществуват основателни причини при определени обстоятелства, при които дадено поведение да е приемливо или дори полезно, но е необходимо да бъдат осъзнати цялостните последици и случаят да бъде внимателно преценен, преди да се приложи поведението, описано в този надпис.

Номер на локомотива (Loco ID)

Уникален идентификационен номер на дадена тягова единица.

Номер на маршрута (Path number)

Номер на определения влаков маршрут

Носещо отговорност лице (Duty holder)

Всяко физическо или юридическо лице, носещо отговорност за внасяния от него риск в железопътната мрежа, т.е. железопътното предприятие.

Нотифицирани органи (Notified bodies)

Органите, които са отговорни за оценката на съответствието и годността за употреба на съставните елементи на оперативната съвместимост или за оценката на процедурата „ЕО“ за проверка на подсистемите. (Директива 91/440/EИО на Съвета (1).

NFS

Network File System (Протокол за мрежов достъп до файлови системи) представлява протокол за разпределени файлови системи.

Протоколът Network File System (NFS) осигурява прозрачен дистанционен достъп до споделени файлови системи в мрежите. Протоколът NFS е предназначен да бъде независим от машината, операционната система, мрежовата архитектура, механизмът за сигурност и транспортния протокол. Тази независимост се постига чрез използването на примитиви на процедура за дистанционно повикване (RPC primitives), изградени върху външно представяне на данни (XDR).

Обединител на интермодална услуга (Intermodal Service Integrator)

Всяка организация или предприятие, която е сключила (което е сключило) договор с клиенти за транспортирането на интермодални товарни единици. Обединителят на интермодална услуга изготвя пътни листове, управлява капацитета на маршрутни влакове и т.н.

Обслужване на едно гише (One Stop Shop — OSS)

Международно партньорство между управители на железопътна инфраструктура за предоставяне на клиентите на единна точка за контакт за целите на:

—

Поръчване на определени влакови маршрути за международни товарни превози,

—

Мониторинг на цялото влаково движение,

—

Обикновено също и за фактуриране на такси за достъп до железопътните линии от името на управители на инфраструктура.

ОВПВ (TETA)

Вж. Очаквано време на пристигане на влака

Оператор на интермодален транспорт (Intermodal operator)

Всяка организация, която е сключила договор за интермодален транспорт и поема цялата отговорност за транспортирането на интермодалните товарни единици.

OSI

Взаимодействие на отворени системи (Open Systems Interconnection)

Описва комуникационен протокол за отворени системи, базиращ се на еталонния модел OSI. Отворените системи могат да комуникират независимо от решения, обект на индустриална собственост.

OSS

Вж. обслужване на едно гише

Очаквано време на пристигане на влака (Train Estimated Time of Arrival)

Означава очакваното време на пристигане на влака в определена точка — например точка на предаване, точка на прехвърляне или крайното местоназначение на влака

ОЧП (ETA)

Очакван час на пристигане.

ОЧПРЕД (ETH)

Очакван час на предаване на даден влак от един управител на инфраструктура на друг.

ОЧПР (ETI)

Очакван час на прехвърляне на вагони от едно железопътно предприятие на друго.

Партидна пратка (Shipment)

Съвкупност от стоки, изпратени от един изпращач до един получател, която е натоварена на един или повече пълни интермодални товарни единици, или която е натоварена на един или повече пълни вагони.

НАПР.:

Image 1

Peer-to-Peer (мрежа от равноправни възли за комуникация „от точка до точка“)

Терминът „peer-to-peer“ означава клас от системи и приложения, които използват разпределени ресурси за изпълнение на критична функция по децентрализиран начин. Ресурсите включват изчислителна мощност, данни (запаметяващи устройства и съдържание), мрежова честотна лента, както и присъствие (на компютърни, човешки и други ресурси). Критичната функция може да бъде разпределено компютърно изчисление, споделяне на данни/съдържание, комуникация и сътрудничество или платформи за услуги. Децентрализацията може да се отнася за алгоритмите, данните и метаданните, или за всички тези елементи. Това не изключва запазване на централизацията в някои части на системите и приложенията, ако това съответства на техните изисквания.

Период преди заминаване (Pre-departure Period)

е времевият интервал преди планирания час на заминаване. Периодът преди заминаване започва в планирания час на заминаване минус времевия интервал и свършва в планирания час на заминаване.

PKI

Инфраструктура с публичен ключ

Планирано време на заминаване (Scheduled time of departure)

Дата и час на заминаване, за които се прави заявка за маршрут

Разписание/график за движение на влаковете (Scheduled Timetable)

Хронологично дефинирано заемане на железопътна инфраструктура за движение на влак по междугарова линия или в гари. Промените в разписанията се съобщават от управителите на инфраструктура поне два дни преди началото на деня, в който влакът потегля от своята начална точка. Разписанието се отнася за определен ден. В някои страни е известно като оперативно разписание.

Получател (Consignee)

Страна, която трябва да получи стоките

Синоним: Получател на стоки

Пратка (Consignment)

Товар, изпратен съгласно единичен договор за превоз. При комбиниран транспорт този термин може да се използва за статистически цели, за изразяване на количеството товарни транспортни единици или автомобилни транспортни средства.

Прехвърляне (Interchange)

Означава прехвърлянето на контрола от едно железопътно предприятие към друго по практически съображения във връзка с експлоатацията и безопасността. Примери за това са:

—

Смесените услуги,

—

Услугите със споделена отговорност за автомобилното извозване,

—

Преносът на информация между различни железопътни предприятия

—

Преносът на информация между собственици на вагони/ползватели на вагони и оператори на влакове

Преходна точка (Gateway)

Гара по маршрута на влак, превозващ интермодални транспортни единици, в която се извършва претоварване от вагоните.

Прогнозен час (Forecast Time)

Възможно най-точно предвиждане на часа на пристигане, заминаване или преминаване на влак.

Продукт COTS (COTS-product)

Продукт, предлаган в търговската мрежа

Проследяване (Tracking)

Дейност за системен мониторинг и записване на текущото местоположение и на състоянието на дадена пратка, возило, съоръжение, пакет или товар.

Проследяване на данни (Tracing)

Дейност по съответна заявка, представляваща откриване и възстановяване историята на транспортирането на дадена пратка, возило, съоръжение, пакет или товар.

Пуснат в експлоатация (Put into Service)

Процедура, зависеща от техническото одобрение на даден вагон и от договор със железопътно предприятие за неговото използване, което дава възможност за стопанска експлоатация на вагона.

Първични данни (Primary data)

Основните данни, използвани като еталонни данни в съобщенията или като база за формулите и изчисленията на производни данни.

Пътен лист (Waybill)

Това е документът, изготвян от превозвача или от негово име, в който е посочен договорът за превоз на товара.

Пътен план (Trip plan)

Показва по отношение на даден вагон или интермодална единица какво е планираното пътуване на вагона/интермодалната единица.

Пътуване (Journey)

„Пътуване“ обозначава превоза на натоварен или празен вагон от изпращащата гара до гарата на местоназначението.

Разпределящ орган (Allocation body)

Вж. УИ.

RAMS

Вж. Надеждност, разполагаемост, ремонтопригодност, безопасност (RAMS)

RARP

Reverse Address Resolution Protocol (обратен протокол за преобразуване на адреси)

Режим на свободен достъп (Open Access mode)

Режим на експлоатация на влака, при който участва само едно железопътно предприятие, превозващо влака по различни инфраструктури. Това железопътно предприятие договаря нужните маршрути с всички съответни управители на инфраструктура.

Режим на сътрудничество (Co-operation mode)

Режим на експлоатация на влака, при който си сътрудничат различни железопътни предприятия, под водителството на едно от тях (водещо железопътно предприятие). Всяко участващо железопътно предприятие договаря съответния необходим маршрут за транспортирането самостоятелно.

Резервиране (Booking)

Процесът на извършване на резервация за обем в транспортно средство за превоза на стоки.

RPC

Процедура за дистанционно повикване (Remote Procedure Call)

Протоколът за RPC е определен в Спецификацията за процедурата за дистанционно повикване, версия 2 [RFC1831] (Remote Procedure Call Protocol Specification Version 2).

CA

Сертифициращ орган

Сглобяване на маршрут (Path assembly)

Съединяване на индивидуални влакови маршрути за разширяване на маршрут във времето и пространството.

СЛЕДВА (SHOULD)

Тази дума или прилагателното „ПРЕПОРЪЧВА СЕ“ означава, че би могло да съществуват основателни причини при определени обстоятелства да не се вземе под внимание даден елемент, но в такъв случай е необходимо да бъдат осъзнати цялостните последици и те да бъдат внимателно преценени преди да бъде предпочетен друг начин на действие.

SMTP

Прост протокол за обмен на електронна поща

SNMP

Прост протокол за управление на мрежа

SQL

Structured Query Language (език за структурирани запитвания)

Език, разработен от IBM и стандартизиран впоследствие от ANSI и ISO, който се използва за създаване на записи, управление и извличане на данни

Ползвател (Keeper)

Лицето, което, в качеството си на собственик или притежаващ правото да се разпорежда с него, експлоатира возилото постоянно и по стопански начин като транспортно средство и е регистрирано като ползвател в регистъра на подвижния състав.

Съставен елемент на оперативната съвместимост (Interoperability constituent)

означава всеки първичен съставен елемент, група съставни елементи, подвъзел или пълен възел на оборудване, включено в състава или предназначено за включване в състава на подсистема, от които зависи пряко или косвено оперативната съвместимост на трансевропейската конвенционална железопътна система. Понятието за съставен елемент включва материалните обекти, но също и нематериални обекти като например програмните продукти.

Съществени изисквания (Essential requirements)

Означава всички условия, зададени в приложение III към Директива 2001/16/ЕО на Европейския парламент и на Съвета (*1), които трябва да бъдат спазвани в трансевропейската железопътна система, подсистемите и съставните елементи на оперативната съвместимост, включително интерфейсите.

Технически спецификации за оперативна съвместимост (Technical Specification for Interoperability)

Означава спецификация, на която трябва да отговаря подсистема или част от подсистема, за да бъдат изпълнени съществените изисквания и да се осигури оперативната съвместимост на железопътната система.

Товарителница (Consignment note)

Документ, който свидетелства за наличието на договор за транспортиране от превозвач на една пратка от посочено място на приемане на пратката до посочено място за нейната доставка. Товарителницата съдържа подробни данни за транспортираната пратка.

Точка за отчитане (Reporting point)

Място по пътя на влака, при което отговорният управител на инфраструктура трябва да изпрати „съобщение с прогноза за движението на влака“, съдържащо очаквано време на пристигане на влака (ОЧПВ), до договорилото маршрута железопътно предприятие.

Точка на предаване (Handover point)

Точка, в която отговорността се предава от един управител на инфраструктура на друг.

Точка на прекомпозиране (Handling point)

Гара, в която железопътното предприятие може да промени влаковата композиция, но след която продължава да носи отговорност за вагоните — без промяна в отговорността.

Точка на прехвърляне (Interchange point)

Мястото, в което отговорността за вагоните в даден влак се прехвърля от едно железопътно предприятие (ЖПП) на друго ЖПП.

При движението на влака той се предава от едно ЖПП на следващо ЖПП, което притежава съответния маршрут за следващия участък от пътуването.

Трансбордиране (Transhipment)

Операцията за преместване на интермодалните товарни единици от едно транспортно средство на друго.

Трансевропейска железопътна мрежа (Trans-European rail network)

Железопътната мрежа, както е описана в приложение I към Директива 2001/16/ЕО (*1).

ТРЯБВА (MUST)

Тази дума, или термините „ИЗИСКВА СЕ“ или „НЕОБХОДИМО Е“ означава, че съответното определение представлява абсолютно изискване на спецификацията.

ТРЯБВА ДА НЕ (MUST NOT)

Този израз, или фразата „НЕ ТРЯБВА ДА“ означава, че съответното определение представлява абсолютна забрана в спецификацията.

ТСОС (TSI)

Вж. Техническа спецификация за оперативна съвместимост

Тунелиране (Tunnelling)

Процес, при който частни IP пакети се капсулират в публичен IP пакет.

TCP

Мрежов протокол за управление на обмена на информация (Transmission Control Protocol)

UDP

User Datagram Protocol (Протокол за потребителски дейтаграми)

Простото преминаване на протокол за потребителски дейтаграми (UDP) през транслатори на мрежови адреси (NATs), известно с означението STUN, представлява облекчен протокол, даващ възможност за приложения за установяване на наличието и видовете на NATs и на защитни прегради (firewalls) между тях и публичния Интернет. То дава също възможност за приложения за определяне на публичните IP адреси, които са им дадени от NAT. Също така, STUN работи с много съществуващи NATs и не изисква специално поведение от тяхна страна. В резултат то дава възможност за много разнообразни приложения за работа в съществуващата инфраструктура на NAT.

Уеб (Web)

World wide Web (световна мрежа):

Интернет услуга за свързване на документи чрез хипервръзки от сървър до сървър, така че потребителят да може да прескача от документ към свързан с него документ, независимо къде той се съхранява в интернет.

УИ (IM)

Управител на инфраструктура означава всяка организация или дружество, отговарящи по-специално за изграждането, управлението и поддръжката на железопътна инфраструктура, включително управлението на движението и контрола на управлението и сигнализацията; функциите на управител на инфраструктурата на дадена мрежа или част от мрежа могат да бъдат поверени на различни органи или дружества. Когато управителят на инфраструктура не е независим от железопътни предприятия по отношение на юридическата си форма, организация или функции по вземане на решения, функциите, посочени в глава IV, раздели 2 и 3, се изпълняват съответно от начисляващ таксите орган и от разпределящ орган, които са независими по отношение на юридическата си форма, организация и вземане на решения от железопътните предприятия. (Директива 2012/34/ЕО [3])

UIC

UIC е Международният железопътен съюз.

UITP

UITP e Международният съюз за обществен транспорт.

UNIFE

Асоциацията на европейската железопътна промишленост (UNIFE) е организация, която се грижи за интересите на доставчиците за железопътния сектор. Понастоящем пряко представени в нея са около 100 доставчици и подизпълнители, а около 1 000 са представени непряко чрез съответни национални организации.

Управител на инфраструктура (УИ) — Infrastructure manager (IM)

Вж. УИ

Участък от маршрут (Route section)

Част от даден маршрут

Участък от пътуването (Journey section)

Представлява част от пътуването, която се провежда в един инфраструктурен участък на управител на инфраструктура, или

част от пътуването от входната точка на предаване до изходната точка на предаване на инфраструктурата на един управител на инфраструктура.

FTP

Протокол за пренос на файлове (File Transfer Protocol)

Протокол за пренос на файлове между компютърни системи в рамките на мрежа, използваща протокола TCP/IP.

HTTP

Протокол за пренос на хипертекст

Протоколът за комуникации клиент/сървър, използван за връзка към сървърите в Уеб мрежата.

Час на освобождаване за вагоните (Release time for wagons)

Дата и час, когато вагоните са готови да бъдат изтеглени от посоченото място на коловоз на клиента.

(*1)  Директива 2001/16/ЕО на Европейския парламент и на Съвета от 19 март 2001 г. относно оперативната съвместимост на трансевропейската конвенционална железопътна система (ОВ L 110, 20.4.2001 г., стр. 1).

(1)  Директива 91/440/ЕИО на Съвета от 29 юли 1991 г. относно развитието на железниците в Общността (ОВ L 237, 24.8.1991 г., стр. 25).

Допълнение III

Задачи на Националния център за контакти (НЦК) по телематичните приложения за пътнически и за товарни превози (ТППП/ТПТП)

1)   

Да изпълнява ролята на център за контакти между Европейската железопътна агенция, Управляващия комитет за ТПТП/ТППП (TAF/TAP Steering Committee) и действащите лица в областта на железопътния транспорт (управители на инфраструктура, железопътни предприятия, ползватели на вагони, управители на гари, продавачи на билети, оператори на интермодален транспорт, клиенти на железопътни товарни превози и съответни асоциации) в държавата членка, за да осигурява активно прилагане на ТПТП и ТППП от действащите лица в областта на железопътния транспорт, както и осведоменост за развитията в тази област и за решенията на Управляващия комитет.

2)   

Да предава безпокойствата и въпросите, интересуващи действащите лица в областта на железопътния транспорт в държавата членка на Управляващия комитет за ТПТП/ТППП чрез съпредседателствата.

3)   

Да поддържа контакт с представителя на съответната държава членка в Комитета за безопасност и оперативна съвместимост на железопътния транспорт (RISC), като по този начин осигурява преди всяко заседание на RISC осведомяване на членовете на RISC по националните въпроси във връзка с ТПТП/ТППП, както и осведомяване на съответните действащи лица в областта на железопътния транспорт за решенията на RISC, свързани с ТПТП/ТППП.

4)   

Държавата членка осигурява установяване на контакт с всички лицензирани железопътни предприятия и други действащи лица в областта на железопътния транспорт (управители на инфраструктура, железопътни предприятия, стопани на вагони, управители на гари, оператори на интермодален транспорт, клиенти на железопътни товарни превози и съответни асоциации), както и да им се предоставят подробни данни за НЦК, ако те все още не са установили контакт с НЦК.

5)   

Доколкото действащите лица в областта на железопътния транспорт в държавата членка са известни, да ги осведоми за техните задължения по регламентите относно ТПТП и ТППП, както и че те трябва да спазват тези изисквания.

6)   

Да работи с държавата членка по определянето на организация, която да отговаря за въвеждане в централния домейн (Central Reference Domain) на първични кодове за местоположение (primary location codes). Идентификационните данни за съответната организация трябва да се докладват на ГД „Мобилност и транспорт“ за осигуряване на разпространение на съответната информация.

7)   

Да улеснява споделянето на информация между действащите лица в областта на железопътния транспорт от държавите членки (управители на инфраструктура, железопътни предприятия, ползватели на вагони, управители на гари, оператори на интермодален транспорт, клиенти на железопътни товарни превози и съответни асоциации) в държавата членка.