РЕГЛАМЕНТ ЗА ИЗПЪЛНЕНИЕ (ЕС) 2018/502 НА КОМИСИЯТА

за изменение на Регламент за изпълнение (ЕС) 2016/799 по отношение на определянето на изискванията за конструкцията, изпитването, монтирането, експлоатацията и ремонта на тахографите и техните компоненти

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

като взе предвид Регламент (ЕС) № 165/2014 на Европейския парламент и на Съвета от 4 февруари 2014 г. относно тахографите в автомобилния транспорт (1), и по-специално член 11 и член 12, параграф 7 от него,

Регламент за изпълнение (ЕС) 2016/799 се изменя, както следва:

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

(2) Регламент за изпълнение (ЕС) 2016/799 на Комисията от 18 март 2016 г. за прилагане на Регламент (ЕС) № 165/2014 на Европейския парламент и на Съвета по отношение на определянето на изискванията за конструкцията, изпитването, монтирането, експлоатацията и ремонта на тахографите и техните компоненти (ОВ L 139, 26.5.2016 г., стр. 1).

(3) Директива 2014/53/ЕС на Европейския парламент и на Съвета от 16 април 2014 г. за хармонизирането на законодателствата на държавите членки във връзка с предоставянето на пазара на радиосъоръжения и за отмяна на Директива 1999/5/ЕО (ОВ L 153, 22.5.2014 г., стр. 62).

ПРИЛОЖЕНИЕ I

Приложение IВ към Регламент (ЕС) 2016/799 се изменя, както следва:

Съдържанието се изменя, както следва:

а)	точка 3.12.5 се заменя със следното: „3.12.5. Места и местоположения, където започват и завършват дневните периоди на работа и/или където общото време на управление на МПС достига 3 часа“;

б)	точка 4.5.3.2.16 се заменя със следното: „4.5.3.2.16 Данни за местата за три часа общо управление на МПС“;

в)	точка 4.5.4.2.14 се заменя със следното: „4.5.4.2.14 Данни за местата за три часа общо управление на МПС“;

г)	точка 6.2 се заменя със следното: „6.2 Проверка на новите или поправените компоненти“.

Точка 1 се изменя, както следва:

а)

определение ии) се заменя със следното:

„ии)	„устройство за връзка от разстояние“ или „устройство за ранно откриване от разстояние“ означава: оборудването в бордовото устройство, използвано за извършването на целенасочени пътни проверки;“

б)

определение рр) се заменя със следното:

„рр)	„сверяване на часовника“ означава: сверяване на текущото време, което може да се извършва автоматично през равни интервали, като за еталонна стойност се използва времето, получено от приемника на сигнали от GNSS, или при калибриране;“

в)

в определение хх) първото тире се заменя със следното:

„—	монтирано и се използва само в превозни средства от типове M1 и N1 (както са определени в последното изменение на приложение II към Директива 2007/46/ЕО на Европейския парламент и на Съвета (*),“;

г)

добавя се ново определение яя):

„яя)

„общо време на управление“ означава:

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

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

Не се предвижда показване, разпечатване или извличане на стойността на общото време на управление;“.

В точка 2.3, подточка 13 последното тире се заменя със следното:

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

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

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

В точка 3.2, подточка 27 второто тире се заменя със следното:

„—	места, където времето на общо управление на МПС достига кратно число на три часа;“.

В точка 3.4 подточка 49 се заменя със следното:

„49)

Приема се, че първата промяна на дейността към „ПРЕКЪСВАНЕ/ПОЧИВКА“ или „НА РАЗПОЛОЖЕНИЕ“, настъпила през 120-те секунди след автоматичната промяна към „РАБОТА“ поради спирането на превозното средство, е настъпила в момента на спиране на превозното средство (и следователно евентуално е анулирала преминаването към „РАБОТА“).“

В точка 3.6.1 подточка 59 се заменя със следното:

„59)

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

Временно въвеждане, направено при последното изваждане на картата, се потвърждава (т.е. впоследствие не се замества) при следните условия:

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

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

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

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

В точка 3.6.2 шестото и седмото тире се заменят със следното:

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

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

Точка 3.9.15 се заменя със следното:

„3.9.15 Събитие „времеви конфликт“

86)

Това събитие се задейства, извън режима на калибриране, когато бордовото устройство установи несъответствие, по-дълго от 1 минута, между показанията на функцията за измерване на времето на бордовото устройство и данните за времето, постъпващи от приемника на сигнали от GNSS. Това събитие се записва заедно със стойността на вътрешния часовник на бордовото устройство и се придружава от автоматично сверяване на часовника. След предизвикване на събитие на времеви конфликт през следващите 12 часа бордовото устройство не генерира други събития на времеви конфликт. Това събитие не трябва да се предизвиква, ако в продължение на 30 или повече дни от приемника на сигнали от GNSS не е можел да бъде открит валиден сигнал от GNSS.“

10)

В точка 3.9.17 се добавя следното тире:

„—	неизправност на интерфейса с ITS (ако е приложимо)“.

11)

Точка 3.10 се изменя, както следва:

i)	текстът преди таблицата в подточка 89 се заменя със следното: „Уредът за регистриране на данните за движението трябва да открива неизправности чрез функции за изпробване и самоизпробване в съответствие с таблицата по-долу:“;

ii)

в таблицата се добавя следният ред:

„интерфейс с ITS (незадължителен)

Правилно функциониране“

12)

В точка 3.12 второто тире се заменя със следното:

„—

средният брой на местоположенията на ден се определя като най-малко 6 местоположения, в които започва дневният период на работа, 6 местоположения, в които общото време на управление на МПС достига кратно число на три часа, и 6 местоположения, в които завършва дневният период на работа, така че „365 дни“ включват най-малко 6570 местоположения,“.

13)

Точка 3.12.5 се изменя, както следва:

а)

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

„3.12.5. Места и местоположения, където започват и завършват дневните периоди на работа и/или където общото време на управление на МПС достига 3 часа

108)

Уредът за регистриране на данните за движението трябва да регистрира и записва в своята памет за данни:

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

—	местоположения, където общото време на управление на МПС достига кратно число на три часа;

—	места и местоположения, където водачът и/или вторият водач приключва своя дневен период на работа.“;

б)

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

„—	вид на въвеждането (начало, край или 3 часа общо време на управление на МПС),“;

в)

подточка 111 се заменя със следното:

„111)

Паметта за данни трябва да позволява съхраняването на места и местоположения, където започват и завършват дневните периоди на работа и/или където общото време на управление на МПС достига 3 часа, в продължение на най-малко 365 дни.“

14)

В точка 3.12.7 подточка 116 се заменя със следното:

„116)

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

15)

Таблицата в точка 3.12.8 се изменя, както следва:

а)

между позициите „Липса на информация за местоположението от приемник на сигнали от GNSS“ и „Грешка в данните за движението“ се вмъква следната позиция:

„Грешка в комуникацията с външното устройство за GNSS

—	най-продължителното събитие за всеки от последните 10 дни на възникване,

—	5-те най-продължителни събития през последните 365 дни.

—	дата и час на началото на събитие,

—	дата и час на края на събитие,

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

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

б)

позицията „Времеви конфликт“ се заменя със следното:

„Времеви конфликт

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

—	5-те най-сериозни събития през последните 365 дни.

—	дата и час на уреда за регистриране на данните за движението,

—	дата и час по GNSS,

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

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

16)

В точка 3.20 подточка 200 се заменя със следното:

„200)

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

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

Изискването за съгласието на водача не се прилага за данните, които уредите за регистриране на данните за движението предават към мрежата на превозното средство. Ако постъпилите в мрежата на превозното средство лични данни се обработват допълнително извън нея, производителят на превозното средство носи отговорност за това обработването им да се извършва в съответствие с разпоредбите на Регламент (ЕС) 2016/679 (Общ регламент относно защитата на данните).

Изискването за съгласието на водача не се прилага също така за данните от тахографа, извлечени от превозвач от разстояние (съгласно изискването в подточка 193), тъй като този сценарий се следи чрез правото за достъп на картата на превозвача.

За ITS данните, предоставяни чрез този интерфейс, се прилагат следните изисквания:

—	тези данни представляват набор от избрани съществуващи данни от речника на данните на тахографа (допълнение 1),

—	поднабор на тези избрани данни е отбелязан като „лични данни“,

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

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

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

—	сдвояването на външното устройство с интерфейса с ITS е защитено чрез специален за целта случаен PIN от най-малко 4 числа, записани във и достъпни чрез дисплея на всяко бордово устройство,

—	наличието на интерфейс с ITS при никакви обстоятелства не може да наруши или да се отрази на правилната работа и сигурността на бордовото устройство.

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

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

Когато контактният ключ на превозното средство е в положение ВКЛЮЧЕН ДВИГАТЕЛ, тези данни могат да бъдат излъчвани постоянно.“

17)

В точка 3.23 подточка 211 се заменя със следното:

„211)

Настройката на часа на вътрешния часовник на бордовото устройство трябва да се коригира автоматично на всеки 12 часа. Когато това не е възможно, тъй като няма сигнал от GNSS, настройката на часа трябва да се извършва веднага, след като бордовото устройство получи достъп до валидно време от приемника на сигнали от GNSS, според условията за запалването на двигателя. Еталонното време за автоматичната настройка на часа на вътрешния часовник на бордовото устройство трябва да се получава от приемника на сигнали от GNSS.“

18)

В точка 3.26 подточки 225 и 226 се заменят със следното:

„225)

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

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

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

—	сериен номер,

—	знак за одобрение на типа.

226)	Когато няма физическо място за всички горепосочени данни, указателната табелка трябва да указва най-малко следното: наименованието или логотипа на производителя и фабричния номер.“

19)	В точка 4.1 изображението, на което са показани лицевата и обратната страна на картата на водача, се заменя със следното: „ Текст на изображението „ “ “

20)

В точка 4.5.3.1.8, подточка 263 първото тире се заменя със следното:

„—	Неизправност на картата (когато неизправна е самата карта),“.

21)

В точка 4.5.3.2.8, подточка 288 първото тире се заменя със следното:

„—	Неизправност на картата (когато неизправна е самата карта),“.

22)

Точка 4.5.3.2.16 се заменя със следното:

„4.5.3.2.16 Данни за местата за три часа общо управление на МПС

305)

Картата на водача трябва да позволява съхраняването на следните данни, свързани с местоположението на превозното средство, когато общото време на управление на МПС достигне кратно число на три часа:

—	дата и час, когато общото време на управление на МПС достигне кратно число на три часа,

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

—	точността на GNSS, датата и часа, когато е било определено местоположението,

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

306)

Картата на водач трябва да може да съхранява най-малко 252 такива записа.“

23)

Точка 4.5.4.2.14 се заменя със следното:

„4.5.4.2.14 Данни за местата за три часа общо управление на МПС

353)

Картата за монтаж и настройки трябва да позволява съхраняването на следните данни, свързани с местоположението на превозното средство, когато общото време на управление на МПС достигне кратно число на три часа:

—	дата и час, когато общото време на управление на МПС достигне кратно число на три часа,

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

—	точността на GNSS, датата и часа, когато е било определено местоположението,

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

354)

Картата за монтаж и настройки трябва да позволява съхраняването на най-малко 18 такива записа.“

24)

В точка 5.2 подточка 396 се заменя със следното:

„396)

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

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

—	характеристичен коефициент на превозното средство, във вида „w = … импулса/km“,

—	константа на уредите за регистриране на данните за движението, във вида „k = … импулса/km“,

—	действителна обиколка на колелата с гумите, във вида „l = … mm“,

—	размер на гумите,

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

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

—	наличието (или не) на външно устройство за GNSS,

—	серийния номер на външното устройство за GNSS, ако има такова,

—	серийния номер на устройството за връзка от разстояние, ако има такова,

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

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

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

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

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

25)

Точка 5.3 се изменя, както следва:

а)

след подточка 398 се вмъква нова подточка 398а:

„398a)

Посочените по-горе пломби трябва да бъдат сертифицирани по стандарт EN 16882:2016.“;

б)

в подточка 401 вторият абзац се заменя със следното:

„Този уникален идентификационен номер се определя като: MMNNNNNNNN чрез неизтриваема маркировка, като ММ е уникална идентификация на производителя (регистрирането в базата данни се управлява от ЕК), а NNNNNNNN е буквено-цифров номер на пломбата, който е уникален в областта на производителя.“;

в)

подточка 403 се заменя със следното:

„403)

След като сертифицират даден модел пломба по стандарт EN 16882:2016, производителите на пломби трябва да се регистрират в специална база данни и публично да оповестят своите идентификационни номера на пломби чрез процедура, която ще се определи от Европейската комисия.“;

г)

подточка 404 се заменя със следното:

„404)

За целите на Регламент (ЕС) № 165/2014 одобрените сервизи и производители на превозни средства използват само пломби, сертифицирани по стандарт EN 16882:2016, от производители на пломби, включени в гореспоменатата база данни.“

26)

Точка 6.2 се заменя със следното:

„6.2. Проверка на новите или поправените компоненти

407)

Всяко отделно устройство, било то ново или поправено, трябва да бъде проверено дали функционира правилно и дали е с точни показания и записи, в границите, определени в глави 3.2.1, 3.2.2, 3.2.3 и 3.3.“

27)

В точка 6.3 подточка 408 се заменя със следното:

„408)

При монтирането в превозното средство всички монтирани компоненти (включително уредите за регистриране на данните за движението) трябва да отговарят на разпоредбите относно максималните толеранси, определени в глави 3.2.1, 3.2.2, 3.2.3 и 3.3. Всички монтирани компоненти трябва да бъдат пломбирани в съответствие с глава 5.3, като монтажът трябва да включва и калибриране.“

28)

Точка 8.1 се изменя, както следва:

а)

в точка 8.1 уводният текст преди подточка 425 се заменя със следното:

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

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

Както се посочва в член 2, определение 10 от настоящия регламент, бордовите устройства могат да включват различни компоненти. С каквито и компоненти да е сглобено бордовото устройство, външната антена и (ако е приложимо) високочестотният разклонител за антената, свързан с приемника на сигнали от GNSS или с устройството за връзка от разстояние, не са част от одобрението на типа на бордовото устройство.

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

б)

подточка 427 се заменя със следното:

„427)

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

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

—	сертификат за функциониране,

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

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

29)

Допълнение 1 се изменя, както следва:

а)

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

i)	точка 2.63 се заменя със следното: „2.63 Reserved for future use“;

ii)	точка 2.78 се заменя със следното: „2.78 GNSSAccumulatedDriving“;

iii)	точка 2.79 се заменя със следното: „2.79 GNSSAccumulatedDrivingRecord“;

iv)	точка 2.111 се заменя със следното: „2.111 NoOfGNSSADRecords“;

v)	точка 2.160 се заменя със следното: „2.160 Reserved for future use“;

vi)	точка 2.203 се заменя със следното: „2.203 VuGNSSADRecord“;

vii)	точка 2.204 се заменя със следното: „2.204 VuGNSSADRecordArray“;

viii)

точка 2.230 се заменя със следното:

„2.230 Reserved for future use“;

ix)	точка 2.231 се заменя със следното: „2.231 Reserved for future use“;

б)

в точка 2 преди точка 2.1 се добавя следният текст:

„Посоченият в настоящото допълнение размер за типовете карти за данни, които се използват за приложенията от поколение 1 и 2, е размерът за приложение от поколение 2. Предполага се, че четецът вече познава размера за приложение от поколение 1. Номерата на изискванията в приложение IB, свързани с тези типове данни, се отнасят за приложенията от поколение 1 и 2.“;

в)

точка 2.19 се заменя със следното:

„2.19. CardEventData

Поколение 1:

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

Текст на изображението

CardEventData е последователност във възходящ ред от EventFaultType и cardEventRecords (с изключение на записите относно опитите за нарушаване на сигурността, които са групирани в последния блок от данни на последователността).

cardEventRecords е набор от записи на събития от определен тип (или категория от събития във връзка с опити за нарушаване на сигурността).

Поколение 2:

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

Текст на изображението

cardEventRecords е набор от записи на събития от определен тип (или категория от събития във връзка с опити за нарушаване на сигурността).“;

г)

точка 2.30 се заменя със следното:

„2.30. CardRenewalIndex

Индекс за подновяване на валидността на картата (определение и).

Текст на изображението

Присвояване на стойност: (вж. глава 7 от настоящото приложение).

„0“	Първо издаване.

Възходящ ред: „0, …, 9, A, …, Z“;

д)

в точка 2.61 текстът след заглавието „Поколение 2“ се заменя със следното:

„

Текст на изображението

В допълнение към поколение 1 се използват следните елементи от данни:

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

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

noOfCardVehicleUnitRecords е броят на записите за използваните бордови устройства, които картата може да съхранява.“;

е)	точка 2.63 се заменя със следното: „2.63. Reserved for future use“;

ж)

в точка 2.67 текстът под заглавието „Поколение 2“ се заменя със следното:

„Използват се същите стойности, както при поколение 1, със следните допълнения:

Текст на изображението

Забележка 1:

стойностите от поколение 2 за пластината, адаптера и външното устройство за GNSS, както и стойностите за поколение 1 за бордовото устройство и датчика за движение могат да се използват в SealRecord, т.е. ако е приложимо.

Забележка 2:

Приема се, че в полето CardHolderAuthorisation (CHA) в сертификат от поколение 2 стойностите (1), (2), и (6) означават сертификат за взаимно удостоверяване на автентичността за съответния вид оборудване. За обозначаване на съответния сертификат за създаване на цифров подпис трябва да се използват стойностите (17), (18) или (19).“;

з)

в точка 2.70 текстът под заглавието „Поколение 2“ се заменя със следното:

„Поколение 2:

	Общи събития, Няма допълнителна информация, Вкарване на невалидна карта, Конфликт, предизвикан от картата, Припокриване във времето, Управление без съответната карта, Вкарване на карта по време на управление, Неправилно приключена последна картова сесия, Превишаване на скоростта, Прекъсване на електрическото захранване, Грешка в данните за движението, Конфликт относно движението на превозното средство, Времеви конфликт (GNSS/вътрешния часовник на бордовото устройство), Грешка в комуникацията с устройството за връзка от разстояние, Липса на информация за местоположението от приемник на сигнали от GNSS, Грешка в комуникацията с външното устройство за GNSS, RFU,
	Опити за нарушаване на сигурността, свързани с бордовото устройство, Няма допълнителна информация, Неуспешна процедура по удостоверяване на датчика за движение, Неуспешна процедура по удостоверяване на тахографската карта, Неразрешена смяна на датчика за движение, Грешка във връзка с целостта на входящите данни на картата Грешка във връзка с целостта на съхранените данни на потребител, Грешка при вътрешно прехвърляне на данни, Неразрешено отваряне на корпус, Възпрепятстване на работата на хардуера, Установяване на вмешателство във връзка с GNSS, Неуспешна процедура по удостоверяване на външно устройство за GNSS, Изтекъл сертификат на външно устройство за GNSS, RFU,
	Опити за нарушаване на сигурността, свързани с датчика за движение, Няма допълнителна информация, Неуспешно удостоверяване, Грешка във връзка с целостта на съхранените данни, Грешка при вътрешно прехвърляне на данни, Неразрешено отваряне на корпус, Възпрепятстване на работата на хардуера, RFU,
	Неизправности във връзка с уреди за регистриране на данните за движението, Няма допълнителна информация, Вътрешна неизправност в бордовото устройство, Неизправност на печатащото устройство, Неизправност на екрана, Неизправност при изтегляне на данни, Неизправност на датчика, Вътрешен приемник на сигнали от GNSS, Външно устройство за GNSS, Устройство за връзка от разстояние, Интерфейс с ITS, RFU,
	Неизправности във връзка с карта, Няма допълнителна информация, RFU,
	RFU,
	Зависи от производителя.“;

и)

точка 2.71 се заменя със следното:

„2.71. ExtendedSealIdentifier

Поколение 2:

Разширеният идентификатор на пломбата идентифицира еднозначно пломбата (съгласно изискването в подточка 401 от приложение IВ).

Текст на изображението

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

sealIdentifier е идентификатор за пломбата, който е уникален за производителя.“;

й)

точки 2.78 и 2.79 се заменят със следното:

„2.78 GNSSAccumulatedDriving

Поколение 2:

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

Текст на изображението

gnssADPointerNewestRecord е индексът на последния актуализиран запис за общо управление по GNSS.

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

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

2.79. GNSSAccumulatedDrivingRecord

Поколение 2:

Текст на изображението

timeStamp е датата и часът, когато общото време на управление на МПС достигне кратно число на три часа.

gnssPlaceRecord съдържа информация за местоположението на превозното средство.

vehicleOdometerValue е стойността от километражния брояч, когато общото време на управление на МПС достигне кратно число на три часа.“;

к)

точка 2.86 се заменя със следното:

„2.86. KeyIdentifier

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

Текст на изображението

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

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

Третият избор е подходящ за указване на публичния ключ на държава членка.“;

л)

точка 2.92 се заменя със следното:

„2.92. MAC

Поколение 2:

Сума за криптографски контрол с дължина от 8, 12 или 16 байта, съответстваща на криптографските поредици, посочени в допълнение 11.

Текст на изображението “

м)	точка 2.111 се заменя със следното: „2.111. NoOfGNSSADRecords Поколение 2: Брой на записите за общо управление по GNSS, които картата може да съхранява. Текст на изображението NoOfGNSSADRecords ::= INTEGER (0..216-1) Присвояване на стойност: вж. допълнение 2.“;

н)	в точка 2.120 присвояването на стойност „16H“ се заменя със следното: „ Текст на изображението ’16’HVuGNSSADRecord “;

о)	точка 2.160 се заменя със следното: „2.160. Reserved for future use“;

п)

точка 2.162 се заменя със следното:

„2.162. TimeReal

Код за комбинирано поле — дата и час, изразени в секунди, считано от 00ч.00м.00сек. по координираното универсално време на 1 януари 1970 г.

Текст на изображението

Присвояване на стойност — синхронизиран октет: брой секунди от полунощ на 1 януари 1970 г. по координираното универсално време.

Най-далечната бъдеща дата/час е през 2106 г.“;

р)

точка 2.179 се заменя със следното:

„2.179 VuCardRecord

Поколение 2:

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

Текст на изображението

cardNumberAndGenerationInformation е пълният номер и поколението на използваната карта (тип данни 2.74).

cardExtendedSerialNumber е от файла EF_ICC под MF на картата.

cardStructureVersion е от файла EF_Application_Identification под DF_Tachograph_G2.

cardNumber е от файла EF_Identification под DF_Tachograph_G2.“;

с)

точки 2.203 и 2.204 се заменят със следното:

„2.203 VuGNSSADRecord

Поколение 2:

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

Текст на изображението

timeStamp е датата и часът, когато общото време на управление на МПС достигне кратно число на три часа.

cardNumberAndGenDriverSlot идентифицира картата, вкарана в процепа за водача, в т.ч. поколението ѝ.

cardNumberAndGenCodriverSlot идентифицира картата, вкарана в процепа за втория водач, в т.ч. поколението ѝ.

gnssPlaceRecord съдържа информация за местоположението на превозното средство.

vehicleOdometerValue е стойността от километражния брояч, когато общото време на управление на МПС достигне кратно число на три часа.

2.204. VuGNSSADRecordArray

Поколение 2:

Текст на изображението

recordType указва типа запис (VuGNSSADRecord).

Присвояване на стойност: вж. RecordType.

recordSize е размерът на VuGNSSADRecord в байтове.

noOfRecords е броят на записите в набора от записи.

Records е набор от записи за общо управление по GNSS.“;

т)	точки 2.230 и 2.231 се заменят със следното: „2.230. Reserved for future use 2.231. Reserved for future use“;

у)

в точка 2.234 текстът под заглавието „Поколение 2“ се заменя със следното:

„

Текст на изображението

В допълнение към поколение 1 се използват следните елементи от данни:

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

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

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

30)

Допълнение 2 се изменя, както следва:

а)

в точка 1.1 се добавят следните съкращения:

„CHA	Certificate Holder Authorisation (разрешение за титуляря на сертификата)
DO	Data Object (обект от данни)“;

б)

точка 3.3 се изменя, както следва:

раздел TCS_24 се заменя със следното:

„TCS_24

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

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

OR:: трябва да бъде изпълнено поне едно от условията за сигурност.

Правилата за достъп до файловата система, т.е. командите SELECT, READ BINARY и UPDATE BINARY, са определени в глава 4. Правилата за достъп за останалите команди са определени в таблиците по-долу. Изразът „не се прилага“ се използва, ако няма изискване да се поддържа изпълнението на командата. В този случай командата може да се поддържа или може да не се поддържа, но условието за достъп е извън обхват.“;

ii)

таблицата в раздел TCS_25 се заменя със следното:

„Команда

Карта на водач

Карта за монтаж и настройки

Контролна карта

Карта на превозвач

External Authenticate

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

ALW

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

ALW

PWD

ALW

Internal Authenticate

ALW

PWD

ALW

General Authenticate

ALW

Get Challenge

ALW

MSE:SET AT

ALW

MSE:SET DST

ALW

Process DSRC Message

Не се прилага

PSO: Compute Digital Signature

ALW ИЛИ

SM-MAC-G2

ALW ИЛИ

SM-MAC-G2

Не се прилага

PSO: Hash

Не се прилага

ALW

Не се прилага

PERFORM HASH of FILE

ALW ИЛИ

SM-MAC-G2

ALW ИЛИ

SM-MAC-G2

Не се прилага

PSO: Verify Certificate

ALW

PSO: Verify Digital Signature

Не се прилага

ALW

Не се прилага

Verify

Не се прилага

ALW

Не се прилага

Не се прилага“

iii)

таблицата в раздел TCS_26 се заменя със следното:

„Команда

Карта на водач

Карта за монтаж и настройки

Контролна карта

Карта на превозвач

External Authenticate

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

Не се прилага

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

ALW

PWD

ALW

Internal Authenticate

Не се прилага

General Authenticate

ALW

Get Challenge

ALW

MSE:SET AT

ALW

MSE:SET DST

ALW

Process DSRC Message

Не се прилага

ALW

Не се прилага

PSO: Compute Digital Signature

ALW ИЛИ

SM-MAC-G2

ALW ИЛИ

SM-MAC-G2

Не се прилага

PSO: Hash

Не се прилага

ALW

Не се прилага

PERFORM HASH of FILE

ALW ИЛИ

SM-MAC-G2

ALW ИЛИ

SM-MAC-G2

Не се прилага

PSO: Verify Certificate

ALW

PSO: Verify Digital Signature

Не се прилага

ALW

Не се прилага

Verify

Не се прилага

ALW

Не се прилага

Не се прилага“

iv)

таблицата в раздел TCS_27 се заменя със следното:

„Команда

Карта на водач

Карта за монтаж и настройки

Контролна карта

Карта на превозвач

External Authenticate

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

Не се прилага

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

ALW

PWD

ALW

Internal Authenticate

Не се прилага

General Authenticate

ALW

Get Challenge

ALW

MSE:SET AT

ALW

MSE:SET DST

ALW

Process DSRC Message

Не се прилага

PSO: Compute Digital Signature

Не се прилага

PSO: Hash

Не се прилага

PERFORM HASH of FILE

Не се прилага

PSO: Verify Certificate

ALW

PSO: Verify Digital Signature

Не се прилага

Verify

Не се прилага

ALW

Не се прилага

Не се прилага“

в)

в точка 3.4 раздел TCS_29 се заменя със следното:

„TCS_29

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

SW1

SW2

Значение

Нормална обработка

Нормална обработка. ХХ = брой на наличните байтове на отговора

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

Удостоверяването е неуспешно (предупреждение)

Грешка при CHV (PIN). Брояч на оставащите опити, осигуряван от ‘X’

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

Грешка при изпълнението — променено състояние на енергонезависимата памет

Грешка при изпълнението — променено състояние на енергонезависимата памет. Неизправност на паметта

Грешка по сигурността

грешна криптографска контролна сума (по време на защитен обмен на съобщения) или

грешен сертификат (по време на проверката на сертификата) или

грешна криптограма (по време на външното удостоверяване) или

грешен цифров подпис (по време на проверката на подписа)

Грешна дължина (грешна Lc или Le)

Очаква се последната команда от веригата

Забранена команда (няма възможност за отговор при Т=0)

Незадоволително състояние по отношение на сигурността

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

Неизпълнени условия за използване

Неразрешена команда (няма активен елементарен файл)

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

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

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

Неоткриваем файл

Грешни параметри P1-P2

Неоткриваеми указани данни

Грешни параметри (поправка извън елементарния файл)

Грешна дължина, SW2 указва точната дължина. Не се връща като отговор поле за данни

Несъвместим или неправилен код на команда

Несъвместим клас

—	Други грешки при проверката

Може да бъдат върнати други байтове за състояние, определени в стандарт ISO/IEC 7816-4, ако поведението им не е изрично упоменато в настоящото допълнение.

Например по избор може да бъдат върнати следните байтове за състояние:

6881: Несъвместим логически канал

6882: Не се поддържа защитен обмен на съобщения“;

г)

в точка 3.5.1.1, в раздел TCS_38 последното тире се заменя със следното:

„—	Ако избраното приложение се смята за повредено (открита е грешка в целостта на атрибутите на файла), за състоянието на обработката се връща ‘6400’ или ‘6500’.“;

д)

в точка 3.5.1.2, в раздел TCS_41 последното тире се заменя със следното:

„—	Ако избраният файл се смята за повреден (открита е грешка в целостта на атрибутите на файла), за състоянието на обработката се връща „6400“ или „6500“.“;

е)

в точка 3.5.2.1, в раздел TCS_43 шестото тире се заменя със следното:

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

ж)

точка 3.5.2.1.1 се изменя, както следва:

таблицата в раздел TCS_45 се заменя със следното:

„Байт

Дължина

Стойност

Описание

‘81h’

TPV: таг за простата стойност на данните

‘NNh’ или

‘81 NNh’

LPV: дължина на върнатите данни (= първоначална Le).

L е 2 байта, ако LPV>127 байта

#(2+L) - #(1+L+NN)

‘XX..XXh’

Проста стойност на данните

#(2+L+NN)

‘99h’

Таг за състоянието на обработката (SW1-SW2) — по избор за защитен обмен на съобщения от поколение 1

#(3+L+NN)

‘02h’

Дължина на стойността за състоянието на обработката — по избор за защитен обмен на съобщения от поколение 1

#(4+L+NN) - #(5+L+NN)

‘XX XXh’

Състояние на обработката на незащитената ответна APDU, т.е. с отговора — незадължително при защитен обмен на съобщения от поколение 1

#(6+L+NN)

‘8Eh’

TCC: таг за криптографската контролна сума

#(7+L+NN)

‘XXh’

LCC: дължина на следната криптографска контролна сума

‘04h’ за защитения обмен на съобщения от поколение 1 (вж. допълнение 11, част А)

‘08h’, ‘0Ch’ или ‘10h’ в зависимост от дължината на ключа по AES за защитен обмен на съобщения от поколение 2 (вж. допълнение 11, част Б)

#(8+L+NN)-#(7+M+L+NN)

‘XX..XXh’

Криптографска контролна сума

‘XXXXh’

Байтове за състоянието (SW1, SW2)“

ii)

таблицата в раздел TCS_46 се заменя със следното:

„Байт

Дължина

Стойност

Описание

‘87h’

TPI CG: таг за криптираните данни (криптограма)

‘MMh’ или

‘81 MMh’

LPI CG: дължина на върнатите криптирани данни (различна от първоначалната Le на командата поради запълване).

L е 2 байта, ако LPI CG > 127 байта.

#(2+L)-#(1+L+MM)

‘01XX..XXh’

Криптирани данни: индикатор за запълване и криптограма

#(2+L+MM)

‘99h’

Таг за състоянието на обработката (SW1-SW2) — по избор за защитен обмен на съобщения от поколение 1

#(3+L+MM)

‘02h’

Дължина на стойността за състоянието на обработката — по избор за защитен обмен на съобщения от поколение 1

#(4+L+MM) - #(5+L+MM)

‘XX XXh’

#(6+L+MM)

‘8Eh’

TCC: таг за криптографската контролна сума

#(7+L+MM)

‘XXh’

LCC: дължина на следната криптографска контролна сума

‘04h’ за защитения обмен на съобщения от поколение 1 (вж. допълнение 11, част А)

#(8+L+MM)-#(7+N+L+MM)

‘XX..XXh’

Криптографска контролна сума

‘XXXXh’

Байтове за състоянието (SW1, SW2)“

з)

в точка 3.5.2.2, в раздел TCS_50 шестото тире се заменя със следното:

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

и)

в точка 3.5.2.3 раздел TCS_52 се изменя, както следва:

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

„Le

‘XXh’

Съгласно стандарта ISO/IEC 7816-4“

ii)	добавя се следното изречение: „Ако T=0, картата приема за стойност на Le = '00h', ако не се прилага защитен обмен на съобщения. Ако T = 1, за състоянието на обработката се връща „6700“, ако Le=’01h’.“;

й)

в точка 3.5.2.3, в раздел TCS_53 шестото тире се заменя със следното:

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

к)

в точка 3.5.3.2, в раздел TCS_63 шестото тире се заменя със следното:

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

л)

в точка 3.5.5 раздел TCS_72 се заменя със следното:

„TCS_72

Въведеният от потребителя PIN трябва да е по стандарта ASCII за кодиране на символи и да е запълнен от IFD отдясно с байтове ‘FFh’ до дължина от 8 байта — вж. също в допълнение 1 за типа на данните WorkshopCardPIN.“;

м)

в точка 3.5.8 раздел TCS_95 се заменя със следното:

„TCS_95

Ако командата INTERNAL_AUTHENTICATE бъде изпълнена успешно, активният ключ на сесията от поколение 1, ако има такъв, се изтрива и повече не е наличен. За да има на разположение нов ключ на сесия от поколение 1, е необходимо да се изпълни успешно командата EXTERNAL AUTHENTICATE за механизма от поколение 1 за удостоверяване на автентичността.

Забележка

За ключове за сесия от поколение 2 вж. допълнение 11, раздели CSM_193 и CSM_195. Ако бъдат установени ключове за сесия от поколение 2 и тахографската карта получи обикновена APDU за командата INTERNAL AUTHENTICATE, тя прекратява създаването на сесия за защитен обмен на съобщения от поколение 2 и унищожава ключовете за сесия от поколение 2.“;

н)

в точка 3.5.9 раздел TCS_97 се заменя със следното:

„TCS_97

Вариантът на командата за механизма от второ поколение за взаимно удостоверяване на бордовото устройство и картата може да се изпълнява в MF, DF Tachograph и DF Tachograph_G2, вж. също TCS_34. Ако командата EXTERNAL AUTHENTICATE от поколение 2 бъде изпълнена успешно, активният ключ на сесията от поколение 1, ако има такъв, се изтрива и повече не е наличен.

Забележка:

За ключове за сесия от поколение 2 вж. допълнение 11, раздели CSM_193 и CSM_195. Ако бъдат установени ключове за сесия от поколение 2 и тахографската карта получи обикновена APDU за командата EXTERNAL AUTHENTICATE, тя прекратява създаването на сесия за защитен обмен на съобщения от поколение 2 и унищожава ключовете за сесия от поколение 2.“;

о)

в точка 3.5.10, в таблицата в раздел TCS_101 се добавя следният ред:

„5 + L + 1

'00h'

Съгласно стандарта ISO/IEC 7816-4“

п)

в точка 3.5.11.2.3, в раздел TCS_114 се добавят следните абзаци:

„—	Ако currentAuthenticatedTime на картата е по-късно от датата, на която изтича срокът на валидност на избрания публичен ключ, за състоянието на обработката се връща „6A88“.

Забележка:

Ако за командата за удостоверяване на автентичността на бордовото устройство (VU Authentication) се използва MSE: SET AT, указаният ключ е публичен ключ VU_MA. Картата задава за използване публичния ключ VU_MA, ако е наличен в паметта ѝ, като той съвпада с указанието за титуляря на сертификата (Certificate Holder Reference — CHR), посочено в полето за данни на командата (картата може да идентифицира публичните ключове VU_MA чрез полето за CHA в сертификата). Ако е наличен само публичен ключ VU_Sign или ако за бордовото устройство няма наличен публичен ключ, в отговор на тази команда картата връща „6A 88“. Вж. определението за полето CHA в допълнение 11 и за типа данни equipmentType в допълнение 1.

По същия начин, ако към контролната карта бъде изпратена команда MSE: SET DST с указание за оборудването EQT (т.е. бордово устройство или карта), в съответствие с раздел CSM_234 указаният ключ винаги е ключ EQT_Sign, който трябва да се използва за удостоверяване на цифровия подпис. В съответствие с фигура 13 в допълнение 11 контролната карта винаги съхранява съответния публичен ключ EQT_Sign. В някои случаи контролната карта може да е съхранила съответния публичен ключ EQT_MA. Винаги, когато получи командата MSE: SET DST, контролната карта задава за използване публичния ключ EQT_Sign.“;

р)

точка 3.5.13 се изменя, както следва:

раздел TCS_121 се заменя със следното:

„TCS_121

Временно съхраняваната хеш-стойност на файла се заличава, ако бъде изчислена нова хеш-стойност на файла посредством командата PERFORM HASH of FILE, ако бъде избран DF и ако тахографската карта бъде инициализирана.“;

ii)

раздел TCS_123 се заменя със следното:

„TCS_123

Тахографското приложение от поколение 2 трябва да поддържа алгоритъма SHA-2 (SHA-256, SHA-384 или SHA-512), посочен в криптографската поредица в допълнение 11, част Б, за ключа за подпис на картата Card_Sign.“;

iii)

таблицата в раздел TCS_124 се заменя със следното:

„Байт	Дължина	Стойност	Описание
CLA	1	‘80h’	CLA
INS	1	‘2Ah’	Извършване на операция, свързана със защитата от неразрешен достъп
P1	1	‘90h’	Таг: Hash
P2	1	‘00h’	Алгоритъм, известен по подразбиране За тахографското приложение от поколение 1: SHA-1 За тахографското приложение от поколение 2: алгоритъм SHA-2 (SHA-256, SHA-384 или SHA-512), определен в криптографската поредица в допълнение 11, част Б, за ключа за подпис на картата Card_Sign“

с)

точка 3.5.14 се изменя, както следва:

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

„Тази команда служи за изчисляване на цифровия подпис на изчислен преди това хеш-код (вж. PERFORM HASH of FILE, точка 3.5.13).

Само за картата на водач и за картата за монтаж и настройки се изисква да поддържат тази команда в DF Tachograph и DF Tachograph_G2.

Другите видове тахографски карти могат или не могат да изпълняват тази команда. При тахографското приложение от поколение 2 само картата на водач и картата за монтаж и настройки имат ключ за подпис от поколение 2; другите карти не могат успешно да изпълнят командата и прекратяват изпълнението с подходящ код за грешка.

Тази команда може да е или да не е достъпна в MF. Ако командата не е достъпна в MF, нейното изпълнение се прекратява с подходящ код за грешка.

Тази команда е в съответствие със стандарт ISO/IEC 7816-8. Нейното използване е по-ограничено, отколкото съгласно посочения стандарт.“;

т)

точка 3.5.15 се изменя, както следва:

таблицата в раздел TCS_133 се заменя със следното:

„Байт

Дължина

Стойност

Описание

CLA

‘00h’

CLA

INS

‘2Ah’

Извършване на операция, свързана със защитата от неразрешен достъп

‘00h’

‘A8h’

Таг: поле за данни, съдържащо съответните обекти от данни (DO) за проверката

‘XXh’

Дължина Lc на последващото поле за данни

‘9Eh’

Таг за цифров подпис

#7 или

#7-#8

‘NNh’ или

‘81 NNh’

Дължина на цифровия подпис (L е 2 байта, ако цифровият подпис е по-дълъг от 127 байта):

128 байта, кодирани в съответствие с допълнение 11, част А за тахографско приложение от поколение 1.

В зависимост от избраната крива за тахографско приложение от поколение 2 (вж. допълнение 11, част Б).

#(7+L)-#(6+L+NN)

‘XX..XXh’

Съдържание на цифровия подпис“

ii)

в раздел TCS_134 се добавя следното тире:

„—	Ако избраният публичен ключ (използван за проверка на въведения цифров подпис) има CHA.LSB (CertificateHolderAuthorisation.equipmentType), който не е подходящ за проверка на цифровия подпис съгласно допълнение 11, за състоянието на обработката се връща „6985“.“;

у)

точка 3.5.16 се изменя, както следва:

в таблицата в раздел TCS_138 се добавя следният ред:

„5 + L + 1

'00h'

Съгласно стандарта ISO/IEC 7816-4“

ii)

в раздел TCS_139 се добавя следният абзац:

„—	„6985“ указва, че времевият печат от 4 байта, посочен в полето за данни на командата, е по-ранен от cardValidityBegin или по-късен от cardExpiryDate.“;

ф)

точка 4.2.2 се изменя, както следва:

i)	в структурата на данните в раздел TCS_154 редовете от DF Tachograph G2 до EF CardMA_Certificate и редовете от EF GNSS_Places до края на раздела се заменят със следното: „ Текст на изображението Файл / елемент на данни Брой записи Размер (байтове) Стойности по подразбиране Мин. Макс. “

ii)

в таблицата в раздел TCS_155 позицията

се заменя със следното:

„

252

336“

х)

в точка 4.3.1 текстът за съкращение SC4 в раздел TCS_156 се заменя със следното:

„SC4	За командата READ BINARY с четен байт INS: (SM-C-MAC-G1 И SM-R-ENC-MAC-G1) ИЛИ (SM-C-MAC-G2 И SM-R-ENC-MAC-G2) За командата READ BINARY с нечетен байт INS (ако се поддържа): NEV“;

ц)

точка 4.3.2 се изменя, както следва:

в структурата на данните в раздел TCS_162 редовете от DF Tachograph G2 до EF CardMA_Certificate, редовете от EF Calibration до extendedSealIdentifier и редовете от EF GNSS_Places до vehicleOdometerValue се заменят със следното:

„

Текст на изображението

“

ii)

в таблицата в раздел TCS_163 позицията NoOfGNSSCDRecords се заменя със следното:

„

24“

31)

В допълнение 3 точка 2 се изменя, както следва:

а)	след реда с пиктограмите „Местоположение в началото на дневния период на работа“ и „Местоположение в края на дневния период на работа“ се вмъква следният ред: „ местоположение след 3 часа общо време на управление на МПС“;

б)	комбинацията от пиктограми „Сверяване на часовника (в сервиз)“ се заменя със следното: „ Времеви конфликт или сверяване на часовника (в сервиз)“;

в)	към списъка „Събития“ се добавят следните комбинации от пиктограми: „ Липса на информация за местоположението от приемник на сигнали от GNSS или Грешка в комуникацията с външното устройство за GNSS; Грешка в комуникацията с устройството за връзка от разстояние“.

32)

Допълнение 4 се изменя, както следва:

а)

точка 2 се изменя, както следва:

блок 11.4 се заменя със следното:

„11.4

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

pi = пиктограма за местоположението при тръгване/пристигане, час, държава (Cou), област (Reg)

дължина на регистрираното местоположение

ширина на регистрираното местоположение

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

показание на километражния брояч

pihh:mm Cou Reg

lon ±DDDoMM.M’

lat ± DDoMM.M’

hh:mm

x xxx xxx km“

ii)

блок 11.5 се заменя със следното:

„11.5

Местоположения след 3 часа общо време на управление на МПС

pi=местоположение след 3 часа общо време на управление на МПС

час

дължина на регистрираното местоположение

ширина на регистрираното местоположение

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

показание на километражния брояч

“

б)

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

„11.5

Местоположения след 3 часа общо време на управление на МПС в хронологичен ред“;

в)

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

„1		Дата и час на отпечатване на документа
2		Тип на разпечатката
3		Идентификация на титуляря на картата (за всички карти, вкарани във VU + GEN)
4		Идентификация на превозното средство (от което е направена разпечатката)
5		Идентификация на бордовото устройство (от което е направена разпечатката + GEN)
6		Последно калибриране на това бордово устройство
7		Последна проверка на този тахограф
9		Разграничител на данни за дейностите на водача
10		Разграничител за четящото устройство за картата на водача (процеп 1)
10a		Условие „Извън обсег“ в началото на този ден
10.1 / 10.2 / 10.3 /10.3a / 10.4		Дейности в хронологичен ред (четящо устройство на водача)
10		Разграничител за четящото устройство за картата на втория водач (процеп 2)
10a		Условие „Извън обсег“ в началото на този ден
10.1 / 10.2 / 10.3 /10.3a / 10.4		Дейности в хронологичен ред (четящо устройство на втория водач)
11		Разграничител за ежедневната справка
11.1		Справка за периодите без вкарана карта в процепа на четящото устройство на водача
11.4		Въведени местоположения в хронологичен ред
11.5		Местоположения след 3 часа общо време на управление на МПС в хронологичен ред
11.7		Общо времетраене на всяка дейност
11.2		Справка за периодите без вкарана карта в процепа на четящото устройство на втория водач
11.4		Въведени местоположения в хронологичен ред
11.5		Местоположения след 3 часа общо време на управление на МПС в хронологичен ред
11.8		Общо времетраене на всяка дейност
11.3		Справка за дейностите на водача, като се вземат под внимание и двете четящи устройства
	11.4	Местоположения, въведени от този водач в хронологичен ред
	11.5	Местоположения след 3 часа общо време на управление на МПС в хронологичен ред
11.9		Общо времетраене на всяка дейност на този водач
13.1		Разграничител на данни за събития и неизправности
13.4		Записи за събития/неизправности (5-те последни събития или неизправности, които са записани или са в процес на записване в бордовото устройство)
22.1		Контролен пункт
22.2		Подпис на контрольора
22.3		От час (празно място, където водач без карта посочва
22.4		До час периодите, валидни за него)
22.5		Подпис на водача“;

г)

в точка 3.7 раздел PRT_014 се заменя със следното:

„PRT_014

Разпечатката за историята на вкараните карти трябва да е в съответствие със следния формат:

1	Дата и час на отпечатване на документа
2	Тип на разпечатката
3	Идентификация на титуляря на картата (за всички карти, вкарани в бордовото устройство)
23	Последна карта, вкарана в бордовото устройство
23.1	Вкарани карти (до 88 записа)
12.3	Разграничител на данни за неизправности“.

33)

Допълнение 7 се изменя, както следва:

а)

точка 1.1 се заменя със следното:

„1.1. Обхват

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

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

—	от тахографска карта чрез IDE, оборудвано с интерфейсно устройство за карта (IFD),

—	през бордовото устройство от тахографска карта чрез IDE, свързано към бордовото устройство.

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

Данните, изтеглени от бордовото устройство, се подписват съгласно общите механизми за сигурност от допълнение 11, част Б (тахографска система от второ поколение), освен когато проверката на водача се извършва от контролен орган на държава извън ЕС с контролна карта от първо поколение; в тези случаи данните се подписват съгласно общите механизми за сигурност от допълнение 11, част А (тахографска система от първо поколение) в съответствие с изискванията в раздел MIG_015 от допълнение 15 — „Миграция“.

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

—	изтегляне на данни от бордово устройство от поколение 2 със структура на данните от поколение 2, като данните се подписват съгласно общите механизми за сигурност от допълнение 11, част Б,

—	изтегляне на данни от бордово устройство от поколение 1 със структура на данните от поколение 1, като данните се подписват съгласно общите механизми за сигурност от допълнение 11, част А.

По същия начин съществуват и два типа данни, изтеглени от карта на водач от второ поколение, вкарана в бордовото устройство, както се посочва в параграфи 3 и 4 от настоящото допълнение.“;

б)

точка 2.2.2 се изменя, както следва:

таблицата се заменя със следното:

„Структура на съобщението		4 байта максимум Заглавна част				255 байта максимум Данни			1 байт Контролна сума
IDE ->	<- VU	FMT	TGT	SRC	LEN	SID	DS_ / TRTP	DATA	CS
Start Communication Request		81	EE	F0		81			E0
Positive Response Start Communication		80	F0	EE	03	C1		EA, 8F	9B
Start Diagnostic Session Request		80	EE	F0	02	10	81		F1
Positive Response Start Diagnostic		80	F0	EE	02	50	81		31
Link Control Service
Verify Baud Rate (stage 1)
9 600 Bd		80	EE	F0	04	87		01,01,01	EC
19 200 Bd		80	EE	F0	04	87		01,01,02	ED
38 400 Bd		80	EE	F0	04	87		01,01,03	EE
57 600 Bd		80	EE	F0	04	87		01,01,04	EF
115 200 Bd		80	EE	F0	04	87		01,01,05	F0
Positive Response Verify Baud Rate		80	F0	EE	02	C7		01	28
Transition Baud Rate (stage 2)		80	EE	F0	03	87		02,03	ED
Request Upload		80	EE	F0	0A	35		00,00,00, 00,00,FF,FF, FF,FF	99
Positive Response Request Upload		80	F0	EE	03	75		00,FF	D5
Transfer Data Request
Overview		80	EE	F0	02	36	01 or 21		97
Activities		80	EE	F0	06	36	02 or 22	Date	CS
Events & Faults		80	EE	F0	02	36	03 or 23	Date	99
Detailed Speed		80	EE	F0	02	36	04 or 24	Date	9A
Technical Data		80	EE	F0	02	36	05 or 25	Date	9B
Card download		80	EE	F0	02	36	06	Slot	CS
Positive Response Transfer Data		80	F0	EE	Len	76	TREP	Data	CS
Request Transfer Exit		80	EE	F0	01	37			96
Positive Response Request Transfer Exit		80	F0	EE	01	77			D6
Stop Communication Request		80	EE	F0	01	82			E1
Positive Response Stop Communication		80	F0	EE	01	C2			21
Acknowledge sub message		80	EE	F0	Len	83		Data	CS
Negative responses
General reject		80	F0	EE	03	7F	Sid Req	10	CS
Service not supported		80	F0	EE	03	7F	Sid Req	11	CS
Sub function not supported		80	F0	EE	03	7F	Sid Req	12	CS
Incorrect Message Length		80	F0	EE	03	7F	Sid Req	13	CS
Conditions not correct or Request sequence error		80	F0	EE	03	7F	Sid Req	22	CS
Request out of range		80	F0	EE	03	7F	Sid Req	31	CS
Upload not accepted		80	F0	EE	03	7F	Sid Req	50	CS
Response pending		80	F0	EE	03	7F	Sid Req	78	CS
Data not available		80	F0	EE	03	7F	Sid Req	FA	CS“

ii)

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

„—

TRTP 21 — 25 се използват за заявки за изтегляне на данни от бордово устройство от поколение 2; TRTP 01 — 05 се използват за заявки за изтегляне на данни от бордово устройство от поколение 1, които бордовото устройство може да приеме само при проверка на водача, която се извършва от контролен орган на държава извън ЕС с контролна карта от първо поколение,

—	TRTP 11 — 19 и 31 — 39 са запазени за заявки за специфични изтегляния на данни от производителя.“;

в)

точка 2.2.2.9 се изменя, както следва:

раздел DDP_011 се заменя със следното:

„DDP_011

IDE изпраща Transfer Data Request, за да уточни за бордовото устройство вида на данните, които трябва да се изтеглят. Transfer Request Parameter (TRTP) на определен байт показва типа трансфер.

Съществуват шест типа трансфер на данни. За изтегляне на данни от бордовото устройство за всеки тип трансфер могат да се използват две различни стойности на TRTP:

Тип трансфер на данни	Стойност на TRTP при изтегляне на данни от бордово устройство от поколение 1	Стойност на TRTP при изтегляне на данни от бордово устройство от поколение 2
Overview	01	21
Activities of a specified date	02	22
Events and faults	03	23
Detailed speed	04	24
Technical data	05	25

Тип трансфер на данни	Стойност на TRTP
Card download	06“

ii)

раздел DDP_054 се заменя със следното:

„DDP_054

За IDE е задължително да заяви overview data transfer (TRTP 01 или 21) по време на сесия за изтегляне на данни, защото единствено това гарантира, че сертификатите на бордовото устройство се регистрират в изтегления файл (и това позволява проверката на цифровия подпис).

Във втория случай (TRTP 02 или 22) съобщението Transfer Data Request съдържа указание за календарния ден (формат ), чиито данни трябва да се изтеглят.“;

г)

в точка 2.2.2.10 раздел DDP_055 се заменя със следното:

„DDP_055

В първия случай (TREP 01 или 21) бордовото устройство ще изпрати данни, предназначени да помогнат на потребителя на IDE при избора на данните, които иска да изтегли. Съобщението съдържа следната информация:

—	сертификати за сигурност,

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

—	актуалната дата и час на бордовото устройство,

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

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

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

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

—	предишни проверки.“;

д)

в точка 2.2.2.16, в раздел DDP_018 последното тире се заменя със следното:

„—

Данни FA, които не са на разположение

Обектът от данни на заявка за трансфер на данни не е достъпен в бордовото устройство (например не е поставена карта; получената заявка за изтегляне на данни от бордовото устройство от поколение 1 не е при проверка на водача от контролен орган на държава извън ЕС...).“;

е)

точка 2.2.6.1 се изменя, както следва:

i)	в раздел DDP_029 първият абзац се заменя със следното: „Полето за данни на съобщението „Positive Response Transfer Data Overview“ трябва да дава данните по-долу по следния ред по SID 76 Hex, TRЕP 01 или 21 Hex и съответните критерии за разделяне и преброяване на подсъобщенията:“;

ii)	заглавието „Структура на данните от поколение 1“ се заменя със следното: „Структура на данните от поколение 1 (TREP 01 Hex)“;

iii)	заглавието „Структура на данните от поколение 2“ се заменя със следното: „Структура на данните от поколение 2 (TREP 21 Hex)“;

ж)

точка 2.2.6.2 се изменя, както следва:

i)	в раздел DDP_030 първият абзац се заменя със следното: „Полето за данни на съобщението „Positive Response Transfer Data Activities“ трябва да дава данните по-долу по следния ред по SID 76 Hex, TRЕP 02 или 22 Hex и съответните критерии за разделяне и преброяване на подсъобщенията:“;

ii)	заглавието „Структура на данните от поколение 1“ се заменя със следното: „Структура на данните от поколение 1 (TREP 02 Hex)“;

iii)	заглавието „Структура на данните от поколение 2“ се заменя със следното: „Структура на данните от поколение 2 (TREP 22 Hex)“;

iv)

позицията VuGNSSCDRecordArray под заглавието „Структура на данните от поколение 2 (TREP 22 Hex)“ се заменя със следното:

„

Местоположения на превозното средство по GNSS, когато общото време на управление на МПС достигне кратно число на три часа. Ако тази част е празна, се изпраща заглавна част на масив с noOfRecords = 0.“

з)

точка 2.2.6.3 се изменя, както следва:

i)	в раздел DDP_031 първият абзац се заменя със следното: „Полето за данни на съобщението „Positive Response Transfer Data Events and Faults“ трябва да дава данните по-долу по следния ред по SID 76 Hex, TRЕP 03 или 23 Hex и съответните критерии за разделяне и преброяване на подсъобщенията:“;

ii)	заглавието „Структура на данните от поколение 1“ се заменя със следното: „Структура на данните от поколение 1 (TREP 03 Hex)“;

iii)	заглавието „Структура на данните от поколение 2“ се заменя със следното: „Структура на данните от поколение 2 (TREP 23 Hex)“;

iv)	позицията VuTimeAdjustmentGNSSRecordArray под заглавието „Структура на данните от поколение 2 (TREP 23 Hex)“ се заличава;

и)

точка 2.2.6.4 се изменя, както следва:

i)	в раздел DDP_032 първият абзац се заменя със следното: „Полето за данни на съобщението „Positive Response Transfer Data Detailed Speed“ трябва да дава данните по-долу по следния ред по SID 76 Hex, TRЕP 04 или 24 Hex и съответните критерии за разделяне и преброяване на подсъобщенията:“;

ii)	заглавието „Структура на данните от поколение 1“ се заменя със следното: „Структура на данните от поколение 1 (TREP 04)“;

iii)	заглавието „Структура на данните от поколение 2“ се заменя със следното: „Структура на данните от поколение 2 (TREP 24)“;

й)

точка 2.2.6.5 се изменя, както следва:

i)	в раздел DDP_033 първият абзац се заменя със следното: „Полето за данни на съобщението „Positive Response Transfer Data Technical Data“ трябва да дава данните по-долу по следния ред по SID 76 Hex, TRЕP 05 или 25 Hex и съответните критерии за разделяне и преброяване на подсъобщенията:“;

ii)	заглавието „Структура на данните от поколение 1“ се заменя със следното: „Структура на данните от поколение 1 (TREP 05)“;

iii)	заглавието „Структура на данните от поколение 2“ се заменя със следното: „Структура на данните от поколение 2 (TREP 25)“;

к)

в точка 3.3 раздел DDP_035 се заменя със следното:

„DDP_035

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

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

—

(за тахографски карти от първо и второ поколение) изтегляне на EF в рамките на :

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

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

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

—	когато се извършва изтегляне на данни от карта на водач, е задължително също да се изтеглят следните EF: Текст на изображението Events_Data, Faults_Data, Текст на изображението Driver_Activity_Data, Vehicles_Used, Places, Control_Activity_Data, Specific_Conditions,

—

(само за тахографски карти от второ поколение) с изключение на случаите, когато изтеглянето на данни от карта на водач, вкарана в бордовото устройство, се извършва при проверка на водача от контролен орган на държава извън ЕС с контролна карта от първо поколение, изтегляне на EF в рамките на :

—	изтегляне на EF CardSignCertificate, CA_Certificate и Link_Certificate (ако е наличен). Тази информация не е защитена с цифров подпис. Тези файлове трябва задължително да се изтеглят за всяка сесия за изтегляне на данни;

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

—	задължително е да се изтеглят поне EF Application_Identification и Identification за всяка сесия за изтегляне на данни;

—	когато се извършва изтегляне на данни от карта на водач, е задължително също да се изтеглят следните EF: Текст на изображението Events_Data, Faults_Data, Driver_Activity_Data, Vehicles_Used, Places, Control_Activity_Data, Specific_Conditions, VehicleUnits_Used, GNSS Places.

—	когато се извършва изтегляне на данни от карта на водач, трябва да се актуализира датата на в EF , както и в и ако е уместно — в DF .

—	когато се извършва изтегляне на данни от карта за монтаж и настройки, трябва да се инициализира броячът за калибриране в EF , както и в и ако е уместно — в DF .

—	когато се изтеглят данни от карта за монтаж и настройки, не трябва да се изтеглят данните от в и ако е уместно — в DF .“;

л)	в точка 3.3.2, в раздел DDP_037 първият абзац се заменя със следното: „Последователността за изтегляне на данни от EF ICC, IC, Card_Certificate (или CardSignCertificate за DF Tachograph_G2), CA_Certificate и Link_Certificate (само за DF Tachograph_G2) е, както следва:“;

м)

таблицата в точка 3.3.3 се заменя със следното:

„Карта

Посока

IDE/IFD

Значение/Забележки

Select File

Perform Hash of File

—	Позволява да се изчисли хеш-стойността по отношение на съдържанието на избрания файл, като се използва хеш-алгоритъмът, посочен в допълнение 11, част А или Б. Това не е команда ISO.

Изчислява се Hash of File и временно се съхранява хеш-стойността

Read Binary

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

Данни от файла

Получените данни се съхраняват върху ESM

Съгласно 3.4. Формат за съхранение на данните

PSO: Compute Digital Signature

Изпълнение на операция за сигурност „Compute Digital Signature“, като се използва временно съхранената хеш-стойност

Подпис

Добавяне на данни към тези, които са съхранени преди това върху ЕSM

съгласно 3.4. Формат за съхранение на данните“

н)

в точка 3.4.2 раздел DDP_046 се заменя със следното:

„DDP_046

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

Определение	Значение	Дължина
FID (2 байта) \|\| „00“	Таг за EF (FID) в или за общата информация на картата	3 байта
FID (2 байта) \|\| „01“	Таг за подпис на EF (FID) в DF	3 байта
FID (2 байта) \|\| „02“	Таг за EF (FID) в DF	3 байта
FID (2 байта) \|\| „03“	Таг за подпис на EF (FID) в DF	3 байта
xx xx	Дължина на полето за стойността	2 байта

Пример за данни в изтеглен файл върху ЕSM:

Таг

Дължина

Стойност

—	Данни от EF ICC

—	Данни от EF Card_Certificate

—

...

Данни от EF

(в DF

)

Подпис на EF

(в DF

)

Данни от EF

в DF

Подпис на EF

в DF

“

о)

в точка 4 раздел DDP_049 се заменя със следното:

„DDP_049

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

Карти на водач от второ поколение: Тогава бордовото устройство трябва да извърши цялостното изтегляне на данни от картата, файл по файл, в съответствие с протокола за изтегляне на данни от карта, определен в параграф 3, както и да изпрати към IDE всички данни, които са получени от картата в съответния файлов формат ТLV (вж. 3.4.2) и са капсулирани в съобщение „Positive Response Transfer Data“.“

34)	В допълнение 8, точка 2 текстът под заглавието „Справочни материали“ се заменя със следното: „ISO 14230-2: Пътни превозни средства. Системи за диагностика. Протокол „Keyword 2000“. Част 2: канален слой. Първо издание: 1999 г.“

35)

Допълнение 9 се изменя, както следва:

а)

точка 6 в съдържанието се заменя със следното:

„6.	ИЗПИТВАНИЯ НА ВЪНШНОТО УСТРОЙСТВО ЗА ВРЪЗКА ОТ РАЗСТОЯНИЕ“;

б)

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

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

в)

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

„№

Изпитване

Описание

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

Административен преглед

1.1

Документиране

Правилност на документацията

1.2

Резултати от изпитване, проведено от производителя

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

Писмени демонстрации.

88, 89, 91

Визуално инспектиране

2.1

Съответствие с документацията

2.2

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

224 до 226

2.3

Материали

219 до 223

2.4

Херметизация

398, 401 до 405

2.5

Външни интерфейси

Функционални изпитвания

3.1

Осигурявани функции

02, 03, 04, 05, 07, 382

3.2

Режими на работа

09 до 11*, 134, 135

3.3

Права за достъп до функции и данни

12* 13*, 382, 383, 386 до 389

3.4

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

15, 16, 17, 18, 19*, 20*, 134

3.5

Измерване на скорост и разстояние

21 до 31

3.6

Измерване на време (изпитване, провеждано при 20 °C)

38 до 43

3.7

Следене на дейностите на водача

44 до 53, 134

3.8

Следене на състоянието при управление на МПС

54, 55, 134

3.9

Ръчно въвеждани данни

56 до 62

3.10

Управление на фирмените блокировки за информация на превозвачи

63 до 68

3.11

Следене на контролните дейности

69, 70

3.12

Установяване на събития и/или неизправности

71 до 88, 134

3.13

Данни за идентифициране на уредите

93*, 94*, 97, 100

3.14

Данни за вкарването и изваждането на картата на водач

102* до 104*

3.15

Данни за дейностите на водача

105* до 107*

3.16

Данни за места и местоположения

108* до 112*

3.17

Данни от километражния брояч

113* до 115*

3.18

Подробни данни за скоростта

116*

3.19

Данни за събития

117*

3.20

Данни за неизправности

118*

3.21

Данни за калибриране

119* до 121*

3.22

Данни за сверяване на часовника

124*, 125*

3.23

Данни за контролните дейности

126*, 127*

3.24

Данни за фирмени блокировки за информация на превозвачи

128*

3.25

Изтегляне на данни за дейностите

129*

3.26

Данни за специфични условия

130*, 131*

3.27

Записване и запаметяване върху тахографските карти

136, 137, 138*, 139*, 141*, 142, 143

144, 145, 146*, 147*, 148*, 149, 150

3.28

Показване върху дисплея

90, 134,

151 до 168,

PIC_001, DIS_001

3.29

Разпечатване

90, 134,

169 до 181, PIC_001, PRT_001 до PRT_014

3.30

Предупреждаване

134, 182 до 191,

PIC_001

3.31

Изтегляне на данни към външни носители

90, 134, 192 до 196

3.32

Връзка от разстояние за извършване на целенасочени пътни проверки

197 до 199

3.33

Данни, прехвърляни към допълнителни външни устройства

200, 201

3.34

Калибриране

202 до 206*, 383, 384, 386 до 391

3.35

Крайпътна проверка на калибрирането

207 до 209

3.36

Сверяване на часовника

210 до 212*

3.37

Отсъствие на смущения от страна на допълнителните функции

06, 425

3.38

Интерфейс на датчика на движение

02, 122

3.39

Външно устройство за GNSS

03, 123

3.40

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

217

3.41

Криптографска поредица (cypher suite) и стандартизирани домейн параметри

CSM_48, CSM_50

Изпитвания за въздействията на околната среда

4.1

Температура

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

Изпитване съгласно ISO 16750-4, глава 5.1.1.2: Изпитване за работа при ниска температура (72 часа при – 20 °C)

Това изпитване е с позоваване на IEC 60068-2-1: Изпитване на въздействия на околната среда — Част 2-1: Изпитвания — Изпитване А: Студ

Изпитване съгласно ISO 16750-4: глава 5.1.2.2: Изпитване за работа при висока температура (72 часа при 70 °C)

Това изпитване е с позоваване на IEC 60068-2-2: Основни процедури за изпитване на въздействия на околната среда; Част 2: Изпитвания; Изпитвания В: Суха топлина

Изпитване съгласно ISO 16750-4: Глава 5.3.2: Бърза промяна на температурата при зададена продължителност на прехода (– 20 °C/70 °C, 20 цикъла, време на задържане при всяка от температурите 2 часа)

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

213

4.2

Влажност

Проверява се, че бордовото устройство може да понесе циклично изпитване на топлина във влажна среда съгласно IEC 60068-2-30, изпитване Db, с шест цикъла по 24 часа, като във всеки от тях температурата се изменя от + 25 °C до + 55 °C и относителната влажност е съответно 97 % при + 25 °C и 93 % при + 55 °C

214

4.3

Механични въздействия

Синусоидални вибрации.

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

постоянно изместване, при честота между 5 и 11 Hz: максимум 10 mm

постоянно ускорение, при честота между 11 и 300 Hz: 5 g

Съответствието с това изискване се проверява чрез изпитване Fc по IEC 60068-2-6, с минимално времетраене на изпитването 3 × 12 часа (по 12 часа на координатна ос)

Стандартът ISO 16750-3 не изисква да се провежда изпитване със синусоидални вибрации за устройства, намиращи се в отделна кабина на превозното средство.

Случайни вибрации:

Изпитване съгласно ISO 16750-3: глава 4.1.2.8: Изпитване VIII: Търговски превозни средства с отделна кабина

Изпитване за случайни вибрации, 10...2000 Hz, вертикално средноквадратично отклонение 21,3 m/s2, надлъжно средноквадратично отклонение 11,8 m/s2, напречно средноквадратично отклонение 13,1 m/s2, 3 оси, по 32 часа за ос, включително температурен цикъл – 20...70 °C.

Това изпитване е с позоваване на IEC 60068-2-64: Изпитване на въздействия на околната среда — Част 2-64: Изпитвания — Изпитване Fh: Вибрации, широколентови случайни, и указания

3.	Удари: механичен удар с ускорение 3 g, полусинусоидален, съгласно ISO 16750.

Гореописаните изпитвания се извършват върху различни мостри на изпитваните съоръжения.

219

4.4

Защита срещу проникване на вода и чужди тела

Изпитване съгласно ISO 20653: Пътни превозни средства. Степен на защита (IP код). Защита на електрическото оборудване срещу проникване на чужди тела, вода и достъп (запазване на характеристиките); Минимално допустима стойност IP 40

220, 221

4.5

Защита срещу пренапрежения

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

при варианти за напрежение 24 V: 34 V при + 40 °C в продължение на 1 час	:	при варианти за напрежение 24 V: 34 V при + 40 °C в продължение на 1 час
при варианти за напрежение 12 V: 17 V при + 40 °C в продължение на 1 час	:	при варианти за напрежение 12 V: 17 V при + 40 °C в продължение на 1 час

(ISO 16750-2)

216

4.6

Защита срещу включване с обратна полярност

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

(ISO 16750-2)

216

4.7

Защита срещу къси съединения

Проверява се, че входно/изходните сигнали са защитени срещу къси съединения към захранването и към масата

(ISO 16750-2)

216

Изпитване за електромагнитна съвместимост (EMC)

5.1

Излъчени емисии и чувствителност към тях

Съответствие с Правило № 10 на ИКЕ на ООН

218

5.2

Електростатичен разряд

Съответствие със стандарт ISO 10605:2008 +

Техническа поправка: 2010 +

AMD1:2014: +/- 4 kV за контактен разряд и +/- 8 kV за разряд през въздух

218

5.3

Чувствителност към преходни процеси по проводниците на захранването

При варианти за напрежение 24 V: съответствие със стандарт ISO 7637-2 + Правило № 10 на ИКЕ на ООН, Преработка 3:

импулс 1a: Vs = – 450 V, Ri = 50 Ω

импулс 2a: Vs = + 37 V, Ri = 2 Ω

импулс 2b: Vs = + 20 V, Ri = 0,05 Ω

импулс 3a: Vs = – 150 V, Ri = 50 Ω

импулс 3b: Vs = + 150 V, Ri = 50 Ω

импулс 4: Vs = – 16 V, Va = – 12 V, t6 = 100 ms

импулс 5: Vs = + 120 V, Ri = 2,2 Ω, td = 250 ms

При варианти за напрежение 12 V: съответствие със стандарт ISO 7637-1 + Правило № 10 на ИКЕ на ООН, Преработка 3:

импулс 1: Vs = – 75 V, Ri = 10 Ω

импулс 2a: Vs = + 37 V, Ri = 2 Ω

импулс 2b: Vs = + 10 V, Ri = 0,05 Ω

импулс 3a: Vs = – 112 V, Ri = 50 Ω

импулс 3b: Vs = + 75 V, Ri = 50 Ω

импулс 4: Vs = – 6 V, Va = – 5 V, t6 = 15 ms

импулс 5: Vs = + 65 V, Ri = 3 Ω, td = 100 ms

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

За примерни стойности на повишено напрежение вследствие разкачане на акумулаторната батерия при зареждащ я алтернатор, вж. стандарт ISO 16750-2, 4-то издание, глава 4.6.4.

218“

г)

точка 6 се заменя със следното:

„6. ИЗПИТВАНИЯ НА ВЪНШНОТО УСТРОЙСТВО ЗА ВРЪЗКА ОТ РАЗСТОЯНИЕ

№

Изпитване

Описание

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

Административен преглед

1.1

Документиране

Правилност на документацията

Визуално инспектиране

2.1.

Съответствие с документацията

2.2.

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

225, 226

2.3

Материали

219 до 223

Функционални изпитвания

3.1

Връзка от разстояние за извършване на целенасочени пътни проверки

4, 197 до 199

3.2

Записване и съхраняване на данните в паметта

3.3

Връзка с бордовото устройство

Допълнение 14, раздели DSC_66 до DSC_70 и DSC_71 до DSC_76

Изпитвания за въздействията на околната среда

4.1

Температура

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

Изпитване съгласно ISO 16750-4, глава 5.1.1.2: Изпитване за работа при ниска температура (72 часа при – 20 °C)

Изпитване съгласно ISO 16750-4: глава 5.1.2.2: Изпитване за работа при висока температура (72 часа при 70 °C)

213

4.2

Защита срещу проникване на вода и чужди тела

Изпитване съгласно ISO 20653: Пътни превозни средства. Степен на защита (IP код). Защита на електрическото оборудване срещу проникване на чужди тела, вода и достъп (целева стойност IP40)

220, 221

Изпитание за електромагнитна съвместимост (EMC)

5.1

Излъчени емисии и чувствителност към тях

Съответствие с Правило № 10 на ИКЕ на ООН

218

5.2

Електростатичен разряд

Съответствие със стандарт ISO 10605:2008 + Техническа поправка: 2010 + AMD1:2014: +/– 4 kV за контактен разряд и +/– 8 kV за разряд през въздух

218

5.3

Чувствителност към преходни процеси по проводниците на захранването

При варианти за напрежение 24 V: съответствие със стандарт ISO 7637-2 + Правило № 10 на ИКЕ на ООН, Преработка 3:

импулс 1a: Vs = – 450 V, Ri = 50 Ω

импулс 2a: Vs = + 37 V, Ri = 2 Ω

импулс 2b: Vs = + 20 V, Ri = 0,05 Ω

импулс 3a: Vs = – 150 V, Ri = 50 Ω

импулс 3b: Vs = + 150 V, Ri = 50 Ω

импулс 4: Vs = – 16 V, Va = – 12 V, t6 = 100 ms

импулс 5: Vs = + 120 V, Ri = 2,2 Ω, td = 250 ms

При варианти за напрежение 12 V: съответствие със стандарт ISO 7637-1 + Правило № 10 на ИКЕ на ООН, Преработка 3:

импулс 1: Vs = – 75 V, Ri = 10 Ω

импулс 2a: Vs = + 37 V, Ri = 2 Ω

импулс 2b: Vs = + 10 V, Ri = 0,05 Ω

импулс 3a: Vs = – 112 V, Ri = 50 Ω

импулс 3b: Vs = + 75 V, Ri = 50 Ω

импулс 4: Vs = – 6 V, Va = – 5 V, t6 = 15 ms

импулс 5: Vs = + 65 V, Ri = 3 Ω, td = 100 ms

218“

д)

таблицата за оперативна съвместимост в точка 8 се заменя със следното:

„№	Изпитване	Описание
8.1 Изпитвания за оперативна съвместимост между бордови устройства и тахографски карти
1	Взаимно удостоверяване на автентичност	Проверява се дали взаимното удостоверяване на автентичност между бордовото устройство и тахографската карта протича нормално
2	Изпитвания за четене /записване	Върху бордовото устройство се изпълнява сценарий на типично действие. Сценарият трябва да е адаптиран към изпитвания тип карта и да включва записвания във възможно най-голям брой елементарни файлове (EF) в картата Чрез изтегляне на данните от бордовото устройство се проверява дали всички съответни записи са направени правилно. Чрез изтегляне на данните от картата се проверява дали всички съответни записи са направени правилно. Чрез дневни разпечатки се проверява дали всички съответни записи могат да бъдат прочетени правилно.
8.2 Изпитвания за оперативна съвместимост между бордови устройства и датчици за движение
1	Сдвояване	Проверява се дали сдвояването между бордовите устройства и датчиците за движение протича нормално
2	Изпитвания на действието	Върху датчика за движение се изпълнява сценарий на типично действие. Сценарият трябва да включва нормално действие и създаване на възможно най-много събития или неизправности. Чрез изтегляне на данните от бордовото устройство се проверява дали всички съответни записи са направени правилно. Чрез изтегляне на данните от картата се проверява дали всички съответни записи са направени правилно. Чрез дневна разпечатка се проверява дали всички съответни записи могат да бъдат прочетени правилно.
8.3 Изпитвания за оперативна съвместимост между бордови устройства и външни устройства за GNSS (когато има такива)
1	Взаимно удостоверяване на автентичност	Проверява се дали взаимното удостоверяване на автентичност (свързване) между бордовото устройство и външното устройство за GNSS протича нормално.
2	Изпитвания на действието	Върху външното устройство за GNSS се изпълнява сценарий на типично действие. Сценарият трябва да включва нормално действие и създаване на възможно най-много събития или неизправности. Чрез изтегляне на данните от бордовото устройство се проверява дали всички съответни записи са направени правилно. Чрез изтегляне на данните от картата се проверява дали всички съответни записи са направени правилно. Чрез дневна разпечатка се проверява дали всички съответни записи могат да бъдат прочетени правилно.“

36)

Допълнение 11 се изменя, както следва:

а)

в точка 8.2.3 раздел CSM_49 се заменя със следното

„CSM_49

Бордовите устройства, тахографските карти и външните устройства за GNSS трябва да поддържат алгоритмите SHA-256, SHA-384 и SHA-512, специфицирани в [SHS].“;

б)

в точка 9.1.2, в раздел CSM_58 първият абзац се заменя със следното:

„CSM_58

Когато генерира нова европейска двойка основни ключове, ERCA трябва да създаде свързващ сертификат за новия европейски публичен ключ и да го подпише с предходния европейски частен ключ. Срокът на валидност на свързващия сертификат е 17 години и 3 месеца. Това е показано също на фигура 1 в раздел 9.1.7.“;

в)

в точка 9.1.4 раздел CSM_72 се заменя със следното

„CSM_72

За всяко бордово устройство трябва да бъдат генерирани две уникални двойки ключове ECC с обозначения съответно VU_MA и VU_Sign. Тази задача се изпълнява от производителите на бордови устройства. Когато бъде генерирана двойка ключове за бордово устройство, генериралата ключовете страна трябва да изпрати публичния ключ на своя MSCA, за да получи съответен сертификат за бордовото устройство, подписан от MSCA. Частният ключ трябва да се използва само от бордовото устройство.“;

г)

точка 9.1.5 се изменя, както следва

раздел CSM_83 се заменя със следното:

„CSM_83

За всяка тахографска карта трябва да бъде генерирана една уникална двойка ключове ECC, обозначена като Card_MA. Допълнително трябва да бъде генерирана втора уникална двойка ключове ECC, обозначена като Card_Sign, за всяка карта на водач и всяка карта за монтаж и настройки. Тази задача може да бъде изпълнявана от производителите на карти или от персонализаторите на карти. Когато бъде генерирана двойка ключове за карта, генериралата ключовете страна трябва да изпрати публичния ключ на своя MSCA, за да получи съответен сертификат за картата, подписан от MSCA. Частният ключ трябва да се използва само от тахографската карта.“;

ii)

раздел CSM_88 се заменя със следното:

„CSM_88

Срокът на валидност на сертификат Card_MA е, както следва:

—	за карти на водач: 5 години

—	за карти на превозвач: 5 години

—	за контролни карти: 2 години

—	за карти за монтаж и настройки: 1 година“;

iii)

в раздел CSM_91 се добавя следният текст:

„—

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

Забележка към последното тире: Например през първите три месеца от срока на действие на сертификат на ERCA(3) (вж. фигура 1) посочените карти трябва да съдържат сертификата на ERCA(1). Това е необходимо, за да се гарантира, че картите могат да се използват за изтегляне на данни от бордови устройства със сертификат на ERCA(1), чийто обичаен 15-годишен срок на експлоатация и допълнителният 3-месечен срок за изтегляне на данни изтичат през тези месеци; вж. изискването в приложение IВ, подточка 13, последното тире.“;

д)

точка 9.1.6 се изменя, както следва

раздел CSM_93 се заменя със следното:

„CSM_93

За всяко външно устройство за GNSS трябва да бъде генерирана една уникална двойка ключове ECC, обозначена като EGF_MA. Тази задача се изпълнява от производителите на външни устройства за GNSS. Когато бъде генерирана двойка ключове EGF_MA, генериралата ключовете страна трябва да изпрати публичния ключ на своя MSCA, за да получи съответен сертификат за EGF_MA, подписан от MSCA. Частният ключ се използва само от външното устройство за GNSS.“;

ii)

раздел CSM_95 се заменя със следното:

„CSM_95

Всяко външно устройство за GNSS трябва да използва своята двойка ключове EGF_MA, състояща се от частен ключ EGF_MA.SK и публичен ключ EGF_MA.PK, изключително и само за взаимно удостоверяване на автентичността и договаряне на сесийни ключове с бордови устройства, както е посочено в раздел 11.4 от настоящото допълнение.“;

е)

точка 9.1.7 се изменя, както следва

фигура 1 се заменя със следното:

„Фигура 1

Издаване и използване на различни поколения основни сертификати на ERCA (ERCA root certificates), свързващи сертификати на ERCA (ERCA link certificates), сертификати на MSCA (MSCA certificates) и сертификати на оборудване (equipment certificates)

Текст на изображението “;

ii)

забележка 6 към фигура 1 се заменя със следното:

„6.	За да се пести място, разликата между сроковете на валидност на сертификатите Card_MA и Card_Sign е показана само за първото поколение.“;

ж)

точка 9.2.1.1 се изменя, както следва:

в раздел CSM_106 първото тире се заменя със следното:

„—	За 128-битови главни ключове на датчици за движение: CV = ‘B6 44 2C 45 0E F8 D3 62 0B 7A 8A 97 91 E4 5D 83’“;

ii)

в раздел CSM_107 първият абзац се заменя със следното:

„Всеки производител на датчици за движение генерира за всеки датчик за движение случаен и уникален ключ за сдвояване KP и изпраща всеки ключ за сдвояване до своя сертифициращ орган на държавата членка (MSCA). MSCA криптира всеки ключ за сдвояване поотделно с главния ключ на датчика за движение KM и връща криптирания ключ на производителя на датчика за движение. За всеки криптиран ключ MSCA уведомява производителя на датчика за движение за номера на версията на съответния KM.“;

iii)

раздел CSM_108 се заменя със следното:

„CSM_108

Всеки производител на датчици за движение генерира уникален сериен номер за всеки датчик за движение и изпраща всички серийни номера до своя сертифициращ орган на държавата членка (MSCA). MSCA криптира всеки сериен номер поотделно с идентификационния ключ KID и връща криптирания сериен номер на производителя на датчика за движение. За всеки криптиран сериен номер MSCA уведомява производителя на датчика за движение за номера на версията на съответния KID.“;

з)

точка 9.2.2.1 се изменя, както следва:

раздел CSM_123 се заменя със следното:

„CSM_123

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

Забележка:

—	Серийният номер на бордовото устройство трябва да е същият като елемента vuSerialNumber от VuIdentification, вж. допълнение 1, и указанието за титуляря на сертификата (Certificate Holder Reference) в сертификатите на бордовото устройство.

—

Серийният номер на бордовото устройство може още да не е известен към момента, когато производителят на бордовото устройство подава искане за специфичните за бордово устройство ключове за DSRC. В този случай вместо него производителят на бордовото устройство трябва да изпрати уникалния идентификатор на подаденото от него искане за сертификатите на бордовото устройство; вж. CSM_153. Съответно идентификаторът на искането за сертификат трябва да е същият като указанието за титуляря на сертификата (Certificate Holder Reference) в сертификатите на бордовото устройство.“;

ii)	в раздел CSM_124 изискването за информация в стъпка 2 се заменя със следното: „info = сериен номер на бордовото устройство или идентификатор на искането за сертификат, както е специфициран в CSM_123“;

iii)

раздел CSM_128 се заменя със следното:

„CSM_128

Съответният MSCA трябва да съхранява архивни записи за всички специфични за бордово устройство ключове за DSRC, които е генерирал, техния номер на версия и серийния номер на бордовото устройство или идентификатора на искането за сертификат, който е използвал за тяхното създаване.“;

и)

в точка 9.3.1, в раздел CSM_135 първият абзац се заменя със следното:

„За кодиране на обекти от данни в сертификатите трябва да бъдат използвани разграничените правила за кодиране (DER) съгласно [ISO 8825-1]. Пълното кодиране на сертификата, в т.ч. всички байтове за таг и дължина, е показано в таблица 4.“;

й)

в точка 9.3.2.3 раздел CSM_141 се заменя със следното:

„CSM_141

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

к)

в точка 9.3.2.5, в раздел CSM_146 се добавя следният абзац:

„Забележка: При сертификат на карта стойността на CHR трябва да бъде равна на стойността на cardExtendedSerialNumber в EF_ICC; вж. допълнение 2. При сертификат на EGF стойността на CHR трябва да бъде равна на стойността на sensorGNSSSerialNumber в EF_ICC; вж. допълнение 14. При сертификат на бордово устройство стойността на CHR трябва да бъде равна на елемента vuSerialNumber от VuIdentification, вж. допълнение 1, освен ако към момента, когато подава искане за сертификат, производителят не знае специфичния за него сериен номер.“;

л)

в точка 9.3.2.6 раздел CSM_148 се заменя със следното:

„CSM_148

Датата на влизане в сила на сертификата показва началната дата и час на срока на валидност на сертификата.“;

м)

точка 9.3.3 се изменя, както следва:

i)	в раздел CSM_151 първият абзац се заменя със следното: „При поискване на сертификат MSCA трябва да изпрати на ERCA следните данни:“;

ii)

раздел CSM_153 се заменя със следното:

„CSM_153

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

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

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

Производителят гарантира, че тези данни са правилни и че полученият от MSCA сертификат е вложен в оборудването, за което е предназначен.“;

н)

точка 10.2.1 се изменя, както следва:

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

„За проверяване на веригата на сертифициране на тахографска карта бордовите устройства трябва да използват протокола, описан във фигура 4. За всеки сертификат, който чете от картата, бордовото устройство трябва да провери дали полето за оторизация на титуляра на картата (Certificate Holder Authorisation — CHA) е правилно:

—	Полето CHA в сертификата на картата трябва да указва сертификат на карта за взаимно удостоверяване на автентичността (вж. допълнение 1, тип данни EquipmentType);

—	CHA в сертификат Card.CA трябва да указва MSCA;

—	CHA в сертификат Card.Link трябва да указва ERCA.“;

ii)	в раздел CSM_159 се добавя следното изречение: „Въпреки че съхранението на всички други видове сертификати не е задължително, бордовото устройство задължително съхранява нов свързващ сертификат, представен от картата.“;

о)

точка 10.2.2 се изменя, както следва:

в раздел CSM_161 текстът преди фигура 5 се заменя със следното:

„За проверяване на веригата на сертифициране на бордово устройство тахографските карти трябва да използват протокола, описан във фигура 5. За всеки сертификат, представен от бордовото устройство, картата трябва да провери дали полето за оторизация на титуляра на картата (Card Holder Authorisation — CHA) е правилно:

—	CHA в сертификат VU.Link трябва да указва ERCA.

—	CHA в сертификат VU.CA трябва да указва MSCA.

—	Полето CHA в сертификата на бордовото устройство трябва да указва сертификат на бордово устройство за взаимно удостоверяване на автентичността (вж. допълнение 1, тип данни EquipmentType).“;

ii)

раздел CSM_165 се заменя със следното:

„CSM_165

Ако командата MSE: Set AT бъде изпълнена успешно, картата трябва да зададе посочения VU.PK за последваща употреба при удостоверяване на автентичността на бордовото устройство и временно да съхрани Comp(VU.PKeph). Ако бъдат изпратени две или повече успешни команди MSE: Set AT, преди да е направено договаряне на сесиен ключ, картата трябва да съхрани само последното получено Comp(VU.PKeph). След успешна команда GENERAL AUTHENTICATE картата трябва да инициализира Comp(VU.PKeph).“;

п)

точка 10.3 се изменя, както следва:

i)	в раздел CSM_170 първият абзац се заменя със следното: „Непосредствено след изпратеното от картата случайно число бордовото устройство включва в подписа указанието за титуляря на сертификата, взето от сертификата на картата.“;

ii)	в раздел CSM_171 фигура 6 се заменя със следното: „Фигура 6 Протокол за удостоверяване на автентичността на бордово устройство “;

iii)

раздел CSM_174 се заменя със следното:

„CSM_174

При получаване на подписа на бордовото устройство в команда EXTERNAL AUTHENTICATE картата трябва да изпълни следните операции:

—	Да изчисли удостоверяващия автентичността маркер (authentication token) чрез конкатенация на Card.CHR, случайно число от картата rcard и идентификатора на краткотрайния публичен ключ на бордовото устройство Comp(VU.PKeph),

—	Да провери подписа на бордовото устройство, като използва алгоритъма ECDSA и алгоритъма за хеширане, съответстващ на размера на ключовете в двойката ключове VU_MA на бордовото устройство, както е специфицирано в CSM_50, в комбинация с VU.PK и изчисления удостоверяващ автентичността маркер.“;

р)

в точка 10.4 раздел CSM_176 се изменя, както следва:

подточка 2 се заменя със следното:

„2.

Бордовото устройство изпраща на картата публичната точка VU.PKeph от своята двойка краткотрайни ключове. Публичната точка трябва да се преобразува в октетен низ, както е специфицирано в [TR-03111]. Трябва да се използва некомпресираният формат за кодиране. Както е изяснено в CSM_164, бордовото устройство е генерирало тази двойка краткотрайни ключове преди проверката на неговата верига на сертифициране. Бордовото устройство е изпратило до картата идентификатора на краткотрайния публичен ключ Comp(VU.PKeph) и картата го е съхранила.“;

ii)

подточка 6 се заменя със следното:

„6.

Използвайки KMAC, картата изчислява удостоверяващ автентичността маркер върху кратковременния публичен ключ на бордовото устройство: TPICC = CMAC(KMAC, VU.PKeph). Публичната точка трябва да бъде в използвания от бордовото устройство формат (вж. подточка 2 по-горе). Картата изпраща на бордовото устройство NPICC и TPICC.“;

с)

в точка 10.5.2 раздел CSM_191 се заменя със следното:

„CSM_191

Всеки обект от данни, който ще се криптира, трябва да бъде запълнен в съответствие с [ISO 7816-4], като се използва индикатор за запълващо съдържание ‘01’. При изчисляването на MAC всеки обект от данни в APDU също трябва да бъде запълнен в съответствие с [ISO 7816-4].

Забележка: Запълването при защитен обмен на съобщения винаги се прави чрез слоя за защитен обмен на съобщения, а не чрез алгоритмите CMAC или CBC.

Обобщение и примери

Командната APDU с приложен защитен обмен на съобщения има следната структура в зависимост от случая за съответната незащитена команда (DO означава обект от данни):

Случай 1	:	CLA INS P1 P2 \|\| Lc' \|\| DO ‘8E’ \|\| Le
Случай 2	:	CLA INS P1 P2 \|\| Lc' \|\| DO ‘97’ \|\| DO‘8E’ \|\| Le
Случай 3 (четен INS байт)	:	CLA INS P1 P2 \|\| Lc' \|\| DO ‘81’ \|\| DO‘8E’ \|\| Le
Случай 3 (нечетен INS байт)	:	CLA INS P1 P2 \|\| Lc' \|\| DO ‘B3’ \|\| DO‘8E’ \|\| Le
Случай 4 (четен INS байт)	:	CLA INS P1 P2 \|\| Lc' \|\| DO ‘81’ \|\| DO‘97’ \|\| DO‘8E’ \|\| Le
Случай 4 (нечетен INS байт)	:	CLA INS P1 P2 \|\| Lc' \|\| DO ‘B3’ \|\| DO‘97’ \|\| DO‘8E’ \|\| Le

където Le = ‘00’ или ‘00 00’ в зависимост от това дали се използват полета с малка дължина или с увеличена дължина; вж. [ISO 7816-4].

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

Случай 1 или 3	:	DO ‘99’ \|\| DO ‘8E’ \|\| SW1SW2
Случай 2 или 4 (четен INS байт) без криптиране	:	DO ‘81’ \|\| DO ‘99’ \|\| DO ‘8E’ \|\| SW1SW2
Случай 2 или 4 (четен INS байт) с криптиране	:	DO ‘87’ \|\| DO ‘99’ \|\| DO ‘8E’ \|\| SW1SW2
Случай 2 или 4 (нечетен INS byte) без криптиране	:	DO ‘B3’ \|\| DO ‘99’ \|\| DO ‘8E’ \|\| SW1SW2

Забележка: случай 2 или 4 (нечетен INS байт) с криптиране никога не се използва при комуникацията между бордово устройство и карта.

По-долу са дадени три примера за преобразуване на APDU за команди с четен INS код. На фигура 8 е показана командна APDU с удостоверена автентичност — случай 4, на фигура 9 е показана ответна APDU с удостоверена автентичност — случай 1/случай 3, а на фигура 10 е показана криптирана ответна APDU с удостоверена автентичност — случай 2/случай 4.

Фигура 8

Преобразуване на командна APDU с удостоверена автентичност, случай 4

Фигура 9

Преобразуване на ответна APDU с удостоверена автентичност, случай 1/случай 3

Фигура 10

Преобразуване на криптирана ответна APDU с удостоверена автентичност, случай 2/случай 4

“;

т)