Този  текст  служи  само  за информационни  цели  и няма  правно  действие . Институциите  на Съюза  не носят  
отговорност  за неговото  съдържание . Автентичните  версии  на съответните  актове , включително  техните  преамбюли , 
са версиите , публикувани  в Официален  вестник  на Европейския  съюз  и налични  в EUR-Lex. Тези  официални  
текстове  са пряко  достъпни  чрез  връзките , публикувани  в настоящия  документ  
►B РЕГЛАМЕНТ  ЗА ИЗПЪЛНЕНИЕ  (ЕС) 2016/799 НА КОМИСИЯТА  
от 18 март  2016 година  
за прилагане  на Регламент  (ЕС) № 165/2014 на Европейския  парламент  и на Съвета  по 
отношение  на определянето  на изискванията  за конструкцията , изпитването , монтирането , 
експлоатацията  и ремонта  на тахографите  и техните  компоненти  
(текст  от значение  за ЕИП ) 
(ОВ L 139, 26.5.2016 г., стр. 1) 
Изменен  със: 
Официален  вестник  
№ страница  дата 
►M1 Регламент  за изпълнение  (ЕС) 2018/502 на Комисията  от 
28 февруари  2018 година  L 85  1  28.3.2018 г. 
►M2 Регламент  за изпълнение  (ЕС) 2020/158 на Комисията  от 
5 февруари  2020 година  L 34  20  6.2.2020 г. 
Поправен  със: 
►C1 Поправка , ОВ L 146, 3.6.2016 г., стр. 31 (2016/799)  
►C2 Поправка , ОВ L 27, 1.2.2017 г., стр. 169 (2016/799)  02016R0799 — BG — 26.02.2020 — 002.001 — 1
02016R0799 — BG — 26.02.2020 — 002.001 — 2  
РЕГЛАМЕНТ  ЗА ИЗПЪЛНЕНИЕ  (ЕС) 2016/799 НА 
КОМИСИЯТА  
от 18 март  2016 година  
за прилагане  на Регламент  (ЕС) № 165/2014 на Европейския  
парламент  и на Съвета  по отношение  на определянето  на 
изискванията  за конструкцията , изпитването , монтирането , 
експлоатацията  и ремонта  на тахографите  и техните  
компоненти  
(текст  от значение  за ЕИП ) 
Член  1 
Предмет  и обхват  
1. С настоящия  регламент  се определят  разпоредбите , необ­  
ходими  за еднаквото  прилагане  на следните  аспекти  относно  тахог­  
рафите : 
а) регистриране  на местоположението  на превозното  средство  в 
определени  точки  през периода  на дневното  работно  време  на 
водача ; 
б) ранно  откриване  от разстояние  на възможна  манипулация  или 
злоупотреба  с интелигентни  тахографи ; 
в) интерфейс  с интелигентни  транспортни  системи ; 
г) административните  и техническите  изисквания  за процедурите  
за одобрение  на типа  на тахографи , включително  механизмите  
за сигурност . 
▼M1 
2. Конструкцията , изпитването , монтирането , проверката , 
експлоатацията  и ремонтът  на интелигентните  тахографи  и 
техните  компоненти  трябва  да отговарят  на техническите  изиск­  
вания , формулирани  в приложение  IВ към настоящия  регламент . 
3. Що се отнася  до конструкцията , изпитването , монтирането , 
проверката , експлоатацията  и ремонта , тахографите , различни  от 
интелигентните  тахографи , трябва  да продължават  да отговарят  
на изискванията  в приложение  I към Регламент  (ЕС) № 165/2014 
или приложение  IБ към Регламент  (ЕИО ) № 3821/85 на Съвета  ( 1 ), 
според  случая . 
▼B 
4. За целите  на ранното  откриване  на измами , съгласно  член  10г 
от Директива  96/53/ЕО на Европейския  парламент  и на Съвета  
устройството  за ранно  откриване  от разстояние  трябва  да предава  
също  и данните  за масите , предоставяни  от вътрешна  бордова  
система  за претегляне . 
▼M1 
5. Настоящият  регламент  не засяга  разпоредбите  на Директива  
2014/53/ЕС на Европейския  парламент  и на Съвета  ( 2 ). 
▼B 
Член  2 
Определения  
За целите  на настоящия  регламент  се прилагат  определенията , 
формулирани  в член  2 от Регламент  (ЕС) № 165/2014.  ▼B 
( 1 ) Регламент  (ЕИО ) № 3821/85 на Съвета  от 20 декември  1985 г. относно  
контролните  уреди  за регистриране  на данните  за движението  при авто­  
мобилен  транспорт  (ОВ L 370, 31.12.1985 г., стр. 8). 
( 2 ) Директива  2014/53/ ЕС на Европейския  парламент  и на Съвета  от 
16 април  2014 г. за хармонизирането  на законодателствата  на 
държавите  членки  във връзка  с предоставянето  на пазара  на радиосъо­  
ръжения  и за отмяна  на Директива  1999/5/ЕО (ОВ L 153, 22.5.2014 г., 
стp. 62).
 02016R0799 — BG — 26.02.2020 — 002.001 — 3  
Освен  това се прилагат  и следните  определения : 
1) „цифров  тахограф “ или „тахограф  от първо  поколение “ е 
цифров  тахограф , различен  от интелигентен  тахограф ; 
2) „външно  устройство  за GNSS“ е устройство , което  съдържа  
приемника  на сигнали  от GNSS, когато  бордовото  устройство  
не е отделно  устройство , както  и други  компоненти , необ­  
ходими  за защитата  на съобщаването  на данни  за местополо­  
жението  към останалата  част на бордовото  устройство ; 
▼M1 
3) „информационно  досие “ е цялостното  досие  в електронен  вид 
или на хартия , съдържащо  цялата  информация , предоставена  от 
производителя  или негов  представител , на органа  по одобря­  
ването  на типа  за целите  на одобряването  на типа  на тахограф  
или компонент  от него , включително  сертификатите , посочени  
в член  12, параграф  3 от Регламент  (ЕС) № 165/2014, и за 
извършването  на изпитванията , определени  в приложение  IВ 
към настоящия  регламент , както  и чертежи , снимки  и други  
съответни  документи ; 
▼B 
4) „информационен  пакет “ е информационното  досие  в елек­  
тронен  вид или на хартия , придружено  от всякакви  други  доку­  
менти , добавени  от органа  по одобряването  на типа  към инфор­  
мационното  досие  по време  на осъществяване  на функциите  
му, включително , в края  на процеса  на одобряване  на типа , 
ЕО сертификата  за одобрение  на типа  на тахографа  или на 
негов  компонент ; 
5) „указател  на информационния  пакет “ е документът , в който  се 
изброява  номерирано  съдържанието  на информационния  пакет  
с посочване  на всички  части  на пакета . Форматът  на този 
документ  трябва  да разграничава  последователните  етапи  в 
процеса  на ЕО одобряване  на типа , включително  датите  на 
всякакви  преразглеждания  и актуализации  на пакета ; 
6) „устройство  за ранно  откриване  от разстояние “ е оборудването  
на бордовото  устройство , което  се използва  за извършването  на 
целенасочени  пътни  проверки ; 
▼M1 
7) „интелигентен  тахограф “, или „тахограф  от второ  поколение “, 
е цифров  тахограф , отговарящ  на изискванията  на членове  8, 9 
и 10 от Регламент  (ЕС) № 165/2014, както  и на изискванията  в 
приложение  IВ към настоящия  регламент ; 
8) „компонент  на тахограф “ е всеки  от следните  елементи : 
бордовото  устройство , датчикът  за движение , тахографският  
лист , външното  устройство  за GNSS и външното  устройство  
за ранно  откриване  от разстояние ; 
▼B 
9) „орган  по одобряването  на типа “ е органът  на държава  членка , 
компетентен  да извършва  одобряването  на типа  на тахографа  
или на компонентите  му, процедурата  по разрешаване , изда­  
ването  и, при необходимост , отнемането  на сертификати  за 
одобрение  на типа , изпълняващ  ролята  на звено  за връзка  с 
органите  по одобряването  на тип на други  държави  членки  и 
гарантиращ , че производителите  изпълняват  своите  задъл­  
жения , свързани  със съответствието  с изискванията  на 
настоящия  регламент ; 
▼M1 
10) „бордово  устройство “ е тахографът , с изключение  на датчика  
за движение  и кабелите  за връзка  с него . 
Бордовото  устройство  може  да се състои  само  от един  блок  
или от няколко  блока , разположени  на различни  места  в 
превозното  средство , и включва  блок  за обработване  на 
данните , памет  за данни , функция  за измерване  на времето , 
две устройства  за интерфейс  с карти  с памет  за водач  и ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 4  
помощник -водач , печатащо  устройство , екран , електрически  
съединители  и устройства , позволяващи  въвеждането  на 
данни  от потребителя , приемник  на сигнали  от GNSS и 
устройство  за връзка  от разстояние . 
Бордовото  устройство  може  да се състои  от следните  компо­  
ненти , за които  се изисква  одобрение  на типа : 
— бордово  устройство  като единичен  компонент  (с приемник  
на сигнали  от GNSS и устройство  за връзка  от разстояние ), 
— основен  корпус  на бордовото  устройство  (с устройство  за 
връзка  от разстояние ) и външно  устройство  за GNSS;  
— основен  корпус  на бордовото  устройство  (с приемник  на 
сигнали  от GNSS) и външно  устройство  за връзка  от 
разстояние , 
— основен  корпус  на бордовото  устройство , външен  приемник  
на сигнали  от GNSS и външно  устройство  за връзка  от 
разстояние . 
Ако бордовото  устройство  се състои  от няколко  блока , 
разположени  на различни  места  в превозното  средство , 
основен  корпус  на бордовото  устройство  е блокът , в който  са 
блокът  за обработване  на данните , паметта  за данните  и 
функцията  за измерване  на времето . 
„Бордово  устройство  (VU)“ се използва  за бордовото  
устройство  или за основния  корпус  на бордовото  устройство . 
▼B 
Член  3 
Услуги , свързани  с определянето  на местоположението  
1. Производителите  гарантират , че интелигентните  тахографи  са 
съвместими  с услугите  за определяне  на местоположението , пред­  
оставяни  от системите  на „Галилео “ и Европейската  геоста­  
ционарна  служба  за навигационно  покритие  (EGNOS).  
2. В допълнение  към системите , посочени  в параграф  1, произво­  
дителите  могат  да решат  да осигурят  съвместимост  с други  системи  
за спътникова  навигация . 
Член  4 
Процедура  за одобряване  на типа  на тахографи  и компоненти  
на тахографи  
1. Производителят  или неговият  представител  подава  заявление  
за одобряване  на типа  на тахограф  или на някой  от неговите  
компоненти  или група  от компоненти  до органите  по одобряването  
на типа , определени  от всяка  държава  членка . То се състои  от 
информационно  досие , съдържащо  информацията  за всеки  от 
въпросните  компоненти , включително , когато  е приложимо , серти­  
фикатите  за одобряване  на типа  на други  компоненти , необходими  
за окомплектуване  на тахографа , както  и всякакви  други  съответни  
документи . 
2. Държавата  членка  издава  одобрение  на типа  на всеки  
тахограф , компонент  или група  от компоненти , които  отговарят  
на административните  и техническите  изисквания , посочени  в 
член  1, параграф  2 или 3, според  случая . В такъв  случай  органът  
по одобряването  на типа  издава  на заявителя  сертификат  за 
одобрение  на типа  в съответствие  с образеца  в приложение  II 
към настоящия  регламент . 
3. Органът  по одобряването  на типа  може  да поиска  от произво­  
дителя  или неговия  представител  да предостави  допълнителна  
информация . ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 5  
4. Производителят  или неговият  представител  предоставя  на 
органите  по одобряването  на типа , както  и на организациите , 
отговарящи  за издаването  на сертификатите , посочени  в член  12, 
параграф  3 от Регламент  (ЕС) № 165/2014, толкова  на брой  
тахографи  или компоненти  на тахографи , колкото  са необходими , 
за да може  процедурата  за одобряване  на типа  да се извърши  по 
задоволителен  начин . 
5. Когато  производителят  или неговият  представител  има за цел 
одобряване  на типа  на определени  компоненти  или групи  от 
компоненти  на тахограф , той предоставя  на органите  по одобря­  
ването  на типа  другите  компоненти , чийто  тип е вече одобрен , 
както  и други  части , необходими  за конструкцията  на окомплек­  
тувания  тахограф , за да могат  въпросните  органи  да проведат  необ­  
ходимите  изпитвания . 
Член  5 
Изменения  на одобрения  на типа  
1. Производителят  или неговият  представител  информира  
незабавно  органите  по одобряването  на типа , издали  първона­  
чалното  одобрение  на типа , за всяка  промяна  в програмното  осигу­  
ряване  (софтуера ) или апаратната  част (хардуера ) на тахографа  или 
в естеството  на материалите , използвани  за производството  му, 
които  са записани  в информационния  пакет , и подава  заявление  
за изменение  на одобрението  на типа . 
2. Органите  по одобряването  на типа  могат  да преразгледат  или 
разширят  съществуващо  одобрение  на типа , или да издадат  ново  
одобрение  на типа  в зависимост  от естеството  и характеристиките  
на измененията . 
„Преразглеждане “ се прави , когато  органът  по одобряването  на 
типа  счете , че промените  в програмното  осигуряване  или в 
апаратната  част на тахографа  или в естеството  на материалите , 
използвани  за производството  му, са незначителни . В такива  
случаи  органът  по одобряването  на типа  издава  преразгледани  
документи  от информационния  пакет , като посочва  естеството  на 
направените  изменения  и датата  на одобряването  им. За спазването  
на това изискване  се счита  за достатъчна  актуализирана  версия  на 
информационния  пакет  в консолидиран  вид, придружена  от 
подробно  описание  на направените  изменения . 
„Разширение “ се прави , когато  органът  по одобряването  на типа  
счете , че промените  в програмното  осигуряване  или в апаратната  
част на тахографа  или в естеството  на материалите , използвани  за 
производството  му, са значителни . В такива  случаи  той може  да 
изиска  да бъдат  извършени  нови  изпитвания  и да информира  за 
това производителя  или представителя  му. Ако изпитванията  са 
задоволителни , органът  по одобряването  на типа  издава  прераз­  
гледан  сертификат  за одобрение  на типа , съдържащ  номер , съот­  
ветстващ  на издаденото  разширение . В сертификата  за одобрение  
на типа  се посочват  причината  за разширението  и датата  на изда­  
ването  му. 
3. В указателя  към информационния  пакет  се посочва  датата  на 
най-новото  разширение  или преразглеждане  на одобрението  на 
типа  или датата  на най-новото  консолидиране  на актуализираната  
версия  на одобрението  на типа . 
4. Когато  заявените  изменения  на тахограф  от одобрен  тип или 
на неговите  компоненти  биха  довели  до издаване  на нов 
сертификат  за сигурност  или за оперативна  съвместимост , е необ­  
ходимо  ново  одобрение  на типа . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 6  
Член  6 
Влизане  в сила  
Настоящият  регламент  влиза  в сила  на двадесетия  ден след  деня  на 
публикуването  му в Официален  вестник  на Европейския  съюз . 
Той се прилага  от 2 март  2016 г. 
▼M1 
Приложение  IВ обаче  се прилага  от 15 юни 2019 г., с изключение  
на допълнение  16, което  се прилага  от 2 март  2016 г. 
▼B 
Настоящият  регламент  е задължителен  в своята  цялост  и се прилага  
пряко  във всички  държави  членки . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 7  
ПРИЛОЖЕНИЕ  I В 
Изисквания  за конструиране , изпитване , монтаж  и контрол  
ВЪВЕДЕНИЕ  
1 ОПРЕДЕЛЕНИЯ  
2 ОБЩИ  ХАРАКТЕРИСТИКИ  И ФУНКЦИИ  НА УРЕДИТЕ  ЗА 
РЕГИСТРИРАНЕ  НА ДАННИТЕ  ЗА ДВИЖЕНИЕТО  
2.1 Общи  характеристики  
2.2 Функции  
2.3 Режими  на работа  
2.4 Сигурност  
3 КОНСТРУКТИВНИ  И ФУНКЦИОНАЛНИ  ИЗИСКВАНИЯ  ЗА 
УРЕДИТЕ  ЗА РЕГИСТРИРАНЕ  НА ДАННИТЕ  ЗА 
ДВИЖЕНИЕТО  
3.1 Следене  на вкарването  и изваждането  на картите  
3.2 Измерване  на скоростта  и разстоянието  и определяне  на 
местоположението  
3.2.1 Измерване  на изминатото  разстояние  
3.2.2 Измерване  на скоростта  
3.2.3 Определяне  на местоположението  
3.3 Измерване  на времето  
3.4 Следене  на дейностите  на водача  
3.5 Следене  на състоянието  при управление  на МПС  
3.6 Въвеждане  на данни  от водачите  
3.6.1 Въвеждане  на мястото , където  дневните  периоди  на работа  
започват  и/или завършват  
3.6.2 Ръчно  въвеждане  на дейностите , извършвани  от водача , и на 
съгласието  на водача  за интерфейса  с ITS  
3.6.3 Въвеждане  на специфични  условия  
3.7 Управление  на блокиранията , наложени  от превозвача  
3.8 Следене  на контролните  дейности  
3.9 Откриване  на събития  и/или неизправности  
3.9.1 Събитие  „вкарване  на невалидна  карта “ 
3.9.2 Събитие  „конфликт , предизвикан  от картата “ 
3.9.3 Събитие  „припокриване  във времето “ 
3.9.4 Събитие  „управление  на МПС  без съответната  карта “ 
3.9.5 Събитие  „вкарване  на карта  по време  на управление  на МПС “ 
3.9.6 Събитие  „неправилно  приключена  последна  картова  сесия “ 
3.9.7 Събитие  „превишаване  на скоростта “ 
3.9.8 Събитие  „прекъсване  на електрическото  захранване “ 
3.9.9 Събитие  „Грешка  в комуникацията  с устройството  за връзка  от 
разстояние “ 
3.9.10 Събитие  „Липса  на информация  за местоположението  от 
приемник  на сигнали  от GNSS“  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 8  
3.9.11 Събитие  „Грешка  в комуникацията  с външното  устройство  за 
GNSS“  
3.9.12 Събитие  „Грешка  в данните  за движението “ 
3.9.13 Събитие  „Противоречие  в данните  за движението  на 
превозното  средство “ 
3.9.14 Събитие  „Опит  за нарушаване  на сигурността “ 
3.9.15 Събитие  „времеви  конфликт “ 
3.9.16 Неизправност  „Карта “ 
3.9.17 Неизправност  „Уред  за регистриране  на данните  за движе­  
нието “ 
3.10 Вградени  функции  за изпробване  и самоизпробване  
3.11 Четене  от паметта  за данни  
3.12 Регистриране  и запис  в паметта  за данни  
3.12.1 Данни  за идентификация  на уредите  
3.12.1.1 Данни  за идентификация  на бордовото  устройство  
3.12.1.2 Данни  за идентификация  на датчика  за движение  
3.12.1.3 Данни  за идентификация  на Глобална  навигационна  спът­  
никова  система  
3.12.2 Ключове  и сертификати  
3.12.3 Данни  за вкарването  и изваждането  на картата  на водач  или 
картата  за монтаж  и настройки  
3.12.4 Данни  за дейностите  на водача  
▼M1 
3.12.5 Места  и местоположения , където  започват  и завършват  
дневните  периоди  на работа  и/или където  общото  време  на 
управление  на МПС  достига  3 часа 
▼B 
3.12.6 Данни  от километражния  брояч  
3.12.7 Подробни  данни  за скоростта  
3.12.8 Данни  за събитията  
3.12.9 Данни  за неизправностите  
3.12.10 Данни  за калибриране  
3.12.11 Данни  за сверяване  на часовника  
3.12.12 Данни  за контролните  дейности  
3.12.13 Данни  за блокирания , извършени  от превозвач  
3.12.14 Изтегляне  на данни  за дейностите  
3.12.15 Данни  за специфични  условия  
3.12.16 Данни  за тахографските  карти  
3.13 Четене  на тахографските  карти  
3.14 Регистриране  и запис  върху  тахографски  карти  
3.14.1 Регистриране  и запис  в тахографски  карти  от първо  поколение  
3.14.2 Регистриране  и запис  в тахографски  карти  от второ  поколение  
3.15 Извеждане  върху  дисплея  
3.15.1 Изобразяване  по подразбиране  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 9  
3.15.2 Изобразяване  на предупреждение  
3.15.3 Меню  за достъп  
3.15.4 Изобразяване  на други  данни  
3.16 Отпечатване  
3.17 Предупреждения  
3.18 Изтегляне  на данни  към външни  носители  
3.19 Връзка  от разстояние  за извършване  на целенасочени  пътни  
проверки  
3.20 Данни , прехвърляни  към допълнителни  външни  устройства  
3.21 Калибриране  
3.22 Пътна  проверка  на калибрирането  
3.23 Сверяване  на часовника  
3.24 Експлоатационни  характеристики  
3.25 Материали  
3.26 Маркировки  
4 КОНСТРУКТИВНИ  И ФУНКЦИОНАЛНИ  ИЗИСКВАНИЯ  ЗА 
ТАХОГРАФСКИТЕ  КАРТИ  
4.1 Видими  данни  
4.2 Сигурност  
4.3 Стандарти  
4.4 Спецификации  във връзка  с околната  среда  и електрически  
спецификации  
4.5 Записване  на данни  
4.5.1 Елементарни  файлове  за идентификация  на управление  на 
картата  
4.5.2 Идентификация  на картите  с интегрална (и) схема (и) 
4.5.2.1 Идентификация  на интегралната  схема  
4.5.2.2 DIR ( има го само  в тахографските  карти  от второ  поколение ) 
4.5.2.3 Информация  за отговора  на инициализиране  (ATR) (условна , 
има я само  в тахографските  карти  от второ  поколение ). 
4.5.2.4 Информация  за увеличена  дължина  (условна , има я само  в 
тахографските  карти  от второ  поколение ) 
4.5.3 Карта  на водач  
4.5.3.1 Тахографско  приложение  (достъпно  за бордови  устройства  от 
първо  и второ  поколение ) 
4.5.3.1.1 Идентификация  на приложенията  
4.5.3.1.2 Ключ  и сертификати  
4.5.3.1.3 Идентификация  на картата  
4.5.3.1.4 Идентификация  на титуляря  на картата  
4.5.3.1.5 Изтегляне  на данни  от карта  
4.5.3.1.6 Информация  за свидетелството  за управление  
4.5.3.1.7 Данни  за събития  
4.5.3.1.8 Данни  за неизправностите  
4.5.3.1.9 Данни  за дейностите  на водача  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 10  
4.5.3.1.10 Данни  за използваното  превозно  средство  
4.5.3.1.11 Места , където  дневните  периоди  на работа  започват  и/или 
завършват  
4.5.3.1.12 Данни  за картовата  сесия  
4.5.3.1.13 Данни  за контролните  дейности  
4.5.3.1.14 Данни  за специфични  условия  
4.5.3.2 Тахографско  приложение  от поколение  2 (не е достъпно  за 
бордово  устройство  от първо  поколение ) 
4.5.3.2.1 Идентификация  на приложенията  
4.5.3.2.2 Ключове  и сертификати  
4.5.3.2.3 Идентификация  на картата  
4.5.3.2.4 Идентификация  на титуляря  на картата  
4.5.3.2.5 Изтегляне  на данни  от карта  
4.5.3.2.6 Информация  за свидетелството  за управление  
4.5.3.2.7 Данни  за събития  
4.5.3.2.8 Данни  за неизправностите  
4.5.3.2.9 Данни  за дейностите  на водача  
4.5.3.2.10 Данни  за използваното  превозно  средство  
4.5.3.2.11 Места  и местоположения , където  дневните  периоди  на работа  
започват  и/или завършват  
4.5.3.2.12 Данни  за картовата  сесия  
4.5.3.2.13 Данни  за контролните  дейности  
4.5.3.2.14 Данни  за специфични  условия  
4.5.3.2.15 Данни  за използваните  бордови  устройства  
▼M1 
4.5.3.2.16 Данни  за местата  за три часа общо  управление  на МПС  
▼B 
4.5.4 Карта  за монтаж  и настройки  
4.5.4.1 Тахографско  приложение  (достъпно  за бордови  устройства  от 
първо  и второ  поколение ) 
4.5.4.1.1 Идентификация  на приложенията  
4.5.4.1.2 Ключове  и сертификати  
4.5.4.1.3 Идентификация  на картата  
4.5.4.1.4 Идентификация  на титуляря  на картата  
4.5.4.1.5 Изтегляне  на данни  от карта  
4.5.4.1.6 Данни  за калибрирането  и сверяването  на часовника  
4.5.4.1.7 Данни  за събития  и за неизправности  
4.5.4.1.8 Данни  за дейностите  на водача  
4.5.4.1.9 Данни  за използваното  превозно  средство  
4.5.4.1.10 Данни  относно  края  и/или началото  на дневните  периоди  на 
работа  
4.5.4.1.11 Данни  за картовата  сесия  
4.5.4.1.12 Данни  за контролните  дейности  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 11  
4.5.4.1.13 Данни  за специфични  условия  
4.5.4.2 Тахографско  приложение  от поколение  2 (не е достъпно  за 
бордово  устройство  от първо  поколение ) 
4.5.4.2.1 Идентификация  на приложенията  
4.5.4.2.2 Ключове  и сертификати  
4.5.4.2.3 Идентификация  на картата  
4.5.4.2.4 Идентификация  на титуляря  на картата  
4.5.4.2.5 Изтегляне  на данни  от карта  
4.5.4.2.6 Данни  за калибрирането  и сверяването  на часовника  
4.5.4.2.7 Данни  за събития  и за неизправности  
4.5.4.2.8 Данни  за дейностите  на водача  
4.5.4.2.9 Данни  за използваното  превозно  средство  
4.5.4.2.10 Данни  за края  и/или началото  на дневните  периоди  на работа  
4.5.4.2.11 Данни  за картовата  сесия  
4.5.4.2.12 Данни  за контролните  дейности  
4.5.4.2.13 Данни  за използваните  бордови  устройства  
▼M1 
4.5.4.2.14 Данни  за местата  за три часа общо  управление  на МПС  
▼B 
4.5.4.2.15 Данни  за специфични  условия  
4.5.5 Контролна  карта  
4.5.5.1 Тахографско  приложение  (достъпно  за бордови  устройства  от 
първо  и второ  поколение ) 
4.5.5.1.1 Идентификация  на приложенията  
4.5.5.1.2 Ключове  и сертификати  
4.5.5.1.3 Идентификация  на картата  
4.5.5.1.4 Идентификация  на титуляря  на картата  
4.5.5.1.5 Данни  за контролните  дейности  
4.5.5.2 Тахографско  приложение  от поколение  2 (не е достъпно  за 
бордово  устройство  от първо  поколение ) 
4.5.5.2.1 Идентификация  на приложенията  
4.5.5.2.2 Ключове  и сертификати  
4.5.5.2.3 Идентификация  на картата  
4.5.5.2.4 Идентифициране  на титуляря  на картата  
4.5.5.2.5 Данни  за контролните  дейности  
4.5.6 Карта  на превозвач  
4.5.6.1 Тахографско  приложение  (достъпно  за бордови  устройства  от 
първо  и второ  поколение ) 
4.5.6.1.1 Идентифициране  на приложенията  
4.5.6.1.2 Ключове  и сертификати  
4.5.6.1.3 Идентифициране  на картата  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 12  
4.5.6.1.4 Идентифициране  на титуляря  на картата  
4.5.6.1.5 Данни  относно  дейността  на предприятието  
4.5.6.2 Тахографско  приложение  от поколение  2 (не е достъпно  за 
бордово  устройство  от първо  поколение ) 
4.5.6.2.1 Идентифициране  на приложенията  
4.5.6.2.2 Ключове  и сертификати  
4.5.6.2.3 Идентифициране  на картата  
4.5.6.2.4 Идентифициране  на титуляря  на картата  
4.5.6.2.5 Данни  за дейността  на предприятието  
5 МОНТИРАНЕ  НА УРЕДИ  ЗА РЕГИСТРИРАНЕ  НА 
ДАННИТЕ  ЗА ДВИЖЕНИЕТО  
5.1 Монтиране  
5.2 Монтажна  табелка  
5.3 Пломбиране  
6 ПРОВЕРКИ , ИНСПЕКТИРАНЕ  И ПОПРАВКИ  
6.1 Одобряване  на монтьори , сервизи  и производители  на 
превозни  средства  
▼M1 
6.2 Проверка  на новите  или поправените  компоненти  
▼B 
6.3 Проверка  на монтирането  
6.4 Периодични  технически  прегледи  
6.5 Измерване  на грешките  
6.6 Поправки  
7 ИЗДАВАНЕ  НА КАРТИ  
8 ОДОБРЕНИЕ  НА ТИПА  НА УРЕДИТЕ  ЗА РЕГИСТРИРАНЕ  
НА ДАННИТЕ  ЗА ДВИЖЕНИЕТО  И НА ТАХОГРАФСКИТЕ  
КАРТИ  
8.1 Общи  положения  
8.2 Сертификат  за сигурност  
8.3 Сертификат  за функциониране  
8.4 Сертификат  за оперативна  съвместимост  
8.5 Сертификат  за одобрение  на типа  
8.6 Извънредна  процедура : първи  сертификати  за оперативна  
съвместимост  за уреди  за регистриране  на данните  за 
движението  и тахографски  карти  от 2-ро поколение  
ВЪВЕДЕНИЕ  
Цифровата  тахографска  система  от първо  поколение  е въведена  от 1 май 
2006 г. Тя може  да бъде  използвана  до края  на експлоатационния  ѝ срок  за 
вътрешен  транспорт . За международен  транспорт  обаче  15 години  след  
влизането  в сила  на настоящия  регламент  на Комисията  всички  превозни  
средства  трябва  да са оборудвани  с интелигентни  тахографи  от второ  поко­  
ление , съответстващи  на изискванията , въведени  с настоящия  регламент . 
Настоящото  приложение  съдържа  изискванията  за уредите  за регистриране  
на данните  за движението  и за тахографските  карти  от второ  поколение . 
Започвайки  от датата  на въвеждането  им, уредите  за регистриране  на 
данните  за движението  от второ  поколение  се монтират  в превозни  
средства , регистрирани  за първи  път, като се издават  тахографски  карти  
от второ  поколение . 
С цел да се насърчи  безпроблемното  въвеждане  на тахографската  система  
от второ  поколение , ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 13  
— тахографските  карти  от второ  поколение  трябва  да са проектирани  така, 
че да се използват  и в бордови  устройства  от първо  поколение , 
— на датата  на въвеждането  не се изисква  замяна  на валидни  тахографски  
карти  от първо  поколение . 
Това  ще позволи  на водачите  да запазят  своята  уникални  карта  на водач  и 
да я използват  и с двете  системи . 
Уредите  за регистриране  на данните  за движението  от второ  поколение  
обаче  се калибрират  само  с използване  на карти  за монтаж  и настройка  
от второ  поколение . 
В настоящото  приложение  се съдържат  всички  изисквания , свързани  с 
оперативната  съвместимост  между  тахографските  системи  от първо  и от 
второ  поколение . 
В допълнение  15 се съдържат  допълнителни  подробности  относно  управ­  
лението  на съвместното  съществуване  на двете  системи . 
Списък  на допълненията  
Доп 1: РЕЧНИК  НА ДАННИТЕ  
Доп 2: СПЕЦИФИКАЦИЯ  НА ТАХОГРАФСКИТЕ  КАРТИ  
Доп 3: ПИКТОГРАМИ  
Доп 4: РАЗПЕЧАТКИ  
Доп 5: ПОКАЗВАНЕ  
Доп 6: ПРЕДЕН  СЪЕДИНИТЕЛ  ЗА КАЛИБРИРАНЕ  И ИЗТЕГЛЯНЕ  
НА ДАННИ  
Доп 7: ПРОТОКОЛИ  ЗА ИЗТЕГЛЯНЕ  НА ДАННИ  
Доп 8: ПРОТОКОЛ  ЗА КАЛИБРИРАНЕ  
Доп 9: МИНИМАЛНО  ИЗИСКВАНИ  ИЗПИТВАНИЯ  ЗА 
ОДОБРЕНИЕ  НА ТИПА  
Доп 10: ИЗИСКВАНИЯ  ЗА СИГУРНОСТ  
Доп 11: ОБЩИ  МЕХАНИЗМИ  ЗА СИГУРНОСТ  
Доп 12: ОПРЕДЕЛЯНЕ  НА МЕСТОПОЛОЖЕНИЕТО  ВЪЗ ОСНОВА  
НА ГЛОБАЛНА  НАВИГАЦИОННА  СПЪТНИКОВА  
СИСТЕМА  (GNSS)  
Доп 13: ИНТЕРФЕЙС  С ITS  
Доп 14: ФУНКЦИЯ  ЗА ВРЪЗКА  ОТ РАЗСТОЯНИЕ  
Доп 15: МИГРАЦИЯ : УПРАВЛЕНИЕ  НА ЕДНОВРЕМЕННОТО  
СЪЩЕСТВУВАНЕ  НА РАЗЛИЧНИ  ПОКОЛЕНИЯ  
ОБОРУДВАНЕ  
Доп 16: АДАПТОР  ЗА ПРЕВОЗНИ  СРЕДСТВА  ОТ КАТЕГОРИИ  M1 
И N1 
1 ОПРЕДЕЛЕНИЯ  
В настоящото  приложение : 
а) „активиране “ означава : 
фазата , по време  на която  тахографът  става  напълно  рабо­  
тоспособен  и може  да извършва  всички  функции , вклю­  
чително  и свързаните  със сигурността , чрез използването  
на карта  за монтаж  и настройки ; 
б) „удостоверяване  на самоличността “: 
функция , предназначена  да установи  и провери  
определена  самоличност ; 
в) „автентичност “ означава : 
характеристиката  определена  информация  да произлиза  от 
страна , чиято  самоличност  може  да бъде  проверена ; 
г) „вградена  функция  за изпробване “: 
изпробвания , които  могат  да се пускат  по заявка , задей­  
ствани  от оператора  или от външна  апаратура ; ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 14  
д) „календарен  ден“ означава : 
ден, който  обхваща  времето  от 00.00 часа до 24.00 часа. 
Всички  календарни  дни са свързани  с координираната  
универсална  скала  за време  (UTC);  
е) „калибриране “ на интелигентен  тахограф  означава : 
обновяване  или потвърждаване  на записаните  в паметта  
данни  за параметрите  на превозното  средство . Пара­  
метрите  на превозното  средство  включват  параметри  за 
неговата  идентификация  (идентификационен  номер , 
регистрационен  номер  и държава  членка , извършила  
регистрацията ) и характеристиките  на превозното  
средство  (w, k, l, размер  на гумите , настройка  на ограни­  
чителя  на скоростта  (ако има), текущо  координирано  
универсално  време  (UTC), текущо  показание  на километ­  
ражния  брояч ); по време  на калибриране  на уреди  за 
регистриране  на данните  за движението , типовете  и иден­  
тификаторите  на всички  пломби , свързани  с одобрението  
на типа , също  трябва  да се записват  в паметта  за данни ; 
всяко  актуализиране  или потвърждаване  само  на коорди­  
нираното  универсално  време  се счита  за сверяване  на 
часовника , а не за калибриране , при условие  че това не 
противоречи  на изискване  409;  
калибрирането  на уреди  за регистриране  на данните  за 
движението  изисква  използването  на карта  за монтаж  и 
настройки ; 
ж) „номер  на картата “ означава : 
16-позиционен  буквено -цифров  код, който  представлява  
уникалният  идентификационен  номер  на тахографска  
карта  в определена  държава  членка . Номерът  на картата  
съдържа  индекс  за пореден  номер  (при необходимост ), 
индекс  за замяна  на картата  и индекс  за подновяване  на 
валидността  на картата . 
По този начин  всяка  карта  се идентифицира  от кода  на 
държавата  членка , която  я е издала , и от картовия  номер . 
з) „индекс  за пореден  номер  на картата “ означава : 
14-ят буквено -цифров  символ  от номера  на картата , 
използван  за различаване  на картите , издадени  на даден  
превозвач , сервиз  или контролен  орган , имащи  право  да 
използват  няколко  тахографски  карти . Превозвачът , 
сервизът  или контролният  орган  се идентифицират  едно­  
значно  чрез първите  13 символа  на картовия  номер ; 
и) „индекс  за подновяване  на валидността  на картата “ 
означава : 
16-ят буквен  или цифров  символ  от картовия  номер , който  
се увеличава  с едно  при всяко  подновяване  на валидността  
на тахографската  карта ; 
й) „индекс  за замяна  на картата “ означава : 
15-ят буквен  или цифров  символ  от картовия  номер , който  
се увеличава  с едно  при всяка  замяна  на тахографската  
карта ; 
к) „характеристичен  коефициент  на превозното  средство “ 
означава : 
цифровата  характеристика , която  посочва  стойността  на 
изходния  сигнал , излъчен  от тази част на превозното  
средство , която  го свързва  с уредите  за регистриране  на 
данните  за движението  (изходящ  вал на скоростната  кутия  
или ос), докато  превозното  средство  изминава  разстояние  
от един  километър  при стандартни  условия  на изпитване , 
както  е определено  в изискване  414. Характеристичният  
коефициент  се изразява  в импулси  на километър  (w: … 
имп./km);  
л) „карта  на превозвач “ означава : 
тахографска  карта , която  се издава  от органите  на държава  
членка  на транспортно  предприятие , което  трябва  да 
експлоатира  превозни  средства , оборудвани  с тахограф , 
и която  идентифицира  транспортното  предприятие  и 
служи  за показване , изтегляне  и разпечатване  на 
данните , съхранени  в паметта  на тахографа , достъпът  до 
които  е бил ограничен  от съответното  транспортно  пред­  
приятие ; ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 15  
м) „константа  на уредите  за регистриране  на данните  за 
движението “ означава : 
цифровата  характеристика , която  дава стойността  на 
входния  сигнал , необходим  за показване  и записване  на 
изминато  разстояние  един  километър ; тази константа  се 
изразява  в импулси  на километър  (k = … имп./km);  
н) „време  за непрекъснато  управление  на МПС “ се изчислява  
от уредите  за регистриране  на данните  за движението  
като ( 1 ): 
времето  на непрекъснато  управление  на МПС  се 
изчислява  като натрупаните  времена  на управление  на 
МПС  от даден  водач  от края  на последния  му период  
НА РАЗПОЛОЖЕНИЕ , на ПРЕКЪСВАНЕ /ПОЧИВКА  
или на НЕИЗВЕСТНА  ДЕЙНОСТ  ( 2 ) от 45 или повече  
минути  (този период  може  да е разделен  в съответствие  
с Регламент  (ЕО) № 561/2006 на Европейския  парламент  и 
на Съвета  ( 3 )). При изчисленията  се държи  сметка , ако е 
необходимо , за предишните  дейности , записани  на картата  
на водач . Когато  водачът  не е вкарвал  картата  си, изчис­  
ленията  се основават  на данните , записани  в паметта  по 
време  на текущия  период , през който  не е била  вкарвана  
никаква  карта , като се отнасят  към съответното  четящо  
устройство ; 
о) „контролна  карта “ означава : 
тахографска  карта , издадена  от органите  на държава  
членка  на национален  компетентен  контролен  орган , 
която  идентифицира  контролния  орган  и евентуално  — 
конкретния  негов  служител , и която  осигурява  достъп  до 
данните , съхранени  в паметта  на тахографа  или в картата  
на водач , и евентуално  — в картите  за монтаж  и наст­  
ройки , с цел тяхното  прочитане , разпечатване  и/или 
изтегляне . 
Тя следва  също  така да дава достъп  до функцията  за пътна  
проверка  на калибрирането  и до данните  на четеца  за 
връзка  с цел ранно  откриване  от разстояние . 
п) „общото  време  на прекъсване “ се изчислява  в уредите  за 
регистриране  на данните  за движението  като ( 1 ): 
общото  време  на прекъсване  в управлението  е сумата  от 
периодите  НА РАЗПОЛОЖЕНИЕ , на ПРЕКЪСВАНЕ / 
ПОЧИВКА  или на НЕИЗВЕСТНА  ДЕЙНОСТ  ( 2 ) от 15 
или повече  минути  на даден  водач  от края  на последния  
му период  НА РАЗПОЛОЖЕНИЕ , на ПРЕКЪСВАНЕ / 
ПОЧИВКА  или на НЕИЗВЕСТНА  ДЕЙНОСТ  ( 2 ) от 45 
или повече  минути  (този период  може  да бъде  разделен  
в съответствие  с Регламент  (ЕО) № 561/2006).  
При изчисленията  се държи  сметка , ако е необходимо , за 
предишните  дейности , записани  на картата  на водач . 
Периодите  на неизвестна  дейност  с отрицателно  
времетраене  (начало  на периода  с неизвестна  дейност  > 
края  на периода  с неизвестна  дейност ) поради  припок­  
риване  на времеви  периоди  между  два различни  уреда  за 
регистриране  на данните  за движението  не се вземат  
предвид  при изчисленията . ▼B 
( 1 ) Този  начин  на изчисляване  на времето  на непрекъснато  управление  на МПС  и на 
общото  време  на прекъсване  служи  в уредите  за регистриране  на данните  за 
движението  за изчисляване  на предупреждението  за времето  на непрекъснато  
управление  на МПС . Той не предопределя  юридическото  тълкуване  на тези 
периоди . Може  да бъдат  използвани  алтернативни  начини  за изчисляване  на 
времето  на непрекъснато  управление  на МПС  и на общото  време  на прекъсване  
в замяна  на тези определения , ако те са остарели  вследствие  на актуализиране  на 
останалото  законодателство  в дадената  област . 
( 2 ) Периодите  на НЕИЗВЕСТНА  ДЕЙНОСТ  съответстват  на периодите , през които  
картата  на водача  не е била  вкарвана  в уред  за регистриране  на данните  за 
движението  и за които  няма  извършено  ръчно  въвеждане  на дейностите  на водача . 
( 3 ) Регламент  (ЕО) № 561/2006 на Европейския  парламент  и на Съвета  от 15 март  
2006 година  за хармонизиране  на някои  разпоредби  от социалното  законода­  
телство , свързани  с автомобилния  транспорт , за изменение  на Регламенти  (ЕИО ) 
№ 3821/85 и (ЕО) № 2135/98 на Съвета  и за отмяна  на Регламент  (ЕИО ) № 3820/85 
на Съвета  (ОВ L 102, 11.4.2006 г., стр. 1).
 02016R0799 — BG — 26.02.2020 — 002.001 — 16  
Когато  водачът  не е вкарвал  картата  си, изчисленията  се 
основават  на данните , записани  в паметта  по време  на 
текущия  период , през който  не е била  вкарвана  никаква  
карта , като се отнасят  към съответното  четящо  
устройство ; 
р) „памет  за данни “ означава : 
електронно  устройство  за съхраняване  на данни , вградено  
в уредите  за регистриране  на данните  за движението ; 
с) „електронен  подпис “ означава : 
данните , прибавени  към блок  от данни , или негово  крип­  
тографско  преобразувание , което  позволява  на получателя  
на този блок  да получи  доказателство  за неговата  автен­  
тичност  и достоверност ; 
т) „изтегляне  на данни “ означава : 
копиране , заедно  с електронния  подпис , на част или на 
пълен  набор  файлове  с данни , записани  в паметта  за 
данни  на бордовото  устройство  или в паметта  на тахог­  
рафската  карта , при условие  че при този процес  не се 
изменят  или изтриват  записани  данни ; 
Производителите  на интелигентни  тахографи  за превозни  
средства  и производителите  на оборудване , конструирано  
и предназначено  за изтегляне  на файлове  с данни , трябва  
да предприемат  всички  подходящи  мерки , за да гаран­  
тират , че изтеглянето  на съответните  данни  може  да 
бъде  извършено  с минимална  загуба  на време  от страна  
на транспортните  предприятия  или водачите . 
Изтеглянето  на файла  с подробни  данни  за скоростта  на 
движение  може  да не е необходимо  за установяване  на 
съответствие  с разпоредбите  на Регламент  (ЕО) № 
561/2006, но може  да бъде  използвано  за други  цели , 
като например  разследване  на злополуки ; 
у) „карта  на водач “ означава : 
тахографска  карта , издадена  от органите  на държава  
членка  на конкретен  водач , която  идентифицира  водача  
и служи  за съхраняване  на данни  за дейността  на водача ; 
ф) „действителна  обиколка  на колелата “ означава : 
средната  стойност  от разстоянията , изминати  от всяко  от 
колелата , задвижващи  превозното  средство  (двигателните  
колела ) за времето  на едно  пълно  завъртане . Измерването  
на тези разстояния  се извършва  при стандартни  условия  
на изпитване , както  е определено  съгласно  изискване  414, 
и се изразява  във вида  „l = … mm“. Производителите  на 
превозни  средства  могат  да заменят  измерването  на тези 
разстояния  с теоретично  изчисление , при което  се взема  
предвид  разпределението  на теглото  на превозното  
средство  върху  осите  в състояние  без товар  и в 
готовност  за движение  ( 1 ). Методите  на това теоретично  
изчисление  подлежат  на одобряване  от компетентен  
орган  на държава  членка  и могат  да бъдат  приложени  
само  преди  пускането  на тахографа ; 
х) „събитие “ означава : 
ненормално  действие , отчетено  от интелигентния  
тахограф , което  може  да е резултат  от опит  за измама ; 
ц) „външно  устройство  за GNSS“ означава  
устройство , което  съдържа  приемника  на сигнали  от 
GNSS, когато  бордовото  устройство  не е отделно  
устройство , както  и други  компоненти , необходими  за 
защитата  на съобщаването  на данни  за местоположението  
към останалата  част на бордовото  устройство ; ▼B 
( 1 ) Регламент  (ЕС) № 1230/2012 на Комисията  от 12 декември  2012 година  за 
прилагане  на Регламент  (ЕО) № 661/2009 на Европейския  парламент  и на Съвета  
във връзка  с изискванията  за одобрение  на типа  по отношение  на масите  и 
размерите  на моторните  превозни  средства  и техните  ремаркета  и за изменение  
на Директива  2007/46/ЕО на Европейския  парламент  и на Съвета  (ОВ L 353, 
21.12.2012 г., стр. 31).
 02016R0799 — BG — 26.02.2020 — 002.001 — 17  
ч) „неизправност “ означава : 
ненормално  действие , открито  от интелигентния  тахограф , 
което  може  да се дължи  на нарушено  функциониране  или 
повреда  на уредите ; 
ш) „приемник  на сигнали  от GNSS“ означава : 
електронно  устройство , което  получава  и обработва  по 
цифров  път сигналите  от един  или повече  спътници  на 
Глобална  навигационна  спътникова  система  (на 
английски  — GNSS) с цел осигуряване  на информация  
за местоположението , скоростта  и времето . 
щ) „монтиране “ означава : 
монтирането  на тахограф  в превозно  средство ; 
ъ) „оперативна  съвместимост “ означава : 
способността  на системите  и съответните  стопански  
процеси  за обмен  на данни  и споделяне  на информация ; 
ю) „интерфейс “ означава : 
междусистемно  устройство , осигуряващо  средствата , чрез 
които  системите  могат  да се свържат  и да взаимодействат ; 
я) „местоположение “ означава : 
географските  координати  на превозното  средство  в даден  
момент ; 
аа) „датчик  за движение “ означава : 
частта  от тахографа , подаваща  сигнал , който  е показателен  
за скоростта  и/или изминатото  разстояние  от превозното  
средство ; 
бб) „невалидна  карта “ означава : 
карта , която  се възприема  като дефектна  или при която  
първоначалното  удостоверяване  на самоличността  е било  
неуспешно , чиято  дата за начало  на валидността  все още 
не е достигната  или за която  е изтекъл  срокът  на 
валидност ; 
вв) „отворен  стандарт “ означава : 
стандарт , който  според  описанието  в стандартен  документ  
за спецификация  се предоставя  безплатно  или срещу  
символична  такса  и който  всички  могат  да възпро­  
извеждат , разпространяват  или използват  без такса  или 
срещу  символична  такса . 
гг) „извън  обхвата “ означава : 
всички  случаи , в които  използването  на уредите  за регис­  
триране  на данните  за движението  не е необходимо  
съгласно  Регламент  (ЕО) № 561/2006;  
дд) „превишаване  на скоростта “ означава : 
всяко  превишаване  на допустимата  за съответното  
превозно  средство  скорост  за време  над 60 секунди , през 
което  измерената  скорост  на превозното  средство  
надвишава  зададената  в Директива  92/6/ЕИО  на Съвета  ( 1 ), 
както  е последно  изменена ; 
ее) „периодичен  технически  преглед “ означава : 
набор  от действия , извършвани , за да се провери  дали  
тахографът  работи  правилно , дали  неговите  настройки  
отговарят  на параметрите  на превозното  средство , както  
и дали  към тахографа  няма  прикачени  устройства  за мани­  
пулиране ; ▼B 
( 1 ) Директива  92/6/ЕИО  на Съвета  от 10 февруари  1992 г. относно  монтирането  и 
използването  на устройства  за ограничаване  на скоростта  за някои  категории  
моторни  превозни  средства  в Общността  (ОВ L 57, 2.3.1992 г., стр. 27).
 02016R0799 — BG — 26.02.2020 — 002.001 — 18  
жж) „печатащо  устройство “ означава : 
компонент  на уредите  за регистриране  на данните  за 
движението , който  осигурява  разпечатки  на записаните  в 
паметта  данни ; 
зз) „връзка  с цел ранно  откриване  от разстояние “ означава : 
комуникация  между  устройството  за връзка  с цел ранно  
откриване  от разстояние  и четеца  за връзка  с цел ранно  
откриване  от разстояние  по време  на целенасочени  пътни  
проверки  с цел дистанционно  откриване  на евентуална  
манипулация  или злоупотреба  с уреди  за регистриране  
на данните  за движението ; 
▼M1 
ии) „устройство  за връзка  от разстояние “ или „устройство  за 
ранно  откриване  от разстояние “ означава : 
оборудването  в бордовото  устройство , използвано  за 
извършването  на целенасочени  пътни  проверки ; 
▼B 
йй) „четец  за връзка  с цел ранно  откриване  от разстояние “ 
означава : 
системата , използвана  от служителите  на контролните  
органи  за извършването  на целенасочени  пътни  проверки ; 
кк) „подновяване “ означава : 
издаването  на нова  тахографска  карта , когато  срокът  на 
валидност  на съществуваща  карта  изтича  или тя не 
функционира  правилно  и е била  върната  на органа , 
който  я е издал ; подновяването  предполага  гаранцията , 
че не могат  да съществуват  едновременно  две валидни  
карти ; 
лл) „ремонт “ означава : 
всякакъв  ремонт  на датчик  за движение , на бордово  
устройство  или на кабел , който  налага  прекъсване  на 
неговото  електрическо  захранване , прекъсване  на 
връзката  с други  компоненти  на тахографа  или отваряне  
на тахографа  или бордовото  устройство ; 
мм) „замяна  на картата “ означава : 
издаването  на тахографска  карта , която  заменя  същест­  
вуваща  карта , която  е обявена  за изгубена , открадната  
или за неправилно  функционираща  и която  е била  
върната  на органа , който  я е издал . Замяната  води  
винаги  до опасността  едновременно  да съществуват  две 
валидни  карти ; 
нн) „сертифициране  по отношение  на сигурността “: 
процесът , чрез който  организация  за сертифициране  по 
единни  критерии  удостоверява , че уредите  за регис­  
триране  на данните  за движението  (или компонент  от 
тях) или изследваната  тахографска  карта  отговарят  на 
изискванията  за сигурност , формулирани  в съответните  
профили  за защита ; 
оо) „самоизпробване “ означава : 
изпробвания , извършвани  периодично  и автоматично  от 
уредите  за регистриране  на данните  за движението  с цел 
откриване  на неизправности ; 
пп) „измерване  на времето “ означава : 
непрекъснат  цифров  запис  на координираното  
универсално  време  и дата (UTC);  
▼M1 
рр) „сверяване  на часовника “ означава : 
сверяване  на текущото  време , което  може  да се извършва  
автоматично  през равни  интервали , като за еталонна  
стойност  се използва  времето , получено  от приемника  на 
сигнали  от GNSS, или при калибриране ; 
▼B 
сс) „размери  на гумите “ означава : 
указването  на размерите  на гумите  (външни  задвижващи  
колела ) в съответствие  с Директива  92/23/ЕИО  на Съве­  
та ( 1 ), както  е последно  изменена ; ▼B 
( 1 ) Директива  92/23/ЕИО  на Съвета  от 31 март  1992 година  относно  гумите  за 
моторни  превозни  средства  и техните  ремаркета , както  и тяхното  монтиране  
(ОВ L 129, 14.5.1992 г., стр. 95).
 02016R0799 — BG — 26.02.2020 — 002.001 — 19  
тт) „идентификация  на превозното  средство “ означава : 
номерата , позволяващи  идентифицирането  на превозното  
средство : регистрационният  номер  (VRN) с указване  на 
държавата  членка , извършила  регистрацията , и идентифи­  
кационният  номер  на превозното  средство  (VIN) (  1 ); 
уу) за целите  на изчисленията  в уредите  за регистриране  на 
данните  за движението  „седмица “ означава : 
период  между  00.00 часа UTC в понеделник  и 24.00 часа 
UTC в неделя ; 
фф) „карта  за монтаж  и настройки “ означава : 
тахографска  карта , която  се издава  от органите  на държава  
членка  на определен  за целта  персонал  на производител  на 
тахографи , монтьор , производител  на превозни  средства  
или сервиз , одобрени  от въпросната  държава  членка , 
чрез която  се идентифицира  титулярят  на картата  и 
която  служи  за изпитване , калибриране  и активиране  на 
тахографите  и/или за изтегляне  на данни  от тях; 
хх) „адаптер “ означава : 
устройство , което  подава  сигнал  в постоянно  съответствие  
със скоростта  на превозното  средство  и/или изминатото  
разстояние , различно  от използваното  за независимо  
откриване  на движение , и което  е: 
▼M1 
— монтирано  и се използва  само  в превозни  средства  от 
типове  M1 и N1 (както  са определени  в последното  
изменение  на приложение  II към Директива  
2007/46/ЕО на Европейския  парламент  и на Съвета  ( 2 ), 
▼B 
— монтирано  в случаите , в които  технически  не е 
възможно  монтирането  на друг  тип съществуващ  
датчик  за движение , който  вече е в съответствие  с 
разпоредбите  на настоящото  приложение  и допълнения  
1 — 15 към него , 
— монтирано  между  бордовото  устройство  и мястото , в 
което  се генерират  импулсите  за скорост /разстояние  от 
вградени  датчици  или от алтернативни  интерфейси , 
— по отношение  на бордовото  устройство  поведението  на 
адаптера  е същото , като при свързване  към бордовото  
устройство  на датчик  за движение , който  е в съот­  
ветствие  с разпоредбите  на настоящото  приложение  и 
допълнения  1 — 16 към него ; 
използването  на такъв  адаптер  в описаните  по-горе 
превозни  средства  трябва  да позволява  монтажа  и 
правилната  употреба  на бордово  устройство , което  е в 
съответствие  с всички  изисквания  на настоящото  прило­  
жение , 
при тези превозни  средства  интелигентният  тахограф  
включва  кабели , адаптер  и бордово  устройство ; ▼B 
( 1 ) Директива  76/114/ЕИО  на Съвета  от 18 декември  1975 година  за сближаването  на 
законодателствата  на държавите -членки  относно  задължителните  регистрационни  
табели  и обозначения  на моторни  превозни  средства  и техните  ремаркета , 
тяхното  разположение  и метод  на закрепване  (ОВ L 24, 30.1.1976 г., стр. 1). 
( 2 ) Директива  2007/46/ЕО на Европейския  парламент  и на Съвета  от 5 септември  
2007 година  за създаване  на рамка  за одобрение  на моторните  превозни  средства  
и техните  ремаркета , както  и на системи , компоненти  и отделни  технически  възли , 
предназначени  за такива  превозни  средства  (Рамкова  директива ) (ОВ L 263, 
9.10.2007 г., стр. 1).
 02016R0799 — BG — 26.02.2020 — 002.001 — 20  
цц) „цялост  на данните “ означава : 
точността  и непротиворечивостта  на записаните  данни , 
указани  от липсата  на каквато  и да е промяна  в данните  
между  две обновявания  на запис  от данни . Целостта  
означава , че данните  са точно  копие  на оригиналната  
версия , напр . че не са били  повредени  в процеса  на 
записване  и прочитане  от тахографската  карта  или 
специално  оборудване  или при предаване  по канал  за 
връзка ; 
чч) „неприкосновеност  на данните “ означава : 
общите  технически  мерки , взети , за да се гарантира  
правилното  прилагане  на принципите , формулирани  в 
Директива  95/46/ЕО на Европейския  парламент  и на Съве­  
та ( 1 ), както  и на формулираните  в Директива  2002/58/ЕО 
на Европейския  парламент  и на Съвета  ( 2 ); 
шш) интелигентна  тахографска  система  означава : 
уредите  за регистриране  на данните  за движението , тахог­  
рафските  карти  и наборът  от всякакво  пряко  или непряко  
взаимодействащо  с тях оборудване  по време  на тяхното  
производство , монтаж , използване , изпитване  и проверка , 
като например  карти , четец  за връзка  с цел ранно  
откриване  от разстояние  и всякакво  друго  оборудване  за 
изтегляне  на данни , анализ  на данни , калибриране , гене­  
риране , управление  или въвеждане  на защитни  елементи  и 
т.н.; 
щщ) дата на въвеждане : 
36 месеца  след  влизането  в сила  на подробните  
разпоредби , посочени  в член  11 от Регламент  (ЕС) № 
165/2014 на Европейския  парламент  и на Съвета  ( 3 ). 
Това  е датата , след която  превозни  средства , регис­  
трирани  за първи  път: 
— се оборудват  с тахограф , свързан  към услуга  за 
определяне  на местоположението  посредством  спът­  
никова  навигационна  система , 
— се оборудват , за да могат  при целенасочени  пътни  
проверки  да подават  данни  на компетентните  
контролни  органи , докато  превозното  средство  е в 
движение , 
— и могат  да бъдат  оборудвани  със стандартизирани  
интерфейси , позволяващи  регистрираните  или генери­  
раните  от тахографите  данни  да се използват  в 
работен  режим  от външно  устройство . 
ъъ) защитен  профил  означава : 
документ , който  се използва  като част от процедура  за 
сертифициране  в съответствие  с общите  критерии , в 
който  е дадена  независима  от приложението  специ­  
фикация  на изискванията  за сигурност  по отношение  на 
гарантирането  на информацията ; ▼B 
( 1 ) Директива  95/46/ЕО на Европейския  парламент  и на Съвета  от 24 октомври  1995 г. 
за защита  на физическите  лица  при обработването  на лични  данни  и за свободното  
движение  на тези данни  (ОВ L 281, 23.11.1995 г., стр. 31). 
( 2 ) Директива  2002/58/ ЕО на Европейския  парламент  и на Съвета  от 12 юли 
2002 година  относно  обработката  на лични  данни  и защита  на правото  на непри­  
косновеност  на личния  живот  в сектора  на електронните  комуникации  (Директива  
за правото  на неприкосновеност  на личния  живот  и електронни  комуникации ) 
(ОВ L 201, 31.7.2002 г., стр. 37). 
( 3 ) Регламент  (ЕС) № 165/2014 на Европейския  парламент  и на Съвета  от 4 февруари  
2014 година  относно  тахографите  в автомобилния  транспорт , за отмяна  на 
Регламент  (ЕИО ) № 3821/85 на Съвета  относно  контролните  уреди  за регистриране  
на данните  за движението  при автомобилен  транспорт  и за изменение  на Регламент  
(ЕО) № 561/2006 на Европейския  парламент  и на Съвета  за хармонизиране  на 
някои  разпоредби  от социалното  законодателство , свързани  с автомобилния  
транспорт  (ОВ L 60, 28.2.2014 г., стр. 1).
 02016R0799 — BG — 26.02.2020 — 002.001 — 21  
юю) точност  на GNSS:  
в контекста  на регистриране  с тахографи  на местополо­  
жението  от Глобална  навигационна  спътникова  система  
(GNSS) означава  стойността  на фактора  на намаляване  
на точността  при определяне  на местоположението  в 
хоризонталната  равнина  (HDOP), изчислявана  като мини­  
малните  стойности  на HDOP, натрупани  на наличните  
системи  GNSS;  
▼M1 
яя) „общо  време  на управление “ означава : 
стойност , представляваща  общо  натрупания  брой  минути  
управление  на дадено  превозно  средство . 
Стойността  на общото  време  на управление  е непре­  
къснато  отброяваната  стойност  на всички  минути , които  
функцията  за следене  на дейностите , извършвани  от 
водача , в уредите  за регистриране  на данните  за 
движението  отчита  като „УПРАВЛЕНИЕ “, и се използва  
само  за да се задейства  регистриране  на местополо­  
жението  на превозното  средство  всеки  път, когато  
общото  време  на управление  достигне  кратно  число  на 
три часа. Отброяването  с натрупване  започва  с активи­  
рането  на уреда  за регистриране  на данните  за движе­  
нието . То не се влияе  от други  условия , като местопо­  
ложение  извън  обсег  или пътуване  с ферибот /влак . 
Не се предвижда  показване , разпечатване  или извличане  
на стойността  на общото  време  на управление . 
▼B 
2 ОБЩИ  ХАРАКТЕРИСТИКИ  И ФУНКЦИИ  НА УРЕДИТЕ  ЗА 
РЕГИСТРИРАНЕ  НА ДАННИТЕ  ЗА ДВИЖЕНИЕТО  
2.1 Общи  характеристики  
Функцията  на уредите  за регистриране  на данните  за 
движението  е да се записва , съхранява , изобразява , отпечатва  
и да се предоставят  данни  относно  дейностите  на водача . 
Всяко  превозно  средство , оборудвано  с уреди  за регистриране  
на данните  за движението  съгласно  разпоредбите  на настоящото  
приложение , трябва  да има скоростомер  и километражен  брояч . 
Тези  функции  може  да бъдат  включени  в уредите  за регис­  
триране  на данните  за движението . 
01) уредите  за регистриране  на данните  за движението  
включват  кабели , датчик  за движение  и бордово  
устройство . 
02) Интерфейсът  между  датчиците  за движение  и бордовите  
устройства  трябва  да са в съответствие  с изискванията , 
специфицирани  в допълнение  11. 
03) Бордовото  устройство  трябва  да има връзка  с глобална  
навигационна  спътникова  система (и), както  е посочено  в 
допълнение  12. 
04) Бордовото  устройство  трябва  да комуникира  с четците  за 
връзка  с цел ранно  откриване  от разстояние , както  е 
специфицирано  в допълнение  14. 
05) Бордовото  устройство  може  да включва  интерфейс  с ITS, 
който  е специфициран  в допълнение  13. 
Уредите  за регистриране  на данните  за движението  могат  
да имат  връзка  с други  устройства  чрез допълнителни  
интерфейси  и/или посредством  незадължителния  
интерфейс  с ITS.  
06) Всяко  вмъкване  или свързване  на функция  или устрой­  
ство(а), одобрено (и) или не, във или към уреди  за регис­  
триране  на данните  за движението , не трябва  да пред­  
извиква  смущения  или да бъде  в състояние  да смущава  
правилната  и сигурна  работа  на уредите  за регистриране  
на данните  за движението , или да бъде  в противоречие  с 
разпоредбите  на настоящия  регламент . 
Потребителите  на уредите  за регистриране  на данните  за 
движението  указват  своята  самоличност  посредством  
тахографски  карти . 
07) Уредите  за регистриране  на данните  за движението  дават  
избирателни  права  за достъп  до данните  и функциите  
според  типа  и/или самоличността  на потребителя . 
Уредите  за регистриране  на данните  за движението  записват  и 
съхраняват  данни  в своята  памет , в устройството  за кому­  
никация  от разстояние  и в тахографски  карти . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 22  
Това  се извършва  в съответствие  с Директива  95/46/ЕО от 
24 октомври  1995 г. за защита  на физическите  лица  при обра­  
ботването  на лични  данни  и за свободното  движение  на тези 
данни  ( 1 ), с Директива  2002/58/ЕО от 12 юли 2002 г. относно  
обработката  на лични  данни  и защита  на правото  на неприкос­  
новеност  на личния  живот  в сектора  на електронните  комуни­  
кации  ( 2 ) и в съответствие  с член  7 от Регламент  (ЕС) № 
165/2014.  
2.2 Функции  
08) Уредите  за регистриране  на данните  за движението  
трябва  да осигуряват  следните  функции : 
— следене  на поставянията  и изважданията  на картите , 
— измерване  на скорост , разстояние  и определяне  на 
местоположение , 
— измерване  на времето , 
— следене  на дейностите , извършвани  от водача , 
— следене  на състоянието  при управление  на МПС , 
— ръчно  въвеждане  на данни  от водача : 
— въвеждане  на местоположението  в началото  и/или 
в края  на дневните  периоди  на работа , 
— ръчно  въвеждане  на дейностите  на водача , 
— въвеждане  на особени  условия , 
— управление  на блокировките , наложени  от превозвача , 
— следене  на контролните  дейности , 
— откриване  на събития  и/или на неизправности , 
— вградени  функции  за изпробване  и самоизпробване , 
— четене  на данни  от паметта , 
— записване  и съхраняване  на данните  в паметта , 
— четене  от тахографските  карти , 
— записване  и съхраняване  на данните  в тахографските  
карти , 
— изобразяване  на данните , 
— отпечатване , 
— предупреждаване , 
— прехвърляне  на данни  към външни  носители , 
— връзка  от разстояние  за извършване  на целенасочени  
пътни  проверки , 
— данни , прехвърляни  към допълнителни  устройства , 
— калибриране , 
— пътна  проверка  на калибрирането , 
— сверяване  на часовника . 
2.3 Режими  на работа  
09) Уредите  за регистриране  на данните  за движението  
трябва  да осигуряват  следните  четири  режима  на работа : 
— работен  режим , 
— контролен  режим , 
— режим  на калибриране , 
— режим  „превозвач “. 
10) Уредите  за регистриране  на данните  за движението  
трябва  да превключват  към следните  режими  на работа  
според  валидната  тахографска  карта , вкарана  в интер­  
фейсното  устройство  за карта : За определянето  на 
режима  на работа , поколението  на тахографската  карта  
е без значение , при условие  че вкараната  карта  е 
валидна . Една  карта  за монтаж  и настройки  от първо  
поколение  винаги  се счита  за невалидна , когато  се 
вкара  в бордово  устройство  от второ  поколение . ▼B 
( 1 ) ОВ L 281, 23.11.1995 г., стр. 31. 
( 2 ) ОВ L 201, 31.7.2002 г., стр. 37
 02016R0799 — BG — 26.02.2020 — 002.001 — 23  
Режим  на работа  Процеп  за карта  на водач  
Няма  карта  Карта  на водач  Контролна  карта  Карта  за монтаж  
и настройки  Карта  на 
превозвач
 Процеп  за карта  на втория  водач Няма  карта  Работен  Работен  Контролен  Калибриране  Предприятие  
карта  на водач  Работен  Работен  Контролен  Калибриране  Предприятие  
Контролна  
карта  Контролен  Контролен  Контролен  (*) Работен  Работен  
Карта  за 
монтаж  и 
настройки  Калибриране  Калибриране  Работен  Калибрира­  
не (*) Работен  
Карта  на 
превозвач  „Предприятие “ „Предприятие “ Работен  Работен  „ Предпри­  
ятие“ (*)  
(*) В тези ситуации  уредите  за регистриране  на данните  за движението  трябва  да използват  само  тахографската  карта , 
поставена  в процепа  за карта  на водач . 
11) Уредите  за регистриране  на данните  за движението  
трябва  да отхвърлят  вкарани  невалидни  карти , като 
обаче  позволяват  изобразяването , отпечатването  и изтег­  
лянето  на данни  от карта  с изтекъл  срок . 
12) Всички  функции , изброени  в 2.2, трябва  да работят  при 
всички  режими  на работа , с изключение  на: 
— функцията  за калибриране , която  е достъпна  само  в 
режима  на калибриране , 
— функцията  за пътна  проверка  на калибрирането , която  
е достъпна  само  в контролния  режим , 
— функцията  за управление  на блокиранията , наложени  
от превозвача , която  е достъпна  само  в режим  „пре­  
возвач “, 
— функцията  за следене  на контролните  дейности , която  
работи  само  в контролния  режим , 
— функцията  за изтегляне  на данни  не е достъпна  в 
работен  режим  (освен  в случаите , предвидени  в 
изискване  193) с изключение  на изтеглянето  на 
данни  от карта  на водач , когато  в бордовото  
устройство  не е вкарана  друга  карта . 
13) Уредите  за регистриране  на данните  за движението  могат  
да подават  всякаква  информация  към дисплей , печатащо  
устройство  или външни  интерфейси , със следните  изклю­  
чения : 
— в работен  режим , при който  всяка  идентификация  на 
самоличност  (фамилно  име и лично (и) име(на)), което  
не отговаря  на вкараната  тахографска  карта , се 
маскира , както  и всеки  номер  на карта , който  не 
отговаря  на вкараната  тахографска  карта , се маскира  
частично  (маскира  се всеки  нечетен  символ  отляво  
надясно ), 
— в режим  „превозвач “ данните  за водача  (изисквания  
102, 105 и 108) могат  да бъдат  извлечени  само  за 
периодите , за които  отсъства  блокиране , или които  
не са блокирани  от друг  превозвач  (определяно  от 
първите  13 цифри  от номера  на картата  на превозвач ), 
— когато  в уредите  за регистриране  на данните  за 
движението  не е вкарана  карта , данните  за водача  
могат  да бъдат  извличани  само  за същия  ден и за 8- 
те предшестващи  календарни  дни, 
— лични  данни , произхождащи  от бордовото  
устройство , не трябва  да бъдат  подавани  навън  
посредством  интерфейса  с ITS на бордовото  
устройство , освен  ако не бъде  проверено  че има 
съгласие  на водача , за когото  се отнасят  данните , ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 24  
— бордовите  устройства  обикновено  са със срок  на 
валидност  на действията  от 15 години , считано  от 
датата , на която  влизат  в сила  сертификатите  на 
бордовото  устройство , но устройствата  могат  да се 
използват  още 3 месеца  само  за изтегляне  на данни . 
▼B 
2.4 Сигурност  
▼M1 
Сигурността  на системата  цели  да предпазва  паметта  така, че да 
възпрепятства  неупълномощен  достъп  до нея или манипулиране  
на данните  и да открива  опити  за това, да защитава  целостта  и 
автентичността  на данните , които  се обменят  между  датчика  за 
движение  и бордовото  устройство , между  уредите  за регис­  
триране  на данните  за движението  и тахографските  карти , а 
също  така между  бордовото  устройство  и външното  устройство  
за GNSS, ако има такова , както  и да защитава  поверителността , 
целостта  и автентичността  на данните , обменяни  чрез връзката  
за ранно  откриване  от разстояние  с контролна  цел, и да 
проверява  целостта  и автентичността  на изтеглените  данни . 
▼B 
14) С цел постигане  на сигурност  на системата , следните  
компоненти  трябва  да отговарят  на изискванията  за 
сигурност , специфицирани  в техните  профили  за 
защита , както  се изисква  в допълнение  10: 
— бордово  устройство , 
— тахографска  карта , 
— датчик  за движение , 
— външно  устройство  за GNSS ( този профил  е 
необходим  и приложим  само  за варианта  с външно  
устройство  за GNSS).  
3 КОНСТРУКТИВНИ  И ФУНКЦИОНАЛНИ  ИЗИСКВАНИЯ  ЗА 
УРЕДИТЕ  ЗА РЕГИСТРИРАНЕ  НА ДАННИТЕ  ЗА 
ДВИЖЕНИЕТО  
3.1 Следене  на вкарването  и изваждането  на картите  
15) Уредите  за регистриране  на данните  за движението  
трябва  да следят  интерфейсните  устройства  за карта , за 
да откриват  вкарванията  и на изважданията  на карта . 
16) При вкарването  на карта , уредите  за регистриране  на 
данните  за движението  трябва  да разпознават  дали  
вкараната  карта  е валидна  тахографска  карта  и ако да, 
да разпознават  типа  и поколението  ѝ. 
Ако в уредите  за регистриране  на данните  за движението  
вече е била  вкарана  карта  със същия  номер  на карта  и с 
по-голям  индекс  за подновяване  на валидността  на 
картата , картата  трябва  да бъде  обявена  за невалидна . 
Ако в уредите  за регистриране  на данните  за движението  
вече е била  вкарана  карта  със същите  номер  на карта  и 
индекс  за подновяване  на валидността  на картата , но с 
по-голям  индекс  за замяна  на картата , картата  трябва  да 
бъде  обявена  за невалидна . 
17) Тахографските  карти  от първо  поколение  трябва  да се 
считат  за невалидни  от уредите  за регистриране  на 
данните  за движението , веднъж  щом  възможността  за 
използване  на тахографски  карти  от първо  поколение  е 
премахната  от страна  на сервиза , в съответствие  с 
допълнение  15 (MIG003)  
18) Карти  за монтаж  и настройка  от първо  поколение , които  
се вкарват  в уреди  за регистриране  на данните  за 
движението  от второ  поколение , трябва  да се считат  за 
невалидни . ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 25  
19) Уредите  за регистриране  на данните  за движението  
трябва  да бъдат  така конструирани , че тахографските  
карти  да бъдат  застопорявани  в правилно  положение  в 
интерфейсното  устройства  за карта . 
20) Изваждането  на тахографска  карта  е възможно  само  
когато  превозното  средство  е спряло  и след  като съот­  
ветните  данни  за записани  на нея. Изваждането  на тахог­  
рафската  карта  трябва  да изисква  целенасочено  действие  
на потребителя . 
3.2 Измерване  на скоростта  и разстоянието  и определяне  на 
местоположението  
21) Датчикът  за движение  (евентуално  вграден  в адаптера ) е 
основният  източник  на сигнал  за измерването  на 
скоростта  и на изминатото  разстояние . 
22) Тази  функция  трябва  да мери  непрекъснато  и да може  да 
подава  стойността  от километражния  брояч , съот­  
ветстваща  на общото  разстояние , изминато  от превозното  
средство , чрез използване  на импулсите , подавани  от 
датчика  за движение . 
23) Тази  функция  трябва  да мери  непрекъснато  и да може  да 
подава  скоростта  на превозното  средство  чрез използване  
на импулсите , подавани  от датчика  за движение . 
24) Функцията  за измерване  на скоростта  на превозното  
средство  трябва  също  така да подава  информацията  
дали  превозното  средство  е в движение  или е спряло . 
Смята  се, че превозното  средство  е в движение  щом  
функцията  засича  от датчика  за движение  повече  от 1 
имп./s за период  не по-малко  от 5 секунди , в противен  
случай  се приема , че превозното  средство  е спряло . 
25) Устройствата  за показване  на скоростта  (скоростомер ) и 
общото  изминато  разстояние  (километражен  брояч ), 
монтирани  на всяко  превозно  средство , оборудвано  с 
отговарящи  на разпоредбите  на настоящия  регламент  
уреди  за регистриране  на данните  за движението , 
трябва  да отговарят  на изискванията  относно  максимално  
допустимите  толеранси  (виж 3.2.1 и 3.2.2), посочени  в 
настоящото  приложение . 
26) За откриване  на манипулиране  на данни  за движението , 
информацията  от датчика  за движение  трябва  да бъде  
потвърдена  от информация  за движението  на превозното  
средство , извлечена  от приемника  на сигнали  от GNSS, и 
като незадължителен  вариант , от друг (и) източник (ци), 
независими  от датчика  за движение . 
27) Тази  функция  трябва  да определя  местоположението  на 
превозното  средство , за да се даде  възможност  за авто­  
матично  записване  на: 
— места , където  водачът  и/или вторият  водач  започва  
своя  дневен  работен  период ; 
▼M1 
— места , където  времето  на общо  управление  на МПС  
достига  кратно  число  на три часа; 
▼B 
— места , където  водачът  и/или вторият  водач  завършва  
своя  дневен  работен  период . 
3.2.1  Измерване  на изминатото  разстояние  
28) Изминатото  разстояние  може  да бъде  измервано  така че: 
— или да се интегрира  и движението  напред , и 
движението  на заден  ход, 
— или да де включва  само  движението  напред . 
29) Уредите  за регистриране  на данните  за движението  
трябва  да измерват  разстояние  от 0 до 9 999 999,9 km.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 26  
30) Измерваното  разстояние  трябва  да бъде  със следния  
толеранс  (разстояния  от най-малко  1 000 m):  
— ± 1 % преди  монтирането , 
— ± 2 % по време  на монтирането  и на периодичните  
технически  прегледи , 
— ± 4 % по време  на работа . 
31) Разделителната  способност  при измерване  на 
разстоянието  трябва  да бъде  по-висока  или равна  на 
0,1 km.  
3.2.2  Измерване  на скоростта  
32) Уредите  за регистриране  на данните  за движението  
трябва  да измерват  скорост  от 0 до 220 km/h.  
33) С цел да гарантира  максимален  толеранс  ± 6 km/h за 
показваната  скорост  по време  на работа  и като се взема  
предвид : 
— толеранс  ± 2 km/h за различия  в постъпващите  данни  
(различия  в гумите  и т.н.), 
— толеранс  ± 1 km/h за измерванията , извършвани  по 
време  на монтирането  и на периодичните  технически  
прегледи , 
при скорости  между  20 и 180 km/h и при характе­  
ристични  коефициенти  на превозното  средство  между  
4 000 и 25 000 имп./km, уредите  за регистриране  на 
данните  за движението  трябва  да могат  да измерват  
скоростта  с толеранс  ± 1 km/h ( при постоянна  скорост ). 
Забележка : Разделителната  способност  на записа  на 
данните  въвежда  допълнителен  толеранс  от ± 0,5 km/h 
за скоростта , записвана  в уредите  за регистриране  на 
данните  за движението . 
34) Скоростта  трябва  да бъде  измервана  правилно , в рамките  
на нормалния  толеранс , в рамките  на две секунди  след  
промяна  на скоростта , когато  се е изменяла  с темп  2 m/s  2 . 
35) Разделителната  способност  при измерване  на скоростта  
трябва  да бъде  по-висока  или равна  на 1 km/h.  
3.2.3  Определяне  на местоположението  
36) Уредите  за регистриране  на данните  за движението  
трябва  да определят  абсолютното  местоположение  на 
превозното  средство  чрез използване  на приемника  на 
сигнали  от GNSS.  
37) Абсолютното  местоположение  се определя  с географски  
координати  за географска  ширина  и географска  дължина  
в градуси  и минути  с разделителна  способност  1/10 от 
минутата . 
3.3 Измерване  на времето  
38) Функцията  за измерване  на времето  трябва  да осигурява  
непрекъснато  измерване  и изобразяването  в цифров  вид 
на датата  и часа по координираното  универсално  време . 
39) Датата  и координираното  универсално  време  се 
използват  за определяне  на дата за данните  в уредите  
за регистриране  на данните  за движението  (записи , 
обмен  на данни ) и за всички  разпечатки , посочени  в 
допълнение  4 „Разпечатки “. 
40) С цел показване  на местното  време , трябва  да може  да се 
коригира  изместването  на времето  на стъпки  от по 
половин  час. Не се позволяват  никакви  други  
измествания  освен  отрицателни  или положителни  
кратни  на половин  час стойности . 
41) Неточността  на времето  трябва  да е в рамките  на ± 2 
секунди  на ден при условията  за одобряване  на типа , в 
отсъствието  на всякакво  сверяване . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 27  
42) Разделителната  способност  при измерване  на времето  
трябва  да бъде  по-висока  или равна  на 1 секунда . 
43) Измерването  на времето  не трябва  да се влияе  от 
прекъсване  на външното  електрическо  захранване , с 
продължителност , по-малка  от 12 месеца  при условията  
за одобряване  на типа . 
3.4 Следене  на дейностите  на водача  
44) Тази  функция  трябва  да осигурява  постоянно  и отделно  
следене  на дейностите , извършвани  от един  водач  и един  
втори  водач . 
45) Дейността , извършвана  от водача , трябва  да бъде  
управление  на МПС , РАБОТА , НА РАЗПОЛОЖЕНИЕ  
или ПРЕКЪСВАНЕ /ПОЧИВКА . 
46) Водачът  и/или вторият  водач  трябва  да може  да избира  
ръчно  дейността  РАБОТА , НА РАЗПОЛОЖЕНИЕ  или 
ПРЕКЪСВАНЕ /ПОЧИВКА . 
47) Когато  превозното  средство  е в движение , дейността  
управление  на МПС  трябва  да бъде  автоматично  
избрана  за водача , а дейността  НА РАЗПОЛОЖЕНИЕ  
трябва  да бъде  автоматично  избрана  за втория  водач . 
48) Когато  превозното  средство  спре , за водача  трябва  да 
бъде  избрана  автоматично  дейността  РАБОТА . 
▼M1 
49) Приема  се, че първата  промяна  на дейността  към „ПРЕ­  
КЪСВАНЕ /ПОЧИВКА “ или „НА РАЗПОЛОЖЕНИЕ “, 
настъпила  през 120-те секунди  след  автоматичната  
промяна  към „РАБОТА “ поради  спирането  на превозното  
средство , е настъпила  в момента  на спиране  на 
превозното  средство  (и следователно  евентуално  е 
анулирала  преминаването  към „РАБОТА “). 
▼B 
50) Тази  функция  трябва  да предава  промените  в дейността  
към функциите , осигуряващи  записването  на информа­  
цията , с разделителна  способност  от една  минута . 
51) За определена  календарна  минута , ако е регистрирана  
дейност  „управление  на МПС “ за непосредствено  пред­  
хождащата  я минута  и за непосредствено  следващата  я 
минута , за цялата  минута  се счита , че се извършва  
дейността  „управление  на МПС “. 
52) За определена  календарна  минута , за която  не се счита , 
че се извършва  дейността  „управление  на МПС “ съгласно  
изискване  051, за цялата  минута  се счита , че е 
извършвана  дейността , която  съвпада  с най-дългата  
непрекъсната  дейност , извършвана  в рамките  на 
минутата  (или с най-скорошната  дейност , при наличие  
на няколко  дейности  с еднаква  продължителност ). 
53) Тази  функция  трябва  също  така да позволява  постоянно  
следене  на непрекъснатото  работно  време  и на общото  
време  на прекъсване  на водача . 
3.5 Следене  на състоянието  при управление  на МПС  
54) Тази  функция  трябва  да осигурява  постоянно  и авто­  
матично  наблюдение  на състоянието  при управление  на 
МПС . 
55) Състоянието  при управление  на МПС  „ЕКИПАЖ “ трябва  
да бъде  избрано , когато  в уреда  са вкарани  две валидни  
карти  на водач , а при всички  останали  случаи  трябва  да 
бъде  избрано  състоянието  при управление  на МПС  
„САМ “. 
3.6 Въвеждане  на данни  от водачите  
3.6.1  Въвеждане  на мястото , където  дневните  периоди  на работа  
започват  и/или завършват  
56) Тази  функция  трябва  да позволява  въвеждането  на 
местата , където , според  водача  и/или втория  водач , 
техните  дневни  периоди  на работа  започват  и/или 
завършват . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 28  
57) Под „места “ се разбира  страната  и, освен  това където  е 
приложимо , регионът , въведен  или потвърден  ръчно . 
58) При изваждането  на карта  на водач , уредът  за регис­  
триране  на данните  за движението  трябва  да прикани  
водача /втория  водач  да въведе  „място , където  дневният  
период  на работа  завършва “. 
▼M1 
59) Тогава  водачът  трябва  да въведе  текущото  място  на 
превозното  средство , което  трябва  да се счита  за 
временно  въвеждане . 
Временно  въвеждане , направено  при последното  
изваждане  на картата , се потвърждава  (т.е. впоследствие  
не се замества ) при следните  условия : 
— въвеждане  на място , където  започва  текущият  дневен  
период  на работа , при ръчно  въвеждане  съгласно  
изискването  в подточка  61; 
— следващо  въвеждане  на място , където  започва  
текущият  дневен  период  на работа , ако титулярят  на 
картата  не въведе  място , където  започва  или където  е 
свършил  периодът  на работа , по време  на ръчното  
въвеждане  съгласно  изискването  в подточка  61. 
Временно  въвеждане , направено  при последното  
изваждане  на картата , се изтрива  и новата  стойност  се 
потвърждава  при следните  условия : 
— следващо  въвеждане  на място , където  завършва  
текущият  дневен  период  на работа , ако титулярят  на 
картата  не въведе  място , където  започва  или където  е 
свършил  периодът  на работа , по време  на ръчното  
въвеждане  съгласно  изискването  в подточка  61. 
▼B 
60) Трябва  да е възможно  въвеждането  на местата , където  
дневният  период  на работа  започва /завършва , чрез 
команди  от менюто . Ако в рамките  на една  календарна  
минута  се направят  повече  от едно  такива  въвеждания , 
трябва  да се съхранят  само  последните  извършени  
задания  за начално  място  и крайно  място . 
3.6.2  Ръчно  въвеждане  на дейностите , извършвани  от водача , и на 
съгласието  на водача  за интерфейса  с ITS 
61) При вкарването  на карта  на водач  (или на карта  за 
монтаж  и настройка ) и само  в този момент , уредът  за 
регистриране  на данните  за движението  трябва  да 
позволява  ръчно  въвеждане  на дейността . Ръчното  
въвеждане  на дейността  се извършва , като се използват  
стойностите  за местното  време  и дата за съответната  
часова  зона (изместване  спрямо  координираното  
универсално  време ), която  е текущо  зададена  за 
бордовото  устройство . 
При вкарването  на карта  на водач  или на карта  за монтаж  
и настройка , на титуляря  на картата  се напомня  за: 
— датата  и часа на последния  път, когато  е извадил  
картата ; 
— незадължително : текущо  зададеното  за бордовото  
устройство  изместване  на местното  време  спрямо  
UTC.  
При първото  вкарване  на дадена  карта  на водач  или на 
карта  за монтаж  и настройка , към момента  неизвестна  за 
бордовото  устройство , титулярят  на картата  трябва  да 
бъде  приканен  да изрази  своето  съгласие  за подаване  на 
лични  данни , свързани  с тахографирането , посредством  
незадължителния  интерфейс  с ITS.  
Във всеки  един  момент , съгласието  на водача  (съответно  
на сервиза ) може  да бъде  активирано  или дезактивирано  
чрез команди  от менюто , при условие , че е вкарана  карта  
на водач  (съответно  карта  за монтаж  и настройка ). 
Трябва  да е възможно  да се зададе  дейност  със следните  
ограничения : ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 29  
— видът  на дейността  трябва  да бъде  „РАБОТА “, „НА 
РАЗПОЛОЖЕНИЕ “ или ПРЕКЪСВАНЕ /ПОЧИВКА ; 
— Началото  и краят  на всяка  дейност  трябва  да са в 
рамките  на периода  между  последното  изваждане  на 
картата  и нейното  настоящо  вкарване . 
— Не се позволява  взаимно  припокриване  на дейности  
във времето . 
Ако е необходимо , при първото  вкарване  на 
неизползвана  преди  карта  на водач  (или карта  за 
монтаж  и настройки ) трябва  да е възможно  ръчно  
въвеждане . 
Процедурата  за ръчно  въвеждане  на дейности  трябва  да 
включва  толкова  последователни  стъпки , колкото  е необ­  
ходимо  за задаване  на вида  и момента , като час и 
минути , на започване  и завършване  на всяка  една  
дейност . За титуляря  на картата  трябва  да има избираем  
вариант  да не посочва  дейност  за която  и да е част от 
периода  от време  между  последното  изваждане  на 
картата  и нейното  настоящо  вкарване . 
По време  на ръчното  въвеждане , съответстващо  на вкар­  
ването  на картата  и, ако е необходимо , титулярят  на 
картата  трябва  да има възможност  да зададе : 
▼M1 
— място , където  е завършил  предишен  дневен  период  на 
работа , заедно  със съответното  време  (като по този 
начин  се замества  и потвърждава  въведеното  при 
последното  изваждане  на картата ), 
— място , където  започва  текущият  дневен  период  на 
работа , заедно  със съответното  време  (като по този 
начин  се потвърждава  временно  въведеното  при 
последното  изваждане  на картата ). 
▼B 
Ако титулярят  на картата  не въведе  място , където  
започва  или е завършил  периодът  на работа , по време  
на ръчните  въвеждания  във връзка  с вкарването  на 
картата , това се счита  за декларация , че периодът  му на 
работа  не се е променил  от последното  изваждане  на 
картата . Следващото  въвеждане  на място , където  е 
завършил  предишен  дневен  период  на работа , трябва  да 
замести  временното  въвеждане , извършено  при 
последното  изваждане  на картата . 
Ако е въведено  място , то трябва  да се запише  в съот­  
ветната  тахографска  карта . 
Ръчното  въвеждане  трябва  да бъде  прекъснато  ако: 
— картата  бъде  извадена  или 
— превозното  средство  се движи  и картата  е в процепа  
за карта  на водач . 
Позволени  са допълнителни  прекъсвания  — напр . след  
изтичане  на определен  период  от време , през който  
потребителят  не е бил активен . Ако ръчното  въвеждане  
бъде  прекъснато , уредите  за регистриране  на данните  за 
движението  трябва  да валидират  вече въведените  пълни  
записи  за място  и дейност  (които  съдържат  или едно­  
значно  посочени  място  и време , или вид, време  на 
започване  и време  на завършване  на дейността ). 
Ако бъде  поставена  втора  карта  на водач  или карта  за 
монтаж  и настройки  докато  е в ход ръчното  въвеждане  на 
дейности  за вкарана  преди  това карта , трябва  да е 
позволено  завършване  на ръчното  въвеждане  за тази 
предишна  карта  преди  да започне  ръчното  въвеждане  за 
втората  карта . 
Титулярят  на картата  трябва  да разполага  с избираем  
вариант  за ръчно  въвеждане  по следната  минимална  
процедура : 
— Ръчно  задаване  на дейности  в хронологична  послед­  
ователност  за периода  от последното  изваждане  на 
картата  до нейното  настоящо  вкарване . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 30  
— Като  време  на започване  на първата  дейност  трябва  да 
се зададе  моментът  на изваждане  на картата . За всяко  
следващо  въвеждане  времето  на започване  авто­  
матично  трябва  да се задава  така, че непосредствено  
да следва  времето  на завършване  за предишното  
въвеждане . За всяка  дейност  се избира  и задава  
нейният  вид и времето  на завършване . 
Процедурата  приключва , когато  времето  на завършване  
на ръчно  зададена  дейност  съвпадне  с времето  на 
вкарване  на картата . Тогава  уредите  за регистриране  на 
данните  за движението  може , като избираем  вариант , да 
позволят  на титуляря  на картата  да промени  всяка  една  
ръчно  въведена  дейност  до нейното  валидиране  чрез 
избор  на конкретна  команда . След  това трябва  да е 
забранено  каквато  и да е изменение . 
3.6.3  Въвеждане  на специфични  условия  
62) Уредите  за регистриране  на данните  за движението  
трябва  да позволяват  на водача  да въвежда  в реално  
време  следните  две специфични  условия : 
— „ИЗВЪН  ОБХВАТ “ (начало , край ) 
— „ПЪТУВАНЕ  С ФЕРИБОТ /ВЛАК “ (начало , край ). 
Не може  да се задава  „ПЪТУВАНЕ  С ФЕРИБОТ /ВЛАК “, 
когато  е зададено  условието  „ИЗВЪН  ОБХВАТ “. 
Отвореното  условие  „ИЗВЪН  ОБХВАТ “ трябва  задъл­  
жително  да бъде  затворено  автоматично  от уреда  за 
регистриране  на данните  за движението  в случай  на 
изваждане  или вкарване  на карта  на водач . 
Ако е отворено  условие  „ИЗВЪН  ОБСЕГ “, това води  до 
забрана  на следните  събития  и предупреждения : 
— управление  на МПС  без съответната  карта , 
— Предупреждения , свързани  с времето  на непрекъснато  
управление  на МПС . 
Началният  флаг  ПЪТУВАНЕ  С ФЕРИБОТ /ВЛАК  трябва  
да се зададе  преди  спирането  на двигателя  върху  фери­  
бота /влака . 
Отворено  ПЪТУВАНЕ  С ФЕРИБОТ /ВЛАК  трябва  да 
приключи , когато  се появи  някой  от следните  
избираеми  варианти : 
— Водачът  приключва  ръчно  ПЪТУВАНЕТО  С ФЕРИ­  
БОТ /ВЛАК  
— Водачът  изважда  картата  си 
Едно  отворено  ПЪТУВАНЕ  С ФЕРИБОТ /ВЛАК  трябва  
да завърши  когато  вече не е валидно  въз основа  на 
правилата , формулирани  в Регламент  (ЕО) № 561/2006.  
3.7 Управление  на блокиранията , наложени  от превозвача  
63) Тази  функция  трябва  да позволява  управлението  на 
блокировките , поставени  от даден  превозвач  с цел да 
ограничи  и запази  единствено  за себе си достъпа  до 
данните  в режим  „превозвач “. 
64) Блокировките , наложени  от превозвача , се състоят  в дата 
и час на начало  (блокиране ) и дата и час на край  (раз­ 
блокиране ), свързани  с идентификацията  на превозвача  
чрез номера  на картата  на превозвач  (по време  на блоки­  
рането ). 
65) Блокирането  и разблокирането  са възможни  само  в 
реално  време . 
66) Разблокирането  трябва  да може  да се извърши  само  от 
превозвача , който  е извършил  блокирането  (така, както  то 
се идентифицира  с първите  13 цифри  на номера  на 
картата  на превозвач ), или, ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 31  
67) Разблокирането  трябва  да става  автоматично , когато  друг  
превозвач  извърши  блокиране . 
68) В случай  че даден  превозвач  извърши  блокиране  и ако 
предишното  блокиране  е било  извършено  от същия  
превозвач , се приема , че предишното  блокиране  не е 
разблокирано  и че то все още е в сила . 
3.8 Следене  на контролните  дейности  
69) Тази  функция  трябва  да следи  дейностите  по ИЗОБРАЗ­  
ЯВАНЕ , ОТПЕЧАТВАНЕ , ИЗТЕГЛЯНЕ  НА ДАНННИ  от 
БУ и картата , както  и пътна  ПРОВЕРКА  НА КАЛИБРИ­  
РАНЕТО , провеждани  в контролен  режим . 
70) Тази  функция  трябва  да осигурява  също  така следене  на 
дейностите  по КОНТРОЛ  ЗА ПРЕВИШЕНА  СКОРОСТ  в 
контролен  режим . Приема  се, че е извършен  контрол  за 
превишена  скорост , когато  в контролен  режим  се 
изпраща  съобщение  „превишена  скорост “ към печа­  
тащото  устройство  или дисплея  или когато  данни  за 
„събития  или неизправности “ са изтеглени  от паметта  
на бордовото  устройство . 
3.9 Откриване  на събития  и/или неизправности  
71) Тази  функция  открива  следните  събития  и/или неизправ­  
ности : 
3.9.1  Събитие  „вкарване  на невалидна  карта “ 
72) Това  събитие  се предизвиква  от вкарването  на невалидна  
карта , при вкарване  на вече заменена  карта  на водач , 
и/или когато  валидността  на вкарана  карта  изтича . 
3.9.2  Събитие  „конфликт , предизвикан  от картата “ 
73) Това  събитие  се предизвиква  от всяка  от отбелязаните  с 
хикс  комбинации  от карти  в долната  таблица : 
Конфликт , предизвикан  от 
карта  Процеп  за карта  на водач  
Няма  карта  Карта  на водач  Контролна  карта  Карта  за монтаж  
и настройки  Карта  на 
превозвач
 Процеп  за карта  на втория  водач 
Няма  карта  
Карта  на водач  X  
Контролна  карта  X  X  X  
Карта  за монтаж  и 
настройки  X X  X  X  
Карта  на превозвач  X  X  X  
3.9.3  Събитие  „припокриване  във времето “ 
74) Това  събитие  се предизвиква  когато  датата /часът  на 
последното  изваждане  на дадена  карта  на водач , 
прочетени  от картата , са по-късни  от текущите  дата/час 
на уреда  за регистриране  на данните  за движението , в 
който  картата  е вкарана . 
3.9.4  Събитие  „управление  на МПС  без съответната  карта “ 
75) Това  събитие  се предизвиква  от всяка  от отбелязаните  с 
хикс  комбинации  от тахографски  карти  в долната  
таблица , когато  дейността  на водача  става  управление  
на МПС , или в случай  на промяна  на режима  на 
работа , когато  дейността  на водача  е управление  на 
МПС : ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 32  
управление  на МПС  без 
съответната  карта  Процеп  за карта  на водач  
Няма  (или нева­  
лидна ) карта  Карта  на водач  Контролна  карта  Карта  за монтаж  
и настройки  Карта  на 
превозвач
 Процеп  за карта  на втория  водач 
Няма  (или нева­  
лидна ) карта  X X  X  
Карта  на водач  X  X  X  X  
Контролна  карта  X  X  X  X  X  
Карта  за монтаж  и 
настройки  X X  X  X  
Карта  на превозвач  X  X  X  X  X  
3.9.5  Събитие  „вкарване  на карта  по време  на управление  на МПС “ 
76) Това  събитие  се предизвиква  от вкарването  на тахог­  
рафска  карта  в който  и да е процеп , когато  дейността  
на водача  е управление  на МПС . 
3.9.6  Събитие  „неправилно  приключена  последна  картова  сесия “ 
77) Това  събитие  се предизвиква , когато  уредите  за регис­  
триране  на данните  за движението  открият  при вкар­  
ването  на карта , че въпреки  разпоредбите  на точка  3.1, 
предишната  картова  сесия  не е била  приключена  
правилно  (картата  е била  извадена  преди  всички  необ­  
ходими  данни  да са били  записани  на картата ). Това  
събитие  трябва  да се предизвиква  само  от карта  на 
водач  или карта  за монтаж  и настройки . 
3.9.7  Събитие  „превишаване  на скоростта “ 
78) Това  събитие  се предизвиква  при всяко  превишаване  на 
допустимата  скорост . 
3.9.8  Събитие  „прекъсване  на електрическото  захранване “ 
79) Това  събитие  се предизвиква  в режим , различен  от 
режима  на калибриране  или от контролния  режим , при 
прекъсване  за повече  от 200 милисекунди  на електри­  
ческото  захранване  на датчика  за движение  и/или на 
бордовото  устройство . Прагът  на прекъсване  се 
определя  от производителя . Прекъсването  на електри­  
ческото  захранване , дължащо  се на пускането  на 
двигателя  на превозното  средство , не трябва  да пред­  
извиква  появата  на това събитие . 
3.9.9  Събитие  „Грешка  в комуникацията  с устройството  за връзка  
от разстояние “ 
80) Това  събитие  трябва  да се предизвиква , извън  режима  
на калибриране , когато  устройството  за връзка  от 
разстояние  не потвърждава  успешното  приемане  на 
данни  при комуникацията  от разстояние , изпратени  от 
бордовото  устройство , при повече  от три опита . 
3.9.10  Събитие  „Липса  на информация  за местоположението  от 
приемник  на сигнали  от GNSS“  
81) Това  събитие  трябва  да се предизвиква  извън  режима  на 
калибриране , в случай  на липса  на информация  за 
местоположението , постъпваща  от приемник  на сигнали  
от GNSS (вътрешен  или външен ) за повече  от три часа 
натрупано , време  на управление  на МПС . 
3.9.11  Събитие  „Грешка  в комуникацията  с външното  устройство  за 
GNSS“  
82) Това  събитие  трябва  да се предизвиква  извън  режима  на 
калибриране , в случай  на прекъсване  на комуникацията  
между  външното  устройство  за GNSS и бордовото  
устройство  за повече  от 20 последователни  минути , 
когато  превозното  средство  е в движение . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 33  
3.9.12  Събитие  „Грешка  в данните  за движението “ 
83) Това  събитие  трябва  да се предизвиква , извън  режима  
на калибриране , при прекъсване  на нормалния  поток  от 
данни  между  датчика  за движение  и бордовото  
устройство  и/или в случай  на грешка , свързана  с 
целостта  на данните  или с удостоверяването  им по 
време  на техния  обмен  между  датчика  за движение  и 
бордовото  устройство . 
3.9.13  Събитие  „Противоречие  в данните  за движението  на 
превозното  средство “ 
84) Това  събитие  трябва  да се предизвиква  извън  режима  на 
калибриране , в случай  че информацията  за движение , 
изчислена  от датчика  за движение , противоречи  на 
информацията  за движение , изчислена  от вътрешния  
приемник  на сигнали  от GNSS или от външно  устройство  
за GNSS и евентуално  от други  независими  източници , 
както  е специфицирано  в допълнение  12. Това  събитие  не 
трябва  да се предизвиква  по време  на пътуване  с фери­  
бот/влак , условие  „ИЗВЪН  ОБСЕГ “, или когато  инфор­  
мацията  за местоположението  не е на разположение  от 
приемника  на сигнали  от GNSS.  
3.9.14  Събитие  „Опит  за нарушаване  на сигурността “ 
85) Извън  режима  за калибриране  това събитие  трябва  да се 
предизвиква  при настъпване  на всяко  друго  събитие , 
засягащо  сигурността  на датчика  за движение  и/или на 
бордовото  устройство  и/или външното  устройство  за 
GNSS, така както  се изисква  в допълнение  10. 
▼M1 
3.9.15  Събитие  „времеви  конфликт “ 
86) Това  събитие  се задейства , извън  режима  на калиб­  
риране , когато  бордовото  устройство  установи  несъот­  
ветствие , по-дълго  от 1 минута , между  показанията  на 
функцията  за измерване  на времето  на бордовото  
устройство  и данните  за времето , постъпващи  от 
приемника  на сигнали  от GNSS. Това  събитие  се 
записва  заедно  със стойността  на вътрешния  часовник  
на бордовото  устройство  и се придружава  от авто­  
матично  сверяване  на часовника . След  предизвикване  на 
събитие  на времеви  конфликт  през следващите  12 часа 
бордовото  устройство  не генерира  други  събития  на 
времеви  конфликт . Това  събитие  не трябва  да се пре- 
дизвиква , ако в продължение  на 30 или повече  дни от 
приемника  на сигнали  от GNSS не е можел  да бъде  
открит  валиден  сигнал  от GNSS.  
▼B 
3.9.16  Неизправност  „Карта “ 
87) Тази  неизправност  се предизвиква  при неизправност  в 
тахографската  карта  по време  на нейното  функцио­  
ниране . 
3.9.17  Неизправност  „Уред  за регистриране  на данните  за движе­  
нието “ 
88) Тази  неизправност  се предизвиква  при следните  
неизправности , при режимите , различни  от режима  за 
калибриране : 
— Неизправност  вътре  в бордовото  устройство  
— Неизправност  в печатащото  устройство  
— Неизправност  в дисплея  
— Грешка  при изтегляне  на данни  
— Неизправност  на датчика  
— Неизправност  в приемника  на сигнали  от GNSS или 
външното  устройство  за GNSS  
— Неизправност  в устройството  за връзка  от разстояние  
▼M1 
— Неизправност  на интерфейса  с ITS (ако е приложимо ) ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 34  
3.10 Вградени  функции  за изпробване  и самоизпробване  
89) ►M1 Уредът  за регистриране  на данните  за движението  
трябва  да открива  неизправности  чрез функции  за 
изпробване  и самоизпробване  в съответствие  с 
таблицата  по-долу : ◄ 
Елемент  за изпробване  Самоизпробване  Вградена  функции  за 
изпробване  
Софтуер  Работоспособност  
Памет  за данни  Достъп  Достъп , цялост  на 
данните  
Интерфейсни  устройства  за 
карта  Достъп  Достъп  
Клавиатура  Ръчна  проверка  
Печатащо  устройство  (по избор  на 
производителя ) Разпечатка  
Дисплей  Визуална  проверка  
Изтегляне  на данни  
(извършвано  само  по време  
на изтеглянето ) Правилно  
функциониране  
Датчик  Правилно  
функциониране  Правилно  
функциониране  
Устройство  за връзка  от 
разстояние  Правилно  
функциониране  Правилно  
функциониране  
Устройство  за GNSS  Правилно  
функциониране  Правилно  
функциониране  
▼M1 
Интерфейс  с ITS (незадъл­  
жителен ) Правилно  
функциониране  
▼B 
3.11 Четене  от паметта  за данни  
90) Уредът  за регистриране  на данните  за движението  трябва  
да може  да чете всякакви  данни , записани  в паметта  му. 
3.12 Регистриране  и запис  в паметта  за данни  
За целите  на настоящата  точка , 
— под „365 дни“ се разбира  365 календарни  дена  на средна  
дейност  на водачите  в дадено  превозно  средство . Средната  
дейност  на ден в едно  превозно  средство  се определя  като 
най-малко  6 водачи  или втори  водачи , 6 цикъла  на вкарване / 
изваждане  на карта  и 256 смени  на дейностите . След­  
ователно  „365 дни“ включват  най-малко  2 190 водачи /втори  
водачи  и 93 440 смени  на дейностите , 
▼M1 
— средният  брой  на местоположенията  на ден се определя  като 
най-малко  6 местоположения , в които  започва  дневният  
период  на работа , 6 местоположения , в които  общото  
време  на управление  на МПС  достига  кратно  число  на три 
часа, и 6 местоположения , в които  завършва  дневният  
период  на работа , така че „365 дни“ включват  най-малко  
6 570 местоположения , 
▼B 
— часовете  се регистрират  с точност  от една  минута , освен  ако 
не е предвидено  друго , 
— стойностите  от километражния  брояч  се регистрират  с 
разделителна  способност  един  километър , 
— скоростите  се регистрират  с разделителна  способност  един  
km/h,  
— местоположенията  (ширини  и дължини ) се регистрират  в 
градуси  и минути , с разделителна  способност  1/10 от 
минутата , със съответните  точност  и време  за снемане  на 
данни  на GNSS.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 35  
91) Данните , записани  в паметта , не трябва  да се влияят  от 
прекъсване  на външното  електрическо  захранване  с 
продължителност , по-малка  от 12 месеца , при условията  
за одобряване  на типа . Освен  това данните , записани  във 
външното  устройство  за връзка  от разстояние , както  е 
определено  в допълнение  14, не трябва  да се влияят  от 
прекъсване  на електрическото  захранване  по-крат­  
котрайно  от 28 дни. 
92) Уредите  за регистриране  на данните  за движението  
трябва  да могат  да регистрират  и записват  по подраз­  
биране  или при задаване  следните  данни  в своята  памет : 
3.12.1  Данни  за идентификация  на уредите  
3.12.1.1 Д а н н и з а и д е н т и ф и к а ц и я н а б о р д о в о т о 
у с т р о й с т в о 
93) Уредът  за регистриране  на данните  за движението  трябва  
да може  да записва  в своята  памет  следните  данни  за 
идентификацията  на бордовото  устройство : 
— наименование  на производителя , 
— адрес  на производителя , 
— номер  на частта , 
— сериен  номер , 
— поколение  на БУ, 
— способност  за използване  на тахографски  карти  от 
първо  поколение  
— номер  на версията  на софтуера , 
— дата на инсталиране  на версията  на софтуера , 
— година  на производство  на уреда , 
— номер  на одобрение , 
94) Данните  за идентификацията  на бордовото  устройство  се 
регистрират  и записват  еднократно  от производителя  на 
бордовото  устройство , освен  данните  за софтуера  и 
номера  на одобрението  (които  могат  да бъдат  
променени  при обновяване  на софтуера ), както  и способ­  
ността  за използване  на тахографски  карти  от първо  
поколение . 
3.12.1.2 Д а н н и з а и д е н т и ф и к а ц и я н а д а т ч и к а з а 
д в и ж е н и е 
95) Датчикът  за движение  трябва  да може  да записва  в 
паметта  си следните  данни  за идентификация : 
— наименование  на производителя , 
— сериен  номер , 
— номер  на одобрение , 
— идентификатор  на вградения  компонент  за сигурност  
(напр . сериен  номер  на вътрешната  интегрална  схема / 
процесор ), 
— идентификатор  на операционната  система  (напр . 
номер  на версията  на софтуера ). 
96) Данните  за идентификация  на датчика  за движение  се 
регистрират  и записват  еднократно  в датчика  от 
неговия  производител . 
97) Бордовото  устройство  трябва  да може  да регистрира  и 
записва  в паметта  си следните  данни , свързани  с 
последните  20 сдвоявания  на датчици  за движение  (ако 
в рамките  на един  календарен  ден се случат  няколко  
свързвания , в паметта  се записват  само  първото  и 
последното  за деня ): ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 36  
За всяко  от тези свързвания  се регистрират  следните  
данни : 
— данни  за идентификация  на датчика  за движение : 
— сериен  номер  
— номер  на одобрение  
— данни  за сдвояването  на датчик  за движение : 
— дата на сдвояването . 
3.12.1.3 Д а н н и з а и д е н т и ф и к а ц и я н а Г л о б а л н а н а в и г а ­ 
ц и о н н а с п ъ т н и к о в а с и с т е м а 
98) Външното  устройство  за GNSS трябва  да може  да 
записва  в паметта  си следните  данни  за идентификация : 
— наименование  на производителя , 
— сериен  номер , 
— номер  на одобрение , 
— идентификатор  на вградения  компонент  за сигурност  
(напр . сериен  номер  на вътрешната  интегрална  схема / 
процесор ), 
— идентификатор  на операционната  система  (напр . 
номер  на версията  на софтуера ). 
99) Данните  за идентификация  се регистрират  и записват  
еднократно  във външното  устройство  за GNSS от 
неговия  производител . 
100) Бордовото  устройство  трябва  да може  да регистрира  и 
записва  в паметта  си следните  данни , свързани  с 
последните  20 свързвания  на външни  устройства  за 
GNSS (ако в рамките  на един  календарен  ден се случат  
няколко  свързвания , в паметта  се записват  само  първото  
и последното  за деня ). 
За всяко  от тези свързвания  се регистрират  следните  
данни : 
— данни  за идентификация  на външно  устройство  за 
GNSS:  
— пореден  номер , 
— номер  на одобрение , 
— данни  за свързаното  външно  устройство  за GNSS:  
— дата на свързването  
3.12.2  Ключове  и сертификати  
101) Уредите  за регистриране  на данните  за движението  
трябва  да могат  да записват  определен  брой  криптог­  
рафски  ключове  и сертификати , както  е посочено  в 
допълнение  11, част А и част Б. 
3.12.3  Данни  за вкарването  и изваждането  на картата  на водач  или 
картата  за монтаж  и настройки  
102) За всеки  цикъл  на вкарване -изваждане  на дадена  карта  на 
водач  или карта  за монтаж  и настройки  в уреда  за регис­  
триране  на данните  за движението , последното  трябва  да 
регистрира  и записва  в своята  памет : 
— името  и презимето  на титуляря  на картата  така, както  
те са записани  в картата , 
— номера  на картата , държавата  членка , която  я е 
издала , и срокът  на валидност , така както  са 
записани  на картата , 
— поколението  на картата , ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 37  
— датата  и часа на вкарването , 
— стойността  от километражния  брояч  на превозното  
средство  в момента  на вкарването  на картата , 
— процепа , в който  се вкарва  картата , 
— датата  и часа на изваждането  ѝ, 
— стойността  от километражния  брояч  на превозното  
средство  в момента  на изваждането  на картата , 
— следната  информация  относно  последното  превозно  
средство , използвано  от водача  така, както  е 
записана  в картата : 
— регистрационния  номер  на превозното  средство  
(VRN) и държавата  членка  на регистрация , 
— поколението  на БУ (когато  е налично ), 
— дата и час на изваждането  на картата , 
— флаг , указващ  дали  при вкарването  на картата  
титулярят  на картата  е въвел  ръчно  дейностите  или 
не. 
103) Паметта  трябва  да може  да запазва  тези данни  в 
продължение  на най-малко  365 дни. 
104) Когато  капацитетът  за съхраняване  на информация  е 
изчерпан , новите  данни  заместват  най-старите  данни . 
3.12.4  Данни  за дейностите  на водача  
105) Уредът  за регистриране  на данните  за движението  трябва  
да регистрира  и записва  в паметта  си всяка  промяна  на 
дейността  на водача  и/или на втория  водач , и/или всяка  
промяна  на състоянието  при управление  на МПС , и/или 
всяко  вкарване  или изваждане  на карта  на водач  или 
карта  за монтаж  и настройки : 
— състояние  при управление  на МПС  (ЕКИПАЖ , САМ ), 
— процеп  (ВОДАЧ , ВТОРИ  ВОДАЧ ), 
— положение  на картата  в процепа  (ВКАРАНА /НЕВКА­  
РАНА ), 
— дейност  (управление  на МПС , НА РАЗПОЛОЖЕНИЕ , 
РАБОТА , ПРЕКЪСВАНЕ /ПОЧИВКА ), 
— дата и час на промяната . 
ВКАРАНА  означава , че в процепа  е вкарана  валидна  
карта  на водач  или карта  за монтаж  и настройки . 
НЕВКАРАНА  означава  обратното , тоест  че в процепа  
няма  валидна  карта  на водач  или карта  за монтаж  и 
настройки  (напр . вкарана  е карта  на превозвач  или не е 
вкарана  карта ) 
Въвежданите  ръчно  от водача  данни  за дейността  не се 
записват  в паметта . 
106) Паметта  трябва  да може  да запазва  данните  за дейността  
на водача  в продължение  на най-малко  365 дни. 
107) Когато  капацитетът  за съхраняване  на информация  е 
изчерпан , новите  данни  заместват  най-старите  данни . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 38  
3.12.5  Места  и местоположения , където  започват  и завършват  
дневните  периоди  на работа  и/или където  общото  време  на 
управление  на МПС  достига  3 часа  
108) Уредът  за регистриране  на данните  за движението  трябва  
да регистрира  и записва  в своята  памет  за данни : 
— места  и местоположения , където  водачът  и/или 
вторият  водач  започва  своя  дневен  период  на работа ; 
— местоположения , където  общото  време  на управление  
на МПС  достига  кратно  число  на три часа; 
— места  и местоположения , където  водачът  и/или 
вторият  водач  приключва  своя  дневен  период  на 
работа . 
▼B 
109) Когато  в тези моменти  местоположението  на превозното  
средство  не е на разположение  от приемника  на сигнали  
от GNSS, уредът  за регистриране  на данните  за 
движението  трябва  да използва  последното  налично  
местоположение  и съответните  дата и час. 
110) Заедно  с всяко  място  или местоположение , уредът  за 
регистриране  на данните  за движението  трябва  да 
регистрира  и записва  и в своята  памет  за данни : 
— номера  на картата  на водача /втория  водач  и 
държавата  членка , която  е издала  картата , 
— поколението  на картата , 
— дата и час на въвеждането , 
▼M1 
— вид на въвеждането  (начало , край  или 3 часа общо  
време  на управление  на МПС ), 
▼B 
— съответната  точност  на GNSS, дата и час, ако е 
приложимо ; 
— стойността  от километражния  брояч  на превозното  
средство . 
▼M1 
111) Паметта  за данни  трябва  да позволява  съхраняването  на 
места  и местоположения , където  започват  и завършват  
дневните  периоди  на работа  и/или където  общото  време  
на управление  на МПС  достига  3 часа, в продължение  на 
най-малко  365 дни. 
▼B 
112) Когато  капацитетът  за съхраняване  на информация  е 
изчерпан , новите  данни  заместват  най-старите  данни . 
3.12.6  Данни  от километражния  брояч  
113) Уредът  за регистриране  на данните  за движението  трябва  
да записва  в своята  памет  стойността  от километражния  
брояч  на превозното  средство  и съответната  дата в 
полунощ  всеки  календарен  ден. 
114) Паметта  за данни  трябва  да позволява  съхраняването  
ежедневните  записи  в полунощ  от километражния  брояч  
в продължение  на най-малко  365 календарни  дни. 
115) Когато  капацитетът  за съхраняване  на информация  е 
изчерпан , новите  данни  трябва  да заместват  най-старите  
данни . 
3.12.7  Подробни  данни  за скоростта  
▼M1 
116) Уредът  за регистриране  на данните  за движението  трябва  
да записва  и съхранява  в своята  памет  моментната  
скорост  на превозното  средство  и датата  и часа през 
всяка  секунда  най-малко  от последните  24 часа, по 
време  на които  превозното  средство  е било  в движение . 
▼B 
3.12.8  Данни  за събитията  
За целите  на настоящата  подточка  времето  се записва  с точност  
една  секунда . 
117) Уредът  за регистриране  на данните  за движението  трябва  
да записва  в своята  памет  следните  данни  за всяко  
засечено  събитие , съгласно  следните  правила  за запис : ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 39  
Събитие  Правила  за запис  в паметта  Данни , които  се регистрират  при всяко  събитие  
Вкарване  на невалидна  
карта  — 10-те най-скорошни  събития . — дата и час на събитие , 
— тип на картата (ите), номер , държава  
членка , издала  картата , и поколение  
на картата , предизвикваща  събитието . 
— брой  сходни  събития , възникнали  
същия  ден 
Конфликт , предизвикан  
от карта  — 10-те най-скорошни  събития . — дата и час на начало  на събитието , 
— дата и час на край  на събитието , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), и 
поколение  на двете  карти , пред­  
извикващи  събитието . 
управление  на МПС  без 
съответната  карта  — най-продължителното  събитие  за 
всеки  от десетте  последни  дена  на 
възникване  на това събитие , 
— 5-те най-продължителни  събития  
през последните  365 дни. — дата и час на начало  на събитието , 
— дата и час на край  на събитието , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), както  и 
поколение  на всяка  карта , вкарана  в 
началото  и/или в края  на събитието , 
— брой  сходни  събития , възникнали  
същия  ден. 
Вкарване  на карта  по 
време  на управление  на 
МПС  — последното  събитие  за всеки  от 
десетте  последни  дена  на възникване  
на това събитие , — дата и час на събитието , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), поко­  
ление , 
— брой  сходни  събития , възникнали  
същия  ден 
Неправилно  
приключване  на 
последната  картова  
сесия  — 10-те най-скорошни  събития . — дата и час на вкарване  на картата , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), поко­  
ление , 
— данни  относно  последната  сесия  така, 
както  са прочетени  от картата : 
— дата и час на вкарване  на картата , 
— VRN, държава  членка  на 
регистрация  и поколение  на 
бордовото  устройство . 
Превишаване  на 
скоростта  (1) — най-сериозното  събитие  (тоест  съби­  
тието , при което  е достигната  най- 
висока  средна  скорост ) през десетте  
последни  дена  на възникване  на това 
събитие , 
— 5-те най-сериозни  събития  през 
последните  365 дни. 
— първото  събитие , възникнало  след  
последното  калибриране  — дата и час на начало  на събитието , 
— дата и час на край  на събитието , 
— максимална  скорост , измерена  по 
време  на събитието , 
— средноаритметична  скорост , измерена  
по време  на събитието , 
— тип и номер  на картата , държава  
членка , издала  картата , и поколение  
на картата  на водач  (ако е прило­  
жимо ), 
— брой  сходни  събития , възникнали  
същия  ден. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 40  
Събитие  Правила  за запис  в паметта  Данни , които  се регистрират  при всяко  събитие  
Прекъсване  на електри­  
ческото  захранване  (2) — най-продължителното  събитие  за 
всеки  от десетте  последни  дена  на 
възникване  на това събитие , 
— 5-те най-продължителни  събития  
през последните  365 дни. — дата и час на начало  на събитието , 
— дата и час на край  на събитието , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), както  и 
поколение  на всяка  карта , вкарана  в 
началото  и/или в края  на събитието , 
— брой  сходни  събития , възникнали  
същия  ден. 
Грешка  в комуникацията  
с устройството  за връзка  
от разстояние  — най-продължителното  събитие  за 
всеки  от десетте  последни  дена  на 
възникване  на това събитие , 
— 5-те най-продължителни  събития  
през последните  365 дни. — дата и час на началото  на събитие , 
— дата и час на края  на събитие , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), както  и 
поколение  на всяка  карта , вкарана  в 
началото  и/или в края  на събитието , 
— брой  сходни  събития , възникнали  
същия  ден. 
Липса  на информация  за 
местоположението  от 
приемник  на сигнали  от 
GNSS  — най-продължителното  събитие  за 
всеки  от десетте  последни  дена  на 
възникване  на това събитие , 
— 5-те най-продължителни  събития  
през последните  365 дни. — дата и час на началото  на събитие , 
— дата и час на край  на събитието , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), както  и 
поколение  на всяка  карта , вкарана  в 
началото  и/или в края  на събитието , 
— брой  сходни  събития , възникнали  
същия  ден. 
▼M1 
Грешка  в комуникацията  
с външното  устройство  
за GNSS  — най-продължителното  събитие  за 
всеки  от последните  10 дни на 
възникване , 
— 5-те най-продължителни  събития  
през последните  365 дни. — дата и час на началото  на събитие , 
— дата и час на края  на събитие , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), както  и 
поколение  на всяка  карта , вкарана  в 
началото  и/или в края  на събитието , 
— брой  сходни  събития , възникнали  
същия  ден. 
▼B 
Грешка  в данните  за 
движението  — най-продължителното  събитие  за 
всеки  от десетте  последни  дена  на 
възникване  на това събитие , 
— 5-те най-продължителни  събития  
през последните  365 дни. — дата и час на начало  на събитието , 
— дата и час на край  на събитието , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), както  и 
поколение  на всяка  карта , вкарана  в 
началото  и/или в края  на събитието , 
— брой  сходни  събития , възникнали  
същия  ден. 
Противоречие  в данните  
за движението  на 
превозното  средство  — най-продължителното  събитие  за 
всеки  от десетте  последни  дена  на 
възникване  на това събитие , 
— 5-те най-продължителни  събития  
през последните  365 дни. — дата и час на начало  на събитието , 
— дата и час на край  на събитието , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), както  и 
поколение  на всяка  карта , вкарана  в 
началото  и/или в края  на събитието , 
— брой  сходни  събития , възникнали  
същия  ден. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 41  
Събитие  Правила  за запис  в паметта  Данни , които  се регистрират  при всяко  събитие  
Опит  за нарушаване  на 
сигурността  — 10-те най-скорошни  събития  за всеки  
тип събитие . — дата и час на начало  на събитието , 
— дата и час на края  на събитие  (ако е от 
значение ), 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), както  и 
поколение  на всяка  карта , вкарана  в 
началото  и/или в края  на събитието , 
— тип събитие . 
▼M1 
Времеви  конфликт  — най-сериозното  събитие  за всеки  от 
десетте  последни  дена  на възникване  
(т.е. с най-голяма  разлика  между  
датата  и часа на уреда  за регис­  
триране  на данните  за движението  и 
датата  и часа по GNSS). 
— 5-те най-сериозни  събития  през 
последните  365 дни. — дата и час на уреда  за регистриране  на 
данните  за движението , 
— дата и час по GNSS, 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), както  и 
поколение  на всяка  карта , вкарана  в 
началото  и/или в края  на събитието , 
— брой  сходни  събития , възникнали  
същия  ден. 
▼B 
1) Уредът  за регистриране  на данните  за движението  
трябва  да регистрира  и записва  също  и в своята  
памет  за данни : 
— датата  и часа на последния  КОНТРОЛ  ЗА 
ПРЕВИШЕНА  СКОРОСТ , 
— датата  и часа на първото  превишаване  на 
скоростта , констатирано  след  този КОНТРОЛ  ЗА 
ПРЕВИШЕНА  СКОРОСТ . 
— броя  на събитията  „превишаване  на скоростта  след  
последния  КОНТРОЛ  ЗА ПРЕВИШЕНА  
СКОРОСТ “. 
2) Тези  данни  могат  да бъдат  регистрирани  само  при 
повторно  включване  на електрическото  захранване , 
времената  могат  да бъдат  известни  с точност  до 
минута . 
3.12.9  Данни  за неизправностите  
За целите  на настоящата  подточка  времето  се регистрира  с 
разделителна  способност  1 секунда . 
118) Уредите  за регистриране  на данните  за движението  
трябва  да се опитват  да регистрират  и записват  в своята  
памет  следните  данни  относно  всяка  открита  
неизправност , съгласно  следните  правила  за запис : 
Неизправност  Правила  за запис  в паметта  Данни , които  се регистрират  при всяка  
неизправност  
Неизправност  на картата  — 10-те последни  неизправности  на 
картата  на водач . — дата и час на началото  на 
неизправност , 
— дата и час на края  на неизправност , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), поко­  
ление . 
неизправности  в уредите  
за регистриране  на 
данните  за движението  — 10-те последни  неизправности  за 
всеки  тип неизправност , 
— първата  неизправност  след  
последното  калибриране . — дата и час на началото  на 
неизправност , 
— дата и час на края  на неизправност , 
— тип на неизправността , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), както  и 
поколение  на всяка  карта , вкарана  в 
началото  и/или в края  на неизправ­  
ността , ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 42  
3.12.10  Данни  за калибриране  
119) Уредът  за регистриране  на данните  за движението  
записва  и съхранява  данни  в своята  памет , имащи  
отношение  към: 
— параметрите  на калибрирането , известни  в момента  на 
пускането , 
— своето  най-първо  калибриране  след  пускането  си, 
— първото  си калибриране  в превозното  средство , на 
което  се намира  в момента  (идентифицирано  от 
неговия  VIN),  
— 20-те последни  калибрирания  (ако няколко  калиб­  
рирания  се извършват  в рамките  на един  календарен  
ден, са записват  само  първото  и последното  за деня ). 
120) За всяко  от тези калибрирания  се регистрират  следните  
данни : 
— цел на калибрирането  (пускане , първо  монтиране , 
монтиране , периодични  технически  прегледи ), 
— наименование  и адрес  на сервиза , 
— номер  на картата  за монтаж  и настройки , държава  
членка , която  я е издала , и срок  на валидност  на 
картата , 
— идентификация  на превозното  средство , 
— актуализирани  или потвърдени  параметри : w, k, l, 
размер  на гумите , регулировка  на ограничителя  на 
скоростта , брояч  на километрите  (стара  и нова  стой­  
ност ), дата и час (стара  и нова  стойност ), 
— типовете  и идентификаторите  на всички  поставени  
пломби . 
121) Освен  това уредите  за регистриране  на данните  за 
движението  регистрират  и записват  в паметта  си за 
данни  способността  си да използват  тахографски  карти  
от първо  поколение  (все още активирани  или не). 
122) Датчикът  за движение  трябва  да регистрира  и записва  в 
паметта  си следните  данни  относно  монтирането  му: 
— първо  сдвояване  към бордово  устройство  (дата, час, 
номер  на одобрение  на устройството , сериен  номер  на 
устройството ), 
— последно  сдвояване  с устройство , монтиран  на 
превозното  средство  (дата, час, сертификационен  
номер  на устройството , сериен  номер  на устрой­  
ството ). 
123) външното  устройство  за GNSS трябва  да регистрира  и 
записва  в паметта  си следните  данни  относно  монти­  
рането  му: 
— първо  свързване  към бордово  устройство  (дата, час, 
номер  на одобрение  на устройството , сериен  номер  на 
устройството ), 
— последно  свързване  към бордово  устройство  (дата, 
час, номер  на одобрение  на устройството , сериен  
номер  на устройството ). 
3.12.11  Данни  за сверяване  на часовника  
124) Уредът  за регистриране  на данните  за движението  трябва  
да регистрира  и записва  данни  в своята  памет , имащи  
отношение  към: сверяванията  на часовника , извършени  
в режим  на калибриране  извън  рамките  на периодичното  
калибриране  (опр. буква  е)): 
— последното  сверяване  на часовника , 
— 5-те най-значителни  сверявания  на часовника , 
125) За всяко  от сверяванията  на часовника  се записват  
следните  данни : 
— дата и час, старата  стойност , 
— дата и час, новата  стойност , 
— наименование  и адрес  на сервиза , 
— номер  на картата  за монтаж  и настройки , държава  
членка , която  я е издала , поколение  на картата  и 
срок  на валидност  на картата . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 43  
3.12.12  Данни  за контролните  дейности  
126) Уредите  за регистриране  на данните  за движението  
записват  и съхраняват  в своята  памет  следните  данни , 
имащи  отношение  към последните  20 контролни  
дейности : 
— дата и час на извършения  контрол , 
— номер  на контролната  карта , държава  членка , която  я 
е издала , и поколение  на картата , 
— тип на контрола  (изобразяване  на данните  и/или 
отпечатване  върху  хартия  и/или изтегляне  на данни  
от бордовото  устройство  и/или изтегляне  на данни  
от картата  и/или пътна  проверка  на калибрирането ). 
127) При извършване  на изтегляне  на данни  се регистрират  
също  така датите  на най-отдалечения  и на най-близкия  
ден във времето , данните  за които  са изтеглени . 
3.12.13  Данни  за блокирания , извършени  от превозвач  
128) Уредите  за регистриране  на данните  за движението  
трябва  да регистрират  и записват  в паметта  си следните  
данни , имащи  отношение  към последните  255 блоки­  
рания , извършени  от превозвача : 
— дата и час на блокирането , 
— дата и час на разблокирането , 
— номер  на картата  на превозвач , държава  членка , която  
я е издала , и поколение  на картата , 
— име и адрес  на превозвач , 
Данните , блокирани  преди  чрез блокиране , което  е 
заличено  от паметта  поради  горепосоченото  ограничение , 
се разглеждат  като неблокирани . 
3.12.14  Изтегляне  на данни  за дейностите  
129) Уредите  за регистриране  на данните  за движението  
трябва  да регистрират  и записват  в паметта  си следните  
данни , имащи  отношение  към последното  изтегляне  на 
данни  от паметта  към външни  носители  в режим  „пре­  
возвач “ или „калибриране “: 
— дата и час на изтеглянето  на данните , 
— номер  на картата  на превозвач  или на картата  за 
монтаж  и настройки , държава  членка , която  я е 
издала , и поколение  на картата , 
— наименование  на превозвача  или на сервиза . 
3.12.15  Данни  за специфични  условия  
130) Уредите  за регистриране  на данните  за движението  
трябва  да регистрират  и записват  в паметта  си следните  
данни , имащи  отношение  към специфични  условия : 
— дата и час на въвеждането , 
— тип на специфичното  условие . 
131) Паметта  трябва  да може  да запазва  данните  за 
специфични  условия  в продължение  на най-малко  365 
дни (като се предполага , че средно  се отваря  и затваря  
1 условие  на ден). Когато  капацитетът  за съхраняване  на 
данни  е изчерпан , новите  данни  трябва  да заместват  най- 
старите  данни . 
3.12.16  Данни  за тахографските  карти  
132) Уредите  за регистриране  на данните  за движението  
трябва  да могат  да записват  следните  данни , свързани  с 
различните  тахографски  карти , в които  са били  
използвани  в бордовото  устройство : 
— номера  на тахографската  карта  и нейния  сериен  
номер , 
— производителя  на тахографската  карта , ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 44  
— типа  на тахографската  карта , 
— версията  на тахографската  карта , 
133) Уредите  за регистриране  на данните  за движението  
трябва  да могат  да запишат  най-малко  88 такива  записа . 
3.13 Четене  на тахографските  карти  
134) Уредите  за регистриране  на данните  за движението  
трябва  при необходимост  да могат  да четат  от тахог­  
рафски  карти  от първо  и второ  поколение  необходимите  
данни : 
— идентификация  на типа  на картата , на титуляря  на 
картата , на използваното  преди  това превозно  
средство , на датата  и часа на последното  изваждане  
на картата  и на дейността , която  е била  избрана  в този 
момент , 
— проверка , че последната  картова  сесия  е била  
приключена  правилно , 
— изчисляване  на времето  на непрекъснато  управление  
на МПС  на водача , общото  време  на прекъсване  и на 
общото  време  на управление  на МПС  за предишната  
и настоящата  седмица , 
— отпечатване  на заявките  за разпечатка , свързани  с 
данните , записани  на карта  на водач , 
— изтегляне  на данни  от карта  на водач  към външен  
носител . 
Това  изискване  се прилага  само  за тахографски  карти  от 
първо  поколение , ако възможността  за използването  им 
не е била  премахната  от сервиз . 
135) При грешка  в четенето , уредите  за регистриране  на 
данните  за движението  трябва  да правят  нов опит , 
максимум  до три пъти , и при наличие  на повтарящ  се 
неуспех , да обявят  картата  за дефектна  и невалидна . 
3.14 Регистриране  и запис  върху  тахографски  карти  
3.14.1  Регистриране  и запис  в тахографски  карти  от първо  
поколение  
136) При условие  че използването  на тахографски  карти  от 
първо  поколение  не е било  премахнато  от сервиз , 
уредите  за регистриране  на данните  за движението  
трябва  да регистрират  и записват  данни  точно  по същия  
начин  както  това би било  извършвано  от уреди  от първо  
поколение  за регистриране  на данните  за движението . 
137) Уредите  за регистриране  на данните  за движението  
трябва  да задават  „данните  за картовата  сесия “ върху  
картата  на водач  или картата  за монтаж  и настройки  
веднага  след  вкарването  на картата . 
138) Уредите  за регистриране  на данните  за движението  
трябва  да актуализират  данните , записани  върху  
валидна  карта  на водач , карта  за монтаж  и настройки , 
карта  на превозвач  и/или контролна  карта , с всички  необ­  
ходими  данни  относно  периода , през който  картата  е 
вкарана , и отнасящи  се за титуляря  ѝ. Данните , 
записвани  върху  тези карти , са специфицирани  в глава  4. 
139) Уредите  за регистриране  на данните  за движението  
трябва  да актуализират  данните  за дейността  на водача  
и местоположенията  (като е специфицирано  в 4.5.3.1.9 и 
4.5.3.1.11), записани  върху  валидни  карта  на водач  и/или 
карта  за монтаж  и настройки , при ръчно  въведени  от 
титуляря  на картата  данни  за дейността  на водача  и 
местоположенията . 
140) Всички  събития , които  не са дефинирани  за уреди  за 
регистриране  на данните  за движението  от първо  поко­  
ление , не трябва  да се записват  върху  картата  на водача  и 
картата  за монтаж  и настройки . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 45  
141) Актуализирането  на данните , записани  на тахографските  
карти  се извършва  по такъв  начин , че когато  това е необ­  
ходимо , като се има предвид  реалният  капацитет  за 
съхраняване  на данни , най-новите  данни  да заместват  
най-старите  данни . 
142) При грешка  в записването , уредите  за регистриране  на 
данните  за движението  трябва  да правят  нов опит , 
максимум  до три пъти , и при повтарящ  се неуспех  да 
обявяват  картата  за невалидна . 
143) Преди  изваждането  на карта  на водач  и след  като всички  
съответни  данни  са записани  върху  картата , уредите  за 
регистриране  на данните  за движението  трябва  да 
инициализират  „данните  за картовата  сесия “. 
3.14.2  Регистриране  и запис  в тахографски  карти  от второ  
поколение  
144) Тахографските  карти  от второ  поколение  трябва  да 
съдържат  2 различни  картови  приложения , първото  от 
които  следва  да бъде  точно  същото  като приложението  
TACHO на тахографските  карти  от първо  поколение , а 
второто  — приложението  „TACHO_G2“, както  е специ­  
фицирано  в глава  4 и допълнение  2. 
145) Уредите  за регистриране  на данните  за движението  
трябва  да задават  „данните  за картовата  сесия “ върху  
картата  на водач  или картата  за монтаж  и настройки  
веднага  след  вкарването  на картата . 
146) Уредите  за регистриране  на данните  за движението  
трябва  да актуализират  данните , записани  върху  2-те 
картови  приложения  на валидна  карта  на водач , карта  
за монтаж  и настройки , карта  на превозвач  и/или 
контролна  карта , с всички  необходими  данни  относно  
периода , през който  картата  е вкарана , и отнасящи  се 
за титуляря  ѝ. Данните , записвани  върху  тези карти , са 
специфицирани  в глава  4. 
147) Уредите  за регистриране  на данните  за движението  
трябва  да актуализират  данните  за местата  на дейността  
на водача  и местоположенията  (както  е специфицирано  в 
4.5.3.1.9, 4.5.3.1.11, 4.5.3.2.9 и 4.5.3.2.11), записани  върху  
валидни  карта  на водач  и/или карта  за монтаж  и наст­  
ройки , при ръчно  въведени  от титуляря  на картата  
данни  за дейността  на водача  и местоположенията . 
148) Актуализирането  на данните , записани  на тахографските  
карти  се извършва  по такъв  начин , че когато  това е необ­  
ходимо , като се има предвид  реалният  капацитет  за 
съхраняване  на данни , най-новите  данни  да заместват  
най-старите  данни . 
149) При грешка  в записването , уредите  за регистриране  на 
данните  за движението  трябва  да правят  нов опит , 
максимум  до три пъти , и при повтарящ  се неуспех  да 
обявяват  картата  за невалидна . 
150) Преди  изваждането  на карта  на водач  и след  като всички  
съответни  данни  са записани  върху  двете  картови  
приложения  на картата , уредите  за регистриране  на 
данните  за движението  трябва  да инициализират  
„данните  за картовата  сесия “. 
3.15 Извеждане  върху  дисплея  
151) Дисплеят  трябва  да бъде  с най-малко  20 символа . 
152) Размерът  на символите  трябва  да бъде  най-малко  5 mm 
височина  и 3,5 mm широчина . 
153) Дисплеят  трябва  да може  да показва  символите , 
определени  в допълнение  1, глава  4 „Набори  от 
символи “. Дисплеят  може  да използва  опростено  пред­  
ставяне  на символите  (напр . букви  с ударения  може  да 
бъдат  изобразени  без ударенията , а малките  букви  може  
да се показват  като главни  букви ). ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 46  
154) Дисплеят  трябва  да е снабден  с подходящо  незасле­  
пяващо  осветяване . 
155) Показанията  трябва  да се виждат  от външната  страна  на 
уредите  за регистриране  на данните  за движението . 
156) Уредите  за регистриране  на данните  за движението  
трябва  да могат  да изобразяват : 
— данните  по подразбиране , 
— данни , свързани  с предупрежденията , 
— данни  относно  достъпа  до менютата , 
— други  данни , поискани  от потребителя . 
Уредите  за регистриране  на данните  за движението  може  
да изобразяват  допълнителна  информация  при поло­  
жение , че тя е ясно  различима  от гореизискваните  инфор­  
мации . 
157) При изобразяването  на данните  на уредите  за регис­  
триране  на данните  за движението  трябва  да се 
използват  пиктограмите  или комбинациите  от 
пиктограми , изброени  в допълнение  3. Могат  да се 
използват  допълнителни  пиктограми  или комбинации  от 
пиктограми  при положение , че те ся ясно  различими  от 
горепосочените  пиктограми  или комбинации  от 
пиктограми . 
158) Дисплеят  трябва  да бъде  винаги  включен , когато  
превозното  средство  е в движение . 
159) Уредите  за регистриране  на данните  за движението  може  
да имат  ръчна  или автоматична  функция  за изключване  
на дисплея , когато  превозното  средство  не е в движение . 
Форматът  на изобразяване  на данните  е специфициран  в 
допълнение  5. 
3.15.1  Изобразяване  по подразбиране  
160) Когато  не е необходимо  да се показва  друга  информация , 
уредите  за регистриране  на данните  за движението  трябва  
да показват  по подразбиране  следното : 
— местното  време  (координирано  универсално  време  
(UTC) + поправка , задавана  от водача ); 
— режима  на работа , 
— текущата  дейност  на водача  и на втория  водач , 
— информация  относно  водача : 
— ако неговата  текуща  дейност  е „управление  на МПС “ 
— текущото  му време  на непрекъснато  управление  на 
МПС  и текущото  му общо  време  на прекъсване , 
— ако неговата  текуща  дейност  не е „управление  на 
МПС “ — текущата  продължителност  на тази 
дейност  (от момента  на нейното  избиране ) и общото  
време  на прекъсване . 
161) Изобразяването  на данните  относно  всеки  водач  трябва  
да бъде  ясно , просто  и недвусмислено . Когато  инфор­  
мацията  за водача  и втория  водач  не може  да бъде  
изобразена  едновременно , уредите  за регистриране  на 
данните  за движението  трябва  да изобразяват  по подраз­  
биране  информацията , отнасяща  се за водача , и трябва  да 
позволяват  на потребителя  да изобрази  информацията  
относно  втория  водач . 
162) Когато  широчината  на изобразяването  не е достатъчна  за 
извеждане  по подразбиране  на режима  на работа , уредите  
за регистриране  на данните  за движението  трябва  за 
кратко  да изобразяват  новия  режим  при всяка  негова  
промяна . 
163) При вкарване  на нова  карта  уредите  за регистриране  на 
данните  за движението  трябва  да изобразяват  за кратко  
време  името  на титуляря  на картата . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 47  
164) Когато  е отворено  условие  „ИЗВЪН  ОБСЕГ “ или 
„ПЪТУВАНЕ  С ФЕРИБОТ /ВЛАК “, по подразбиране  
трябва  да се изобрази  съответната  пиктограма , за да се 
укаже , че това конкретно  условие  е отворено  (текущата  
активна  дейност  на водача  може  да не се изобразява  в 
същото  време ). 
3.15.2  Изобразяване  на предупреждение  
165) Уредите  за регистриране  на данните  за движението  
трябва  да използват  при предупрежденията  най-вече 
пиктограмите , фигуриращи  в допълнение  3, допълнени  
при нужда  от информация  под формата  на цифров  код. 
Може  също  така да се добави  съобщение  за пред­  
упреждение  на езика , избран  от водача . 
3.15.3  Меню  за достъп  
166) Уредите  за регистриране  на данните  за движението  
трябва  да разполагат  с необходимите  команди  чрез 
подходящо  структурирано  меню . 
3.15.4  Изобразяване  на други  данни  
167) При поискване  трябва  да бъде  възможно  избирателно  
показване  на: 
— датата  и часа по координираното  универсално  време , 
както  и поправката  за местното  време , 
— съдържанието  на която  и да е от шестте  разпечатки , 
което  да бъде  в същия  формат  както  самата  
разпечатка , 
— времето  на непрекъснато  управление  на МПС  и 
общото  време  на прекъсване  от водача , 
— времето  на непрекъснато  управление  на МПС  и 
общото  време  на прекъсване  от втория  водач ; 
— общото  време  на управление  от водача  за предишната  
и настоящата  седмица , 
— времето  на непрекъснато  управление  на МПС  на 
втория  водач  за предишната  и настоящата  седмица , 
незадължително : 
— продължителността  на текущата  дейност  на втория  
водач  (от момента  на нейното  избиране ), 
— общото  време  на управление  на МПС  на водача  за 
настоящата  седмица , 
— общото  време  на управление  на МПС  на втория  водач  
за настоящия  дневен  работен  период , 
— общото  време  на управление  на МПС  от водача  за 
настоящия  дневен  работен  период . 
168) Изобразяването  на съдържанието  на разпечатката  на 
хартия  е последователно , ред по ред. Ако широчината  
на изобразяването  е по-малка  от 24 символа , 
потребителят  може  да визуализира  цялата  информация  
чрез съответен  способ  (на няколко  реда , изобразяване  
във вид на безконечен  списък , …)  
При отпечатването  върху  хартия , редовете  предвидени  за 
ръчното  изписване  на информация , могат  да бъдат  
изпуснати . 
3.16 Отпечатване  
169) Уредите  за регистриране  на данните  за движението  
трябва  да могат  да отпечатват  информацията , записана  
в паметта  им и/или върху  тахографските  карти  в съот­  
ветствие  със следните  разпечатки  на хартия : 
— ежедневната  разпечатка  от картата  за дейностите  на 
водача , 
— ежедневната  разпечатка  от бордовото  устройство  за 
дейностите  на водача , 
— разпечатката  от картата  за събитията  и неизправ­  
ностите , ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 48  
— разпечатката  от бордовото  устройство  за събитията  и 
неизправностите , 
— разпечатка  за техническите  данни , 
— разпечатка  за превишаванията  на скоростта . 
— предистория  на данните  върху  тахографската  карта  за 
дадено  бордово  устройство  (вж. глава  3.12.16)  
Подробностите  относно  формата  и съдържанието  на тези 
разпечатки  са специфицирани  в допълнение  4. 
В края  на разпечатките  може  да фигурират  допълнителни  
данни . 
Уредите  за регистриране  на данните  за движението  могат  
също  така да вадят  и други  разпечатки  ако те са ясно  
различими  от гореизброените  седем  разпечатки . 
170) „ежедневната  разпечатка  от картата  за дейностите  на 
водача “ и „разпечатката  от картата  за събитията  и 
неизправностите “ трябва  да са достъпни  само  когато  в 
уредите  за регистриране  на данните  за движението  е 
вкарана  карта  на водач  или карта  за монтаж  и настройки . 
Уредите  за регистриране  на данните  за движението  актуа­  
лизират  данните , записани  на въпросната  карта , преди  да 
стартира  отпечатването . 
171) За да извадят  „ежедневната  разпечатка  от картата  за 
дейностите  на водача “ и „разпечатката  от картата  за 
събитията  и неизправностите “, уредите  за регистриране  
на данните  за движението  трябва : 
— или да избират  автоматично  картата  на водач , или 
картата  за монтаж  и настройки , ако е вкарана  само  
една  от тези карти , 
— или да имат  команда , позволяваща  избирането  на 
картата -източник  на данните , или да избират  
картата , поставена  в процепа  за карта  на водач , ако 
са вкарани  и двете  карти . 
172) Печатащото  устройство  трябва  да може  да отпечатва  24 
символа  на ред. 
173) Минималният  размер  на символите  трябва  да е височина  
2,1 mm и широчина  1,5 mm.  
174) Печатащото  устройство  трябва  да може  да отпечатва  
символите , специфицирани  в допълнение  1, глава  4, 
„Набори  от символи “. 
175) Печатащите  устройства  трябва  да са с такава  
конструкция , че тези разпечатки  да са с ниво  на 
разделителна  способност  достатъчно , за да се избегне  
всяка  двусмисленост  при четенето  им. 
176) Разпечатките  трябва  да запазват  размерите  и съдър­  
жанието  си при нормалните  условия  на влажност  (10- 
90 %) и температура . 
177) Хартията  от одобрен  тип, използвана  от уредите  за регис­  
триране  на данните  за движението , трябва  да бъде  със 
съответен  знак за одобрен  тип и указание  за типа /ти­ 
повете  уреди  за регистриране  на данните  за движението , 
с който /които  може  да бъде  използвана . 
178) Разпечатките  трябва  да остават  четливи  и разпознаваеми  
при нормални  условия  на съхранение , изразени  като 
светлинен  интензитет , влажност  и температура , в 
продължение  на най-малко  две години . 
179) Разпечатките  трябва  да отговарят  минимум  на специфи­  
кациите  за изпитване , определени  в допълнение  9. 
180) Също  така трябва  да бъде  възможно  върху  тези 
документи  да се добавят  бележки , написани  на ръка , 
като например  при подпис  на водача . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 49  
181) При свършване  на хартията  по време  на разпечатване  и 
след  ново  зареждане  с хартия  уредите  за регистриране  на 
данните  за движението  трябва  да започват  разпечатването  
отначало  или продължават  от същото  място , като 
осигуряват  недвусмислена  връзка  с предишната  
разпечатана  част. 
3.17 Предупреждения  
182) Уредите  за регистриране  на данните  за движението  
трябва  да предупреждават  водача  при откриване  на 
някакво  събитие  и/или неизправност . 
183) Предупреждението  относно  прекъсване  на електри­  
ческото  захранване  може  да бъде  забавено  до момента  
на възстановяване  на захранването . 
184) Уредите  за регистриране  на данните  за движението  
трябва  да предупреждават  водача  15 минути  преди  и по 
време  на превишаването  на максималното  позволено  
време  на непрекъснато  управление  на МПС . 
185) Предупрежденията  трябва  да бъдат  визуални . Освен  визу­  
алните  предупреждения  може  да се извършват  и звукови  
предупреждения . 
186) Визуалните  предупреждения  трябва  да бъдат  ясно  
различими  от потребителя , да се появяват  в зрителното  
поле  на водача  и да бъдат  четливи  както  през деня , така и 
през нощта . 
187) Визуалните  предупреждения  могат  да бъдат  вградени  в 
уредите  за регистриране  на данните  за движението , или 
да бъдат  извън  тях. 
188) В последния  случай  те трябва  да са означени  със символ  
„Т“. 
189) Предупрежденията  трябва  да са с продължителност  не 
по-малка  от 30 секунди , освен  ако потребителят  
потвърди  приемането  им чрез натискане  на един  или 
няколко  конкретни  бутона  на уредите  за регистриране  
на данните  за движението . Това  първо  потвърждаване  
на приемането  на предупреждението  не трябва  да 
изтрива  изобразяването  на причината  за предупрежде­  
нието , посочено  в следващия  параграф . 
190) Причината  за съобщението  трябва  да бъде  изобразена  на 
уредите  за регистриране  на данните  за движението  и да 
остане  видима  докато  потребителят  потвърди  приемането  
ѝ чрез конкретен  бутон  или команда  на уредите  за регис­  
триране  на данните  за движението . 
191) Може  да има допълнителни  предупреждения , при 
условие  че те не объркват  водачите  по отношение  на 
дефинираните  по-горе. 
3.18 Изтегляне  на данни  към външни  носители  
192) Уредите  за регистриране  на данните  за движението  
трябва  да позволяват  при поискване  да се изтеглят  
данни , съхранени  в паметта  им или от карта  на водач  
към външни  носители  през съединителя  за калибриране / 
изтегляне  на данни . Уредите  за регистриране  на данните  
за движението  трябва  да актуализират  данните , записани  
върху  съответната  карта , преди  да започнат  изтеглянето . 
193) Освен  това като незадължителна  функция  уредите  за 
регистриране  на данните  за движението  може  при 
всички  режими  на работа  да изтеглят  данни  по друг  
начин  към превозвач , чието  разпознаване  е потвърдено  
чрез този канал . В подобен  случай  така за изтеглените  
данни  важат  правата  за достъп , приложими  в режим  
„превозвач “. 
194) Изтеглянето  на данни  не трябва  нито  да променя , нито  да 
изтрива  записаните  данни . 
195) Електрическият  интерфейс  за съединителя  за калибрира­  
не/изтегляне  на данни  е специфициран  в допълнение  6. 
196) Протоколите  за изтегляне  на данни  са специфицирани  в 
допълнение  7. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 50  
3.19 Връзка  от разстояние  за извършване  на целенасочени  пътни  
проверки  
197) Когато  контактният  ключ  на превозното  средство  е в 
положение  „ВКЛЮЧЕН “, бордовото  устройство  трябва  
да записва  на всеки  60 секунди  в устройството  за 
връзка  от разстояние  най-новите  данни , необходими  за 
извършване  на целенасочени  пътни  проверки . Тези  
данни  трябва  да са кодирани  и с подпис , както  е специ­  
фицирано  в допълнение  11 и допълнение  14. 
198) Данните , които  се проверяват  от разстояние , трябва  да 
бъдат  на разположение  на четците  за връзка  от 
разстояние  чрез безжична  комуникация  от разстояние , 
както  е специфицирано  в допълнение  14. 
199) Данните , необходими  за извършване  на целенасочени  
пътни  проверки , трябва  да се отнасят  за: 
— последния  опит  за нарушаване  на сигурността , 
— най-дълго  прекъсване  на електрическото  захранване , 
— неизправност  на датчика , 
— грешка  в данните  за движението , 
— противоречие  в данните  за движението  на превозното  
средство , 
— управление  без валидна  карта , 
— вкарване  на карта  по време  на управление  на МПС , 
— данни  за сверяването  на часовника , 
— данни  за калибриране , включително  датите  на 
последните  две записани  калибрирания , 
— регистрационния  номер  на превозното  средство , 
— скоростта , регистрирана  от тахографа . 
3.20 Данни , прехвърляни  към допълнителни  външни  устройства  
▼M1 
200) Уредите  за регистриране  на данните  за движението  могат  
да са оборудвани  със стандартизирани  интерфейси , 
позволяващи  регистрираните  или генерираните  от тахог­  
рафите  данни  да се използват  в работен  режим  или в 
режим  на калибриране  от външно  устройство . 
В допълнение  13 е дефиниран  и стандартизиран  незадъл­  
жителен  интерфейс  с ITS. Съвместно  с него  могат  да 
съществуват  други  интерфейси  на бордовото  устройство , 
при условие  че напълно  съответстват  на изискванията  от 
допълнение  13 по отношение  на минималния  списък  от 
данни , сигурността  и съгласието  на водача . 
Изискването  за съгласието  на водача  не се прилага  за 
данните , които  уредите  за регистриране  на данните  за 
движението  предават  към мрежата  на превозното  
средство . Ако постъпилите  в мрежата  на превозното  
средство  лични  данни  се обработват  допълнително  
извън  нея, производителят  на превозното  средство  носи  
отговорност  за това обработването  им да се извършва  в 
съответствие  с разпоредбите  на Регламент  (ЕС) 2016/679 
(Общ  регламент  относно  защитата  на данните ). 
Изискването  за съгласието  на водача  не се прилага  също  
така за данните  от тахографа , извлечени  от превозвач  от 
разстояние  (съгласно  изискването  в подточка  193), тъй 
като този сценарий  се следи  чрез правото  за достъп  на 
картата  на превозвача . 
За ITS данните , предоставяни  чрез този интерфейс , се 
прилагат  следните  изисквания : 
— тези данни  представляват  набор  от избрани  същест­  
вуващи  данни  от речника  на данните  на тахографа  
(допълнение  1), ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 51  
— поднабор  на тези избрани  данни  е отбелязан  като 
„лични  данни “, 
— поднаборът  „лични  данни “ е достъпен  само  ако е 
активирано  удостоверимото  съгласие  на водача , 
който  приема  личните  му данни  да могат  да 
напускат  мрежата  на превозното  средство , 
— съгласието  на водача  може  да бъде  активирано  или 
дезактивирано  във всеки  един  момент  чрез команди  
от менюто , при условие  че е вкарана  картата  на 
водач , 
— наборът  и поднаборът  от данни  се излъчват  чрез 
безжичния  протокол  Bluetooth с обхват  кабината  на 
превозното  средство  при честота  на обновяване  1 
минута , 
— сдвояването  на външното  устройство  с интерфейса  с 
ITS е защитено  чрез специален  за целта  случаен  PIN 
от най-малко  4 числа , записани  във и достъпни  чрез 
дисплея  на всяко  бордово  устройство , 
— наличието  на интерфейс  с ITS при никакви  обстоя­  
телства  не може  да наруши  или да се отрази  на 
правилната  работа  и сигурността  на бордовото  
устройство . 
Може  да има и други  изходни  данни  освен  набора  от 
подбрани  съществуващи  данни , разглеждани  като 
минимален  списък , при условие  че те не могат  да бъдат  
считани  за лични  данни . 
Уредът  за регистриране  на данните  за движението  трябва  
да може  да съобщава  информация  за съгласието  на 
водача  на други  платформи  в мрежата  на превозното  
средство . 
Когато  контактният  ключ  на превозното  средство  е в 
положение  ВКЛЮЧЕН  ДВИГАТЕЛ , тези данни  могат  
да бъдат  излъчвани  постоянно . 
▼B 
201) Серийният  интерфейс , както  е специфициран  в 
приложение  1Б към Регламент  (ЕИО ) № 3821/85, 
последно  изменен , може  да продължи  да бъде  наличен  
в тахографите  с цел обратна  съвместимост . Независимо  
от това, в случай  че се предават  лични  данни  е необ­  
ходимо  съгласието  на водача . 
3.21 Калибриране  
202) Функцията  за калибриране  трябва  да позволява : 
— автоматичното  сдвояване  на датчика  за движение  с 
бордовото  устройство , 
— автоматично  свързване  на външното  устройство  за 
GNSS с бордовото  устройство , ако е приложимо , 
— цифрово  адаптиране  на константата  (k) на уредите  за 
регистриране  на данните  за движението  към характе­  
ристичния  коефициент  на превозното  средство  (w),  
— коригиране  на текущото  време  в рамките  на срока  на 
валидност  на вкараната  карта  за монтаж  и настройки , 
— коригиране  на текущата  стойност  на километражния  
брояч , 
— актуализиране  на данните  за идентификация  на 
датчика  за движение , записани  в паметта  за данни , 
— ако е приложимо , актуализиране  на данните  за иден­  
тификация  на външното  устройство  за GNSS, 
записани  в паметта  за данни , ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 52  
— актуализиране  на типовете  и идентификаторите  на 
всички  поставени  пломби , 
— актуализиране  или потвърждаване  на други  пара­  
метри , известни  на уредите  за регистриране  на 
данните  за движението : идентификация  на превозното  
средство , w, l, размер  на гумите  и настройка  на огра­  
ничителя  на скоростта , ако е приложимо . 
203) Освен  това функцията  за калибриране  трябва  да 
позволява  потискане  на използването  на тахографски  
карти  от първо  поколение  в уредите  за регистриране  на 
данните  за движението , при положение  че са изпълнени  
условията , формулирани  в допълнение  15. 
204) Сдвояването  на датчика  за движение  с бордовото  
устройство , трябва  да се състои  най-малкото  във: 
— актуализиране  на данните  за монтирането  на датчика  
за движение , намиращи  се в него  (при необходимост ), 
— копиране  от паметта  за данни  на датчика  за движение  
в тази на бордовото  устройство  на необходимите  
данни  за идентификация  на датчика  за движение . 
205) Свързването  на външното  устройство  за GNSS с 
бордовото  устройство  трябва  да се състои  най-малкото  
във: 
— актуализиране  на данните  за монтирането  на 
външното  устройство  за GNSS, намиращи  се във 
външното  устройство  за GNSS (при необходимост ), 
— копиране  от външното  устройство  за GNSS към 
паметта  за данни  на бордовото  устройство  на необхо­  
димите  данни  за идентификация  на външното  
устройство  за GNSS, включително  серийния  му 
номер . 
Свързването  трябва  да бъде  последвано  от проверка  на 
информацията  за местоположението  от GNSS.  
206) Функцията  за калибриране  трябва  да позволява  
въвеждането  на необходимите  данни  посредством  съеди­  
нителя  за калибриране  /изтегляне  в съответствие  с 
протокола  за калибриране , дефиниран  в допълнение  8. 
Функцията  за калибриране  може  също  така да 
позволява  въвеждането  на необходимите  данни  по 
други  начини . 
3.22 Пътна  проверка  на калибрирането  
207) Функцията  за пътна  проверка  на калибрирането  трябва  да 
позволява  прочитане  на серийния  номер  на датчика  за 
движение  (евентуално  намиращ  се в адаптера ) и 
серийния  номер  на външното  устройство  за GNSS 
(когато  е приложимо ), свързани  към бордовото  
устройство  към момента  на поискването . 
208) Това  прочитане  трябва  да бъде  възможно  поне  на 
дисплея  на бордовото  устройство  чрез команди  от 
менюто . 
209) Функцията  за пътна  проверка  на калибрирането  трябва  да 
позволява  също  управление  на избора  на входно - 
изходния  режим  на входно -изходната  сигнална  линия  за 
калибриране , специфицирана  в допълнение  6, 
посредством  интерфейса  на линията  K. Това  се 
извършва  чрез ECUAdjustmentSession, както  е специфи­  
цирано  в допълнение  8, раздел  7 „Управление  на изпит­  
вателните  импулси  — Функционален  блок  за управление  
на вход /изход “. 
3.23 Сверяване  на часовника  
210) Функцията  за сверяване  на часовника  трябва  да 
позволява  автоматичното  сверяване  на текущото  време . 
За сверяване  на часовника , в уредите  за регистриране  
на данните  за движението  се използват  два времеви  
източника : 1) вътрешният  часовник  на БУ, 2) приемникът  
на сигнали  от GNSS.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 53  
211) Настройката  на часа на вътрешния  часовник  на 
бордовото  устройство  трябва  да се коригира  автоматично  
на всеки  12 часа. Когато  това не е възможно , тъй като 
няма  сигнал  от GNSS, настройката  на часа трябва  да се 
извършва  веднага , след  като бордовото  устройство  
получи  достъп  до валидно  време  от приемника  на 
сигнали  от GNSS, според  условията  за запалването  на 
двигателя . Еталонното  време  за автоматичната  
настройка  на часа на вътрешния  часовник  на бордовото  
устройство  трябва  да се получава  от приемника  на 
сигнали  от GNSS.  
▼B 
212) Функцията  за сверяване  на часовника  трябва  да 
позволява  също  предизвикано  сверяване  на текущото  
време  в режим  на калибриране . 
3.24 Експлоатационни  характеристики  
213) Бордовото  устройство  трябва  да е напълно  работос­  
пособен  в температурен  обхват  от – 20°C до 70°C, 
външното  устройство  за GNSS в температурен  обхват  
от – 20°C до 70°C, а датчикът  за движение  — в темпе­  
ратурен  обхват  от – 40°C до 135°C. Съдържанието  на 
паметта  трябва  да се запазва  при температури  до – 40°C.  
214) Тахографът  трябва  да е напълно  работоспособен  в обхват  
за влажността  от 10 % до 90 %.  
215) Пломбите , използвани  в интелигентния  тахограф , трябва  
да издържат  на същите  условия  като тези, приложими  за 
компонентите  на тахографа , към които  те са закрепени . 
216) Уредите  за регистриране  на данните  за движението  
трябва  да са защитени  срещу  пренапрежения , размяна  
на полярността  на електрическото  им захранване  и къси  
съединения . 
217) Датчиците  за движение  трябва  или: 
— да реагират  на магнитно  поле , което  смущава  устано­  
вяването  на движението  на превозното  средство . При 
такива  обстоятелства  бордовото  устройство  
регистрира  и записва  неизправност  в датчика  
(изискване  88) или 
— да има чувствителен  елемент , който  е защитен  срещу  
магнитни  полета  или е устойчив  на такива . 
218) Уредите  за регистриране  на данните  за движението  и 
външното  устройство  за GNSS трябва  да съответстват  
на международното  Правило  №10 на ИКЕ  на ООН , и 
трябва  да са защитени  срещу  електростатични  разряди  
и преходни  процеси . 
3.25 Материали  
219) Всички  елементи , съставящи  уредите  за регистриране  на 
данните  за движението , трябва  да бъдат  от материали  с 
достатъчна  стабилност  и механична  здравина , и да имат  
стабилни  електрически  и магнитни  характеристики . 
220) Всички  вътрешни  части  на уредите  трябва  да бъдат  
защитени  от влага  и прах  при нормалните  условия  на 
употреба . 
221) Бордовото  устройство  и външното  устройство  за GNS, 
трябва  да отговарят  на степен  на защита  IP 40, а 
датчикът  за движение  — на степен  на защита  IP 64 по 
смисъла  на стандарт  IEC 2013:1989 включително  A1:1999 
и A2:2013.  
222) Уредите  за регистриране  на данните  за движението  
трябва  да отговарят  на техническите  спецификации , 
свързани  с ергономичното  проектиране . ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 54  
223) Уредите  за регистриране  на данните  за движението  
трябва  да бъдат  защитени  от случайни  повреждания . 
3.26 Маркировки  
224) Ако уредите  за регистриране  на данните  за движението  
визуализират  скоростта  и километража  на превозното  
средство , следните  детайли  трябва  да бъдат  изобразени : 
— до числото , указващо  изминатото  разстояние , мерната  
единица  за разстояние , дадена  със съкращението  
„km“,  
— до числото , показващо  скоростта , указанието  „km/h“.  
Уредите  за регистриране  на данните  за движението  може  
също  така да бъдат  превключени  да изобразяват  
скоростта  в мили  в час, като в този случай  мерната  
единица  за скоростта  трябва  да е указана  със съкра­  
щението  „mph“. Уредите  за регистриране  на данните  за 
движението  може  също  така да бъдат  превключени  да 
изобразяват  разстоянието  в мили , като в този случай  
мерната  единица  за разстоянието  трябва  да е указана  
със съкращението  „mi“.  
▼M1 
225) На всеки  компонент , който  е отделен  от уредите  за регис­  
триране  на данните  за движението , трябва  да се постави  
указателна  табелка  със следните  данни : 
— наименование  и адрес  на производителя , 
— фабричен  номер  от производителя  и година  на 
производство , 
— сериен  номер , 
— знак за одобрение  на типа . 
226) Когато  няма  физическо  място  за всички  горепосочени  
данни , указателната  табелка  трябва  да указва  най-малко  
следното : наименованието  или логотипа  на произво­  
дителя  и фабричния  номер . 
▼B 
4 КОНСТРУКТИВНИ  И ФУНКЦИОНАЛНИ  ИЗИСКВАНИЯ  ЗА 
ТАХОГРАФСКИТЕ  КАРТИ  
4.1 Видими  данни  
Лицевата  страна  трябва  да съдържа : 
227) думите  „карта  на водач “ или „контролна  карта “ или 
„карта  за монтаж  и настройки “ или „карта  на превозвач “, 
отпечатани  с главни  букви  на официалния (ите) 
език(езици ) на държавата  членка , която  е издала  
картата , според  типа  карта . 
228) наименованието  на държавата  членка , която  издала  
картата  (незадължително ); 
229) отличителния  знак на държавата  членка , издала  картата , 
отпечатан  в бяло  на син фон в правоъгълник , ограден  от 
12 жълти  звезди . Отличителните  знаци  са както  следва : 
B 
BG 
CZ 
CY Белгия  
България  
Чешка  република  
Кипър  LV 
L 
LT 
M Латвия  
Люксембург  
Литва  
Малта  
DK Дания  NL  Нидерландия  
D 
EST Германия  
Естония  A 
PL Австрия  
Полша  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 55  
GR Гърция  P 
RO 
SK 
SLO  Португалия  
Румъния  
Словакия  
Словения  
E Испания  FIN  Финландия  
F 
HR 
H Франция  
Хърватия  
Унгария  S Швеция  
IRL Ирландия  UK  Обединено  
кралство  
I Италия  
230) информация , специфична  за издадената  карта , номе­  
рирана  както  следва : 
Карта  на водач  Контролна  карта  Карта  на превозвач  или карта  
за монтаж  и настройки  
1. фамилно  име на водача  наименование  на 
контролния  орган  наименование  на 
превозвача  или на сервиза  
2. собствено (и) име(на) на 
водача  фамилно  име на 
контрольора  
(ако е приложимо ) фамилно  име на титуляря  
на картата  
(ако е приложимо ) 
3. дата на раждане  на водача  собствено (и) име(на) на 
контрольора  
(ако е приложимо ) собствено (и) име(на) на 
титуляря  на картата  
(ако е приложимо ) 
4.a дата на начало  на валидността  на картата  
4.б срок  на валидност  на картата  
4.в наименование  на органа , който  я е издал  (може  да се отпечата  на обратната  страна ) 
4.г номер , различен  от указания  в точка  5, по административни  причини  (незадължи­  
телно ) 
5.а Номер  на свидетелството  
за управление  на МПС  
(към датата  на издаване  
на картата  на водач ) — —  
5.б Номер  на картата  
6. Снимка  на водача  снимка  на контрольора  
(незадължително ) снимка  на монтьора  (неза­  
дължително ) 
7. Подпис  на титуляря  (незадължително ) 
8. Обичайно  място  на преби­  
ваване  или пощенски  
адрес  на титуляря  (неза­  
дължително ) Пощенски  адрес  на 
контролния  орган  Пощенски  адрес  на 
превозвача  или на сервиза  
231) датите  трябва  да са написани  в следния  формат  „дд/ 
мм/гггг“ или „дд.мм.гггг“ (ден, месец , година ). 
Обратната  страна  трябва  да съдържа : 
232) легенда  на номерираните  позиции , налични  върху  
лицевата  страна  на картата ; ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 56  
233) с изрично  писмено  съгласие  на титуляря  на картата , може  
да бъде  добавена  и информация , която  не е свързана  с 
администрирането  на картата , при положение  че това 
добавяне  не променя  с нищо  използването  на модела  
като тахографска  карта . 
234) Преобладаващите  цветове  на фона  при отпечатването  на 
тахографските  карти  трябва  да бъдат  както  следва : 
— карта  на водач : бял, 
— контролна  карта : син, 
— карта  за монтаж  и настройки : червен , 
— карта  на превозвач : жълт . 
235) Тахографските  карти  трябва  да имат  следните  елементи  
на защита  на тялото  на картата  срещу  подправяне  и 
фалшифициране : 
— фон със защитни  характеристики , включващ  мотиви  с 
плетеници  (гилоши ) от тънки  линии  и ирисов  печат , 
— припокриване  на фоновия  защитен  печат  и на 
снимката , 
— поне  една  двуцветна  линия  с микропечат .
 
► (1) M1 
236) След  консултация  с Комисията  държавите  членки  могат  
да добавят  цветове  или маркировки , като например  
националните  символи  и защитни  елементи , без това да 
засяга  другите  разпоредби  на настоящото  приложение . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 57  
237) Временните  карти , посочени  в член  26.4 от Регламент  
(ЕС) №165/2014, трябва  да съответстват  на разпоредбите  
на настоящото  приложение . 
4.2 Сигурност  
Сигурността  на системата  цели  да предпази  целостта  и автен­  
тичността  на данните , обменяни  между  картите  и уредите  за 
регистриране  на данните  за движението , както  и целостта  и 
автентичността  на данните , прехвърляни  от карти , като 
позволява  единствено  извършването  на някои  операции  по 
записване  на данни  върху  картите  на уредите  за регистриране  
на данните  за движението , дешифриране  на определени  данни  
като изключва  всяка  възможност  за фалшифициране  на 
данните , съхранени  на картата , и като открива  всякакъв  опит  
от този вид. 
238) С цел постигане  на сигурност  на системата , тахог­  
рафските  карти  трябва  да отговарят  на изискванията  за 
сигурност , дефинирани  в допълнения  10 и 11. 
239) Тахографските  карти  трябва  да могат  да бъдат  четени  от 
други  устройства , като например  персонални  компютри . 
4.3 Стандарти  
240) Тахографските  карти  трябва  да отговарят  на следните  
стандарти : 
— ISO/IEC 7810 — Идентификационни  карти  — 
физични  характеристики , 
— ISO/IEC 7816 Идентификационни  карти  — Карти  с 
интегрална  схема : 
— Част  1: Физични  характеристики , 
— Част  2: Размери  и разположение  на контактите  
(ISO/IEC 7816-2: 2007),  
— Част  3: Електрически  интерфейс  и протоколи  за 
предаване  (ISO/IEC 7816-3:2006),  
— Част  4: Организация , сигурност  и команди  за 
обмен  (ISO/IEC 7816-4:2013 + Cor 1:2014),  
— Част  6: Вътрешноотраслови  елементи  от данни  за 
взаимен  обмен  (ISO/IEC 7816-6:2004 + Cor 
1:2006),  
— Част  8: Команди  за операции  по сигурността  
(ISO/IEC 7816-8:2004).  
— Тахографските  карти  се изпитват  в съответствие  със 
стандарта  ISO/IEC 10373-3: 2010 Идентификационни  
карти  — методи  за изпитване  — Част  3: Карти  с 
интегрална (и) схема (и) с контакти  и съответни  интер­  
фейсни  устройства  
4.4 Спецификации  във връзка  с околната  среда  и електрически  
спецификации  
241) Тахографските  карти  трябва  да могат  да функционират  
правилно  при всички  климатични  условия , които  
нормално  се наблюдават  на територията  на Общността  
и в минимален  температурен  интервал  от – 25 °C до 
+ 70 °C, с моментни  върхови  стойности  до + 85 °C, 
като „моментни “ означава  продължителност  под 4 часа 
и не повече  от 100 пъти  по време  на живота  на картата . 
242) Тахографските  карти  трябва  да могат  да функционират  
правилно  при интервал  на влажността  от 10 % до 90 %.  
243) Тахографските  карти  трябва  да могат  да функционират  
правилно  през период  от пет години , ако се използват  в 
рамките  на спецификациите  във връзка  с околната  среда  
и електрическите  спецификации . 
244) При функционирането  си тахографските  карти  трябва  да 
са в съответствие  с Правило  № 10 на ИКЕ  на ООН , 
отнасящо  се за електромагнитната  съвместимост  и да 
бъдат  защитени  срещу  електростатични  разряди . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 58  
4.5 Записване  на данни  
За целите  на настоящата  точка , 
— часовете  се регистрират  с точност  от една  минута , освен  ако 
не е предвидено  друго , 
— стойностите  от километражния  брояч  се регистрират  с 
разделителна  способност  един  километър , 
— скоростите  се регистрират  с разделителна  способност  
1 km/h,  
— местоположенията  (ширини  и дължини ) се регистрират  в 
градуси  и минути , с разделителна  способност  1/10 от 
минутата . 
Функциите , командите  и логическите  структури  на тахог­  
рафските  карти , които  отговарят  на изискванията  относно  
записването  на данните , са указани  в допълнение  2. 
Ако не е предвидено  друго , записването  на данни  върху  тахог­  
рафските  карти  трябва  да бъде  организирано  по такъв  начин , че 
новите  данни  да заместват  най-старите  записани  данни , в 
случай  че предвиденият  размер  за конкретните  записи  се 
изчерпа . 
245) В настоящия  параграф  се специфицира  минималният  
капацитет  за съхраняване  на данни  за различните  
файлове  с данни  на приложенията . Тахографските  карти  
трябва  да могат  да указват  на уредите  за регистриране  на 
данните  за движението  реалния  капацитет  за съхранение  
на тези файлове  с данни . 
246) Всякакви  допълнителни  данни , които  могат  да бъдат  
записвани  на тахографски  карти  и свързани  с други  
приложения , евентуално  намиращи  се в картата , се 
записват  в съответствие  с Директива  95/46/ЕО с 
Директива  2002/58/ ЕО и в съответствие  с член  7 от 
Регламент  (ЕС) № 165/2014.  
247) Всеки  главен  файл  (MF) на която  и да било  тахографска  
карта  трябва  да съдържа  до пет елементарни  файла  (EF) 
за управление  на картата , идентификация  на прило­  
женията  и на чипа , както  и два специализирани  файла  
(DF):  
— DF Tachograph, който  съдържа  приложението , 
достъпно  за бордови  устройства  от първо  поколение , 
присъстващо  и в тахографските  карти  от първо  поко­  
ление , 
— DF Tachograph_G2, който  съдържа  приложението , 
достъпно  само  за бордови  устройства  от второ  поко­  
ление , присъстващо  само  в тахографските  карти  от 
второ  поколение . 
Пълните  подробности  за структурата  на тахографските  
карти , са специфицирани  в допълнение  2. 
4.5.1  Елементарни  файлове  за идентификация  на управление  на 
картата  
4.5.2  Идентификация  на картите  с интегрална (и) схема (и) 
248) Тахографските  карти  трябва  да могат  да съхраняват  
следните  данни  за идентификация  на карти  с чип: 
— спиране  на тактовия  генератор , 
— сериен  номер  на картата  (включително  справочни  
данни  за производството ), 
— номер  на одобрението  на картата , 
— идентификация  на организацията  за персонализиране  
на картата  (ID),  
— идентификация  на интегратора , 
— идентификатор  на интегралната  схема . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 59  
4.5.2.1 И д е н т и ф и к а ц и я н а и н т е г р а л н а т а с х е м а 
249) Тахографските  карти  трябва  да могат  да съхраняват  
следните  данни  за идентификация  на интегралната  схема : 
— сериен  номер  на интегралната  схема , 
— справочни  данни  за производството  на интегралната  
схема . 
4.5.2.2 D I R ( и м а г о с а м о в т а х о г р а ф с к и т е к а р т и о т 
в т о р о п о к о л е н и е ) 
250) Тахографските  карти  трябва  да могат  да съхраняват  
обектите  от данни  за идентификация  на приложенията , 
посочени  в допълнение  2. 
4.5.2.3 И н ф о р м а ц и я з а о т г о в о р а н а и н и ц и а л и з и р а н е 
( A T R ) ( у с л о в н а , и м а я с а м о в т а х о г р а ф с к и т е 
к а р т и о т в т о р о п о к о л е н и е ) . 
251) Тахографските  карти  трябва  да могат  да съхраняват  
следния  обекта  от данни  с увеличена  дължина : 
— в случай  че тахографската  карта  дава възможност  за 
полета  с увеличена  дължина  — обекта  от данни  с 
увеличена  дължина , специфициран  в допълнение  2. 
4.5.2.4 И н ф о р м а ц и я з а у в е л и ч е н а д ъ л ж и н а ( у с л о в н а , 
и м а я с а м о в т а х о г р а ф с к и т е к а р т и о т в т о р о 
п о к о л е н и е ) . 
252) Тахографските  карти  трябва  да могат  да съхраняват  
следните  обекти  от данни  с увеличена  дължина : 
— в случай  че тахографската  карта  дава възможност  за 
полета  с увеличена  дължина  — обектите  от данни  с 
увеличена  дължина , специфициран  в допълнение  2. 
4.5.3  Карта  на водач  
4.5.3.1 Т а х о г р а ф с к о п р и л о ж е н и е ( д о с т ъ п н о з а 
б о р д о в и у с т р о й с т в а о т п ъ р в о и в т о р о п о к о ­ 
л е н и е ) 
4.5.3.1.1 Идентификация  на приложенията  
253) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  за идентификация  на приложението : 
— идентификация  на тахографското  приложение , 
— идентификация  на типа  тахографска  карта . 
4.5.3.1.2 Ключ  и сертификати  
254) Картата  на водач  трябва  да позволява  съхраняването  
определен  брой  криптографски  ключове  и сертификати , 
както  е посочено  в допълнение  11, част А. 
4.5.3.1.3 Идентификация  на картата  
255) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  за идентификация  на картата : 
— номер  на картата , 
— държава  членка , издала  картата , наименование  на 
органа , който  я е издал , дата на издаване , 
— дата на начало  на валидността  на картата , дата на 
край  на валидността . 
4.5.3.1.4 Идентификация  на титуляря  на картата  
256) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  за идентификация  на титуляря  на картата : 
— фамилно  име на титуляря , 
— собствено (и) име(на) на титуляря , 
— дата на раждане , 
— предпочитан  език. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 60  
4.5.3.1.5 Изтегляне  на данни  от карта  
257) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  относно  изтеглянето  на данни  от нея: 
— дата и час на последното  изтегляне  на данни  от 
картата  (с цел, различна  от извършването  на контрол ). 
258) Картата  на водача  трябва  да позволява  съхраняването  на 
един  такъв  запис . 
4.5.3.1.6 Информация  за свидетелството  за управление  
259) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  за свидетелството  за управление : 
— държава  членка , наименование  на органа , който  го е 
издал , 
— номер  на свидетелството  за управление  (към датата  на 
издаване  на картата ). 
4.5.3.1.7 Данни  за събития  
За целите  на настоящата  подточка  времето  се регистрира  с 
разделителна  способност  1 секунда . 
260) Картата  на водача  трябва  да позволява  съхраняването  на 
данните , свързани  със следните  събития , засечени  от 
уредите  за регистриране  на данните  за движението  по 
времето , когато  картата  е вкарана : 
— Припокриване  във времето  (когато  дадената  карта  е 
причина  за събитието ), 
— Вкарване  на карта  по време  на управление  на МПС  
(когато  събитието  засяга  дадената  карта ), 
— Неправилно  приключване  на предишна  сесия  (когато  
събитието  засяга  дадената  карта ), 
— Прекъсване  на електрическото  захранване , 
— Грешка  в данните  за движението , 
— Опити  за нарушаване  на сигурността . 
261) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  за тези събития : 
— Код на събитието , 
— Дата  и час на начало  на събитието  (или на вкарването  
на картата  в случай , че в този момент  събитието  е 
било  текущо ), 
— Дата  и час на край  на събитието  (или на изваждането  
на картата  в случай , че в този момент  събитието  е 
било  текущо ), 
— VRN и държава  членка , извършила  регистрацията  на 
превозното  средство , в което  събитието  е настъпило . 
Забележка : За събитието  „Припокриване  във времето “: 
— Датата  и часът  на началото  на събитието  трябва  да 
съответстват  на датата  и часа на изваждане  на 
картата  от предишното  превозно  средство , 
— Датата  и часът  на края  на събитието  трябва  да съот­  
ветстват  на датата  и на часа на вкарването  на картата  
в настоящото  превозно  средство , 
— Данните  за превозното  средство  трябва  да съот­  
ветстват  на настоящото  превозно  средство , в което  
събитието  се е случило . 
Забележка : За събитието  „Неправилно  приключване  на 
предишната  сесия “: 
— Датата  и часът  на началото  на събитието  трябва  да 
съответстват  на датата  и на часа на вкарването  на 
картата , съответстващо  на неправилно  приключената  
сесия , 
— Датата  и часът  на края  на събитието  трябва  да съот­  
ветстват  на датата  и на часа на вкарването  на картата  
за сесията , по време  на която  събитието  е засечено  
(текуща  сесия ), ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 61  
— Данните  за превозното  средство  трябва  да съот­  
ветстват  на превозното  средство , в което  сесията  не 
е била  приключена  правилно . 
262) Картата  на водач  трябва  да позволява  съхраняването  на 
данните  за шестте  последни  събития  от всеки  тип (т.е. 36 
събития ). 
4.5.3.1.8 Данни  за неизправностите  
За целите  на настоящата  подточка  времето  се регистрира  с 
разделителна  способност  1 секунда . 
263) Картата  на водача  трябва  да позволява  съхраняването  на 
данните , свързани  със следните  неизправности , засечени  
от уредите  за регистриране  на данните  за движението  по 
времето , когато  картата  е била  вкарана : 
▼M1 
— Неизправност  на картата  (когато  неизправна  е самата  
карта ), 
▼B 
— Неизправност  в уредите  за регистриране  на данните  за 
движението . 
264) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  за тези неизправности : 
— Код на неизправността , 
— Дата  и час на начало  на неизправността  (или на вкар­  
ването  на картата , в случай  че неизправността  е била  
текуща  в този момент ), 
— Дата  и час на край  на неизправността  (или на изваж­  
дането  на картата , в случай  че неизправността  е била  
текуща  в този момент ), 
— VRN и държава  членка , извършила  регистрацията  на 
превозното  средство , в което  се е появила  неизправ­  
ността . 
265) Картата  на водач  трябва  да позволява  съхраняването  на 
данните  за дванайсетте  последни  неизправности  от всеки  
тип (т.е. 24 неизправности ). 
4.5.3.1.9 Данни  за дейностите  на водача  
266) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  за всеки  календарен  ден, в който  тя се 
използва , или в който  водачът  е въвел  ръчно  дейностите  
си: 
— датата ; 
— брояч  на присъствените  дни (който  се увеличава  с 
една  единица  за всеки  от тези календарни  дни), 
— общо  разстояние , изминато  от водача  през този ден, 
— статус  на водача  в 00:00 часа, 
— всякакви  промени  в дейността  на водача  и/или 
промени  в обстановката  при управление  на МПС , 
и/или вкарване  или изваждане  на картата  на водач : 
— състояние  при управление  на МПС  (ЕКИПАЖ , 
САМ ), 
— процеп  (ВОДАЧ , ВТОРИ  ВОДАЧ ), 
— положение  на картата  (ВКАРАНА , НЕВКАРАНА ), 
— дейност  (управление  на МПС , НА РАЗПОЛО­  
ЖЕНИЕ , РАБОТА , ПРЕКЪСВАНЕ /ПОЧИВКА ), 
— час на промяната . 
267) Паметта  на картата  на водач  трябва  да позволява  съхра­  
няването  на данните  за дейността  на водача  в 
продължение  на най-малко  28 дни (средната  дейност  на 
водач  се определя  като 93 промени  на дейността  на ден). ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 62  
268) Данните , изброени  в изисквания  261, 264 и 266 трябва  да 
бъдат  съхранени  по начин , позволяващ  дейностите  да 
бъдат  открити  по реда  на тяхното  настъпване , дори  в 
случай  на припокриване  във времето . 
4.5.3.1.10 Данни  за използваното  превозно  средство  
269) Картата  на водач  трябва  да позволява  съхраняването  за 
всеки  календарен  ден, в който  тя се използва , и за всеки  
период  на използване  на определено  превозно  средство  
през този ден (периодът  на използване  включва  всички  
последователни  цикли  на вкарване /изваждане  на картата  
в превозното  средство , като се има предвид  самата  
карта ), следните  данни : 
— дата и час на първото  използване  на превозното  
средство  (т.е. първото  вкарване  на картата  за този 
период  на употреба  на превозното  средство , или 
00:00 часа, ако периодът  на използване  е протичал  
по това време ), 
— стойност  на километражния  брояч  на превозното  
средство  в този момент , 
— дата и час на последното  използване  на превозното  
средство  (тоест  последното  изваждане  на картата  за 
този период  на употреба  на превозното  средство , 
или 23:59 часа, ако периодът  на използване  е 
протичал  по това време ), 
— стойност  на километражния  брояч  на превозното  
средство  в този момент , 
— VRN и държава  членка , извършила  регистрацията  на 
превозното  средство . 
270) Картата  на водача  трябва  да позволява  съхраняването  84 
такива  записа . 
4.5.3.1.11 Места , където  дневните  периоди  на работа  започват  и/или 
завършват  
271) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  относно  местоположенията , където  
дневните  периоди  на работа  започват  и/или завършват , 
въведени  от водача : 
— дата и час на въвеждането  (или дата и час, свързани  с 
въвеждането , когато  то се извършва  по време  на 
процедурата  по ръчно  въвеждане ), 
— типа  на въвежданата  информация  (начало  или край , 
условия  на въвеждане  на информацията ), 
— въведените  страна  и област , 
— стойността  от километражния  брояч  на превозното  
средство . 
272) Картата  на водача  трябва  да позволява  съхраняването  
най-малко  42 двойки  такива  записи . 
4.5.3.1.12 Данни  за картовата  сесия  
273) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  относно  превозното  средство , в което  е 
отворена  текущата  сесия : 
— дата и час на отваряне  на сесията  (тоест  на вкарване  
на картата ), с точност  до една  секунда , 
— VRN и държава  членка , извършила  регистрацията  на 
превозното  средство . 
4.5.3.1.13 Данни  за контролните  дейности  
274) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  относно  контролните  дейности : 
— дата и час на извършения  контрол , 
— номер  на контролната  карта , държава  членка , която  я 
е издала , 
— вид на проверката  (изобразяване  на данните  и/или 
отпечатване  и/или изтегляне  на данни  от БУ и/или 
изтегляне  на данни  от картата  (виж забележката )), ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 63  
— изтеглен  период , в случай  на изтегляне , 
— VRN и държава  членка , извършила  регистрацията  на 
превозното  средство , в което  е извършена  проверката . 
Забележка : изтеглянето  от картата  се регистрира  само  
ако се извърши  чрез уреди  за регистриране  на данните  
за движението . 
275) Картата  на водач  трябва  да позволява  съхраняването  на 
един  такъв  запис . 
4.5.3.1.14 Данни  за специфични  условия  
276) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни , свързани  със специфични  условия , 
въведени  докато  картата  е била  вкарана  (независимо  в 
кой процеп ): 
— дата и час на въвеждането , 
— тип на специфичното  условие . 
277) Картата  на водач  трябва  да позволява  съхраняването  
минимум  56 такива  записа . 
4.5.3.2 Т а х о г р а ф с к о п р и л о ж е н и е о т п о к о л е н и е 2 ( н е е 
д о с т ъ п н о з а б о р д о в о у с т р о й с т в о о т п ъ р в о 
п о к о л е н и е ) 
4.5.3.2.1 Идентификация  на приложенията  
278) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  за идентификация  на приложението : 
— Идентификация  на тахографското  приложение , 
— Идентификация  на типа  тахографска  карта . 
4.5.3.2.2 Ключове  и сертификати  
279) Картата  на водач  трябва  да позволява  съхраняването  
определен  брой  криптографски  ключове  и сертификати , 
както  е посочено  в допълнение  11, част Б. 
4.5.3.2.3 Идентификация  на картата  
280) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  за идентификация  на картата : 
— номер  на картата , 
— държава  членка , издала  картата , наименование  на 
органа , който  я е издал , дата на издаване , 
— дата на начало  на валидността  на картата , дата на 
край  на валидността . 
4.5.3.2.4 Идентификация  на титуляря  на картата  
281) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  за идентификация  на титуляря  на картата : 
— фамилно  име на титуляря , 
— собствено (и) име(на) на титуляря , 
— дата на раждане , 
— предпочитан  език. 
4.5.3.2.5 Изтегляне  на данни  от карта  
282) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  относно  изтеглянето  на данни  от нея: 
— дата и час на последното  изтегляне  на данни  от 
картата  (с цел, различна  от извършването  на контрол ). 
283) Картата  на водач  трябва  да позволява  съхраняването  на 
един  такъв  запис . 
4.5.3.2.6 Информация  за свидетелството  за управление  
284) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  за свидетелството  за управление : 
— държава  членка , наименование  на органа , който  го е 
издал , 
— номер  на свидетелството  за управление  (към датата  на 
издаване  на картата ). ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 64  
4.5.3.2.7 Данни  за събития  
За целите  на настоящата  подточка  времето  се регистрира  с 
разделителна  способност  1 секунда . 
285) Картата  на водач  трябва  да позволява  съхраняване  на 
данните , свързани  със следните  събития , засечени  от 
уредите  за регистриране  на данните  за движението  по 
времето , когато  картата  е била  вкарана : 
— Припокриване  във времето  (когато  дадената  карта  е 
причина  за събитието ), 
— Вкарване  на карта  по време  на управление  на МПС  
(когато  събитието  засяга  дадената  карта ), 
— Неправилно  приключване  на предишна  сесия  (когато  
събитието  засяга  дадената  карта ), 
— Прекъсване  на електрическото  захранване , 
— Грешка  в комуникацията  с устройството  за връзка  от 
разстояние , 
— Събитие  „Липса  на информация  за местоположението  
от приемник  на сигнали  от GNSS“  
— Грешка  в комуникацията  с външното  устройство  за 
GNSS  
— Грешка  в данните  за движението , 
— Противоречие  в данните  за движението  на превозното  
средство  
— Опити  за нарушаване  на сигурността , 
— Времеви  конфликт . 
286) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  за тези събития : 
— Код на събитието , 
— Дата  и час на начало  на събитието  (или на вкарването  
на картата  в случай , че събитието  е било  текущо  за 
този момент ), 
— Дата  и час на край  на събитието  (или на изваждането  
на картата  в случай , че в този момент  събитието  е 
било  текущо ), 
— VRN и държава  членка , извършила  регистрацията  на 
превозното  средство , в което  събитието  е настъпило . 
Забележка : За събитието  „Припокриване  във времето “: 
— Датата  и часът  на началото  на събитието  трябва  да 
съответстват  на датата  и часа на изваждане  на 
картата  от предишното  превозно  средство , 
— Датата  и часът  на края  на събитието  трябва  да съот­  
ветстват  на датата  и на часа на вкарването  на картата  
в настоящото  превозно  средство , 
— Данните  за превозното  средство  трябва  да съот­  
ветстват  на настоящото  превозно  средство , в което  
събитието  се е случило . 
Забележка : За събитието  „Неправилно  приключване  на 
предишната  сесия “: 
— Датата  и часът  на началото  на събитието  трябва  да 
съответстват  на датата  и на часа на вкарването  на 
картата , съответстващо  на неправилно  приключената  
сесия , 
— Датата  и часът  на края  на събитието  трябва  да съот­  
ветстват  на датата  и на часа на вкарването  на картата  
за сесията , по време  на която  събитието  е засечено  
(текуща  сесия ), ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 65  
— Данните  за превозното  средство  трябва  да съот­  
ветстват  на превозното  средство , в което  сесията  не 
е била  приключена  правилно . 
287) Картата  на водач  трябва  да позволява  съхраняването  на 
данните  за шестте  последни  събития  от всеки  тип (т.е. 66 
събития ). 
4.5.3.2.8 Данни  за неизправностите  
За целите  на настоящата  подточка  времето  се регистрира  с 
разделителна  способност  1 секунда . 
288) Картата  на водача  трябва  да позволява  съхраняването  на 
данните , свързани  със следните  неизправности , засечени  
от уредите  за регистриране  на данните  за движението  по 
времето , когато  картата  е била  вкарана : 
▼M1 
— Неизправност  на картата  (когато  неизправна  е самата  
карта ), 
▼B 
— Неизправност  в уредите  за регистриране  на данните  за 
движението . 
289) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  за тези неизправности : 
— Код на неизправността , 
— Дата  и час на начало  на неизправността  (или на вкар­  
ването  на картата , в случай  че неизправността  е била  
текуща  в този момент ), 
— Дата  и час на край  на неизправността  (или на изваж­  
дането  на картата , в случай  че неизправността  е била  
текуща  в този момент ), 
— VRN и държава  членка , извършила  регистрацията  на 
превозното  средство , в което  се е появила  неизправ­  
ността . 
290) Картата  на водач  трябва  да позволява  съхраняването  на 
данните  за дванайсетте  последни  неизправности  от всеки  
тип (т.е. 24 неизправности ). 
4.5.3.2.9 Данни  за дейностите  на водача  
291) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  за всеки  календарен  ден, в който  тя се 
използва , или в който  водачът  е въвел  ръчно  дейностите  
си: 
— датата ; 
— брояч  на присъствените  дни (който  се увеличава  с 
една  единица  за всеки  от тези календарни  дни), 
— общо  разстояние , изминато  от водача  през този ден, 
— статус  на водача  в 00:00 часа, 
— всякакви  промени  в дейността  на водача  и/или 
промени  в обстановката  при управление  на МПС , 
и/или вкарване  или изваждане  на картата  на водач : 
— състояние  при управление  на МПС  (ЕКИП , САМ ), 
— процеп  (ВОДАЧ , ВТОРИ  ВОДАЧ ), 
— положение  на картата  (ВКАРАНА , НЕВКАРАНА ), 
— дейност  (управление  на МПС , НА РАЗПОЛО­  
ЖЕНИЕ , РАБОТА , ПРЕКЪСВАНЕ /ПОЧИВКА ). ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 66  
— час на промяната , 
292) Паметта  на картата  на водач  трябва  да позволява  съхра­  
няването  на данните  за дейността  на водача  в 
продължение  на най-малко  28 дни (средната  дейност  на 
водач  се определя  като 93 промени  на дейността  на ден). 
293) Данните , изброени  в изисквания  286, 289 и 291 трябва  да 
бъдат  съхранени  по начин , позволяващ  дейностите  да 
бъдат  открити  по реда  на тяхното  настъпване , дори  в 
случай  на припокриване  във времето . 
4.5.3.2.10 Данни  за използваното  превозно  средство  
294) Картата  на водач  трябва  да позволява  съхраняването  за 
всеки  календарен  ден, в който  тя се използва , и за всеки  
период  на използване  на определено  превозно  средство  
през този ден (периодът  на използване  включва  всички  
последователни  цикли  на вкарване /изваждане  на картата  
в превозното  средство , като се има предвид  самата  
карта ), следните  данни : 
— дата и час на първото  използване  на превозното  
средство  (т.е. първото  вкарване  на картата  за този 
период  на употреба  на превозното  средство , или 
00:00 часа, ако периодът  на използване  е протичал  
по това време ), 
— стойност  на километражния  брояч  на превозното  
средство  в този момент  на първо  използване , 
— дата и час на последното  използване  на превозното  
средство  (тоест  последното  изваждане  на картата  за 
този период  на употреба  на превозното  средство , 
или 23:59 часа, ако периодът  на използване  е 
протичал  по това време ), 
— стойност  на километражния  брояч  на превозното  
средство  в този момент  на последно  използване , 
— VRN и държава  членка , извършила  регистрацията  на 
превозното  средство , 
— VIN на превозното  средство . 
295) Картата  на водач  трябва  да позволява  съхраняването  
минимум  84 такива  записа . 
4.5.3.2.11 Места  и местоположения , където  дневните  периоди  на работа  
започват  и/или завършват  
296) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  относно  местоположенията , където  
дневните  периоди  на работа  започват  и/или завършват , 
въведени  от водача : 
— дата и час на въвеждането  (или дата и час, свързани  с 
въвеждането , когато  то се извършва  по време  на 
процедурата  по ръчно  въвеждане ), 
— типа  на въвежданата  информация  (начало  или край , 
условия  на въвеждане  на информацията ), 
— въведените  страна  и област , 
— стойността  от километражния  брояч  на превозното  
средство , 
— местоположението  на превозното  средство , 
— точността  на ГНСС , датата  и времето , когато  е била  
определено  местоположението . 
297) Картата  на водача  трябва  да позволява  съхраняването  
най-малко  84 двойки  такива  записи . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 67  
4.5.3.2.12 Данни  за картовата  сесия  
298) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  относно  превозното  средство , в което  е 
отворена  текущата  сесия : 
— дата и час на отваряне  на сесията  (тоест  на вкарване  
на картата ), с точност  до една  секунда , 
— VRN и държава  членка , извършила  регистрацията  на 
превозното  средство . 
4.5.3.2.13 Данни  за контролните  дейности  
299) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни  относно  контролните  дейности : 
— дата и час на извършения  контрол , 
— номер  на контролната  карта , държава  членка , която  я 
е издала , 
— вид на проверката  (изобразяване  на данните  и/или 
отпечатване  и/или изтегляне  на данни  от БУ и/или 
изтегляне  на данни  от картата  (виж забележката )), 
— изтеглен  период , в случай  на изтегляне , 
— VRN и държава  членка , извършила  регистрацията  на 
превозното  средство , в което  е извършена  проверката . 
Забележка : Изискванията  за сигурност  предполагат , че 
изтеглянето  от картата  се регистрира  само  ако се 
извърши  чрез уреди  за регистриране  на данните  за 
движението . 
300) Картата  на водач  трябва  да позволява  съхраняването  на 
един  такъв  запис . 
4.5.3.2.14 Данни  за специфични  условия  
301) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни , свързани  със специфични  условия , 
въведени  докато  картата  е била  вкарана  (независимо  в 
кой процеп ): 
— дата и час на въвеждането , 
— тип на специфичното  условие . 
302) Картата  на водач  трябва  да позволява  съхраняването  
минимум  56 такива  записа . 
4.5.3.2.15 Данни  за използваните  бордови  устройства  
303) Картата  на водач  трябва  да позволява  съхраняването  на 
следните  данни , свързани  с различните  бордови  
устройства , в които  е била  използвана : 
— датата  и часа на началото  на периода  на използване  
на превозното  средство  (т.е. първото  вкарване  на 
картата  в бордовото  устройство  през периода ), 
— наименование  на производителя  на бордовото  
устройство , 
— тип на бордовото  устройство , 
— номер  на версията  на софтуера  на бордовото  
устройство . 
304) Картата  на водач  трябва  да позволява  съхраняването  
минимум  84 такива  записа . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 68  
4.5.3.2.16 Данни  за местата  за три часа общо  управление  на МПС  
305) Картата  на водача  трябва  да позволява  съхраняването  на 
следните  данни , свързани  с местоположението  на 
превозното  средство , когато  общото  време  на управление  
на МПС  достигне  кратно  число  на три часа: 
— дата и час, когато  общото  време  на управление  на 
МПС  достигне  кратно  число  на три часа, 
— местоположението  на превозното  средство , 
— точността  на GNSS, датата  и часа, когато  е било  
определено  местоположението , 
— стойността  от километражния  брояч  на превозното  
средство . 
306) Картата  на водач  трябва  да може  да съхранява  най-малко  
252 такива  записа . 
▼B 
4.5.4  Карта  за монтаж  и настройки  
4.5.4.1 Т а х о г р а ф с к о п р и л о ж е н и е ( д о с т ъ п н о з а 
б о р д о в и у с т р о й с т в а о т п ъ р в о и в т о р о п о к о ­ 
л е н и е ) 
4.5.4.1.1 Идентификация  на приложенията  
307) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на следните  данни  за идентификация  на 
приложението : 
— Идентификация  на тахографското  приложение , 
— Идентификация  на типа  тахографска  карта . 
4.5.4.1.2 Ключове  и сертификати  
308) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  определен  брой  криптографски  ключове  и 
сертификати , както  е посочено  в допълнение  11, част А. 
309) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на персонален  идентификационен  номер  
(PIN).  
4.5.4.1.3 Идентификация  на картата  
310) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на следните  данни  относно  идентифи­  
кацията  на картата : 
— номер  на картата , 
— държава  членка , издала  картата , наименование  на 
органа , който  я е издал , дата на издаване , 
— дата на начало  на валидността  на картата , дата на 
край  на валидността . 
4.5.4.1.4 Идентификация  на титуляря  на картата  
311) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на следните  данни  относно  идентифи­  
кацията  на титуляря  на картата : 
— наименование  на сервиза , 
— адрес  на сервиза , 
— фамилно  име на титуляря , 
— собствено (и) име(на) на титуляря , 
— предпочитан  език. 
4.5.4.1.5 Изтегляне  на данни  от карта  
312) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на запис  за изтеглянето  на данни  от 
картата  по същия  начин  като картата  на водач . ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 69  
4.5.4.1.6 Данни  за калибрирането  и сверяването  на часовника  
313) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на записи  за калибрирания  и/или 
сверявания  на часовника , извършени  когато  картата  е 
била  вкарана  в уред  за регистриране  на данните  за движе­  
нието . 
314) Всеки  запис  за калибриране  трябва  да позволява  съхра­  
няване  на следните  данни : 
— Цел на калибрирането  (пускане , първо  монтиране , 
монтиране , периодични  технически  прегледи ), 
— Идентификация  на превозното  средство  
— Актуализирани  или потвърдени  параметри  (w, k, l, 
размер  на гумите , регулировка  на ограничителя  на 
скоростта , километражен  брояч  (стара  и нова  стой­  
ност ), дата и час (стара  и нова  стойност )). 
— Идентификация  на уредите  за регистриране  на 
данните  за движението  (фабричен  и сериен  номер  на 
бордовото  устройство , сериен  номер  на датчика  за 
движение ). 
315) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на най-малко  88 такива  записа . 
316) Картата  за монтаж  и настройки  трябва  да има брояч , 
указващ  общия  брой  на калибриранията , извършени  с 
картата . 
317) Картата  за монтаж  и настройки  трябва  да съдържа  брояч , 
указващ  общия  брой  на калибриранията , извършени  от 
последното  изтегляне  на данни . 
4.5.4.1.7 Данни  за събития  и за неизправности  
318) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на данни  за събитията  и неизправностите  
по същия  начин  като картата  на водач . 
319) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на трите  последни  събития  от всеки  тип 
(т.е. 18 събития ) и на шестте  последни  неизправности  от 
всеки  тип (т.е. 12 неизправности ). 
4.5.4.1.8 Данни  за дейностите  на водача  
320) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на данни  за дейността  на водача  по 
същия  начин  като картата  на водач . 
321) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на данни  за дейността  на водача  за най- 
малко  1 ден средна  дейност  на водача . 
4.5.4.1.9 Данни  за използваното  превозно  средство  
322) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на записи  от данни  за използваните  
превозни  средства  по същия  начин  като картата  на водач . 
323) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на най-малко  4 такива  записа . 
4.5.4.1.10 Данни  относно  края  и/или началото  на дневните  периоди  на 
работа  
324) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на данни  за началото  и/или края  на 
дневните  периоди  на работа  по същия  начин  като 
картата  на водача . 
325) Картата  на водача  трябва  да позволява  съхраняването  на 
най-малко  3 двойки  такива  записи . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 70  
4.5.4.1.11 Данни  за картовата  сесия  
326) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на запис  от данни  за картова  сесия  по 
същия  начин  като картата  на водач . 
4.5.4.1.12 Данни  за контролните  дейности  
327) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на запис  от данни  за контролните  
дейности  по същия  начин  като картата  на водач . 
4.5.4.1.13 Данни  за специфични  условия  
328) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на данни  за специфични  условия  по 
същия  начин  като картата  на водач . 
329) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на най-малко  2 такива  записа . 
4.5.4.2 Т а х о г р а ф с к о п р и л о ж е н и е о т п о к о л е н и е 2 ( н е е 
д о с т ъ п н о з а б о р д о в о у с т р о й с т в о о т п ъ р в о 
п о к о л е н и е ) 
4.5.4.2.1 Идентификация  на приложенията  
330) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на следните  данни  за идентификация  на 
приложението : 
— идентификация  на тахографското  приложение , 
— идентификация  на типа  тахографска  карта . 
4.5.4.2.2 Ключове  и сертификати  
331) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  определен  брой  криптографски  ключове  
и сертификати , както  е посочено  в допълнение  11, част Б. 
332) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на персонален  идентификационен  номер  
(PIN).  
4.5.4.2.3 Идентификация  на картата  
333) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на следните  данни  за идентификацията  
на картата : 
— номер  на картата , 
— държава  членка , издала  картата , наименование  на 
органа , който  я е издал , дата на издаване , 
— дата на начало  на валидността  на картата , дата на 
край  на валидността . 
4.5.4.2.4 Идентификация  на титуляря  на картата  
334) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на следните  данни  относно  идентифи­  
кацията  на титуляря  на картата : 
— наименование  на сервиза , 
— адрес  на сервиза , 
— фамилно  име на титуляря , 
— собствено (и) име(на) на титуляря , 
— предпочитан  език. 
4.5.4.2.5 Изтегляне  на данни  от карта  
335) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на запис  за изтеглянето  на данни  от 
картата  по същия  начин  като картата  на водач . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 71  
4.5.4.2.6 Данни  за калибрирането  и сверяването  на часовника  
336) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на записи  за калибрирания  и/или 
сверявания  на часовника , извършени  когато  картата  е 
била  вкарана  в уред  за регистриране  на данните  за движе­  
нието . 
337) Всеки  запис  за калибриране  трябва  да позволява  съхра­  
няване  на следните  данни : 
— цел на калибрирането  (пускане , първо  монтиране , 
монтиране , периодични  технически  прегледи ), 
— идентификация  на превозното  средство , 
— актуализирани  или потвърдени  параметри  (w, k, l, 
размер  на гумите , регулировка  на ограничителя  на 
скоростта , километражен  брояч  (стара  и нова  стой­  
ност ), дата и час (стара  и нова  стойност )). 
— Идентификация  на уредите  за регистриране  на 
данните  за движението  (фабричен  и сериен  номер  на 
БУ, сериен  номер  на датчика  за движение , сериен  
номер  на устройството  за връзка  от разстояние , 
сериен  номер  на външното  устройство  за GNSS (ако 
е приложимо ), 
— типове  и идентификатори  на всички  поставени  
пломби , 
— способност  на бордовото  устройство  да използва  
тахографски  карти  от първо  поколение  (може  или не). 
338) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на най-малко  88 такива  записа . 
339) Картата  за монтаж  и настройки  трябва  да има брояч , 
указващ  общия  брой  на калибриранията , извършени  с 
картата . 
340) Картата  за монтаж  и настройки  трябва  да съдържа  брояч , 
указващ  общия  брой  на калибриранията , извършени  от 
последното  изтегляне  на данни . 
4.5.4.2.7 Данни  за събития  и за неизправности  
341) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на данни  за събитията  и неизправностите  
по същия  начин  като картата  на водач . 
342) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на трите  последни  събития  от всеки  тип 
(т.е. 33 събития ) и на шестте  последни  неизправности  от 
всеки  тип (т.е. 12 неизправности ). 
4.5.4.2.8 Данни  за дейностите  на водача  
343) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на данни  за дейността  на водача  по 
същия  начин  като картата  на водач . 
344) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на данни  за дейността  на водача  за най- 
малко  1 ден средна  дейност  на водача . 
4.5.4.2.9 Данни  за използваното  превозно  средство  
345) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на записи  от данни  за използваните  
превозни  средства  по същия  начин  като картата  на водач . 
346) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на най-малко  4 такива  записа . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 72  
4.5.4.2.10 Данни  за края  и/или началото  на дневните  периоди  на работа  
347) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на данни  за началото  и/или края  на 
дневните  периоди  на работа  по същия  начин  като 
картата  на водача . 
348) Картата  на водача  трябва  да позволява  съхраняването  на 
най-малко  3 двойки  такива  записи . 
4.5.4.2.11 Данни  за картовата  сесия  
349) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на запис  от данни  за картова  сесия  по 
същия  начин  като картата  на водач . 
4.5.4.2.12 Данни  за контролните  дейности  
350) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на запис  от данни  за контролните  
дейности  по същия  начин  като картата  на водач . 
4.5.4.2.13 Данни  за използваните  бордови  устройства  
351) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на следните  данни , свързани  с различните  
бордови  устройства , в които  е била  използвана : 
— датата  и часа на началото  на периода  на използване  
на превозното  средство  (т.е. първото  вкарване  на 
картата  в бордовото  устройство  през периода ), 
— наименование  на производителя  на бордовото  
устройство , 
— тип на бордовото  устройство , 
— номер  на версията  на софтуера  на бордовото  
устройство . 
352) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на най-малко  4 такива  записа . 
▼M1 
4.5.4.2.14 Данни  за местата  за три часа общо  управление  на МПС  
353) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на следните  данни , свързани  с местополо­  
жението  на превозното  средство , когато  общото  време  на 
управление  на МПС  достигне  кратно  число  на три часа: 
— дата и час, когато  общото  време  на управление  на 
МПС  достигне  кратно  число  на три часа, 
— местоположението  на превозното  средство , 
— точността  на GNSS, датата  и часа, когато  е било  
определено  местоположението , 
— стойността  от километражния  брояч  на превозното  
средство . 
354) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на най-малко  18 такива  записа . 
▼B 
4.5.4.2.15 Данни  за специфични  условия  
355) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на данни  за специфични  условия  по 
същия  начин  като картата  на водач . 
356) Картата  за монтаж  и настройки  трябва  да позволява  
съхраняването  на най-малко  2 такива  записа . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 73  
4.5.5  Контролна  карта  
4.5.5.1 Т а х о г р а ф с к о п р и л о ж е н и е ( д о с т ъ п н о з а 
б о р д о в и у с т р о й с т в а о т п ъ р в о и в т о р о п о к о ­ 
л е н и е ) 
4.5.5.1.1 Идентификация  на приложенията  
357) Контролната  карта  трябва  да позволява  съхраняването  на 
следните  данни  за идентификация  на приложението : 
— идентификация  на тахографското  приложение , 
— идентификация  на типа  тахографска  карта . 
4.5.5.1.2 Ключове  и сертификати  
358) Контролната  карта  трябва  да позволява  съхраняването  
определен  брой  криптографски  ключове  и сертификати , 
както  е посочено  в допълнение  11, част А. 
4.5.5.1.3 Идентификация  на картата  
359) Контролната  карта  трябва  да позволява  съхраняването  на 
следните  данни  относно  идентификацията  на картата : 
— номер  на картата , 
— държава  членка , издала  картата , наименование  на 
органа , който  я е издал , дата на издаване , 
— дата на начало  на валидността  на картата , дата на 
край  на валидността  (при необходимост ). 
4.5.5.1.4 Идентификация  на титуляря  на картата  
360) Контролната  карта  трябва  да позволява  съхраняването  на 
следните  данни  за титуляря  на картата : 
— наименование  на контролния  орган , 
— адрес  на контролния  орган , 
— фамилно  име на титуляря , 
— собствено (и) име(на) на титуляря , 
— предпочитан  език. 
4.5.5.1.5 Данни  за контролните  дейности  
361) Контролната  карта  трябва  да позволява  съхраняването  на 
следните  данни  за контролните  дейности : 
— дата и час на извършената  проверка , 
— вид на проверката  (изобразяване  на данните  и/или 
отпечатване  върху  хартия  и/или изтегляне  на данни  
от бордовото  устройство  и/или изтегляне  на данни  
от картата  и/или пътна  проверка  на калибрирането ). 
— изтеглен  период  (ако има такъв ), 
— VRN и орган  на държавата  членка , регистрирал  
проверяваното  превозно  средство , 
— номер  на проверяваната  карта  на водач  и държава  
членка , която  я е издала . 
362) Контролната  карта  трябва  да позволява  съхраняването  на 
най-малко  230 такива  записи . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 74  
4.5.5.2 Т а х о г р а ф с к о п р и л о ж е н и е о т п о к о л е н и е 2 ( н е е 
д о с т ъ п н о з а б о р д о в о у с т р о й с т в о о т п ъ р в о 
п о к о л е н и е ) 
4.5.5.2.1 Идентификация  на приложенията  
363) Контролната  карта  трябва  да позволява  съхраняването  на 
следните  данни  за идентификация  на приложението : 
— идентификация  на тахографското  приложение , 
— идентификация  на типа  тахографска  карта . 
4.5.5.2.2 Ключове  и сертификати  
364) Контролната  карта  трябва  да позволява  съхраняването  
определен  брой  криптографски  ключове  и сертификати , 
както  е посочено  в допълнение  11, част Б. 
4.5.5.2.3 Идентификация  на картата  
365) Контролната  карта  трябва  да позволява  съхраняването  на 
следните  данни  относно  идентифицирането  на картата : 
— номер  на картата , 
— държава  членка , издала  картата , наименование  на 
органа , който  я е издал , дата на издаване , 
— дата на начало  на валидността  на картата , дата на 
край  на валидността  (ако има). 
4.5.5.2.4 Идентифициране  на титуляря  на картата  
366) Контролната  карта  трябва  да позволява  съхраняването  на 
следните  данни  за титуляря  на картата : 
— наименование  на контролния  орган , 
— адрес  на контролния  орган , 
— фамилно  име на титуляря , 
— собствено (и) име(на) на титуляря , 
— предпочитан  език. 
4.5.5.2.5 Данни  за контролните  дейности  
367) Контролната  карта  трябва  да позволява  съхраняването  на 
следните  данни  за контролните  дейности : 
— дата и час на извършената  проверка , 
— вид на проверката  (изобразяване  на данните  и/или 
отпечатване  върху  хартия  и/или изтегляне  на данни  
от бордовото  устройство  и/или изтегляне  на данни  
от картата  и/или пътна  проверка  на калибрирането ) 
— изтеглен  период  (ако има такъв ), 
— VRN и орган  на държавата  членка , регистрирал  
проверяваното  превозно  средство , 
— номер  на проверяваната  карта  на водач  и държава  
членка , която  я е издала . 
368) Контролната  карта  трябва  да позволява  съхраняването  на 
най-малко  230 такива  записи . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 75  
4.5.6  Карта  на превозвач  
4.5.6.1 Т а х о г р а ф с к о п р и л о ж е н и е ( д о с т ъ п н о з а 
б о р д о в и у с т р о й с т в а о т п ъ р в о и в т о р о п о к о ­ 
л е н и е ) 
4.5.6.1.1 Идентифициране  на приложенията  
369) Картата  на превозвач  трябва  да позволява  съхраняването  
на следните  данни  за идентификация  на приложението : 
— идентификация  на тахографското  приложение , 
— идентификация  на типа  тахографска  карта . 
4.5.6.1.2 Ключове  и сертификати  
370) Картата  на превозвач  трябва  да позволява  съхраняването  
определен  брой  криптографски  ключове  и сертификати , 
както  е посочено  в допълнение  11, част А. 
4.5.6.1.3 Идентифициране  на картата  
371) Картата  на превозвач  трябва  да позволява  съхраняването  
на следните  данни  за идентифицирането  на картата : 
— номер  на картата , 
— държава  членка , издала  картата , наименование  на 
органа , който  я е издал , дата на издаване , 
— дата на начало  на валидността  на картата , дата на 
край  на валидността  (ако има). 
4.5.6.1.4 Идентифициране  на титуляря  на картата  
372) Картата  на превозвач  трябва  да позволява  съхраняването  
на следните  данни  за идентифицирането  на титуляря  на 
картата : 
— наименование  на превозвача , 
— адрес  на превозвача . 
4.5.6.1.5 Данни  относно  дейността  на предприятието  
373) Картата  на превозвач  трябва  да позволява  съхраняването  
на следните  данни  за дейностите  на превозвача : 
— дата и час на дейността , 
— тип на дейността  (блокиране  и/или разблокиране  на 
бордовото  устройство , изтегляне  на данни  от 
бордовото  устройство  и/или от картата ) 
— изтеглен  период  (ако има такъв ), 
— VRN и орган  на държавата  членка , извършил  регист­  
рацията  на превозното  средство , 
— номер  на картата  и държава  членка , която  я е издала  
(при изтегляне  на данни  от картата ). 
374) Картата  на превозвач  трябва  да позволява  съхраняването  
на най-малко  230 такива  записа . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 76  
4.5.6.2 Т а х о г р а ф с к о п р и л о ж е н и е о т п о к о л е н и е 2 ( н е е 
д о с т ъ п н о з а б о р д о в о у с т р о й с т в о о т п ъ р в о 
п о к о л е н и е ) 
4.5.6.2.1 Идентифициране  на приложенията  
375) Картата  на превозвач  трябва  да позволява  съхраняването  
на следните  данни  за идентификация  на приложението : 
— идентификация  на тахографското  приложение , 
— идентификация  на типа  на тахографската  карта . 
4.5.6.2.2 Ключове  и сертификати  
376) Картата  на превозвач  трябва  да позволява  съхраняването  
определен  брой  криптографски  ключове  и сертификати , 
както  е посочено  в допълнение  11, част Б. 
4.5.6.2.3 Идентифициране  на картата  
377) Картата  на превозвач  трябва  да позволява  съхраняването  
на следните  данни  за идентифицирането  на картата : 
— номер  на картата , 
— държава  членка , издала  картата , наименование  на 
органа , който  я е издал , дата на издаване , 
— дата на начало  на валидността  на картата , дата на 
край  на валидността  (ако има). 
4.5.6.2.4 Идентифициране  на титуляря  на картата  
378) Картата  на превозвач  трябва  да позволява  съхраняването  
на следните  данни  за идентифицирането  на титуляря  на 
картата : 
— наименование  на превозвача , 
— адрес  на превозвача . 
4.5.6.2.5 Данни  за дейността  на предприятието  
379) Картата  на превозвач  трябва  да позволява  съхраняването  
на следните  данни  за дейностите  на превозвача : 
— дата и час на дейността , 
— тип на дейността  (блокиране  и/или разблокиране  на 
бордовото  устройство , изтегляне  на данни  от 
бордовото  устройство  и/или от картата ) 
— изтеглен  период  (ако има такъв ), 
— VRN и орган  на държавата  членка , извършил  регист­  
рацията  на превозното  средство , 
— номер  на картата  и държава  членка , която  я е издала  
(при изтегляне  на данни  от картата ). 
380) Картата  на превозвач  трябва  да позволява  съхраняването  
на най-малко  230 такива  записа . 
5 МОНТИРАНЕ  НА УРЕДИ  ЗА РЕГИСТРИРАНЕ  НА ДАННИТЕ  
ЗА ДВИЖЕНИЕТО  
5.1 Монтиране  
381) Новите  уреди  за регистриране  на данните  за движението  
се доставят  неактивирани  на монтьорите  или на произво­  
дителите  на превозното  средство , заедно  с всички  
параметри  на калибрирането , фигуриращи  в списъка  на 
глава  3.21, настроени  на подходящи  и валидни  стойности  
по подразбиране . Когато  не е подходяща  никаква  
определена  стойност , за буквените  параметри  се задават  
низове  от „?“, а за числените  параметри  се задава  „0“). 
Доставянето  на важни  за сигурността  части  на уредите  за 
регистриране  на данните  за движението  може  да бъде  
ограничено  ако това е необходимо  по време  на сертифи­  
цирането  за сигурност . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 77  
382) Преди  своето  активиране  уредите  за регистриране  на 
данните  за движението  трябва  да дадат  достъп  до 
функцията  за калибриране , дори  и да не са в режим  на 
калибриране . 
383) Преди  своето  активиране  уредите  за регистриране  на 
данните  за движението  не трябва  нито  да регистрират , 
нито  да записват  данни , посочени  в точки  3.12.3, 3.12.9 
и 3.12.12 до 3.12.15 включително . 
384) По време  на монтирането  производителите  на превозното  
средство  трябва  да настроят  предварително  всички  
известни  параметри . 
385) Производителите  на превозното  средство  или монтьорите  
трябва  да активират  монтираните  уреди  за регистриране  
на данните  за движението  най-късно  преди  да започне  
използването  на превозното  средство  в обхвата  на 
Регламент  (ЕО) № 561/2006.  
386) Активирането  на уредите  за регистриране  на данните  за 
движението  трябва  да се задейства  автоматично  при 
първото  вкарване  на карта  за монтаж  и настройки  в кое 
да е от интерфейсните  устройства  за карта . 
387) Специфичните  действия  по свързването  на датчика  за 
движение  с бордовото  устройство , ако има такива , 
трябва  да се извършват  автоматично  преди  или по 
време  на активирането . 
388) По подобен  начин  специфични  действия  по свързването  
на външното  устройство  за GNSS с бордовото  
устройство , ако има такива , трябва  да се извършват  авто­  
матично  преди  или по време  на активирането . 
389) След  активирането  си уредите  за регистриране  на 
данните  за движението  трябва  да приложат  в пълна  
степен  контрол  върху  достъпа  до функциите  и данните . 
390) След  активирането  си уредите  за регистриране  на 
данните  за движението  трябва  да съобщят  на устрой­  
ството  за връзка  от разстояние  защитените  данни , необ­  
ходими  за целите  на целенасочените  пътни  проверки . 
391) Регистриращите  и записващите  функции  на уредите  за 
регистриране  на данните  за движението  трябва  да бъдат  
напълно  действащи  след  активирането . 
392) Монтирането  трябва  да бъде  последвано  от калибриране . 
Не е задължително  първоначалното  калибриране  да 
включва  въвеждане  на регистрационния  номер  на 
превозното  средство , когато  той не е известен  на 
одобрения  сервиз , който  трябва  да извърши  това калиб­  
риране . При такива  обстоятелства  и само  по това време  
собственикът  на превозното  средство  трябва  да може  да 
въведе  регистрационния  номер  на превозното  средство  
(VRN), като използва  своята  карта  на превозвач , преди  
да започне  използването  на превозното  средство  в 
обхвата  на Регламент  (ЕО) № 561/2006 ( напр . чрез 
използване  на команди  посредством  подходяща  
структура  от менюта  в интерфейса  „човек  — машина “ 
на бордовото  устройство ) ( 1 ). Актуализирането  или 
потвърждаването  на това въвеждане  трябва  да е 
възможно  само  с използване  на карта  за монтаж  и наст­  
ройки . 
393) За монтирането  на външно  устройство  за GNSS е необ­  
ходимо  свързване  с бордовото  устройство  и последваща  
проверка  на информацията  за местоположението  от 
GNSS.  
394) Уредите  за регистриране  на данните  за движението  
трябва  да бъдат  разположени  така в превозното  
средство , че водачът  да има достъп  до необходимите  
функции  от седалката  си. ▼B 
( 1 ) ОВ L 102, 11.4.2006 г., стр. 1.
 02016R0799 — BG — 26.02.2020 — 002.001 — 78  
5.2 Монтажна  табелка  
395) След  като монтираните  уреди  за регистриране  на данните  
за движението  бъдат  проверени , е необходимо  върху  
уредите  да се прикрепи  монтажна  табелка  (гравирана  
или отпечатана  неизтриваемо ), която  да е добре  видима  
и лесно  достъпна . В случаи , когато  това не е възможно , 
табелката  трябва  да се прикрепи  към средната  колона  на 
автомобилната  каросерия , така че да е добре  видима . За 
превозни  средства , които  нямат  средна  колона  на каросе­  
рията , монтажната  табелка  следва  да бъде  прикрепена  
към рамката  на вратата  от страната  на водача  на 
превозното  средство  и във всички  случаи  да бъде  добре  
видима . 
След  всяко  инспектиране  от страна  на лицензиран  
монтьор  или сервиз , на мястото  на старата  табелка  се 
поставя  нова  такава . 
▼M1 
396) Табелката  трябва  да съдържа  най-малко  следните  данни : 
— име и адрес  или търговско  наименование  на 
одобрения  монтьор  или сервиз , 
— характеристичен  коефициент  на превозното  средство , 
във вида  „w = … импулса /km“,  
— константа  на уредите  за регистриране  на данните  за 
движението , във вида  „k = … импулса /km“,  
— действителна  обиколка  на колелата  с гумите , във вида  
„l = … mm“,  
— размер  на гумите , 
— датата , на която  са измерени  характеристичният  
коефициент  на превозното  средство  и действителната  
обиколка  на колелата  с гумите , 
— идентификационния  номер  на превозното  средство , 
— наличието  (или не) на външно  устройство  за GNSS,  
— серийния  номер  на външното  устройство  за GNSS, 
ако има такова , 
— серийния  номер  на устройството  за връзка  от 
разстояние , ако има такова , 
— серийния  номер  на всички  поставени  пломби , 
— частта  на превозното  средство , на която  е монтиран  
адаптерът , ако има такъв , 
— частта  на превозното  средство , на която  е монтиран  
датчикът  за движение , ако не е свързан  с предава­  
телната  кутия  или не се използва  адаптер , 
— описание  на цвета  на кабела  между  адаптера  и частта  
на превозното  средство , която  изработва  входящите  за 
адаптера  импулси , 
— серийния  номер  на вградения  в адаптера  датчик  за 
движение . 
▼B 
397) Само  за превозни  средства  от категории  M1 и N1, които  
са оборудвани  с адаптер  в съответствие  с Регламент  (ЕО) 
№ 68/2009 на Комисията  ( 1 ) с последните  му изменения , 
и когато  не е възможно  да се включи  цялата  необходима  
информация , както  е описано  в изискване  396, може  да се 
използва  втора , допълнителна  табелка . В такива  случаи  
тази допълнителна  табелка  трябва  да съдържа  поне  
информацията  съгласно  последните  четири  тирета  от 
изискване  396.  ▼B 
( 1 ) Регламент  (ЕО) № 68/2009 на Комисията  от 23 януари  2009 година  за адаптиране  
за девети  път към техническия  прогрес  на Регламент  (ЕИО ) № 3821/85 на Съвета  
относно  контролните  уреди  за регистриране  на данните  за движението  при авто­  
мобилен  транспорт  (ОВ L 21, 24.1.2009 г., стр. 3).
 02016R0799 — BG — 26.02.2020 — 002.001 — 79  
Ако се използва  втора , допълнителна  табелка , тя трябва  
да бъде  поставена  близо  до първата  основна  табелка , 
описана  в изискване  396, и трябва  да е със същото  
ниво  на защита . Освен  това допълнителната  табелка  
трябва  да съдържа  името , адреса  или търговската  марка  
на лицензирания  монтьор  или сервиз , извършил  монти­  
рането , и датата  на монтиране . 
5.3 Пломбиране  
398) Трябва  да бъдат  пломбирани  следните  части : 
— Всяка  връзка , която  ако бъде  прекъсната , би пред­  
извикала  неоткриваеми  промени  или неоткриваема  
загуба  на данни  (това може  да важи  например  за 
монтирането  на датчика  за движение  към предава­  
телната  кутия , адаптера  за превозни  средства  от 
категории  M1/N1, връзката  с външното  устройство  
за ГНСС  или бордовото  устройство ); 
— Монтажната  табелка , освен  ако е прикрепена  по такъв  
начин , че не може  да бъде  отделена  без да се 
разрушат  маркировките  върху  нея. 
▼M1 
398a) Посочените  по-горе пломби  трябва  да бъдат  сертифи­  
цирани  по стандарт  EN 16882:2016.  
▼B 
399) Предвидените  пломби  може  да бъдат  премахнати : 
— В случаите  на извънредни  обстоятелства , 
— С цел монтиране , регулиране  или поправяне  на огра­  
ничител  на скоростта  или на всяко  друго  устройство , 
което  има отношение  към пътната  безопасност , при 
положение  че уредите  за регистриране  на данните  за 
движението  продължават  да функционират  правилно  
и сигурно  и при положение , че той се пломбира  
отново  от лицензиран  монтьор  или сервиз  (съгласно  
глава  6) веднага  след  монтирането  на ограничителя  на 
скоростта  или на всяко  друго  устройство , което  има 
отношение  към пътната  безопасност , или в течение  на 
следващите  7 дена  в другите  случаи . 
400) При всяко  счупване  на тези пломби  се съставя  писмена  
декларация , указваща  причините  за това действие , и тя се 
предоставя  на компетентния  орган . 
401) Пломбите  трябва  да бъдат  с идентификационен  номер , 
зададен  от производителя . Този  номер  трябва  да е 
уникален  и да е различен  от всеки  друг  номер  на 
пломба , зададен  от друг  производител  на пломби . 
▼M1 
Този  уникален  идентификационен  номер  се определя  
като: MMNNNNNNNN чрез неизтриваема  маркировка , 
като ММ е уникална  идентификация  на производителя  
(регистрирането  в базата  данни  се управлява  от ЕК), а 
NNNNNNNN е буквено -цифров  номер  на пломбата , 
който  е уникален  в областта  на производителя . 
▼B 
402) Пломбите  трябва  да имат  свободно  място , където  одоб­  
рените  монтьори , сервизи  или производители  на 
превозни  средства  да могат  да добавят  специална  
маркировка  в съответствие  с член  22, параграф  3 от 
Регламент  (ЕС) № 165/2014.  
Тази  маркировка  не трябва  да закрива  идентифика­  
ционния  номер  на пломбата . 
▼M1 
403) След  като сертифицират  даден  модел  пломба  по стандарт  
EN 16882:2016, производителите  на пломби  трябва  да се 
регистрират  в специална  база данни  и публично  да 
оповестят  своите  идентификационни  номера  на пломби  
чрез процедура , която  ще се определи  от Европейската  
комисия . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 80  
404) За целите  на Регламент  (ЕС) № 165/2014 одобрените  
сервизи  и производители  на превозни  средства  
използват  само  пломби , сертифицирани  по стандарт  EN 
16882:2016, от производители  на пломби , включени  в 
гореспоменатата  база данни . 
▼B 
405) Производителите  на пломби  и техните  разпространители  
трябва  да водят  пълна  ведомост  за проследяемост  на 
пломбите , продавани , за да бъдат  използвани  в рамките  
на Регламент  (ЕС) № 165/2014, и трябва  да са подготвени  
да ги представят  винаги  когато  е необходимо  на компет­  
ентните  национални  органи . 
406) Уникалните  идентификационни  номера  на пломби  трябва  
да се виждат  върху  монтажната  табелка . 
6 ПРОВЕРКИ , ИНСПЕКТИРАНЕ  И ПОПРАВКИ  
Изискванията  относно  обстоятелствата , при които  пломбите  
могат  да бъдат  премахнати , както  е указано  в член  22, 
параграф  5 на Регламент  (ЕС) № 165/2014, са определени  в 
глава  5.3 от настоящото  приложение . 
6.1 Одобряване  на монтьори , сервизи  и производители  на 
превозни  средства  
Държавите  членки  одобряват , контролират  редовно  и серти­  
фицират  органите , натоварени  със следните  задачи : 
— монтирания , 
— проверки , 
— инспекции , 
— поправки . 
Картите  за монтаж  и настройки  се издават  само  на монтьорите  
и/или сервизите , които  са одобрени  да извършват  активирането  
и/или калибрирането  на уредите  за регистриране  на данните  за 
движението  в съответствие  с настоящото  приложение  и които , 
освен  при надлежно  мотивиран  случай : 
— не отговарят  на условията  за получаване  на карта  на 
превозвач ; 
— при които  останалите  професионални  дейности  не са от вид, 
който  да попречи  на общата  сигурност  на системата  както  
се изисква  в допълнение  10. 
▼M1 
6.2 Проверка  на новите  или поправените  компоненти  
407) Всяко  отделно  устройство , било  то ново  или поправено , 
трябва  да бъде  проверено  дали  функционира  правилно  и 
дали  е с точни  показания  и записи , в границите , 
определени  в глави  3.2.1, 3.2.2, 3.2.3 и 3.3. 
▼B 
6.3 Проверка  на монтирането  
▼M1 
408) При монтирането  в превозното  средство  всички  
монтирани  компоненти  (включително  уредите  за регис­  
триране  на данните  за движението ) трябва  да отговарят  
на разпоредбите  относно  максималните  толеранси , 
определени  в глави  3.2.1, 3.2.2, 3.2.3 и 3.3. Всички  
монтирани  компоненти  трябва  да бъдат  пломбирани  в 
съответствие  с глава  5.3, като монтажът  трябва  да 
включва  и калибриране . 
▼B 
6.4 Периодични  технически  прегледи  
409) Извършват  се периодични  технически  прегледи  на 
уредите , монтирани  на превозните  средства , след  всяка  
поправка  или след  всяка  промяна  на характеристичния  
коефициент  на превозното  средство  или на действи­  
телната  обиколка  на търкаляне  на гумите , или когато  
часовникът , показващ  координираното  универсално  
време , е неточен  с повече  от 20 минути , или когато  е 
променен  регистрационният  номер , или най-малко  един  
път на всеки  две години  (24 месеца ). ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 81  
410) Тези  прегледи  трябва  да включват  следните  проверки : 
— за правилно  функциониране  на уредите  за регис­  
триране  на данните  за движението , включително  
функцията  за записване  на данни  в тахографските  
карти  и комуникацията  с четците  за връзка  с цел 
ранно  откриване  от разстояние . 
— че е осигурено  съответствие  с разпоредбите  на глава  
3.2.1 и III.2.2 относно  максималните  толеранси  при 
монтиране , 
— че е осигурено  съответствие  с разпоредбите  на глава  
3.2.3 и 3.3,  
— че уредите  за регистриране  на данните  за движението  
имат  знак за одобрение  на типа , 
— че монтажната  табелка , както  е определено  с 
изискване  396, и указателната  табелка , както  е 
определено  с изискване  225, са поставени , 
— на размера  на гумите  и действителната  обиколка  на 
гумите , 
— за отсъствие  на устройства  за манипулиране , 
прикрепени  към уредите , 
— че пломбите  са правилно  поставени , в добро  
състояние , техните  идентификационни  номера  са 
валидни  (производител  на пломбите  с позоваване  на 
базата  данни  на ЕК) и че техните  идентификационни  
номера  съответстват  на маркировките  върху  
монтажната  табела  (вж. изискване  401).  
411) Ако за едно  от събитията , изброени  в глава  3.9 („От­ 
криване  на събития  и/или неизправности “), е установено , 
че се е случило  след  последното  инспектиране , и то се 
счита  от производителите  на тахографи  и/или от нацио­  
налните  органи  за потенциално  излагащо  на риск  сигур­  
ността  на уредите , сервизът  трябва : 
а. да извърши  съпоставка  на данните  за идентификация  
на датчика  за движение  от свързания  към предава­  
телната  кутия  датчик  за движение , с тези от 
сдвоения  датчик  за движение , регистриран  в 
бордовото  устройство . 
б. да провери  дали  информацията , записана  върху  
монтажната  табелка , съответства  на информацията , 
съдържаща  се в записа  от бордовото  устройство ; 
в. да провери  дали  серийният  номер  на датчика  за 
движение  и номерът  на одобрението  му, ако са 
отпечатани  върху  корпуса  на датчика  за движение , 
съответстват  на информацията , записана  в паметта  за 
данни  на бордовото  устройство ; 
г. да сравни  идентификационните  данни , отбелязани  
върху  указателната  табелка  на външното  устройство  
за GNSS, ако има такова , с тези, записани  в паметта  
за данни  на бордовото  устройство ; 
412) Сервизите  трябва  да записват  в своите  протоколи  от 
проверки  всички  констатации  относно  счупени  пломби  
или за устройства  за манипулиране . Тези  протоколи  
трябва  да се съхраняват  от сервизите  поне  две години  и 
да се предоставят  на компетентния  орган  при всяко  
поискване . 
413) Тези  проверки  трябва  да включват  калибриране  и 
превантивна  замяна  на пломбите , за чието  монтиране  са 
отговорни  сервизите .. 
6.5 Измерване  на грешките  
414) Измерването  на грешките  при монтирането  и по време  на 
използването  трябва  да се осъществява  при следните  
условия , които  се разглеждат  като стандартни  условия  
на изпитване : ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 82  
— превозно  средство  без товар , в готовност  за движение , 
— налягане  в гумите  в съответствие  с указанията  на 
производителя , 
— износване  на гумите  в границите , разрешени  от 
националното  законодателство , 
— движение  на превозното  средство : 
— превозното  средство  трябва  да се движи  напред  под 
действие  на собствения  си двигател , по права  линия  и 
върху  равна  повърхност  със скорост  50 ± 5 km/h. 
Измереното  разстояние  трябва  да бъде  най-малко  
1 000 m.  
— при положение  са със сходна  точност , за това 
изпитание  могат  също  така да бъдат  използвани  
други  методи , като например  подходящ  изпитвателен  
стенд . 
6.6 Поправки  
415) Сервизите  трябва  да могат  да изтеглят  данни  от уредите  
за регистриране  на данните  за движението , за да ги 
върнат  на съответното  транспортно  предприятие  (пре­  
возвач ). 
416) Одобрените  сервизи  трябва  да издават  на транспортните  
предприятия  сертификат , удостоверяващ  че данните  не 
могат  да бъдат  изтеглени , когато  повреда  в уредите  за 
регистриране  на данните  за движението  не позволява  
записаните  данни  да бъдат  изтеглени , дори  след  
поправка  в самия  сервиз . Сервизите  запазват  копие  от 
всеки  издаден  сертификат  в продължение  на най-малко  
две години . 
7 ИЗДАВАНЕ  НА КАРТИ  
Процедурите , прилагани  от държавите  членки  при издаване  на 
картите , трябва  да отговарят  на следните  изисквания : 
417) Номерът  на картата  при първото  издаване  на тахографска  
карта  трябва  да съдържа  пореден  номер  (ако е прило­  
жимо ), индекс  за замяна  и индекс  за подновяване  на 
валидността , зададен  като „0“.  
418) Номерата  на картата  на всички  тахографски  карти , които  
не са поименни  и са издадени  от един  контролен  орган  
или от един  сервиз  или едно  транспортно  предприятие , 
трябва  да са със същите  първи  13 цифри  да са с различен  
пореден  номер . 
419) Тахографска  карта , издадена  за замяна  на друга  същест­  
вуваща  тахографска  карта , трябва  да е със същия  номер  
на картата , като този на заменената  карта , с изключение  
на индекса  за замяна , който  трябва  да се увеличи  с 1 (в 
реда  0, …, 9, А, …, Z).  
420) Тахографска  карта , издадена  за замяна  на друга  същест­  
вуваща  тахографска  карта , трябва  да е със същата  дата на 
край  на валидността  като картата , която  заменя . 
421) Тахографска  карта , издадена  за подновяване  на същест­  
вуваща  тахографска  карта , трябва  да е със същия  номер  
на картата  като номера  на картата , чиято  валидност  
подновява , с изключение  на индекса  за подновяване , 
който  трябва  да се увеличи  с 1 (в реда  0, …, 9, А, …, Z).  
422) Замяната  на съществуваща  тахографска  карта , с цел 
промяна  на административните  данни , трябва  да следва  
правилата , прилагани  при подновяване , ако тя се 
извършва  в рамките  на една  и съща  държава  членка , 
или правилата , прилагани  при първото  издаване , ако се 
извършва  в друга  държава  членка . 
423) „Фамилното  име на титуляря  на картата “ в случая  на 
контролна  карта  или карта  за монтаж  и настройки , 
която  не е поименна , трябва  да бъде  попълнено  с наиме­  
нованието  на сервиза  или на контролния  орган  или с 
името  на монтьора  или на контролиращия  служител , 
ако така бъде  решено  от държавите  членки . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 83  
424) Държавите  членки  трябва  да обменят  данни  по елек­  
тронен  път, за да гарантират  уникалността  на картите  
на водач , които  издават , в съответствие  с член  31 от 
Регламент  (ЕС) № 165/2014.  
8 ОДОБРЕНИЕ  НА ТИПА  НА УРЕДИТЕ  ЗА РЕГИСТРИРАНЕ  
НА ДАННИТЕ  ЗА ДВИЖЕНИЕТО  И НА ТАХОГРАФСКИТЕ  
КАРТИ  
8.1 Общи  положения  
▼M1 
За целите  на настоящата  глава  под „уреди  за регистриране  на 
данните  за движението “ се имат  предвид  уредите  за регис­  
триране  на данните  за движението  или техните  компоненти . 
Не се изисква  одобрение  на типа  на кабела  или кабелите , 
свързващи  датчика  за движение  с бордовото  устройство , 
външното  устройство  за GNSS с бордовото  устройство  или 
външното  устройство  за връзка  от разстояние  с бордовото  
устройство . Хартията , използвана  в уредите  за регистриране  
на данните  за движението , се приема  като компонент  на 
уредите  за регистриране  на данните  за движението . 
Всеки  производител  може  да поиска  одобрение  на типа  на един  
или повече  компоненти  на уредите  за регистриране  на данните  
за движението  с всеки  друг  компонент  или компоненти  на 
такива  уреди , при условие  че всеки  компонент  отговаря  на 
изискванията  от настоящото  приложение . Като  алтернатива , 
производителите  могат  да поискат  и одобряване  на типа  на 
уредите  за регистриране  на данните  за движението . 
Както  се посочва  в член  2, определение  10 от настоящия  
регламент , бордовите  устройства  могат  да включват  различни  
компоненти . С каквито  и компоненти  да е сглобено  бордовото  
устройство , външната  антена  и (ако е приложимо ) високочес­  
тотният  разклонител  за антената , свързан  с приемника  на 
сигнали  от GNSS или с устройството  за връзка  от разстояние , 
не са част от одобрението  на типа  на бордовото  устройство . 
При все това производителите , получили  одобрение  на типа  за 
бордово  устройство , трябва  да поддържат  публично  достъпен  
списък  на съвместимите  антени  и високочестотни  разклонители  
за всяко  получило  одобрение  на типа  бордово  устройство , 
външно  устройство  за GNSS и външно  устройство  за връзка  
от разстояние . 
▼B 
425) Уредите  за регистриране  на данните  за движението  
трябва  да се представят  за одобряване  заедно  с всички  
свои  компоненти , както  и с всички  допълнителни  
устройство , вградени  в тях. 
426) Одобрението  на типа  на уреди  за регистриране  на 
данните  за движението  и на тахографски  карти  трябва  
да включва  изпитвания , свързани  със сигурността , 
изпитвания  на функционирането  и изпитвания  за 
оперативна  съвместимост . Положителните  резултати  от 
всяко  от тези изпитвания  се удостоверяват  чрез 
съответен  сертификат . 
▼M1 
427) Органите  по одобряването  на типа  на държавите  членки  
не предоставят  сертификат  за одобряване  на типа , при 
положение  че при тях няма : 
— сертификат  за сигурност  (ако съгласно  настоящото  
приложение  се изисква  такъв ), 
— сертификат  за функциониране , 
— сертификат  за оперативна  съвместимост  (ако съгласно  
настоящото  приложение  се изисква  такъв ), 
за уредите  за регистриране  на данните  за движението  или 
за тахографската  карта , за които  се иска  одобряване  на 
типа . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 84  
428) Всяка  промяна  на софтуера  или хардуера , или на мате­  
риалите , използвани  при производството , трябва  да бъде  
съобщена  предварително  на органа , който  е издал  
одобрение  на типа  на уредите . Този  орган  трябва  да 
потвърди  на производителя  разширяването  на одоб­  
рението  на типа  или може  да поиска  актуализиране  или 
потвърждаване  на сертификатите  за функционирането , 
сигурността  и/или оперативната  съвместимост . 
429) Процедурите  по обновяване  на място  на софтуера  на 
уредите  за регистриране  на данните  за движението  
трябва  да бъдат  одобрени  от органа , който  е издал  
одобрение  на типа  на въпросните  уреди . Обновяването  
на софтуера  не трябва  да променя  или да изтрива  
никаква  информация  относно  дейността  на водача , 
записана  в уредите  за регистриране  на данните  за движе­  
нието . Софтуерът  може  да бъде  обновяван  само  на 
отговорност  на производителя  на уредите  за регис­  
триране  на данните  за движението . 
430) Одобряването  на типа  на софтуерни  изменения , насочени  
към обновяване  на одобрен  преди  тип уреди  за регис­  
триране  на данните  за движението  не може  да бъде  
отказвано , ако такива  изменения  важат  само  за 
функции , които  не са специфицирани  в настоящото  
приложение . Обновяването  на софтуера  на уредите  за 
регистриране  на данните  за движението  може  да се 
изключва  въвеждането  на нови  набори  от символи , ако 
това не е технически  осъществимо . 
8.2 Сертификат  за сигурност  
431) Сертификатът  за сигурност  се издава  съгласно  
разпоредбите  на допълнение  10 към настоящото  прило­  
жение . Компонентите  на уредите  за регистриране  на 
данните  за движението , които  се сертифицират , са 
бордово  устройство , датчик  за движение , външно  
устройство  за GNSS и тахографските  карти . 
432) При извънредното  обстоятелство  на отказ  на органите  за 
сертифициране  за сигурност  да сертифицират  ново  
оборудване  въз основа  на излизане  от употреба  на меха­  
низмите  за сигурност , издаването  на одобрения  на типа  
трябва  да продължи  само  при това специфично  и 
извънредно  обстоятелство , когато  не съществува  алтер­  
нативно  решение , съответстващо  на регламента . 
433) При това обстоятелство  въпросната  държава  членка  
следва  незабавно  да информира  Европейската  комисия , 
която  в рамките  на двадесет  календарни  месеца  от изда­  
ването  на одобрението  на типа  трябва  да започне  
процедура  за гарантиране , че равнището  на сигурност  е 
възстановено  в неговото  първоначално  състояние . 
8.3 Сертификат  за функциониране  
434) Всеки  кандидат  за одобрение  на типа  трябва  да пред­  
остави  на органа , извършващ  типовото  одобрение  в съот­  
ветната  държава  членка , цялата  материална  част и доку­  
ментацията , които  този орган  смята  за необходими . 
435) Производителите  предоставят  съответните  образци  от 
продукти , за чието  одобрение  на типа  се кандидатства , 
и свързаната  с тях документация , изисквана  от лаборато­  
риите , определени  да извършват  изпитвания  на функцио­  
нирането , в срок  от един  месец  от подаването  на 
искането . Разходите , възникнали  в резултат  на това 
искане , се поемат  от страната , която  го е направила . 
Лабораториите  разглеждат  като поверителна  цялата  
търговска  информация  с чувствителен  характер . 
436) На производителя  се издава  сертификат  за функцио­  
ниране  само  ако всички  изпитвания  за функциониране , 
специфицирани  в допълнение  9, са били  преминати  
успешно . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 85  
437) Сертификатът  за функциониране  се издава  от органа  по 
одобряването  на типа . Освен  името  на притежателя  си и 
наименованието  на модела , този сертификат  трябва  да 
съдържа  подробен  списък  на извършените  изпитвания  и 
на получените  резултати . 
438) В сертификата  за функциониране  на всеки  компонент  на 
уредите  за регистриране  на данните  за движението  трябва  
да се посочват  и номерата  на одобренията  на типа  на 
всички  други  одобрени  съвместими  компоненти  на 
уредите  за регистриране  на данните  за движението , 
изпитани  за сертифицирането . 
439) В сертификата  за функциониране  на всеки  компонент  на 
уредите  за регистриране  на данните  за движението  също  
така трябва  да се посочва  стандарт  ISO или CEN, по 
който  е сертифициран  функционалният  интерфейс . 
8.4 Сертификат  за оперативна  съвместимост  
440) Изпитванията  за оперативна  съвместимост  се извършват  
само  от една  лаборатория  под контрола  и отговорността  
на Европейската  комисия . 
441) Лабораторията  записва  исканията  за провеждане  на 
изпитвания  за оперативна  съвместимост , подадени  от 
производителите , по реда  на тяхното  постъпване . 
442) Исканията  се записват  официално  само  ако лабора­  
торията  разполага  със: 
— цялата  материална  част и необходимите  документи  за 
провеждане  на изпитванията  за оперативна  съвмес­  
тимост , 
— съответния  сертификат  за сигурност , 
— съответния  сертификат  за функциониране , 
Датата  на вписване  на искането  се съобщава  на произво­  
дителя . 
443) Лабораторията  не извършва  изпитвания  за оперативна  
съвместимост  на уреди  за регистриране  на данните  за 
движението  или на тахографски  карти , за които  не е 
издаден  сертификат  за сигурност  и сертификат  за 
функциониране  освен  при извънредното  обстоятелство , 
описано  в изискване  432.  
444) Всеки  производител , поискал  провеждането  на 
изпитвания  за оперативна  съвместимост , трябва  да се 
ангажира  да остави  на лабораторията , натоварена  с 
изпитванията , цялата  материална  част и документацията , 
необходими  за целите  на изпитванията . 
445) Изпитванията  за оперативна  съвместимост  се провеждат  
в съответствие  с разпоредбите  на допълнение  9 към 
настоящото  приложение , съответни  с всички  типове  
уреди  за регистриране  на данните  за движението  или 
тахографски  карти : 
— валидността  на одобрението  на типа  на които  не е 
изтекла  или 
— чието  одобрение  на типа  се извършва  в момента  и за 
които  съществува  валиден  сертификат  за оперативна  
съвместимост . 
446) Изпитванията  за оперативна  съвместимост  трябва  да 
обхващат  всички  поколения  уреди  за регистриране  на 
данните  за движението  или тахографски  карти , които  
все още са в употреба . 
447) Сертификатът  за оперативна  съвместимост  трябва  да бъде  
издаден  на производителя  от лабораторията , само  след  
като са преминати  успешно  всички  изпитвания  за 
оперативна  съвместимост . 
448) Ако изпитванията  за оперативна  съвместимост  не са 
преминати  успешно  от един  или от няколко  уреда  за ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 86  
регистриране  на данните  за движението  или от тахог­  
рафска (и) карта (и), сертификат  за оперативна  съвмес­  
тимост  не се издава , докато  заявилият  производител  не 
направи  необходимите  промени  и не премине  изпит­  
ванията  за оперативна  съвместимост . Лабораторията  
трябва  да установи  причината  за проблема  с помощта  
на съответния  производител  и се опитва  да му помогне  
при търсенето  на техническо  решение . В случай  че 
производителят  е променил  продукта  си, той трябва  да 
се увери , като се обърне  към компетентните  органи , че 
сертификатът  за сигурност  и на сертификатът  за 
функциониране  са все още валидни . 
449) Сертификатът  за възможността  за взаимна  работа  важи  6 
месеца . Той изтича  в края  на този период , ако произво­  
дителят  не е получил  съответния  сертификат  за типово  
одобрение . Той се предава  от производителя  на органа , 
извършващ  типовото  одобрение  в държавата  членка , 
която  е издала  сертификата  за функциониране . 
450) Всеки  елемент , който  би могъл  да предизвика  
неизправност  свързана  с оперативната  съвместимост , не 
трябва  да се използва  за извличане  на печалба  или за 
придобиване  на доминиращо  положение  на пазара . 
8.5 Сертификат  за одобрение  на типа  
451) Органът , извършващ  одобряването  на типа  в държавата  
членка , може  да издаде  сертификат  за одобряване  на 
типа , при положение  че при него  са налице  трите  
изисквани  сертификата . 
452) В сертификата  за одобряване  на типа  на всеки  компонент  
на уредите  за регистриране  на данните  за движението  
трябва  да се посочват  и номерата  на одобрението  на 
типа  на другите  одобрени  съвместими  компоненти  на 
уреди  за регистриране  на данните  за движението . 
453) Копие  от сертификата  за одобряване  на типа  трябва  да 
бъде  предадено  от органа  по одобряването  на типа  на 
лабораторията , натоварена  с изпитванията  за оперативна  
съвместимост , в момента  на издаването  на този документ  
на производителя . 
454) Лабораторията , отговаряща  за изпитванията  за 
оперативна  съвместимост , трябва  да има публична  
интернет  страница , на която  да се актуализира  списъкът  
на моделите  на уредите  за регистриране  на данните  за 
движението  или на тахографски  карти : 
— за които  е било  регистрирано  искане  за провеждане  
на изпитвания  за оперативна  съвместимост , 
— които  са получили  сертификат  за оперативна  съвмес­  
тимост  (дори  и временен ), 
— които  са получили  сертификат  за одобряване  на типа . 
8.6 Извънредна  процедура : първи  сертификати  за оперативна  
съвместимост  за уреди  за регистриране  на данните  за 
движението  и тахографски  карти  от 2-ро поколение  
455) За период  от 4 месеца  след  като една  първа  двойка  от 
уреди  за регистриране  на данните  за движението  от 2-ро 
поколение  и тахографски  карти  от 2-ро поколение  (карта  
на водач , карта  за монтаж  и настройки , контролна  карта  и 
карта  на превозвач ) е била  призната  за оперативно  
съвместима , всеки  издаден  сертификат  за оперативна  
съвместимост  (включително  първия ), имащ  отношение  
към заявките , получени  през този период , се счита  за 
временен . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 87  
456) След  изтичане  на този период , ако всички  въпросни  
продукти  са оперативно  съвместими , всички  съответни  
сертификати  за оперативна  съвместимост  стават  оконча­  
телни . 
457) Ако по време  на този период  се появят  неизправности , 
свързани  с оперативната  съвместимост , лабораторията , 
натоварена  с провеждането  на изпитванията  за 
оперативна  съвместимост , трябва  да определи  
причините  за проблемите  с помощта  на всички  
участващи  производители  и да прикани  последните  да 
направят  необходимите  промени . 
458) Ако в края  на този период  проблемите , свързани  с опера­  
тивната  съвместимост , все още са налице , лабораторията , 
натоварена  с провеждането  на изпитванията , в сътрудни­  
чество  със заинтересованите  производители  и с органите  
по одобряването  на типа , определя  причините  за 
неизправностите , свързани  с оперативната  съвместимост , 
и определя  промените , които  всеки  заинтересован  
производител  трябва  да направи . Търсенето  на 
технически  решения  може  да продължи  най-много  два 
месеца , след  което  Комисията , при липса  на общо  
решение  и след  консултация  с лабораторията , натоварена  
с извършването  на изпитванията  за оперативна  съвмес­  
тимост , решава  на кой(кои) уред (и) и карти  ще се 
издаде  окончателен  сертификат  за оперативна  съвмес­  
тимост , като уточнява  причините  за своя  избор . 
459) Всяко  искане  за извършване  на изпитвания  за оперативна  
съвместимост , заведено  от лабораторията  във времето  от 
края  на периода  от четири  месеца  след  издаване  на 
първия  временен  сертификат  за оперативна  съвместимост  
до датата  на вземане  на решение  от Комисията , посочена  
в изискване  455, се отлага  до решаване  на първона­  
чалните  проблеми , свързани  с оперативната  съвмес­  
тимост . Тези  искания  след  това се обработват  в реда  на 
тяхното  завеждане . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 88  
Допълнение  1 
РЕЧНИК  НА ДАННИТЕ  
СЪДЪРЖАНИЕ  
1. ВЪВЕДЕНИЕ  
1.1. Подход  към определенията  на типовете  данни  
1.2. Справочни  материали  
2. ОПРЕДЕЛЕНИЯ  НА ТИПОВЕТЕ  ДАННИ  
2.1. ActivityChangeInfo  
2.2. Address  
2.3. AESKey  
2.4. AES128Key  
2.5. AES192Key  
2.6. AES256Key  
2.7. BCDString  
2.8. CalibrationPurpose  
2.9. CardActivityDailyRecord  
2.10. CardActivityLengthRange  
2.11. CardApprovalNumber  
2.12. CardCertificate  
2.13. CardChipIdentification  
2.14. CardConsecutiveIndex  
2.15. CardControlActivityDataRecord  
2.16. CardCurrentUse  
2.17. CardDriverActivity  
2.18. CardDrivingLicenceInformation  
2.19. CardEventData  
2.20. CardEventRecord  
2.21. CardFaultData  
2.22. CardFaultRecord  
2.23. CardIccIdentification  
2.24. CardIdentification  
2.25. CardMACertificate  
2.26. CardNumber  
2.27. CardPlaceDailyWorkPeriod  
2.28. CardPrivateKey  
2.29. CardPublicKey  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 89  
2.30. CardRenewalIndex  
2.31. CardReplacementIndex  
2.32. CardSignCertificate  
2.33. CardSlotNumber  
2.34. CardSlotsStatus  
2.35. CardSlotsStatusRecordArray  
2.36. CardStructureVersion  
2.37. CardVehicleRecord  
2.38. CardVehiclesUsed  
2.39. CardVehicleUnitRecord  
2.40. CardVehicleUnitsUsed  
2.41. Certificate  
2.42. CertificateContent  
2.43. CertificateHolderAuthorisation  
2.44. CertificateRequestID  
2.45. CertificationAuthorityKID  
2.46. CompanyActivityData  
2.47. CompanyActivityType  
2.48. CompanyCardApplicationIdentification  
2.49. CompanyCardHolderIdentification  
2.50. ControlCardApplicationIdentification  
2.51. ControlCardControlActivityData  
2.52. ControlCardHolderIdentification  
2.53. ControlType  
2.54. CurrentDateTime  
2.55. CurrentDateTimeRecordArray  
2.56. DailyPresenceCounter  
2.57. Datef  
2.58. DateOfDayDownloaded  
2.59. DateOfDayDownloadedRecordArray  
2.60. Distance  
2.61. DriverCardApplicationIdentification  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 90  
2.62. DriverCardHolderIdentification  
▼M1 
2.63. Reserved for future use  
▼B 
2.64. EGFCertificate  
2.65. EmbedderIcAssemblerId  
2.66. EntryTypeDailyWorkPeriod  
2.67. EquipmentType  
2.68. EuropeanPublicKey  
2.69. EventFaultRecordPurpose  
2.70. EventFaultType  
2.71. ExtendedSealIdentifier  
2.72. ExtendedSerialNumber  
2.73. FullCardNumber  
2.74. FullCardNumberAndGeneration  
2.75. Generation  
2.76. GeoCoordinates  
2.77. GNSSAccuracy  
▼M1 
2.78. GNSSAccumulatedDriving  
2.79. GNSSAccumulatedDrivingRecord  
▼B 
2.80. GNSSPlaceRecord  
2.81. HighResOdometer  
2.82. HighResTripDistance  
2.83. HolderName  
2.84. InternalGNSSReceiver  
2.85. K-ConstantOfRecordingEquipment  
2.86. KeyIdentifier  
2.87. KMWCKey  
2.88. Language  
2.89. LastCardDownload  
2.90. LinkCertificate  
2.91. L-TyreCircumference  
2.92. MAC  
2.93. ManualInputFlag  
2.94. ManufacturerCode  
2.95. ManufacturerSpecificEventFaultData  
2.96. MemberStateCertificate  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 91  
2.97. MemberStateCertificateRecordArray  
2.98. MemberStatePublicKey  
2.99. Name  
2.100. NationAlpha  
2.101. NationNumeric  
2.102. NoOfCalibrationRecords  
2.103. NoOfCalibrationsSinceDownload  
2.104. NoOfCardPlaceRecords  
2.105. NoOfCardVehicleRecords  
2.106. NoOfCardVehicleUnitRecords  
2.107. NoOfCompanyActivityRecords  
2.108. NoOfControlActivityRecords  
2.109. NoOfEventsPerType  
2.110. NoOfFaultsPerType  
▼M1 
2.111. NoOfGNSSADRecords  
▼B 
2.112. NoOfSpecificConditionRecords  
2.113. OdometerShort  
2.114. OdometerValueMidnight  
2.115. OdometerValueMidnightRecordArray  
2.116. OverspeedNumber  
2.117. PlaceRecord  
2.118. PreviousVehicleInfo  
2.119. PublicKey  
2.120. RecordType  
2.121. RegionAlpha  
2.122. RegionNumeric  
2.123. RemoteCommunicationModuleSerialNumber  
2.124. RSAKeyModulus  
2.125. RSAKeyPrivateExponent  
2.126. RSAKeyPublicExponent  
2.127. RtmData  
2.128. SealDataCard  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 92  
2.129. SealDataVu  
2.130. SealRecord  
2.131. SensorApprovalNumber  
2.132. SensorExternalGNSSApprovalNumber  
2.133. SensorExternalGNSSCoupledRecord  
2.134. SensorExternalGNSSIdentification  
2.135. SensorExternalGNSSInstallation  
2.136. SensorExternalGNSSOSIdentifier  
2.137. SensorExternalGNSSSCIdentifier  
2.138. SensorGNSSCouplingDate  
2.139. SensorGNSSSerialNumber  
2.140. SensorIdentification  
2.141. SensorInstallation  
2.142. SensorInstallationSecData  
2.143. SensorOSIdentifier  
2.144. SensorPaired  
2.145. SensorPairedRecord  
2.146. SensorPairingDate  
2.147. SensorSCIdentifier  
2.148. SensorSerialNumber  
2.149. Signature  
2.150. SignatureRecordArray  
2.151. SimilarEventsNumber  
2.152. SpecificConditionRecord  
2.153. SpecificConditions  
2.154. SpecificConditionType  
2.155. Speed  
2.156. SpeedAuthorised  
2.157. SpeedAverage  
2.158. SpeedMax  
2.159. TachographPayload  
▼M1 
2.160. Reserved for future use  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 93  
2.161. TDesSessionKey  
2.162. TimeReal  
2.163. TyreSize  
2.164. VehicleIdentificationNumber  
2.165. VehicleIdentificationNumberRecordArray  
2.166. VehicleRegistrationIdentification  
2.167. VehicleRegistrationNumber  
2.168. VehicleRegistrationNumberRecordArray  
2.169. VuAbility  
2.170. VuActivityDailyData  
2.171. VuActivityDailyRecordArray  
2.172. VuApprovalNumber  
2.173. VuCalibrationData  
2.174. VuCalibrationRecord  
2.175. VuCalibrationRecordArray  
2.176. VuCardIWData  
2.177. VuCardIWRecord  
2.178. VuCardIWRecordArray  
2.179. VuCardRecord  
2.180. VuCardRecordArray  
2.181. VuCertificate  
2.182. VuCertificateRecordArray  
2.183. VuCompanyLocksData  
2.184. VuCompanyLocksRecord  
2.185. VuCompanyLocksRecordArray  
2.186. VuControlActivityData  
2.187. VuControlActivityRecord  
2.188. VuControlActivityRecordArray  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 94  
2.189. VuDataBlockCounter  
2.190. VuDetailedSpeedBlock  
2.191. VuDetailedSpeedBlockRecordArray  
2.192. VuDetailedSpeedData  
2.193. VuDownloadablePeriod  
2.194. VuDownloadablePeriodRecordArray  
2.195. VuDownloadActivityData  
2.196. VuDownloadActivityDataRecordArray  
2.197. VuEventData  
2.198. VuEventRecord  
2.199. VuEventRecordArray  
2.200. VuFaultData  
2.201. VuFaultRecord  
2.202. VuFaultRecordArray  
▼M1 
2.203. VuGNSSADRecord  
2.204. VuGNSSADRecordArray  
▼B 
2.205. VuIdentification  
2.206. VuIdentificationRecordArray  
2.207. VuITSConsentRecord  
2.208. VuITSConsentRecordArray  
2.209. VuManufacturerAddress  
2.210. VuManufacturerName  
2.211. VuManufacturingDate  
2.212. VuOverSpeedingControlData  
2.213. VuOverSpeedingControlDataRecordArray  
2.214. VuOverSpeedingEventData  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 95  
2.215. VuOverSpeedingEventRecord  
2.216. VuOverSpeedingEventRecordArray  
2.217. VuPartNumber  
2.218. VuPlaceDailyWorkPeriodData  
2.219. VuPlaceDailyWorkPeriodRecord  
2.220. VuPlaceDailyWorkPeriodRecordArray  
2.221. VuPrivateKey  
2.222. VuPublicKey  
2.223. VuSerialNumber  
2.224. VuSoftInstallationDate  
2.225. VuSoftwareIdentification  
2.226. VuSoftwareVersion  
2.227. VuSpecificConditionData  
2.228. VuSpecificConditionRecordArray  
2.229. VuTimeAdjustmentData  
▼M1 
2.230. Reserved for future use  
2.231. Reserved for future use  
▼B 
2.232. VuTimeAdjustmentRecord  
2.233. VuTimeAdjustmentRecordArray  
2.234. WorkshopCardApplicationIdentification  
2.235. WorkshopCardCalibrationData  
2.236. WorkshopCardCalibrationRecord  
2.237. WorkshopCardHolderIdentification  
2.238. WorkshopCardPIN  
2.239. W-VehicleCharacteristicConstant  
2.240. VuPowerSupplyInterruptionRecord  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 96  
2.241. VuPowerSupplyInterruptionRecordArray  
2.242. VuSensorExternalGNSSCoupledRecordArray  
2.243. VuSensorPairedRecordArray  
3. ОПРЕДЕЛЕНИЯ  НА ДИАПАЗОНИТЕ  ОТ СТОЙНОСТИ  И 
РАЗМЕРИ  
4. НАБОР  ОТ СИМВОЛИ  
5. КОДИРАНЕ  
6. ИДЕНТИФИКАТОРИ  НА ОБЕКТИ  И ИДЕНТИФИКАТОРИ  НА 
ПРИЛОЖЕНИЯ  
6.1. Идентификатори  на обекти  
6.2. Идентификатори  на приложения  
1. ВЪВЕДЕНИЕ  
В настоящото  допълнение  са посочени  форматите , елементите  и 
структурата  на данните , използвани  от уредите  за регистриране  на 
данните  за движението  и тахографските  карти . 
1.1. Подход  към определенията  на типовете  данни  
В настоящото  допълнение  се използва  абстрактно  означаване  на 
синтаксиса  на информационна  единица  (ASN.1) за определяне  на 
различните  типове  данни . Тази  система  позволява  дефинирането  
на прости  и структурирани  данни , без да има нужда  от използване  
на специфичен  синтаксис  за трансфер  (правила  за кодиране ), които  
да зависят  от съответното  приложение  и среда . 
Правилата  за наименуване  от тип ASN.1 се изготвят  съгласно  
стандарт  ISO/IЕС 8824-1. От това следва , че: 
— в рамките  на възможното  значението  на определен  тип данни  
става  ясно  от избраните  имена , 
— ако определен  тип данни  се състои  от други  типове  данни , 
името  на този тип се представя  винаги  под формата  на една - 
единствена  последователност  от буквени  символи , започваща  с 
главна  буква , въпреки  че главните  букви  се използват  в името , 
за да предадат  съответното  значение , 
— по принцип  имената  на типовете  данни  са свързани  с името  на 
типовете  данни , от които  са съставени , с оборудването , в което  
данните  се съхраняват , и с функцията , която  е асоциирана  към 
съответните  данни . 
Ако тип ASN.1 вече е дефиниран  като част от друг  стандарт  и ако е 
от значение  за използването  в уредите  за регистриране  на данните  
за движението , тогава  този тип ASN.1 се дефинира  в настоящото  
допълнение . 
За да е възможно  прилагането  на няколко  типа  правила  за кодиране , 
някои  типове  ASN.1, упоменати  в настоящото  допълнение , са огра­  
ничени  от идентификаторите  на диапазона  от стойности . Тези  иден­  
тификатори  са определени  в параграф  3 и допълнение  2. 
1.2. Справочни  материали  
В настоящото  допълнение  се използват  следните  справочни  мате­  
риали : 
ISO 639 Код за представяне  на наименованията  на езиците . 
Първо  издание : 1988 г. 
ISO 3166 Кодове  за представяне  на наименованията  на 
държавите  и техните  подразделения . Част  1: 
Кодове  на държавите , 2013 г. 
ISO 3779 Пътни  превозни  средства . Номер  за идентифи­  
циране  на превозните  средства  (VIN). Съдържание  
и структура . 2009 г. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 97  
ISO/IEC 7816-5 Идентификационни  карти . Карти  с интегрална (и) 
схема (и) с контакти . Част  5: Система  за номе­  
риране  и процедури  по регистрация  на идентифи­  
каторите  на приложенията . 
Второ  издание : 2004 г. 
ISO/IEC 7816-6 Идентификационни  карти . Карти  с интегрални  
схеми . Част  6: Вътрешно -отраслови  елементи  от 
данни  за взаимен  обмен , 2004 г. + техническа  
поправка  1: 2006 г. 
ISO/IEC 8824-1 Информационни  технологии . Абстрактно  озна­  
чаване  на синтаксиса  на информационна  единица  
(ASN.1). Спецификация  на основната  нотация  
2008 г. + Техническа  поправка  1: 2012 г. + 
Техническа  поправка  2: 2014 г. 
ISO/IEC 8825-2 Информационни  технологии . Правила  за кодиране  
на ASN.1. Спецификация  на правилата  за пакетно  
кодиране . 2008 г. 
ISO/IEC 8859-1 Информационни  технологии  — Набори  от 
графични  символи , кодирани  в байтове  — Част  
1: Латинска  азбука  № 1. Първо  издание : 1998 г. 
ISO/IEC 8859-7 Информационни  технологии  — Набори  от 
графични  символи , кодирани  в байтове  — Част  
7: Латинска /гръцка  азбука . 2003 г. 
ISO 16844-3 Пътни  превозни  средства  — Тахографски  системи  
— Интерфейси  на датчиците  за движение . 2004 г. 
+ Техническа  поправка  1: 2006 г. 
TR-03110-3 BSI / ANSSI Технически  насоки  TR-03110-3, 
усъвършенствани  механизми  за сигурност  за 
машинночетими  документи  за пътуване  и маркер  
eIDAS. Част  3: Общи  спецификации , версия  2.20, 
3. Февруари  2015 г. 
2. ОПРЕДЕЛЕНИЯ  НА ТИПОВЕТЕ  ДАННИ  
За всеки  от следващите  типове  данни  стойността  по подразбиране  
за съдържание  „неизвестно “ или „неприложимо “ води  до запълване  
на елемента  от данни  с байтове  „FF“.  
Всички  типове  данни  се използват  за приложенията  от поколение  1 
и 2, освен  ако е посочено  нещо  друго . 
▼M1 
Посоченият  в настоящото  допълнение  размер  за типовете  карти  за 
данни , които  се използват  за приложенията  от поколение  1 и 2, е 
размерът  за приложение  от поколение  2. Предполага  се, че четецът  
вече познава  размера  за приложение  от поколение  1. Номерата  на 
изискванията  в приложение  IB, свързани  с тези типове  данни , се 
отнасят  за приложенията  от поколение  1 и 2. 
▼B 
2.1. ActivityChangeInfo  
Този  тип данни  позволява  кодирането  във вид на дума  от два байта  
на статуса  на процепа  в 00.00 часа и/или на състоянието  при 
управление  в 00.00 часа и/или на промените  на дейността , и/или 
на промените  на състоянието  при управление , и/или на промените  
на статуса  на картата  на водач  или втория  водач . Този  тип данни  е 
свързан  с изисквания  105, 266, 291, 320, 321, 343 и 344 от 
приложение  1В.
 
Присвояване  на стойност  — синхронизиран  октет : ‘scpa­
attttttttttt’B (16 бита ) 
За записването  на паметта  за данни  (или статус  на процепа ): 
‘s’B Процеп : 
‘0’B: ВОДАЧ , 
‘1’B: ВТОРИ  ВОДАЧ , ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 98  
‘c’B Състояние  при: 
‘0’B: САМ , 
‘1’B: ЕКИПАЖ , 
‘p’B Статус  на картата  на водач  (или картата  за монтаж  
и настройки ) в съответния  процеп : 
‘0’B: ВКАРАНА , картата  е вкарана , 
‘1’B: НЕ Е ВКАРАНА , не е вкарана  карта  (или 
картата  е извадена ), 
‘aa’B Дейност : 
‘00’B: ПРЕКЪСВАНЕ /ПОЧИВКА , 
‘01’B: НА РАЗПОЛОЖЕНИЕ , 
‘10’B: РАБОТА , 
‘11’B: УПРАВЛЕНИЕ , 
‘ttttttttttt’B Време  на промяната : брой  минути , изтекли  след  
00.00 часа на съответния  ден. 
Относно  записите  на картата  на водач  (или картата  за монтаж  и 
настройки ) (и състоянието  при управление ): 
‘s’B Процеп  (не е от значение , ако ‘p’=1 освен  забе­  
лежката  по-долу ): 
‘0’B: ВОДАЧ , 
‘1’B: ВТОРИ  ВОДАЧ , 
‘c’B Състояние  при управление  (‘p’=0) или 
след  статус  на дейността  (‘p’=1):  
‘0’B: САМ , 
‘0’B: НЕИЗВЕСТНА  ДЕЙНОСТ  
‘1’B: ЕКИПАЖ , 
‘1’B: ИЗВЕСТНА  ДЕЙНОСТ  (=ръчно  въведена ) 
‘p’B Статус  на картата : 
‘0’B: ВКАРАНА , картата  е вкарана  в уред  за 
регистриране  на данните  за движението , 
‘1’B: НЕ Е ВКАРАНА , не е вкарана  картата  (или 
картата  е извадена ), 
‘aa’B Дейност  (не е от значение , когато  ‘p’=1 и ‘c’=0 
освен  забележката  по-долу ): 
‘00’B: ПРЕКЪСВАНЕ /ПОЧИВКА , 
‘01’B: НА РАЗПОЛОЖЕНИЕ , 
‘10’B: РАБОТА , 
‘11’B: УПРАВЛЕНИЕ , 
‘ttttttttttt’B Време  на промяната : брой  минути , изтекли  след  
00.00 часа на съответния  ден. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 99  
Забележка  в случай  на „Изваждане  на картата “: 
Когато  картата  е извадена : 
— ‘s’ се прилага  и указва  процепа , откъдето  е извадена  картата , 
— за ‘c’ трябва  да се зададе  0, 
— за ‘p’ трябва  да се зададе  1, 
— ‘aa’ трябва  да кодира  текущата  дейност , избрана  в същия  
момент . 
Вследствие  на ръчното  въвеждане  битовете  ‘c’ и ‘aa’ на думата  
(съхранена  на карта ) могат  да бъдат  изтрити  с цел отразяване  на 
постъпването  на съответните  данни . 
2.2. Address  
Адрес .
 
codePage  указва  набор  от символи , определен  в глава  4. 
address  е адрес , кодиран  с използването  на указания  набор  от 
символи . 
2.3. AESKey  
Поколение  2: 
Ключ  AES с дължина  128, 192 или 256 бита .
 
Присвояване  на стойност : липса  на допълнителна  информация . 
2.4. AES128Key  
Поколение  2: 
Ключ  AES128.
  
length  указва  дължината  на ключа  AES128 в октети . 
aes128Key  е ключ  AES с дължина  от 128 бита . 
Присвояване  на стойност : 
Дължината  трябва  да е със стойност  16. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 100  
2.5. AES192Key  
Поколение  2: 
Ключ  AES192.
  
length  указва  дължината  на ключа  AES192 в октети . 
aes192Key  е ключ  AES с дължина  от 192 бита . 
Присвояване  на стойност : 
Дължината  трябва  да е със стойност  24. 
2.6. AES256Key  
Поколение  2: 
Ключ  AES256.
  
length  указва  дължината  на ключа  AES256 в октети . 
aes156Key  е ключ  AES с дължина  от 256 бита . 
Присвояване  на стойност : 
Дължината  трябва  да е със стойност  32. 
2.7. BCDString  
BCDString се прилага  при представяне  в двоичен  код на данни , 
представени  в десетичен  вид (DCB). Този  тип данни  се използва  
за представяне  на десетично  число  чрез един  полуоктет  (4 бита ). 
BCDString се основава  на ISO/IЕС 8824-1 „CharacterStringType“.
  
BCDString използва  нотацията  „hstring“. Най-лявото  шестнад­  
есетично  число  трябва  да е най-старши  полуоктет  на първия  
октет . За да се получи  кратно  число  на октетите , е необходимо  
според  нуждите  да се вмъкне  съответният  брой  младши  нулеви  
полуоктети  от най-лявата  позиция  на полуоктета  на първия  октет . 
Допустими  цифри : 0, 1, .. 9.  
2.8. CalibrationPurpose  
Код, указващ  причината  за записване  на набор  от параметри  за 
калибриране . Този  тип данни  е свързан  с изисквания  097 и 098 от 
приложение  1Б и изискване  119 от приложение  1В.
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 101  
Присвояване  на стойност : 
Поколение  1: 
‘00’H запазена  стойност , 
‘01’H активиране : записване  на параметрите  за калиб­  
риране , известни  в момента  на активиране  на 
бордовото  устройство , 
‘02’H първо  монтиране : първо  калибриране  на 
бордовото  устройство  след  активирането  му, 
‘03’H монтиране : първо  калибриране  на бордовото  
устройство  в съответното  превозно  средство , 
‘04’H периодичен  технически  преглед . 
Поколение  2: 
В допълнение  към поколение  1 се използват  следните  стойности : 
‘05’H въвеждане  на VRN от превозвача , 
‘06’H сверяване  на часовника  без калибриране , 
‘07’H до ‘7F’H RFU,  
‘80’H до ‘FF’H Фабрични  характеристики . 
2.9. CardActivityDailyRecord  
Информация , съхранена  на карта  и отнасяща  се до дейностите  на 
водача  в определен  календарен  ден. Този  тип данни  е свързан  с 
изисквания  266, 291, 320 и 343 от приложение  1В.
 
activityPreviousRecordLength  е общата  дължина  на предишния  
дневен  запис , изразена  в байтове . Максималната  стойност  съот­  
ветства  на дължината  на OCTET STRING, съдържащ  тези записи  
(вж. CardActivityLengthRange, допълнение  2, параграф  4). Когато  
този запис  е най-старият  дневен  запис , за стойността  на activityPre ­
viousRecordLength трябва  да се зададе  0. 
activityRecordLength  е общата  дължина  на този запис , изразена  в 
байтове . Максималната  стойност  съответства  на дължината  на 
OCTET STRING, съдържащ  тези записи . 
activityRecordDate  е датата  на записа . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 102  
activityDailyPresenceCounter  е състоянието  за съответния  ден на 
брояча  на присъствените  дни за картата . 
activityDayDistance  е общото  изминато  разстояние  през съответния  
ден. 
activityChangeInfo  указва  за съответния  ден набора  от данни  Acti­
vityChangeInfo, който  се отнася  за водача . Той не може  да съдържа  
повече  от 1440 стойности  (една  промяна  на дейност  в минута ). Този  
набор  съдържа  винаги  ActivityChangeInfo, който  кодира  състоянието  
при управление  в 00:00 часа. 
2.10.  CardActivityLengthRange  
Брой  на байтовете  в карта  на водач  или карта  за монтаж  и наст­  
ройки , които  са налични  за съхранение  на записите  за дейностите  на 
водача .
 
Присвояване  на стойност : вж. допълнение  2. 
2.11.  CardApprovalNumber  
Номер  на одобрение  на типа  на картата .
 
Присвояване  на стойност : 
Номерът  на одобрение  е този, който  е публикуван  на съответната  
интернет  страница  на Европейската  комисия , т.е. например , като се 
включват  тиренца , ако има. Номерът  на одобрение  се подравнява  
отляво . 
2.12.  CardCertificate  
Поколение  1: 
Сертификат  на публичния  ключ  на карта .
 
2.13.  CardChipIdentification  
Информация , съхранена  на карта  и отнасяща  се до идентификация  
на интегралната  схема  (ИС) на картата  (изискване  249 от 
приложение  1В). icSerialNumber и icManufacturingReferences иденти­  
фицират  уникално  чипа  на картата . Самостоятелно  icSerialNumber 
не идентифицира  уникално  чипа  на картата .
 
icSerialNumber  е серийният  номер  на ИС. 
icManufacturingReferences  е специфичният  идентификатор  на 
производителя  на ИС. 
2.14.  CardConsecutiveIndex  
Индекс  за пореден  номер  на картата  (определение  з).
 
Присвояване  на стойност : (вж. приложение  1В, глава  7) 
Възходящ  ред: ‘0, …, 9, A, …, Z, a, …, z’  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 103  
2.15.  CardControlActivityDataRecord  
Информация , съхранена  на карта  на водач  или карта  за монтаж  и 
настройки  и отнасяща  се до последната  проверка  на водача  
(изисквания  274, 299, 327 и 350 от приложение  1В).
 
controlType  е типът  проверка . 
controlTime  е датата  и часът  на проверката . 
controlCardNumber  е FullCardNumber на служителя  на контролен  
орган , който  е извършил  проверката . 
controlVehicleRegistration  посочва  VRN и регистриращата  
превозното  средство  държава  членка , където  е извършена  
проверката . 
controlDownloadPeriodBegin  и controlDownloadPeriodEnd  са 
периодът , за който  са изтеглени  данни , при наличие  на такова  
изтегляне  на данни . 
2.16.  CardCurrentUse  
Информация  относно  актуалната  употреба  на картата  (изискване  
273, 298, 326 и 349 от приложение  1В).
 
sessionOpenTime  е моментът  на вкарване  на картата  за актуалната  
употреба . Този  елемент  се нулира  при изваждане  на картата . 
sessionOpenVehicle  е идентификацията  на понастоящем  изпол­  
званото  превозно  средство  след  вкарване  на картата . Този  елемент  
се нулира  при изваждане  на картата . 
2.17.  CardDriverActivity  
Информация , съхранена  на карта  на водач  или карта  за монтаж  и 
настройки  и отнасяща  се до дейностите  на водача  (изисквания  267, 
268, 292, 293, 321 и 344 от приложение  1В).
 
activityPointerOldestDayRecord  е спецификацията  на началото  на 
мястото  на съхранение  (брой  на байтовете  от началото  на низа ) на 
най-стария  пълен  дневен  запис  в низа  activityDailyRecords. Макси­  
малната  стойност  съответства  на дължината  на низа . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 104  
activityPointerNewestRecord  е спецификацията  на началото  на 
мястото  на съхранение  (брой  на байтовете  от началото  на низа ) на 
най-скорошния  дневен  запис  в низа  activityDailyRecords. Макси­  
малната  стойност  съответства  на дължината  на низа . 
activityDailyRecords  е мястото , което  е налично  за съхранение  на 
данните  относно  дейностите  на водача  (структура  на данни : CardAc­
tivityDailyRecord) за всеки  календарен  ден, през който  картата  е 
била  използвана . 
Присвояване  на стойност : този низ от октети  се попълва  циклично  
със записи  от CardActivityDailyRecord. При първото  използване  
съхранението  започва  на първия  байт  на низа . Следващите  записи  
се запаметяват  в края  на предишния . Когато  низът  се запълни , 
съхранението  продължава  от първия  байт  на низа , независимо  от 
прекъсването  вътре  в елемент  от данни . Преди  да се въведат  нови  
данни  за дейността  в низа  (като се разшири  текущият  activityDaily ­
Record или като се въведе  нов activityDailyRecord), които  заместват  
по-старите  данни  за дейността , е необходимо  да се актуализира  
activityPointerOldestDayRecord, за да се отрази  новото  местопо­  
ложение  на най-стария  пълен  дневен  запис , и трябва  да се нулира  
activityPreviousRecordLength на този (нов) най-стар пълен  дневен  
запис . 
2.18.  CardDrivingLicenceInformation  
Информация , съхранена  на карта  на водач  и отнасяща  се до свиде­  
телството  за управление  на титуляря  на картата  (изисквания  259 и 
284 от приложение  1В).
 
drivingLicenceIssuingAuthority  е компетентният  орган  за издаване  
на свидетелството  за управление . 
drivingLicenceIssuingNation  е националността  на органа , издал  
свидетелството  за управление . 
drivingLicenceNumber  е номерът  на свидетелството  за управление . 
▼M1 
2.19.  CardEventData  
Поколение  1: 
Информация , съхранена  на карта  на водач  или карта  за монтаж  и 
настройки  и отнасяща  се до събитията , свързани  с титуляря  на 
картата  (изисквания  в подточки  260 и 318 от приложение  IВ).
 
CardEventData  е последователност  във възходящ  ред от EventFa­
ultType и cardEventRecords ( с изключение  на записите  относно  
опитите  за нарушаване  на сигурността , които  са групирани  в 
последния  блок  от данни  на последователността ). 
cardEventRecords  е набор  от записи  на събития  от определен  тип 
(или категория  от събития  във връзка  с опити  за нарушаване  на 
сигурността ). 
Поколение  2: ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 105  
Информация , съхранена  на карта  на водач  или карта  за монтаж  и 
настройки  и отнасяща  се до събитията , свързани  с титуляря  на 
картата  (изисквания  в подточки  285 и 341 от приложение  IВ).
 
CardEventData  е последователност  във възходящ  ред от EventFa­
ultType и cardEventRecords ( с изключение  на записите  относно  
опитите  за нарушаване  на сигурността , които  са групирани  в 
последния  блок  от данни  на последователността ). 
cardEventRecords  е набор  от записи  на събития  от определен  тип 
(или категория  от събития  във връзка  с опити  за нарушаване  на 
сигурността ). 
▼B 
2.20.  CardEventRecord  
Информация , съхранена  на карта  на водач  или карта  за монтаж  и 
настройки  и отнасяща  се до събитие , свързано  с титуляря  на картата  
(изисквания  261, 286, 318 и 341 от приложение  1В).
 
eventType  е типът  на събитието . 
eventBeginTime  е датата  и часът  на начало  на събитието . 
eventEndTime  е датата  и часът  на край  на събитието . 
eventVehicleRegistration  посочва  VRN и регистриращата  
превозното  средство  държава  членка , в която  се е случило  съби­  
тието . 
2.21.  CardFaultData  
Информация , съхранена  на карта  на водач  или карта  за монтаж  и 
настройки  и отнасяща  се до неизправности , свързани  с титуляря  на 
картата  (изисквания  263, 288, 318 и 341 от приложение  1В).
 
CardFaultData  е последователност , съдържаща  набор  от записи  за 
неизправности , засягащи  уредите  за регистриране  на данните  за 
движението , и последван  от набор  записи  за неизправностите  във 
връзка  с картата . 
cardFaultRecords  е набор  от записи  за неизправности  в определена  
категория  неизправности  (уреди  за регистриране  на данните  за 
движението  или карти ). 
2.22.  CardFaultRecord  
Информация , съхранена  на карта  на водач  или карта  за монтаж  и 
настройки  и отнасяща  се до неизправност , свързана  с титуляря  на 
картата  (изисквания  264, 289, 318 и 341 от приложение  1В).
 
faultType  е типът  неизправност . ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 106  
faultBeginTime  е датата  и часът  на начало  на неизправността . 
faultEndTime  е датата  и часът  на край  на неизправността . 
faultVehicleRegistration  посочва  VRN и регистриращата  превозното  
средство  държава  членка , в която  се е случила  съответната  
неизправност . 
2.23.  CardIccIdentification  
Информация , съхранена  на карта  и отнасяща  се до идентификация  
на картата  с интегрална  схема  (ИС) (изискване  248 от приложение  
1В).
 
clockStop  е режимът  clockStop, определен  в допълнение  2. 
cardExtendedSerialNumber  е уникалният  сериен  номер  на ИС на 
картата , допълнително  специфициран  от типа  данни  ExtendedSerial ­
Number.  
cardApprovalNumber  е номерът  на одобрение  на типа  на картата . 
cardPersonaliserID  е идентификатор  на организацията , персонали­  
зирала  картата , изразен  чрез ManufacturerCode.  
embedderIcAssemblerId  осигурява  информация  за интегратора /мон­  
тажника  на ИС. 
icIdentifier  е идентификаторът  на ИС на картата  и производителя  на 
нейната  ИС, определен  в стандарт  ISO/IEC 7816-6.  
2.24.  CardIdentification  
Информация , съхранена  на карта  и отнасяща  се до идентификация  
на картата  (изисквания  255, 280, 310, 333, 359, 365, 371 и 377 от 
приложение  1В).
 
cardIssuingMemberState  е кодът  на държавата  членка , издаваща  
картата . 
cardNumber  е номерът  на картата . 
cardIssuingAuthorityName  е наименованието  на органа , издал  
картата . 
cardIssueDate  е датата  на издаване  на картата  на актуалния  ѝ 
титуляр . 
cardValidityBegin  е първата  дата на валидност  на картата . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 107  
cardExpiryDate  е датата  на край  на валидност  на картата . 
2.25.  CardMACertificate  
Поколение  2: 
Сертификат  на публичния  ключ  на картата  за общо  удостоверяване  
с бордовото  устройство . Структурата  на този сертификат  е посочена  
в допълнение  11.
 
2.26.  CardNumber  
Номер  на картата  съгласно  определение  ж).
 
driverIdentification  е уникалната  идентификация  на водач  в 
държава  членка . 
ownerIdentification  е уникалната  идентификация  на превозвач , 
сервиз  или контролен  орган  в държава  членка . 
cardConsecutiveIndex  е индексът  за пореден  номер  на картата . 
cardReplacementIndex  е индексът  за замяна  на картата . 
cardRenewalIndex  е индексът  за подновяване  на валидността  на 
картата . 
Първата  последователност  от селекцията  позволява  да се кодира  
номерът  на картата  на водач , втората  последователност  — 
номерата  на контролната  карта , картата  за монтаж  и настройки  и 
на картата  на превозвач . 
2.27.  CardPlaceDailyWorkPeriod  
Информация , съхранена  на карта  на водач  или карта  за монтаж  и 
настройки  и отнасяща  се за местата  в началото  и/или в края  на 
дневните  периоди  на работа  (изисквания  272, 297, 325 и 348 от 
приложение  1В).
 
placePointerNewestRecord  е индексът  на последния  актуализиран  
запис  за местоположението . 
Присвояване  на стойност : число , съответстващо  на номератора  на 
записа  за местоположението , като се започва  с 0 за първия  случай  
на записи  за местоположението  в структурата . 
placeRecords  е наборът  от записи , съдържащ  данните  относно  
въведените  местоположения . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 108  
2.28.  CardPrivateKey  
Поколение  1: 
Частен  ключ  на карта .
 
2.29.  CardPublicKey  
Публичен  ключ  на карта .
 
▼M1 
2.30.  CardRenewalIndex  
Индекс  за подновяване  на валидността  на картата  (определение  и).
 
Присвояване  на стойност : (вж. глава  7 от настоящото  прило­  
жение ). 
„0“ Първо  издаване . 
Възходящ  ред: „0, …, 9, A, …, Z“  
▼B 
2.31.  CardReplacementIndex  
Индекс  за замяна  на картата  (определение  й).
 
Присвояване  на стойност : (вж. глава  VII от настоящото  прило­  
жение ). 
‘0’ Оригинална  карта . 
Възходящ  ред: ‘0, …, 9, A, …, Z’  
2.32.  CardSignCertificate  
Поколение  2: 
Сертификат  на публичния  ключ  на картата  за подпис . Структурата  
на този сертификат  е посочена  в допълнение  11.
 
2.33.  CardSlotNumber  
Код, позволяващ  да се разграничат  двата  процепа  на бордово  
устройство .
 
Присвояване  на стойност : липса  на допълнителна  информация . 
2.34.  CardSlotsStatus  
Код, указващ  типа  на картите , вкарани  в двата  процепа  на 
бордовото  устройство .
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 109  
Присвояване  на стойност  — синхронизиран  октет : ‘ccccdddd’B  
‘cccc’B Идентификация  на типа  на картата , вкарана  в 
процепа  за втория  водач , 
‘dddd’B Идентификация  на типа  на картата , вкарана  в 
процепа  за водача , 
с помощта  на следните  кодове  за идентификация : 
‘0000’B не е вкарана  карта , 
‘0001’B вкарана  е карта  на водач , 
‘0010’B вкарана  е карта  за монтаж  и настройки , 
‘0011’B вкарана  е контролна  карта , 
‘0100’B вкарана  е карта  на превозвач . 
2.35.  CardSlotsStatusRecordArray  
Поколение  2: 
CardSlotsStatus плюс  метаданните , използвани  в протокола  за 
изтегляне  на данни .
 
recordType  указва  типа  на записа  (CardSlotsStatus).  Присвояване  
на стойност : вж. RecordType.  
recordSize  е размерът  на CardSlotsStatus в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е наборът  от записи  на CardSlotsStatus.  
2.36.  CardStructureVersion  
Код, указващ  версията  на структурата , приложена  в определена  
тахографска  карта .
 
Присвояване  на стойност : ‘aabb’H:  
‘aa’H Индекс  за промените  на структурата . 
‘00’H за приложенията  от поколение  1 
‘01’H за приложенията  от поколение  2 
‘bb’H Индекс  за промените , отнасящи  се до използването  
на елементи  от данни , определени  за съответната  
структурата  от високия  байт . 
‘00’H за тази версия  на приложенията  от 
поколение  1 
‘00’H за тази версия  на приложенията  от поколение  2 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 110  
2.37.  CardVehicleRecord  
Информация , съхранена  на карта  на водач  или карта  за монтаж  и 
настройки  и отнасяща  се до период  на използване  на превозно  
средство  през определен  календарен  ден (изисквания  269, 294, 322 
и 345 от приложение  1В). 
Поколение  1:
 
vehicleOdometerBegin  е стойността  от километражния  брояч  на 
превозното  средство  в началото  на периода  на използване  на 
превозното  средство . 
vehicleOdometerEnd  е стойността  от километражния  брояч  на 
превозното  средство  в края  на периода  на използване  на превозното  
средство . 
vehicleFirstUse  е датата  и часът  на начало  на периода  на използване  
на превозното  средство . 
vehicleLastUse  е датата  и часът  на край  на периода  на използване  
на превозното  средство . 
vehicleRegistration  посочва  VRN и държавата  членка , регистрираща  
превозното  средство . 
vuDataBlockCounter  е стойността  на vuDataBlockCounter при 
последното  извличане  на периода  на използване  на превозното  
средство . 
Поколение  2:
 
В допълнение  към поколение  1 се използва  следният  елемент  от 
данни : 
VehicleIdentificationNumber  е идентификационният  номер  на 
превозното  средство , обозначаващ  цялото  превозно  средство . 
2.38.  CardVehiclesUsed  
Информация , съхранена  на карта  на водач  или карта  за монтаж  и 
настройки  и отнасяща  се до превозните  средства , използвани  от 
титуляря  на картата  (изисквания  270, 295, 323 и 346 от приложение  
1В).
 
vehiclePointerNewestRecord  е индексът  на последния  актуализиран  
запис  на превозното  средство . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 111  
Присвояване  на стойност : число , съответстващо  на номератора  на 
записа  за превозното  средство , като се започва  с 0 за първия  случай  
на записи  за превозното  средство  в структурата . 
cardVehicleRecords  е наборът  от записи , съдържащ  информация  за 
използваните  превозни  средства . 
2.39.  CardVehicleUnitRecord  
Поколение  2: 
Информация , съхранена  на карта  на водач  или карта  за монтаж  и 
настройки  и отнасяща  се до използвано  бордово  устройство  
(изисквания  303 и 351 от приложение  1В).
 
timeStamp  е началото  на периода  на използване  на бордовото  
устройство  (т.е. първото  вкарване  на картата  в бордовото  
устройство  за периода ). 
manufacturerCode  идентифицира  производителя  на бордовото  
устройство . 
deviceID  идентифицира  типа  бордово  устройство  на производител . 
Стойността  е специфична  за съответния  производител . 
vuSoftwareVersion  е номерът  на версията  на софтуера  на бордовото  
устройство . 
2.40.  CardVehicleUnitsUsed  
Поколение  2: 
Информация , съхранена  на карта  на водач  или карта  за монтаж  и 
настройки  и отнасяща  се до използваните  бордови  устройства  от 
титуляря  на картата  (изисквания  306 и 352 от приложение  1В).
 
vehicleUnitPointerNewestRecord  е индексът  на последния  актуа­  
лизиран  запис  на бордовото  устройство . 
Присвояване  на стойност : число , съответстващо  на номератора  на 
записа  за бордовото  устройство , като се започва  с 0 за първия  
случай  на записи  за бордовото  устройство  в структурата . 
cardVehicleUnitRecords  е наборът  от записи , съдържащ  
информация  за използваните  бордови  устройства . 
2.41.  Certificate  
Сертификатът  на публичен  ключ , издаден  от сертификационен  
орган . 
Поколение  1:
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 112  
Присвояване  на стойност : електронен  подпис  с частично  възста­  
новяване  на CertificateContent съгласно  общите  механизми  за 
сигурност  от допълнение  11: подпис  (128 байта ) || Остатък  от 
публичния  ключ  (58 байта ) || Посочване  на сертификационния  
орган  (8 байта ). 
Поколение  2:
 
Присвояване  на стойност : вж. допълнение  11. 
2.42.  CertificateContent  
Поколение  1: 
Съдържанието  (което  е достъпно ) на сертификат  на публичен  ключ  
съгласно  общите  механизми  за сигурност  от допълнение  11.
 
certificateProfileIdentifier  е версията  на съответния  сертификат . 
Присвояване  на стойност : ‘01h’ за тази версия . 
certificationAuthorityReference  идентифицира  сертификационния  
орган , издаващ  сертификата . Тази  информация  указва  също  така 
публичния  ключ  на този сертификационен  орган . 
certificateHolderAuthorisation  идентифицира  правата  на титуляря  
на сертификата . 
certificateEndOfValidity  е датата , когато  от административна  гледна  
точка  изтича  срокът  на валидност  на сертификата . 
certificateHolderReference  идентифицира  титуляря  на сертификата . 
Тази  информация  указва  също  така публичния  ключ . 
publicKey  е публичният  ключ , сертифициран  с този сертификат . 
2.43.  CertificateHolderAuthorisation  
Идентифициране  на правата  на титуляря  на сертификат .
 
Поколение  1: 
tachographApplicationID  е идентификаторът  на тахографското  
приложение . 
Присвояване  на стойност : ‘FFh’ ‘54h’ ‘41h’ ‘43h’ ‘48h’ ‘4Fh’. Този  
АID е идентификатор  на нерегистрирано  приложение , което  е обект  
на права  на собственост  съгласно  ISO/IЕС 7816-5.  
equipmentType  е идентификацията  на типа  оборудване , за което  е 
предназначен  сертификатът . 
Присвояване  на стойност : съгласно  типа  данни  EquipmentType.  0, 
ако сертификатът  е издаден  от някоя  от държавите  членки . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 113  
Поколение  2: 
tachographApplicationID  указва  6-те най-старши  байта  на иденти­  
фикатора  на приложението  на тахографската  карта  от поколение  2 
(AID). AID за приложението  на тахографската  карта  е посочен  в 
глава  6.2.  
Присвояване  на стойност : ‘FF 53 4D 52 44 54’.  
equipmentType  е идентификацията  на типа  оборудване , както  е 
посочено  за поколение  2, за който  е предназначен  сертификатът . 
Присвояване  на стойност : съгласно  типа  данни  EquipmentType.  
2.44.  CertificateRequestID  
Уникална  идентификация  на заявка  за сертификат . Може  също  така 
да се използва  за идентификатор  на публичния  ключ  на бордовото  
устройство , в случай  че серийният  номер  на бордовото  устройство , 
за което  е предназначен  ключът , е неизвестен  към момента  на гене­  
риране  на сертификата .
 
requestSerialNumber  е сериен  номер  на заявката  за сертификат , 
който  е уникален  за производителя  и месеца  по-долу . 
requestMonthYear  е идентификацията  на месеца  и годината  на 
заявката  за сертификат . 
Присвояване  на стойност : кодиране  BCD на месеца  (две цифри ) и 
годината  (последните  две цифри ). 
crIdentifier : идентификатор , позволяващ  да се прави  разлика  между  
заявка  за сертификат  и разширен  сериен  номер . 
Присвояване  на стойност : ‘FFh’.  
manufacturerCode : цифровият  код на производителя , подаващ  
заявката  за сертификат . 
2.45.  CertificationAuthorityKID  
Идентификатор  на публичния  ключ  на сертификационен  орган  
(държава  членка  или европейския  сертификационен  орган ).
 
nationNumeric  е националният  цифров  код на сертификационния  
орган . 
nationAlpha  е националният  буквено -цифров  код на сертифика­  
ционния  орган . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 114  
keySerialNumber  е сериен  номер , позволяващ  да се прави  разлика  
между  различните  ключове  на сертификационния  орган , ако някои  
ключове  са променени . 
additionalInfo  е поле  от два байта  за допълнително  кодиране  (спе­  
цифични  за сертификационния  орган ). 
caIdentifier  е идентификатор , позволяващ  да се прави  разлика  
между  идентификатор  на ключ  на сертификационен  орган  и други  
идентификатори  на ключове . 
Присвояване  на стойност : ‘01h’.  
2.46.  CompanyActivityData  
Информация , съхранена  на карта  на превозвач  и отнасяща  се до 
дейности , извършени  с картата  (изисквания  373 и 379 от 
приложение  1В).
 
companyPointerNewestRecord  е индексът  на последния  актуа­  
лизиран  companyActivityRecord.  
Присвояване  на стойност : число , съответстващо  на номератора  на 
записа  за дейността  на превозвача , като се започва  с 0 за първия  
случай  на запис  за дейността  на превозвача  в структурата . 
companyActivityRecords  е наборът  от всички  записи  за дейността  
на превозвача . 
companyActivityRecord  е последователността  от данни , свързани  с 
определена  дейност  на превозвача . 
companyActivityType  е типът  дейност  на превозвача . 
companyActivityTime  е датата  и часът  на дейността  на превозвача . 
cardNumberInformation  е номерът  на картата  и ако е необходимо  
— посочване  на държавата  членка , където  е издадена  картата , от 
която  са изтеглени  данните . 
vehicleRegistrationInformation  посочва  VRN и регистриращата  
превозното  средство  държава  членка , като тази информация  може  
да е изтеглена , блокирана  или разблокирана . 
downloadPeriodBegin  и downloadPeriodEnd  са периодът , за който  
са изтеглени  данни  от бордовото  устройство , ако има такъв . 
2.47.  CompanyActivityType  
Код за дейност , провеждана  от определен  превозвач , използващ  
своята  карта  на превозвач .
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 115  
2.48.  CompanyCardApplicationIdentification  
Информация , съхранена  на карта  на превозвач  и отнасяща  се за 
идентификация  на приложението  на картата  (изисквания  369 и 
375 от приложение  1В).
 
typeOfTachographCardId  обозначава  използвания  тип карта . 
cardStructureVersion  указва  версията  на структурата , приложена  в 
картата . 
noOfCompanyActivityRecords  е броят  на записите  за дейността  на 
превозвача , които  картата  може  да съхранява . 
2.49.  CompanyCardHolderIdentification  
Информация , съхранена  на карта  на превозвач  и отнасяща  се за 
идентификация  на титуляря  на картата  (изисквания  372 и 378 от 
приложение  1В).
 
companyName  е наименованието  на превозвача , който  притежава  
картата . 
companyAddress  е адресът  на превозвача , който  притежава  картата . 
cardHolderPreferredLanguage  е предпочитаният  език на титуляря  
на картата . 
2.50.  ControlCardApplicationIdentification  
Информация , съхранена  на контролна  карта  и отнасяща  се за иден­  
тификация  на приложението  на картата  (изисквания  357 и 363 от 
приложение  1В).
 
typeOfTachographCardId  обозначава  използвания  тип карта . 
cardStructureVersion  указва  версията  на структурата , приложена  в 
картата . 
noOfControlActivityRecords  е броят  на записите  за контролната  
дейност , които  картата  може  да съхранява . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 116  
2.51.  ControlCardControlActivityData  
Информация , съхранена  на контролна  карта  и отнасяща  се до 
определена  контролна  дейност , извършена  с картата  (изисквания  
361 и 367 от приложение  1В).
 
controlPointerNewestRecord  е индексът  на последния  актуализиран  
запис  за контролната  дейност . 
Присвояване  на стойност : число , съответстващо  на номератора  на 
записа  за контролната  дейност , като се започва  с 0 за първия  случай  
на запис  за контролната  дейност  в структурата . 
controlActivityRecords  е наборът  от всички  записи  за контролната  
дейност . 
controlActivityRecord  е последователността  от информация , 
свързана  с една  проверка . 
controlType  е типът  проверка . 
controlTime  е датата  и часът  на проверката . 
controlledCardNumber  посочва  номера  на картата  и държавата  
членка , издаваща  проверената  карта . 
controlledVehicleRegistration  посочва  VRN и регистриращата  
превозното  средство  държава  членка , в която  е извършена  
проверката . 
controlDownloadPeriodBegin  и controlDownloadPeriodEnd  са 
периодът , за който  са изтеглени  евентуално  данни . 
2.52.  ControlCardHolderIdentification  
Информация , съхранена  на контролна  карта  и отнасяща  се за иден­  
тификация  на титуляря  на картата  (изисквания  360 и 366 от 
приложение  1В).
 
controlBodyName  е наименованието  на контролния  орган  на 
титуляря  на картата . 
controlBodyAddress  е адресът  на контролния  орган  на титуляря  на 
картата . 
cardHolderName  е фамилията  и името  (и презимето ) на титуляря  на 
контролната  карта . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 117  
cardHolderPreferredLanguage  е предпочитаният  език на титуляря  
на картата . 
2.53.  ControlType  
Код, указващ  дейностите , извършени  по време  на проверка . Този  
тип данни  е свързан  с изисквания  126, 274, 299, 327 и 350 от 
приложение  1В.
 
Поколение  1: 
Присвояване  на стойност  — синхронизиран  октет : ‘cvpdxxxx’B 
(8 бита ) 
‘c’B изтегляне  на данни  от картата : 
‘0’B: не са изтеглени  данни  от картата  при тази 
контролна  дейност , 
‘1’B: изтеглени  са данни  от картата  при тази 
контролна  дейност  
‘v’B изтегляне  на данни  от бордовото  устройство : 
‘0’B: не са изтеглени  данни  от бордовото  устройство  
при тази контролна  дейност , 
‘1’B: изтеглени  са данни  от бордовото  устройство  
при тази контролна  дейност  
‘p’B отпечатване : 
‘0’B: няма  отпечатване  при тази контролна  дейност , 
‘1’B: има отпечатване  при тази контролна  дейност  
‘d’B изобразяване : 
‘0’B: няма  изобразяване  при тази контролна  
дейност , 
‘1’B: има изобразяване  при тази контролна  дейност  
‘xxxx’B Не се използва . 
Поколение  2: 
Присвояване  на стойност  — синхронизиран  октет : ‘cvpdexxx’B 
(8 бита ) 
‘c’B изтегляне  на данни  от картата : 
‘0’B: не са изтеглени  данни  от картата  при тази 
контролна  дейност , 
‘1’B: изтеглени  са данни  от картата  при тази 
контролна  дейност  
‘v’B изтегляне  на данни  от бордовото  устройство : 
‘0’B: не са изтеглени  данни  от бордовото  устройство  
при тази контролна  дейност , 
‘1’B: изтеглени  са данни  от бордовото  устройство  
при тази контролна  дейност  
‘p’B отпечатване : 
‘0’B: няма  отпечатване  при тази контролна  дейност , 
‘1’B: има отпечатване  при тази контролна  дейност  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 118  
‘d’B изобразяване : 
‘0’B: няма  изобразяване  при тази контролна  
дейност , 
‘1’B: има изобразяване  при тази контролна  дейност  
‘e’B пътна  проверка  на калибрирането : 
‘0’B: не са проверени  параметрите  за калибриране  
при тази контролна  дейност , 
‘1’B: проверени  са параметрите  за калибриране  при 
тази контролна  дейност  
‘xxx’B RFU.  
2.54.  CurrentDateTime  
Актуалната  дата и час на уредите  за регистриране  на данните  за 
движението .
 
Присвояване  на стойност : липса  на допълнителна  информация . 
2.55.  CurrentDateTimeRecordArray  
Поколение  2: 
Актуалната  дата и час плюс  метаданните , използвани  в протокола  
за изтегляне  на данни .
 
recordType  указва  типа  на записа  (CurrentDateTime).  Присвояване  
на стойност : вж. RecordType.  
recordSize  е размерът  на CurrentDateTime в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е набор  от записи  на актуалната  дата и час. 
2.56.  DailyPresenceCounter  
Брояч , съхранен  на карта  на водач  или карта  за монтаж  и наст­  
ройки , чиято  стойност  се увеличава  с едно  за всеки  календарен  
ден, когато  картата  е била  вкарана  в бордово  устройство . Този  
тип данни  е свързан  с изисквания  266, 299, 320 и 343 от 
приложение  1В.
 
Присвояване  на стойност : последователен  номер  с максималната  
стойност  = 9999, като се започва  от 0. При първото  издаване  на 
картата  номерът  е 0. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 119  
2.57.  Datef  
Дата , изразена  в цифров  формат , който  може  да се разпечата  
веднага .
 
Присвояване  на стойност : 
yyyy Година  
mm Месец  
dd Ден 
‘00000000’H Указва  изрично  липсата  на дата. 
2.58.  DateOfDayDownloaded  
Поколение  2: 
датата  и часът  на изтеглянето  на данни .
 
Присвояване  на стойност : липса  на допълнителна  информация . 
2.59.  DateOfDayDownloadedRecordArray  
Поколение  2: 
Датата  и часът  на изтегляне  плюс  метаданните , използвани  в 
протокола  за изтегляне  на данни .
 
recordType  указва  типа  на записа  (DateOfDayDownloaded).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът  на CurrentDateTime в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е наборът  от дати  и часове  на записите  за изтегляне  на 
данни . 
2.60.  Distance  
Изминатото  разстояние  (резултат  от изчислението  на разликата  
между  две стойности  на километражния  брояч  на превозното  
средство ).
 
Присвояване  на стойност : двоична  без знак. Стойност  в km в 
работния  диапазон  от 0 до 9 999 km.  
2.61.  DriverCardApplicationIdentification  
Информация , съхранена  на карта  на водач  и отнасяща  се до иден­  
тификация  на приложението  на картата  (изисквания  253 и 278 от 
приложение  1В). ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 120  
Поколение  1:
 
typeOfTachographCardId  обозначава  използвания  тип карта . 
cardStructureVersion  указва  версията  на структурата , приложена  в 
картата . 
noOfEventsPerType  е броят  на събитията  от всеки  тип, които  
картата  може  да запише . 
noOfFaultsPerType  е броят  на неизправностите  от всеки  тип, които  
картата  може  да запише . 
activityStructureLength  указва  броя  на байтовете , които  могат  да се 
използват  за съхранение  на записите  за дейността . 
noOfCardVehicleRecords  е броят  на записите  за превозното  
средство , които  картата  може  да съдържа . 
noOfCardPlaceRecords  е броят  на местоположенията , които  картата  
може  да запише . 
Поколение  2: 
▼M1
 
В допълнение  към поколение  1 се използват  следните  елементи  от 
данни : 
noOfGNSSADRecords  е броят  на записите  за общо  управление  по 
GNSS, които  картата  може  да съхранява . 
noOfSpecificConditionRecords  е броят  на записите  за специфични  
условия , които  картата  може  да съхранява . 
noOfCardVehicleUnitRecords  е броят  на записите  за използваните  
бордови  устройства , които  картата  може  да съхранява . 
▼B 
2.62.  DriverCardHolderIdentification  
Информация , съхранена  на карта  на водач  и отнасяща  се за иден­  
тификация  на титуляря  на картата  (изисквания  256 и 281 от 
приложение  1В).
 
cardHolderName  е фамилията  и името  (и презимето ) на титуляря  на 
картата  на водач . 
cardHolderBirthDate  е рождената  дата на титуляря  на картата  на 
водач . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 121  
cardHolderPreferredLanguage  е предпочитаният  език на титуляря  
на картата . 
▼M1 
2.63.  Reserved for future use  
▼B 
2.64.  EGFCertificate  
Поколение  2: 
Сертификат  на публичния  ключ  на външното  устройство  за GNSS 
за общо  удостоверяване  с бордовото  устройство . Структурата  на 
този сертификат  е посочена  в допълнение  11.
 
2.65.  EmbedderIcAssemblerId  
Дава  информация  за интегратора  на ИС.
 
countryCode  е двубуквеният  код на държавата  на интегратора  на 
модула  съгласно  ISO 3166.  
moduleEmbedder  указва  интегратора  на модула . 
manufacturerInformation  за вътрешна  употреба  на производителя . 
2.66.  EntryTypeDailyWorkPeriod  
Код, позволяващ  да се прави  разлика  между  местоположението  в 
началото  и в края  на един  дневен  период  на работа  и условията  на 
въвеждане  на тези данни . 
Поколение  1
 
Присвояване  на стойност : съгласно  стандарт  ISO/IЕС 8824-1.  
Поколение  2
 
Присвояване  на стойност : съгласно  стандарт  ISO/IЕС 8824-1.  
2.67.  EquipmentType  
Код, позволяващ  да се прави  разлика  между  различните  типове  
оборудване , използвани  за тахографското  приложение .
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 122  
Поколение  1:
 
Присвояване  на стойност : съгласно  стандарт  ISO/IЕС 8824-1.  
Стойността  0 е запазена  за указване  на определена  държава  членка  
или на Европа  в полето  CHA на сертификатите . 
Поколение  2: 
▼M1 
Използват  се същите  стойности , както  при поколение  1, със 
следните  допълнения :
 
Забележка  1: стойностите  от поколение  2 за пластината , адаптера  и 
външното  устройство  за GNSS, както  и стойностите  за поколение  1 
за бордовото  устройство  и датчика  за движение  могат  да се 
използват  в SealRecord, т.е. ако е приложимо . 
Забележка  2: Приема  се, че в полето  CardHolderAuthorisation 
(CHA) в сертификат  от поколение  2 стойностите  (1), (2), и (6) 
означават  сертификат  за взаимно  удостоверяване  на автентичността  
за съответния  вид оборудване . За обозначаване  на съответния  
сертификат  за създаване  на цифров  подпис  трябва  да се използват  
стойностите  (17), (18) или (19).  
▼B 
2.68.  EuropeanPublicKey  
Поколение  1: 
Европейски  публичен  ключ .
 
2.69.  EventFaultRecordPurpose  
Код, указващ  причината  за записване  на събитие  или неизправност .
 
Присвояване  на стойност : ▼B
02016R0799 — BG — 26.02.2020 — 002.001 — 123 
едно от 10-те най-скорошни ( или последни ) събития или неизправности  
най-дългото събитие , настъпило по време на един от 10-те последни дена , в 
които са отбелязани събития 
едно от 5-те най-дълги събития , записани по време на 365-те последни дена 
последното събитие , настъпило по време на един от 10-те последни дена , в 
които са отбелязани събития 
най-сериозното събитие , записано по време на един от 10-те последни дена , 
в които са отбелязани събития 
едно от 5-те най-сериозни събития , записани по време на 365-те последни 
дена 
първото събитие или неизправност , настъпила след  последното калибриране 
активно /текущо събитие или неизправност 
RFU 
зависи от производителя  
2.70. EventFaultType 
Код, характеризиращ събитие или неизправност .
 
Присвояване на стойност : 
Поколение 1:
  
Общи събития , 
Няма допълнителна информация , 
Вкарване на невалидна карта , 
Конфликт , предизвикан от картата , 
Припокриване във времето, 
Управление без съответната карта , 
Вкарване на карта  по време на управление , 
Неправилно приключена последна картова сесия , 
Превишаване на скоростта , 
Прекъсване на електрическото  захранване, 
Грешка в данните за движението , 
Конфликт относно движението на превозното средство , 
RFU,
  
Опити  за нарушаване на сигурността , свързани с бордовото устройство , 
Няма допълнителна информация , 
Неуспешна процедурата по удостоверяване на датчика  за движение , 
Неуспешна процедурата по удостоверяване на тахографската  карта , 
Неразрешена смяна на датчика  за движение , 
Грешка във връзка с целостта на входящите данни на картата , 
Грешка във връзка с целостта на съхранените данни на потребител , 
Грешка при трансфер на вътрешни данни, 
Неразрешено отваряне на корпус , 
Възпрепятстване на работата на хардуера , 
RFU,
  
Опити  за нарушаване на сигурността , свързани с датчика  за движение , 
Няма допълнителна информация , 
Неуспешно удостоверяване , 
Грешка във връзка с целостта на съхранените данни, 
Грешка при трансфер на вътрешни данни, 
Неразрешено отваряне на корпус , 
Възпрепятстване на работата  на хардуера , 
RFU,
  
Неизправности във връзка с уреди за регистриране на данните за движението , 
Няма допълнителна информация , 
Вътрешна неизправност в бордовото устройство , 
Неизправност на печатащото устройство , 
Неизправност на екрана , 
Неизправност при изтегляне на данни, 
Неизправност на датчика , 
RFU,  ▼B
02016R0799 — BG — 26.02.2020 — 002.001 — 124 
Неизправности във връзка с карта , 
Няма допълнителна информация , 
RFU,
  
RFU,
  
Зависи от производителя . 
▼M1
Поколение 2:
  
Общи събития , 
Няма допълнителна информация , 
Вкарване на невалидна карта , 
Конфликт , предизвикан от картата , 
Припокриване във времето, 
Управление без съответната карта , 
Вкарване на карта  по време на управление , 
Неправилно приключена последна картова сесия , 
Превишаване на скоростта , 
Прекъсване на електрическото  захранване, 
Грешка в данните за движението , 
Конфликт относно движението на превозното средство , 
Времеви конфликт (GNSS/ вътрешния часовник на бордовото устройство ), 
Грешка в комуникацията с устройството за връзка от разстояние , 
Липса на информация за местоположението от приемник на сигнали от GNSS, 
Грешка в комуникацията с външното  устройство за GNSS, 
RFU,
  
Опити  за нарушаване на сигурността , свързани с бордовото устройство , 
Няма допълнителна информация , 
Неуспешна процедура по удостоверяване на датчика  за движение , 
Неуспешна процедура по удостоверяване на тахографската  карта , 
Неразрешена смяна на датчика  за движение , 
Грешка във връзка с целостта на входящите данни на картата  
Грешка във връзка с целостта на съхранените данни на потребител , 
Грешка при вътрешно прехвърляне на данни, 
Неразрешено отваряне на корпус , 
Възпрепятстване на работата на хардуера , 
Установяване на вмешателство  във връзка с GNSS, 
Неуспешна процедура по удостоверяване на външно  устройство за GNSS, 
Изтекъл сертификат на външно  устройство за GNSS, 
RFU,
  
Опити  за нарушаване на сигурността , свързани с датчика  за движение , 
Няма допълнителна информация , 
Неуспешно удостоверяване , 
Грешка във връзка с целостта на съхранените данни, 
Грешка при вътрешно прехвърляне на данни, 
Неразрешено отваряне на корпус , 
Възпрепятстване на работата  на хардуера , 
RFU,  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 125
  
Неизправности  във връзка  с уреди  за регистриране  на данните  за движението , 
Няма  допълнителна  информация , 
Вътрешна  неизправност  в бордовото  устройство , 
Неизправност  на печатащото  устройство , 
Неизправност  на екрана , 
Неизправност  при изтегляне  на данни , 
Неизправност  на датчика , 
Вътрешен  приемник  на сигнали  от GNSS, 
Външно  устройство  за GNSS, 
Устройство  за връзка  от разстояние , 
Интерфейс  с ITS, 
RFU,
  
Неизправности  във връзка  с карта , 
Няма  допълнителна  информация , 
RFU,
  
RFU,
  
Зависи  от производителя . 
2.71.  ExtendedSealIdentifier  
Поколение  2: 
Разширеният  идентификатор  на пломбата  идентифицира  еднозначно  
пломбата  (съгласно  изискването  в подточка  401 от приложение  IВ).
 
manufacturerCode  е кодът  на производителя  на пломбата . 
sealIdentifier  е идентификатор  за пломбата , който  е уникален  за 
производителя . 
▼B 
2.72.  ExtendedSerialNumber  
Индивидуална  идентификация  на оборудване . Този  номер  може  
също  така да се използва  за идентификатор  на публичния  ключ  
на оборудването . 
Поколение  1:
 
serialNumber  е сериен  номер  на оборудване , уникален  за произво­  
дителя , типа  на оборудването  и месеца  и годината  по-долу . 
monthYear  е идентификация  на месеца  и годината  на производ - 
ството  (или на присвояването  на сериен  номер ). ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 126  
Присвояване  на стойност : кодиране  BCD на месеца  (две цифри ) и 
годината  (последните  две цифри ). 
type е идентификатор  на типа  оборудване . 
Присвояване  на стойност : зависи  от производителя , като стой­  
ността  ‘FFh’ е запазена . 
manufacturerCode : е цифровият  код за идентификация  на произво­  
дителя  на оборудването  от одобрен  тип. 
Поколение  2:
 
serialNumber  вж. поколение  1. 
monthYear  вж. поколение  1. 
type указва  типа  оборудване . 
manufacturerCode : вж. поколение  1. 
2.73.  FullCardNumber  
Код, който  изцяло  идентифицира  тахографска  карта .
 
cardType  е типът  тахографска  карта . 
cardIssuingMemberState  е кодът  на държавата  членка , която  е 
издала  картата . 
cardNumber  е номерът  на картата . 
2.74.  FullCardNumberAndGeneration  
Поколение  2: 
Код, който  изцяло  идентифицира  тахографска  карта  и поколението  
ѝ.
 
fullcardNumber  идентифицира  тахографската  карта . 
generation  указва  поколението  на използваната  тахографска  карта . 
2.75.  Generation  
Поколение  2: 
Указва  поколението  на използвания  тахограф .
 
Присвояване  на стойност : 
‘00’H RFU  
‘01’H Поколение  1 
‘02’H Поколение  2 
‘03’H .. ‘FF’H RFU  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 127  
2.76.  GeoCoordinates  
Поколение  2: 
Геокординатите  се кодират  като цели  числа . Те са кратни  числа  на 
кодирането  ±DDMM.M за ширината  и на ±DDDMM.M за 
дължината . В случая  ±DD, съответно  ±DDD, указва  градусите , а 
MM.M — минутите .
 
latitude  се кодира  като кратно  число  (коефициент  10) на предста­  
вянето  ±DDMM.M.  
longitude  се кодира  като кратно  число  (коефициент  10) на предста­  
вянето  ±DDDMM.M.  
2.77.  GNSSAccuracy  
Поколение  2: 
Точността  на данните  за местоположението  по GNSS (вж. опред­  
еление  ддд). Тази  точност  се кодира  като цяло  число  и е кратно  
число  (коефициент  10) на стойността  X.Y, подадена  от изречението  
GSA NMEA.
  
▼M1 
2.78.  GNSSAccumulatedDriving  
Поколение  2: 
Информация , съхранена  на карта  на водач  или карта  за монтаж  и 
настройки  и отнасяща  се до местоположението  на превозното  
средство  по GNSS, ако общото  време  на управление  на МПС  
достигне  кратно  число  на три часа (съгласно  изискванията  в 
подточки  306 и 354 от приложение  IВ).
 
gnssADPointerNewestRecord  е индексът  на последния  актуализиран  
запис  за общо  управление  по GNSS.  
Присвояване  на стойност  е число , съответстващо  на номератора  
на записа  за общо  управление  по GNSS, като се започва  с 0 за 
първия  случай  на запис  за общо  управление  по GNSS в структурата . 
gnssAccumulatedDrivingRecords  е набор  от записи , съдържащ  
датата  и часа, когато  общото  управление  на МПС  достигне  
кратно  число  на три часа, и информация  за местоположението  на 
превозното  средство . 
2.79.  GNSSAccumulatedDrivingRecord  
Поколение  2: ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 128  
Информация , съхранена  на карта  на водач  или карта  за монтаж  и 
настройки  и отнасяща  се до местоположението  на превозното  
средство  по GNSS, ако общото  време  на управление  на МПС  
достигне  кратно  число  на три часа (съгласно  изискванията  в 
подточки  305 и 353 от приложение  IВ).
 
timeStamp  е датата  и часът , когато  общото  време  на управление  на 
МПС  достигне  кратно  число  на три часа. 
gnssPlaceRecord  съдържа  информация  за местоположението  на 
превозното  средство . 
vehicleOdometerValue  е стойността  от километражния  брояч , 
когато  общото  време  на управление  на МПС  достигне  кратно  
число  на три часа. 
▼B 
2.80.  GNSSPlaceRecord  
Поколение  2: 
Информация  във връзка  с местоположението  по GNSS на 
превозното  средство  (изисквания  108, 109, 110, 296, 305, 347 и 
353 от приложение  1В).
 
timeStamp  е датата  и часът , когато  е било  определено  местополо­  
жението  по GNSS на превозното  средство . 
gnssAccuracy  е точността  на данните  за местоположението  по 
GNSS.  
geoCoordinates  е записаното  местоположение , като се използва  
GNSS.  
2.81.  HighResOdometer  
Стойността  от километражния  брояч  на превозното  средство : общо  
разстояние , изминато  от превозното  средство  по време  на експлоа­  
тацията  му.
 
Присвояване  на стойност : двоична  без знак. Стойност  в 1/200 km 
в работния  диапазон  от 0 до 21 055 406 km.  
2.82.  HighResTripDistance  
Разстояние , изминато  по време  на цяло  пътуване  или част от него .
 
Присвояване  на стойност : двоична  без знак. Стойност  в 1/200 km 
в работния  диапазон  от 0 до 21 055 406 km.  
2.83.  HolderName  
Фамилия  и име (и презиме ) на титуляря  на карта .
 
holderSurname  е фамилията  на титуляря , като не се посочва  
господин , госпожа  или госпожица . 
Присвояване  на стойност : ако картата  не е лична , holderSurname 
съдържа  същите  данни , като companyName, workshopName или 
controlBodyName.  ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 129  
holderFirstNames  е името  (и презимето ) и инициалите  на титуляря . 
2.84.  InternalGNSSReceiver  
Поколение  2: 
Информация  дали  приемникът  на сигнали  от GNSS е вътрешен  или 
външен  за бордовото  устройство . Вярно  означава , че приемникът  на 
сигнали  от GNSS е вътрешен  за бордовото  устройство . Невярно  
означава , че приемникът  на сигнали  от GNSS е външен .
 
2.85.  K-ConstantOfRecordingEquipment  
Константа  на уреда  за регистриране  на данните  за движението  
(определение  м).
 
Присвояване  на стойност : импулси  на километър  в работния  
диапазон  от 0 до 64 255 имп./km. 
▼M1 
2.86.  KeyIdentifier  
Уникален  идентификатор  на публичен  ключ , използван  за 
посочване  и избор  на ключа . Този  идентификатор  идентифицира  
също  така титуляря  на ключа .
 
Първият  избор  е подходящ  за указване  на публичния  ключ  на 
бордово  устройство , тахографска  карта  или външно  устройство  за 
GNSS.  
Вторият  избор  е подходящ  за указване  на публичния  ключ  на 
бордово  устройство  (в случай  че серийният  номер  на бордовото  
устройство  е неизвестен  към момента  на генериране  на сертифи­  
ката). 
Третият  избор  е подходящ  за указване  на публичния  ключ  на 
държава  членка . 
▼B 
2.87.  KMWCKey  
Поколение  2: 
Ключ  AES и съответната  му версия  на ключа  за сдвояването  на 
бордово  устройство  — датчик  за движение . За подробни  данни  
вж. допълнение  11.
 
kMWCKey  е дължината  на ключа  AES, съединен  с ключа , 
използван  за сдвояването  бордово  устройство  — датчик  за 
движение . 
keyVersion  указва  версията  на ключа  AES.  
2.88.  Language  
Код, идентифициращ  език.
 
Присвояване  на стойност : код, съставен  от две малки  букви  
съгласно  стандарт  ISO 639.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 130  
2.89.  LastCardDownload  
Дата  и час, съхранени  на карта  на водач , на последното  изтегляне  
на данните  от картата  (за цели , различни  от извършването  на 
проверка ). Изисквания  257 и 282 от приложение  1В. Тази  дата 
може  да се актуализира  от бордово  устройство  или всеки  четец  
на карта .
 
Присвояване  на стойност : липса  на допълнителна  информация . 
2.90.  LinkCertificate  
Поколение  2: 
Сертификатът  за връзка  между  двойките  ключове  на основния  евро­  
пейски  сертификационен  орган .
 
2.91.  L-TyreCircumference  
Действителна  обиколка  на колелата  (определение  ф).
 
Присвояване  на стойност : двоична  без знак, стойност  в 1/8 mm и в 
работния  диапазон  от 0 до 8 031 mm.  
▼M1 
2.92.  MAC  
Поколение  2: 
Сума  за криптографски  контрол  с дължина  от 8, 12 или 16 байта , 
съответстваща  на криптографските  поредици , посочени  в 
допълнение  11.
 
▼B 
2.93.  ManualInputFlag  
Код, позволяващ  да се разбере  дали  титулярят  на картата  ръчно  е 
въвел  дейностите  на водача  при вкарване  на картата  (изискване  081 
от приложение  1Б и изискване  102 от приложение  1В).
 
Присвояване  на стойност : липса  на допълнителна  информация . 
2.94.  ManufacturerCode  
Код за идентификация  на производителя  на оборудване  от одобрен  
тип.
 
Лабораторията , компетентна  за изпитванията  за оперативна  съвмес­  
тимост , поддържа  и публикува  на своя  уебсайт  списъка  с кодове  на 
производителите  (изискване  454 от приложение  1В). 
Разработчиците  на тахографско  оборудване  получават  временно  
ManufacturerCodes след  подадена  заявка  до лабораторията , 
компетентна  за изпитванията  за оперативна  съвместимост . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 131  
2.95.  ManufacturerSpecificEventFaultData  
Поколение  2: 
Кодовете  за грешка , специфични  за производителя , опростяват  
анализа  на грешките  и поддържането  на бордовите  устройства .
 
manufacturerCode  идентифицира  производителя  на бордовото  
устройство . 
manufacturerSpecificErrorCode  е код за грешка , специфичен  за 
производителя . 
2.96.  MemberStateCertificate  
Сертификат  на публичния  ключ  на държава  членка , издаден  от 
европейския  сертификационен  орган .
 
2.97.  MemberStateCertificateRecordArray  
Поколение  2: 
Сертификатът  на държавата  членка  плюс  метаданните , използвани  в 
протокола  за изтегляне  на данни .
 
recordType  указва  типа  на записа  (MemberStateCertificate).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът  на MemberStateCertificate в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . Стойността  се 
определя  на 1, тъй като сертификатите  могат  да имат  различна  
дължина . 
records  е наборът  от сертификати  на държава  членка . 
2.98.  MemberStatePublicKey  
Поколение  1: 
Публичен  ключ  на държава  членка .
 
2.99.  Name  
Име.
 
codePage  указва  набор  от символи , определен  в глава  4. 
name  е име, кодирано , като е използван  указаният  набор  от 
символи . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 132  
2.100.  NationAlpha  
Буквеният  код за указване  на държавата  трябва  да бъде  в съот­  
ветствие  с отличителните  знаци , използвани  върху  превозни  
средства  при международен  трафик  (съгласно  Виенската  
конвенция  на ООН  от 1968 г. за движението  по пътищата ).
 
Буквените  и цифровите  кодове  за държави  трябва  да се съдържат  в 
списък , поддържан  на уебсайта  на лабораторията , определена  да 
извършва  изпитванията  за оперативна  съвместимост , както  е 
посочено  в изискване  440 от приложение  1В. 
2.101.  NationNumeric  
Цифров  код за указване  на държавата .
 
Присвояване  на стойност : вж. данните  тип 2.100 (NationAlpha).  
Изменението  или актуализирането  на спецификацията  NationAlpha 
или NationNumeric, описана  в параграфа  по-горе, трябва  да се 
извършва  само  след  като определената  лаборатория  получи  стано­  
вищата  на производителите  на бордови  устройства  на цифрови  и 
интелигентни  тахографи  от одобрен  тип. 
2.102.  NoOfCalibrationRecords  
Брой  на записите  на калибриранията , които  картата  за монтаж  и 
настройки  може  да съхранява . 
Поколение  1:
 
Присвояване  на стойност : вж. допълнение  2. 
Поколение  2:
 
Присвояване  на стойност : вж. допълнение  2. 
2.103.  NoOfCalibrationsSinceDownload  
Брояч , указващ  броя  на калибриранията , извършени  с една  карта  за 
монтаж  и настройки  от последното  изтегляне  на данни  от нея 
(изисквания  317 и 340 от приложение  1В).
 
Присвояване  на стойност : липса  на допълнителна  информация . 
2.104.  NoOfCardPlaceRecords  
Брой  на записите  на местоположенията , които  картата  на водач  или 
картата  за монтаж  и настройки  може  да съхранява . 
Поколение  1:
 
Присвояване  на стойност : вж. допълнение  2. 
Поколение  2:
 
Присвояване  на стойност : вж. допълнение  2. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 133  
2.105.  NoOfCardVehicleRecords  
Брой  на записите  на използваните  превозни  средства , които  картата  
на водач  или картата  за монтаж  и настройки  може  да съхранява .
 
Присвояване  на стойност : вж. допълнение  2. 
2.106.  NoOfCardVehicleUnitRecords  
Поколение  2: 
Брой  на записите  на използваните  бордови  устройства , които  
картата  на водач  или картата  за монтаж  и настройки  може  да 
съхранява .
 
Присвояване  на стойност : вж. допълнение  2. 
2.107.  NoOfCompanyActivityRecords  
Брой  на записите  на дейностите  на превозвача , които  картата  на 
превозвач  може  да съхранява .
 
Присвояване  на стойност : вж. допълнение  2. 
2.108.  NoOfControlActivityRecords  
Брой  на записите  за контролната  дейност , които  контролната  карта  
може  да съхранява .
 
Присвояване  на стойност : вж. допълнение  2. 
2.109.  NoOfEventsPerType  
Брой  на събитията  от всеки  тип, които  картата  може  да съхранява .
 
Присвояване  на стойност : вж. допълнение  2. 
2.110.  NoOfFaultsPerType  
Брой  на неизправностите  от всеки  тип, които  картата  може  да 
съхранява .
 
Присвояване  на стойност : вж. допълнение  2. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 134  
2.111.  NoOfGNSSADRecords  
Поколение  2: 
Брой  на записите  за общо  управление  по GNSS, които  картата  може  
да съхранява .
 
Присвояване  на стойност : вж. допълнение  2. 
▼B 
2.112.  NoOfSpecificConditionRecords  
Поколение  2: 
Брой  на записите  за специфични  условия , които  картата  може  да 
съхранява .
 
Присвояване  на стойност : вж. допълнение  2. 
2.113.  OdometerShort  
Стойност  от километражния  брояч  на превозното  средство  в 
съкратена  форма .
 
Присвояване  на стойност : двоична  без знак. Стойност  в km в 
работния  диапазон  от 0 до 9 999 999 km.  
2.114.  OdometerValueMidnight  
Стойността  от километражния  брояч  в полунощ  от определено  
денонощие  (изискване  090 от приложение  1Б и изискване  113 от 
приложение  1В).
 
Присвояване  на стойност : липса  на допълнителна  информация . 
2.115.  OdometerValueMidnightRecordArray  
Поколение  2: 
OdometerValueMidnight плюс  метаданните , използвани  в протокола  
за изтегляне  на данни .
 
recordType  указва  типа  на записа  (OdometerValueMidnight).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът  на OdometerValueMidnight в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е наборът  от записи  на OdometerValueMidnight.  ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 135  
2.116.  OverspeedNumber  
Брой  на събитията  „превишаване  на скоростта “ след  последната  
проверка  за превишаването  на скоростта .
 
Присвояване  на стойност : 0 означава , че никакво  събитие  „преви­  
шаване  на скоростта “ не е настъпило  след  последната  проверка  за 
превишаването  на скоростта , 1 означава , че едно  събитие  от този 
тип е настъпило  след  последната  проверка  за превишаването  на 
скоростта  … 255 означава , че броят  на събитията  „превишаване  
на скоростта “, настъпили  след  последната  проверка  за превиша­  
ването  на скоростта , е равен  на 255 или надвишава  тази стойност . 
2.117.  PlaceRecord  
Информация  относно  местоположението  в началото  или в края  на 
един  дневен  период  на работа  (изисквания  108, 271, 296, 324 и 347 
от приложение  1В). 
Поколение  1:
 
entryTime  е датата  и часът  във връзка  с въведените  данни . 
entryTypeDailyWorkPeriod  е типът  въведени  данни . 
dailyWorkPeriodCountry  е въведената  държава . 
dailyWorkPeriodRegion  е въведеният  регион . 
vehicleOdometerValue  е стойността  от километражния  брояч  в часа 
на въвеждане  на местоположението . 
Поколение  2:
 
В допълнение  към поколение  1 се използва  следният  компонент : 
entryGNSSPlaceRecord  е записаното  местоположение  и час. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 136  
2.118.  PreviousVehicleInfo  
Информация  за превозното  средство , използвано  преди  това от 
определен  водач  по време  на вкарване  на неговата  карта  в 
бордово  устройство  (изискване  081 от приложение  1Б и изискване  
102 от приложение  1В). 
Поколение  1:
 
vehicleRegistrationIdentification  посочва  VRN и държавата  членка , 
регистрираща  превозното  средство . 
cardWithdrawalTime  е датата  и часът  на изваждане  на картата . 
Поколение  2:
 
В допълнение  към поколение  1 се използва  следният  елемент  от 
данни : 
vuGeneration  идентифицира  поколението  на бордовото  устройство . 
2.119.  PublicKey  
Поколение  1: 
Публичен  ключ  RSA.
  
rsaKeyModulus  е модулът  на двойката  ключове . 
rsaKeyPublicExponent  е публичният  степенен  показател  на 
двойката  ключове . 
2.120.  RecordType  
Поколение  2: 
Посочване  на типа  запис . Този  тип данни  се използва  в Recor­
dArrays.
  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 137  
Присвояване  на стойност :
 
► (1) M1 ActivityChangeInfo, 
CardSlotsStatus, 
CurrentDateTime, 
MemberStateCertificate, 
OdometerValueMidnight, 
DateOfDayDownloaded, 
SensorPaired, 
Signature, 
SpecificConditionRecord, 
VehicleIdentificationNumber, 
VehicleRegistrationNumber, 
VuCalibrationRecord, 
VuCardIWRecord, 
VuCardRecord, 
VuCertificate, 
VuCompanyLocksRecord, 
VuControlActivityRecord, 
VuDetailedSpeedBlock, 
VuDownloadablePeriod, 
VuDownloadActivityData, 
VuEventRecord,  
►M1 VuGNSSADRecord, ◄ 
VuITSConsentRecord, 
VuFaultRecord, 
VuIdentification, 
VuOverSpeedingControlData, 
VuOverSpeedingEventRecord, 
VuPlaceDailyWorkPeriodRecord, 
VuTimeAdjustmentGNSSRecord, 
VuTimeAdjustmentRecord, 
VuPowerSupplyInterruptionRecord, 
SensorPairedRecord, 
SensorExternalGNSSCoupledRecord, 
RFU, 
Зависи  от производителя . 
2.121.  RegionAlpha  
Буквено  означение  на регион  в определена  държава .
 
Поколение  1: 
Присвояване  на стойност :
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 138  
Поколение  2: 
Кодовете  за RegionAlpha трябва  да се съдържат  в списък , 
поддържан  на уебсайта  на лабораторията , определена  да извършва  
изпитванията  за оперативна  съвместимост . 
2.122.  RegionNumeric  
Цифрово  означение  на регион  в определена  държава .
 
Поколение  1: 
Присвояване  на стойност :
 
Поколение  2: 
Кодовете  за RegionNumeric трябва  да се съдържат  в списък , 
поддържан  на уебсайта  на лабораторията , определена  да извършва  
изпитванията  за оперативна  съвместимост . 
2.123.  RemoteCommunicationModuleSerialNumber  
Поколение  2: 
Сериен  номер  на модула  за връзка  от разстояние .
 
2.124.  RSAKeyModulus  
Поколение  1: 
Модули  на двойка  ключове  RSA.
  
Присвояване  на стойност : не е указана . 
2.125.  RSAKeyPrivateExponent  
Поколение  1: 
Частен  степенен  показател  на двойка  ключове  RSA.
  
Присвояване  на стойност : не е указана . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 139  
2.126.  RSAKeyPublicExponent  
Поколение  1: 
Публичен  степенен  показател  на двойка  ключове  RSA.
  
Присвояване  на стойност : не е указана . 
2.127.  RtmData  
Поколение  2: 
за определението  на този тип данни  вж. допълнение  14. 
2.128.  SealDataCard  
Поколение  2: 
Този  тип данни  съхранява  информация  за пломбите , поставени  
върху  различни  компоненти  на превозното  средство , и е пред­  
назначен  за съхранение  върху  карта . Този  тип данни  е свързан  с 
изискване  337 от приложение  1В.
 
noOfSealRecords  е броят  записи  в sealRecords.  
sealRecords  е набор  от записи  за пломбите . 
2.129.  SealDataVu  
Поколение  2: 
Този  тип данни  съхранява  информация  за пломбите , поставени  
върху  различни  компоненти  на превозното  средство , и e пред­  
назначен  за съхранение  в бордово  устройство .
 
sealRecords  е набор  от записи  за пломбите . Ако има по-малко  от 5 
налични  пломби , стойността  на EquipmentType във всички  
неизползвани  sealRecords се фиксира  на 16, т.е. неизползвани . 
2.130.  SealRecord  
Поколение  2: 
Този  тип данни  съхранява  информация  за пломба , вкарана  върху  
компонент . Този  тип данни  е свързан  с изискване  337 от 
приложение  1В.
 
equipmentType  идентифицира  типа  оборудване , върху  което  е 
вкарана  пломбата . 
extendedSealIdentifier  е идентификатор  на пломбата , вкарана  върху  
оборудването . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 140  
2.131.  SensorApprovalNumber  
Номер  на одобрение  на типа  датчик . 
Поколение  1:
 
Присвояване  на стойност : не е указана . 
Поколение  2:
 
Присвояване  на стойност : 
Номерът  на одобрение  е този, който  е публикуван  на съответната  
интернет  страница  на Европейската  комисия , т.е. например , като се 
включват  тиренца , ако има. Номерът  на одобрение  се подравнява  
отляво . 
2.132.  SensorExternalGNSSApprovalNumber  
Поколение  2: 
Номер  на одобрение  на типа  външно  устройство  за GNSS.
  
Присвояване  на стойност : 
Номерът  на одобрение  е този, който  е публикуван  на съответната  
интернет  страница  на Европейската  комисия , т.е. например , като се 
включват  тиренца , ако има. Номерът  на одобрение  се подравнява  
отляво . 
2.133.  SensorExternalGNSSCoupledRecord  
Поколение  2: 
Информация , съхранена  в бордовото  устройство  и отнасяща  се до 
идентификация  на външното  устройство  за GNSS, свързано  с 
бордовото  устройство  (изискване  100 от приложение  1В).
 
sensorSerialNumber  е серийният  номер  на външното  устройство  за 
GNSS, свързано  с бордовото  устройство . 
sensorApprovalNumber  е номерът  на одобрение  на това външно  
устройство  за GNSS.  
sensorCouplingDate  е дата на свързване  на това външно  устройство  
за GNSS с бордовото  устройство . 
2.134.  SensorExternalGNSSIdentification  
Поколение  2: 
Информация , свързана  с идентификацията  на външното  устройство  
за GNSS (изискване  98 от приложение  1В). ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 141
  
sensorSerialNumber  е разширеният  сериен  номер  на външното  
устройство  за GNSS.  
sensorApprovalNumber  е номерът  на одобрение  на външното  
устройство  за GNSS.  
sensorSCIdentifier  е идентификаторът  на компонента  за сигурност  
на външното  устройство  за GNSS.  
sensorOSIdentifier  е идентификаторът  на операционната  система  на 
външното  устройство  за GNSS.  
2.135.  SensorExternalGNSSInstallation  
Поколение  2: 
Информация , съхранена  на външно  устройство  за GNSS и свързана  
с монтирането  на външния  датчик  за GNSS (изискване  123 от 
приложение  1В).
 
sensorCouplingDateFirst  е датата  на първото  свързване  на външно  
устройство  за GNSS с бордово  устройство . 
firstVuApprovalNumber  е номерът  на одобрение  на първото  
бордово  устройство , свързано  с външното  устройство  за GNSS.  
firstVuSerialNumber  е серийният  номер  на първото  бордово  
устройство , свързано  с външното  устройство  за GNSS.  
sensorCouplingDateCurrent  е датата  на свързване  към съответния  
момент  на външно  устройство  за GNSS с бордово  устройство . 
currentVuApprovalNumber  е номерът  на одобрение  на бордовото  
устройство , свързано  към съответния  момент  с външното  
устройство  за GNSS.  
currentVUSerialNumber  е серийният  номер  на бордовото  
устройство , свързано  към съответния  момент  с външното  
устройство  за GNSS.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 142  
2.136.  SensorExternalGNSSOSIdentifier  
Поколение  2: 
Идентификатор  на операционната  система  на външното  устройство  
за GNSS.
  
Присвояване  на стойност : зависи  от производителя . 
2.137.  SensorExternalGNSSSCIdentifier  
Поколение  2: 
Този  тип се използва  например  за идентификация  на криптог­  
рафския  модул  на външното  устройство  за GNSS.  
Идентификатор  на компонента  за сигурност  на външното  
устройство  за GNSS.
  
Присвояване  на стойност : зависи  от производителя  на компо­  
нента . 
2.138.  SensorGNSSCouplingDate  
Поколение  2: 
Дата  на свързване  на външното  устройство  за GNSS с бордово  
устройство .
 
Присвояване  на стойност : не е указана . 
2.139.  SensorGNSSSerialNumber  
Поколение  2: 
Този  тип се използва  за съхранение  на серийния  номер  на 
приемника  на сигнали  от GNSS, когато  е във и извън  бордовото  
устройство . 
Сериен  номер  на приемника  на сигнали  от GNSS.
  
2.140.  SensorIdentification  
Информация , съхранена  на датчик  за движение  и отнасяща  се до 
идентификация  на датчика  за движение  (изискване  077 от 
приложение  1Б и изискване  95 от приложение  1В).
 
sensorSerialNumber  е разширеният  сериен  номер  на датчика  за 
движение  (включително  номер  на частта  и код на производителя ). 
sensorApprovalNumber  е номерът  на одобрение  на датчика  за 
движение . 
sensorSCIdentifier  е идентификаторът  на компонента  за сигурност  
на датчика  за движение . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 143  
sensorOSIdentifier  е идентификаторът  на операционната  система  на 
датчика  за движение . 
2.141.  SensorInstallation  
Информация , съхранена  на датчик  за движение  и отнасяща  се до 
монтирането  на датчика  за движение  (изискване  099 от приложение  
1Б и изискване  122 от приложение  1В).
 
sensorPairingDateFirst  е датата  на първото  сдвояване  на датчика  за 
движение  с бордово  устройство . 
firstVuApprovalNumber  е номерът  на одобрение  на първото  
бордово  устройство , свързано  с датчика  за движение . 
firstVuSerialNumber  е серийният  номер  на първото  бордово  
устройство , свързано  с датчика  за движение . 
sensorPairingDateCurrent  е датата  на сдвояване  към съответния  
момент  на датчика  за движение  с бордовото  устройство . 
currentVuApprovalNumber  е номерът  на одобрение  на бордовото  
устройство , свързано  към съответния  момент  с датчика  за 
движение . 
currentVUSerialNumber  е серийният  номер  на бордовото  
устройство , свързано  към съответния  момент  с датчика  за 
движение . 
2.142.  SensorInstallationSecData  
Информация , съхранена  на карта  за монтаж  и настройки  и отнасяща  
се за данните  относно  сигурността , необходими  за сдвояване  на 
датчиците  за движение  с бордовите  устройства  (изисквания  308 и 
331 от приложение  1В). 
Поколение  1:
 
Присвояване  на стойност : съгласно  стандарт  ISO 16844-3.  
Поколение  2: 
Както  е описано  в допълнение  11, картата  за монтаж  и настройки  
съхранява  до три ключа  за сдвояването  на датчик  за движение  с 
бордово  устройство . Тези  ключове  трябва  да имат  различни  версии  
на ключовете .
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 144  
2.143.  SensorOSIdentifier  
Идентификатор  на операционната  система  на датчика  за движение .
 
Присвояване  на стойност : зависи  от производителя . 
2.144.  SensorPaired  
Поколение  1: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
идентификация  на датчика  за движение , свързан  с бордовото  
устройство  (изискване  079 от приложение  1Б).
 
sensorSerialNumber  е серийният  номер  на датчика  за движение , 
свързан  към съответния  момент  с бордовото  устройство . 
sensorApprovalNumber  е номерът  на одобрение  на датчика  за 
движение , свързан  към съответния  момент  с бордовото  устройство . 
sensorPairingDateFirst  е датата  на първото  сдвояване  с бордово  
устройство  на датчика  за движение , свързан  към съответния  
момент  с бордовото  устройство . 
2.145.  SensorPairedRecord  
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
идентификация  на датчик  за движение , свързан  с бордовото  
устройство  (изискване  97 от приложение  1В).
 
sensorSerialNumber  е серийният  номер  на датчик  за движение , 
свързан  с бордовото  устройство . 
sensorApprovalNumber  е номерът  на одобрение  на този датчик  за 
движение . 
sensorPairingDate  е датата  на сдвояване  на този датчик  за движение  
с бордовото  устройство . 
2.146.  SensorPairingDate  
Дата  на сдвояване  на датчика  за движение  с бордово  устройство .
 
Присвояване  на стойност : не е указана . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 145  
2.147.  SensorSCIdentifier  
Идентификатор  на компонента  за сигурност  на датчика  за 
движение .
 
Присвояване  на стойност : зависи  от производителя  на компо­  
нента . 
2.148.  SensorSerialNumber  
Сериен  номер  на датчика  за движение .
 
2.149.  Signature  
Електронен  подпис . 
Поколение  1:
 
Присвояване  на стойност : съгласно  общите  механизми  за 
сигурност  от допълнение  11. 
Поколение  2:
 
Присвояване  на стойност : съгласно  общите  механизми  за 
сигурност  от допълнение  11. 
2.150.  SignatureRecordArray  
Поколение  2: 
Набор  от подписи  плюс  метаданните , използвани  в протокола  за 
изтегляне  на данни .
 
recordType  указва  типа  запис  (Signature).  Присвояване  на 
стойност : вж. RecordType.  
recordSize  е размерът  на Signature в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . Стойността  се 
определя  на 1, тъй като подписите  могат  да имат  различна  дължина . 
records  е наборът  от подписи . 
2.151.  SimilarEventsNumber  
Броят  на сходните  събития  от определен  ден (изискване  094 от 
приложение  1Б и изискване  117 от приложение  1В).
 
Присвояване  на стойност : 0 не се използва , 1 означава , че само  
едно  събитие  от този тип е настъпило  и е било  съхранено  през 
съответния  ден, 2 означава , че две събития  от този тип са 
настъпили  през съответния  ден (само  едно  от тях е било  съхранено ), 
… 255 означава , че през разглеждания  ден са настъпили  255 или 
повече  събития  от този тип. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 146  
2.152.  SpecificConditionRecord  
Информация , съхранена  на карта  на водач , карта  за монтаж  и 
настройки  или бордово  устройство  и отнасяща  се до определено  
специфично  условие  (изисквания  130, 276, 301, 328 и 355 от 
приложение  1В).
 
entryTime  е датата  и часът  на въвеждането  на тези данни . 
specificConditionType  е кодът , идентифициращ  специфичното  
условие . 
2.153.  SpecificConditions  
Информация , съхранена  на карта  на водач , карта  за монтаж  и 
настройки  или бордово  устройство  и отнасяща  се до определено  
специфично  условие  (изисквания  131, 277, 302, 329 и 356 от 
приложение  1В). 
Поколение  2:
 
conditionPointerNewestRecord  е индексът  на последния  актуа­  
лизиран  запис  за специфично  условие . 
Присвояване  на стойност : число , съответстващо  на номератора  на 
записа  за специфично  условие , като се започва  с 0 за първия  случай  
на запис  за специфично  условие  в структурата . 
specificConditionRecords  е наборът  от записи , съдържащ  
информация  за записаните  специфични  условия . 
2.154.  SpecificConditionType  
Код, идентифициращ  специфично  условие  (изисквания  050б, 105а, 
212а и 230а от приложение  1Б и изискване  62 от приложение  1В).
 
Поколение  1: 
Присвояване  на стойност : 
‘00’H RFU  
‘01’H Извън  обхват  — начало  
‘02’H Извън  обхват — край  
‘03’H Пътуване  с ферибот /влак  
‘04’H .. ‘FF’H RFU  
Поколение  2: 
Присвояване  на стойност : 
‘00’H RFU  
‘01’H Извън  обхват  — начало  
‘02’H Извън  обхват  — край  
‘03’H Пътуване  с ферибот /влак  — начало  
‘04’H Пътуване  с ферибот /влак  — край  
‘05’H .. ‘FF’H RFU  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 147  
2.155.  Speed  
Скорост  на превозното  средство  (km/h).
  
Присвояване  на стойност : километри  на час в работния  диапазон  
от 0 до 220 km/h.  
2.156.  SpeedAuthorised  
Максимална  разрешена  скорост  на превозното  средство  (опред­  
еление  зз).
 
2.157.  SpeedAverage  
Средна  скорост , измерена  в рамките  на предварително  определен  
период  от време  (km/h).
  
2.158.  SpeedMax  
Максимална  скорост , измерена  в рамките  на предварително  
определен  период  от време .
 
2.159.  TachographPayload  
Поколение  2: 
За определението  на този тип данни  вж. допълнение  14. 
▼M1 
2.160.  Reserved for future use  
▼B 
2.161.  TDesSessionKey  
Поколение  1: 
Троен  ключ  на сесия  DES.
  
Присвояване  на стойност : липса  на допълнителна  информация . 
▼M1 
2.162.  TimeReal  
Код за комбинирано  поле  — дата и час, изразени  в секунди , 
считано  от 00ч.00м.00сек. по координираното  универсално  време  
на 1 януари  1970 г.
 
Присвояване  на стойност  — синхронизиран  октет : брой  секунди  
от полунощ  на 1 януари  1970 г. по координираното  универсално  
време . 
Най-далечната  бъдеща  дата/час е през 2106 г. 
▼B 
2.163.  TyreSize  
Обозначение  на размерите  на гумите .
 
Присвояване  на стойност : съгласно  Директива  92/23 (ЕИО ), 
ОВ L 129, 31.3.1992 г., стр. 95. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 148  
2.164.  VehicleIdentificationNumber  
Идентификационен  номер  на превозното  средство  (VIN), отнасящ  
се за цялото  превозно  средство , обикновено  сериен  номер  на шаси  
или номер  на рама .
 
Присвояване  на стойност : съгласно  стандарт  ISO 3779.  
2.165.  VehicleIdentificationNumberRecordArray  
Поколение  2: 
Идентификационният  номер  на превозното  средство  плюс  мета­  
данните , използвани  в протокола  за изтегляне  на данни .
 
recordType  указва  типа  запис  (VehicleIdentificationNumber).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът  на VehicleIdentificationNumber в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е наборът  от идентификационни  номера  на превозни  
средства . 
2.166.  VehicleRegistrationIdentification  
Идентификация  на превозно  средство , която  е уникална  за Европа  
(VRN и държава  членка ).
 
vehicleRegistrationNation  е държавата , в която  е извършена  регист­  
рацията  на превозното  средство . 
vehicleRegistrationNumber  е регистрационният  номер  на 
превозното  средство  (VRN).  
2.167.  VehicleRegistrationNumber  
Регистрационен  номер  на превозното  средство  (VRN). Регистраци­  
онният  номер  се определя  от компетентния  орган  за регистрацията  
на превозните  средства .
 
codePage  указва  набор  от символи , определен  в глава  4. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 149  
vehicleRegNumber  е VRN, кодиран  с използването  на указания  
набор  от символи . 
Присвояване  на стойност : зависи  от държавата . 
2.168.  VehicleRegistrationNumberRecordArray  
Поколение  2: 
Регистрационният  номер  на превозното  средство  плюс  метаданните , 
използвани  в протокола  за изтегляне  на данни .
 
recordType  указва  типа  запис  (VehicleRegistrationNumber).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът  на VehicleRegistrationNumber в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е наборът  от регистрационни  номера  на превозни  средства . 
2.169.  VuAbility  
Поколение  2: 
Информация , съхранена  в бордово  устройство , за възможността  му 
да използва  тахографски  карти  от поколение  1 (изискване  121 от 
приложение  1В).
 
Присвояване  на стойност  — синхронизиран  октет : ‘xxxxxxxa’B 
(8 бита ) 
За възможността  да поддържа  тахографски  карти  от поколение  1: 
‘a’B Възможност  да поддържа  тахографски  карти  от 
поколение  1: 
‘0’ B поддържат  се карти  от поколение  1, 
‘1’B не се поддържат  карти  от поколение  1, 
‘xxxxxxx’B RFU  
2.170.  VuActivityDailyData  
Поколение  1: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
промените  на дейността  и/или промените  на състоянието  при 
управление  и/или промените  на статуса  на картата  за определен  
календарен  ден (изискване  084 от приложение  1Б и изисквания  
105, 106 и 107 от приложение  1В) и за статуса  на процепите  в 
00.00 часа на този ден.
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 150  
noOfActivityChanges  е броят  думи  от ActivityChangeInfo в набора  
activityChangeInfos.  
activityChangeInfos  е наборът  думи  от ActivityChangeInfo, 
съхранени  в бордовото  устройство  за съответния  ден. Той 
съдържа  винаги  две думи  от ActivityChangeInfo, които  указват  
статуса  на двата  процепа  в 00.00 часа на същия  ден. 
2.171.  VuActivityDailyRecordArray  
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
промените  на дейността  и/или промените  на състоянието  при 
управление  и/или промените  на статуса  на картата  за определен  
календарен  ден (изисквания  105, 106 и 107 от приложение  1В) и 
за статуса  на процепите  в 00.00 часа на този ден.
 
recordType  указва  типа  запис  (ActivityChangeInfo).  Присвояване  
на стойност : вж. RecordType.  
recordSize  е размерът  на ActivityChangeInfo в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е наборът  думи  от ActivityChangeInfo, съхранени  в 
бордовото  устройство  за съответния  ден. Той съдържа  винаги  две 
думи  от ActivityChangeInfo, които  указват  статуса  на двата  процепа  
в 00.00 часа на същия  ден. 
2.172.  VuApprovalNumber  
Номер  на одобрение  на типа  на бордовото  устройство . 
Поколение  1:
 
Присвояване  на стойност : не е указана . 
Поколение  2:
 
Присвояване  на стойност : 
Номерът  на одобрение  е този, който  е публикуван  на съответната  
интернет  страница  на Европейската  комисия , т.е. например , като се 
включват  тиренца , ако има. Номерът  на одобрение  се подравнява  
отляво . 
2.173.  VuCalibrationData  
Поколение  1: ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 151  
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
калибриранията  на уредите  за регистриране  на данните  за 
движението  (изискване  098 от приложение  1Б).
 
noOfVuCalibrationRecords  е броят  записи , които  съдържа  наборът  
vuCalibrationRecords.  
vuCalibrationRecords  е наборът  записи  от калибриранията . 
2.174.  VuCalibrationRecord  
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
калибриране  на уредите  за регистриране  на данните  за движението  
(изискване  098 от приложение  1Б и изисквания  119 и 120 от 
приложение  1В). 
Поколение  1:
 
calibrationPurpose  е целта  на калибрирането . 
workshopName, workshopAddress  са наименованието  и адресът  на 
сервиза . 
workshopCardNumber  идентифицира  картата  за монтаж  и наст­  
ройки , използвана  при калибрирането . 
workshopCardExpiryDate  е датата  на край  на валидност  на картата . 
vehicleIdentificationNumber  е VIN.  
vehicleRegistrationIdentification  съдържа  VRN и регистриращата  
държава  членка . 
wVehicleCharacteristicConstant  е характеристичният  коефициент  на 
превозното  средство . 
kConstantOfRecordingEquipment  е константата  на уреда  за регис­  
триране  на данните  за движението . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 152  
lTyreCircumference  е действителната  обиколка  на колелата . 
tyreSize  е обозначение  на размерите  на гумите , монтирани  на 
превозното  средство . 
authorisedSpeed  е разрешената  скорост  на превозното  средство . 
oldOdometerValue и newOdometerValue  са старата  и новата  
стойност , отчетени  от километражния  брояч . 
oldTimeValue, newTimeValue  са старите  и новите  стойности  на 
датата  и часа. 
nextCalibrationDate  е датата  на следващото  калибриране  на типа  в 
CalibrationPurpose, което  оправомощеният  инспектиращ  орган  
трябва  да извърши . 
Поколение  2:
 
В допълнение  към поколение  1 се използва  следният  елемент  от 
данни : 
sealDataVu  дава информация  за пломбите , поставени  върху  
различните  компоненти  на превозното  средство . 
2.175.  VuCalibrationRecordArray  
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
калибриранията  на уредите  за регистриране  на данните  за 
движението  (изисквания  119 и 120 от приложение  1В). ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 153
  
recordType  указва  типа  запис  (VuCalibrationRecord).  Присвояване  
на стойност : вж. RecordType.  
recordSize  е размерът  на VuCalibrationRecord в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е наборът  от записи  за калибрирането . 
2.176.  VuCardIWData  
Поколение  1: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
циклите  на вкарване  и изваждане  на картите  на водач  или картите  
за монтаж  и настройки  в бордовото  устройство  (изискване  081 от 
приложение  1Б и изискване  103 от приложение  1В).
 
noOfIWRecords  е броят  на записите , които  съдържа  наборът  vuCar­
dIWRecords.  
vuCardIWRecords  е набор  от записи  относно  циклите  на вкарване  
и изваждане  на картите . 
2.177.  VuCardIWRecord  
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
цикъла  на вкарване  и изваждане  на карта  на водач  или карта  за 
монтаж  и настройки  в бордовото  устройство  (изискване  081 от 
приложение  1Б и изискване  102 от приложение  1В). 
Поколение  1:
 
cardHolderName  е фамилията , името  и презимето  на титуляря  на 
картата  на водач  или картата  за монтаж  и настройки , съхранени  на 
картата . 
fullCardNumber  е типът  карта , държавата  членка , която  я издава , и 
нейният  номер  на карта , съхранени  на картата . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 154  
cardExpiryDate  е датата  на изтичане  на валидността  на картата , 
както  е съхранена  на нея. 
cardInsertionTime  е датата  и часът  на вкарване  на картата . 
vehicleOdometerValueAtInsertion  е стойността , отчетена  от кило­  
метражния  брояч  при вкарване  на картата . 
cardSlotNumber  е процепът , където  се вкарва  картата . 
cardWithdrawalTime  е датата  и часът  на изваждане  на картата . 
vehicleOdometerValueAtWithdrawal  е стойността , отчетена  от 
километражния  брояч  при изваждане  на картата . 
previousVehicleInfo  съдържа  информация  относно  предишното  
превозно  средство , използвано  от водача , както  е съхранена  на 
картата . 
manualInputFlag  е знак, позволяващ  да се разбере  дали  титулярят  
на картата  е извършил  ръчно  въвеждане  на дейностите  на водача  
при вкарване  на картата . 
Поколение  2:
 
Вместо  fullCardNumber структурата  на данните  от поколение  2 
използва  следния  елемент  от данни . 
fullCardNumberAndGeneration  е типът  карта , държавата  членка , 
която  я издава , нейният  номер  на карта  и поколението , съхранени  
на картата . 
2.178.  VuCardIWRecordArray  
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се до 
циклите  на вкарване  и изваждане  на карти  на водач  или карти  за 
монтаж  и настройки  в бордовото  устройство  (изискване  103 от 
приложение  1В).
 
recordType  указва  типа  запис  (VuCardIWRecord).  Присвояване  на 
стойност : вж. RecordType.  
recordSize  е размерът  на VuCardIWRecord в байтове . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 155  
noOfRecords  е броят  на записите  в набора  от записи . 
records  е набор  от записи  относно  циклите  на вкарване  и изваждане  
на картите . 
▼M1 
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.  
▼B 
2.180.  VuCardRecordArray  
Поколение  2: 
Информация , съхранена  в бордово  устройство  относно  използвани  
тахографски  карти  с това бордово  устройство . Тази  информация  е 
предназначена  за анализа  на бордово  устройство  — проблеми  с 
картата  (изискване  132 от приложение  1В).
 
recordType  указва  типа  запис  (VuCardRecord).  Присвояване  на 
стойност : вж. RecordType.  
recordSize  е размерът  на VuCardRecord в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е набор  от записи  относно  използваните  тахографски  карти  
с бордовото  устройство . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 156  
2.181.  VuCertificate  
Сертификат  на публичния  ключ  на бордово  устройство .
 
2.182.  VuCertificateRecordArray  
Поколение  2: 
Сертификатът  за бордовото  устройство  плюс  метаданните , 
използвани  в протокола  за изтегляне  на данни .
 
recordType  указва  типа  запис  (VuCertificate).  Присвояване  на 
стойност : вж. RecordType.  
recordSize  е размерът  на VuCertificate в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . Стойността  се 
определя  на 1, тъй като сертификатите  могат  да имат  различна  
дължина . 
records  е наборът  от сертификати  за бордови  устройства . 
2.183.  VuCompanyLocksData  
Поколение  1: 
Информация , съхранена  в бордово  устройство  и отнасяща  се до 
блокировките  на превозвач  (изискване  104 от приложение  1Б).
 
noOfLocks  е броят  на блокировките , посочени  в vuCompanyLocks ­
Records.  
vuCompanyLocksRecords  е набор  от записи  за блокировките  на 
превозвач . 
2.184.  VuCompanyLocksRecord  
Информация , съхранена  в бордово  устройство  и отнасяща  се до 
блокировка  на превозвач  (изискване  104 от приложение  1Б и 
изискване  128 от приложение  1В). 
Поколение  1:
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 157  
lockInTime, lockOutTime  са датата  и часът  на блокиране  и отбло­  
киране . 
companyName, companyAddress  са наименованието  и адресът  на 
превозвача , свързан  с блокирането . 
companyCardNumber  идентифицира  картата , използвана  при 
блокирането . 
Поколение  2:
 
Вместо  companyCardNumber структурата  на данните  от поколение  2 
използва  следния  елемент  от данни . 
companyCardNumberAndGeneration  идентифицира  картата , вклю­  
чително  поколението  ѝ, използвана  при блокирането . 
2.185.  VuCompanyLocksRecordArray  
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
блокировките  на превозвач  (изискване  128 от приложение  1В).
 
recordType  указва  типа  запис  (VuCompanyLocksRecord).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът  на VuCompanyLocksRecord в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . Стойност  
0..255.  
records  е наборът  от записи  за блокировките  на превозвач . 
2.186.  VuControlActivityData  
Поколение  1: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
проверките , извършени  с помощта  на това устройство  (изискване  
102 от приложение  1Б).
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 158  
noOfControls  е броят  на проверките , посочени  в vuControlActivity ­
Records.  
vuControlActivityRecords  е наборът  от записи  за контролната  
дейност . 
2.187.  VuControlActivityRecord  
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
проверка , извършена , като е използвано  това устройство  (изискване  
102 от приложение  1Б и изискване  126 от приложение  1В). 
Поколение  1:
 
controlType  е типът  проверка . 
controlTime  е датата  и часът  на проверката . 
controlCardNumber  идентифицира  контролната  карта , използвана  
за проверката . 
downloadPeriodBeginTime  е началото  на периода  на изтегляне  на 
данните . 
downloadPeriodEndTime  е краят  на периода  на изтегляне  на 
данните . 
Поколение  2:
 
Вместо  controlCardNumber структурата  на данните  от поколение  2 
използва  следния  елемент  от данни . 
controlCardNumberAndGeneration  идентифицира  контролната  
карта , включително  поколението  ѝ, използвана  за проверката . 
2.188.  VuControlActivityRecordArray  
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се до 
проверките , извършени  с помощта  на това устройство  (изискване  
126 от приложение  1В). ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 159
  
recordType  указва  типа  запис  (VuControlActivityRecord).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът  на VuControlActivityRecord в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е наборът  от записи  за контролната  дейност  на бордовото  
устройство . 
2.189.  VuDataBlockCounter  
Брояч , записан  на карта  и идентифициращ  последователно  циклите  
на вкарване  и изваждане  на картата  в бордови  устройства .
 
Присвояване  на стойност : последователни  номера , с максималната  
стойност  от 9999, като се започва  от 0. 
2.190.  VuDetailedSpeedBlock  
Информация , съхранена  в бордово  устройство  и отнасяща  се до 
подробните  данни  за скоростта  на превозното  средство  в 
продължение  на една  минута , по време  на която  превозното  
средство  е било  в движение  (изискване  093 от приложение  1Б и 
изискване  116 от приложение  1В).
 
speedBlockBeginDate  е датата  и часът  на първата  стойност  на 
скоростта  в блока . 
speedsPerSecond  е хронологичната  последователност  на скоростите , 
измерени  във всички  секунди  на минутата , започвайки  при 
скоростта  от speedBlockBeginDate ( включена ). 
2.191.  VuDetailedSpeedBlockRecordArray  
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
подробните  данни  за скоростта  на превозното  средство .
 
recordType  указва  типа  запис  (VuDetailedSpeedBlock).  
Присвояване  на стойност : вж. RecordType.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 160  
recordSize  е размерът  на VuDetailedSpeedBlock в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е наборът  от блокове  с подробни  данни  за скоростта . 
2.192.  VuDetailedSpeedData  
Поколение  1: 
Информация , съхранена  в бордово  устройство  и отнасяща  се до 
подробните  данни  за скоростта  на превозното  средство .
 
noOfSpeedBlocks  е броят  на блоковете  с данни  за скоростта  в 
набора  vuDetailedSpeedBlocks.  
vuDetailedSpeedBlocks  е наборът  блокове  с подробни  данни  за 
скоростта . 
2.193.  VuDownloadablePeriod  
Най-старите  и най-скорошните  дати , за които  определено  бордово  
устройство  съдържа  данни  относно  дейностите  на водачите  
(изисквания  081, 084 или 087 от приложение  1Б и изисквания  
102, 105 и 108 от приложение  1В).
 
minDownloadableTime  е датата  и часът  на най-отдалеченото  във 
времето  вкарване  на карта , промяна  на дейността  или въвеждане  
на местоположението , съхранени  в бордовото  устройство . 
maxDownloadableTime  е датата  и часът  на последното  вкарване  на 
карта , промяна  на дейността  или въвеждане  на местоположението , 
съхранени  в бордовото  устройство . 
2.194.  VuDownloadablePeriodRecordArray  
Поколение  2: 
VUDownloadablePeriod плюс  метаданните , използвани  в протокола  
за изтегляне  на данни .
 
recordType  указва  типа  запис  (VuDownloadablePeriod).  
Присвояване  на стойност : вж. RecordType.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 161  
recordSize  е размерът  на VuDownloadablePeriod в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е наборът  от записи  от VuDownloadablePeriod.  
2.195.  VuDownloadActivityData  
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
последното  ѝ изтегляне  (изискване  105 от приложение  1Б и 
изискване  129 от приложение  1В). 
Поколение  1:
 
downloadingTime  е датата  и часът  на изтегляне  на данни . 
fullCardNumber  идентифицира  картата , използвана  за разрешаване  
на изтеглянето  на данните . 
companyOrWorkshopName  е наименованието  на превозвача  или 
сервиза . 
Поколение  2:
 
Вместо  fullCardNumber структурата  на данните  от поколение  2 
използва  следния  елемент  от данни . 
fullCardNumberAndGeneration  идентифицира  картата , вклю­  
чително  поколението  ѝ, използвана  за разрешаване  на изтеглянето  
на данните . 
2.196.  VuDownloadActivityDataRecordArray  
Поколение  2: 
Информация , свързана  с последните  изтеглени  данни  за бордовото  
устройство  (изискване  129 от приложение  1В).
 
recordType  указва  типа  запис  (VuDownloadActivityData).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът  на VuDownloadActivityData в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 162  
records  е наборът  от записи  на изтеглени  данни  за дейността . 
2.197.  VuEventData  
Поколение  1: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
събития  (изискване  094 от приложение  1Б с изключение  на 
събитията  „превишаване  на скоростта “).
 
noOfVuEvents  е броят  на събитията , посочени  в набора  vuEventRe ­
cords.  
vuEventRecords  е набор  записи  за събития . 
2.198.  VuEventRecord  
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
събитие  (изискване  094 от приложение  1Б и изискване  117 от 
приложение  1В с изключение  на събитията  „превишаване  на 
скоростта “). 
Поколение  1:
 
eventType  е типът  на събитието . 
eventRecordPurpose  е целта  на записване  на събитието . 
eventBeginTime  е датата  и часът  на начало  на събитието . 
eventEndTime  е датата  и часът  на край  на събитието . 
cardNumberDriverSlotBegin  идентифицира  картата , вкарана  в 
процепа  за водача  в началото  на събитието . 
cardNumberCodriverSlotBegin  идентифицира  картата , вкарана  в 
процепа  за втория  водач  в началото  на събитието . 
cardNumberDriverSlotEnd  идентифицира  картата , вкарана  в 
процепа  за водача  в края  на събитието . 
cardNumberCodriverSlotEnd  идентифицира  картата , вкарана  в 
процепа  за втория  водач  в края  на събитието . 
similarEventsNumber  е броят  на сходните  събития  през същия  ден. 
Тази  последователност  може  да се използва  за всички  събития , 
различни  от „превишаване  на скоростта “. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 163  
Поколение  2:
 
В допълнение  към поколение  1 се използват  следните  елементи  от 
данни : 
manufacturerSpecificEventFaultData  съдържа  допълнителна  
конкретна  информация  от производителя  за събитието . 
Вместо  cardNumberDriverSlotBegin, cardNumberCodriverSlotBegin, 
cardNumberDriverSlotEnd и cardNumberCodriverSlotEnd структурата  
на данните  от поколение  2 използва  следните  елементи  от данни : 
cardNumberAndGenDriverSlotBegin  идентифицира  картата , вклю­  
чително  поколението  ѝ, вкарана  в процепа  за водача  в началото  
на събитието . 
cardNumberAndGenCodriverSlotBegin  идентифицира  картата , 
включително  поколението  ѝ, вкарана  в процепа  за втория  водач  в 
началото  на събитието . 
cardNumberAndGenDriverSlotEnd  идентифицира  картата , вклю­  
чително  поколението  ѝ, вкарана  в процепа  за водача  в края  на 
събитието . 
cardNumberAndGenCodriverSlotEnd  идентифицира  картата , вклю­  
чително  поколението  ѝ, вкарана  в процепа  за втория  водач  в края  
на събитието . 
Ако събитието  е „времеви  конфликт “, eventBeginTime и even­
tEndTime трябва  да се тълкуват , както  следва : 
eventBeginTime  е датата  и часът  на уредите  за регистриране  на 
данните  за движението . 
eventEndTime  е датата  и часът  по GNSS.  
2.199.  VuEventRecordArray  
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се до 
събития  (изискване  117 от приложение  1В с изключение  на 
събитията  „превишаване  на скоростта “).
 
recordType  указва  типа  запис  (VuEventRecord).  Присвояване  на 
стойност : вж. RecordType.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 164  
recordSize  е размерът  на VuEventRecord в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е набор  записи  за събития . 
2.200.  VuFaultData  
Поколение  1: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
неизправности  (изискване  096 от приложение  1Б).
 
noOfVuFaults  е броят  на неизправностите , посочени  в набора  vuFa­
ultRecords.  
vuFaultRecords  е набор  записи  на неизправности . 
2.201.  VuFaultRecord  
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
неизправност  (изискване  096 от приложение  1Б и изискване  118 
от приложение  1В). 
Поколение  1:
 
faultType  е типът  на неизправността  на уредите  за регистриране  на 
данните  за движението . 
faultRecordPurpose  е целта  на записване  на неизправността . 
faultBeginTime  е датата  и часът  на начало  на неизправността . 
faultEndTime  е датата  и часът  на край  на неизправността . 
cardNumberDriverSlotBegin  идентифицира  картата , вкарана  в 
процепа  за водача  в началото  на неизправността . 
cardNumberCodriverSlotBegin  идентифицира  картата , вкарана  в 
процепа  за втория  водач  в началото  на неизправността . 
cardNumberDriverSlotEnd  идентифицира  картата , вкарана  в 
процепа  за водача  в края  на неизправността . 
cardNumberCodriverSlotEnd  идентифицира  картата , вкарана  в 
процепа  за втория  водач  в края  на неизправността . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 165  
Поколение  2:
 
В допълнение  към поколение  1 се използват  следните  елементи  от 
данни : 
manufacturerSpecificEventFaultData  съдържа  допълнителна  
конкретна  информация  от производителя  за неизправността . 
Вместо  cardNumberDriverSlotBegin, cardNumberCodriverSlotBegin, 
cardNumberDriverSlotEnd и cardNumberCodriverSlotEnd структурата  
на данните  от поколение  2 използва  следните  елементи  от данни : 
cardNumberAndGenDriverSlotBegin  идентифицира  картата , вклю­  
чително  поколението  ѝ, вкарана  в процепа  за водача  в началото  
на неизправността . 
cardNumberAndGenCodriverSlotBegin  идентифицира  картата , 
включително  поколението  ѝ, вкарана  в процепа  за втория  водач  в 
началото  на неизправността . 
cardNumberAndGenDriverSlotEnd  идентифицира  картата , вклю­  
чително  поколението  ѝ, вкарана  в процепа  за водача  в края  на 
неизправността . 
cardNumberAndGenCodriverSlotEnd  идентифицира  картата , вклю­  
чително  поколението  ѝ, вкарана  в процепа  за втория  водач  в края  
на неизправността . 
2.202.  VuFaultRecordArray  
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
неизправности  (изискване  118 от приложение  1В).
 
recordType  указва  типа  запис  (VuFaultRecord).  Присвояване  на 
стойност : вж. RecordType.  
recordSize  е размерът  на VuFaultRecord в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е набор  записи  за неизправности . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 166  
2.203.  VuGNSSADRecord  
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
местоположението  на превозното  средство  по GNSS, ако общото  
време  на управление  на МПС  достигне  кратно  число  на три часа 
(съгласно  изискванията  в подточки  108 и 110 от приложение  IВ).
 
timeStamp  е датата  и часът , когато  общото  време  на управление  на 
МПС  достигне  кратно  число  на три часа. 
cardNumberAndGenDriverSlot  идентифицира  картата , вкарана  в 
процепа  за водача , в т.ч. поколението  ѝ. 
cardNumberAndGenCodriverSlot  идентифицира  картата , вкарана  в 
процепа  за втория  водач , в т.ч. поколението  ѝ. 
gnssPlaceRecord  съдържа  информация  за местоположението  на 
превозното  средство . 
vehicleOdometerValue  е стойността  от километражния  брояч , 
когато  общото  време  на управление  на МПС  достигне  кратно  
число  на три часа. 
2.204.  VuGNSSADRecordArray  
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
местоположението  на превозното  средство  по GNSS, ако общото  
време  на управление  на МПС  достигне  кратно  число  на три часа 
(съгласно  изискванията  в подточки  108 и 110 от приложение  IВ).
 
recordType  указва  типа  запис  (VuGNSSADRecord).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът  на VuGNSSADRecord в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
Records  е набор  от записи  за общо  управление  по GNSS.  
▼B 
2.205.  VuIdentification  
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
идентификация  на бордовото  устройство  (изискване  075 от 
приложение  1Б и изисквания  93 и 121 от приложение  1В). ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 167  
Поколение  1:
 
vuManufacturerName  е наименованието  на производителя  на 
бордовото  устройство . 
vvuManufacturerAddress  е адресът  на производителя  на бордовото  
устройство . 
vuPartNumber  е фабричният  номер  на бордовото  устройство . 
vuSerialNumber  е серийният  номер  на бордовото  устройство . 
vuSoftwareIdentification  идентифицира  софтуера , използван  в 
бордовото  устройство . 
vuManufacturingDate  е датата  на производство  на бордовото  
устройство . 
vuApprovalNumber  е номерът  на одобрение  на типа  на бордовото  
устройство . 
Поколение  2:
 
В допълнение  към поколение  1 се използват  следните  елементи  от 
данни : 
vuGeneration  идентифицира  поколението  на бордовото  устройство . 
vuAbility  осигурява  информация  дали  бордовото  устройство  
поддържа  тахографски  карти  от поколение  1. 
2.206.  VuIdentificationRecordArray  
Поколение  2: 
VuIdentification плюс  метаданните , използвани  в протокола  за 
изтегляне  на данни . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 168
  
recordType  указва  типа  запис  (VuIdentification).  Присвояване  на 
стойност : вж. RecordType.  
recordSize  е размерът  на VuIdentification в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е набор  записи  от VuIdentification.  
2.207.  VuITSConsentRecord  
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
съгласието  на водача  да използва  интелигентни  транспортни  
системи .
 
cardNumberAndGen  идентифицира  картата , включително  поко­  
лението  ѝ. Това  трябва  да е карта  на водач  или карта  за монтаж  
и настройки . 
consent  е флаг , който  указва  дали  водачът  е дал съгласието  си за 
използването  на интелигентни  транспортни  системи  на това 
превозно  средство /бордово  устройство . 
Присвояване  на стойност : 
TRUE указва  съгласието  на водача  да използва  интелигентни  
транспортни  системи  
FALSE указва  отказа  на водача  да използва  интелигентни  транс­  
портни  системи  
2.208.  VuITSConsentRecordArray  
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
съгласието  на водачите  да използват  интелигентни  транспортни  
системи  (изискване  200 от приложение  1В).
 
recordType  указва  типа  запис  (VuITSConsentRecord).  Присвояване  
на стойност : вж. RecordType.  
recordSize  е размерът  на VuITSConsentRecord в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е наборът  от записи  за съгласието  във връзка  с интели­  
гентните  транспортни  системи . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 169  
2.209.  VuManufacturerAddress  
Адрес  на производителя  на бордовото  устройство .
 
Присвояване  на стойност : не е указана . 
2.210.  VuManufacturerName  
Наименование  на производителя  на бордовото  устройство .
 
Присвояване  на стойност : не е указана . 
2.211.  VuManufacturingDate  
Дата  на производство  на бордовото  устройство .
 
Присвояване  на стойност : не е указана . 
2.212.  VuOverSpeedingControlData  
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
събитията  „превишаване  на скоростта “, настъпили  след  извършване  
на последната  проверка  за превишаване  на скоростта  (изискване  095 
от приложение  1Б и изискване  117 от приложение  1В).
 
lastOverspeedControlTime  е датата  и часът  на последната  проверка  
за превишаване  на скоростта . 
firstOverspeedSince  е датата  и часът  на първото  превишаване  на 
скоростта  след  последната  проверка  за превишаване  на скоростта . 
numberOfOverspeedSince  е броят  на събитията  „превишаване  на 
скоростта “ след  последната  проверка  за превишаване  на скоростта . 
2.213.  VuOverSpeedingControlDataRecordArray  
Поколение  2: 
VuOverSpeedingControlData плюс  метаданните , използвани  в 
протокола  за изтегляне  на данни .
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 170  
recordType  указва  типа  запис  (VuOverSpeedingControlData).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът  на VuOverSpeedingControlData в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е набор  от записи  с данни  за проверките  за превишаване  на 
скоростта . 
2.214.  VuOverSpeedingEventData  
Поколение  1: 
Информация , съхранена  в бордово  устройство  и отнасяща  се до 
събитията  „превишаване  на скоростта “ (изискване  094 от 
приложение  1Б).
 
noOfVuOverSpeedingEvents  е броят  на събитията , посочени  в 
набора  vuOverSpeedingEventRecords.  
vuOverSpeedingEventRecords  е набор  от записи  на събития  „пре­  
вишаване  на скоростта “. 
2.215.  VuOverSpeedingEventRecord  
Поколение  1: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
събития  „превишаване  на скоростта “ (изискване  094 от приложение  
1Б и изискване  117 от приложение  1В).
 
eventType  е типът  на събитието . 
eventRecordPurpose  е целта  на записване  на събитието . 
eventBeginTime  е датата  и часът  на начало  на събитието . 
eventEndTime  е датата  и часът  на край  на събитието . 
maxSpeedValue  е максималната  скорост , измерена  по време  на 
събитието . 
averageSpeedValue  е средноаритметичната  скорост , измерена  по 
време  на събитието . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 171  
cardNumberDriverSlotBegin  идентифицира  картата , вкарана  в 
процепа  за водача  в началото  на събитието . 
similarEventsNumber  е броят  на сходните  събития  през същия  ден. 
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
събития  „превишаване  на скоростта “ (изискване  094 от приложение  
1Б и изискване  117 от приложение  1В).
 
Вместо  cardNumberDriverSlotBegin структурата  на данните  от 
поколение  2 използва  следния  елемент  от данни : 
cardNumberAndGenDriverSlotBegin  идентифицира  картата , вклю­  
чително  поколението  ѝ, вкарана  в процепа  за водача  в началото  
на събитието . 
2.216.  VuOverSpeedingEventRecordArray  
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се до 
събитията  „превишаване  на скоростта “ (изискване  117 от 
приложение  1В).
 
recordType  указва  типа  запис  (VuOverSpeedingEventRecord).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът  на VuOverSpeedingEventRecord в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е набор  от записи  за събития  „превишаване  на скоростта “. 
2.217.  VuPartNumber  
Фабричен  номер  на бордовото  устройство .
 
Присвояване  на стойност : зависи  от производителя  на бордовото  
устройство . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 172  
2.218.  VuPlaceDailyWorkPeriodData  
Поколение  1: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
местоположенията  в началото  или края  на дневен  период  на 
работа  на водачите  (изискване  087 от приложение  1Б и изисквания  
108 и 110 от приложение  1В).
 
noOfPlaceRecords  е броят  на записите , посочени  в набора  vuPlace­
DailyWorkPeriodRecords.  
vuPlaceDailyWorkPeriodRecords  е набор  от записи  във връзка  с 
местоположения . 
2.219.  VuPlaceDailyWorkPeriodRecord  
Поколение  1: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
местоположение  в началото  или края  на дневен  период  на работа  
на водач  (изискване  087 от приложение  1Б и изисквания  108 и 110 
от приложение  1В).
 
fullCardNumber  е типът  карта  на водач , държавата  членка , която  
издава  картата , и номерът  на картата . 
placeRecord  съдържа  данни  относно  въведеното  местоположение . 
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
местоположение  в началото  или края  на дневен  период  на работа  
на водач  (изискване  087 от приложение  1Б и изисквания  108 и 110 
от приложение  1В).
 
Вместо  fullCardNumber структурата  на данните  от поколение  2 
използва  следния  елемент  от данни : 
fullCardNumberAndGeneration  е типът  карта , държавата  членка , 
която  я издава , нейният  номер  на карта  и поколението , съхранени  
на картата . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 173  
2.220.  VuPlaceDailyWorkPeriodRecordArray  
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се до 
местоположенията  в началото  или края  на дневен  период  на 
работа  на водачи  (изисквания  108 и 110 от приложение  1В).
 
recordType  указва  типа  запис  (VuPlaceDailyWorkPeriodRecord).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът  на VuPlaceDailyWorkPeriodRecord в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е набор  записи  във връзка  с местоположението . 
2.221.  VuPrivateKey  
Поколение  1: 
Частен  ключ  на бордово  устройство .
 
2.222.  VuPublicKey  
Поколение  1: 
Публичен  ключ  на бордово  устройство .
 
2.223.  VuSerialNumber  
Сериен  номер  на бордовото  устройство  (изискване  075 от 
приложение  1Б и изискване  93 от приложение  1В).
 
2.224.  VuSoftInstallationDate  
Дата  на инсталиране  на версията  на софтуера  на бордовото  
устройство .
 
Присвояване  на стойност : не е указана . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 174  
2.225.  VuSoftwareIdentification  
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
инсталирания  софтуер .
 
vuSoftwareVersion  е номерът  на версията  на софтуера  на бордовото  
устройство . 
vuSoftInstallationDate  е датата  на инсталиране  на версията  на 
софтуера . 
2.226.  VuSoftwareVersion  
Номер  на версията  на софтуера  на бордовото  устройство .
 
Присвояване  на стойност : не е указана . 
2.227.  VuSpecificConditionData  
Поколение  1: 
Информация , съхранена  в бордово  устройство  и отнасяща  се до 
специфични  условия .
 
noOfSpecificConditionRecords  е броят  на записите , посочени  в 
набора  от specificConditionRecords.  
specificConditionRecords  е набор  записи  във връзка  със специфични  
условия . 
2.228.  VuSpecificConditionRecordArray  
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
специфични  условия  (изискване  130 от приложение  1В).
 
recordType  указва  типа  запис  (SpecificConditionRecord).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът  на SpecificConditionRecord в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е набор  от записи  във връзка  със специфични  условия . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 175  
2.229.  VuTimeAdjustmentData  
Поколение  1: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
сверяването  на часовника , извършено  извън  рамките  на редовното  
калибриране  (изискване  101 от приложение  1Б).
 
noOfVuTimeAdjRecords  е броят  на записите  в vuTimeAdjustmen ­
tRecords . 
vuTimeAdjustmentRecords  е набор  записи  относно  сверяването  на 
часовника . 
▼M1 
2.230.  Reserved for future use  
2.231.  Reserved for future use  
▼B 
2.232.  VuTimeAdjustmentRecord  
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
сверяването  на часовника , извършено  извън  рамките  на редовното  
калибриране  (изискване  101 от приложение  1Б и изисквания  124 и 
125 от приложение  1В). 
Поколение  1:
 
oldTimeValue, newTimeValue  са старите  и новите  стойности  на 
датата  и часа. 
workshopName, workshopAddress  са наименованието  и адресът  на 
сервиза . 
workshopCardNumber  идентифицира  картата  за монтаж  и наст­  
ройки , използвана  за сверяване  на часовника . 
Поколение  2:
 
Вместо  workshopCardNumber структурата  на данните  от поколение  
2 използва  следния  елемент  от данни . 
workshopCardNumberAndGeneration  идентифицира  картата  за 
монтаж  и настройки , включително  поколението  ѝ, използвана  за 
сверяване  на часовника . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 176  
2.233.  VuTimeAdjustmentRecordArray  
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
сверяването  на часовника , извършено  извън  рамките  на редовното  
калибриране  (изисквания  124 и 125 от приложение  1В).
 
recordType  указва  типа  запис  (VuTimeAdjustmentRecord).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът  на VuTimeAdjustmentRecord в байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е набор  от записи  за сверяване  на часовника . 
2.234.  WorkshopCardApplicationIdentification  
Информация , съхранена  на карта  за монтаж  и настройки  и отнасяща  
се за идентификация  на приложението  на картата  (изисквания  307 и 
330 от приложение  1В). 
Поколение  1:
 
typeOfTachographCardId  обозначава  използвания  тип карта . 
cardStructureVersion  указва  версията  на структурата , приложена  в 
картата . 
noOfEventsPerType  е броят  на събитията  от всеки  тип, които  
картата  може  да запише . 
noOfFaultsPerType  е броят  на неизправностите  от всеки  тип, които  
картата  може  да запише . 
activityStructureLength  указва  броя  на байтовете , които  могат  да се 
използват  за съхранение  на записите  за дейността . 
noOfCardVehicleRecords  е броят  на записите  за превозното  
средство , които  картата  може  да съдържа . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 177  
noOfCardPlaceRecords  е броят  на местоположенията , които  картата  
може  да запише . 
noOfCalibrationRecords  е броят  на записите  за калибриранията , 
които  картата  може  да съхрани . 
Поколение  2: 
▼M1
 
В допълнение  към поколение  1 се използват  следните  елементи  от 
данни : 
noOfGNSSADRecords  е броят  на записите  за общо  управление  по 
GNSS, които  картата  може  да съхранява . 
noOfSpecificConditionRecords  е броят  на записите  за специфични  
условия , които  картата  може  да съхранява . 
noOfCardVehicleUnitRecords  е броят  на записите  за използваните  
бордови  устройства , които  картата  може  да съхранява . 
▼B 
2.235.  WorkshopCardCalibrationData  
Информация , съхранена  на карта  за монтаж  и настройки  и отнасяща  
се до определена  сервизна  дейност , извършена  с картата  
(изисквания  314, 316, 337 и 339 от приложение  1В).
 
calibrationTotalNumber  е общият  брой  на извършените  с картата  
калибрирания . 
calibrationPointerNewestRecord  е индексът  на последния  актуа­  
лизиран  запис  за калибриране . 
Присвояване  на стойност : число , съответстващо  на номератора  на 
запис  за калибриране , като се започва  с 0 за първия  случай  на запис  
за калибриране  в структурата . 
calibrationRecords  е набор  от записи , съдържащи  информация  за 
калибрирането  и/или сверяването  на часовника . 
2.236.  WorkshopCardCalibrationRecord  
Информация , съхранена  на карта  за монтаж  и настройки  и отнасяща  
се за калибриране , извършено  с картата  (изисквания  314 и 337 от 
приложение  1В). ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 178  
Поколение  1:
 
calibrationPurpose  е целта  на калибрирането . 
vehicleIdentificationNumber  е VIN.  
vehicleRegistration  съдържа  VRN и регистриращата  държава  
членка . 
wVehicleCharacteristicConstant  е характеристичният  коефициент  на 
превозното  средство . 
kConstantOfRecordingEquipment  е константата  на уреда  за регис­  
триране  на данните  за движението . 
lTyreCircumference  е действителната  обиколка  на колелата . 
tyreSize  е обозначение  на размерите  на гумите , монтирани  на 
превозното  средство . 
authorisedSpeed  е разрешената  максимална  скорост  на превозното  
средство . 
oldOdometerValue и newOdometerValue  са старата  и новата  
стойност , отчетени  от километражния  брояч . 
oldTimeValue, newTimeValue  са старите  и новите  стойности  на 
датата  и часа. 
nextCalibrationDate  е датата  на следващото  калибриране  на типа  в 
CalibrationPurpose, което  оправомощеният  инспектиращ  орган  
трябва  да извърши . 
vuPartNumber , vuSerialNumber  и sensorSerialNumber  са елементи  
от данни , необходими  за идентификация  на уредите  за регистриране  
на данните  за движението . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 179  
Поколение  2:
 
В допълнение  към поколение  1 се използват  следните  елементи  от 
данни : 
sensorGNSSSerialNumber  идентифицира  външното  устройство  за 
GNSS.  
rcmSerialNumber  идентифицира  модула  за връзка  от разстояние . 
sealDataVu  дава информация  за пломбите , поставени  върху  
различните  компоненти  на превозното  средство . 
2.237.  WorkshopCardHolderIdentification  
Информация , съхранена  на карта  за монтаж  и настройки  и отнасяща  
се за идентификация  на титуляря  на картата  (изисквания  311 и 334 
от приложение  1В).
 
workshopName  е наименованието  на сервиза  на титуляря  на 
картата . 
workshopAddress  е адресът  на сервиза  на титуляря  на картата . 
cardHolderName  е фамилията  и името  (и презимето ) на титуляря  
(например  името  на механика ). 
cardHolderPreferredLanguage  е предпочитаният  език на титуляря  
на картата . 
2.238.  WorkshopCardPIN  
Персонален  идентификационен  номер  на картата  за монтаж  и 
настройки  (изисквания  309 и 332 от приложение  1В).
 
Присвояване  на стойност : PIN, известен  на титуляря  на картата , 
запълнен  отдясно  със серия  от байтове  „FF“, която  може  да 
съдържа  до 8 байта . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 180  
2.239.  W-VehicleCharacteristicConstant  
Характеристичен  коефициент  на превозното  средство  (определение  
к).
 
Присвояване  на стойност : импулси  на километър  в работния  
диапазон  от 0 до 64 255 имп./km.  
2.240.  VuPowerSupplyInterruptionRecord  
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се до 
събитията  „прекъсване  на електрическото  захранване “ (изискване  
117 от приложение  1В).
 
eventType  е типът  на събитието . 
eventRecordPurpose  е целта  на записване  на събитието . 
eventBeginTime  е датата  и часът  на начало  на събитието . 
eventEndTime  е датата  и часът  на край  на събитието . 
cardNumberAndGenDriverSlotBegin  идентифицира  картата , вклю­  
чително  поколението  ѝ, вкарана  в процепа  за водача  в началото  
на събитието . 
cardNumberAndGenDriverSlotEnd  идентифицира  картата , вклю­  
чително  поколението  ѝ, вкарана  в процепа  за водача  в края  на 
събитието . 
cardNumberAndGenCodriverSlotBegin  идентифицира  картата , 
включително  поколението  ѝ, вкарана  в процепа  за втория  водач  в 
началото  на събитието . 
cardNumberAndGenCodriverSlotEnd  идентифицира  картата , вклю­  
чително  поколението  ѝ, вкарана  в процепа  за втория  водач  в края  на 
събитието . 
similarEventsNumber  е броят  на сходните  събития  през същия  ден. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 181  
2.241.  VuPowerSupplyInterruptionRecordArray  
Поколение  2: 
Информация , съхранена  в бордово  устройство  и отнасяща  се за 
събитията  „прекъсване  на електрическото  захранване “ (изискване  
117 от приложение  1В).
 
recordType  указва  типа  запис  (VuPowerSupplyInterruptionRecord).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът  на VuPowerSupplyInterruptionRecord в 
байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е набор  от записи  за събития  „прекъсване  на електри­  
ческото  захранване “. 
2.242.  VuSensorExternalGNSSCoupledRecordArray  
Поколение  2: 
Набор  от SensorExternalGNSSCoupledRecord плюс  метаданните , 
използвани  в протокола  за изтегляне  на данни .
 
recordType  указва  типа  запис  (SensorExternalGNSSCoupledRecord).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът  на SensorExternalGNSSCoupledRecord в 
байтове . 
noOfRecords  е броят  на записите  в набора  от записи . 
records  е набор  от Sensor External GNSS Coupled records.  
2.243.  VuSensorPairedRecordArray  
Поколение  2: 
Набор  от SensorPairedRecord плюс  метаданните , използвани  в 
протокола  за изтегляне  на данни .
 
recordType  указва  типа  запис  (SensorPairedRecord).  Присвояване  
на стойност : вж. RecordType.  
recordSize  е размерът  на SensorPairedRecord в байтове . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 182  
noOfRecords  е броят  на записите  в набора  от записи . 
records  е набор  от записи  за свързани  датчици . 
3. ОПРЕДЕЛЕНИЯ  НА ДИАПАЗОНИТЕ  ОТ СТОЙНОСТИ  И 
РАЗМЕРИ  
Определяне  на стойностите  на променливите , използвани  в опред­  
еленията  в параграф  2.
 
4. НАБОР  ОТ СИМВОЛИ  
Низовете  IA5 се състоят  от ASCII символи , както  е определено  в 
ISO/IЕС 8824-1. За по-голяма  четливост  и за да се улесни  указ­  
ването  на символите , определянето  на стойностите  се дава по- 
долу . В случай  на различие  прилагането  на ISO/IЕС 8824-1 има 
предимство  пред  настоящата  информация .
 
В други  низове  от символи  (Address, Name, VehicleRegistration ­
Number) се използват  освен  това символи  с десетични  кодове  в 
диапазона  161 — 255 от следните  8-битови  стандартни  набори  от 
символи , указани  от номера  на кодовата  страница : 
Стандартен  набор  от символи  Кодова  страница  
(десетична ) 
ISO/IEC 8859-1 латиница  1 — Западна  Европа  1  
ISO/IEC 8859-2 латиница  2 — Централна  Европа  2  
ISO/IEC 8859-3 латиница  3 — Южна  Европа  3  
ISO/IEC 8859-5 латиница /кирилица  5  
ISO/IEC 8859-7 латиница /гръцка  азбука  7  
ISO/IEC 8859-9 латиница  5/турска  азбука  9  
ISO/IEC 8859-13 латиница  7 — Балтийски  регион  13  
ISO/IEC 8859-15 латиница  9 15  
ISO/IEC 8859-16 латиница  10 — Югоизточна  Европа  16  
KOI8-R латиница /кирилица  80  
KOI8-U латиница /кирилица  85  
5. КОДИРАНЕ  
Ако се прилагат  правилата  за кодиране  ASN.1, всички  определени  
типове  данни  трябва  да се кодират  съгласно  приведения  в съот­  
ветствие  вариант  на стандарт  ISO/IЕС 8825-2.  
6. ИДЕНТИФИКАТОРИ  НА ОБЕКТИ  И ИДЕНТИФИКАТОРИ  НА 
ПРИЛОЖЕНИЯ  
6.1. Идентификатори  на обекти  
Идентификаторите  на обекти  (ИО), посочени  в тази глава , 
се прилагат  само  към поколение  2. Тези  ИО са определени  в ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 183  
TR-03110-3 и тук са повторени  само  за пълнота . Тези  ИО се 
съдържат  в поддървото  на bsi-de:
  
Идентификатори  за протокол  за удостоверяване  на бордово  
устройство
  
Пример : да предположим , че удостоверяването  на бордовото  
устройство  трябва  да се извърши  със SHA-384, тогава  идентифи­  
каторът  на обект , който  трябва  да се използва , е (в ASN.1)
  
. Стойността  
на този идентификатор  на обект  в точковата  нотация  е
 
. 
Точкова  нотация  Байтова  нотация
  
‘04 00 7F 00 07 02 02 02 02 03’
  
‘04 00 7F 00 07 02 02 02 02 04’
  
‘04 00 7F 00 07 02 02 02 02 05’  
Идентификатори  за протокол  за удостоверяване  на чип
 
Пример : да предположим , че удостоверяването  на чипа  трябва  да се 
извърши  чрез използване  на алгоритъм  ECDH, водещо  до дължина  
на ключа  на сесията  AES от 128 бита . Впоследствие  този ключ  на 
сесия  ще се използва  в работния  режим  CBC, за да се осигури  
поверителността  на данните , а с алгоритъма  CMAC — автентич­  
ността  на данните . Следователно  идентификаторът  на обект , 
който  трябва  да се използва , е (в ASN.1)
  
. Стойността  
на този идентификатор  на обект  в точковата  нотация  е
 
. 
Точкова  нотация  Байтова  нотация
  
‘04 00 7F 00 07 02 02 03 02 02’
  
‘04 00 7F 00 07 02 02 03 02 03’
  
‘04 00 7F 00 07 02 02 03 02 04’  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 184  
6.2. Идентификатори  на приложения  
Поколение  2: 
Идентификаторът  на приложение  (ИП) за външното  устройство  за 
GNSS (поколение  2) е даден  от ‘FF 44 54 45 47 4D’. Това  е ИП, 
който  е обект  на права  на собственост , съгласно  ISO/IEC 7816-4.  
Забележка : последните  пет байта  кодират  DTEGM за интелигентно  
тахографско  външно  устройство  за GNSS.  
Идентификаторът  на приложение  на тахографска  карта  от 
поколение  2 е даден  от ‘FF 53 4D 52 44 54’. Това  е ИП, който  е 
обект  на права  на собственост , съгласно  ISO/IEC 7816-4.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 185  
Допълнение  2 
СПЕЦИФИКАЦИЯ  НА ТАХОГРАФСКИТЕ  КАРТИ  
СЪДЪРЖАНИЕ  
1. ВЪВЕДЕНИЕ  
1.1. Съкращения  
1.2. Позовавания  
2. ЕЛЕКТРИЧЕСКИ  И ФИЗИЧЕСКИ  ХАРАКТЕРИСТИКИ  
2.1. Захранващо  напрежение  и потребление  на електрически  ток 
2.2. Напрежение  при програмиране  V pp 
2.3. Генериране  на тактове  и тактова  честота  
2.4. Входно /изходен  (I/O) контакт  
2.5. Състояния  на картата  
3. ХАРДУЕР  И ОБМЕН  НА ДАННИ  
3.1. Въведение  
3.2. Протокол  за предаване  на данни  
3.2.1 Протоколи  
3.2.2 ATR  
3.2.3 PTS  
3.3. Правила  за достъп  
3.4. Общ  преглед  на командите  и кодовете  за грешка  
3.5. Описание  на командите  
3.5.1 SELECT  
3.5.2 READ BINARY  
3.5.3 UPDATE BINARY  
3.5.4 GET CHALLENGE  
3.5.5 VERIFY  
3.5.6 GET RESPONSE  
3.5.7 PSO: VERIFY CERTIFICATE  
3.5.8 INTERNAL AUTHENTICATE  
3.5.9 EXTERNAL AUTHENTICATE  
3.5.10 GENERAL AUTHENTICATE  
3.5.11 MANAGE SECURITY ENVIRONMENT  
3.5.12 PSO: HASH  
3.5.13 PERFORM HASH of FILE  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 186  
3.5.14 PSO: COMPUTE DIGITAL SIGNATURE  
3.5.15 PSO: VERIFY DIGITAL SIGNATURE  
3.5.16 PROCESS DSRC MESSAGE  
4. СТРУКТУРА  НА ТАХОГРАФСКИТЕ  КАРТИ  
4.1. Главен  файл  (MF)  
4.2. Приложения  за картата  на водач  
4.2.1 Приложение  от поколение  1 за картата  на водач  
4.2.2 Приложение  от поколение  2 за картата  на водача  
4.3. Приложения  за картата  за монтаж  и настройки  
4.3.1 Приложение  от поколение  1 за картата  за монтаж  и настройки  
4.3.2 Приложение  от поколение  2 за картата  за монтаж  и настройки  
4.4. Приложения  за контролната  карта  
4.4.1 Приложение  от поколение  1 за контролната  карта  
4.4.2 Приложение  от поколение  2 за контролната  карта  
4.5. Приложения  за картата  на превозвач  
4.5.1 Приложение  от поколение  1 за картата  на превозвач  
4.5.2 Приложение  от поколение  2 за картата  на превозвач  
1. ВЪВЕДЕНИЕ  
1.1. Съкращения  
За целите  на настоящото  допълнение  се използват  следните  
съкращения . 
AC Access conditions ( условия  за достъп ) 
AES Advanced Encryption Standard („ Усъвършенстван  
стандарт  за криптиране “) 
AID Application Identifier („ Идентификатор  на приложе­  
нието “) 
ALW Always („ Винаги “) 
APDU Application Protocol Data Unit (structure of a command) 
(„Единица  данни  по приложния  протокол “ — 
структура  на команда ) 
ATR Answer To Reset („ Отговор  на инициализиране “) 
AUT Authenticated („ Удостоверен  за автентичност “) 
C6, C7 Contacts No 6 and 7 of the card as described in ISO/IEC 
7816-2 („Контакти  номера  6 и 7 на картата  са описани  
съгласно  стандарт  ISO/IEC 7816-2“)  
cc clock cycles ( тактови  цикли ) 
▼M1 
CHA Certificate Holder Authorisation ( разрешение  за 
титуляря  на сертификата ) 
▼B 
CHV Card Holder Verification information ( информация  за 
проверка  самоличността  на титуляря  на картата ) 
CLA Class byte of an APDU command ( байт  за определяне  
на класа  на APDU команда ) 
▼M1 
DO Data Object ( обект  от данни ) 
▼B 
DSRC Dedicated Short Range Communication ( специализирана  
връзка  или специализирана  съобщителна  система  с 
малък  обсег  на действие ) 
DF Dedicated File („ Специализиран  файл “) Един  DF може  
да съдържа  други  файлове  (елементарни  (EF) или 
специализирани ) 
ECC Elliptic Curve Cryptography („ Криптография  по 
елиптична  крива “) 
EF Elementary File („ Елементарен  файл “) 
etu elementary time unit („ елементарна  времева  единица “) ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 187  
G1 Generation 1 („ Поколение  1“) 
G2 Generation 2 („ Поколение  2“) 
IC Integrated Circuit („ Вграден  чип“) 
ICC Integrated Circuit Card („ Карта  с вграден  чип“) 
ID Identifier ( идентификатор ) 
IFD Interface Device ( интерфейсно  устройство ) 
IFS Information Field Size („ Дължина  на зоната  за инфор­  
мация “) 
IFSC Information Field Size for the card („ Дължина  на зоната  
за информация , запазена  за картата “) 
IFSD Information Field Size Device (for the Terminal) 
(„Дължина  на зоната  за информация , запазена  за 
крайното  устройство “) 
INS Instruction byte of an APDU command („ Байт  за 
инструкция  на APDU команда “) 
Lc Length of the input data for a APDU command ( дължина  
на входните  данни  за APDU команда ) 
Le Length of the expected data (output data for a command) 
(дължина  на очакваните  данни  (изходни  данни , 
отнасящи  се до определена  команда ) 
MF Master File (root DF) („ Главен  файл “ (специализиран  
файл , намиращ  се в кореновата  директория ) 
NAD Node Address used in T = 1 protocol ( възлов  адрес , 
използван  в протокол  Т = 1)  
NEV Never („ Никога “) 
P1-P2 Parameter bytes ( байтове  за параметри ) 
PIN Personal Identification Number („ Персонален  идентифи­  
кационен  номер “) 
PRO SM Protected with secure messaging („ Предпазен  
посредством  защитен  обмен  на съобщения “) 
PTS Protocol Transmission Selection („ Избор  на протокола  
за предаване  на данни “) 
RFU Reserved for Future Use („ Запазено  за бъдеща  упот­  
реба “) 
RST Reset (of the card) („ Инициализиране “ (на картата ) 
SFID Short EF Identifier („ Кратък  идентификатор  на 
елементарен  файл “) 
SM Secure Messaging ( защитен  обмен  на съобщения ) 
SW1-SW2 Status bytes ( байтове  за състоянието ) 
TS Initial ATR character ( начален  символ  на отговор  на 
инициализиране ) 
VPP Programming Voltage ( напрежение  при програмиране ) 
VU Vehicle Unit („ Бордово  устройство “) 
XXh Стойност  XX в шестнадесетична  бройна  система  
‘XXh’ Стойност  XX в шестнадесетична  бройна  система  
|| Символ  за конкатенация  03||04=0304  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 188  
1.2. Позовавания  
В настоящото  допълнение  се използват  позовавания  на следните  
стандарти : 
ISO/IEC 7816-2 Идентификационни  карти . Карти  с интегрални  
схеми . Част  2: Размери  и разположение  на 
контактите . ISO/IEC 7816-2:2007.  
ISO/IEC 7816-3 Идентификационни  карти . Карти  с интег­  
рална (и) схема (и) с контакти . Част  3: Елек­  
тронни  сигнали  и протоколи  за предаване . 
ISO/IEC 7816-3:2006.  
ISO/IEC 7816-4 Идентификационни  карти . Карти  с интег­  
рална (и) схема (и) с контакти . Част  4: Органи­  
зация , сигурност  и команди  за обмен . ISO/IEC 
7816-4:2013 + Cor 1: 2014.  
ISO/IEC 7816-6 Идентификационни  карти . Карти  с интегрални  
схеми . Част  6: Вътрешно -отраслови  елементи  
от данни  за взаимен  обмен . ISO/IEC 7816- 
6:2004 + Cor 1: 2006.  
ISO/IEC 7816-8 Идентификационни  карти . Карти  с интегрални  
схеми . Част  8: Команди  за операции  по сигур­  
ността . ISO/IEC 7816-8:2004.  
ISO/IEC 9797-2 Информационни  технологии . Техники  за 
сигурност . Кодове  за удостоверяване  на съоб­  
щението  (MACs). Част  2: Механизми , 
използващи  специализирана  хеш-функция . 
ISO/IEC 9797-2:2011  
2. ЕЛЕКТРИЧЕСКИ  И ФИЗИЧЕСКИ  ХАРАКТЕРИСТИКИ  
TCS_01 Всички  електронни  сигнали  трябва  да са в съответствие  
със стандарта  ISO/IEC 7816-3, освен  ако е указано  
друго . 
TCS_02 Местоположението  и размерите  на контактите  на 
картата  трябва  да са в съответствие  със стандарта  
ISO/IEC 7816-2.  
2.1. Захранващо  напрежение  и потребление  на електрически  ток 
TCS_03 Картата  трябва  да функционира  съгласно  специфи­  
кациите  с потребление  в границите , определени  в 
стандарта  ISO/IEC 7816-3.  
TCS_04 Картата  функционира  със захранващо  напрежение  Vcc 
= 3 V (+/– 0,3 V) или Vcc = 5 V (+/– 0,5 V).  
Изборът  на напрежението  се извършва  съгласно  
ISO/IEC 7816-3.  
2.2. Напрежение  при програмиране  V pp 
TCS_05 За картата  не се изисква  върху  краче  C6 да се прилага  
напрежение  при програмиране . Предвижда  се крачето  
C6 да не е свързано  в интерфейсно  устройство  (IFD). 
Контакт  C6 може  да бъде  свързан  към V cc в картата , но 
не трябва  да се свързва  на маса . Това  напрежение  не 
подлежи  на никакво  интерпретиране . 
2.3. Генериране  на тактове  и тактова  честота  
TCS_06 Картата  трябва  да функционира  в честотния  обхват  
1—5 MHz и може  да поддържа  по-високи  честоти . По 
време  на една  и съща  сесия  тактовата  честота  може  да 
варира  в рамките  на ± 2 %. Тактовата  честота  се 
генерира  от бордовото  устройство , а не от самата  
карта . Коефициентът  на запълване  може  да варира  
между  40 и 60 %.  
TCS_07 Възможно  е спирането  на външния  тактов  генератор  
при условията , записани  във файла  EF ICC на 
картата . Чрез  първия  байт  от тялото  на файла  EF ICC 
се програмират  условията  за режима  Clockstop:  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 189  
Долно  
равнище  (L) Горно  
равнище  (H) 
Бит 3 Бит 2 Бит 1 
0 0  1  Clockstop е разрешен , няма  предпочитано  
равнище  
0 1  1  Clockstop е разрешен , с предпочитание  към 
горното  равнище  
1 0  1  Clockstop е разрешен , с предпочитание  към 
долното  равнище  
0 0  0  Clockstop не е разрешен  
0 1  0  Clockstop е разрешен  само  на горното  равнище  
1 0  0  Clockstop е разрешен  само  на долното  равнище  
Битове  4—8 не се използват . 
2.4. Входно /изходен  (I/O) контакт  
TCS_08 Входно /изходният  контакт  C7 се използва  за 
приемането  и предаването  на данни , идващи  от или 
предназначени  за интерфейсното  устройство  (IFD). По 
време  на работа  в режим  на предаване  е или картата , 
или интерфейсното  устройство , но не и двете  едновре­  
менно . Ако и двете  са в режим  на предаване , това не 
трябва  да причинява  повреждане  на картата . Когато  
картата  не предава  повече , тя преминава  в режим  на 
приемане . 
2.5. Състояния  на картата  
TCS_09 Картата  функционира  в две състояния , когато  е 
приложено  захранващото  напрежение : 
активно  състояние , докато  изпълнява  команди  или се 
свързва  с цифрово  устройство , 
пасивно  състояние  през останалото  време ; в това 
състояние  картата  трябва  да запазва  всички  запаметени  
данни . 
3. ХАРДУЕР  И ОБМЕН  НА ДАННИ  
3.1. Въведение  
В настоящия  параграф  се описват  минималните  функционални  
възможности , които  трябва  да притежават  тахографските  карти  
и бордовите  устройства  (VU), за да се гарантира  правилно  
функциониране  и оперативна  съвместимост . 
Тахографските  карти  трябва  също  така да са в съответствие  с 
действащите  стандарти  ISO/IEC ( и по-специално  ISO/IEC 7816) 
в максималната  възможна  степен . Въпреки  това се дава 
подробно  описание  на командите  и протоколите , за да се 
посочат  някои  ограничения  в използването  или евентуални  
различия . Описаните  команди  са в пълно  съответствие  с посо­  
чените  стандарти , освен  ако е указано  друго . 
3.2. Протокол  за предаване  на данни  
TCS_10 Протоколът  за предаване  на данни  трябва  да е в съот­  
ветствие  със стандарта  ISO/IEC 7816-3 за T = 0 и T = 1. 
По-специално  бордовото  устройство  трябва  да бъде  в 
състояние  да разпознава  удълженията  на времето  на 
изчакване , които  му изпраща  картата . 
3.2.1  Протоколи  
TCS_11 Картата  трябва  да може  да предоставя  и двата  
протокола  T=0 и T=1. Освен  това тя може  да 
поддържа  допълнителни  контактно -ориентирани  
протоколи . 
TCS_12  Т=0 е протоколът  по подразбиране ; така че е необ­  
ходима  команда  PTS  за преминаване  към протокола  
Т=1. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 190  
TCS_13 Устройствата  трябва  да могат  да използват  прякото  
условие  за връзка , което  съдържат  тези два протокола : 
следователно  прякото  условие  за връзка  е задължително  
за картата . 
TCS_14 Байтът  „Дължина  на зоната  за информация , запазена  
за картата “ (IFSC)  се представя  при ATR („Отговор  на 
инициализиране “) в символа  TA3. Тази  стойност  трябва  
да е най-малко  ‘F0h’ (= 240 байта ). 
Прилагат  се следните  ограничения  за протоколите : 
TCS_15  T=0  
— Интерфейсното  устройство  трябва  да може  да 
възприема  отговор  по I/O след  предния  фронт  на 
сигнала  относно  RST от 400 тактови  цикли  (cc).  
— Интерфейсното  устройство  трябва  да бъде  в 
състояние  да чете символите , разделени  с 12 etu.  
— Интерфейсното  устройство  трябва  да бъде  в 
състояние  да разпознава  грешен  символ  и неговото  
повторение , ако са разделени  с 13 etu. В случай  на 
откриване  на грешен  символ , сигналът  за грешка  
(Error) може  да се подаде  по I/O в интервал  от 1 
до 2 etu. Устройството  трябва  да бъде  в състояние  
да понася  закъснение  от 1 etu.  
— Интерфейсното  устройство  трябва  да бъде  в 
състояние  да приема  ATR от 33 байта  (TS+32).  
— Ако TC1 присъства  в ATR, трябва  да се предвиди  
допълнително  време  за изчакване  за символите , 
изпратени  от интерфейсното  устройство , въпреки  
че символите , изпратени  от картата , все още могат  
да бъдат  разделени  с 12 etu. Това  важи  и за символа  
ACK („Удостоверяване  на приемане “), изпратен  от 
картата  след  издаване  от интерфейсното  устройство  
на символ  P3. 
— Интерфейсното  устройство  отчита  символа  NUL, 
издаден  от картата . 
— Интерфейсното  устройство  трябва  да приема  
режима  на допълване  за удостоверяване  на 
приемането  на данни . 
— Командата  за получаване  на отговор  (get-response) 
не може  да се използва  в режим  на обединяване  
на данните  за получаване  на блокове  от данни , 
чиято  дължина  би могла  да надвиши  255 байта . 
TCS_16  T=1  
— Байт  NAD: не се използва  (за NAD се задава  „00“).  
— S-block ABORT: не се използва . 
— Грешка  в състоянието  на VPP, засягаща  S-block: не 
се използва . 
— Общата  дължина  на верижно  свързаните  данни  
(chaining length) в едно  поле  за данни  не трябва  да 
надвишава  255 байта  (за да се поддържа  от IFD).  
— Information Field Size Device (IFSD) се указва  от IFD 
непосредствено  след  ATR: IFD предава  заявката  за 
дължината  на зоната  за информация  (IFS) на S- 
Block след  ATR и картата  отговаря  с IFS на S- 
Block. Препоръчва  се стойността  на IFSD да е 254 
байта . 
— Картата  не подава  искане  за промяна  на IFS. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 191  
3.2.2  ATR  
TCS_17 Устройството  проверява  байтовете  на ATR съгласно  
стандарта  ISO/IEC 7816-3. Не се проверяват  символите , 
отбелязващи  историята  на ATR.  
Пример  за базов  двупротоколен  ATR съгласно  
стандарта  ISO/IEC 7816-3.  
Символ  Стойност  Забележки  
TS ‘3Bh’  Указва  пряко  условие  за връзка . 
T0 ‘85h’  TD1 наличен ; наличие  на 5 байта , отбелязващи  
историята . 
TD1 ‘80h’  TD2 наличен ; използва  се T=0  
TD2 ‘11h’  TA3 наличен ; използва  се T=1  
TA3 ‘XXh’ ( най-малко  
‘F0h’)  Дължина  на зоната  за информация , запазена  за 
картата  (IFSC)  
TH1 до TH5  ‘XXh’  Символи , използвани  за отбелязване  на историята  
TCK  ‘XXh’  Контролен  символ  (изключително  ИЛИ ) 
TCS_18 След  Answer To Reset (ATR) главният  файл  (MF) се 
избира  по подразбиране  и става  текуща  директория . 
3.2.3  PTS  
TCS_19 Протоколът  по подразбиране  е Т=0. За да се зададе  
протоколът  Т=1, устройството  изпраща  на картата  
команда  PTS (известна  и като PPS).  
TCS_20 Тъй като и двата  протокола  Т=0 и Т=1 са задължителни  
за картата , задължителна  е и базовата  команда  PTS за 
превключване  между  протоколите . 
PTS може  да се използва , както  е посочено  в ISO/IEC 
7816-3, за превключване  към по-висока  скорост  на 
предаване  на данни  отколкото  подразбиращата  се, пред­  
ложена  от картата  в ATR, ако има такава  (байт  TA(1).  
Използването  на по-висока  скорост  на предаване  на 
данни  не е задължително  за картата . 
TCS_21 Ако се поддържа  само  подразбиращата  се скорост  на 
предаване  на данни  (или ако избраната  скорост  на 
предаване  на данни  не се поддържа ), картата  отговаря  
на PTS правилно  съгласно  стандарта  ISO/IEC 7816-3, 
като изпуска  байта  PPS1.  
Следват  примери  за базова  команда  PTS за избор  на 
протокола : 
Символ  Стойност  Забележки  
PPSS  ‘FFh’  Символ  за иницииране  
PPS0  ‘00h’ или ‘01h’  От PPS1 до PPS3 не са налични ; ‘00h’ за избор  на T0, 
‘01h’ за избор  на T1. 
PK ‘XXh’  Контролен  символ : ‘XXh’ = ‘FFh’ ако PPS0 = ‘00h’, 
‘XXh’ = ‘FEh’ ако PPS0 = ‘01h’.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 192  
3.3. Правила  за достъп  
TCS_22 Правилата  за достъп  определят  за даден  режим  на 
достъп , т.е. команда , съответните  условия  за сигурност . 
Ако тези условия  за сигурност  са изпълнени , съот­  
ветната  команда  се изпълнява . 
TCS_23 За тахографската  карта  се използват  следните  условия  
за сигурност : 
Съкращение  Значение  
ALW  Действието  винаги  е изпълнимо  и може  да се изпълнява  без ограни­  
чения . APDU с команда  или с отговор  се изпраща  като открит  текст , 
т.е. без защитен  обмен  на съобщения . 
NEV  Действието  никога  не е изпълнимо . 
PLAIN-C  APDU с команда  се изпраща  като открит  текст , т.е. без защитен  обмен  на 
съобщения . 
PWD  Действието  може  да бъде  изпълнено  само  след  успешна  проверка  на PIN 
на картата  за монтаж  и настройки , т.е. ако е установено  вътрешното  
състояние  „PIN_Verified“ по отношение  на сигурността  на картата . 
Командата  трябва  да бъде  изпратена  без защитен  обмен  на съобщения . 
EXT-AUT-G1  Действието  може  да бъде  изпълнено  само  ако командата  External Authen ­
ticate за удостоверяване  от поколение  1 (виж също  допълнение  11, част 
А) е била  изпълнена  успешно . 
SM-MAC-G1  APDU ( с команда  или с отговор ) трябва  да се прилага  със защитен  обмен  
на съобщения  от поколение  1 в режим  само  с удостоверяване  (виж 
допълнение  11, част А). 
SM-C-MAC-G1  APDU с команда  трябва  да се прилага  със защитен  обмен  на съобщения  
от поколение  1 в режим  само  с удостоверяване  (виж допълнение  11, част 
А). 
SM-R-ENC-G1  APDU с отговор  трябва  да се прилага  със защитен  обмен  на съобщения  
от поколение  1 (виж допълнение  11, част А), т.е. не се връща  код за 
удостоверяване  автентичността  на съобщението . 
SM-R-ENC- 
MAC-G1  APDU с отговор  трябва  да се прилага  със защитен  обмен  на съобщения  
от поколение  1 в режим  „криптиране  и след  това удостоверяване  на 
автентичността “ (encrypt-then-authenticate) ( виж допълнение  11, част А). 
SM-MAC-G2  APDU ( с команда  или с отговор ) трябва  да се прилага  със защитен  обмен  
на съобщения  от поколение  2 в режим  само  с удостоверяване  (виж 
допълнение  11, част Б). 
SM-C-MAC-G2  APDU с команда  трябва  да се прилага  със защитен  обмен  на съобщения  
от поколение  2 в режим  само  с удостоверяване  (виж допълнение  11, част 
Б). 
SM-R-ENC- 
MAC-G2  APDU с отговор  трябва  да се прилага  със защитен  обмен  на съобщения  
от поколение  2 в режим  „криптиране  и след  това удостоверяване  на 
автентичността “ (виж допълнение  11, част Б). 
▼M1 
TCS_24 Тези  условия  за сигурност  могат  да бъдат  свързани  
помежду  си по следните  начини : 
AND: трябва  да бъдат  изпълнени  всички  условия  за 
сигурност  
OR: трябва  да бъде  изпълнено  поне  едно  от условията  
за сигурност . 
Правилата  за достъп  до файловата  система , т.е. 
командите  SELECT, READ BINARY и UPDATE 
BINARY, са определени  в глава  4. Правилата  за 
достъп  за останалите  команди  са определени  в 
таблиците  по-долу . Изразът  „не се прилага “ се 
използва , ако няма  изискване  да се поддържа  изпъл­  
нението  на командата . В този случай  командата  може  
да се поддържа  или може  да не се поддържа , но 
условието  за достъп  е извън  обхват . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 193  
TCS_25 В приложението  DF Tachograph G1 се използват  
следните  правила  за достъп : 
▼M1 
Команда  Карта  на водач  Карта  за 
монтаж  и наст­  
ройки  Контролна  
карта  Карта  на 
превозвач  
External Authenticate  
— За удостоверяване  от 
поколение  1 ALW  ALW  ALW  ALW  
— За удостоверяване  от 
поколение  2 ALW  PWD  ALW  ALW  
Internal Authenticate  ALW  PWD  ALW  ALW  
General Authenticate  ALW  ALW  ALW  ALW  
Get Challenge  ALW  ALW  ALW  ALW  
MSE:SET AT  ALW  ALW  ALW  ALW  
MSE:SET DST  ALW  ALW  ALW  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  ALW  ALW  ALW  
PSO: Verify Digital Signature  Не се 
прилага  Не се 
прилага  ALW  Не се 
прилага  
Verify  Не се 
прилага  ALW  Не се 
прилага  Не се 
прилага  
▼B 
TCS_26 В приложението  DF Tachograph_G2 се използват  
следните  правила  за достъп : 
▼M1 
Команда  Карта  на водач  Карта  за монтаж  
и настройки  Контролна  карта  Карта  на 
превозвач  
External Authenticate  
— За удостоверяване  
от поколение  1 Не се прилага  Не се прилага  Не се прилага  Не се прилага  
— За удостоверяване  
от поколение  2 ALW  PWD  ALW  ALW  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 194  
Команда  Карта  на водач  Карта  за монтаж  
и настройки  Контролна  карта  Карта  на 
превозвач  
Internal Authenticate  Не се прилага  Не се прилага  Не се прилага  Не се прилага  
General Authenticate  ALW  ALW  ALW  ALW  
Get Challenge  ALW  ALW  ALW  ALW  
MSE:SET AT  ALW  ALW  ALW  ALW  
MSE:SET DST  ALW  ALW  ALW  ALW  
Process DSRC Message  Не се прилага  ALW  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  ALW  ALW  ALW  
PSO: Verify Digital 
Signature  Не се прилага  Не се прилага  ALW  Не се прилага  
Verify  Не се прилага  ALW  Не се прилага  Не се прилага  
▼B 
TCS_27 В главния  файл  (MF) се използват  следните  правила  за 
достъп : 
▼M1 
Команда  Карта  на водач  Карта  за монтаж  
и настройки  Контролна  карта  Карта  на 
превозвач  
External Authenticate  
— За удостоверяване  
от поколение  1 Не се прилага  Не се прилага  Не се прилага  Не се прилага  
— За удостоверяване  
от поколение  2 ALW  PWD  ALW  ALW  
Internal Authenticate  Не се прилага  Не се прилага  Не се прилага  Не се прилага  
General Authenticate  ALW  ALW  ALW  ALW  
Get Challenge  ALW  ALW  ALW  ALW  
MSE:SET AT  ALW  ALW  ALW  ALW  
MSE:SET DST  ALW  ALW  ALW  ALW  ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 195  
Команда  Карта  на водач  Карта  за монтаж  
и настройки  Контролна  карта  Карта  на 
превозвач  
Process DSRC Message  Не се прилага  Не се прилага  Не се прилага  Не се прилага  
PSO: Compute Digital 
Signature  Не се прилага  Не се прилага  Не се прилага  Не се прилага  
PSO: Hash  Не се прилага  Не се прилага  Не се прилага  Не се прилага  
PERFORM HASH of 
FILE  Не се прилага  Не се прилага  Не се прилага  Не се прилага  
PSO: Verify Certificate  ALW  ALW  ALW  ALW  
PSO: Verify Digital 
Signature  Не се прилага  Не се прилага  Не се прилага  Не се прилага  
Verify  Не се прилага  ALW  Не се прилага  Не се прилага  
▼B 
TCS_28 Тахографската  карта  може  да възприема  или да не 
възприема  команда  с по-високо  равнище  на сигурност  
от указаното  в условията  за сигурност . Т.е. ако 
условието  за сигурност  е ALW (или PLAIN-C) картата  
може  да възприема  команда  със защитен  обмен  на 
съобщения  (режим  криптиране  и/или удостоверяване  
на автентичността ). Ако условието  за сигурност  
изисква  защитен  обмен  на съобщения  с режим  на удос­  
товеряване  на автентичността , тахографската  карта  
може  да възприема  команда  със защитен  обмен  на 
съобщения  от същото  поколение  в режим  на удостове­  
ряване  на автентичността  и криптиране . 
Забележка : описанията  на командите  предоставят  
повече  информация  относно  поддръжката  на 
командите  за различните  видове  тахографски  карти  и 
различните  специализирани  файлове  (DF).  
3.4. Общ  преглед  на командите  и кодовете  за грешка  
Командите  и структурата  на файловете  са изведени  от стандарта  
ISO/IEC 7816-4 и са в съответствие  с него . 
В настоящия  раздел  са описани  следните  двойки  APDU коман­  
да—отговор . Поддържаните  от приложения  от поколение  1 и 2 
варианти  на команди  са указани  в описанията  на съответните  
команди . 
Команда  INS  
SELECT  ‘A4h’  
READ BINARY  ‘B0h’, ‘B1h’  
UPDATE BINARY  ‘D6h’, ‘D7h’  
GET CHALLENGE  ‘84h’  
VERIFY  ‘20h’  
GET RESPONSE  ‘C0h’  ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 196  
Команда  INS  
PERFORM SECURITY 
OPERATION  ‘2Ah’  
— VERIFY CERTIFICATE  
— COMPUTE DIGITAL 
SIGNATURE  
— VERIFY DIGITAL 
SIGNATURE  
— HASH  
— PERFORM HASH OF FILE  
— PROCESS DSRC MESSAGE  
INTERNAL AUTHENTICATE  ‘88h’  
EXTERNAL AUTHENTICATE  ‘82h’  
MANAGE SECURITY ENVI ­
RONMENT  ‘22h’  
— SET DIGITAL SIGNATURE 
TEMPLATE  
— SET AUTHENTICATION 
TEMPLATE  
GENERAL AUTHENTICATE  ‘86h’  
▼M1 
TCS_29 Байтовете  за състояние  SW1 и SW2 се връщат  във 
всяко  съобщение , съдържащо  отговор , и обозначават  
състоянието  на изпълнение  на съответната  команда . 
SW1  SW2  Значение  
90 00  Нормална  обработка  
61 XX  Нормална  обработка . ХХ = брой  на наличните  байтове  на 
отговора  
62 81  Предупреждение  за обработката . Възможно  е част от 
върнатите  данни  да са увредени  
63 00  Удостоверяването  е неуспешно  (предупреждение ) 
63 CX  Грешка  при CHV (PIN). Брояч  на оставащите  опити , 
осигуряван  от ‘X’ 
64 00  Грешка  при изпълнението  — непроменено  състояние  на 
енергонезависимата  памет . Грешка  в целостта  на данните  
65 00  Грешка  при изпълнението  — променено  състояние  на енер­  
гонезависимата  памет  
65 81  Грешка  при изпълнението  — променено  състояние  на енер­  
гонезависимата  памет . Неизправност  на паметта  
66 88  Грешка  по сигурността : грешна  криптографска  контролна  
сума  (по време  на защитен  обмен  
на съобщения ) или 
грешен  сертификат  (по време  на 
проверката  на сертификата ) или 
грешна  криптограма  (по време  на 
външното  удостоверяване ) или 
грешен  цифров  подпис  (по време  
на проверката  на подписа ) ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 197  
SW1  SW2  Значение  
67 00  Грешна  дължина  (грешна  Lc или Le) 
68 83  Очаква  се последната  команда  от веригата  
69 00  Забранена  команда  (няма  възможност  за отговор  при Т=0) 
69 82  Незадоволително  състояние  по отношение  на сигурността  
69 83  Блокиран  метод  за удостоверяване  
69 85  Неизпълнени  условия  за използване  
69 86  Неразрешена  команда  (няма  активен  елементарен  файл ) 
69 87  Липса  на очакваните  обекти  от данни  при защитения  обмен  
на съобщения  
69 88  Неправилни  обекти  от данни  при защитения  обмен  на съоб­  
щения  
6A 80  Неправилни  параметри  в поле  за данни  
6A 82  Неоткриваем  файл  
6A 86  Грешни  параметри  P1-P2  
6A 88  Неоткриваеми  указани  данни  
6B 00  Грешни  параметри  (поправка  извън  елементарния  файл ) 
6C XX  Грешна  дължина , SW2 указва  точната  дължина . Не се връща  
като отговор  поле  за данни  
6D 00  Несъвместим  или неправилен  код на команда  
6E 00  Несъвместим  клас 
6F 00  — Други  грешки  при проверката  
Може  да бъдат  върнати  други  байтове  за състояние , 
определени  в стандарт  ISO/IEC 7816-4, ако поведението  
им не е изрично  упоменато  в настоящото  допълнение . 
Например  по избор  може  да бъдат  върнати  следните  
байтове  за състояние : 
6881: Несъвместим  логически  канал  
6882: Не се поддържа  защитен  обмен  на съобщения  
▼B 
TCS_30 Ако в една  APDU с команда  е изпълнено  повече  от 
едно  условие  за грешка , картата  може  да върне  който  
и да е от съответните  байтове  за състояние . 
3.5. Описание  на командите  
В настоящата  глава  са описани  задължителните  команди  за тахог­  
рафските  карти . 
Още  важни  подробности  относно  използваните  криптографски  
операции  се дават  в допълнение  11 „Общи  механизми  за 
сигурност  за тахографи  от поколение  1 и поколение  2“. 
Всички  команди  са описани  независимо  от използвания  протокол  
(T=0 или T=1). Винаги  са посочени  байтовете  CLA, INS, P1, P2, 
Lc и Le на APDU. Ако за описаната  команда  не е необходим  байт  
Lc или Le, за него  не се дават  дължина , стойност  и описание . ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 198  
TCS_31 Ако се изисква  наличието  и на двата  байта  за дължина  
(Lc и Le), описаната  команда  трябва  да бъде  разделена  
на две части , ако IFD използва  протокола  Т=0: IFD 
изпраща  командата , както  е описано , с P3=Lc + 
данни , след  което  изпраща  команда  GET RESPONSE 
(виж точка  3.5.6) с P3=Le.  
TCS_32 Ако се изисква  наличието  и на двата  байта  за дължина  
и ако Le=0 (защитен  обмен  на съобщения ): 
— когато  се използва  протоколът  T=1, картата  
отговаря  на Le=0, като изпраща  всички  налични  
изходни  данни . 
— Когато  се използва  протоколът  T=0, IFD изпраща  
първата  команда  с P3=Lc + данни , а картата  
отговаря  (на подразбиращия  се Le=0) с байтовете  
за състояние  ‘61La ’, където  La е броят  на 
наличните  байтове  на отговора . След  това IFD 
издава  команда  GET RESPONSE с P3 = La за 
четене , т.е. извличане  на данните . 
TCS_33 Тахографската  карта  може  да поддържа  полета  с 
увеличена  дължина  съгласно  стандарт  ISO/IEC 7816-4, 
без това да е задължително . Тахографската  карта , която  
поддържа  полета  с увеличена  дължина , трябва : 
— да указва  в ATR, че поддържа  полета  с увеличена  
дължина ; 
— предоставя  поддържаните  буферни  размери  
посредством  информация  за увеличената  дължина  
в EF ATR/INFO, виж TCS_146;  
— да указва  дали  поддържа  полета  с увеличена  
дължина  за T = 1 и/или T = 0 в EF Extended 
Length, виж TCS_147;  
— да поддържа  полета  с увеличена  дължина  за тахог­  
рафските  приложения  от поколения  1 и 2. 
Забележки : 
Всички  команди  са определени  за полета  с малка  
дължина . Използването  на APDU с увеличена  
дължина  се определя  от стандарта  ISO/IEC 7816-4.  
По принцип  командите  са определени  за открития  
режим , т.е. без защитен  обмен  на съобщения , тъй 
като слоят  за защитен  обмен  на съобщения  е 
определен  в допълнение  11. От отнасящите  се за 
дадена  команда  правила  за достъп  става  ясно  дали  
командата  трябва  или не трябва  да поддържа  защитен  
обмен  на съобщения  и дали  командата  трябва  да 
поддържа  защитен  обмен  на съобщения  от поколение  
1 и/или от поколение  2. За някои  команди  са описани  
варианти  със защитен  обмен  на съобщения , за да се 
онагледи  използването  на такъв  обмен . 
TCS_34 Бордовото  устройство  (VU) изпълнява  цялостния  
протокол  от поколение  2 за взаимно  удостоверяване  
на автентичността  между  него  и картата  за дадена  
сесия , включително  проверката  на сертификата  (ако се 
изисква ), или в специализирания  файл  (DF) Tachograph, 
или Tachograph_G2, или в главния  файл  (MF).  
3.5.1  SELECT  
Тази  команда  е в съответствие  със стандарта  ISO/IEC 7816-4, но е 
с по-ограничена  употреба  в сравнение  с аналогичната  команда , 
описана  в този стандарт . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 199  
Командата  SELECT се използва  за: 
— селектиране  на специализиран  файл  на приложение  (селекти­  
рането  трябва  да е по име); 
— селектиране  на елементарен  файл , съответстващ  на идентифи­  
катора  на представения  файл . 
3.5.1.1 С е л е к т и р а н е п о и м е ( A I D )  
Тази  команда  позволява  селектирането  на специализиран  файл  на 
приложение , записан  на картата . 
TCS_35 Тази  команда  е изпълнима  от всяка  точка  във 
файловата  структура  (след  ATR или във всеки  един  
момент ). 
TCS_36 Селектирането  на определено  приложение  инициа­  
лизира  текущата  среда  за защита  от неоторизиран  
достъп . След  селектирането  на приложението  не се 
селектира  повече  никакъв  активен  публичен  ключ . 
Условието  за достъп  EXT-AUT-G1 също  така се деак­  
тивира . Ако командата  е изпълнена  без защитен  обмен  
на съобщения , ключовете  от предишната  сесия  със 
защитен  обмен  на съобщения  не са повече  на разполо­  
жение . 
TCS_37  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  
INS 1  ‘A4h’  
P1 1  ‘04h’  Селектиране  по име (AID)  
P2 1  ‘0Ch’  Не се очаква  отговор  
Lc 1  ‘NNh’  Брой  байтове , изпратени  на картата  (дължина  на 
AID): 
‘06h’ за тахографското  приложение  
#6-#(5+NN)  NN  ‘XX..XXh’  AID: ‘FF 54 41 43 48 4F’ за тахографското  
приложение  от поколение  1 
AID: ‘FF 53 4D 52 44 54’ за тахографското  
приложение  от поколение  2 
Не е нужно  да се отговаря  на командата  SELECT (Le 
липсва  при T=1 или не се изисква  отговор  при T=0).  
TCS_38  Ответно  съобщение  (не се изисква  отговор ) 
Байт  Дължи­  
на Стойност  Описание  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— Ако приложението , съответстващо  на AID, е 
неоткриваемо , за състоянието  на обработката  се 
връща  ‘6A82 ’. 
— При T=1 за състоянието  се връща  ‘6700 ’, ако е 
наличен  байтът  Le. 
— При Т=0 за състоянието  се връща  ‘6900 ’, ако се 
изисква  отговор  след  командата  SELECT.  
▼M1 
— Ако избраното  приложение  се смята  за повредено  
(открита  е грешка  в целостта  на атрибутите  на 
файла ), за състоянието  на обработката  се връща  
‘6400 ’ или ‘6500 ’. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 200  
3.5.1.2 С е л е к т и р а н е н а е л е м е н т а р е н ф а й л ч р е з н е г о в и я 
ф а й л о в и д е н т и ф и к а т о р 
TCS_39  Командно  съобщение  
TCS_40 При този вариант  на командата  тахографската  карта  
поддържа  защитения  обмен  на съобщения  от 
поколение  2, както  е определено  в допълнение  11, 
част Б. 
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  
INS 1  ‘A4h’  
P1 1  ‘02h’  Селектиране  на елементарен  файл , който  зависи  от 
активния  специализиран  файл  
P2 1  ‘0Ch’  Не се очаква  отговор  
Lc 1  ‘02h’  Брой  байтове , изпратени  на картата  
#6-#7  2  ‘XXXXh’  Файлов  идентификатор  
Не е нужно  да се отговаря  на командата  SELECT (Le 
липсва  при T=1 или не се изисква  отговор  при T=0).  
TCS_41  Ответно  съобщение  (не се изисква  отговор ) 
Байт  Дължи­  
на Стойност  Описание  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— Ако файлът , съответстващ  на файловия  идентифи­  
катор , е неоткриваем , за състоянието  на обработката  
се връща  ‘6A82 ’. 
— При T=1 за състоянието  се връща  ‘6700 ’, ако е 
наличен  байтът  Le. 
— При Т=0 за състоянието  се връща  ‘6900 ’, ако се 
изисква  отговор  след  командата  SELECT.  
▼M1 
— Ако избраният  файл  се смята  за повреден  (открита  е 
грешка  в целостта  на атрибутите  на файла ), за 
състоянието  на обработката  се връща  ‘6400 ’ или 
‘6500 ’. 
▼B 
3.5.2  READ BINARY  
Тази  команда  е в съответствие  със стандарта  ISO/IEC 7816-4, но е 
с по-ограничена  употреба  в сравнение  с аналогичната  команда , 
описана  в този стандарт . 
Командата  READ BINARY се използва  за четене , т.е. извличане  
на данните  от файл  с прозрачна  структура . 
Отговорът  на картата  се състои  във връщането  на извлечените  
данни , като те се капсулират  при необходимост  в структура  за 
защитен  обмен  на съобщения . 
3.5.2.1 К о м а н д а с и з м е с т в а н е ( o f f s e t ) в P 1 - P 2  
Тази  команда  позволява  на IFD да извлича  данни  от селектирания  
елементарен  файл , без да използва  защитен  обмен  на съобщения . 
Забележка : Тази  команда  може  да се използва  без защитен  обмен  
на съобщения  само  за извличане  на данни  от файл , който  
поддържа  условието  за сигурност  ALW за режима  на достъп  за 
извличане  на данни . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 201  
TCS_42  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  
INS 1  ‘B0h’  Read Binary  
P1 1  ‘XXh’  Изместване  в байтове , считано  от началото  на файла : 
най-старшият  байт  
P2 1  ‘XXh’  Изместване  в байтове , считано  от началото  на файла : 
най-младшият  байт  
Le 1  ‘XXh’  Дължина  на очакваните  данни . Брой  на байтовете , 
които  трябва  да се извлекат  
Забележка : бит 8 на байт  P1 трябва  да бъде  равен  на 
нула . 
TCS_43  Ответно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
#1-#X  X  ‘XX..XXh’  Извлечени  данни  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— Ако не е селектиран  елементарен  файл  (EF), за 
състоянието  на обработката  се връща  ‘6986 ’. 
— Ако условията  за сигурност  за селектирания  файл  
не са изпълнени , изпълнението  на командата  се 
прекъсва  с ‘6982 ’. 
— Ако изместването  не е съвместимо  с размера  на EF 
(изместването  > размера  на EF), за състоянието  на 
обработката  се връща  ‘6B00 ’: 
— Ако обемът  на подлежащите  на извличане  данни  не 
е съвместим  с размера  на EF (изместването  + Le > 
размера  на EF), за състоянието  на обработката  се 
връща  ‘6700 ’ или ‘6Cxx ’, където  ‘xx’ указва  
точната  дължина . 
▼M1 
— Ако е открита  грешка  в целостта  на атрибутите  на 
файла , картата  счита  файла  за повреден  и невъзста­  
новим , а за състоянието  на обработката  се връща  
‘6400 ’ или ‘6500 ’. 
▼B 
— Ако е открита  грешка  в цялостността  на записаните  
данни , картата  връща  поисканите  данни , а за 
състоянието  на обработката  се връща  ‘6281 ’. 
3.5.2.1.1 К о м а н д а с ъ с з а щ и т е н о б м е н н а с ъ о б щ е н и я 
( п р и м е р и ) 
Тази  команда  позволява  на IFD да извлече  данни  от селектирания  
елементарен  файл , като използва  защитен  обмен  на съобщения , за 
да провери  цялостността  на получените  данни  и да защити  
тяхната  поверителност , ако се прилага  условието  за сигурност  
SM-R-ENC-MAC-G1 ( поколение  1) или SM-R-ENC-MAC-G2 
(поколение  2). 
TCS_44  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘0Ch’  Изисква  се защитен  обмен  на съобщения  
INS 1  ‘B0h’  Read Binary  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 202  
Байт  Дължи­  
на Стойност  Описание  
P1 1  ‘XXh’  P1 ( изместване  в байтове , считано  от началото  на 
файла ): най-старшият  байт  
P2 1  ‘XXh’  P2 ( изместване  в байтове , считано  от началото  на 
файла ): най-младшият  байт  
Lc 1  ‘XXh’  Дължина  на входящите  данни  за защитения  обмен  на 
съобщения  
#6 1  ‘97h’  T  LE : таг за спецификацията  на очакваната  дължина  
#7 1  ‘01h’  L  LE : Очаквана  дължина  
#8 1  ‘NNh’  Спецификация  на очакваната  дължина  (първоначална  
Le): брой  на байтовете , които  трябва  да се извлекат . 
#9 1  ‘8Eh’  T  CC : таг за криптографската  контролна  сума  
#10 1  ‘XXh’  L  CC : дължина  на следната  криптографска  контролна  
сума  
‘04h’ за защитения  обмен  на съобщения  от поколение  
1 (виж допълнение  11, част А) 
‘08h’, ‘0Ch’ или ‘10h’ в зависимост  от дължината  на 
ключа  по AES за защитен  обмен  на съобщения  от 
поколение  2 (виж допълнение  11, част Б) 
#11-#(10+L)  L  ‘XX..XXh’  Криптографска  контролна  сума  
Le 1  ‘00h’  Съгласно  стандарта  ISO/IEC 7816-4  
TCS_45  Ответно  съобщение , ако не се изисква  SM-R-ENC- 
MAC-G1 ( поколение  1) / SM-R-ENC-MAC-G2 
(поколение  2) и ако форматът  на входящите  данни  
за защитения  обмен  на съобщения  е правилен : 
▼M1 
Байт  Дълж­  
ина Стойност  Описание  
#1 1  ‘81h’  T  PV : таг за простата  стойност  на данните  
#2 L  ‘NNh’ или 
‘81 NNh’  L PV : дължина  на върнатите  данни  
(= първоначална  Le). 
L е 2 байта , ако L PV >127 байта  
#(2+L) - #(1+L+NN)  NN  ‘XX..XXh’  Проста  стойност  на данните  
#(2+L+NN)  1  ‘99h’  Таг за състоянието  на обработката  (SW1- 
SW2) — по избор  за защитен  обмен  на 
съобщения  от поколение  1 
#(3+L+NN)  1  ‘02h’  Дължина  на стойността  за състоянието  на 
обработката  — по избор  за защитен  
обмен  на съобщения  от поколение  1 
#(4+L+NN) - #(5+L+NN)  2  ‘XX XXh’  Състояние  на обработката  на незащи­  
тената  ответна  APDU, т.е. с отговора  — 
незадължително  при защитен  обмен  на 
съобщения  от поколение  1 
#(6+L+NN)  1  ‘8Eh’  TCC: таг за криптографската  контролна  
сума  
#(7+L+NN)  1  ‘XXh’  LCC: дължина  на следната  криптографска  
контролна  сума  
‘04h’ за защитения  обмен  на съобщения  от 
поколение  1 (вж. допълнение  11, част А) 
‘08h’, ‘0Ch’ или ‘10h’ в зависимост  от 
дължината  на ключа  по AES за защитен  
обмен  на съобщения  от поколение  2 (вж. 
допълнение  11, част Б) ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 203  
Байт  Дълж­  
ина Стойност  Описание  
#(8+L+NN)-#(7+M+L+NN)  M  ‘XX..XXh’  Криптографска  контролна  сума  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
▼B 
TCS_46  Ответно  съобщение , ако се изисква  SM-R-ENC- 
MAC-G1 ( поколение  1) / SM-R-ENC-MAC-G2 
(поколение  2) и ако форматът  на входящите  данни  
за защитения  обмен  на съобщения  е правилен : 
▼M1 
Байт  Дълж­  
ина Стойност  Описание  
#1 1  ‘87h’  TPI CG: таг за криптираните  данни  (крип­  
тограма ) 
#2 L  ‘MMh’ или 
‘81 MMh’  LPI CG: дължина  на върнатите  крип­  
тирани  данни  (различна  от първона­  
чалната  Le на командата  поради  запъл­  
ване ). 
L е 2 байта , ако LPI CG > 127 байта . 
#(2+L)-#(1+L+MM)  MM  ‘01XX..XXh’  Криптирани  данни : индикатор  за 
запълване  и криптограма  
#(2+L+MM)  1  ‘99h’  Таг за състоянието  на обработката  (SW1- 
SW2) — по избор  за защитен  обмен  на 
съобщения  от поколение  1 
#(3+L+MM)  1  ‘02h’  Дължина  на стойността  за състоянието  на 
обработката  — по избор  за защитен  
обмен  на съобщения  от поколение  1 
#(4+L+MM) - #(5+L+MM)  2  ‘XX XXh’  Състояние  на обработката  на незащи­  
тената  ответна  APDU, т.е. с отговора  — 
незадължително  при защитен  обмен  на 
съобщения  от поколение  1 
#(6+L+MM)  1  ‘8Eh’  TCC: таг за криптографската  контролна  
сума  
#(7+L+MM)  1  ‘XXh’  LCC: дължина  на следната  криптографска  
контролна  сума  
‘04h’ за защитения  обмен  на съобщения  
от поколение  1 (вж. допълнение  11, част 
А) 
‘08h’, ‘0Ch’ или ‘10h’ в зависимост  от 
дължината  на ключа  по AES за защитен  
обмен  на съобщения  от поколение  2 (вж. 
допълнение  11, част Б) 
#(8+L+MM)- 
#(7+N+L+MM)  N ‘XX..XXh’  Криптографска  контролна  сума  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
▼B 
Командата  READ BINARY може  да върне  стойности  за 
нормални  състояния  на обработка , изброени  в TCS_43 
под тага ‘99h’, както  е описано  в TCS_59, използвайки  
за отговора  структурата  за защитен  обмен  на съоб­  
щения . 
Освен  това могат  да възникнат  някои  грешки , 
конкретно  свързани  със защитения  обмен  на съоб­  
щения . В този случай  се връща  само  стойност  за 
състоянието  на обработката  без участието  на струк­  
турата  за защитен  обмен  на съобщения : ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 204  
TCS_47  Ответно  съобщение , ако форматът  на входящите  
данни  за защитения  обмен  на съобщения  не е 
правилен  
Байт  Дължи­  
на Стойност  Описание  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако не е наличен  ключ  на активна  сесия , за 
състоянието  на обработката  се връща  ‘6A88 ’. Това  
става , ако ключът  за сесията  все още не е генериран  
или ако валидността  му е изтекла  (в този случай  
IFD трябва  да извърши  отново  съответния  процес  
на взаимно  удостоверяване  за автентичност  с цел 
генериране  на нов ключ  за сесията ). 
— Ако някои  очаквани  обекти  от данни  (както  е 
определено  по-горе) липсват  в структурата  за 
защитен  обмен  на съобщения , за състоянието  на 
обработката  се връща  ‘6987 ’: тази грешка  
възниква , ако липсва  очакван  таг или ако тялото  
на командата  не е конструирано  правилно . 
— Ако някои  обекти  от данни  са неправилни , за 
състоянието  на обработката  се връща  ‘6988 ’: тази 
грешка  възниква , ако всички  изисквани  тагове  са 
налични , но някои  дължини  се различават  от очак­  
ваните . 
— Ако проверката  на криптографската  контролна  сума  
е неуспешна , за състоянието  на обработката  се 
връща  ‘6688 ’. 
3.5.2.2 К о м а н д а с к р а т ъ к и д е н т и ф и к а т о р н а E F ( е л е ­ 
м е н т а р е н ф а й л ) 
Този  вариант  на командата  позволява  на IFD да селектира  един  
EF чрез неговия  кратък  идентификатор  и да извлече  данни  от 
този EF. 
TCS_48 Тахографската  карта  трябва  да поддържа  този вариант  
на командата  за всички  елементарни  файлове , които  са 
с определен  кратък  идентификатор . Тези  кратки  иден­  
тификатори  на EF са определени  в глава  4. 
TCS_49  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  
INS 1  ‘B0h’  Read Binary  
P1 1  ‘XXh’  За бит 8 е зададена  стойност  1 
За битове  7 и 6 е зададена  стойност  00. 
Битове  5 — 1 кодират  краткия  идентификатор  на 
съответния  EF 
P2 1  ‘XXh’  Кодира  изместване  от 0 до 255 байта  в EF, посочен  
от P1 
Le 1  ‘XXh’  Дължина  на очакваните  данни  Брой  на байтовете , 
които  трябва  да се извлекат . 
Забележка : Кратките  идентификатори  на EF, 
използвани  за тахографското  приложение  от 
поколение  2, са определени  в глава  4. 
Ако P1 кодира  кратък  идентификатор  на EF и 
командата  бъде  изпълнена  успешно , идентифицираният  
EF се селектира  като текущ  (активен  EF).  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 205  
TCS_50  Ответно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
#1-#L  L  ‘XX..XXh’  Извлечени  данни  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— Ако файлът , съответстващ  на краткия  EF идентифи­  
катор , е неоткриваем , за състоянието  на обработката  
се връща  ‘6A82 ’. 
— Ако условията  за сигурност  за селектирания  файл  
не са изпълнени , изпълнението  на командата  се 
прекъсва  с ‘6982 ’. 
— Ако изместването  не е съвместимо  с размера  на EF 
(изместването  > размера  на EF), за състоянието  на 
обработката  се връща  ‘6B00 ’: 
— Ако обемът  на подлежащите  на извличане  данни  не 
е съвместим  с размера  на EF (изместването  + Le > 
размера  на EF), за състоянието  на обработката  се 
връща  ‘6700 ’ или ‘6Cxx ’, където  ‘xx’ указва  
точната  дължина : 
▼M1 
— Ако е открита  грешка  в целостта  на атрибутите  на 
файла , картата  счита  файла  за повреден  и невъзста­  
новим , а за състоянието  на обработката  се връща  
‘6400 ’ или ‘6500 ’. 
▼B 
— Ако е открита  грешка  в цялостността  на записаните  
данни , картата  връща  поисканите  данни , а за 
състоянието  на обработката  се връща  ‘6281 ’. 
3.5.2.3 К о м а н д а с н е ч е т е н б а й т з а и н с т р у к ц и я 
Този  вариант  на командата  позволява  на IFD да извлича  данни  от 
един  елементарен  файл  с големина  32 768 байта  или повече . 
TCS_51 Тахографска  карта , която  поддържа  елементарни  
файлове  с големина  32 768 байта  или повече , трябва  
да поддържа  за тях и този вариант  на командата . Тахог­  
рафската  карта  може  да поддържа  или да не поддържа  
този вариант  на командата  за други  елементарни  
файлове  с изключение  на елементарния  файл  Sensor_In ­
stallation_Data — виж TCS_156 и TCS_160.  
TCS_52  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  
INS 1  ‘B1h’  Read Binary  
P1 1  ‘00h’  Активен  елементарен  файл  
P2 1  ‘00h’  
Lc 1  ‘NNh’  Дължина  Lc на изместения  обект  от данни  
#6-#(5+NN)  NN  ‘XX..XXh’  Изместване  на обекта  от данни : 
Таг ‘54h’ 
Дължина  ‘01h’ или ‘02h’ 
Стойност  изместване  
▼M1 
Le 1  ‘XXh’  Съгласно  стандарта  ISO/IEC 7816-4  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 206  
IFD кодира  дължината  на изместения  обект  от данни  с 
минималния  възможен  брой  октети , т.е. като използва  
байта  за дължина  ‘01h’ IFD кодира  изместване  от 0 до 
255, а като използва  байта  за дължина  ‘02h’ — 
изместване  от ‘256’ до ‘65 535’ байта . 
▼M1 
Ако T=0, картата  приема  за стойност  на Le = ‘00h’, ако 
не се прилага  защитен  обмен  на съобщения . 
Ако T = 1, за състоянието  на обработката  се връща  
‘6700’, ако Le=’01h’.  
▼B 
TCS_53  Ответно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
#1-#L  L  ‘XX..XXh’  Извлечените  данни , капсулирани  в дискреционен  
обект  от данни  с таг ‘53h’.  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— Ако не е селектиран  елементарен  файл  (EF), за 
състоянието  на обработката  се връща  ‘6986 ’. 
— Ако условията  за сигурност  за селектирания  файл  
не са изпълнени , изпълнението  на командата  се 
прекъсва  с ‘6982 ’. 
— Ако изместването  не е съвместимо  с размера  на EF 
(изместването  > размера  на EF), за състоянието  на 
обработката  се връща  ‘6B00 ’: 
— Ако обемът  на подлежащите  на извличане  данни  не 
е съвместим  с размера  на EF (изместването  + Le > 
размера  на EF), за състоянието  на обработката  се 
връща  ‘6700 ’ или ‘6Cxx ’, където  ‘xx’ указва  
точната  дължина . 
▼M1 
— Ако е открита  грешка  в целостта  на атрибутите  на 
файла , картата  счита  файла  за повреден  и невъзста­  
новим , а за състоянието  на обработката  се връща  
‘6400 ’ или ‘6500 ’. 
▼B 
— Ако е открита  грешка  в цялостността  на записаните  
данни , картата  връща  поисканите  данни , а за 
състоянието  на обработката  се връща  ‘6281 ’. 
3.5.2.3.1 К о м а н д а с ъ с з а щ и т е н о б м е н н а с ъ о б щ е н и я 
( п р и м е р ) 
Следният  пример  онагледява  използването  на защитен  обмен  на 
съобщения , ако е валидно  условието  за сигурност  SM-MAC-G2.  
TCS_54 Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘0Ch’  Изисква  се защитен  обмен  на съобщения  
INS 1  ‘B1h’  Read Binary  
P1 1  ‘00h’  Активен  елементарен  файл  
P2 1  ‘00h’  
Lc 1  ‘XXh’  Дължина  на защитеното  поле  за данни  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 207  
Байт  Дължи­  
на Стойност  Описание  
#6 1  ‘B3h’  Таг за простата  стойност  на данните , кодирани  по 
BER-TLV  
#7 1  ‘NNh’  L  PV : дължина  на предадените  данни  
#(8)-#(7+NN)  NN  ‘XX..XXh’  Прости  данни , кодирани  по BER-TLV, т.е. измес­  
теният  обект  от данни  с таг ‘54’  
#(8+NN)  1  ‘97h’  T  LE : таг за спецификацията  на очакваната  дължина  
#(9+NN)  1  ‘01h’  L  LE : Очаквана  дължина  
#(10+NN)  1  ‘XXh’  Спецификация  на очакваната  дължина  (първоначална  
Le): брой  на байтовете , които  трябва  да се извлекат . 
#(11+NN)  1  ‘8Eh’  T  CC : таг за криптографската  контролна  сума  
#(12+NN)  1  ‘XXh’  L  CC : дължина  на следната  криптографска  контролна  
сума  
‘08h’, ‘0Ch’ или ‘10h’ в зависимост  от дължината  на 
ключа  по AES за защитен  обмен  на съобщения  от 
поколение  2 (виж допълнение  11, част Б) 
#(13+NN)- 
#(12+M+NN)  M ‘XX..XXh’  Криптографска  контролна  сума  
Le 1  ‘00h’  Съгласно  стандарта  ISO/IEC 7816-4  
TCS_55 Ответно  съобщение , ако командата  бъде  изпълнена  
успешно  
Байт  Дължи­  
на Стойност  Описание  
#1 1  ‘B3h’  Прости  данни , кодирани  по BER-TLV  
#2 L  ‘NNh’ или 
‘81 NNh’  L PV : дължина  на върнатите  данни  (= първоначална  
Le) 
L е 2 байта , ако L PV >127 байта  
#(2+L)- 
#(1+L+NN)  NN ‘XX..XXh’  Стойност  на простите  данни , кодирана  по BER-TLV, 
т.е. извлечените  данни , капсулирани  в дискреционен  
обект  от данни  с таг ‘53h’.  
#(2+L+NN)  1  ‘99h’  Състояние  на обработката  на незащитената  ответна  
APDU  
#(3+L+NN)  1  ‘02h’  Дължина  на стойността  за състоянието  на обра­  
ботката  
#(4+L+NN) — 
#(5+L+NN)  2 ‘XX XXh’  Състояние  на обработката  на незащитената  ответна  
APDU  
#(6+L+NN)  1  ‘8Eh’  T  CC : таг за криптографската  контролна  сума  
#(7+L+NN)  1  ‘XXh’  L  CC : дължина  на следната  криптографска  контролна  
сума  
‘08h’, ‘0Ch’ или ‘10h’ в зависимост  от дължината  на 
ключа  по AES за защитен  обмен  на съобщения  от 
поколение  2 (виж допълнение  11, част Б) 
#(8+L+NN)- 
#(7+M+L+N ­
N) M ‘XX..XXh’  Криптографска  контролна  сума  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
3.5.3  UPDATE BINARY  
Тази  команда  е в съответствие  със стандарта  ISO/IEC 7816-4, но е 
с по-ограничена  употреба  в сравнение  с аналогичната  команда , 
описана  в този стандарт . 
Съобщението  с командата  UPDATE BINARY инициализира  
актуализирането  (изтриване  + записване ) на битовете , които  
вече присъстват  в определен  двоичен  елементарен  файл  (EF), с 
битовете , които  се съдържат  в APDU с командата . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 208  
3.5.3.1 К о м а н д а с и з м е с т в а н е в P 1 - P 2  
Тази  команда  позволява  на IFD да запише  данните  в селек­  
тирания  елементарен  файл , без картата  да проверява  цялостността  
на получените  данни . 
Забележка : Тази  команда  може  да се използва  без защитен  обмен  
на съобщения  за актуализиране  само  на файл , който  поддържа  
условието  за сигурност  ALW за режима  на достъп  за актуали­  
зиране . 
TCS_56  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  
INS 1  ‘D6h’  Update Binary  
P1 1  ‘XXh’  Изместване  в байтове , считано  от началото  на файла : 
най-старшият  байт  
P2 1  ‘XXh’  Изместване  в байтове , считано  от началото  на файла : 
най-младшият  байт  
Lc 1  ‘NNh’  Дължина  Lc на данните , които  подлежат  на актуали­  
зиране  Брой  на байтовете , които  трябва  да се 
запишат  
#6-#(5+NN)  NN  ‘XX..XXh’  Данни , които  трябва  да се запишат  
Забележка : бит 8 на байт  P1 трябва  да бъде  равен  на 
нула . 
TCS_57  Ответно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— Ако не е селектиран  елементарен  файл  (EF), за 
състоянието  на обработката  се връща  ‘6986 ’. 
— Ако условията  за сигурност  за селектирания  файл  
не са изпълнени , изпълнението  на командата  се 
прекъсва  с ‘6982 ’. 
— Ако изместването  не е съвместимо  с размера  на EF 
(изместването  > размера  на EF), за състоянието  на 
обработката  се връща  ‘6B00 ’: 
— Ако обемът  на данните , които  ще се записват , не е 
съвместим  с размера  на елементарния  файл  (измест­  
ването  + Lc > размера  на елементарния  файл ), за 
състоянието  на обработката  се връща  ‘6700 ’. 
— Ако е открита  грешка  в цялостността  на атрибутите  
на файла , картата  счита  файла  за повреден  и невъз­  
становим , а за състоянието  на обработката  се връща  
‘6400 ’ или ‘6500 ’. 
— Ако записването  е неуспешно , за състоянието  на 
обработката  се връща  ‘6581 ’. 
3.5.3.1.1 К о м а н д а с ъ с з а щ и т е н о б м е н н а с ъ о б щ е н и я 
( п р и м е р и ) 
Тази  команда  позволява  на IFD да запише  данните  в селек­  
тирания  елементарен  файл , като картата  проверява  цялостността  
на получените  данни . Тъй като няма  изискване  за поверителност , 
данните  не са криптирани . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 209  
TCS_58  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘0Ch’  Изисква  се защитен  обмен  на съобщения  
INS 1  ‘D6h’  Update Binary  
P1 1  ‘XXh’  Изместване  в байтове , считано  от началото  на файла : 
най-старшият  байт  
P2 1  ‘XXh’  Изместване  в байтове , считано  от началото  на файла : 
най-младшият  байт  
Lc 1  ‘XXh’  Дължина  на защитеното  поле  за данни  
#6 1  ‘81h’  T  PV : таг за простата  стойност  на данните  
#7 L  ‘NNh’ или 
‘81 NNh’  L PV : дължина  на предадените  данни  
L е 2 байта , ако L PV > 127 байта  
#(7+L)- 
#(6+L+NN)  NN ‘XX..XXh’  Стойност  на простите  данни  (данни , които  трябва  да 
се запишат ) 
#(7+L+NN)  1  ‘8Eh’  T  CC : таг за криптографската  контролна  сума  
#(8+L+NN)  1  ‘XXh’  L  CC : дължина  на следната  криптографска  контролна  
сума ‘04h’ за защитения  обмен  на съобщения  от 
поколение  1 (виж допълнение  11, част А) 
‘08h’, ‘0Ch’ или ‘10h’ в зависимост  от дължината  на 
ключа  по AES за защитен  обмен  на съобщения  от 
поколение  2 (виж допълнение  11, част Б) 
#(9+L+NN)- 
#(8+M+L+N ­
N) M ‘XX..XXh’  Криптографска  контролна  сума  
Le 1  ‘00h’  Съгласно  стандарта  ISO/IEC 7816-4  
TCS_59  Ответно  съобщение  ако форматът  на входящите  
данни  при защитения  обмен  на съобщения  е 
правилен  
Байт  Дължи­  
на Стойност  Описание  
#1 1  ‘99h’  T  SW : таг за байтовете  за състояние  (трябва  защита  с 
криптографски  контрол ) 
#2 1  ‘02h’  L  SW : дължина  на върнатите  байтове  за състояние  
#3-#4  2  ‘XXXXh’  Състояние  на обработката  на незащитената  ответна  
APDU  
#5 1  ‘8Eh’  T  CC : таг за криптографската  контролна  сума  
#6 1  ‘XXh’  L  CC : дължина  на следната  криптографска  контролна  
сума  
‘04h’ за защитения  обмен  на съобщения  от поколение  
1 (виж допълнение  11, част А) 
‘08h’, ‘0Ch’ или ‘10h’ в зависимост  от дължината  на 
ключа  по AES за защитен  обмен  на съобщения  от 
поколение  2 (виж допълнение  11, част Б) 
#7-#(6+L)  L  ‘XX..XXh’  Криптографска  контролна  сума  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
Стойностите  за „нормалните “ състояния  на обработка , 
описани  за командата  UPDATE BINARY без 
използване  на защитен  обмен  на съобщения  (виж 
точка  3.5.3.1), могат  да бъдат  върнати , като се 
използва  описаната  по-горе структура  на ответно  съоб­  
щение . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 210  
Освен  това могат  да възникнат  някои  грешки , 
конкретно  свързани  със защитения  обмен  на съоб­  
щения . В този случай  се връща  само  стойността  за 
състоянието  на обработката  без участието  на струк­  
турата  за защитен  обмен  на съобщения : 
TCS_60  Ответно  съобщение  в случай  на грешка , засягаща  
защитения  обмен  на съобщения  
Байт  Дължи­  
на Стойност  Описание  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако не е наличен  ключ  на активна  сесия , за 
състоянието  на обработката  се връща  ‘6A88 ’. 
— Ако някои  очаквани  обекти  от данни  (както  е 
определено  по-горе) липсват  в структурата  за 
защитен  обмен  на съобщения , за състоянието  на 
обработката  се връща  ‘6987 ’: тази грешка  
възниква , ако липсва  очакван  таг или ако тялото  
на командата  не е конструирано  правилно . 
— Ако някои  обекти  от данни  са неправилни , за 
състоянието  на обработката  се връща  ‘6988 ’: тази 
грешка  възниква , ако всички  изисквани  тагове  са 
налични , но някои  дължини  се различават  от очак­  
ваните . 
— Ако проверката  на криптографската  контролна  сума  
е неуспешна , за състоянието  на обработката  се 
връща  ‘6688 ’. 
3.5.3.2 К о м а н д а с к р а т ъ к и д е н т и ф и к а т о р н а E F  
Този  вариант  на командата  позволява  на IFD да селектира  един  
EF чрез неговия  кратък  идентификатор  и да запише  данни  от този 
EF. 
TCS_61 Тахографската  карта  трябва  да поддържа  този вариант  
на командата  за всички  елементарни  файлове , които  са 
с определен  кратък  идентификатор . Тези  кратки  иден­  
тификатори  на EF са определени  в глава  4. 
TCS_62  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  
INS 1  ‘D6h’  Update Binary  
P1 1  ‘XXh’  За бит 8 е зададена  стойност  1 
За битове  7 и 6 е зададена  стойност  00. 
Битове  5 — 1 кодират  краткия  идентификатор  на 
съответния  EF 
P2 1  ‘XXh’  Кодира  изместване  от 0 до 255 байта  в EF, посочен  
от P1 
Lc 1  ‘NNh’  Дължина  Lc на данните , които  подлежат  на актуали­  
зиране  Брой  на байтовете , които  трябва  да се 
запишат  
#6-#(5+NN)  NN  ‘XX..XXh’  Данни , които  трябва  да се запишат  
TCS_63  Ответно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
Забележка : Кратките  идентификатори  на EF, 
използвани  за тахографското  приложение  от 
поколение  2, са определени  в глава  4. 
Ако P1 кодира  кратък  идентификатор  на EF и 
командата  бъде  изпълнена  успешно , идентифицираният  
EF се селектира  като текущ  (активен  EF).  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 211  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— Ако файлът , съответстващ  на краткия  EF идентифи­  
катор , е неоткриваем , за състоянието  на обработката  
се връща  ‘6A82 ’. 
— Ако условията  за сигурност  за селектирания  файл  
не са изпълнени , изпълнението  на командата  се 
прекъсва  с ‘6982 ’. 
— Ако изместването  не е съвместимо  с размера  на EF 
(изместване  > размера  на EF), за състоянието  на 
обработката  се връща  ‘6B00 ’: 
— Ако обемът  на данните , които  ще се записват , не е 
съвместим  с размера  на елементарния  файл  (измест­  
ването  + Lc > размера  на елементарния  файл ), за 
състоянието  на обработката  се връща  ‘6700 ’. 
▼M1 
— Ако е открита  грешка  в целостта  на атрибутите  на 
файла , картата  счита  файла  за повреден  и невъзста­  
новим , а за състоянието  на обработката  се връща  
‘6400 ’ или ‘6500 ’. 
▼B 
— Ако записването  е неуспешно , за състоянието  на 
обработката  се връща  ‘6581 ’. 
3.5.3.3 К о м а н д а с н е ч е т е н б а й т з а и н с т р у к ц и я 
Този  вариант  на командата  позволява  на IFD да записва  данни  в 
елементарен  файл  с големина  32 768 байта  или повече . 
TCS_64 Тахографска  карта , която  поддържа  елементарни  
файлове  с големина  32 768 байта  или повече , трябва  
да поддържа  за тях и този вариант  на командата . Тахог­  
рафската  карта  може  да поддържа  или да не поддържа  
този вариант  на командата  за други  елементарни  
файлове . 
TCS_65  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  
INS 1  ‘D7h’  Update Binary  
P1 1  ‘00h’  Активен  елементарен  файл  
P2 1  ‘00h’  
Lc 1  ‘NNh’  Lc дължина  на данните  в полето  за данни  на 
командата  
#6-#(5+NN)  NN  ‘XX..XXh’  Изместване  на обект  от данни  с таг ‘54h’ || Дискре­  
ционен  обект  от данни  с таг ‘53h’, в който  са капсу­  
лирани  подлежащите  на записване  данни  
IFD кодира  дължината  на изместения  обект  от данни  и 
на дискреционния  обект  от данни  с минималния  
възможен  брой  октети , т.е. като използва  байта  за 
дължина  ‘01h’ IFD кодира  изместване  / дължина  от 0 
до 255, а като използва  байта  за дължина  ‘02h’ — 
изместване  / дължина  от ‘256’ до ‘65 535’ байта . 
TCS_66  Ответно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 212  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— Ако не е селектиран  елементарен  файл  (EF), за 
състоянието  на обработката  се връща  ‘6986 ’. 
— Ако условията  за сигурност  за селектирания  файл  
не са изпълнени , изпълнението  на командата  се 
прекъсва  с ‘6982 ’. 
— Ако изместването  не е съвместимо  с размера  на EF 
(изместването  > размера  на EF), за състоянието  на 
обработката  се връща  ‘6B00 ’: 
— Ако обемът  на данните , които  ще се записват , не е 
съвместим  с размера  на елементарния  файл  (измест­  
ването  + Lc > размера  на елементарния  файл ), за 
състоянието  на обработката  се връща  ‘6700 ’. 
— Ако е открита  грешка  в цялостността  на атрибутите  
на файла , картата  счита  файла  за повреден  и невъз­  
становим , а за състоянието  на обработката  се връща  
‘6400 ’ или ‘6500 ’. 
— Ако записването  е неуспешно , за състоянието  на 
обработката  се връща  ‘6581 ’. 
3.5.3.3.1 К о м а н д а с ъ с з а щ и т е н о б м е н н а с ъ о б щ е н и я 
( п р и м е р ) 
Следният  пример  онагледява  използването  на защитен  обмен  на 
съобщения , ако е валидно  условието  за сигурност  SM-MAC-G2.  
TCS_67 Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘0Ch’  Изисква  се защитен  обмен  на съобщения  
INS 1  ‘D7h’  Update Binary  
P1 1  ‘00h’  Активен  елементарен  файл  
P2 1  ‘00h’  
Lc 1  ‘XXh’  Дължина  на защитеното  поле  за данни  
#6 1  ‘B3h’  Таг за простата  стойност  на данните , кодирани  по 
BER-TLV  
#7 L  ‘NNh’ или 
‘81 NNh’  L PV : дължина  на предадените  данни  
L е 2 байта , ако L PV > 127 байта  
#(7+L)- 
#(6+L+NN)  NN ‘XX..XXh’  Прости  данни , кодирани  по BER-TLV, т.е. 
изместване  на обекта  от данни  с таг ‘54h’ || Дискре­  
ционен  обект  от данни  с таг ‘53h’, в който  са капсу­  
лирани  подлежащите  на записване  данни  
#(7+L+NN)  1  ‘8Eh’  T  CC : таг за криптографската  контролна  сума  
#(8+L+NN)  1  ‘XXh’  L  CC : дължина  на следната  криптографска  контролна  
сума  
‘08h’, ‘0Ch’ или ‘10h’ в зависимост  от дължината  на 
ключа  по AES за защитен  обмен  на съобщения  от 
поколение  2 (виж допълнение  11, част Б) 
#(9+L+NN)- 
#(8+M+L+N ­
N) M ‘XX..XXh’  Криптографска  контролна  сума  
Le 1  ‘00h’  Съгласно  стандарта  ISO/IEC 7816-4  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 213  
TCS_68 Ответно  съобщение  ако командата  бъде  изпълнена  
успешно  
Байт  Дължи­  
на Стойност  Описание  
#1 1  ‘99h’  T  SW : таг за байтовете  за състояние  (трябва  защита  с 
криптографски  контрол ) 
#2 1  ‘02h’  L  SW : дължина  на върнатите  байтове  за състояние  
#3-#4  2  ‘XXXXh’  Състояние  на обработката  на незащитената  ответна  
APDU  
#5 1  ‘8Eh’  T  CC : таг за криптографската  контролна  сума  
#6 1  ‘XXh’  L  CC : дължина  на следната  криптографска  контролна  
сума  
‘08h’, ‘0Ch’ или ‘10h’ в зависимост  от дължината  на 
ключа  по AES за защитен  обмен  на съобщения  от 
поколение  2 (виж допълнение  11, част Б) 
#7-#(6+L)  L  ‘XX..XXh’  Криптографска  контролна  сума  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
3.5.4  GET CHALLENGE  
Тази  команда  е в съответствие  със стандарта  ISO/IEC 7816-4, но е 
с по-ограничена  употреба  в сравнение  с аналогичната  команда , 
описана  в този стандарт . 
С командата  GET CHALLENGE от картата  се иска  да издаде  
произволно  число , за да се използва  то в свързана  със сигур­  
ността  процедура , при която  на картата  се изпращат  някои  крип­  
тирани  данни  или криптограма . 
TCS_69 Произволното  число , издадено  от картата , важи  един­  
ствено  за следващата  команда , при която  се използва  
произволно  число , изпратено  на картата . 
TCS_70  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  
INS 1  ‘84h’  INS  
P1 1  ‘00h’  P1  
P2 1  ‘00h’  P2  
Le 1  ‘08h’  Le ( дължина  на очакваното  произволно  число ) 
TCS_71  Ответно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
#1-#8  8  ‘XX..XXh’  Произволно  число  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— Ако байтът  Le се различава  от ‘08h’, състоянието  на 
обработката  е ‘6700 ’. 
— Ако параметрите  P1-P2 са неправилни , състоянието  
на обработката  е ‘6A86 ’. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 214  
3.5.5  VERIFY  
Тази  команда  е в съответствие  със стандарта  ISO/IEC 7816-4, но е 
с по-ограничена  употреба  в сравнение  с аналогичната  команда , 
описана  в този стандарт . 
Само  за картата  за монтаж  и настройки  се изисква  да поддържа  
тази команда . 
Другите  видове  тахографски  карти  могат  или не могат  да 
изпълняват  тази команда , но за тях референтната  информация  
за CHV не е персонализирана . Поради  това тези карти  не могат  
да изпълняват  успешно  тази команда . Ако тази команда  бъде  
подадена  на други  видове  тахографски  карти , различни  от 
картите  за монтаж  и настройки , тяхното  поведение , т.е. 
връщаният  код за грешка , е извън  обхвата  на настоящата  специ­  
фикация . 
Командата  VERIFY стартира  сравняването  на равнището  на 
картата  между  изпратените  данни  за CHV (PIN) и референтните  
данни  за CHV, записани  в паметта  на картата . 
▼M1 
TCS_72 Въведеният  от потребителя  PIN трябва  да е по 
стандарта  ASCII за кодиране  на символи  и да е 
запълнен  от IFD отдясно  с байтове  ‘FFh’ до дължина  
от 8 байта  — вж. също  в допълнение  1 за типа  на 
данните  WorkshopCardPIN.  
▼B 
TCS_73 За тахографските  приложения  от поколения  1 и 2 се 
използват  едни  и същи  референтни  данни  за CHV.  
TCS_74 Тахографската  карта  проверява  дали  командата  е 
кодирана  правилно . Ако командата  не е кодирана  
правилно , картата  не сравнява  стойностите  за CHV, 
не намалява  стойността  на брояча  за оставащите  
опити  за CHV и не инициализира  състоянието  
„PIN_Verified“ по отношение  на сигурността , а 
прекратява  изпълнението  на командата . Командата  е 
кодирана  правилно , ако байтовете  CLA, INS, P1, P2 и 
Lc са с указаните  стойности , Le отсъства  и полето  за 
данни  на командата  е с правилната  дължина . 
TCS_75 Ако командата  бъде  изпълнена  успешно , броячът  на 
оставащите  опити  за CHV се връща  на първоначалната  
си стойност . Първоначалната  стойност  на брояча  на 
оставащите  опити  за CHV е 5. Ако командата  бъде  
изпълнена  успешно , картата  установява  „PIN_Verified“ 
за вътрешното  състояние  по отношение  на сигурността . 
Картата  инициализира  това състояние  по отношение  на 
сигурността , ако картата  бъде  инициализирана  или ако 
предаденият  в командата  код за CHV не съвпада  със 
съхраняваните  референтни  данни  за CHV.  
Забележка : Чрез  използването  на същите  референтни  
данни  за CHV и на общо  състояние  по отношение  на 
сигурността  се избягва  необходимостта  сервизният  
служител  да въвежда  повторно  PIN след  селектиране  
на специализиран  файл  (DF) на друго  тахографско  
приложение . 
TCS_76 Ако сравняването  завърши  неуспешно , това се 
регистрира  в картата , т.е. стойността  на брояча  за оста­  
ващите  опити  за CHV се намалява  с единица , за да се 
ограничи  броят  на следващите  опити  за използване  на 
референтните  данни  за CHV.  
TCS_77  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  
INS 1  ‘20h’  INS  
P1 1  ‘00h’  P1  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 215  
Байт  Дължи­  
на Стойност  Описание  
P2 1  ‘00h’  P2 ( проверените  данни  за CHV са известни  по 
подразбиране ) 
Lc 1  ‘08h’  Дължина  на предадения  код за CHV  
#6-#13  8  ‘XX..XXh’  CHV  
TCS_78  Ответно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— Ако референтните  данни  за CHV са неоткриваеми , 
за състоянието  на обработката  се връща  ‘6A88 ’. 
— Ако проверката  CHV е блокирана  (броячът  на оста­  
ващите  опити  за CHV е на нула ), за състоянието  на 
обработката  се връща  ‘6983 ’. След  като се достигне  
това състояние , повече  не е възможно  данните  за 
CHV да бъдат  представени  успешно . 
— Ако сравняването  не завърши  успешно , стойността  
на брояча  за оставащите  опити  се намалява  с 
единица  и за състоянието  се връща  ‘63CX ’ (X>0 и 
X е равно  на стойността  на брояча  за оставащите  
опити ). 
— Ако референтните  данни  за CHV се считат  за 
повредени , за състоянието  на обработката  се 
връща  ‘6400 ’ или ‘6581 ’. 
— Ако Lc се различава  от ‘08h’, състоянието  на обра­  
ботката  е ‘6700 ’. 
3.5.6  GET RESPONSE  
Тази  команда  е в съответствие  със стандарта  ISO/IEC 7816-4.  
Тази  команда  (която  е необходима  и налична  само  за протокола  
T=0) се използва  за предаване  на подготвените  данни  от картата  
към интерфейсното  устройство  (когато  и двата  байта  Lc и Le са 
включени  в командата ). 
Командата  GET RESPONSE трябва  да бъде  изпратена  непос­  
редствено  след  командата  за подготовка  на данните , тъй като в 
противен  случай  данните  се загубват . След  изпълнението  на 
командата  GET RESPONSE подготвените  преди  това данни  не 
са налични  повече  (освен  ако възникне  грешката  ‘61xx ’ или 
‘6Cxx ’, виж по-долу ). 
TCS_79  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  
INS 1  ‘C0h’  
P1 1  ‘00h’  
P2 1  ‘00h’  
Le 1  ‘XXh’  Брой  на очакваните  байтове  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 216  
TCS_80  Ответно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
#1-#X  X  ‘XX..XXh’  Данни  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— Ако картата  не е подготвила  никакви  данни , за 
състоянието  на обработката  се връща  ‘6900 ’ или 
‘6F00 ’. 
— Ако байтът  Le надвишава  броя  на наличните  
байтове  или ако този байт  е нулев , за състоянието  
на обработката  се връща  ‘6Cxx ’, където  xx указва  
точния  брой  на наличните  байтове . В този случай  
подготвените  данни  остават  на разположение  за 
изпълнението  по-късно  на командата  GET 
RESPONSE.  
— Ако байтът  Le представлява  ненулева  стойност , 
която  е по-малка  от броя  на наличните  байтове , 
картата  нормално  изпраща  исканите  данни  и за 
състоянието  на обработката  се връща  ‘61xx ’, 
където  ‘xx’ указва  броя  на допълнителните  
байтове , които  все още са на разположение  за 
изпълнението  по-късно  на командата  GET 
RESPONSE.  
— Ако командата  не се поддържа  (за протокола  Т=1), 
картата  връща  ‘6D00 ’. 
3.5.7  PSO: VERIFY CERTIFICATE  
Тази  команда  е в съответствие  със стандарта  ISO/IEC 7816-8, но е 
с по-ограничена  употреба  в сравнение  с аналогичната  команда , 
описана  в този стандарт . 
Картата  използва  командата  VERIFY CERTIFICATE, за да получи  
публичен  ключ , идващ  от публичното  пространство , и за 
проверка  на неговата  валидност . 
3.5.7.1 Д в о й к а к о м а н д а — о т г о в о р о т п о к о л е н и е 1 
TCS_81 Този  вариант  на командата  се поддържа  само  от тахог­  
рафско  приложение  от поколение  1. 
TCS_82 Когато  командата  VERIFY CERTIFICATE бъде  
изпълнена  успешно , съответният  публичен  ключ  се 
запаметява  в средата , свързана  със защитата  от 
неоторизиран  достъп , с цел по-късното  му използване . 
Този  ключ  трябва  да бъде  специално  конфигуриран , за 
да бъде  използван  в рамките  на командите , имащи  
отношение  към сигурността  (INTERNAL AUTHEN ­
TICATE, EXTERNAL AUTHENTICATE или VERIFY 
CERTIFICATE), чрез командата  MSE ( виж точка  
3.5.11), като се използва  неговият  идентификатор . 
TCS_83 При всички  положения  командата  VERIFY CERTI ­
FICATE използва  публичния  ключ , избран  преди  това 
чрез командата  MSE, за да отвори  определен  серти­  
фикат . Това  трябва  да бъде  публичен  ключ  на 
определена  държава  членка  или на Европа . 
TCS_84  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  
INS 1  ‘2Ah’  Извършване  на операция , свързана  със защитата  от 
неоторизиран  достъп  
P1 1  ‘00h’  P1  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 217  
Байт  Дължи­  
на Стойност  Описание  
P2 1  ‘AEh’  P2: данни , които  не са кодирани  по BER-TLV ( кон­  
катенация  на елементи  на данни ) 
Lc 1  ‘C2h’  Lc: дължина  на сертификата , 194 байта  
#6-#199  194  ‘XX..XXh’  Сертификат : конкатенация  на елементи  на данни  
(съгласно  описанието  в допълнение  11) 
TCS_85  Ответно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— Ако проверката  на сертификата  е неуспешна , за 
състоянието  на обработката  се връща  ‘6688 ’. 
Процесът  на проверка  и на отваряне  на сертификата  
е описан  в допълнение  11 за поколения  1 и 2. 
— Ако не е наличен  ключ  в средата , свързана  със 
защитата  от неоторизиран  достъп , се връща  ‘6A88 ’. 
— Ако избраният  публичен  ключ  (използван  за 
отваряне  на сертификата ) се счита  за повреден , за 
състоянието  на обработката  се връща  ‘6400’ или 
‘6581’ . 
— Само  за поколение  1: ако избраният  публичен  ключ  
(използван  за отваряне  на сертификата ) има 
CHA.LSB (
  ), 
различен  от ‘00’ (т.е. не принадлежи  на държава  
членка  или на Европа ), за състоянието  на обра­  
ботката  се връща  ‘6985 ’. 
3.5.7.2 Д в о й к а к о м а н д а — о т г о в о р о т п о к о л е н и е 2 
В зависимост  от размера  на кривата  ECC сертификатите  могат  да 
бъдат  толкова  дълги , че да не е възможно  предаването  им в една - 
единствена  APDU. В този случай  трябва  да се приложи  верижно  
свързване  на команди  в съответствие  с ISO/IEC 7816-4 и серти­  
фикатът  се предава  в две последователни  APDU PSO: Verify 
Certificate.  
Структурата  на сертификата  и параметрите  на домейна  са 
определени  в допълнение  11. 
TCS_86 Тази  команда  може  да бъде  изпълнена  в MF, DF 
Tachograph и DF Tachograph_G2, виж също  TCS_33.  
TCS_87  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘X0h’  Байт  CLA, указващ  верижно  свързване  на команди : 
‘00h’ за единствена  или последна  команда  във 
веригата  
‘10h’ за команда , която  не е последна  във веригата  
INS 1  ‘2Ah’  Извършване  на операция , свързана  със защитата  от 
неоторизиран  достъп  
P1 1  ‘00h’  
P2 1  ‘BEh’  Проверка  на самоописващ  се (self-descriptive) серти­  
фикат  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 218  
Байт  Дължи­  
на Стойност  Описание  
Lc 1  ‘XXh’  Дължина  на полето  за данни  на командата , виж 
TCS_88 и TCS_89.  
#6-#5+L  L  ‘XX..XXh’  Данни , кодирани  по DER-TLV: обектът  от данни  в 
тялото  на ECC сертификата  е съединен  като първи  
обект  от данни  с обекта  от данни  в подписа  на ECC 
сертификата  като втори  обект  от данни  или част от 
тази конкатенация . Тагът  ‘7F21’ и съответната  
дължина  не се предават . 
Тези  обекти  от данни  са във фиксирана  последова­  
телност . 
TCS_88 За APDU с малка  дължина  се прилагат  следните  
разпоредби : IFD трябва  да използва  минималния  брой  
APDU, необходими  за предаването  на командите , и да 
предава  максималния  брой  байтове  в първата  APDU с 
команда  съгласно  стойността  на байта  за зоната  за 
информация , запазена  за картата , виж TCS_14. Ако 
IFD действа  по различен  начин , поведението  на 
картата  е извън  обхвата  на настоящата  спецификация . 
TCS_89 За APDU с увеличена  дължина  се прилагат  следните  
разпоредби : Ако сертификатът  не се побира  в една - 
единствена  APDU, картата  трябва  да поддържа  
верижно  свързване  на команди . IFD трябва  да 
използва  минималния  брой  APDU, необходими  за пред­  
аването  на командите , и да предава  максималния  брой  
байтове  в първата  APDU с команда . Ако IFD действа  
по различен  начин , поведението  на картата  е извън  
обхвата  на настоящата  спецификация . 
Забележка : съгласно  допълнение  11 картата  съхранява  
сертификата  или съответното  съдържание  на серти­  
фиката  и актуализира  своето  currentAuthenticatedTime.  
Структурата  на ответното  съобщение  и байтовете  за 
състоянието  са определени  в TCS_85.  
TCS_90 В допълнение  към кодовете  за грешка , посочени  в 
TCS_85, картата  може  да върне  следните  кодове  за 
грешка : 
— ако избраният  публичен  ключ  (използван  за 
отваряне  на сертификата ) има CHA.LSB (Certificate ­
HolderAuthorisation.equipmentType), който  не е 
подходящ  за проверка  на сертификата  съгласно  
допълнение  11, за състоянието  на обработката  се 
връща  ‘6985 ’. 
— Ако currentAuthenticatedTime на картата  е по-късно  
от датата  на изтичане  на срока  на сертификата , а 
състоянието  на обработката  се връща  ‘6985 ’. 
— Ако се очаква  последната  команда  от верижната  
последователност , картата  връща  ‘6883 ’. 
— Ако са изпратени  неправилни  параметри  в полето  за 
данни  на командата , картата  връща  ‘6A80 ’ (използва  
се и когато  обектите  от данни  не са изпратени  в 
указаната  последователност ). ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 219  
3.5.8  INTERNAL AUTHENTICATE  
Тази  команда  е в съответствие  със стандарта  ISO/IEC 7816-4.  
TCS_91 Всички  тахографски  карти  трябва  да поддържат  тази 
команда  в специализирания  файл  (DF) Tachograph от 
поколение  1. Тази  команда  може  или не може  да е 
достъпна  в MF и/или в DF Tachograph_G2. Ако 
командата  е достъпна , нейното  изпълнение  се 
прекратява  с подходящ  код за грешка , тъй като 
частният  ключ  на картата  (Card.SK) за протокола  от 
поколение  1 за удостоверяване  на автентичността  е 
достъпен  само  в DF_Tachograph от поколение  1. 
Чрез  командата  INTERNAL AUTHENTICATE интер­  
фейсното  устройство  (IFD) може  да удостовери  автен­  
тичността  на картата . Процесът  на удостоверяване  е 
описан  в допълнение  11. Той включва  следните  
оператори : 
TCS_92 Командата  INTERNAL AUTHENTICATE използва  
частния  ключ  на картата  (избран  по подразбиране ), за 
да подпише  данните  от удостоверяването , включително  
K1 (първият  елемент , указващ  съпоставянето  на 
ключовете  на сесията ) и RND1, и също  така използва  
избрания  публичен  ключ  (посредством  последната  
команда  MSE), за да криптира  подписа  и да състави  
маркера  за удостоверяването  (за повече  подробности  
виж допълнение  11).  
TCS_93  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  CLA  
INS 1  ‘88h’  INS  
P1 1  ‘00h’  P1  
P2 1  ‘00h’  P2  
Lc 1  ‘10h’  Дължина  на данните , изпратени  на картата  
#6 — #13  8  ‘XX..XXh’  Искане  за достъп , използвано  за удостоверяване  
автентичността  на картата  
#14 -#21  8  ‘XX..XXh’  VU.CHR ( виж допълнение  11) 
Le 1  ‘80h’  Дължина  на очакваните  данни , идващи  от картата  
TCS_94  Ответно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
#1-#128  128  ‘XX..XXh’  Маркер  за удостоверяването  на картата  (виж 
допълнение  11) 
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— Ако не е наличен  публичен  ключ  в средата , 
свързана  със защитата  от неоторизиран  достъп , за 
състоянието  на обработката  се връща  ‘6A88 ’. 
— Ако не е наличен  частен  ключ  в средата , свързана  
със защитата  от неоторизиран  достъп , за 
състоянието  на обработката  се връща  ‘6A88 ’. 
— Ако VU.CHR не съвпада  с идентификатора  на 
активния  публичен  ключ , за състоянието  на обра­  
ботката  се връща  ‘6A88 ’. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 220  
— Ако избраният  частен  ключ  се счита  за повреден , за 
състоянието  на обработката  се връща  ‘6400 ’ или 
‘6581 ’. 
▼M1 
TCS_95 Ако командата  INTERNAL_AUTHENTICATE бъде  
изпълнена  успешно , активният  ключ  на сесията  от 
поколение  1, ако има такъв , се изтрива  и повече  не е 
наличен . За да има на разположение  нов ключ  на сесия  
от поколение  1, е необходимо  да се изпълни  успешно  
командата  EXTERNAL AUTHENTICATE за механизма  
от поколение  1 за удостоверяване  на автентичността . 
Забележка  За ключове  за сесия  от поколение  2 вж. 
допълнение  11, раздели  CSM_193 и CSM_195. Ако 
бъдат  установени  ключове  за сесия  от поколение  2 и 
тахографската  карта  получи  обикновена  APDU за 
командата  INTERNAL AUTHENTICATE, тя прекратява  
създаването  на сесия  за защитен  обмен  на съобщения  
от поколение  2 и унищожава  ключовете  за сесия  от 
поколение  2. 
▼B 
3.5.9  EXTERNAL AUTHENTICATE  
Тази  команда  е в съответствие  със стандарта  ISO/IEC 7816-4.  
Чрез  командата  EXTERNAL AUTHENTICATE картата  може  да 
удостовери  автентичността  на IFD. Процесът  на удостоверяване  е 
описан  в допълнение  11 за Tachograph G1 и G2 (удостоверяване  
на автентичността  на VU, т.е. на бордовото  устройство ). 
TCS_96 Вариантът  на командата  за механизма  от поколение  1 
за взаимно  удостоверяване  се поддържа  само  от тахог­  
рафско  приложение  от поколение  1. 
▼M1 
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. 
▼B 
TCS_98  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  CLA  
INS 1  ‘82h’  INS  
P1 1  ‘00h’  Ключове  и алгоритми , известни  по подразбиране  
P2 1  ‘00h’  
Lc 1  ‘XXh’  Lc ( дължина  на данните , изпратени  на картата ) 
#6-#(5+L)  L  ‘XX..XXh’  Удостоверяване  от поколение  1: криптограма  (виж 
допълнение  11, част А) 
Удостоверяване  от поколение  2: подпис , генериран  
от IFD (виж допълнение  11, част Б) ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 221  
TCS_99  Ответно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— Ако CHA на избрания  публичен  ключ  не съот­  
ветства  на конкатенацията  на AID на тахографското  
приложение  с данните  за типа  оборудване  на 
бордовото  устройство  (VU equipment Type), за 
състоянието  на обработката  се връща  ‘6F00 ’. 
— Ако командата  не е непосредствено  предшествана  
от команда  GET CHALLENGE, за състоянието  на 
обработката  се връща  ‘6985 ’. 
Тахографското  приложение  от поколение  1 може  да 
върне  следните  допълнителни  кодове  за грешка : 
— Ако не е наличен  публичен  ключ  в средата , 
свързана  със защитата  от неоторизиран  достъп , се 
връща  ‘6A88 ’. 
— Ако не е наличен  частен  ключ  в средата , свързана  
със защитата  от неоторизиран  достъп , за 
състоянието  на обработката  се връща  ‘6A88 ’. 
— Ако проверката  на криптограмата  е неуспешна , за 
състоянието  на обработката  се връща  ‘6688 ’. 
— Ако избраният  частен  ключ  се счита  за повреден ,, за 
състоянието  на обработката  се връща  ‘6400 ’ или 
‘6581 ’. 
Вариантът  на командата  за удостоверяване  от 
поколение  2 може  да върне  следния  допълнителен  код 
за грешка : 
— Ако проверката  на подписа  е неуспешна , картата  
връща  ‘6300 ’. 
3.5.10  GENERAL AUTHENTICATE  
Тази  команда  се използва  при протокола  от поколение  2 за удос­  
товеряване  автентичността  на чип съгласно  допълнение  11, част Б 
и е в съответствие  със стандарта  ISO/IEC 7816-4.  
TCS_100 Командата  може  да бъде  изпълнена  в MF, DF 
Tachograph и DF Tachograph_G2, виж също  TCS_34.  
TCS_101  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  
INS 1  ‘86h’  
P1 1  ‘00h’  Ключове  и протокол , известни  по подразбиране  
P2 1  ‘00h’  
Lc 1  ‘NNh’  Lc: дължина  на последващото  поле  за данни  
#6-#(5+L)  L  ‘7Ch’ + L  7C + 
‘80h’ + L  80 + 
‘XX..XXh’  Стойност  на краткотраен  публичен  ключ , кодиран  
по DER-TLV ( виж допълнение  11) 
VU изпраща  обектите  от данни  в тази последова­  
телност . 
▼M1 
5 + L + 1  1  ‘00h’  Съгласно  стандарта  ISO/IEC 7816-4  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 222  
TCS_102  Ответно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
#1-#L  L  ‘7Ch’ + L  7C + ‘81h’ 
+ ‘08h’ + ‘XX..XXh’ 
+ ‘82h’ + L  82 + 
‘XX..XXh’  Кодирани  по DER-TLV данни  за динамично  
удостоверяване : еднократен  код (nonce) и 
маркер  за удостоверяване  на автентичността  
(виж допълнение  11) 
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— Картата  връща  ‘6A80 ’, за да укаже  за неправилни  
параметри  в полето  за данни . 
— Картата  връща  ‘6982 ’, ако командата  External 
Authenticate не е била  изпълнена  успешно . 
Ответният  обект  Dynamic Authentication Data ‘7Ch’:  
— трябва  да е наличен , ако операцията  е била  
успешна , т.е. байтовете  за състоянието  са ‘9000 ’; 
— трябва  да отсъства  в случай  на грешка  при изпъл­  
нението  или при проверката , т.е. ако байтовете  за 
състоянието  са в интервала  ‘6400 ’ — ‘ 6FFF ’, и 
— може  да отсъства  в случай  на предупреждение , т.е. 
ако байтовете  за състоянието  са в интервала  ‘6200 ’ 
— ‘63FF ’. 
3.5.11  MANAGE SECURITY ENVIRONMENT  
Тази  команда  служи  за определяне  на публичен  ключ  за целите  
на удостоверяването  на автентичността . 
3.5.11.1 Д в о й к а к о м а н д а — о т г о в о р о т п о к о л е н и е 1 
Тази  команда  е в съответствие  със стандарта  ISO/IEC 7816-4. 
Нейното  използване  е по-ограничено , отколкото  съгласно  
въпросния  стандарт . 
TCS_103 Тази  команда  се поддържа  само  от тахографско  
приложение  от поколение  1. 
TCS_104 Ключът , указан  в полето  за данни  MSE, остава  активен  
публичен  ключ  до следващата  правилна  команда  MSE, 
селектиране  на DF или инициализиране  на картата . 
TCS_105 Ако указаният  ключ  не е (вече) наличен  в паметта  на 
картата , средата , свързана  със защитата  от 
неоторизиран  достъп , остава  непроменена . 
TCS_106  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  CLA  
INS 1  ‘22h’  INS  
P1 1  ‘C1h’  P1: указан  ключ , който  е валиден  за всички  криптог­  
рафски  операции  
P2 1  ‘B6h’  P2 ( указани  данни , отнасящи  се до цифровия  подпис ) 
Lc 1  ‘0Ah’  Lc: дължина  на последващото  поле  за данни  
#6 1  ‘83h’  Таг, указващ  публичен  ключ  в случаи  на асиметрия  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 223  
Байт  Дължи­  
на Стойност  Описание  
#7 1  ‘08h’  Дължина  на указанието  за ключа  (идентификатора  на 
ключа ) 
#8-#15  8  ‘XX..XXh’  Идентификатор  на ключ  съгласно  допълнение  11 
TCS_107  Ответно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— Ако указаният  ключ  не е наличен  в паметта  на 
картата , за състоянието  на обработката  се връща  
‘6A88 ’. 
— Ако някои  очаквани  обекти  от данни  липсват  във 
формата  за защитен  от неоторизиран  достъп  обмен  
на съобщения , за състоянието  на обработката  се 
връща  ‘6987 ’. Това  може  да се случи , ако липсва  
тагът  ‘83h’.  
— Ако някои  обекти  от данни  са неправилни , за 
състоянието  на обработката  се връща  ‘6988 ’. Това  
може  да се случи , ако дължината  на идентифи­  
катора  на ключа  не е ‘08h’.  
— Ако избраният  ключ  се счита  за повреден , за 
състоянието  на обработката  се връща  ‘6400 ’ или 
‘6581 ’. 
3.5.11.2 Д в о й к и к о м а н д а — о т г о в о р о т п о к о л е н и е 2 
За удостоверяването  от поколение  2 тахографската  карта  
поддържа  следните  версии  на командата  MSE: Set, които  са в 
съответствие  със стандарта  ISO/IEC 7816-4. Тези  версии  на 
командата  не се поддържат  от удостоверяването  от поколение  1. 
3.5.11.2.1 M S E : S E T A T з а у д о с т о в е р я в а н е а в т е н т и ч н о с т т а 
н а ч и п а 
Следната  команда  MSE:SET AT се използва  за избор  на пара­  
метрите  за удостоверяване  автентичността  на чипа  (Chip Authen ­
tication), което  се извършва  от последващата  команда  General 
Authenticate.  
TCS_108 Командата  може  да бъде  изпълнена  в MF, DF 
Tachograph и DF Tachograph_G2, виж също  TCS_34.  
TCS_109  Командно  съобщение  MSE:SET AT за удостове­  
ряване  автентичността  на чипа  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  
INS 1  ‘22h’  
P1 1  ‘41h’  Зададена  за вътрешно  удостоверяване  на автентич­  
ността  
P2 1  ‘A4h’  Удостоверяване  на автентичността  
Lc 1  ‘NNh’  Lc: дължина  на последващото  поле  за данни  
#6-#(5+L)  L  ‘80h’ + ‘0Ah’ 
+ ‘XX..XXh’  Кодирано  по DER-TLV указание  към криптографския  
механизъм : идентификатор  на обекта  за удостове­  
ряване  автентичността  на чипа  (само  стойност , 
тагът  ‘06h’ се изпуска ). 
Виж  допълнение  1 за стойностите  на идентифика­  
торите  на обекти ; трябва  да се използва  обознача­  
ването  по байтове . Виж  допълнение  11 за указания  
относно  това как да се избере  един  от тези иденти­  
фикатори  на обекти . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 224  
3.5.11.2.2 M S E : S E T A T з а у д о с т о в е р я в а н е а в т е н т и ч н о с т т а 
н а б о р д о в о т о у с т р о й с т в о ( V U )  
Следната  команда  MSE:SET AT се използва  за избор  на пара­  
метрите  и ключовете  за удостоверяване  автентичността  на 
бордовото  устройство  (VU Authentication), което  се извършва  от 
последващата  команда  External Authenticate.  
TCS_110 Командата  може  да бъде  изпълнена  в MF, DF 
Tachograph и DF Tachograph_G2, виж също  TCS_34.  
TCS_111  Командно  съобщение  MSE:SET AT за удостове­  
ряване  автентичността  на VU  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  
INS 1  ‘22h’  
P1 1  ‘81h’  Зададена  за външно  удостоверяване  на автентич­  
ността  
P2 1  ‘A4h’  Удостоверяване  на автентичността  
Lc 1  ‘NNh’  Lc: дължина  на последващото  поле  за данни  
#6-#(5+L)  L  ‘80h’ + ‘0Ah’ 
+ ‘XX..XXh’  Кодирано  по DER-TLV указание  към криптографския  
механизъм : идентификатор  на обекта  за удостове­  
ряване  автентичността  на VU (само  стойност , тагът  
‘06h’ се изпуска ). 
Виж  допълнение  1 за стойностите  на идентифика­  
торите  на обекти ; трябва  да се използва  обознача­  
ването  по байтове . Виж  допълнение  11 за указания  
относно  това как да се избере  един  от тези иденти­  
фикатори  на обекти . 
‘83h’ + ‘08h’ 
+ ‘XX..XXh’  Кодирано  по DER-TLV указание  за публичния  ключ  
на VU чрез указанието  за титуляря  на сертификата  
(Certificate Holder Reference), посочено  в този серти­  
фикат . 
‘91h’ + L  91 + 
‘XX..XXh’  Кодирано  по DER-TLV компресирано  представяне  на 
краткотрайния  публичен  ключ  на VU, който  ще се 
използва  по време  на удостоверяването  на автентич­  
ността  на чипа  (виж допълнение  11) 
3.5.11.2.3 M S E : S E T D S T  
Следната  команда  MSE:SET DST се използва  за установяването  
на публичен  ключ  или 
— за проверка  на подпис , който  се предоставя  в последваща  
команда  PSO: Verify Digital Signature, или 
— за проверка  по подпис  на сертификат , който  се предоставя  в 
последваща  команда  PSO: Verify Certificate  
TCS_112 Тази  команда  може  да бъде  изпълнена  в MF, DF 
Tachograph и DF Tachograph_G2, виж също  TCS_33.  
TCS_113  Командно  съобщение  MSE:SET DST  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  
INS 1  ‘22h’  
P1 1  ‘81h’  Установяване  за проверка  
P2 1  ‘B6h’  Цифров  подпис  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 225  
Байт  Дължи­  
на Стойност  Описание  
Lc 1  ‘NNh’  Lc: дължина  на последващото  поле  за данни  
#6-#(5+L)  L  ‘83h’ + ‘08h’ 
+ ‘XX...XXh’  Кодирано  по DER-TLV указание  за публичен  ключ , 
т.е. указание  за титуляря  на сертификата  (Certificate 
Holder Reference) в сертификата  на публичния  ключ  
(виж допълнение  11) 
За всички  версии  на командата  структурата  и байтовете  за 
състоянието  на ответното  съобщение  се дават  от: 
TCS_114  Ответно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. Протоколът  е избран  и активиран . 
— ‘6A80 ’ сочи  неправилни  параметри  в полето  за 
данни  на командата . 
— ‘6A88 ’ сочи , че указаните  данни  (т.е. указан  ключ ) 
не са налични . 
▼M1 
— Ако currentAuthenticatedTime на картата  е по-късно  
от датата , на която  изтича  срокът  на валидност  на 
избрания  публичен  ключ , за състоянието  на обра­  
ботката  се връща  ‘6A88’ . 
Забележка : Ако за командата  за удостоверяване  на 
автентичността  на бордовото  устройство  (VU Authenti ­
cation) се използва  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.  
▼B 
3.5.12  PSO: HASH  
Тази  команда  се използва  за прехвърляне  към картата  на 
резултата  от изчисляването  на хеш-стойността  за някои  данни . 
Тази  команда  служи  за проверката  на цифрови  подписи . Хеш - 
стойността  се съхранява  временно  за последващата  команда  
PSO: Verify Digital Signature.  
Тази  команда  е в съответствие  със стандарта  ISO/IEC 7816-8. 
Нейното  използване  е по-ограничено , отколкото  съгласно  
въпросния  стандарт . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 226  
Само  за контролната  карта  се изисква  да поддържа  тази команда  
в DF Tachograph и DF Tachograph_G2.  
Другите  видове  тахографски  карти  могат  или не могат  да 
изпълняват  тази команда . Тази  команда  може  или не може  да е 
достъпна  в MF.  
Приложението  от поколение  1 за контролната  карта  поддържа  
само  SHA-1.  
TCS_115 Временно  съхранената  хеш-стойност  се заличава , ако 
бъде  изчислена  нова  хеш-стойност  посредством  
командата  PSO: HASH, ако бъде  селектиран  DF и ако 
тахографската  карта  бъде  инициализирана . 
TCS_116  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  CLA  
INS 1  ‘2Ah’  Извършване  на операция , свързана  със защитата  от 
неоторизиран  достъп  
P1 1  ‘90h’  Връщане  на хеш-кода  
P2 1  ‘A0h’  Таг: поле  за данни , съдържащо  съответните  обекти  от 
данни  (DO) за хеширането  
Lc 1  ‘XXh’  Дължина  Lc на последващото  поле  за данни  
#6 1  ‘90h’  Таг за хеш-кода  
#7 1  ‘XXh’  Дължина  L на хеш-кода : 
‘14h’ в приложение  от поколение  1 (виж допълнение  
11, част А) 
‘20h’, ‘30h’ или ‘40h’ в приложение  от поколение  2 
(виж допълнение  11, част Б) 
#8-#(7+L)  L  ‘XX..XXh’  Хеш -код 
TCS_117  Ответно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— Ако някои  очаквани  обекти  от данни  (както  е 
определено  по-горе) липсват , за състоянието  на 
обработката  се връща  ‘6987 ’ Това  може  да се 
случи , ако един  от таговете  ‘90h’ липсва . 
— Ако някои  обекти  от данни  са неправилни , за 
състоянието  на обработката  се връща  ‘6988 ’. Тази  
грешка  възниква , ако изискваният  таг е наличен , но 
неговата  дължина  се различава  от ‘14h’ за SHA-1, 
‘20h’ за SHA-256, ‘30h’ за SHA-384 и ‘40h’ за SHA- 
512 (за приложение  от поколение  2). 
3.5.13  PERFORM HASH of FILE  
Тази  команда  не е в съответствие  със стандарта  ISO/IEC 7816-8. 
Поради  това байтът  CLA на тази команда  указва , че е налице  
частно  използване  на PERFORM SECURITY OPERATION / 
HASH.  
Само  за картата  на водач  и за контролната  карта  се изисква  да 
поддържат  тази команда  в DF Tachograph и DF Tachograph_G2.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 227  
Другите  видове  тахографски  карти  могат  или не могат  да 
изпълняват  тази команда . Ако карта  на превозвач  или 
контролна  карта  изпълнява  тази команда , това трябва  да става , 
както  е определено  в настоящата  глава . 
Тази  команда  може  или не може  да е достъпна  в MF. Ако 
командата  е достъпна , тя се изпълнява , както  е определено  в 
настоящата  глава , т.е. не позволява  изчисляването  на хеш- 
стойност , а се прекратява  с подходящ  код за грешка . 
TCS_118 Командата  PERFORM HASH of FILE се използва  за 
хеширане  на зоната  за данни  на селектирания  
елементарен  файл  (EF) с прозрачна  структура . 
TCS_119 Тахографската  карта  поддържа  тази команда  само  за 
EF, които  са изброени  в глава  4 в рамките  на DF_Tac­
hograph и DF_Tachograph_G2, със следното  изклю­  
чение . Тахографската  карта  не трябва  да поддържа  
командата  за елементарния  файл  Sensor_Installati ­
on_Data на DF Tachograph_G2.  
TCS_120 Резултатът  от операцията  по хеширане  се съхранява  
временно  в картата . След  това тя може  да се 
използва , за да се получи  цифров  подпис  за файла  
посредством  командата  PSO: COMPUTE DIGITAL 
SIGNATURE.  
▼M1 
TCS_121 Временно  съхраняваната  хеш-стойност  на файла  се 
заличава , ако бъде  изчислена  нова  хеш-стойност  на 
файла  посредством  командата  PERFORM HASH of 
FILE, ако бъде  избран  DF и ако тахографската  карта  
бъде  инициализирана . 
▼B 
TCS_122 Тахографското  приложение  от поколение  1 трябва  да 
поддържа  SHA-1.  
▼M1 
TCS_123 Тахографското  приложение  от поколение  2 трябва  да 
поддържа  алгоритъма  SHA-2 (SHA-256, SHA-384 или 
SHA-512), посочен  в криптографската  поредица  в 
допълнение  11, част Б, за ключа  за подпис  на картата  
Card_Sign.  
▼B 
TCS_124  Командно  съобщение  
▼M1 
Байт  Дължи­  
на Стойност  Описание  
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  
▼B 
TCS_125  Ответно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— Ако активният  EF не позволява  тази команда  (EF 
Sensor_Installation_Data в DF Tachograph_G2), за 
състоянието  на обработката  се връща  ‘6985 ’. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 228  
— Ако селектираният  EF се счита  за повреден  (открита  
е грешка  в цялостността  на атрибутите  на файла  или 
в съхранените  в него  данни ), за състоянието  на 
обработката  се връща  ‘6400 ’ или ‘6581 ’. 
— Ако селектираният  файл  не е с прозрачна  структура  
или ако няма  активен  EF, за състоянието  на обра­  
ботката  се връща  ‘6986 ’. 
3.5.14  PSO: COMPUTE DIGITAL SIGNATURE  
▼M1 
Тази  команда  служи  за изчисляване  на цифровия  подпис  на 
изчислен  преди  това хеш-код (вж. PERFORM HASH of FILE, 
точка  3.5.13).  
Само  за картата  на водач  и за картата  за монтаж  и настройки  се 
изисква  да поддържат  тази команда  в DF Tachograph и DF 
Tachograph_G2.  
Другите  видове  тахографски  карти  могат  или не могат  да 
изпълняват  тази команда . При тахографското  приложение  от 
поколение  2 само  картата  на водач  и картата  за монтаж  и 
настройки  имат  ключ  за подпис  от поколение  2; другите  карти  
не могат  успешно  да изпълнят  командата  и прекратяват  изпъл­  
нението  с подходящ  код за грешка . 
Тази  команда  може  да е или да не е достъпна  в MF. Ако 
командата  не е достъпна  в MF, нейното  изпълнение  се прекратява  
с подходящ  код за грешка . 
Тази  команда  е в съответствие  със стандарт  ISO/IEC 7816-8. 
Нейното  използване  е по-ограничено , отколкото  съгласно  
посочения  стандарт . 
▼B 
TCS_126 Тази  команда  не изчислява  цифров  подпис  за изчислен  
преди  това хеш-код с командата  PSO: HASH.  
TCS_127 За изчисляване  на цифровия  подпис  се използва  
частния  ключ  на картата , на която  той е известен  по 
подразбиране . 
TCS_128 Тахографското  приложение  от поколение  1 изпълнява  
цифров  подпис , като използва  метод  на запълване  в 
съответствие  с PKCS1 (виж в допълнение  11 за подроб­  
ности ). 
TCS_129 Тахографското  приложение  от поколение  2 изчислява  
цифров  подпис  въз основа  на елиптична  крива  (виж 
допълнение  11 за подробности ). 
TCS_130  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  CLA  
INS 1  ‘2Ah’  Извършване  на операция , свързана  със защитата  от 
неоторизиран  достъп  
P1 1  ‘9Eh’  Цифров  подпис , който  трябва  да се върне  
P2 1  ‘9Ah’  Таг: поле  за данни  съдържащо  данните , които  трябва  
да се подпишат . Тъй като не е включено  поле  за 
данни , се приема , че данните  вече са налични  в 
картата  (хеширане  на файла ) 
Le 1  ‘NNh’  Дължина  на очаквания  подпис  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 229  
TCS_131  Ответно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
#1-#L  L  ‘XX..XXh’  Подпис  за изчисленото  преди  това хеширане  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— Ако избраният  по подразбиране  частен  ключ  се 
счита  за повреден , за състоянието  на обработката  
се връща  ‘6400 ’ или ‘6581 ’. 
— Ако хеширането , изчислено  с предходна  команда  
Perform Hash of File не е налично , за състоянието  
на обработката  се връща  ‘6985 ’. 
3.5.15  PSO: VERIFY DIGITAL SIGNATURE  
Тази  команда  служи  за проверка  на въведения  цифров  подпис , 
чието  хеширане  е известно  на картата . Алгоритъмът  на подписа  е 
известен  по подразбиране  на картата . 
Тази  команда  е в съответствие  със стандарта  ISO/IEC 7816-8. 
Нейното  използване  е по-ограничено , отколкото  съгласно  
въпросния  стандарт . 
Само  за контролната  карта  се изисква  да поддържа  тази команда  
в DF Tachograph и DF Tachograph_G2.  
Другите  видове  тахографски  карти  могат  или не могат  да 
изпълняват  тази команда . Тази  команда  може  или не може  да е 
достъпна  в MF.  
TCS_132 Командата  VERIFY DIGITAL SIGNATURE използва  
винаги  публичния  ключ , избран  посредством  пред­  
ходната  команда  Manage Security Environment MSE: 
Set DST, и предишния  хеш-код, въведен  с команда  
PSO: HASH.  
TCS_133  Командно  съобщение  
▼M1 
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘00h’  CLA  
INS 1  ‘2Ah’  Извършване  на операция , свързана  със защитата  от 
неразрешен  достъп  
P1 1  ‘00h’  
P2 1  ‘A8h’  Таг: поле  за данни , съдържащо  съответните  обекти  от 
данни  (DO) за проверката  
Lc 1  ‘XXh’  Дължина  Lc на последващото  поле  за данни  
#6 1  ‘9Eh’  Таг за цифров  подпис  
#7 или 
#7-#8  L ‘NNh’ или 
‘81 NNh’  Дължина  на цифровия  подпис  (L е 2 байта , ако 
цифровият  подпис  е по-дълъг  от 127 байта ): 
128 байта , кодирани  в съответствие  с допълнение  11, 
част А за тахографско  приложение  от поколение  1. 
В зависимост  от избраната  крива  за тахографско  
приложение  от поколение  2 (вж. допълнение  11, 
част Б). 
#(7+L)- 
#(6+L+NN)  NN ‘XX..XXh’  Съдържание  на цифровия  подпис  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 230  
TCS_134  Ответно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— Ако проверката  на подписа  е неуспешна , за 
състоянието  на обработката  се връща  ‘6688 ’. 
Процесът  на проверка  е описан  подробно  в 
допълнение  11. 
— Ако не е избран  публичен  ключ , за състоянието  на 
обработката  се връща  ‘6A88 ’. 
— Ако някои  очаквани  обекти  от данни  (както  е 
определено  по-горе) липсват , за състоянието  на 
обработката  се връща  ‘6987 ’ Това  може  да стане , 
ако липсва  един  от изискваните  тагове . 
— Ако не е наличен  хеш-код за изпълнение  на 
командата  (в резултат  на предходна  команда  PSO: 
Hash), за състоянието  на обработката  се връща  
‘6985 ’. 
— Ако някои  обекти  от данни  са неправилни , за 
състоянието  на обработката  се връща  ‘6988 ’. Това  
може  да се случи , ако дължината  на някой  от изиск­  
ваните  обекти  от данни  е неправилна . 
— Ако избраният  публичен  ключ  се счита  за повреден , 
за състоянието  на обработката  се връща  ‘6400 ’ или 
‘6581 ’. 
▼M1 
— Ако избраният  публичен  ключ  (използван  за 
проверка  на въведения  цифров  подпис ) има 
CHA.LSB (CertificateHolderAuthorisation.equipmen ­
tType), който  не е подходящ  за проверка  на 
цифровия  подпис  съгласно  допълнение  11, за 
състоянието  на обработката  се връща  ‘6985 ’. 
▼B 
3.5.16  PROCESS DSRC MESSAGE  
Тази  команда  служи  за проверка  на цялостността  и автентич­  
ността  на съобщения  по специализирана  връзка  с малък  обсег  
на действие  („DSRC съобщения “) и за дешифриране  на данните , 
съобщени  от VU на контролен  орган  или сервиз  по такава  връзка . 
Картата  извлича  криптографския  ключ  и MAC ключовете , 
използвани  за защитата  на DSRC съобщението  от неоторизиран  
достъп , както  е описано  в допълнение  11, част Б, глава  13. 
Само  за контролната  карта  и картата  за монтаж  и настройки  се 
изисква  да поддържат  тази команда  в DF Tachograph_G2.  
Другите  видове  тахографски  карти  могат  или не могат  да 
изпълняват  тази команда , но не трябва  да имат  главен  ключ  за 
DSRC съобщения . Поради  това тези карти  не могат  да изпълняват  
командата  успешно , а прекратяват  изпълнението  с подходящ  код 
за грешка . 
Тази  команда  може  или не може  да е достъпна  в MF и/или DF 
Tachograph. Ако командата  е достъпна , нейното  изпълнение  се 
прекратява  с подходящ  код за грешка . 
TCS_135 Главният  ключ  за DSRC съобщения  е достъпен  само  в 
DF Tachograph_G2, т.е. контролната  карта  и картата  за 
монтаж  и настройки  трябва  да поддържат  успешното  
изпълнение  на командата  само  в DF Tachograph_G2.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 231  
TCS_136 Командата  само  декриптира  DSRC данните  и проверява  
криптографската  контролна  сума , но не интерпретира  
входящите  данни . 
TCS_137 Последователността  на обектите  от данни  в полето  за 
данни  на командата  е неизменна  и се определя  от 
настоящата  спецификация . 
TCS_138  Командно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
CLA  1  ‘80h’  Собствен  CLA  
INS 1  ‘2Ah’  Извършване  на операция , свързана  със защитата  от 
неоторизиран  достъп  
P1 1  ‘80h’  Данни  за отговора : проста  стойност  
P2 1  ‘B0h’  Данни  за командата : проста  стойност , кодирана  по 
BER-TLV и включваща  обекти  от данни  (DO) със 
защитен  обмен  на съобщения  (SM)  
Lc 1  ‘NNh’  Дължина  Lc на последващото  поле  за данни  
#6-#(5+L)  L  ‘87h’ + L  87 + 
‘XX..XXh’  Кодиран  по DER-TLV указателен  байт  за запъл­  
ващото  съдържание , последван  от криптирани  
данни  за натоварването  на тахографа . Указателният  
байт  за запълващото  съдържание  трябва  да бъде  със 
стойност  ‘00h’ (‘no further indication’, т.е. „без допъл­  
нително  указване “, съгласно  ISO/IEC 7816-4:2013, 
таблица  52). За механизма  за криптиране  виж 
допълнение  11, част Б, глава  13. 
Позволени  стойности  за дължината  L 87 са кратните  
на дължината  на AES блока  плюс  1 за указателния  
байт  за запълващото  съдържание , т.е. от 17 байта  до 
193 байта  включително . 
Забележка : виж ISO/IEC 7816-4:2013, таблица  49 за 
обекта  от данни  със защитен  обмен  на съобщения  с 
таг ‘87h’.  
‘81h’ + ‘10h’  Кодирано  по DER-TLV вместване  съгласно  стан­  
дартния  модел  за контрол  с оглед  на поверителността  
(Control Reference Template for Confidentiality) на 
конкатенацията  на следните  елементи  на данните  
(виж допълнение  1 DSRCSecurityData и допълнение  
11, част Б, глава  13): 
— времеви  печат  от 4 байта  
— брояч  от 3 байта  
— сериен  номер  на VU от 8 байта  
— версия  от 1 байт  на главния  ключ  за DSRC 
съобщения  
Забележка : виж ISO/IEC 7816-4:2013, таблица  49 за 
обекта  от данни  със защитен  обмен  на съобщения  с 
таг ‘81h’.  
‘8Eh’ + L  8E + 
‘XX..XXh’  Кодиран  по DER-TLV MAC за DSRC съобщението . 
За алгоритъма  за MAC и неговото  изчисляване  виж 
допълнение  11, част Б, глава  13. 
Забележка : виж ISO/IEC 7816-4:2013, таблица  49 за 
обекта  от данни  със защитен  обмен  на съобщения  с 
таг ‘8Eh’.  
▼M1 
5 + L + 1  1  ‘00h’  Съгласно  стандарта  ISO/IEC 7816-4  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 232  
TCS_139  Ответно  съобщение  
Байт  Дължи­  
на Стойност  Описание  
#1-#L  L  ‘XX..XXh’  Отсъства  (в случай  на грешка ) или дешифрирани  
данни  (запълването  е отстранено ) 
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , картата  
връща  ‘9000 ’. 
— ‘6A80 ’ указва  за неправилни  параметри  в полето  за 
данни  на командата , (използва  се и когато  обектите  
от данни  не са изпратени  в определената  последова­  
телност ). 
— ‘6A88 ’ сочи , че указаните  данни , т.е. указаният  
главен  ключ  за DSRC съобщения , не са налични . 
— ‘6900 ’ указва , че проверката  на криптографската  
контролна  сума  или на описанието  на данните  не 
е била  успешна . 
▼M1 
— ‘6985 ’ указва , че времевият  печат  от 4 байта , 
посочен  в полето  за данни  на командата , е по- 
ранен  от cardValidityBegin или по-късен  от cardEx­
piryDate.  
▼B 
4. СТРУКТУРА  НА ТАХОГРАФСКИТЕ  КАРТИ  
В настоящата  глава  се определя  структурата  на файловете  в 
тахографските  карти  за съхраняване  на достъпните  данни . 
Не се определя  вътрешната  структура , която  зависи  от произво­  
дителя  от картата  — например  заглавната  част на файла , нито  
съхраняването  и обработването  на необходимите  само  
за вътрешна  употреба  елементи  на данните  — например
  
,
 ,
  или
 
. 
TCS_140 Тахографската  карта  от поколение  2 трябва  да съдържа  
главния  файл  (MF) и тахографско  приложение  от 
поколение  1 и от поколение  2 от същия  вид 
(например  приложение  за карта  на водач ). 
TCS_141 Тахографската  карта  трябва  да поддържа  поне  мини­  
малния  брой  записи , определен  за съответните  прило­  
жения , и да поддържа  не повече  от максималния  брой  
записи , определен  за съответните  приложения . 
Максималният  и минималният  брой  на записите  за 
различните  приложения  са определени  в настоящата  
глава . 
Условията  за сигурност , използвани  в правилата  за 
достъп  в рамките  на тази глава , са посочени  в глава  
3.3. По принцип  режимът  на достъп  „Четене “ („Read“) 
означава  командата  READ BINARY с четен  и, ако се 
поддържа , нечетен  байт  INS — с изключение  на 
елементарния  файл  (EF) Sensor_Installation_Data на 
картата  за монтаж  и настройки , виж TCS_156 и 
TCS_160. Режимът  на достъп  „Актуализация “ („Up­
date“) означава  командата  READ BINARY с четен  и, 
ако се поддържа , нечетен  байт  INS, а режимът  на 
достъп  „Селектиране “ („Select“) — командата  SELECT.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 233  
4.1. Главен  файл  (MF)  
TCS_142 След  персонализирането  на главния  файл  (MF) той 
трябва  да е със следната  постоянна  файлова  структура  
и правила  за достъп  до файловете : 
Забележка : краткият  идентификатор  на EF (SFID) се 
дава като десетично  число  — например  стойността  30 
съответства  на 11110 в двоичната  бройна  система .
 
В тази таблица  се използва  следното  съкращение  за 
условието  за сигурност : 
SC1 ALW ИЛИ  SM-MAC-G2  
TCS_143 Структурите  на всички  EF трябва  да бъдат  прозрачни . 
TCS_144 Главният  файл  (MF) трябва  да е със следната  структура  
на данните :
 
TCS_145 Елементарният  файл  EF DIR трябва  да съдържа  
следните  обекти  от данни , свързани  с приложението : 
‘61 08 4F 06 FF 54 41 43 48 4F 61 08 4F 06 FF 53 
4D 52 44 54’  
TCS_146 Елементарният  файл  EF ATR/INFO трябва  да е 
наличен , ако тахографската  карта  указва  в своя  ATR, 
че поддържа  полета  с увеличена  дължина . В този 
случай  EF ATR/INFO трябва  да съдържа  обекта  от 
данни  с увеличена  дължина  (DO‘7F66’), определен  в 
ISO/IEC 7816-4:2013, клауза  12.7.1.  
TCS_147 Елементарният  файл  EF Extended_Length трябва  да е 
наличен , ако тахографската  карта  указва  в своя  ATR, 
че поддържа  полета  с увеличена  дължина . В този 
случай  EF трябва  да съдържа  следния  обект  от данни : 
‘02 01 xx’ където  стойността  ‘xx’ указва  дали  за 
протокола  T = 1 и / или T = 0 се поддържат  полета  с 
увеличена  дължина . 
Стойността  ‘01’ указва , че за протокола  T = 1 се 
поддържат  полета  с увеличена  дължина . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 234  
Стойността  ‘10’ указва , че за протокола  T = 0 се 
поддържат  полета  с увеличена  дължина . 
Стойността  ‘11’ указва , че за протоколите  T = 1 и T = 0 
се поддържат  полета  с увеличена  дължина . 
4.2. Приложения  за картата  на водач  
4.2.1  Приложение  от поколение  1 за картата  на водач  
TCS_148 След  персонализирането  на приложението  от поколение  
1 за картата  на водач  то трябва  да е със следната  
постоянна  файлова  структура  и правила  за достъп  до 
файловете :
 
В тази таблица  се използват  следните  съкращения  за 
условията  за сигурност : 
SC1 ALW ИЛИ  SM-MAC-G2  
SC2 ALW ИЛИ  SM-MAC-G1 ИЛИ  SM-MAC-G2  
SC3 SM-MAC-G1 ИЛИ  SM-MAC-G2  
TCS_149 Структурите  на всички  EF трябва  да бъдат  прозрачни . 
TCS_150 Приложението  от поколение  1 за картата  на водач  
трябва  да е със следната  структура  на данните : ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 235
  
▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 236
  
▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 237  
TCS_151 Следните  стойности , използвани  за указване  на размери  
в таблицата  по-горе, определят  минималния  и макси­  
малния  брой  на записите , който  трябва  да се използва  
за приложение  от поколение  1 в структурата  на данните  
в картата  на водача :
 
4.2.2  Приложение  от поколение  2 за картата  на водача  
TCS_152 След  персонализирането  на приложението  от поколение  
2 за картата  на водача  то трябва  да е със следната  
постоянна  файлова  структура  и правила  за достъп  до 
файловете : 
Забележка : краткият  идентификатор  на EF (SFID) се 
дава като десетично  число  — например  стойността  30 
съответства  на 11110 в двоичната  бройна  система .
 
В тази таблица  се използва  следното  съкращение  за 
условието  за сигурност : 
SC1 ALW ИЛИ  SM-MAC-G2  
TCS_153 Структурите  на всички  EF трябва  да бъдат  прозрачни . 
TCS_154 Приложението  от поколение  2 за картата  на водача  
трябва  да е със следната  структура  на данните : ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 238
  
► (1) M1 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 239
  
▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 240
  
► (1) M1 
TCS_155 Следните  стойности , използвани  за указване  на размери  
в таблицата  по-горе, определят  минималния  и макси­  
малния  брой  на записите , който  трябва  да се използва  
за приложение  от поколение  2 в структурата  на данните  
в картата  на водача :
 
► (1) M1 
4.3. Приложения  за картата  за монтаж  и настройки  
4.3.1  Приложение  от поколение  1 за картата  за монтаж  и 
настройки  
TCS_156 След  персонализирането  на приложението  от поколение  
1 за картата  за монтаж  и настройки  то трябва  да е със 
следната  постоянна  файлова  структура  и правила  за 
достъп  до файловете : ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 241
  
В тази таблица  се използват  следните  съкращения  за 
условията  за сигурност : 
SC1 ALW ИЛИ  SM-MAC-G2  
SC2 ALW ИЛИ  SM-MAC-G1 ИЛИ  SM-MAC-G2  
SC3 SM-MAC-G1 ИЛИ  SM-MAC-G2  
▼M1 
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  
▼B 
TCS_157 Структурите  на всички  EF трябва  да бъдат  прозрачни . 
TCS_158 Приложението  от поколение  1 за картата  за монтаж  и 
настройки  трябва  да е със следната  структура  на 
данните : ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 242
  
▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 243
  
▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 244
  
TCS_159 Следните  стойности , използвани  за указване  на размери  
в таблицата  по-горе, определят  минималния  и макси­  
малния  брой  на записите , който  трябва  да се използва  
за приложение  от поколение  1 в структурата  на данните  
в картата  за монтаж  и настройки :
 
4.3.2  Приложение  от поколение  2 за картата  за монтаж  и 
настройки  
TCS_160 След  персонализирането  на приложението  от поколение  
2 за картата  за монтаж  и настройки  то трябва  да е със 
следната  постоянна  файлова  структура  и правила  за 
достъп  до файловете : 
Забележка : краткият  идентификатор  на EF (SFID) се 
дава като десетично  число  — например  стойността  30 
съответства  на 11110 в двоичната  бройна  система .
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 245  
В тази таблица  се използват  следните  съкращения  за 
условията  за сигурност : 
SC1 ALW ИЛИ  SM-MAC-G2  
SC 5  За командата  Read Binary с четен  байт  INS: SM- 
C-MAC-G2 И SM-R-ENC-MAC-G2  
За командата  Read Binary с нечетен  байт  INS 
(ако се поддържа ): NEV  
TCS_161 Структурите  на всички  EF трябва  да бъдат  прозрачни . 
TCS_162 Приложението  от поколение  2 за картата  за монтаж  и 
настройки  трябва  да е със следната  структура  на 
данните :
 
► (1) (2) M1 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 246
  
► (1) M1 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 247
  
► (1) M1 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 248  
TCS_163 Следните  стойности , използвани  за указване  на размери  
в таблицата  по-горе, определят  минималния  и макси­  
малния  брой  на записите , който  трябва  да се използва  
за приложение  от поколение  2 в структурата  на данните  
в картата  за монтаж  и настройки :
 
► (1) M1 
4.4. Приложения  за контролната  карта  
4.4.1  Приложение  от поколение  1 за контролната  карта  
TCS_164 След  персонализирането  на приложението  от поколение  
1 за контролната  карта  то трябва  да е със следната  
постоянна  файлова  структура  и правила  за достъп  до 
файловете :
 
В тази таблица  се използват  следните  съкращения  за 
условията  за сигурност : 
SC1 ALW ИЛИ  SM-MAC-G2  
SC2 ALW ИЛИ  SM-MAC-G1 ИЛИ  SM-MAC-G2  
SC3 SM-MAC-G1 ИЛИ  SM-MAC-G2  
SC6 EXT-AUT-G1 ИЛИ  SM-MAC-G1 ИЛИ  SM-MAC- 
G2 
TCS_165 Структурите  на всички  EF трябва  да бъдат  прозрачни . 
TCS_166 Приложението  от поколение  1 за контролната  карта  
трябва  да е със следната  структура  на данните : ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 249
  
TCS_167 Следните  стойности , използвани  за указване  на размери  
в таблицата  по-горе, определят  минималния  и макси­  
малния  брой  на записите , който  трябва  да се използва  
за приложение  от поколение  1 в структурата  на данните  
в контролната  карта :
 
4.4.2  Приложение  от поколение  2 за контролната  карта  
TCS_168 След  персонализирането  на приложението  от поколение  
2 за контролната  карта  то трябва  да е със следната  
постоянна  файлова  структура  и правила  за достъп  до 
файловете : 
Забележка : краткият  идентификатор  на EF (SFID) се 
дава като десетично  число  — например  стойността  30 
съответства  на 11110 в двоичната  бройна  система . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 250
  
В тази таблица  се използва  следното  съкращение  за 
условието  за сигурност : 
SC1 ALW ИЛИ  SM-MAC-G2  
TCS_169 Структурите  на всички  EF трябва  да бъдат  прозрачни . 
TCS_170 Приложението  от поколение  2 за контролната  карта  
трябва  да е със следната  структура  на данните :
 
TCS_171 Следните  стойности , използвани  за указване  на размери  
в таблицата  по-горе, определят  минималния  и макси­  
малния  брой  на записите , който  трябва  да се използва  
за приложение  от поколение  2 в структурата  на данните  
в контролната  карта : ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 251
  
4.5. Приложения  за картата  на превозвач  
4.5.1  Приложение  от поколение  1 за картата  на превозвач  
TCS_172 След  персонализирането  на приложението  от поколение  
1 за картата  на превозвач  то трябва  да е със следната  
постоянна  файлова  структура  и правила  за достъп  до 
файловете :
 
В тази таблица  се използват  следните  съкращения  за 
условията  за сигурност : 
SC1 ALW ИЛИ  SM-MAC-G2  
SC2 ALW ИЛИ  SM-MAC-G1 ИЛИ  SM-MAC-G2  
SC3 SM-MAC-G1 ИЛИ  SM-MAC-G2  
SC6 EXT-AUT-G1 ИЛИ  SM-MAC-G1 ИЛИ  SM-MAC- 
G2 
TCS_173 Структурите  на всички  EF трябва  да бъдат  прозрачни . 
TCS_174 Приложението  от поколение  1 за картата  на превозвач  
трябва  да е със следната  структура  на данните :
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 252  
TCS_175 Следните  стойности , използвани  за указване  на размери  
в таблицата  по-горе, определят  минималния  и макси­  
малния  брой  на записите , който  трябва  да се използва  
за приложение  от поколение  1 в структурата  на данните  
в картата  на превозвач :
 
4.5.2  Приложение  от поколение  2 за картата  на превозвач  
TCS_176 След  персонализирането  на приложението  от поколение  
2 за картата  на превозвач  то трябва  да е със следната  
постоянна  файлова  структура  и правила  за достъп  до 
файловете : 
Забележка : краткият  идентификатор  на EF (SFID) се 
дава като десетично  число  — например  стойността  30 
съответства  на 11110 в двоичната  бройна  система .
 
В тази таблица  се използва  следното  съкращение  за 
условието  за сигурност : 
SC1 ALW ИЛИ  SM-MAC-G2  
TCS_177 Структурите  на всички  EF трябва  да бъдат  прозрачни . 
TCS_178 Приложението  от поколение  2 за картата  на превозвач  
трябва  да е със следната  структура  на данните :
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 253  
TCS_179 Следните  стойности , използвани  за указване  на размери  
в таблицата  по-горе, определят  минималния  и макси­  
малния  брой  на записите , който  трябва  да се използва  
за приложение  от поколение  2 в структурата  на данните  
в картата  на превозвач :
 ▼B
02016R0799 — BG — 26.02.2020 — 002.001 — 254 
Допълнение 3  
ПИКТОГРАМИ  
PIC_001 При тахографите може по избор да се използват следните 
пиктограми и комбинации от пиктограми ( или пиктограми и 
комбинации , които да са достатъчно сходни на тях, така че едно­ 
значно да бъдат отъждествими с тях): 
1.ОСНОВНИ  ПИКТОГРАМИ
Хора Действия Режими  на работа
  
Предприятие Режим на предприятие
  
Контрольор Контрол Контролен режим
  
Водач  Управление на МПС Работен режим
  
Сервиз /изпитателен пункт Техн . преглед /калиб­ 
риране Режим на калибриране
  
Производител 
Дейности Времетраене
  
На разположение  Текущ период на разположение
  
Управление на МПС  Време на непрекъснато управление на 
МПС
  
Почивка Текущ период на почивка
  
Друга работа  Текущ период на работа
  
Прекъсване  Общо време на прекъсване
  
Неизвестна дейност 
Оборудване Функции
  
Четящо устройство с процеп 
за картата  на водача
  
Четящо устройство с процеп 
за картата  на втория водач
  
Карта
  
Часовник
  
Дисплей Показване върху дисплея
  
Външна памет Изтегляне на данни
  
Електрическо  захранване
  
Принтер / разпечатка  Разпечатване
  
Датчик
  
Размер на гумите
  
Превозно средство / бордово 
устройство
  
Устройство за GNSS
  
Устройство за откриване от 
разстояние
  
Интерфейс с ITS  ▼B
02016R0799 — BG — 26.02.2020 — 002.001 — 255 
Особени условия
  
Извън  обсег
  
Преминаване с ферибот /влак 
Други
  
Събития
  Неизправности
  
Начало на дневен период на работа
  Край на дневен период на 
работа
  
Местоположение
  
Ръчно въвеждане на дейностите , 
извършвани  от водача
  
Сигурност
  
Скорост
  
Час
 
Общо /обобщение ( справка ) 
Определения 
24h За деня
  
За седмица
  
За две седмици
  
От или към 
2.КОМБИНАЦИИ  ОТ ПИКТОГРАМИ
Други
  
Контролен пункт
  
Местоположение в началото на 
дневния период на работа
  Местоположение в края на 
дневния период на работа  
▼M1
Местоположение след  3 часа общо 
време на управление на МПС  
▼B
От … часа
 До … часа
 
От превозното средство
  
Начало на излизането извън  обсег
  Край на излизането извън  
обсег  
Карти
  
Карта на водач
  
Карта на превозвач
  
Контролна карта
  
Карта за монтаж и настройки
  
Без карта  ▼B
02016R0799 — BG — 26.02.2020 — 002.001 — 256 
Управление на МПС
  
Управление на МПС в екип
  
Време на управление на МПС за една седмица
  
Време на управление на МПС за две седмици 
Разпечатки
  
Ежедневна разпечатка  на дейностите , извършвани  от водача , 
извлечени от картата
  
Ежедневна разпечатка  на дейностите , извършвани  от водача , 
извлечени от VU (бордовото устройство )
 
Разпечатка  на събитията и неизправностите , извлечени от картата
  
Разпечатка  на събитията и неизправностите , извлечени от VU
  
Разпечатка  на техническите данни
  
Разпечатка  за превишаването на допустимата скорост  
Събития
  
Вкарване на невалидна карта
  
Конфликт , предизвикан от картата
  
Припокриване във времето
  
Управление на МПС без съответната карта
  
Вкарване на карта по време на управление на МПС
  
Неправилно приключване на последната  картова сесия
  
Превишаване на допустимата скорост
  
Прекъсване на електрическото  захранване
  
Грешка в данните за движението
  
Противоречие в данните относно движението на превозното 
средство
  
Нарушаване на сигурността  
▼M1
Времеви конфликт или сверяване на часовника ( в сервиз ) 
▼B
Контрол на превишаването на допустимата скорост  
▼M1
Липса на информация за местоположението от приемник на сигнали 
от GNSS или Грешка в комуникацията с външното  устройство за 
GNSS
  
Грешка в комуникацията с устройството за връзка от разстояние  
▼B
Неизправности
  
Дефектна карта (в процепа на четящото устройство за картата  на 
водача )
 
Дефектна карта (в процепа на четящото устройство за картата  на 
втория водач )
 
Неизправност в дисплея  ▼B
02016R0799 — BG — 26.02.2020 — 002.001 — 257 
Грешка при изтеглянето на данни
  
Неизправност в принтера ( печатащото устройство )
 
Неизправност на датчика
  
Неизправност вътре във VU
  
Неизправност във връзка с GNSS
  
Неизправност във връзка с откриването от разстояние 
Процедура по ръчно въвеждане
  
За същия дневен период на работа ?
 
Край на предишен период на работа ?
 
Потвърждение или въвеждане на местоположението в края на 
дневния период на работа
  
Въвеждане на часа на тръгване
  
Въвеждане на местоположението в началото на периода на работа . 
Забележка : в допълнение 4 са определени допълнителни  
комбинации от пиктограми с оглед да се получат блокове за 
разпечатване или идентификатори на записи . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 258  
Допълнение  4 
РАЗПЕЧАТКИ  
СЪДЪРЖАНИЕ  
1. ОБЩИ  ПОЛОЖЕНИЯ  
2. СПЕЦИФИКАЦИЯ  ЗА БЛОКОВЕТЕ  ДАННИ  
3. СПЕЦИФИКАЦИИ  ЗА РАЗПЕЧАТКИТЕ  
3.1. Ежедневна  разпечатка  на данните  за дейностите  на водача , 
извлечени  от карта  
3.2. Ежедневна  разпечатка  на данните  за дейностите  на водача , 
извлечени  от бордовото  устройство  
3.3. Разпечатка  на данните  за събития  и неизправности , извлечени  от 
картата  
3.4. Разпечатка  на данните  за събития  и неизправности , извлечени  от 
бордовото  устройство  
3.5. Разпечатка  на техническите  данни  
3.6. Разпечатка  за превишаванията  на скоростта  
3.7. Разпечатка  за историята  на вкараните  карти  
1. ОБЩИ  ПОЛОЖЕНИЯ  
Всяка  разпечатка  се състои  от поредица  последователни  блокове  от 
данни , които  могат  да бъдат  определени  от идентификатор  на 
блока . 
Един  блок  данни  съдържа  един  или няколко  записа , които  при 
необходимост  могат  да бъдат  определени  от идентификатор  на 
записа . 
PRT_001 Ако идентификатор  на блок  предхожда  непосредствено  
идентификатор  на запис , идентификаторът  на запис  не 
се отпечатва . 
PRT_002 Ако някакъв  елемент  от данните  е неизвестен  или не 
трябва  да се отпечатва  поради  права  за достъп  до 
данните , на мястото  на този елемент  остава  празно  
пространство  при разпечатването . 
PRT_003 Ако съдържанието  на цял ред е неизвестно  или не се 
налага  да бъде  отпечатано , целият  този ред се пропуска . 
PRT_004 Полетата  с цифрови  данни  се отпечатват  с подравняване  
отдясно  и без нули  в началото  на числата , като групите  
от цифри  за хилядите  и за милионите  се разделят  с 
празен  интервал . 
PRT_005 Полетата  за данни , състоящи  се от символни  низове , се 
отпечатват  с подравняване  отляво  и при необходимост  се 
допълват  с празни  интервали  или се отрязват  съобразно  
дължината  на елемента  от данните  (имена  и адреси ). 
PRT_006 Ако се налага  пренос  на нов ред поради  дълъг  текст , като 
първи  символ  на новия  ред следва  да се отпечата  специален  
знак (точка  на половината  височина  на реда  „•“).  
2. СПЕЦИФИКАЦИЯ  ЗА БЛОКОВЕТЕ  ДАННИ  
В настоящата  глава  се прилагат  следните  условни  обозначения  за 
формата : 
— символите , които  са изписани  с удебелен  шрифт , обозначават  
обикновен  текст  (отпечатват  се същите  символи , но с нормален  
шрифт ); ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 259  
— символите  с нормален  шрифт  обозначават  променливи  (пик­  
тограми  или данни ), които  се заместват  при отпечатването  с 
техните  съответни  стойности ; 
— имената  на променливите  се допълват  от знаци  за подчертаване , 
за да се посочи  допустимата  дължина  на елемента  от данни  за 
съответната  променлива ; 
— датите  се указват  във формата  „дд/мм/гггг“ (ден/месец /година ). 
Може  да се използва  и формат  „дд.мм.гггг“. 
— Терминът  „Идентификация  на картата “ обхваща  съвкупността  
от: типа  на картата , обозначен  чрез комбинация  от пиктограми , 
кода  на държавата  членка , която  е издала  картата , наклонена  
надясно  черта  и номер  на картата  с индекс  за замяна  и индекс  
за подновяване , разделени  от един  празен  интервал : 
P
 x  x  x  / x  x  x  x  x  x  x  x  x  x  x  x  x  x  x  x
 Комбинация  
от пиктограми  за 
картата  
Код на издаващата  
държава  членка Първите  14 символа  от номера  на картата  
(евентуално  включително  индекс  за последователност ) 
Индекс  за подмяна  
Индекс  за подновяване ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 260  
PRT_007 Разпечатките  се състоят  от следните  блокове  и/или записи  от 
данни  със следните  значения  и формати :
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 261
  
▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 262
  
► (1) (2) M1 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 263
  
▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 264
  
▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 265
  
▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 266
  
3. СПЕЦИФИКАЦИИ  ЗА РАЗПЕЧАТКИТЕ  
В настоящата  глава  се прилагат  следните  условни  обозначения : 
N Отпечатване  на блока  или на записа  с номер  N 
N Отпечатване  на блока  или на записа  номер  N, повторен  толкова  
пъти , колкото  е необходимо  
X/Y Отпечатване  на блоковете  или на записите  Х и/или Y, според  
нуждите , и повторение  на операцията  толкова  пъти , колкото  е 
необходимо  
3.1. Ежедневна  разпечатка  на данните  за дейностите  на водача , 
извлечени  от карта  
PRT_008 Ежедневната  разпечатка  на данните  за дейностите  на 
водача , извлечени  от карта , трябва  да бъде  в съответствие  
със следния  формат : 
1 Дата  и час на отпечатване  на документа  
2 Тип на разпечатката  
3 Идентификация  на контрольора  (ако е вкарана  контролна  карта  
във VU)  
3 Идентификация  на водача  (извлечена  от картата , която  е обект  на 
разпечатката  + GEN)  
4 Идентификация  на превозното  средство  (от което  е направена  
разпечатката ) 
5 Идентификация  на VU (от което  е направена  разпечатката  + 
GEN)  
6 Последно  калибриране  на това бордово  устройство  
7 Последна  проверка , на която  е бил подложен  инспектираният  
водач  
8 Разграничител  на данни  за дейностите  на водача  
8а Условие  „Извън  обсег “ в началото  на този ден 
8.1а/ 8.1б/ 8.1в/ 8.2 / 
8.3 / 8.3а/ 8.4  Дейности  на водача  в хронологичен  ред 
11 Разграничител  за ежедневната  справка  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 267  
11.4 Въведени  местоположения  в хронологичен  ред 
▼M1 
11.5 Местоположения  след  3 часа общо  време  на управление  на МПС  
в хронологичен  ред 
▼B 
11.6 Общо  времетраене  на всяка  дейност  
12.1 Разграничител  на данни  за събития  или неизправности , извлечени  
от картата  
12.4 Записи  за събития  или неизправности  (за последните  5 събития  
или неизправности , съхранявани  в картата ) 
13.1 Разграничител  на данни  за събития  или неизправности , извлечени  
от бордовото  устройство  
13.4 Записи  за събития /неизправности  (5-те последни  събития  или 
неизправности , които  са записани  или са в процес  на записване  
в бордовото  устройство ) 
22.1 Контролен  пункт  
22.2 Подпис  на контрольора  
22.5 Подпис  на водача  
3.2. Ежедневна  разпечатка  на данните  за дейностите  на водача , 
извлечени  от бордовото  устройство  
PRT_009 Ежедневната  разпечатка  на данните  за дейностите  на 
водача , извлечени  от бордовото  устройство , трябва  да 
бъде  в съответствие  със следния  формат : 
▼M1 
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 Справка  за периодите  без вкарана  карта  в процепа  на 
четящото  устройство  на водача  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 268  
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 Подпис  на водача  
▼B 
3.3. Разпечатка  на данните  за събития  и неизправности , извлечени  
от картата  
PRT_010 Ежедневната  разпечатка  на данните  за събития  и 
неизправности , извлечени  от картата , трябва  да е в съот­  
ветствие  със следния  формат : 
1 Дата  и час на отпечатване  на документа  
2 Тип на разпечатката  
3 Идентификация  на контрольора  (ако е вкарана  контролна  карта  
във VU + GEN)  
3 Идентификация  на водача  (извлечена  от картата , която  е обект  на 
разпечатката ) 
4 Идентификация  на превозното  средство  (от което  е направена  
разпечатката ) 
12.2 Разграничител  на данни  за събития  
12.4 Записи  за събития  (за всички  събития , записани  върху  картата ) 
12.3 Разграничител  на данни  за неизправности  
12.4 Записи  за неизправности  (за всички  неизправности , записани  
върху  картата ) 
22.1 Контролен  пункт  
22.2 Подпис  на контрольора  
22.5 Подпис  на водача  ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 269  
3.4. Разпечатка  на данните  за събития  и неизправности , извлечени  
от бордовото  устройство  
PRT_011 Разпечатката  на данните  за събития  и неизправности , 
извлечени  от бордовото  устройство , трябва  да е в съот­  
ветствие  със следния  формат : 
1 Дата  и час на отпечатване  на документа  
2 Тип на разпечатката  
3 Идентификация  на титуляря  на картата  (за всички  карти , вкарани  
във VU + GEN)  
4 Идентификация  на превозното  средство  (от което  е направена  
разпечатката ) 
13.2 Разграничител  на данни  за събитията  
13.4 Записи  за събития  (за всички  събития , които  са записани  или са в 
процес  на записване  в бордовото  устройство ) 
13.3 Разграничител  на данни  за неизправности  
13.4 Записи  за неизправности  (за всички  неизправности , които  са 
записани  или са в процес  на записване  в бордовото  устройство ) 
22.1 Контролен  пункт  
22.2 Подпис  на контрольора  
22.5 Подпис  на водача  
3.5. Разпечатка  на техническите  данни  
PRT_012 Разпечатката  на техническите  данни  трябва  да е в съот­  
ветствие  със следния  формат : 
1 Дата  и час на отпечатване  на документа  
2 Тип на разпечатката  
3 Идентификация  на титуляря  на картата  (за всички  карти , вкарани  
във VU + GEN)  
4 Идентификация  на превозното  средство  (от което  е направена  
разпечатката ) 
14 Идентификация  на бордовото  устройство  
15 Идентификация  на датчика  
15.1 Данни  за сдвояването  на датчика  (всички  налични  данни  в хроно­  
логичен  ред) 
16 Идентификация  на GNSS  
16.1 Данни  за свързването  на външното  устройство  за GNSS (всички  
налични  данни  в хронологичен  ред) 
17 Разграничител  на данните  от калибрирането  
17.1 Записи  за калибрирането  (всички  налични  записи  в хронологичен  
ред) 
18 Разграничител  на данни  за сверяването  на часовника  
18.1 Записи  за сверяването  на часовника  (всички  налични  записи  от 
сверяването  на часовника  и от калибрирането ) 
19 Последни  събития  и неизправности , записани  във VU ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 270  
3.6. Разпечатка  за превишаванията  на скоростта  
PRT_013 Разпечатката  за превишаванията  на скоростта  трябва  да е 
в съответствие  със следния  формат : 
1 Дата  и час на отпечатване  на документа  
2 Тип на разпечатката  
3 Идентификация  на титуляря  на картата  (за всички  карти , вкарани  
във VU + GEN)  
4 Идентификация  на превозното  средство  (от което  е направена  
разпечатката ) 
20 Информация  относно  контрола  за превишаване  на допустимата  
скорост  
21.1 Идентификатор  на данните  за превишаване  на допустимата  
скорост  
21.4 / 21.5  Първо  превишаване  на допустимата  скорост  след  последното  
калибриране  
21.2 Идентификатор  на данните  за превишаване  на допустимата  
скорост  
21.4 / 21.5  5 най-сериозни  превишавания  през последните  365 дни 
21.3 Идентификатор  на данните  за превишаване  на допустимата  
скорост  
21.4 / 21.5  Най-сериозното  превишаване  за всеки  от последните  10 дни на 
възникване  на това събитие  
22.1 Контролен  пункт  
22.2 Подпис  на контрольора  
22.5 Подпис  на водача  
3.7. Разпечатка  за историята  на вкараните  карти  
▼M1 
PRT_014 Разпечатката  за историята  на вкараните  карти  трябва  да е 
в съответствие  със следния  формат : 
1 Дата  и час на отпечатване  на документа  
2 Тип на разпечатката  
3 Идентификация  на титуляря  на картата  (за всички  карти , вкарани  
в бордовото  устройство ) 
23 Последна  карта , вкарана  в бордовото  устройство  
23.1 Вкарани  карти  (до 88 записа ) 
12.3 Разграничител  на данни  за неизправности  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 271  
Допълнение  5 
ПОКАЗВАНЕ  
В настоящото  допълнение  се прилагат  следните  условни  обозначения  за 
формата : 
— символите , които  се изписани  с удебелен  шрифт , обозначават  обикновен  
текст , който  трябва  да се покаже  (показват  се същите  символи , но с 
нормален  шрифт ), 
— символите  с нормален  шрифт  обозначават  променливи  (пиктограми  или 
данни ), които  се заместват  при показването  с техните  съответни  стой­  
ности : 
— дд мм гггг: ден, месец , година , 
— hh: часове , 
— mm: минути , 
— D: пиктограма  за времетраене , 
— EF: комбинация  от пиктограми  за събитие  или 
неизправност , 
— O: пиктограма  за режим  на работа . 
DIS_001 Тахографът  трябва  да показва  данните  в следните  формати : 
Данни  Формат  
Показване  по подразбиране  
Местно  време
  
Режим  на работа
  
Информация  относно  водача :
 
Информация  относно  втория  водач :
 
Отворено  условие  „Извън  обсег “
 
Показване  на предупреждение  
Надвишаване  на времето  за непрекъснато  управление  на 
МПС
  
Събитие  или неизправност
  
Показване  на други  данни  
Дата  по координирано  универсално  време  (UTC)
  
час 
Време  на непрекъснато  управление  на МПС  и общо  
време  на прекъсване  за водача
  
Време  на непрекъснато  управление  на МПС  и общо  
време  на прекъсване  за втория  водач
  
Общо  време  на управление  на МПС  на водача  през 
текущата  и предходната  седмица
  
Общо  време  на управление  на МПС  на втория  водач  
през текущата  и предходната  седмица
  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 272  
Допълнение  6 
ПРЕДЕН  СЪЕДИНИТЕЛ  ЗА КАЛИБРИРАНЕ  И ИЗТЕГЛЯНЕ  НА 
ДАННИ  
СЪДЪРЖАНИЕ  
1. ХАРДУЕР  
1.1. Съединител  
1.2. Разпределение  на контактите  
1.3. Блоксхема  
2. ИНТЕРФЕЙС  ЗА ИЗТЕГЛЯНЕ  НА ДАННИ  
3. ИНТЕРФЕЙС  ЗА КАЛИБРИРАНЕ  
1. ХАРДУЕР  
1.1. Съединител  
INT_001 Съединителят  за калибриране /изтегляне  на данни  трябва  да е 
с шест  крачета , да е достъпен  върху  лицевия  панел , без да се 
налага  разкачване  на каквато  и да е част на тахографа , и да е 
в съответствие  със следния  чертеж  (всички  размери  са 
дадени  в милиметри ):
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 273  
На следната  схема  е показан  обичаен  контактен  съединител  
с 6 крачета :
 
1.2. Разпределение  на контактите  
INT_002 Контактите  трябва  да са разпределени  съгласно  следната  
таблица : 
Краче  Описание  Забележка  
1 Отрицателен  полюс  на 
акумулатора  Свързан  към отрицателната  клема  на акумулатора  на 
превозното  средство  
2 Предаване  на данни  Линия  K (ISO 14230-1)  
3 RxD — изтегляне  на данни  Входящи  данни  към тахографа  
4 Входен /изходен  сигнал  Калибриране  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 274  
Краче  Описание  Забележка  
5 Постоянна  изходяща  
мощност  Обхватът  на напрежението  трябва  да бъде  същият  както  
за електрическото  захранване  на превозното  средство , 
намален  с 3 V, за да се отчете  спадът  на напрежението  
през защитните  вериги  
Изход  40 mA  
6 TxD — изтегляне  на данни  Изходящи  данни  от тахографа  
1.3. Блоксхема  
INT_003 Блоксхемата  трябва  е в съответствие  със следното :
 
2. ИНТЕРФЕЙС  ЗА ИЗТЕГЛЯНЕ  НА ДАННИ  
INT_004 Интерфейсът  за изтегляне  на данни  трябва  да е в съот­  
ветствие  със спецификациите  RS232.  
INT_005 Интерфейсът  за изтегляне  на данни  използва  един  стартов  
бит, осем  бита  за данни  (в началото  е най-младшият  бит), 
един  бит за проверка  по четност  и един  стопов  бит.
 
Организация  на байта  за данни  
Стаpтов бит: един  бит с логическо  ниво  0 
Битове  за данни : предават  се, като първи  е най-младшият  бит 
Бит за четност : проверка  по четност  
Стопов  бит: един  бит с логическо  ниво  1 
При предаването  на цифрови  данни , съставени  от повече  от един  
байт , първо  се предава  най-старшият  байт , а най-младшият  байт  е 
последен . 
INT_006 Скоростта  на предаване  на данните  трябва  да може  да се 
регулира  от 9 600 bps до 115 200 bps. Предаването  на 
данни  се извършва  с най-високата  възможна  скорост , като 
началната  скорост  е 9 600 bps.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 275  
3. ИНТЕРФЕЙС  ЗА КАЛИБРИРАНЕ  
INT_007 Предаването  на данни  трябва  да е в съответствие  с ISO 14 
230-1: Пътни  превозни  средства . Системи  за диагностика . 
Протокол  с ключови  думи  2000 — част I: физически  слой . 
Първо  издание , 1999 г. 
INT_008 Входният /изходният  сигнал  трябва  да е в съответствие  със 
следната  електрическа  спецификация : 
Параметър  Минимум  Обичайна  
стойност  Максимум  Забележка  
U low (ниско  ниво  на 
входния  сигнал ) 1,0 V  I = 750 μА 
U high (високо  ниво  
на входния  сигнал ) 4 V I = 200 μА 
Честота  4 kHz  
U low (ниско  ниво  на 
изходния  сигнал ) 1,0 V  I = 1 mA  
U high (високо  ниво  
на изходния  сигнал ) 4 V I = 1 mA  
INT_009 Входният /изходният  сигнал  трябва  да е в съответствие  със 
следните  хронограми :
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 276  
Допълнение  7 
ПРОТОКОЛИ  ЗА ИЗТЕГЛЯНЕ  НА ДАННИ  
СЪДЪРЖАНИЕ  
1. ВЪВЕДЕНИЕ  
1.1. Обхват  
1.2. Съкращения  и означения  
2. ИЗТЕГЛЯНЕ  НА ДАННИ  ОТ БОРДОВО  УСТРОЙСТВО  
2.1. Процедура  за изтегляне  на данни  
2.2. Протокол  за изтегляне  на данни  
2.2.1 Структура  на съобщението  
2.2.2 Типове  съобщения  
2.2.2.1 Start Communication Request (SID 81)  
2.2.2.2 Positive Response Start Communication (SID C1)  
2.2.2.3 Start Diagnostic Session Request (SID 10)  
2.2.2.4 Positive Response Start Diagnostic (SID 50)  
2.2.2.5 Link Control Service (SID 87)  
2.2.2.6 Link Control Positive Response (SID C7)  
2.2.2.7 Request Upload (SID 35)  
2.2.2.8 Positive Response Request Upload (SID 75)  
2.2.2.9 Transfer Data Request (SID 36)  
2.2.2.10 Positive Response Transfer Data (SID 76)  
2.2.2.11 Request Transfer Exit (SID 37)  
2.2.2.12 Positive Response Request Transfer Exit (SID 77)  
2.2.2.13 Stop Communication Request (SID 82)  
2.2.2.14 Positive Response Stop Communication (SID C2)  
2.2.2.15 Acknowledge Sub Message (SID 83)  
2.2.2.16 Negative Response (SID 7F)  
2.2.3 Поток  на съобщенията  
2.2.4 Синхронизация  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 277  
2.2.5 Обработка  на грешки  
2.2.5.1 Start Communication phase  
2.2.5.2 Communication phase  
2.2.6 Съдържание  на съобщенията  за отговор  
2.2.6.1 Positive Response Transfer Data Overview  
2.2.6.2 Positive Response Transfer Data Activities  
2.2.6.3 Positive Response Transfer Data Events and Faults  
2.2.6.4 Positive Response Transfer Data Detailed Speed  
2.2.6.5 Positive Response Transfer Data Technical Data  
2.3. Съхранение  на файлове  върху  ESM  
3. ПРОТОКОЛ  ЗА ИЗТЕГЛЯНЕ  НА ДАННИ  ОТ ТАХОГ­  
РАФСКИТЕ  КАРТИ  
3.1. Обхват  
3.2. Определения  
3.3. Изтегляне  на данни  от карта  
3.3.1 Последователност  при инициализиране  
3.3.2 Последователност  за неподписани  файлове  с данни  
3.3.3 Последователност  за подписани  файлове  с данни  
3.3.4 Последователност  за инициализиране  на брояча  за калибриране  
3.4. Формат  за съхранение  на данните  
3.4.1 Въведение  
3.4.2 Формат  на файловете  
4. ИЗТЕГЛЯНЕ  НА ДАННИ  ОТ ТАХОГРАФСКА  КАРТА  ЧРЕЗ  
БОРДОВО  УСТРОЙСТВО  
1. ВЪВЕДЕНИЕ  
В това допълнение  са посочени  процедурите , които  е необходимо  
да се прилагат  за извършване  на различните  типове  изтегляне  на 
данни  върху  външно  запаметяващо  устройство , както  и прото­  
колите , които  трябва  да се спазват , за да се осигури  правилното  
прехвърляне  на данни  и да се гарантира  пълната  съвместимост  на 
форм àта на изтеглените  данни  с цел всяко  контролиращо  лице  да 
може  да инспектира  тези данни , като преди  да пристъпи  към 
техния  анализ , да може  да се увери  в тяхната  автентичност  и 
цялост . 
▼M1 
1.1. Обхват  
Някои  данни  могат  да бъдат  изтеглени  върху  външно  запаме­  
тяващо  устройство : 
— от бордовото  устройство  чрез свързано  към него  специали­  
зирано  интелигентно  устройство  (IDE),  
— от тахографска  карта  чрез IDE, оборудвано  с интерфейсно  
устройство  за карта  (IFD),  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 278  
— през бордовото  устройство  от тахографска  карта  чрез IDE, 
свързано  към бордовото  устройство . 
С цел да се даде  възможност  за проверка  на автентичността  и 
целостта  на изтеглените  данни , съхранени  върху  външно  запаме­  
тяващо  устройство , те се придружават  от подпис  съгласно  общите  
механизми  за сигурност  от допълнение  11. Изтеглят  се също  
данните  за идентификацията  на изходното  оборудване  (бордово  
устройство  или карта ) и неговите  сертификати  за сигурност  
(държава  членка  и оборудване ). Проверителят  на данните  трябва  
да притежава  свой  собствен  защитен  европейски  публичен  ключ . 
Данните , изтеглени  от бордовото  устройство , се подписват  
съгласно  общите  механизми  за сигурност  от допълнение  11, част 
Б (тахографска  система  от второ  поколение ), освен  когато  
проверката  на водача  се извършва  от контролен  орган  на 
държава  извън  ЕС с контролна  карта  от първо  поколение ; в тези 
случаи  данните  се подписват  съгласно  общите  механизми  за 
сигурност  от допълнение  11, част А (тахографска  система  от 
първо  поколение ) в съответствие  с изискванията  в раздел  
MIG_015 от допълнение  15 — „Миграция “. 
За тази цел в посоченото  допълнение  се предвиждат  два типа  
изтегляния  на данни  от бордовото  устройство : 
— изтегляне  на данни  от бордово  устройство  от поколение  2 със 
структура  на данните  от поколение  2, като данните  се 
подписват  съгласно  общите  механизми  за сигурност  от 
допълнение  11, част Б, 
— изтегляне  на данни  от бордово  устройство  от поколение  1 със 
структура  на данните  от поколение  1, като данните  се 
подписват  съгласно  общите  механизми  за сигурност  от 
допълнение  11, част А. 
По същия  начин  съществуват  и два типа  данни , изтеглени  от карта  
на водач  от второ  поколение , вкарана  в бордовото  устройство , 
както  се посочва  в параграфи  3 и 4 от настоящото  допълнение . 
▼B 
1.2. Съкращения  и означения  
В настоящото  допълнение  се използват  следните  съкращения : 
AID Идентификатор  на приложението  
ATR  Отговор  на инициализиране  
CS Байт  за контролна  сума  
DF Специализиран  файл  
DS_ Диагностична  сесия  
EF Елементарен  файл  
ESM  Външно  запаметяващо  устройство  
FID Идентификатор  на файл  
FMT  Байт  за структура  (първи  байт  на заглавната  част на съоб­  
щение ) 
ICC Карта  с интегрална  схема  
IDE Специализирано  интелигентно  устройство : устройство , 
което  се използва  за изтегляне  на данни  върху  ESM 
(например  персонален  компютър ) 
IFD Интерфейсно  устройство  
KWP  Протокол  „Keyword 2000“  
LEN  Байт  за дължина  (последен  байт  на заглавната  част на 
съобщение ) 
PPS Избор  на параметрите  на протокола  
PSO  Извършване  на операция  по сигурността  
SID Идентификатор  на услуга  
SRC  Изходен  байт  
TGT  Целеви  байт ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 279  
TLV  Стойност  за дължината  на тага 
TREP  Параметър  на отговор  за трансфер  
TRTP  Параметър  на заявка  за трансфер  
VU Бордово  устройство  
2. ИЗТЕГЛЯНЕ  НА ДАННИ  ОТ БОРДОВО  УСТРОЙСТВО  
2.1. Процедура  за изтегляне  на данни  
За да се извърши  изтегляне  на данни  от бордово  устройство , 
потребителят  трябва  да изпълни  следните  операции : 
— поставя  тахографската  си карта  в процепа  за картата  на VU (*);  
— свързва  IDE към съединителя  за изтегляне  на данни  от VU;  
— установява  връзката  между  IDE и VU;  
— от IDE избира  данните , които  ще се изтеглят , и изпраща  
заявката  към VU;  
— приключва  сесията  за изтегляне  на данни . 
2.2. Протокол  за изтегляне  на данни  
Структурата  на протокола  се основава  на принципа  главно - 
подчинено  устройство , като IDE има функцията  на главно  
устройство , а VU — на подчинено  устройство . 
Структурата  на съобщенията , техните  типове  и потокът  им се 
основават  главно  на протокола  „Keyword 2000“ (KWP) (ISO 
14230-2 Пътни  превозни  средства . Системи  за диагностика . 
Протокол  „Keyword 2000“. Част  2: канален  слой ). 
Приложният  слой  се основава  главно  върху  актуалния  проект  за 
стандарт  ISO 14229-1 ( Пътни  превозни  средства . Системи  за диаг­  
ностика . Част  1: услуги  за диагностика , версия  6 от 22 февруари  
2001 г.). 
2.2.1  Структура  на съобщението  
DDP_002 Всички  разменени  съобщения  между  IDE и VU се 
характеризират  със структура  от три части : 
— заглавна  част, съставена  от байт  за структура  (FMT), 
целеви  байт  (TGT), изходен  байт  (SRC) и евентуално  
байт  за дължина  (LEN);  
— поле  за данни , съдържащо  байт  за идентификатор  на 
услуга  (SID) и променлив  брой  байтове  за инфор­  
мация , които  могат  да включат  един  незадължителен  
байт  за диагностична  сесия  (DS_) или един  незадъл­  
жителен  байт  за параметър  за трансфер  (TRTP или 
TREP);  
— контролна  сума , съставена  от байт  за контролна  сума  
(CS).  
Заглавна  част Поле  за данни  Контролна  сума  
FMT  TGT  SRC  LEN  SID  DATA  …  …  …  CS  
4 байта  255 байта  максимум  1 байт  
Байтовете  TGT и SRC представляват  физическите  
адреси  на получателя  и изпращача  на съобщението . Те 
приемат  стойностите  F0 Hex за IDE и EE Hex за VU.  
Байтът  LЕN е дължината  на полето  за данни . ▼B 
(*) Поставянето  на картата  активира  съответните  права  за достъп  до функцията  за 
изтегляне  на данни  и до данните . Трябва  да е възможно  обаче  изтеглянето  на 
данни  от карта  на водач , вкарана  в един  от процепите  на VU, когато  в другия  
процеп  не е поставена  друга  карта .
 02016R0799 — BG — 26.02.2020 — 002.001 — 280  
Байтът  за контролна  сума  е серия  от суми  по 8 бита  по 
модул  256, които  представляват  всички  байтове  на съоб­  
щението  с изключение  на самата  CS. 
Байтовете  FMT, SID, DS_, TRTP и TREP са определени  
по-нататък  в този документ . 
DDP_003 Ако дължината  на данните , които  трябва  да се пренесат  
от съобщението , надхвърля  свободното  пространство  в 
полето  за данни , изпращането  на това съобщение  става  
под формата  на няколко  подсъобщения . Всяко  
подсъобщение  съдържа  заглавна  част, същите  SID, 
TREP и брояч  на подсъобщения  от 2 байта , който  
посочва  номера  на подсъобщението  в рамките  на 
цялото  съобщение . С цел проверка  за грешки  и евен­  
туално  прекратяване  на обмена  на данни  IDE 
потвърждава  получаването  на всяко  подсъобщение . 
IDE може  да приеме  подсъобщение , да поиска  
повторното  му предаване  и да поиска  от VU да 
възобнови  или да прекрати  предаването . 
DDP_004 Ако полето  за данни  на последното  подсъобщение  
съдържа  точно  255 байта , е необходимо  да се прибави  
едно  последно  подсъобщение , което  съдържа  празно  
поле  за данни  (с изключение  на SID TREP и брояча  на 
подсъобщения ), за да покаже  края  на съобщението . 
Пример : 
Заглавна  част SID  TREP  Съобщение  CS  
4 байта  Дължина , по-голяма  от 255 байта  
Ще бъде  предадено  като: 
Заглавна  част SID  TREP  00  01  Подсъобщение  
1 CS 
4 байта  255 байта  
Заглавна  част SID  TREP  00  02  Подсъобщение  
2 CS 
4 байта  255 байта  
… 
Заглавна  част SID  TREP  xx  yy  Подсъобщение  
n CS 
4 байта  По-малка  от 255 байта  
или като: 
Заглавна  част SID  TREP  00  01  Подсъобщение  
1 CS 
4 байта  255 байта  
Заглавна  част SID  TREP  00  02  Подсъобщение  
2 CS 
4 байта  255 байта  
… 
Заглавна  част SID  TREP  xx  yy  Подсъобщение  
n CS 
4 байта  255 байта  
Заглавна  част SID  TREP  xx  yy + 1  CS  
4 байта  4 байта  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 281  
2.2.2  Типове  съобщения  
Протоколът  за връзка  за изтегляне  на данни  между  VU и IDE 
изисква  обмен  на 8 различни  типа  съобщения . 
Следващата  таблицата  обобщава  тези съобщения . 
▼M1 
Структура  на съобщението  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 Diag ­
nostic  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  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 282  
Структура  на съобщението  4 байта  максимум  Заглавна  част 255 байта  максимум  Данни  1 байт  
Контр­  
олна  
сума  
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DATA  CS  
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  
▼B 
Забележки : 
▼M1 
— TRTP 21 — 25 се използват  за заявки  за изтегляне  на данни  от 
бордово  устройство  от поколение  2; TRTP 01 — 05 се 
използват  за заявки  за изтегляне  на данни  от бордово  
устройство  от поколение  1, които  бордовото  устройство  може  
да приеме  само  при проверка  на водача , която  се извършва  от 
контролен  орган  на държава  извън  ЕС с контролна  карта  от 
първо  поколение . 
— TRTP 11 — 19 и 31 — 39 са запазени  за заявки  за специфични  
изтегляния  на данни  от производителя . 
▼B 
— Sid Req = the Sid на съответната  заявка . 
— TREP = the TRTP на съответната  заявка . 
— Черните  полета  означава , че нищо  не е предадено . 
— Терминът  „upload“ [„ качване  на данни “] (от IDE) се използва  за 
съвместимостта  със стандарта  ISO 14229. Този  термин  
притежава  същото  значение  като „download“ [„ изтегляне  на 
данни “] (от VU).  
— В тази таблица  не са показани  потенциални  броячи  за 
подсъобщения  от 2 байта . 
— Процеп  е номерът  на процепа  — или 1 (карта  в процепа  за 
водача ), или 2 (карта  в процепа  за втория  водач ). 
— Ако процепът  не е посочен , VU избира  процеп  1, ако картата  е 
поставена  в този процеп , а процеп  2 — само  ако този процеп  е 
специално  избран  от потребителя . 
2.2.2.1 S t a r t C o m m u n i c a t i o n R e q u e s t ( S I D 8 1 )  
DDP_005 Това  съобщение  се подава  от IDE за установяване  на 
връзка  с VU. Началната  връзка  се извършва  винаги  
със скорост  от 9 600 бода  (до момента , когато  тази 
скорост  за предаване  на данни  се промени  с помощта  
на съответните  услуги  за контрол  на връзките ). ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 283  
2.2.2.2 P o s i t i v e R e s p o n s e S t a r t C o m m u n i c a t i o n ( S I D C 1 )  
DDP_006 VU изпраща  това съобщение , за да отговори  поло­  
жително  на start communication request. То съдържа  
двата  ключови  байта  ‘EA’ и ‘8F’, които  указват , че съот­  
ветното  устройство  поддържа  протокол  със заглавна  
част, включително  целевата  и изходната  информация  и 
информацията  за дължината . 
2.2.2.3 S t a r t D i a g n o s t i c S e s s i o n R e q u e s t ( S I D 1 0 )  
DDP_007 IDE изпраща  съобщение  за Start Diagnostic Session 
request с цел заявяване  на нова  диагностична  сесия  с 
VU. Подфункцията  „default session“ (81 Hex) указва , че 
ще започне  стандартна  диагностична  сесия . 
2.2.2.4 P o s i t i v e R e s p o n s e S t a r t D i a g n o s t i c ( S I D 5 0 )  
DDP_008 VU изпраща  съобщение  Positive Response Start Diag ­
nostic, за да отговори  положително  на Diagnostic 
Session Request.  
2.2.2.5 L i n k C o n t r o l S e r v i c e ( S I D 8 7 )  
DDP_052 Link Control Service се използва  от IDE, за да започне  
промяна  в скоростта  за предаване  на данни . Тази  
операция  включва  два етапа . През  първия  етап IDE 
предлага  промяна  в скоростта  за предаване  на данни , 
като посочва  нова  скорост . При получаване  на поло­  
жително  съобщение  от VU IDE изпраща  потвърждение  
на промяната  в скоростта  за предаване  на данни  до VU 
(втори  етап). Тогава  IDE преминава  към новата  скорост  
за предаване  на данни . След  получаване  на потвър­  
ждението  VU преминава  към новата  скорост  за 
предаване  на данни . 
2.2.2.6 L i n k C o n t r o l P o s i t i v e R e s p o n s e ( S I D C 7 )  
DDP_053 Link Control Positive Response се подава  от VU, за да се 
отговори  положително  на Link Control Service request 
(първи  етап). Трябва  да се отбележи , че на заявката  за 
потвърждение  не се дава никакъв  отговор  (втори  етап). 
2.2.2.7 R e q u e s t U p l o a d ( S I D 3 5 )  
DDP_009 IDE изпраща  съобщение  за Request Upload, за да посочи  
на VU, че заявява  изпълнение  на операция  по изтегляне  
на данни . За да се изпълнят  изискванията  на стандарта  
ISO 14229, се включват  данни  относно  адреса , размера  и 
характеристиките  на форм àта на заявените  данни . Тъй 
като тази информация  не е известна  на IDE преди  
изтегляне  на данните , адресът  в паметта  се нулира , 
форм àтът се декриптира  и декомпресира  и размерът  на 
паметта  се определя  на максимума . 
2.2.2.8 P o s i t i v e R e s p o n s e R e q u e s t U p l o a d ( S I D 7 5 )  
DDP_010 VU изпраща  съобщение  Positive Response Request 
Upload, за да съобщи  на IDE, че е готов  да изтегли  
данните . За да се изпълнят  изискванията  на стандарт  
ISO 14229, положителното  съобщение  за отговор  
съдържа  данни , които  показват  на IDE, че следващите  
съобщения  Positive Response Transfer Data ще съдържат  
максимум  00FF hex байта . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 284  
2.2.2.9 T r a n s f e r D a t a R e q u e s t ( S I D 3 6 )  
▼M1 
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  
DDP_054 За IDE е задължително  да заяви  overview data transfer 
(TRTP 01 или 21) по време  на сесия  за изтегляне  на 
данни , защото  единствено  това гарантира , че сертифи­  
катите  на бордовото  устройство  се регистрират  в 
изтегления  файл  (и това позволява  проверката  на 
цифровия  подпис ). 
Във втория  случай  (TRTP 02 или 22) съобщението  
Transfer Data Request съдържа  указание  за календарния  
ден (формат
  ), чиито  данни  трябва  да се 
изтеглят . 
▼B 
2.2.2.10 P o s i t i v e R e s p o n s e T r a n s f e r D a t a ( S I D 7 6 )  
DDP_012 VU изпраща  Positive Response Transfer Data в отговор  на 
Transfer Data Request. Съобщението  съдържа  заявените  
данни  с Transfer Response Parameter (TREP), съот­  
ветстващ  на TRТP на заявката . 
▼M1 
DDP_055 В първия  случай  (TREP 01 или 21) бордовото  
устройство  ще изпрати  данни , предназначени  да 
помогнат  на потребителя  на IDE при избора  на 
данните , които  иска  да изтегли . Съобщението  съдържа  
следната  информация : 
— сертификати  за сигурност , ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 285  
— идентификация  на превозното  средство , 
— актуалната  дата и час на бордовото  устройство , 
— най-ранната  и най-късната  дата за изтегляне  на 
данните  (данни  от бордовото  устройство ), 
— указване  за наличието  на карти  в бордовото  
устройство , 
— предишни  изтеглени  данни  към превозвач , 
— блокировки  от страна  на превозвача , 
— предишни  проверки . 
▼B 
2.2.2.11 R e q u e s t T r a n s f e r E x i t ( S I D 3 7 )  
DDP_013 IDE изпраща  съобщение  Request Transfer Exit, за да 
информира  VU, че сесията  за изтегляне  на данни  е 
приключена . 
2.2.2.12 P o s i t i v e R e s p o n s e R e q u e s t T r a n s f e r E x i t ( S I D 7 7 )  
DDP_014 VU изпраща  съобщение  Positive Response Request 
Transfer Exit, за да потвърди  получаването  на Request 
Transfer Exit.  
2.2.2.13 S t o p C o m m u n i c a t i o n R e q u e s t ( S I D 8 2 )  
DDP_015 IDE изпраща  съобщение  Stop Communication Request с 
цел преустановяване  на връзката  с VU.  
2.2.2.14 P o s i t i v e R e s p o n s e S t o p C o m m u n i c a t i o n ( S I D C 2 )  
DDP_016 VU изпраща  съобщение  Positive Response Stop Commu ­
nication, за да потвърди  получаването  на Stop Communi ­
cation Request.  
2.2.2.15 A c k n o w l e d g e S u b M e s s a g e ( S I D 8 3 )  
DDP_017 IDE изпраща  Acknowledge Sub Message с цел потвър­  
ждение  получаването  на различните  части  от съобще­  
нието , изпратени  под формата  на подсъобщения . 
Полето  за данни  съдържа  SID, получен  от VU, както  и 
следния  код от 2 байта : 
— MsgC + 1 потвърждава  правилното  получаване  на 
подсъобщение  номер  MsgC.  
Заявка  за изпращане  на следващото  подсъобщение , 
адресирано  от IDE до VU.  
— MsgC посочва  появяването  на проблем , който  засяга  
получаването  на подсъобщение  номер  MsgC.  
Заявка  за повторно  изпращане  на подсъобщение , 
адресирано  от IDE до VU.  
— FFFF заявява  прекъсване  на съобщението . 
IDE може  да използва  това, за да сложи  край  на 
предаването  на съобщението  от VU поради  каквато  
и да е причина . 
Възможно  е да се потвърди  последното  подсъобщение  
от съобщение  (байт  LЕN < 255), като се използва  някой  
от тези кодове . 
Отговорите  на VU, които  ще са съставени  от няколко  
подсъобщения , са: 
— Positive Response Transfer Data (SID 76)  ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 286  
2.2.2.16 N e g a t i v e R e s p o n s e ( S I D 7 F )  
DDP_018 VU изпраща  съобщение  Negative Response в отговор  на 
съобщенията  по-горе, ако не е в състояние  да удов­  
летвори  заявката . Полетата  за данни  на съобщението  
съдържат  SID на отговора  (7F), SID на заявката  и код, 
който  уточнява  причината  за отрицателния  отговор . 
Налични  са следните  кодове : 
— 10 — общо  отхвърляне  
Действието  не може  да се изпълни  по причина , 
която  не се разглежда  по-нататък . 
— 11 — услугата  не се поддържа  
SID на заявката  не се разбира . 
— 12 — подфункцията  не се поддържа  
DS_ или TRTP на заявката  не се разбира  или пред­  
аването  на подсъобщения  е приключило . 
— 13 — неправилна  дължина  на съобщение  
Дължината  на полученото  съобщение  е грешна . 
— 22 — неправилни  условия  или грешка , която  засяга  
последователността  на заявяването  
Заявената  услуга  не е активна  или последовател­  
ността  на съобщенията  за заявката  е неправилна . 
— 31 — недопустимост  на заявката  
Записването  (полето  за данни ) на параметъра  на 
заявката  не е валидно . 
— 50 — качването  на данни  не е прието  
Заявката  не може  да се изпълни  (VU се използва  в 
несвойствен  режим  на работа  или има някаква  
вътрешна  неизправност  на VU).  
— 78 — изчакване  на отговор  
Заявеното  действие  не може  да приключи  в опред­  
еленото  време  и VU няма  готовност  да приеме  друга  
заявка . 
▼M1 
— Данни  FA, които  не са на разположение  
Обектът  от данни  на заявка  за трансфер  на данни  не 
е достъпен  в бордовото  устройство  (например  не е 
поставена  карта ; получената  заявка  за изтегляне  на 
данни  от бордовото  устройство  от поколение  1 не е 
при проверка  на водача  от контролен  орган  на 
държава  извън  ЕС...). 
▼B 
2.2.3  Поток  на съобщенията  
При нормална  процедура  за изтегляне  на данни  потокът  на съоб­  
щенията  обикновено  е следният : 
IDE VU  
Start Communication Request  ⇨ 
⇦  Positive Response  
Start Diagnostic Service Request  ⇨ 
⇦  Positive Response  
Request Upload  ⇨ 
⇦  Positive Response  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 287  
IDE VU  
Transfer Data Request Overview  ⇨ 
⇦  Positive Response  
Transfer Data Request #2  ⇨ 
⇦  Positive Response #1  
Acknowledge Sub Message #1  ⇨ 
⇦  Positive Response #2  
Acknowledge Sub Message #2  ⇨ 
⇦  Positive Response #m  
Acknowledge Sub Message #m  ⇨ 
⇦  Positive Response (Data Field<255 Bytes)  
Acknowledge Sub Message (optional)  ⇨  
… 
Transfer Data Request #n  ⇨ 
⇦  Positive Response  
Request Transfer Exit  ⇨ 
⇦  Positive Response  
Stop Communication Request  ⇨ 
⇦  Positive Response  
2.2.4  Синхронизация  
DDP_019 При нормални  условия  на работа  се прилагат  следните  
параметри  за синхронизация , илюстрирани  на следната  
фигура : 
Фигура  1 
Поток  на съобщенията , синхронизация
  
където : 
P1 = междубайтово  време  за отговора  на VU,  
P2 = времето  между  края  на заявка  на IDE и началото  
на отговор  на VU или между  края  на потвър­  
ждаване  от IDE и начало  на следващ  отговор  от 
VU, 
P3 = времето  между  края  на отговор  на VU и началото  
на нова  заявка  на IDE, между  края  на отговор  на 
VU и началото  на потвърждаване  от IDE или 
между  края  на заявка  от IDE и началото  на нова  
заявка  от IDE, ако VU не даде  отговор , 
P4 = междубайтово  време  за заявка  на IDE,  
P5 = разширена  стойност  на Р3 за изтегляне  на данни  
от карти . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 288  
В следващата  таблица  са показани  разрешените  
стойности  за параметрите  за синхронизация  (разширен  
набор  от параметри  за синхронизация  KWP, използвани  
в случай  на физическо  адресиране  за по-бърза  връзка ). 
Синхронизация  Параметър  Долна  граница  
Стойност  (в ms)  Горна  граница  
Стойност  (в ms) 
P1 0  20  
P2 20  1 000 (*)  
P3 10  5 000  
P4 5  20  
P5 10  20 минути  
(*) ако VU отговори  с Negative Response, съдържащ  код със значение  „request correctly received, response 
pending“ („ правилно  получена  заявка , очаква  се отговор “), тази стойност  се разширява  до същата  
горна  стойност  на P3. 
2.2.5  Обработка  на грешки  
Ако се появи  грешка  по време  на обмена  на съобщения , схемата  за 
поток  на съобщенията  се променя  в зависимост  от устройството , 
което  е открило  грешката , и от съобщението , което  е породило  
тази грешка . 
На фигури  2 и 3 са показани  процедурите  за обработване  на 
грешки , които  се прилагат  съответно  за VU и IDE.  
2.2.5.1 S t a r t C o m m u n i c a t i o n p h a s e  
DDP_020 Ако IDE открие  грешка  по време  на Start Communication 
phase, както  на ниво  синхронизация , така и на ниво  
последователност  на битовете , тогава  то изчаква  за 
период  от P3 min, преди  да изпрати  отново  заявката . 
DDP_021 Ако VU открие  грешка  в последователността , която  
идва  от IDE, то не изпраща  никакъв  отговор  и изчаква  
друго  съобщение  Start Communication Request в рамките  
на период  от Р3 max.  
2.2.5.2 C o m m u n i c a t i o n p h a s e  
Могат  да се определят  две различни  процедури  за обработване  на 
грешки : 
1. VU открива  грешка  в предаването  от IDE  
DDP_022 VU извършва  анализ  на всяко  получено  съобщение , за 
да открие  евентуална  грешка  по синхронизирането , 
структурата  на байтовете  (например  нарушения , 
които  засягат  началните  битове  и битовете  за край ) 
или грешки  във връзка  с кадрите  (приемане  на грешен  
брой  байтове , грешен  байт  за контролна  сума ). 
DDP_023 Ако VU открие  една  от горепосочените  грешки , то не 
изпраща  никакъв  отговор  и не взема  под внимание  
полученото  съобщение . 
DDP_024 VU може  да открие  други  грешки , които  засягат  
структурата  или съдържанието  на полученото  
съобщение  (например  съобщението  не се поддържа ) 
даже  и ако съобщението  отговаря  на изискванията  за 
дължина  и контролна  сума ; в такъв  случай  VU трябва  
да отговори  на IDE със съобщение  Negative Response, 
което  указва  характера  на грешката . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 289  
Фигура  2 
Обработка  на грешки  в VU
 
2. IDE открива  грешка  при предаването  от VU 
DDP_025 IDE извършва  анализ  на всяко  получено  съобщение , 
за да открие  евентуална  грешка  по синхронизирането , 
структурата  на байтовете  (например  нарушения , 
които  засягат  началните  битове  и битовете  за край ) 
или грешки  във връзка  с кадрите  (приемане  на грешен  
брой  байтове , грешен  байт  за контролна  сума ). 
DDP_026 IDE открива  грешки  при последователността , като 
например  погрешно  увеличение  на брояча  на 
подсъобщения  в последователно  получени  съоб­  
щения . 
DDP_027 Ако IDE открие  грешка  или ако VU не му изпрати  
никакъв  отговор  в срок  от максимум  Р2, съобщението  
за заявка  ще бъде  отново  изпратено  общо  най-много  
три пъти . За целите  на това откриване  на грешки  
всяко  потвърждаване  за подсъобщение  ще се 
разглежда  като заявка  до VU. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 290  
DDP_028 IDE трябва  да изчака  в продължение  най-малко  на 
Р3min, преди  започване  на предаване  на данни ; 
времето  за изчакване  се измерва  от последната  
поява  на бит за край  след  откриване  на съответната  
грешка . 
Фигура  3 
Обработка  на грешки  на ниво  на IDE
  
2.2.6  Съдържание  на съобщенията  за отговор  
В този параграф  е определено  съдържанието  на полетата  за данни  
на различните  положителни  съобщения  за отговор . 
Елементите  от данни  са определени  в допълнение  1 (Речник  на 
данните ). 
Забележка : при изтеглените  данни  от поколение  2 всеки  елемент  
от данни  от най-високо  ниво  е представен  от масив  записи  дори  
ако съдържа  само  един  запис . Масивът  записи  започва  със 
заглавна  част, която  съдържа  типа , размера  и броя  записи . 
Масивите  записи  имат  наименованието „…RecordArray“ ( със 
заглавна  част) в следващите  таблици . 
2.2.6.1 P o s i t i v e R e s p o n s e T r a n s f e r D a t a O v e r v i e w  
DDP_029  ►M1 Полето  за данни  на съобщението  „Positive 
Response Transfer Data Overview“ трябва  да дава 
данните  по-долу  по следния  ред по SID 76 Hex, TR ЕP 
01 или 21 Hex и съответните  критерии  за разделяне  и 
преброяване  на подсъобщенията : ◄ ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 291  
Структура  на данните  от поколение  1 (TREP 01 Hex)  
▼B 
Елемент  от данни  Коментар
  
Сертификати  за сигурност  на VU
 
Идентификация  на превозното  средство
  
Актуална  дата и час на VU
 
Период  за изтегляне  на данни
  
Тип карти , поставени  в VU
 
Предишни  изтеглени  данни  от VU
 
Всички  съхранени  блокировки  от страна  на 
превозвача . Ако тази част е празна , се 
изпраща  само  noOfLocks = 0
  
Всички  съхранени  в VU контролни  записи . 
Ако тази част е празна , се изпраща  само  
noOfControls = 0
  
RSA подпис  на всички  данни  (освен  сертифи­  
катите ), започвайки  от VehicleIdentification ­
Number до последния  байт  на последния  
VuControlActivityData  
▼M1 
Структура  на данните  от поколение  2 (TREP 21 Hex)  
▼B 
Елемент  от данни  Коментар
  
Сертификат  на държава  членка
  
Сертификат  за VU
 
Идентификация  на превозното  средство
  
Регистрационен  номер  на превозното  
средство
  
Актуална  дата и час на VU
 
Период  за изтегляне  на данни
  
Тип карти , вкарани  в VU
 
Предишни  изтеглени  данни  от VU
 
Всички  съхранени  блокировки  от страна  на 
превозвача . Ако тази част е празна , се 
изпраща  заглавна  част на масив  с noOf­
Records = 0
  
Всички  съхранени  в VU контролни  записи . 
Ако тази част е празна , се изпраща  заглавна  
част на масив  с noOfRecords = 0
  
ЕСС  подпис  на всички  предходни  данни  
освен  сертификатите  
2.2.6.2 P o s i t i v e R e s p o n s e T r a n s f e r D a t a A c t i v i t i e s  
DDP_030  ►M1 Полето  за данни  на съобщението  „Positive 
Response Transfer Data Activities“ трябва  да дава 
данните  по-долу  по следния  ред по SID 76 Hex, TR ЕP 
02 или 22 Hex и съответните  критерии  за разделяне  и 
преброяване  на подсъобщенията : ◄ ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 292  
Структура  на данните  от поколение  1 (TREP 02 Hex)  
▼B 
Елемент  от данни  Коментар
  
Дата  на деня , за който  са изтеглени  данни
  
Километражен  брояч  в края  на деня , за който  са 
изтеглени  данни
  
Данни  за циклите  на поставяне  и изваждане  на 
картите . 
— Ако тази част не съдържа  данни , се изпраща  
само  noOfVuCardIWRecords = 0. 
— Когато  VuCardIWRecord обхваща  период , който  
започва  преди  00:00 ч. (поставяне  на картата  в 
предходния  ден) или приключва  след  24:00 ч. 
(изваждане  на картата  на следващия  ден), този 
елемент  от данни  се появява  цялостно  в 
записите  за двата  съответни  дни
 
Статус  на процепите  в 00:00 ч. и промени  на 
дейността , записани  за деня , за който  са изтеглени  
данни
  
Данни  във връзка  с местоположенията , записани  за 
деня , за който  са изтеглени  данни . Ако тази част е 
празна , се изпраща  само  noOfPlaceRecords = 0
  
Данни  във връзка  със специфични  условия , записани  
за деня , за който  са изтеглени  данни . Ако тази част е 
празна , се изпраща  само  noOfSpecificCondition ­
Records = 0
  
RSA подпис  на всички  данни , започвайки  от 
TimeReal до последния  байт  на последния  запис  за 
специфично  условие  
▼M1 
Структура  на данните  от поколение  2 (TREP 22 Hex)  
▼B 
Елемент  от данни  Коментар
  
Дата  на деня , за който  са изтеглени  данни
  
Километражен  брояч  в края  на деня , за който  са 
изтеглени  данни
  
Данни  за циклите  на поставяне  и изваждане  на 
картите . 
— Ако тази част не съдържа  налични  данни , се 
изпраща  заглавна  част на масив  с noOfRecords 
= 0. 
— Когато  VuCardIWRecord обхваща  период , който  
започва  преди  00:00 ч. (поставяне  на картата  в 
предходния  ден) или приключва  след  24:00 ч. 
(изваждане  на картата  на следващия  ден), този 
елемент  от данни  се появява  цялостно  в 
записите  за двата  съответни  дни.
 
Статус  на процепите  в 00:00 ч. и промени  на 
дейността , записани  за деня , за който  са изтеглени  
данни
  
Данни  във връзка  с местоположенията , записани  за 
деня , за който  са изтеглени  данни . Ако тази част е 
празна , се изпраща  заглавна  част на масив  с noOf­
Records = 0  
▼M1
 
Местоположения  на превозното  средство  по GNSS, 
когато  общото  време  на управление  на МПС  
достигне  кратно  число  на три часа. Ако тази част е 
празна , се изпраща  заглавна  част на масив  с noOf­
Records = 0.  ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 293  
Елемент  от данни  Коментар
  
Данни  във връзка  със специфични  условия , записани  
за деня , за който  са изтеглени  данни . Ако тази част е 
празна , се изпраща  заглавна  част на масив  с noOf­
Records = 0
  
ЕСС  подпис  на всички  предходни  данни  
2.2.6.3 P o s i t i v e R e s p o n s e T r a n s f e r D a t a E v e n t s a n d F a u l t s  
DDP_031  ►M1 Полето  за данни  на съобщението  „Positive 
Response Transfer Data Events and Faults“ трябва  да 
дава данните  по-долу  по следния  ред по SID 76 Hex, 
TRЕP 03 или 23 Hex и съответните  критерии  за 
разделяне  и преброяване  на подсъобщенията : ◄ 
▼M1 
Структура  на данните  от поколение  1 (TREP 03 Hex)  
▼B 
Елемент  от данни  Коментар
  
Всички  записани  или текущи  неизправности  в 
VU. 
Ако тази част е празна , се изпраща  само  
noOfVuFaults = 0
  
Всички  записани  или текущи  събития  в VU 
(освен  превишаването  на скоростта ). 
Ако тази част е празна , се изпраща  само  
noOfVuEvents = 0
  
Данни  във връзка  с последната  проверка  за 
превишаване  на скоростта  (стойност  по 
подразбиране , ако няма  данни )
 
Всички  събития  „превишаване  на скоростта “, 
записани  в VU. 
Ако тази част е празна , се изпраща  само  
noOfVuOverSpeedingEvents = 0
  
Всички  събития  „сверяване  на часовника “, 
записани  в VU (извън  рамките  на пълно  
калибриране ). 
Ако тази част е празна , се изпраща  само  
noOfVuTimeAdjRecords = 0
  
RSA подпис  на всички  данни , започвайки  от 
noOfVuFaults до последния  байт  на последния  
запис  за сверяване  на часовника  
▼M1 
Структура  на данните  от поколение  2 (TREP 23 Hex)  
▼B 
Елемент  от данни  Коментар
  
Всички  записани  или текущи  неизправности  в 
VU. 
Ако тази част е празна , се изпраща  заглавна  
част на масив  с noOfRecords = 0
  
Всички  записани  или текущи  събития  в VU 
(освен  превишаването  на скоростта ). 
Ако тази част е празна , се изпраща  заглавна  
част на масив  с noOfRecords = 0
  
Данни  във връзка  с последната  проверка  за 
превишаване  на скоростта  (стойност  по 
подразбиране , ако няма  данни )
 
Всички  събития  „превишаване  на скоростта “, 
записани  в VU. 
Ако тази част е празна , се изпраща  заглавна  
част на масив  с noOfRecords = 0  ▼B
02016R0799 — BG — 26.02.2020 — 002.001 — 294 
Елемент  от данни  Коментар
  
Всички събития „ сверяване на часовника “, 
записани в VU (извън  рамките на пълно 
калибриране ). 
Ако тази част е празна , се изпраща заглавна 
част на масив с noOfRecords = 0  
▼M1__________  
▼B
ЕСС подпис на всички предходни данни 
2.2.6.4 P o s i t i v e R e s p o n s e T r a n s f e r D a t a D e t a i l e d S p e e d  
DDP_032 ►M1 Полето за данни на съобщението „Positive 
Response Transfer Data Detailed Speed“ трябва да дава 
данните по-долу по следния ред по SID 76 Hex, TR ЕP 
04 или 24 Hex и съответните критерии за разделяне  и 
преброяване на подсъобщенията : ◄ 
▼M1
Структура на данните от поколение 1 (TREP 04)  
▼B
Елемент  от данни  Коментар
  
Всички подробни данни за скоростта  в VU 
(един блок с данни за скоростта  на минута , 
през която превозното средство  е в движение ) 
60 стойности на скоростта  на минута (една на 
секунда )
 
RSA подпис на всички данни, започвайки от 
noOfSpeedBlocks до последния байт на 
последния блок данни за скоростта  
▼M1
Структура на данните от поколение 2 (TREP 24)  
▼B
Елемент  от данни  Коментар
  
Всички подробни данни за скоростта  в VU 
(един блок с данни за скоростта  на минута , 
през която превозното средство  е в движение ) 
60 стойности на скоростта  на минута (една на 
секунда )
 
ЕСС подпис на всички предходни данни 
2.2.6.5 P o s i t i v e R e s p o n s e T r a n s f e r D a t a T e c h n i c a l D a t a  
DDP_033 ►M1 Полето за данни на съобщението „Positive 
Response Transfer Data Technical Data“ трябва да дава 
данните по-долу по следния ред по SID 76 Hex, TR ЕP 
05 или 25 Hex и съответните критерии за разделяне  и 
преброяване на подсъобщенията : ◄ ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 295  
Структура  на данните  от поколение  1 (TREP 05)  
▼B 
Елемент  от данни  Коментар
  
Всички  записи  за калибриране , съхранени  в 
VU
 
RSA подпис  на всички  данни , започвайки  от 
vuManufacturerName до последния  байт  на 
последния  VuCalibrationRecord  
▼M1 
Структура  на данните  от поколение  2 (TREP 25)  
▼B 
Елемент  от данни  Коментар
  
Всички  сдвоявания  с датчика  за движение  
(MS), съхранени  в VU
 
Всички  свързвания  с външното  устройство  за 
GNSS, съхранени  в VU
 
Всички  записи  за калибриране , съхранени  в 
VU
 
Всички  данни  за поставяне  на карти , 
съхранени  в VU
 
ЕСС  подпис  на всички  предходни  данни  
2.3. Съхранение  на файлове  върху  ESM  
DDP_034 Ако дадена  сесия  за изтегляне  на данни  е включвала  
прехвърляне  на данни  от VU, IDE съхранява  в един - 
единствен  физически  файл  всички  данни , получени  от 
VU по време  на тази сесия  за изтегляне  на данни  в 
рамките  на съобщенията  Positive Response Transfer 
Data. Съхранените  данни  изключват  заглавните  части  
на съобщенията , броячите  на подсъобщения , празните  
подсъобщения  и контролните  суми , но включват  SID и 
TREP (на първото  подсъобщение , при положение  че има 
няколко  подсъобщения ). 
3. ПРОТОКОЛ  ЗА ИЗТЕГЛЯНЕ  НА ДАННИ  ОТ ТАХОГ­  
РАФСКИТЕ  КАРТИ  
3.1. Обхват  
В настоящия  параграф  е описано  директното  изтегляне  на данни  
от тахографска  карта  към IDE. IDE не е част от сигурната  среда ; 
ето защо  не се извършва  удостоверяване  между  картата  и IDE.  
3.2. Определения  
Сесия  за изтегляне  на данни : всеки  път, когато  се извършва  
изтегляне  на данни  от IСС. 
Тази  сесия  обхваща  цялата  
процедура  от инициали­  
зацията  на ICC чрез IFD до 
дезактивирането  на ICC 
(изваждане  на картата  или 
следващо  инициализиране ). ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 296  
Подписан  файл  за данни : файл  от ICC. Този  файл  се 
прехвърля  като обикновен  
текст  към IFD. Върху  ICC 
файлът  се хешира  и 
подписва , а подписът  се 
прехвърля  към IFD.  
3.3. Изтегляне  на данни  от карта  
▼M1 
DDP_035 Изтеглянето  на данни  от тахографска  карта  съдържа  
следните  операции : 
— изтегляне  на общата  информация  на картата  в EF
 
и
 . Тази  информация  е незадължителна  и 
не е защитена  с цифров  подпис ; 
— (за тахографски  карти  от първо  и второ  поколение ) 
изтегляне  на EF в рамките  на
 :  
— изтегляне  на EF
  и
 
. Тази  информация  не е 
защитена  с цифров  подпис . 
Тези  файлове  трябва  задължително  да се изтеглят  
за всяка  сесия  за изтегляне  на данни ; 
— изтегляне  на останалите  елементарни  файлове  с 
приложни  данни  (в рамките  на
 
) освен  EF
  
. Тази  информация  е 
защитена  с цифров  подпис  съгласно  общите  
механизми  за сигурност  от допълнение  11, част 
А; 
— задължително  е да се изтеглят  поне
  
и
 
за всяка  сесия  за 
изтегляне  на данни ; 
— когато  се извършва  изтегляне  на данни  от карта  
на водач , е задължително  също  да се изтеглят  
следните  EF:
 
— (само  за тахографски  карти  от второ  поколение ) с 
изключение  на случаите , когато  изтеглянето  на 
данни  от карта  на водач , вкарана  в бордовото  
устройство , се извършва  при проверка  на 
водача  от контролен  орган  на държава  извън  
ЕС с контролна  карта  от първо  поколение , 
изтегляне  на EF в рамките  на
 
: 
— изтегляне  на EF CardSignCertificate, CA_Certi ­
ficate и Link_Certificate ( ако е наличен ). Тази  
информация  не е защитена  с цифров  подпис . 
Тези  файлове  трябва  задължително  да се 
изтеглят  за всяка  сесия  за изтегляне  на данни ; 
— изтегляне  на останалите  елементарни  файлове  
с приложни  данни  (в рамките  на
 
) освен  EF
  
. Тази  информация  е 
защитена  с цифров  подпис  съгласно  общите  
механизми  за сигурност  от допълнение  11, 
част Б. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 297  
— задължително  е да се изтеглят  поне  EF 
Application_Identification и Identification за 
всяка  сесия  за изтегляне  на данни ; 
— когато  се извършва  изтегляне  на данни  от 
карта  на водач , е задължително  също  да се 
изтеглят  следните  EF:
 
— когато  се извършва  изтегляне  на данни  от 
карта  на водач , трябва  да се актуализира  
датата  на
 в EF
  
, както  и в
 
и ако е уместно  — в DF
  
. 
— когато  се извършва  изтегляне  на данни  от 
карта  за монтаж  и настройки , трябва  да се 
инициализира  броячът  за калибриране  в EF
 
, както  и в
 
и ако е уместно  — в DF
  
. 
— когато  се изтеглят  данни  от карта  за монтаж  и 
настройки , не трябва  да се изтеглят  данните  
от
 в
 
и ако е уместно  — в DF
  
. 
▼B 
3.3.1  Последователност  при инициализиране  
DDP_036 IDE трябва  да започне  последователността , както  
следва : 
Карта  Посока  IDE/IFD  Значение /Забележки  
⇦ Инициализация  на хардуера  
ATR ⇨ 
Възможно  е да се използва  РРS, за да премине  към по- 
висока  скорост  за предаване  на данни , при условие  че 
ICC я поддържа . 
3.3.2  Последователност  за неподписани  файлове  с данни  
DDP_037  ►M1 Последователността  за изтегляне  на данни  от EF 
ICC, IC, Card_Certificate ( или CardSignCertificate за DF 
Tachograph_G2), CA_Certificate и Link_Certificate ( само  
за DF Tachograph_G2) е, както  следва : ◄ 
Карта  Посока  IDE/IFD  Значение /Забележки  
⇦ Select File  Изберете  идентификаторите  
на файлове  
OK ⇨ 
⇦ Read Binary  Ако файлът  съдържа  
повече  данни  от капацитета  
на буферната  памет  на 
четящото  устройство  или 
картата , командата  трябва  
да се повтори , докато  
целият  файл  се прочете . 
Данни  от файла  
OK ⇨ Съхранение  на данните  
върху  ЕSM Съгласно  3.4  Data storage 
format  ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 298  
Забележка  1: преди  да се избере  Card_Certificate ( или 
CardSignCertificate) EF, трябва  да се избере  тахог­  
рафското  приложение  (избор  от страна  на AID).  
Забележка  2: изборът  и прочитането  на файл  може  да 
се извършат  и в една  стъпка , като се използва  командата  
Read Binary с кратък  EF идентификатор . 
3.3.3  Последователност  за подписани  файлове  с данни  
DDP_038 Трябва  да се използва  следната  последователност  за 
всеки  от следните  файлове , от които  трябва  да се 
изтеглят  данните  с техния  подпис : 
▼M1 
Карта  Посока  IDE/IFD  Значение /Забележки
  
Select File  
OK
 
Perform Hash of File  — Позволява  да се 
изчисли  хеш-стой­  
ността  по отношение  
на съдържанието  на 
избрания  файл , като се 
използва  хеш-алгори­  
тъмът , посочен  в 
допълнение  11, част А 
или Б. Това  не е 
команда  ISO.  
Изчислява  се Hash of 
File и временно  се 
съхранява  хеш-стой­  
ността  
OK
 
Read Binary  Ако файлът  съдържа  
повече  данни  от капацитета  
на буферната  памет  на 
четящото  устройство  или 
картата , командата  трябва  
да се повтори , докато  се 
прочете  целият  файл . 
Данни  от файла  
OK
 Получените  данни  се 
съхраняват  върху  ESM  Съгласно  3.4.  Формат  за 
съхранение  на данните
  
PSO: Compute Digital 
Signature  
Изпълнение  на 
операция  за 
сигурност  „Compute 
Digital Signature“, 
като се използва  
временно  съхра­  
нената  хеш-стойност  
Подпис  
OK
 Добавяне  на данни  към 
тези, които  са съхранени  
преди  това върху  ЕSM съгласно  3.4. Формат  за 
съхранение  на данните  
▼B 
Забележка : изборът  и прочитането  на файл  могат  да се 
извършат  и в една  стъпка , като се използва  командата  
Read Binary с кратък  EF идентификатор . В този случай  
може  да се избере  и прочете  EF, преди  да се приложи  
командата  Perform Hash of File.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 299  
3.3.4  Последователност  за инициализиране  на брояча  за калибриране  
DDP_039 Последователността  на инициализиране  на брояча
  
в EF
  
в карта  за монтаж  и настройки  е 
следната : 
Карта  Посока  IDE/IFD  Значение /Забележки  
⇦ Select File  EF 
Card_Download  Изберете  идентификаторите  
на файлове  
OK ⇨ 
⇦ Update Binary  
NoOfCalibrationsSince ­
Download = ‘00 00’  
Инициализира  броя  на 
изтеглянията  на данни  
от картата  
OK ⇨ 
Забележка : изборът  и актуализацията  на файл  могат  да 
се извършат  и в една  стъпка , като се използва  командата  
Update Binary с кратък  EF идентификатор . 
3.4. Формат  за съхранение  на данните  
3.4.1  Въведение  
DDP_040 Изтеглените  данни  трябва  да се съхраняват  при следните  
условия : 
— съхранението  на данните  трябва  се извършва  
прозрачно . Това  означава , че при съхранението  
трябва  да се запазят  редът  на байтовете  и редът  на 
битовете  в рамките  на байта , които  се прехвърлят  от 
картата ; 
— всички  файлове  на картата , от която  са изтеглени  
данни  в рамките  на една  сесия  за изтегляне  на 
данни , се съхраняват  в един  файл  на ESM.  
3.4.2  Формат  на файловете  
DDP_041 Форматът  на файловете  представлява  съединяване  на 
няколко  обекта  ТLV. 
DDP_042 Тагът  за EF трябва  да е FID плюс  допълнението „00“.  
DDP_043 Тагът  на EF подпис  трябва  да е FID на файла  плюс  
допълнението „01“.  
DDP_044 Дължината  е стойност  от два байта . Стойността  
определя  броя  на байтовете  в полето  за стойност . Стой­  
ността „FF FF“ в полето  за дължина  се запазва  за по- 
нататъшна  употреба . 
DDP_045 Когато  не е изтеглен  файл , не се запазва  никаква  
информация  за файла  (без таг и без дължина  нула ). 
▼M1 
DDP_046 Всеки  подпис  трябва  да бъде  съхранен  под формата  на 
обект  ТLV веднага  след  обекта  ТLV, който  съдържа  
данните  на файла . 
Определение  Значение  Дължина  
FID (2 байта ) || „00“  Таг за EF (FID) в
 
или за 
общата  информация  на 
картата  3 байта  
FID (2 байта ) || „01“  Таг за подпис  на EF (FID) 
в DF
 3 байта  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 300  
Определение  Значение  Дължина  
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
 
▼B 
4. ИЗТЕГЛЯНЕ  НА ДАННИ  ОТ ТАХОГРАФСКА  КАРТА  ЧРЕЗ  
БОРДОВО  УСТРОЙСТВО  
DDP_047 VU трябва  да позволява  изтеглянето  на съдържанието  на 
карта  на водач , поставена  в свързано  IDE.  
DDP_048 IDE трябва  да изпрати  съобщение  „Transfer Data Request 
Card Download“ до VU, за да се започне  този режим  (вж. 
2.2.2.9).  
▼M1 
DDP_049 Карти  на водач  от първо  поколение : Данните  трябва  да 
се изтеглят , като се използва  протоколът  за изтегляне  на 
данни  от първо  поколение , и изтеглените  данни  трябва  
да са със същия  формат  като данните , изтеглени  от 
бордово  устройство  от първо  поколение . 
Карти  на водач  от второ  поколение : Тогава  бордовото  
устройство  трябва  да извърши  цялостното  изтегляне  на 
данни  от картата , файл  по файл , в съответствие  с 
протокола  за изтегляне  на данни  от карта , определен  в 
параграф  3, както  и да изпрати  към IDE всички  данни , 
които  са получени  от картата  в съответния  файлов  
формат  ТLV (вж. 3.4.2) и са капсулирани  в съобщение  
„Positive Response Transfer Data“.  
▼B 
DDP_050 IDE трябва  да извлече  данните  от картата  от съоб­  
щението  „Positive Response Transfer Data“ ( като 
премахне  всички  заглавни  части , SID, ТRЕР, броячи  на 
подсъобщения  и контролни  суми ) и да ги запише  в един  
физически  файл , както  е описано  в параграф  2.3.  
DDP_051 След  това, в зависимост  от случая , VU трябва  да извъ - 
рши актуализиране  на файла
  
или
 на картата  на водач . ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 301  
Допълнение  8 
ПРОТОКОЛ  ЗА КАЛИБРИРАНЕ  
СЪДЪРЖАНИЕ  
1. ВЪВЕДЕНИЕ  
2. ПОНЯТИЯ , ОПРЕДЕЛЕНИЯ  И СПРАВОЧНИ  МАТЕРИАЛИ  
3. ПРЕГЛЕД  НА УСЛУГИТЕ  
3.1. Налични  услуги  
3.2. Кодове  за отговор  
4. СЪОБЩИТЕЛНИ  УСЛУГИ  
4.1. Услуга  StartCommunication  
4.2. Услуга  StopCommunication  
4.2.1 Описание  на съобщенията  
4.2.2 Формат  на съобщенията  
4.2.3 Определяне  на параметрите  
4.3. Услуга  TesterPresent  
4.3.1 Описание  на съобщенията  
4.3.2 Формат  на съобщенията  
5. УСЛУГИ  ЗА УПРАВЛЕНИЕ  
5.1. Услуга  StartDiagnosticSession  
5.1.1 Описание  на съобщенията  
5.1.2 Формат  на съобщенията  
5.1.3 Определяне  на параметрите  
5.2. Услуга  SecurityAccess  
5.2.1 Описание  на съобщенията  
5.2.2 Формат  на съобщенията  — SecurityAccess — requestSeed  
5.2.3 Формат  на съобщенията  — SecurityAccess — sendKey  
6. УСЛУГИ  ЗА ПРЕДАВАНЕ  НА ДАННИ  
6.1. Услуга  ReadDataByIdentifier  
6.1.1 Описание  на съобщенията  
6.1.2 Формат  на съобщенията  
6.1.3 Определяне  на параметрите  
6.2. Услуга  WriteDataByIdentifier  
6.2.1 Описание  на съобщенията  
6.2.2 Формат  на съобщенията  
6.2.3 Определяне  на параметрите  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 302  
7. КОНТРОЛ  НА ИЗПИТВАТЕЛНИТЕ  ИМПУЛСИ  — 
ФУНКЦИОНАЛЕН  БЛОК  ЗА КОНТРОЛ  НА ВХОДНИТЕ /ИЗ­ 
ХОДНИТЕ  ДАННИ  
7.1. Услуга  InputOutputControlByIdentifier  
7.1.1 Описание  на съобщенията  
7.1.2 Формат  на съобщенията  
7.1.3 Определяне  на параметрите  
8. ФОРМАТИ  НА DATARECORDS  
8.1. Диапазони  от предавани  параметри  
8.2. Формати  на dataRecords  
1. ВЪВЕДЕНИЕ  
В това допълнение  са разгледани  начините  на обмен  на данни  
между  бордово  устройство  и изпитвателно  оборудване  
посредством  линията  К, която  представлява  част от интерфейса  
за калибриране , описан  в допълнение  6. В настоящото  допълнение  
е описан  също  контролът  на линията  за входни /изходни  сигнали  на 
съединителя  за калибриране . 
Установяването  на връзките  по линия  К е дадено  в раздел  4 „Com­
munication Services“.  
В настоящото  допълнение  е използвана  концепцията  за „диаг­  
ностични  сесии “ за определяне  на обхвата  на контрола  на 
линията  К при различни  условия . Сесията  по подразбиране  е 
„StandardDiagnosticSession“, при която  е възможно  всички  данни  
да се прочетат  от бордово  устройство , но никакви  данни  не могат  
да бъдат  записани  върху  него . 
Избирането  на диагностична  сесия  е описано  в раздел  5 „Mana­
gement Services“.  
Настоящото  допълнение  е от значение  за двете  поколения  бордови  
устройства  и карти  за монтаж  и настройки  в съответствие  с изиск­  
ванията  към оперативната  съвместимост  по този регламент . 
CPR_001 „ECUProgrammingSession“ дава възможност  да се 
въведат  данните  в бордовото  устройство . Освен  това, 
когато  се въвеждат  данни  за калибриране , бордовото  
устройство  трябва  да е в режим  на работа  „КАЛИБРИ­  
РАНЕ “. 
Трансферът  на данни  по линията  К е описан  в раздел  6 
„Data Transmission Services“. Форматите  на прехвър­  
лените  данни  са дадени  подробно  в раздел  8 „data­
Records formats“.  
CPR_002 „ECUAdjustmentSession“ дава възможност  да се избере  
режима  на работа  за линията  за входни /изходни  сигнали  
за калибриране  чрез интерфейса  на линията  К. 
Контролът  на линията  за входни /изходни  сигнали  за 
калибриране  е описан  в раздел  7 „Control of Test 
Pulses — Input/Output Control functional unit“.  
CPR_003 В настоящия  документ  адресът  на изпитвателното  
оборудване  се посочва  като „tt“. Въпреки  че е 
възможно  да има предпочитани  адреси  за изпит­  
вателното  оборудване , бордовото  устройство  трябва  да 
отговаря  правилно  на всеки  адрес  на изпитвателно  
оборудване . Физическият  адрес  на бордовото  
устройство  е 0xEE.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 303  
2. ПОНЯТИЯ , ОПРЕДЕЛЕНИЯ  И СПРАВОЧНИ  МАТЕРИАЛИ  
Протоколите , съобщенията  и кодовете  за грешка  се основават  
главно  на проект  на стандарт  ISO 14229-1 ( Пътни  превозни  
средства . Системи  за диагностика . Част  1: услуги  за диагностика , 
версия  6 от 22 февруари  2001 г.). 
Кодирането  на байтове  и други  шестнадесетични  стойности  се 
използват  за идентификаторите  на услуги , служебните  заявки  и 
отговори  и стандартните  параметри . 
„Изпитвателно  оборудване “ е оборудването , което  се използва  за 
въвеждане  на данни  за програмиране /калибриране  в бордовото  
устройство . 
Понятията  „клиент “ и „сървър “ се отнасят  съответно  за изпит­  
вателното  оборудване  и бордовото  устройство . 
Понятието  UCE е „електронен  блок  за управление “ и се отнася  за 
бордовото  устройство . 
Справочни  материали : 
▼M1 
ISO 14230-2: Пътни  превозни  средства . Системи  за диагностика . 
Протокол  „Keyword 2000“. Част  2: канален  слой . 
Първо  издание : 1999 г. 
▼B 
3. ПРЕГЛЕД  НА УСЛУГИТЕ  
3.1. Налични  услуги  
В следващата  таблица  са представени  услугите , които  са налични  в 
тахографа  и са определени  в настоящия  документ . 
CPR_004 В тази таблица  е посочено  кои са услугите  на 
разположение  по време  на активна  диагностична  сесия . 
— В първата  колона  са дадени  наличните  услуги . 
— Във втората  колона  е посочен  номерът  на раздела  в 
настоящото  допълнение , където  са представени  
допълнителни  данни  за услугата . 
— В третата  колона  са указани  стойностите  за иден­  
тификаторите  на услугите  за съобщенията  за заявка . 
— В четвъртата  колона  са дадени  услугите  на „Stan­
dardDiagnosticSession“ (SD) , които  трябва  да се 
изпълняват  във всяко  бордово  устройство . 
— В петата  колона  са уточнени  услугите  на „ECUAd ­
justmentSession“ (ECUAS) , които  трябва  да се 
изпълняват , за да се даде  възможност  за контрол  
на линията  за входни /изходни  сигнали  от предния  
панел  на съединителя  за калибриране  на бордовото  
устройство . 
— В шестата  колона  са посочени  услугите  на „ECU­
ProgrammingSession“ (ECUPS) , които  трябва  да се 
изпълняват , за да се даде  възможност  за програ­  
миране  на параметрите  в бордовото  устройство . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 304  
Таблица  1 
Обобщаваща  таблица  за стойностите  на идентификаторите  на услуги  
Диагностични  сесии  
Наименование  на диагностичната  
услуга  Раздел  
№ Стойности  за 
съобщенията  
за заявка  за 
SId SD ECUAS  ECUPS  
StartCommunication  4.1  81  ■ ■ ■ 
StopCommunication  4.2  82  ■ 
TesterPresent  4.3  3E  ■ ■ ■ 
StartDiagnosticSession  5.1  10  ■ ■ ■ 
SecurityAccess  5.2  27  ■ ■ ■ 
ReadDataByIdentifier  6.1  22  ■ ■ ■ 
WriteDataByIdentifier  6.2  2E  ■ 
InputOutputControlByIdentifier  7.1  2F  ■ 
■ Този  символ  указва , че услугата  е задължителна  в тази диагностична  сесия . 
Няма  символ , който  да посочва , че съответната  услуга  не е разрешена  в тази 
диагностична  сесия . 
3.2. Кодове  за отговор  
Кодовете  за отговор  са определени  за всяка  услуга . 
4. СЪОБЩИТЕЛНИ  УСЛУГИ  
Някои  услуги  са необходими  за установяване  и поддържане  на 
връзката . Те не се появяват  в приложния  слой . В следващата  
таблица  са посочени  наличните  услуги : 
Таблица  2 
Съобщителни  услуги  
Наименование  на услугата  Описание  
StartCommunication  Клиентът  заявява  започване  на съоб­  
щителна  сесия  със сървъра (ите). 
StopCommunication  Клиентът  заявява  прекъсване  на 
текущата  съобщителна  сесия . 
TesterPresent  Клиентът  указва  на сървъра , че е все 
още на линия . 
CPR_005 Услугата  StartCommunication се използва  за започване  на 
връзка . Изпълнението  на всяка  услуга  предполага  уста­  
новяване  на връзка  и избор  на параметри  на връзката , 
подходящи  за желания  режим . 
4.1. Услуга  StartCommunication  
CPR_006 При получаване  на примитив  за указване  StartCommuni ­
cation бордовото  устройство  проверява  дали  заявената  
съобщителна  връзка  може  да се осъществи  при 
дадените  условия . Валидните  условия  за осъществяване  
на съобщителна  връзка  са описани  в документ  ISO 
14230-2.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 305  
CPR_007 След  това бордовото  устройство  трябва  да изпълни  
всички  необходими  действия  за осъществяване  на съоб­  
щителната  връзка  и да изпрати  примитив  за отговор  
StartCommunication с избраните  параметри  за поло­  
жителен  отговор . 
CPR_008 Ако едно  вече инициализирано  бордово  устройство  (и 
влязло  в диагностична  сесия ) получи  нова  заявка  за Star­
tCommunication ( например  поради  повторно  стартиране  
при грешка  в изпитвателното  оборудване ), тази заявка  
трябва  да бъде  приета  и устройството  да бъде  реинициа­  
лизирано . 
CPR_009 Ако по една  или друга  причина  осъществяването  на 
съобщителната  връзка  се окаже  невъзможно , бордовото  
устройство  трябва  да продължи  да работи  по същия  
начин , както  непосредствено  преди  опита  за осъщест­  
вяване  на съобщителна  връзка . 
CPR_010 Съобщението  за заявка  за StartCommunication трябва  да 
се адресира  физически . 
CPR_011 Инициализирането  на бордовото  устройство  за услугите  
се осъществява  чрез „бързо  инициализиране “: 
— има време  на активност /неактивност  преди  всяко  
действие ; 
— след  това изпитвателното  оборудване  изпраща  
конфигурация  за инициализиране ; 
— цялата  информация  за установяване  на връзка  се 
съдържа  в отговора  на бордовото  устройство . 
CPR_012 След  приключване  на инициализирането : 
— стойностите , които  са определени  за всички  съоб­  
щителни  параметри , са описани  в таблица  4 в зави­  
симост  от ключовите  байтове ; 
— бордовото  устройство  изчаква  първата  заявка  от 
изпитвателното  оборудване ; 
— бордовото  устройство  работи  в диагностичен  режим  
по подразбиране , тоест  в StandardDiagnosticSession;  
— линията  за входни /изходни  сигнали  за калибриране  
се намира  в състояние  по подразбиране , тоест  е 
дезактивирана . 
CPR_014 Скоростта  за предаване  на данни  по линията  К трябва  да 
е 10 400 бода . 
CPR_016 Бързата  инициализация  се задейства  от изпитвателното  
оборудване , изпращащо  сигнал  за активиране  (Wup) по 
линията  К след  период  на неактивност  на линията  К, 
последван  от времеви  период  Tinil. Изпитвателното  
оборудване  изпраща  първия  бит на услугата  StartCom ­
municationService след  времеви  период  Twup, последван  
от първия  заден  фронт  на импулса .
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 306  
CPR_017 Стойностите  за синхронизация  за бързата  инициа­  
лизация  и връзките  по принцип  са подробно  описани  в 
следващите  таблици . Що се отнася  до времето  на неак­  
тивност , има различни  възможности : 
— Първо  предаване  на данни  след  включване  под 
напрежение  — Tidle = 300 ms.  
— След  приключване  на услугата  StopCommunication 
— Tidle = 3 min.  
— След  прекъсване  на връзката  поради  превишаване  на 
определеното  време  P3 max — Tidle = 0.  
Таблица  3 
Стойности  за синхронизация , определени  за бързата  инициализация  
Параметър  Минимална  стойност  Максимална  
стойност  
Tinil  25 ± 1 ms  24 ms  26 ms  
Twup  50 ± 1 ms  49 ms  51 ms  
Таблица  4 
Стойности  за синхронизация  за връзките  
Синхро­  
низация  
Параметър  Описание  на параметъра  Допустими  
минимални  
стойности  (ms)  Допустими  
максимални  
стойности  (ms)  
Минимални  Максимални  
P1 Междубайтово  време  за 
отговора  на бордовото  
устройство  0 20  
P2 Време  между  една  заявка  от 
изпитвателното  оборудване  и 
един  или два отговора  от 
бордовото  устройство  25 250  
P3 Време  между  края  на 
отговорите  на бордовото  
устройство  и началото  на 
нова  заявка , изпратена  от 
изпитвателното  оборудване  55 5 000  
P4 Междубайтово  време  за 
заявка , изпратена  от изпит­  
вателното  оборудване  5 20  
CPR_018 Форматът  на съобщенията  за бързата  инициализация  е 
подробно  описан  в следващите  таблици . (ЗАБЕЛЕЖКА : 
Hex means hexadecimal)  
Таблица  5 
Съобщение  за заявка  за StartCommunication  
Байт  # Наименование  на параметъра  Стойност  hex.  Мнемоничен  
код 
#1 Байт  за структура  — 
физическо  адресиране  81 FMT  
#2 Целеви  байт  за адреса  EE  TGT  
#3 Изходен  байт  за адреса  tt  SRC  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 307  
Байт  # Наименование  на параметъра  Стойност  hex.  Мнемоничен  
код 
#4 Идентификатор  на заявка  
за услугата  StartCommuni ­
cation  81 SCR  
#5 Контролна  сума  00-FF  CS  
Таблица  6 
Съобщение  за положителен  отговор  за StartCommunication  
Байт  # Наименование  на параметъра  Стойност  hex.  Мнемоничен  
код 
#1 Байт  за структура  — 
физическо  адресиране  80 FMT  
#2 Целеви  байт  за адреса  tt  TGT  
#3 Изходен  байт  за адреса  EE  SRC  
#4 Допълнителен  байт  за 
дължина  03 LEN  
#5 Идентификатор  на поло­  
жителен  отговор  за 
услугата  StartCommuni ­
cation  C1 SCRPR  
#6 Ключов  байт  1 EA  KB1  
#7 Ключов  байт  2 8F  KB2  
#8 Контролна  сума  00-FF  CS  
CPR_019 Няма  отрицателен  отговор  на съобщението  за заявка  за 
StartCommunication. Поради  липса  на съобщение  за 
положителен  отговор  за изпращане , бордовото  
устройство  не се инициализира , никакви  данни  не се 
предават  и то остава  в режим  на нормална  работа . 
4.2. Услуга  StopCommunication  
4.2.1  Описание  на съобщенията  
Целта  на тази услуга  е да се прекрати  съобщителната  сесия . 
CPR_020 При получаване  на примитив  за указване  StopCommuni ­
cation бордовото  устройство  трябва  да провери  дали  
актуалните  условия  позволяват  да се прекрати  тази 
връзка . В такъв  случай  бордовото  устройство  трябва  
да извърши  всички  необходими  операции , за да 
прекрати  връзката . 
CPR_021 Ако е възможно  прекратяване  на връзката , бордовото  
устройство  трябва  да изпрати  примитив  за отговор  Stop­
Communication с избраните  параметри  за положителен  
отговор , преди  да прекрати  връзката . 
CPR_022 Ако по една  или друга  причина  се окаже  невъзможно  
прекратяването  на връзката , бордовото  устройство  
трябва  да изпрати  примитив  за отговор  StopCommuni ­
cation с избрания  параметър  за отрицателен  отговор . 
CPR_023 Ако бордовото  устройство  установи  надвишаване  на 
времетраенето  P3max, връзката  се прекратява  без 
примитив  за отговор . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 308  
4.2.2  Формат  на съобщенията  
CPR_024 Форматите  на съобщенията  за примитивите  на StopCom­
munication са подробно  описани  в следващите  таблици . 
Таблица  7 
Съобщение  за заявка  за StopCommunication  
Байт  # Наименование  на параметъра  Стойност  hex.  Мнемоничен  
код 
#1 Байт  за структура  — 
физическо  адресиране  80 FMT  
#2 Целеви  байт  за адреса  EE  TGT  
#3 Изходен  байт  за адреса  tt  SRC  
#4 Допълнителен  байт  за 
дължина  01 LEN  
#5 Идентификатор  на заявка  
за услугата  StopCommuni ­
cation  82 SPR  
#6 Контролна  сума  00-FF  CS  
Таблица  8 
Съобщение  за положителен  отговор  за StopCommunication  
Байт  # Наименование  на параметъра  Стойност  hex.  Мнемоничен  
код 
#1 Байт  за структура  — 
физическо  адресиране  80 FMT  
#2 Целеви  байт  за адреса  tt  TGT  
#3 Изходен  байт  за адреса  EE  SRC  
#4 Допълнителен  байт  за 
дължина  01 LEN  
#5 Идентификатор  на поло­  
жителен  отговор  за 
услугата  StopCommuni ­
cation  C2 SPRPR  
#6 Контролна  сума  00-FF  CS  
Таблица  9 
Съобщение  за отрицателен  отговор  за StopCommunication  
Байт  # Наименование  на параметъра  Шестнай­  
сетична  
стойност  Мнемоничен  
код 
#1 Байт  за структура  — 
физическо  адресиране  80 FMT  
#2 Целеви  байт  за адреса  tt  TGT  
#3 Изходен  байт  за адреса  EE  SRC  
#4 Допълнителен  байт  за 
дължина  03 LEN  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 309  
Байт  # Наименование  на параметъра  Шестнай­  
сетична  
стойност  Мнемоничен  
код 
#5 Идентификатор  на отри­  
цателен  отговор  за 
услугата  7F NR  
#6 Идентификация  на заявка  за 
услугата  StopCommunication  82 SPR  
#7 responseCode = generalReject  10  RC_GR  
#8 Контролна  сума  00-FF  CS  
4.2.3  Определяне  на параметрите  
Тази  услуга  не налага  определяне  на параметри . 
4.3. Услуга  TesterPresent  
4.3.1  Описание  на съобщенията  
Услугата  TesterPresent се използва  от изпитвателното  оборудване , 
за да укаже  на сървъра , че все още е на разположение , с цел да се 
попречи  на автоматичното  връщане  на сървъра  към режим  на 
нормална  работа  и да се избегне  евентуалното  прекъсване  на 
връзката . Изпращана  периодично , тази услуга  поддържа  активна  
диагностичната  сесия /връзката , като нулира  брояча  Р3 при всяка  
заявка  за тази услуга . 
4.3.2  Формат  на съобщенията  
CPR_079 Форматите  на съобщенията  за примитивите  за Tester­
Present са подробно  описани  в следващите  таблици . 
Таблица  10 
Съобщение  за заявка  за TesterPresent  
Байт  # Наименование  на параметъра  Шестнай­  
сетична  
стойност  Мнемоничен  
код 
#1 Байт  за структура  — 
физическо  адресиране  80 FMT  
#2 Целеви  байт  за адреса  EE  TGT  
#3 Изходен  байт  за адреса  tt  SRC  
#4 Допълнителен  байт  за 
дължина  02 LEN  
#5 Идентификатор  на заявка  
за услугата  TesterPresent  3E TP  
#6 Подфункция  = 
responseRequired =  [ да 01  RESPREQ_Y  
не ] 02  RESPREQ_NO  
#7 Контролна  сума  00-FF  CS  
CPR_080 Ако за параметъра  responseRequired е зададено „да“, 
сървърът  ще отговори  с последващо  съобщение  за поло­  
жителен  отговор . Ако е зададено  „не“, сървърът  не 
изпраща  отговор . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 310  
Таблица  11 
Съобщение  за положителен  отговор  за TesterPresent  
Байт  # Наименование  на параметъра  Шестнай­  
сетична  стой­  
ност . Мнемоничен  
код 
#1 Байт  за структура  — 
физическо  адресиране  80 FMT  
#2 Целеви  байт  за адреса  tt  TGT  
#3 Изходен  байт  за адреса  EE  SRC  
#4 Допълнителен  байт  за 
дължина  01 LEN  
#5 Идентификатор  на поло­  
жителен  отговор  за 
услугата  TesterPresent  7E TPPR  
#6 Контролна  сума  00-FF  CS  
CPR_081 Услугата  трябва  да поддържа  следните  кодове  за отри­  
цателен  отговор : 
Таблица  12 
Съобщение  за отрицателен  отговор  за TesterPresent  
Байт  # Наименование  на параметъра  Шест­  
найсети­  
чна 
стойност  Мнемоничен  
код 
#1 Байт  за структура  — физическо  
адресиране  80 FMT  
#2 Целеви  байт  за адреса  tt  TGT  
#3 Изходен  байт  за адреса  EE  SRC  
#4 Допълнителен  байт  за дължина  03  LEN  
#5 Идентификатор  на отрицателен  
отговор  за услугата  7F NR  
#6 Идентификация  на заявка  за 
услугата  TesterPresent  3E TP  
#7 respon ­
seCode =  [SubFunctionNotSup ­
ported-InvalidFormat  12 RC_SFNS_IF  
incorrectMessage ­
Length ]  13 RC_IML  
#8 Контролна  сума  00-FF  CS  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 311  
5. УСЛУГИ  ЗА УПРАВЛЕНИЕ  
В следващата  таблица  са посочени  наличните  услуги : 
Таблица  13 
Услуги  за управление  
Наименование  на услугата  Описание  
StartDiagnosticSession  Клиентът  заявява  започване  на диаг­  
ностична  сесия  с бордовото  устрой­  
ство. 
SecurityAccess  Клиентът  заявява  достъп  до 
функции , които  са запазени  за 
оторизирани  потребители . 
5.1. Услуга  StartDiagnosticSession  
5.1.1  Описание  на съобщенията  
CPR_025 Услугата  StartDiagnosticSession позволява  активиране  на 
различни  диагностични  сесии  в сървъра . Диагнос­  
тичната  сесия  дава възможност  за специфичен  набор  
от услуги  в съответствие  с таблица  17. Сесията  може  
да позволи  извършването  на специфични  услуги  на 
производителя  на превозното  средство , които  не са 
част от настоящия  документ . Правилата  за тяхното  
извършване  трябва  да отговарят  на следните  изисквания : 
— винаги  има само  една  активна  диагностична  сесия  в 
бордовото  устройство ; 
— бордовото  устройство  винаги  започва  StandardDiag ­
nosticSession, когато  е включен  под напрежение . Ако 
няма  започната  друга  диагностична  сесия , Standar­
dDiagnosticSession остава  активна , докато  бордовото  
устройство  е включено  към захранване ; 
— ако една  вече започната  диагностична  сесия  е 
заявена  от изпитвателното  оборудване , бордовото  
устройство  изпраща  съобщение  за положителен  
отговор ; 
— когато  изпитвателното  оборудване  заяви  нова  диаг­  
ностична  сесия , бордовото  устройство  първо  
изпраща  съобщение  за положителен  отговор  за Star­
tDiagnosticSession, преди  да се започне  новата  сесия  
в бордовото  устройство . Ако бордовото  устройство  
не може  да започне  заявената  нова  диагностична  
сесия , той изпраща  съобщение  за отрицателен  
отговор  на StartDiagnosticSession и текущата  сесия  
продължава . 
CPR_026 Диагностична  сесия  започва  само  ако е била  установена  
връзка  между  клиента  и бордовото  устройство . 
CPR_027 Параметрите  за синхронизация , определени  в таблица  4, 
се активират  след  успешно  изпълнение  на StartDiagnos ­
ticSession с параметъра  diagnosticSession, за който  е 
зададено  „StandardDiagnosticSession“ в съобщението  за 
заявка , ако преди  това е била  активна  друга  диаг­  
ностична  сесия . 
5.1.2  Формат  на съобщенията  
CPR_028 Форматите  на съобщенията  за примитивите  StartDiagnos ­
ticSession са подробно  описани  в следващите  таблици . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 312  
Таблица  14 
Съобщение  за заявка  за StartDiagnosticSession  
Байт  # Наименование  на параметъра  Шестнай­  
сетична  
стойност  Мнемоничен  
код 
#1 Байт  за структура  — 
физическо  адресиране  80 FMT  
#2 Целеви  байт  за адреса  EE  TGT  
#3 Изходен  байт  за адреса  tt  SRC  
#4 Допълнителен  байт  за 
дължина  02 LEN  
#5 Идентификатор  на заявка  
за услугата  StartDiagnostic ­
Session  10 STDS  
#6 diagnosticSession = [ една  
стойност  от таблица  17] xx DS_…  
#7 Контролна  сума  00-FF  CS  
Таблица  15 
Съобщение  за положителен  отговор  за StartDiagnosticSession  
Байт  # Наименование  на параметъра  Шестнай­  
сетична  
стойност  Мнемоничен  
код 
#1 Байт  за структура  — 
физическо  адресиране  80 FMT  
#2 Целеви  байт  за адреса  tt  TGT  
#3 Байт  за изходен  адрес  EE  SRC  
#4 Допълнителен  байт  за 
дължина  02 LEN  
#5 Идентификатор  на поло­  
жителен  отговор  за 
услугата  StartDiagnostic ­
Session  50 STDSPR  
#6 diagnosticSession = [ същата  
стойност  като байт  #6 
таблица  14 ]  xx DS_…  
#7 Контролна  сума  00-FF  CS  
Таблица  16 
Съобщение  за отрицателен  отговор  за StartDiagnosticSession  
Байт  # Наименование  на параметъра  Шест­  
найсети­  
чна 
стойност  Мнемоничен  
код 
#1 Байт  за структура  — физическо  
адресиране  80 FMT  
#2 Байт  за целеви  адрес  tt  TGT  
#3 Байт  за изходен  адрес  EE  SRC  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 313  
Байт  # Наименование  на параметъра  Шест­  
найсети­  
чна 
стойност  Мнемоничен  
код 
#4 Допълнителен  байт  за дължина  03  LEN  
#5 Идентификатор  на отрицателен  
отговор  за услугата  7F NR  
#6 Идентификатор  на заявка  за 
услугата  StartDiagnosticSession  10 STDS  
#7 ResponseCode =  [subFunctionNot ­
Supported (  a ) 12 RC_SFNS  
incorrectMessa ­
geLength (  б ) 13 RC_IML  
conditionsNot ­
Correct (  в ) 22 RC_CNC  
#8 Контролна  сума  00-FF  CS  
( a ) Въведената  стойност  в байт  #6 на съобщението  за заявка  не се поддържа , тоест  
не е в таблица  17. 
( б ) Дължината  на съобщението  е грешна . 
( в ) Критериите  за заявка  за StartDiagnosticSession не са изпълнени . 
5.1.3  Определяне  на параметрите  
CPR_029 Параметърът  diagnosticSession (DS_)  се използва  от 
услугата  StartDiagnosticSession за избор  на специален  
режим  на сървъра (ите). Следващите  диагностични  
сесии  са посочени  в настоящия  документ : 
Таблица  17 
Определяне  на стойностите  на diagnosticSession  
Hex Описание  Мнемоничен  
код 
81 StandardDiagnosticSession  
Тази  диагностична  сесия  дава възможност  за 
всички  услуги , посочени  в таблица  1, колона  
4, „SD“ . Тези  услуги  позволяват  четенето  на 
данни  от сървър  (бордово  устройство ). Тази  
диагностична  сесия  е активна  след  успешна  
инициализация  между  клиент  (изпитвателно  
оборудване ) и сървър  (бордово  устройство ). 
Възможно  е тази диагностична  сесия  да бъде  
заменена  от други  други  диагностични  сесии , 
посочени  в този раздел . SD 
85 ECUProgrammingSession  
Тази  диагностична  сесия  дава възможност  за 
всички  услуги , посочени  в таблица  1, колона  
6, „ECUPS“ . Тези  услуги  поддържат  програ - 
мирането  на паметта  на сървър  (бордово  
устройство ). Възможно  е тази сесия  да бъде  
заменена  от други  други  диагностични  сесии , 
посочени  в този раздел . ECUPS  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 314  
Hex Описание  Мнемоничен  
код 
87 ECUAdjustmentSession  
Тази  диагностична  сесия  дава възможност  за 
всички  услуги , посочени  в таблица  1, колона  
5, „ECUАS“. Тези  услуги  поддържат  контро - 
ла на входните /изходните  данни  на сървър  
(бордово  устройство ). Възможно  е тази диаг - 
ностична  сесия  да бъде  заменена  от други  
други  диагностични  сесии , посочени  в този 
раздел . ECUAS  
5.2. Услуга  SecurityAccess  
Записването  на данните  за калибрирането  не е възможно , освен  
ако бордовото  устройство  работи  в режим  КАЛИБРИРАНЕ . 
Освен  вкарването  на валидна  карта  за монтаж  и настройки  в 
бордовото  устройство  е необходимо  да се въведе  съответният  
PIN в устройството , преди  да се получи  достъп  до режима  
КАЛИБРИРАНЕ . 
Когато  бордовото  устройство  е в режим  КАЛИБРИРАНЕ  или 
КОНТРОЛ , достъпът  до входно -изходната  линия  за калибриране  
е също  възможен . 
Услугата  SecurityAccess позволява  въвеждане  на PIN и посочване  
на изпитвателното  оборудване  дали  бордовото  устройство  работи  в 
режим  КАЛИБРИРАНЕ . 
Допустимо  е да се използват  други  методи  за въвеждане  на PIN.  
5.2.1  Описание  на съобщенията  
Услугата  SecurityAccess се състои  от съобщение  „requestSeed“ на 
SecurityAccess, евентуално  последвано  от съобщението  „sendKey“ 
на SecurityAccess. Услугата  SecurityAccess трябва  да се изпълни  
след  услугата  StartDiagnosticSession.  
CPR_033 Изпитвателното  оборудване  трябва  да използва  
съобщение  „requestSeed“ на SecurityAccess, за да 
провери  дали  бордовото  устройство  е в готовност  да 
приеме  PIN.  
CPR_034 Ако бордовото  устройство  е вече в режим  КАЛИБ­  
РИРАНЕ , то трябва  да отговори  на заявката  чрез 
изпращане  на инициализация  с начална  стойност  от 
0х0000, като използва  положителен  отговор  на 
услугата  SecurityAccess.  
CPR_035 Ако бордовото  устройство  е готово  да приеме  PIN за 
проверка  чрез карта  за монтаж  и настройки , то трябва  
да отговори  на заявката  чрез изпращане  на инициа­  
лизация  с начална  стойност , по-голяма  от 0х0000, като 
използва  положителен  отговор  на услугата  Security­
Access.  
CPR_036 Ако бордовото  устройство  не е готово  да приеме  PIN от 
изпитвателното  оборудване , защото  вкараната  карта  за 
монтаж  и настройки  не е валидна  или защото  не е 
вкарана  карта , или защото  бордовото  устройство  
изчаква  PIN по друг  начин , то трябва  да отговори  на 
заявката  с отрицателен  отговор , придружен  от код за 
отговор  conditionsNotCorrectOrRequestSequenceError.  
CPR_037 Тогава  евентуално  изпитвателното  оборудване  трябва  да 
използва  съобщение  „sendKey“ на SecurityAccess, за да 
предаде  PIN на бордовото  устройство . За управление  на 
времето , необходимо  за извършване  на процеса  по удос­  
товеряване  на картата , бордовото  устройство  трябва  да 
използва  кода  за отрицателен  отговор  requestCorrect ­
lyReceived-ResponsePending, за да удължи  времето  за 
отговор . Максималното  време  за отговор  не трябва  
обаче  да надхвърля  5 минути . След  като бъде  
изпълнена  заявената  услуга , бордовото  устройство  
изпраща  съобщение  за положителен  или отрицателен  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 315  
отговор  с код за отговор , който  е различен  от кода  по- 
горе. Кодът  за отрицателен  отговор  requestCorrectlyRe ­
ceived-ResponsePending може  да се повторя  от 
бордовото  устройство , докато  заявената  услуга  бъде  
изпълнена , а съобщението  за краен  отговор  — 
изпратено . 
CPR_038 Бордовото  устройство  трябва  да отговори  на тази заявка , 
като използва  положителен  отговор  на SecurityAccess 
само  когато  работи  в режим  КАЛИБРИРАНЕ . 
CPR_039 В следващите  случаи  бордовото  устройство  трябва  да 
отговори  на тази заявка  с отрицателен  отговор , 
придружен  от един  от следните  кодове  за отговор : 
— не се поддържа  subFunctionNot: невалиден  формат  за 
параметъра  subfunction (accessType);  
— conditionsNotCorrectOrRequestSequenceError: 
бордовото  устройство  не е готово  за приемане  на 
PIN;  
— invalidKey: невалиден  PIN и броят  на опитите  за 
проверка  на PIN не е надхвърлен ; 
— exceededNumberOfAttempts: невалиден  PIN и броят  
на опитите  за проверка  на PIN е надхвърлен ; 
— generalReject: правилен  PIN, но неуспешно  взаимно  
удостоверяване  с картата  за монтаж  и настройки . 
5.2.2  Формат  на съобщенията  — SecurityAccess — requestSeed  
CPR_040 Форматите  на съобщенията  за примитивите  на 
„requestSeed“ на SecurityAccess са подробно  описани  в 
следващите  таблици . 
Таблица  18 
Заявка  за SecurityAccess — съобщение  за requestSeed  
Байт  # Наименование  на параметъра  Шестнай­  
сетична  
стойност  Мнемоничен  
код 
#1 Байт  за структура  — 
физическо  адресиране  80 FMT  
#2 Байт  за целевия  адрес  EE  TGT  
#3 Байт  за изходен  адрес  tt  SRC  
#4 Допълнителен  байт  за 
дължина  02 LEN  
#5 Идентификатор  на заявка  
за услугата  SecurityAccess  27 SA  
#6 accessType — requestSeed  7D  AT_RSD  
#7 Контролна  сума  00-FF  CS  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 316  
Таблица  19 
SecurityAccess — съобщение  за положителен  отговор  за requestSeed  
Байт  # Наименование  на параметъра  Шестнай­  
сетична  
стойност  Мнемоничен  
код 
#1 Байт  за структура  — 
физическо  адресиране  80 FMT  
#2 Байт  за целевия  адрес  tt  TGT  
#3 Байт  за изходния  адрес  EE  SRC  
#4 Допълнителен  байт  за 
дължина  04 LEN  
#5 Идентификатор  на поло­  
жителен  отговор  за 
услугата  SecurityAccess  67 SAPR  
#6 accessType — requestSeed  7D  AT_RSD  
#7 Инициализация  от високо  
ниво  00-FF  SEEDH  
#8 Инициализация  от ниско  
ниво  00-FF  SEEDL  
#9 Контролна  сума  00-FF  CS  
Таблица  20 
Съобщение  за отрицателен  отговор  за SecurityAccess  
Байт  # Наименование  на параметъра  Шест­  
найсети­  
чна 
стойност  Мнемоничен  
код 
#1 Байт  за структура  — физическо  адре­  
сиране  80 FMT  
#2 Байт  за целевия  адрес  tt  TGT  
#3 Байт  за изходния  адрес  EE  SRC  
#4 Допълнителен  байт  за дължина  03  LEN  
#5 Идентификатор  на отрицателен  
отговор  за услугата  7F NR  
#6 Идентификатор  на заявка  за услугата  
SecurityAccess  27 SA  
#7 responseCode =  [conditionsNotCorrec ­
tOrRequestSequence ­
Error  22 RC_CNC  
incorrectMessage ­
Length]  13 RC_IML  
#8 Контролна  сума  00-FF  CS  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 317  
5.2.3  Формат  на съобщенията  — SecurityAccess — sendKey  
CPR_041 Форматите  на съобщенията  за примитивите  на 
„sendKey“ на SecurityAccess са подробно  описани  в 
следващите  таблици . 
Таблица  21 
Заявка  за SecurityAccess — съобщение  за sendKey  
Байт  # Наименование  на параметъра  Шестнай­  
сетична  
стойност  Мнемоничен  
код 
#1 Байт  за структура  — 
физическо  адресиране  80 FMT  
#2 Байт  за целевия  адрес  EE  TGT  
#3 Байт  за изходния  адрес  tt  SRC  
#4 Допълнителен  байт  за 
дължина  m+2 LEN  
#5 Идентификатор  на заявка  
за услугата  SecurityAccess  27 SA  
#6 accessType — sendKey  7E  AT_SK  
#7 до #m+6  Key #1 (High)  xx  KEY  
… …  
Key #m ( ниска , стойността  
на m трябва  да бъде  в 
интервала  между  4 и 8) xx 
#m+7  Контролна  сума  00-FF  CS  
Таблица  22 
SecurityAccess — съобщение  за положителен  отговор  за sendKey  
Байт  # Наименование  на параметъра  Шестнай­  
сетична  
стойност  Мнемоничен  
код 
#1 Байт  за структура  — 
физическо  адресиране  80 FMT  
#2 Байт  за целевия  адрес  tt  TGT  
#3 Байт  за изходния  адрес  EE  SRC  
#4 Допълнителен  байт  за 
дължина  02 LEN  
#5 Идентификатор  на поло­  
жителен  отговор  за 
услугата  SecurityAccess  67 SAPR  
#6 accessType — sendKey  7E  AT_SK  
#7 Контролна  сума  00-FF  CS  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 318  
Таблица  23 
Съобщение  за отрицателен  отговор  за SecurityAccess  
Байт  # Наименование  на параметъра  Шест­  
найсети­  
чна 
стойност  Мнемоничен  
код 
#1 Байт  за структура  — физическо  адре­  
сиране  80 FMT  
#2 Байт  за целевия  адрес  tt  TGT  
#3 Байт  за изходния  адрес  EE  SRC  
#4 Допълнителен  байт  за дължина  03  LEN  
#5 Идентификатор  на отрицателен  
отговор  за услугата  7F NR  
#6 Идентификатор  на заявка  за услугата  
SecurityAccess  27 SA  
#7 ResponseCode =  [generalReject  10  RC_GR  
subFunctionNotSup ­
ported  12 RC_SFNS  
incorrectMessage ­
Length  13 RC_IML  
conditionsNotCorrec ­
tOrRequestSequence ­
Error  22 RC_CNC  
invalidKey  35  RC_IK  
exceededNumberO ­
fAttempts  36 RC_ENA  
requestCorrectlyRe ­
ceived-ResponsePen ­
ding]  78 RC_RCR_RP  
#8 Контролна  сума  00-FF  CS  
6. УСЛУГИ  ЗА ПРЕДАВАНЕ  НА ДАННИ  
В следващата  таблица  са посочени  наличните  услуги : 
Таблица  24 
Услуги  за предаване  на данни  
Наименование  на 
услугата  Описание  
ReadDataByIdentifier  Клиентът  заявява  предаването  на акту­  
алната  стойност  на запис  с достъп  от 
recordDataIdentifier.  
WriteDataByIdentifier  Клиентът  заявява  запаметяване  на запис , 
до който  recordDataIdentifier е имал  
достъп . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 319  
6.1. Услуга  ReadDataByIdentifier  
6.1.1  Описание  на съобщенията  
CPR_050 Услугата  ReadDataByIdentifier се използва  от клиента , за 
да заяви  извличането  на стойности , които  са записани  на 
сървър . Данните  се идентифицират  от recordDataIden ­
tifier. Производителят  на бордовото  устройство  има 
задължение  да следи  за изпълнението  на условията  на 
сървъра  по време  на извършването  на тази услуга . 
6.1.2  Формат  на съобщенията  
CPR_051 Форматите  на съобщенията  за примитивите  на ReadDa­
taByIdentifier са подробно  описани  в следващите  
таблици . 
Таблица  25 
Съобщение  за заявка  за ReadDataByIdentifier  
Байт  # Наименование  на параметъра  Шестнай­  
сетична  
стойност  Мнемоничен  
код 
#1 Байт  за структура  — 
физическо  адресиране  80 FMT  
#2 Байт  за целевия  адрес  EE  TGT  
#3 Байт  за изходния  адрес  tt  SRC  
#4 Допълнителен  байт  за 
дължина  03 LEN  
#5 Идентификатор  на заявка  
за услугата  ReadDataByI ­
dentifier  22 RDBI  
#6 до #7 recordDataIdentifier = 
[стойност  от таблица  28] xxxx  RDI_…  
#8 Контролна  сума  00-FF  CS  
Таблица  26 
Съобщение  за положителен  отговор  за ReadDataByIdentifier  
Байт  # Наименование  на параметъра  Шест­  
найсети­  
чна 
стойност  Мнемоничен  
код 
#1 Байт  за структура  — физическо  
адресиране  80 FMT  
#2 Байт  за целевия  адрес  tt  TGT  
#3 Байт  за изходния  адрес  EE  SRC  
#4 Допълнителен  байт  за дължина  m + 3  LEN  
#5 Идентификатор  на положителен  
отговор  за услугата  ReadData ­
ByIdentifier  62 RDBIPR  
#6 и #7 recordDataIdentifier = [ същата  
стойност  като байтовете  #6 и #7 
таблица  25] xxxx  RDI_…  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 320  
Байт  # Наименование  на параметъра  Шест­  
найсети­  
чна 
стойност  Мнемоничен  
код 
#8 до #m 
+ 7 dataRecord[] =  [data#1  xx  DREC_DAT ­
A1 
: :  :  
data#m]  xx  DREC_DAT ­
Am 
#m + 8  Контролна  сума  00-FF  CS  
Таблица  27 
Съобщение  за отрицателен  отговор  за ReadDataByIdentifier  
Байт  # Наименование  на параметъра  Шест­  
найсети­  
чна 
стойност  Мнемоничен  
код 
#1 Байт  за структура  — физическо  адре­  
сиране  80 FMT  
#2 Байт  за целевия  адрес  tt  TGT  
#3 Байт  за изходния  адрес  EE  SRC  
#4 Допълнителен  байт  за дължина  03  LEN  
#5 Идентификатор  на отрицателен  
отговор  за услугата  7F NR  
#6 Идентификатор  на заявка  за услугата  
ReadDataByIdentifier  22 RDBI  
#7 ResponseCode=  [requestOutOfRange  31  RC_ROOR  
incorrectMessage ­
Length  13 RC_IML  
conditionsNotCor ­
rect] 22 RC_CNC  
#8 Контролна  сума  00-FF  CS  
6.1.3  Определяне  на параметрите  
CPR_052 Параметърът  recordDataIdentifier (RDI_)  в съобщението  
за заявка  за ReadDataByIdentifier идентифицира  запис  на 
данни . 
CPR_053 Определените  с настоящия  документ  стойности  на recor­
dDataIdentifier са показани  в таблицата  по-долу . 
Таблицата  за recordDataIdentifier се състои  от четири  
колони  и няколко  реда . 
— Първата  колона  (Hex.)  указва  „Hex Value.“ ( шест­  
найсетична  стойност ), присвоявана  на recordDataI ­
dentifier, посочен  в третата  колона . 
— Втората  колона  (елемент  от данни ) показва  
елемента  на данни  от допълнение  1, на който  се 
основава  recordDataIdentifier ( понякога  е необходимо  
преобразуване  на кода ). ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 321  
— Третата  колона  (описание ) указва  наименованието  
на съответния  recordDataIdentifier.  
— Четвъртата  колона  (мнемоничен  код) показва  
мнемоничния  код, свързан  с този recordDataIdentifier.  
Таблица  28 
Определяне  на стойностите  на recordDataIdentifier  
Hex Елемент  от данни  Наименование  на recordDataI ­
dentifier 
(вж. форм àта в раздел  8.2)  Мнемоничен  код 
F90B
  TimeDate  RDI_TD  
F912
  HighResolutionTotalVehicle ­
Distance  RDI_HRTVD  
F918
  Kfactor  RDI_KF  
F91C
  LfactorTyreCircumference  RDI_LF  
F91D
  WvehicleCharacteristicFactor  RDI_WVCF  
F921
  TyreSize  RDI_TS  
F922
  NextCalibrationDate  RDI_NCD  
F92C
  SpeedAuthorised  RDI_SA  
F97D
  RegisteringMemberState  RDI_RMS  
F97E
  VehicleRegistrationNumber  RDI_ VRN  
F190
  VIN  RDI_ VIN  
CPR_054 Параметърът  dataRecord (DREC_)  е използван  от съоб­  
щението  за положителен  отговор  на ReadDataByIden ­
tifier, за да подаде  на клиента  (изпитвателното  
оборудване ) стойността  от записа  на данни , идентифи­  
цирана  от recordDataIdentifier. Форматите  на данни  са 
посочени  в раздел  8. Други  dataRecords, включително  
входящите  данни  в бордовото  устройство , вътрешните  
и изходните  данни , могат  да се получат  по избор  от 
потребителя , но те не са определени  в настоящия  
документ . 
6.2. Услуга  WriteDataByIdentifier  
6.2.1  Описание  на съобщенията  
CPR_056 Клиентът  използва  услугата  WriteDataByIdentifier, за да 
запише  стойностите  от записи  на данни  върху  сървър . 
Данните  се идентифицират  от recordDataIdentifier. 
Производителят  на бордовото  устройство  има 
задължение  да следи  за изпълнението  на условията  на 
сървъра  по време  на извършването  на тази услуга . За 
актуализация  на параметрите , изброени  в таблица  28, 
бордовото  устройство  трябва  да е в режим  КАЛИБ­  
РИРАНЕ . 
6.2.2  Формат  на съобщенията  
CPR_057 Форматите  на съобщенията  за примитивите  на WriteDa­
taByIdentifier са подробно  описани  в следващите  
таблици . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 322  
Таблица  29 
Съобщение  за заявка  за WriteDataByIdentifier  
Байт  # Наименование  на параметъра  Шест­  
найсети­  
чна 
стойност  Мнемоничен  
код 
#1 Байт  за структура  — физическо  
адресиране  80 FMT  
#2 Байт  за целевия  адрес  EE  TGT  
#3 Байт  за изходния  адрес  tt  SRC  
#4 Допълнителен  байт  за дължина  m + 3  LEN  
#5 Идентификатор  на заявка  за 
услугата  WriteDataByIdentifier  2E WDBI  
#6 до #7 recordDataIdentifier = [ стойност  от 
таблица  28] xxxx  RDI_…  
#8 до m 
+ 7 dataRecord[] =  [data#1  xx  DREC_DAT ­
A1 
: :  :  
data#m]  xx  DREC_DAT ­
Am 
#m + 8  Контролна  сума  00-FF  CS  
Таблица  30 
Съобщение  за положителен  отговор  за WriteDataByIdentifier  
Байт  # Наименование  на параметъра  Шестнай­  
сетична  
стойност  Мнемоничен  
код 
#1 Байт  за структура  — 
физическо  адресиране  80 FMT  
#2 Байт  за целевия  адрес  tt  TGT  
#3 Байт  за изходния  адрес  EE  SRC  
#4 Допълнителен  байт  за 
дължина  03 LEN  
#5 Идентификатор  на поло­  
жителен  отговор  за 
услугата  WriteDataByIden ­
tifier  6E WDBIPR  
#6 до #7 recordDataIdentifier = [ същата  
стойност  като байтовете  #6 и 
#7 таблица  29] xxxx  RDI_…  
#8 Контролна  сума  00-FF  CS  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 323  
Таблица  31 
Съобщение  за отрицателен  отговор  за WriteDataByIdentifier  
Байт  # Наименование  на параметъра  Шест­  
найсети­  
чна 
стойност  Мнемоничен  
код 
#1 Байт  за структура  — физическо  адре­  
сиране  80 FMT  
#2 Байт  за целевия  адрес  tt  TGT  
#3 Байт  за изходния  адрес  EE  SRC  
#4 Допълнителен  байт  за дължина  03  LEN  
#5 Идентификатор  на отрицателен  
отговор  за услугата  7F NR  
#6 Идентификатор  на заявка  за услугата  
WriteDataByIdentifier  2E WDBI  
#7 ResponseCode=  [requestOutOfRange  31  RC_ROOR  
incorrectMessage ­
Length  13 RC_IML  
conditionsNotCorrect]  22  RC_CNC  
#8 Контролна  сума  00-FF  CS  
6.2.3  Определяне  на параметрите  
Параметърът  recordDataIdentifier (RDI_)  е определен  таблица  28. 
Параметърът  dataRecord (DREC_)  се използва  от съобщението  за 
заявка  на WriteDataByIdentifier, за да осигури  стойностите  на 
записа  от данни , идентифициран  от recordDataIdentifier, на 
сървъра  (бордовото  устройство ). Форматите  на данни  са 
посочени  в раздел  8. 
7. КОНТРОЛ  НА ИЗПИТВАТЕЛНИТЕ  ИМПУЛСИ  — 
ФУНКЦИОНАЛЕН  БЛОК  ЗА КОНТРОЛ  НА ВХОДНИТЕ /ИЗ­ 
ХОДНИТЕ  ДАННИ  
В следващата  таблица  са посочени  наличните  услуги : 
Таблица  32 
Функционален  блок  за контрол  на входните /изходните  данни  
Наименование  на 
услугата  Описание  
InputOutputControl ­
ByIdentifier  Клиентът  заявява  извършване  на контрол  
на определени  входни /изходни  данни  на 
сървъра  
7.1. Услуга  InputOutputControlByIdentifier  
7.1.1  Описание  на съобщенията  
Връзката , която  се осъществява  посредством  фронтално  
разположения  съединител , позволява  контрола  или следенето  на 
изпитвателните  импулси  с помощта  на съответно  изпитвателно  
оборудване  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 324  
CPR_058 Възможно  е да се конфигурира  тази линия  за входни / 
изходни  сигнали  за калибриране  с команда  по линията  
К, като се използва  услугата  InputOutputControlByIden ­
tifier за избора  на необходимата  входна  или изходна  
функция  за линията . Съществуват  следните  състояния  
по линията : 
— дезактивирана , 
— speedSignalInput, когато  линията  за входния /изходния  
сигнал  за калибриране  се използва  за въвеждане  на 
сигнал  за скорост  (изпитвателен  сигнал ), който  
замества  сигнала  за скорост  на датчика  за 
движение , като тази функция  не съществува  в 
режим  КОНТРОЛ , 
— realTimeSpeedSignalOutputSensor, когато  линията  за 
входни /изходни  сигнали  за калибриране  се използва  
за извеждане  на сигнала  за скорост  на датчика  за 
движение , 
— RTCOutput, когато  линията  за входни /изходни  
сигнали  за калибриране  се използва  за извеждане  
на сигнала  на часовника , работещ  по координи­  
раното  универсално  време , като тази функция  не 
съществува  в режим  КОНТРОЛ . 
CPR_059 За да бъде  в състояние  да конфигурира  състоянието  на 
линията , бордовото  устройство  трябва  да е започнало  
сесия  за настройка  и да работи  в режим  КАЛИБ­  
РИРАНЕ  или КОНТРОЛ . Когато  бордовото  устройство  
е в режим  КАЛИБРИРАНЕ , могат  да се изберат  
четирите  състояние  на линията  (дезактивирана , speedSig­
nalInput, realTimeSpeedSignalOutputSensor и RTCOutput). 
Когато  бордовото  устройство  е в режим  КОНТРОЛ , 
могат  да се изберат  само  двете  състояние  на линията  
(дезактивирана  и realTimeSpeedSignalOutputSensor). При 
приключване  на сесия  за настройка  или излизане  от 
режим  КАЛИБРИРАНЕ  или КОНТРОЛ , бордовото  
устройство  трябва  да осигури  линията  за входни / 
изходни  сигнали  за калибриране  да се е върнала  в дезак­  
тивирано  състояние  (по подразбиране ). 
CPR_060 В случай  на получаване  на импулси  за скорост  по 
линията  за входния  сигнал  за моментната  скорост  на 
бордовото  устройство , при положение  че линията  за 
входни /изходни  сигнали  работи  в режим  на въвеждане  
на данни , тази линия  трябва  да премине  в режим  на 
извеждане  на данни  или да се върне  в своето  дезакти­  
вирано  състояние . 
CPR_061 Последователността  на операциите  е следната : 
— установяване  на връзки  чрез услугата  StartCommuni ­
cation,  
— влизане  в сесия  за настройка  чрез услугата  StartDi­
agnosticSession и преминаване  в режим  на работа  
КАЛИБРИРАНЕ  ИЛИ  КОНТРОЛ  (редът  на 
изпълнение  на тези две операции  е без значение ), 
— промяна  на състоянието  на изхода  чрез услугата  
InputOutputControlBydentifier.  
7.1.2  Формат  на съобщенията  
CPR_062 Форматите  на съобщенията  за примитивите  на InputOut­
putControlByIdentifier са подробно  описани  в следващите  
таблици . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 325  
Таблица  33 
Съобщение  за заявка  за InputOutputControlByIdentifier  
Байт  # Наименование  на параметъра  Шестнай­  
сетична  
стойност  Мнемоничен  
код 
#1 Байт  за структура  — 
физическо  адресиране  80 FMT  
#2 Байт  за целевия  адрес  EE  TGT  
#3 Байт  за изходния  адрес  tt  SRC  
#4 Допълнителен  байт  за 
дължина  xx LEN  
#5 Идентификатор  на заявка  
за InputOutputControlByI ­
dentifier  2F IOCBI  
#6 и #7 InputOutputIdentifier = [Calib ­
rationInputOutput]  F960  IOI_CIO  
#8 или 
#8 до #9 ControlOptionRecord = [  COR_…  
inputOutputControlParameter 
— една  стойност  от таблица  
36 xx IOCP_…  
controlState — една  стойност  
от таблица  37 (вж. забе­  
лежката  по-долу )] xx CS_…  
#9 или #10  Контролна  сума  00-FF  CS  
Забележка : параметърът  сontrolState се появява  само  в 
някои  случаи  (вж. 7.1.3).  
Таблица  34 
Съобщение  за положителен  отговор  за InputOutputControlByIdentifier  
Байт  # Наименование  на параметъра  Шестнай­  
сетична  
стойност  Мнемоничен  
код 
#1 Байт  за структура  — 
физическо  адресиране  80 FMT  
#2 Байт  за целевия  адрес  tt  TGT  
#3 Байт  за изходния  адрес  EE  SRC  
#4 Допълнителен  байт  за 
дължина  xx LEN  
#5 Идентификатор  на поло­  
жителен  отговор  за inputO­
utputControlByIdentifier  6F IOCBIPR  
#6 и #7 inputOutputIdentifier = [Calib ­
rationInputOutput]  F960  IOI_CIO  
#8 или 
#8 до #9 controlStatusRecord = [  CSR_  
inputOutputControlParameter 
(същата  стойност  като байт  
#8 таблица  33) xx IOCP_…  
controlState ( същата  стойност  
като байт  #9 таблица  33)] 
(ако е приложимо ) xx CS_…  
#9 или #10  Контролна  сума  00-FF  CS  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 326  
Таблица  35 
Съобщение  за отрицателен  отговор  за InputOutputControlByIdentifier  
Байт  # Наименование  на параметъра  Шестнай­  
сетична  
стойност  Мнемоничен  
код 
#1 Байт  за структура  — 
физическо  адресиране  80 FMT  
#2 Байт  за целевия  адрес  tt  TGT  
#3 Байт  за изходния  адрес  EE  SRC  
#4 Допълнителен  байт  за 
дължина  03 LEN  
#5 Идентификатор  на отри­  
цателен  отговор  за 
услугата  7F NR  
#6 Идентификатор  на заявка  за 
inputOutputControlByIdentifier  2F IOCBI  
#7 responseCode=[  
incorrectMessageLength  13  RC_IML  
conditionsNotCorrect  22  RC_CNC  
requestOutOfRange  31  RC_ROOR  
deviceControlLimitsExceeded]  7A  RC_DCLE  
#8 Контролна  сума  00-FF  CS  
7.1.3  Определяне  на параметрите  
CPR_064 Параметърът  inputOutputControlParameter (IOCP_)  е 
определен  в следващата  таблица . 
Таблица  36 
Определяне  на стойностите  на inputOutputControlParameter  
Hex Описание  Мнемоничен  
код 
00 ReturnControlToECU  
Тази  стойност  трябва  да посочва  на сървъра  
(бордовото  устройство ), че изпитвателното  
оборудване  не управлява  повече  линията  за 
входни /изходни  сигнали  за калибриране . RCTECU  
01 ResetToDefault  
Тази  стойност  трябва  да посочва  на сървъра  
(бордовото  устройство ), че трябва  да върне  
линията  за входни /изходни  сигнали  за кали - 
бриране  към състоянието  ѝ по подразбиране . RTD ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 327  
Hex Описание  Мнемоничен  
код 
03 ShortTermAdjustment  
Тази  стойност  трябва  да посочва  на сървъра  
(бордовото  устройство ), че трябва  да настрои  
линията  за входни /изходни  сигнали  за кали - 
бриране  към стойността , включена  в пара - 
метъра  controlState.  STA  
CPR_065 Параметърът  controlState  се появява  само  когато  inputO­
utputControlParameter е конфигуриран  като ShortTermAd ­
justment и е определен  в следващата  таблица : 
Таблица  37 
Определяне  на стойностите  на controlState  
Режим  Шестнай­  
сетична  
стойност  Описание  
Дезакти­  
виран  00 Дезактивирана  линия  за вход /изход  (по 
подразбиране ) 
Активиран  01  Активирана  линия  за вход /изход  за калиб­  
риране  като speedSignalInput  
Активиран  02  Активирана  линия  за вход /изход  за калиб­  
риране  като realTimeSpeedSignalOutput ­
Sensor  
Активиран  03  Активирана  линия  за вход /изход  за калиб­  
риране  като RTCOutput  
8. ФОРМАТИ  НА DATARECORDS  
В настоящия  раздел  са изложени  подробно : 
— общите  правила , които  трябва  да се прилагат  към диапазоните  
от параметри , предавани  от бордовото  устройство  към изпит­  
вателното  оборудване , 
— форматите , които  трябва  да се използват  за прехвърлените  
данни  чрез услугите  за предаване  на данни , изложени  в 
раздел  6. 
CPR_067 Всички  идентифицирани  параметри  трябва  да се 
поддържат  от бордовото  устройство . 
CPR_068 Данните , предавани  от бордовото  устройство  към изпит­  
вателното  оборудване  в отговор  на съобщение  за заявка , 
трябва  да са измерими  (тоест  актуалната  стойност  на 
заявения  параметър  е такава , каквато  е измерена  или 
наблюдавана  от бордовото  устройство ). 
8.1. Диапазони  от предавани  параметри  
CPR_069 Таблица  38 определя  използваните  диапазони  за 
определяне  валидността  на даден  предаван  параметър . 
CPR_070 Стойностите  от диапазона  „индикатор  за грешка “ 
позволяват  на бордовото  устройство  да посочи  веднага , 
че към съответния  момент  не са налице  валидни  данни  
за параметъра  поради  някакъв  вид грешка  в тахографа . 
CPR_071 Стойностите  от диапазона  „не е наличен “ позволяват  на 
бордовото  устройство  да изпрати  съобщение , 
съдържащо  параметър , който  не е наличен  или не се 
поддържа  в този модул . Стойностите  от диапазона  
„Незаявен “ позволяват  на устройството  да предаде  
командно  съобщение  и да идентифицира  параметрите , 
за които  не се очаква  отговор  от получаващото  
устройство . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 328  
CPR_072 Когато  неизправност  в даден  компонент  попречи  на 
предаването  на валидни  данни  за даден  параметър , е 
целесъобразно  да се използва  индикаторът  за грешка , 
така както  е описан  в таблица  38, вместо  данните  за 
този параметър . Въпреки  това, ако измерените  или 
изчислените  данни  показват  валидна  стойност , която  
обаче  надвишава  определения  за този параметър  
диапазон , индикаторът  за грешка  не трябва  да бъде  
използван . В този случай  следва  да се предадат  
данните , като се използва  подходящата  минимална  или 
максимална  стойност  на параметъра . 
Таблица  38 
Диапазони  на dataRecords  
Наименование  на диапазона  1 байт  
(шестнайсетична  
ст-т) 2 байта  
(шестнайсетична  ст- 
т) 4 байта  
(стойност  hex.)  ASCII  
Валиден  сигнал  00 до FA 0000 до FAFF  00000000 до FAFFFFFF  1 до 254  
Специфичен  за даден  
параметър  индикатор  FB FB00 до FBFF  FB000000 до FBFFFFFF  Няма  
Диапазон , запазен  за бъдещите  
битове  на индикатора  FC до FD FC00 до FDFF  FC000000 до FDFFFFFF  Няма  
Индикатор  за грешка  FE  FE00 до FEFF  FE000000 до FEFFFFFF  0  
Не е наличен  или незаявен  FF  FF00 до FFFF  FF000000 до FFFFFFFF  FF  
CPR_073 За параметрите , кодирани  в ASCII, символът  ASCII „*“ 
се запазва  като разграничител . 
8.2. Формати  на dataRecords  
В таблица  39 до таблица  42 са изложени  подробно  форматите , 
които  трябва  да се използват  чрез услугите  ReadDataByIdentifier 
и WriteDataByIdentifier.  
CPR_074 Таблица  39 указва  дължината , разделителната  
способност  и оперативния  диапазон  на всеки  параметър , 
идентифициран  от своя  recordDataIdentifier:  
Таблица  39 
Формат  на dataRecords  
Наименование  на параметъра  Дължина  на 
данните  (байтове ) Разделителна  способност  Оперативен  диапазон  
TimeDate  8  Вж. подробна  информация  в таблица  40 
HighResolutionTotalVehicle ­
Distance  4 усилване  5 m/bit, отместване  0 m  0 до + 21 055 406 km  
Kfactor  2  усилване  0,001 imp/m/bit, 
отместване  0 0 до 64,255 imp/m  
LfactorTyreCircumference  2  усилване  0,125 10  – 3 m/bit, 
отместване  0 0 до + 8,031 m  
WvehicleCharacteristicFactor  2  усилване  0,001 imp/m/bit, 
отместване  0 0 до 64,255 imp/m  
TyreSize  15  ASCII  ASCII  
NextCalibrationDate  3  Вж. подробна  информация  в таблица  41 
SpeedAuthorised  2  усилване  1/256 km/h/bit, 
отместване  0 0 до 250,996 km/h  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 329  
Наименование  на параметъра  Дължина  на 
данните  (байтове ) Разделителна  способност  Оперативен  диапазон  
RegisteringMemberState  3  ASCII  ASCII  
VehicleRegistrationNumber  14  Вж. подробна  информация  в таблица  42 
VIN 17  ASCII  ASCII  
CPR_075 Таблица  40 показва  подробно  форматите  на различните  
байтове  на параметъра  TimeDate:  
Таблица  40 
Подробна  структура  на TimeDate ( стойност  на recordDataIdentifier # 
F90B)  
Байт  Определяне  на 
параметрите  Разделителна  способност  Оперативен  
диапазон  
1 Секунди  усилване  0,25 s/bit, отместване  
0 секунди  0 до 59,75 s  
2 Минути  усилване  1 min/bit, отместване  
0 минути  0 до 59 
минути  
3 Часове  усилване  1 h/bit, отместване  0 
часа 0 до 23 ч 
4 Месец  усилване  1 month/bit, 
отместване  0 месеца  1 до 12 
месеца  
5 Ден усилване  0,25 дена /bit, 
отместване  0 дена  
(вж. забележката  по-долу  
таблица  41) 0,25 до 31,75 
дена  
6 Година  усилване  1 година /bit, 
отместване  + 1985 година  
(вж. забележката  по-долу  
таблица  41) 1985 до 2235 
година  
7 Корекция  на 
минути  
спрямо  
местното  
време  усилване  1 min/bit, отместване  
– 125 min  – 59 до 59 
минути  
8 Поправка  на 
часове  
спрямо  
местното  
време  усилване  1 h/bit, отместване  – 
125 h  – 23 до + 23 
ч 
CPR_076 Таблица  41 показва  подробно  форматите  на различните  байтове  на пара­  
метъра  NextCalibrationDate:  
Таблица  41 
Подробен  формат  на NextCalibrationDate ( стойност  на 
recordDataIdentifier # F922)  
Байт  Определяне  на 
параметрите  Разделителна  способност  Оперативен  
диапазон  
1 Месец  усилване  1 месец /bit, 
отместване  0 месеца  1 до 12 
месеца  
2 Ден усилване  0,25 дена /bit, 
отместване  0 дена  
(вж. забележката  по-долу ) 0,25 до 31,75 
дена  
3 Година  усилване  1 година /bit, 
отместване  + 1985 година  
(вж. забележката  по-долу ) 1985 до 2235 
година  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 330  
ЗАБЕЛЕЖКА  относно  използването  на параметъра „Ден“: 
1) Стойност  0 за датата  е нулева . Стойностите  1, 2, 3 и 4 се 
използват , за да идентифицират  първия  ден от месеца ; стой­  
ностите  5, 6, 7 и 8 указват  втория  ден на месеца  и т.н. 
2) Този  параметър  не влияе , нито  променя  параметъра  за часовете  
по-горе. 
ЗАБЕЛЕЖКА  относно  използването  на байта  на параметъра „го­ 
дина “: 
Стойност  0 за годината  отговаря  на година  1985; стойност  от 1 
отговаря  на година  1986 и т.н. 
CPR_078 Таблица  42 показва  подробно  форматите  на различните  
байтове  на параметъра  VehicleRegistrationNumber:  
Таблица  42 
Подробен  формат  на VehicleRegistrationNumber ( стойност  на 
recordDataIdentifier # F97 Е) 
Байт  Определяне  на параметрите  Разделителна  
способност  Оперативен  
диапазон  
1 Кодова  страница  (както  е 
определена  в допълнение  1) ASCII  от 01 до 0A 
2 — 14  Регистрационен  номер  на 
превозното  средство  (както  
е определен  в допълнение  1) ASCII  ASCII  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 331  
Допълнение  9 
МИНИМАЛНО  ИЗИСКВАНИ  ИЗПИТВАНИЯ  ЗА ОДОБРЕНИЕ  НА 
ТИПА  
СЪДЪРЖАНИЕ  
1. ВЪВЕДЕНИЕ  
2. ФУНКЦИОНАЛНИ  ИЗПИТВАНИЯ  НА БОРДОВОТО  УСТРОЙСТВО  
3. ФУНКЦИОНАЛНИ  ИЗПИТВАНИЯ  НА ДАТЧИКА  ЗА ДВИЖЕНИЕ  
4. ФУНКЦИОНАЛНИ  ИЗПИТВАНИЯ  НА ТАХОГРАФСКИТЕ  КАРТИ  
5. ИЗПИТВАНИЯ  НА ВЪНШНОТО  УСТРОЙСТВО  ЗА GNSS  
▼M1 
6. ИЗПИТВАНИЯ  НА ВЪНШНОТО  УСТРОЙСТВО  ЗА ВРЪЗКА  ОТ 
РАЗСТОЯНИЕ  
▼B 
7. ФУНКЦИОНАЛНИ  ИЗПИТВАНИЯ  ЗА РАЗПЕЧАТВАНЕ  ВЪРХУ  
ХАРТИЕН  НОСИТЕЛ  
8. ИЗПИТВАНИЯ  ЗА ОПЕРАТИВНА  СЪВМЕСТИМОСТ  
1. ВЪВЕДЕНИЕ  
1.1. Одобряване  на типа  
ЕО одобряването  на типа  на уреди  за регистриране  на данните  за 
движението  (или на техен  компонент ), или съответно  на тахографска  
карта , се основава  на: 
▼M1 
— сертифициране  за сигурност , въз основа  на спецификациите  на 
Общите  критерии , при цел за състояние  на сигурност  на системата , 
което  да е в пълно  съответствие  с допълнение  10 към настоящото  
приложение , 
▼B 
— сертифициране  за функционалност , извършвано  от компетентния  
орган  на съответната  държава  членка , удостоверяващо  че изпит­  
ваното  устройство  отговаря  на изискванията  в настоящото  
приложение  по отношение  на изпълняваните  функции , на 
точността  на измерванията  и на характеристиките  на околната  
среда , 
— сертифициране  за оперативна  съвместимост , извършвано  от 
компетентния  орган , удостоверяващо  че уредът  за регистриране  
на данните  за движението  (или тахографската  карта ) е изцяло  
оперативно  съвместим  съответно  с необходимите  модели  тахог­  
рафска  карта  (или уред  за регистриране  на данните  за движението ) 
(виж глава  8 от настоящото  приложение ). 
В настоящото  допълнение  е уточнено  кои изпитвания  трябва  да бъдат  
проведени  като минимум  от компетентния  орган  на дадена  държава  
членка  в рамките  на функционалните  изпитвания , както  и кои 
изпитвания  трябва  да бъдат  проведени  като минимум  от компетентния  
орган  в рамките  на изпитванията  за оперативна  съвместимост . Не са 
включени  допълнителни  уточнения  нито  за процедурите  за провеж­  
дането  на тези изпитвания , нито  за типа  на изпитванията . 
Също  така, в настоящото  допълнение  не са разгледани  и аспектите  на 
сертифицирането  за сигурност . Ако по време  на процеса  за оценяване  и 
сертифициране  на сигурността  са извършени  някои  изпитвания , 
изисквани  за одобряването  на типа , не е необходимо  те да бъдат  
провеждани  повторно . В такъв  случай  могат  да бъдат  инспектирани  
само  резултатите  от тези изпитания  за сигурност . С информативна  
цел в настоящото  допълнение  са отбелязани  със звездичка  („*“) изиск­  
ванията , за които  се очаква  да бъдат  проведени  изпитвания  при серти­  
фицирането  за сигурност  (или съответно  изискванията , тясно  свързани  
с такива  изпитвания ). 
Номерираните  изисквания  са свързани  със съдържанието  на настоящото  
приложение , а останалите  изисквания  са свързани  с другите  допълнения  
(например  PIC_001 е свързано  с Допълнение  3 „Пиктограми “). 
В настоящото  допълнение  са разгледани  поотделно  одобряването  на типа  
на датчика  за движение , на бордовото  устройство  и на външното  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 332  
устройство  за GNSS, в качеството  им на компоненти  на уредите  за регис­  
триране  на данните  за движението . За всеки  компонент  се издава  негов  
отделен  сертификат  за одобрение , в който  се посочват  другите  съвместими  
компоненти . Функционалното  изпитване  на датчика  за движение  (или на 
външното  устройство  за GNSS) се прави  заедно  с бордовото  устройство , и 
обратно . 
Не се изисква  оперативна  съвместимост  между  всеки  модел  датчик  за 
движение  (респективно  всеки  модел  външно  устройство  за GNSS) и 
всеки  модел  бордово  устройство . В подобни  случаи  одобрението  на 
типа  на датчик  за движение  (респективно  на външно  устройство  за 
GNSS) може  да бъде  дадено  само  в комбинация  с одобрение  на типа  
на съответното  бордово  устройство  и обратно . 
1.2. Позовавания  
В настоящото  допълнение  се използват  позовавания  на следните  стан­  
дарти : 
IEC 60068-2-1: Изпитване  на въздействия  на околната  среда  — Част  2- 
1: Изпитвания  — Изпитване  А: Студ  
IEC 60068-2-2: Основни  процедури  за изпитване  на въздействия  на 
околната  среда ; Част  2: Изпитвания ; Изпитване  В: Суха  топлина  (сину­  
соидални ). 
IEC 60068-2-6: Изпитване  на въздействия  на околната  среда  — Част  2: 
Изпитвания  — Изпитване  Fc:: Вибрации  
IEC 60068-2-14: Изпитания  на въздействия  на околната  среда ; Част  2- 
14: Изпитвания ; Изпитване  N: Промени  на температурата  
IEC 60068-2-27: Изпитания  на въздействия  на околната  среда . Част  2: 
Изпитвания . Изпитване  Еа и указания : Удар  
IEC 60068-2-30: Изпитване  на въздействия  на околната  среда  — Част  2- 
30: Изпитвания  — Изпитване  Db: Влажна  топлина , циклично  (цикъл  12 
+ 12 часа) 
IEC 60068-2-64: Изпитване  на въздействия  на околната  среда  — Част  2- 
64: Изпитвания  — Изпитване  Fh: Вибрации , широколентови  случайни , 
и указания  
IEC 60068-2-78: Изпитване  на въздействия  на околната  среда  — Част  2- 
78: Изпитвания  — Изпитване Cab: Влажна  топлина , постоянен  режим  
ISO 16750-3 Механични  натоварвания  (2012-12)  
ISO 16750-4 Климатични  натоварвания  (2010-04)  
ISO 20653: Пътни  превозни  средства . Степен  на защита  (IP код). 
Защита  на електрическото  оборудване  срещу  чужди  обекти , вода  и 
достъп  
ISO 10605:2008 + Техническа  поправка :2010 + AMD1:2014 Пътни  
превозни  средства . Методи  за изпитване  на електрически  смущения , 
предизвикани  от електростатичен  разряд  
ISO 7637-1:2002 + AMD1: 2008 Пътни  превозни  средства . Елек­  
трически  смущения  от електропроводящите  устройства  и свързването . 
Част  1: Определения  и общи  съображения . 
ISO 7637-2 Пътни  превозни  средства . Електрически  смущения  от елек­  
тропроводящите  устройства  и свързването . Част  2: Разпространение  на 
смущения  от преходни  процеси  само  по захранващите  линии . 
ISO 7637-3 Пътни  превозни  средства . Електрически  смущения  от елек­  
тропроводящите  устройства  и свързването . Част  3: Прехвърляне  на 
смущения  от преходни  процеси  чрез капацитивно  и индуктивно  
свързване  по линии , различни  от захранващите  линии . 
ISO/IEC 7816-1 Идентификационни  карти . Карти  с интегрална (и) 
схема (и) с контакти . Част  1: Физични  характеристики . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 333  
ISO/IEC 7816-2 Информационни  технологии . Идентификационни  
карти . Карти  с интегрална (и) схема (и) с контакти . Част  2: Размери  и 
разположение  на контактите . 
ISO/IEC 7816-3 Информационни  технологии . Идентификационни  
карти . Карти  с интегрална (и) схема (и) с контакти . Част  3: Електронни  
сигнали  и протоколи  за предаване . 
ISO/IEC 10373-1:2006 + AMD1:2012 Идентификационни  карти . Методи  
за изпитване . Част  1: Общи  характеристики  
ISO/IEC 10373-3:2010 + Technical Corrigendum:2013 Идентификационни  
карти . Методи  за изпитване . Част  3: Карти  с интегрална (и) схема (и) с 
контакти  и съответни  интерфейсни  устройства  
ISO 16844-3:2004, Cor 1:2006 Пътни  превозни  средства . Тахографски  
системи . Част  3: Интерфейс  на датчика  за движение  (към бордови  
устройства ). 
ISO 16844-4 Пътни  превозни  средства . Тахографски  системи . Част  4: 
Интерфейс  на CAN мрежа  
ISO 16844-6 Пътни  превозни  средства . Тахографски  системи . Част  6: 
Диагностика  
ISO 16844-7 Пътни  превозни  средства . Тахографски  системи . Част  7: 
Параметри  
ISO 534 Хартия  и картон . Определяне  на дебелина , плътност  и 
специфичен  обем  
Правило  № 10 на ИКЕ  на ООН  Единни  условия  относно  одобряването  
на превозни  средства  по отношение  на електромагнитната  съвмес­  
тимост  (Икономическа  комисия  за Европа  на Организацията  на обеди­  
нените  нации ) 
2. ФУНКЦИОНАЛНИ  ИЗПИТВАНИЯ  НА БОРДОВОТО  УСТРОЙСТВО  
▼M1 
№ Изпитване  Описание  Съответни  изисквания  
1. Административен  преглед  
1.1 Документиране  Правилност  на документацията  
1.2 Резултати  от 
изпитване , проведено  
от производителя  Резултати  от изпитване  при интегриране , 
проведено  от производителя  
Писмени  демонстрации . 88, 89, 91  
2. Визуално  инспектиране  
2.1 Съответствие  с документацията  
2.2 Идентификация /маркировки  224 до 226  
2.3 Материали  219 до 223  
2.4 Херметизация  398, 401 до 405  
2.5 Външни  интерфейси  
3. Функционални  изпитвания  
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 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 334  
№ Изпитване  Описание  Съответни  изисквания  
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  ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 335  
№ Изпитване  Описание  Съответни  изисквания  
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. Изпитвания  за въздействията  на околната  среда  
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 ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 336  
№ Изпитване  Описание  Съответни  изисквания  
4.3 Механични  въздей­  
ствия  1. Синусоидални  вибрации . 
Проверява  се, че бордовото  устройство  
може  да понесе  синусоидални  вибрации  
със следните  характеристики : 
постоянно  изместване , при честота  
между  5 и 11 Hz: максимум  10 mm 
постоянно  ускорение , при честота  
между  11 и 300 Hz: 5 g 
Съответствието  с това изискване  се 
проверява  чрез изпитване  Fc по IEC 
60068-2-6, с минимално  времетраене  на 
изпитването  3 × 12 часа (по 12 часа на 
координатна  ос) 
Стандартът  ISO 16750-3 не изисква  да 
се провежда  изпитване  със сину­  
соидални  вибрации  за устройства , 
намиращи  се в отделна  кабина  на 
превозното  средство . 
2. Случайни  вибрации : 
Изпитване  съгласно  ISO 16750-3: глава  
4.1.2.8: Изпитване  VIII: Търговски  
превозни  средства  с отделна  кабина  
Изпитване  за случайни  вибрации , 
10...2000 Hz, вертикално  средноквад­  
ратично  отклонение  21,3 m/s  2 , 
надлъжно  средноквадратично  
отклонение  11,8 m/s  2 , напречно  сред­  
ноквадратично  отклонение  13,1 m/s  2 , 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 ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 337  
№ Изпитване  Описание  Съответни  изисквания  
4.6 Защита  срещу  
включване  с обратна  
полярност  Проверява  се, че бордовото  устройство  
може  да издържи  на размяна  на полюсите  
на електрическото  му захранване  
(ISO 16750-2)  216 
4.7 Защита  срещу  къси  
съединения  Проверява  се, че входно /изходните  
сигнали  са защитени  срещу  къси  
съединения  към захранването  и към масата  
(ISO 16750-2)  216 
5. Изпитване  за електромагнитна  съвместимост  (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 ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 338  
3. ФУНКЦИОНАЛНИ  ИЗПИТВАНИЯ  НА ДАТЧИКА  ЗА ДВИЖЕНИЕ  
№ Изпитване  Описание  Съответни  изисквания  
1. Административен  преглед  
1.1 Документация  Коректност  на документацията  
2. Визуално  инспектиране  
2.1. Съответствие  с документацията  
2.2. Идентификация /маркировки  225, 226,  
2.3 Материали  219 до 223  
2.4. Херметизация  398, 401 до 405  
3. Функционални  изпитвания  
3.1 Данни  за идентифициране  на датчика  95 до 97*  
3.2 Сдвояване  датчик  за движение  — бордово  устройство  122*, 204  
3.3 Установяване  на движение  
Точност  на измерване  на движението  30 до 35 
3.4 Интерфейс  към бордовото  устройство  02  
3.5 Проверява  се дали  датчикът  за движение  е защитен  срещу  въздействието  на 
постоянно  магнитно  поле . Като  алтернативна  възможност  се проверява  
дали  датчикът  за движение  реагира  по такъв  начин  на постоянни  
магнитни  полета , смущаващи  установяването  на движение  на превозното  
средство , че свързано  с него  бордово  устройство  да може  да открива , 
записва  и съхранява  данни  за неизправности  във функционирането  на 
датчика  217 
4. Изпитания  за въздействията  на околната  среда  
4.1 Работна  температура  Проверява  се функционалността  (както  е 
дефинирана  за изпитване  № 3.3) за темпера­  
турния  обхват  [– 40 °C; + 135 °C] чрез: 
изпитване  Ad по IEC 60068-2-1, с продължи­  
телност  на изпитването  96 часа при мини­  
малната  температура  To  min , 
изпитване  Bd по IEC 60068-2-2, с продължи­  
телност  на изпитването  96 часа при 
максимална  температура  To  max 
Изпитване  съгласно  ISO 16750-4: Глава  
5.1.1.2 Изпитване  за работа  при ниска  темпе­  
ратура  (24 часа при – 40 °C) 
Това  изпитване  е с позоваване  на IEC 60068- 
2-1: Изпитване  на въздействия  на околната  
среда  — Част  2-1: Изпитвания . Изпитване  
А: Студ , IEC 68-2-2 изпитване  Вd, с продъл­  
жителност  на изпитването  96 часа при мини­  
малната  температура  – 40 °C. 
Изпитване  съгласно  ISO 16750-4: Глава  
5.1.2.2 Изпитване  за работа  при висока  
температура  (96 часа при 135 °C) 
Това  изпитване  е с позоваване  на IEC 60068- 
2-2: Основни  процедури  за изпитване  на 
въздействия  на околната  среда ; Част  2: 
Изпитвания ; Изпитвания  В: Суха  топлина  213 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 339  
№ Изпитване  Описание  Съответни  изисквания  
4.2 Температурни  цикли  Изпитване  съгласно  ISO 16750-4: Глава  5.3.2: 
Бърза  промяна  на температурата  при зададена  
продължителност  на прехода  (– 40 °C/135 °C, 
20 цикъла , време  на задържане  при всяка  от 
температурите  30 минути ) 
IEC 60068-2-14: Изпитания  на въздействия  на 
околната  среда ; Част  2-14: Изпитвания ; 
Изпитване  N: Промени  на температурата  213 
4.3 Влажностни  цикли  Проверява  се функционалността  (както  е 
дефинирана  в изпитване  № 3.3) чрез 
изпитване  Db по IEC 60068-2-30, със шест  
цикъла  по 24 часа, с промяна  на темпера­  
турата  при всеки  от циклите  от + 25 °C до 
+ 55 °C и относителна  влажност  съответно  
97 % при + 25 °C и 93 % при + 55 °C  214 
4.4 Вибрации  ISO 16750-3: Глава  4.1.2.6: Изпитване  VI: 
Търговско  превозно  средство  (commercial 
vehicle), двигател , скоростна  кутия  
Смесен  режим  на изпитване  за вибрации , 
включително  
а) Изпитване  със синусоидални  вибрации , 
20…520 Hz, 11.4 … 120 m/s  2 , <= 0,5 
октави /минута  
б) Изпитване  за случайни  вибрации , 
10…2 000 Hz, средноквадратична  
стойност  на ускорението  (RMS) 177 m/s  2 
по 94 часа на координатна  ос, включително  с 
температурен  цикъл  – 20…70 °C) 
Това  изпитване  е с позоваване  на IEC 60068- 
2-80: Изпитване  на въздействия  на околната  
среда  — Част  2-80: Изпитвания  — Изпитване  
Fi: Вибрации  — Смесен  режим  на изпитване  219 
4.5 Механичен  удар  ISO 16750-3: Глава  4.2.3: Изпитване  VI: 
Изпитване  за устройства , намиращи  се във 
или върху  скоростната  кутия  
полусинусоидален  удар , ускорение  по съгла­  
суване  в интервала  3 000…15 000 m/s  2 , 
времетраене  на удара  по съгласуване , но 
по-малко  от 1 ms, брой  на ударите : по съгла­  
суване  
Това  изпитване  е с позоваване  на IEC 60068- 
2-27: Изпитания  на въздействия  на околната  
среда . Част  2: Изпитвания . Изпитване  Еа и 
указания : Удар  219 
4.6 Защита  срещу  вода  и 
чужди  тела Изпитване  съгласно  ISO 20653: Пътни  
превозни  средства . Степен  на защита  (IP 
код). Защита  на електрическото  оборудване  
срещу  чужди  обекти , вода  и достъп  
(Целева  стойност  IP 64)  220, 221  
4.7 Защита  срещу  обратна  
полярност  Проверява  се, че датчикът  може  да понесе  
размяна  на полюсите  на своето  електрическо  
захранване  216 
4.8 Защита  срещу  къси  съеди­  
нения  Проверява  се, че входно /изходните  сигнали  
са защитени  срещу  къси  съединения  към 
захранването  и към масата  216 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 340  
№ Изпитване  Описание  Съответни  изисквания  
5. Изпитание  за електромагнитна  съвместимост  
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: 
импулс  1 a: Vs = – 450 V, Ri=50 Ω 
импулс  2 a: Vs = + 37 V, Ri=2 Ω 
импулс  2b: Vs = + 20 V, Ri=0,05 Ω 
импулс  3 a: 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 = 100 ms 
импулс  5: Vs = + 65 V, Ri = 2,2 Ω, td = 250 ms 
Импулс  5 се изпитва  само  за бордови  
устройства , предвидени  за монтиране  на 
превозни  средства , които  не разполагат  с 
устройство  за обща  външна  защита  срещу  
повишено  напрежение  вследствие  разкачане  
на акумулаторната  батерия  при зареждащ  я 
алтернатор  (protection against load dump) 
За примерни  стойности  на повишено  
напрежение  вследствие  разкачане  на акумула­  
торната  батерия  при зареждащ  я алтернатор  
виж стандарт  ISO 16750-2, 4- то издание , глава  
4.6.4.  218 
4. ФУНКЦИОНАЛНИ  ИЗПИТВАНИЯ  НА ТАХОГРАФСКИТЕ  КАРТИ  
Изпитванията  съгласно  настоящия  раздел  4, 
№ 5 „Изпитване  за спазване  на протоколи “ 
№ 6 „Структура  на картата “ и 
№ 7 „Функционални  изпитвания “ 
могат  да бъдат  извършвани  от оценителя  или сертификатора  по време  
на процеса  на сертифициране  за сигурност  по Общите  критерии  
(Common Criteria security certification process) на модула  с чипа . 
Изпитванията  с номера  2.3 и 4.2 са същите . Това  са механичните  
изпитвания  за комбинацията  от тялото  на картата  и модула  с чипа . 
Ако някой  от тези компоненти  (тялото  на картата , модула  с чипа ) е 
променен , тези изпитвания  са необходими . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 341  
№ Изпитване  Описание  Съответни  изисквания  
1. Административен  преглед  
1.1 Документация  Коректност  на документацията  
2 Тяло  на картата  
2.1 Оформление  на 
отпечатването  Проверява  се дали  всички  елементи  за защита  и 
видими  данни  са правилно  отпечатани  на картата  
и дали  са в съответствие . 
[Обозначител ] 
Приложение  1В, глава  4.1 „Видими  данни “, 227) 
Лицевата  страна  трябва  да съдържа : 
думите  „карта  на водач “ или „контролна  карта “ 
или „карта  за монтаж  и настройки “ или „карта  на 
превозвач “, отпечатани  с главни  букви  на офици­  
алния (ите) език(езици ) на държавата  членка , 
която  е издала  картата , според  типа  карта . 
[Наименование  на държавата  членка ] 
Приложение  1В, глава  4.1 „Видими  данни “, 228 
Лицевата  страна  трябва  да съдържа : 
наименованието  на държавата  членка , която  изда- 
ва картата  (незадължително ); 
[Знак ] 
Приложение  1В, глава  4.1 „Видими  данни “, 229) 
Лицевата  страна  трябва  да съдържа : 
отличителния  знак на държавата  членка , издала  
картата , отпечатан  в бяло  на син фон в правоъгъл - 
ник и ограден  с 12 жълти  звезди . 
[Изброяване ] 
Приложение  1В, глава  4.1 „Видими  данни “, 232) 
Обратната  страна  трябва  да съдържа : 
легенда  на номерата , указани  на лицевата  страна  
на картата . 
[Цвят ] 
Приложение  1В, глава  4.1 „Видими  данни “, 234) 
Ц в е т ъ т н а ф о н а п р и о т п е ч а т в а н е т о н а 
тахографските  карти  трябва  да бъде  както  следва : 
— карта  на водач : бял, 
— карта  за монтаж  и настройки : червен , 
— контролна  карта : син, 
— карта  на превозвач : жълт . 227 до 229, 232, 234 
до 236 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 342  
№ Изпитване  Описание  Съответни  изисквания  
[Сигурност ] 
Приложение  1В, глава  4.1 „Видими  данни “, 235) 
Тахографските  карти  трябва  да имат  следните  
елементи  на защита  на тялото  на картата  срещу  
подправяне  и фалшифициране : 
— фон със защитни  характеристики , включващ  
мотиви  с плетеници  (гилоши ) от тънки  линии  и 
ирисов  печат , 
— поне  една  двуцветна  линия  с микропечат . 
[Маркировки ] 
Приложение  1В, глава  4.1 „Видими  данни “, 236) 
Държавите  членки  могат  да добавят  цветове  или 
маркировки , като например  национални  символи  и 
елементи  за сигурност . 
[Маркировка  за одобрение ] 
Тахографските  карти  трябва  да съдържат  маркир - 
овка  за одобрение . 
Маркировката  за одобрение  се състои  от: 
— правоъгълник , в който  е разположена  буквата  
„е“, последвана  от отличителен  номер  или 
буква  на страната , която  е издала  одобрението , 
— номер  на одобрението , съответстващ  на номера  
н а у д о с т о в е р е н и е т о з а о д о б р я в а н е н а 
тахографската  карта , разположен  в непосредст - 
вена  близост  до посочения  правоъгълник . 
2.2 Механични  изпит­  
вания  [Размер  на картата ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810, Идентификационни  карти . 
Физични  характеристики , 
[5] Големина  на картата , 
[5.1] Размер  на картата , 
[5.1.1] Размери  на картата  и допуски , 
карта  тип ID-1 Неизползвана  карта  
[Ръбове  на картата ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810, Идентификационни  карти . Физични  
характеристики , 
[5] Големина  на картата , 
[5.1] Размер  на картата , 
[5.1.2] Ръбове  на картата  240, 243 
ISO/IEC 7810  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 343  
№ Изпитване  Описание  Съответни  изисквания  
[Конструкция  на картата ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810, Идентификационни  карти . Физични  
характеристики , 
[6] Конструкция  на картата  
[Материали , от които  се състои  картата ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810, Идентификационни  карти . Физични  
характеристики , 
[7] Материали , от които  се състои  картата  
[Коравина  на огъване ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810, Идентификационни  карти . Физични  
характеристики , 
[8] Характеристики  на картата , 
[8.1] Коравина  на огъване  
[Токсичност ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810, Идентификационни  карти . Физични  
характеристики , 
[8] Характеристики  на картата  
[8.3] Токсичност  
[Устойчивост  на химикали ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810, Идентификационни  карти . Физични  
характеристики , 
[8] Характеристики  на картата , 
[8.4] Устойчивост  на химикали  
[Устойчивост  на картата ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810, Идентификационни  карти . Физични  
характеристики , 
[8] Характеристики  на картата , 
[8.5] Устойчивост  на размерите  на картата  и 
температурно  и влажностно  измятане  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 344  
№ Изпитване  Описание  Съответни  изисквания  
[Светлина ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810, Идентификационни  карти . Физични  
характеристики , 
[8] Характеристики  на картата , 
[8.6] Светлина  
[Дълготрайност ] 
Приложение  1В, глава  4.4, „Спецификации  във 
в р ъ з к а с о к о л н а та с р ед а и е л е к тр и ч е с к и 
спецификации “, 241) 
Тах о гр аф ски те кар ти тр я бв а да мо гат да 
функционират  правилно  през период  от пет год- 
и н и , а к о с е и з п о л з в а т в р а м к и т е н а 
спецификациите  във връзка  с околната  среда  и 
електрическите  спецификации . 
[Якост  на разслояване ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810, Идентификационни  карти . Физични  
характеристики , 
[8] Характеристики  на картата , 
[8.8] Якост  на разслояване  
[Прилепване  или блокиране ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810, Идентификационни  карти . Физични  
характеристики , 
[8] Характеристики  на картата , 
[8.9] Прилепване  или блокиране  
[Измятане ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810, Идентификационни  карти . Физични  
характеристики , 
[8] Характеристики  на картата , 
[8.11] Общо  измятане  на картата  
[Устойчивост  на топлина ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810, Идентификационни  карти . Физични  
характеристики , 
[8] Характеристики  на картата , 
[8.12] Устойчивост  на топлина  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 345  
№ Изпитване  Описание  Съответни  изисквания  
[Деформации  на повърхността ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810, Идентификационни  карти . Физични  
характеристики , 
[8] Характеристики  на картата , 
[8.13] Деформации  на повърхността  
[Замърсяване ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810, Идентификационни  карти . Физични  
характеристики , 
[8] Характеристики  на картата , 
[8.14] Замърсяване  и взаимодействие  на компо - 
нентите  на картата  
2.3 Механични  
изпитвания  с вграден  
модул  с чип [Огъване ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810:2003/Amd. 1:2009, Идентифика­  
ционни  карти . Физични  характеристики , 
Изменение  1: Критерии  за карти , съдържащи  
интегрални  схеми  
[9.2] Динамично  напрежение  на огъване  
Общ  брой  цикли  на огъване : 4 000. 
[Усукване ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810:2003/Amd. 1:2009, Идентифи - 
кационни  карти . Физични  характеристики , Изме - 
н е н и е 1 : К р и те р и и з а к ар ти , съ д ър ж а щ и 
интегрални  схеми  
[9.3] Динамично  напрежение  на усукване  
Общ  брой  цикли  на усукване : 4 000.  ISO/IEC 7810  
3 Модул  
3.1 Модул  Модулът  е корпусът  на чипа  и контактната  
повърхност . 
[Повърхностен  профил ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7816-1:2011, Идентификационни  карти . 
Карти  с интегрална (и) схема (и). Част  1: Карти  с 
контакти . Физични  характеристики  
[4.2] Повърхностен  профил  на контактите  ISO/IEC 7816  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 346  
№ Изпитване  Описание  Съответни  изисквания  
[Механична  якост ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7816-1:2011, Идентификационни  карти . 
Карти  с интегрална (и) схема (и). Част  1: Карти  с 
контакти . Физични  характеристики  
[4.3] Механична  якост  (на карта  и контакти ) 
[Електрическо  съпротивление ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7816-1:2011, Идентификационни  карти . 
Карти  с интегрална (и) схема (и). Част  1: Карти  с 
контакти . Физични  характеристики  
[4.4] Електрическо  съпротивление  (на контактите ) 
[Размери ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7816-2:2007, Идентификационни  карти . 
Карти  с интегрална (и) схема (и). Част  2: Карти  с 
контакти . Размери  и разположение  на контактите  
[3] Размери  на контактите  
[Разположение ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7816-2:2007, Идентификационни  карти . 
Карти  с интегрална (и) схема (и). Част  2: Карти  с 
контакти . Размери  и разположение  на контактите  
[4] Брой  и разположение  на контактите  
При модулите  със шест  контакти , настоящото  
изискване  за изпитване  не се отнася  за контакти  
„C4“ и „C8“.  
4 Чип  
4.1 Чип 
[[Работна  температура ] 
Чипът  на тахографската  карта  трябва  да може  да 
функционира  при околна  температура  в 
интервала  между  – 25 °C и + 85 °C.  241 до 244 
Правило  № 10 на 
ИКЕ  на ООН  
ISO/IEC 7810 
ISO/IEC 10373  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 347  
№ Изпитване  Описание  Съответни  изисквания  
[Температура  и влажност ] 
Приложение  1В, глава  4.4, „Спецификации  във 
връзка  с околната  среда  и електрически  специфи­  
кации “, 241) 
Тахографските  карти  трябва  да могат  да 
функционират  правилно  при всички  климатични  
условия , които  нормално  се наблюдават  на тери­  
торията  на Общността , и в минимален  темпе­  
ратурен  интервал  от – 25 °C до + 70 °C, с крат­  
котрайни  и редки  върхови  стойности  до + 85 °C, 
като „краткотрайни  и редки “ означава  продължи­  
телност  под 4 часа и не повече  от 100 пъти  по 
време  на живота  на картата . 
Тахографските  карти  се подлагат  в послед­  
ователни  стъпки  на следните  температури  и 
влажности  в посоченото  време . След  всяка  
стъпка  тахографските  карти  се изпитват  за елек­  
трическа  функционалност . 
1. Температура  – 20 °C в продължение  на 2 часа. 
2. Температура  +/– 0 °C в продължение  на 2 часа. 
3. Температура  + 20 °C и 50 % относителна  
влажност  в продължение  на 2 часа. 
4. Температура  + 50 °C и 50 % относителна  
влажност  в продължение  на 2 часа. 
5. Температура  + 70 °C и 50 % относителна  
влажност  в продължение  на 2 часа. 
Температурата  се увеличава  с прекъсвания  до 
+ 85 °C и 50 % относителна  влажност  в 
продължение  на 60 минути . 
6. Температура  70 °C и 85 % относителна  
влажност  в продължение  на 2 часа. 
Температурата  се увеличава  с прекъсвания  до 
+ 85 °C и 85 % относителна  влажност  в 
продължение  на 30 минути . 
[Влажност ] 
Приложение  1В, глава  4.4, „Спецификации  във 
в р ъ з к а с о к о л н а та с р ед а и е л е к тр и ч е с к и 
спецификации “, 242) 
Тах о гр аф ски те кар ти тр я бв а да мо гат да 
ф у н к ц и о н и р ат п р ави лн о п р и и н тер в ал н а 
влажността  от 10 % до 90 %. 
[Електромагнитна  съвместимост  — ЕМС ] 
Приложение  1В, глава  4.4 „Спецификации  във 
в р ъ з к а с о к о л н а та с р ед а и е л е к тр и ч е с к и 
спецификации “, 244) 
При функционирането  си тахографските  карти  
трябва  да са в съответствие  с Правило  № 10 на 
ИКЕ  на ООН  по отношение  на електромагнитната  
съвместимост . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 348  
№ Изпитване  Описание  Съответни  изисквания  
[Статично  електричество ] 
Приложение  1В, глава  4.4 „Спецификации  във 
в р ъ з к а с о к о л н а та с р ед а и е л е к тр и ч е с к и 
спецификации “, 244) 
При функционирането  си тахографските  карти  
трябва  да бъдат  защитени  срещу  електростатични  
разряди . 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810:2003/Amd. 1:2009, Идентифи - 
кационни  карти . Физични  характеристики , Изме - 
н е н и е 1 : К р и те р и и з а к ар ти , съ д ър ж а щ и 
интегрални  схеми  
[9.4] Статично  електричество  
[9.4.1] Контактни  карти  с интегрална (и) схема (и) 
Изпитвателно  напрежение : 4 000 V 
[Рентгенови  лъчи ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810:2003/Amd. 1:2009, Идентифи - 
кационни  карти . Физични  характеристики , Изме - 
н е н и е 1 : К р и те р и и з а к ар ти , съ д ър ж а щ и 
интегрални  схеми  
[9.1] Рентгенови  лъчи  
[Ултравиолетова  светлина ] 
ISO/IEC 10373-1:2006, Идентификационни  карти . 
М е т о д и з а и з п и т в а н е . Ч а с т 1 : О б щ и 
характеристики  
[5.11] Ултравиолетова  светлина  
[Триролково  изпитване  — 3-wheel] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 10373-1:2006/Amd. Идентификационни  
карти . Методи  за изпитване . Част  1: Общи  
характеристики , Изменение  1 
[5.22] ICC — Механична  якост : Триролково  
изпитване  за карти  с интегрална (и) схема (и) с 
контакти  
[„Обвивка “ на чипа  — Wrapping] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
MasterCard CQM V2.03:2013 
[11.1.3] R-L3-14-8: Изпитване  за издържливостта  
на закрепването  на чипа  към тялото  на картата  
чрез огъване  на картата  (wrapping test robustness) 
[13.2.1.32] TM-422: Механична  надеждност : Из- 
питване  на опаковката  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 349  
№ Изпитване  Описание  Съответни  изисквания  
4.2 Механични  
изпитвания  на модула  
с чипа , вграден  в 
тялото  на картата  -> 
също  като в точка  2.3 [Огъване ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810:2003/Amd. 1:2009, Идентифика­  
ционни  карти . Физични  характеристики , 
Изменение  1: Критерии  за карти , съдържащи  
интегрални  схеми  
[9.2] Динамично  напрежение  на огъване  
Общ  брой  цикли  на огъване : 4 000. 
[Усукване ] 
Тахографските  карти  трябва  да съответстват  на 
стандарта  
ISO/IEC 7810:2003/Amd. 1:2009, Идентифи - 
кационни  карти . Физични  характеристики , Изме - 
н е н и е 1 : К р и те р и и з а к ар ти , съ д ър ж а щ и 
интегрални  схеми  
[9.3] Динамично  напрежение  на усукване  
Общ  брой  цикли  на усукване : 4 000.  ISO/IEC 7810  
5 Изпитвания  за спазване  на протоколи  
5.1 Отговор  на инициа­  
лизиране  (ATR)  Проверява  се съответствието  на ATR  ISO/IEC 7816-3 
TCS_14, TCS_17, 
TCS_18  
5.2 T=0  Проверява  се съответствието  на протокола  T = 0  ISO/IEC 7816-3 
TCS_11, TCS_12, 
TCS_13, TCS_15  
5.3 Избор  на типа  
протокол  (PTS)  Проверява  се съответствието  на командата  PTS, 
като се преминава  към T = 1от T = 0  ISO/IEC 7816-3 
TCS_12, TCS_19, 
TCS_20, TCS_21  
5.4 T=1  Проверява  се съответствието  на протокола  T = 1  ISO/IEC 7816-3 
TCS_11, TCS_13, 
TCS_16  
6 Структура  на картата  
6.1 Проверява  се съответствието  на записаната  на 
картата  структура  на файловете , като се 
проверява  наличието  на задължителните  файлове  
на картата , както  и условията  за достъп  до тях TCS_22 до TCS_28 
TCS_140 до TCS_179  
7 Функционални  изпитвания  
7.1 Нормално  функцио­  
ниране  Проверява  се поне  веднъж  всяко  разрешено  
използване  на всяка  команда  (напр . проверява  се 
командата  UPDATE BINARY с CLA = „00“, CLA 
= „0C“ и с различни  параметри  P1, P2 и Lc) 
Проверява  се дали  операциите  действително  са 
изпълнени  в картата  (напр .: чрез прочитане  на 
файла , върху  който  е била  изпълнена  командата ) TCS_29 до TCS_139  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 350  
№ Изпитване  Описание  Съответни  изисквания  
7.2 Съобщения  за грешки  Изпробва  се поне  веднъж  всяко  съобщение  за 
грешка  (както  е посочено  в допълнение  2) за 
всяка  команда . 
Изпробва  се поне  веднъж  всяка  типова  (generic) 
грешка  (с изключение  на грешките  за цялост  
„6400“, които  се проверяват  при сертифицирането  
за сигурност ) 
7.3 Криптографска  поредица  (cypher suite) и стандартизирани  домейн  пара­  
метри  CSM_48, CSM_50  
8 Персонализиране  
8.1 Визуално  персонали­  
зиране  Приложение  1В, глава  4.1 „Видими  данни “, 230) 
Лицевата  страна  трябва  да съдържа : 
информация , специфична  за издадената  карта . 
Приложение  1В, глава  4.1 „Видими  данни “, 231) 
Лицевата  страна  трябва  да съдържа : 
дати  с формат  „дд/мм/гггг“ или „дд.мм.гггг“ (ден, 
месец , година ). 
Приложение  1В, глава  4.1 „Видими  данни “, 235) 
Тахографските  карти  трябва  да имат  следните  
елементи  на защита  на тялото  на картата  срещу  
подправяне  и фалшифициране : 
— в зоната  на снимката  трябва  да се припокриват  
фонът  със защитни  характеристики  и снимката . 230, 231, 235  
5. ИЗПИТВАНИЯ  НА ВЪНШНОТО  УСТРОЙСТВО  ЗА GNSS  
№ Изпитване  Описание  Съответни  изисквания  
1. Административен  преглед  
1.1 Документация  Коректност  на документацията  
2. Визуално  инспектиране  на външното  устройство  за GNSS  
2.1. Съответствие  с документацията  
2.2. Идентификация /маркировки  224 до 226  
2.3 Материали  219 до 223  
3. Функционални  изпитвания  
3.1 Данни  за идентифициране  на датчика  98, 99  
3.2 Свързване  на модула  за GNSS и бордовото  устройство  123, 205  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 351  
№ Изпитване  Описание  Съответни  изисквания  
3.3 Местоположение  съгласно  GNSS  36, 37  
3.4 Интерфейс  на бордовото  устройство , когато  приемникът  за сигнали  от 
GNSS е извън  бордовото  устройство  03 
3.5 Криптографска  поредица  (cypher suite) и стандартизирани  домейн  пара­  
метри  CSM_48, CSM_50  
4. Изпитания  за въздействията  на околната  среда  
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 цикъла , време  на 
задържане  при всяка  от температурите  1 час) 
Възможно  е да се проведат  намален  набор  изпитвания  
(измежду  посочените  в раздел  3 на настоящата  таблица ) 
съответно  при ниските  температури , високите  темпе­  
ратури  и температурните  цикли  213 
4.2 Влажност  Проверява  се, че бордовото  устройство  може  да понесе  
циклично  изпитване  на топлина  във влажна  среда  
съгласно  IEC 60068-2-30, изпитване  Db, със шест  
цикъла  по 24 часа, като във всеки  от тях температурата  
се изменя  от + 25 °C до + 55 °C и относителната  
влажност  е съответно  97 % при + 25 °C и 93 % при + 
55 °C  214 
4.3 Механични  
въздействия  1. Синусоидални  вибрации . 
Проверява  се, че бордовото  устройство  може  да 
понесе  синусоидни  вибрации  със следните  характе­  
ристики : 
постоянно  изместване , при честота  между  5 и 11 Hz: 
максимум  10 mm 
постоянно  ускорение , при честота  между  11 и 300 Hz: 
5 g 
Съответствието  с това изискване  с проверява  чрез 
изпитване  Fc по IEC 60068-2-6, с минимално  
времетраене  на изпитването  3 × 12 часа (по 12 часа 
на координатна  ос) 
Стандартът  ISO 16750-3 не изисква  да се провежда  
изпитване  със синусоидални  вибрации  за устройства , 
намиращи  се в отделна  кабина  на превозното  
средство  (decoupled vehicle cab).  219 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 352  
№ Изпитване  Описание  Съответни  изисквания  
2. Случайни  вибрации : 
Изпитване  съгласно  ISO 16750-3: Глава  4.1.2.8: Из- 
питване  VIII: Търговски  превозни  средства  (commer- 
cial vehicles) с отделна  кабина  
Изпитване  за случайни  вибрации  (Random vibration 
test), 10…2 000 Hz, вертикално  средноквадратично  
отклонение  21,3 m/s  2 , надлъжно  средноквадратично  
отклонение  11,8 m/s  2 , напречно  средноквадратично  
отпклонение  13,1 m/s  2 , 3 оси, по 32 часа за ос, 
включително  температурен  цикъл  – 20…70 °C. 
Това  изпитване  е с позоваване  на IEC 60068-2-64: 
Изпитване  на въздействия  на околната  среда  — Част  2- 
6 4: И зпи тван  ия — И зп итване  Fh : Ви бр аци и, 
широколентови  случайни , и указания  
3. Удари : 
механичен  удар  с ускорение  3g, полусинусоидален , 
съгласно  ISO 16750. 
Гореописаните  изпитвания  се извършват  върху  различни  
мостри  на изпитваните  съоръжения . 
4.4 Защита  срещу  
вода  и чужди  
тела Изпитване  съгласно  ISO 20653: Пътни  превозни  
средства . Степен  на защита  (IP код). Защита  на електри­  
ческото  оборудване  срещу  чужди  обекти , вода  и достъп  
(запазване  на параметрите ) 220, 221  
4.5 Защита  срещу  
пренапрежения  Проверява  се, че бордовото  устройство  може  да понесе  
захранващо  напрежение  както  следва : 216 
при варианти  за 24 V:  34 V при + 40 °C в 
продължение  на 1 
час 
при варианти  за 12 V:  17 V при + 40 °C в 
продължение  на 1 
час 
(ISO 16750-2, глава  4.3)  
4.6 Защита  срещу  
обратна  
полярност  Проверява  се, че бордовото  устройство  може  да 
издържи  на размяна  на полюсите  на своето  електрическо  
захранване  
(ISO 16750-2, глава  4.7)  216 
4.7 Защита  срещу  
къси  съеди­  
нения  Проверява  се, че входно /изходните  сигнали  са защитени  
срещу  къси  съединения  към захранването  и към масата  
(ISO 16750-2, глава  4.10)  216 
5 Изпитание  за електромагнитна  съвместимост  (EMC)  
5.1 Излъчени  
емисии  и чувст­  
вителност  към 
тях Съответствие  с Правило  № 10 на ИКЕ  на ООН  218  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 353  
№ Изпитване  Описание  Съответни  изисквания  
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 Ω 
импулс  2 a: Vs= + 37 V, Ri = 2 Ω 
импулс  2b: Vs= + 20 V, Ri = 0,05 Ω 
импулс  3 a: 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 = 250ms 
При варианти  за напрежение  12 V: съответствие  със 
стандарт  ISO 7637-1 + Правило  № 10 на ИКЕ  на 
ООН , Преработка  3: 
импулс  1: Vs= – 75 V, Ri = 10 Ω 
импулс  2 a: Vs= + 37 V, Ri = 2 Ω 
импулс  2b: Vs= + 10 V, Ri = 0,05 Ω 
импулс  3 a: Vs= – 112 V, Ri = 50 Ω 
импулс  3b: Vs= + 75 V, Ri = 50 Ω 
импулс  4: Vs = – 6 V, Va = – 5 V, t6 = 100 ms 
импулс  5: Vs= + 65 V, Ri = 2,2 Ω, td = 250ms 
Импулс  5 се изпитва  само  за бордови  устройства , пред­  
видени  за монтиране  на превозни  средства , които  не 
разполагат  с устройство  за обща  външна  защита  срещу  
повишено  напрежение  вследствие  разкачане  на акумула­  
торната  батерия  при зареждащ  я алтернатор  (protection 
against load dump) 
За примерни  стойности  на повишено  напрежение  
вследствие  разкачане  на акумулаторната  батерия  при 
зареждащ  я алтернатор , вижте  стандарт  ISO 16750-2, 4- 
то издание , глава  4.6.4.  218 
▼M1 
6. ИЗПИТВАНИЯ  НА ВЪНШНОТО  УСТРОЙСТВО  ЗА ВРЪЗКА  ОТ 
РАЗСТОЯНИЕ  
№ Изпитване  Описание  Съответни  изисквания  
1. Административен  преглед  
1.1 Документиране  Правилност  на доку­  
ментацията  
2. Визуално  инспектиране  
2.1. Съответствие  с документацията  
2.2. Идентификация /маркировки  225, 226  
2.3 Материали  219 до 223  
3. Функционални  изпитвания  
3.1 Връзка  от разстояние  за извършване  на целенасочени  пътни  проверки  4, 197 до 199  
3.2 Записване  и съхраняване  на данните  в паметта  91  
3.3 Връзка  с бордовото  устройство  Допълнение  14, 
раздели  DSC_66 до 
DSC_70 и DSC_71 
до DSC_76  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 354  
№ Изпитване  Описание  Съответни  изисквания  
4. Изпитвания  за въздействията  на околната  среда  
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 цикъла , време  
на задържане  при всяка  от температурите  1 час) 
Възможно  е да се проведат  намален  набор  
изпитвания  (измежду  посочените  в раздел  3 от 
настоящата  таблица ) съответно  при ниските  темпе­  
ратури , високите  температури  и температурните  
цикли  213 
4.2 Защита  срещу  
проникване  на 
вода  и чужди  тела Изпитване  съгласно  ISO 20653: Пътни  превозни  
средства . Степен  на защита  (IP код). Защита  на елек­  
трическото  оборудване  срещу  проникване  на чужди  
тела, вода  и достъп  (целева  стойност  IP40)  220, 221  
5 Изпитание  за електромагнитна  съвместимост  (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 Ω 218 ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 355  
№ Изпитване  Описание  Съответни  изисквания  
импулс  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.  
▼B 
7. ФУНКЦИОНАЛНИ  ИЗПИТВАНИЯ  ЗА РАЗПЕЧАТВАНЕ  ВЪРХУ  
ХАРТИЕН  НОСИТЕЛ  
№ Изпитване  Описание  Съответни  изисквания  
1. Административен  преглед  
1.1 Документация  Коректност  на документацията  
2 Общи  изпитвания  
2.1 Брой  знаци  на ред Визуално  инспектиране  на разпечатките . 172  
2.2 Минимален  размер  
на знаците  Визуално  инспектиране  на разпечатката  и инспек­  
тиране  на знаците . 173 
2.3 Поддържани  
набори  от символи  Печатащото  устройство  трябва  да може  да отпечатва  
символите , специфицирани  в допълнение  1, глава  4, 
„Набори  от символи “. 174 
2.4 Дефиниране  на 
разпечатките  Проверка  на одобрението  на типа  на тахографа  и 
визуално  инспектиране  на разпечатките  174 
2.5 Четливост  и иден­  
тифициране  на 
разпечатките  Инспектиране  на разпечатките  
Докладва  се чрез доклади  от изпитвания  и 
протоколи  от изпитвания  от производителя . 
Всички  хомологационни  номера  на тахографи , с 
които  може  да се използва  съответната  печатна  
хартия , са отбелязани  върху  хартията . 175, 177, 178  
2.6 Добавяне  на 
ръкописни  бележки  Визуално  инспектиране : Налично  е поле  за подпис  
на водача . 
Налични  са полета  за други  ръкописни  бележки . 180 
2.7 Допълнителни  
данни  върху  
лицевата  страна  на 
хартията . Върху  лицевата  и обратната  страна  на хартията  
могат  да присъстват  допълнителни  данни  и инфор­  
мация . 
Тези  допълнителни  данни  и информация  не трябва  
да пречат  на четливостта  на разпечатките . 
Визуално  инспектиране . 177, 178  ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 356  
№ Изпитване  Описание  Съответни  изисквания  
3 Изпитвания  за съхранение  
3.1 Суха  топлина  Предварителна  подготовка : 16 часа при + 23°C ± 
2°C/55 % ±3 % относителна  влажност  
Среда  за изпитването : 72 часа при +70 °C ± 2 °C; 
Възстановяване  след  изпитването : 16 часа при 
+23°C ± 2°C/55 % ±3 % относителна  влажност  176, 178 
IEC 60068-2-2-Bb  
2.2 Топлина  във 
влажна  среда  Предварителна  подготовка : 16 часа при +23°C ± 
2°C/55 % ±3 % относителна  влажност  
Среда  за изпитването : 144 часа при + 55 °C ± 2°C/ 
93 % ±3 % относителна  влажност  
Възстановяване  след  изпитването : 16 часа при + 
23°C ± 2°C/55 % ± 3 % относителна  влажност  176, 178 
IEC 60068-2-78-Cab  
4 Изпитвания  на работна  хартия  
4.1 Устойчивост  на 
влага  на фона  
(хартията  без 
отпечатване  върху  
нея) Предварителна  подготовка : 16 часа при + 23°C ± 
2°C/55 % ±3 % относителна  влажност  
Среда  за изпитването : 144 часа при +55 °C ± 2°C/ 
93 % ±3 % относителна  влажност  
Възстановяване : 16 часа при +23°C ± 2°C/55 % ±3 % 
относителна  влажност  176, 178 
IEC 60068-2-78-Cab  
4.2 Пригодност  за 
печатане  Предварителна  подготовка : 24 часа при +40 °C ± 
2°C/93 % ± 3 % относителна  влажност  
Среда  за изпитването : разпечатка , извършена  при 
+23 °C ± 2 °C 
Възстановяване : 16 часа при +23°C ± 2°C/55 % ±3 % 
относителна  влажност  176, 178  
4.3 Устойчивост  на 
топлина  Предварителна  подготовка : 16 часа при + 23°C ± 
2°C/55 % ± 3 % относителна  влажност  
Среда  за изпитването : 2 часа при + 70 °C ± 2 °C; 
Възстановяване : 16 часа при +23°C ± 2°C/55 % ±3 % 
относителна  влажност  176, 178 
IEC 60068-2-2-Bb  
4.4 Устойчивост  на 
ниска  температура  Предварителна  подготовка : 16 часа при + 23°C ± 
2°C/55 % ±3 % относителна  влажност  
Среда  за изпитването : 24 часа при – 20 °C ± 3 °C, 
сух студ  
Възстановяване : 16 часа при + 23°C ± 2°C/55 % ± 
3 % относителна  влажност  176, 178 
ISO 60068-2-1-Ab  
4.5 Устойчивост  на 
светлина  Предварителна  подготовка : 16 часа при + 23°C ± 
2°C/55 % ±3 % относителна  влажност  
Среда  за изпитването : 100 часа при осветеност  5 000 
лукса  и при + 23°C ± 2°C/55 % ±3 % относителна  
влажност  
Възстановяване : 16 часа при +23°C ± 2°C/55 % ±3 % 
относителна  влажност  176, 178  
Критерии  за четливост  за изпитванията  3.x и 4.x:  
Четливостта  на разпечатките  е осигурена  ако стойностите  на оптичната  
плътност  са в съответствие  със следните  гранични  стойности : 
Отпечатани  знаци : минимум  1,0 
Фон (хартия  без отпечатване  върху  нея) максимум  0,2 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 357  
Стойностите  на оптичната  плътност  на съответните  разпечатки  трябва  
да се измерват  в съответствие  с DIN EN ISO 534.  
Разпечатките  не трябва  да имат  променени  размери  и трябва  да остават  
ясно  четливи . 
8. ИЗПИТВАНИЯ  ЗА ОПЕРАТИВНА  СЪВМЕСТИМОСТ  
▼M1 
№ Изпитване  Описание  
8.1 Изпитвания  за оперативна  съвместимост  между  бордови  устройства  и тахографски  карти  
1 Взаимно  удостоверяване  на 
автентичност  Проверява  се дали  взаимното  удостоверяване  на автентичност  
между  бордовото  устройство  и тахографската  карта  протича  
нормално  
2 Изпитвания  за четене  
/записване  Върху  бордовото  устройство  се изпълнява  сценарий  на типично  
действие . Сценарият  трябва  да е адаптиран  към изпитвания  тип 
карта  и да включва  записвания  във възможно  най-голям  брой  
елементарни  файлове  (EF) в картата  
Чрез  изтегляне  на данните  от бордовото  устройство  се проверява  
дали  всички  съответни  записи  са направени  правилно . 
Чрез  изтегляне  на данните  от картата  се проверява  дали  всички  
съответни  записи  са направени  правилно . 
Чрез  дневни  разпечатки  се проверява  дали  всички  съответни  
записи  могат  да бъдат  прочетени  правилно . 
8.2 Изпитвания  за оперативна  съвместимост  между  бордови  устройства  и датчици  за движение  
1 Сдвояване  Проверява  се дали  сдвояването  между  бордовите  устройства  и 
датчиците  за движение  протича  нормално  
2 Изпитвания  на действието  Върху  датчика  за движение  се изпълнява  сценарий  на типично  
действие . Сценарият  трябва  да включва  нормално  действие  и 
създаване  на възможно  най-много  събития  или неизправности . 
Чрез  изтегляне  на данните  от бордовото  устройство  се проверява  
дали  всички  съответни  записи  са направени  правилно . 
Чрез  изтегляне  на данните  от картата  се проверява  дали  всички  
съответни  записи  са направени  правилно . 
Чрез  дневна  разпечатка  се проверява  дали  всички  съответни  
записи  могат  да бъдат  прочетени  правилно . 
8.3 Изпитвания  за оперативна  съвместимост  между  бордови  устройства  и външни  устройства  за GNSS 
(когато  има такива ) 
1 Взаимно  удостоверяване  на 
автентичност  Проверява  се дали  взаимното  удостоверяване  на автентичност  
(свързване ) между  бордовото  устройство  и външното  устройство  
за GNSS протича  нормално . 
2 Изпитвания  на действието  Върху  външното  устройство  за GNSS се изпълнява  сценарий  на 
типично  действие . Сценарият  трябва  да включва  нормално  
действие  и създаване  на възможно  най-много  събития  или 
неизправности . 
Чрез  изтегляне  на данните  от бордовото  устройство  се проверява  
дали  всички  съответни  записи  са направени  правилно . 
Чрез  изтегляне  на данните  от картата  се проверява  дали  всички  
съответни  записи  са направени  правилно . 
Чрез  дневна  разпечатка  се проверява  дали  всички  съответни  
записи  могат  да бъдат  прочетени  правилно . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 358  
Допълнение  10 
ИЗИСКВАНИЯ  ЗА СИГУРНОСТ  
В настоящото  допълнение  са специфицирани  изискванията  за информа­  
ционна  сигурност  по отношение  на компонентите  на интелигентните  тахог­  
рафски  системи  (тахографите  от второ  поколение ). 
SEC_001 Сертифициране  за сигурност  по Схемата  за общите  критерии  се 
изисква  за следните  компоненти  на интелигентната  тахографска  
система : 
— бордовото  устройство , 
— тахографската  карта , 
— датчика  за движение , 
— външното  устройство  за GNSS.  
SEC_002 Минималните  изисквания  за информационна  сигурност , на които  
трябва  да отговаря  всеки  компонент , подлежащ  на сертифи­  
циране  за сигурност , се дефинират  в защитен  профил  на компо­  
нента , в съответствие  със Схемата  за общите  критерии . 
SEC_003 За посочените  по-долу  четири  защитни  профила  в съответствие  с 
настоящото  приложение  Европейската  комисия  трябва  да 
осигури  те да бъдат  спонсорирани , разработени , одобрени  от 
държавните  сертификационни  органи  по информационна  
сигурност , които  са организирани  в рамките  на Съвместната  
интерпретационна  работна  група  (Joint Interpretation Working 
Group — JIWG), която  съдейства  за взаимното  признаване  на 
сертификатите  под егидата  на Европейското  споразумение  за 
взаимно  признаване  на сертификатите  за оценка  на сигурността  
на информационните  технологии  (Agreement on Mutual Recog ­
nition of Information Technology Security Evaluation Certificates 
— SOGIS-MRA), както  и регистрирани : 
— Защитен  профил  за бордово  устройство , 
— Защитен  профил  за тахографска  карта , 
— Защитен  профил  за датчик  за движение , 
— Защитен  профил  за външно  устройство  за GNSS.  
Защитният  профил  за бордово  устройство  трябва  да се отнася  за случаите , 
при които  бордовият  блок  е проектиран  да се използва  със или без външно  
устройство  за GNSS. В първия  от тези два случая  изискванията  за сигурност  
за външното  GNSS устройство  се посочват  в неговия  защитен  профил . 
SEC_004 Производителите  на компоненти  трябва  да уточняват  и допълват  
съответния  защитен  профил , както  е необходимо , без да изменят  
или изтриват  съществуващи  заплахи , цели , процедурни  средства  
и спецификации  за функции  за обезпечаване  на сигурност , така 
че да формулират  цел за сигурност , спрямо  която  да канди­  
датстват  за сертифициране  за сигурност  на съответния  
компонент . 
SEC_005 По време  на процеса  на оценка  трябва  да бъде  декларирано  
наличието  на строго  съответствие  на такава  специфична  цел за 
сигурност  със съответния  защитен  профил . 
SEC_006 Нивото  на сигурност  на всеки  защитен  профил  трябва  да бъде  
EAL4, увеличено  с компонентите  за сигурност  ATE_DPT.2 и 
AVA_VAN.5.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 359  
Допълнение  11 
ОБЩИ  МЕХАНИЗМИ  ЗА СИГУРНОСТ  
СЪДЪРЖАНИЕ  
ПРЕАМБЮЛ  
ЧАСТ  А ТАХОГРАФСКА  СИСТЕМА  ОТ ПЪРВО  ПОКОЛЕНИЕ  
1. ВЪВЕДЕНИЕ  
1.1. Позовавания  
1.2. Означения  и съкращения  на термини  
2. КРИПТОГРАФСКИ  СИСТЕМИ  И АЛГОРИТМИ  
2.1. Криптографски  системи  
2.2. Криптографски  алгоритми  
2.2.1 Алгоритъм  RSA  
2.2.2 Алгоритъм  за хеширане  
2.2.3 Алгоритъм  за криптиране  на данни  
3. КЛЮЧОВЕ  И СЕРТИФИКАТИ  
3.1. Генериране  и разпределение  на ключове  
3.1.1 Генериране  и разпределение  на ключове  RSA  
3.1.2 Ключове  за контрол  с RSA  
3.1.3 Ключове  за датчика  за движение  
3.1.4 Генериране  и разпределение  на сесийни  T-DES ключове  
3.2. Ключове  
3.3. Сертификати  
3.3.1 Съдържание  на сертификатите  
3.3.2 Издадени  сертификати  
3.3.3 Проверка  и разкриване  на съдържанието  на сертификатите  
4. МЕХАНИЗЪМ  ЗА ВЗАИМНО  УДОСТОВЕРЯВАНЕ  НА 
АВТЕНТИЧНОСТТА  
5. МЕХАНИЗМИ  ЗА ПОВЕРИТЕЛНОСТ , ЦЯЛОСТНОСТ  И 
УДОСТОВЕРЯВАНЕ  НА АВТЕНТИЧНОСТТА  ПРИ  ОБМЕН  
НА ДАННИ  МЕЖДУ  БОРДОВО  УСТРОЙСТВО  И КАРТА  
5.1. Защитен  обмен  на съобщения  
5.2. Третиране  на грешки  при защитен  обмен  на съобщения  
5.3. Алгоритъм  за изчисляване  на криптографските  контролни  суми  
5.4. Алгоритъм  за изчисление  на криптограмите  за поверителни  
обекти  от данни  
6. МЕХАНИЗМИ  ЗА ИЗТЕГЛЯНЕ  НА ДАННИ  С ЕЛЕК­  
ТРОННИ  ПОДПИСИ  
6.1. Генериране  на подписи  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 360  
6.2. Проверка  на подписите  
ЧАСТ  Б ТАХОГРАФСКА  СИСТЕМА  ОТ ВТОРО  ПОКОЛЕНИЕ  
7. ВЪВЕДЕНИЕ  
7.1. Позовавания  
7.2. Означения  и съкращения  
7.3. Определения  
8. КРИПТОГРАФСКИ  СИСТЕМИ  И АЛГОРИТМИ  
8.1. Криптографски  системи  
8.2. Криптографски  алгоритми  
8.2.1 Симетрични  алгоритми  
8.2.2 Асиметрични  алгоритми  и стандартизирани  домейн  параметри  
8.2.3 Алгоритми  за хеширане  
8.2.4 Криптографски  поредици  
9. КЛЮЧОВЕ  И СЕРТИФИКАТИ  
9.1. Двойки  от асиметрични  ключове  и сертификати  на публични  
ключове  
9.1.1 Общи  положения  
9.1.2 Европейско  равнище  
9.1.3 Равнище  на държава  членка  
9.1.4 Равнище  на съответното  оборудване : бордови  устройства  
9.1.5 Равнище  на вид оборудване : Тахографски  карти  
9.1.6 Равнище  на вид оборудване : външни  устройства  за GNSS  
9.1.7 Обобщение : замяна  на сертификати  
9.2. Симетрични  ключове  
9.2.1 Ключове  за обезпечаване  на сигурността  на връзката  бордово  
устройство  — датчик  за движение  
9.2.2 Ключове  за обезпечаване  на сигурността  на специализирана  
връзка  с малък  обсег  на действие  (DSRC Communication)  
9.3. Сертификати  
9.3.1 Общи  положения  
9.3.2 Съдържание  на сертификатите  
9.3.3 Заявяване  на сертификати  
10. ВЗАИМНО  УДОСТОВЕРЯВАНЕ  НА АВТЕНТИЧНОСТТА  И 
ЗАЩИТЕН  ОБМЕН  НА СЪОБЩЕНИЯ  БОРДОВО  
УСТРОЙСТВО  — КАРТА  
10.1. Общи  положения  
10.2. Взаимна  проверка  на веригата  на сертифициране  
10.2.1 Проверка  от бордовото  устройство  на веригата  на сертифи­  
циране  на картата  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 361  
10.2.2 Проверка  от карта  на веригата  на сертифициране  на бордово  
устройство  
10.3. Удостоверяване  на автентичността  на бордово  устройство  
10.4. Удостоверяване  на автентичността  на чипа  и договаряне  на 
ключ  за сесията  
10.5. Защитен  обмен  на съобщения  
10.5.1 Общи  положения  
10.5.2 Структура  на защитено  съобщение  
10.5.3 Прекратяване  на сесия  на защитен  обмен  на съобщения  
11. КУПЛИРАНЕ  БОРДОВО  УСТРОЙСТВО  — ВЪНШНО  
УСТРОЙСТВО  ЗА GNSS, ВЗАИМНО  УДОСТОВЕРЯВАНЕ  
НА АВТЕНТИЧНОСТТА  И ЗАЩИТЕН  ОБМЕН  НА 
СЪОБЩЕНИЯ  
11.1. Общи  положения  
11.2. Куплиране  на бордово  устройство  с външно  устройство  за 
GNSS  
11.3. Взаимна  проверка  на веригата  на сертифициране  
11.3.1 Общи  положения  
11.3.2 По време  на куплирането  бордово  устройство  — EGF  
11.3.3 При нормална  работа  
11.4. Автентифициране  на бордовото  устройство , автентифициране  
на чипа  и договаряне  на сесийни  ключове  
11.5. Защитен  обмен  на съобщения  
12. СДВОЯВАНЕ  И КОМУНИКАЦИЯ  БОРДОВО  УСТРОЙСТВО  
— ДАТЧИК  ЗА ДВИЖЕНИЕ  
12.1. Общи  положения  
12.2. Сдвояване  бордово  устройство  — датчик  за движение  с 
използване  на ключове  от различни  поколения  
12.3. Сдвояване  и връзка  бордово  устройство  — датчик  за движение  
с използване  на AES  
12.4. Сдвояване  бордово  устройство  — датчик  за движение  при 
различни  поколения  на оборудването  
13. СИГУРНОСТ  ПРИ  ВРЪЗКА  ОТ РАЗСТОЯНИЕ  ПО DSRC  
13.1. Общи  положения  
13.2. Криптиране  на полезните  тахографски  данни  и генериране  на 
MAC  
13.3. Проверка  и декриптиране  на полезни  тахографски  данни  
14. ПОДПИСВАНЕ  НА ИЗТЕГЛЕНИ  ДАННИ  И ПРОВЕРКА  НА 
ПОДПИСИТЕ  
14.1. Общи  положения  
14.2. Генериране  на подпис  
14.3. Проверка  на подписа  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 362  
ПРЕАМБЮЛ  
В настоящото  допълнение  са специфицирани  механизмите  за сигурност , 
които  обезпечават : 
— взаимно  удостоверяване  на автентичност  между  различни  компоненти  
на тахографската  система . 
— поверителност , цялостност , автентичност  и безотказно  приемане  на 
данните , предавани  между  различните  компоненти  на тахографската  
система  или изтегляни  от външни  носители  на информация . 
Настоящото  допълнение  се състои  от две части . В Част  А са дефинирани  
механизмите  за сигурност  за тахографска  система  от първо  поколение  
(цифров  тахограф ). В Част  Б са дефинирани  механизмите  за сигурност  за 
тахографска  система  от второ  поколение  (интелигентен  тахограф ). 
Механизмите , специфицирани  в Част  А от настоящото  допълнение , се 
прилагат  ако поне  един  от компонентите  на тахографската  система , 
участващи  в процес  на взаимно  удостоверяване  на автентичност  и/или 
прехвърляне  на данни , е от първо  поколение . 
Механизмите , специфицирани  в Част  Б от настоящото  допълнение , се 
прилагат  ако и двата  компонента  на тахографската  система , участващи  в 
процес  на взаимно  удостоверяване  на автентичност  и/или прехвърляне  на 
данни , са от второ  поколение . 
Допълнителна  информация  относно  използването  на компоненти  от първо  
поколение  в комбинация  с компоненти  от второ  поколение  е дадена  в 
Допълнение  15. 
ЧАСТ  А 
ТАХОГРАФСКА  СИСТЕМА  ОТ ПЪРВО  ПОКОЛЕНИЕ  
1. ВЪВЕДЕНИЕ  
1.1. Позовавания  
В настоящото  допълнение  са използвани  позовавания  на следните  
референтни  документи : 
SHA-1 National Institute of Standards and Technology 
(NIST).  FIPS Publication 180-1: Secure Hash 
Standard . April 1995  
PKCS1 RSA Laboratories. PKCS # 1: RSA Encryption 
Standard. Version 2.0. October 1998.  
TDES National Institute of Standards and Technology 
(NIST).  FIPS Publication 46-3: Data Encryption 
Standard . Draft 1999.  
TDES-OP ANSI X9.52, Triple Data Encryption Algorithm 
Modes of Operation. 1998.  
ISO/IEC 7816-4 Информационни  технологии . Идентификационни  
карти . Карти  с интегрална (и) схема (и) с контакти . 
Част  4: Вътрешно -отраслови  команди  за взаимен  
обмен . Първо  издание : 1995 г. + Изменение  1: 
1997 г.. 
ISO/IEC 7816-6 Информационни  технологии . Идентификационни  
карти . Карти  с интегрална (и) схема (и) с контакти . 
Част  6: Отраслови  елементи  от данни  за взаимен  
обмен . Първо  издание : 1996 г. + Поправка  1: 
1998 г. 
ISO/IEC 7816-8 Информационни  технологии . Идентификационни  
карти . Карти  с интегрална (и) схема (и) с контакти . 
Част  8: Отраслови  команди  за операции  по сигур­  
ността . Първо  издание :1999 г. 
ISO/IEC 9796-2 Информационни  технологии . Техники  за 
сигурност . Схеми  за електронен  подпис , позво­  
ляващи  възстановяване  на съобщението . Част  2: 
Механизми , използващи  хеш-функция . Първо  
издание : 1997 г. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 363  
ISO/IEC 9798-3 Информационни  технологии . Техники  за 
сигурност . Автентификация  на обекта . Част  3: 
Механизми , използващи  електронен  подпис . 
Второ  издание , 1998 г. 
ISO 16844-3 Пътни  превозни  средства . Тахографски  системи . 
Част  3: Интерфейс  на датчика  на движение . 
1.2. Означения  и съкращения  на термини  
В настоящото  допълнение  са използвани  следните  означения  и 
съкращения  на термини : 
(K a , K  b , K  c ) a key bundle for use by the Triple Data Encryption 
Algorithm ( група  от ключове , използвани  в 
тройния  алгоритъм  за криптиране  на данни ), 
CA Certification Authority ( удостоверяващ  орган ), 
CAR Certification Authority Reference ( референтно  
означение  на удостоверяващия  орган ), 
CC Cryptographic Checksum ( криптографска  контролна  
сума ), 
CG Cryptogram ( криптограма ), 
CH Command Header ( заглавна  част на команда ), 
CHA Certificate Holder Authorisation ( оторизация  на 
титуляря  на сертификата ), 
CHR Certificate Holder Reference ( референтно  означение  
на титуляря  на сертификата ). 
D() Decryption with DES ( декриптиране  с DES (Data 
Encryption Standard)),  
DE Data Element ( елемент  от данни ), 
DO Data Object ( обект  от данни ), 
d RSA private key, private exponent ( частен  ключ  на 
RSA система , частен  степенен  показател ), 
е RSA public key, public exponent ( публичен  ключ  
RSA система , публичен  степенен  показател ), 
E() Encryption with DES ( криптиране  с DES),  
EQT Equipment ( оборудване ), 
Hash()  Hash value, an output of  Hash  (хеш-стойност  
(стойност  на сегментиране ), изходен  низ от хеши­  
ране ), 
Hash Hash  (хеш-функция ), 
KID Key Identifier ( идентификатор  на ключ ), 
Km TDES key. Master Key defined in ISO 16844-3 
(ключ  TDES, главен  ключ , определен  в стандарт  
ISO 16844 -3),  
Km  VU TDES key inserted in vehicle units ( ключ  TDES, 
въведен  в бордови  устройства ), 
Km  WC TDES key inserted in workshop cards ( ключ  TDES, 
въведен  в карти  за монтаж  и настройки ), 
m message representative, an integer between 0 and  n-1 
(указател  за представяне  на съобщение , цяло  число  
между  0 и n–1),  
n RSA keys, modulus ( ключове  RSA, модул  (в 
модулно  степенуване )), 
PB Padding Bytes ( запълващи  байтове ), 
PI Padding Indicator byte ( байт  на индикатора  за 
запълване  (използван  в криптограма  за пове­  
рителни  обекти  от данни )) 
PV Plain Value ( открита  стойност ), 
s Signature representative, an integer between 0 and  n-1 
(указател  за представяне  на подпис , цяло  число  
между  0 и n–1),  
SSC Send Sequence Counter ( брояч  на изпратени  поре­  
дици ), 
SM Secure Messaging ( защитен  обмен  на съобщения ), 
TCBC TDEA Cipher Block Chaining Mode of Operation 
(режим  на работа  чрез свързване  на блокове  от 
шифровани  данни  TDEA),  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 364  
TDEA Triple Data Encryption Algorithm ( троен  алгоритъм  
за криптиране  на данни ), 
TLV Tag Length Value ( стойност  на дължината  на таг), 
VU Vehicle Unit ( бордово  устройство ), 
X.C The certificate of user X issued by a certification 
authority ( сертификатът  на ползвателя  Х, издаден  
от сертифициращ  орган ), 
X.CA A certification authority of user X ( сертифициращ  
орган  на ползвателя  Х), 
X.CA.PK  o X.C The operation of unwrapping a certificate to extract a 
public key. It is an infix operator, whose left operand 
is the public key of a certification authority, and 
whose right operand is the certificate issued by that 
certification authority. The outcome is the public key 
of the user X whose certificate is the right operand 
(Операция  по разкриване  съдържанието  на 
сертификат  с цел извличане  на публичен  ключ  от 
него . Това  е оператор , който  е поставен  между  
операнди , като операндът  отляво  е публичният  
ключ  на даден  сертифициращ  орган , а операндът  
отдясно  е сертификатът , издаден  от този серти­  
фициращ  орган . Като  резултат  се получава  
публичният  ключ  на ползвателя  Х, чийто  
сертификат  е операндът  отдясно ), 
X.PK RSA public key of a user X ( публичен  ключ  RSA на 
ползвателя  Х), 
X.PK[I] RSA encipherment of some information I, using the 
public key of user X ( криптиране  RSA на някои  
информации  I с помощта  на публичния  ключ  на 
ползвателя  Х), 
X.SK RSA private key of a user X ( частен  ключ  RSA на 
ползвателя  Х), 
X.SK[I] RSA encipherment of some information I, using the 
private key of user X ( криптиране  RSA на някои  
информации  I с помощта  на частния  ключ  на 
ползвателя  Х) 
‘xx’ An Hexadecimal value ( стойност  в шестнадесе­  
тичната  бройна  система ), 
|| Concatenation operator ( оператор  за конкатенация ). 
2. КРИПТОГРАФСКИ  СИСТЕМИ  И АЛГОРИТМИ  
2.1. Криптографски  системи  
CSM_001 Бордовите  устройства  и тахографските  карти  трябва  да 
използват  класическа  криптографска  система  с 
публичен  ключ  RSA за предоставяне  на следните  
механизми  за сигурност : 
— взаимно  удостоверяване  на автентичност  между  
бордовите  устройства  и тахографските  карти , 
— маршрутизация  на тройните  ключове  за сесия  DES 
(Data Encryption Standard) между  бордовите  
устройства  и тахографските  карти , 
— електронен  подпис  за данните , изтегляни  от 
бордовите  устройства  или от тахографските  карти  
върху  външни  носители  на информация . 
CSM_002 Бордовите  устройства  и тахографските  карти  трябва  да 
използват  криптографска  система  с троен  DES шифър  
със симетричен  ключ  за осигуряване  на механизъм , 
който  да гарантира  целостта  на данните  при обмена  на 
данни  на ползвателя  между  бордовите  устройства  и 
тахографските  карти , както  и за осигуряване , в съот­  
ветните  случаи , на поверителност  на обмена  на данни  
между  бордовите  устройства  и тахографските  карти . 
2.2. Криптографски  алгоритми  
2.2.1  Алгоритъм  RSA  
CSM_003 Алгоритъмът  RSA се дефинира  изцяло  чрез следните  
отношения : ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 365  
X.SK[ m] = s = m d mod n 
X.PK[ s] = m = s e mod n 
По-подробно  писание  на функцията  RSA е дадено  в 
референтния  документ  [PKCS1]. За целите  на изчис­  
ленията  за RSA, публичният  степенен  показател  е пред­  
ставлява  цяло  число  със стойност  между  3 и n-1, 
отговарящо  на условието  gcd(e, lcm(p-1, q-1))=1.  
2.2.2  Алгоритъм  за хеширане  
CSM_004 Механизмите  за електронния  подпис  трябва  да използват  
алгоритъма  за хеширане  SHA-1, така както  е определен  в 
референтния  документ  SHA-1.  
2.2.3  Алгоритъм  за криптиране  на данни  
CSM_005 Алгоритмите  на база DES трябва  да се използват  при 
работен  режим  на свързване  на блокове  от шифровани  
данни . 
3. КЛЮЧОВЕ  И СЕРТИФИКАТИ  
3.1. Генериране  и разпределение  на ключове  
3.1.1  Генериране  и разпределение  на ключове  RSA  
CSM_006 Ключовете  RSA се генерират  на три йерархични  
функционални  равнища : 
— европейско  равнище , 
— равнище  на държавата  членка , 
— равнище  на вид оборудване . 
CSM_007 На европейското  равнище  се генерира  само  една  двойка  
европейски  ключове  (EUR.SK и EUR.PK). Европейският  
частен  ключ  се използва  за сертифицирането  на 
публичните  ключове  на равнището  на държавите  
членки . Трябва  се съхраняват  записи  за всички  сертифи­  
цирани  ключове . Тези  задачи  се изпълняват  от Евро­  
пейски  сертифициращ  орган  под контрола  и отговор­  
ността  на Европейската  комисия . 
CSM_008 На равнището  на държава  членка  се генерира  една  
двойка  ключове  за държавата  членка  (MS.SK и MS.PK). 
Публичните  ключове  на държавите  членки  трябва  да 
бъдат  сертифицирани  от Европейския  сертифициращ  
орган . Частният  ключ  на държавата  членка  се използва  
за сертифицирането  на публичните  ключове , които  се 
въвеждат  в оборудването  (бордовото  устройство  или 
тахографската  карта ). Записите  на всички  сертифицирани  
публични  ключове  трябва  да се съхраняват  заедно  с 
данните  за идентифициране  на оборудването , за което  
те са предназначени . Тези  задачи  се изпълняват  от 
национален  сертифициращ  орган  на държавата  членка . 
Всяка  държава  членка  има право  да сменя  периодично  
своята  двойка  ключове . 
CSM_009 На равнището  на оборудването  се генерира  и въвежда  
само  една  двойка  ключове  във всяко  оборудване  
(EQT.SK и EQT.PK). Публичните  ключове  на оборуд­  
ването  трябва  да бъдат  сертифицирани  от националния  
сертифициращ  орган . Тези  задачи  могат  да се изпълняват  
от производителите  на оборудването , от изпълнителите  
на персонализацията  на оборудването  (equipment persona ­
lisers), или от органи  на държавата  членка . Тази  двойка  
ключове  се използва  за операции  във връзка  с удостове­  
ряването  на автентичността , електронния  подпис  и крип­  
тирането . 
CSM_010 Поверителността  на частните  ключове  трябва  да се 
запази  при тяхното  генериране , (евентуално ) маршрути­  
зиране  и съхранение . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 366  
Движението  на данните  при този процес  е обобщено  на 
следната  фигура :
 
3.1.2  Ключове  за контрол  с RSA  
CSM_011 CSM_011 За целите  на изпитванията  на оборудване  
(включително  изпитвания  за оперативна  съвместимост ), 
Европейският  сертифициращ  орган  генерира  една  
различна  европейска  двойка  контролни  ключове  и най- 
малко  две двойки  национални  контролни  ключове , чиито  
публични  ключове  се сертифицират  с европейския  частен  
контролен  ключ . Производителите  трябва  да въвеждат  в 
оборудването , което  е в процес  на сертифициране  на 
типа , контролни  ключове , сертифицирани  чрез един  от 
националните  контролни  ключове . 
3.1.3  Ключове  за датчика  за движение  
Поверителността  на ключовете  с троен  DES шифър , описани  по- 
долу , трябва  да бъде  запазена  по подходящ  начин  при тяхното  гене­  
риране , (евентуално ) маршрутизиране  и съхранение . 
За да се даде  възможност  за поддържане  на тахографски  компо­  
ненти , отговарящи  на стандарта  ISO 16844, Европейският  серти­  
фициращ  орган  и националните  сертифициращи  органи  на 
държавите  членки  трябва  също  да осигуряват  следното : 
CSM_036 Европейският  сертифициращ  орган  генерира  ключовете  
KmVU и KmWC, два независими  и уникални  ключа  с 
троен  DES шифър , както  и Km по формулата : 
Km = Km  VU XOR Km  WC . При поискване  Европейският  
сертифициращ  орган  изпраща  тези ключове , при спазване  
на подходящи  защитни  процедури , на сертифициращите  
органи  на държавите  членки . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 367  
CSM_037 Сертифициращите  органи  на държавите  членки  трябва : 
— да използват  ключа  Km за криптиране  на данните  на 
датчици  за движение , поискано  от производителите  
на датчици  за движение  (данните  за криптиране  с 
ключа  Km са определени  в стандарт  ISO 16844-3),  
— да изпращат  ключа  Km  VU на производителите  на 
бордови  устройства , при спазване  на подходящи  
защитни  процедури , за да бъде  този ключ  въведен  в 
бордови  устройства , 
— да осигуряват  въвеждането  на Km  WC във 
всички  карти  за монтаж  и настройки  
(
 в елементарния  
файл
  ) по време  на 
персонализацията  на картата . 
3.1.4  Генериране  и разпределение  на сесийни  T-DES ключове  
CSM_012 При процеса  на взаимно  удостоверяване  на автентич­  
ността , бордовите  устройства  и тахографските  карти  
трябва  да генерират  и обменят  необходимите  данни  за 
изработването  на общ сесиен  T-DES ключ . Поверител­  
ността  на този обмен  на данни  трябва  да бъде  защитена  
с механизъм  за криптиране  RSA.  
CSM_013 При всички  последващи  криптографски  операции  този 
ключ  трябва  да се използва  със защитен  обмен  на съоб­  
щения . Неговата  валидност  изтича  в края  на сесията  
(изваждане  или инициализиране  на картата ) и/или след  
240 употреби  (една  употреба  на ключа  = изпращане  на 
команда  към картата  при защитен  обмен  на съобщения  и 
съответният  отговор ). 
3.2. Ключове  
CSM_014 Ключовете  RSA трябва  да имат  (независимо  от 
равнището ) следните  дължини : модул  n 1 024 бита , 
публичен  степенен  показател  e максимум  64 бита , 
частен  степенен  показател  d 1 024 бита . 
CSM_015 Ключовете  с троен  DES шифър  трябва  да имат  формата  
(K a , K  b , K  a ), където  K a и K b са независими  ключове  с 
дължина  64 бита . Нe се въвеждат  никакви  битове  за 
откриване  на грешка  по четност . 
3.3. Сертификати  
CSM_016 Сертификатите  с публични  ключове  RSA трябва  да бъдат  
от типа  „non self-descriptive“ („ несамоописващи  се“) и 
„card verifiable“(„ проверими  с карта “) (Справка : 
стандарт  ISO/CEI 7816-8) ISO/IEC 7816-8  
3.3.1  Съдържание  на сертификатите  
CSM_017 Сертификатите  с публични  ключове  RSA трябва  да 
съдържат  посочените  по-долу  данни  в следния  ред: 
Данни  Формат  Байтове  Забележки  
CPI INTEGER  1  Идентификатор  на 
профила  на сертификата  
(‘01’ за тази версия ) 
CAR  OCTET 
STRING  8 Референтно  означение  на 
сертифициращия  орган  
CHA  OCTET 
STRING  7 Оторизация  на титуляря  
на сертификата  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 368  
Данни  Формат  Байтове  Забележки  
EOV  TimeReal  4  Изтичане  на валидността  
на сертификата . Незадъл­  
жително , може  да се 
допълни  с „FF“, ако не 
е използвано . 
CHR  OCTET 
STRING  8 Референтно  означение  на 
титуляря  на сертификата  
n OCTET 
STRING  128 Публичен  ключ  (модул ) 
е OCTET 
STRING  8 Публичен  ключ  
(публичен  степенен  пока­  
зател ) 
164 
Забележки : 
1. „Идентификаторът  на профила  на сертификата “ (Certificate Profile 
Identifier — CPI) определя  точната  структура  на даден  сертификат  
за удостоверяване  на автентичност . Той изпълнява  функция  на 
вътрешен  идентификатор  на оборудване  в съответен  списък  на 
заглавни  части  (Headerlist), който  описва  конкатенацията  на 
елементите  от данни , съдържащи  се в сертификата . 
Списъкът  на заглавни  части , свързан  със съдържанието  на този 
сертификат , има следния  вид: 
‘4D’  ‘16’  ‘5F 
29’ ‘01’ ‘42’  ‘08’  ‘5F 
4B’ ‘07’ ‘5F 
24’ ‘04’ ‘5F 
20’ ‘08’ ‘7F 
49’ ‘05’ ‘81’  ‘81 
80’ ‘82’ ‘08’
 Таг за разширен  Headerlist  
Дължина  на Headerlist  
Таг за идентификатор  на профила  на сертификата  (CPI)  
Дължина  на CPI  
Таг за CAR  
Дължина  на CAR  
Таг за оторизация  на титуляря  на сертификата  
Дължина  на CHA  
Таг за EOV  
Дължина  на EOV  
Таг за CHR  
Дължина  на CHR  
Таг за публичен  ключ  (конструиран ) 
Дължина  на последващите  обекти  от данни  
Таг на модула  
Дължина  на модула  
Таг на публичния  степенен  покзател  
Дължина  на публ . степенен  показател 
2. „Референтното  означение  на сертифициращия  орган “ (CAR) е 
предназначено  да идентифицира  издалия  сертификата  орган  по 
такъв  начин , че елементът  от данни  да може  да изпълнява  едно­  
временно  функцията  на идентификатор  на органа  за ключа , 
посочващ  кой е сертифициращият  орган , генерирал  публичния  
ключ  (за кодирането  вж. по-долу  „Идентификатор  на ключ “). 
3. „Оторизация  на титуляря  на сертификата “ (CHA) се издава  за 
посочване  на правата  на титуляря  на сертификата . Тя се състои  
от идентификатор  на заявката  за тахограф  и от типа  на оборуд­  
ването , за което  се отнася  сертификатът  (в зависимост  от 
елемента  от данни
  , за държава  членка  този 
идентификатор  е ‘00’).  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 369  
4. „Референтното  означение  на титуляря  на сертификата “ (CHR) е 
предназначено  да служи  за уникално  идентифициране  на 
титуляря  на сертификата  по такъв  начин , че елементът  от данни  
да може  да бъде  използван  в същото  време  и като идентификатор  
на предметен  ключ , за означаване  на публичния  ключ  на 
титуляря  на сертификата . 
5. Идентификаторите  на ключове  служат  за уникално  идентифи­  
циране  на титуляря  на сертификата  или на сертифициращите  
органи . Те се кодират , както  следва : 
5.1. Оборудване  (бордово  устройство  или карта ): 
Данни  Сериен  
номер  на 
оборуд­  
ването  Дата  Тип Производител  
Дължина  4 байта  2 байта  1 байт  1 байт  
Стойност  Цяло  
число  Кодиране  BCD мм 
гг Специфични  
данни  за 
производителя  Код на 
производителя  
В случаите , при които  става  въпрос  за бордово  устройство , 
при исканията  за сертификати  е възможно  производителят  да 
знае или да не знае идентификационните  данни  на оборуд­  
ването , в което  ще бъдат  въведени  ключовете . 
В първия  случай  производителят  изпраща  до сертифи­  
циращия  орган  в своята  държава  членка  идентификаци­  
онните  данни  на оборудването  и публичния  ключ . Серти­  
фикатът  в такъв  случай  съдържа  идентификационните  
данни  на оборудването  и производителят  трябва  да осигури  
въвеждането  на ключовете  и сертификата  в съответното  
оборудване . Идентификаторът  на ключа  има указаната  по- 
горе форма . 
Във втория  случай  производителят  трябва  да идентифицира  
уникално  всяко  искане  за сертификат  и да изпрати  до серти­  
фициращия  орган  в своята  държава  членка  тази иденти­  
фикация  и публичния  ключ . В такъв  случай  сертификатът  
съдържа  идентификацията  на искането  за сертификат . След  
инсталирането  на ключ  в оборудването  производителят  
трябва  да подаде  до сертифициращия  орган  в своята  
държава  членка  обратна  информация  за определянето  на 
ключ  за оборудването  (т.е. за идентификацията  на искането  
за сертификат  и за идентификацията  на оборудването ). Иден­  
тификаторът  на ключа  има указаната  по-долу  форма : 
Данни  Сериен  
номер  на 
искането  
за серти­  
фикат  Дата  Тип Производител  
Дължина  4 байта  2 байта  1 байт  1 байт  
Стойност  Integer  Кодиране  BCD мм 
гг ‘FF’ Код на 
производителя  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 370  
5.2 Сертифициращ  орган : 
Данни  Иденти­  
фикация  
на органа  Сериен  номер  на 
ключа  Допълнителна  
информация  Идентифи­  
катор  
Дължина  4 байта  1 байт  2 байта  1 байт  
Стойност  1 байт  
цифров  
код за 
национал­  
ността  
3 байта  
буквено - 
цифров  
код за 
национал­  
ността  Integer  допълнително  
кодиране  
(специфично  
за сертифи­  
циращия  
орган ) 
‘FF FF’ ако не 
е използвано  ‘01’ 
Серийният  номер  на ключа  се използва  за разграничаване  на 
различните  ключове  на дадена  държава  членка  в случай , че 
ключът  бъде  променен . 
6. Проверителите  на сертификати  трябва  имплицитно  да знаят , че 
сертифицираният  публичен  ключ  е от тип RSA, който  се използва  
за удостоверяване  на автентичността , проверка  и криптиране  на 
електронен  подпис  при поверителни  операции  (сертификатът  не 
съдържа  никакъв  идентификатор  на обекта , който  да го специфи­  
цира ). 
3.3.2  Издадени  сертификати  
CSM_018 Издаденият  сертификат  е електронен  подпис  с частично  
възстановяване  на съдържанието  на сертификата  в съот­  
ветствие  със стандарт  ISO/IEC 9796-2 ( с изключение  на 
неговото  приложение  А.4), допълнен  с „Референтното  
означение  на сертифициращия  орган “ (Certification 
Authority Reference).  
X.C = X.CA.SK[‘6A’ || C  r || Hash (Cc) || ‘BC’] || C  n || X.CAR 
Със съдържание  на сертификата  = Cc =  C  r || C  n 
106 байта  58 байта  
Забележки : 
1. Дължината  на този вид сертификат  е 194 байта . 
2. Референтното  означение  на сертифициращия  орган  (CAR), което  
е скрито  от подписа , в същото  време  е прикрепено  като 
допълнение  към подписа , за да може  публичният  ключ  на серти­  
фициращия  орган  да бъде  избран  за извършване  на проверката  на 
сертификата . 
3. Проверителят  на сертификата  трябва  имплицитно  да знае алго­  
ритъма , използван  от сертифициращия  орган  за подписване  на 
сертификата . 
4. Списъкът  на заглавни  части , свързан  с този вид издаден  серти­  
фикат , има следния  вид: 
‘7F 21’  ‘09’  ‘5F 37’  ‘81 80’  ‘5F 38’  ‘3A’  ‘42’  ‘08’
 Таг за проверим  с 
карта  сертификат  
(конструиран ) 
Дължина  на 
последващите  обекти  
от данни  
Таг за подписа  
Дължина  на подписа  
Таг за остатъка  
Дължина  на остатъка  
Таг за CAR  
Дължина  на CAR ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 371  
3.3.3  Проверка  и разкриване  на съдържанието  на сертификатите  
Проверката  и разкриването  на съдържанието  на сертификатите  се 
състои  от проверка  на подписа  съгласно  стандарт  ISO/IEC 9796-2 
и извличане  на съдържанието  на сертификата  и на съдържащия  се в 
сертификата  публичен  ключ : X.PK = X.CA.PKoX.C, както  и от 
проверка  на валидността  на сертификата . 
CSM_019 Това  включва  следните  стъпки : 
Проверка  на подписа  и извличане  на съдържанието : 
— От X.C, се извличат  Sign., C  n ' и CAR':  X.C =  Sign  ||  C  n ' ||  CAR'  
128 байта  58 байта  8 байта  
— От CAR' се избира  публичният  ключ  на съответния  
сертифициращ  орган  (ако това не е било  вече 
направено  с други  средства ) 
— Отваря  се Sign с публичния  ключ  на сертифициращия  
орган : Sr'= X.CA.PK [Sign],  
— проверява  се дали  Sr' започва  с ‘6A’ и завършва  с 
‘BC’ 
— изчисляват  се C r ' и H' както  следва : Sr' =  ‘6 A’  || C  r ' ||  H'  ||  ‘BC’  
106 байта  20 байта  
— Възстановява  се съдържанието  на сертификата  C' = 
C r ' || C  n ', 
— проверява  се Hash (C‘) = H’  
Ако резултатите  от проверките  са положителни , серти­  
фикатът  е истински  и съдържанието  му е C'. 
Проверява  се валидността . От C': 
— проверява  се датата  на изтичане  на валидността  (ако 
има такава ), 
От C' се извлича  и се запаметява  публичният  ключ , иден­  
тификаторът  на ключа , оторизацията  на титуляря  на 
сертификата  и датата  на изтичане  на валидността : 
— X.PK =  n || е 
— X.KID = CHR,  
— X.CHA = CHA,  
— X.EOV = EOV  
4. МЕХАНИЗЪМ  ЗА ВЗАИМНО  УДОСТОВЕРЯВАНЕ  НА АВТЕН­  
ТИЧНОСТТА  
Взаимното  удостоверяване  на автентичността  между  картите  и 
бордовите  устройства  се основава  на следния  принцип : 
Всяка  от страните  трябва  да демонстрира  на другата , че притежава  
двойка  валидни  ключове , като публичният  ключ , който  е позволил  
тяхното  сертифициране  от национален  сертифициращ  орган , на свой  
ред е сертифициран  от европейския  сертифициращ  орган . 
Това  демонстриране  се състои  в подписване  с частния  ключ  на 
случайно  число , изпратено  от другата  страна , която  трябва  да 
възстанови  изпратеното  случайно  число  при проверката  на този 
подпис . 
Механизмът  се задейства  от бордовото  устройство  при вкарване  на 
карта  в него . Той започва  с размяна  на сертификатите  и разкри­  
ването  на съдържанието  на публичните  ключове  и завършва  с 
определянето  на ключ  на сесията . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 372  
CSM_020 Използва  се следният  протокол  (стрелките  указват  обме­  
нените  команди  и данни  (вж. допълнение  2)):
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 373
  
▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 374  
5. МЕХАНИЗМИ  ЗА ПОВЕРИТЕЛНОСТ , ЦЯЛОСТНОСТ  И УДОС­  
ТОВЕРЯВАНЕ  НА АВТЕНТИЧНОСТТА  ПРИ  ОБМЕН  НА 
ДАННИ  МЕЖДУ  БОРДОВО  УСТРОЙСТВО  И КАРТА  
5.1. Защитен  обмен  на съобщения  
CSM_021 Цялостността  при обмен  на данни  между  бордово  
устройство  и карти  трябва  да бъде  опазвана  чрез 
използване  на защитен  обмен  на съобщения  в съот­  
ветствие  с референтните  документи  [ISO/IEC 7816-4] и 
[ISO/IEC 7816-8].  
CSM_022 Ако се налага  защита  на данните  при тяхното  
прехвърляне , необходимо  е към обектите  от данни , 
изпращани  в рамките  на командата  или отговора , да се 
добави  обект  от данни , представляващ  криптографска  
контролна  сума . Криптографската  контролна  сума  се 
проверява  от получателя  на данните . 
CSM_023 Криптографската  контролна  сума  за данните , изпратени  в 
рамките  на дадена  команда , трябва  да включва  заглавната  
част на командата , както  и всички  изпратени  обекти  от 
данни  (=>CLA = ‘0C’, и всички  обекти  от данни  трябва  
да бъдат  оградени  с тагове , в които  b1=1).  
CSM_024 Ако отговорът  не съдържа  поле  за данни , байтовете  за 
състояние /информация  в него  трябва  да бъдат  защитени  с 
криптографска  контролна  сума . 
CSM_025 Криптографските  контролни  суми  трябва  да са с дължина  
4 байта . 
Така  че при използване  на защитен  обмен  на съобщения , 
командите  и отговорите  трябва  да имат  следната  
структура : 
Използваните  обекти  от данни  представляват  частичен  
набор  от обектите  от данни  за защитен  обмен  на съоб­  
щения , описани  в ISO/IEC 7816-4:  
Таг Мнемонич­  
ен код Значение  
‘81’ T  PV Открита  стойност  (Plain Value), некодирана  по 
BER-TVL ( която  трябва  да бъде  защитена  с крип­  
тографска  контролна  сума ) 
‘97’ T  LE Стойност  на Le в незащитена  от неоторизиран  
достъп  команда  (която  трябва  да бъде  защитена  
с криптографска  контролна  сума ) 
‘99’ T  SW Информация  за състоянието  (която  трябва  да бъде  
защитена  с криптографска  контролна  сума ) 
‘8E’ T  CC Криптографска  контролна  сума  
‘87’ T  PI CG  Байт  на индикатора  за запълването  || Криптограма  
(открита  стойност , некодирана  в BER-TVL)  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 375  
При дадена  незащитена  двойка  от команда  и отвор : 
Заглавна  част на командата  Тяло  на командата  
CLA  INS  P1  P2  [L  c на поле ] [Поле  за данни ] [L  e на поле ] 
четири  байта  Байтове  L, означени  като B 1 до B L 
Тяло  на отговора  Завършваща  част на отговора  
[Поле  за данни ] SW1  SW2  
Байтове  данни  L r Два байта  
Съответната  защитена  двойка  от команда  и отговор  е: 
Защитена  от неоторизиран  достъп  команда : 
Заглавна  част на 
командата  (CH)  Тяло  на командата  
CLA  INS  P1  P2  [L  c на новото  
поле ] [Ново  поле  за данни ] [L  e на 
новото  
поле ] 
‘OC’  Дължина  на 
новото  поле  за 
данни  T PV L PV PV T  LE L LE L e T CC L CC CC ‘00’  
‘81’ L  c Поле  за 
данни  ‘97’ ‘01’  L  e ‘8E’ ‘04’  CC  
Данни , които  се включват  в контролната  сума  = CH || PB 
|| T  PV || L  PV || PV || T  LE || L  LE || L  e || PB  
PB = допълващи  байтове  (80 .. 00) съгласно  ISO-IEC 
7816-4 и ISO 9797, метод  2. 
PV и LE на обекта  от данни  (DO) присъстват  единствено  
ако незащитената  команда  съдържа  съответстващи  данни . 
Защитен  отговор : 
1. Случай , когато  полето  за данни  в отговора  не е празно  
и не се нуждае  от защита  с цел поверителност : 
Тяло  на отговора  Завършваща  част на 
отговора  
[Ново  поле  за данни ] Нови  SW1 SW2  
T PV L PV PV T  CC L CC CC 
‘81’ L  r Поле  за данни  ‘8E’  ‘04’  CC  
Данни , които  се включват  в контролната  сума  = T  PV || 
L PV || PV || PB  
2. Случай , когато  полето  за данни  на отговора  не е 
празно  и се нуждае  от защита  с цел поверителност : ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 376  
Тяло  на отговора  Завършваща  част на 
отговора  
[Ново  поле  за данни ] Нови  SW1 SW2  
T PI CG  L PI 
CG PI CG  T  CC L CC CC 
‘87’ PI || CG  ‘8E’  ‘04’  CC  
Данни , които  се маршрутизират  чрез CG: некодирани  
с BER-TLV данни  и допълващи  байтове . 
Данни , които  се включват  в контролната  сума  = T  PI CG  
|| L  PI CG  || PI CG || PB  
3. Случай , когато  полето  за данни  на отговора  е празно : 
Тяло  на отговора  Завършваща  част на 
отговора  
[Ново  поле  за данни ] Нови  SW1 SW2  
T SW L SW SW T  CC L CC CC 
‘99’ ‘02’  Нови  SW1 SW2  ‘8E’  ‘04’  CC  
Данни , които  се включват  в контролната  сума  = T  SW || 
L SW || SW || PB  
5.2. Третиране  на грешки  при защитен  обмен  на съобщения  
CSM_026 Когато  тахографската  карта  при интерпретирането  на 
дадена  команда  разпознае  грешка  при защитен  обмен  
на съобщения , необходимо  е байтовете  за състоянието  
да бъдат  върнати  без защитен  обмен . В съответствие  с 
ISO/IEC 7816-4, за посочване  на грешки  при защитен  
обмен  на съобщения  са определени  следните  байтове  за 
състояние : 
‘66 88’: Неуспешна  проверка  на криптографската  
контролна  сума , 
‘69 87’: Липса  на очаквани  обекти  от данни  за защитен  
обмен , 
‘69 88’: Неверни  обекти  от данни  за защитен  обмен . 
CSM_027 Когато  тахографската  карта  върне  байтове  за състояние  
без посочени  обекти  от данни  за защитен  обмен  (SM 
DOs) или с погрешен  обект  от данни  за защитен  обмен  
(SM DO), бордовото  устройство  трябва  да прекрати  
сесията . 
5.3. Алгоритъм  за изчисляване  на криптографските  контролни  суми  
CSM_028 Криптографските  контролни  суми  се съставят  с 
използване  на подробни  кодове  за автентификация  на 
съобщенията  (retail MACs), в съответствие  със стандарт  
ANSI X9.19, с използване  на DES:  
— Начален  стадий : Първоначалният  контролен  блок  y0 е 
E(Ka, SSC).  
— Последващ  стадий : Контролните  блокове  y1, .., yn се 
изчисляват  с използване  на Ka. 
— Краен  стадий : Криптографската  контролна  сума  се 
изчислява  въз основа  на последния  контролен  блок  
yn, както  следва : E(Ka, D(Kb, yn)).  
където  съкращението  E() означава  криптиране  с DES, а 
съкращението  D() означава  декриптиране  с DES.  
Прехвърлят  се четирите  най-старши  байта  от криптог­  
рафската  контролна  сума . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 377  
CSM_029 При процедурата  на договаряне  на ключ  се инициира  
броячът  на изпратените  поредици  (SSC) по следния  
начин : 
Начален  SSC: Rnd3 (4- те най-младши  байта ) || Rnd1 (4- те 
най-младши  байта ). 
CSM_030 Броячът  на изпратените  поредици  се увеличава  с 1 при 
всяко  изчисляване  на MAC (т.е. SSC за SSC след  първата  
команда  е началният  SSC + 1 и SSC след  първия  отговор  
е SSC + 2).  
Процедурата  по изчисляването  на подробния  MAC е 
показана  на следната  фигура :
 
5.4. Алгоритъм  за изчисление  на криптограмите  за поверителни  
обекти  от данни  
CSM_031 Тези  криптограми  се изчисляват  с използване  на TDEA в 
работен  режим  TCBC, съгласно  референтните  документи  
[TDES] и [TDES-OP] и с нулев  вектор  като блок  на 
началната  стойност . 
Прилагането  на ключове  в TDES е показано  на следната  
фигура :
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 378  
6. МЕХАНИЗМИ  ЗА ИЗТЕГЛЯНЕ  НА ДАННИ  С ЕЛЕКТРОННИ  
ПОДПИСИ  
CSM_032 Специализираното  интелигентно  устройство  (IDE) 
записва  във физически  файл  данните , прехвърлени  от 
съответното  оборудване  (бордово  устройство  или карта ) 
в рамките  на една  сесия  на изтегляне  на данни . Този  
файл  трябва  да съдържа  сертификатите  MS  i .C и EQT.C. 
Файлът  съдържа  електронни  подписи  на блоковете  
данни , както  е специфицирано  в допълнение  7 „Про­  
токоли  за изтегляне  на данни “. 
CSM_033 За електронните  подписи  на изтеглените  данни  трябва  да 
се използва  схема  за електронни  подписи  с допълнение , 
така че при съответно  желание  изтеглените  данни  да 
могат  да се четат  без каквото  и да е дешифриране . 
6.1. Генериране  на подписи  
CSM_034 Генерирането  от оборудването  на електронни  подписи  на 
данните  трябва  да следва  схемата  за електронни  подписи  
с допълнение , дефинирана  в референтния  документ  
[PKCS1] с хеш-функцията  SHA-1:  
Подпис  = EQT.SK[‘00’ || ‘01’ ||  PS || ‘00’ || DER(SHA- 
1(Data))]  
PS = Допълващ  низ от октети  със стойност  ‘FF’, така че 
дължината  да стане  128.  
DER(SHA-1(M)) е кодирането  на идентификатора  на 
алгоритъма  на хеш-функцията  и хеш-стойността  в 
стойност  ASN.1 от типа  DigestInfo ( разграничени  
правила  за кодиране ): 
‘30’||‘21’||‘30’||‘09’||‘06’||‘05’ ||‘2B’||‘0E’||‘03’||‘02’||‘1A’|| 
‘05’||‘00’||‘04’||‘14’|| Хеш -стойност . 
6.2. Проверка  на подписите  
CSM_035 При проверката  на електронните  подписи  на изтеглените  
данни  трябва  да се следва  схемата  за електронни  подписи  
с допълнение , дефинирана  в референтния  документ  
[PKCS1] с функцията  за хеширане  SHA-1.  
Необходимо  е европейският  публичен  ключ  EUR.PK да 
бъде  познат  на проверителя  по независим  път и прове­  
рителят  да има доверие  в него . 
В следната  таблица  е илюстриран  протоколът , който  
може  да бъде  следван  от специализирано  интелигентно  
устройство  (IDE) с вложена  в него  контролна  карта  за 
проверка  на цялостността  на данните , изтеглени  и 
съхранени  на външен  носител  на информация  (ESM). 
Контролната  карта  се използва  за дешифриране  на елек­  
тронните  подписи . В такъв  случай  тази функция  може  да 
не е въведена  в IDE.  
Оборудването , което  е изтеглило  и подписало  
подлежащите  на анализ  данни , е означено  със съкра­  
щението  EQT.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 379
  
ЧАСТ  Б 
ТАХОГРАФСКА  СИСТЕМА  ОТ ВТОРО  ПОКОЛЕНИЕ  
7. ВЪВЕДЕНИЕ  
7.1. Позовавания  
В настоящото  допълнение  се използват  позовавания  на следните  
референтни  документи : 
AES National Institute of Standards and Technology (NIST), 
FIPS PUB 197: Advanced Encryption Standard (AES), 
November 26, 2001  
DSS National Institute of Standards and Technology (NIST), 
FIPS PUB 186-4: Digital Signature Standard (DSS), July 
2013  
ISO 7816-4 ISO/IEC 7816-4, Идентификационни  карти . Карти  с 
интегрална (и) схема (и). Част  4: Организация , 
сигурност  и команди  за обмен . Трето  издание , 2013- 
04-15  
ISO 7816-8 ISO/IEC 7816-8, Идентификационни  карти . Карти  с 
интегрална (и) схема (и). Част  8: Команди  за операции  
по сигурността  Второ  издание  2004-06-01  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 380  
ISO 8825-1 ISO/IEC 8825-1 Информационна  технология . Правила  
за кодиране  на ASN.1. Спецификация  на основни  
(BER), канонични  (CER) и разграничени  (DER) 
правила  за кодиране . Четвърто  издание , 2008-12-15  
ISO 9797-1 Информационни  технологии . Техники  за сигурност . 
Кодове  за удостоверяване  на автентичността  на съоб­  
щението  (MACs). Част  1: Механизми , използващи  
блоков  шифър . Второ  издание , 2011-03-01  
ISO 10116 ISO/IEC 10116, Информационни  технологии . Техники  
за сигурност . Режими  ма работа , използващи  n-битов  
блоков  шифър . Трето  издание , 2006-02-01  
ISO 16844-3 ISO/IEC 16844-3, Пътни  превозни  средства . Тахог­  
рафски  системи . Част  3: Интерфейс  на датчика  на 
движение . Първо  издание , 2004 г., включително  
Техническа  поправка , 1.2006 г. 
RFC 5480 Elliptic Curve Cryptography Subject Public Key Infor ­
mation, March 2009  
RFC 5639 Elliptic Curve Cryptography (ECC) — Brainpool 
Standard Curves and Curve Generation, 2010  
RFC 5869 HMAC-based Extract-and-Expand Key Derivation 
Function (HKDF), May 2010  
SHS National Institute of Standards and Technology (NIST), 
FIPS PUB 180-4: Secure Hash Standard, March 2012  
SP 800-38B National Institute of Standards and Technology (NIST), 
Special Publication 800-38B: Recommendation for Block 
Cipher Modes of Operation: The CMAC Mode for 
Authentication, 2005  
TR-03111 BSI Technical Guideline TR-03111, Elliptic Curve Cryp ­
tography, version 2.00, 2012-06-28  
7.2. Означения  и съкращения  
В настоящото  допълнение  са използвани  следните  означения  и 
съкращения  на термини : 
AES Advanced Encryption Standard ( усъвършенстван  
стандарт  за криптиране ) 
CA Certificate Authority ( сертифициращ  орган ) 
CAR Certificate Authority Reference ( референтно  означение  
на сертифициращия  орган ) 
CBC Cipher Block Chaining (mode of operation) ( свързване  на 
блокове  от шифровани  данни  (работен  режим )) 
CH Command Header ( заглавна  част на команда ) 
CHA Certificate Holder Authorisation ( оторизация  на титуляря  
на сертификата ) 
CHR Certificate Holder Reference ( референтно  означение  на 
титуляря  на сертификата ) 
CV Constant Vector ( константен  вектор ) 
DER Distinguished Encoding Rules ( разграничени  правила  за 
кодиране ) 
DO Data Object ( обект  от данни ) 
DSRC Dedicated Short Range Communication ( специализирана  
връзка  (или съобщителна  система ) с малък  обсег  на 
действие ) 
ECC Elliptic Curve Cryptography ( криптография  по 
елиптична  крива ) 
ECDSA Elliptic Curve Digital Signature Algorithm ( алгоритъм  за 
електронни  подписи  по елиптична  крива ) 
ECDH Elliptic Curve Diffie-Hellman (key agreement algorithm) 
(елиптична  крива  Diffie-Hellman — алгоритъм  за дого­  
варяне  на ключ ) 
EGF External GNSS Facility ( външно  устройство  за GNSS)  
EQT Equipment ( оборудване ) ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 381  
IDE Intelligent Dedicated Equipment ( специализирано  инте­  
лигентно  устройство ) 
K M Motion Sensor Master Key, allowing the pairing of a 
Vehicle Unit to a Motion Sensor ( главен  ключ  за 
датчика  за движение , даващ  възможност  за сдвояване  
на бордовото  устройство  към датчика  за движение ) 
K M-VU  Key inserted in vehicle units, allowing a VU to derive the 
Motion Sensor Master Key if a workshop card is inserted 
into the VU ( ключ , въвеждан  в бордовите  устройства , 
даващ  възможност  на съответното  бордово  устройство  
да изведе  главния  ключ  (Master Key) на датчика  за 
движение , ако в бордовото  устройство  бъде  вкарана  
карта  за монтаж  и настройки ) 
K M-WC  Key inserted in workshop cards, allowing a VU to derive 
the Motion Sensor Master Key if a workshop card is 
inserted into the VU ( ключ , въвеждан  в картите  за 
монтаж  и настройки , даващ  възможност  на съот­  
ветното  бордово  устройство  да изведе  главния  ключ  
на датчика  за движение , ако в бордовото  устройство  
бъде  вкарана  карта  за монтаж  и настройки ) 
MAC Message Authentication Code ( код за автентифициране  
на съобщение ) 
MoS Motion Sensor ( датчик  за движение ) 
MSB Most Significant Bit ( най-старши  бит) 
PKI Public Key Infrastructure ( инфраструктура  с публичен  
ключ ) 
RCF Remote Communication Facility ( устройство  за връзка  от 
разстояние ) 
SSC Send Sequence Counter ( брояч  на изпратени  поредици ) 
SM Secure Messaging ( защитен  обмен  на съобщения ) 
TDES Triple Data Encryption Standard ( троен  DES — симе­  
тричен  ключ , който  изпълнява  стандарта  за криптиране  
на данни  DES три пъти  с различни  ключове ) 
TLV Tag Length Value ( стойност  на дължината  на таг) 
VU Vehicle Unit ( бордово  устройство ) 
X.C The public key certificate of user X ( сертификатът  на 
публичен  ключ  на ползвателя  Х) 
X.CA The certificate authority that issued the certificate of user 
X (сертифициращият  орган , издал  сертификата  на 
ползвателя  X) 
X.CAR The certificate authority reference mentioned in the certificate 
of user X ( референтното  означение  на сертифициращия  
орган , посочено  в сертификата  на ползвателя  X) 
X.CHR The certificate holder reference mentioned in the certificate 
of user X ( референтното  означение  на титуляря  на 
сертификата , посочено  в сертификата  на ползвателя  X) 
X.PK Public key of user X ( публичен  ключ  на ползвателя  Х) 
X.SK Private key of user X ( частен  ключ  на ползвателя  Х) 
X.PK  eph Ephemeral public key of user X ( краткотраен  (ephemeral) 
публичен  ключ  на ползвателя  Х) 
X.SK  eph Ephemeral private key of user X ( краткотраен  (ephe­
meral) частен  ключ  на ползвателя  Х) 
‘xx’ A hexadecimal value ( шестнадесетична  стойност ) 
|| Concatenation operator ( оператор  за конкатенация ) 
7.3. Определения  
Определенията  на използваните  в настоящото  допълнение  термини  
са включени  в раздел  I от приложение  1В. 
8. КРИПТОГРАФСКИ  СИСТЕМИ  И АЛГОРИТМИ  
8.1. Криптографски  системи  
CSM_38 Бордовите  устройства  и тахографските  карти  трябва  да 
използват  класическа  базираща  се на елиптична  крива  
криптографска  система  с публичен  ключ  за пред­  
оставяне  на следните  механизми  за сигурност : 
— взаимно  удостоверяване  на автентичност  между  
бордово  устройство  и карта , ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 382  
— договаряне  на AES сесийни  ключове  между  
бордово  устройство  и карта , 
— осигуряване  на автентичност , цялостност  и 
безотказно  приемане  на данните , изтегляни  от 
бордовите  устройства  или от тахографските  карти  
върху  външни  носители  на информация . 
CSM_39 Бордовите  устройства  и външните  устройства  за GNSS 
трябва  да използват  класическа  базираща  се на 
елиптична  крива  криптографска  система  с публичен  
ключ  за предоставяне  на следните  механизми  за 
сигурност : 
— свързване  на бордово  устройство  и външно  GNSS 
устройство , 
— взаимно  удостоверяване  на автентичност  между  
бордово  устройство  и външно  GNSS устройство , 
— договаряне  на AES сесийни  ключове  между  
бордово  устройство  и външно  GNSS устройство . 
CSM_40 Бордовите  устройства  и тахографските  карти  трябва  да 
използват  класическа  базираща  се на AES симетрична  
криптографска  система  за предоставяне  на следните  
механизми  за сигурност : 
— осигуряване  на автентичност  и цялостност  на 
данните , обменяни  между  бордово  устройство  и 
тахографска  карта , 
— в съответните  случаи , осигуряване  на повери­  
телност  на данните , обменяни  между  бордово  
устройство  и тахографска  карта . 
CSM_41 Бордовите  устройства  и външните  устройства  за GNSS 
трябва  да използват  класическа  базираща  се на AES 
симетрична  криптографска  система  за предоставяне  
на следните  механизми  за сигурност : 
— осигуряване  на автентичност  и цялостност  на 
данните , обменяни  между  бордово  устройство  и 
тахографска  карта . 
CSM_42 Бордовите  устройства  и датчиците  за движение  трябва  
да използват  класическа  базираща  се на AES симе­  
трична  криптографска  система  за предоставяне  на 
следните  механизми  за сигурност : 
— сдвояване  на бордово  устройство  и датчик  за 
движение , 
— взаимно  удостоверяване  на автентичност  между  
бордово  устройство  и датчик  за движение , 
— осигуряване  на поверителност  на данните , 
обменяни  между  бордово  устройство  и датчик  за 
движение . 
CSM_43 Бордовите  устройства  и контролните  карти  трябва  да 
използват  класическа  базираща  се на AES симетрична  
криптографска  система  за предоставяне  на следните  
механизми  за сигурност : 
— осигуряване  на поверителност , автентичност  и 
цялостност  на данните , предавани  между  бордово  
устройство  и контролна  карта , 
Забележки : 
— По-точно  казано , данните  се предават  от бордово  
устройство  към дистанционно  разпитващо  
устройство  под контрола  на инспектор , като се 
използва  устройство  за връзка  от разстояние , 
което  може  да е вътрешно  или външно  за 
бордовото  устройство , вж. допълнение  14. Дистан­  
ционното  разпитващо  устройство  обаче  изпраща  
получените  данни  на контролна  карта  за дешиф­  
риране  и валидиране  на автентичността . От гледна  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 383  
точка  на сигурността , устройството  за връзка  от 
разстояние  и дистанционното  разпитващо  
устройство  са изцяло  прозрачни . 
— Същите  механизми  за сигурност , които  се 
изпълняват  от контролната  карта , се предоставят  и 
от картата  за монтаж  и настройки  по отношение  на 
интерфейса  за DSRC. Това  дава възможност  на 
съответния  сервиз  да валидира  правилното  
функциониране  на интерфейса  за връзка  от 
разстояние  на дадено  бордово  устройство , вклю­  
чително  и неговата  сигурност . За повече  
информация  вж. раздел  9.2.2.  
8.2. Криптографски  алгоритми  
8.2.1  Симетрични  алгоритми  
CSM_44 Бордовите  устройства , тахографските  карти , датчиците  
за движение  и външните  устройства  за GNSS трябва  да 
поддържат  алгоритъма  AES, както  е дефиниран  в 
[AES], с дължина  на ключовете  128, 192 и 256 бита . 
8.2.2  Асиметрични  алгоритми  и стандартизирани  домейн  параметри  
CSM_45 Бордовите  устройства , тахографските  карти  и 
външните  устройства  за GNSS трябва  да поддържат  
криптография  по елиптична  крива  с размер  на 
ключовете  256, 384 и 512/521 бита . 
CSM_46 Бордовите  устройства , тахографските  карти  и 
външните  устройства  за GNSS трябва  да поддържат  
алгоритъма  за подписи  ECDSA, както  е специфициран  
в [DSS].  
CSM_47 Бордовите  устройства , тахографските  карти  и 
външните  устройства  за GNSS трябва  да поддържат  
алгоритъма  за договаряне  на ключ  ECKA-EG, както  е 
специфициран  в [TR 03111].  
CSM_48 Бордовите  устройства , тахографските  карти  и 
външните  устройства  за GNSS трябва  да поддържат  
всички  стандартизирани  домейн  параметри , специфи­  
цирани  по-долу  в таблица  1 за криптография  по 
елиптична  крива . 
Таблица  1 
Стандартизирани  домейн  параметри  
Наименовани e Размер  (битове ) Референтно  означение  Идентификатор  на обект  (Object 
Identifier)  
NIST P-256  256  [DSS], [RFC 5480]
  
BrainpoolP256r1  256  [RFC 5639]
  
NIST P-384  384  [DSS], [RFC 5480]
  
BrainpoolP384r1  384  [RFC 5639]
  
BrainpoolP512r1  512  [RFC 5639]
  
NIST P-521  521  [DSS], [RFC 5480]
  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 384  
Забележка : идентификаторите  на обекти , споменати  в 
последната  колона  на таблица  1, са специфицирани  
съответно  в [RFC 5639] за кривите  Brainpool и в 
[RFC 5480] за кривите  NIST.
  
8.2.3  Алгоритми  за хеширане  
▼M1 
CSM_49 Бордовите  устройства , тахографските  карти  и 
външните  устройства  за GNSS трябва  да поддържат  
алгоритмите  SHA-256, SHA-384 и SHA-512, специфи­  
цирани  в [SHS].  
▼B 
8.2.4  Криптографски  поредици  
CSM_50 При симетричния  алгоритъм  се използват  съвместно  
асиметричен  алгоритъм  и/или алгоритъм  за хеширане , 
така че да формират  протокол  за сигурност , като съот­  
ветните  дължини  на ключовете  и хеш размери  трябва  
да бъдат  (приблизително ) с еднаква  сила  (equal 
strength). Разрешените  криптографски  поредици  са 
показани  в таблица  2: 
Таблица  2 
Разрешени  криптографски  поредици  
Идентификатор  на 
криптографската  
поредица  Размер  на ключа  
ECC (битове ) Размер  на ключа  AES 
(битове ) Алгоритъм  за 
хеширане  Дължина  на кода  
за автентифи­  
циране  на 
съобщения  
(MAC, байтове ) 
CS#1  256  128  SHA-256  8  
CS#2  384  192  SHA-384  12  
CS#3  512/521  256  SHA-512  16  
Забележка : Размерите  на ECC ключове  от 512 бита  и 521 бита  се считат  за равни  по сила  
за всички  цели  в рамките  на настоящото  допълнение . 
9. КЛЮЧОВЕ  И СЕРТИФИКАТИ  
9.1. Двойки  от асиметрични  ключове  и сертификати  на публични  
ключове  
9.1.1  Общи  положения  
Забележка : описаните  в настоящия  раздел  ключове  се използват  за 
взаимно  удостоверяване  на автентичност  и за защитен  обмен  на 
съобщения  между  бордови  устройства  и тахографски  карти , както  
и между  бордови  устройства  и външни  устройства  за GNSS. Тези  
процеси  са описани  подробно  в глава  10 и глава  11 от настоящото  
допълнение . 
CSM_51 В рамките  на Европейската  система  за интелигентни  
тахографи , двойките  ECC ключове  и съответните  
сертификати  се генерират  и управляват  на три 
функционални  йерархични  равнища : 
— европейско  равнище , 
— равнище  на държавата  членка , 
— равнище  на вид оборудване . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 385  
CSM_52 В цялата  Европейска  система  за интелигентни  
тахографи  публичните  и частните  ключове  и серти­  
фикати  трябва  да бъдат  генерирани , управлявани  и 
съобщавани  по стандартизирани  и сигурни  методи . 
9.1.2  Европейско  равнище  
CSM_53 На европейското  равнище  се генерира  само  една  
уникална  двойка  ECC ключове , с означение  EUR. Тя 
се състои  от частен  ключ  (EUR.SK) и публичен  ключ  
(EUR.PK). Тази  двойка  ключове  формира  двойката  
основни  ключове  (root key pair) на цялата  инфраст­  
руктура  за публични  ключове  на Европейската  
система  за интелигентни  тахографи . Тази  задач a се 
изпълнява  от Европейския  орган  за основни  серти­  
фикати  (European Root Certificate Authority — ERCA), 
който  е под управлението  и отговорността  на Евро­  
пейската  комисия . 
CSM_54 ERCA използва  европейския  частен  ключ  за 
подписване  на (самоподписан ) основен  сертификат  
(root certificate) на европейския  публичен  ключ  и да 
съобщава  този европейски  основен  сертификат  на 
всички  държави  членки . 
CSM_55 При поискване  ERCA използва  европейския  частен  
ключ  за подписване  на сертификатите  на държавите  
членки . Задължение  на ERCA е да съхранява  архивни  
записи  за всички  подписани  сертификати  за публичен  
ключ  на държави  членки . 
CSM_56 Както  е показано  на фигура  1 в раздел  9.1.7, на всеки  
17 години  ERCA трябва  да генерира  нова  европейска  
двойка  основни  ключове . Когато  ERCA генерира  нова  
европейска  двойка  основни  ключове , тя трябва  да 
създаде  нов самоподписан  основен  сертификат  за 
новия  европейски  публичен  ключ . Периодът  на 
валидност  на даден  европейски  основен  сертификат  е 
34 години  и 3 месеца . 
Забележка : Въвеждането  на нова  двойка  основни  
ключове  означава  също , че ERCA ще генерира  нов 
главен  ключ  (master key) на датчика  за движение  и 
нов главен  ключ  за DSRC, вж. раздели  9.2.1.2 и 9.2.2.2.  
CSM_57 Преди  генерирането  на нова  европейска  двойка  
основни  ключове , ERCA трябва  да направи  анализ  за 
необходимата  криптографска  сила  на новата  двойка  
ключове , като се има предвид  че тя следва  да запази  
своята  сигурност  в следващите  34 години . Ако това се 
окаже  необходимо , ERCA трябва  да премине  към 
използване  на по-силна  криптографска  поредица  от 
използваната  до този момент , както  е специфицирано  
в CSM_50.  
▼M1 
CSM_58 Когато  генерира  нова  европейска  двойка  основни  
ключове , ERCA трябва  да създаде  свързващ  
сертификат  за новия  европейски  публичен  ключ  и да 
го подпише  с предходния  европейски  частен  ключ . 
Срокът  на валидност  на свързващия  сертификат  е 17 
години  и 3 месеца . Това  е показано  също  на фигура  1 в 
раздел  9.1.7.  
▼B 
Забележка : Тъй като свързващият  сертификат  съдържа  
публичен  ключ  на ERCA от поколение  X и е подписан  
с частен  ключ  на ERCA от поколение  X-1, свързващият  
сертификат  предоставя  на оборудването  с криптиране  
от поколение  X-1  метод , по който  да се доверява  на 
оборудване  с криптиране  от поколение  X. 
CSM_59 От момента  когато  стане  валиден  нов сертификат  за 
основни  ключове , ERCA трябва  вече да не използва  
частния  ключ  от двойка  основни  ключове  за каквото  
и да е предназначение . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 386  
CSM_60 Във всеки  момент  във времето  ERCA трябва  да 
разполага  със следните  криптографски  ключове  и 
сертификати : 
— Текущата  двойка  ключове  EUR и съответния  
сертификат  
— Всички  предходни  сертификати  EUR, използвани  за 
проверка  на сертификатите  на сертифициращите  
органи  на държавите  членки  (MSCA), които  
продължават  да са валидни  
— Свързващи  сертификати  за всички  поколения  EUR 
сертификати  освен  за първото  
9.1.3  Равнище  на държава  членка  
CSM_61 На равнището  на държава  членка , всички  държави  
членки , от които  се изисква  да подписват  сертификати  
за тахографски  карти , трябва  да генерират  една  или 
повече  уникални  двойки  ключове  ECC с обозначението  
MSCA_Card. Всички  държави  членки , от които  се 
изисква  да подписват  сертификати  за външни  
устройства  за GNSS или за бордови  устройства , 
трябва  да генерират  допълнително  една  или повече  
уникални  двойки  ключове  ECC с обозначението  
MSCA_VU-EGF.  
CSM_62 Задачата  за генериране  на двойки  ключове  на държава  
членка  се изпълнява  от сертифициращия  орган  на 
държавата  членка  (MSCA). Когато  даден  MSCA 
генерира  двойка  ключове  на държава  членка , той 
изпраща  публичния  ключ  на Европейския  орган  за 
основни  сертификати  (ERCA), за да получи  съответния  
подписан  от ERCA сертификат  на държава  членка . 
CSM_63 MSCA избира  силата  на двойка  ключове  на държава  
членка  така, че тя да е равна  на силата  на европейската  
основна  двойка  ключове , използвана  за подписване  на 
съответния  сертификат  на държавата  членка . 
CSM_64 Когато  съществува  двойка  ключове  MSCA_VU-EGF, тя 
се състои  от частен  ключ  MSCA_VU-EGF.SK и 
публичен  ключ  MSCA_VU-EGF.PK. MSCA трябва  да 
използва  частния  ключ  MSCA_VU-EGF.SK изклю­  
чително  само  за подписване  на сертификатите  на 
публични  ключове  на външни  устройства  за GNSS и 
на бордови  устройства . 
CSM_65 Всяка  двойка  ключове  MSCA_Card се състои  от частен  
ключ  MSCA_Card.SK и публичен  ключ  
MSCA_Card.PK. MSCA използва  частния  ключ  
MSCA_Card.SK изключително  само  за подписване  на 
сертификатите  на публични  ключове  на тахографски  
карти . 
CSM_66 MSCA трябва  да съхранява  архивни  записи  за всички  
подписани  сертификати  за бордови  устройства , серти­  
фикати  за външни  GNSS устройства  и сертификати  за 
карти , заедно  с идентификационните  данни  на оборуд­  
ването , за което  е предназначен  всеки  сертификат . 
CSM_67 Периодът  на валидност  на сертификат  MSCA_VU-EGF 
е 17 години  и 3 месеца . Периодът  на валидност  на 
сертификат  MSCA_Card е 7 години  и 1 месеца . 
CSM_68 Както  е показано  на фигура  1 в раздел  9.1.7, частният  
ключ  от двойка  ключове  MSCA_VU-EGF и частният  
ключ  от двойка  ключове  MSCA_Card са с период  на 
използване  две години . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 387  
CSM_69 След  края  на периода  на използване  съответният  
MSCA трябва  вече да не използва  за каквото  и да е 
предназначение  частния  ключ  от двойка  ключове  
MSCA_VU-EGF. Също  така, след  края  на периода  на 
използване  съответният  MSCA трябва  вече да не 
използва  за каквото  и да е предназначение  частния  
ключ  от двойка  ключове  MSCA_Card.  
CSM_70 Във всеки  момент  във времето  MSCA трябва  да 
разполага  със следните  криптографски  ключове  и 
сертификати : 
— Текущата  двойка  ключове  MSCA_Card и съот­  
ветния  сертификат  
— Всички  предходни  сертификати  MSCA_Card, 
използвани  за проверка  на сертификатите  на тахог­  
рафски  карти , които  продължават  да са валидни  
— Текущият  сертификат  EUR, необходим  за проверка  
на текущия  сертификат  на MSCA  
— Всички  предходни  сертификати  EUR, необходими  
за проверка  на всички  сертификати  на MSCA, 
които  продължават  да са валидни  
CSM_71 Ако от даден  MSCA се изисква  да подписва  серти­  
фикати  за външни  устройства  за GNSS или за 
бордови  устройства , той трябва  да разполага  също  и 
със следните  ключове  и сертификати : 
— Текущата  двойка  ключове  MSCA_VU-EGF и съот­  
ветния  сертификат  
— Всички  предходни  публични  ключове  MSCA_VU- 
EGF, използвани  за проверка  на сертификатите  на 
външни  устройства  за GNSS и на бордови  
устройства , които  продължават  да са валидни  
9.1.4  Равнище  на съответното  оборудване : бордови  устройства  
▼M1 
CSM_72 За всяко  бордово  устройство  трябва  да бъдат  гене­  
рирани  две уникални  двойки  ключове  ECC с обоз­  
начения  съответно  VU_MA и VU_Sign. Тази  задача  
се изпълнява  от производителите  на бордови  
устройства . Когато  бъде  генерирана  двойка  ключове  
за бордово  устройство , генериралата  ключовете  
страна  трябва  да изпрати  публичния  ключ  на своя  
MSCA, за да получи  съответен  сертификат  за 
бордовото  устройство , подписан  от MSCA. Частният  
ключ  трябва  да се използва  само  от бордовото  
устройство . 
▼B 
CSM_73 Сертификатите  VU_MA и VU_Sign на дадено  бордово  
устройство  трябва  да имат  една  и съща  дата на влизане  
в сила . 
CSM_74 Производителят  на бордови  устройства  избира  силата  
на двойка  ключове  на съответното  бордово  устройство  
така, че тя да е равна  на силата  на двойката  ключове  
на MSCA, използвана  за подписване  на съответния  
сертификат  на бордово  устройство . 
CSM_75 Всяко  бордово  устройство  трябва  да използва  своята  
двойка  ключове  VU_MA, състояща  се от частен  ключ  
VU_MA.SK и публичен  ключ  VU_MA.PK изклю­  
чително  само  за удостоверяване  на автентичността  на 
бордовото  устройство  по отношение  на тахографските  
карти  и външните  устройства  за GNSS, както  е специ­  
фицирано  в раздел  10.3 и раздел  11.4 от настоящото  
допълнение . 
CSM_76 Всяко  бордово  устройство  трябва  да може  да генерира  
двойки  краткотрайни  (ephemeral) ключове  за ECC и 
трябва  да използва  дадена  двойка  краткотрайни  (ephe­
meral) ключове  изключително  само  за извършване  на 
договаряне  на сесиен  ключ  с тахографска  карта  или с 
външно  устройство  за GNSS, както  е специфицирано  в 
раздел  10.4 и раздел  11.4 от настоящото  допълнение . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 388  
CSM_77 Всяко  бордово  устройство  трябва  да използва  частния  
ключ  VU_Sign.SK от своята  двойка  ключове  VU_Sign 
изключително  само  за подписване  на изтеглени  
файлове  с данни , както  е специфицирано  в глава  14 
от настоящото  допълнение . Съответният  публичен  
ключ  VU_Sign.PK трябва  да бъде  използван  изклю­  
чително  само  за проверяване  на подписите , създадени  
от бордовото  устройство . 
CSM_78 Както  е показано  на фигура  1 в раздел  9.1.7, периодът  
на валидност  на сертификат  VU_MA е 15 години  и 3 
месеца . Периодът  на валидност  на сертификат  
VU_Sign също  е 15 години  и 3 месеца . 
Забележки : 
— Удълженият  период  на валидност  на сертификата  
VU_Sign дава възможност  на бордовото  устройство  
да създава  валидни  подписи  върху  изтеглени  данни  
през първите  три месеца  след  изтичането  на серти­  
фиката , както  се изисква  съгласно  Регламент  (ЕС) 
№ 581/2010.  
— Удълженият  период  на валидност  на сертификата  
VU_MA дава възможност  на бордовото  устройство  
да удостовери  автентичността  на контролна  карта  
или на фирмена  карта  на превозвач  през първите  
три месеца  след  изтичането  на сертификата , така че 
да е възможно  да се извърши  изтегляне  на данни . 
CSM_79 След  изтичането  на съответния  сертификат , бордовото  
устройство  трябва  да не използва  за каквото  и да е пред­  
назначение  частния  ключ  от двойката  ключове  VU.  
CSM_80 Двойките  ключове  VU (освен  краткотрайните  двойки  
ключове ) и съответните  сертификати  на дадено  
бордово  устройство  не трябва  да се заменят  или 
обновяват  в работна  среда  (in the field) след  като 
бордовото  устройство  е пуснато  в експлоатация . 
Забележки : 
— Това  изискване  не се отнася  за двойките  крат­  
котрайни  (ephemeral) ключове , тъй като нова  
двойка  краткотрайни  ключове  се създава  всеки  
път, когато  се прави  удостоверяване  на автентич­  
ността  на чип и се извършва  договаряне  на сесиен  
ключ , вж. раздел  10.4. Да се има предвид , че крат­  
котрайните  ключове  нямат  съответни  сертификати . 
— Настоящото  изискване  не ограничава  възможността  
за замяна  на двойки  статични  ключове  VU при 
модернизация  или поправка  в сигурна  среда , 
контролирана  от производителя  на бордовото  
устройство . 
CSM_81 При пускането  си в експлоатация  бордовите  
устройства  трябва  да съдържат  следните  криптог­  
рафски  ключове  и сертификати : 
— Частния  ключ  VU_MA и съответния  сертификат  
— Частния  ключ  VU_Sign и съответния  сертификат  
— Сертификата  MSCA_VU-EGF, съдържащ  
публичния  ключ  MSCA_VU-EGF.PK, който  се 
използва  за проверяване  на сертификата  VU_MA 
и на сертификата  VU_Sign  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 389  
— Сертификата  EUR, съдържащ  публичния  ключ  
EUR.PK, който  се използва  за проверяване  на 
сертификата  MSCA_VU-EGF  
— Ако съществува  — сертификата  EUR, чийто  период  
на валидност  непосредствено  предшества  този 
сертификат  EUR, който  се използва  за проверяване  
на сертификата  MSCA_VU-EGF  
— Ако съществува  — свързващия  сертификат , който  
дава връзка  между  тези два сертификата  EUR  
CSM_82 В допълнение  към криптографските  ключове  и серти­  
фикатите , посочени  в CSM_81, бордовите  устройства  
трябва  да съдържат  също  ключовете  и сертификатите , 
специфицирани  в част А от настоящото  допълнение , 
даващи  възможност  на бордовото  устройство  да взаи­  
модейства  с тахографски  карти  от първо  поколение . 
9.1.5  Равнище  на вид оборудване : Тахографски  карти  
▼M1 
CSM_83 За всяка  тахографска  карта  трябва  да бъде  генерирана  
една  уникална  двойка  ключове  ECC, обозначена  като 
Card_MA. Допълнително  трябва  да бъде  генерирана  
втора  уникална  двойка  ключове  ECC, обозначена  
като Card_Sign, за всяка  карта  на водач  и всяка  карта  
за монтаж  и настройки . Тази  задача  може  да бъде  
изпълнявана  от производителите  на карти  или от 
персонализаторите  на карти . Когато  бъде  генерирана  
двойка  ключове  за карта , генериралата  ключовете  
страна  трябва  да изпрати  публичния  ключ  на своя  
MSCA, за да получи  съответен  сертификат  за картата , 
подписан  от MSCA. Частният  ключ  трябва  да се 
използва  само  от тахографската  карта . 
▼B 
CSM_84 Сертификатите  Card_MA и Card_Sign на дадена  карта  
на водач  или карта  за монтаж  и настройки  трябва  да 
имат  една  и съща  дата на влизане  в сила . 
CSM_85 Производителят  на картата  или нейният  персона­  
лизатор  избира  силата  на двойка  ключове  на съот­  
ветната  карта  така, че тя да е равна  на силата  на 
двойката  ключове  на MSCA, използвана  за подписване  
на съответния  картов  сертификат . 
CSM_86 Всяка  тахографска  карта  трябва  да използва  своята  
двойка  ключове  Card_MA, състояща  се от частен  
ключ  Card_MA.SK и публичен  ключ  Card_MA.PK 
изключително  само  за извършване  на взаимно  удосто­  
веряване  на автентичността  и договаряне  на сесийни  
ключове  с бордови  устройства , както  е специфицирано  
в раздел  10.3 и раздел  10.4 от настоящото  допълнение . 
CSM_87 Всяка  карта  на водач  или карта  за монтаж  и настройки  
трябва  да използва  частния  ключ  Card_Sign.SK от 
своята  двойка  ключове  Card_Sign изключително  само  
за подписване  на изтеглени  файлове  с данни , както  е 
специфицирано  в глава  14 от настоящото  допълнение . 
Съответният  публичен  ключ  Card_Sign.PK трябва  да 
бъде  използван  изключително  само  за проверяване  на 
подписите , създадени  от картата . 
▼M1 
CSM_88 Срокът  на валидност  на сертификат  Card_MA е, както  
следва : 
— за карти  на водач : 5 години  
— за карти  на превозвач : 5 години  
— за контролни  карти : 2 години  
— за карти  за монтаж  и настройки : 1 година  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 390  
CSM_89 Периодът  на валидност  на сертификат  Card_Sign е 
както  следва : 
— За карти  на водач : 5 години  и 1 
месец  
— За карти  за монтаж  и наст­  
ройки : 1 година  и 1 
месец  
Забележка : удълженият  период  на валидност  на серти­  
фиката  Card_Sign дава възможност  на карта  на водач  
да създава  валидни  подписи  върху  изтеглени  данни  
през първия  месец  след  изтичането  на сертификата . 
Това  е необходимо  във връзка  с посоченото  в 
Регламент  (ЕС) № 581/2010, в който  се изисква  да 
има възможност  за изтегляне  на данни  от карта  на 
водач  в период  до 28 дни след  записването  на 
последните  данни . 
CSM_90 Веднъж  след  като дадена  тахографска  карта  бъде  
издадена , не трябва  да бъдат  заменяни  или 
подновявани  двойките  ключове  и съответните  серти­  
фикати  в нея. 
CSM_91 При издаването  си тахографските  карти  трябва  да 
съдържат  следните  криптографски  ключове  и серти­  
фикати : 
— Частния  ключ  Card_MA и съответния  сертификат  
— Картите  на водачи  и картите  за монтаж  и 
настройки  трябва  да съдържат  също  и частния  
ключ  Card_Sign и съответния  сертификат  
— Сертификата  MSCA_Card, съдържащ  публичния  
ключ  MSCA_Card.PK, който  се използва  за прове­  
ряване  на сертификата  Card_MA и на сертификата  
Card_Sign  
— Сертификата  EUR, съдържащ  публичния  ключ  
EUR.PK, който  се използва  за проверяване  на 
сертификата  MSCA_Card  
— Ако съществува  — сертификата  EUR, чийто  период  
на валидност  непосредствено  предшества  този 
сертификат  EUR, който  се използва  за проверяване  
на сертификата  MSCA_Card  
— Ако съществува  — свързващия  сертификат , който  
дава връзка  между  тези два сертификата  EUR  
▼M1 
— В допълнение  — само  за контролните  карти , 
картите  на превозвач  и картите  за монтаж  и наст­  
ройки , и то само  ако се издават  през първите  три 
месеца  от срока  на валидност  на нов сертификат  
EUR — ако съществува  — сертификата  EUR, 
който  е по-стар с две поколения . 
Забележка  към последното  тире : Например  през 
първите  три месеца  от срока  на действие  на 
сертификат  на ERCA(3) ( вж. фигура  1) посочените  
карти  трябва  да съдържат  сертификата  на ERCA(1). 
Това  е необходимо , за да се гарантира , че картите  
могат  да се използват  за изтегляне  на данни  от 
бордови  устройства  със сертификат  на ERCA(1), 
чийто  обичаен  15-годишен  срок  на експлоатация  и 
допълнителният  3-месечен  срок  за изтегляне  на 
данни  изтичат  през тези месеци ; вж. изискването  
в приложение  IВ, подточка  13, последното  тире . 
▼B 
CSM_92 В допълнение  към криптографските  ключове  и серти­  
фикатите , посочени  в CSM_91, тахографските  карти  
трябва  да съдържат  също  ключовете  и сертификатите , 
специфицирани  в част А от настоящото  допълнение , 
даващи  възможност  на тези карти  да взаимодействат  
с бордови  устройства  от първо  поколение . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 391  
9.1.6  Равнище  на вид оборудване : външни  устройства  за GNSS  
▼M1 
CSM_93 За всяко  външно  устройство  за GNSS трябва  да бъде  
генерирана  една  уникална  двойка  ключове  ECC, обоз­  
начена  като EGF_MA. Тази  задача  се изпълнява  от 
производителите  на външни  устройства  за GNSS. 
Когато  бъде  генерирана  двойка  ключове  EGF_MA, 
генериралата  ключовете  страна  трябва  да изпрати  
публичния  ключ  на своя  MSCA, за да получи  
съответен  сертификат  за EGF_MA, подписан  от 
MSCA. Частният  ключ  се използва  само  от външното  
устройство  за GNSS.  
▼B 
CSM_94 Производителят  на EGF избира  силата  на двойка  
ключове  EGF_MA така, че тя да е равна  на силата  на 
двойката  ключове  на MSCA, използвана  за подписване  
на съответния  сертификат  EGF_MA.  
▼M1 
CSM_95 Всяко  външно  устройство  за GNSS трябва  да използва  
своята  двойка  ключове  EGF_MA, състояща  се от 
частен  ключ  EGF_MA.SK и публичен  ключ  
EGF_MA.PK, изключително  и само  за взаимно  удосто­  
веряване  на автентичността  и договаряне  на сесийни  
ключове  с бордови  устройства , както  е посочено  в 
раздел  11.4 от настоящото  допълнение . 
▼B 
CSM_96 Периодът  на валидност  на даден  сертификат  EGF_MA 
е 15 години . 
CSM_97 След  изтичането  на съответния  сертификат , външното  
устройство  за GNSS трябва  да не използва  частния  
ключ  от своята  двойка  ключове  EGF_MA за 
куплиране  (coupling) към бордово  устройство . 
Забележка : както  е изяснено  в раздел  11.3.3, дадено  
външно  устройство  за GNSS може  евентуално  да 
използва  своя  частен  ключ  за взаимно  удостоверяване  
на автентичност  с бордово  устройство , към което  то е 
вече куплирано , дори  и след  изтичането  на съответния  
сертификат . 
CSM_98 Двойката  ключове  EGF_MA и съответния  сертификат  
на дадено  външно  устройство  за GNSS не трябва  да се 
заменят  или обновяват  в работна  среда  (in the field) 
след  като външното  устройство  за GNSS е пуснато  в 
експлоатация . 
Забележка : Настоящото  изискване  не ограничава  
възможността  за замяна  на двойки  статични  ключове  
EGF при модернизация  или поправка  в сигурна  среда , 
контролирана  от производителя  на външното  
устройство  за GNSS.  
CSM_99 При пускането  си в експлоатация  външните  устройства  
за GNSS трябва  да съдържат  следните  криптографски  
ключове  и сертификати : 
— Частния  ключ  EGF_MA и съответния  сертификат  
— Сертификата  MSCA_VU-EGF, съдържащ  
публичния  ключ  MSCA_VU-EGF.PK, който  се 
използва  за проверяване  на сертификата  EGF_MA  
— Сертификата  EUR, съдържащ  публичния  ключ  
EUR.PK, който  се използва  за проверяване  на 
сертификата  MSCA_VU-EGF  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 392  
— Ако съществува  — сертификата  EUR, чийто  период  
на валидност  непосредствено  предшества  този 
сертификат  EUR, който  се използва  за проверяване  
на сертификата  MSCA_VU-EGF  
— Ако съществува  — свързващия  сертификат , който  
дава връзка  между  тези два сертификата  EUR  
9.1.7  Обобщение : замяна  на сертификати  
На фигура  1 по-долу  е показано  как се издават  и използват  във 
времето  различните  поколения  основни  сертификати  на ERCA, 
свързващи  сертификати  на ERCA, сертификати  на MSCA и серти­  
фикати  на оборудване  (на бордови  устройства  и карти ): 
▼M1 
Фигура  1 
Издаване  и използване  на различни  поколения  основни  сертификати  на ERCA (ERCA root certificates), 
свързващи  сертификати  на ERCA (ERCA link certificates), сертификати  на MSCA (MSCA certificates) и 
сертификати  на оборудване  (equipment certificates)
  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 393  
Забележки  към фигура  1: 
1. Различните  поколения  основни  сертификати  са означени  с 
поставено  в скоби  число . Например  ERCA (1) означава  първо  
поколение  на основен  сертификат  на ERCA. ERCA (2) е такъв  
сертификат  от второ  поколение  и т.н. 
2. Други  сертификати  са обозначени  с по две числа  в скоби , като 
първото  от тях показва  поколението  на основния  сертификат , въз 
основа  на който  са издадени , а второто  показва  поколението  на 
самия  сертификат . Например  MSCA_Card (1-1) е първият  
сертификат  MSCA_Card, издаден  въз основа  на ERCA (1); 
MSCA_Card (2-1) е първият  сертификат  MSCA_Card, издаден  
въз основа  на ERCA (2); MSCA_Card (2-last) е последният  
сертификат  MSCA_Card, издаден  въз основа  на ERCA (2); 
Card_MA(2-1) е първият  картов  сертификат  за взаимно  удостове­  
ряване  на автентичността , издаден  въз основа  на ERCA (2), и т.н. 
3. Сертификатите  MSCA_Card (2-1) и MSCA_Card (1-last) се издават  
почти  (но не точно ) на една  и съща  дата. Сертификатът  
MSCA_Card (2-1) е първият  сертификат  MSCA_Card, който  ще 
бъде  издаден  въз основа  на ERCA (2), и неговото  издаване  е 
малко  по-късно  от това на MSCA_Card (1-last) — последният  
сертификат  въз основа  на ERCA (1).  
4. Както  е показано  на фигурата , първите  сертификати  VU и Card, 
издадени  въз основа  на ERCA (2), ще се появят  почти  две години  
преди  да се появят  последните  сертификати , издадени  въз основа  
на ERCA (1). Това  е така поради  факта , че сертификатите  VU и 
Card се издават  въз основа  на сертификат  MSCA, а не пряко  въз 
основа  на сертификат  ERCA. Сертификатът  MSCA (2-1) ще бъде  
издаден  веднага  след  като ERCA (2) стане  валиден , но серти­  
фикатът  MSCA (1-last) ще бъде  издаден  малко  преди  това, 
докато  сертификатът  ERCA (1) е все още валиден . По такъв  
начин  двата  сертификата  MSCA ще имат  почти  един  и същ 
период  на валидност , въпреки  факта , че са от различни  поко­  
ления . 
5. Показаният  период  на валидност  за картите  е същият  като този за 
картите  на водачи  (5 години ). 
▼M1 
6. За да се пести  място , разликата  между  сроковете  на валидност  на 
сертификатите  Card_MA и Card_Sign е показана  само  за първото  
поколение . 
▼B 
9.2. Симетрични  ключове  
9.2.1  Ключове  за обезпечаване  на сигурността  на връзката  бордово  
устройство  — датчик  за движение  
9.2.1.1  Общи  положения  
Забележка : предполага  се, че читателите  на настоящия  раздел  са 
запознати  със съдържанието  на [ISO 16844-3], описващ  интерфейса  
между  бордово  устройство  и датчик  за движение . Процесът  на 
сдвояване  между  бордово  устройство  и датчик  за движение  е 
описан  подробно  в глава  12 от настоящото  допълнение . 
CSM_100 За сдвояване  на бордовите  устройства  и датчиците  за 
движение  е необходим  известен  брой  симетрични  
ключове , които  служат  за взаимно  удостоверяване  на 
автентичността  между  бордовите  устройства  и 
датчиците  за движение , а също  и за криптиране  на 
връзката  между  бордовите  устройства  и датчиците  за 
движение , както  е показано  в таблица  3. Всички  тези 
ключове  трябва  да са от типа  AES, с дължина  равна  
на дължината  на главния  ключ  на датчика  за 
движение , която  трябва  да е във връзка  с дължината  
на (предвижданата ) европейска  двойка  основни  
ключове , описана  в CSM_50.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 394  
Таблица  3 
Ключове  за обезпечаване  на сигурността  на връзката  бордово  устройство  — датчик  за движение  
Ключ  Символ  Генериран  от Метод  за генериране  Съхранява  се от 
Главен  ключ  на датчика  
за движение  — част 
VU K M-VU  ERCA  Случаен  ERCA, съответните  MSCA, 
участващи  в издаването  на 
сертификати  за бордови  
устройства , производителите  
на бордови  устройства , 
бордовите  устройства  
Главен  ключ  на датчика  
за движение  — 
сервизна  част K M-WC  ERCA  Случаен  ERCA, MSCA, производи­  
телите  на карти , картите  за 
монтаж  и настройка  
Главен  ключ  за датчика  
за движение  K M Не се генерира  
независимо  Изчислява  се по 
формулата : K  M = K  M- 
VU XOR K  M-WC  ERCA, съответните  MSCA, 
участващи  в издаването  на 
ключове  за датчици  за 
движение  (като опция ) (*) 
Идентификационен  
ключ  K ID Не се генерира  
независимо  Изчислява  се по 
формулата : K  ID =  K M 
XOR CV, където  CV е 
специфицирано  в 
CSM_106  ERCA, съответните  MSCA, 
участващи  в издаването  на 
ключове  за датчици  за 
движение  (като опция ) (*) 
Ключ  за сдвояване  K  P Производителя  
на датчика  за 
движение  Случаен  Един  датчик  за движение  
Сесиен  ключ  K  S Бордовото  
устройство  (при 
сдвояване  на 
бордово  
устройство  и 
датчик  за 
движение  Случаен  Едно  бордово  устройство  и 
един  датчик  за движение  
(*) Съхраняването  на K M и K ID не е задължително , тъй като тези ключове  могат  да бъдат  изведени  от K M–VU  , K  M–WC  и CV. 
CSM_101 Европейският  орган  за основни  сертификати  (ERCA) 
генерира  K M-VU  and K  M-WC  , два случайни  и уникални  
ключа  AES, от които  може  да бъде  изчислен  главният  
ключ  (master key) на датчика  за движение  K M като K M- 
VU XOR K  M-WC  . При поискване  ERCA съобщава  K M, 
K M-VU  и K  M-WC  на сертифициращите  органи  на 
държавите  членки . 
CSM_102 Към всеки  главен  ключ  K  M на датчик  за движение  
ERCA прикрепя  уникален  номер  на версия , който  е 
валиден  също  за конституиращите  ключове  K  M-VU  и 
K M-WC  и за съответния  идентификационен  ключ  K  ID . 
ERCA информира  за номера  на версията  сертифици­  
ращите  органи  на държавите  членки  (MSCAs), когато  
им изпраща  K M-VU  и K M-WC  . 
Забележка : Номерът  на версията  се използва  за разгра­  
ничаване  на различните  поколения  на тези ключове , 
както  е обяснено  подробно  в раздел  9.2.1.2.  
CSM_103 При поискване  сертифициращият  орган  на съответната  
държава  членка  препраща  K M-VU  заедно  с номера  на 
неговата  версия  на производителите  на бордови  
устройства . Производителите  на бордови  устройства  
трябва  да влагат  във всички  произведени  бордови  
устройства  K M-VU  и номера  на неговата  версия . 
CSM_104 Сертифициращият  орган  на държавата  членка  трябва  да 
гарантира , че във всяка  карта  за монтаж  и настройки , 
издадена  в рамките  на неговата  отговорност , е вложен  
K M-WC  , заедно  с номера  на неговата  версия . 
Забележки : 
— Вж. описанието  на типа  данни
  
в Допълнение  2. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 395  
— Както  е изяснено  в раздел  9.2.1.2, фактически  е 
възможно  в една  карта  за монтаж  и настройки  да е 
необходимо  да бъдат  вложени  няколко  поколения  
K M-WC  . 
CSM_105 В допълнение  към ключа  AES, специфициран  в 
CSM_104, всеки  сертифициращ  орган  на държава  
членка  (MSCA) трябва  да гарантира , че TDES ключът  
Km  WC , специфициран  в изискване  CSM_037 в част А 
от настоящото  допълнение , е вложен  във всяка  карта  
за монтаж  и настройки , издадена  в рамките  на отговор­  
ността  на този сертифициращ  орган . 
Забележки : 
— Това  дава възможност  да се използва  карта  за 
монтаж  и настройки  от второ  поколение  за 
куплиране  с бордово  устройство  от първо  поколение . 
— Картата  за монтаж  и настройки  от второ  поколение  
ще съдържа  две различни  приложения  — едно  в 
съответствие  с част Б от настоящото  приложение  и 
едно  в съответствие  с част А. Последното  ще 
съдържа  TDES ключа  Km  WC . 
CSM_106 Сертифициращият  орган  на държава  членка  (MSCA), 
участващ  в издаването  на ключове  за датчици  за 
движение , трябва  да изведе  идентификационния  ключ  
от главния  ключ  на датчика  за движение  чрез 
прилагане  на операцията  XOR върху  него  с константен  
вектор  (CV). Стойността  на CV трябва  да бъде  както  
следва : 
▼M1 
— За 128-битови  главни  ключове  на датчици  за 
движение : CV = ‘B6 44 2C 45 0E F8 D3 62 0B 7A 
8A 97 91 E4 5D 83’  
▼B 
— За 192-битови  главни  ключове  на датчици  за 
движение : CV = ‘72 AD EA FA 00 BB F4 EE F4 
99 15 70 5B 7E EE BB 1C 54 ED 46 8B 0E F8 25’  
— За 256-битови  главни  ключове  на датчици  за 
движение : CV = ‘1D 74 DB F0 34 C7 37 2F 65 55 
DE D5 DC D1 9A C3 23 D6 A6 25 64 CD BE 2D 42 
0D 85 D2 32 63 AD 60’  
Забележка : Константните  вектори  са генерирани  както  
следва : 
Pi_10 = първите  десет  байта  от десетичната  част на мате­  
матическата  константа  π = ‘24 3F 6A 88 85 A3 08 D3 13 
19’ 
CV_128-bits = първите  16 байта  от SHA-256(Pi_10)  
CV_128-bits = първите  24 байта  от SHA-384(Pi_10)  
CV_128-bits = първите  32 байта  от SHA-512(Pi_10)  
CSM_107  ►M1 Всеки  производител  на датчици  за движение  
генерира  за всеки  датчик  за движение  случаен  и 
уникален  ключ  за сдвояване  K P и изпраща  всеки  ключ  
за сдвояване  до своя  сертифициращ  орган  на държавата  
членка  (MSCA). MSCA криптира  всеки  ключ  за 
сдвояване  поотделно  с главния  ключ  на датчика  за 
движение  K M и връща  криптирания  ключ  на произво­  
дителя  на датчика  за движение . За всеки  криптиран  
ключ  MSCA уведомява  производителя  на датчика  за 
движение  за номера  на версията  на съответния  K M . ◄ 
Забележка : Както  е изяснено  в раздел  9.2.1.2, 
фактически  е възможно  за един  датчик  за движение  да 
е необходимо  производителят  да генерира  няколко  
уникални  ключа  за сдвояване . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 396  
CSM_108 Всеки  производител  на датчици  за движение  генерира  
уникален  сериен  номер  за всеки  датчик  за движение  и 
изпраща  всички  серийни  номера  до своя  сертифициращ  
орган  на държавата  членка  (MSCA). MSCA криптира  
всеки  сериен  номер  поотделно  с идентификационния  
ключ  K  ID и връща  криптирания  сериен  номер  на 
производителя  на датчика  за движение . За всеки  
криптиран  сериен  номер  MSCA уведомява  произво­  
дителя  на датчика  за движение  за номера  на версията  
на съответния  K ID . 
▼B 
CSM_109 Във връзка  с изискванията  CSM_107 и CSM_108 MSCA 
трябва  да използва  алгоритъма  AES в работния  режим  
на свързване  на блокове  от шифровани  данни , 
дефиниран  в [ISO 10116], с параметър  на редуване  
(interleave parameter)  m = 1 и инициализиращ  вектор  
SV = ‘00’ {16}, т.е. шестнадесет  байта  с двоична  
стойност  0. В случаите , при които  е необходимо , 
MSCA трябва  да използва  метода  на запълване  2 
(padding method 2), дефиниран  в [ISO 9797-1].  
CSM_110 Производителят  на датчика  за движение  трябва  да 
запише  в бъдещия  датчик  за движение  криптирания  
ключ  за сдвояване  и криптирания  сериен  номер , а 
също  съответните  стойности  „в открит  текст “ (plain 
text values) и съответния  номер  на версията  на K M и 
на K ID ,използвани  за криптирането . 
Забележка : Както  е изяснено  в раздел  9.2.1.2, 
фактически  е възможно  в един  датчик  за движение  да 
е необходимо  производителят  да вложи  няколко  крип­  
тирани  ключа  за сдвояване  и няколко  криптирани  
серийни  номера . 
CSM_111 Освен  посочения  в CSM_110 криптографски  материал  
на базата  на AES, производителят  на датчика  за 
движение  може  също  да запише  във всеки  датчик  за 
движение  и криптографски  материал  на базата  на 
TDES, специфициран  в изискване  CSM_037 в част А 
от настоящото  допълнение . 
Забележка : Това  би дало  възможност  за куплиране  на 
датчик  за движение  от второ  поколение  с бордово  
устройство  от първо  поколение . 
CSM_112 Дължината  на сесийния  ключ  K S, генериран  от бордово  
устройство  при сдвояване  с датчик  за движение , трябва  
да е свързана  с дължината  на неговия  ключ  K M-VU,  както  
е описана  в CSM_50.  
9.2.1.2  Замяна  на главния  ключ  на датчик  за движение  в оборудване  от 
второ  поколение  
CSM_113 Всеки  главен  ключ  на датчик  за движение  (и всички  
съответни  ключове  — вж. таблица  3) е свързан  с 
конкретно  поколение  на двойката  основни  ключове  на 
ERCA. Следователно  тези ключове  трябва  да бъдат  
заменяни  на всеки  17 години . Периодът  на валидност  
на всяко  поколение  главен  ключ  за датчик  за движение  
започва  една  година  преди  началото  на валидността  на 
свързаната  с него  двойка  основни  ключове  на ERCA и 
завършва  с изтичането  на валидността  на свързаната  с 
него  двойка  основни  ключове  на ERCA. Това  е описано  
във фигура  2. ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 397  
Фигура  2 
Издаване  и използване  на различни  поколения  на главния  ключ  за датчик  за движение  в бордови  
устройства , датчици  за движение  и карти  за монтаж  и настройки  (сервизни  карти )
 
CSM_114 Поне  една  година  преди  генерирането  на нова  евро­  
пейска  двойка  основни  ключове , както  е описано  в 
CSM_56, ERCA генерира  нов главен  ключ  за датчика  
за движение  K M , като генерира  нови  K M-VU  и K M-WC  . 
Дължината  на главния  ключ  за датчика  за движение  
трябва  да е свързана  с предвижданата  сила  на новата  
европейска  двойка  основни  ключове , в съответствие  с 
CSM_50. При поискване  ERCA съобщава  новите  K M , 
K M-VU  и K  M-WC  на сертифициращите  органи  на 
държавите  членки  (MSCAs), заедно  с техния  номер  на 
версия . 
CSM_115 MSCA трябва  да гарантира , че всички  валидни  
поколения  K  M-WC  са записани  във всяка  карта  за 
монтаж  и настройки , издадена  в рамките  на неговото  
управление , заедно  с техните  номера  на версии , както  
е показано  във фигура  2. 
Забележка : Това  означава , че в последната  година  на 
валидност  на даден  сертификат  на ERCA съответните  
карти  за монтаж  и настройки  ще се издават  с три 
различни  поколения  K  M-WC  , както  е показано  във 
фигура  2. 
CSM_116 Във връзка  с процеса , описан  по-горе в CSM_107 и 
CSM_108: съответният  MSCA трябва  да криптира  
всеки  ключ  за сдвояване  K P , получен  от производител  
на датчик  за движение , поотделно  с всяко  валидно  
поколение  главен  ключ  за датчик  за движение  K  M . 
Също  така, MSCA трябва  да криптира  всеки  сериен  
номер , получен  от производител  на датчик  за 
движение , поотделно  с всяко  валидно  поколение  иден­  
тификационен  ключ  K ID . Производителят  на датчика  за 
движение  трябва  да запише  в изработвания  датчик  за 
движение  криптирания  ключ  за сдвояване  и крип­  
тирания  сериен  номер , а също  съответните  стойности  
„в открит  текст “ (plain text values) и номера (та) на 
версията (ите) на K  M и на K  ID ,използвани  за крипти­  
рането . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 398  
Забележка : Това  означава , че в последната  година  на 
валидност  на даден  сертификат  на ERCA датчиците  за 
движение  ще излизат  с криптирани  данни  на базата  на 
три различни  поколения  K  M , както  е показано  във 
фигура  2. 
CSM_117 Във връзка  с процеса , описан  по-горе в CSM_107: тъй 
като дължината  на ключа  за сдвояване  K P трябва  да бъде  
свързана  с дължината  на K M (вж. CSM_100), възможно  е 
производителят  на датчика  за движение  да е необходимо  
да генерира  за един  датчик  за движение  три различни  
ключове  за сдвояване  (с три различни  дължини ), в 
случай  че последващите  поколения  K M са с различна  
дължина . В такъв  случай  производителят  трябва  да 
изпрати  на MSCA всеки  един  от ключовете  за сдвояване . 
Съответният  MSCA трябва  да гарантира , че всеки  ключ  
за сдвояване  е криптиран  с правилното  поколение  
главен  ключ  за датчика  за движение , т.е. с поколението , 
имащо  същата  дължина . 
Забележка : в случай , че производителят  на датчика  за 
движение  избере  да генерира  базиращ  се на TDES ключ  
за сдвояване  на датчик  за движение  от второ  поколение  
(вж. CSM_111), производителят  трябва  да посочи  на 
MSCA, че за криптирането  на този ключ  за сдвояване  
трябва  да се използва  базиращият  се на TDES главен  
ключ  на датчика  за движение . Това  е необходимо  
защото  дължината  на ключ  TDES може  да е същата  
като дължината  на ключ  AES, така че MSCA не може  
да направи  преценка  само  въз основа  на дължината  на 
ключа . 
CSM_118 Производителите  на бордови  устройства  трябва  да 
влагат  във всяко  бордово  устройство  само  едно  
поколение  K M-VU  , заедно  с неговия  номер  на версия . 
Поколението  на този K M-VU  трябва  да бъде  свързано  
със сертификата  на ERCA, на който  се базират  сертифи­  
катите  на бордовото  устройство . 
Забележки : 
— Бордово  устройство , което  се базира  на сертификат  
на ERCA от поколение  X, трябва  да съдържа  само  
K M-VU  от поколение  X, дори  ако издаването  на 
бордовото  устройство  е след  началото  на периода  
на валидност  на сертификат  на ERCA от поколение  
X+1. Това  е показано  на фигура  2. 
— Бордово  устройство  от поколение  X не може  да се 
сдвоява  с датчик  за движение  от поколение  X-1. 
— Тъй като картите  за монтаж  и настройки  имат  период  
на валидност  една  година , в резултат  от изиск­  
ванията  CSM_113 — CSM_118 всички  карти  за 
монтаж  и настройки  ще съдържат  новия  K M-WC  в 
момента  на издаване  на първото  бордово  устройство , 
съдържащо  новия  K  M-VU  . Следователно  такова  
бордово  устройство  винаги  ще може  винаги  да 
изчислява  новия  K M . Също  така, по това време  и 
повечето  нови  датчици  за движение  ще съдържат  
криптирани  данни , базиращи  се на новия  K M . 
9.2.2  Ключове  за обезпечаване  на сигурността  на специализирана  връзка  
с малък  обсег  на действие  (DSRC Communication)  
9.2.2.1  Общи  положения  
CSM_119 Автентичността  и поверителността  на данните , съоб­  
щавани  от бордово  устройство  на контролен  орган  
посредством  канал  за дистанционна  връзка  DSRC 
трябва  да бъдат  обезпечени  посредством  набор  от 
специфични  за бордовото  устройство  AES ключове , 
получени  от един  главен  ключ  за DSRC, KM  DSRC  . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 399  
CSM_120 Главният  ключ  за DSRC KM  DSRC  трябва  да е AES ключ , 
който  да бъде  генериран , съхраняван  и предоставян  от 
ERCA по сигурен  начин . Дължината  на ключа  може  да е 
128, 192 или 256 бита  и трябва  да е свързана  с 
дължината  на европейската  основна  двойка  ключове , 
както  е описано  в CSM_50.  
CSM_121 ERCA трябва  при поискване  да съобщава  главния  ключ  
за DSRC на сертифициращите  органи  на държавите  
членки  по сигурен  начин , така че да им даде  възможност  
да изчисляват  специфичните  за бордовите  устройства  
ключове  за DSRC и да гарантират  влагане  на главния  
ключ  за DSRC във всички  контролни  карти  и карти  за 
монтаж  и настройки , издавани  в рамките  на тяхната  
отговорност . 
CSM_122 Към всеки  главен  ключ  за DSRC ERCA прикрепя  
уникален  номер  на версия . ERCA информира  за 
номера  на версията  сертифициращите  органи  на 
държавите  членки  (MSCAs), когато  им изпраща  
главния  ключ  за DSRC.  
Забележка : Номерът  на версията  се използва  за разгра­  
ничаване  на различните  поколения  на главния  ключ  за 
DSRC, както  е обяснено  подробно  в раздел  9.2.2.2.  
▼M1 
CSM_123 За всяко  бордово  устройство  производителят  на бордови  
устройства  създава  уникален  сериен  номер  VU и 
изпраща  този номер  на своя  сертифициращ  орган  на 
държавата  членка  с искане  да получи  набор  от два 
специфични  за бордово  устройство  ключа  за DSRC. 
Серийният  номер  на бордовото  устройство  трябва  да 
съдържа  типа  данни
  .  
Забележка : 
— Серийният  номер  на бордовото  устройство  трябва  да 
е същият  като елемента  vuSerialNumber от VuIdenti­
fication, вж. допълнение  1, и указанието  за титуляря  
на сертификата  (Certificate Holder Reference) в серти­  
фикатите  на бордовото  устройство . 
— Серийният  номер  на бордовото  устройство  може  още 
да не е известен  към момента , когато  производителят  
на бордовото  устройство  подава  искане  за специ­  
фичните  за бордово  устройство  ключове  за DSRC. 
В този случай  вместо  него  производителят  на 
бордовото  устройство  трябва  да изпрати  уникалния  
идентификатор  на подаденото  от него  искане  за 
сертификатите  на бордовото  устройство ; вж. 
CSM_153. Съответно  идентификаторът  на искането  
за сертификат  трябва  да е същият  като указанието  
за титуляря  на сертификата  (Certificate Holder Refe ­
rence) в сертификатите  на бордовото  устройство . 
▼B 
CSM_124 При получаването  на искане  за специфични  за бордово  
устройство  ключове  DSRC, съответният  MSCA трябва  
да изчисли  два AES ключа  за бордовото  устройство , 
наричани  K_VU  DSRC  _ENC и K_VU  DSRC  _MAC. Тези  
специфични  за бордово  устройство  ключове  трябва  да 
са със същата  дължина  като главния  ключ  за DSRC. 
Съответният  MSCA трябва  да използва  функцията  за 
извеждане  на ключа , дефинирана  в [RFC 5869]. Хеш  
функцията , която  е необходима  за приписване  на 
значение  на кода  HMAC-Hash трябва  да е свързана  с 
дължината  на главния  ключ  за DSRC, както  е описано  
в CSM_50. Функцията  за извеждане  на ключа  съгласно  
[RFC 5869] трябва  да се използва  както  следва : 
Стъпка  1 (Извличане ): 
— PRK  = HMAC-Hash ( salt, IKM ) където  salt  е празен  
низ ‘’ и IKM  е KM  DSRC  . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 400  
Стъпка  2 (Разширение ): 
— OKM  = T(1) , където  
T(1) = HMAC-Hash ( PRK , T(0)  || info  || ‘01’) с 
— T(0)  = празен  низ ( ‘’)  
— ►M1 info  = сериен  номер  на бордовото  
устройство  или идентификатор  на искането  за 
сертификат , както  е специфициран  в CSM_123 ◄ 
— K_VU  DSRC  _ENC = първите  L октета  от OKM  и 
K_VU  DSRC  _MAC = последните  L октета  от OKM  
където  L е изискваната  дължина  на K_VU  DSRC  _ENC 
и K_VU  DSRC  _MAC в октети . 
CSM_125 Съответният  MSCA трябва  по сигурен  начин  да пред­  
остави  K_VU  DSRC  _ENC и K_VU  DSRC  _MAC на произво­  
дителя  на бордови  устройства , за влагане  в бъдещото  
бордово  устройство . 
CSM_126 Когато  бъде  издадено , бордовото  устройство  трябва  да 
има записани  K_VU  DSRC  _ENC и K_VU  DSRC  _MAC в 
неговата  защитена  памет , за да може  да осигурява  
цялостността , автентичността  и поверителността  на 
данните , изпращани  по канала  за дистанционна  връзка . 
В бордовото  устройство  трябва  да е записан  също  и 
номерът  на версията  на главния  ключ  за DSRC, 
използван  за извеждане  на специфичните  за бордовото  
устройство  ключове . 
CSM_127 При издаването  на контролните  карти  и картите  за 
монтаж  и настройки  в тяхната  защитена  памет  трябва  
да е записан  KM  DSRC  , за да могат  да проверяват  цялост­  
ността  и автентичността  на данните , изпратени  от VU по 
канал  за дистанционна  връзка , както  и да могат  да 
декриптират  тези данни . Също  така, в контролните  
карти  и картите  за монтаж  и настройка  трябва  да е 
записан  номерът  на версията  на главния  ключ  за DSRC.  
Забележка : Както  е изяснено  в раздел  9.2.2.2, 
фактически  е възможно  в една  карта  за монтаж  и 
настройки  или контролна  карта  да е необходимо  да 
бъдат  вложени  няколко  поколения  KM  DSRC  . 
▼M1 
CSM_128 Съответният  MSCA трябва  да съхранява  архивни  записи  
за всички  специфични  за бордово  устройство  ключове  за 
DSRC, които  е генерирал , техния  номер  на версия  и 
серийния  номер  на бордовото  устройство  или идентифи­  
катора  на искането  за сертификат , който  е използвал  за 
тяхното  създаване . 
▼B 
9.2.2.2  Замяна  на главен  ключ  за DSRC  
CSM_129 Всеки  главен  ключ  за DSRC е свързан  с конкретно  
поколение  на двойката  основни  ключове  на ERCA. 
Следователно  ERCA трябва  да заменя  главния  ключ  за 
DSRC на всеки  17 години . Периодът  на валидност  на 
всяко  поколение  главен  ключ  за DSRC започва  две 
години  преди  началото  на валидността  на свързаната  с 
него  двойка  основни  ключове  на ERCA и завършва  с 
изтичането  на валидността  на свързаната  с него  двойка  
основни  ключове  на ERCA. Това  е описано  във фигура  3. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 401  
Фигура  3 
Издаване  и използване  на различни  поколения  на главния  ключ  за DSRC в бордови  устройства , карти  за 
монтаж  и настройки  (сервизни  карти ) и контролни  карти
  
CSM_130 Поне  две години  преди  генерирането  на нова  европейска  
двойка  основни  ключове , както  е описано  в CSM_56, 
ERCA генерира  нов главен  ключ  за датчика  за DSRC. 
Дължината  на главния  ключ  за DSRC трябва  да е 
свързана  с предвижданата  сила  на новата  европейска  
двойка  основни  ключове , в съответствие  с CSM_50. 
При поискване  ERCA съобщава  новия  главен  ключ  за 
DSRC на сертифициращите  органи  на държавите  
членки  (MSCAs), заедно  с неговия  номер  на версия . 
CSM_131 Всеки  MSCA трябва  да гарантира , че всички  валидни  
поколения  на KM  DSRC  са записани  във всяка  контролна  
карта , издадена  в рамките  на неговото  управление , 
заедно  с техните  номера  на версии , както  е показано  
във фигура  3. 
Забележка : Това  означава , че в последните  две години  
на валидност  на даден  сертификат  на ERCA съответните  
контролни  карти  ще се издават  с три различни  
поколения  KM  DSRC  , както  е показано  във фигура  3. 
CSM_132 MSCA трябва  да гарантира , че всички  валидни  
поколения  на KM  DSRC  , които  са били  валидни  в 
продължение  на поне  една  година  и продължават  да са 
валидни , са записани  във всяка  карта  за монтаж  и наст­  
ройки , издадена  в рамките  на неговото  управление , 
заедно  с техните  номера  на версии , както  е показано  
във фигура  3. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 402  
Забележка : Това  означава , че в последната  година  на 
валидност  на даден  сертификат  на ERCA съответните  
карти  за монтаж  и настройки  ще се издават  с три 
различни  поколения  KM  DSRC  , както  е показано  във 
фигура  3. 
CSM_133 Производителите  на бордови  устройства  трябва  да 
влагат  във всяко  бордово  устройство  само  един  набор  
от специфични  за бордовото  устройство  ключове  DSRC, 
заедно  с неговия  номер  на версия . Този  набор  от 
ключове  се получава  от KM  DSRC  от поколението , 
свързано  със сертификата  на ERCA, на който  се 
базират  сертификатите  на бордовото  устройство . 
Забележки : 
— Това  означава , че бордово  устройство , което  се 
базира  на сертификат  на ERCA от поколение  X, 
трябва  да съдържа  K_VU  DSRC  _ENC и 
K_VU  DSRC  _MAC от поколение  X, дори  ако изда­  
ването  на бордовото  устройство  е след  началото  на 
периода  на валидност  на сертификат  на ERCA от 
поколение  X+1 . Това  е показано  на фигура  3. 
— Тъй като периодът  на валидност  на картите  за 
монтаж  и настройка  е една  година , а за контролните  
карти  този период  е две години , в резултат  от изиск­  
ванията  CSM_131 — CSM_133 всички  карти  за 
монтаж  и настройки  и всички  контролни  карти  ще 
съдържат  новия  главен  ключ  DSRC в момента  на 
издаване  на първото  бордово  устройство , 
съдържащо  специфичните  за бордово  устройство  
ключове , базиращи  се на този главен  ключ . 
9.3. Сертификати  
9.3.1  Общи  положения  
CSM_134 Всички  сертификати  в Европейската  система  за интели­  
гентни  тахографи  трябва  да бъдат  самоописващи  се и 
проверими  с карта  (CV) сертификати  в съответствие  с 
[ISO 7816-4] и [ISO 7816-8].  
CSM_135  ►M1 За кодиране  на обекти  от данни  в сертификатите  
трябва  да бъдат  използвани  разграничените  правила  за 
кодиране  (DER) съгласно  [ISO 8825-1]. Пълното  
кодиране  на сертификата , в т.ч. всички  байтове  за таг 
и дължина , е показано  в таблица  4. ◄ 
Забележка : Това  кодиране  води  до следната  структура  
Таг-Дължина -Стойност  (TLV):  
Таг: Тагът  се кодира  в един  или два октета  и 
показва  съдържанието . 
Дължина : Дължината  се кодира  като беззнаково  цяло  
число  в един , два или три октета , като в 
резултат  максималната  дължина  е 65 535 
октета . Използва  се минималният  брой  
октети . 
Стойност : Стойността  се кодира  в нула  или повече  
октети . 
9.3.2  Съдържание  на сертификатите  
CSM_136 Всички  сертификати  трябва  да са със структурата , 
показана  в профила  на сертификатите  във таблица  4. 
Таблица  4. 
Профил  на сертификат , версия  1 
Поле  ID на полето  Таг Дължи -на (бай-тове) ASN.1 тип на данните  
(вж. допълнение  1) 
ECC сертификат  C  ‘7F 21’  променлива  
Тяло  на ECC серти­  
фикат  B ‘7F 4E’  променлива  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 403  
Поле  ID на полето  Таг Дължи -на (бай-тове) ASN.1 тип на данните  
(вж. допълнение  1) 
Идентификатор  на 
профила  на серти­  
фиката  CPI ‘5F 29’  ‘01’
  
Референтно  
означение  на серти­  
фициращия  орган  CAR  ‘42’  ‘08’
  
Оторизация  на 
титуляря  на серти­  
фиката  CHA  ‘5F 4C’  ‘07’
  
Публичен  ключ  PK  ‘7F 49’  променлива  
Домейн  параметри  DP  ‘06’  променлива
  
Публична  точка  PP  ‘86’  променлива
  
Референтно  
означение  на 
титуляря  на серти­  
фиката  CHR  ‘5F 20’  ‘08’
  
Дата  на влизане  в 
сила  на сертификата  CEfD  ‘5F 25’  ‘04’
  
Дата  на изтичане  на 
сертификата  CExD  ‘5F 24’  ‘04’
  
Подпис  на ECC 
сертификат  S ‘5F 37’  променлива
  
Забележка : идентификаторите  на полета  се използват  в 
следващи  раздели  на настоящото  приложение  за озна­  
чаване  на отделните  полета  в даден  сертификат , 
например  X.CAR е референтно  означение  на сертифи­  
циращия  орган , посочен  в сертификата  на ползвател  X. 
9.3.2.1 Идентификатор  на профила  на сертификата  
CSM_137 Сертификатите  трябва  да имат  идентификатор  на 
профила  на сертификата , показващ  какъв  е използваният  
профил  на сертификат . Версия  1, посочена  във таблица  
4, се идентифицира  със стойността  ‘00’.  
9.3.2.2 Референтно  означение  на сертифициращия  орган  
CSM_138 Референтното  означение  на сертифициращия  орган  се 
използва  за идентифициране  на публичния  ключ , който  
служи  за проверяване  на подписа  на сертификата . След­  
ователно  референтното  означение  на сертифициращия  
орган  трябва  да е еднакво  с референтното  означение  
на титуляря  на сертификата  на съответния  серти­  
фициращ  орган . 
CSM_139 Всеки  основен  сертификат  на ERCA трябва  да е само­  
подписан , т.е. референтното  означение  на сертифи­  
циращия  орган  и референтното  означение  на титуляря  
на сертификата  в този сертификат  трябва  да са еднакви . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 404  
CSM_140 При свързващ  сертификат  на ERCA референтното  
означение  на титуляря  на сертификата  (CHR) трябва  да 
е еднакво  с CHR на новия  основен  сертификат  на ERCA. 
При свързващ  сертификат  CHR трябва  да е еднакво  с 
CHR на предходния  основен  сертификат  на ERCA.  
9.3.2.3 Оторизация  на титуляря  на сертификата  
▼M1 
CSM_141 Оторизацията  на титуляря  на сертификата  се използва  за 
идентифициране  на типа  на сертификата . Тя се състои  
от шестте  най-старши  байта  от идентификатора  на 
заявката  за тахограф , следвани  от типа  уред , указващ  
за какъв  тип уреди  е предназначен  сертификатът . При 
сертификат  за бордово  устройство , сертификат  за карта  
на водач  или сертификат  за карта  за монтаж  и настройки  
типът  уред  се използва  също  така, за да се направи  
разлика  между  сертификат  за взаимно  удостоверяване  
на автентичността  и сертификат  за създаване  на 
цифрови  подписи  (вж. раздел  9.1 и допълнение  1, тип 
данни  EquipmentType).  
▼B 
9.3.2.4 Публичен  ключ  
В публичния  ключ  са поместени  два елемента  от данни : стандарти­  
зираните  домейн  параметри , използвани  с публичния  ключ  в серти­  
фиката  и стойността  на публичната  точка . 
CSM_142 Елементът  от данни  „домейн  параметри “ трябва  да 
съдържа  един  от идентификаторите  на обекти , специфи­  
цирани  в таблица  1 за означаване  на набор  от стандар­  
тизирани  домейн  параметри . 
CSM_143 Елементът  от данни  „публична  точка “ трябва  да съдържа  
публичната  точка . Публичните  точки  от елиптичната  
крива  трябва  да се преобразуват  в октетни  низове  
както  е специфицирано  в [TR-03111]. Трябва  да се 
използва  некомпресираният  формат  за кодиране . При 
възстановяването  на точка  от елиптичната  крива  от 
нейния  кодиран  формат  винаги  трябва  да се извършват  
валидиранията , описани  в [TR-03111].  
9.3.2.5 Референтно  означение  на титуляря  на сертификата  
CSM_144 Референтното  означение  на титуляря  на сертификата  е 
идентификатор  за публичния  ключ , даден  в сертификата . 
То трябва  да се използва  за означаване  на този публичен  
ключ  в други  сертификати . 
CSM_145 В картовите  сертификати  и сертификатите  за външни  
GNSS устройства , референтното  означение  на титуляря  
на сертификата  трябва  да е с тип на данните
  
, специфициран  в 
допълнение  1. 
CSM_146 При бордовите  устройства , когато  производителят  
отправя  искане  за сертификат  е възможно  той да знае 
или да не знае специфичния  сериен  номер  на бордовото  
устройство , за което  е предназначен  този сертификат  и 
свързания  с него  частен  ключ . В първия  случай  рефе­  
рентното  означение  на титуляря  на сертификата  трябва  
да е с тип на данните
  , 
специфициран  в допълнение  1. Във втория  случай  рефе­  
рентното  означение  на титуляря  на сертификата  трябва  
да е с тип на данните
  , 
специфициран  в допълнение  1. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 405  
Забележка : При сертификат  на карта  стойността  на CHR 
трябва  да бъде  равна  на стойността  на cardExtendedSeri ­
alNumber в EF_ICC; вж. допълнение  2. При сертификат  
на EGF стойността  на CHR трябва  да бъде  равна  на 
стойността  на sensorGNSSSerialNumber в EF_ICC; вж. 
допълнение  14. При сертификат  на бордово  устройство  
стойността  на CHR трябва  да бъде  равна  на елемента  
vuSerialNumber от VuIdentification, вж. допълнение  1, 
освен  ако към момента , когато  подава  искане  за серти­  
фикат , производителят  не знае специфичния  за него  
сериен  номер . 
▼B 
CSM_147 При сертификатите  на ERCA и MSCA референтното  
означение  на титуляря  на сертификата  трябва  да е с 
тип на данните
  , 
специфициран  в допълнение  1. 
9.3.2.6 Дата  на влизане  в сила  на сертификат  
▼M1 
CSM_148 Датата  на влизане  в сила  на сертификата  показва  
началната  дата и час на срока  на валидност  на серти­  
фиката . 
▼B 
9.3.2.7 Дата  на изтичане  на сертификата  
CSM_149 Датата  на изтичане  на сертификата  показва  крайната  
дата и час на периода  на валидност  на сертификата . 
9.3.2.8 Подпис  върху  сертификат  
CSM_150 Подписът  върху  сертификата  се създава  върху  коди­  
раното  тяло  на сертификата , включително  с тага и 
дължината  на тялото  на сертификата . Алгоритъмът  за 
подписа  трябва  да бъде  ECDSA, както  е специфициран  
в [DSS], с използване  на алгоритъма  за хеширане , 
свързан  с размера  на ключа  на подписващия  орган , 
както  е специфицирано  в CSM_50. Форматът  на 
подписа  трябва  да бъде  открит  (plain), както  е специфи­  
цирано  в [TR-03111].  
9.3.3  Поискване  на сертификати  
CSM_151  ►M1 При поискване  на сертификат  MSCA трябва  да 
изпрати  на ERCA следните  данни : ◄ 
— Идентификатора  на профила  на искания  сертификат  
— Референтното  означение  на сертифициращия  орган , 
за което  се очаква  да бъде  използвано  за подписване  
на сертификата . 
— Публичния  ключ , който  да бъде  подписан  
CSM_152 В допълнение  към данните  в CSM_151, когато  
заявителят  е MSCA, той трябва  да изпрати  следните  
данни  в искане  за сертификат  до ERCA, които  да 
дадат  възможност  на ERCA да създаде  референтното  
означение  на титуляря  на сертификата  на новия  
сертификат  на MSCA:  
— Цифровия  национален  код на сертифициращия  орган  
(тип на данните
  , дефиниран  в 
допълнение  1) 
— Буквено -цифровия  национален  код на сертифи­  
циращия  орган  (тип на данните
  , 
дефиниран  в допълнение  1) 
— 1-байтовия  сериен  номер  за разграничаване  на 
различните  ключове  на сертифициращия  орган , в 
случай  че ключовете  са сменени  
— Двубайтовото  поле , съдържащо  специфична  допъл­  
нителна  информация  на сертифициращия  орган  ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 406  
CSM_153 Производител  на оборудване  изпраща  следните  данни  в 
искане  за сертификат  до MSCA, които  да дадат  
възможност  на MSCA да създаде  указанието  на 
титуляря  на новия  сертификат  на оборудване : 
— сериен  номер  на оборудването , ако е известен  (вж. 
CSM_154), който  да е уникален  за производителя , 
типа  на оборудването  и месеца  на производство . В 
противен  случай , уникален  идентификатор  на 
искането  за сертификат , 
— месеца  и годината  на производство  на оборудването  
или на искането  за сертификат . 
Производителят  гарантира , че тези данни  са правилни  и че полу­  
ченият  от MSCA сертификат  е вложен  в оборудването , за което  е 
предназначен . 
▼B 
CSM_154 В случай  на бордово  устройство , когато  производителят  
отправя  искане  за сертификат , е възможно  той да знае 
или да не знае специфичния  сериен  номер  на бордовото  
устройство , за което  е предназначен  този сертификат  и 
свързания  с него  частен  ключ . Ако серийният  номер  е 
известен , производителят  на бордовото  устройство  
трябва  да го изпрати  на MSCA. Ако този номер  не е 
известен , производителят  трябва  уникално  да иденти­  
фицира  всяко  искане  за сертификат  и да изпрати  на 
MSCA серийния  номер  на съответното  искане  за серти­  
фикат . В такъв  случай  полученият  в резултат  сертификат  
ще съдържа  серийния  номер  на искането  за сертификат . 
След  влагането  на сертификата  в конкретното  бордово  
устройство , производителят  трябва  да съобщи  на MSCA 
връзката  между  серийния  номер  на искането  за 
сертификат  и идентификацията  на бордовото  
устройство . 
10. ВЗАИМНО  УДОСТОВЕРЯВАНЕ  НА АВТЕНТИЧНОСТТА  И 
ЗАЩИТЕН  ОБМЕН  НА СЪОБЩЕНИЯ  БОРДОВО  УСТРОЙСТВО  
— КАРТА  
10.1.  Общи  положения  
CSM_155 При високо  равнище  на сигурност , защитената  връзка  
между  бордово  устройство  и тахографска  карта  трябва  
да се базира  на следните  стъпки : 
— Първо , всяка  страна  трябва  да демонстрира  на 
другата , че притежава  валиден  сертификат  за 
публичен  ключ , подписан  от сертифициращ  орган  
на държава  членка  (MSCA). На свой  ред, серти­  
фикатът  за публичен  ключ  на MSCA трябва  да е 
подписан  от европейския  орган  за основни  серти­  
фикати  (ERCA). Тази  стъпка  се нарича  проверка  на 
веригата  на сертифициране  и е подробно  специфи­  
цирана  в раздел  10.2.  
— Второ , бордовото  устройство  трябва  да демонстрира  
на картата , че притежава  частния  ключ , съответстващ  
на публичния  ключ  в представения  сертификат . То 
прави  това чрез подписване  на случайно  число , 
изпратено  на картата . Картата  проверява  подписа  
върху  случайното  число . Ако тази проверка  е 
успешна , бордовото  устройство  е автентифицирано . 
Тази  стъпка  се нарича  удостоверяване  на автентич­  
ността  на бордовото  устройство  и е подробно  специ­  
фицирана  в раздел  10.3.  ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 407  
— Трето , и двете  страни  независимо  изчисляват  два 
AES сесийни  ключа , като използват  асиметричен  
алгоритъм  за договаряне  на ключове . Като  използва  
един  от тези сесийни  ключове , картата  създава  код за 
автентифициране  на съобщение  (MAC) върху  данни , 
изпратени  от бордовото  устройство . Бордовото  
устройство  проверява  този MAC. Ако проверката  е 
успешна , картата  е автентифицирана . Тази  стъпка  се 
нарича  удостоверяване  на автентичността  на карта  и 
е подробно  специфицирана  в раздел  10.4.  
— Четвърто , бордовото  устройство  и картата  трябва  да 
използват  договорените  сесийни  ключове  за осигу­  
ряване  на поверителността , цялостността  и автентич­  
ността  на всички  обменени  съобщения . Това  се 
нарича  защитен  обмен  на съобщения  и е подробно  
специфицирано  в раздел  10.5.  
CSM_156 Описаният  в CSM_155 механизъм  трябва  да бъде  
задействан  от бордовото  устройство  винаги  когато  
бъде  вкарана  карта  в едно  от неговите  четящи  
устройства . 
10.2.  Взаимна  проверка  на веригата  на сертифициране  
10.2.1  Проверка  от бордовото  устройство  на веригата  на сертифи­  
циране  на картата  
CSM_157  ►M1 За проверяване  на веригата  на сертифициране  на 
тахографска  карта  бордовите  устройства  трябва  да 
използват  протокола , описан  във фигура  4. За всеки  
сертификат , който  чете от картата , бордовото  устройство  
трябва  да провери  дали  полето  за оторизация  на 
титуляра  на картата  (Certificate Holder Authorisation — 
CHA) е правилно : 
— Полето  CHA в сертификата  на картата  трябва  да 
указва  сертификат  на карта  за взаимно  удостове­  
ряване  на автентичността  (вж. допълнение  1, тип 
данни  EquipmentType);  
— CHA в сертификат  Card.CA трябва  да указва  MSCA;  
— CHA в сертификат  Card.Link трябва  да указва  
ERCA. ◄ 
Забележки  към фигура  4: 
— Посочените  във фигурата  сертификати  и публични  
ключове  Card са тези, които  се използват  за 
взаимно  удостоверяване  на автентичността . В 
раздел  9.1.5 те са означени  като Card_MA.  
— Упоменатите  във фигурата  сертификати  и публични  
ключове  Card.CA са тези, които  се използват  за 
подписване  на картови  сертификати  и се посочват  в 
референтното  означение  на сертифициращия  орган  
(CAR) на сертификатите  Card. В раздел  9.1.3 те са 
означени  като MSCA_Card.  
— Упоменатият  във фигурата  сертификат  Card.CA.EUR 
е европейският  основен  сертификат , който  е посочен  
в референтното  означение  на сертифициращия  орган  
(CAR) на сертификата  Card.CA.  
— Упоменатият  във фигурата  сертификат  Card.Link е 
свързващият  сертификат  на картата , ако има такъв . 
Както  е посочено  в раздел  9.1.2, това е свързващ  
сертификат  за нова  европейска  двойка  основни  
ключове , създадена  от ERCA и подписана  с пред­  
ходния  европейски  частен  ключ . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 408  
— Сертификатът  Card.Link.EUR е европейският  основен  
сертификат , който  е посочен  в референтното  
означение  на сертифициращия  орган  (CAR) на серти­  
фиката  Card.Link.  
CSM_158 Както  е описано  във фигура  4, проверката  на веригата  
на сертифициране  на картата  започва  с вкарването  на 
картата . Бордовото  устройство  трябва  да прочете  рефе­  
рентното  означение  на титуляря  на картата  
(
 ) от EF ICC. 
Бордовото  устройство  трябва  да провери  дали  познава  
картата , т.е. дали  в миналото  успешно  е проверявало  
веригата  на сертифициране  на картата  и я е записало  
за бъдещи  справки . Ако това е така и ако сертификатът  
на картата  продължава  да е валиден , процесът  
продължава  с проверка  на веригата  на сертифициране  
на бордовото  устройство . В противен  случай  
бордовото  устройство  трябва  последователно  да 
прочете  от картата  сертификата  MSCA_Card, който  да 
се използва  за проверка  на картовия  сертификат , 
Card.CA.EUR, който  да се използва  за проверка  на 
сертификата  MSCA_Card и евентуално  свързващия  
сертификат , докато  намери  сертификат , който  познава  
или може  да провери . Ако такъв  сертификат  бъде  
намерен , бордовото  устройство  трябва  да го използва  
за да провери  съответните  картови  сертификати , които  
то е прочело  от картата . Ако проверката  на картата  е 
успешна , процесът  продължава  с проверяване  на 
веригата  на сертифициране  на бордовото  устройство . 
Ако проверката  на картата  не е успешна , бордовото  
устройство  трябва  да я игнорира . 
Забележка : Има три начина , по които  бордовото  
устройство  може  да познава  сертификата  Card.CA.EUR:  
— сертификатът  Card.CA.EUR е същият  като 
собствения  сертификат  EUR на бордовото  
устройство ; 
— сертификатът  Card.CA.EUR предхожда  собствения  
сертификат  EUR на бордовото  устройство  и 
бордовото  устройство  вече е имало  този сертификат  
при своето  издаване  (вж. CSM_81);  
— сертификатът  Card.CA.EUR е следващ  сертификат  
след  собствения  сертификат  EUR на бордовото  
устройство  и в миналото  бордовото  устройство  е 
получило  свързващ  сертификат  от друга  тахографска  
карта , проверило  го е и го е съхранило  за бъдещи  
справки . 
CSM_159 Както  е посочено  във фигура  4, след  като веднъж  
бордовото  устройство  удостовери  автентичността  и 
валидността  на непознат  по-рано  сертификат , то може  
да съхрани  този сертификат  за бъдещи  справки , така 
че да не е необходимо  пак да проверява  автентичността  
му ако този сертификат  му бъде  представен  отново . 
Вместо  да съхранява  целия  сертификат , бордовото  
устройство  може  да избере  да съхранява  само  тялото  
на сертификата , както  е специфицирано  в 9.3.2.  
►M1 Въпреки  че съхранението  на всички  други  
видове  сертификати  не е задължително , бордовото  
устройство  задължително  съхранява  нов свързващ  серти­  
фикат , представен  от картата . ◄ 
CSM_160 Бордовото  устройство  трябва  да проверява  валидността  
във времето  на всеки  прочетен  в карта  или съхранен  в 
паметта  му сертификат  и трябва  да отхвърля  изтеклите  
сертификати . За проверяването  на валидността  във 
времето  на представен  от карта  сертификат  бордовото  
устройство  трябва  да използва  своя  вътрешен  часовник . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 409  
Фигура  4 
Протокол  за проверка  от бордово  устройство  на веригата  на сертифициране  на карта
  
10.2.2  Проверка  от карта  на веригата  на сертифициране  на бордово  
устройство  
CSM_161  ►M1 За проверяване  на веригата  на сертифициране  на 
бордово  устройство  тахографските  карти  трябва  да 
използват  протокола , описан  във фигура  5. За всеки  
сертификат , представен  от бордовото  устройство , 
картата  трябва  да провери  дали  полето  за оторизация  
на титуляра  на картата  (Card Holder Authorisation — 
CHA) е правилно : 
— CHA в сертификат  VU.Link трябва  да указва  ERCA.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 410  
— CHA в сертификат  VU.CA трябва  да указва  MSCA.  
— Полето  CHA в сертификата  на бордовото  устройство  
трябва  да указва  сертификат  на бордово  устройство  
за взаимно  удостоверяване  на автентичността  (вж. 
допълнение  1, тип данни  EquipmentType). ◄ 
Фигура  5 
Протокол  за проверка  от карта  на веригата  на сертифициране  на бордово  устройство
  
Забележки  към фигура  5: 
— Посочените  във фигурата  сертификати  и публични  ключове  VU 
са тези, които  се използват  за взаимно  удостоверяване  на автен­  
тичността . В раздел  9.1.4 те са означени  като VU_MA.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 411  
— Посочените  във фигурата  сертификати  и публични  ключове  
VU.CA са тези, които  се използват  за подписване  на сертификати  
на бордови  устройства  и на външни  устройства  за GNSS. В 
раздел  9.1.3 те са означени  като MSCA_VU-EGF.  
— Упоменатият  във фигурата  сертификат  VU.CA.EUR е евро­  
пейският  основен  сертификат , който  е посочен  в референтното  
означение  на сертифициращия  орган  (CAR) на сертификата  
VU.CA.  
— Посоченият  във фигурата  сертификат  VU.Link е свързващият  
сертификат  на бордовото  устройство , ако има такъв . Както  е 
посочено  в 9.1.2, това е свързващ  сертификат  за нова  европейска  
двойка  основни  ключове , създадена  от ERCA и подписана  с 
предходния  европейски  частен  ключ . 
— Сертификатът  VU.Link.EUR е европейският  основен  сертификат , 
който  е посочен  в референтното  означение  на сертифициращия  
орган  (CAR) на сертификата  VU.Link.  
CSM_162 Както  е описано  във фигура  5, проверката  на веригата  
на сертифициране  на бордовото  устройство  започва  с 
опит  на бордовото  устройство  да зададе  своя  собствен  
публичен  ключ  за използване  в тахографската  карта . 
Ако този опит  е успешен , това означава  че в миналото  
тахографската  карта  успешно  е проверила  веригата  на 
сертифициране  на бордовото  устройство  и е съхранила  
сертификата  на бордовото  устройство  за бъдещи  
справки . В такъв  случай  сертификатът  на бордовото  
устройство  е зададен  за употреба  и процесът  
продължава  с удостоверяване  на автентичността  на 
бордовото  устройство . Ако картата  не разпознава  серти­  
фиката  на бордовото  устройство , за да се стигне  до 
познат  или проверим  от картата  сертификат , то трябва  
да представи  последователно  сертификата  VU.СА за 
проверка  на неговия  сертификат , сертификата  
VU.CA.EUR за проверка  на сертификата  VU.СА и евен­  
туално  и свързващия  сертификат , за да намери  картата  
познат  или проверим  от нея сертификат . Ако такъв  
сертификат  бъде  намерен , картата  трябва  да го 
използва  за да провери  съответните  сертификати  на 
VU, които  са ѝ представени . Ако проверката  е 
успешна , бордовото  устройство  накрая  задава  своя  
публичен  ключ  за употреба  в тахографската  карта . 
Ако проверката  не е успешна , бордовото  устройство  
трябва  да игнорира  картата . 
Забележка : Има три начина , по които  картата  може  
да познава  сертификата  VU.CA.EUR:  
— сертификатът  VU.CA.EUR е същият  като собствения  
сертификат  EUR на картата ; 
— Сертификатът  VU.CA.EUR предхожда  собствения  
сертификат  EUR на картата  и картата  вече е имала  
този сертификат  при своето  издаване  (вж. CSM_91);  
— Сертификатът  VU.CA.EUR е следващ  сертификат  
след  собствения  сертификат  EUR на картата  и в 
миналото  картата  е получила  свързващ  сертификат  
от друго  бордово  устройство , проверила  го е и го 
е съхранила  за бъдещи  справки . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 412  
CSM_163 Бордовото  устройство  трябва  да използва  командата  
MSE: SET AT за да зададе  своя  публичен  ключ  за 
употреба  в тахографската  карта . Както  е специфицирано  
в допълнение  2, тази команда  съдържа  индикация  за 
криптографския  механизъм , който  ще бъде  използван  
със задавания  ключ . Този  механизъм  трябва  да бъде  
„Автентифициране  на бордово  устройство  с използване  
на алгоритъма  ECDSA, в комбинация  с алгоритъма  за 
хеширане , съответстващ  на размера  на ключовете  в 
двойката  ключове  VU_MA на бордовото  устройство , 
както  е специфицирано  в CSM_50“.  
CSM_164 Командата  MSE: Set AT съдържа  също  индикация  за 
двойката  краткотрайни  ключове  (ephemeral key pair), 
която  бордовото  устройство  ще използва  при догова­  
рянето  на сесиен  ключ  (вж. раздел  10.4). Следователно , 
преди  да изпрати  командата  MSE: Set AT, бордовото  
устройство  трябва  да генерира  двойка  краткотрайни  
ключове  за ECC. За генерирането  на двойката  крат­  
котрайни  ключове  бордовото  устройство  трябва  да 
използва  стандартизираните  домейн  параметри , 
посочени  в сертификата  на картата . Двойката  крат­  
котрайни  ключове  се означава  по следния  начин : 
(VU.SK  eph , VU.PK  eph , Card.DP). Като  идентификация  
на ключа  бордовото  устройство  взема  координатата  x 
на кратковременната  публична  точка  в ECDH; това се 
нарича  компресирано  представяне  на публичния  ключ  и 
се означава  като Comp(VU.PK  eph ). 
▼M1 
CSM_165 Ако командата  MSE: Set AT бъде  изпълнена  успешно , 
картата  трябва  да зададе  посочения  VU.PK за 
последваща  употреба  при удостоверяване  на автентич­  
ността  на бордовото  устройство  и временно  да съхрани  
Comp(VU.PKeph). Ако бъдат  изпратени  две или повече  
успешни  команди  MSE: Set AT, преди  да е направено  
договаряне  на сесиен  ключ , картата  трябва  да съхрани  
само  последното  получено  Comp(VU.PKeph). След  
успешна  команда  GENERAL AUTHENTICATE картата  
трябва  да инициализира  Comp(VU.PKeph).  
▼B 
CSM_166 Картата  трябва  да проверява  валидността  във времето  
на всеки  представен  от бордовото  устройство  
сертификат  или посочен  от бордовото  устройство  
съхраняван  в паметта  на картата  сертификат , и трябва  
да отхвърля  изтеклите  сертификати . 
CSM_167 За целите  на проверяването  на валидността  във времето  
на представен  от бордовото  устройство  сертификат , 
всяка  тахографска  карта  трябва  вътрешно  да съхранява  
данни , изразяващи  текущото  време . Тези  данни  трябва  
да не могат  да бъдат  директно  актуализирани  от 
бордово  устройство . При нейното  издаване  текущото  
време  на дадена  карта  трябва  да бъде  зададено  да 
съвпада  с датата  на влизане  в сила  на сертификата  
Card_MA на картата . Ако датата  на влизане  в сила  на 
представен  от дадено  бордово  устройство  автентичен  
сертификат , представляващ  „валиден  източник  на 
данни  за времето “, е по-скорошна  в сравнение  с 
текущото  време  на картата , тя трябва  да актуализира  
своето  текущо  време . В такъв  случай  картата  трябва  
да настрои  своето  текущо  време  да съвпада  с датата  
на влизане  в сила  на този сертификат . Като  валиден  
източник  на данни  за времето  картата  трябва  да 
възприема  само  следните  сертификати : 
— Свързващи  сертификати  на ERCA от второ  
поколение  
— Сертификати  на MSCA от второ  поколение  
— Сертификати  на бордово  устройство  от второ  поко­  
ление , издадени  от същата  държава  като собствения  
сертификат  (собствените  сертификати ) на картата . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 413  
Забележка : Последното  изискване  означава , че картата  
трябва  да може  да разпознае  референтното  означение  на 
сертифициращия  орган  (CAR) на сертификата  на 
бордовото  устройство , т.е. на сертификата  MSCA_VU- 
EGF. То няма  да е същото  като CAR на нейния  собствен  
сертификат , който  е сертификат  MSCA_Card.  
CSM_168 Както  е посочено  във фигура  5, след  като веднъж  
картата  удостовери  автентичността  и валидността  на 
непознат  по-рано  сертификат , тя може  да съхрани  този 
сертификат  за бъдещи  справки , така че да не е необ­  
ходимо  пак да проверява  автентичността  му ако този 
сертификат  ѝ бъде  представен  отново . Вместо  да 
съхранява  целия  сертификат , картата  може  да избере  
да съхранява  само  тялото  на сертификата , както  е 
специфицирано  в 9.3.2.  
10.3.  Удостоверяване  на автентичността  на бордово  устройство  
CSM_169 За удостоверяване  на автентичността  на бордово  
устройство  по отношение  на карта , бордовите  
устройства  и картите  трябва  да използват  протокола  
VU Authentication, описан  във фигура  6. Протоколът  
VU Authentication дава възможност  на тахографската  
карта  експлицитно  да провери , че бордовото  устройство  
е автентично . За целта  бордовото  устройство  трябва  да 
използва  своя  частен  ключ  за да подпише  генерирано  от 
картата  случайно  число  (challenge).  
CSM_170  ►M1 Непосредствено  след  изпратеното  от картата  
случайно  число  бордовото  устройство  включва  в 
подписа  указанието  за титуляря  на сертификата , взето  
от сертификата  на картата . ◄ 
Забележка : Така  се гарантира , че картата  спрямо  която  
се автентифицира  бордовото  устройство , е същата  
карта , чиято  верига  на сертифициране  то е проверило  
преди  това. 
CSM_171 Бордовото  устройство  трябва  да включи  също  в подписа  
идентификатора  на краткотрайния  (ephemeral) публичен  
ключ  Comp(VU.PK  eph ), който  бордовото  устройство  ще 
използва  за защитен  обмен  на съобщения  по време  на 
процеса  на удостоверяване  на автентичността  на чипа , 
специфициран  в раздел  10.4.  
Забележка : Това  гарантира , че бордовото  устройство , с 
което  комуникира  дадена  карта  по време  на сесия  на 
защитен  обмен  на съобщения , е същото  бордово  
устройство , което  е било  автентифицирано  от картата . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 414  
Фигура  6 
Протокол  за удостоверяване  на автентичността  на бордово  устройство
  
▼B 
CSM_172 Ако по време  на процеса  на автентифициране  на 
бордовото  устройство  то изпрати  няколко  команди  
GET CHALLENGE, картата  трябва  всеки  път да връща  
ново  8-байтово  случайно  число , но трябва  да съхранява  
само  последното  случайно  число . 
CSM_173 Използваният  от бордовото  устройство  алгоритъм  за 
подписване  при автентифицирането  на бордовото  
устройство  трябва  да бъде  ECDSA, както  е специ­  
фициран  в [DSS], с използване  на алгоритъма  за 
хеширане , свързан  с размера  на двойката  ключове  на 
бордовото  устройство  VU_MA, както  е специфицирано  
в CSM_50. Форматът  на подписа  трябва  да бъде  открит  
(plain), както  е специфицирано  в [TR-03111]. Бордовото  
устройство  трябва  да изпрати  така получения  подпис  на 
картата . 
▼M1 
CSM_174 При получаване  на подписа  на бордовото  устройство  в 
команда  EXTERNAL AUTHENTICATE картата  трябва  
да изпълни  следните  операции : 
— Да изчисли  удостоверяващия  автентичността  маркер  
(authentication token) чрез конкатенация  на 
Card.CHR, случайно  число  от картата  rcard и иден­  
тификатора  на краткотрайния  публичен  ключ  на 
бордовото  устройство  Comp(VU.PKeph),  
— Да провери  подписа  на бордовото  устройство , като 
използва  алгоритъма  ECDSA и алгоритъма  за 
хеширане , съответстващ  на размера  на ключовете  в 
двойката  ключове  VU_MA на бордовото  устройство , 
както  е специфицирано  в CSM_50, в комбинация  с 
VU.PK и изчисления  удостоверяващ  автентичността  
маркер . ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 415  
10.4.  Удостоверяване  на автентичността  на чипа  и договаряне  на 
ключ  за сесията  
CSM_175 За удостоверяване  на автентичността  на картата  по 
отношение  на бордовото  устройство , бордовите  
устройства  и картите  трябва  да използват  протокола  Chip 
Authentication, описан  във фигура  7. Протоколът  Chip 
Authentication дава възможност  на бордовото  устройство  
експлицитно  да провери , че картата  е автентична . 
Фигура  7 
Удостоверяване  на автентичността  на чипа  и договаряне  на ключ  за сесията
  
CSM_176 Бордовото  устройство  и картата  трябва  да изпълнят  
следните  стъпки : 
1. Бордовото  устройство  инициира  процеса  на удостове­  
ряване  на автентичността  на чипа  като изпраща  
командата  MSE: Set AT с индикация  „Удостоверяване  
на автентичността  на чип с използване  на алгоритъм  
ECDH, водещ  до дължина  на сесийния  ключ  AES, 
която  е свързана  с размера  на ключовете  в двойката  
ключове  на картата  Card_MA, както  е специфицирано  
в CSM_50“. Бордовото  устройство  трябва  да определи  
размера  на ключовете  в двойката  ключове  на картата  
от картовия  сертификат . 
▼M1 
2. Бордовото  устройство  изпраща  на картата  публичната  
точка  VU.PK  eph от своята  двойка  краткотрайни  
ключове . Публичната  точка  трябва  да се преобразува  
в октетен  низ, както  е специфицирано  в [TR-03111]. 
Трябва  да се използва  некомпресираният  формат  за 
кодиране . Както  е изяснено  в CSM_164, бордовото  
устройство  е генерирало  тази двойка  краткотрайни  
ключове  преди  проверката  на неговата  верига  на 
сертифициране . Бордовото  устройство  е изпратило  
до картата  идентификатора  на краткотрайния  
публичен  ключ  Comp(VU.PKeph) и картата  го е съхра­  
нила . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 416  
3. Картата  изчислява  Comp(VU.PK  eph ) от VU.PK  eph и 
сравнява  така получената  стойност  със съхранената  
стойност  на Comp(VU.PK  eph ). 
4. Като  използва  алгоритъма  ECDH в комбинация  със 
своя  статичен  частен  ключ  и с краткотрайния  
публичен  ключ  на бордовото  устройство , картата  
изчислява  секретна  стойност  К. 
5. После  картата  избира  случаен  8-байтов  еднократен  
код (nonce) N и го използва  за да получи  от К два 
сесийни  ключа  AES — K  MAC и K ENC . Вж. CSM_179.  
▼M1 
6. Използвайки  K MAC , картата  изчислява  удостоверяващ  
автентичността  маркер  върху  кратковременния  
публичен  ключ  на бордовото  устройство : T  PICC = 
CMAC(K  MAC , VU.PK  eph ). Публичната  точка  трябва  
да бъде  в използвания  от бордовото  устройство  
формат  (вж. подточка  2 по-горе). Картата  изпраща  
на бордовото  устройство  N PICC и T PICC . 
▼B 
7. Като  използва  алгоритъма  ECDH в комбинация  със 
статичния  публичен  ключ  на картата  и със своя  крат­  
котраен  частен  ключ , бордовото  устройство  
изчислява  същата  секретна  стойност  К, която  е 
изчислена  от картата  в стъпка  4. 
8. Въз основа  на K и N  PICC бордовото  устройство  
извежда  сесийните  ключове  K  MAC и K  ENC ; вж. 
CSM_179.  
9. Бордовото  устройство  проверява  автентифика­  
ционния  маркер  T PICC . 
CSM_177 В по-горната  стъпка  3 картата  трябва  да изчисли  
Comp(VU.PKeph) като стойност  на координатата  х на 
публичната  точка  във VU.PKeph.  
CSM_178 В по-горните  стъпки  4 и 7 картата  и бордовото  
устройство  трябва  да използват  алгоритъма  ECKA-EG, 
както  е дефиниран  в [TR-03111].  
CSM_179 В по-горните  стъпки  5 и 8 картата  и бордовото  
устройство  трябва  да използват  за определяне  на 
сесийните  ключове  AES функцията  за извеждане  на 
ключове , дефинирана  в [TR-03111], със следните  
уточнения  и промени : 
— Стойността  на брояча  трябва  да бъде  ‘00 00 00 01’ за 
K ENC и ‘00 00 00 02’ за K MAC.  
— Трябва  да се използва  опционният  еднократен  код r, 
чиято  стойност  трябва  да е равна  на N PICC. 
— За извеждането  на 128-битови  ключове  AES изпол­  
званият  алгоритъм  за хеширане  трябва  да е SHA- 
256. 
— За извеждането  на 192-битови  ключове  AES изпол­  
званият  алгоритъм  за хеширане  трябва  да е SHA- 
384. 
— За извеждането  на 256-битови  ключове  AES изпол­  
званият  алгоритъм  за хеширане  трябва  да е SHA- 
512. 
Дължината  на сесийните  ключове  (т.е. дължината , при 
която  се отрязва  хеша ) трябва  да е свързана  с размера  
на двойката  ключове  Card_MA, както  е специфициран  в 
CSM_50.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 417  
CSM_180 В по-горните  стъпки  6 и 9 картата  и бордовото  
устройство  трябва  да използват  алгоритъма  AES в 
режим  CMAC, както  е специфицирано  в [SP 800-38B]. 
Дължината  на T PICC трябва  да е свързана  с дължината  
на сесийните  ключове  AES, както  е специфицирано  в 
CSM_50.  
10.5.  Защитен  обмен  на съобщения  
10.5.1  Общи  положения  
CSM_181 Всички  команди  и отговори , които  се разменят  между  
бордово  устройство  и тахографска  карта  след  успешно  
проведено  удостоверяване  на автентичността  на чипа  до 
края  на сесията  трябва  да бъдат  защитени  чрез защитен  
обмен  на съобщения . 
CSM_182 Освен  в случай  на четене  на файл  с условие  за достъп  
SM-R-ENC-MAC-G2 ( вж. допълнение  2, раздел  4), защи­  
теният  обмен  на съобщения  трябва  да се използва  в 
режим  „само  с удостоверяване “. В този режим  към 
всички  команди  и отговори  се добавя  криптографска  
контролна  сума  (наричана  също  MAC) за осигуряване  
на автентичността  и цялостността  на съобщенията . 
CSM_183 При четенето  на данни  от файл  с условие  за достъп  SM- 
R-ENC-MAC-G2, защитеният  обмен  на съобщения  
трябва  да се използва  в режим  „криптиране  с 
последващо  автентифициране “, т.е. данните  в 
отговорите  първо  се криптират  за осигуряване  на пове­  
рителност  на съобщението  и после  върху  формати­  
раните  криптирани  данни  се изчислява  MAC за осигу­  
ряване  на автентичност  и цялостност . 
CSM_184 За защитеният  обмен  на съобщения  трябва  да се 
използва  AES, както  е дефиниран  в [AES], със 
сесийните  ключове  K MAC и K ENC , които  са договорени  
при удостоверяването  на автентичността  на чипа . 
CSM_185 С цел предотвратяване  на атаки  с повторно  възпро­  
извеждане  (replay attacks) трябва  да се използва  
беззнаково  цяло  число  в качеството  на брояч  на изпра­  
тените  поредици  (SSC). Размерът  на SSC трябва  да бъде  
равен  на размера  на AES блок , т.е. 128 бита . Форматът  
на SSC трябва  да е с най-старшия  бит на първо  място  
(MSB-first format). При стартирането  на защитения  
обмен  на съобщения  броячът  на изпратените  поредици  
трябва  да бъде  инициализиран  с нулева  стойност  (т.е. 
‘00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00’). 
Стойността  на SSC трябва  да нараства  всеки  път преди  
генерирането  на командна  или ответна  APDU, т.е. след  
като началната  стойност  на SSC при сесия  на защитен  
обмен  на съобщения  е 0, при първата  команда  стой­  
ността  на SSC ще е 1. След  това при първия  отговор  
стойността  на SSC ще е 2. 
CSM_186 За криптиране  на съобщенията  трябва  да се използва  
K ENC с AES в работен  режим  на свързване  на блокове  
от шифровани  данни  (CBC), както  е дефиниран  в [ISO 
10116], с параметър  на редуване  (interleave parameter)  m 
= 1 и инициализиращ  вектор  SV = E(K  ENC , SSC), т.е. 
текущата  стойност  на брояча  на изпратените  поредици , 
криптирана  с K ENC . 
CSM_187 За автентифициране  на съобщенията  трябва  да се 
използва  K MAC с AES в работен  режим  CMAC, както  
е специфициран  в [SP 800-38B]. Дължината  на МАС  
трябва  да е свързана  с дължината  на сесийните  
ключове  AES, както  е специфицирано  в CSM_50. 
Броячът  на изпратените  поредици  трябва  да бъде  
включен  в MAC чрез добавянето  му пред  датаграмата , 
която  ще се автентифицира . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 418  
10.5.2  Структура  на защитено  съобщение  
CSM_188 При защитения  обмен  на съобщения  трябва  да се 
използват  само  обекти  от данни  за защитен  обмен  на 
съобщения  (вж. [ISO 7816-4]), които  са посочени  в 
таблица  5. Тези  обекти  от данни  трябва  във всяко  
съобщение  да се използват  в реда , специфициран  в 
следната  таблица . 
Таблица  5 
Обекти  от данни  за защитен  обмен  на съобщения  
Наименование  на обекта  от данни  Таг Присъствие : Задължи­  
телно (M), Условно (C) 
или Забранено  (F) в 
Команди  Отговори  
Открита  (plain) стойност , некодирана  
по BER-TLV  ‘81’ C  C  
Открита  стойност , кодирана  по BER- 
TLV, но невключваща  обекти  от 
данни  за защитен  обмен  (SM DOs)  ‘B3’ C  C  
Индикатор  за запълващото  
съдържание  (padding-content indi ­
cator), открита  (plain) стойност , неко­  
дирана  по BER-TLV  ‘87’ C  C  
Защитена  Le ‘97’  C  F  
Състояние  на обработка  ‘99’  F  M  
Криптографска  контролна  сума  ‘8E’  M  M  
Забележка : Както  е с специфицирано  в допълнение  2, 
възможно  е тахографските  карти  да поддържат  
командите  READ BINARY и UPDATE BINARY с 
нечетен  INS байт  (‘B1’, респективно  ‘D7’). Тези  
варианти  на командите  са необходими  за четене  и 
актуализация  на файлове  с големина  над 32 768 или 
повече  байта . В случай  че се използва  такъв  вариант , 
трябва  да се използва  обект  от данни  с таг ‘B3’ вместо  
обект  от данни  с таг ‘81’. За допълнителна  информация  
вж. допълнение  2. 
CSM_189 Всички  обекти  от данни  при защитен  обмен  на 
съобщения  трябва  да бъдат  кодирани  в DER TLV, 
както  е специфицирано  в [ISO 8825-1]. Това  кодиране  
води  до следната  структура  Таг-Дължина -Стойност  
(TLV):  
Таг: Тагът  се кодира  в един  или два октета  и 
показва  съдържанието . 
Дължина : Дължината  се кодира  като беззнаково  цяло  
число  в един , два или три октета , като в 
резултат  максималната  дължина  е 65 535 
октета . Използва  се минималният  брой  
октети . 
Стойност : Стойността  се кодира  в нула  или повече  
октети . 
CSM_190 Единиците  данни  APDUs, защитени  чрез защитен  обмен  
на съобщения , трябва  да бъдат  създавани  както  следва : 
— Заглавната  част на командата  (command header) 
трябва  да бъде  включена  в изчислението  на MAC, 
поради  което  трябва  да бъде  използвана  стойността  
‘0C’ за байта  CLA за определяне  на класа . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 419  
— Както  е специфицирано  в допълнение  2, всички  INS 
байтове  трябва  да са четни , с възможно  изключение  
за нечетни  INS байтове  за командите  READ 
BINARY и UPDATE BINARY.  
— След  прилагането  на защитен  обмен  на съобщения  
действителната  стойност  на Lc ще се измени  на Lc'. 
— Полето  от данни  ще се състои  от обекти  от данни  за 
защитен  обмен  на съобщения  (SM).  
— В защитената  командна  APDU за байта  за новата  Le 
се задава  ‘00’. Ако е необходимо , в полето  за данни  
се включва  обект  от данни  ‘97’ за представяне  на 
първоначалната  стойност  на Le. 
▼M1 
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 байт ) с криптиране  никога  
не се използва  при комуникацията  между  бордово  устройство  и 
карта . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 420  
По-долу  са дадени  три примера  за преобразуване  на APDU за 
команди  с четен  INS код. На фигура  8 е показана  командна  APDU 
с удостоверена  автентичност  — случай  4, на фигура  9 е показана  
ответна  APDU с удостоверена  автентичност  — случай  1/случай  3, а 
на фигура  10 е показана  криптирана  ответна  APDU с удостоверена  
автентичност  — случай  2/случай  4. 
Фигура  8 
Преобразуване  на командна  APDU с удостоверена  автентичност , случай  4
 
Фигура  9 
Преобразуване  на ответна  APDU с удостоверена  автентичност , случай  
1/случай  3
 ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 421  
Фигура  10 
Преобразуване  на криптирана  ответна  APDU с удостоверена  автентичност , случай  2/случай  4
 
▼B 
10.5.3  Прекратяване  на сесия  на защитен  обмен  на съобщения  
CSM_192 Бордовото  устройство  трябва  да прекрати  текуща  сесия  
на защитен  обмен  на съобщения  ако и само  ако е 
изпълнено  едно  от следните  условия : 
— бордовото  устройство  получи  ответна  APDU в открит  
текст , 
— бордовото  устройство  открие  в ответна  APDU грешка  
по отношение  на защитения  обмен  на съобщения , 
както  следва : 
— Липсва  очакван  обект  от данни  за защитен  обмен  
на съобщения , подреждането  на обектите  от 
данни  е неправилно  или е включен  непознат  
обект  от данни . 
— Даден  обект  от данни  за защитен  обмен  на 
съобщения  е неправилен , например  стойността  
на MAC е невярна , структурата  на TLV е 
неправилна  или индикаторът  за запълване  в таг 
‘87’ не е равен  на ‘01’.  
— картата  изпраща  байт  за състояние , показващ  че тя е 
открила  грешка  в защитения  обмен  на съобщения  
(вж. CSM_194),  
— достигнат  е лимитът  за броя  на командите  и съот­  
ветните  отговори  в рамките  на текущата  сесия . Този  
лимит  за дадено  бордово  устройство  трябва  да е 
определен  от неговия  производител , като се имат  
предвид  изискванията  за сигурност  във връзка  с 
използвания  хардуер , с максимална  стойност  240 
команди  и съответни  отговори  на сесия  за защитен  
обмен  на съобщения . ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 422  
CSM_193 Тахографската  карта  трябва  да прекрати  текуща  сесия  на 
защитен  обмен  на съобщения  ако — и само  ако — е 
изпълнено  едно  от следните  условия : 
— тахографската  карта  получи  командна  APDU в 
открит  текст , 
— тахографската  карта  открие  в командната  APDU 
грешка  по отношение  на защитения  обмен  на съоб­  
щения , както  следва : 
— липсва  очакван  обект  от данни  за защитен  обмен  
на съобщения , подреждането  на обектите  от 
данни  е неправилно  или е включен  непознат  
обект  от данни , 
— даден  обект  от данни  за защитен  обмен  на 
съобщения  е неправилен , например  стойността  
на MAC е невярна  или структурата  на TLV е 
неправилна , 
— тахографската  карта  е без захранване  или e инициа­  
лизирана , 
— бордовото  устройство  започне  процес  на удостове­  
ряване  на автентичността  на бордово  устройство , 
— достигнат  е лимитът  за броя  на командите  и съот­  
ветните  отговори  в рамките  на текущата  сесия . 
Лимитът  за дадена  карта  се определя  от нейния  
производител , като се имат  предвид  изискванията  за 
сигурност  във връзка  с използвания  хардуер , с 
максимална  стойност  240 команди  и съответни  
отговори  на сесия  за защитен  обмен  на съобщения . 
▼B 
CSM_194 Относно  реагирането  на тахографска  карта  при грешка  в 
защитения  обмен  на съобщения . 
— Ако в дадена  командна  APDU липсват  някои  
очаквани  обекти  от данни  за защитен  обмен  на съоб­  
щения , подреждането  на обектите  от данни  е 
неправилно  или са включени  непознати  обекти  от 
данни , тахографската  карта  трябва  да отговори  с 
байтове  за състояние  ‘69 87’.  
— Ако обект  от данни  за защитен  обмен  на съобщения  в 
командна  APDU е неправилен , тахографската  карта  
трябва  да отговори  с байтове  за състояние  ‘69 88’.  
В такъв  случай  байтовете  за състояние  се изпращат  
обратно  без използване  на защитен  обмен  на съобщения . 
CSM_195 Ако бъде  прекратена  сесия  на защитен  обмен  на 
съобщения  между  бордово  устройство  и тахографска  
карта , бордовото  устройство  и тахографската  карта  
трябва : 
— да унищожат  по сигурен  начин  съхранените  сесионни  
ключове  
— веднага  да създадат  нова  сесия  за защитен  обмен  на 
съобщения , както  е описано  в раздели  10.2 — 10.5.  
CSM_196 Ако по някаква  причина  бордовото  устройство  реши  да 
рестартира  взаимното  удостоверяване  на автентичност  с 
вкарана  карта , процесът  трябва  да рестартира  с проверка  
на веригата  на сертифициране  на картата , както  е 
описано  в раздел  10.2, и да продължи  както  е описано  
в раздели  10.2 — 10.5.  ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 423  
11. КУПЛИРАНЕ  БОРДОВО  УСТРОЙСТВО  — ВЪНШНО  
УСТРОЙСТВО  ЗА GNSS, ВЗАИМНО  УДОСТОВЕРЯВАНЕ  НА 
АВТЕНТИЧНОСТТА  И ЗАЩИТЕН  ОБМЕН  НА СЪОБЩЕНИЯ  
11.1.  Общи  положения  
CSM_197 Устройството  за GNSS, използвано  от бордово  
устройство  за определяне  на местоположението  му, 
може  да бъде  вътрешно  (т.е. вградено  в корпуса  на 
бордовото  устройство  и неотделящо  се) или да пред­  
ставлява  външен  модул . В първия  случай  не е необ­  
ходимо  да се стандартизира  вътрешната  комуникация  
между  устройството  за GNSS и бордовото  устройство  и 
изискванията  в настоящата  глава  не се отнасят  за него . 
Във втория  случай  комуникацията  между  бордовото  
устройство  и външното  устройство  за GNSS трябва  да 
бъде  стандартизирана  и защитена , както  е описано  в 
настоящата  глава . 
CSM_198 Защитената  комуникация  между  бордово  устройство  и 
външно  устройство  за GNSS трябва  да се извършва  по 
същия  начин  както  защитената  комуникация  между  
бордово  устройство  и тахографска  карта , като 
външното  устройство  за GNSS (EGF) е в ролята  на 
картата . EGF трябва  да изпълнява  всички  изисквания , 
посочени  в глава  10 за тахографските  карти , като се 
имат  предвид  посочените  в настоящата  глава  откло­  
нения , изяснения  и допълнения . По-специално , 
взаимната  проверка  на веригата  на сертифициране , удос­  
товеряването  на автентичността  на бордовото  устройство  
и на чипа  трябва  да бъдат  извършвани  както  е описано  в 
раздели  11.3 и 11.4.  
CSM_199 Комуникацията  между  бордово  устройство  и EGF се 
различава  от комуникацията  между  бордово  устройство  
и карта  поради  факта , че дадено  бордово  устройство  и 
EGF трябва  да бъдат  вече куплирани  веднъж  в завод / 
сервиз , преди  те да могат  да обменят  базиращи  се на 
GNSS данни  при нормална  работа . Процесът  на купли­  
рането  е описан  в раздел  11.2.  
CSM_200 При комуникацията  между  бордово  устройство  и EGF 
трябва  да се използват  командните  и ответните  APDU, 
базиращи  се на [ISO 7816-4] и [ISO 7816-8]. Точната  
структура  на тези APDU е дефинирана  в допълнение  2 
към настоящото  приложение . 
11.2.  Куплиране  на бордово  устройство  с външно  устройство  за GNSS  
CSM_201 Бордовото  устройство  и EGF в дадено  превозно  средство  
трябва  да бъдат  куплирани  от завод /сервиз  (by a 
workshop). При нормална  работа  могат  да комуникират  
само  куплирани  бордово  устройство  и EGF.  
CSM_202 Куплирането  на бордово  устройство  и EGF трябва  да е 
възможно  само  ако бордовото  устройство  е в режим  на 
калибриране . Куплирането  трябва  да се инициира  от 
бордовото  устройство . 
CSM_203 В завод /сервиз  (workshop) може  по всяко  време  да се 
рекуплира  дадено  бордово  устройство  с друго  или със 
същото  EGF. При рекуплирането  бордовото  устройство  
трябва  в сигурен  режим  да унищожи  съществуващия  
сертификат  EGF_MA в своята  памет  и да съхрани  серти­  
фиката  EGF_MA на съответното  EGF, с което  се 
куплира . 
CSM_204 В завод /сервиз  (workshop) може  по всяко  време  да се 
рекуплира  дадено  устройство  за GNSS с друго  или със 
същото  бордово  устройство . При рекуплирането  EGF 
трябва  в сигурен  режим  да унищожи  съществуващия  
сертификат  VU_MA в своята  памет  и да съхрани  серти­  
фиката  VU_MA на съответното  бордово  устройство , с 
което  се куплира . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 424  
11.3.  Взаимна  проверка  на веригата  на сертифициране  
11.3.1  Общи  положения  
CSM_205 Взаимната  проверка  на веригата  на сертифициране  
между  бордово  устройство  и EGF трябва  да се 
провежда  само  по време  на куплирането  на бордовото  
устройство  и EGF от завод /сервиз  (workshop). При 
нормална  работа  на куплирани  бордово  устройство  и 
EGF не се прави  проверка  на сертификати . Вместо  
това бордовото  устройство  и EGF трябва  да се 
доверяват  на сертификатите , които  са съхранили  по 
време  на куплирането , след  като проверят  валидността  
във времето  на тези сертификати . Бордовото  устройство  
и EGF не се доверяват  на никакви  други  сертификати  за 
защита  на комуникацията  бордово  устройство  — EGF 
при нормална  работа . 
11.3.2  По време  на куплирането  бордово  устройство  — EGF  
CSM_206 При куплирането  си към EGF бордовото  устройство  
трябва  да използва  протокола , описан  във фигура  4 
(раздел  10.2.1), за проверка  на веригата  на сертифи­  
циране  на външното  устройство  за GNSS.  
Забележки  в този  контекст  към фигура  4: 
— Управлението  на комуникацията  е извън  обхвата  на 
настоящото  допълнение . Но все пак EGF не е карта  с 
чип и поради  това бордовото  устройство  вероятно  
няма  да изпраща  команда  Reset за иницииране  на 
комуникация  и няма  да получава  ATR.  
— Посочените  във фигурата  картови  сертификати  и 
публични  ключове  трябва  да се интерпретират  като 
сертификати  и публични  ключове  на EGF за взаимно  
удостоверяване  на автентичността . В раздел  9.1.6 те 
са означени  като EGF_MA.  
— Посочените  във фигурата  Card.CA сертификати  и 
публични  ключове  трябва  да се интерпретират  като 
сертификати  и публични  ключове  на MSCA за 
подписване  на сертификатите  на EGF. В раздел  
9.1.3 те са означени  като MSCA_VU-EGF.  
— Упоменатият  във фигурата  сертификат  Card.CA.EUR 
трябва  да се интерпретира  като европейския  основен  
сертификат , който  е посочен  в референтното  
означение  на сертифициращия  орган  (CAR) на серти­  
фиката  MSCA_VU-EGF.  
— Упоменатият  във фигурата  сертификат  Card.Link 
трябва  да се интерпретира  като свързващия  
сертификат  на EGF, ако има такъв . Както  е 
посочено  в 9.1.2, това е свързващ  сертификат  за 
нова  европейска  двойка  основни  ключове , създадена  
от ERCA и подписана  с предходния  европейски  
частен  ключ . 
— Сертификатът  Card.Link.EUR е европейският  основен  
сертификат , който  е посочен  в референтното  
означение  на сертифициращия  орган  (CAR) на серти­  
фиката  Card.Link.  
— Вместо
  , бордовото  
устройство  трябва  да прочете
  
от EF ICC.  
— Вместо  да избере  Tachograph AID, бордовото  
устройство  трябва  да избере  EGF AID.  
— ‘Ignore Card’ трябва  да се интерпретира  като ‘Ignore 
EGF’.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 425  
CSM_207 След  като веднъж  е проверило  сертификата  EGF_MA, 
бордовото  устройство  трябва  да съхрани  този 
сертификат  за използване  при нормална  работа ; вж. 
раздел  11.3.3.  
CSM_208  ►M1 При куплирането  си към бордово  устройство  
външното  устройство  за GNSS трябва  да използва  
протокола , описан  във фигура  5 (раздел  10.2.2), за 
проверка  на веригата  на сертифициране  на бордовото  
устройство . ◄ 
Забележки  в този  контекст  към фигура  5: 
— Бордовото  устройство  трябва  да генерира  свежа  
(fresh) двойка  краткотрайни  ключове , използвайки  
домейн  параметрите  в сертификата  на EGF.  
— Упоменатите  във фигурата  сертификати  и публични  
ключове  VU са тези, които  се използват  за взаимно  
удостоверяване  на автентичността . В раздел  9.1.4 те 
са означени  като VU_MA.  
— Упоменатите  във фигурата  сертификати  и публични  
ключове  VU.CA са тези, които  се използват  за 
подписване  на сертификати  на бордови  устройства  
и на външни  устройства  за GNSS. В раздел  9.1.3 те 
са означени  като MSCA_VU-EGF.  
— Упоменатият  във фигурата  сертификат  VU.CA.EUR е 
европейският  основен  сертификат , който  е посочен  в 
референтното  означение  на сертифициращия  орган  
(CAR) на сертификата  VU.CA.  
— Упоменатият  във фигурата  сертификат  VU.Link е 
свързващият  сертификат  на бордовото  устройство , 
ако има такъв . Както  е посочено  в 9.1.2, това е 
свързващ  сертификат  за нова  европейска  двойка  
основни  ключове , създадена  от ERCA и подписана  
с предходния  европейски  частен  ключ . 
— Сертификатът  VU.Link.EUR е европейският  основен  
сертификат , който  е посочен  в референтното  
означение  на сертифициращия  орган  (CAR) на серти­  
фиката  VU.Link.  
CSM_209 В отклонение  от изискването  CSM_167, EGF трябва  да 
използва  отчитаното  от GNSS време  за проверка  на 
валидността  във времето  на всеки  представен  серти­  
фикат . 
▼M1 
CSM_210 След  като веднъж  е проверило  сертификата  VU_MA, 
външното  устройство  за GNSS трябва  да го съхрани  за 
използване  при нормална  работа ; вж. раздел  11.3.3.  
▼B 
11.3.3  При нормална  работа  
CSM_211  ►M1 При нормална  работа  дадено  бордово  устройство  
и EGF трябва  да използват  протокола , описан  във фигура  
11, за проверка  на валидността  във времето  на 
съхранения  сертификат  EGF_MA и за задаване  на 
публичния  ключ  VU_MA за последващо  удостоверяване  
на автентичността  на бордовото  устройство . При 
нормална  работа  не трябва  да се прави  по-нататъшна  
взаимна  проверка  на веригите  за сертифициране . ◄ 
Забележете , че по същество  фигура  11 се състои  от 
първите  стъпки , посочени  в фигура  4 и фигура  5. И 
още веднъж , имайте  предвид  че тъй като EGF не е 
карта  с чип, бордовото  устройство  вероятно  няма  да 
изпраща  команда  Reset за иницииране  на комуникация  
и няма  да получава  ATR. При всички  случаи  това е 
извън  обхвата  на настоящото  допълнение . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 426  
Фигура  11 
Взаимна  проверка  на валидността  във времето  на сертификатите  при нормална  работа  VU — EGF
  
CSM_212 Както  е показано  във фигура  11, в случай  че серти­  
фикатът  EGF_MA вече не е валиден , бордовото  
устройство  трябва  да регистрира  грешка . Въпреки  това, 
взаимното  удостоверяване  на автентичността , догова­  
рянето  на ключовете  и последващата  комуникация  
посредством  защитен  обмен  на съобщения  трябва  да 
продължат  нормално . 
11.4.  Автентифициране  на бордовото  устройство , автентифициране  
на чипа  и договаряне  на сесийни  ключове  
CSM_213 Автентифицирането  на бордовото  устройство , автенти­  
фицирането  на чипа  и договарянето  на сесийни  
ключове  между  бордово  устройство  и EGF трябва  да 
се прави  по време  на куплирането  и по време  на 
последващо  влизане  в сесия  за защитен  обмен  на 
информация  при нормална  работа . Бордовото  устройство  
и EGF трябва  да изпълняват  процесите , описани  в 
раздели  10.3 и 10.4. Валидни  са всички  изисквания , 
описани  в тези раздели . 
11.5.  Защитен  обмен  на съобщения  
CSM_214 Всички  команди  и отговори , които  се разменят  между  
бордово  устройство  и външното  устройство  за GNSS 
след  успешно  проведено  удостоверяване  на автентич­  
ността  на чипа  до края  на сесията  трябва  да бъдат  
защитени  чрез защитен  обмен  на съобщения . Валидни  
са всички  изисквания , описани  в раздел  10.5.  
CSM_215 Ако дадена  сесия  за защитен  обмен  на съобщения  между  
бордово  устройство  и EGF бъде  прекратена , бордовото  
устройство  трябва  веднага  да създаде  нова  сесия  за 
защитен  обмен  на съобщения , както  е описано  в 
раздели  11.3.3 и 11.4.  
12. СДВОЯВАНЕ  И КОМУНИКАЦИЯ  БОРДОВО  УСТРОЙСТВО  — 
ДАТЧИК  ЗА ДВИЖЕНИЕ  
12.1.  Общи  положения  
CSM_216 Бордовото  устройство  и датчикът  за движение  трябва  да 
комуникират  при сдвояване  и нормална  работа  като 
използват  интерфейсния  протокол , специфициран  в 
[ISO 16844-3], в съответствие  с измененията , описани  в 
настоящата  глава  и в раздел  9.2.1.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 427  
Забележка : читателите  на настоящата  глава  следва  да са 
запознати  със съдържанието  на [ISO 16844-3].  
12.2.  Сдвояване  бордово  устройство  — датчик  за движение  с 
използване  на различни  поколения  ключове  
Както  е изяснено  в раздел  9.2.1, главният  ключ  на датчика  за 
движение  и всички  свързани  с него  ключове  редовно  се заменят . 
Това  води  до наличието  в картите  за монтаж  и настройка  на до 
три свързани  с датчика  на движение  AES ключа  K M-WC  (от послед­  
ователни  поколения  ключове ). Подобно  на това, в датчиците  за 
движение  могат  да присъстват  до три различни  базиращи  се на 
AES криптирания  на данни  (на базата  на последователни  
поколения  на главния  ключ  на датчика  за движение  K  M ). 
Бордовото  устройство  съдържа  само  един  свързан  с датчика  за 
движение  ключ  K M-VU.  
CSM_217 Бордово  устройство  от второ  поколение  и датчик  за 
движение  от второ  поколение  трябва  да бъдат  
сдвоявани  както  следва  (сравнете  с посоченото  в 
таблица  6 от [ISO 16844-3]):  
1. В бордовото  устройство  се вкарва  карта  за монтаж  и 
настройки  от второ  поколение  и бордовото  
устройство  се свързва  с датчика  за движение . 
2. Бордовото  устройство  прочита  всички  налични  
ключове  K M-WC  от картата  за монтаж  и настройки , 
инспектира  техните  номера  на версии  и избира  един  
от тях, който  съответства  на номера  на версията  на 
ключа  K M-VU  в бордовото  устройство . Ако в картата  
за монтаж  и настройки  липсва  съответстващ  ключ  K M- 
WC , бордовото  устройство  прекратява  процеса  на 
сдвояване  и показва  на титуляря  на картата  за 
монтаж  и настройки  подходящо  съобщение  за грешка . 
3. Въз основа  на K M-VU  и K M-WC  бордовото  устройство  
изчислява  главния  ключ  на датчика  за движение  K M и 
съответно  от K  M изчислява  K  ID , както  е специфи­  
цирано  в раздел  9.2.1.  
4. Бордовото  устройство  изпраща  на датчика  за 
движение  инструкцията  за иницииране  на процес  на 
сдвояване , както  е описано  в [ISO 16844-3], и 
криптира  получения  от датчика  за движение  сериен  
номер  с идентификационния  ключ  K  ID. След  това 
бордовото  устройство  изпраща  криптирания  сериен  
номер  обратно  на датчика  за движение . 
5. Датчикът  за движение  сравнява  криптирания  сериен  
номер  последователно  с всеки  от криптираните  
серийни  номера , които  той съдържа  вътре  в себе си. 
Ако се установи  съответствие , бордовото  устройство  
е автентифицирано . Датчикът  за движение  отбелязва  
генерирането  на K  ID , използван  от бордовото  
устройство , и връща  съответстващата  криптирана  
версия  на своя  ключ  за сдвояване ; т.е. криптирането , 
създадено  с използване  на същото  поколение  K M . 
6. Бордовото  устройство  декриптира  ключа  за сдвояване  
като използва  K M , създава  сесиен  ключ  K S, криптира  
го с ключа  за сдвояване  и изпраща  така получения  
резултат  на датчика  за движение . Датчикът  за 
движение  декриптира  K S . 
7. Бордовото  устройство  информацията  за сдвояване , 
както  е дефинирана  в [ISO 16844-3], криптира  инфор­  
мацията  с ключа  за сдвояване  и изпраща  резултата  на 
датчика  за движение . Датчикът  за движение  
декриптира  информацията  за сдвояване . 
8. След  това датчикът  за движение  криптира  получената  
информация  за сдвояване  с получения  ключ  K S и я 
връща  на бордовото  устройство . Бордовото  
устройство  проверява  дали  информацията  за 
сдвояване  е същата  като тази, която  то е изпратило  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 428  
на датчика  за движение  при предишната  стъпка . Ако е 
така, това доказва  че датчикът  за движение  е 
използвал  същия  ключ  K S като бордовото  устройство  
и следователно  в стъпка  5 е изпратило  своя  ключ  за 
сдвояване , криптиран  с правилното  поколение  K M . По 
този начин  датчикът  за движение  е автентифициран . 
Забележете , че стъпки  2 и 5 са различни  от стандартния  
процес  в [ISO 16844-3]; останалите  стъпки  са същите  
като в стандарта . 
Пример : Да предположим , че сдвояването  се провежда  в 
първата  година  на валидност  на сертификата  ERCA (3); 
вж. фигура  2 в раздел  9.2.1.2. Освен  това, 
— Да предположим , че датчикът  за движение  е издаден  
в последната  година  на валидност  на сертификата  
ERCA (1). Следователно  той ще съдържа  следните  
ключове  и данни : 
— N  s [1]: неговият  сериен  номер , криптиран  с K ID от 
поколение  1, 
— N  s [2]: неговият  сериен  номер , криптиран  с K ID от 
поколение  2, 
— N  s [3]: неговият  сериен  номер , криптиран  с K ID от 
поколение  3, 
— K  P [1]: неговият  ключ  за сдвояване  от поколение  
1 ( 1 ), криптиран  с K M от поколение  1, 
— K  P [2]: неговият  ключ  за сдвояване  от поколение  
2, криптиран  с K M от поколение  2, 
— K  P [3]: неговият  ключ  за сдвояване  от поколение  
3, криптиран  с K M от поколение  2, 
— Да предположим , че картата  за монтаж  и настройки  е 
издадена  в първата  година  на валидност  на серти­  
фиката  ERCA (3). В такъв  случай  тя ще съдържа  
поколение  2 и поколение  3 на ключа  K M-WC  . 
— Да предположим , че бордовото  устройство  е от 
поколение  2 и съдържа  поколение  2 на ключа  K M-VU.  
В такъв  случай  при стъпки  2 — 5 ще се случи  следното : 
— Стъпка  2: Бордовото  устройство  прочита  от картата  
за монтаж  и настройки  поколение  2 и поколение  3 на 
ключа  K  M-WC  и инспектира  техните  номера  на 
версии . 
— Стъпка  3: Бордовото  устройство  комбинира  ключа  
K M-WC  от поколение  2 със своя  ключ  K M-VU  за да 
изчисли  K M и K ID. 
— Стъпка  4: Бордовото  устройство  криптира  с K  ID 
серийния  номер , получен  от датчика  за движение . 
— Стъпка  5: Датчикът  за движение  сравнява  получените  
данни  с N s [1] и не намира  съответствие . След  това 
той сравнява  данните  с N  s [2] и установява  съот­  
ветствие . Прави  заключението , че бордовото  
устройство  е от поколение  2 и поради  това изпраща  
обратно  K P [2]. ▼B 
( 1 ) Забележете , че ключовете  за сдвояване  от поколение  1, 2 и 3 могат  реално  да са 
един  и същ ключ , или три различни  ключа  с различни  дължини , както  е изяснено  в 
CSM_117.
 02016R0799 — BG — 26.02.2020 — 002.001 — 429  
12.3.  Сдвояване  и връзка  бордово  устройство  — датчик  за движение  с 
използване  на AES  
CSM_218 Както  е специфицирано  в таблица  3 в раздел  9.2.1, 
всички  ключове , участващи  в сдвояване  на бордово  
устройство  (от второ  поколение ) и датчик  за движение , 
както  и в последващата  комуникация , трябва  по-скоро  да 
са AES ключове , а не TDES ключове  с двойна  дължина , 
както  е специфицирано  в [ISO 16844-3]. Тези  AES 
ключове  могат  да са с дължина  128, 192 или 256 бита . 
Тъй като размерът  на AES блока  е 16 байта , дължината  
на криптираното  съобщение  трябва  да е кратна  на 16 
байта , докато  при TDES тя трябва  да е кратна  на 8 
байта . Също  така, някои  от тези съобщения  ще бъдат  
използвани  за маршрутизиране  на AES ключове , чиято  
дължина  може  да е 128, 192 или 256 бита . Следователно , 
броят  на байтовете  данни  за една  инструкция , посочен  в 
Таблица  5 от [ISO 16844-3], трябва  да бъде  променен , 
както  е показано  в таблица  6: 
▼M1 
Таблица  6 
Брой  на байтовете  данни  в открит  текст  и на криптираните  байтове  данни  за една  инструкция , 
дефиниран  в [ISO 16844-3]  
Инструкц­  
ия Заявка  / 
отговор  Описание  на данните  # на байтовете  
данни  в открит  
текст  съгласно  
[ISO 16844-3]  # на байтовете  
данни  в открит  
текст , използващи  
AES ключове  # на криптираните  байтове  
данни , използващи  AES 
ключове  с дължина  в битове  
128 192  256  
10 Заявка  Данни  за удостове­  
ряване  на автентич­  
ността  + номер  на 
файла  8 8  16  16  16  
11 Отговор  Данни  за удостове­  
ряване  на автентич­  
ността  + 
съдържание  на 
файла  16 или 32, зависи  
от файла  16 или 32, зависи  
от файла  32 / 48  32 / 48  32 / 48  
41 Заявка  Сериен  номер  на 
MoS  8 8  16  16  16  
41 Отговор  Ключ  за сдвояване  16  16 / 24 / 32  16  32  32  
42 Заявка  Сесиен  ключ  16  16 / 24 / 32  16  32  32  
43 Заявка  Информация  за 
сдвояване  24 24  32  32  32  
50 Отговор  Информация  за 
сдвояване  24 24  32  32  32  
70 Заявка  Данни  за удостове­  
ряване  на автентич­  
ността  8 8  16  16  16  
80 Отговор  Стойност  на брояча  
на MoS + данни  за 
удост . на автент . 8 8  16  16  16  
▼B 
CSM_219 Информацията  за сдвояване , изпращана  с инструкции  
номер  43 (заявка  от бордовото  устройство ) и номер  50 
(отговор  от датчика  за движение ) трябва  да бъде  
събрана , както  е специфицирано  в раздел  7.6.10 от 
[ISO 16844-3], с тази разлика , че в схемата  за криптиране  
на данните  за сдвояване  се използва  алгоритъмът  AES 
вместо  алгоритъма  TDES, като по този начин  се 
получават  две криптирания  AES и се възприема  специ­  
фицираното  в CSM_220 запълване , за да има съот­  
ветствие  с размера  на AES блок . Използваният  за това 
криптиране  ключ  K'  p трябва  да бъде  генериран  както  
следва : 
— В случай , че ключът  за сдвояване  K P е с дължина  16 
байта : K'  p = K  P XOR (N  s ||N s ) ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 430  
— В случай , че ключът  за сдвояване  K P е с дължина  24 
байта : K'  p = K  P XOR (N  s ||N s ||N s ) 
— В случай , че ключът  за сдвояване  K P е с дължина  32 
байта : K'  p = K  P XOR (N  s ||N s ||N s ||N s ) 
където  N s е 8-байтовият  сериен  номер  на датчика  за 
движение . 
CSM_220 В случай  че дължината  на данните  в открит  текст  (при 
използване  на AES ключове ) не е кратна  на 16 байта , 
трябва  да се използва  методът  на запълване  номер  2, 
дефиниран  в [ISO 9797-1].  
Забележка : В [ISO 16844-3] броят  на байтовете  данни  в 
открит  текст  е винаги  кратен  на 8 и поради  това когато  
се използва  TDES не е необходимо  да се прави  
запълване . С тази част на настоящото  допълнение  не се 
променя  дефиницията  на данни  и съобщения  от [ISO 
16844-3] и поради  това се появява  необходимост  да се 
прилага  запълване . 
CSM_221 За инструкция  11 и в случай , че трябва  да бъде  
криптиран  повече  от един  блок  данни , трябва  да бъде  
използван  работният  режим  на свързване  на блокове  
шифровани  данни  (Cipher Block Chaining), дефиниран  в 
[ISO 10116], с параметър  на редуване  (interleave para ­
meter)  m = 1. Използваният  инициализиращ  вектор  
трябва  да бъде  както  следва : 
— За инструкция  11: 8-байтовият  автентифициращ  блок , 
специфициран  в раздел  7.6.3.3 от [ISO 16844-3], 
запълнен  с използване  на метода  за запълване  
номер  2, дефиниран  в [ISO 9797-1]; вж. също  
раздели  7.6.5 и 7.6.6 от [ISO 16844-3].  
— За всички  други  инструкции , при които  се 
прехвърлят  повече  от 16 байта , както  е специфи­  
цирано  в таблица  6: ‘00’ {16}, т.е. шестнадесет  
байта  с бинарна  стойност  0. 
Забележка : Както  е показано  в раздел  7.6.5 и 7.6.6 от 
[ISO 16844-3], когато  бордовото  устройство  криптира  
файлове  с данни  за включване  в инструкция  11, автен­  
тифициращият  блок  едновременно : 
— се използва  като инициализиращ  вектор  за крип­  
тиране  в режим  CBC на файловете  с данни  
— се криптира  и включва  като първия  блок  с данни , 
който  се изпраща  на бордовото  устройство . 
12.4.  Сдвояване  бордово  устройство  — датчик  за движение  при 
различни  поколения  на оборудването  
CSM_222 Както  е изяснено  в раздел  9.2.1, даден  датчик  за 
движение  от второ  поколение  може  да съдържа  крип­  
тиране  на база TDES на данните  за сдвояване  (както  е 
дефинирано  в част А от настоящото  допълнение ), което  
дава възможност  този датчик  за движение  да бъде  сдвоен  
с бордово  устройство  от първо  поколение . Ако случаят  е 
такъв , бордовото  устройство  от първо  поколение  и 
датчикът  за движение  от второ  поколение  трябва  да 
бъдат  сдвоени  както  е описано  в част А от настоящото  
допълнение  и в [ISO 16844-3]. За процеса  на сдвояване  
може  да бъде  използвана  карта  за монтаж  и настройки  
или от първо , или от второ  поколение . 
Забележки : 
— Не е възможно  сдвояване  на бордово  устройство  от 
второ  поколение  с датчик  за движение  от първо  
поколение . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 431  
— Не е възможно  да се използва  карта  за монтаж  и 
настройки  от първо  поколение  за куплиране  към 
датчик  за движение  на бордово  устройство  от второ  
поколение . 
13. СИГУРНОСТ  ПРИ  ВРЪЗКА  ОТ РАЗСТОЯНИЕ  ПО DSRC  
13.1.  Общи  положения  
Както  е специфицирано  в допълнение  14, бордовото  устройство  
редовно  генерира  данни  за дистанционен  мониторинг  на тахографа  
(Remote Tachograph Monitoring — RTM) и изпраща  тези данни  на 
(вътрешно  или външно ) устройство  за връзка  от разстояние  (Remote 
Communication Facility — RCF). Устройството  за връзка  от 
разстояние  има за задача  да изпраща  тези данни  по описаната  в 
допълнение  14 DSRC до дистанционното  разпитващо  устройство . 
В допълнение  1 е посочено , че RTM данните  представляват  конка­  
тенация  на: 
Криптирани  полезни  данни  от тахографа  (криптирането  на 
открития  текст  на полезните  данни  от тахографа ) 
Данни  за сигурността  на DSRC  (описани  по-долу ) 
Форматът  на тахографските  полезни  данни  в открит  текст  е специ­  
фициран  в допълнение  1 и доуточнен  в допълнение  14. В 
настоящата  секция  е описана  структурата  на данните  за сигурността  
на DSRC; официалната  спецификация  е в допълнение  1. 
CSM_223 Данните
  в открит  текст , които  
се съобщават  от бордово  устройство  на устройство  за 
връзка  от разстояние  (RCF — ако това устройство  е 
външно  за бордовото  устройство ) или от бордово  
устройство  на дистанционно  разпитващо  устройство  по 
DSRC интерфейс  (ако RCF е вътрешно  устройство  в 
бордовото  устройство ) трябва  да бъдат  защитени  в 
режим  „криптиране  с последващо  автентифициране “, 
т.е. тахографските  полезни  данни  първо  се криптират  
за да се осигури  поверителността  на съобщението  и 
след  това се изчислява  автентификационен  код (MAC) 
за съобщението , за да се осигури  автентичност  и 
цялостност  на данните . 
CSM_224 Данните  за сигурността  на DSRC трябва  да пред­  
ставляват  конкатенация  на следните  елементи  от данни  
в следния  ред; вж. също  фигура  12: 
Текуща  дата  и час (текущата  дата и час на бордовото  
устройство  (тип данни
  ))  
Брояч  (3-байтов  брояч , вж. CSM_225)  
▼M1 
Сериен  номер  на бордовото  устройство  (серийният  
номер  на бордовото  устройство  или идентификаторът  
на искането  за сертификат  (тип данни  VuSerialNumber 
или CertificateRequestID) — вж. CSM_123  
▼B 
номер  на версията  на главния  ключ  за DSRC  (1- 
байтовият  номер  на версията  на главния  ключ  за 
DSRC, от който  са изведени  специфични  за бордовото  
устройство  ключове  за DSRC, вж. раздел  9.2.2.)  
MAC  (Стойността  на MAC, изчислена  върху  всички  
предходни  байтове  в RTM данните ). 
CSM_225 3- байтовият  брояч  в данните  за сигурността  на DSRC 
трябва  да бъде  във формат  с най-старшия  байт  на 
първо  място  (MSB-first format). Когато  дадено  бордово  
устройство  за пръв  път изчислява  набор  от RTM данни  
след  неговото  влизане  в експлоатация , стойността  в 
брояча  му трябва  да е настроена  да е 0. Бордовото  
устройство  трябва  да увеличава  стойността  в брояча  на 
данните  с 1 преди  всяко  изчисление  от него  на нов набор  
от RTM данни . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 432  
13.2.  Криптиране  на полезните  тахографски  данни  и генериране  на 
MAC  
CSM_226 При даден  елемент  от данни  в открит  текст  от типа
  
, както  е описан  в допълнение  
14, съответното  бордово  устройство  трябва  да криптира  
тези данни , както  е показано  на фигура  12: крипти­  
ращият  DSRC ключ  на бордовото  устройство  
K_VU  DSRC  _ENC (вж. раздел  9.2.2) трябва  да бъде  
използван  с AES в работен  режим  на свързване  на 
блокове  шифровани  данни  (CBC), както  е дефиниран  в 
[ISO 10116], с параметър  на редуване  (interleave para ­
meter)  m = 1. Инициализиращият  вектор  трябва  да бъде  
IV = current date time  || ‘00 00 00 00 00 00 00 00 00’  || 
counter , където  current date time  и counter  са специфи­  
цирани  в CSM_224. Данните  за криптиране  трябва  да 
бъдат  запълнени  с използване  на метод  2, дефиниран  в 
[ISO 9797-1].  
CSM_227 Бордовото  устройство  трябва  да изчисли  MAC за 
данните  за сигурността  на DSRC, както  е показано  във 
фигура  12: MAC трябва  да бъде  изчислен  върху  всички  
предходни  байтове  в RTM данните , до и включително  с 
номера  на версията  на главния  ключ  за DSRC, както  и 
включително  с таговете  и дължините  на обектите  от 
данни . Бордовото  устройство  трябва  да използва  своя  
DSRC ключ  за автентификация  K_VU  DSRC  _MAC (вж. 
раздел  9.2.2) с алгоритъма  AES в режим  CMAC, както  
е специфицирано  в [SP 800-38B]. Дължината  на МАС  
трябва  да е свързана  с дължината  на специфичните  за 
бордовото  устройство  DSRC ключове , както  е специфи­  
цирано  в CSM_50.  
Фигура  12 
Криптиране  на полезните  тахографски  данни  и генериране  на MAC
  
13.3.  Проверка  и декриптиране  на полезни  тахографски  данни  
CSM_228 Когато  дадено  дистанционно  разпитващо  устройство  
получи  от бордово  устройство  RTM данни , то трябва  
да изпрати  всички  тези данни  на контролна  карта  в 
полето  за данни  на команда  PROCESS DSRC 
MESSAGE, както  е описано  в допълнение  2. Тогава : ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 433  
1. Контролната  карта  трябва  да инспектира  номера  на 
версията  на главния  ключ  за DSRC в данните  за 
сигурността  на DSRC. Ако контролната  карта  не 
познава  посочения  главен  ключ  за DSRC, тя трябва  
да върне  съобщение  за грешка , което  е специфи­  
цирано  в допълнение  2, и да прекрати  процеса . 
▼M1 
2. Контролната  карта  трябва  да използва  посочения  
главен  ключ  DSRC в комбинация  със серийния  
номер  на бордовото  устройство  или с идентификатора  
на искането  за сертификат  в данните  за сигурността  
на DSRC, за да изведе  специфичните  за бордовото  
устройство  ключове  K_VU  DSRC  _ENC и 
K_VU  DSRC  _MAC, както  е специфицирано  в CSM_124.  
▼B 
3. Контролната  карта  трябва  да използва  ключа  
K_VU  DSRC  _MAC за да провери  MAC в данните  за 
сигурността  на DSRC, както  е специфицирано  в 
CSM_227. Ако MAC не е верен , контролната  карта  
трябва  да върне  съответното  съобщение  за грешка , 
специфицирано  в допълнение  2 и да прекрати  
процеса . 
4. Контролната  карта  трябва  да използва  ключа  
K_VU  DSRC  _ENC за да декриптира  криптираните  
тахографски  полезни  данни , както  е специфицирано  
в CSM_226. Контролната  карта  трябва  да отстрани  
запълването  и да върне  декриптираните  тахографски  
полезни  данни  на дистанционното  разпитващо  
устройство . 
CSM_229 С цел предотвратяване  на атаки  с повторно  възпро­  
извеждане  (replay attacks) дистанционното  разпитващо  
устройство  трябва  да проверява  свежестта  (freshness) на 
данните  RTM чрез проверка  дали  стойността  current date 
time в данните  за сигурността  на DSRC не се отклонява  
прекалено  много  от текущото  време  според  дистанци­  
онното  разпитващо  устройство . 
Забележки : 
— За тази цел е необходимо  дистанционното  разпитващо  
устройство  да разполага  с точен  и надежден  източник  
за отчитане  на времето . 
— Като  се има предвид , че в допълнение  14 има 
изискване  бордовото  устройство  да изчислява  нов 
набор  от RTM данни  на всеки  60 секунди  и че за 
часовника  на бордовото  устройство  е допустимо  да 
се отклонява  с 1 минута  от действителното  време , 
долната  граница  за свежест  на данните  RTM е 2 
минути . Действителната  стойност  на свежестта  
зависи  също  от точността  на часовника  на дистанци­  
онното  разпитващо  устройство . 
CSM_230 Когато  даден  завод /сервиз  (workshop) проверява  
правилното  действие  на DSRC функционалността  на 
дадено  бордово  устройство , той трябва  да изпрати  
всички  RTM данни , които  е получил  от бордовото  
устройство , до карта  за монтаж  и настройка  в полето  
за данни  на команда  PROCESS DSRC MESSAGE, както  
е описано  в допълнение  2. Картата  за монтаж  и 
настройки  трябва  да изпълни  всички  проверки  и 
дейности , специфицирани  в CSM_228.  
14. ПОДПИСВАНЕ  НА ИЗТЕГЛЕНИ  ДАННИ  И ПРОВЕРКА  НА 
ПОДПИСИТЕ  
14.1.  Общи  положения  
CSM_231 Специализираното  интелигентно  устройство  (IDE) трябва  
да записва  в един  физически  файл  данните , получени  от 
бордово  устройство  или карта  в рамките  на една  сесия  
на изтегляне  на данни . Данните  могат  да бъдат  
съхранени  върху  външно  запаметяващо  устройство  
(ESM). Гореспоменатият  файл  съдържа  електронни  
подписи  върху  блоковете  данни , както  е специфицирано  
в допълнение  7. Този  файл  трябва  да съдържа  също  
следните  сертификати  (вж. раздел  9.1):  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 434  
— В случай  на изтегляне  на данни  от бордово  
устройство : 
— Сертификата  VU_Sign  
— Сертификата  MSCA_VU-EGF, съдържащ  
публичния  ключ , който  се използва  за прове­  
ряване  на сертификата  VU_Sign  
— В случай  на изтегляне  на данни  от карта : 
— Сертификата  Card_Sign  
— Сертификата  MSCA_Card, съдържащ  публичния  
ключ , който  се използва  за проверяване  на серти­  
фиката  Card_Sign  
CSM_232 Специализираното  интелигентно  устройство  трябва  да 
разполага  също  със следните  сертификати  в съответните  
случаи : 
— В случай  че използва  контролна  карта  за проверка  на 
подпис , както  е показано  във фигура  13 — със свър­  
зващият  сертификат , който  свързва  последния  EUR 
сертификат  с този EUR сертификат , чийто  период  
на валидност  е непосредствено  предхождащ , ако 
има такъв . 
— В случай , че проверява  самия  подпис  — с всички  
валидни  европейски  основни  сертификати . 
Забележка : В настоящото  допълнение  не е специ­  
фициран  методът , който  да се използва  от IDE за придо­  
биване  на тези сертификати . 
14.2.  Генериране  на подпис  
CSM_233 Използваният  от бордовото  устройство  алгоритъм  за 
подписване  при автентифицирането  на бордовото  
устройство  трябва  да бъде  ECDSA, както  е специ­  
фициран  в [DSS], с използване  на алгоритъма  за 
хеширане , свързан  с размера  на ключа  на бордовото  
устройство  или на картата , както  е специфицирано  в 
CSM_50. Форматът  на подписа  трябва  да бъде  открит  
(plain), както  е специфицирано  в [TR-03111].  
14.3.  Проверка  на подписа  
CSM_234  ►M1 Дадено  IDE може  само  да извършва  проверка  на 
подпис  върху  изтеглени  данни  или да използва  за тази 
цел контролна  карта . В случай  че използва  контролна  
карта , проверката  на подписа  се извършва , както  е 
показано  във фигура  13. За да провери  валидността  във 
времето  на представен  от IDE сертификат , контролната  
карта  трябва  да използва  вътрешно  генерираното  от нея 
текущо  време  съгласно  посоченото  в раздел  CSM_167. 
Ако датата  на влизане  в сила  на автентичен  сертификат , 
представляващ  „валиден  източник  на данни  за времето “, 
е по-скорошна  от текущото  време  на картата , картата  
трябва  да актуализира  своето  текущо  време . Като  
валиден  източник  на данни  за времето  картата  трябва  
да възприема  само  следните  сертификати : 
— свързващи  сертификати  на ERCA от второ  поко­  
ление , 
— сертификати  на MSCA от второ  поколение , 
— сертификати  VU_Sign или Card_Sign от второ  поко­  
ление , издадени  от същата  държава  като издалата  
собствения  сертификат  на контролната  карта . 
В случай  че самото  IDE проверява  подписа , то трябва  да 
провери  автентичността  и валидността  на всички  серти­  
фикати  в сертификационната  верига  във файла  с данни , 
както  и подписа  върху  данните , в съответствие  със 
схемата  за подписване , дефинирана  в [DSS]. И в двата  
случая  за всеки  сертификат , който  се чете от файла  с 
данни , трябва  да се провери  дали  полето  за оторизация  
на титуляря  на сертификата  (Certificate Holder Authori ­
sation — CHA) е правилно : 
— Полето  CHA в сертификата  EQT трябва  да указва  
сертификат  за подпис  на бордово  устройство  или 
карта  според  случая  (вж. допълнение  1, тип данни  
EquipmentType).  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 435  
— CHA в сертификат  EQT.CA трябва  да указва  MSCA.  
— CHA в сертификат  EQT.Link трябва  да указва  
ERCA. ◄ 
Забележки  към фигура  13: 
— Оборудването , което  е подписало  подлежащите  на 
анализ  данни  се означава  с EQT.  
— Упоменатите  във фигурата  сертификати  и публични  
ключове  EQT са тези, които  се използват  за 
подписване , т.е. VU_Sign или Card_Sign.  
— Упоменатите  във фигурата  сертификати  и публични  
ключове  EQT.CA са тези, които  се използват  за 
подписване  на сертификати  на бордови  устройства  
или карти , съобразно  конкретния  случай . 
— Упоменатият  във фигурата  сертификат  EQT.CA.EUR 
е европейският  основен  сертификат , който  е посочен  
в референтното  означение  на сертифициращия  орган  
(CAR) на сертификата  EQT.CA.  
— Упоменатият  във фигурата  сертификат  EQT.Link е 
свързващият  сертификат  на EQT, ако има такъв . 
Както  е посочено  в раздел  9.1.2, това е свързващ  
сертификат  за нова  европейска  двойка  основни  
ключове , създадена  от ERCA и подписана  с пред­  
ходния  европейски  частен  ключ . 
— Сертификатът  EQT.Link.EUR е европейският  основен  
сертификат , който  е посочен  в референтното  
означение  на сертифициращия  орган  (CAR) на серти­  
фиката  EQT.Link.  
CSM_235 За изчисляването  на хеш M, изпратено  на контролната  
карта  в командата  PSO:Hash, IDE трябва  да използва  
алгоритъма  за хеширане , свързан  с размера  на ключа  
на бордовото  устройство  или на картата , от които  се 
изтеглят  данни , както  е специфицирано  в CSM_50.  
CSM_236 За проверяване  на подписа  на EQT контролната  карта  
трябва  да следва  схемата  за подписване , дефинирана  в 
[DSS].  
Забележка : В настоящия  документ  не е специфицирано  
действие , което  да се предприема , ако подписът  върху  
изтеглени  данни  не може  да бъде  проверен  или ако 
проверката  е неуспешна . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 436  
Фигура  13 
Протокол  за проверка  на подписа  върху  изтеглен  файл  с данни
  ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 437  
Допълнение  12 
ОПРЕДЕЛЯНЕ  НА МЕСТОПОЛОЖЕНИЕТО  ВЪЗ  ОСНОВА  НА 
ГЛОБАЛНА  НАВИГАЦИОННА  СПЪТНИКОВА  СИСТЕМА  (GNSS)  
СЪДЪРЖАНИЕ  
1. ВЪВЕДЕНИЕ  
1.1. Обхват  
1.2. Съкращения  и означения  
2. СПЕЦИФИКАЦИЯ  НА ПРИЕМНИКА  НА СИГНАЛИ  ОТ GNSS  
3. ИЗРЕЧЕНИЯ  НА NMEA  
4. БОРДОВО  УСТРОЙСТВО  С ВЪНШНО  УСТРОЙСТВО  ЗА GNSS  
4.1. Конфигурация  
4.1.1 Основни  компоненти  и интерфейси  
4.1.2 Състоянието  на външното  устройство  за GNSS при завършването  на 
производството  му 
4.2. Връзка  между  външното  устройство  за GNSS и бордовото  
устройство  
4.2.1 Протокол  за връзка  
4.2.2 Защитено  прехвърляне  на данни  от GNSS  
4.2.3 Структура  на командата  Read Record  
4.3. Куплиране , взаимно  удостоверяване  на автентичността  и договаряне  
на сесийни  ключове  на външното  устройство  за GNSS с бордовото  
устройство  
4.4. Третиране  на грешки  
4.4.1 Грешка  във връзката  с външното  устройство  за GNSS  
4.4.2 Нарушение  на физическата  цялост  на външното  устройство  за GNSS  
4.4.3 Липса  на информация  за местоположението  от приемник  на сигнали  
от GNSS  
4.4.4 Изтекъл  сертификат  на външното  устройство  за GNSS  
5. БОРДОВО  УСТРОЙСТВО  БЕЗ ВЪНШНО  УСТРОЙСТВО  ЗА GNSS  
5.1. Конфигурация  
5.2. Третиране  на грешки  
5.2.1 Липса  на информация  за местоположението  от приемник  на сигнали  
от GNSS  
6. ВРЕМЕВИ  КОНФЛИКТ  В ДАННИТЕ  ОТ GNSS  
7. ПРОТИВОРЕЧИЕ  В ДАННИТЕ  ЗА ДВИЖЕНИЕТО  НА 
ПРЕВОЗНОТО  СРЕДСТВО  
1. ВЪВЕДЕНИЕ  
В настоящото  допълнение  са описани  техническите  изисквания  за 
данните  от GNSS, използвани  от бордовото  устройство , вклю­  
чително  протоколите , които  трябва  да бъдат  приложени  за обез­  
печаване  на сигурно  и правилно  прехвърляне  на данни  за местопо­  
ложението . 
Основните  текстове  в Регламент  (ЕС) № 165/2014 във връзка  с тези 
изисквания  са в следните  негови  членове : „Член  8 Регистриране  на 
местоположението  на превозното  средство  на определени  точки  в 
рамките  на дневното  работно  време “, „Член  10 Интерфейс  с инте­  
лигентни  транспортни  системи “ и „Член  11 Подробни  разпоредби  за 
интелигентните  тахографи “. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 438  
1.1. Обхват  
GNS_1 Бордовото  устройство  трябва  да събира  данни  за местопо­  
ложението  от поне  една  GNSS, които  да служат  за 
изпълнение  на изискването  по член  8. 
Бордовото  устройство  може  да бъде  със или без външно  устройство  
за GNSS, както  е описано  на Figure 1:  
Фигура  1 
Различни  конфигурации  за разположението  на приемника  на сигнали  от GNSS.
  
1.2. Съкращения  и означения  
В настоящото  допълнение  се използват  следните  съкращения : 
DOP Намаление  на точността  при определяне  на местополо­  
жението  
EGF Елементарен  файл  на устройството  за GNSS  
EGNOS Европейска  геостационарна  служба  за навигационно  
покритие  
GNSS Глобална  навигационна  спътникова  система  
GSA DOP и активни  спътници  на GPS  
HDOP Хоризонтално  намаление  на точността  при определяне  на 
местоположението  
ICD Документ  за управление  на интерфейса  
NMEA National Marine Electronics Association ( Национална  
асоциация  за морска  електроника , САЩ ) ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 439  
PDOP Position Dilution of Precision ( позиционно  намаление  на 
точността  при определяне  на местоположението ) 
RMC Recommended Minimum Specific ( препоръчан  минимум  от 
специфични  [GNSS данни ]) 
SIS Signal in Space ( сигнал  от геонавигационни  спътници ) 
VDOP Вертикално  намаление  на точността  при определяне  на 
местоположението  
VU Бордово  устройство  
2. СПЕЦИФИКАЦИЯ  НА ПРИЕМНИКА  НА СИГНАЛИ  ОТ GNSS  
Независимо  дали  конфигурацията  на интелигентния  тахограф  е със 
или без външно  GNSS устройство , осигуряването  на точна  и 
надеждна  информация  за местоположението  е съществен  елемент  
от функционирането  на интелигентния  тахограф . Следователно  е 
целесъобразно  да има изискване  за съвместимост  с услугите , пред­  
оставяни  по програмата  „Галилео “ и програмата  за Европейската  
геостационарна  служба  за навигационно  покритие  (EGNOS), 
определени  в Регламент  (ЕС) № 1285/2013 на Европейския  
парламент  и на Съвета  ( 1 ). Системата , създадена  в рамките  на 
програмата  „Галилео “, е независима  глобална  спътникова  навига­  
ционна  система , а системата , създадена  в рамките  на програмата  
EGNOS, е регионална  спътникова  навигационна  система  за 
подобряване  на качеството  на сигнала  на Глобалната  система  за 
позициониране  (GPS).  
GNS_2 Производителите  трябва  да осигуряват  съвместимост  на 
приемниците  на сигнали  от GNSS с услугите  за определяне  
на местоположението , предоставяни  от системите  
„Галилео “ и EGNOS. Също  така, производителите  могат  
допълнително  да изберат  да има съвместимост  и с други  
навигационни  спътникови  системи . 
GNS_3 Приемникът  на сигнали  от GNSS трябва  да има способност  
да поддържа  автентифициране  в рамките  на отворените  
услуги  на „Галилео “, когато  такива  услуги  бъдат  пред­  
оставяни  от системата  „Галилео “ и бъдат  поддържани  от 
производителите  на приемници  на сигнали  от GNSS. От 
друга  страна  обаче , няма  да се изисква  обновяване  на инте­  
лигентните  тахографи , които  са пуснати  на пазара  преди  
реализирането  на горните  условия  и нямат  способност  да 
поддържат  автентифициране  в рамките  на отворените  
услуги  на „Галилео “. 
3. ИЗРЕЧЕНИЯ  НА NMEA  
В настоящия  раздел  са описани  изреченията  на NMEA, използвани  в 
областта  на функционирането  на интелигентните  тахографи . Посо­  
ченото  в настоящия  раздел  е валидно  и за двата  вида  конфигурации  
на интелигентните  тахографи  — със или без външно  устройство  за 
GNSS.  
GNS_4 Данните  за местоположението  се базират  на изречението  на 
NMEA Recommended Minimum Specific (RMC) GNSS Data 
(препоръчан  минимум  от специфични  GNSS данни ), което  
обхваща  информацията  за местоположението  (географска  
ширина  и дължина ), за времето  във формат  UTC 
(hhmmss.ss) и за скоростта  спрямо  земната  повърхност  
във възли , плюс  допълнителни  величини . 
Форматът  на изречението  RMC е както  следва  (съгласно  стандарта  
на NMEA V4.1 ):  ▼B 
( 1 ) Регламент  (ЕС) № 1285/2013 на Европейския  парламент  и на Съвета  от 11 декември  
2013 г. за изграждане  и експлоатация  на европейските  навигационни  спътникови  
системи  и за отмяна  на Регламент  (ЕО) № 876/2002 на Съвета  и на Регламент  (ЕО) 
№ 683/2008 на Европейския  парламент  и на Съвета  (ОВ L 347, 20.12.2013 г., 
стр. 1).
 02016R0799 — BG — 26.02.2020 — 002.001 — 440  
Фигура  2 
Структура  на изречение  RMC
  
Състоянието  (Status) показва  дали  има наличен  GNSS сигнал . 
Докато  стойността  за състоянието  не стане  A, получените  данни  
(например  за времето  или за географската  ширина /дължина ) не 
могат  да се използват  за записване  в бордовото  устройство  на 
местоположението  на превозното  средство . 
▼M1 
Разделителната  способност  за местоположението  се базира  на 
формата  на гореописаното  изречение  RMC. Първата  част от 
полета  3) и 5) се използва  за посочване  на градусите . Останалото  
пространство  се използва  за посочване  на минутите  с три десетични  
знака . Следователно  разделителната  способност  е 1/1000 от 
минутата  или 1/60000 от градуса  (защото  една  минута  е 1/60 от 
градуса ). 
GNS_5 Бордовото  устройство  трябва  да съхранява  в своята  база 
данни  позиционната  информация  за географска  ширина  и 
дължина  с разделителна  способност  1/10 от минутата  или 
1/600 от градуса , както  е описано  в допълнение  1 за типа  
данни  „географски  координати “. 
За определяне  и записване  на наличието  и точността  на 
сигнал  бордовото  устройство  може  да използва  командата  
за DOP и активните  спътници  на GPS (командата  GSA). 
По-специално , стойността  на HDOP се използва  като 
показател  за степента  на точност  на записаните  данни  за 
местоположението  (вж. 4.2.2). Бордовото  устройство  
трябва  да съхранява  стойността  на хоризонталното  
намаление  на точността  при определяне  на местополо­  
жението  (HDOP), изчислена  като минималната  измежду  
стойностите  на HDOP, получени  от наличните  системи  за 
GNSS.  
Идентификаторът  на системата  за GNSS посочва  съот­  
ветния  идентификатор  на NMEA за всяка  група  спътници  
на GNSS и за спътниковата  система  за диференциална  
корекция  (Satellite- Based Augmentation System, SBAS).  
Фигура  3 
Структура  на изречение  GSA
  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 441  
GNS_6 Изречението  GSA трябва  да бъде  съхранявано  с номер  на 
записа  „02“ — „06“.  
▼B 
GNS_7 Максималният  размер  на изреченията  на NMEA (например  
за RMC, GSA или други ), които  могат  да бъдат  използвани  
във връзка  с оразмеряването  на командата  „read record“, 
трябва  да е 85 байта  (вж. Table 1).  
4. БОРДОВО  УСТРОЙСТВО  С ВЪНШНО  УСТРОЙСТВО  ЗА GNSS  
4.1. Конфигурация  
4.1.1  Основни  компоненти  и интерфейси  
При тази конфигурация  приемникът  на сигнали  от GNSS е част от 
външното  устройство  за GNSS.  
GNS_8 Външното  устройство  за GNSS трябва  да бъде  захранвано  
чрез специфичен  интерфейс  на превозното  средство . 
GNS_9 Външното  устройство  за GNSS трябва  да се състои  от 
следните  компоненти  (вж. Figure 4):  
а) Предлаган  на пазара  приемник  на сигнали  от GNSS за 
осигуряване  на данни  за местоположението  чрез 
интерфейс  за данни  от GNSS. Например , интерфейсът  
за данни  от GNSS може  да бъде  по стандарт  V4.10 на 
NMEA, където  GNSS приемникът  действа  като източник  
на съобщения  (talker) и предава  изречения  на NMEA на 
защитен  GNSS приемопредавател  (трансивер ) с честота  
1 Hz за предварително  дефинирания  набор  от изречения  
на NMEA, който  трябва  да съдържа  поне  изреченията  
RMC и GSA. Начинът  на изпълнение  на интерфейса  за 
данни  от GNSS се избира  от производителите  на 
външни  устройства  за GNSS.  
б) приемопредавателен  модул  (защитен  GNSS приемопред­  
авател ) със способност  да поддържа  стандарт  ISO/IEC 
7816-4:2013 ( вж. 4.2.1) за да комуникира  с бордовото  
устройство , както  и да поддържа  интерфейса  за данни  
от GNSS към приемника  на сигнали  от GNSS. Модулът  
разполага  с памет  за съхранение  на идентификаци­  
онните  данни  на приемника  на сигнали  от GNSS и на 
външното  устройство  за GNSS.  
в) Ограждаща  система  с функция  за откриване  на намес a 
(tamper detection function), която  капсулира  както  
приемника  на сигнали  от GNSS, така и защитения  
GNSS приемопредавател . Функцията  за откриване  на 
манипулиране  трябва  да изпълнява  защитните  мерки  за 
сигурност , в съответствие  с изискванията  на защитния  
профил  на интелигентния  тахограф . 
г) GNSS антена , инсталирана  върху  превозното  средство  и 
свързана  с приемника  на сигнали  от GNSS през ограж­  
дащата  система . 
GNS_10 Външното  устройство  за GNSS разполага  поне  със 
следните  външни  интерфейси : 
а) Интерфейс  към GNSS антената , инсталирана  върху  
корпуса  на превозното  средство , ако се използва  
външна  антена . 
б) Интерфейс  към бордовото  устройство . 
GNS_11 Намиращият  се в бордовото  устройство  защитен  приемо­  
предавател  (трансивер ) на бордовото  устройство  пред­  
ставлява  другият  край  на защитената  връзка  със 
защитения  GNSS приемопредавател  и той трябва  да 
поддържа  стандарта  ISO/IEC 7816-4:2013 за връзката  към 
външното  устройство  за GNSS.  ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 442  
GNS_12 По отношение  на физическия  слой  на връзката  с външното  
устройство  за GNSS, бордовото  устройство  трябва  да 
поддържа  стандарта  ISO/IEC 7816-12:2005 или друг  
стандарт , който  може  да поддържа  ISO/IEC 7816-4:2013. 
(вж. 4.2.1).  
4.1.2  Състоянието  на външното  устройство  за GNSS при завършването  
на производството  му 
GNS_13 При излизането  си от завода  външното  устройство  за GNSS 
трябва  да съхранява  следните  стойности  в енергонезави­  
симата  памет  на защитения  приемопредавател  за GNSS:  
— двойката  ключове  EGF_MA и съответния  сертификат , 
— сертификата  MSCA_VU-EGF, съдържащ  публичния  
ключ  MSCA_VU-EGF.PK, който  се използва  за прове­  
ряване  на сертификата  EGF_MA,  
— сертификата  EUR, съдържащ  публичния  ключ  EUR.PK, 
който  се използва  за проверяване  на сертификата  
MSCA_VU-EGF,  
— ако съществува , сертификата  EUR, чийто  период  на 
валидност  непосредствено  предшества  този сертификат  
EUR, който  се използва  за проверяване  на сертификата  
MSCA_VU-EGF,  
— ако съществува , свързващия  сертификат , който  дава 
връзка  между  тези два сертификата  EUR,  
— разширения  сериен  номер  на външното  устройство  за 
GNSS,  
— идентификатора  на операционната  система  на устрой­  
ството  за GNSS,  
— номера  на одобрението  на типа  на външното  
устройство  за GNSS,  
— идентификатор  на компонента  за сигурност  на 
външното  устройство  за GNSS.  
4.2. Връзка  между  външното  устройство  за GNSS и бордовото  
устройство  
4.2.1  Протокол  за връзка  
GNS_14 Протоколът  за връзка  между  външното  устройство  за 
GNSS и бордовото  устройство  трябва  да поддържа  
следните  три функции : 
1. Събиране  и разпределяне  на GNSS данни  (например  за 
местоположението , времето , скоростта ), 
2. Събиране  на конфигурационните  данни  за външното  
устройство  за GNSS,  
3. Протокола  за управление , който  да поддържа  купли­  
рането , взаимното  удостоверяване  на автентичността  и 
договарянето  на сесийните  ключове  между  външното  
устройство  за GNSS и бордовото  устройство . 
GNS_15 Протоколът  за връзка  трябва  да се базира  на стандарта  
ISO/IEC 7816-4:2013, като защитеният  приемопредавател  
на бордовото  устройство  играе  ролята  на главно  
устройство , а защитеният  приемопредавател  за GNSS 
играе  ролята  на подчинено  устройство . Физическата  
връзка  между  външното  устройство  за GNSS и бордовото  
устройство  се базира  на стандарта  ISO/IEC 7816-12:2005 
или друг  стандарт , който  може  да поддържа  ISO/IEC 
7816-4:2013.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 443  
GNS_16 В протокола  за връзка  не трябва  да се поддържат  полета  с 
увеличена  дължина . 
▼B 
GNS_17 Протоколът  за връзка  по стандартите  ISO 7816 ( съответно  
*-4:2013 и *-12:2005) между  външното  устройство  за GNSS 
и бордовото  устройство  трябва  да бъде  зададен  с T=1.  
▼M1 
GNS_18 По отношение  на функциите : 1) събиране  и разпределяне  
на GNSS данни , 2) събиране  на конфигурационните  данни  
за външното  устройство  за GNSS и 3) протокол  за управ­  
ление , защитеният  приемопредавател  за GNSS трябва  да 
симулира  карта  с чип с архитектура  на файловата  
система , състояща  се от главен  файл  (Master File, MF), 
специализиран  файл  (Dedicated File, DF) с идентификатор  
на приложенията , специфициран  в допълнение  1, глава  6.2 
(‘FF 44 54 45 47 4D’), 3 елементарни  файла , съдържащи  
сертификати , и един  единичен  елементарен  файл  (EF.EGF) 
с идентификатор , равен  на „2F2F“, както  е описано  в 
таблица  1. 
▼B 
GNS_19 Защитеният  GNSS приемопредавател  трябва  да съхранява  
във файла  EF.EGF данните , идващи  от приемника  на 
сигнали  от GNSS, и конфигурацията . Този  файл  пред­  
ставлява  линеен  файл  с променлива  дължина  и е с иденти­  
фикатор  равен  на ‘2F2F’ в шестнадесетичен  формат . 
▼M1 
GNS_20 Паметта , използвана  от защитения  приемопредавател  за 
GNSS за съхраняване  на данните , трябва  да може  да 
изпълни  поне  20 милиона  цикъла  запис /четене . С 
изключение  на този аспект , вътрешната  конструкция  и 
изпълнението  на защитения  приемопредавател  за GNSS е 
по усмотрение  на производителите . 
Разпределянето  на номерата  на записите  и данните  в 
паметта  е дадено  в таблица  1. Отбележете , че съществуват  
пет изречения  GSA за GNSS и за спътниковата  система  за 
диференциална  корекция  (SBAS).  
▼B 
GNS_21 Файловата  структура  е дадена  в Table 1. По отношение  на 
условията  за достъп  (ALW, NEV, SM-MAC) вж. 
допълнение  2, глава  3.5.  
Таблица  1 
Файлова  структура  
Условия  за достъп  
Файл  Идентификатор  
на файла  Четене  Актуализация  Криптиран  
MF 3F00  
EF.ICC  0002  ALW  NEV 
(чрез VU)  Не 
DF GNSS Facility  0501  ALW  NEV  Не 
EF EGF_MACertificate  C100  ALW  NEV  Не 
EF CA_Certificate  C108  ALW  NEV  Не 
EF Link_Certificate  C109  ALW  NEV  Не 
EF.EGF  2F2F  SM-MAC  NEV 
(чрез VU)  Не ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 444  
Файл  / елемент  от данни  Номер  на записа  Размер  (байтове ) Стойности  по 
подразбиране  
Мин . Макс . 
MF 552  1 031  
EF.ICC  
sensorGNSSSerialNumber  8  8  
DF GNSS Facility  612  1 023  
EF EGF_MACertificate  204  341  
EGFCertificate  204  341  {00..00}  
EF CA_Certificate  204  341  
MemberStateCertificate  204  341  {00..00}  
EF Link_Certificate  204  341  
LinkCertificate  204  341  {00..00}  
EF.EGF  
изречение  RMC NMEA  ‘01’  85  85  
1-во RMC NMEA изречение  ‘02’  85  85  
2-ро GSA NMEA изречение  ‘03’  85  85  
3-то GSA NMEA изречение  ‘04’  85  85  
4-то GSA NMEA изречение  ‘05’  85  85  
5-то GSA NMEA изречение  ‘06’  85  85  
Разширен  сериен  номер  на 
външното  устройство  за GNSS, 
дефиниран  в допълнение  1 като 
SensorGNSSSerialNumber.  ‘07’ 8  8  
Идентификатор  на операционната  
система  на защитения  приемопред­  
авател  за GNSS, дефиниран  в 
допълнение  1 като SensorOSIdenti ­
fier. ‘08’ 2  2  
Номер  на одобрението  на типа  на 
външното  устройство  за GNSS, 
дефиниран  в допълнение  1 като 
SensorExternalGNSSApproval ­
Number.  ‘09’ 16  16  
Идентификатор  на компонента  за 
сигурност  на външното  устройство  
за GNSS, дефиниран  в допълнение  
1 като SensorExternalGNSSSCIden ­
tifier  ‘10’ 8  8  
RFU — Запазен  за бъдещо  използване  От ‘11’ до ‘FD’  
4.2.2  Защитено  прехвърляне  на данни  от GNSS  
GNS_22 Защитеното  прехвърляне  на получени  от GNSS данни  за 
местоположението  трябва  да се допуска  само  при 
следните  условия : 
1. Завършен  процес  на куплиране , както  е описано  в 
допълнение  11. Общи  механизми  за сигурност . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 445  
2. Периодично  взаимно  удостоверяване  на автентичността  
и договаряне  на сесийни  ключове  между  бордовото  
устройство  и външното  устройство  за GNSS, също  
описано  в допълнение  11. Общите  механизми  за 
сигурност  трябва  да са изпълнени  с посочената  перио­  
дичност . 
GNS_23 На всеки  T секунди , където  T е със стойност  по-малка  или 
равна  на 10, освен  когато  се провежда  куплиране  или 
взаимно  удостоверяване  на автентичността  и договаряне  
на сесийни  ключове , бордовото  устройство  иска  от 
външното  устройство  за GNSS информацията  за местопо­  
ложението  въз основа  на следния  поток  от данни : 
1. Бордовото  устройство  иска  от външното  устройство  за 
GNSS данни  за местоположението , заедно  с данни  за 
намалението  на точността  (от изречението  GSA 
NMEA). Защитеният  приемопредавател  на бордовото  
устройство  използва  командата  SELECT and READ 
RECORD(S) по ISO/IEC 7816-4:2013 при защитен  
обмен  на съобщения  в режим  „само  с удостоверяване  
на автентичността “ (authentication-only mode), както  е 
описано  в допълнение  11, раздел  11.5, с идентификатор  
на файла  „2F2F“ и RECORD номер  равен  на ‘01’ за 
изречение  RMC NMEA и съответно  ‘02’, ‘03’, ‘04’, 
‘05’, ‘06’ за изречение  GSA NMEA.  
2. Последната  получена  информация  за местоположението  
се съхранява  в елементарния  файл  с идентификатор  
‘2F2F’ и в записите  в защитения  GNSS приемопред­  
авател , описани  в таблица  1, като защитеният  GNSS 
приемопредавател  получава  NMEA данни  с честота  
поне  1 Hz от GNSS приемника  посредством  интерфейса  
за GNSS данни . 
3. Защитеният  GNSS приемопредавател  изпраща  отговора  
до защитения  приемопредавател  на бордовото  
устройство  като използва  ответно  APDU съобщение  
при защитен  обмен  на съобщения  в режим  „само  с удос­  
товеряване  на автентичността “, както  е описано  в 
допълнение  11, раздел  11.5.  
4. Защитеният  приемопредавател  на бордовото  устройство  
проверява  автентичността  и целостта  на получения  
отговор . При положителен  резултат  от тази проверка  
данните  за местоположението  се прехвърлят  в 
процесора  на бордовото  устройство  посредством  
интерфейса  за GNSS данни . 
▼M1 
5. Процесорът  на бордовото  устройство  проверява  полу­  
чените  данни  и извлича  информация  (например  
географска  ширина , дължина , време ) от изречението  
RMC NMEA. Изречението  RMC NMEA включва  
информация  дали  местоположението  е валидно . Ако 
местоположението  не е валидно , данните  за местополо­  
жението  все още не са достъпни  и не могат  да се 
използват  за записване  на местоположението  на 
превозното  средство . Ако местоположението  е 
валидно , процесорът  на бордовото  устройство  извлича  
от изреченията  GSA NMEA и стойностите  на HDOP и 
изчислява  средната  стойност  по наличните  спътникови  
системи  (т.е. когато  има налично  фиксиране ). 
▼B 
6. Процесорът  на бордовото  устройство  съхранява  в 
бордовото  устройство  получената  и обработена  инфор­  
мация , например  за географската  ширина , дължина , 
време  и скорост  във формата , дефиниран  в допълнение  
1 Data Dictionary като GeoCoordinates заедно  със стой­  
ността  на HDOP, изчислена  като минималната  измежду  
стойностите  на HDOP, получени  от наличните  системи  
за GNSS.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 446  
4.2.3  Структура  на командата  Read Record  
В настоящия  раздел  е описана  подробно  структурата  на командата  
Read Record. Добавя  се защитен  обмен  на съобщения  (в режим  само  
с удостоверяване  на автентичността ), както  е описан  в допълнение  
11 „Общи  механизми  за сигурност “. 
GNS_24 Командата  трябва  да поддържа  защитен  обмен  на 
съобщения  (в режим  само  с удостоверяване  на автентич­  
ността ), вж. допълнение  11. 
GNS_25 Командно  съобщение  
Байт  Дължи­  
на Стойно­  
ст Описание  
CLA  1  ‘0Ch’  Поискан  е защитен  обмен  на съобщения . 
INS 1  ‘B2h’  Read Record  
P1 1  ‘XXh’  Номер  на записа  (номерът  ‘00’ е на 
текущия  запис ) 
P2 1  ‘04h’  Прочитане  на записа  с посочения  в P1 
номер . 
Le 1  ‘XXh’  Дължина  на очакваните  данни . Брой  на 
байтовете , които  трябва  да се извлекат  
GNS_26 Посоченият  в P1 запис  става  текущ  запис . 
Байт  Дължи­  
на Стойност  Описание  
#1-#X  X  ‘XX..XXh’  Извлечени  данни  
SW 2  ‘XXXXh’  Байтове  за състоянието  (SW1, SW2)  
— Ако командата  бъде  изпълнена  успешно , защитеният  
GNSS приемопредавател  отговаря  с ‘9000 ’. 
— Ако текущият  файл  не е предназначен  за записи , защи­  
теният  GNSS приемопредавател  отговаря  с ‘6981 ’. 
— Ако командата  се използва  с P1 = ‘00’ но няма  текущ  
елементарен  файл , защитеният  GNSS приемопредавател  
отговаря  с ‘6986 ’ (неразрешена  команда ). 
— Ако записът  не е намерен , защитеният  GNSS приемо­  
предавател  отговаря  с ‘6A 83 ’. 
— Ако външното  устройство  за GNSS открие  манипу­  
лиране , то трябва  да отговори  с израза  за състояние  
‘66 90 ’. 
GNS_27 Защитеният  GNSS приемопредавател  трябва  да поддържа  
следните  команди  за тахографи  от поколение  2, специфи­  
цирани  в допълнение  2: 
Команда  Препратка  
Select  Допълнение  2, глава  3.5.1  
Read Binary  Допълнение  2, глава  3.5.2  
Get Challenge  Допълнение  2, глава  3.5.4  
PSO: Verify Certificate  Допълнение  2, глава  3.5.7  
External Authenticate  Допълнение  2, глава  3.5.9  
General Authenticate  Допълнение  2, глава  3.5.10  
MSE:SET  Допълнение  2, глава  3.5.11  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 447  
4.3. Куплиране , взаимно  удостоверяване  на автентичността  и дого­  
варяне  на сесийни  ключове  на външното  устройство  за GNSS с 
бордовото  устройство  
Куплирането , взаимно  удостоверяване  на автентичността  и догова­  
рянето  на сесийни  ключове  на външното  устройство  за GNSS с 
бордовото  устройство  са описани  в допълнение  11 „Общи  механизми  
за сигурност “, глава  11. 
4.4. Третиране  на грешки  
В настоящия  раздел  е описано  как се третират  и записват  в 
бордовото  устройство  потенциалните  състояния  на грешка  от 
страна  на външното  устройство  за GNSS.  
4.4.1  Грешка  във връзката  с външното  устройство  за GNSS  
▼M1 
GNS_28 Ако бордовото  устройство  не успее  да установи  връзка  с 
куплираното  външно  устройство  за GNSS в течение  на 
повече  от 20 последователни  минути , бордовото  устройство  
трябва  да генерира  и регистрира  в себе си събитие  от типа  
EventFaultType с изброена  (enum) стойност  ‘0E’H — Грешка  
в комуникацията  с външното  устройство  за GNSS, и с времеви  
печат , съответстващ  на текущото  време . Събитието  се 
генерира  само  ако са изпълнени  следните  две условия : а) инте­  
лигентният  тахограф  не е в режим  на калибриране  и б) 
превозното  средство  е в движение . В този случай  регистри­  
рането  на грешка  във връзката  се задейства , когато  защи­  
теният  приемопредавател  на бордовото  устройство  не 
получи  съобщение , съдържащо  отговор , след  изпращането  
на съобщение  със заявка , както  е описано  в раздел  4.2. 
▼B 
4.4.2  Нарушение  на физическата  цялост  на външното  устройство  за 
GNSS  
▼M1 
GNS_29 Ако целостта  на външното  устройство  за GNSS бъде  
нарушена , защитеният  приемопредавател  за GNSS трябва  да 
изтрие  цялата  си памет , включително  криптографския  
материал . Както  е описано  в раздели  GNS_25 и GNS_26, 
бордовото  устройство  трябва  да констатира  наличие  на 
вмешателство , ако отговорът  е със статус  ‘6690’. В такъв  
случай  бордовото  устройство  трябва  да генерира  събитие  от 
типа  EventFaultType с изброена  (enum) стойност  ‘19’H — 
Установяване  на вмешателство  в GNSS. Като  алтернатива , 
външното  устройство  за GNSS може  повече  да не отговаря  
на други  външни  заявки . 
▼B 
4.4.3  Липса  на информация  за местоположението  от приемник  на 
сигнали  от GNSS  
▼M1 
GNS_30 Ако защитеният  приемопредавател  за GNSS не получава  
данни  от приемника  на сигнали  от GNSS в течение  на 
повече  от 3 последователни  часа, защитеният  при- 
емопредавател  за GNSS трябва  да генерира  съобщение , 
съдържащо  отговор  на командата  READ RECORD, с номер  
на записа  (RECORD), равен  на ‘01’, и с поле  за данни  от 12 
байта , всички  със стойност  0xFF. При получаване  на 
съдържащо  отговор  съобщение  с тази стойност  в полето  за 
данни , бордовото  устройство  трябва  да генерира  и регистрира  
събитие  от типа  EventFaultType с изброена  (enum) стойност  
‘0D’H — Липса  на информация  за местоположението  от 
приемник  на сигнали  от GNSS, с времеви  печат , съответстващ  
на текущото  време , само  ако са изпълнени  следните  две 
условия : а) интелигентният  тахограф  не е в режим  на калиб­  
риране  и б) превозното  средство  е в движение . 
▼B 
4.4.4  Изтекъл  сертификат  на външното  устройство  за GNSS  
GNS_31  ►M1 Ако установи , че използваният  за взаимно  удостове­  
ряване  на автентичността  сертификат  EGF вече не е валиден , 
бордовото  устройство  трябва  да генерира  и регистрира  
събитие , свързано  с уредите  за регистриране  на данни  за 
движението , от типа  EventFaultType с изброена  (enum) 
стойност  ‘1B’H — Изтекъл  сертификат  на външно  
устройство  за GNSS , с времеви  печат , съответстващ  на 
текущото  време . При това бордовото  устройство  трябва  да 
продължи  да използва  получаваните  от GNSS данни  за 
местоположението . ◄ ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 448  
Фигура  4 
Схема  на външно  устройство  за GNSS
  
5. БОРДОВО  УСТРОЙСТВО  БЕЗ ВЪНШНО  УСТРОЙСТВО  ЗА GNSS  
5.1. Конфигурация  
При този вид конфигурация  приемникът  за сигнали  от GNSS е вътре  
в бордовото  устройство , както  е описано  в Figure 1.  
GNS_32 Приемникът  за сигнали  от GNSS действа  като източник  на 
съобщения  (talker) и предава  изречения  NMEA на 
процесора  на бордовото  устройство , който  действа  като 
приемник  (listener) с честота  по-голяма  или равна  на 
1/10 Hz на предварително  дефинирания  набор  от 
изречения  на NMEA, който  трябва  да съдържа  поне  изре­  
ченията  RMC и GSA.  
GNS_33 Към бордовото  устройство  се свързва  външна  GNSS 
антена , инсталирана  върху  превозното  средство , или 
вътрешна  GNSS антена . 
5.2. Третиране  на грешки  
5.2.1  Липса  на информация  за местоположението  от приемник  на 
сигнали  от GNSS  
▼M1 
GNS_34 Ако бордовото  устройство  не получи  данни  от приемника  
на сигнали  от GNSS в течение  на повече  от 3 послед­  
ователни  часа, бордовото  устройство  трябва  да генерира  
и регистрира  събитие  от типа  EventFaultType с изброена  
(enum) стойност  ‘0D’H — Липса  на информация  за 
местоположението  от приемник  на сигнали  от GNSS, с 
времеви  печат , съответстващ  на текущото  време , само  ако 
са изпълнени  следните  две условия : а) интелигентният  
тахограф  не е в режим  на калибриране  и б) превозното  
средство  е в движение . 
6. ВРЕМЕВИ  КОНФЛИКТ  В ДАННИТЕ  ОТ GNSS  
Ако установи  несъответствие , по-дълго  от 1 минута , между  пока­  
занията  на функцията  за измерване  на времето  на бордовото  
устройство  и данните  за времето , постъпващи  от приемника  на 
сигнали  от GNSS, бордовото  устройство  трябва  да регистрира  
събитие  от типа  EventFaultType с изброена  (enum) стойност  ‘0B’H 
— Времеви  конфликт  (GNSS/вътрешния  часовник  на бордовото  
устройство ). След  задействане  на събитие  на времеви  конфликт  
през следващите  12 часа бордовото  устройство  не проверява  за 
времеви  конфликт . Това  събитие  не трябва  да се предизвиква , ако 
през последните  30 дни от приемника  на сигнали  от GNSS не е 
можел  да бъде  открит  валиден  сигнал  от GNSS.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 449  
7. ПРОТИВОРЕЧИЕ  В ДАННИТЕ  ЗА ДВИЖЕНИЕТО  НА 
ПРЕВОЗНОТО  СРЕДСТВО  
GNS_35 Бордовото  устройство  генерира  и регистрира  събитие  за 
противоречие  в данните  за движението  на превозното  
средство  (вж. изискване  84 в настоящото  допълнение ) с 
времеви  печат , съответстващ  на текущото  време , в случай  
че информацията  за движението , изчислена  от датчика  за 
движение , противоречи  на информацията  за движението , 
изчислена  от вътрешния  приемник  на сигнали  от GNSS 
или съответно  от външното  устройство  за GNSS. За 
целите  по откриване  на такива  противоречия  трябва  да 
бъде  използвана  стойността  на медианата  на разликите  в 
данните  за скоростта  от тези източници , както  е посочено  
по-долу : 
— Най-много  на всеки  10 секунди  трябва  да се изчислява  
разликата  между  данните  за скоростта  на превозното  
средство , оценена  от GNSS, и скоростта , оценена  от 
датчика  за движение . 
— За изчисление  на стойността  на медианата  трябва  да се 
използват  всички  изчислени  стойности  във времеви  
прозорец , съдържащ  последните  пет минути  от движе­  
нието . 
— Стойността  на медианата  трябва  да се изчислява  като 
средна  стойност  на 80 % от числата , оставащи  след  
елиминиране  на най-големите  по абсолютна  стойност  
числа . 
Събитие  за противоречие  в данните  за превозното  средство  
трябва  да се задейства  ако стойността  на медианата  е над 
10 км/час за пет последователни  минути  от движението  на 
превозното  средство . Като  опционна  възможност  могат  да 
се използват  други  независими  източници  на данни  за 
движението  на превозното  средство , така че да се 
осигури  по-надеждно  разкриване  на манипулации  на 
тахографа . (Забележка : използването  на стойността  на 
медианата  за последните  5 минути  се прилага  за смек­  
чаване  на риска  от силно  отличаващи  се измерени  
резултати  и преходни  стойности ). Този  вид събитие  не 
трябва  да се задейства  при следните  условия : а) при преми­  
наване  с ферибот /влак , б) когато  няма  достъпна  
информация  за местоположението  от приемника  на 
сигнали  от GNSS и в) при режим  на калибриране . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 450  
Допълнение  13 
ИНТЕРФЕЙС  С ITS  
СЪДЪРЖАНИЕ  
1. ВЪВЕДЕНИЕ  
2. ОБХВАТ  
2.1. Съкращения , определения  и обозначения  
3. ПОЗОВАВАНИЯ  НА РЕГЛАМЕНТИ  И СТАНДАРТИ  
4. ПРИНЦИПИ  НА ФУНКЦИОНИРАНЕ  НА ИНТЕРФЕЙСА  
4.1. Предварителни  условия  за прехвърляне  на данни  чрез интерфейса  с 
ITS 
4.1.1 Данни , предоставяни  чрез интерфейса  с ITS  
4.1.2 Съдържание  на данните  
4.1.3 Приложения  за ITS  
4.2. Съобщителна  технология  
4.3. Разрешаване  на достъпа  чрез PIN  
4.4. Формат  на съобщенията  
4.5. Съгласие  на водача  
4.6. Извличане  на стандартни  данни  
4.7. Извличане  на лични  данни  
4.8. Извличане  на данни  за събития  и неизправности  
1. ВЪВЕДЕНИЕ  
В настоящото  допълнение  се определят  проектирането  и проце­  
дурите , които  трябва  да се следват  за осъществяването  на интерфейса  
с интелигентни  транспортни  системи  (ИТС , по-долу  ITS от Intelligent 
Transport Systems), изисквана  съгласно  член  10 от Регламент  (ЕС) № 
165/2014 ( Регламентът ). 
В Регламента  е посочено , че тахографите  на превозни  средства  могат  
да бъдат  оборудвани  със стандартни  интерфейси , позволяващи  регис­  
трираните  или генерираните  от тахограф  данни  да се използват  в 
работен  режим  от външно  устройство , когато  са изпълнени  
следните  условия : 
а) интерфейсът  не засяга  истинността  и цялостността  на данните  от 
тахографа ; 
б) интерфейсът  съответства  на подробните  разпоредби  по член  11; 
в) външното  устройство , свързано  с интерфейса , има достъп  до 
лични  данни , включително  данни  за местоположението , само  
след  получаване  на съгласието  на водача , за когото  се отнасят  
данните , като даването  на съгласие  трябва  да може  да се удос­  
товери . 
2. ОБХВАТ  
В настоящото  допълнение  е определен  начинът , по който  прило­  
жения , поддържани  от външни  устройства , могат  да получат  чрез 
връзка  Bluetooth® данни  (данните ) от даден  тахограф . 
Данните , предоставяни  чрез този интерфейс , са описани  в 
приложение  1 към настоящия  документ . Този  интерфейс  не възпре­  
пятства  прилагането  на други  интерфейси  (напр . чрез CAN bus) за 
предаване  на данни  от бордовото  устройство  (VU) към други  бордови  
средства  за обработка  на данни . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 451  
В настоящото  допълнение  са определени : 
— Данните , предоставяни  чрез интерфейса  с ITS  
— Профилът  на връзката  Bluetooth®, която  се използва  за 
прехвърляне  на данните  
— Процедурите  за запитване  и изтегляне  на данни  и последовател­  
ността  на операциите  
— Механизмът  за „сдвояване “ (pairing) между  тахографа  и външното  
устройство  
— Предоставяният  на водача  механизъм  за даване  на съгласие  
▼M1 
Трябва  да се поясни , че в настоящото  допълнение  не са определени : 
— събирането  и управлението  на данните  в рамките  на бордовото  
устройство  (които  са определени  на друго  място  в регламента  
или — ако не е така — зависят  от проектирането  на съответния  
продукт ), 
— формата  на представяне  на събраните  данни  на приложенията , 
поддържани  от външното  устройство , 
— мерките  за сигурност  на данните  извън  предоставяните  от Blue­
tooth® (като например  криптиране ), отнасящи  се за съдържанието  
на данните  (които  са определени  на друго  място  в регламента  
[общите  механизми  за сигурност  от допълнение  11]),  
— протоколите  за Bluetooth®, използвани  от интерфейса  с ITS.  
▼B 
2.1. Съкращения , определения  и обозначения  
В настоящото  допълнение  са използвани  следните  съкращения  и 
определения , които  са специфични  за него : 
връзката  обменът  на информация /данни  между  главно  
устройство  (т.е. тахографа ) и външно  устройство  
чрез интерфейса  с ITS по Bluetooth®.  
данните  наборите  данни , определени  в приложение  1. 
Регламентът  Регламент  (ЕС) № 165/2014 на Европейския  
парламент  и на Съвета  от 4 февруари  2014 г. 
относно  тахографите  в автомобилния  транспорт , за 
отмяна  на Регламент  (ЕИО ) № 3821/85 на Съвета  
относно  контролните  уреди  за регистриране  на 
данните  за движението  при автомобилен  транспорт  и 
за изменение  на Регламент  (ЕО) № 561/2006 на Евро­  
пейския  парламент  и на Съвета  за хармонизиране  на 
някои  разпоредби  от социалното  законодателство , 
свързани  с автомобилния  транспорт  
BR Basic Rate ( основна  скорост ) 
EDR  Enhanced Data Rate ( повишена  скорост  за предаване  на 
данни ) 
GNSS  Global Navigation Satellite System („ Глобална  навига­  
ционна  спътникова  система “) 
IRK  Identity Resolution Key  
ITS Intelligent Transport System ( интелигентна  транспортна  
система  — ИТС ) 
LE Low Energy ( ниска  енергия ) 
PIN (ПИН ) Personal Identification Number ( персонален  идентифи­  
кационен  номер ) 
PUC  Personal Unblocking Code („ персонален  код за дебло­  
киране “) 
SID Service Identifier ( идентификатор  на услугата ) 
SPP Serial Port Profile ( профил  на сериен  порт ) ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 452  
SSP Secure Simple Pairing ( защитено  опростено  сдвояване ) 
TRTP  Transfer Request Parameter ( параметър  на заявката  за 
прехвърляне  на данни ) 
TREP  Transfer Response Parameter ( параметър  на отговора  за 
прехвърляне  на данни ) 
VU Vehicle Unit ( бордово  устройство ) 
3. ПОЗОВАВАНИЯ  НА РЕГЛАМЕНТИ  И СТАНДАРТИ  
Спецификацията , определена  в настоящото  допълнение , се отнася  до 
и зависи  от всички  или части  от посочените  по-долу  регламенти  и 
стандарти . В разделите  от настоящото  допълнение  са посочени  
относимите  стандарти  или относимите  раздели  на стандарти . В 
случай  на противоречие  разделите  на настоящото  допълнение  имат  
предимство . 
Настоящото  допълнение  съдържа  позовавания  на следните  
регламенти  и стандарти : 
— Регламент  (ЕС) № 165/2014 на Европейския  парламент  и на 
Съвета  от 4 февруари  2014 г. относно  тахографите  в автомо­  
билния  транспорт , за отмяна  на Регламент  (ЕИО ) № 3821/85 на 
Съвета  относно  контролните  уреди  за регистриране  на данните  за 
движението  при автомобилен  транспорт  и за изменение  на 
Регламент  (ЕО) № 561/2006 на Европейския  парламент  и на 
Съвета  за хармонизиране  на някои  разпоредби  от социалното  
законодателство , свързани  с автомобилния  транспорт  
— Регламент  (ЕО) № 561/2006 на Европейския  парламент  и на 
Съвета  от 15 март  2006 г. за хармонизиране  на някои  разпоредби  
от социалното  законодателство , свързани  с автомобилния  
транспорт , за изменение  на Регламенти  (ЕИО ) № 3821/85 и (ЕО) 
№ 2135/98 на Съвета  и за отмяна  на Регламент  (ЕИО ) № 3820/85 
на Съвета  
— ISO 16844 — 4: Пътни  превозни  средства . Тахографски  системи . 
Част  4: Интерфейс  на CAN мрежа  
— ISO 16844 — 7: Пътни  превозни  средства . Тахографски  системи . 
Част  7: Параметри  
— Bluetooth® — профил  на сериен  порт  — V1.2  
— Bluetooth® — основна  версия  4.2 
— Протокол  NMEA 0183 V4.1  
4. ПРИНЦИПИ  НА ФУНКЦИОНИРАНЕ  НА ИНТЕРФЕЙСА  
4.1. Предварителни  условия  за прехвърляне  на данни  чрез  
интерфейса  с ITS  
От бордовото  устройство  (VU) се изисква  да актуализира  и да 
поддържа  данните , които  трябва  да се съхраняват  в него , без 
никакво  участие  на интерфейса  с ITS. Средството , чрез което  се 
постига  това, е вътрешно  за VU и е определено  другаде  в Регламента , 
а не в настоящото  допълнение . 
4.1.1  Данни , предоставяни  чрез интерфейса  с ITS 
От VU се изисква  да актуализира  данните , които  ще бъдат  пред­  
оставяни  чрез интерфейса  с ITS, с честота , определена  в рамките  на 
процедурите  на VU, без никакво  участие  на интерфейса  с ITS. 
Данните  във VU се използват  като основа  за получаване  и актуали­  
зиране  на данните , като начинът  за постигане  на това е определен  
другаде  в Регламента , а ако не е определен  там, се определя  не в 
настоящото  допълнение , а при проектирането  на съответния  продукт . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 453  
4.1.2  Съдържание  на данните  
Съдържанието  на данните  трябва  да е съгласно  приложение  1 към 
настоящото  допълнение . 
4.1.3  Приложения  за ITS 
Приложенията  за ITS ще използват  данни , предоставени  чрез 
интерфейса  с ITS — например  за оптимизиране  на управлението  на 
дейностите  на водача , като същевременно  се спазва  Регламентът , за 
откриване  на евентуални  неизправности  в тахографа  или за 
използване  на данни  от GNSS. Спецификацията  на приложенията  
не попада  в обхвата  на настоящото  допълнение . 
4.2. Съобщителна  технология  
Обменът  на данни  чрез интерфейса  с ITS се извършва  посредством  
интерфейс  Bluetooth®, който  е съвместим  с версия  4.2 или по-късна . 
Bluetooth® функционира  в нелицензираната  радиочестотна  лента  от 
2,4 до 2,485 GHz за промишлени , научни  и медицински  (ISM) цели . 
Bluetooth ® 4.2 осигурява  усъвършенствани  механизми  за неприкос­  
новеност  на личния  живот  и сигурност , а също  така повишава  
скоростта  и надеждността  на прехвърлянето  на данни . За целите  на 
настоящата  спецификация  се използва  радиовръзка  Bluetooth® клас 2 
с обсег  до 10 метра . Повече  информация  относно  Bluetooth ® 4.2 е 
налична  на www.bluetooth.com (https://www.bluetooth.org/en-us/specifi ­
cation/adopted-specificati ­
ons?_ga=1.215147412.2083380574.1435305676).  
Връзката  със съобщителното  оборудване  се установява , след  като 
главното  устройство  приключи  процеса  на сдвояване . Тъй като при 
Bluetooth® се използва  модел  главен /подчинен , за да се контролира  
кога и къде  устройствата  могат  да изпращат  данни , тахографът  ще 
изпълнява  ролята  на главно  устройство , а външното  устройство  — на 
подчинено . 
▼M1 
Процесът  на сдвояване  за връзка  Bluetooth® може  да започне , когато  
външно  устройство  попадне  в обсега  на бордовото  устройство  за 
първи  път (вж. също  приложение  2). Устройствата  споделят  своите  
адреси , наименования  и профили , както  и общ таен ключ , който  им 
позволява  в бъдеще  винаги  да се съчетават , когато  са в близост . След  
като бъде  завършена  тази стъпка , външното  устройство  придобива  
статут  на доверено  и е в състояние  да отправи  заявки  за изтегляне  
на данни  от тахографа . Не се предвижда  да се добавят  още 
механизми  за криптиране  извън  предоставяното  от Bluetooth®. Ако 
са необходими  обаче  допълнителни  механизми  за сигурност , те се 
осъществяват  в съответствие  с общите  механизми  за сигурност  от 
допълнение  11. 
▼B 
Общият  принцип  на връзка  е онагледен  на следващата  фигура .
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 454  
За прехвърляне  на данни  от VU към външното  устройство  се 
използва  профилът  SPP (Serial Port Profile) на Bluetooth®.  
4.3. Разрешаване  на достъпа  чрез  PIN  
▼M1 
От съображения  за сигурност  бордовото  устройство  изисква  система  
за разрешаване  на достъпа  чрез PIN код, която  е отделена  от сдвоя­  
ването  по Bluetooth. Всяко  бордово  устройство  трябва  да е в 
състояние  да генерира  PIN кодове , съставени  от най-малко  4 
цифри , за целите  на удостоверяването  на автентичността . Всеки  
път, когато  външно  устройство  се сдвоява  с бордовото  устройство , 
то трябва  да подаде  правилния  PIN код, преди  да получи  каквито  и да 
било  данни . 
▼B 
Когато  устройството  подаде  успешно  PIN, то се включва  в позитивен  
списък  (whitelist). В позитивния  списък  трябва  да се съхраняват  данни  
за най-малко  64 устройства , сдвоени  с конкретното  VU.  
Ако устройството  три пъти  подред  подаде  неправилен  PIN код, то се 
включва  временно  в „черен  списък “. Докато  устройството  е в черния  
списък , всеки  нов опит  от негова  страна  се отхвърля . Ако след  това 
устройството  подаде  още три пъти  подред  неправилен  PIN код, това 
води  до все по-продължителна  забрана  на достъпа  (виж таблица  1). 
Подаването  на правилния  PIN код нулира  продължителността  на 
забраната  за достъп  и броя  на опитите . Във фигура  1 в приложение  
2 е дадена  диаграма  на последователността  при опит  за валидиране  на 
PIN. 
Таблица  1 
Продължителност  на забраната  в зависимост  от броя  на 
поредните  неуспешни  опити  за подаване  на правилния  PIN код 
Брой  на поредните  неуспешни  опити  Продължителност  на забраната  
3 30 секунди  
6 5 минути  
9 1 час 
12 24 часа 
15 Постоянна  
Ако ITS устройството  петнадесет  пъти  (5 × 3) подред  подаде  
неправилен  PIN код, то се включва  за постоянно  в черния  списък . 
Тази  постоянна  забрана  се отменя  само  с подаването  на правилния  
PUC код. 
PUC кодът  се състои  от 8 цифри  и се предоставя  от производителя  
заедно  с VU. Ако ITS устройството  десет  пъти  подред  подаде  
неправилен  PUC код, то се включва  неотменимо  за постоянно  в 
черния  списък . 
▼M1 
Производителят  може  да предлага  възможност  за промяна  на PIN 
кода  пряко  чрез бордовото  устройство , но PUC кодът  не може  да 
се променя . Ако изменението  на PIN кода  е възможно , за целта  се 
изисква  текущият  PIN код да бъде  въведен  пряко  в бордовото  
устройство . 
▼B 
Освен  това всички  устройства , данни  за които  се съхраняват  в пози­  
тивния  списък , се запазват , докато  не бъдат  заличени  ръчно  от 
ползвателя  (напр . чрез интерфейса  човек —машина  на VU или с 
други  средства ). По този начин  загубени  или откраднати  устройства  
на ITS могат  да бъдат  отстранени  от позитивния  списък . Също  така 
всяко  ITS устройство , напуснало  обсега  за връзка  по Bluetooth за 
повече  от 24 часа, автоматично  се отстранява  от позитивния  списък  
на VU и трябва  да подаде  отново  правилния  PIN код, когато  връзката  
се възстанови . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 455  
Форматът  на съобщенията  между  интерфейса  на VU и самото  VU не 
се определя , а е по усмотрение  на производителя . Въпросният  
производител  трябва  обаче  да гарантира  спазването  на формата  за 
съобщенията  между  ITS устройството  и интерфейса  на VU (виж 
спецификациите  за ASN.1).  
По този начин  всяка  заявка  за прехвърляне  на данни  се посреща  с 
надлежна  проверка  на пълномощията  на подателя  преди  каквато  и да 
била  форма  на обработване . Във фигура  2 в приложение  2 е дадена  
диаграма  на последователността  за тази процедура . Всяко  устройство , 
включено  в черния  списък , се отхвърля  автоматично , а всяко  
устройство , което  не фигурира  нито  в черния , нито  в позитивния  
списък , получава  заявка  за PIN, която  трябва  да изпълни  преди  да 
изпрати  пак своята  заявка  за прехвърляне  на данни . 
4.4. Формат  на съобщенията  
Всички  съобщения , разменяни  между  ITS устройството  и VU, трябва  
да са форматирани  със структура  от следните  три части : заглавна  част 
(header), съставена  от байт  за целевото  устройство  (TGT), байт  за 
източника  (SRC) и байт  за дължина  (LEN);  
поле  за данни , съдържащо  един  байт  за идентификатора  на услугата  
(SID) и променлив  брой  байтове  с данни  (максимум  255);  
байт  за контролната  сума  (CS) — серия  от еднобайтови  суми  по 
модул  256, които  представляват  всички  байтове  на съобщението  с 
изключение  на самата  контролна  сума . 
Съобщението  трябва  да бъде  във формат  Big Endian.  
Таблица  2 
Общ  формат  на съобщенията  
Заглавна  част Поле  за данни  Контролна  
сума  
TGT  SRC  LEN  SID  TRTP  CC  CM  DATA 
(ДАННИ ) CS 
3 байта  Макс . 255 байта  1 байт  
Заглавна  част  
TGT и SRC: идентификатор  (ID) съответно  на целевото  (Target — 
TGT) и изходното  (Source — SRC) устройство  за съобщението . 
Интерфейсът  на VU трябва  по подразбиране  да е с ID „EE“. Този  
ID не може  да се променя . Устройството  на ITS използва  по подраз­  
биране  за ID „A0“ за своето  първо  съобщение  от сесията  на връзка . 
След  това интерфейсът  на VU присвоява  уникален  ID на ITS устрой­  
ството  и го уведомява  за този ID с оглед  на бъдещи  съобщения  по 
време  на сесията . 
Байтът  LEN отчита  само  частта  DATA на полето  за данни  (виж 
таблица  2), като първите  4 байта  са имплицитни . 
Интерфейсът  на VU потвърждава  автентичността  на подателя  на 
съобщението  чрез кръстосана  проверка  на своя  списък  на идентифи­  
катори  (IDList) с данните  по Bluetooth, като проверява  дали  ITS 
устройството , фигуриращо  в списъка  за предоставения  ID, понас­  
тоящем  в обсега  на връзката  по Bluetooth.  
Поле  за данни  
Освен  SID полето  за данни  съдържа  и други  параметри : параметър  на 
заявката  за прехвърляне  на данни  (TRTP) и броячни  байтове . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 456  
Ако данните , които  трябва  да се пренасят , са твърде  дълги  спрямо  
наличното  пространство  в едно  съобщение , те се разделят  в няколко  
подсъобщения . Всяко  подсъобщение  е с една  и съща  заглавна  част и 
SID, но съдържа  брояч  от 2 байта  — Counter Current (CC) и Counter 
Max (CM), който  посочва  номера  на подсъобщението . С цел да се 
осигури  контрол  за грешки  и евентуално  да се прекрати  обменът  на 
данни , приемащото  устройство  потвърждава  получаването  на всяко  
подсъобщение . Приемащото  устройство  може  да потвърди  
приемането  на подсъобщението , да поиска  повторното  му предаване  
или да заяви  възобновяване  или прекратяване  на предаването  на 
данните  от предаващото  устройство . 
▼B 
Ако CC и CM не се използват , те получават  стойността  0xFF.  
Например  следното  съобщение  
HEADER  SID  TRTP  CC  CM  DATA  TC  
3 байта  Дължина , по-голяма  от 255 байта  1 байт  
се предават  като: 
HEADER  SID  TRTP  01  n  DATA  TC  
3 байта  255 байта  1 байт  
HEADER  SID  TRTP  02  n  DATA  TC  
3 байта  255 байта  1 байт  
… 
HEADER  SID  TRTP  N  N  DATA  TC  
3 байта  Макс . 255 байта  1 байт  
Таблица  3 съдържа  съобщенията , които  VU и ITS устройството  
трябва  да са в състояние  да обменят . Съдържанието  на всеки  
параметър  е дадено  в шестнадесетична  бройна  система . За яснота  в 
таблицата  не са представени  CC и CM, виж по-горе за пълния  
формат . 
Таблица  3 
Подробно  съдържание  на съобщението  
Съобщение  Заглавна  част DATA  Контрол­  
на сума  
TGT  SRC  LEN  SID  TRTP  DATA  
RequestPIN  ITSID  EE  00  01  FF  
SendITSID  ITSID  EE  01  02  FF  ITSID  
SendPIN  EE  ITSID  04  03  FF  4*INTEGER, т.е. 
цяло  число  (0..9)  
PairingResult  ITSID  EE  01  04  FF  BOOLEAN (T/F), 
т.е. булева  
стойност  T за 
„вярно “ и F за 
„невярно “ 
SendPUC  EE  ITSID  08  05  FF  8*INTEGER (0..9)  ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 457  
Съобщение  Заглавна  част DATA  Контрол­  
на сума  
TGT  SRC  LEN  SID  TRTP  DATA  
BanLiftingResult  ITSID  EE  01  06  FF  BOOLEAN (T/F)  
RequestRejected  ITSID  EE  08  07  FF  Час 
RequestData  
standardTachData  EE  ITSID  01  08  01  
personalTachData  EE  ITSID  01  08  02  
gnssData  EE  ITSID  01  08  03  
standardEventData  EE  ITSID  01  08  04  
personalEventData  EE  ITSID  01  08  05  
standardFaultData  EE  ITSID  01  08  06  
manufacturerData  EE  ITSID  01  08  07  
ResquestAccepted  ITSID  EE  Len  09  TREP  Данни  
DataUnavailable  
Няма  налични  
данни  ITSID  EE  02  0A  TREP  10  
Не се споделят  
лични  данни  ITSID  EE  02  0A  TREP  11  
NegativeAnswer  
Общ  отказ  ITSID  EE  02  0B  SID Req  10  
Несъвместима  
услуга  ITSID  EE  02  0B  SID Req  11  
Несъвместима  
подфункция  ITSID  EE  02  0B  SID Req  12  
Неправилна  
дължина  на 
съобщението  ITSID  EE  02  0B  SID Req  13  
Неправилни  
условия  или 
грешка  в послед­  
ователността  на 
заявката  ITSID  EE  02  0B  SID Req  22  
Заявка  извън  
обсега  ITSID  EE  02  0B  SID Req  31  
Изчакване  на 
отговор  ITSID  EE  02  0B  SID Req  78  
Несъответствие  
на ITSID  ITSID  EE  02  0B  SID Req  FC  
Неоткриваем  
ITSID  ITSID  EE  02  0B  SID Req  FB  
RequestPIN (SID 01)  
Това  съобщение  се издава  от интерфейса  на VU, ако ITS устройство , 
което  не фигурира  в черния  списък , но не фигурира  и в позитивния  
списък , заяви  данни . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 458  
SendITSID (SID 02)  
Това  съобщение  се издава  от интерфейса  на VU винаги  когато  ново  
устройство  изпрати  заявка . Това  устройство  използва  за ID „A0“ по 
подразбиране  преди  да му се присвои  уникален  ID за сесията  на 
връзка . 
SendPIN (SID 03)  
Това  съобщение  се издава  от ITS устройството , за да бъде  включено  в 
позитивния  списък  от интерфейса  на VU. Съдържанието  на това 
съобщение  е код от 4 цели  числа  (INTEGER) между  0 и 9. 
PairingResult (SID 04)  
Това  съобщение  се издава  от интерфейса  на VU, за да уведоми  ITS 
устройството , ако изпратеният  от последното  PIN код е верен . Съдър­  
жанието  на това съобщение  е булева  стойност  „True“ за верен  PIN 
код и „False“ в противен  случай . 
SendPUC (SID 05)  
Това  съобщение  се издава  от ITS устройството , за да бъде  извадено  
от черния  списък  от интерфейса  на VU. Съдържанието  на това 
съобщение  е код от 8 цели  числа  (INTEGER) между  0 и 9. 
BanLiftingResult (SID 06)  
Това  съобщение  се издава  от интерфейса  на VU, за да уведоми  ITS 
устройството , ако изпратеният  от последното  PUC код е верен . 
Съдържанието  на това съобщение  е булева  стойност  „True“ за 
верен  PUC код и „False“ в противен  случай . 
RequestRejected (SID 07)  
Това  съобщение  се издава  от интерфейса  на VU в отговор  на всяко  
съобщение  от включено  в черния  списък  ITS устройство  с 
изключение  на съобщението  „SendPUC“. В съобщението  се посочва  
още колко  време  ITS устройството  ще остане  в черния  списък , като 
се спазва  форматът  на последователността  „Time“, определен  в 
приложение  3. 
RequestData (SID 08)  
Това  съобщение  със заявка  за достъп  до данни  се издава  от ITS 
устройството . Еднобайтов  параметър  на заявката  за прехвърляне  на 
данни  (TRTP) указва  вида  на заявените  данни . Има няколко  вида  
данни : 
— standardTachData (TRTP 01): налични  данни  от тахографа , класи­  
фицирани  като нелични . 
— personalTachData (TRTP 02): налични  данни  от тахографа , класи­  
фицирани  като лични . 
— gnssData (TRTP 03): данни  от GNSS, които  винаги  са лични . 
— standardEventData (TRTP 04): записани  данни  за събития , класи­  
фицирани  като нелични . 
— personalEventData (TRTP 05): записани  данни  за събития , класи­  
фицирани  като лични . 
— standardFaultData (TRTP 06): записани  данни  за неизправности , 
класифицирани  като нелични . 
— manufacturerData (TRTP 07): данни , предоставени  от произво­  
дителя . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 459  
Вж. приложение  3 към настоящото  допълнение  за повече  
информация  относно  съдържанието  на всеки  вид данни . 
Виж  допълнение  12 за повече  информация  относно  формата  и съдър­  
жанието  на данните  от GNSS.  
Вж. приложения  IБ и IB за повече  информация  за кодове  на данни  за 
събития  и неизправности . 
RequestAccepted (SID 09)  
Това  съобщение  се издава  от интерфейса  на VU, ако се приеме  
съобщение  „RequestData“ на ITS устройството . Това  съобщение  
съдържа  еднобайтов  параметър  на отговора  за прехвърляне  на 
данни  (TREP), който  представлява  TRTP байтът  на съответното  
съобщение  RequestData, и всички  данни  от заявения  вид. 
DataUnavailable (SID 0A)  
Това  съобщение  се издава  от интерфейса  на VU, ако по някаква  
причина  заявените  данни  не са на разположение  за изпращане  на 
включено  в позитивния  списък  ITS устройство . Съобщението  
съдържа  еднобайтов  TREP, който  представлява  TRTP на заявените  
данни , и еднобайтов  код за грешка , определен  в таблица  3. 
Прилагат  се следните  кодове : 
— Няма  налични  данни  (10): интерфейсът  на VU няма  достъп  до 
данните  на VU по неуточнени  причини . 
— Не се споделят  лични  данни  (11): ITS устройството  се опитва  да 
извлече  лични  данни , когато  те не са споделени . 
NegativeAnswer (SID 0B)  
Тези  съобщения  се издават  от интерфейса  на VU, ако дадена  заявка  
не може  да бъде  изпълнена  по причини , различни  от липсата  на 
данни . Тези  съобщения  обикновено  се дължат  на неправилен  
формат  на заявката  (по отношение  на дължина , SID, ITSID…), но 
не само  на това. TRTP в полето  за данни  съдържа  SID на заявката . 
Полето  за данни  съдържа  код, идентифициращ  причината  за отрица­  
телния  отговор . Прилагат  се следните  кодове : 
— General Reject, т.е. общ отказ  (код: 10)  
— Действието  не може  да се изпълни  по причина , която  не е 
посочена  по-долу , нито  в раздел  … (да се впише  номерът  на 
раздела  за DataUnavailable).  
— Service not supported, т.е. несъвместима  услуга  (код: 11)  
— SID на заявката  не е разпознат . 
— Sub function not supported, т.е. несъвместима  подфункция  (код: 12)  
— TRTP на заявката  не е разпознат . Например  той може  да липсва  
или да е извън  приетите  стойности . 
— Incorrect message length, т.е. неправилна  дължина  на съобщението  
(код: 13)  
— Дължината  на полученото  съобщение  е неправилна  (несъот­  
ветствие  между  байта  LEN и действителната  дължина  на съоб­  
щение ). 
— Conditions not correct or request sequence error, т.е. неправилни  
условия  или грешка  в последователността  на заявката  (код: 22)  
— Заявената  услуга  не е налична  или последователността  на съоб­  
щенията  за заявката  е неправилна . 
— Request out of range, т.е. заявка  извън  обсега  (код: 33) ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 460  
— Записът  за параметрите  на заявката  (полето  за данни ) не е 
валиден . 
— Response pending, т.е. изчакване  на отговор  (код: 78)  
— Заявеното  действие  не може  да бъде  изпълнено  в определеното  
време  и VU няма  готовност  да приеме  друга  заявка . 
— ITSID  Mismatch ( код: FB)  
— След  сравнение  с информацията  по Bluetooth е установено  несъот­  
ветствие  на ITSID на SRC с устройството , за което  се отнася . 
— ITSID  Not Found ( код: FC)  
— ITSID на SRC не е свързан  с никакво  устройство . 
Редове  1—72 ( FormatMessageModule ) на кода  ASN. 1 в приложение  
3 определят  формата  на съобщенията , както  е описано  в таблица  3. 
Повече  подробности  относно  съдържанието  на съобщенията  се дава 
по-долу . 
4.5. Съгласие  на водача  
Всички  налични  данни  са класифицирани  или като стандартни , или 
като лични . Личните  данни  са достъпни  само  ако водачът  е дал 
своето  съгласие  личните  данни  от неговия  тахограф  да напускат  
мрежата  на превозното  средство  за използване  от приложения  на 
трети  страни . 
Водачът  дава съгласието  си, когато  при първото  вкарване  на своята  
карта  на водач  или на карта  за монтаж  и настройки , която  към 
момента  е неизвестна  за бордовото  устройство , титулярят  на 
картата  бъде  приканен  да изрази  своето  съгласие  за подаване  на 
лични  данни  от тахографа  посредством  незадължителния  интерфейс  
с ITS (виж също  приложение  IВ, точка  3.6.2).  
Състоянието  по отношение  на даването  на съгласие  (дадено  или не) 
се записва  в паметта  на тахографа . 
В случай  на екип  от няколко  водача , по интерфейса  с ITS се споделят  
личните  данни  само  на водачите , които  са дали  съгласието  си за това. 
Например  ако превозното  средство  е с двама  водачи  и само  първият  
от тях се е съгласил  да споделя  личните  си данни , не се споделят  
личните  данни , отнасящи  се за втория  водач . 
4.6. Извличане  на стандартни  данни  
На фигура  3 от приложение  2 се дават  диаграми  на последовател­  
ността  на валидна  заявка , изпратена  от ITS устройството  за достъп  до 
стандартни  данни . Ако ITS устройството  надлежно  фигурира  в пози­  
тивния  списък  и заявката  не е за лични  данни , не е необходима  по- 
нататъшна  проверка . Диаграмите  са с оглед , че вече е изпълнена  
правилната  процедура , показана  на фигура  2 от приложение  2. Те 
могат  да бъдат  отъждествени  със сивата  клетка  REQUEST 
TREATMENT  във фигура  2. 
Измежду  наличните  данни  за стандартни  се считат  следните : 
— standardTachData (TRTP 01)  
— StandardEventData (TRTP 04)  
— standardFaultData (TRTP 06)  
4.7. Извличане  на лични  данни  
Във фигура  4 от приложение  2 е дадена  диаграма  на последовател­  
ността  за обработката  на заявката  за лични  данни . Както  вече беше  
посочено , интерфейсът  на VU изпраща  лични  данни  само  ако водачът  
е дал своето  изрично  съгласие  (виж също  4.5). В противен  случай  
заявката  трябва  да бъде  отхвърлена  автоматично . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 461  
Измежду  наличните  данни  за лични  се считат  следните : 
— personalTachData (TRTP 02)  
— gnssData (TRTP 03)  
— personalEventData (TRTP 05)  
— manufacturerData (TRTP 07)  
4.8. Извличане  на данни  за събития  и неизправности  
ITS устройствата  трябва  да могат  да заявяват  данни  относно  събития  
със списък  на всички  неочаквани  събития . Тези  данни  се считат  за 
стандартна  или за лични  — виж приложение  3. Съдържанието  на 
данните  за всяко  събитие  е в съответствие  с документацията , пред­  
оставена  в приложение  1 към настоящото  допълнение . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 462  
ПРИЛОЖЕНИЕ  1 
▼M1 
1) СПИСЪК НА ДАННИТЕ , ПРЕДОСТАВЯНИ  ЧРЕЗ ИНТЕРФЕЙСА С 
ITS 
▼C2 
Данни  Източник Класификация 
на данните 
(лични /нелични ) 
VehicleIdentificationNumber  Бордово устройство нелични 
CalibrationDate  Бордово устройство нелични 
TachographVehicleSpeed speed instant t Бордово устройство лични 
Driver1WorkingState Selector driver  Бордово устройство лични 
Driver2WorkingState  Бордово устройство лични 
DriveRecognize Speed Threshold detected  Бордово устройство нелични 
Driver1TimeRelatedStates Weekly day time  Карта на водач лични 
Driver2TimeRelatedStates  Карта на водач лични 
DriverCardDriver1 Бордово устройство нелични 
DriverCardDriver2 Бордово устройство нелични 
OverSpeed Бордово устройство лични 
TimeDate  Бордово устройство нелични 
HighResolutionTotalVehicleDistance  Бордово устройство нелични 
ServiceComponentIdentification  Бордово устройство нелични 
ServiceDelayCalendarTimeBased  Бордово устройство нелични 
Driver1Identification  Карта на водач лични 
Driver2Identification  Карта на водач лични 
NextCalibrationDate  Бордово устройство нелични 
Driver1ContinuousDrivingTime  Карта на водач лични 
Driver2ContinuousDrivingTime  Карта на водач лични 
Driver1CumulativeBreakTime  Карта на водач лични 
Driver2CumulativeBreakTime  Карта на водач лични 
Driver1CurrentDurationOfSelectedActivity  Карта на водач лични 
Driver2CurrentDurationOfSelectedActivity  Карта на водач лични 
SpeedAuthorised Бордово устройство нелични 
TachographCardSlot1  Карта на водач нелични 
TachographCardSlot2  Карта на водач нелични 
Driver1Name Карта на водач лични 
Driver2Name Карта на водач лични  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 463  
Данни  Източник  Класификация  
на данните  
(лични /нелични ) 
OutOfScopeCondition  Бордово  устройство  нелични  
ModeOfOperation  Бордово  устройство  нелични  
Driver1CumulatedDrivingTimePreviousAndCur ­
rentWeek  Карта  на водач  лични  
Driver2CumulatedDrivingTimePreviousAndCur ­
rentWeek  Карта  на водач  лични  
EngineSpeed  Бордово  устройство  лични  
RegisteringMemberState  Бордово  устройство  нелични  
VehicleRegistrationNumber  Бордово  устройство  нелични  
Driver1EndOfLastDailyRestPeriod  Карта  на водач  лични  
Driver2EndOfLastDailyRestPeriod  Карта  на водач  лични  
Driver1EndOfLastWeeklyRestPeriod  Карта  на водач  лични  
Driver2EndOfLastWeeklyRestPeriod  Карта  на водач  лични  
Driver1EndOfSecondLastWeeklyRestPeriod  Карта  на водач  лични  
Driver2EndOfSecondLastWeeklyRestPeriod  Карта  на водач  лични  
Driver1CurrentDailyDrivingTime  Карта  на водач  лични  
Driver2CurrentDailyDrivingTime  Карта  на водач  лични  
Driver1CurrentWeeklyDrivingTime  Карта  на водач  лични  
Driver2CurrentWeeklyDrivingTime  Карта  на водач  лични  
Driver1TimeLeftUntilNewDailyRestPeriod  Карта  на водач  лични  
Driver2TimeLeftUntilNewDailyRestPeriod  Карта  на водач  лични  
Driver1CardExpiryDate  Карта  на водач  лични  
Driver2CardExpiryDate  Карта  на водач  лични  
Driver1CardNextMandatoryDownloadDate  Карта  на водач  лични  
Driver2CardNextMandatoryDownloadDate  Карта  на водач  лични  
TachographNextMandatoryDownloadDate  Бордово  устройство  нелични  
Driver1TimeLeftUntilNewWeeklyRestPeriod  Карта  на водач  лични  
Driver2TimeLeftUntilNewWeeklyRestPeriod  Карта  на водач  лични  
Driver1NumberOfTimes9hDailyDrivingTimesEx ­
ceeded  Карта  на водач  лични  
Driver2NumberOfTimes9hDailyDrivingTimesEx ­
ceeced  Карта  на водач  лични  ▼C2
 02016R0799 — BG — 26.02.2020 — 002.001 — 464  
Данни  Източник  Класификация  
на данните  
(лични /нелични ) 
Driver1CumulativeUninterruptedRestTime  Карта  на водач  лични  
Driver2CumulativeUninterruptedRestTime  Карта  на водач  лични  
Driver1MinimumDailyRest  Карта  на водач  лични  
Driver2MinimumDailyRest  Карта  на водач  лични  
Driver1MinimumWeeklyRest  Карта  на водач  лични  
Driver2MinimumWeeklyRest  Карта  на водач  лични  
Driver1MaximumDailyPeriod  Карта  на водач  лични  
Driver2MaximumDailyPeriod  Карта  на водач  лични  
Driver1MaximumDailyDrivingTime  Карта  на водач  лични  
Driver2MaximumDailyDrivingTime  Карта  на водач  лични  
Driver1NumberOfUsedReducedDailyRestPeriods  Карта  на водач  лични  
Driver2NumberOfUsedReducedDailyRestPeriods  Карта  на водач  лични  
Driver1RemainingCurrentDrivingTime  Карта  на водач  лични  
Driver2RemainingCurrentDrivingTime  Карта  на водач  лични  
GNSS position  Бордово  устройство  лични  
▼B 
2) НЕПРЕКЪСНАТИ  ДАННИ  ОТ GNSS, ПРЕДОСТАВЯНИ  СЛЕД  
СЪГЛАСИЕТО  НА ВОДАЧА  
Виж  допълнение  12 — GNSS.  
3) ПРЕДОСТАВЯНИ  БЕЗ СЪГЛАСИЕТО  НА ВОДАЧА  КОДОВЕ  ЗА 
СЪБИТИЯ  
Събитие  Правила  за съхраняване  на данните  Данни , които  се регистрират  при всяко  събитие  
Вкарване  на невалидна  
карта  — десетте  най-скорошни  събития . — дата и час на събитието , 
— тип на картата (ите), номер , държава  
членка , издала  картата , и поколение  на 
картата , предизвикваща  събитието . 
— брой  сходни  събития , възникнали  същия  
ден 
Конфликт , предизвикан  от 
карта  — десетте  най-скорошни  събития . — дата и час на началото  на събитието , 
— дата и час на края  на събитието , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), и 
поколение  на двете  карти , пред­  
извикващи  събитието . 
Неправилно  приключване  
на последната  картова  
сесия  — десетте  най-скорошни  събития . — дата и час на вкарване  на картата , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), поколение , 
— данни  относно  последната  сесия  така, 
както  са прочетени  от картата : 
— дата и час на вкарване  на картата , 
— VRN, държава  членка  на регистрация  
и поколение  на бордовото  устрой­  
ство. ▼C2
 02016R0799 — BG — 26.02.2020 — 002.001 — 465  
Събитие  Правила  за съхраняване  на данните  Данни , които  се регистрират  при всяко  събитие  
Прекъсване  на електри­  
ческото  захранване  (2) — най-продължителното  събитие  
за всеки  от десетте  последни  
дни на възникване  на това 
събитие , 
— петте  най-продължителни  
събития  през последните  365 
дни. — дата и час на началото  на събитието , 
— дата и час на края  на събитието , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), както  и 
поколение  на всяка  карта , вкарана  в 
началото  и/или в края  на събитието , 
— брой  сходни  събития , възникнали  същия  
ден. 
Грешка  в комуникацията  с 
устройството  за връзка  от 
разстояние  — най-продължителното  събитие  
за всеки  от десетте  последни  
дни на възникване  на това 
събитие , 
— петте  най-продължителни  
събития  през последните  365 
дни. — дата и час на началото  на събитие , 
— дата и час на края  на събитието , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), както  и 
поколение  на всяка  карта , вкарана  в 
началото  и/или в края  на събитието , 
— брой  сходни  събития , възникнали  същия  
ден. 
Липса  на информация  за 
местоположението  от 
приемник  на сигнали  от 
GNSS  — най-продължителното  събитие  
за всеки  от десетте  последни  
дни на възникване  на това 
събитие , 
— петте  най-продължителни  
събития  през последните  365 
дни. — дата и час на началото  на събитие , 
— дата и час на края  на събитието , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), както  и 
поколение  на всяка  карта , вкарана  в 
началото  и/или в края  на събитието , 
— брой  сходни  събития , възникнали  същия  
ден. 
▼M1 
Грешка  в комуникацията  с 
външното  устройство  за 
GNSS  — най-продължителното  събитие  
за всеки  от последните  10 дни 
на възникване , 
— 5-те най-продължителни  
събития  през последните  365 
дни. — дата и час на началото  на събитие , 
— дата и час на края  на събитие , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), както  и 
поколение  на всяка  карта , вкарана  в 
началото  и/или в края  на събитието , 
— брой  сходни  събития , възникнали  същия  
ден. 
▼B 
Грешка  в данните  за 
движението  — най-продължителното  събитие  
за всеки  от десетте  последни  
дни на възникване  на това 
събитие , 
— петте  най-продължителни  
събития  през последните  365 
дни. — дата и час на началото  на събитието , 
— дата и час на края  на събитието , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), както  и 
поколение  на всяка  карта , вкарана  в 
началото  и/или в края  на събитието , 
— брой  сходни  събития , възникнали  същия  
ден. 
Противоречие  в данните  за 
движението  на превозното  
средство  — най-продължителното  събитие  
за всеки  от десетте  последни  
дни на възникване  на това 
събитие , 
— петте  най-продължителни  
събития  през последните  365 
дни. — дата и час на началото  на събитието , 
— дата и час на края  на събитието , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), както  и 
поколение  на всяка  карта , вкарана  в 
началото  и/или в края  на събитието , 
— брой  сходни  събития , възникнали  същия  
ден. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 466  
Събитие  Правила  за съхраняване  на данните  Данни , които  се регистрират  при всяко  събитие  
Опит  за нарушаване  на 
сигурността  десетте  най-скорошни  събития  за 
всеки  тип събитие . — дата и час на началото  на събитието , 
— дата и час на края  на събитие  (ако е от 
значение ), 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), както  и 
поколение  на всяка  карта , вкарана  в 
началото  и/или в края  на събитието , 
— тип събитие . 
Времеви  конфликт  — най-продължителното  събитие  
за всеки  от десетте  последни  
дни на възникване  на това 
събитие , 
— петте  най-продължителни  
събития  през последните  365 
дни. — -уред  за регистриране  на дата и час 
— дата и час по GNSS, 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), както  и 
поколение  на всяка  карта , вкарана  в 
началото  и/или в края  на събитието , 
— брой  сходни  събития , възникнали  същия  
ден. 
4) ПРЕДОСТАВЯНИ  СЪС  СЪГЛАСИЕТО  НА ВОДАЧА  КОДОВЕ  НА 
ДАННИ  ЗА СЪБИТИЯ  
Събитие  Правила  за съхраняване  на данните  Данни , които  се регистрират  при всяко  събитие  
Управление  на МПС  без 
съответната  карта  — най-продължителното  събитие  
за всеки  от десетте  последни  
дни на възникване  на това 
събитие , 
— петте  най-продължителни  
събития  през последните  365 
дни. — дата и час на началото  на събитието , 
— дата и час на края  на събитието , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), както  и 
поколение  на всяка  карта , вкарана  в 
началото  и/или в края  на събитието , 
— брой  сходни  събития , възникнали  
същия  ден. 
Вкарване  на карта  по време  
на управление  на МПС  — последното  събитие  за всеки  
от десетте  последни  дни на 
възникване  на това събитие , — дата и час на събитието , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), поколение , 
— брой  сходни  събития , възникнали  
същия  ден 
Превишаване  на скоростта  
(1) — най-сериозното  събитие  (т.е. 
събитието , при което  е 
достигната  най-висока  средна  
скорост ) през десетте  
последни  дни на възникване  
на това събитие , 
— петте  най-сериозни  събития  
през последните  365 дни. 
— първото  събитие , възникнало  
след  последното  калибриране  — дата и час на началото  на събитието , 
— дата и час на края  на събитието , 
— максимална  скорост , измерена  по време  
на събитието , 
— средноаритметична  скорост , измерена  
по време  на събитието , 
— тип и номер  на картата , държава  членка , 
издала  картата , и поколение  на картата  
на водач  (ако е приложимо ), 
— брой  сходни  събития , възникнали  
същия  ден. 
5) ПРЕДОСТАВЯНИ  БЕЗ СЪГЛАСИЕТО  НА ВОДАЧА  КОДОВЕ  НА 
ДАННИ  ЗА НЕИЗПРАВНОСТИ  
Неизправност  Правила  за съхраняване  на данните  Данни , които  се регистрират  при всяка  
неизправност  
Неизправност  на картата  — десетте  последни  
неизправности  на картата  на 
водач . — дата и час на началото  на неизправ­  
ността , 
— дата и час на края  на неизправността , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), поколение . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 467  
Неизправност  Правила  за съхраняване  на данните  Данни , които  се регистрират  при всяка  
неизправност  
неизправности  в уредите  за 
регистриране  на данните  за 
движението  — десетте  последни  
неизправности  за всеки  тип 
неизправност , 
— първата  неизправност  след  
последното  калибриране . — дата и час на началото  на неизправност , 
— дата и час на края  на неизправност , 
— тип на неизправността , 
— тип и номер  на картата (ите), държава  
членка , издала  картата (ите), както  и 
поколение  на всяка  карта , вкарана  в 
началото  и/или в края  на неизправ­  
ността , 
Тази  неизправност  се предизвиква  от следните  нередности  при режимите , 
различни  от режима  на калибриране : 
— Неизправност  вътре  в бордовото  устройство  
— Неизправност  в печатащото  устройство  
— Неизправност  в дисплея  
— Грешка  при изтегляне  на данни  
— Неизправност  на датчика  
— Неизправност  в приемника  на сигнали  от GNSS или външното  
устройство  за GNSS  
— Неизправност  в устройството  за връзка  от разстояние  
▼M1 
— Неизправност  на интерфейса  с ITS (ако е приложимо ) 
▼B 
6) ПРЕДОСТАВЯНИ  БЕЗ СЪГЛАСИЕТО  НА ВОДАЧА  ДАННИ  ЗА 
СПЕЦИФИЧНИ  ЗА ПРОИЗВОДИТЕЛЯ  СЪБИТИЯ  И 
НЕИЗПРАВНОСТИ  
Събитие  или неизправност  Правила  за съхраняване  на данните  Данни , които  се регистрират  при всяко  събитие  
Определят  се от произво­  
дителя  Определят  се от производителя  Определят  се от производителя  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 468  
ПРИЛОЖЕНИЕ  2 
ДИАГРАМИ  НА ПОСЛЕДОВАТЕЛНОСТТА  НА ОБМЕНА  НА СЪОБЩЕНИЯ  С ITS УСТРОЙСТВОТО  
Фигура  1 
Диаграма  на последователността  при опит  за валидиране  на PIN
  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 469  
Фигура  2 
Диаграма  на последователността  за проверката  на разрешението  на ITS устройството
  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 470  
Фигура  3 
Диаграма  на последователността  на обработката  на заявка  за данни , класифицирани  като  нелични  (след  
правилен  PIN за достъп )
 
Фигура  4 
Диаграма  на последователността  на обработката  на заявка  за данни , класифицирани  като  лични  (след  
правилен  PIN за достъп )
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 471  
Фигура  5 
Диаграма  на последователността  при опит  за валидиране  на PUC
  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 472  
ПРИЛОЖЕНИЕ  3 
СПЕЦИФИКАЦИИ  НА ASN.1
  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 473
  
▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 474
  
▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 475
  
▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 476
  
► (1) M1 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 477
  
► (1) (2) (3)  M1 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 478
  
► (1) M1 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 479
  
► (1) (2) M1 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 480
  
▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 481
  
▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 482
  
► (1) M1 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 483
  
▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 484  
Допълнение  14 
ФУНКЦИЯ  ЗА ВРЪЗКА  ОТ РАЗСТОЯНИЕ  
СЪДЪРЖАНИЕ  
1 ВЪВЕДЕНИЕ  
2 ОБХВАТ  
3 СЪКРАЩЕНИЯ , ОПРЕДЕЛЕНИЯ  И ОБОЗНАЧЕНИЯ  
4 ОПЕРАТИВНИ  СЦЕНАРИИ  
4.1 Преглед  
4.1.1 Условия  за прехвърляне  на данни  чрез интерфейса  към DSRC на 
5,8 GHz  
4.1.2 Профил  1а: чрез ръчно  насочен  или временно  монтиран  край  пътя  
четец  за връзка  с цел ранно  откриване  
4.1.3 Профил  1б: чрез монтиран  на превозно  средство  и насочен  четец  за 
връзка  с цел ранно  откриване  (REDCR)  
4.2 Сигурност  и цялост  на данните  
5 СТРУКТУРА  И ПРОТОКОЛИ  ЗА ВРЪЗКАТА  ОТ РАЗСТОЯНИЕ  
5.1 Структура  
5.2 Блоксхема  
5.2.1 Действия  
5.2.2 Тълкуване  на данните , получени  по връзката  DSRC  
5.3 Параметри  на физическия  DSRC интерфейс  за връзка  от разстояние  
5.3.1 Ограничения  за местоположението  
5.3.2 Параметри  на предаването  на данни  в права  и обратна  посока  
5.3.3 Конструкция  на антената  
5.4 Изисквания  по протокола  DSRC за RTM  
5.4.1 Преглед  
5.4.2 Команди  
5.4.3 Последователност  на командите  за разпитване  
5.4.4 Структура  на данните  
5.4.5 Елементи  на RtmData, извършени  действия  и определения  
5.4.6 Механизъм  за прехвърляне  на данни  
5.4.7 Подробно  описание  на транзакцията  по DSRC  
5.4.8 Описание  на изпитването  за транзакция  по DSRC  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 485  
5.6 Прехвърляне  на данни  между  DSRC-VU и VU 
5.6.1 Физическа  връзка  и интерфейси  
5.6.2 Приложен  протокол  
5.7 Третиране  на грешки  
5.7.1 Записване  и съобщаване  на данните  в DSRC-VU  
5.7.2 Грешки  при безжичната  връзка  
6 ИЗПИТВАНИЯ  ЗА ВЪВЕЖДАНЕ  В ЕКСПЛОАТАЦИЯ  И 
ПЕРИОДИЧЕН  ТЕХНИЧЕСКИ  ПРЕГЛЕД  НА ФУНКЦИЯТА  ЗА 
ВРЪЗКА  ОТ РАЗСТОЯНИЕ  
6.1 Общи  положения  
6.2 ECHO  
6.3 Изпитване  за валидиране  на съдържанието  от защитени  данни  
1 ВЪВЕДЕНИЕ  
Настоящото  допълнение  определя  проектирането  и процедурите , 
които  трябва  да се следват  за осъществяването  на функцията  за 
връзка  от разстояние  („връзката “), изисквана  съгласно  член  9 от 
Регламент  (ЕС) № 165/2014 („ Регламентът “). 
DSC_1 В Регламент  (ЕС) № 165/2014 се определя , че тахографът  
трябва  да притежава  функция  за връзка  от разстояние , 
която  да дава възможност  на представители  на компет­  
ентните  контролни  органи  да четат  информация  от 
тахографа  на преминаващи  превозни  средства , изпол­  
звайки  оборудване  за разпитване  от разстояние  (четеца  за 
връзка  с цел ранно  откриване  от разстояние  [REDCR]), 
като това оборудване  осъществява  по-конкретно  
безжична  връзка  на честота  5,8 GHz по интерфейси  CEN 
към специализирани  съобщителни  системи  с малък  обсег  
на действие  (Dedicated Short Range Communication — 
DSRC).  
Важно  е да се разбере , че тази функция  е предназначена  да 
служи  само  като предварителен  филтър , за да се подбират  
превозни  средства  за по-щателна  проверка , и не заменя  
формалния  процес  на контрол , определен  в разпоредбите  
на Регламент  (ЕС) № 165/2014. Виж  съображение  9 в 
преамбюла  към този регламент , което  гласи , че връзката  
от разстояние  за целите  на пътните  проверки  между  тахог­  
рафите  и контролните  органи  улеснява  извършването  на 
целеви  пътни  проверки . 
DSC_2  Данните  се обменят  чрез връзката , която  трябва  да бъде  
безжична  на честота  5,8 GHz с използване  на DSRC 
съгласно  настоящото  допълнение  и изпитана  спрямо  съот­  
ветните  параметри  по EN 300 674-1, {Electromagnetic 
compatibility and Radio spectrum Matters (ERM), т.е. 
въпроси  по електромагнитната  съвместимост  и радиочес­  
тотния  спектър ; Road Transport and Traffic Telematics 
(RTTT), т.е. телематика  за автомобилния  транспорт  и ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 486  
пътното  движение  (RTTT); Dedicated Short Range Commu ­
nication (DSRC) transmission equipment (500 kbit/s / 250 
kbit/s) operating in the 5,8 GHz Industrial, Scientific and 
Medical (ISM) band, т.е. специализирани  съобщителни  
системи  с малък  обсег  на действие  (DSRC) (500 kbit/s / 
250 kbit/s), работещи  в честотната  лента  5,8 GHz за 
промишлени , научни  и медицински  (ISM) цели ; Part 1, 
т.е. част 1: General characteristics and test methods for 
Road Side Units (RSU) and On -Board Units (OBU), т.е. 
общи  характеристики  и методи  за изпитване  на 
крайпътни  устройства  (RSU) и бордови  устройства  
(OBU)}.  
DSC_3  Връзката  със съобщителните  системи  се осъществява  
само  когато  това е заявено  от оборудването  на компет­  
ентния  контролен  орган , използвайки  отговарящи  на 
изискванията  радиосъобщителни  средства  (четеца  за 
връзка  с цел ранно  откриване  от разстояние  (REDCR ). 
DSC_4  Данните  се защитават , за да се гарантира  цялостността  им. 
DSC_5 Достъпът  до съобщените  данни  се ограничава  до компет­  
ентните  контролни  органи , оправомощени  да проверяват  
за нарушенията  на Регламент  (ЕО) № 561/2006 и 
Регламент  (ЕС) № 165/2014, и до сервизите , доколкото  
това е необходимо , за да се провери  правилното  функцио­  
ниране  на тахографа . 
DSC_6 Съобщените  при осъществяване  на връзката  данни  се 
ограничават  до данните , необходими  за извършване  на 
целеви  пътни  проверки  на превозни  средства , при които  
е възможно  манипулиране  или злоупотреба  с тахографа . 
DSC_7 Цялостността  и сигурността  на данните  се постига  чрез 
защита  на данните  в бордовото  устройство  (VU) и чрез 
предаването  само  на защитените  полезни  данни  и данни , 
свързани  със сигурността  (виж 5.4.4), по безжичната  
връзка  от разстояние  на честота  5,8 GHz с DSRC, което  
означава , че само  оправомощени  представители  на компет­  
ентните  контролни  органи  разполагат  с нужните  средства , 
за да разбират  данните , предадени  по връзката , и да 
проверяват  тяхната  автентичност . Виж  допълнение  11 
относно  общите  механизми  за сигурност . 
DSC_8 Данните  трябва  да съдържат  времеви  печат , посочващ  
момента  на последното  им актуализиране . 
DSC_9 Съдържанието  на данните , свързани  със сигурността , 
трябва  да е известно  и да е под контрола  на компетентните  
контролни  органи  и на страните , с които  те споделят  тази 
информация , като то е извън  обхвата  на разпоредбите  
относно  връзката , която  е предмет  на настоящото  допъл­  
нение , освен  ако при връзката  се предвижда  с всеки  пакет  
от полезни  данни  да се предава  и пакет  от данни , свързани  
със сигурността . 
DSC_10 Трябва  да е възможно  използването  на същата  архитектура  
и оборудване  за получаването  на други  концепти  на данни  
(като например  от бордово  устройство  за претегляне ) чрез 
определената  тук архитектура . 
DSC_11 Трябва  да се поясни , че в съответствие  с член  9 от 
Регламент  (ЕС) № 165/2014 ( член  7) по връзката  не се 
предават  данни  за самоличността  на водача . 
2 ОБХВАТ  
Настоящото  допълнение  обхваща  определянето  на начина , по който  
представители  на компетентните  контролни  органи  използват  
специфицирана  безжична  DSRC връзка  на честота  5,8 GHz, за да ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 487  
получат  от разстояние  данни  (данните ) от целево  превозно  
средство , които  удостоверяват , че е възможно  това превозно  
средство  да нарушава  разпоредбите  на Регламент  (ЕС) №165/2014 
и следва  да бъде  набелязано  за спиране  с оглед  на по-нататъшно  
разследване . 
Съгласно  Регламент  (ЕС) №165/2014 събраните  данни  се огра­  
ничават  до данните , които  удостоверяват  възможно  нарушение , 
или са свързани  с тези данни , както  е определено  в член  9 от 
Регламент  (ЕС) № 165/2014.  
▼M1 
В този сценарий  наличното  време  за връзка  е ограничено , тъй като 
връзката  е целева  и е разчетена  за малък  обсег . Освен  това същите  
съобщителни  средства  за наблюдение  на тахографа  от разстояние  
(RTM) могат  да бъдат  използвани  от компетентните  контролни  
органи  и за други  приложения  (например  за максимално  допус­  
тимите  маси  и размери  на тежкотоварни  превозни  средства , 
определени  в Директива  (ЕС) 2015/719), като тези действия  могат  
да бъдат  отделни  или последователни  по преценка  на компет­  
ентните  контролни  органи . 
▼B 
В настоящото  допълнение  се определя : 
— Съобщителното  оборудване , процедури  и протоколи , които  да 
се използват  за връзката  
— Стандартите  и регламентите , на които  трябва  да отговаря  радио­  
техническото  оборудване  
— Представянето  на данните  на оборудването  за връзката  
— Процедурите  за запитване  и изтегляне  на данни  и последовател­  
ността  на операциите  
— Данни , които  трябва  да бъдат  предадени  
— Възможно  тълкуване  на данните , предадени  по връзката  
— Разпоредби  за свързаните  със сигурността  данни , отнасящи  се 
до връзката  
— Предоставянето  на данните  на компетентните  контролни  органи  
— Как четецът  за връзка  с цел ранно  откриване  от разстояние  може  
да заяви  различни  концепти  на данни  за теглото  и други  харак­  
теристики  на превозните  средства  
Трябва  да се поясни , че в настоящото  допълнение  не се определят : 
— събирането  на данни  за функционирането  и управлението  в 
рамките  на бордовото  устройство  (което  се определя  при 
проектирането  на съответния  продукт , освен  ако е посочено  
друго  в Регламент  (ЕС) № 165/2014)  
— формата  на представяне  на събраните  данни  на представителя  на 
компетентните  контролни  органи , нито  критериите , които  да се 
използват  от тези органи  при вземането  на решение  кои 
превозни  средства  да бъдат  спрени  (което  се определя  при 
проектирането  на продукта , освен  ако е посочено  друго  в 
Регламент  (ЕС) № 165/2014 или в решение  за политиката  на 
компетентните  контролни  органи ). За пояснение : данните  се 
предоставят  по връзката  на компетентните  контролни  органи  
само  за да могат  те да вземат  информирани  решения  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 488  
— мерките  за сигурност  на данните  (като например  криптиране ), 
отнасящи  се до съдържанието  на данните  (които  се определят  в 
допълнение  11 относно  общите  механизми  за сигурност ) 
— подробности  за концепти  на данни , различни  от тези при RTM, 
които  могат  да бъдат  получени , използвайки  същата  архитектура  
и оборудване  
— подробности  за поведението  и управлението  между  бордовото  
устройство  (VU) и неговото  средство  за DSRC (DSRC-VU), нито  
за поведението  в рамките  на DSRC-VU ( освен  във връзка  с 
предоставянето  на данните , когато  е заявено  така от REDCR).  
3 СЪКРАЩЕНИЯ , ОПРЕДЕЛЕНИЯ  И ОБОЗНАЧЕНИЯ  
В настоящото  допълнение  се използват  следните  съкращения  и 
определения , които  са специфични  за него : 
Антената  електрическо  устройство , което  
преобразува  електрическата  
енергия  в радиовълни  и обратно , 
използвано  в съчетание  с радио­  
предавател  или радиоприемник . 
Когато  радиопредавателят  е в 
действие , той подава  трептящ  на 
радиочестота  електрически  ток към 
клемите  на антената , която  излъчва  
енергията  от електрическия  ток под 
формата  на електромагнитни  вълни  
(радиовълни ). В режим  на приемане  
антената  прехваща  част от 
енергията  на електромагнитните  
вълни , за да генерира  много  ниско  
напрежение  върху  своите  клеми , 
което  се подава  към приемник  за 
усилване . 
Връзката  обмен  на информация /данни  между  
DSRC-REDCR и DSRC-VU 
съгласно  раздел  5 във взаимоот­  
ношение  „ главен /подчинен “ 
(master-slave) с цел получаване  на 
данните  
Данните  защитени  данни  в определен  
формат  (виж 5.4.4), заявени  от 
DSRC-REDCR  и предоставени  на 
DSRC-REDCR  от DSRC-VU  по 
DSRC връзка  на честота  5,8 GHz 
link, както  е определено  в 5 по-долу  
Регламент  (ЕС) № 165/2014  Регламент  (ЕС) № 165/2014 на 
Европейския  парламент  и на 
Съвета  от 4 февруари  2014 г. 
относно  тахографите  в автомо­  
билния  транспорт , за отмяна  на 
Регламент  (ЕИО ) № 3821/85 на 
Съвета  относно  контролните  уреди  
за регистриране  на данните  за 
движението  при автомобилен  
транспорт  и за изменение  на 
Регламент  (ЕО) № 561/2006 на 
Европейския  парламент  и на 
Съвета  за хармонизиране  на някои  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 489  
разпоредби  от социалното  законо­  
дателство , свързани  с автомобилния  
транспорт  
AID Application Identifier („ иденти­  
фикатор  на приложение “) 
BLE  Bluetooth Low Energy („Bluetooth с 
ниска  енергия “) 
BST  Beacon Service Table („ таблица  за 
навигационните  услуги “) 
CIWD  Card insertion while driving 
(„вкарване  на карта  по време  на 
управление  на МПС “) 
CRC  cyclic redundancy check („ циклична  
контролна  сума “) 
DSC (n)  идентификатор  на изискване  за 
конкретно  допълнение  за DSRC  
DSRC  Dedicated Short Range Communi ­
cation (специализирана  връзка  или 
специализирана  съобщителна  
система  с малък  обсег  на действие ) 
DSRC-REDCR  DSRC — Remote Early Detection 
Communication Reader (DSRC — 
четец  за връзка  с цел ранно  
откриване  от разстояние ) 
DSRC-VU  DSRC — Vehicle Unit (DSRC — 
бордово  устройство ) Това  е „уст­  
ройството  за ранно  откриване  от 
разстояние “, определено  в 
приложение  1В. 
DWVC  Driving without valid card („ уп­ 
равление  на МПС  без валидна  
карта “) 
EID Element Identifier („ идентификатор  
на елемент “) 
LLC  Logical Link Control („ управление  
на логическата  връзка “) 
LPDU  LLC Protocol Data Unit („ единица  
данни  по протокола  LLC“)  
OWS  Onboard Weighing System („ бордова  
система  за претегляне “) 
PDU  Protocol Data Unit („ единица  данни  
по протокола “) 
REDCR  Remote early detection communi ­
cation reader („ четец  за връзка  с 
цел ранно  откриване  от 
разстояние “) Това  е „четящото  
устройство  за връзка  с цел ранно  
откриване  от разстояние “, опред­  
еление  за което  се дава в 
приложение  1В. 
RTM  Remote Tachograph Monitoring („ на­ 
блюдение  на тахографа  от 
разстояние “) 
SM-REDCR  Security Module-Remote early 
detection communication reader 
(„модул  за сигурност  на четеца  за 
връзка  с цел ранно  откриване  от 
разстояние “) 
TARV  Telematics Applications for Regulated 
Vehicles (ISO 15638 series of Stan ­
dards) („Телематични  приложения  
за регулирани  превозни  средства “ 
— серия  от стандарти  ISO 15638)  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 490  
VU Vehicle Unit („ бордово  устройство “) 
VUPM  Vehicle Unit Payload Memory 
(„памет  на бордовото  устройство  
за полезни  данни “) 
VUSM  Vehicle Unit Security Module 
(„модул  за сигурност  на бордовото  
устройство “) 
VST  Vehicle Service Table ( таблица  за 
услуги  във връзка  с превозното  
средство ) 
WIM  Weigh in motion („ претегляне  в 
движение “) 
WOB  Weigh on board („ бордово  претег­  
ляне “) 
Спецификацията , определена  в настоящото  допълнение , се отнася  
до и зависи  от всички  или части  от следните  регламенти  и стан­  
дарти . В разделите  от настоящото  допълнение  са посочени  
относимите  стандарти  или относимите  раздели  на стандарти . В 
случай  на противоречие  разделите  на настоящото  допълнение  
имат  предимство . В случай  на противоречие , когато  в настоящото  
допълнение  липсва  ясно  определена  спецификация , действието  в 
рамките  на ERC 70-03 ( изпитано  по отношение  на съответните  
параметри  по EN 300 674-1) има предимство , последвано  в 
низходяща  последователност  от EN 12795, EN 12253, EN 12834 и 
EN 13372, 6.2, 6.3, 6.4 и 7.1.  
Настоящото  допълнение  съдържа  позовавания  на следните  
регламенти  и стандарти : 
[1] Регламент  (ЕС) № 165/2014 на Европейския  парламент  и на 
Съвета  от 4 февруари  2014 г. относно  тахографите  в автомо­  
билния  транспорт , за отмяна  на Регламент  (ЕИО ) № 3821/85 на 
Съвета  относно  контролните  уреди  за регистриране  на данните  
за движението  при автомобилен  транспорт  и за изменение  на 
Регламент  (ЕО) № 561/2006 на Европейския  парламент  и на 
Съвета  за хармонизиране  на някои  разпоредби  от социалното  
законодателство , свързани  с автомобилния  транспорт . 
[2] Регламент  (ЕО) № 561/2006 на Европейския  парламент  и на 
Съвета  от 15 март  2006 г. за хармонизиране  на някои  
разпоредби  от социалното  законодателство , свързани  с автомо­  
билния  транспорт , за изменение  на Регламенти  (ЕИО ) № 
3821/85 и (ЕО) № 2135/98 на Съвета  и за отмяна  на 
Регламент  (ЕИО ) № 3820/85 на Съвета  (текст  от значение  за 
ЕИП ). 
[3] ERC 70-03 CEPT: ECC Recommendation 70-03: Relating to the 
Use of Short Range Devices (SRD)  
[4] ISO 15638 Intelligent transport systems — Framework for 
cooperative telematics applications for regulated commercial 
freight vehicles (TARV).  
[5] EN 300 674-1 Electromagnetic compatibility and Radio spectrum 
Matters (ERM); Road Transport and Traffic Telematics (RTTT); 
Dedicated Short Range Communication (DSRC) transmission 
equipment (500 kbit/s / 250 kbit/s) operating in the 5,8 GHz Indus ­
trial, Scientific and Medical (ISM) band; Part 1: General characte ­
ristics and test methods for Road Side Units (RSU) and On-Board 
Units (OBU).  
[6] EN 12253 Road transport and traffic telematics — Dedicated short- 
range communication — Physical layer using microwave at 
5.8 GHz.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 491  
[7] EN 12795 Road transport and traffic telematics — Dedicated short- 
range communication — Data link layer: medium access and 
logical link control.  
[8] EN 12834 Road transport and traffic telematics — Dedicated short- 
range communication — Application layer.  
[9] EN 13372 Road transport and traffic telematics — Dedicated short- 
range communication — Profiles for RTTT applications.  
[10] ISO 14906 Electronic fee collection — Application interface defi ­
nition for dedicated short- range communication ( Електронно  
събиране  на такси . Определяне  на приложния  интерфейс  за 
обмен  на информация  на близки  разстояния ). 
4 ОПЕРАТИВНИ  СЦЕНАРИИ  
4.1 Преглед  
Регламент  (ЕС) № 165/2014 предоставя  конкретни  и контролирани  
сценарии , в рамките  на които  да се използва  връзката . 
Поддържат  се следните  сценарии : 
„Communication Profile 1:( Профил  1 за връзката :) Roadside 
inspection using a short range wireless communication Remote Early 
Detection Communication Reader instigating a physical roadside 
inspection (master-:-slave) ( Пътна  проверка , използвайки  четец  за 
връзка  с цел ранно  откриване  от разстояние  чрез съобщителна  
система  с малък  обсег  на действие , която  да предизвика  
физическа  пътна  проверка  (главен -:-подчинен ) 
Reader Profile 1a: ( Профил  1а за четеца :) via a hand aimed or 
temporary roadside mounted and aimed Remote Early Detection 
Communication ( чрез ръчно  насочен  или временно  монтиран  край  
пътя  четец  за връзка  с цел ранно  откриване ) 
Reader Profile 1b: ( Профил  1б за четеца :) via a vehicle mounted and 
directed Remote Early Detection Communication Reader ( чрез 
монтиран  на превозно  средство  и насочен  четец  за връзка  с цел 
ранно  откриване )“. 
4.1.1  Условия  за прехвърляне  на данни  чрез интерфейса  към DSRC на 
5,8 GHz  
ЗАБЕЛЕЖКА : за разбиране  на контекста  за предварителните  
условия  трябва  да се направи  справка  с фигура  14.3 по-долу . 
4.1.1.1 Данни , съхранявани  в бордовото  устройство  (VU)  
DSC_12 От бордовото  устройство  се изисква  да актуализира  на 
всеки  60 секунди  и да поддържа  данните , които  трябва  
да се съхраняват  в него , без никакво  участие  на 
функцията  за специализирана  връзка  с малък  обсег  на 
действие  (DSRC). Това  се постига  по вътрешен  за 
бордовото  устройство  начин , който  е определен  не в 
настоящото  допълнение , а в раздел  3.19 „Връзка  от 
разстояние  за целеви  пътни  проверки “ от приложение  
1В към Регламент  (ЕС) № 165/2014.  
4.1.1.2 Данни , предоставяни  на средството  за DSRC на бордовото  
устройство  (DSRC-VU)  
DSC_13 От бордовото  устройство  се изисква  да актуализира  пред­  
аваните  по DSRC тахографски  данни  (данните ) всеки  път 
когато  съхраняваните  в него  данни  се актуализират  през 
интервала , определен  в точка  4.1.1.1 (DSC_12), без 
никакво  участие  на функцията  за DSRC.  
DSC_14 Данните  в бордовото  устройство  се използват  като основа  
за получаване  и актуализиране  на полезните  данни  (дан­ 
ните ), като начинът  за постигане  на това е определен  в 
раздел  3.19 „Връзка  от разстояние  за целеви  пътни  
проверки “ от приложение  1В, а ако не е определен  там, 
се определя  не в настоящото  допълнение , а при проекти­  
рането  на съответния  продукт . Проектирането  на връзката  
между  средството  за DSRC на бордовото  устройство  и 
самото  бордово  устройство  се разглежда  в раздел  5.6. ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 492  
4.1.1.3 Съдържание  на данните  
DSC_15 Съдържанието  и форматът  на данните  трябва  да бъдат  
такива , че след  тяхното  декриптиране  да са структурирани  
и налични  във форма  и формат , определен  в раздел  5.4.4 
от настоящото  допълнение  („Структури  на данните “). 
4.1.1.4 Представяне  на данните  
DSC_16 Данните , които  се актуализират  често  в съответствие  с 
процедурите , определени  в точка  4.1.1.1, се защитават , 
преди  да бъдат  представени  на DSRC-VU , и се представят  
като защитена  стойност  на концепта  на данните  за 
временно  съхранение  в DSRC-VU  като текуща  версия  на 
данните . Тези  данни  се прехвърлят  от VUSM  (модула  за 
сигурност  на бордовото  устройство ) към DSRC-функцията  
VUPM  (паметта  на бордовото  устройство  за полезни  
данни ). VUSM  и VUPM  представляват  функции , а не 
непременно  физически  обекти . Формата  на физическо  
изпълнение  на тези функции  се определя  при проекти­  
рането  на съответния  продукт , ако не е определена  
другаде  в Регламент  (ЕС) № 165/2014.  
4.1.1.5 Данни , свързани  със сигурността  
DSC_17 Данните , свързани  със сигурността  (securityData ), вклю­  
чително  данните , изисквани  от REDCR, за да придобие  
пълна  способност  да декриптира  данните , се предоставят  
съгласно  допълнение  11 относно  общите  механизми  за 
сигурност  и се представят  като стойност  на концепта  на 
данните  за временно  съхранение  в DSRC-VU  като текуща  
версия  на securityData  във формата , определена  в раздел  
5.4.4 от настоящото  допълнение . 
4.1.1.6 Данни  във VUPM, които  са на разположение  за прехвърляне  по 
интерфейса  към DSRC  
DSC_18 Концептът  на данните , който  трябва  винаги  да е на 
разположение  в DSRC-функцията  VUPM за незабавно  
прехвърляне  по заявка  от REDCR , е определен  в раздел  
5.4.4 за пълните  спецификации  на модула  ASN.1.  
Общ  преглед  на профил  1 за връзката  
Този  профил  обхваща  случаите  на употреба , когато  представител  на 
компетентните  контролни  органи  използва  четец  за връзка  с цел 
ранно  откриване  от разстояние  чрез съобщителна  система  с малък  
обсег  на действие  (с DSRC интерфейси  на 5,8 GHz, функциониращи  
в рамките  на ERC 70-03 и изпитани  по отношение  на съответните  
параметри  по EN 300 674-1, както  е описано  в раздел  5) ( REDCR ), 
за да идентифицира  от разстояние  превозно  средство , което  евен­  
туално  нарушава  разпоредбите  на Регламент  (ЕС) №165/2014. След  
като контролиращият  разпитването  за данни  представител  на 
компетентните  контролни  органи  идентифицира  превозното  
средство , той решава  дали  това превозно  средство  следва  да бъде  
спряно . 
4.1.2  Профил  1а: чрез ръчно  насочен  или временно  монтиран  край  пътя  
четец  за връзка  с цел ранно  откриване  
В този случай  представителят  на компетентните  контролни  органи  
се намира  край  пътя  и насочва  от там държан  с ръка , монтиран  
върху  триножник  или подобен  преносим  REDCR  към центъра  на 
предното  стъкло  на целевото  превозно  средство . За разпитването  
се използват  DSRC интерфейси  на 5,8 GHz, функциониращи  в 
рамките  на ERC 70-03 и изпитани  по отношение  на съответните  
параметри  по EN 300 674-1, както  е описано  в раздел  5. Виж  
фигура  14.1 (случай  № 1 на употреба ). ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 493  
Фигура  14.1  
Крайпътно  разпитване  за данни  чрез  DSRC на 5,8 GHz
  
4.1.3  Профил  1б: чрез монтиран  на превозно  средство  и насочен  четец  
за връзка  с цел ранно  откриване  (REDCR)  
В този случай  представителят  на компетентните  контролни  органи  
се намира  в движещо  се превозно  средство  и насочва  държан  с ръка  
REDCR  към центъра  на предното  стъкло  на целевото  превозно  
средство  или REDCR  е монтиран  вътре  в превозното  средство  или 
върху  него  така, че да сочи  към центъра  на предното  стъкло  на 
целевото  превозно  средство , когато  превозното  средство  с четеца  
за връзка  с цел ранно  откриване  се намира  в определено  положение  
спрямо  целевото  превозно  средство  (например  непосредствено  пред  
него  в пътния  поток ). За разпитването  се използват  DSRC 
интерфейси  на 5,8 GHz, функциониращи  в рамките  на ERC 70-03 
и изпитани  по отношение  на съответните  параметри  по EN 300 674- 
1, както  е описано  в раздел  5. Виж  фигура  14.2 (случай  № 2 на 
употреба ). 
Фигура  14.2  
Разпитване  за данни  с монтиран  в превозно  средство  четец  
чрез  DSRC на 5,8 GHz
  
4.2 Сигурност  и цялост  на данните  
С цел да се даде  възможност  за проверка  на автентичността  и 
цялостността  на данните , изтеглени  по връзката  от разстояние , 
защитените  данни  се проверяват  и декриптират  съгласно  
допълнение  11 относно  общите  механизми  за сигурност . 
5 СТРУКТУРА  И ПРОТОКОЛИ  ЗА ВРЪЗКАТА  ОТ РАЗСТОЯНИЕ  
5.1 Структура  
Структурата  за реализиране  на функцията  за връзка  от разстояние  в 
интелигентния  тахограф  е показана  на фигура  14.3.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 494  
Фигура  14.3  
Структура  за реализиране  на функцията  за връзка  от разстояние
  
DSC_19 Бордовото  устройство  осъществява  следните  функции : 
— Модул  за сигурност  (VUSM ). Тази  функция  на 
бордовото  устройство  отговаря  за защитата  на 
данните , които  трябва  да се предадат  от DSRC-VU  на 
представителя  на компетентните  контролни  органи  по 
връзката  от разстояние . 
— Защитените  данни  се съхраняват  в паметта  на VUSM. 
През  интервали , определени  в 4.1.1.1 (DSC_12), 
бордовото  устройство  криптира  и подава  наново  
концепта  на данните  за RTM (който  включва  стой­  
ностите  на концептите  на полезните  данни  и на свър­  
заните  със сигурността  данни , определени  по-долу  в 
настоящото  допълнение ), съхранявани  в паметта  на 
DSRC-VU. Функционирането  на модула  за сигурност  
е определено  в допълнение  11 относно  общите  
механизми  за сигурност  и е извън  обхвата  на 
настоящото  допълнение , освен  ако от него  се изисква  
да предоставя  актуализация  на средството  за връзка  на 
бордовото  устройство  (VU Communication facility) при 
всяка  промяна  на данните  във VUSM.  
— Връзката  между  VU и DSRC-VU може  да бъде  жична  
или Bluetooth Low Energy (BLE), а DSRC-VU може  да 
е обединено  физически  с антената  върху  предното  
стъкло  на целевото  превозно  средство , да е вътре  в 
бордовото  устройство  или да е разположено  някъде  
между  тях. 
— DSRC-VU трябва  да разполага  по всяко  време  с 
надежден  източник  на електроенергия . Начинът  на 
неговото  електрическо  захранване  се определя  при 
проектирането  му. 
— Паметта  на DSRC-VU трябва  да бъде  енергонезависима  
с цел запазване  на данните  в DSRC-VU дори  когато  
електрическата  система  на превозното  средство  е 
изключена . 
— Ако връзката  между  VU и DSRC-VU се осъществява  
чрез BLE и електроенергийният  източник  не е акуму­  
латорна  батерия , електроенергийният  източник  на ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 495  
DSRC-VU се подменя  при всеки  периодичен  
технически  преглед , а производителят  на DSRC-VU 
гарантира , че електрическото  захранване  е в 
състояние  да издържи  от един  периодичен  технически  
преглед  до следващия , като осигурява  нормален  достъп  
до данните  чрез REDCR през целия  период  без 
неизправност  или прекъсване . 
— Функция  „памет  за полезните  данни “ (payload memory) 
на VU ( VUPM ) за RTM. Тази  функция  на VU служи  за 
предоставяне  и актуализиране  на данните . Съдър­  
жанието  на данните  („TachographPayload“) е 
определено  в 5.4.4/5.4.5 и се актуализира  през 
интервала , определен  в 4.1.1.1 (DSC_12).  
— DSRC-VU. Това  е функцията , осъществявана  в рамките  
на антената  или свързано  с нея и чрез комуникация  с 
VU посредством  жична  или безжична  (BLE) връзка , 
която  поддържа  текущите  данни  (VUPM-data ) и 
управлява  отговарянето  на разпитване  по DSRC на 
5,8 GHz. Прекъсването  на специализираната  връзка  с 
малък  обсег  на действие  (DSRC) или намесата  по 
време  на нормалната  експлоатация  на превозното  
средство  във функционирането  на тази връзка  се 
счита  за нарушение  на Регламент  (ЕС) № 165/2014.  
— Модулът  за сигурност  на REDCR ( SM-REDCR ) е 
функцията , използвана  за декриптиране  и проверка  на 
цялостността  на данните , произхождащи  от VU. 
Начинът  за постигане  на това се определя  в 
допълнение  11 относно  общите  механизми  за 
сигурност , а не в настоящото  допълнение . 
— Функцията  DSRC на REDCR ( DSRC-REDCR ) се 
осъществява  от приемопредавател  на честота  5,8 GHz 
и съответен  фърмуер  и софтуер , който  управлява  
връзката  с DSRC-VU  съгласно  настоящото  допъл­  
нение . 
— DSRC-REDCR  разпитва  DSRC-VU  на целевото  превозно  
средство  и получава  данните  (текущите  данни  от 
VUPM  на целевото  превозно  средство ) по DSRC, 
обработва  и съхранява  получените  данни  в своя  SM- 
REDCR . 
▼M1 
— Антената  на DSRC-VU трябва  да е разположена  на 
място , което  осигурява  оптимална  DSRC връзка  
между  превозното  средство  и антената  на крайпътния  
четец , при положение  че четецът  е монтиран  на 
разстояние  15 метра  пред  превозното  средство  и на 
височина  2 метра , като се търси  средата  по хоризон­  
талата  и по вертикалата  на предното  стъкло . За леки  
превозни  средства  е подходящо  монтиране  в горната  
част на предното  стъкло . За всички  останали  
превозни  средства  антената  за DSRC трябва  да се 
монтира  близо  до долната  или до горната  част на 
предното  стъкло . 
▼B 
DSC_20 Антената  и връзката  трябва  да функционират  в рамките  на 
ERC 70-03 и да са изпитани  по отношение  на съответните  
параметри  по EN 300 674-1, както  е описано  в раздел  5. 
Антената  и връзката  могат  да прилагат  техники  за ограни­  
чаване  на смущенията  в безжичната  връзка , както  е 
описано  в доклад  № 228 на ЕСС , като например  се 
използват  филтри . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 496  
DSC_21 Антената  за DSRC се свързва  със средството  за DSRC на 
VU или пряко  в модула , монтиран  на предното  стъкло  или 
в близост  до него , или посредством  специален  кабел , 
конструиран  така, че да затруднява  неправомерно  
разкачване . Разкачването  на антената  или намесата  в 
нейното  функциониране  се счита  за нарушение  на 
Регламент  (ЕС) № 165/2014. Умишленото  екраниране  на 
антената  или отрицателното  въздействие  по друг  начин  
върху  нейните  работни  характеристики  се счита  за 
нарушение  на Регламент  (ЕС) № 165/2014.  
DSC_22  ►M1 Размерната  спецификация  на антената  не е 
определена  и е предмет  на търговско  решение , стига  
монтираното  DSRC-VU да отговаря  на изискванията  за 
съответствие , посочени  в раздел  5 по-долу . Антената  се 
разполага , както  е определено  в DSC_19, и трябва  
ефикасно  да работи  за случаите  на употреба , описани  в 
точки  4.1.2 и 4.1.3. ◄ 
Фигура  14.4  
Пример  за разполагането  на антената  за DSRC на 5,8 GHz на 
предното  стъкло  на регулирани  превозни  средства
  
Форм -факторът  на четеца  REDCR  и неговата  антена  може  да е 
различен  в зависимост  от обстоятелствата  по четеца  (дали  той е 
монтиран  върху  триножник , държан  с ръка , монтиран  в превозно  
средство  и т.н.) и от начина  на работа  на представителя  на компет­  
ентните  контролни  органи . 
Използва  се функция  за показване  и/или уведомяване , за да се дадат  
на представителя  на компетентните  контролни  органи  резултатите  
от функцията  за връзка  от разстояние . Показването  може  да бъде  
върху  екран , като разпечатка , звуков  сигнал  или комбинация  от тези 
различни  форми  на уведомяване . Формата  на това показване  и/или 
уведомяване  зависи  от изискванията  на представителите  на компет­  
ентните  контролни  органи  и от конструкцията  на оборудването  и не 
е определена  в настоящото  допълнение . 
DSC_23 Конструкцията  и форм -факторът  на REDCR  се определят  
от производителя  в рамките  на ERC 70-03 и от специфи­  
кациите  за конструкцията  и работните  характеристики , 
дадени  в настоящото  допълнение (раздел  5.3.2), като по ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 497  
този начин  се предоставя  максимална  свобода  на участ­  
ниците  в пазара  да проектират  и доставят  оборудване , 
което  да покрива  специфичните  сценарии  за разпитване  
на конкретния  компетентен  контролен  орган . 
DSC_24 Конструкцията  и форм -факторът  на DSRC-VU , както  и 
неговото  разполагане  във или извън  VU, се определят  от 
производителя  в рамките  на ERC 70-03 и от специфи­  
кациите  за конструкцията  и работните  характеристики , 
дадени  в настоящото  допълнение (раздел  5.3.2) и в 
рамките  на настоящия  раздел  (5.1).  
DSC_25  DSRC-VU  обаче  трябва  да е в състояние  в приемлива  
степен  да възприема  стойности  на концепти  на данни  от 
друго  интелигентно  оборудване  на превозни  средства  
посредством  връзка  и протоколи  по отворен  отраслови  
стандарт  (например  от бордово  оборудване  за претегляне ), 
стига  тези концепти  на данни  да се идентифицират  от 
уникални  и известни  идентификатори  на приложения  / 
имена  на файлове , а инструкциите  за прилагане  на 
такива  протоколи  трябва  да се представят  на Европейската  
комисия  и да се предоставят  безплатно  на производи­  
телите  на съответното  оборудване . 
5.2 Блоксхема  
5.2.1  Действия  
Блоксхемата  на действията  е показана  на фигура  14.5.  
Фигура  14.5  
Блоксхема  на функцията  за връзка  от разстояние
  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 498  
Стъпките  са описани  по-долу : 
а) Когато  превозното  средство  е в действие  (т.е. контактният  ключ  
е в положение  „включено “), тахографът  подава  данни  на 
функцията  VU. Функцията  VU подготвя  данните  за функцията  
за връзка  от разстояние  (криптира  ги) и актуализира  VUPM , 
съдържаща  се в паметта  на DSRC-VU  (както  е определено  в 
4.1.1.1—4.1.1.2). Събраните  данни  се актуализират  съгласно  
5.4.4—5.4.5 по-долу . 
б) При всяка  актуализация  на данните  се актуализира  и времевият  
печат , определен  в концепта  на данните , свързани  със сигур­  
ността . 
в) Функцията  VUSM  осигурява  защитата  на данните  в съответствие  
с процедурите , определени  в допълнение  11. 
г) При всяка  актуализация  на данните  (виж 4.1.1.1—4.1.1.2), те се 
прехвърлят  към DSRC-VU , където  заместват  предишните  данни , 
така че винаги  да са налични  актуализирани  текущи  данни  (дан­ 
ните ), които  да бъдат  предоставени  в случай  на разпитване  от 
четец  REDCR.  Когато  данните  се предоставят  от VU на DSRC- 
VU, трябва  да е възможно  тяхното  идентифициране  по името  на 
файла  RTMData или по идентификатори  на приложението  (App­
licationID) и атрибута  (Attribute).  
д) Ако представител  на компетентния  контролен  орган  желае  да 
получи  данни  от целево  превозно  средство , той най-напред  
вкарва  своята  карта  с чип в REDCR , за да се установи  
връзката  и да се даде  възможност  на SM-REDCR  да провери  
нейната  автентичност  и да декриптира  данните . 
е) След  това представителят  на компетентния  контролен  орган  
насочва  четеца  към превозното  средство  и изисква  данните  по 
връзката  от разстояние . REDCR  открива  сесия  по интерфейса  за 
DSRC на 5,8 GHz с DSRC-VU  на целевото  превозно  средство  и 
заявява  данните . Данните  се прехвърлят  към REDCR  по 
безжичната  съобщителна  система  като DSRC атрибут , изпол­  
звайки  услугата  GET на приложението , както  е определено  5.4. 
Атрибутът  съдържа  криптираните  стойности  на полезните  данни  
и данните , свързани  със сигурността  на DSRC.  
ж) Данните  се анализират  от четеца  REDCR  и се подават  на пред­  
ставителя  на компетентния  контролен  орган . 
з) Представителят  на компетентния  контролен  орган  използва  
данните , за да реши  дали  превозното  средство  да бъде  спряно  
за задълбочена  проверка  и, ако вземе  такова  решение , се обръща  
към друг  представител  на компетентния  контролен  орган  с 
искане  за спирането  на превозното  средство . 
5.2.2  Тълкуване  на данните , получени  по връзката  DSRC  
DSC_26 Данните , получени  по интерфейса  на честота  5,8 GHz, 
трябва  да бъдат  със смисъла  и значението , определени  в 
5.4.4 и 5.4.5 по-долу , и единствено  с този смисъл  и 
значение , и трябва  да се тълкуват  съобразно  целите , 
определени  там. В съответствие  с разпоредбите  на 
Регламент  (ЕС) № 165/2014  данните  се използват  един­  
ствено  за предоставяне  на относима  информация  на 
компетентен  контролен  орган  с оглед  той да бъде  
подпомогнат  при подбора  на превозни  средства , които  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 499  
следва  да бъдат  спрени  за физическа  проверка , и 
впоследствие  те се унищожават  съгласно  член  9 от 
Регламент  (ЕС) № 165/2014.  
5.3 Параметри  на физическия  DSRC интерфейс  за връзка  от 
разстояние  
5.3.1  Ограничения  за местоположението  
DSC_27 Разпитването  на превозни  средства  от разстояние , изпол­  
звайки  DSRC интерфейс  на 5,8GHz, следва  да се 
извършва  на не по-малко  от 200 метра  от функциониращ  
DSRC портал . 
5.3.2  Параметри  на предаването  на данни  в права  и обратна  посока  
DSC_28 Оборудването , използвано  за наблюдение  на тахограф  от 
разстояние , трябва  да бъде  в съответствие  с ERC70-03 и 
да функционира  в неговите  рамки , както  и с параметрите , 
определени  в таблици  14.1 и 14.2 по-долу . 
DSC_29 Освен  това оборудването , използвано  за наблюдение  на 
тахограф  от разстояние , трябва  да бъде  в съответствие  с 
параметрите  от EN 12253 и EN 13372, за да се гарантира  
оперативна  съвместимост  с работните  параметри  на други  
стандартизирани  системи  за DSRC на 5,8 GHz.  
Това  са именно : 
Таблица  14.1.  
Параметри  на предаването  на данни  в права  посока  
Позиция  № Параметър  Стойност (и) Забележка  
D1 Носещи  честоти  за 
предаване  в права  посока  Има четири  алтернативи , 
които  могат  да бъдат  
използвани  от REDCR: 
5,7975 GHz 
5,8025 GHz 
5,8075 GHz 
5,8125 GHz  В рамките  на ERC 70-03. 
Носещите  честоти  може  да бъдат  
избрани  от изпълнителя  на край­  
пътната  система  и не е нужно  те 
да са известни  в DSRC-VU 
(в съответствие  с EN 12253 и EN 
13372)  
D1a (*) Допустимо  отклонение  на 
носещите  честоти  до 5 ppm  ( в съответствие  с EN 12253)  
D2 (*) Спектрална  маска  на 
радиопредавателя  на край­  
пътното  устройство  (RSU, 
т.е. на REDCR)  В рамките  на ERC 70-03. 
REDCR трябва  да е в 
съответствие  с клас B,C 
съгласно  EN 12253. 
Няма  други  специфични  
изисквания  в рамките  на 
настоящото  приложение  Параметри , използвани  за 
контролиране  на смущенията  
между  близки  разпитващи  
устройства  (както  е определено  
в EN 12253 и EN 13372).  
D3 Минимален  честотен  
обхват  на бордовото  
устройство  (DSRC-VU)  5,795—5,815 GHz  ( в съответствие  с EN 12253)  
D4 (*) Максимална  еквивалентна  
изотропно  излъчена  
мощност  (E.I.R.P.)  В рамките  на ERC 70-03 
(нелицензирано ) и на 
националното  законода­  
телство  
Максимум  + 33 dBm  (в съответствие  с EN 12253)  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 500  
Позиция  № Параметър  Стойност (и) Забележка  
D4a Ъглова  маска  за E.I.R.P.  Съгласно  обявената  и 
публикувана  специ­  
фикация  на проектанта  
на разпитващото  
устройство  (в съответствие  с EN 12253)  
D5 Поляризация  Ляво  въртяща  се кръгова  
поляризация  (в съответствие  с EN 12253)  
D5a Напречна  поляризация  XPD: 
В диаграмата  на насо­  
ченост : (REDCR) RSU t ≥ 
15 δВ 
(DSRC-VU) OBU r ≥ 10 
δВ 
В зоната  – 3 dB: (REDCR) 
RSU t ≥ 10 δВ 
(DSRC-VU) OBU r ≥ 6 δВ (в съответствие  с EN 12253)  
D6 (*) Модулация  Амплитудна  модулация  на 
две нива . (в съответствие  с EN 12253)  
D6a (*) Индекс  на модулация  0,5 … 0,9  ( в съответствие  с EN 12253)  
D6b Диаграма  Eye Pattern  ≥ 90 % (време ) / ≥ 85 % 
(амплитуда ) 
D7 (*) Кодиране  на данните  FM0 
Бит „1“ има преходи  само  
в началото  и края  на 
интервала  на бита . Бит 
„0“ има допълнителен  
преход  в средата  на 
интервала  на бита  в 
сравнение  с бита  „1“.  (в съответствие  с EN 12253)  
D8 (*) Скорост  на предаване  на 
данните  500 kBit/s  ( в съответствие  с EN 12253)  
D8a Допустимо  отклонение  на 
такта  за бит (Bit Clock)  по-малко  от ± 100 ppm  (в съответствие  с EN 12253)  
D9 (*) Честота  на грешните  
битове  (B.E.R.) при 
връзката  ≤ 10  – 6 когато  падащата  
мощност  върху  
бордовото  устройство  
(OBU, т.е. DSRC-VU) е в 
диапазона , посочен  в 
[D11a до D11b].  (в съответствие  с EN 12253)  
D10 Тригер  за „събуждане “ на 
OBU (DSRC-VU)  OBU (DSRC-VU) се 
събужда  при получаване  
на какъвто  и да е фрейм  
с 11 или повече  октета  
(включително  преамбюл ) Не е необходим  специален  модел  
за събуждане . 
DSRC-VU може  да се събуди  
при получаването  на фрейм  с 
по-малко  от 11 октета . 
(в съответствие  с EN 12253)  
D10a  Максимално  стартово  
време  ≤ 5 ms  ( в съответствие  с EN 12253)  
D11 Съобщителна  зона Пространствената  област , 
в рамките  на която  е 
постигната  B.E.R. 
съгласно  D9a  (в съответствие  с EN 12253)  
D11a  (*) Гранична  стойност  на 
мощността  за връзката  
(горна ). – 24dBm  ( в съответствие  с EN 12253)  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 501  
Позиция  № Параметър  Стойност (и) Забележка  
D11b  (*) Гранична  стойност  на 
мощността  за връзката  
(долна ). Падаща  мощност : 
– 43 dBm ( диаграма  на 
насоченост ) 
– 41 dBm ( в границите  от 
– 45° до + 45° в съот­  
ветствие  с равнината , 
успоредна  на повър­  
хността  на пътя , когато  
DSRC-VU по-късно  е 
монтирано  в превозното  
средство  (Azimuth)  (в съответствие  с EN 12253) 
Разширено  изискване  за хори­  
зонтални  ъгли  до ±45° поради  
случаите  на употреба , 
определени  в настоящото  прило­  
жение . 
D12 (*) Гранично  ниво  на 
мощността  (на DSRC-VU)  – 60 dBm  ( в съответствие  с EN 12253)  
D13 Преамбюл  Преамбюлът  е задължи­  
телен . (в съответствие  с EN 12253)  
D13a  Дължина  и модел  на 
преамбюла  16 бита  ± 1 бит, кодирани  
по FM0 битове  „1“ (в съответствие  с EN 12253)  
D13b  Форма  на вълната  на 
преамбюла  Редуваща  се поредица  от 
ниско  ниво  и високо  
ниво  с времетраене  на 
импулса  2 μѕ. 
Допустимото  отклонение  
се дава от D8a  (в съответствие  с EN 12253)  
D13c  Изоставащи  (trailing) 
битове  На крайпътното  
устройство  (т.е. REDCR) 
е разрешено  да предаде  
максимум  8 бита  след  
флага  за край . Не се 
изисква  бордовото  
устройство  (DSRC-VU) 
да отчита  тези допъл­  
нителни  битове . (в съответствие  с EN 12253)  
(*) Параметрите  на предаването  на данни  в права  посока  подлежат  на изпитване  за съответствие  съгласно  относимото  
изпитване  на параметри  по EN 300 674-1  
Таблица  14.2.  
Параметри  на предаването  на данни  в обратна  посока  
Позиция  № Параметър  Стойност (и) Забележка  
U1 (*) Подносещи  честоти  OBU (DSRC-VU) трябва  
да поддържа  1,5 MHz и 
2,0 MHz 
RSU (REDCR) трябва  да 
поддържа  1,5 MHz или 
2,0 MHz, или и двете  
честоти  U1-0: 1,5 MHz 
U1-1: 2,0 MHz  Изборът  на подносещата  честота  
(1,5 MHz или 2,0 MHz) зависи  от 
избрания  профил  по EN 13372.  
U1a (*) Допустимо  отклонение  на 
подносещите  честоти  в рамките  на ± 0,1 %  (в съответствие  с EN 12253)  
U1b Използване  на странични  
ленти  Едни  и същи  данни  за 
двете  страни  (в съответствие  с EN 12253)  
U2 (*) Спектрална  маска  на 
радиопредавателя  на 
бордовото  устройство  
(OBU, т.е. на DSRC-VU)  В съответствие  с EN 
12253 
1) Мощност  извън  
лентата : 
виж ETSI EN 300674-1  (в съответствие  с EN 12253)  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 502  
Позиция  № Параметър  Стойност (и) Забележка  
2) Мощност  в лентата : 
[U4a] dBm в 500 kHz 
3) Емисия  в който  и да е 
друг  канал  в обратна  
посока : 
U2(3)-1 = – 35 dBm в 
500 kHz  
U4a (*) Максимална  E.I.R.P. за 
единична  странична  
лента  (диаграма  на насо­  
ченост ) Две възможности : 
U4a-0: – 14 dBm 
U4a-1: – 21 dBm  Съгласно  обявената  и публи­  
кувана  спецификация  на 
проектанта  на оборудването  
U4b (*) Максимална  E.I.R.P. за 
единична  странична  
лента  (35°)  Две възможности  
— неприложимо  
— – 17 dBm  Съгласно  обявената  и публи­  
кувана  спецификация  на 
проектанта  на оборудването  
U5 Поляризация  Ляво  въртяща  се кръгова  
поляризация  (в съответствие  с EN 12253)  
U5a Напречна  поляризация  XPD: 
В диаграмата  на насо­  
ченост : (REDCR) RSU r 
≥ 15 dB 
(DSRC-VU) OBU t ≥ 
10 dB 
При -3 dB: (REDCR) RSU 
r ≥ 10 dB 
(DSRC-VU) OBU t ≥ 6 dB  (в съответствие  с EN 12253)  
U6 Модулация  на 
подносещата  2-PSK 
Кодирани  данни , синхро­  
низирани  с подносещата : 
преходите  на кодираните  
данни  съвпадат  с 
преходите  на подносе­  
щата . (в съответствие  с EN 12253)  
U6b Коефициент  на запълване  Коефициент  на запълване : 
50 % ± α, α ≤ 5 %  (в съответствие  с EN 12253)  
U6c Модулация  на носещата  Мултиплексиране  на 
модулираната  подносеща  
с носещата . (в съответствие  с EN 12253)  
U7 (*) Кодиране  на данните  NRZI ( без преход  към 
началото  на бит „1“, 
преход  в началото  на бит 
„0“, без преход  в рамките  
на бита ) (в съответствие  с EN 12253)  
U8 (*) Скорост  на предаване  на 
данните  250 kbit/s  ( в съответствие  с EN 12253)  
U8a Допустимо  отклонение  на 
такта  за бит (Bit Clock)  в рамките  на ± 1 000 ppm  (в съответствие  с EN 12253)  
U9 Честота  на грешните  
битове  (B.E.R.) за 
връзката  ≤ 10  – 6 (в съответствие  с EN 12253)  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 503  
Позиция  № Параметър  Стойност (и) Забележка  
U11 Съобщителна  зона Пространствената  област , 
в рамките  на която  
DSRC-VU е разположено  
така, че предадените  
данни  са получени  от 
REDCR с по-малка  
B.E.R. от посочената  в 
U9a.  (в съответствие  с EN 12253)  
U12a  (*) Усилване  при преобраз­  
уването  (долна  граница ) 1 dB за всяка  странична  
лента  Ъглов  диапазон : 
кръгово  симетричен  
между  диаграмата  на 
насоченост  и ± 35° 
и 
в границите  от – 45° до + 
45° в съответствие  с 
равнината , успоредна  на 
повърхността  на пътя , 
когато  DSRC-VU по- 
късно  е монтирано  в 
превозното  средство  (Azi­
muth)  По-голямо  от специфицирания  
диапазон  на стойности  за хори­  
зонтални  ъгли  до ± 45° поради  
случаите  на употреба , 
определени  в настоящото  прило­  
жение . 
U12b  (*) Усилване  при преобраз­  
уването  (горна  граница ) 10 dB за всяка  странична  
лента  По-малко  от специфицирания  
диапазон  на стойностите  за 
всяка  странична  лента  в кръгъл  
конусовиден  около  диаграмата  
на насоченост  на ± 45° ъгъл  на 
отваряне  
U13 Преамбюл  Преамбюлът  е задължи­  
телен . (в съответствие  с EN 12253)  
U13a  Преамбюл  
Дължина  и модел  32 to 36 μѕ модулиран  
само  с подносещата , 
после  8 бита  „0“, 
кодирани  по NRZI.  (в съответствие  с EN 12253)  
U13b  Изоставащи  (trailing) 
битове  На DSRC-VU е разрешено  
да предаде  максимум  8 
бита  след  флага  за край . 
Не се изисква  RSU 
(REDCR) да отчита  тези 
допълнителни  битове . (в съответствие  с EN 12253)  
(*) Параметрите  на предаването  на данни  в обратна  посока  подлежат  на изпитване  за съответствие  съгласно  относимото  
изпитване  на параметри  по EN 300 674-1.  
5.3.3  Конструкция  на антената  
5.3.3.1 Антена  на четеца  (REDCR)  
DSC_30 Конструкцията  на антената  на REDCR  зависи  от произво­  
дителя  при спазване  на ограниченията , определени  в 
5.3.2, и оптимизация  на характеристиките  на DSRC- 
REDCR  за четене  на данни  съобразно  специфичното  пред­  
назначение  и условията  за четене , за които  е проектиран  
REDCR . 
5.3.3.2 Антена  на бордовото  устройство  (VU)  
DSC_31 Конструкцията  на антената  на DSRC-VU  зависи  от 
производителя  при спазване  на ограниченията , 
определени  в 5.3.2, и оптимизация  на характеристиките  
на DSRC-REDCR  за четене  на данни  съобразно  специ­  
фичното  предназначение  и условията  за четене , за които  
е проектиран  REDCR . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 504  
DSC_32 Антената  на VU се закрепва  върху  предното  стъкло  на 
превозното  средство , както  е определено  в 5.1 по-горе. 
DSC_33 При изпитването  в сервиз  (виж раздел  6.3) антената  на 
DSRC-VU, закрепена  съгласно  5.1 по-горе, трябва  
успешно  да осъществява  стандартна  изпитателна  връзка  
и транзакция  за RTM, както  е определено  в настоящото  
допълнение , на разстояние  между  2 и 10 метра  през 
повече  от 99 % от времето  — осреднено  за 1 000 
разпитвания  за данни . 
5.4 Изисквания  по протокола  DSRC за RTM  
5.4.1  Преглед  
DSC_34 Протоколът  за транзакцията  по изтегляне  на данните  по 
интерфейса  за DSRC на 5,8 GHz трябва  да бъде  съгласно  
следните  стъпки . В настоящия  раздел  се описва  проти­  
чането  на транзакцията  при идеални  условия  без 
повторни  предавания  на данни  или прекъсвания  на 
връзката . 
ЗАБЕЛЕЖКА  Целта  на етапа  на инициализиране  (стъпка  
№ 1) е да се установи  връзката  между  REDCR  и DSRC- 
VU, които  са навлезли  в зоната  на транзакцията  за DSRC 
на 5,8 GHz ( главен /подчинен ), но все още не са уста­  
новили  връзката  между  REDCR , и да се уведомят  
приложните  процеси . 
— Стъпка  № 1. Инициализиране . Четецът  REDCR  
изпраща  фрейм , съдържащ  таблица  за навигационните  
услуги  (Beacon Service Table — BST), която  включва  
идентификаторите  на приложения  (AID) в списъка  на 
услугите , поддържани  от него . В приложението  RTM 
това ще бъде  услугата  със стойност  на AID = 2 (Fre ­
ight&Fleet).  DSRC-VU  оценява  получената  BST и 
отговаря  (виж по-долу ) със списъка  на поддържаните  
приложения  в домейна  Freight&Fleet, или не отговаря  
въобще , ако не се поддържа  никое  от тези прило­  
жения . Ако REDCR  не предлага  AID=2, DSRC-VU 
не отговаря  на REDCR.  
— Стъпка  № 2. DSRC-VU  изпраща  фрейм , съдържащ  
заявка  за разпределяне  на частен  прозорец  (private 
window allocation).  
— Стъпка  № 3. REDCR  изпраща  фрейм , съдържащ  
разпределение  на частен  прозорец . 
— Стъпка  № 4. DSRC-VU  използва  разпределения  
частен  прозорец , за да изпрати  фрейм , съдържащ  
неговата  таблица  за услуги  във връзка  с превозното  
средство  (Vehicle Service Table — VST). Тази  VST 
включва  списък  на всички  инстанциирания  на 
различните  услуги , поддържани  от това DSRC-VU  в 
рамките  на AID=2. Различните  инстанциирания  се 
идентифицират  посредством  уникални  идентифи­  
катори  на елементи  (Element Identifiers — EIDs), 
всеки  от които  е свързан  със стойност  на параметъра  
Application Context Mark, указваща  приложението  и 
стандарта , които  се поддържат . 
— Стъпка  № 5. След  това четецът  REDCR  анализира  
предложената  VST и или прекъсва  връзката  
(RELEASE) поради  липса  на интерес  към каквото  и 
да било , предложено  от VST (т.е. той получава  VST 
от DSRC-VU , което  не поддържа  транзакцията  за 
RTM), или започва  инстанциирането  на приложение , 
ако получи  подходяща  VST.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 505  
— Стъпка  № 6. За целта  REDCR изпраща  фрейм , 
съдържащ  команда  за извличане  на данните  за RTM, 
като идентифицира  инстанциирането  на прило­  
жението  за RTM чрез указване  на съответния  иденти­  
фикатор  (посочен  от DSRC-VU във VST), и 
разпределя  частен  прозорец . 
— Стъпка  № 7. DSRC-VU  използва  новоразпределения  
частен  прозорец , за да изпрати  фрейм , който  съдържа  
адресирания  идентификатор , съответстващ  на инстан­  
циирането  на приложението  за RTM съгласно  VST, 
следван  от атрибута  RtmData  (елемент  на полезните  
данни  + елемент  на данните , свързани  със сигур­  
ността ). 
— Стъпка  № 8. Ако са заявени  няколко  услуги , стой­  
ността  „n“ се променя  на референтния  номер  на след­  
ващата  услуга  и процесът  се повтаря . 
— Стъпка  № 9. REDCR  потвърждава  приемането  на 
данните , като изпраща  на DSRC-VU  фрейм , 
съдържащ  командата  RELEASE, за да приключи  
сесията , ИЛИ  се връща  на стъпка  № 6, ако не е 
успял  да валидира  успешното  приемане  на LDPU.  
Виж  фигура  14.6 за схематично  описание  на протокола  за 
транзакцията . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 506  
Фигура  14.6  
Последователност  на процеса  на RTM по DSRC на 5,8 GHz
  
5.4.2  Команди  
DSC_35 На етапа  на транзакцията  за RTM се използват  само  
функциите , осъществявани  от следните  команди : 
— INITIALISATION.request : Излъчвана  от REDCR 
команда  с определение  за приложенията , поддържани  
от REDCR.  
— INITIALISATION.response : Отговор  от DSRC-VU, 
потвърждаващ  връзката  и съдържащ  списък  на 
инстанции  на поддържаните  приложения  с характе­  
ристики  и информация  за начина  на обръщане  към 
тях (EID).  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 507  
— GET.request : Команда , издадена  от REDCR  на DSRC- 
VU, указваща  инстанциирането  на приложението , към 
което  трябва  да се обърне  посредством  определен  
EID, получен  във VST, с която  DSRC-VU  се 
инструктира  да изпрати  избрания (те) атрибут (и) с 
данните . Целта  на командата  GET е REDCR  да 
получи  данните  от DSRC-VU . 
— GET.response : Отговор  от DSRC-VU , който  съдържа  
заявените  данни . 
— ACTION.request ECHO : Команда  към DSRC-VU  да 
изпрати  обратно  данни  от DSRC-VU  на REDCR . 
Целта  на командата  ECHO е да даде  възможност  на 
сервизи  или изпитателни  пунктове  за одобрение  на 
типа  да проверят  дали  DSRC функционира , без да е 
нужен  достъп  до сертификати  за сигурност . 
— ACTION .response ECHO: Отговор  от DSRC-VU на 
командата  ECHO.  
— EVENT_REPORT.request  RELEASE: Команда  към 
DSRC-VU , че транзакцията  е приключила . Целта  на 
командата  RELEASE е да приключи  сесията  с 
DSRC-VU . При получаване  на RELEASE  DSRC-VU  
не отговаря  повече  на по-нататъшни  разпитвания  по 
текущата  връзка . Следва  да се отбележи , че съгласно  
EN 12834 едно  DSRC-VU  не се свързва  два пъти  с 
едно  и също  разпитващо  устройство , освен  ако е 
било  извън  съобщителната  зона в продължение  на 
255 секунди  или ако е променен  навигационният  
идентификационен  номер  (Beacon ID) на разпит­  
ващото  устройство . 
5.4.3  Последователност  на командите  за разпитване  
DSC_36 По отношение  на последователността  от команди  и 
отговори  транзакцията  се описва , както  следва : 
Пореден  
номер  Предавател  Приемник  Описание  Действие  
1 REDCR  >  DSRC-VU  Инициализиране  на 
връзката  — заявка  REDCR излъчва  BST  
2 DSRC-VU  >  REDCR  Инициализиране  на 
връзката  — отговор  Ако BST поддържа  
AID=2,тогава  DSRC-VU 
заявява  частен  прозорец  
3 REDCR  >  DSRC-VU  Предоставя  частен  
прозорец  Изпраща  фрейм , 
съдържащ  разпределение  
за частен  прозорец  
4 DSRC-VU  >  REDCR  Изпраща  VST  Изпраща  фрейм , 
включващ  VST  
5 REDCR  >  DSRC-VU  Изпраща  GET.request 
за данни  в Attribute 
за конкретен  EID  
6 DSRC-VU  >  REDCR  Изпраща  
GET.response със 
заявения  Attribute за 
конкретен  EID  Изпраща  Attribute 
(RTMData, OWSData…) с 
данни  за конкретен  EID ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 508  
Пореден  
номер  Предавател  Приемник  Описание  Действие  
▼M1 
7 REDCR  >  DSRC-VU  Изпраща  GET.request 
за данни , различни  от 
Attribute ( ако е 
уместно ) 
▼B 
8 DSRC-VU  >  REDCR  Изпраща  
GET.response със 
заявения  Attribute  Изпраща  Attribute с 
данни  за конкретен  EID  
9 REDCR  >  DSRC-VU  Потвърждава  
успешното  приемане  
на данните  Изпраща  команда  
RELEASE за 
приключване  на транзак­  
цията  
10 DSRC-VU  Приключва  транзак­  
цията  
Пример  за последователността  на транзакцията  и съдър­  
жанието  на разменяните  фреймове  се дава в раздели  5.4.7 
и 5.4.8.  
5.4.4  Структура  на данните  
DSC_37 Семантичната  структура  на данните , когато  преминават  
през интерфейса  за DSRC на 5,8 GHz, трябва  да е в съот­  
ветствие  с описаната  в настоящото  допълнение . Начинът  
на структуриране  на тези данни  е определен  в настоящия  
раздел . 
DSC_38 Полезните  данни  (RTM data) се състоят  от конкатенацията  
на: 
1. данните  EncryptedTachographPayload, които  пред­  
ставляват  криптираните  данни  TachographPayload, 
определени  в ASN.1 в раздел  5.4.5. Методът  на крип­  
тиране  е описан  в допълнение  11; 
2. данните  DSRCSecurityData, определени  в 
допълнение  11. 
DSC_39 Данните  за RTM (RTM Data) се адресират  като RTM Attri ­
bute=1 и се прехвърлят  в RTM контейнер  =10.  
DSC_40 RTM Context Mark идентифицира  поддържаната  част от 
стандарта  в серията  TARV от стандарти  (RTM съот­  
ветства  на част 9) 
Модулът  ASN.1 за DSRC данните  в рамките  на прило­  
жението  RTM е определен , както  следва : ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 509
  
► (1) (2) (3) (4)  M1 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 510
  
5.4.5  Елементи  на RtmData, извършени  действия  и определения  
DSC_41 Стойностите  на данните , които  трябва  да бъдат  изчислени  
от бордовото  устройство  (VU) и използвани  за актуали­  
зиране  на защитените  данни  в DSRC-VU, се изчисляват  
съгласно  правилата , определени  в таблица  14.3:  
Таблица  14.3.  
Елементи  на RtmData, извършени  действия  и определения  
(1) Елемент  на 
RTM Data  (2) Действие , извършено  от VU (3) ASN.1 определение  на 
данните  
RTM1 
Регистрация  
на 
превозното  
средство  
Регистра­  
ционен  
номер  VU задава  стойността  на елемента  
tp15638VehicleRegistrationPlate  на данните  
RTM1 от регистрираната  стойност  на 
данните  тип VehicleRegistrationIdentification  
както  е определено  в допълнение  1 Vehicle­
RegistrationIdentification  Регистрационен  
номер  на 
превозното  
средство , 
изразен  като низ 
от символи
  
RTM2 
Преви­  
шаване  на 
допустимата  
скорост  VU генерира  булева  стойност  на елемента  
RTM2 на данните  tp15638SpeedingEvent. 
Стойността  на tp15638SpeedingEvent се 
изчислява  от VU от броя  на събитията  
Over Speeding Events, регистрирани  във 
VU през последните  10 дни на възникването  
им, както  е определено  в приложение  1В. 1 (TRUE) — 
указва  
нередности  по 
отношение  на 
скоростта  през 
последните  10 
дни на 
възникване
  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 511  
(1) Елемент  на 
RTM Data  (2) Действие , извършено  от VU (3) ASN.1 определение  на 
данните  
Ако има поне  едно  събитие  tp15638Speedin ­
gEvent през последните  10 дни на 
възникване , за стойността  на tp15638Spee ­
dingEvent се задава  TRUE, т.е. „ВЯРНО “. 
В ПРОТИВЕН  СЛУЧАЙ , ако не е имало  
такива  събития  през последните  10 дни на 
възникване , за стойността  на tp15638Spee ­
dingEvent се задава  FALSE, т.е. 
„НЕВЯРНО “. 
RTM3 
Управление  
на МПС  без 
валидна  
карта  VU генерира  булева  стойност  на елемента  
RTM3 на данните  tp15638DrivingWithout ­
ValidCard. 
VU присвоява  стойност  TRUE на промен­  
ливата  tp15638DrivingWithoutValidCard, ако 
през последните  10 дни на възникване  VU 
е регистрирало  поне  едно  събитие  от типа  
„Управление  на МПС  без съответна  карта “ 
съгласно  определението  в приложение  1В. 
В ПРОТИВЕН  СЛУЧАЙ , ако не е имало  
такива  събития  през последните  10 дни на 
възникване , за стойността  на tp15638Drivin ­
gWithoutValidCard се задава  FALSE.  1 (TRUE) = 
указва  
използване  на 
невалидна  карта
  
RTM4 
Валидна  
карта  на 
водач  VU генерира  булева  стойност  на елемента  
RTM4 на данните  
tp15638DriverCard въз основа  на данните , 
съхранени  във VU и определени  в 
допълнение  1. 
Ако не е налице  валидна  карта  на водач , VU 
задава  за променливата  стойност  TRUE. 
В ПРОТИВЕН  СЛУЧАЙ , ако е налице  
валидна  карта  на водач , VU задава  за 
променливата  стойност  FALSE.  0 (FALSE) = 
указва  валидна  
карта  на водач
  
RTM5 
Вкарване  на 
карта  по 
време  на 
управ­  
лението  на 
МПС  VU генерира  булева  стойност  на елемента  
RTM5 на данните . 
VU присвоява  стойност  TRUE на промен­  
ливата  tp15638CardInsertion, ако през 
последните  10 дни на възникване  VU е 
регистрирало  поне  едно  събитие  от типа  
„Вкарване  на карта  по време  на управ­  
лението  на МПС “ съгласно  определението  
в приложение  1В. 
В ПРОТИВЕН  СЛУЧАЙ , ако не е имало  
такива  събития  през последните  10 дни на 
възникване , за стойността  на tp15638CardIn ­
sertion се задава  FALSE.  1 (TRUE) = 
указва  вкарване  
на карта  по 
време  на управ­  
лението  на МПС  
през последните  
10 дни на 
възникване  на 
това събитие
  
RTM6 
Грешка  в 
данните  за 
движението  VU генерира  булева  стойност  на елемента  
RTM6 на данните . 
VU присвоява  стойност  TRUE на промен­  
ливата  tp15638MotionDataError, ако през 
последните  10 дни на възникване  VU е 
регистрирало  поне  едно  събитие  от типа  
„Грешка  в данните  за движението “ 
съгласно  определението  в приложение  1В. 
В ПРОТИВЕН  СЛУЧАЙ , ако не е имало  
такива  събития  през последните  10 дни на 
възникване , за стойността  на tp15638Motion ­
DataError се задава  FALSE.  1 (TRUE) = 
указва  грешка  в 
данните  за 
движението  
през последните  
10 дни на 
възникване
  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 512  
(1) Елемент  на 
RTM Data  (2) Действие , извършено  от VU (3) ASN.1 определение  на 
данните  
RTM7 
Проти­  
воречие  в 
данните  за 
движението  
на превозно - 
то средство  VU генерира  булева  стойност  на елемента  
RTM7 на данните . 
VU присвоява  стойност  TRUE на промен­  
ливата  tp15638vehicleMotionConflict, ако 
VU през последните  10 дни VU е регис­  
трирало  поне  едно  събитие  от типа  „проти­  
воречие  в данните  за движението  на 
превозното  средство “ съгласно  опред­  
елението  в приложение  1В (стойност  
‘0A’H ). 
В ПРОТИВЕН  СЛУЧАЙ , ако не е имало  
такива  събития  през последните  10 дни на 
възникване , за стойността  на tp15638vehicle ­
MotionConflict се задава  FALSE.  1 (TRUE) = 
указва  проти­  
воречие  в 
данните  за 
движението  
през последните  
10 дни на 
възникване
  
RTM8 
Карта  на 
втория  
водач  VU генерира  булева  стойност  на елемента  
RTM8 на данните  въз основа  на приложение  
1В („Данни  за дейността  на водача “ ЕКИП  
и ВТОРИ  ВОДАЧ ). 
Ако е налице  валидна  карта  на втория  
водач , VU задава  за променливата  
стойност  TRUE. 
В ПРОТИВЕН  СЛУЧАЙ , ако не е налице  
валидна  карта  на втория  водач , VU задава  
за променливата  стойност  FALSE.  1 (FALSE) = 
указва , че е 
вкарана  карта  на 
втория  водач
  
RTM9 
Текуща  
дейност  VU генерира  булева  стойност  на елемента  
RTM9 на данните . 
Ако текущата  дейност  е записана  във VU 
като дейност , различна  от „УПРАВЛЕНИЕ  
НА МПС “ (DRIVING) съгласно  опред­  
елението  в приложение  1В, VU задава  за 
променливата  стойност  TRUE 
В ПРОТИВЕН  СЛУЧАЙ , ако текущата  
дейност  е записана  във VU като 
„Управление  на МПС “, VU задава  за 
променливата  стойност  FALSE  1 (TRUE) = 
друга  дейност  е 
избрана  
0 (FALSE) = 
избрано  е 
управление  на 
МПС
  
RTM10 
Последната  
сесия  е 
приключена  VU генерира  булева  стойност  на елемента  
RTM10 на данните . 
Ако последната  картова  сесия  не е 
приключена  правилно  съгласно  опред­  
елението  в приложение  1В, VU задава  за 
променливата  стойност  TRUE. 
В ПРОТИВЕН  СЛУЧАЙ , ако последната  
картова  сесия  е приключена  правилно , VU 
задава  за променливата  стойност  FALSE.  1 (TRUE) = 
приключена  
неправилно  
0 (FALSE) = 
приключена  
правилно
  
RTM11 
Прекъсване  
на електри­  
ческото  
захранване  VU генерира  цяло  число  като стойност  на 
елемента  RTM11 на данните . 
VU присвоява  на променливата  tp15638Po ­
werSupplyInterruption стойност , която  е 
равна  на най-дългото  прекъсване  на елек­  
трическото  захранване , съгласно  член  9 от 
Регламент  (ЕС) № 165/2014 от типа  „Пре­  
късване  на електрическото  захранване “, 
както  е определено  в приложение  1В. — Брой  на 
прекъс­  
ванията  на 
електри­  
ческото  
захранване  
през 
последните  
10 дни на 
възникване
  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 513  
(1) Елемент  на 
RTM Data  (2) Действие , извършено  от VU (3) ASN.1 определение  на 
данните  
В ПРОТИВЕН  СЛУЧАЙ , ако през 
последните  10 дни на възникване  на 
събитието  „Прекъсване  на електрическото  
захранване “ не е имало  такова , за стой­  
ността  на това цяло  число  се задава  0. 
▼M1 
RTM12 
Неиз­  
правност  на 
датчика  Бордовото  устройство  генерира  целочислена  
стойност  за елемента  RTM12 на данните . 
Бордовото  устройство  присвоява  на промен­  
ливата  sensorFault стойността : 
— 1, ако през последните  10 дни е било  
регистрирано  събитие  от типа  ‘35’H за 
неизправност  на датчика , 
— 2, ако през последните  10 дни е било  
регистрирано  събитие  за неизправност  
на приемника  на сигнали  от GNSS 
(вътрешно  или външно  с изброени  
(enum) стойности  ‘36’H или ‘37’H), 
— 3, ако през последните  10 дни е било  
регистрирано  събитие  от типа  ‘0E’H за 
грешка  в комуникацията  с външното  
устройство  за GNSS, 
— 4, ако през последните  10 дни са били  
регистрирани  неизправности  както  по 
датчика , така и по приемника  на 
сигнали  от GNSS, 
— 5, ако през последните  10 дни са били  
регистрирани  както  неизправност  по 
датчика , така и грешка  в комуникацията  
с външното  устройство  за GNSS, 
— 6, ако през последните  10 дни са били  
регистрирани  както  неизправност  по 
приемника  на сигнали  от GNSS, така и 
грешка  в комуникацията  с външното  
устройство  за GNSS, 
— 7, ако през последните  10 дни са били  
регистрирани  всички  три вида  
неизправности  по датчика . В 
ПРОТИВЕН  СЛУЧАЙ  се присвоява  
стойност  0, ако през последните  10 
дни не са били  регистрирани  събития . — за 
неизправност  
на датчика  
— един  
октет  
съгласно  
речника  на 
данните
  
▼B 
RTM13 
Сверяване  
на 
часовника  VU генерира  целочислена  стойност  
(timeReal от допълнение  1) за елемента  
RTM13 на данните  въз основа  на 
наличните  данни  за сверяването  на 
часовника  (Time Adjustment) съгласно  
определението  в приложение  1В. 
VU присвоява  като стойност  момента , в 
който  е станало  последното  събитие  „Све­  
ряване  на часовника “. 
В ПРОТИВЕН  СЛУЧАЙ , ако в данните  във 
VU липсва  събитие  „Сверяване  на 
часовника “ съгласно  определението  в 
приложение  1В, VU задава  стойност  0. Момент  на 
последното  
сверяване  на 
часовника
  
RTM14 
Опит  за 
нарушаване  
на сигур­  
ността  VU генерира  целочислена  стойност  
(timeReal от допълнение  1) за елемента  
RTM14 на данните  въз основа  на 
наличието  на събитие  „Опит  за нарушаване  
на сигурността “ съгласно  определението  в 
приложение  1В. Момент  на 
последния  опит  
за нарушаване  
на сигурността  
— Стойност  по 
подраз­  
биране  
=0x00FF
  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 514  
(1) Елемент  на 
RTM Data  (2) Действие , извършено  от VU (3) ASN.1 определение  на 
данните  
VU присвоява  като стойност  момента , в 
който  е възникнало  последното  събитие  
„Опит  за нарушаване  на сигурността “, 
регистрирано  от VU. 
В ПРОТИВЕН  СЛУЧАЙ , ако в данните  във 
VU липсва  събитие  „Опит  за нарушаване  на 
сигурността “ съгласно  определението  в 
приложение  1В, VU задава  стойност  
0x00FF.  
RTM15 
Последно  
калибриране  VU генерира  целочислена  стойност  
(timeReal от допълнение  1) за елемента  
RTM15 на данните  въз основа  на 
наличните  данни  за последното  калибриране  
(Last Calibration) съгласно  определението  в 
приложение  1В. 
VU присвоява  като стойност  момента  на 
последните  две калибрирания  (RTM15 и 
RTM16), които  са зададени  във VuCalibrati ­
onData съгласно  определението  в 
допълнение  1. 
VU присвоява  като стойност  на RTM15 
timeReal в записа  за последното  калибри­  
ране . Данни  за 
момента  на 
последното  
калибриране
  
RTM16 
Предишно  
калибриране  VU генерира  целочислена  стойност  
(timeReal от допълнение  1) за елемента  
RTM16 на данните  в записа  за калибри­  
рането , предхождащо  последното  калиб­  
риране . 
В ПРОТИВЕН  СЛУЧАЙ , ако не е имало  
предишно  калибриране , VU задава  за 
RTM16 стойност  0. Данни  за 
момента  на 
предишното  
калибриране
  
RTM17 
Дата  на 
свързване  
на 
тахографа  За елемента  RTM17 на данните  VU 
генерира  целочислена  стойност  (timeReal 
от допълнение  1). 
VU присвоява  като стойност  момента  на 
първоначалното  монтиране  на VU. 
VU извлича  тези данни  от VuCalibrationData 
(допълнение  1) на vuCalibrationRecords, като 
CalibrationPurpose е равно  на: ‘03’H  Дата  на 
свързване  на 
тахографа
  
RTM18 
Моментна  
скорост  VU генерира  цяло  число  като стойност  на 
елемента  RTM18 на данните . 
VU присвоява  като стойност  на RTM18 
последната  записана  моментна  скорост  при 
последното  актуализиране  на RtmData.  Последна  
записана  
моментна  
скорост
  
RTM19 
Времеви  
печат  За елемента  RTM17 на данните  VU 
генерира  целочислена  стойност  (timeReal 
от допълнение  1). 
VU присвоява  като стойност  на RTM19 
момента  на последното  актуализиране  на 
RtmData.  Времеви  печат  
на текущия  
запис  Tachog­
raphPayload
  
5.4.6  Механизъм  за прехвърляне  на данни  
DSC_42 Полезните  данни , определени  преди , се заявяват  от четеца  
(REDCR) след  етапа  на инициализиране  и впоследствие  се 
предават  от DSRC-VU  в разпределения  прозорец . REDCR 
използва  командата  GET, за да извлече  данните . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 515  
DSC_43 При всеки  обмен  на данни  по DSRC те трябва  да бъдат  
кодирани  съгласно  PER (Packed Encoding Rules) 
UNALIGNED, с изключение  на
 
и
 , които  трябва  да бъдат  кодирани  
съгласно  OER (Octet Encoding Rules), определени  в 
стандарт  ISO/IEC 8825-7, Rec. ITU-T X.696.  
▼B 
5.4.7  Подробно  описание  на транзакцията  по DSRC  
DSC_44 Инициализирането  се извършва  съгласно  DSC_44— 
DSC_48 и таблици  14.4—14.9. На етапа  на инициали­  
зиране  REDCR започва  изпращането  на фрейм , 
съдържащ  BST (Beacon Service Table) съгласно  EN 
12834 и EN 13372, 6.2, 6.3, 6.4 и 7.1 с настройките , 
определени  в таблица  14.4 по-долу . 
Таблица  14.4.  
Инициализиране  — настройки  за фрейма  с BST  
Поле  Настройки  
Link Identifier („ Иденти­  
фикатор  на връзката “) Broadcast address  
BeaconId  Съгласно  EN 12834  
Time  Съгласно  EN 12834  
Профил  Без разширение , да се 
използва  0 или 1 
MandApplications  Без разширение , EID 
липсва , параметърът  
липсва , AID= 2 
Freight&Fleet  
NonMandApplications  Липсва  
ProfileList  Без разширение , брой  на 
профилите  в списъка  = 0 
Fragmentation header  Без фрагментиране  
Настройки  за слой  2 PDU с команда , UI команда  
Практически  пример  за настройките , определени  в 
таблица  14.4, с указание  за кодиранията  на битовете , се 
дава в следващата  таблица  14.5.  
Таблица  14.5.  
Инициализиране  — пример  за съдържанието  на фрейма  с BST
 Октет  # 
Атрибут /поле  Битове  в октета  Описание  
1 FLAG
  Флаг  за начало  
2 Broadcast ID
  Broadcast address  
3 MAC Control Field
  PDU с команда  
4 LLC Control field
  UI команда  ▼M1
 02016R0799 — BG — 26.02.2020 — 002.001 — 516
 Октет  # 
Атрибут /поле  Битове  в октета  Описание  
5 Fragmentation header
  Без фрагментиране  
6 BST
  Заявка  за инициали­  
зиране  
SEQUENCE {  
OPTION indicator 
BeaconID SEQUENCE { 
ManufacturerId INTEGER (0..65535)
  Липсват  незадъл­  
жителни  (NonMand) 
приложения
  
Идентификатор  на 
производителя  
7
 
8
 
IndividualID INTEGER (0..134217727) 
}
 27 бита  на разположение  
за идентификация  на 
производителя  
9
 
10
 
11
 
12 Time INTEGER (0..4294967295)
  32 bit UNIX в реално  
време  
13
 
14
 
15
 
16 Profile INTEGER (0..127,...)
  Без разширение . Пример  
за профил  0 
17 MandApplications SEQUENCE 
(SIZE(0..127,...)) 
OF {
  Без разширение , брой  на 
mandApplications = 1  
18 SEQUENCE {  
OPTION indicator
  EID липсва  
OPTION indicator
  Липсващ  параметър  
AID DSRCApplicationEntityID } }
  Без разширение . AID = 
2 Freight&Fleet  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 517
 Октет  # 
Атрибут /поле  Битове  в октета  Описание  
19 ProfileList SEQUENCE (0..127,...) OF 
Profile }
  Без разширение , брой  на 
профилите  в списъка  = 0 
20 FCS
  Контролна  поредица  за 
фрейма  
21
 
22 Flag
  Флаг  за край  
DSC_45 Когато  DSRC-VU  получи  BST, то заявява  разпределянето  
на частен  прозорец  съгласно  EN 12795 и EN 13372, 7.1.1, 
без специфични  настройки  за RTM. В таблица  14.6 се 
дава пример  за кодирането  на битовете . 
Таблица  14.6.  
Инициализиране  — съдържание  на фрейма  със заявка  за разпределяне  на частен  
прозорец
 Октет  # 
Атрибут /поле  Битове  в октета  Описание  
1 FLAG
  Флаг  за начало  
2 Private LID
  Адрес  на връзката  за 
конкретно  DSRC-VU  
3
 
4
 
5
 
6 MAC Control field
  Заявка  за частен  
прозорец  
7 FCS
  Контролна  поредица  за 
фрейма  
8
 
9 Flag
  Флаг  за край  
DSC_46 В отговор  REDCR разпределя  частен  прозорец  съгласно  
EN 12795 и EN 13372, 7.1.1 без специфични  настройки  за 
RTM.  
В таблица  14.7 се дава пример  за кодирането  на битовете . 
Таблица  14.7.  
Инициализиране  — съдържание  на фрейма  за разпределяне  на частен  прозорец
 Октет  # 
Атрибут /поле  Битове  в октета  Описание  
1 FLAG
  Флаг  за начало  
2 Private LID
  Адрес  на конкретното  
DSRC-VU за връзката  
3
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 518
 Октет  # 
Атрибут /поле  Битове  в октета  Описание  
4
 
5
 
6 MAC Control field
  Разпределяне  на частен  
прозорец  
7 FCS
  Контролна  поредица  за 
фрейма  
8
 
9 Flag
  Флаг  за край  
DSC_47 Когато  DSRC-VU  получи  разпределянето  на частен  
прозорец , то изпраща  своята  VST (Vehicle Service Table) 
съгласно  EN 12834 и EN 13372, 6.2, 6.3, 6.4 и 7.1 с наст­  
ройки , определени  в таблица  14.8, като използва  разпред­  
еления  частен  прозорец . 
Таблица  14.8.  
Инициализиране  — настройки  за фрейма  с VST  
Поле  Настройки  
Private LID  Съгласно  EN 12834  
Параметри  на VST  Попълва  се =0, после  за всяко  
поддържано  приложение : EID 
наличен , параметър  наличен , 
AID=2, EID съгласно  генерирания  
от бордовото  устройство  (OBU)  
Параметър  Без разширение , съдържа  RTM 
Context Mark  
ObeConfiguration  Незадължителното  поле  ObeStatus 
може  да е налично , но не се 
използва  от REDCR  
Fragmentation header  Без фрагментиране  
Настройки  за слой  2 PDU с команда , UI команда  
DSC_48  DSRC-VU  трябва  да поддържа  приложението  „Freight and 
Fleet“, идентифицирана  от Application Identifier ‘2’. Може  
да се поддържат  и други  Application Identifiers, но те не 
трябва  да присъстват  в тази VST, тъй като BST изисква  
само  AID=2. Полето  „Applications“ („ Приложения “) 
съдържа  списък  на инстанции  на поддържаните  
приложения  в DSRC-VU . За инстанциирането  на всяко  
поддържано  приложение  се дава препратка  към съот­  
ветния  стандарт , състояща  се от маркера  RTM Context 
Mark, съставен  от OBJECT IDENTIFIER, представляващ  
съответния  стандарт , неговата  част (9 за RTM) и евен­  
туално  неговата  версия , плюс  един  EID, който  е 
генериран  от DSRC-VU и е свързан  с инстанцията  на 
това приложение . 
Практически  пример  за настройките , определени  в 
таблица  14.8, с указание  за кодиранията  на битовете , се 
дава в таблица  14.9.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 519  
Таблица  14.9.  
Инициализиране  — пример  за съдържанието  на фрейма  с VST
 Октет  # 
Атрибут /поле  Битове  в октета  Описание  
1 FLAG
  Флаг  за начало  
2 Private LID
  Адрес  на конкретното  
DSRC-VU за връзката  
3
 
4
 
5
 
6 MAC Control field
  PDU с команда  
7 LLC Control field
  UI команда  
8 Fragmentation header
  Без фрагментиране  
9 VST 
SEQUENCE {
  Отговор  на инициали­  
зиране  
Fill BIT STRING (SIZE(4))
  Не се използва  и е 
зададен  равен  на 0 
10 Profile INTEGER (0..127,…) 
Applications SEQUENCE OF {
  Без разширение . Пример  
за профил  0 
11
 Без разширение , 1 
приложение  
12 SEQUENCE {  
OPTION indicator
  EID налице  
OPTION indicator
  Параметърът  липсва  
AID DSRCApplicationEntityID
  Без разширение . AID= 2 
Freight&Fleet  
13 EID Dsrc-EID
  Определен  в рамките  на 
OBU и идентифициращ  
инстанцията  на прило­  
жението . 
14 Parameter Container {
  Без разширение , 
Container Choice = 02, 
Октетен  низ 
15
 Без разширение , дължина  
на Rtm Context Mark = 8  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 520
 Октет  # 
Атрибут /поле  Битове  в октета  Описание  
16 Rtm-ContextMark::= SEQUENCE 
{ 
StandardIdentifier 
standardIdentifier
  ►M1 Object Identifier на 
поддържания  стандарт , 
част и версия . Пример : 
ISO (1) Standard (0) 
TARV (15638) part9 (9) 
Version1 (1). 
Първият  октет  е 06H, 
който  е Object Identifier. 
Вторият  октет  е 06H, 
който  дава неговата  
дължина . Следващите  6 
октета  кодират  
примерния  Object 
Identifier. ◄ 17
 
18
 
19
 
20
 
21
 
22
 
23
 
24 ObeConfiguration Sequence {  
OPTION indicator
  ObeStatus липсва  
EquipmentClass INTEGER (0..32767)
  
25
 
26 ManufacturerId INTEGER (0..65535)
  Идентификатор  на 
производителя  на 
DSRC-VU, както  е 
описано  в ISO 14816 
Register  27
 
28 FCS
  Контролна  поредица  за 
фрейма  
29
 
30 Flag
  Флаг  за край  
DCS_49 После  REDCR извлича  данните , като издава  команда  GET 
в съответствие  с командата  GET, определена  в EN 13372, 
6.2, 6.3, 6.4 и EN 12834, с настройки  съгласно  таблица  
14.10.  
Таблица  14.10.  
Инициализиране  — настройки  за фрейма  Get Request  
Поле  Настройки  
Invoker Identifier (IID)  Липсва  
Link Identifier (LID)  Адрес  на конкретното  DSRC-VU за 
връзката  
Chaining  Не 
Element Identifier (EID)  Както  е указано  във VST. Без 
разширение . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 521  
Поле  Настройки  
Access Credentials  Не 
AttributeIdList  Без разширение , 1 атрибут , Attri­
buteID = 1 (RtmData)  
Fragmentation  Не 
Layer2 settings  PDU с команда , Polled ACn 
команда  
В таблица  14.11 се дава пример  за извличането  на 
данните  за RTM.  
Таблица  14.11.  
Представяне  — пример  за фрейма  Get Request
 Октет  # 
Атрибут /поле  Битове  в октета  Описание  
1 FLAG
  Флаг  за начало  
2 Private LID
  Адрес  на конкретното  
DSRC-VU за връзката  
3
 
4
 
5
 
6 MAC Control field
  PDU с команда  
7 LLC Control field
  Polled ACn команда , n 
бит 
8 Fragmentation header
  Без фрагментиране  
9 Get.request 
SEQUENCE {
  Заявка  за получаване  
(Get)  
OPTION indicator
  Access Credentials 
липсват  
OPTION indicator
  IID липсва  
OPTION indicator
  AttributeIdList налице  
Fill BIT STRING(SIZE(1))
  Зададен  на 0. 
10 EID INTEGER(0..127,…)
  EID на инстанцията  на 
приложението  за RTM, 
както  е указано  във 
VST. Без разширение . 
11 AttributeIdList SEQUENCE OF { 
AttributeId }}
  Без разширение , брой  на 
атрибутите  = 1 
12
 AttributeId=1, RtmData. 
Без разширение . 
13 FCS
  Контролна  поредица  за 
фрейма  
14
 
15 Flag
  Флаг  за край ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 522  
DSC_50 Когато  DSRC-VU  получи  заявката  GET, то отговаря  на 
GET със заявените  данни  в съответствие  с отговора  на 
GET, определен  в EN 13372, 6.2, 6.3, 6.4 и EN 12834, с 
настройки  съгласно  таблица  14.12.  
Таблица  14.12.  
Представяне  — настройки  за фрейма  с отговора  на 
GET  
Поле  Настройки  
Invoker Identifier (IID)  Липсва  
Link Identifier (LID)  Съгласно  EN 12834  
Chaining  Не 
Element Identifier (EID)  Както  е указано  във VST.  
Access Credentials  Не 
Fragmentation  Не 
Layer2 settings  PDU с отговора , отговорът  
е налице  и командата  е 
приета , ACn команда  
В таблица  14.13 се дава пример  за извличането  на 
данните  за RTM.  
Таблица  14.13.  
Представяне  — пример  за съдържанието  на фрейма  с отговора
 Октет  # 
Атрибут /поле  Битове  в октета  Описание  
1 FLAG
  Флаг  за начало  
2 Private LID
  Адрес  на конкретното  
DSRC-VU за връзката  
3
 
4
 
5
 
6 MAC Control field
  PDU с отговора  
7 LLC Control field
  Отговорът  е налице , 
ACn команда , n бит 
8 LLC Status field
  Отговорът  е налице  и 
командата  е приета  
9 Fragmentation header
  Без фрагментиране  
10 Get.response 
SEQUENCE {
  Get Response ( полу­  
чаване  на отговор ) ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 523
 Октет  # 
Атрибут /поле  Битове  в октета  Описание  
OPTION indicator
  IID липсва  
OPTION indicator
  Attribute List налице  
OPTION indicator
  Return status липсва  
Fill BIT STRING(SIZE(1))
  Не се използва  
11 EID INTEGER(0..127,…)
  Отговор  от инстанции­  
рането  на приложението  
за RTM. 
Без разширение  
12 AttributeList SEQUENCE OF {
  Без разширение , брой  на 
атрибутите  = 1 
13 Attributes SEQUENCE { 
AttributeId
  Без разширение , Attri­
buteID = 1 (RtmData)  
14 AttributeValue CONTAINER {
  Без разширение , 
Container Choice = 10  10 . 
15
 RtmData  
16
 
17
 
… …  
n }}}}
  
n+1 FCS
  Контролна  поредица  за 
фрейма  
n+2
 
n+3 Flag
  Флаг  за край  
DSC_51 След  това REDCR приключва  връзката , като издава  
команда  EVENT_REPORT, RELEASE съгласно  EN 
13372, 6.2, 6.3, 6.4 и EN 12834,7.3.8, без специфични  
настройки  за RTM. В таблица  14.14 се дава пример  за 
кодирането  на битовете  за командата  RELEASE.  
Таблица  14.14.  
Приключване . Съдържание  на фрейма  EVENT_REPORT Release
 Октет  # 
Атрибут /поле  Битове  в октета  Описание  
1 FLAG
  Флаг  за начало  
2 Private LID
  Адрес  на конкретното  
DSRC-VU за връзката  
3
 
4
 ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 524
 Октет  # 
Атрибут /поле  Битове  в октета  Описание  
5
 
6 MAC Control field
  Фреймът  съдържа  LPDU 
с команда  
7 LLC Control field
  UI команда  
8 Fragmentation header
  Без фрагментиране  
9 EVENT_REPORT.request 
SEQUENCE {
  EVENT_REPORT 
(Release)  
OPTION indicator
  Access Credentials 
липсват  
OPTION indicator
  Липсва  параметър  за 
събитието  
OPTION indicator
  IID липсва  
Mode BOOLEAN
  Не се очаква  отговор  
10 EID INTEGER (0..127,…)
  Без разширение , EID = 0 
(System)  
11 EventType INTEGER (0..127,…) }
  Event type 0 = Release  
12 FCS
  Контролна  поредица  за 
фрейма  
13
 
14 Flag
  Флаг  за край  
DSC_52 Не се очаква  DSRC-VU  да отговори  на командата  Release. 
След  това връзката  приключва . 
5.4.8  Описание  на изпитването  за транзакция  по DSRC  
DSC_53 Пълно  изпитване , включващо  защита  на данните , трябва  
да се извършва  съгласно  допълнение  11 относно  общите  
механизми  за сигурност  от оправомощени  лица  с достъп  
до процедури  за сигурност , използвайки  обичайната  
команда  GET, както  е определено  по-горе. 
DSC_54 Изпитването  за въвеждане  в експлоатация  и при 
периодичен  технически  преглед , за което  е необходимо  
дешифриране  и разбиране  на съдържанието  на дешифри­  
раните  данни , се извършва  съгласно  допълнение  11 
относно  общите  механизми  за сигурност  и съгласно  
списъка  в допълнение  9 на минимално  изискваните  
изпитания  за одобрение  на типа . 
За базово  изпитване  на връзката  по DSRC може  да се 
използва  обаче  и командата  ECHO. Такова  изпитване  
може  да се изисква  за въвеждане  в експлоатация , при 
периодичен  технически  преглед  или другояче  по искане  
на компетентния  контролен  орган  или съгласно  Регламент  
(ЕС) № 165/2014 ( виж 6 по-долу ). ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 525  
DSC_55 За да се извърши  това базово  изпитване  на връзката , 
REDCR издава  командата  ECHO по време  на сесия , т.е. 
след  като успешно  завърши  етапът  на инициализиране . 
Поради  това последователността  на взаимодействията  е 
сходна  с тази при разпитване : 
— Стъпка  № 1: REDCR  изпраща  таблица  за навигаци­  
онните  услуги  (Beacon Service Table — BST), която  
включва  идентификаторите  на приложения  (AID) в 
списъка  на услугите , поддържани  от него . В прило­  
женията  за RTM това ще бъде  просто  услугата  със 
стойност  на AID = 2.  
DSRC-VU  оценява  получената  BST и отговаря , когато  
установи , че BST заявява  Freight&Fleet (AID = 2). Ако 
REDCR  не предлага  AID=2,  DSRC-VU  прекратява  
своята  транзакция  с REDCR . 
— Стъпка  № 2:  DSRC-VU  изпраща  заявка  за 
разпределяне  на частен  прозорец . 
— Стъпка  № 3: REDCR  изпраща  разпределение  на 
частен  прозорец . 
— Стъпка  № 4: DSRC-VU  използва  разпределения  частен  
прозорец , за да изпрати  своята  таблица  за услуги  във 
връзка  с превозното  средство  (Vehicle Service Table — 
VST). Тази  VST включва  списък  на всички  инстан­  
циирания  на различните  услуги , поддържани  от това 
DSRC-VU  в рамките  на AID=2. Различните  инстан­  
циирания  се идентифицират  посредством  уникални  
идентификатори  на елементи  (Element Identifiers — 
EIDs), всеки  от които  е свързан  със стойност  на пара­  
метър , указваща  инстанцията  на приложението , което  
се поддържа . 
— Стъпка  № 5: след  това четецът  REDCR  анализира  
предложената  VST и или прекъсва  връзката  
(RELEASE) поради  липса  на интерес  към каквото  и 
да било , предложено  от VST (т.е. той получава  VST 
от DSRC-VU , което  не е за RTM), или започва  инстан­  
циирането  на приложение , ако получи  подходяща  
VST.  
— Стъпка  № 6: REDCR  издава  команда  (ECHO) на 
конкретното  DSRC-VU  и разпределя  частен  прозорец . 
— Стъпка  № 7: DSRC-VU  използва  новоразпределения  
частен  прозорец , за да изпрати  фрейм  с отговора  на 
ECHO.  
В следващите  таблици  се дава практически  пример  за сесия  на 
обмен  на данни  чрез ECHO.  
DSC_56 Инициализирането  се извършва  съгласно  5.4.7 (DSC_44— 
DSC_48) и таблици  14.4—14.9.  
DSC_57 След  това REDCR команда  ACTION, ECHO съгласно  ISO 
14906, съдържаща  100 октета  данни  и без специфични  
настройки  за RTM. Таблица  14.15 показва  съдържанието  
на фрейма , изпратен  от REDCR.  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 526  
Таблица  14.15.  
Пример  за фрейм  за заявка  ACTION, ECHO
 Октет  # 
Атрибут /поле  Битове  в октета  Описание  
1 FLAG
  Флаг  за начало  
2 Private LID
  Адрес  на конкретното  
DSRC-VU за връзката  
3
 
4
 
5
 
6 MAC Control field
  PDU с команда  
7 LLC Control field
  Polled ACn команда , n 
бит 
8 Fragmentation header
  Без фрагментиране  
9 ACTION.request 
SEQUENCE {
  Заявка  за действие  
(ECHO)  
OPTION indicator
  Access Credentials 
липсват  
OPTION indicator
  Параметър  за действие  
налице  
OPTION indicator
  IID липсва  
Mode BOOLEAN
  Очаква  се отговор  
10 EID INTEGER (0..127,…)
  Без разширение , EID = 0 
(System)  
11 ActionType INTEGER (0..127,…)
  Без разширение , вид на 
действието  — заявка  
ECHO  
12 ActionParameter CONTAINER {
  Без разширение , 
Container Choice = 2  
13
 Без разширение . 
Дължина  на низа  = 100 
октета  
14
 Данни , които  трябва  да 
се върнат  обратно  
… …  
113 }}
  
114 FCS
  Контролна  поредица  за 
фрейма  
115
 
116 Flag
  Флаг  за край ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 527  
DSC_58 Когато  DSRC-VU  получи  заявката  ECHO, то изпраща  
отговор  от 100 октета  на ECHO, като връща  обратно  
получената  команда , съгласно  ISO 14906, без специфични  
настройки  за RTM. В таблица  14.16 се дава пример  за 
кодирането  на равнище  бит. 
Таблица  14.16.  
Пример  за фрейм  за отговор  на ACTION, ECHO
 Октет  # 
Атрибут /поле  Битове  в октета  Описание  
1 FLAG
  Флаг  за начало  
2 Private LID
  Адрес  на конкретното  
DSRC-VU за връзката  
3
 
4
 
5
 
6 MAC Control field
  PDU с отговора  
7 LLC Control field
  ACn команда , n бит 
8 LLC status field
  Отговорът  е налице  
9 Fragmentation header
  Без фрагментиране  
10 ACTION.response 
SEQUENCE {
  ACTION response 
(ECHO)  
OPTION indicator
  IID липсва  
OPTION indicator
  Параметър  за отговор  
налице  
OPTION indicator
  Return status липсва  
Fill BIT STRING (SIZE (1))
  Не се използва  
11 EID INTEGER (0..127,…)
  Без разширение , EID = 0 
(System)  
12 ResponseParameter CONTAINER {
  Без разширение , 
Container Choice = 2  
13
 Без разширение . 
Дължина  на низа  = 100 
октета  
14
 Данни , върнати  обратно  
… …  
113 }}
  
114 FCS
  Контролна  поредица  за 
фрейма  
115
 
116 Flag
  Флаг  за край ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 528  
__________  
▼B 
5.6 Прехвърляне  на данни  между  DSRC-VU и VU 
5.6.1  Физическа  връзка  и интерфейси  
DSC_66 Връзката  между  VU и DSRC-VU  може  да бъде  физическа  
чрез кабел  или безжична  с малък  обсег  въз основа  на 
Bluetooth v4.0 BLE.  
DSC_67 Независимо  от избора  на физическата  връзка  и 
интерфейса  трябва  да бъдат  изпълнени  следните  изиск­  
вания : 
DSC_68  ►M1 а) Връзката  между  бордовото  устройство  и DSRC- 
VU, която  не е вътрешна  за бордовото  
устройство , трябва  да бъде  по отворен  
стандарт , за да е възможно  договарянето  с 
различни  доставчици  за получаването  на 
бордови  устройства  и DSRC-VU, както  и на 
DSRC-VU от различни  партиди . Бордовото  
устройство  се свързва  с DSRC-VU по някой  
от следните  начини : ◄ 
i) по фиксиран  кабел  от най-малко  2 метра , 
използвайки  от страната  на DSRC-VU 
мъжки  съединител  от одобрен  тип Straight 
DIN 41612 H11 с 11 щифта , а от страната  на 
VU — съответен  женски  съединител , 
одобрен  по DIN/ISO,  
ii) чрез Bluetooth Low Energy (BLE),  
iii) чрез стандартна  връзка  по ISO 11898 или 
SAE J1939.  
DSC_69 б) Определението  за интерфейсите  и връзката  между  VU 
и DSRC-VU трябва  да е в съответствие  с командите  на 
приложния  протокол  съгласно  5.6.2 и 
DSC_70 в) VU и DSRC-VU трябва  да поддържат  операцията  на 
прехвърляне  на данни  по връзката  по отношение  на 
характеристики  и електрическо  захранване . 
5.6.2  Приложен  протокол  
DSC_71 Приложният  протокол  за комуникацията  между  устрой­  
ството  за връзка  от разстояние  на VU и DSRC-VU 
отговаря  за периодичното  прехвърляне  на данни  по 
връзката  от разстояние  от VU към DSRC.  
DSC_72 Установяват  се следните  основни  команди : 
1. Initialisation of the communication link — Request („ Ини­  
циализиране  на съобщителната  връзка  — заявка “) 
2. Initialisation of the communication link — Response 
(„Инициализиране  на съобщителната  връзка  — 
отговор “) 
3. Send Data („ Изпращане  на данни “) с Identifier („ иден­  
тификатор “) на приложението  за RTM и Payload 
(полезни  данни ), определени  от RTM Data  
4. Acknowledgment („ Потвърждаване  на приемането “) на 
данните  
5. Termination of the communication link — Request („ При­  
ключване  на съобщителната  връзка  — заявка “) 
6. Termination of the communication link — Response 
(„Приключване  на съобщителната  връзка  — отговор “) 
DSC_73 В ASN1.0 горните  команди  могат  да бъдат  определени , 
както  следва : ▼M2
 02016R0799 — BG — 26.02.2020 — 002.001 — 529
  
DSC_74 Следва  описание  на командите  и параметрите : 
—
 
се използва  за инициализиране  на съобщителната  
връзка . Командата  се изпраща  от VU на DSRC-VU. 
LinkIdentifier се задава  от VU и се съобщава  на 
DSRC-VU за проследяване  на конкретна  съобщителна  
връзка . 
(Забележка : това е за поддържане  на бъдещи  връзки  и 
други  приложения /модули  като бордово  претегляне ). 
—
 
се използва  от DSRC-VU за даване  на отговор  на 
заявката  за инициализиране  на съобщителната  
връзка . Командата  се изпраща  от DSRC-VU на VU. 
Командата  предоставя  резултата  от инициализирането  
като отговор  = 1 (Success, т.е. успешно ) или 0 = 
(Failure, т.е. неуспешно ). 
DSC_75 Инициализирането  на съобщителната  връзка  се извършва  
само  след  монтиране , калибриране  и пускане  на двигателя  
/ VU е включено . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 530  
—
 се използва  от VU за изпращане  
на подписаните  RCDTData ( данните  от връзката  от 
разстояние ) към DSRC-VU. Данните  се изпращат  на 
всеки  60 секунди . Параметърът  DataTransactionId 
идентифицира  конкретното  предаване  на данни . LinkI­
dentifier се използва  и за да се гарантира , че съот­  
ветната  връзка  е правилната . 
—
 се изпраща  от 
DSRC-VU за обратна  връзка  към VU относно  
приемането  на данните  вследствие  на команда
  
, идентифицирана  от параметъра  
DataTransactionId. Параметърът  Answer е 1 (Success, 
т.е. успешно ) или =0 (Failure, т.е. неуспешно ). Ако 
VU получи  повече  от три отговора , равни  на 0, или 
ако VU не получи  RCDT Data Acknowledgment за 
изпратена  преди  това команда  RCDT- Send Data с 
конкретен  параметър  DataTransactionId, VU генерира  
събитие , което  регистрира . 
—
 се 
изпраща  от VU на DSRC-VU за приключване  на 
връзката  за конкретен  LinkIdentifier.  
DSC_76 При рестартирането  на DSRC-VU или VU всички  същест­  
вуващи  съобщителни  връзки  се прекратяват , тъй като 
може  да има „висящи “ връзки  поради  внезапното  
изключване  на VU.  
—
 се 
изпраща  от DSRC-VU на VU, за да потвърди  заявката  
за приключване  на връзката  от VU за конкретния  
LinkIdentifier.  
5.7 Третиране  на грешки  
5.7.1  Записване  и съобщаване  на данните  в DSRC-VU  
▼M1 
DSC_77  Данните  се предоставят , вече защитени , от функцията  
VUSM  на DSRC-VU . VUSM  проверява  дали  данните , 
регистрирани  в DSRC-VU , са били  записани  правилно . 
Записването  и протоколирането  на всякакви  грешки  при 
прехвърлянето  на данни  от бордовото  устройство  към 
паметта  на DSRC-VU  се извършва  с типа  EventFaultType 
и изброена  (enum) стойност , зададена  като събитие  ‘0C’H 
— Грешка  в комуникацията  с устройството  за връзка  от 
разстояние , заедно  с времеви  печат . 
▼B 
DSC_78  VU  трябва  да поддържа  файл , идентифициран  от 
уникално  име, което  лесно  да се разпознава  от 
контрольори  за целите  на регистрирането  на „вътрешни  
неизправности  по връзката  във VU“.  
DSC_79 Ако VUPM се опита  неуспешно  да получи  VU данни  от 
модула  за сигурност  (за подаване  на VU-DSRC), тя 
записва  този неуспех  с типа  EventFaultType и изброена  
стойност , зададена  като ‘62’H Remote Communication 
Facility  за неизправност  във връзката , заедно  с времевия  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 531  
печат . Неуспешната  връзка  се открива , когато  при повече  
от три последователни  опита  не се получи  съобщение
  
за съответната  команда
  
(т.е. със същия  DataTransactionId в 
съобщенията
  ).  
5.7.2  Грешки  при безжичната  връзка  
DSC_80 Третирането  на грешки  при връзката  трябва  да бъде  в 
съответствие  със стандартите , отнасящи  се за DSRC, а 
именно  EN 300 674-1, EN 12253, EN 12795, EN 12834, 
и съответните  параметри  по EN 13372.  
5.7.2.1  Грешки  по криптирането  и подписа  
DSC_81 Грешките  по криптирането  и подписа  се третират  
съгласно  допълнение  11 относно  общите  механизми  за 
сигурност  и не присъстват  в съобщения  за грешки , 
свързани  с прехвърлянето  на данни  по DSRC.  
5.7.2.2  Регистриране  на грешки  
DSRC представлява  динамична  безжична  връзка  в среда  на непос­  
тоянни  атмосферни  условия  и смущения  — особено  в комби­  
нациите  от „преносим  REDCR“ и „превозно  средство  в движение “ 
при това приложение . Поради  това е необходимо  да се установи  
разликата  между  „неуспешно  извличане  на данни “ (read failure) и 
„грешка “. При транзакция  по безжичен  интерфейс  неуспешното  
извличане  на данни  е нещо  обичайно , последицата  от което  обик­  
новено  е повторен  опит  за излъчване  на BST и за изпълнение  на 
поредицата  от действия , водещо  в повечето  случаи  до успешно  
свързване  и прехвърляне  на данни , ако целевото  превозно  
средство  не излезе  извън  обсега  през времето , необходимо  за 
повторно  предаване . („Успешното “ извличане  на данни  може  да 
включва  няколко  повторни  опита ). 
Неуспешно  извличане  на данни  може  да се получи , понеже  
антените  са „сдвоени “ неправилно  (грешно  „насочване “); понеже  
една  от антените  е екранирана  — това може  да е умишлено , но 
също  така е възможно  да е причинено  от физическото  присъствие  
на друго  превозно  средство ; поради  радиосмущения , по-специално  
от WIFI на около  5,8 GHz или други  публично  достъпни  безжични  
връзки , или може  да е причинено  от радарни  смущения  или от 
неблагоприятни  атмосферни  условия  (напр . по време  на гръмо­  
тевична  буря ); или просто  от излизането  извън  обсега  на връзката  
по DSRC. Регистрирането  на отделните  случаи  на неуспешно  
извличане  на данни  не е възможно  поради  неговото  естество , 
просто  защото  не е била  осъществена  комуникация . 
Ако обаче  представителят  на компетентния  контролен  орган  се 
насочи  към дадено  превозно  средство  и се опита  да разпита  
неговото  DSRC-VU , но последващото  прехвърляне  на данни  е неус­  
пешно , това може  да се дължи  на умишлено  манипулиране  и след­  
ователно  представителят  на компетентния  контролен  орган  се 
нуждае  от средство , за да протоколира  неуспеха  и да предупреди  
своите  колеги  надолу  по веригата  за възможно  наличие  на нару­  
шение . Колегите  след  това могат  да спрат  превозното  средство  и да 
извършат  физическа  проверка . DSRC-VU обаче  не може  да пред­  
остави  данни  относно  неуспешната  връзка , именно  защото  тя е била  
неуспешна . Следователно  това протоколиране  трябва  да бъде  
функция  на оборудването  на REDCR, която  да се предвиди  при 
неговото  проектиране . 
Неуспешното  извличане  на данни  (failure to read) технически  се 
различава  от „грешка “ (error). В настоящия  контекст  „грешка “ 
означава  придобиване  на погрешна  стойност . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 532  
Данните , прехвърлени  към DSRC-VU , се доставят  вече защитени , 
така че трябва  да бъдат  проверени  от доставчика  на данните  (виж 
5.4). 
Данните , предадени  впоследствие  по ефира , се проверяват  чрез 
циклични  контролни  суми  (CRC) на комуникационно  равнище . 
Ако CRC бъде  потвърдена , данните  са правилни . Ако CRC не 
бъде  потвърдена , данните  се предават  повторно . Вероятността  
неправилни  данни  да преминат  успешно  през проверка  чрез CRC 
е толкова  малка , че може  да бъде  пренебрегната . 
Ако CRC не бъде  потвърдена  и няма  време  за повторно  предаване  и 
получаване  на правилните  данни , тогава  резултатът  ще бъде  не 
грешка , а инстанцииране  на конкретния  тип неуспешно  извличане  
на данни . 
Единствените  значими  данни  за такъв  „неуспех “, които  могат  да 
бъдат  регистрирани , са за броя  на осъществените  успешни  стар­  
тирания  на транзакции , които  не са довели  до успешно  прехвърляне  
на данни  към REDCR.  
DSC_82 Следователно  REDCR  трябва  да регистрира , заедно  с 
времеви  печат , броя  на случаите , в които  етапът  на 
инициализиране  на разпитване  по DSRC е бил успешен , 
но транзакцията  е приключена  преди  успешното  
извличане  на данните  от REDCR. Тези  данни  трябва  да 
са на разположение  на представителя  на компетентния  
контролен  орган  и да се съхраняват  в паметта  на 
REDCR. Начинът  за постигане  на това се определя  при 
проектирането  на съответния  продукт  или в специ­  
фикация  от компетентния  контролен  орган . 
Единствените  значими  данни  за „грешка “, които  могат  да 
бъдат  регистрирани , са за броя  на случаите , в които  
REDCR не е успял  да декриптира  получените  данни . 
Следва  да се отбележи  обаче , че това ще е показателно  
само  за ефикасността  на софтуера  на REDCR. Възможно  е 
данните  технически  да бъдат  декриптирани , но да са 
безсмислени . 
DSC_83 Следователно  REDCR  трябва  да регистрира , заедно  с 
времеви  печат , броя  на случаите , в които  се е опитал , 
но не е успял  да дешифрира  данните , получени  по 
интерфейса  към DSRC.  
6 ИЗПИТВАНИЯ  ЗА ВЪВЕЖДАНЕ  В ЕКСПЛОАТАЦИЯ  И 
ПЕРИОДИЧЕН  ТЕХНИЧЕСКИ  ПРЕГЛЕД  НА ФУНКЦИЯТА  ЗА 
ВРЪЗКА  ОТ РАЗСТОЯНИЕ  
6.1 Общи  положения  
DSC_84 Предвидени  са два вида  изпитвания  за функцията  за 
връзка  от разстояние : 
1) Изпитване  чрез ECHO за валидиране  на безжичния  
съобщителен  канал  DSRC-REDCR  >>-:-< DSRC-VU . 
2) Изпитване  за сигурност  от край  до край , за да се 
гарантира , че карта  за монтаж  и настройки  може  да 
получи  достъп  до съдържанието  от криптирани  и 
подписани  данни , създадено  от VU и предадено  по 
безжичния  съобщителен  канал . 
6.2 ECHO  
Настоящият  раздел  съдържа  специални  разпоредби  за изпитване  
само  дали  функционира  каналът  DSRC-REDCR  >>-:-< DSRC-VU . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 533  
Целта  на командата  ECHO е да даде  възможност  на сервизи  или 
изпитателни  пунктове  за одобрение  на типа  да проверят  дали  DSRC 
функционира , без да е нужен  достъп  до сертификати  за сигурност . 
Поради  това от изпитвателното  оборудване  се изисква  само  да е в 
състояние  да инициализира  връзка  по DSRC (изпращайки  BST с 
AID=2), след  това да изпрати  команда  ECHO и, ако DSRC 
функционира , да приеме  отговора  на ECHO. Виж  5.4.8 за подроб­  
ности . Ако то получи  правилно  този отговор , каналът  за DSRC 
(DSRC-REDCR  >>-:-< DSRC-VU ) може  да бъде  валидиран  като 
функциониращ  правилно . 
6.3 Изпитване  за валидиране  на съдържанието  от защитени  данни  
DSC_85 Това  изпитване  се извършва  за валидиране  на защитения  
от край  до край  поток  от данни . За такова  изпитване  е 
необходим  тестов  DSRC четец . Тестовият  DSRC четец  
изпълнява  същите  функции  и спецификации , както  изпол­  
званият  от правоприлагащите  органи , като разликата  се 
състои  в това, че за удостоверяване  на автентичността  
на ползвателя  на тестовия  DSRC четец  се използва  
карта  за монтаж  и настройки , а не контролна  карта . 
Изпитването  може  да бъде  извършено  след  първона­  
чалното  активиране  на интелигентен  тахограф  или в 
края  на процедурата  на калибриране . След  активирането  
превозното  средство  генерира  и съобщава  на DSRC-VU 
защитените  данни  за равно  откриване . 
DSC_86 Сервизният  техник  поставя  тестовия  DSRC четец  на 
разстояние  между  2 и 10 метра  пред  превозното  средство . 
DSC_87 После  сервизният  техник  вкарва  карта  за монтаж  и 
настройки  в тестовия  DSRC четец , за да заяви  разпит­  
ването  на бордовото  устройство  за данни  за ранно  
откриване . След  успешно  разпитване  сервизният  техник  
осъществява  достъп  до получените  данни , за да се 
убеди , че те са валидирани  успешно  за цялост  и са 
декриптирани . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 534  
Допълнение  15 
МИГРАЦИЯ : УПРАВЛЕНИЕ  НА ЕДНОВРЕМЕННОТО  
СЪЩЕСТВУВАНЕ  НА РАЗЛИЧНИ  ПОКОЛЕНИЯ  ОБОРУДВАНЕ  
СЪДЪРЖАНИЕ  
1. ОПРЕДЕЛЕНИЯ  
2. ОБЩИ  РАЗПОРЕДБИ  
2.1. Преглед  на прехода  
2.2. Оперативна  съвместимост  между  бордовите  устройства  и картите  
2.3. Оперативна  съвместимост  между  бордовите  устройства  и 
датчиците  за движение  
2.4. Оперативна  съвместимост  между  бордови  устройства , тахографски  
карти  и устройства  за изтегляне  на данни  
2.4.1 Директно  изтегляне  на данни  от карта  със специализирано  инте­  
лигентно  устройство  (IDE)  
2.4.2 Изтегляне  на данни  от карта  през бордово  устройство  
2.4.3 Изтегляне  на данни  от бордово  устройство  
2.5. Оперативна  съвместимост  между  бордово  устройство  и 
оборудване  за калибриране  
3. ОСНОВНИ  СТЪПКИ  ПРЕЗ  ПЕРИОДА  ПРЕДИ  ДАТАТА  НА 
ВЪВЕЖДАНЕ  
4. РАЗПОРЕДБИ  ЗА ПЕРИОДА  СЛЕД  ДАТАТА  НА ВЪВЕЖДАНЕ  
1. ОПРЕДЕЛЕНИЯ  
За целите  по настоящото  допълнение  се използват  следните  опред­  
еления : 
Интелигентна  тахографска  система : както  е дефинирана  в 
настоящото  приложение  (глава  1: определение  ббб); 
Първо  поколение  тахографска  система : както  е дефинирано  в 
настоящия  регламент  (член  2: определение  1); 
Второ  поколение  тахографска  система : както  е дефинирано  в 
настоящия  регламент  (член  2: определение  7); 
Дата  на въвеждане : както  е дефинирана  в настоящото  приложение  
(глава  1: определение  ввв); 
Специализирано  интелигентно  устройство  (IDE) : устройство , 
използвано  за изтегляне  на данни , както  е дефинирано  в допълнение  
7 от настоящото  приложение . 
2. ОБЩИ  РАЗПОРЕДБИ  
2.1. Преглед  на прехода  
В преамбюла  към настоящото  приложение  е направен  преглед  на 
прехода  от първо  към второ  поколение  тахографски  системи . 
В допълнение  към разпоредбите  на този преамбюл : 
— първото  поколение  датчици  за движение  няма  да бъдат  
оперативно  съвместими  с второто  поколение  бордови  
устройства ; 
— инсталирането  на второто  поколение  датчици  за движение  в 
превозните  средства  ще започне  по същото  време  като на 
второто  поколение  бордови  устройства ; ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 535  
— устройствата  за изтегляне  на данни  и за калибриране  ще е необ­  
ходимо  да се развиват , за да могат  да поддържат  използването  и 
на двете  поколения  уреди  за регистриране  на данни  и тахог­  
рафски  карти . 
2.2. Оперативна  съвместимост  между  бордовите  устройства  и 
картите  
▼M1 
Подразбира  се, че първото  поколение  тахографски  карти  са 
оперативно  съвместими  с първото  поколение  бордови  устройства  
в съответствие  с приложение  IБ към Регламент  (ЕИО ) № 3821/85, 
както  и че второто  поколение  тахографски  карти  са оперативно  
съвместими  с второто  поколение  бордови  устройства  в съответствие  
с приложение  IВ от настоящия  регламент . В допълнение  към това 
се прилагат  следните  изисквания : 
▼B 
MIG_001 С изключение  на посоченото  в изискване  MIG_004 и 
изискване  MIG_005, първото  поколение  тахографски  
карти  могат  да продължат  да бъдат  използвани  във 
второто  поколение  бордови  устройства  до края  на 
техния  период  на валидност . От друга  страна , 
техните  титуляри  могат  да поискат  те да бъдат  
заменени  с тахографски  карти  от второ  поколение  
веднага  щом  се появят  такива  карти . 
MIG_002 Второто  поколение  бордови  устройства  ще трябва  да 
могат  да използват  всяка  вкарана  в тях карта  от първо  
поколение  от следните  видове : карта  на водач , 
контролна  карта  и фирмена  карта  на превозвач . 
MIG_003 Тази  способност  на подобни  бордови  устройства  може  
безвъзвратно  да бъде  премахвана  в заводи /сервизи  
(workshops), така че да не могат  повече  да бъдат  
приемани  тахографски  карти  от първо  поколение . 
Това  може  да се прави  само  след  като Европейската  
комисия  инициира  процедура , имаща  за цел да се 
поиска  от сервизите  да извършват  такава  дейност , 
например  при всяка  периодичен  технически  преглед  
на тахограф . 
MIG_004 По отношение  на картите  за монтаж  и настройка , 
бордовите  устройства  от второ  поколение  трябва  да 
могат  да използват  само  второ  поколение  такива  карти . 
MIG_005 За целите  по определяне  на работния  режим  бордовите  
устройства  от второ  поколение  трябва  да вземат  
предвид  само  типовете  на вкарваните  валидни  карти , 
без значение  кое е тяхното  поколение . 
MIG_006 Всяка  валидна  тахографска  карта  от второ  поколение  
трябва  да може  да се използва  в бордови  устройства  от 
първо  поколение  точно  по същия  начин  като тахог­  
рафска  карта  от първо  поколение  от същия  тип. 
2.3. Оперативна  съвместимост  между  бордовите  устройства  и 
датчиците  за движение  
Подразбира  се, че първото  поколение  датчици  за движение  са 
оперативно  съвместими  с първото  поколение  бордови  устройство , 
както  и че второто  поколение  датчици  за движение  са оперативно  
съвместими  с второто  поколение  бордови  устройства . В допълнение  
към това са валидни  следните  изисквания : 
MIG_007 Второто  поколение  бордови  устройства  няма  да могат  
да се сдвояват  и използват  с първо  поколение  датчици  
за движение . 
MIG_008 Възможно  е датчици  за движение  от второ  поколение  
да могат  да бъдат  сдвоявани  или само  с бордови  
устройства  от второ  поколение , или с бордови  
устройства  и от двете  поколения . 
2.4. Оперативна  съвместимост  между  бордови  устройства , тахог­  
рафски  карти  и устройства  за изтегляне  на данни  
MIG_009 Възможно  е устройства  за изтегляне  на данни  да могат  
да бъдат  използвани  само  с едно  поколение  бордови  
устройства  и тахографски  карти , или съответно  и с 
двете  поколения . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 536  
2.4.1  Директно  изтегляне  на данни  от карта  със специализирано  инте­  
лигентно  устройство  (IDE)  
MIG_010 IDE трябва  да могат  да изтеглят  данни  от тахографски  
карти  от едно  поколение , вкарани  в съответните  
четящи  устройства  за карти , като използват  меха­  
низмите  за сигурност  и протокола  за изтегляне  на 
данни  за това поколение , и изтеглените  данни  трябва  
да са с формата , дефиниран  за това поколение . 
MIG_011 За да се даде  възможност  за контролиране  на водачите  
от контролни  органи  на държави  извън  ЕС, трябва  да е 
възможно  изтегляне  на данните  от второ  поколение  
карти  на водачи  (и карти  за монтаж  и настройки ) 
точно  по същия  начин  както  от първо  поколение  
карти  на водачи  (и карти  за монтаж  и настройки ). 
Подобно  изтегляне  трябва  да включва : 
▼M1 
— неподписаните  елементарни  файлове  IC и ICC 
(незадължително ), 
▼B 
— неподписаните  елементарни  файлове  (от 1 во поко­  
ление )
 и
 
, 
▼M1 
— останалите  елементарни  файлове  с приложни  данни  
(в рамките  на DF Tachograph), изисквани  по 
протокола  за изтегляне  на данни  от карти  от 
първо  поколение . Информацията  трябва  да бъде  
защитена  с цифров  подпис  в съответствие  с меха­  
низмите  за сигурност  за първото  поколение . 
Подобно  изтегляне  не трябва  да включва  елементарни  
файлове  с приложни  данни , които  присъстват  само  във 
второ  поколение  карти  на водачи  (и карти  за монтаж  и 
настройки ) — елементарни  файлове  с приложни  данни  
в рамките  на DF Tachograph_G2.  
▼B 
2.4.2  Изтегляне  на данни  от карта  през бордово  устройство  
MIG_012 Данните  от второ  поколение  карта , вкарана  в първо  
поколение  бордово  устройство , трябва  да бъдат  
изтегляни  с използване  на първо  поколение  протокол  
за изтегляне  на данни . Картата  трябва  да отговаря  на 
командите  на бордовото  устройство  точно  по същия  
начин  като карта  от първо  поколение  и изтеглените  
данни  трябва  да бъдат  със същия  формат  като 
данните , изтеглени  от първо  поколение  карта . 
MIG_013 Данните  от първо  поколение  карта , вкарана  във второ  
поколение  бордово  устройство , трябва  да се изтеглят  с 
използване  на протокола  за изтегляне  на данни , 
дефиниран  в допълнение  7 от настоящото  приложение . 
Бордовото  устройство  трябва  да изпраща  команди  на 
картата  точно  по същия  начин  като бордово  устройство  
от първо  поколение  и изтеглените  данни  трябва  да 
съответстват  на формата , дефиниран  за карти  от 
първо  поколение . 
2.4.3  Изтегляне  на данни  от бордово  устройство  
▼M1 
MIG_014 С Изключение  на случаите  на проверка  на водача  от 
контролни  органи  на държави  извън  ЕС, данните  от 
второ  поколение  бордови  устройства  трябва  да се 
изтеглят  с използване  на второ  поколение  механизми  
за сигурност  и на протокола  за изтегляне  на данни , 
специфициран  в допълнение  7 към настоящото  прило­  
жение . 
MIG_015 С Цел проверка  на водача  да може  да се извършва  от 
контролни  органи  на държави  извън  ЕС, по избор  
може  да бъде  възможно  данни  от бордово  устройство  
от второ  поколение  да се изтеглят , като се използват  
първо  поколение  механизми  за сигурност . Изтеглените  
данни  трябва  да имат  същия  формат  като данните , 
изтеглени  от бордово  устройство  от първо  поколение . 
Тази  възможност  трябва  да може  да бъде  избрана  чрез 
команди  в менюто . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 537  
2.5. Оперативна  съвместимост  между  бордово  устройство  и 
оборудване  за калибриране  
MIG_016 Оборудването  за калибриране  трябва  да може  да 
извършва  калибриране  на всяко  поколение  тахографи , 
с използване  на протокола  за калибриране  на това 
поколение . Възможно  е калибриращото  оборудване  да 
може  да се използва  само  с едно  поколение  тахографи , 
или и с двете  поколения . 
3. ОСНОВНИ  СТЪПКИ  ПРЕЗ  ПЕРИОДА  ПРЕДИ  ДАТАТА  НА 
ВЪВЕЖДАНЕ  
MIG_017 Изпитвателните  ключове  и сертификати  трябва  да 
бъдат  на разположение  на производителите  не по- 
късно  от 30 месеца  преди  датата  на въвеждане . 
MIG_018 Трябва  да има готовност  изпитванията  за оперативна  
съвместимост  да започнат  при поискване  от произво­  
дителите  не по-късно  от 15 месеца  преди  датата  на 
въвеждане . 
MIG_019 Официалните  ключове  и сертификати  трябва  да бъдат  
достъпни  за производителите  не по-късно  от 12 месеца  
преди  датата  на въвеждане . 
MIG_020 Държавите  членки  трябва  да могат  да издават  второ  
поколение  карти  за монтаж  и настройки  не по-късно  
3 месеца  преди  датата  на въвеждане . 
MIG_021 Държавите  членки  трябва  да могат  да издават  всички  
видове  тахографски  карти  от второ  поколение  не по- 
късно  от 1 месец  преди  датата  на въвеждане . 
4. РАЗПОРЕДБИ  ЗА ПЕРИОДА  СЛЕД  ДАТАТА  НА ВЪВЕЖДАНЕ  
MIG_022 След  датата  на въвеждане  държавите  членки  трябва  да 
издават  тахографски  карти  само  от второ  поколение . 
MIG_023 На производителите  на бордови  устройства  / датчици  
за движение  се разрешава  да произвеждат  бордови  
устройства  / датчици  за движение  от първо  поколение  
докато  те се използват  в практиката , така че да могат  
да се заменят  неизправни  компоненти . 
MIG_024 На производителите  на бордови  устройства  / датчици  
за движение  се разрешава  да искат  и да получават  
запазване  на одобрението  на типа  на бордови  
устройства  / датчици  за движение , чийто  тип вече е 
одобрен . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 538  
Допълнение  16 
АДАПТОР  ЗА ПРЕВОЗНИ  СРЕДСТВА  ОТ КАТЕГОРИИ  M1 И N1 
СЪДЪРЖАНИЕ  
1. СЪКРАЩЕНИЯ  И РЕФЕРЕНТНИ  ДОКУМЕНТИ  
1.1. Съкращения  
1.2. Базови  стандарти  
2. ОБЩИ  ХАРАКТЕРИСТИКИ  И ФУНКЦИИ  НА АДАПТОРА  
2.1. Общо  описание  на адаптора  
2.2. Функции  
2.3. Сигурност  
3. ИЗИСКВАНИЯ  КЪМ  УРЕДИТЕ  ЗА РЕГИСТРИРАНЕ  НА 
ДАННИТЕ  ЗА ДВИЖЕНИЕТО  В СЛУЧАИТЕ , ПРИ  КОИТО  Е 
МОНТИРАН  АДАПТОР  
4. КОНСТРУКТИВНИ  И ФУНКЦИОНАЛНИ  ИЗИСКВАНИЯ  КЪМ  
АДАПТОРА  
4.1. Препредаване  и адаптиране  на входящите  импулси  за скорост  
4.2. Индуктиране  на входящите  импулси  във вградения  датчик  за 
движение  
4.3. Вграден  датчик  за движение  
4.4. Изисквания  за сигурност  
4.5. Експлоатационни  характеристики  
4.6. Материали  
4.7. Маркировки  
5. МОНТАЖ  НА УРЕДИТЕ  ЗА РЕГИСТРИРАНЕ  НА ДАННИТЕ  ЗА 
ДВИЖЕНИЕТО  В СЛУЧАИТЕ , ПРИ  КОИТО  СЕ ИЗПОЛЗВА  
АДАПТОР  
5.1. Монтаж  
5.2. Пломбиране  
6. ПРОВЕРКИ , ТЕХНИЧЕСКИ  ПРЕГЛЕДИ  И ПОПРАВКИ  
6.1. Периодични  технически  прегледи  
7. ОДОБРЕНИЕ  НА ТИПА  НА УРЕДИТЕ  ЗА РЕГИСТРИРАНЕ  НА 
ДАННИТЕ  ЗА ДВИЖЕНИЕТО  В СЛУЧАИТЕ , ПРИ  КОИТО  СЕ 
ИЗПОЛЗВА  АДАПТОР  
7.1. Общи  положения  
7.2. Функционален  сертификат  
1. СЪКРАЩЕНИЯ  И РЕФЕРЕНТНИ  ДОКУМЕНТИ  
1.1. Съкращения  
Следва  да се определи  Да се определи  
VU Бордово  устройство  
1.2. Базови  стандарти  
ISO16844-3 Пътни  превозни  средства . Тахографски  системи . Част  3: 
Интерфейс  на датчика  за движение  
2. ОБЩИ  ХАРАКТЕРИСТИКИ  И ФУНКЦИИ  НА АДАПТОРА  
2.1. Общо  описание  на адаптора  
ADA_001 Адапторът  осигурява  на свързано  с него  бордово  
устройство  защитени  данни  за движението , които  
постоянно  са представителни  за скоростта  на превозното  
средство  и за изминатото  разстояние . 
Адапторът  е предназначен  само  за тези превозни  средства , 
за които  се изисква  да са снабдени  с уреди  за регистриране  
на данните  за движението  в съответствие  с настоящия  
регламент . ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 539  
Той се монтира  и използва  само  на типовете  превозни  
средства , дефинирани  в шш) „адаптор “, когато  технически  
не е възможно  монтирането  на друг  тип съществуващ  
датчик  за движение , който  иначе  е в съответствие  с 
разпоредбите  в настоящото  приложение  и допълнения  
1—16 към него . 
Адапторът  трябва  да не е механично  свързан  с движеща  се 
част от превозното  средство , а да е свързан  с импулсите  за 
скорост /разстояние , генерирани  от вградените  датчици  или 
от алтернативни  интерфейси . 
ADA_002 В корпуса  на адаптора  се монтира  датчик  за движение  от 
одобрен  тип (съгласно  разпоредбите  на настоящото  
приложение  IВ, раздел  8 — Типово  одобрение  на 
уредите  за регистриране  на данните  за движението  и на 
тахографските  карти ), като адапторът  трябва  да включва  
също  преобразувател  на импулси , индуктиращ  входящите  
импулси  във вградения  датчик  за движение . Вграденият  
датчик  за движение  трябва  да е свързан  с бордовото  
устройство , така че интерфейсът  между  бордовото  
устройство  и адаптора  да е в съответствие  с изискванията , 
определени  в ISO 16844-3.  
2.2. Функции  
ADA_003 Адапторът  трябва  да изпълнява  следните  функции : 
— да служи  като интерфейс  и да адаптира  входящите  
импулси  за скоростта , 
— да индуктира  входящите  импулси  във вградения  датчик  
за движение , 
— всички  функции  на вградения  датчик  за движение , 
предоставящ  защитени  данни  на бордовото  устройство . 
2.3. Сигурност  
ADA_004 Не се изисква  адапторът  да има сертификат  за сигурност  в 
съответствие  с общата  цел за сигурност  на датчика  за 
движение , определена  в допълнение  10 към настоящото  
приложение . Вместо  това се прилагат  свързаните  със 
сигурността  изисквания , определени  в раздел  4.4 от 
настоящото  допълнение . 
3. ИЗИСКВАНИЯ  КЪМ  УРЕДИТЕ  ЗА РЕГИСТРИРАНЕ  НА ДАННИТЕ  
ЗА ДВИЖЕНИЕТО  В СЛУЧАИТЕ , ПРИ  КОИТО  Е МОНТИРАН  
АДАПТОР  
Изискванията  в тази и следващите  глави  посочват  как трябва  да се 
тълкуват  изискванията  от настоящото  приложение  в случаите , при 
които  се използва  адаптор . Съответните  номера  на изискванията  в 
приложение  IB са посочени  в скоби . 
ADA_005 Уредите  за регистриране  на данните  за движението  на 
всяко  превозно  средство , снабдено  с адаптор , трябва  да 
съответстват  на всички  разпоредби  от настоящото  прило­  
жение , освен  ако в настоящото  допълнение  е посочено  
друго . 
ADA_006 Когато  е монтиран  адаптор , уредите  за регистриране  на 
данните  за движението  включват  кабели , самия  адаптор  
(заедно  с датчик  за движение ) и бордово  устройство  [01].  
ADA_007 Функцията  за откриване  на събития  и/или на грешки  на 
уредите  за регистриране  на данни  за движението  се 
променя  както  следва : 
— събитието  „прекъсване  на захранването “ се поражда  от 
бордовото  устройство , ако то не е в режим  на калиб­  
риране , в случай  на прекъсване  на захранването  на 
вградения  датчик  за движение , продължаващо  по- 
дълго  от 200 милисекунди  [79],  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 540  
— събитието  „грешка  в данните  за движение “ се поражда  
от бордовото  устройство  в случай  на прекъсване  на 
нормалния  поток  от данни  между  вградения  датчик  за 
движение  и бордовото  устройство  и/или в случай  на 
грешка , свързана  с цялостността  на данните  или с удос­  
товеряването  им по време  на техния  обмен  между  
вградения  датчик  за движение  и бордовото  устройство  
[83] 
— събитието  „опит  за нарушаване  на сигурността “ се 
поражда  от бордовото  устройство  при всяко  друго  
събитие  от значение  за сигурността  на вградения  
датчик  за движение , когато  не е в режим  на калиб­  
риране  [85]  
— грешката  „уреди  за регистриране  на данните  за движе­  
нието “ се поражда  от бордовото  устройство , ако то не е 
в режим  на калибриране  при всяка  грешка  на вградения  
датчик  за движение  (88).  
ADA_008 Грешките  на адаптора , които  се откриват  от уредите  за 
регистриране  на данните  за движението , са тези грешки , 
които  са свързани  с вградения  датчик  на движение  [88].  
ADA_009 Калибриращата  функция  на бордовото  устройство  трябва  
да дава възможност  за автоматично  сдвояване  на вградения  
датчик  за движение  с бордовото  устройство  [202, 204].  
4. КОНСТРУКТИВНИ  И ФУНКЦИОНАЛНИ  ИЗИСКВАНИЯ  КЪМ  
АДАПТОРА  
4.1. Препредаване  и адаптиране  на входящите  импулси  за скорост  
ADA_011 Входният  интерфейс  на адаптора  трябва  да приема  
честотни  импулси  за скоростта  на превозното  средство  и 
изминатото  от него  разстояние . Електрическите  характе­  
ристики  на входящите  импулси : подлежат  на определяне  
от производителя . В случай  че е приложимо , за 
правилната  интерфейсна  връзка  между  входа  на адаптора  
и превозното  средство  се допускат  настройки , достъпни  
само  за производителя  на адаптора  и за завода /сервиза  
(workshop), извършващ  монтажа  на адаптора . 
ADA_012 Входният  интерфейс  на адаптора  трябва  да може , в случай  
че е приложимо , да умножава  или да дели  честотните  
импулси  на входящите  импулси  за скоростта  с постоянен  
коефициент , за да адаптира  сигнала  към интервала  от стой­  
ностите  на коефициента  k, определен  в настоящото  
приложение  (4 000 до 25 000 импулса /km). Този  
постоянен  коефициент  може  да бъде  програмиран  само  
от производителя  на адаптора  и от завода /сервиза , 
извършващ  монтажа  на адаптора . 
4.2. Индуктиране  на входящите  импулси  във вградения  датчик  за 
движение  
ADA_013 Входящите  импулси , които  е възможно  да са адаптирани , 
както  е посочено  по-горе, се индуктират  във вградения  
датчик  за движение , така че всеки  входящ  импулс  да се 
регистрира  от датчика  за движение . 
4.3. Вграден  датчик  за движение  
ADA_014 Вграденият  датчик  за движение  се стимулира  от индукти­  
раните  импулси , като по този начин  генерира  данни  за 
движението , представящи  точно  движението  на превозното  
средство , както  при механично  свързване  на датчика  с 
движеща  се част на превозното  средство . 
ADA_015 Идентификационните  данни  на вградения  датчик  за 
движение  се използват  от бордовото  устройство  за разпоз­  
наване  на адаптора  [95].  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 541  
ADA_016 Монтажните  данни , съхранявани  във вградения  датчик  за 
движение , се считат , че представляват  монтажните  данни  
на адаптора  [122].  
4.4. Изисквания  за сигурност  
ADA_017 Корпусът  на адаптора  трябва  да се проектира  така, че да не 
може  да се отваря . Той трябва  да е пломбиран , така че 
опитите  за отваряне  да бъдат  откривани  лесно  (напр . чрез 
визуална  инспекция , вж. ADA_035). Пломбите  трябва  да 
съответстват  на същите  изисквания  като изискванията  за 
пломбите  на датчика  за движение  [398 до 406].  
ADA_018 Не трябва  да е възможно  сваляне  на вградения  датчик  за 
движение  от адаптора  без да се счупи (ят) пломбата (ите) на 
корпуса  на адаптора , или без да се счупи  пломбата  между  
датчика  и корпуса  на адаптора  (вж. ADA_034).  
ADA_019 Адапторът  трябва  да гарантира , че данни  за движението  
могат  да се обработват  и получават  само  от постъпващите  
в адаптора  данни . 
4.5. Експлоатационни  характеристики  
ADA_020 Адапторът  трябва  да е напълно  работоспособен  в темпера­  
турния  обхват , дефиниран  от производителя . 
ADA_021 Адапторът  трябва  да е напълно  работоспособен  в 
интервала  за стойности  на влажността  от 10 % до 90 % 
[214].  
ADA_022 Адапторът  трябва  да е защитен  от пренапрежение , 
обръщане  на поляритета  на захранването  и къси  
съединения  [216].  
ADA_023 Адапторът  трябва  да е защитен  по един  от следните  два 
начина : 
— да реагира  на магнитно  поле , смущаващо  събирането  на 
данни  за движението  на превозното  средство . При 
такива  обстоятелства  бордовото  устройство  регистрира  
и записва  неизправност  в датчика  [88], или 
— да има чувствителен  елемент , който  е защитен  срещу  
магнитни  полета  или е устойчив  на такива  [217].  
ADA_024 Адапторът  трябва  да съответства  на международното  
правило  на ИКЕ  на ООН  UN ECE R10, отнасящо  се за 
електромагнитната  съвместимост , и трябва  да бъде  
защитен  срещу  електростатични  разряди  и преходни  
процеси  [218].  
4.6. Материали  
ADA_025 Адапторът  трябва  да отговаря  на степен  на защита  
(определя  се от производителя , в зависимост  от мястото  
на монтаж ) [220, 221].  
ADA_026 Корпусът  на адаптора  трябва  да е в жълт  цвят . 
4.7. Маркировки  
ADA_027 Върху  адаптора  трябва  да е закрепена  указателна  табелка , 
съдържаща  следните  данни : 
— наименование  и адрес  на производителя  на адаптора ; 
— фабричен  номер  от производителя , и година  на 
производство  на адаптора ; 
— знак за одобрение  на типа  на адаптора  или типа  на 
уредите  за регистриране  на данните  за движението , 
включващи  адаптора ; 
— датата , на която  е монтиран  адапторът ; ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 542  
— идентификационния  номер  на превозното  средство , на 
което  е монтиран . 
ADA_028 Указателната  табелка  трябва  да съдържа  също  и следната  
информация  (ако не може  да се прочете  отвън  върху  
вградения  датчик  за движение ): 
— наименование  на производителя  на вградения  датчик  за 
движение ; 
— фабричен  номер  от производителя , и година  на 
производство  на вградения  датчик  за движение ; 
— знак за одобрение  на вградения  датчик  за движение . 
5. МОНТАЖ  НА УРЕДИТЕ  ЗА РЕГИСТРИРАНЕ  НА ДАННИТЕ  ЗА 
ДВИЖЕНИЕТО  В СЛУЧАИТЕ , ПРИ  КОИТО  СЕ ИЗПОЛЗВА  
АДАПТОР  
5.1. Монтаж  
ADA_029 Адапторите  се монтират  в превозни  средства  само  от 
производители  на превозни  средства  или от одобрени  заво­  
ди/сервизи , оторизирани  да монтират , задействат  и 
калибрират  цифрови  и интелигентни  тахографи . 
ADA_030 Одобреният  завод /сервиз , който  монтира  адаптора , трябва  
да настрои  входния  интерфейс  и да избере  отношението  на 
делене  на входния  сигнал  (в случаите , в които  това е 
приложимо ). 
ADA_031 Одобреният  завод /сервиз , който  монтира  адаптора , трябва  
да пломбира  корпуса  на адаптора . 
ADA_032 Адапторът  трябва  да е монтиран  възможно  най-близо  до 
тази част на превозното  средство , от която  идват  
входящите  в него  импулси . 
ADA_033 Кабелите  за захранване  на адаптора  трябва  да са червен  
(положителен  полюс ) и черен  (маса ). 
5.2. Пломбиране  
ADA_034 Прилагат  се следните  изисквания  за пломбиране : 
— корпусът  на адаптора  трябва  да е пломбиран  (вж. 
ADA_017),  
— корпусът  на вградения  датчик  трябва  да е пломбиран  за 
корпуса  на адаптора , освен  ако изваждането  на 
вградения  датчик  от корпуса  на адаптора  е невъзможно  
без да се счупи (ят) пломбата (ите) на корпуса  на 
адаптора  (вж. ADA_018),  
— корпусът  на адаптора  трябва  да е пломбиран  за 
превозното  средство , 
— връзката  между  адаптора  и оборудването , което  подава  
входящите  в него  импулси , трябва  да е пломбирана  в 
двата  края  (доколкото  това е разумно  осъществимо ). 
6. ПРОВЕРКИ , ТЕХНИЧЕСКИ  ПРЕГЛЕДИ  И ПОПРАВКИ  
6.1. Периодични  технически  прегледи  
ADA_035 Когато  се използва  адаптор , всеки  периодичен  технически  
преглед  (периодичният  технически  преглед  означава  
инспекция  в съответствие  с изискванията  с номера  от 
[409] до [413] от приложение  1В) на уредите  за регис­  
триране  на данните  за движението  трябва  да включва  
следните  проверки : 
— че върху  адаптора  е поставен  съответният  знак за 
одобрение  на типа , 
— че пломбите  на адаптора  и връзките  му са невредими , ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 543  
— че адапторът  е монтиран , както  е показано  на 
монтажната  табелка , 
— че адапторът  е монтиран , както  е посочено  от произво­  
дителя  на адаптора  и/или на превозното  средство , 
— че монтирането  на адаптор  е разрешено  за преглеж­  
даното  превозно  средство . 
ADA_036 Тези  технически  прегледи  трябва  да включват  калибриране  
и замяна  на всички  пломби , каквото  и да е тяхното  
състояние . 
7. ОДОБРЕНИЕ  НА ТИПА  НА УРЕДИТЕ  ЗА РЕГИСТРИРАНЕ  НА 
ДАННИТЕ  ЗА ДВИЖЕНИЕТО  В СЛУЧАИТЕ , ПРИ  КОИТО  СЕ 
ИЗПОЛЗВА  АДАПТОР  
7.1. Общи  положения  
ADA_037 Уредите  за регистриране  на данните  за движението  се 
представят  за одобрение  на типа , окомплектовани  с 
адаптор  [425].  
ADA_038 Даден  адаптор  може  да бъде  представен  за одобрение  на 
собствения  му тип, или за одобрение  на типа  като елемент  
от уредите  за регистриране  на данните  за движението . 
ADA_039 Такова  одобрение  на типа  трябва  да включва  
функционални  изпитвания  с участието  на адаптора . Поло­  
жителните  резултати  при всяко  от тези изпитвания  се удос­  
товеряват  чрез съответен  сертификат  [426].  
7.2. Функционален  сертификат  
ADA_040 Функционален  сертификат  на адаптор  или на уреди  за 
регистриране  на данните  за движението , включващи  
адаптор , се издава  на производителя  на адаптора  само  
след  като са били  преминати  успешно  следните  
функционални  изпитвания . 
№ Изпитване  Описание  Съответни  изисквания  
1. Административен  преглед  
1.1 Документация  Коректност  на 
документацията  на 
адаптора  
2. Визуално  инспектиране  
2.1 Съответствие  на адаптора  с документацията  
2.2 Идентификация /маркировка  на адаптора  ADA_027, 
ADA_028  
2.3 Материали , от които  е направен  адапторът  [219] до [223] 
ADA_026  
2.4 Пломбиране  ADA_017, 
ADA_018, 
ADA_034  
3. Функционални  изпитвания  
3.1 Индуктиране  на импулсите  за скорост  във 
вградения  датчик  за движение  ADA_013  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 544  
№ Изпитване  Описание  Съответни  изисквания  
3.2 Препредаване  и адаптиране  на входящите  
импулси  за скорост  ADA_011, 
ADA_012  
3.3 Точност  на измерване  на движението  [30] до [35], [217]  
4. Изпитания  за въздействията  на околната  среда  
4.1 Резултати  от изпитване , 
проведено  от произво­  
дителя  Резултати  от 
изпитванията  на 
производителя  за 
въздействието  на 
околната  среда  ADA_020, 
ADA_021, 
ADA_022, 
ADA_024  
5. Изпитание  за електромагнитна  съвместимост  
5.1 Излъчени  емисии  и 
чувствителност  към тях Проверява  се съот­  
ветствието  с 
Директива  2006/ 
28/ЕО ADA_024  
5.2 Резултати  от изпитване , 
проведено  от произво­  
дителя  Резултати  от 
изпитванията  на 
производителя  за 
въздействието  на 
околната  среда  ADA_024  ▼B
 02016R0799 — BG — 26.02.2020 — 002.001 — 545  
ПРИЛОЖЕНИЕ  II 
МАРКИРОВКА  ЗА ОДОБРЕНИЕ  И СЕРТИФИКАТ  ЗА ОДОБРЕНИЕ  
I. МАРКИРОВКА  ЗА ОДОБРЕНИЕ  
1. Маркировката  за одобрение  се състои  от: 
а) правоъгълник , в който  е разположена  буквата  „е“, следвана  от 
отличителен  номер  или буква  на държавата , която  е издала  одобре­  
нието , в съответствие  със следните  общоприети  знаци : 
Белгия  6,  
България  34,  
Чешка  република  8,  
Дания  18,  
Германия  1,  
Естония  29,  
Ирландия  24,  
Гърция  23,  
Испания  9,  
Франция  2,  
Хърватия  25,  
Италия  3,  
Кипър  CY,  
Латвия  32,  
Литва  36,  
Люксембург  13,  
Унгария  7,  
Малта  MT,  
Нидерландия  4,  
Австрия  12,  
Полша  20,  
Португалия  21,  
Румъния  19,  
Словения  26,  
Словакия  27,  
Финландия  17,  
Швеция  5,  
Обединено  кралство  11,  
както  и 
▼M1 
б) номер  на одобрението , съответстващ  на номера  на сертификата  за 
одобрение , изготвен  за прототипа  на уреда  за регистриране  на 
данните  за движението , тахографския  лист  или тахографската  карта , 
който  се поставя  в непосредствена  близост  до посочения  правоъ­  
гълник . ▼C1
 02016R0799 — BG — 26.02.2020 — 002.001 — 546  
2. Маркировката  за одобрение  се поставя  върху  указателната  табелка  на 
всеки  комплект  уреди  и на всеки  тахографски  лист  и върху  всяка  тахог­  
рафска  карта . Маркировката  трябва  да бъде  незаличима  и винаги  да бъде  
ясно  четлива . 
3. Посочените  по-долу  размери  на маркировката  за одобрение  ( 1 ) са 
изразени  в милиметри , като това са минимални  стойности . Съот­  
ношението  между  размерите  трябва  да бъде  запазено .
 ▼C1 
( 1 ) Показаните  цифри  служат  само  за насока .
 02016R0799 — BG — 26.02.2020 — 002.001 — 547  
II. СЕРТИФИКАТ  ЗА ОДОБРЕНИЕ  ЗА АНАЛОГОВИ  ТАХОГРАФИ  
Държавата  членка , предоставила  одобрение , издава  на заявителя  сертификат  
за одобрение  съгласно  образеца  по-долу . Когато  уведомява  други  държави  
членки  за издадени  одобрения  или съответно  за отменянето  им, държавата  
членка  използва  копия  на въпросния  сертификат . 
СЕРТИФИКАТ  ЗА ОДОБРЕНИЕ  
Наименование  на компетентния  орган  
Уведомление  относно  ( 1 ): 
— одобрение  на типа  на уред  за регистриране  на данните  за движението  
— отменяне  на одобрението  на типа  на уред  за регистриране  на данните  за 
движението  
— одобрение  на образец  за тахографски  лист  
— отменяне  на одобрението  на образец  за тахографски  лист  
Одобрение  №: 
...................................  
1. Търговска  марка  или наименование  
2. Наименование  на типа  или модела  
3. Наименование  на производителя  
4. Адрес  на производителя  
5. Представено  за одобрение  на 
6. Изпитано  в 
7. Дата  и номер  на изпитването /изпитванията  
8. Дата  на одобрението  
9. Дата  на отменяне  на одобрението  
10. Тип или типове  уреди  за регистриране  на данните  за движението , с 
които  листът  е предназначен  да бъде  използван  
11. Място  
12. Дата  
13. Приложени  пояснителни  документи  
14. Забележки  (включително  разположение  на пломбите , ако е приложимо ) 
(Подпис ) ▼C1 
( 1 ) Ненужното  се зачертава .
 02016R0799 — BG — 26.02.2020 — 002.001 — 548  
III. СЕРТИФИКАТ  ЗА ОДОБРЕНИЕ  ЗА ЦИФРОВИ  ТАХОГРАФИ  
Държавата  членка , предоставила  одобрение , издава  на заявителя  сертификат  
за одобрение  съгласно  образеца  по-долу . Когато  уведомява  други  държави  
членки  за издадени  одобрения  или съответно  за отменянето  им, държавата  
членка  използва  копия  на въпросния  сертификат . 
СЕРТИФИКАТ  ЗА ОДОБРЕНИЕ  ЗА ЦИФРОВИ  ТАХОГРАФИ  
Наименование  на компетентния  орган  
Уведомление  относно  ( 1 ): 
□ одобрение  на: □ отменяне  на одобрението  на: 
□ модел  уред  за регистриране  на данните  за 
движението  
□ компонент  на уред  за регистриране  на данните  за 
движението  ( 2 ) 
□ карта  на водач 
□ карта  за монтаж  и настройки  
□ карта  на превозвач  
□ контролна  карта  
Одобрение  №: 
1. Производствена  марка  или търговска  марка  
2. Наименование  на модела  
3. Наименование  на производителя  
4. Адрес  на производителя  
▼M1 
5. Представено  за одобряване  на 
▼C1 
6. Лаборатория (ии) 
7. Дата  и номер  на протокол  от изпитване  
8. Дата  на одобрението  
9. Дата  на отменяне  на одобрението  
10. Модел  на уред (и) за регистриране  на данните  за движението , с 
който /които  е предназначен  да се използва  компонентът  
11. Място  
12. Дата  
13. Приложени  пояснителни  документи  
14. Забележки  (включително  разположение  на пломбите , ако е приложимо ) 
(Подпис ) ▼C1 
( 1 ) Отбележете  съответните  полета . 
( 2 ) Посочете  компонента , предмет  на уведомлението .
 02016R0799 — BG — 26.02.2020 — 002.001 — 549  
IV. СЕРТИФИКАТ  ЗА ОДОБРЕНИЕ  ЗА ИНТЕЛИГЕНТНИ  ТАХОГРАФИ  
Държавата  членка , предоставила  одобрение , издава  на заявителя  сертификат  
за одобрение  съгласно  образеца  по-долу . Когато  уведомява  други  държави  
членки  за издадени  одобрения  или съответно  за отменянето  им, държавата  
членка  използва  копия  на въпросния  сертификат . 
СЕРТИФИКАТ  ЗА ОДОБРЕНИЕ  ЗА ИНТЕЛИГЕНТНИ  ТАХОГРАФИ  
Наименование  на компетентния  орган  
Уведомление  относно  ( 1 ): 
□ одобрение  на: □ отменяне  на одобрението  на: 
□ модел  уред  за регистриране  на данните  за 
движението  
□ компонент  на уред  за регистриране  на данните  за 
движението  ( 2 ) 
□ карта  на водач 
□ карта  за монтаж  и настройки  
□ карта  на превозвач  
□ контролна  карта  
Одобрение  №: 
1. Производствена  марка  или търговска  марка  
2. Наименование  на модела  
3. Наименование  на производителя  
4. Адрес  на производителя  
▼M1 
5. Представено  за одобряване  на 
▼C1 
6. а) изпитвателна  лаборатория  за сертифициране  за функциониране  
б) изпитвателна  лаборатория  за сертифициране  за сигурност  
в) изпитвателна  лаборатория  за сертифициране  за оперативна  съвмес­  
тимост  
7. а) дата и номер  на сертификат  за функциониране  
б) дата и номер  на сертификат  за сигурност  
в) дата и номер  на сертификат  за оперативна  съвместимост  
8. Дата  на одобрението  
9. Дата  на отменяне  на одобрението  
10. Модел  на уред (и) за регистриране  на данните  за движението , с 
който /които  е предназначен  да се използва  компонентът  
11. Място  
12. Дата  
13. Приложени  пояснителни  документи  
14. Забележки  (включително  разположение  на пломбите , ако е приложимо ) 
(Подпис ) ▼C1 
( 1 ) Отбележете  съответните  полета . 
( 2 ) Посочете  компонента , предмет  на уведомлението .