13/ 51

BG

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

184

---

32006R0062

---

L 013/1

ОФИЦИАЛЕН ВЕСТНИК НА ЕВРОПЕЙСКИЯ СЪЮЗ

---

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

от 23 декември 2005 година

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

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

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

като взе предвид Договора за създаване на Европейската общност,

като взе предвид Директива 2001/16/ЕО на Европейския парламент и на Съвета от 19 март 2001 г. относно оперативната съвместимост на трансевропейската конвенционална железопътна система (1), и по-специално член 6, параграф 1 от нея,

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

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

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

(3)

ЕАОС получи мандат да изготви проект за ТСОС относно подсистемата „Телематични приложения за превоз на товари“ съгласно член 6, параграф 1 от Директива 2001/16/ЕО. Основните параметри на този проект за ТСОС са приети с Решение 2004/446/ЕО на Комисията от 29 април 2004 г., с което се уточняват основните параметри на техническите спецификации за оперативна съвместимост на подсистемите „Шум“, „Товарни вагони“ и „Телематични приложения за превоз на товари“, упоменати в Директива 2001/16/ЕО (2).

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

(5)	Проектът за ТСОС бе разгледан от Комитета, установен с член 21 от Директива 96/48/ЕО на Съвета от 23 юли 1996 г. относно оперативната съвместимост на Трансевропейската високоскоростна железопътна система (3), като се има предвид докладът за представянето на проекта.

(6)

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

(7)

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

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

(9)

ТСОС на телематичните приложения се основава на най-добрите специализирани познания, налични към момента на изготвянето на съответния проект. Може да се окаже необходимо тази ТСОС да бъде изменена или допълнена, за да се вземе под внимание развитието на технологиите или на социалните изисквания, както и на изискванията относно функционирането или безопасността. За тази цел ще бъде изготвена процедура по управление на промените с цел хармонизирането и актуализирането на разпоредбите на ТСОС. Тази процедура по актуализиране ще бъде поставена под ръководството на Европейската железопътна агенция, учредена по Регламент (ЕО) № 881/2004 на Европейския парламент и на Съвета (4), когато Агенцията започне своята работа, а именно най-късно през месец април 2006 г. Ако е необходимо, в съответствие с член 6, параграф 3 от Директива 2001/16/ЕО ще започне по-задълбочена и пълна процедура по преглед или актуализиране, с която се извършват промени на редовната процедура, определена в тази ТСОС.

(10)

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

(11)

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

(12)

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

(13)

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

(14)	За да се избегне възникването на объркване, е необходимо да се уточни, че разпоредбите на Решение 2004/446/ЕО относно основните параметри на конвенционалната трансевропейска железопътна система повече не се прилагат.

(15)

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

(16)	Разпоредбите на настоящия регламент са в съответствие със становището на комитета, създаден съгласно Директива 96/48/ЕО,

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

Член 1

Техническата спецификация за оперативна съвместимост (по-нататък наричана „ТСОС“) на подсистемата „Телематични приложения за превоз на товари“ на конвенционална железопътна система, предвидена в член 6, параграф 1 от Директива 2001/16/ЕО, се определя в приложението към настоящия регламент.

ТСОС е напълно приложима към инфраструктурата и подвижния състав на конвенционалната трансевропейска железопътна система, определени в приложение I от Директива 2001/16/ЕО.

Член 2

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

Член 3

Определените в член 3, параграф 2 от Регламент (ЕО) № 881/2004 представителни органи от железопътния сектор на европейско ниво изготвят стратегически план за развитие на приложената ТСОС в съответствие с критериите, изложени в глава 7 от приложението към настоящия регламент.

Те предават този стратегически план на останалите държави-членки и на Комисията най-късно една година след датата на влизане в сила на настоящия регламент.

Член 4

Разпоредбите на Решение 2004/446/ЕО относно основните параметри на конвенционалната трансевропейска железопътна система не се прилагат от датата на влизане в сила на настоящия регламент.

Член 5

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

---

(1)  ОВ L 110, 20.4.2001 г., стр. 1. Директива, изменена с Директива 2004/50/ЕО (ОВ L 164, 30.4.2004 г., стр. 114), поправена с ОВ L 220, 21.6.2004 г., стр. 40.

(2)  ОВ L 155, 30.4.2004 г., стр. 1, поправена с ОВ L 193, 1.6.2004 г., стр. 1.

(3)  ОВ L 235, 17.9.1996 г., стр. 6. Директива, последно изменена с Директива 2004/50/ЕО.

(4)  ОВ L 164, 30.4.2004 г., стр. 1, поправен с ОВ L 220, 21.6.2004 г., стр. 3.

---

ПРИЛОЖЕНИЕ

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

СЪДЪРЖАНИЕ

1.

ВЪВЕДЕНИЕ

1.1.	Област на техническо приложение

1.2.	Област на географско приложение

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

2.	ОПРЕДЕЛЕНИЕ НА ПОДСИСТЕМАТА/ПОЛЕ НА ПРИЛОЖЕНИЕ

2.1.	Функции, влизащи в приложното поле на ТСОС

2.2.	Функции, намиращи се извън приложното поле на ТСОС

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

2.3.1.

Участващи доставчици на услуги

2.3.2.

Предвидени процедури

2.3.3.

Общи забележки

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

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

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

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

3.3.1.

Сигурност

3.3.2.

Надеждност и достъпност

3.3.3.

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

3.3.4.

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

3.3.5.

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

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

3.4.1.

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

3.4.2.

Надеждност и достъпност

3.4.3.

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

3.4.4.

Сигурност

4.	ОПИСАНИЕ НА ПОДСИСТЕМАТА

4.1.

Въведение

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

4.2.1.

Данни от документите по проследяване

4.2.2.

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

4.2.3.

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

4.2.4.

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

4.2.5.

Информация за прекъсване на услугата

4.2.6.

Локализиране на влака

4.2.7.

ПЧО/ПЧП (предвидени часове на обмен/предвиден час на пристигане) на товара

4.2.8.

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

4.2.9.

Доклади за извършения обмен

4.2.10.

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

4.2.11.

Основни референтни данни

4.2.12.

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

4.2.13.

Предаване на документи по електронен път

4.2.14.

Свързване в мрежа и комуникация

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

4.3.1.

Интерфейси с ТСОС относно инфраструктурата

4.3.2.

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

4.3.3.

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

4.3.4.

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

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

4.4.1.

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

4.4.2.

Управление на централния регистър

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

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

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

4.8.	Регистри на инфраструктурата и на подвижния състав

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

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

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

5.3.	Характеристики и спецификации на съставните елементи

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

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

6.1.1.

Процедури по оценяване

6.1.2.

Модул

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

7.

ПРИЛАГАНЕ

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

7.1.1.

Въведение

7.1.2.

Стратегически европейски план за развитие (SEDP)

7.1.3.

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

7.2.	Стратегия за извършване на преход

7.3.	Управление на промените

7.3.1.

Въведение

7.3.2.

Основни линии

7.3.3.

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

7.3.4.

Създаване на нови основни линии

7.3.5.

Управление на промените — изисквания

7.3.6.

План за управление на конфигурацията — изисквания

7.4.	Особени случаи

7.4.1.

Въведение

7.4.2.

Списък на особените случаи

ПРИЛОЖЕНИЕ А:

СПИСЪК НА ПРИДРУЖАВАЩИТЕ ДОКУМЕНТИ

ПРИЛОЖЕНИЕ Б:

РЕЧНИК

ТАБЛИЦИ:

Таблица 1:

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

Таблица 2:

Анулиране на маршрут от железопътно предприятие

Таблица 3:

Анулиране на маршрут от управител на инфраструктура

Таблица 4:

Потвърждение за получаване

Таблица 5:

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

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

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

1.   ВЪВЕДЕНИЕ

1.1.   Област на техническо приложение

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

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

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

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

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

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

Крайната цел на настоящата ТСОС е да позволи управлението на товарите при спазване на изискванията на всички тези интерфейси благодарение на обмена на информация на основата на Директиви 2001/14/ЕО (1) и 2001/16/ЕО на Европейския парламент и на Съвета.

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

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

1.2.   Област на географско приложение

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

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

Съгласно член 5, параграф 3 от Директива 2001/16/ЕО настоящата ТСОС:

а)	обхваща приложното поле, визирано в рамките на подсистемата „Телематични приложения за превоз на товари“ — глава 2: Определение на подсистемата/поле на приложение;

б)	уточнява съществените изисквания относно съответната подсистема и нейната свързаност с други подсистеми — глава 3: Съществени изисквания;

в)	установява функционалните и технически спецификации, на които трябва да отговаря подсистемата и нейните връзки с други подсистеми — глава 4: Описание на подсистемата;

г)

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

д)

определя във всеки отделен случай процедурите за оценка на съответствието или пригодността за употреба. Това включва по-специално модулите, определени в Директива 93/465/ЕИО на Съвета (2), или при необходимост специфичните процедури, които се използват за оценка или на съвместимостта, или на пригодността за употреба на съставните елементи на оперативната съвместимост, а също и за проверка „ЕО“ на подсистемите — глава 6: Оценка на съответствието и/или на пригодността за употреба на съставните елементи и проверка на подсистемата;

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

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

Освен това съгласно член 5, параграф 5 за тази ТСОС може да бъде предвидено наличието на особени случаи, които са посочени в глава 7.4:

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

2.   ОПРЕДЕЛЕНИЕ НА ПОДСИСТЕМАТА/ПОЛЕ НА ПРИЛОЖЕНИЕ

2.1.   Функции, влизащи в приложното поле на ТСОС

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

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

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

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

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

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

2.2.   Функции извън приложното поле на ТСОС

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

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

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

2.3.1.   Участващи доставчици на услуги

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

—

вагони,

—	локомотиви,

—	машинисти,

—	стрелки и маневрени гърбици,

—	продажба на часови слотове (маршрути),

—	управление на товарите,

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

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

—	наблюдение на движението на влаковете,

—	контролиране на влаковете,

—	надзор на товарно-разтоварната дейност,

—	преглед и ремонт на вагоните и/или локомотивите,

—	митническо оформяне,

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

—	управление на шосейния превоз.

Някои доставчици на услуги са изрично посочени в Директиви 2001/14/ЕО и 2001/16/ЕО. Тъй като и двата текста трябва да бъдат взети под внимание, настоящата ТСОС се базира по-специално на следната дефиниция (виж също така приложение А, индекс 6):

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

Съгласно Директива 2001/14/ЕО органът или предприятието, на което управителят на инфраструктура предоставя маршрут, се приема като „кандидат“:

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

Що се отнася до предоставянето на маршрути, член 13 от Директива 2001/14/ЕО също трябва да бъде взет под внимание:

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

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

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

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

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

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

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

2.3.2.   Предвидени процедури

Съгласно Директива 2001/16/ЕО настоящата ТСОС относно железопътния превоз на товари се ограничава по отношение на преките си клиенти до УИ и до ЖПП/ГЖПП.

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

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

Най-общо ЖПП/ГЖПП трябва като минимум да имат правомощия да:

—

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

—	ПРЕДОСТАВЯТ услугата, определена по надежден и логичен начин, като използват общоприложими търговски процедури и свързани системи. ЖПП, УИ и останалите доставчици на услуги и участници, като например митниците, трябва да разполагат с компютърни средства за обмен на информация,

—

ИЗВЪРШВАТ ОЦЕНКА на качеството на услугата, предоставяна въз основа на определените параметри. С други думи, става дума за проверка на съответствието между предварителната оферта и окончателната фактура, между предвиденото време за извършване на транзит и действителното време, между броя заявени вагони и броя доставени вагони, и между предвидените часове на пристигане и действителните часове на пристигане,

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

В качеството им на кандидати ЖПП/ГЖПП също така трябва да предоставят (чрез сключването на договори с УИ) исканите маршрути и да експлоатират влака по отсечката от пътя, за която отговарят. Те могат да използват вече резервираните маршрути (в режим на планиране) или да поискат от заинтересования(ите) управител(и) на инфраструктура(и) маршрут ad hoc за експлоатираните от тях отсечки от пътя. В приложение А, индекс 5, глава 1.2 се дава пример за заявка за маршрут.

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

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

Диалогът между ЖПП и УИ с цел предоставянето на маршрут на товарен влак се описва в глава 4.2.2 „Заявка за маршрут“. Тази функция се основава на член 23, параграф 1 от Директива 2001/14/ЕО. Диалогът не включва получаването на лиценз за ЖПП, предоставящо услуги съгласно Директива 2001/13/ЕО на Европейския парламент и на Съвета (3), получаването на сертификата, предвиден в Директива 2001/14/ЕО, нито правата за достъп, предвидени в Директива 91/440/ЕИО на Съвета (4).

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

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

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

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

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

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

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

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

—	подобряване на качеството и производителността на транспорта (глава 4.2.10 „Обмен на данни за подобряване на качеството“).

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

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

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

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

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

—	техническите и производствените характеристики,

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

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

—	характеристиките относно спирането,

—	данните относно поддръжката,

—	характеристиките относно околната среда.

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

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

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

—	свързаност с подсистемата „Експлоатация и управление на трафика“ на конвенционалната трансевропейска железопътна система, упомената в член 5, параграф 3 от Директива 2001/16/ЕО,

—	изискванията относно съдържанието на референтния документ относно мрежата, които са определени в член 3 и в приложение I към Директива 2001/14/ЕО,

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

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

Свързаността със структурните подсистеми „Подвижен състав“ и „Контрол и управление“ може да бъде установена само посредством референтните бази данни относно подвижния състав (глава 4.2.11.3 „Референтни бази данни относно подвижния състав“), които се управляват от притежателите на подвижния състав. А свързаността с подсистемите „Инфраструктури“, „Контрол и управление“ и „Енергоснабдяване“ се предоставя от УИ заедно с определянето на маршрута (глава 4.2.2.3), който освен това отбелязва инфраструктурните данни относно влака, като се вземат предвид ограниченията относно използването на инфраструктурите (глава 4.2.11.2 „Бази данни с информация за ограниченията по отношение на инфраструктурата“).

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

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

Член 4, параграф 1 от Директива 2001/16/EО постановява, че трансевропейската конвенционална железопътна система, подсистемите и съставните елементи на оперативната съвместимост трябва да отговарят на съществените изисквания, посочени в най-общ вид в приложение III към директивата.

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

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

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

—	сигурността,

—	надеждността и достъпността,

—	опазването на здравето на хората,

—	опазването на околната среда,

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

Съгласно Директива 2001/16/ЕО съществените изисквания могат да се прилагат по принцип към цялата конвенционална трансевропейска железопътна система или да се отнасят само до нейните подсистеми и съставни елементи.

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

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

3.3.1.   Сигурност

Приложение III към Директива 2001/16/ЕО постановява, че подсистемата „Телематични приложения за превоз на товари“ трябва да отговаря на описаните по-долу съществени изисквания относно сигурността.

—

Съществено изискване 1.1.1 от приложение III към Директива 2001/16/ЕО: „Проектирането, построяването или изработването, поддръжката и контролът на съставни елементи с решаваща важност за сигурността, и по-специално на съставните елементи, свързани с влаковото движение, трябва да са такива, че да гарантират равнище на сигурност, съответстващо на целите, които се предвиждат за мрежата, включително при наличие на специфични влошени условия.“ Това съществено изискване не се отнася до подсистемата „Телематични приложения“.

—

Съществено изискване 1.1.2 от приложение III към Директива 2001/16/ЕО: „Параметрите, свързани с контакта колело-релса, трябва да отговарят на изискванията за стабилност, необходими за гарантиране на сигурно движение при максималната разрешена скорост.“ Това съществено изискване не се отнася до подсистемата „Телематични приложения“.

—

Съществено изискване 1.1.3 от приложение III към Директива 2001/16/ЕО: „Използваните съставни елементи трябва да издържат на всички нормални и екстремни натоварвания, които са специфицирани за периода на употребата им. Отражението върху сигурността на всякакви случайни повреди трябва да бъде ограничено със съответни средства.“ Това съществено изискване не се отнася до подсистемата „Телематични приложения“.

—

Съществено изискване 1.1.4 от приложение III към Директива 2001/16/ЕО: „Проектирането на стационарните съоръжения и подвижния състав, както и подборът на използваните материали трябва да целят ограничаване на предпоставките за поява на огън и дим, както и разпространението и последиците от тях в случай на възникване на пожар.“ Това съществено изискване не се отнася до подсистемата „Телематични приложения“.

—

Съществено изискване 1.1.5 от приложение III към Директива 2001/16/ЕО: „Устройствата, които са предназначени да бъдат използвани от потребители, трябва да са проектирани така че да не се нарушава безопасното функциониране на устройствата или здравето и сигурността на ползвателите, в случай на предвидимо несъответстващо на обявените инструкции ползване.“ Това съществено изискване не се отнася до подсистемата „Телематични приложения“.

3.3.2.   Надеждност и достъпност

Това съществено изискване се разглежда в следните глави:

глава 4.2.11: Основни референтни данни,

глава 4.2.12: Справочни файлове и бази данни,

глава 4.2.14: Свързване в мрежа и комуникация.

3.3.3.   Здраве

—

Съществено изискване 1.3.1 от приложение III към Директива 2001/16/ЕО: „Във влаковете и железопътната инфраструктура не трябва да се използват материали, които поради начина на употребата им представляват опасност за здравето на хората, влизащи в досег с тях.“ Това съществено изискване не се отнася до подсистемата „Телематични приложения“.

—

Съществено изискване 1.3.2 от приложение III към Директива 2001/16/ЕО: „Тези материали трябва да се подбират, разполагат и използват по такъв начин, че да ограничават емисията на вредни и опасни димни емисии и газове, особено в случай на пожар.“ Това съществено изискване не се отнася до подсистемата „Телематични приложения“.

3.3.4.   Опазване на околната среда

—

Съществено изискване 1.4.1 от приложение III към Директива 2001/16/ЕО: „Последствията от създаването и функционирането на трансевропейската конвенционална железопътна система върху околната среда трябва да се оценят и вземат предвид при проектиране на системата в съответствие с действащите разпоредби на Общността.“ Това съществено изискване не се отнася до подсистемата „Телематични приложения“.

—

Съществено изискване 1.4.2 от приложение III към Директива 2001/16/ЕО: „Материалите, използвани във влаковете и елементите на инфраструктурата, трябва да ограничават емисията на вредни и опасни за околната среда димни емисии и газове, особено в случай на пожар.“ Това съществено изискване не се отнася до подсистемата „Телематични приложения“.

—

Съществено изискване 1.4.3 от приложение III към Директива 2001/16/ЕО: „Подвижният състав и системите за енергозахранване трябва да са проектирани и изработени по начин, осигуряващ електромагнитна съвместимост с инсталациите, оборудването, обществените и частните мрежи, с които съществува риск те да си взаимодействат.“ Това съществено изискване не се отнася до подсистемата „Телематични приложения“.

—

Съществено изискване 1.4.4 от приложение III към Директива 2001/16/ЕО: „При експлоатацията на трансевропейската конвенционална железопътна система трябва да се спазват действащите разпоредби за нивото на допустимото шумово замърсяване.“ Това съществено изискване не се отнася до подсистемата „Телематични приложения“.

—

Съществено изискване 1.4.5 от приложение III към Директива 2001/16/ЕО: „При нормално поддържане и експлоатация трансевропейската конвенционална железопътна система не трябва да предизвиква нива на земни вибрации, които са недопустими за дейностите и областите извършвани или намиращи се в близост до инфраструктурата.“ Това съществено изискване не се отнася до подсистемата „Телематични приложения“.

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

—

Съществено изискване 1.5 от приложение III към Директива 2001/16/ЕО: „Техническите характеристики на отделните елементи на инфраструктурата и на стационарните съоръжения трябва да са съвместими помежду си, а също и с тези на влаковете, които се използват по трансевропейската конвенционална железопътна система. Ако постигането на такива характеристики се окаже трудно, в някои участъци от мрежата биха могли да бъдат приложени временни решения, които да осигуряват съвместимост в бъдеще.“ Това съществено изискване не се отнася до подсистемата „Телематични приложения“.

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

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

—

Съществено изискване 2.7.1 от приложение III към Директива 2001/16/ЕО: „Съществените изисквания относно телематичните приложения гарантират минимално качество на услугата за пътници и превозвачи на стоки, по-специално по отношение на техническата съвместимост. По отношение на тези приложения е необходимо да се предприеме следното: — базите данни, софтуера и протоколите за предаване на данни да се развиват по начин, позволяващ гарантирането на максимален брой възможности за обмен на данни между различните приложения от една страна и между различните оператори от друга страна, като се изключват поверителните търговски данни, — информацията да бъде леснодостъпна за потребителите. “ Това съществено изискване се разглежда по-специално в следните глави: — глава 4.2.11: Основни референтни данни, — глава 4.2.12: Справочни файлове и бази данни, — глава 4.2.14: Свързване в мрежа и комуникация.

3.4.2.   Надеждност и достъпност

—

Съществено изискване 2.7.2 от приложение III към Директива 2001/16/ЕО: „Методите на използване, управление, актуализиране и поддръжка на тези бази данни, софтуера и протоколите за предаване на данни трябва да гарантират ефективността на тези системи и качеството на услугата.“ Това съществено изискване се разглежда по-специално в следните глави: — глава 4.2.11: Основни референтни данни, — глава 4.2.12: Справочни файлове и бази данни, — глава 4.2.14: Свързване в мрежа и комуникация. Въпреки всичко това съществено изискване, и по-специално използваният метод за гарантиране на ефективността на тези телематични приложения и качеството на услугата, представлява основата на цялата ТСОС, а не се ограничава само до упоменатите по-горе точки.

3.4.3.   Здраве

—

Съществено изискване 2.7.3 от приложение III към Директива 2001/16/ЕО: „Използваните интерфейси между тези системи и потребителите трябва да са в съответствие с минималните изисквания за ергономия и правилата за опазване на човешкото здраве.“ Тази ТСОС не определя допълнителни изисквания по отношение на националните и европейското законодателства в областта на минималните изисквания за ергономия и правилата за опазване на човешкото здраве що се отнася до интерфейса между тези телематични приложения и потребителите.

3.4.4.   Сигурност

—

Съществено изискване 2.7.4 от приложение III към Директива 2001/16/ЕО: „Трябва да бъдат осигурени подходящи нива на кохерентност и надеждност за съхранението или предаването на информация, свързана със сигурността.“ Това съществено изискване се разглежда по-специално в следните глави: — глава 4.2.11: Основни референтни данни, — глава 4.2.12: Справочни файлове и бази данни, — глава 4.2.14: Свързване в мрежа и комуникация.

4.   ОПИСАНИЕ НА ПОДСИСТЕМАТА

4.1.   Въведение

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

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

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

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

—	данните от документите по проследяване,

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

—	подготовката на влака,

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

—	информацията за прекъсване на услугата,

—	локализирането на влака,

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

—	движението на вагоните,

—	докладите за извършения обмен,

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

—	основните референтни данни,

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

—	предаването на документи по електронен път,

—	свързването в мрежа и комуникацията.

Спецификациите са описани подробно по-долу. В приложение А, индекс 1 може да се намери по-подробна информация, както и отделните формати на съобщенията.

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

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

—	контролните данни: виж обясненията по-долу,

—	предоставената информация: информация относно заявката.

Контролните данни имат следните елементи:

—	Статус: статусът на съобщението може да бъде: — „Ново съобщение“, ако се отнася до ново съобщение, — „Промяна“, ако се отнася до изменение на изпратено преди това съобщение, — „Анулиране“, ако изпратено преди това съобщение трябва да бъде анулирано.

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

—

Атрибути, обвързани с друго съобщение, единствено ако съобщението е отговор на предишно съобщение (при което графата „предмет на съобщението“ е идентична с тази на полученото съобщение): — тип на обвързаното съобщение: тип на полученото съобщение, — дата и час на полученото обвързано съобщение, — номер на обвързаното съобщение: номер на полученото съобщение.

—	Изпращач на съобщението.

—	Получател на съобщението.

Следващите точки се отнасят най-вече до статуса „ново съобщение“. Глава 4.2.2 „Заявка за маршрут“ се отнася също така до статуса „анулиране“ по отношение на съобщенията за предоставяне на маршрут.

4.2.1.   Данни от документите по проследяване

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

Товарителницата трябва да се изпрати от клиента до ГЖПП. Тя трябва да съдържа цялата информация, необходима за превоза на пратката от изпращача до получателя. ГЖПП трябва да допълни тези данни с допълнителна информация. Всички тези сведения са изброени в таблицата към приложение А, индекс 3, която в колона „Данни от документите по проследяване“ указва дали те са опционални или задължителни и дали трябва да бъдат предоставени от изпращача или да бъдат добавени от ГЖПП.

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

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

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

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

—	заявка за предоставяне на вагони за ЖПП, извършващо първоначално поемане на стоките (Първоначално ЖПП — ПЖПП),

—	заявка за предоставяне на вагони за ЖПП, натоварено с извършването на транзита (ТЖПП),

—	заявка за предоставяне на вагони за ЖПП, натоварено с извършването на доставката (ДЖПП).

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

Заявките за предоставяне на вагони съдържат основно информация относно следните елементи:

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

—	информация относно пътуването,

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

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

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

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

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

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

—	информация относно опасните стоки,

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

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

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

Дългосрочно планиране

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

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

Основните данни, свързани с маршрута, са следните:

—	идентифкация на маршрута (номер на маршрута). Може да се отнася или за предвиденото използване на инфраструктурата по определена отсечка от пътя, или за действителния маршрут на влак по определена железопътна линия от пътя. Точният вид на маршрута зависи от процедурите, използвани от съответния УИ,

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

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

—

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

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

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

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

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

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

Споразумението относно маршрута в случай на краткосрочна експлоатация на влак трябва да се извърши чрез диалог между всички участващи ЖПП и УИ, дори ако участието им варира в зависимост от процедурата по търсене на маршрут. Член 13 от Директива 2001/14/ЕО различава основно два сценария относно превоза на товари по инфраструктурите на няколко УИ (виж също приложение А, индекс 5, глава 1.3).

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

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

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

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

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

Таблица 1

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

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

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

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

Таблица 2

Анулиране на маршрут от железопътно предприятие

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

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

Съобщения, използвани при диалога за анулиране на резервиран маршрут, започнат по инициатива на УИ.

Таблица 3

Анулиране на маршрут от управител на инфраструктура

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

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

Таблица 4

Потвърждение за получаване

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

Тези съобщения са описани накратко в следващите точки. Подробните формати са определени в приложение А, индекс 1. Логическата последователност на тези съобщения е представена в диаграмата към приложение А, индекс 5, глави от 2.1 до 2.3.

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

Става дума за заявката за маршрут, изпратена от ЖПП на УИ. В нея трябва да се указва:

—	отправната точка на маршрута: отправната точка на предложения маршрут,

—	исканите дата и час на потегляне,

—	крайната точка на маршрута: направлението на влака в рамките на заявения маршрут,

—	предвидените дата и час на пристигане,

—

заявената отсечка от пътя: — междинните спирания или другите точки, указани в рамките на предложения маршрут, с указване на датата и часа на пристигане в предложените междинни точки и датата и часа на потегляне от предложените междинни точки. Ако тази графа е празна, това означава, че в тази точка не се предвижда никакво спиране, — оборудването, с което разполага влакът: типът тракция, системата за управление и контрол, включително бордовото радиооборудване; — теглото на влака, — дължината на влака, — спирачната система, която трябва да се използва, и спирачните характеристики, — максималната скорост на влака, — максималното натоварване на ос, — максималното тегло на метър, — информация относно извънгабаритните размери, — ООН и RID номерата на опасните стоки; — описанията на дейностите, които трябва да се извършват в междинните точки, — отговорното железопътно предприятие: идентификационна информация за ЖПП, отговарящо за влака за съответната отсечка от пътя, — отговорният управител на инфраструктура: идентификационна информация за УИ, отговарящ за влака за съответната отсечка от пътя, — УИ, отговарящ за следващата отсечка: идентификационна информация за УИ, отговарящ за влака за следващата отсечка от пътя (при необходимост).

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

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

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

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

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

Когато УИ предложи алтернативно решение, той трябва да изпрати следните данни:

—	новия номер на маршрута,

—	отправната точка на маршрута: отправната точка на предложения маршрут,

—	исканите дата и час на потегляне,

—	крайната точка на маршрута: направлението на влака в рамките на заявения маршрут,

—	предвидените дата и час на пристигане,

—

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

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

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

—	идентификационен номер на маршрута,

—	отправната точка на маршрута: мястото на тръгване на влака,

—	исканите дата и час на потегляне,

—	крайната точка на маршрута: направлението на влака в рамките на заявения маршрут,

—	предвидените дата и час на пристигане на предложения влак,

—	указание, че ЖПП приема предложения маршрут.

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

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

—	идентификационен номер на маршрута,

—	указване на отказа на подробностите за маршрута.

Следните данни могат да бъдат изпратени като допълнителна информация:

—	отправната точка на маршрута: мястото на тръгване на влака,

—	исканите дата и час на потегляне,

—	крайната точка на маршрута: направлението на влака в рамките на заявения маршрут,

—	предвидените дата и час на пристигане на предложения влак.

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

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

—	идентификационният номер на маршрута,

—	номерът на влака (ако УИ вече го знае),

—	да се указва анулирането на резервирания маршрут.

Следните данни могат да бъдат изпратени като допълнителна информация:

—	отправната точка на маршрута: мястото на тръгване на влака,

—	исканите дата и час на потегляне,

—	крайната точка на маршрута: направлението на влака в рамките на заявения маршрут,

—	предвидените дата и час на пристигане на предложения влак.

4.2.2.7.   Съобщение за невъзможността за използване на маршрут

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

—	номера на маршрута, който не може да бъде използван,

—	номера на влака, предвиден за анулирания маршрут (ако УИ вече го знае),

—	отправната точка на маршрута с датата и часа, за които маршрутът е бил резервиран,

—	направлението на маршрута с датата и часа на пристигане на влака,

—	указване на невъзможността за използване на маршрута,

—	указване на причината за невъзможността за използване на маршрута.

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

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

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

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

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

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

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

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

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

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

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

ТАблица 5

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

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

Тези съобщения са описани накратко в следващите глави. Подробните формати са определени в приложение А, индекс 1. Тяхната логическа последователност е представена в приложение А, индекс 5, глава 3.

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

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

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

Необходимо е следната информация да бъде изпратена и да остане достъпна:

—	номерът на влака и идентификационният номер на маршрута,

—	отправната точка на маршрута, както и датата и часът на заявения маршрут,

—	направлението на маршрута, както и предвидените дата и час на пристигане на предложения влак,

—	идентификацията на локомотива(ите) и неговото(тяхното) местоположение в състава на влака,

—	дължината на влака, теглото му и максималната му скорост,

—	съставът на влаковата композиция с идентификационните номера на вагоните според реда им в композицията,

—	системата за управление и контрол, включително типът на радиооборудването,

—	информация относно извънгабаритните размери,

—	ООН и RID номерата на опасните стоки,

—	указване за наличието на животни и хора (различни от персонала на влака),

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

—	данните относно вагоните.

Веднага след получаването на състава на влаковата композиция УИ може, ако това се позволява изрично от договора между УИ и ЖПП, да провери елементите, съдържащи се в съобщението, като ги сравни със съответния маршрут. В този случай УИ трябва да има достъп до информацията относно евентуалните ограниченията на съответната инфраструктура, до техническите данни на вагоните (глава 4.2.11.3 „Референтни бази данни относно подвижния състав“), до справочните файлове относно опасните товари и до актуализираната информация относно вагоните (глава 4.2.12.2 „Други бази данни“ — Оперативна база данни за вагоните и интермодалните единици). Това се отнася до всички вагони на влака. УИ, който управлява маршрутите и актуализира информацията относно тях, трябва да добави данните за състава на влаковата композиция към данните за маршрута и влака, както е упоменато в глава 4.2.2.1 „Заявка за маршрут“ (Предварителни бележки).

4.2.3.3.   Съобщение за приемане на влака

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

То трябва да съдържа най-вече следните елементи:

—	номерата на влака и на маршрута,

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

—	направлението на маршрута, както и предвидените дата и час на пристигане на предложения влак,

—	указване, че УИ приема влаковата композиция за договорения маршрут.

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

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

—	номерата на влака и на маршрута,

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

—	направлението на маршрута, както и предвидените дата и час на пристигане на предложения влак,

—	указване, че влакът не съответства на предоставения му маршрут и че следователно не може да се движи,

—	указване на причината за това несъответствие.

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

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

—	номерата на влака и на маршрута,

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

—	направлението на маршрута, както и предвидените дата и час на пристигане на предложения влак,

—	указанието „влак готов“, което означава че подготовката му е завършена и че влакът е готов да се движи,

—	идентификационния номер за контакт и управление на всички бордово-наземни комуникации,

—

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

4.2.3.6.   Съобщение относно местоположението на влака

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

—	номерата на влака и на маршрута,

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

—	направлението на маршрута, както и предвидените дата и час на пристигане на предложения влак,

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

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

—	идентификационния номер за контакт и управление.

4.2.3.7.   Съобщение „влак в момент на тръгване“

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

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

4.2.3.8.   Информация относно движението на влака

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

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

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

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

Тези съобщения са:

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

информацията относно движението на влака.

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

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

—	Влак, наближаващ точката на трансфер между УИ № 1 и следващия след него УИ № 2

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

След като влакът е напуснал отправната точка (5), УИ № 1 трябва да изпрати съобщение за предвиждане на движението на влака на УИ № 2, като укаже предвидения час на трансфер (ПЧТ). Едновременно с това съобщението се изпраща и на ЖПП.

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

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

—	Влак, наближаващ точката за обмен между ЖПП № 1 и следващия след него ЖПП № 2 (единствено сценарий Б)

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

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

Ако точката за обмен е също така и точка на трансфер (например между УИ № 1 и УИ № 2), УИ № 1 изпраща съобщението за предвиждане на движението на влака на УИ № 2, веднага след като влаковата композиция напусне отправната точка или предишната точка за обмен, като указва предвидения час на трансфер (ПЧТ). Това съобщение трябва да бъде изпратено също така и на ЖПП, което е резервирало маршрута, например ЖПП № 1. За него ПЧТ съответства на предвидения час на пристигане на влака в точката за обмен. ЖПП № 1 предава това съобщение на ЖПП № 2 и на евентуалното ГЖПП, ако договорът за сътрудничество между двете ЖПП предвижда това.

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

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

—	Влак, приближаващ точка за маневриране на дадено ЖПП (сценарий А)

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

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

Ако обаче точката за маневриране е също така и точка на трансфер (например между УИ № 1 и УИ № 2), УИ № 1 трябва да изпрати съобщението за предвиждане на движението на влака на УИ № 2, веднага след като влаковата композиция напусне отправната точка или предишната точка за обмен, като указва предвидения час на трансфер (ПЧТ). Това съобщение се изпраща също така и на ЖПП. За него ПЧТ съответства на предвидения час на пристигане на влака в точката за маневриране.

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

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

—	Пристигане на влака в крайната точка

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

Забележка: възможно е в договора за предоставяне на маршрут да се определят други точки, които да налагат изпращането на съобщения за предвиждане на движението на влака с отбелязване на предвидения час на пристигане на влака и на информация относно движението на влака, в която се отбелязва действителният час на пристигане. Отговорният УИ изпраща тези съобщения в съответствие с разпоредбите на договора. По-нататъшната оценка и обработка на тези ПЧТ и ПЧПВ са описани в глави от 4.2.7 „ПЧО/ПЧП (предвидени часове на обмен/предвиден час на пристигане) на товара“ до 4.2.9. „Доклади за извършения обмен“.

В следващите точки се описват единствено най-важните данни от съобщенията за предвиждане на движението на влака и от информацията относно движението на влака. Подробните формати са определени в приложение А, индекс 1. Логическата последователност на тези съобщения в зависимост от различните сценарии за комуникация е представена в приложение А, индекс 5, глава 4. Необходимо е да се отбележи, че по отношение на комуникацията между ЖПП и УИ относно движението на влака двете опции, предлагани от сценарий А относно заявката за маршрут, а по-специално случаи А и Б (виж точка 4.2.2.1 „Заявка за маршрут“ — Предварителни бележки) са идентични, като се има предвид че и в двата случая УИ са в контакт само с едно ЖПП, носещо отговорност за целия път и за новия състав на влаковата композиция в точките за маневриране.

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

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

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

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

—	номерата на влака и на маршрута,

—	предвидените дата и час на тръгване на влака от местоположението на УИ (или предвидения час на трансфер към следващия УИ),

—	идентификацията на пункта за наблюдение,

—	предвидените дата и час на пристигане в пункта за наблюдение.

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

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

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

—

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

4.2.5.   Информация за прекъсване на услугата

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

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

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

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

В изключителни случаи, когато ЖПП или УИ не са в състояние да осигурят движението на влака на предвидените дата и час, трябва да бъде договорен нов маршрут съгласно глава 4.2.2 (Заявка за маршрут).

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

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

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

—	номерата на маршрута и на влака,

—	идентификацията на местоположението,

—	предвидените дата и час на тръгване от това местоположение,

—	причината за прекъсването,

—	описанието на прекъсването.

4.2.6.   Локализиране на влака

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

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

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

—	характеристиките на влака (закъснения, причини за закъснението, места на възникване на закъсненията),

—	всички идентификационни данни на влака,

—	предвижданията за движението на влака в определено място,

—	всички предвиждания за движението на влака в определено място.

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

4.2.6.2.   Заявка за сведения относно съобщенията, свързани с движението на влака

Цел	:	да се позволи на ЖПП да получи сведения относно последния записан статус (местоположение, закъснения и причини за закъснението) на определен влак в инфраструктурата на даден УИ.
Заявка за получаване на сведения	:	основни данни: — номер на влака, — идентификационен номер на УИ, — предвидени дата и час на тръгване от местоположението на УИ.
Отговор	:	информационни данни: — последното наблюдавано местоположение, — действителния час в пункта за наблюдение, — положение на влака в пункта за наблюдение (пристигане, потегляне, преминаване, неуказано, потегляне от отправната точка, пристигане по местоназначение), — линията на пристигане в съответното място, — линията на потегляне от съответното място, — предвиден час, — закъснение (Х) спрямо предвидения час, — предвидено ново разписание (спрямо текущото разписание, ако съществуват няколко), — за всяко закъснение в този пункт за наблюдение: — код на причината и времетраене на закъснението за този код.

4.2.6.3.   Заявка за сведения относно съобщенията, свързани със закъсненията и характеристиките на влака

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

4.2.6.4.   Заявка за сведения относно съобщенията, свързани с идентификационния номер на влака

Цел	:	да се позволи на ЖПП да поиска сведения за текущия идентификационен номер на влака и за предишните идентификационни номера. При заявката е възможно да се използва всеки един идентификационен номер за определен влак.
Заявка за получаване на сведения	:	основни данни: — известен номер на влака, — идентификационен номер на УИ, — предвидени дата и час на тръгване от местоположението на УИ.
Отговор	:	информационни данни: — Текущ идентификационен номер на влака: — номер на влака, — предвидени дата и час на тръгване от местоположението на УИ. — За всеки друг идентификационен номер на влака: — номер на влака, — предвидени дата и час на тръгване от местоположението на УИ.

4.2.6.5.   Заявка до УИ за сведения относно съобщенията, свързани с предвижданията за движението на влака

Цел	:	да се позволи на ЖПП да получи сведения относно предвидения час на влак в определен пункт за наблюдение или при липса на такъв, в точката на трансфер на УИ.
Заявка за получаване на сведения	:	основни данни: — номер на влака, — предвидените дата и час на тръгване от местоположението на УИ, — идентификационен номер на пункта за наблюдение (този, от който се иска предвиждането). Тази информация не е задължителна. Ако не е указано друго, в отговора се посочва крайният пункт за наблюдение на този УИ за този влак.
Отговор	:	информационни данни: — код на УИ, — идентификацията на пункта за наблюдение, — предвидените дата и час на пристигане в пункта за наблюдение.

4.2.6.6.   Заявка до УИ за сведения относно съобщенията, свързани с влаковете в пункта за наблюдение

Цел	:	да се позволи на ЖПП да получи сведения относно всички влакове в определен пункт за наблюдение в инфраструктурата на даден УИ.
Заявка за получаване на сведения	:	основни данни: — код на УИ, — идентификация на пункта за наблюдение (този, от който се иска предвиждането). Тази информация не е задължителна. Ако не е указано друго, в отговора се посочва крайният пункт за наблюдение на този УИ за този влак.
Отговор	:	информационни данни: — за всеки от влаковете на заявителя: — номер на влака, — предвидените дата и час на тръгване на влака от местоположението на УИ или предвидения час на трансфер, — код на УИ, — идентификацията на пункта за наблюдение, — предвидените дата и час на пристигане в пункта за наблюдение.

4.2.7.   ПЧО/ПЧП (предвидени часове на обмен/предвиден час на пристигане) на товара

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

Глави от 4.2.2 (Заявка за маршрут) до 4.2.6 (Локализиране на влака) разглеждат основно комуникацията, осъществявана между ЖПП и УИ. Доколкото задачата на управителя на инфраструктура е да контролира влаковете, най-важният елемент, който трябва да се спомене при тази комуникация, е номерът на влака. Частта от съобщението относно вагоните на влаковата композиция се използва за проверка на състава на влаковата композиция въз основа на разпоредбите на сключения между УИ и ЖПП договор за предоставяне на маршрут, както и при извънредни случаи.

Този обмен на информация не обхваща проследяването на вагоните или на интермодалните единици. Това се извършва от ЖПП и ГЖПП въз основа на съобщенията относно влаковете и е описано в глави от 4.2.7 (ПЧО/ПЧП (предвидени часове на обмен/предвиден час на пристигане) на товара) до 4.2.9 (Доклади за извършения обмен).

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

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

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

4.2.7.2.   Изчисляване на ПЧО/ПЧП (предвидени часове на обмен/предвиден час на пристигане)

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

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

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

Пример 1	:	ЖПП № 1 разполага с вагони № 1 и № 2 на ГЖПП № 1 и с вагони от № 3 до № 5 на ГЖПП № 2 в един и същ влак. В точка за обмен В поемането на вагони № 1 и № 2 се осигурява от ЖПП № 2, а поемането на вагони от № 3 до № 5 се осигурява от ЖПП № 3. В този случай ЖПП № 1 трябва да изчисли ПЧО на вагони № 1 и № 2 в точка за обмен В и трябва да изпрати тези стойности на ГЖПП № 1. ЖПП № 1 трябва също така да изчисли ПЧО на вагони от № 3 до № 5 в точка за обмен В и да изпрати тези стойности на ГЖПП № 2.
Пример 2	:	ЖПП № 1 разполага с вагони № 1 и № 2 на ГЖПП № 1 и с вагони от № 3 до № 5 на ГЖПП № 2 в един и същ влак. В точка за обмен В поемането на вагони от № 3 до № 5 се осигурява от ЖПП № 3, докато вагони № 1 и № 2 остават прикачени за влака на ЖПП № 1 до точка за обмен Д, в който се предават на ЖПП № 2. В този случай ЖПП № 1 трябва да изчисли само ПЧО на вагони от № 3 до № 5 в точка за обмен В и трябва да изпрати тези стойности на ГЖПП № 2. Точка за обмен В няма отношение към вагони 1 и 2. Следващата точка за обмен за тези вагони е Д, като ЖПП № 1 трябва да изчисли ПЧО относно него и трябва да изпрати тези стойности на ГЖПП № 1.

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

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

ГЖПП е натоварено с проверката на спазването на ПЧО въз основа на ангажиментите, които са поети към клиента.

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

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

4.2.7.3.   Съобщение „ПЧО/ПЧП на вагона“

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

4.2.7.4.   Предупредително съобщение

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

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

4.2.7.5.   Заявка за сведения относно съобщенията, свързани с констатираните отклонения

Цел	:	да се позволи на ГЖПП да поиска сведения за отклоненията по отношение на даден вагон.
Заявка за получаване на сведения	:	основни данни: — номер на вагона, — идентификационен номер на ГЖПП.
Отговор	:	информационни данни: — за всеки пункт за наблюдение: — пунктът за наблюдение, — положението на вагона в пункта за наблюдение (потегляне, пристигане в разпределителна гара, потегляне от разпределителна гара, пристигане в точката за обмен, пристигане в разпределителната гара по местоназначение), — отговорното ЖПП в пункта за наблюдение в зависимост от статуса на вагона в този пункт, — новото разписание (спрямо текущото разписание, ако съществуват няколко), — ПЧО, ако пунктът за наблюдение е точка за обмен, — действителният час в пункта за наблюдение, — за всяко отклонение в този пункт за наблюдение: — код на причината и времетраене на закъснението поради тази причина.

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

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

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

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

—	Известие за потегляне на вагон

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

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

—	Съобщение за известяване за инцидент

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

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

—	Потвърждение за доставяне на вагон

—	Докладът относно обмена на вагони е предмет на отделно описание в глава 4.2.9 „Доклади за извършения обмен“.

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

Цел	:	това известие се изпраща от ГЖПП на ЖПП. Ако това ЖПП не е първото ЖПП в транспортната верига, то трябва да информира отговорното ЖПП че вагонът е готов да потегли (мястото на потегляне зависи от поетите от ГЖПП ангажименти), в указания момент на освобождаване (дата и час на потегляне). Това съобщение трябва да бъде записано в оперативната база данни за вагоните и интермодалните единици.
Основни данни	:	— номер на вагона, — място, дата и час на тръгване (предвидено място на потегляне). Следните данни трябва да бъдат леснодостъпни за ЖПП и ГЖПП в базата данни: — идентификация, размер и тип на транспортната единица, — използвана единица при изразяване на капацитета, — общо тегло (маса) (заявено и действително тегло на стоките, включително опаковката и оборудването на превозвача), — указване на опасните стоки.

4.2.8.3.   Известие за тръгване на вагон

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

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

Цел	:	ЖПП трябва да информира ГЖПП, че вагонът е пристигнал в неговата разпределителна гара. Това съобщение може да се основава на съобщението за информиране относно движението на влака, описано в глава 4.2.4 „Предвиждане на движението на влака“. Това съобщение трябва да бъде записано в оперативната база данни за вагоните и интермодалните единици.
Основни данни	:	— номер на вагона, — идентификация на разпределителната гара, в която се пристига, — дата и час на пристигане в депото.

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

Цел	:	ЖПП трябва да информира ГЖПП, че вагонът е напуснал неговата разпределителна гара. Това съобщение може да се основава на съобщението за информиране относно движението на влака, описано в глава 4.2.4 „Предвиждане на движението на влака“. Това съобщение трябва да бъде записано в оперативната база данни за вагоните и интермодалните единици.
Основни информативни елементи	:	— номер на вагона, — идентификация на разпределителната гара, от която се тръгва, — дата и час на потегляне от разпределителната гара.

4.2.8.6.   Съобщение за известяване за инцидент

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

4.2.8.7.   Съобщение за известяване за инцидент: искане на нов ПЧО/ПЧП

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

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

Цел	:	последното ЖПП от транспортната верига при превоза на вагон или на интермодална единица трябва да информира ГЖПП, че вагонът е пристигнал в неговата разпределителна гара (в местоположението на ЖПП).
Основни данни	:	— номер на вагона, — идентификация на разпределителната гара на ЖПП, — дата и час на пристигане.

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

Цел	:	последното ЖПП от транспортната верига трябва да информира ГЖПП, че вагонът е поставен на разпределителните коловози на получателя.
Основни данни	:	— номер на вагона, — идентификация на мястото, в което вагонът е поставен на разпределителните коловози на получателя (място, зона, коловоз, местоположение), — дата и час на тази маневра.

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

—	идентификация на клиента.

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

Диаграмата на последователността на тези съобщения, базираща се на пример № 1 относно изчисляването на ПЧО на вагони № 1 и № 2 (виж глава 4.2.7.2: Изчисляване на ПЧО/ПЧП), е включена в диаграмата относно докладите за извършения обмен в приложение А, индекс 5, глава 6.

4.2.9.   Доклади за извършения обмен

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

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

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

—	известие за обмен на вагон,

—	известие за обмен на вагон (допълнително съобщение),

—	вагонът приет в точката за обмен,

—	вагонът отказан в точката за обмен.

Данните, съдържащи се в тези съобщения, трябва да бъдат записани в оперативната база данни за вагоните и интермодалните единици. В случай на закъснение трябва да бъде изчислен на нов ПЧО/ПЧП, който да бъде изпратен в съответствие с процедурата, описана в глава 4.2.7 „ПЧО/ПЧП на товара“. Диаграмата на последователността на тези съобщения е представена заедно със съобщенията за движението на влаковете в приложение А, индекс 5, глава 6.

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

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

Тези съобщения са описани по-долу.

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

Цел	:	с това известие ЖПП № 1 пита следващото ЖПП № 2 от транспортната верига дали приема да поеме отговорността за вагона. Чрез допълнителното съобщение от известието за обмен на вагона ЖПП 2 информира УИ, че приема да поеме отговорността за вагона до следващото ЖПП.
Основни данни	:	— номер на вагона, — номер на влака (единствено ако вагонът е прикачен към влак), — място, дата и час на обмена. Освен това следните данни трябва да бъдат леснодостъпни и да са записани в базите данни: — идентификация на транспортната единица (номер, размер, тип), — общо тегло (маса) (заявено и действително тегло на стоките, включително опаковката и оборудването на превозвача), — използвана единица при изразяване на капацитета, — идентификация на опасните стоки.

4.2.9.3.   Известие за обмен на вагон (допълнително съобщение)

Цел	:	допълнителното съобщение от известието за обмен на вагона позволява на ЖПП 2 да информира УИ, че приема да поеме отговорността за вагона.
Основни данни	:	— номер на вагона, — номер на влака (единствено ако вагонът е прикачен към влак), — място, дата и час на обмена. Освен това следният елемент трябва да бъде леснодостъпен и да бъде записан в базите данни: — идентификация на опасните стоки.

4.2.9.4.   Вагонът приет в точката за обмен

Цел	:	съобщението „вагонът приет в точката за обмен“ позволява на ЖПП № 2 да информира ЖПП № 1, че приема да поеме отговорността за вагона.
Основни данни	:	— номер на вагона, — място, дата и час на обмена.

4.2.9.5.   Вагонът отказан в точката за обмен

Цел	:	съобщението „вагонът отказан в точката за обмен“ позволява на ЖПП № 2 да информира ЖПП № 1, че не желае да поеме отговорността за вагона.
Основни данни	:	— номер на вагона, — място, дата и час на обмена, — код на причината за отказа, — други елементи (опционално).

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

За да бъде конкурентоспособен, европейският отрасъл на железопътния транспорт трябва да предоставя на своите клиенти висококачествени услуги (виж също така приложение III, член 2.7.1 към Директива 2001/16/ЕО).

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

Освен тази оценка ГЖПП, ЖПП и УИ трябва да правят оценка на качеството на отделните компоненти на услугата, което е неразделна част от предоставения продукт.

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

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

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

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

Оценяването се извършва неколкократно.

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

1.   ГЖПП/Клиент: време на извършване на транзит, ПЧП, предупредителна резолюция

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

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

известието за потегляне,

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

2.   ГЖПП/Доставчици на услуги: време на извършване на транзит, ПЧП, ПЧО, кодове за причината

Договорите между ГЖПП и останалите доставчици на транспортни услуги могат да включват разпоредби относно времето на извършване на транзит (в часове) въз основа на следните елементи:

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

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

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

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

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

времето между разтоварването и доставката.

Най-подходящите съобщения относно тази оценка на качеството са:

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

известието за потегляне,

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

потеглянето от разпределителната гара,

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

известието за обмен на вагон,

вагонът приет в точката за обмен,

вагонът отказан в точката за обмен.

3.   ЖПП/УИ: точност на влака, ПЧП на влака (ПЧПВ), ПЧО

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

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

информацията относно движението на влака,

заявката за сведения/отговора относно закъснението/точността на влаковете.

4.   ЖПП/УИ: (предвидена) наличност на маршрута

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

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

анулиран маршрут,

невъзможен за използване маршрут.

5.   ЖПП/УИ: краткосрочна заявка за предоставяне на маршрут

Когато ЖПП желае да експлоатира влак извън предвидените времеви рамки на съответния маршрут, то трябва да изпрати краткосрочна заявка за предоставяне на маршрут на съответния(те) УИ (съгласно разпоредбите на Директива 2001/14/ЕО).

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

сравнение между времето за отговор на заявката и времето, предвидено от рамковото споразумение,

сравнение между броя на предоставените в определен срок маршрути и предоставените в заявения срок,

вземане под внимание на броя на отказаните заявки за маршрути.

Най-подходящите съобщения относно тази оценка на качеството са:

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

подробности за маршрута,

отказани подробности за маршрута,

анулиран маршрут,

невъзможен за използване маршрут.

6.   УИ/EF: качество на влаковата композиция

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

влакова композиция,

влак неподходящ.

4.2.11.   Основни референтни данни

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

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

4.2.11.2.   Бази данни с информация за ограниченията по отношение на инфраструктурата

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

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

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

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

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

4.2.11.3.   Референтни бази данни относно подвижния състав

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

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

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

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

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

—	необходимите характеристики относно спирачното действие,

—	данните относно поддръжката,

—	характеристиките относно околната среда.

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

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

—

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

—

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

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

Освен референтните данни относно подвижния състав, най-важни за целите на експлоатацията са тези, които указват неговия реален „статус“.

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

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

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

—	притежателят на подвижния състав, и

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

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

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

4.2.12.   Справочни файлове и бази данни

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

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

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

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

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

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

—	справочен файл за числовото кодиране на клиентите,

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

—	справочен файл за числовото кодиране за местонахожденията на клиентите,

—	справочен файл на всички системи за контрол на влаковете, превозващи опасни товари, ООН и RID номера,

—	справочен файл на опасните товари, ООН и RID номера,

—	справочен файл за всички видове локомотиви,

—	справочен файл на всички кодове на стоки по КН и ХС,

—	справочен файл на всички европейски цехове за техническо обслужване,

—	справочен файл на всички европейски контролни органи,

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

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

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

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

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

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

Тези бази данни трябва да бъдат достъпни чрез общия интерфейс (глави 4.2.14.1 „Обща архитектура“ и 4.2.14.7 „Общ интерфейс“).

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

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

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

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

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

—	Статус: вагон, натоварен в точка от пътя

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

—	Статус: вагон празен в точка от пътя

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

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

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

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

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

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

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

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

Забележка:

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

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

4.2.12.3.   Допълнителни разпоредби относно базите данни

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

Те са:

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

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

3.	Кохерентност Базата данни трябва да гарантира прилагането на принципа ACID (атомистичност, кохерентност, изолация, устойчивост).

4.

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

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

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

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

8.	Надеждност Надеждността на базата данни трябва да гарантира изискваната достъпност на данните.

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

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

11.

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

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

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

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

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

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

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

18.

Работни параметри Базата данни позволява обработването на достатъчен брой заявки за консултиране, така че да се гарантира нейната ефективност при около 60 000 записани движения на влакове на всеки 24 часа. Около 50 % от тези движения се извършват в рамките на два часа. Броят и типът на консултиранията или актуализиранията за всеки от влаковете зависят от глобалната процедура по планиране и експлоатация.

19.

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

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

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

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

Забележки:

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

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

4.2.13.   Предаване на документи по електронен път

Глава 4.2.14 „Свързване в мрежа и комуникация“ описва комуникационната мрежа, която се използва за обмен на данни. Тази мрежа и свързаните с нея мерки за сигурност позволяват осъществяването на независимо какъв тип комуникация чрез електронна поща, трансфер на файлове (FTP, HTTP) и т. н. Следователно потребителите могат сами да решат какъв тип комуникация ще изберат, например протокола FTP.

4.2.14.   Свързване в мрежа и комуникация

4.2.14.1.   Обща архитектура

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

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

Тази архитектура на информационния обмен:

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

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

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

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

Моделът на взаимодействие на принципа „от точка до точка“ (мрежа от равноправни възли) позволява да се направи най-доброто разпределение на разходите между различните участници на базата на действителното ползване на архитектурата от тяхна страна. Тя по принцип ще бъде по-малко уязвима от проблемите, свързани с йерархичните нива. Представянето чрез изображения на общата архитектура е изложено в приложение А, индекс 5, глава 1.5.

4.2.14.2.   Мрежа

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

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

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

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

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

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

4.2.14.3.   Протоколи

Трябва да се използват само протоколи, които са част от Пакет от Интернет-протоколи (Internet Protocol Suite).

4.2.14.4.   Сигурност

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

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

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

4.2.14.6.   Централен регистър

Централният регистър трябва да бъде в състояние да взема предвид:

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

—	инфраструктурата на публични ключове (ИПК),

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

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

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

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

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

Общият интерфейс трябва да бъде в състояние да взема предвид:

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

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

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

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

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

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

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

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

Проверката на автентичността на входящите съобщения предвижда две възможности за признаване на съобщението:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

—

точност,

—	изчерпателност,

—	кохерентност,

—	своевременно изпращане.

Точност:

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

Изчерпателност:

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

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

Кохерентност:

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

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

Навременно изпращане на информацията:

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

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

Времето за отговор на заявките за получаване на сведения не трябва да надхвърля 5 минути. Актуализирането и обменът на данни трябва да се извършват в най-кратки срокове. Времето за реагиране на системата и за предаване на данните с цел тяхното актуализиране не трябва да надвишава една минута.

Мерки за осигуряване качеството на данните

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

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

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

4.4.2.   Управление на централния регистър

Функциите на централния регистър са определени в глава 4.2.14.6 „Централен регистър“. За да се гарантира качеството на данните, органът, натоварен с управлението му, трябва да бъде отговорен за актуализирането и качеството на метаданните и на регистъра, както и за управлението на контрола на достъпа (публичен ключ). Що се отнася до качеството на метаданните, тяхната изчерпателност, кохерентност и точност трябва да достига 100 %.

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

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

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

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

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

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

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

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

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

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

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

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

4.8.   Регистри на инфраструктурата и на подвижния състав

На основание член 24, параграф 1 от Директива 2001/16/ЕО „държавите-членки осигуряват ежегодното публикуване и актуализиране на регистрите на инфраструктурата и на подвижния състав. Тези регистри посочват основните характеристики на всяка една съставна подсистема или част от подсистема, основните параметри и тяхната корелация с характеристиките, предписани в приложимите ТСОС. За тази цел всяка ТСОС посочва точно каква информация трябва да се включва в регистрите за инфраструктурата и за подвижния състав.“

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

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

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

Съгласно член 2, буква г) от Директива 2001/16/ЕО съставните елементи на оперативната съвместимост са „всеки елементарен компонент, група от съставни елементи, подкомплект или комплект от оборудване, включени или предназначени да бъдат включени в подсистема, от която оперативната съвместимост на трансевропейската конвенционална железопътна система зависи пряко или непряко. Понятието „съставен елемент“ обхваща материалните и нематериалните вещи, като например компютърните програми.“

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

Съставните елементи на оперативната съвместимост са обхванати в разпоредбите на Директива 2001/16/ЕО.

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

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

5.3.   Характеристики и спецификации на съставните елементи

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

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

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

6.1.1.   Процедури по оценяване

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

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

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

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

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

6.1.2.   Модул

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

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

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

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

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

Въз основа на приложение II към Директива 2001/16/ЕО подсистемите се разпределят на области от структурен или функционален вид.

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

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

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

—	Централният регистър съдържа справочника (телефонния указател) с информация за всички участници в обмена на съобщения. Той трябва да се актуализира постоянно. Грешките се откриват незабавно. Не се налага прилагането на процедура по оценка.

—	Централният регистър съдържа също така и данните относно сертифициращия орган. Става дума основно за прилагането на административна разпоредба. Грешките се откриват незабавно. Не се налага прилагането на процедура по оценка.

—

Централният регистър съдържа метаданните относно съобщенията (съгласно приложение А, индекс 1), които служат като основа за обмена на съобщения в разнообразна информационна среда. Те трябва да бъдат управлявани и актуализирани в рамките на този регистър. Всяка несъвместимост в структурата на съобщенията или съдържанието им ще бъде открита своевременно и трансферът ще бъде отказан. Не е необходима никаква процедура по оценка.

—

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

7.   ПРИЛАГАНЕ

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

7.1.1.   Въведение

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

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

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

7.1.2.   Стратегически европейски план за развитие (SEDP)

7.1.2.1.   Цели на стратегическия европейски план за развитие

Стратегическият европейски план за развитие (SEDP) преследва три цели:

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

2.	извършване на технико-икономическо проучване за осъществимостта на този план;

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

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

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

7.1.2.2.   Изисквания относно прилагането на стратегическия европейски план за развитие

Изготвянето на този план изисква систематичен анализ на въпросите от технически, оперативен, икономически и институционален характер, които са в основата на процеса по прилагане на ТСОС „Телематични приложения за превоз на товари“ (ТППТ). Той по-специално включва:

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

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

3.

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

4.	определяне на техническите критерии, по-специално относно интерфейса, на системата ТППТ и на нейните ориентирани към клиента потенциални подсистеми;

5.

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

6.	определяне на управленските структури, необходими за прилагането на системата ТППТ и за нейното използване;

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

Този анализ не трябва да бъде извършен само веднъж. Той трябва да бъде проведен на няколко пъти, за да се определи най-добрата стратегия за развитието на системата. Анализът трябва да достигне до следните резултати:

—	пълен комплект от функционални, системни и технически спецификации, както и такива относно работните характеристики, необходими за придобиването на система ТППТ,

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

—	определяне на управленската структура, методите и процедурите (7), които са в основата на прилагането, валидирането и функционирането на системата,

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

7.1.3.   Изисквания относно прилагането

Изискванията относно прилагането на настоящата ТСОС се подчиняват на условията от посочения по-горе стратегически европейски план за развитие (SEDP).

Изготвянето на стратегическия европейски план за развитие трябва да включва следните етапи:

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

—

Определените в член 3, параграф 2 от Регламент (ЕО) № 881/2004 представителни органи от железопътния сектор на европейско ниво трябва да изготвят стратегически европейски план за развитие в съответствие с критериите, изложени по-горе. Те предават този стратегически план на останалите държави-членки и на Комисията най-късно една година след датата на публикуване на настоящия регламент. Ако в края на този период не е отбелязан никакъв значителен напредък, Европейската комисия трябва да изготви предложения в областта на законодателството с цел прилагане на настоящата ТСОС.

—

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

7.2.   Стратегия за извършване на преход

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

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

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

Етап 1: Общата архитектура, така както тя е определена в глава 4.2.14.1 (Обща архитектура), изисква наличието на „централен регистър“, управляван от неутрален и независим орган. На местоположението на всеки от участниците в комуникационната мрежа има интерфейсен слой, който евентуално може да бъде снабден със система за обмен на съобщения и който е специално разработен с оглед на оперативната съвместимост, независимо дали тя е централизирана или индивидуална. В случая става дума за спазване на изискванията за „свързването в мрежа и комуникацията“, единствените оперативни аспекти, които са необходими за оперативната съвместимост. Тези изисквания освен това представляват предварителните базови условия за прилагането на система за обмен на данни на европейско ниво. Ето защо те трябва да бъдат спазвани и прилагани преди всеки друг етап.

След като този етап завърши, вече е възможно документите да се предават по електронен път (глава 4.2.13 „Предаване на документи по електронен път“) независимо от логическата последователност на останалите етапи.

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

Етап 2: едновременно с първия етап или веднага след него е необходимо да се създадат референтните бази данни относно подвижния състав и оперативната база данни за вагоните и интермодалните единици (глава 4.2.11.3 „Референтни бази данни относно подвижния състав“ и глава 4.2.12.2 „Други бази данни“). Ако всички данни все още не са въведени в базите данни, поне трябва да е възможно ръчното въвеждане в оперативната база данни относно вагоните и интермодалните единици на информацията относно различните вагони, която е необходима за експлоатацията на влака, така както тя е посочена в приложение А, индекс 2.

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

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

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

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

Етап 4: процедурата относно съобщенията за заявка за маршрут може да бъде прилагана независимо от следващите етапи. Въпреки това от етап 6 нататък е необходимо маршрутът да бъде указван чрез съответен номер.

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

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

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

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

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

Етап 7: най-късно преди началото на етап 8 е необходимо ЖПП да гарантират прилагането на функциите относно движението на вагоните (известие за освобождаване на вагона и известие за потегляне, пристигане на вагона в разпределителна гара, потегляне на вагона от разпределителна гара, известие за пристигане на вагона, известие за доставяне на вагона и потвърждаване на доставянето), както и функцията относно плана за пътуването.

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

Етап 8: този етап засяга съобщенията, свързани с движението на влака и с предвижданията за движението на влака. Благодарение на съобщението за предвиждане на движението на влака е възможно изпращането на съобщението за предвидения час на пристигане на влака (ПЧПВ и предвидено време на трансфер), което служи като основа за изчисляването на ПЧО и ПЧП на вагоните/товарите. Този етап включва също така процедурата по изпращане на въпроси/отговори относно движението на влака и относно предвижданията за движението на влака.

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

Етап 9: докладите относно обмена (глава 4.2.9 „Доклади за извършения обмен“) и функцията, представена в глава 4.2.7 „ПЧО/ПЧП на товара“, трябва да започнат да се прилагат едновременно с осмия етап или непосредствено след неговото приключване. Този етап засяга по-специално железопътните предприятия.

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

Етап 10: този етап засяга прилагането на функцията „информация относно прекъсването на услугата“, както и процедурата по изпращане на въпроси/отговори относно закъсненията на влаковете, техните идентификационни номера и местоположение. Тази информация позволява да се изпращат съобщения на ЖПП относно инцидентите (глава 4.2.8.6 „Съобщение за известяване за инцидент“ и глава 4.2.8.7 „Съобщение за известяване за инцидент: искане на нов ПЧО/ПЧП“).

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

Етап 11: След фаза на консолидиране този етап се състои в оценка на данните, които са предадени и записани.

Степен на прилагане, достигната след края на този етап
от УИ	от ЖПП
Наличност на изчерпателни статистически бази данни Предимство:   Подобряване на качеството на услугите чрез добавяне на данни.

7.3.   Управление на промените

7.3.1.   Въведение

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

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

—

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

—	въвеждането на стратегия относно прилагането на основните линии на системата.

7.3.2.   Основни линии

Стабилността на системата е необходима за нейното функциониране и развитие. Това се отнася до всички участващи страни:

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

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

Основната линия олицетворява основно понятието за стабилно ядро по отношение на функционалността, работните параметри и другите характеристики, които не са свързани с функционирането на системата (например RAM) (9). Въпреки това опитът с този тип система показва, че са необходими няколко различни версии (10), преди да се достигне до основна линия, която е стабилна и подходяща за желаното прилагане, както това е показано в графиката по-долу:

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

7.3.3.   Прилагане на основните линии

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

Новата основна линия по принцип трябва да съдържа най-важните промени по отношение на функционалността или на характеристиките на системата. Това може да включва следното:

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

—	други услуги с добавена стойност.

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

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

7.3.4.   Създаване на нови основни линии

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

7.3.5.   Управление на промените — изисквания

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

Съвкупността от стандартите и процедурите, които са в основата на процедурата по управление на осъвременяванията, така както тя е описана по-горе, трябва да бъде описана в план за управление на конфигурацията. Общите спецификации на този план са описани в параграф 7.3.6 по-долу. Одобрената стратегия за прилагане на осъвременяванията трябва да бъде формализирана (съгласно разпоредбите и въз основа на документите ad hoc) в рамките на план за управление на осъвременяванията, в който по-специално трябва да се отбележи:

—	техническите изисквания, които са в основата на промените,

—	кой носи отговорност за процедурите по прилагане на промените,

—	процедурата по валидиране на промените, която трябва да се прилага,

—	политиката на управление на промените, по тяхното прилагане, по извършване на прехода и по осигуряване на развитие.

Важен аспект от управлението на осъвременяването на системата е определянето на отговорностите за изготвяне на спецификациите, гарантирането на качеството им и управлението на конфигурацията. По-голямата част от тази дейност би трябвало да се поеме от Европейската железопътна агенция (установена с Регламент № 881/2004/ЕО) или да бъде контролирана от нея щом тя започне да функционира. Управлението на промените трябва да бъде формализирано чрез комплекта от документи, посочени в приложение А.

И на последно място е необходимо органът, натоварен с контролирането на промените (CCB) (Change Control Board), който ще упражнява контрол над цялата система, да се състои от пълномощни представители на всички участници: управителите на инфраструктурата, железопътните предприятия, техните доставчици, нотифицираните органи и контролните органи. Това участие на всички страни трябва да гарантира вземането под внимание на промените, които е необходимо да се направят, както и извършването на глобална оценка на последиците от тях. Впоследствие ССВ ще премине под управлението на Европейската железопътна агенция.

7.3.6.   План за управление на конфигурацията — изисквания

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

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

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

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

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

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

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

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

7.4.   Особени случаи

7.4.1.   Въведение

Разрешени са следните специални разпоредби в представените по-долу особени случаи.

Особените случаи се разпределят в две категории: постоянни (случай „P“) или временни (случай „T“). При временните случаи на заинтересованите държави-членки се препоръчва да се съобразяват или със съответната подсистема до 2010 г. (случай „T1“), като тази цел е записана в Решение № 1692/96/ЕО на Европейския парламент и на Съвета от 23 юли 1996 г. относно насоките на Общността за развитие на трансевропейската транспортна мрежа (11), или до 2020 г. (случай „T2“). „Отворено T“ се счита като неопределен период, който ще бъде уточнен по време на по-късно ревизиране на настоящата ТСОС.

7.4.2.   Списък на особените случаи

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

На територията на държавите-членки, които притежават обща граница с трети страни, изискванията на ТСОС не са задължителни за преките транспортни връзки с тези трети страни (случай „отворено T“).

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

7.4.2.2.   Особен случай, засягащ Гърция

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

---

(1)  ОВ L 75, 15.3.2001 г., стр. 29. Директива, последно изменена с Директива 2004/49/ЕО (ОВ L 164, 30.4.2004 г., стр. 44), поправена с ОВ L 220, 21.6.2004 г., стр. 16.

(2)  ОВ L 220, 30.8.1993 г., стр. 23.

(3)  ОВ L 75, 15.3.2001 г., стр. 26.

(4)  ОВ L 237, 24.8.1991 г., стр. 25. Директива, последно изменена с Директива 2004/51/ЕО на Европейския парламент и на Съвета (ОВ L 164, 30.4.2004 г., стр. 164), поправена с ОВ L 220, 21.6.2004 г., стр. 58.

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

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

(7)  Например стандартите за гарантиране на качеството, методиката на изготвяне на плана, методиката на провеждане на експерименти, планирането на документите и др.

(8)  Телематични приложения в областта на превоза на товари са телематични приложения, използвани преди влизането в сила на ТСОС.

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

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

(11)  ОВ L 228, 9.9.1996 г., стр. 1. Решение, последно изменено с Решение № 884/2004/ЕО (ОВ L 167, 30.4.2004 г., стр. 1), поправено с ОВ L 201, 7.6.2004 г., стр. 1.

ПРИЛОЖЕНИЕ А

СПИСЪК НА ПРИДРУЖАВАЩИТЕ ДОКУМЕНТИ

Списък на задължителните спецификации

Индекс №	Документ	Наименование на документа	Версия
1	AEIF_TAF_MesData_V11_041021.doc	Подсистема „Телематични приложения за превоз на товари“ — Определения и съобщения, свързани с данните	1.1
2	AEIF_TAF_DbsData_V10_040322.doc	Подсистема „Телематични приложения за превоз на товари“ — Данни относно инфраструктурата и подвижния състав	1.0
3	AEIF_TAF_ConData_V10_040622.doc	Подсистема „Телематични приложения за превоз на товари“ — Описание и информация относно товарителницата	1.0
4	AEIF_TAF_Patdata_V10_040622.doc	Подсистема „Телематични приложения за превоз на товари“ — Описание и информация относно маршрутите	1.0
5	AEIF_TAF_FigSeq_V10_040622.doc	Подсистема „Телематични приложения за превоз на товари“ — Илюстрации и секвенциални диаграми относно съобщенията на ТСОС „Телематични приложения за превоз на товари“	1.0
6	AEIF_TAF_CofMgt_V10_041012.doc Pending	Управление на конфигурацията, понятие и общи условия на ТСОС „Телематични приложения за превоз на товари“	1.0

ПРИЛОЖЕНИЕ Б

РЕЧНИК

Термин	Описание
ACID	Атомичност, кохерентност, изолация, устойчивост Става въпрос за четирите основни съставки на всяка трансакция.   Атомичност: при трансакция, в която участват най-малко два информационни елемента, или всички елементи се вземат под внимание, или нито един от тях.   Кохерентност: една трансакция или създава ново валидно състояние на данни, или при неуспех възстановява всички данни в началното им състояние.   Изолация: трансакция, която е в процес на протичане и все още не е валидирана, трябва да остане изолирана от всяка друга трансакция.   Устойчивост: Валидираните данни се записват в системата по такъв начин, че да остават на разположение в нормално им състояние, дори при изключване и рестартиране на системата. Концепцията на ACID е определена в Стандарт ISO/IEC (Международната електротехническа комисия) 10026-1:1992 г., раздел 4. Всеки от нейните атрибути може да бъде оценяван по отношение на референтна стойност. По принцип прилагането на тази концепция е задължение на управителя или супервайзъра на трансакцията. В една система с разпределена база данни тя може да бъде гарантирана чрез валидиране на два етапа (2 PC), която задължава всички участващи страни да се ангажират с валидирането на трансакцията. В противен случай тя се анулира.
FTP	Съкращение на File Transfer Protocol (Протокол за трансфер на файлове) Протокол за трансфер на файлове между компютърни системи
GGP	Съкращение на Gateway to Gateway Protocol (протокол за трансфер на информация между шлюзови устройства).Виж също IP
HTTP	Съкращение на HyperText Transfer Protocol Става въпрос за протокол от типа клиент/сървър, използван за връзка със сървъри в Интернет-мрежата.
ICMP	Съкращение на Internet Control Message Protocol (Протокол за управление на контролни съобщения)Протоколът ICMP се използва понякога от шлюзово устройство (виж GGP) или от главен (хост) компютър (виж IP) за комуникация с локален компютър, например за да му сигнализира за грешка при обработката на дейтагарама. Протоколът ICMP използва IP-протокола като базов носител, все едно че е протокол от високо ниво; всъщност той е неразделна част на IP-протокола и трябва да бъде вграден във всеки IP-модул. Съществуват няколко положения, при което се изпращат съобщения ICMP: например когато една дейтаграма не може да стигне до местоназначението си, когато шлюзът няма достатъчно буферна памет за препращане на дейтаграмата, и когато шлюзът даде указание на главния (хост) компютър да изпрати поток от данни по по-кратък маршрут. IP-протоколът (виж това съкращение) не е проектиран да притежава абсолютна надеждност. Целта на тези контролни съобщения е да се предостави обратна информация за проблемите на комуникационната среда, а не IP-протоколът да стане по-надежден. Въпреки това няма никаква гаранция, че дейтаграмата ще бъде доставена или че контролното съобщение ще бъде върнато. Възможно е някои дейтаграми да не пристигнат по местоназначение и никакво съобщение да не информира за тяхната загуба. Протоколите от високо ниво, които използват IP-протокола, трябва да прилагат свои собствени процедури за надеждност, ако се изисква надеждна комуникация. По принцип съобщенията на ICMP отчитат грешките при обработване на дейтаграми. За да се избегне безкрайно повтаряне на съобщения, изпращани заради други съобщения и т. н., не се изпраща никакво съобщение ICMP по отношение на съобщения ICMP. Съща така съобщенията ICMP се изпращат само в случай на грешки при обработване на „нулеви“ фрагменти на фрагментирани дейтаграми. („Нулев“ фрагмент означава фрагмент с отместване равно на нула).
ICP (ИПК)	Инфраструктура с публични ключове
IP	Съкращение на Internet Protocol, протокол на Интернет-мрежата Този протокол се използва за услуги по обмен на дейтаграми между главни (хост) компютри в система от взаимосвързани мрежи. Устройства за свързване на мрежите се наричат шлюзове. Тези шлюзове комуникират помежду си с цел извършване на контрол посредством протокол за трансфер на информация между шлюзови устройства (GGP).
NFS	Съкращение на Network File System, протокол за разпределена файлова система Протоколът NFS позволява отдалечен достъп при пълна прозрачност до споделени файлови системи в мрежи. Той е разработен, за да бъде независим от машината, операционната система, мрежовата архитектура, механизма за сигурност и транспортния протокол. Тази независимост се получава благодарение на механизма от примитиви RPC (Remote Procedure Call, извикване на отдалечена процедура), изграден върху XDR (eXternal Data Representation), общ протокол за външно представяне на данни.
OC	Сертифициращ орган
OSI	Съкращение на Open Systems Interconnection (взаимна свързаност на отворени системи) Описва протокол за комуникация между отворени системи на базата на еталонния модел OSI. Отворените системи могат да комуникират независимо от използваните различни нееднородни решения.
RARP	Съкращение на Reverse Address Resolution Protocol (Протокол за обратно преобразуване на адреси).
RID	Нормативна уредба относно международния железопътен превоз на опасни стоки.
RIV	Нормативна уредба за използването на реципрочен принцип на вагони при международния трафик Нормативна уредба за използването на реципрочен принцип на инвентар за товарене, контейнери и палети при международния трафик.
RPC	Съкращение на Remote Procedure Call (Извикване на отдалечена процедура) Протоколът RPC е определен в спецификацията на Протокола за Извикване на отдалечена процедура, версия 2 [RFC1831].
SMTP	Съкращение на Simple Mail Transfer Protocol (опростен протокол за обмен на електронна поща)
SNMP	Съкращение на Simple Network Management Protocol (опростен протокол за управление на мрежа)
SQL	Съкращение на Structured Query Language (език за структурирани заявки) Език, разработен от IBM, след това стандартизиран чрез ANSI и ISO, който се използва за създаване, управление и събиране на информация от релационни бази данни.
TCP	Съкращение на „Transmission Control Protocol“ (протокол за контрол на предаването)
UDP	Съкращение на User Datagram Protocol (Протокол за обмен на дейтаграми) Протоколът UDP извършва обикновено преминаване през NAT (Network Address Translators, превеждане на адресите на мрежата) (STUN); става въпрос за лек протокол, който разкрива присъствието и типовете NAT на приложения и поставя защитна стена между тези приложения и публичния Интернет. Той също така позволява на приложенията да определят публичните IP-адреси, които им се дават от NAT. STUN функционира с голям брой съществуващи програмни продукти и не налага никакво особено поведение от тяхна страна. Следователно той позволява на широка гама от приложения да функционират в съществуваща NAT-инфраструктура.
UIC	Международен съюз на железниците
UITP	Международен съюз на обществения транспорт
UNIFE	Съюз на европейската железопътна индустрия. Тази организация защитава интересите на доставчиците в железопътния сектор. Понастоящем около стотина доставчици и подизпълнители са представени пряко, а около хиляда са представени непряко, посредством техните национални организации.
VPN (ВЧМ)	Виртуална частна мрежа (ВЧМ) Този термин се използва за описване на почти всички типове системи за отдалечена връзка, като публичната телефонна мрежа и ПВВ (постоянните виртуални вериги) (Frame relay). С появата на Интернет, виртуалната частна мрежа стана синоним на отдалечена мрежа за данни, основаваща се на IP-протокола.С една дума виртуалната частна мрежа се състои от две или няколко частни мрежи, които комуникират при пълна сигурност в публичната мрежа. Може да има връзка чрез ВЧМ между една машина и една частна мрежа (клиент към сървър) или между една отдалечена локална мрежа и една публична мрежа (сървър към сървър). Частните мрежи могат да се свързват посредством тунелиране, докато ВЧМ използва по принцип Интернет като базова преносна мрежа, но криптира обменените данни между клиента на ВЧМ и шлюза на ВЧМ, за да бъде сигурно, че те няма да могат да бъдат прочетени, в случай че бъдат прихванати.
Web	Интернет-услуга, която позволява свързването на документи посредством хипертекстови връзки между сървъри, така че потребителят да може да премине от един документ към друг, независимо от мястото, на което той се съхранява в Интернет.
XDR	Съкращение на „External Data Representation“ (представяне на външни данни) Протоколът XDR е специфициран в стандарта за представяне на външни данни [RFC1832]. XDR е стандарт за описване и кодиране на данни. Той се използва за трансфер на данни между различни компютърни архитектури. Той се вписва в презентационния слой от модела OSI и функцията му общо взето е аналогична на ASN (абстрактен език за синтактично описание на ISO), определено в стандарт X-409 на ISO. Основната разлика се състои във факта, че XDR използва имплицитен контрол на типовете, докато X. 409 използва експлицитен контрол на типовете. Освен това XDR използва език за описание на формати на данни. Става въпрос за език само за описване на данни, а не за език за програмиране. Този език позволява сбито описание на формати на комплексни данни. Решението, което може да се състои в използването на графично представяне (което е само по себе си неформален език) дава много бързо неразбираеми резултати щом данните, които трябва да се представят, станат по-комплексни. Езикът XDR е подобен на езика С. Протоколи като RPC (Remote Procedure Call, извикване на отдалечена процедура), ONC (отворена мрежова архитектура) и NFS (Network File System, Мрежова файлова система) използват XDR за описване на формата на своите данни. Стандартът XDR приема по презумпция, че е налична преносимост на байтовете, когато всеки байт представлява 8 бита информация. Необходимо е дадено периферно устройство за може да кодира байтовете върху различните носители по такъв начин, че други периферни устройства да могат да декодират байтовете без загуба на значение.
XML-RPC	Съкращение на Extensible Markup Language — Remote Procedure Calling (Разширяем език за маркиране — отдалечено извикване на процедура), този протокол се използва широко в Интернет. Той определя XML-формат за обменените съобщения между клиенти и сървъри в HTTP. Едно съобщение XML-RPC кодира или процедура, която може да бъде извиквана от сървъра, като тя се придружава от параметрите, които се използват при извикването, или резултата от едно извикване. Параметрите и резултатите от тези процедури могат да бъдат скаларни величини, числови стойности, буквени низове, дати и др. Те могат да бъдат също така сложни записи и структури на списъци. Документът, който описва този протокол, представя метода за използване на протокола BEEP (Blocks Extensible Exchange Protocol) за обмен между клиенти и сървъри на съобщения, кодирани във формат XML-RPC.
XQL	Съкращение на Extended Structured Query Language (Разширяем език за структурирани заявки).
Брутно тегло на стоките	Общо(а) заявено(а)/действително(а) тегло (маса) на стоките, включително опаковките, без да се включва оборудването на превозвача.
Влак без свободен капацитет	Специфична форма на директен влак, който съдържа точно необходимия брой вагони и който се движи между две точки за претоварване без междинно разпределяне на вагони.
ГЖПП	Виж Главно железопътно предприятие
Главно железопътно предприятие (ГЖПП)	Железопътно предприятие, което носи отговорност за организацията и управлението на поредицата от етапи по извършване на превоза съгласно поетите от него ангажименти по отношение на клиента, на когото то е единствен партньор. Ако транспортната верига включва участие на няколко железопътни предприятия, ГЖПП отговоря също така за координацията между тях. Даден клиент може, по-специално при интермодалния превоз, да бъде интегратор на интермодални услуги.
Датата и час на освобождаване	Дата и час, в които е предвидено освобождаването на стоките или на които те са били освободени от клиента.
Датата и час на освобождаване на вагоните	Дата и час, в които вагоните са готови да бъдат придвижени на определеното от клиента местоположение.
Действителни дата и час на потегляне	Дата и час на потегляне на превозното средство
Директен влак	Влак, който съдържа необходимия брой вагони и който се движи между две точки за претоварване (начална точка — крайно местоназначение), без междинно разпределяне на вагони.
Доставчик на услуги	Превозвач, който отговаря за този специален етап на превоза. Страната, която получава и управлява резервацията.
ЕАОС	Европейска асоциация за оперативна съвместимост на железопътната система.Съгласно Директива 2001/16/ЕО става въпрос за „съвместен представителен органи“, съставен от представители на UIC (Международен съюз на железниците), на UNIFE (Международен съюз на производителите на железопътно оборудване), и на UITP (Международен съюз на обществения транспорт).
ЕГ	Единно гише (отдел за комплексни услуги)
Единица товар	Съвкупност от отделни опаковки, които са привързани, палетизирани или обвити, така че да образуват единица товар и по този начин да се улесни обработката им с механични средства.
Единичен влак	Влак за товарен превоз, изпратен с една товарителница и един вид стоки, съставен от един вид вагони, който се движи от местоположението на спедитора до местоположението на получателя без междинно разпределяне на вагони.
Единичен използван капацитет	Код, указващ степента на натоварване (например напълно натоварен, празен, непълно натоварен)
Единно гише (отдел за комплексни услуги) (ЕГ)	Международно партньорство между управители на железопътни инфраструктури, което предлага единен партньор на клиентите за железопътен превоз на товари, с цел: — да се иска предоставяне на специални влакови маршрути за международния превоз на товари, — да се наблюдават всички движения на влаковете, — и по принцип да се фактурират разходите, свързани с достъпа до железопътната линия, за сметка на УИ.
Еталонен модел на архитектурата OSI	Стандартизирано описание на начина, по който съобщенията трябва да бъдат разменяни между независимо кои две точки на една мрежа. Моделът OSI определя 7 слоя функции, прилагани в крайните точки на всяка комуникационна връзка. Тези слоеве са единствената призната нормативна рамка в международен мащаб в областта на комуникацията.
Железопътно предприятие (ЖПП)	Всяко частно или публично предприятие, чиято основна дейност е предоставянето на услуги за превоз на стоки и/или пътници по железопътната мрежа, като тракцията трябва да се осигурява задължително от това предприятие. Този термин включва също така и предприятията, които осигуряват единствено тракция.
ЖПП	Виж Железопътно предприятие
Заинтересовани страни	Всяко физическо или юридическо лице, което е разумно заинтересовано от експлоатацията на влака. Примери: железопътно предприятие (ЖПП); доставчик на услуга по проследяване на експедирането; доставчик на локомотиви; доставчик на вагони; доставчик на машинисти/влаков персонал; доставчик на услуга по разпределяне на вагони чрез маневрена гърбица; доставчик на услуга по маневриране за подреждане; интегратор на услуги; доставчик на маршрути (УИ); отговарящ за контролирането на влаковете (УИ); управляващ трафика; управляващ парка на подвижния състав; доставчик на фериботи; инспектор на вагони, локомотиви; доставчик на услуга по ремонт на вагони, локомотиви; управляващ експедирането; доставчик на услуга по насочване чрез стрелки и разпределяне чрез маневрена гърбица; доставчик на логистика; получател; спедитор. Освен това по отношение на интермодалния превоз те могат да бъдат: доставчик на контейнери; оператор на интермодален терминал; доставчик на услуги, свързани с превоз с камиони/предприятие за пътен превоз; морска компания; линии, обслужвани от баржи/шлепове.
Заявка за предоставяне на вагони	Подгрупа графи от товарителница, която съдържа сведенията, необходими на едно железопътно предприятие (ЖПП) за извършване на превоз на негова отговорност до прехвърлянето на товара на следващото ЖПП. Инструкция за превоз на въпросната стока.
Идентификатор на локомотива	Уникален идентификационен номер на локомотив
Интегратор на интермодални услуги	Всяка организация или предприятие, което има сключен договор с клиенти за превоз на интермодални единици. Тя изготвя пътните листи, управлява капацитета на влаковите композиции без свободен капацитет и др.
Интермодален превоз	Движение на стоки с едно-единствено превозно средство или товарна единица, при което се използват последователно няколко начина на превоз без преместване на самите стоки при преминаване от един начин на превоз към друг.
Интермодален терминал	Място, което разполага с пространство, оборудване и операционна среда, в които се извършва трансфер на единиците товар (контейнери, мобилни товарни шасита, ремаркета и полуремаркета).
Интермодална единица	Единица товар, която може да бъде превозена по различни начини, като контейнер, мобилно товарно шаси, полуремарке или ремарке.
Интернет	Всяка голяма мрежа, съставена от няколко по-малки мрежи. Група мрежи, които са взаимосвързани по такъв начин, че изглеждат като една голяма непрекъсната мрежа, към която може да се получи достъп по прозрачен начин с помощта на маршрутизатори на ниво мрежов слой на архитектурата OSI. Техническо наименование на мрежата, използвана като базово средство за електронната поща, както и за форуми за разговор онлайн в световен мащаб.
Кандидат	Всяко лицензирано железопътно предприятие и/или всяка международна групировка на лицензирани железопътни предприятия и, в държавите-членки, които предвиждат тази възможност, други физически или юридически лица или организации, които извършват публична услуга или имат търговски интерес от придобиване на инфраструктурен капацитет за експлоатация на железопътна услуга на техните съответни територии, като публичните власти, визирани в Регламент (ЕИО) № 1191/69 на Съвета (1) и спедиторите, комисионерите по транзита и операторите на комбинирани транспортни превози.
Код от Комбинираната номенклатура (КН)	Списък на осемсимволни кодове на стоките, използвани в митниците
Код по Хармонизираната система (ХС)	Списък на шестсимволни кодове на стоките, използвани в митниците Първите шест знака са идентични с тези от кода от КН.
Комбиниран железопътен превоз	Интермодален превоз, при който преминаването на по-голямата част от пътя по европейската мрежа се извършва с железница, и при който началният и/или крайният етап, извършен по шосе, е възможно най-кратък.
Краткосрочна заявка за предоставяне на маршрут	Заявка за предоставяне на маршрут съгласно член 23 от Директива 2001/14/ЕО, възникнала поради допълнителни заявки или нужди от транспорт.
Маршрут	Представлява инфраструктурния капацитет, необходим за движението на даден влак между две определени точки за определен период от време (маршрут, определен във времето и пространството).
Маршрут	Маршрут на влак, определен във времето и в пространството
Маршрут/отрязък от време	Определяне на маршрута на влака (времетраене и точки на тръгване и на местоназначение), с подробно описание на местата на преминаване и спиране, което може да включва също така всякаква дейност по време на движението на влака, като смяната на персонала на борда на влака, смяната на локомотива или на композицията.
Междинна точка	Място, което определя началото или края на една отсечка от пътя. То може да бъде например точка за извършване на връзка, трансфер или маневриране.
Местоназначение	Предвидено или действително място на пристигане на транспортно средство. Синоним: място на пристигане
Метаданни	Става въпрос за данни, отнасящи се до данни. Те описват данните, софтуерните услуги и другите съставни елементи на информационните системи на предприятията. Примери за различни типове метаданни са определителите на стандартизираните данни, данните за локализиране и маршрутизация, както и управлението на синхронизацията при разпределянето на споделяни данни.
МОЖЕ	Този термин или прилагателното „НЕЗАДЪЛЖИТЕЛЕН“ означава, че даден елемент е незадължителен. Даден доставчик може да избере да включи визирания елемент, за да отговори на нуждите на определен специфичен пазар, или защото счита че този елемент дава предимство на продукта, дори когато се приема, че друг доставчик може да го пропусне. Приложение, което не включва специална опция, ТРЯБВА да бъде проектирано така че да предоставя оперативна съвместимост с друго приложение, което включва този незадължителен елемент, дори в случай когато това е свързано с възможно намаляване на неговата функционалност. По същата логика приложение, което не включва специална опция, ТРЯБВА да бъде проектирано така че да предоставя оперативна съвместимост с друго приложение, което не включва този незадължителен елемент (с изключение разбира се на случая, когато се отнася до функционалност, предоставяна от съответната опция).
Място на доставяне	Място на доставяне (посочва се отправната железопътна гара). Място на предаване на отговорността за вагона.
Наблюдение	Дейност, която се състои в системно наблюдение и записване на мястото и текущото състояние на товар, превозно средство, съоръжение, група товари или отделна пратка.
Надеждност, достъпност, поддръжка, сигурност (НДРС)	Надеждност: изразена по математически начин възможност за начало на функциониране и за продължаване на функционирането при предварително определени условия и в рамките на определен период Достъпност: изразено по математически начин времетраене в режим на работа, съпоставено с времетраенето в неработен режим Ремонтоспособност: изразена по математически начин способност на дадена система да бъде възстановена в режим на работа след възникване на повреда Сигурност: изразена по математически начин вероятност за възникване на опасно за системата събитие.
Наемател	Всяко физическо или юридическо лице, посочено като такова от ползвателя/собственика на вагона.
Начин на експлоатация при свободен достъп	Начин на експлоатация на влаковете, който включва само едно ЖПП, което има за задача да осигурява движението на влака по няколко инфрастуктури. Това железопътно предприятие сключва договорите относно необходимите маршрути с всички заинтересовани УИ.
Начин на сътрудничество	Начин на експлоатация на влаковете, при който няколко ЖПП си сътрудничат под ръководството на едно главно железопътно предприятие (ГЖПП). Всяко участващо железопътно предприятие сключва отделен договор за искания маршрут за разстоянието, което го интересува.
НДРС	Виж: Надеждност, достъпност, ремонтоспособност, сигурност
НЕ СЛЕДВА	Този израз или изразът „НЕ СЕ ПРЕПОРЪЧВА“ означава, че при особени обстоятелства могат да възникнат основателни причини, при които възприемането на специално поведение може да бъде приемливо, и дори целесъобразно, но въпреки това е необходимо да се разберат и преценят правилно всички последствия, преди да се приложи поведението, описано в този етикет.
НЕ ТРЯБВА	Този израз означава, че определението представлява категорична забрана на спецификацията.
Номер на маршрута	Номер на маршрута на определен влак
Номер на ООН	Номер на Обединените нации, определен за опасни стоки
Номер по RID	Номер на OTIF (Междуправителствена организация за международни железопътни превози) относно опасните стоки
Нотифицирани органи	Органи, натоварени да оценяват съответствието или пригодността за употреба на съставните елементи на оперативната съвместимост или да правят преглед на процедурата по проверка „ЕО“ на подсистемите (Директива 91/440/EО)
Обмен	Прехвърляне на контрола от едно железопътно предприятие на друго въз основа на практически съображения, свързани с експлоатацията и сигурността, като например: — комбинирани услуги, — услуги със споделено носене на отговорност по шосеен превоз, — трансфер на информация между различни железопътни администрации, — трансфер на информация между собственици/притежатели на вагони и лицата, които извършват експлоатация на железните пътища.
Оператор на интермодален терминал	Оператор на интермодален терминал, например шлюзово устройство.
От точка до точка (мрежа от равноправни възли, peer-to-peer)	Клас от системи и приложения, които използват разпределени ресурси, за осъществяване на критична функция по децентрализиран начин. Ресурсите обхващат изчислителната мощ, данните (памет и съдържание), ширината на честотната лента на мрежата и наличността (компютри, персонал и други ресурси). Критичната функция може да представлява разпределено изчисление, споделяне на данни/съдържание, комуникация и сътрудничество или платформени услуги. Децентрализацията може да се приложи към алгоритми, данни и метаданни или към съвкупността от тези елементи. Това не изключва поддържането на децентрализацията за някои части на системите и на приложенията, ако съответствието по отношение на изискванията е осигурено.
Отговорна страна	Всяко физическо или юридическо лице, което поема отговорност за рисковете по железопътната мрежа, например ЖПП.
Отправна точка	Предвидено или действително място на тръгване на транспортно средство.
Отсечка от пътя	Отсечка от пътя, която се намира в сектор от инфраструктурата на даден управител на инфраструктура или част от пътя от входяща точка на трансфер до изходяща точка на трансфер от инфраструктурата на даден управител на инфраструктура.
Период преди тръгване	Период с продължителност от време Х преди часа на тръгване. Той започва известно време преди предвидения час на тръгване и свършва, когато този час настъпи.
План за пътуването	Означава предвидения референтен маршрут на един вагон или на една интермодална единица.
Получател	Страна, която трябва да получи стоките Синоним: получател на стоките
Портал — Място за достъп — Точка на преминаване	Гара по пътя на влак, композиран от интермодални единици, на която товарът сменя вагона си.
Предвиден час	Възможно най-точно предвиден час на пристигане, тръгване или преминаване на влака
Предвиден час на пристигане на влака	Преценка на часа на пристигане на влака на определено място, например в точката на трансфер, станция за връзка, на местоназначението на влака.
Предвиден час на тръгване	Дата и час на тръгване, за които е направена заявка за предоставяне на маршрут.
Предвиден часови график	Заетост на железопътната инфраструктура, определена хронологически за движение на влака по железопътната линия или в гарите. Промените в часовия график се предоставят от УИ най-малко два дни преди деня на тръгването на влака от началната точка. Този часови график се прилага за определен ден. В някои страни той се определя като часови график на експлоатация.
Претоварване	Операция, която се състои в преместване на елементи на един товар от стоки или на единични товари от едно превозно средство на друго или от едно място на складиране на друго.
Притежател	Лице, което постоянно експлоатира икономически едно превозно средство като средство за превоз, или като негов собственик, или като негов ползвател, и което е вписано като такова в регистъра на подвижния състав.
Проследимост	Дейност, която има за цел да открие и възстанови фактите, свързани с превоза на товар, превозно средство, съоръжение, група товари или отделна пратка.
Пункт за наблюдение	Място по пътя на влака, където отговорният управител на инфраструктурата трябва да изпрати на ЖПП, с което той е сключил договор относно преминаването по маршрута, съобщение за „Предвиждане относно движението на влака“, в което железопътното предприятие, което е участник по договора, се информира за предвидения час на пристигане на влака.
Пускане в експлоатация	Процедура, която зависи от техническото одобрение на даден вагон и от наличието на договор за ползване с ЖПП, който позволява търговската експлоатация на този вагон.
ПЧО	Предвиден час на обмен на вагони между две железопътни предприятия
ПЧП	Предвиден час на пристигане на вагоните на местоположението на клиента.
ПЧПВ	Виж Предвиден час на пристигане на влака
ПЧТ	Предвиден час на трансфер на влак между двама управители на инфраструктури
Първични данни	Базови данни, използвани за въвеждането на референтна информация за съобщенията или за функционалността и изчислението на производните данни.
Път	Географски път, по който се преминава от една отправна точка до точка на пристигане
Път	Пространствено или времево представяне на експедирането на празен или пълен вагон от една гара на експедиране до друга гара по местоназначение.
Пътен лист	Документ, съставен от превозвача или от негово име, който доказва съществуването на договор за превоз на товара.
Регистър	Регистърът наподобява база данни и речник с данни. Той включва по принцип среда със система за глобално управление на информацията. Той трябва също да включва не само описание на структурата на данните (тоест на компонентите и елементите), а също така и метаданните, които интересуват предприятието, екраните с данни, отчетите, програмите и системите. По принцип регистърът съдържа вътрешен набор от софтуерни инструменти, система за управление на база данни (SGBD), един метамодел, предварително установени метаданни, както и програмен продукт за зареждане и извличане на информация, който позволява достъп до данните на централизирания регистър.
Резервация	Резервиране на пространство за изпращане на стоки посредством специално средство за превоз.
СЛЕДВА	Този термин или изразът „ПРЕПОРЪЧВА СЕ“ означава, че при особени обстоятелства може да съществуват основателни причини за игнориране на някой от елементите, но в този случай е необходимо да се разберат и преценят правилно всички последствия, преди да се избере различно процедиране.
Спедитор	Страна, която по силата на сключен договор с интегратор на услуги, експедира или изпраща стоки с превозвач или му поверява техния превоз. Синоними: спедитор на стоки.
Съвкупност от маршрути	Свързване на няколко влакови маршрута за разширяване на железопътния маршрут във времето и пространството.
Съставен елемент на оперативната съвместимост	Всеки елементарен съставен елемент, група от съставни елементи, подгрупа или пълна съвкупност от оборудване, което е включено или е предназначено да бъде включено в подсистема, от която зависи пряко или непряко оперативната съвместимост на трансевропейската конвенционална железопътна система. Понятието „съставен елемент“ обхваща материалните и нематериалните вещи, като например компютърните програми.
Съществени изисквания	Съвкупността от описаните условия в приложение III на Директива 2001/16/EО, на които трябва да отговоря трансевропейската конвенционална железопътна система, подсистемите и съставните елементи на оперативната съвместимост, включително и различните интерфейси.
Техническа спецификация за оперативна съвместимост	Спецификации, който са предмет на всяка подсистема или част от подсистема, с цел да се отговори на съществените изисквания и да се осигури оперативната съвместимост на конвенционалната трансевропейска железопътна система.
Товар	Съвкупност от стоки, изпратени от спедитор до получател в една или няколко отделни товарни единици на управител на инфраструктура (УИ), или които са натоварени върху един или няколко отделни вагона. Пример:
Товар на вагон	Единичен товар, чиято единица представлява вагона.
Товари за превоз	Количеството стоки, които са ясно определими и трябва да бъдат превозени от спедитор до получател с използване на един или няколко начина на превоз, както е посочено в единния транспортен документ (синоним: експедирана стока).
Товарителница	Документ, който доказва съществуването на договор за извършване на превоз на товар от даден превозвач от договорено начално място на тръгване до договорено място за доставяне. Този документ съдържа точно описание на стоките, които се превозват.
Точка за маневриране	Гара, на която железопътното предприятие може да промени състава на влаковата композиция, но продължава да носи отговорност за вагоните (няма смяна на отговорността).
Точка за обмен	Място, в което отговорността за вагоните на един влак се прехвърля от едно ЖПП на друго. Що се отнася до експлоатацията на влака, едното ЖПП прехвърля отговорността за влака на другото ЖПП, което притежава от този момент маршрута за следващата отсечка от пътя.
Точка на трансфер	Пункт на трансфер на отговорността между двама управители на инфраструктури
Трансевропейска железопътна мрежа	Железопътна мрежа, така както е определена в приложение I към Директива 2001/16/ЕО.
ТРЯБВА	Този термин, както и изразът „ИЗИСКВА СЕ“ означават, че определението представлява задължително изискване на спецификацията.
ТСОС	Виж Техническа спецификация за оперативна съвместимост
Тунелиране	Процес на интегриране на частни IP-пакети към публичен IP-пакет.
УИ	Управител на инфраструктура: всяка организация или всяко предприятие, което е натоварено по-специално с изграждането и поддръжката на железопътни инфраструктури, и дори с управлението на системи за контрол и сигурност. Функциите на управител на инфраструктура върху цял коридор или върху част от него могат да бъдат възложени на няколко организации или предприятия. (Директива 2001/14/ЕО).
Управител на инфраструктура (УИ)	Виж УИ.
Участък от маршрут	Част от маршрут
Шифриране	Кодиране на съобщения Дешифриране: конвертиране на кодирани данни в първоначалния им вид

---

(1)  ОВ L 156, 28.6.1969 г., стр. 1. Регламент, последно изменен с Регламент (ЕИО) № 1893/91 (ОВ L 169, 29.6.1991 г., стр. 1).

---