Този  текст  служи  само  за информационни  цели  и няма  правно  действие . Институциите  на Съюза  не носят  
отговорност  за неговото  съдържание . Автентичните  версии  на съответните  актове , включително  техните  преамбюли , 
са версиите , публикувани  в Официален  вестник  на Европейския  съюз  и налични  в 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  2 0  6.2.2020 г.  
►M3 Регламент за изпълнение (ЕС) 2021/1228 на Комисията от 16 юли 
2021 година  L 273  1  30.7.2021 г.  
Поправен със:  
►C1 Поправка, ОВ L 146, 3.6.2016 г., стр. 31 (2016/799)  
►C2 Поправка, ОВ L 27, 1.2.2017 г., стр. 169 (2016/799)  02016R0799 — BG — 21.08.2023 — 003.001 — 1
02016R0799 — BG — 21.08.2023 — 003.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 — 21.08.2023 — 003.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 — 21.08.2023 — 003.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 — 21.08.2023 — 003.001 — 5  
4. Производителят или неговият представител предоставя на 
органите по одобряването на типа, както и на организациите, отг о­ 
варящи за издаването на сертификатите, посочени в член 12, 
параграф 3 от Регламент (ЕС) № 165/2014, толкова на брой 
тахографи или компоненти на тахографи, колкото са необходими, 
за да може процедурата за одобряване на типа да се извърши по 
задоволителен начин.  
5. Когато производителят или неговият представител има за цел 
одобряване на типа на определени компоненти или групи от 
компоненти на тахограф, той предоставя на органите по одобря­ 
ването на типа другите компоненти, чийто тип е вече одобрен, 
както и други части, необходими за конструкцията на окомплек­ 
тувания тахограф, за да могат въпросните органи да проведат нео б­ 
ходимите изпитвания.  
Член  5 
Изменения  на одобрения  на типа  
1. Производителят или неговият представител информира 
незабавно органите по одобряването на типа, издали първона­ 
чалното одобрение на типа, за всяка промяна в програмното осигу ­ 
ряване (софтуера) или апаратната част (хардуера) на тахографа и ли 
в естеството на материалите, използвани за производството му, 
които са записани в информационния пакет, и подава заявление 
за изменение на одобрението на типа.  
2. Органите по одобряването на типа могат да преразгледат или 
разширят съществуващо одобрение на типа, или да издадат ново 
одобрение на типа в зависимост от естеството и характеристиките  
на измененията.  
„Преразглеждане“ се прави, когато органът по одобряването на 
типа счете, че промените в програмното осигуряване или в 
апаратната част на тахографа или в естеството на материалите, 
използвани за производството му, са незначителни. В такива 
случаи органът по одобряването на типа издава преразгледани 
документи от информационния пакет, като посочва естеството на 
направените изменения и датата на одобряването им. За спазванет о 
на това изискване се счита за достатъчна актуализирана версия н а 
информационния пакет в консолидиран вид, придружена от 
подробно описание на направените изменения.  
„Разширение“ се прави, когато органът по одобряването на типа 
счете, че промените в програмното осигуряване или в апаратната 
част на тахографа или в естеството на материалите, използвани з а 
производството му, са значителни. В такива случаи той може да 
изиска да бъдат извършени нови изпитвания и да информира за 
това производителя или представителя му. Ако изпитванията са 
задоволителни, органът по одобряването на типа издава прераз­ 
гледан сертификат за одобрение на типа, съдържащ номер, съот­ 
ветстващ на издаденото разширение. В сертификата за одобрение 
на типа се посочват причината за разширението и датата на изда­  
ването му.  
3. В указателя към информационния пакет се посочва датата на 
най-новото разширение или преразглеждане на одобрението на 
типа или датата на най-новото консолидиране на актуализираната 
версия на одобрението на типа.  
4. Когато заявените изменения на тахограф от одобрен тип или 
на неговите компоненти биха довели до издаване на нов 
сертификат за сигурност или за оперативна съвместимост, е необ­  
ходимо ново одобрение на типа.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 6  
Член  6 
Влизане  в сила  
Настоящият регламент влиза в сила на двадесетия ден след деня н а 
публикуването му в  Официален  вестник  на Европейския  съюз . 
Той се прилага от 2 март 2016 г.  
▼M1 
Приложение IВ обаче се прилага от 15 юни 2019 г., с изключение 
на допълнение 16, което се прилага от 2 март 2016 г.  
▼B 
Настоящият регламент е задължителен в своята цялост и се прилаг а 
пряко във всички държави членки.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.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 Въвеждане на специфични условия  
▼M3 
3.6.4 Въвеждане на товаро-разтоварна операция  
▼B 
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 — 21.08.2023 — 003.001 — 8  
3.9.11 Събитие „Грешка в комуникацията с външното устройство за  
GNSS“  
3.9.12 Събитие „Грешка в данните за движението“  
3.9.13 Събитие „Противоречие в данните за движението на 
превозното средство“  
3.9.14 Събитие „Опит за нарушаване на сигурността“  
3.9.15 Събитие „времеви конфликт“  
3.9.16 Неизправност „Карта“  
3.9.17 Неизправност „Уред за регистриране на данните за 
движението“  
▼M3 
3.9.18 Събитие „Аномалия в GNSS“  
▼B 
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 Данни за тахографските карти  
▼M3 
3.12.17 Пресичане на граници  
3.12.18 Товаро-разтоварни операции  
3.12.19 Цифрова карта  
▼B 
3.13 Четене на тахографските карти  
3.14 Регистриране и запис върху тахографски карти  
3.14.1 Регистриране и запис в тахографски карти от първо поколе ние ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 9  
3.14.2 Регистриране и запис в тахографски карти от второ поколе ние 
3.15 Извеждане върху дисплея  
3.15.1 Изобразяване по подразбиране  
3.15.2 Изобразяване на предупреждение  
3.15.3 Меню за достъп  
3.15.4 Изобразяване на други данни  
3.16 Отпечатване  
3.17 Предупреждения  
3.18 Изтегляне на данни към външни носители  
3.19 Връзка от разстояние за извършване на целенасочени пътни 
проверки  
▼M3 
3.20 Обмен на данни с допълнителни външни устройства  
▼B 
3.21 Калибриране  
3.22 Пътна проверка на калибрирането  
3.23 Сверяване на часовника  
3.24 Експлоатационни характеристики  
3.25 Материали  
3.26 Маркировки  
▼M3 
3.27 Следене на пресичането на граници  
3.28 Актуализация на софтуера  
▼B 
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 Идентификация на титуляря на картата  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 10  
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 Данни за дейностите на водача  
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 Идентификация на приложенията  
▼M3 
4.5.3.2.1.1 Допълнителна идентификация на приложението (не е до стъпно 
за версия 1 на бордови устройства от второ поколение)  
▼B 
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 Данни за местата за три часа общо управление на МПС  
▼M3 
4.5.3.2.17 Статус на удостоверяването на местоположението, свър зано с 
местата, в които е началото и/или краят на дневните периоди 
на работа (не е достъпно за версия 1 на бордовите устройства 
от второ поколение)  
4.5.3.2.18 Статус на удостоверяването на местоположенията, в ко ито е 
достигнато три часа общо време на управление (не е достъпно 
за версия 1 на бордовите устройства от второ поколение)  
4.5.3.2.19 Пресичане на граници (не е достъпно за версия 1 на б ордови 
устройства от второ поколение)  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 11  
4.5.3.2.20 Товаро-разтоварни операции (не е достъпно за версия 1 на 
бордови устройства от второ поколение)  
4.5.3.2.21 Вписвания за типа товарене (не е достъпно за версия 1 на 
бордови устройства от второ поколение)  
4.5.3.2.22 Конфигурации на БУ (не е достъпно за версия 1 на бор дови 
устройства от второ поколение)  
▼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 Данни за контролните дейности  
4.5.4.1.13 Данни за специфични условия  
4.5.4.2 Тахографско приложение от поколение 2 (не е достъпно за  
бордово устройство от първо поколение)  
4.5.4.2.1 Идентификация на приложенията  
▼M3 
4.5.4.2.1.1 Допълнителна идентификация на приложението (не е до стъпно 
за версия 1 на бордови устройства от второ поколение)  
▼B 
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 Данни за картовата сесия  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 12  
4.5.4.2.12 Данни за контролните дейности  
4.5.4.2.13 Данни за използваните бордови устройства  
▼M1 
4.5.4.2.14 Данни за местата за три часа общо управление на МПС  
▼B 
4.5.4.2.15 Данни за специфични условия  
▼M3 
4.5.4.2.16 Статус на удостоверяването на местоположението, свър зано с 
местата, в които е началото и/или краят на дневните периоди 
на работа (не е достъпно за версия 1 на бордовите устройства 
от второ поколение)  
4.5.4.2.17 Статус на удостоверяването на местоположенията, в ко ито е 
достигнато три часа общо време на управление (не е достъпно 
за версия 1 на бордовите устройства от второ поколение)  
4.5.4.2.18 Пресичане на граници (не е достъпно за версия 1 на б ордови 
устройства от второ поколение)  
4.5.4.2.19 Товаро-разтоварни операции (не е достъпно за версия 1 на 
бордови устройства от второ поколение)  
4.5.4.2.20 Вписвания за типа товарене (не е достъпно за версия 1 на 
бордови устройства от второ поколение)  
4.5.4.2.21 Допълнителни данни за калибрирането (не е достъпно з а 
версия 1 на бордови устройства от второ поколение)  
4.5.4.2.22 Конфигурации на БУ (не е достъпно за версия 1 на бор дови 
устройства от второ поколение)  
▼B 
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 Идентификация на приложенията  
▼M3 
4.5.5.2.1.1 Допълнителна идентификация на приложението (не е до стъпно 
за версия 1 на бордови устройства от второ поколение)  
▼B 
4.5.5.2.2 Ключове и сертификати  
4.5.5.2.3 Идентификация на картата  
4.5.5.2.4 Идентифициране на титуляря на картата  
4.5.5.2.5 Данни за контролните дейности  
▼M3 
4.5.5.2.6 Конфигурации на БУ (не е достъпно за версия 1 на борд ови 
устройства от второ поколение)  
▼B 
4.5.6 Карта на превозвач  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 13  
4.5.6.1 Тахографско приложение (достъпно за бордови устройства от 
първо и второ поколение)  
4.5.6.1.1 Идентифициране на приложенията  
4.5.6.1.2 Ключове и сертификати  
4.5.6.1.3 Идентифициране на картата  
4.5.6.1.4 Идентифициране на титуляря на картата  
4.5.6.1.5 Данни относно дейността на предприятието  
4.5.6.2 Тахографско приложение от поколение 2 (не е достъпно за  
бордово устройство от първо поколение)  
4.5.6.2.1 Идентифициране на приложенията  
▼M3 
4.5.6.2.1.1 Допълнителна идентификация на приложението (не е до стъпно 
за версия 1 на бордови устройства от второ поколение)  
▼B 
4.5.6.2.2 Ключове и сертификати  
4.5.6.2.3 Идентифициране на картата  
4.5.6.2.4 Идентифициране на титуляря на картата  
4.5.6.2.5 Данни за дейността на предприятието  
▼M3 
4.5.6.2.6 Конфигурации на БУ (не е достъпно за версия 1 на борд ови 
устройства от второ поколение)  
▼B 
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-ро поколение  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 14  
ВЪВЕДЕНИЕ  
Настоящото приложение съдържа изискванията за уредите за регист риране 
на данните за движението и за тахографските карти от второ поко ление.  
От 15 юни 2019 г. в превозните средства, регистрирани за първи път в 
Съюза, се монтират уреди за регистриране на данните за движение то от 
второ поколение и се издават тахографски карти от второ поколен ие. 
С цел гладкото въвеждане на тахографската система от второ поко ление, 
тахографските карти от второ поколение са проектирани така, че да се 
използват и в бордови устройства от първо поколение, произведен и в съот­ 
ветствие с приложение IБ към Регламент (ЕИО) № 3821/85.  
Съответно, в бордовите устройства от второ поколение могат да с е 
използват тахографски карти от първо поколение. Въпреки това, 
бордовите устройства от второ поколение могат да бъдат калибрир ани 
само с карти за монтаж и настройки второ поколение.  
Изискванията по отношение на оперативната съвместимост между та хог­ 
рафските системи от първо и второ поколение са определени в нас тоящото 
приложение. В тази връзка в допълнение 15 се съдържат допълните лни 
подробности за управлението на съвместното съществуване на двет е 
поколения.  
Освен това, поради въвеждането на нови функции, като например и зпол­ 
зването на удостоверяването на автентичността на навигационните  
съобщения с отворен сигнал на „Галилео“, откриването на пресича нето на 
граници, въвеждането на товаро-разтоварни операции, както и пор ади необ­ 
ходимостта от увеличаване на капацитета на картите на водач на 56 дни от 
дейността на водача, с настоящия регламент се въвеждат техничес ките 
изисквания за втората версия на уредите за регистриране на данн ите за 
движението и тахографските карти от второ поколение.  
▼B 
Списък на допълненията  
Доп 1: РЕЧНИК НА ДАННИТЕ  
Доп 2: СПЕЦИФИКАЦИЯ НА ТАХОГРАФСКИТЕ КАРТИ  
Доп 3: ПИКТОГРАМИ  
Доп 4: РАЗПЕЧАТКИ  
Доп 5: ПОКАЗВАНЕ  
Доп 6: ПРЕДЕН СЪЕДИНИТЕЛ ЗА КАЛИБРИРАНЕ И ИЗТЕГЛЯНЕ 
НА ДАННИ  
Доп 7: ПРОТОКОЛИ ЗА ИЗТЕГЛЯНЕ НА ДАННИ  
Доп 8: ПРОТОКОЛ ЗА КАЛИБРИРАНЕ  
Доп 9: МИНИМАЛНО ИЗИСКВАНИ ИЗПИТВАНИЯ ЗА ОДОБРЕНИЕ 
НА ТИПА  
Доп 10: ИЗИСКВАНИЯ ЗА СИГУРНОСТ  
Доп 11: ОБЩИ МЕХАНИЗМИ ЗА СИГУРНОСТ  
Доп 12: ОПРЕДЕЛЯНЕ НА МЕСТОПОЛОЖЕНИЕТО ВЪЗ ОСНОВА 
НА ГЛОБАЛНА НАВИГАЦИОННА СПЪТНИКОВА 
СИСТЕМА (GNSS)  
Доп 13: ИНТЕРФЕЙС С ITS  
Доп 14: ФУНКЦИЯ ЗА ВРЪЗКА ОТ РАЗСТОЯНИЕ  
Доп 15:  МИГРАЦИЯ: УПРАВЛЕНИЕ НА ЕДНОВРЕМЕННОТО СЪЩЕСТ­ 
ВУВАНЕ НА РАЗЛИЧНИ ПОКОЛЕНИЯ ОБОРУДВАНЕ  
Доп 16:  АДАПТОР ЗА ПРЕВОЗНИ СРЕДСТВА ОТ КАТЕГОРИИ M1 И N1  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 15  
1 ОПРЕДЕЛЕНИЯ  
В настоящото приложение:  
а) „активиране“ означава:  
фазата, по време на която тахографът става напълно рабо­ 
тоспособен и може да извършва всички функции, вклю­ 
чително и свързаните със сигурността, чрез използването 
на карта за монтаж и настройки;  
б) „удостоверяване на самоличността“:  
функция, предназначена да установи и провери определена 
самоличност;  
в) „автентичност“ означава:  
характеристиката определена информация да произлиза от 
страна, чиято самоличност може да бъде проверена;  
г) „вградена функция за изпробване“:  
изпробвания, които могат да се пускат по заявка, задей­ 
ствани от оператора или от външна апаратура;  
д) „календарен ден“ означава:  
ден, който обхваща времето от 00.00 часа до 24.00 часа. 
Всички календарни дни са свързани с координираната 
универсална скала за време (UTC);  
▼M3 
f) „калибриране на интелигентен тахограф“ означава:  
обновяване или потвърждаване на записаните в паметта 
данни за параметрите на превозното средство. Пара­ 
метрите на превозното средство включват идентифи­ 
кацията на превозното средство (идентификационен 
номер на превозното средство (VIN), регистрационен 
номер на превозното средство (VRN) и държава членка, 
извършила регистрацията) и характеристиките на 
превозното средство (w, k, l, размер на гумите, настройка 
на ограничителя на скоростта (ако се прилага), текущо 
координирано универсално време (UTC), текущо 
показание на километражния брояч, типа на товара по 
подразбиране); по време на калибрирането на уреди за 
регистриране на данните за движението, типовете и иден­ 
тификаторите на всички пломби, свързани с одобрението 
на типа, също трябва да се записват в паметта за данни;  
всяко актуализиране или потвърждаване само на коорди­ 
нираното универсално време се счита за сверяване на 
часовника, а не за калибриране, при условие че това не 
противоречи на изискване 409, определено в точка 6.4.  
калибрирането на уреди за регистриране на данните за 
движението изисква използването на карта за монтаж и 
настройки;  
ж) „номер на картата“ означава:  
16-позиционен буквено-цифров код, който представлява 
уникалният идентификационен номер на тахографска 
карта в определена държава членка. Номерът на картата 
включва идентификация, която се състои от идентификация 
на водача или от идентификация на собственика на картата 
заедно с индекс за поредния номер на картата, индекс за 
замяна на картата и индекс за подновяване на картата;  
по този начин всяка карта се идентифицира от кода на 
държавата членка, която я е издала, и от картовия номер  
▼B 
з) „индекс за пореден номер на картата“ означава:  
14-ят буквено-цифров символ от номера на картата, 
използван за различаване на картите, издадени на даден 
превозвач, сервиз или контролен орган, имащи право да 
използват няколко тахографски карти. Превозвачът, 
сервизът или контролният орган се идентифицират едно­ 
значно чрез първите 13 символа на картовия номер;  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 16  
и) „индекс за подновяване на валидността на картата“ означава:  
шестнадесетият буквено-цифров знак от номера на картата, 
който се увеличава всеки път с една стъпка, когато тахог­ 
рафска карта, съответстваща на дадена идентификация, т.е. 
идентификацията на водача или идентификацията на собст­ 
веника, заедно с индекса за поредния номер, бъде подновена;  
й) „индекс за замяна на картата“ означава:  
петнадесетият буквено-цифров знак от номера на картата, 
който се увеличава всеки път с една стъпка, когато тахог­ 
рафска карта, съответстваща на дадена идентификация, т.е. 
идентификацията на водача или идентификацията на собст­ 
веника, заедно с индекса за поредния номер, бъде заменена;  
▼B 
к) „характеристичен коефициент на превозното средство“ 
означава:  
цифровата характеристика, която посочва стойността на 
изходния сигнал, излъчен от тази част на превозното 
средство, която го свързва с уредите за регистриране на 
данните за движението (изходящ вал на скоростната кутия 
или ос), докато превозното средство изминава разстояние от 
един километър при стандартни условия на изпитване, както 
е определено в изискване 414. Характеристичният коефициент 
се изразява в импулси на километър (w: … имп./km);  
л) „карта на превозвач“ означава:  
тахографска карта, която се издава от органите на държава 
членка на транспортно предприятие, което трябва да 
експлоатира превозни средства, оборудвани с тахограф, и 
която идентифицира транспортното предприятие и служи 
за показване, изтегляне и разпечатване на данните, 
съхранени в паметта на тахографа, достъпът до които е 
бил ограничен от съответното транспортно предприятие;  
м) „константа на уредите за регистриране на данните за 
движението“ означава:  
цифровата характеристика, която дава стойността на 
входния сигнал, необходим за показване и записване на 
изминато разстояние един километър; тази константа се 
изразява в импулси на километър (k = … имп./km);  
н) „време за непрекъснато управление на МПС“ се изчислява от 
уредите за регистриране на данните за движението като (  1 ): 
времето на непрекъснато управление на МПС се изчислява 
като натрупаните времена на управление на МПС от даден 
водач от края на последния му период НА РАЗПО­ 
ЛОЖЕНИЕ, на ПРЕКЪСВАНЕ/ПОЧИВКА или на НЕИЗ­ 
ВЕСТНА ДЕЙНОСТ (  2 ) от 45 или повече минути (този 
период може да е разделен в съответствие с Регламент 
(ЕО) № 561/2006 на Европейския парламент и на 
Съвета (  3 )). При изчисленията се държи сметка, ако е необ­ 
ходимо, за предишните дейности, записани на картата на 
водач. Когато водачът не е вкарвал картата си, изчис­ 
ленията се основават на данните, записани в паметта по 
време на текущия период, през който не е била вкарвана 
никаква карта, като се отнасят към съответното четящо 
устройство;  ▼M3 
( 1 ) Този начин на изчисляване на времето на непрекъснато управлен ие на МПС и на 
общото време на прекъсване служи в уредите за регистриране на д анните за 
движението за изчисляване на предупреждението за времето на неп рекъснато 
управление на МПС. Той не предопределя юридическото тълкуване н а тези 
периоди. Може да бъдат използвани алтернативни начини за изчисл яване на 
времето на непрекъснато управление на МПС и на общото време на прекъсване 
в замяна на тези определения, ако те са остарели вследствие на актуализиране на 
останалото законодателство в дадената област. 
( 2 ) Периодите на НЕИЗВЕСТНА ДЕЙНОСТ съответстват на периодите, пр ез които 
картата на водача не е била вкарвана в уред за регистриране на данните за 
движението и за които няма извършено ръчно въвеждане на дейност ите на водача. 
( 3 ) Регламент (ЕО) № 561/2006 на Европейския парламент и на Съвет а от 15 март 
2006 година за хармонизиране на някои разпоредби от социалното законода­ 
телство, свързани с автомобилния транспорт, за изменение на Рег ламенти (ЕИО) 
№ 3821/85 и (ЕО) № 2135/98 на Съвета и за отмяна на Регламент ( ЕИО) № 3820/85 
на Съвета (ОВ L 102, 11.4.2006 г., стр. 1).
 02016R0799 — BG — 21.08.2023 — 003.001 — 17  
о) „контролна карта“ означава:  
тахографска карта, издадена от органите на държава 
членка на национален компетентен контролен орган, 
която идентифицира контролния орган и евентуално — 
конкретния негов служител, и която осигурява достъп до 
данните, съхранени в паметта на тахографа или в картата 
на водач, и евентуално — в картите за монтаж и 
настройки, с цел тяхното прочитане, разпечатване и/или 
изтегляне.  
Тя следва също така да дава достъп до функцията за пътна 
проверка на калибрирането и до данните на четеца за 
връзка с цел ранно откриване от разстояние.  
п) „общото време на прекъсване“ се изчислява в уредите за 
регистриране на данните за движението като (  1 ): 
общото време на прекъсване в управлението е сумата от 
периодите НА РАЗПОЛОЖЕНИЕ, на ПРЕКЪСВАНЕ/ 
ПОЧИВКА или на НЕИЗВЕСТНА ДЕЙНОСТ (  2 ) от 15 
или повече минути на даден водач от края на последния 
му период НА РАЗПОЛОЖЕНИЕ, на ПРЕКЪСВАНЕ/ 
ПОЧИВКА или на НЕИЗВЕСТНА ДЕЙНОСТ (  2 ) от 45 
или повече минути (този период може да бъде разделен 
в съответствие с Регламент (ЕО) № 561/2006).  
При изчисленията се държи сметка, ако е необходимо, за 
предишните дейности, записани на картата на водач. 
Периодите на неизвестна дейност с отрицателно 
времетраене (начало на периода с неизвестна дейност > 
края на периода с неизвестна дейност) поради припок­ 
риване на времеви периоди между два различни уреда за 
регистриране на данните за движението не се вземат 
предвид при изчисленията.  
Когато водачът не е вкарвал картата си, изчисленията се 
основават на данните, записани в паметта по време на 
текущия период, през който не е била вкарвана никаква 
карта, като се отнасят към съответното четящо устройство;  
р) „памет за данни“ означава:  
електронно устройство за съхраняване на данни, вградено 
в уредите за регистриране на данните за движението;  
с) „електронен подпис“ означава:  
данните, прибавени към блок от данни, или негово крип­ 
тографско преобразувание, което позволява на получателя 
на този блок да получи доказателство за неговата автен­ 
тичност и достоверност;  
т) „изтегляне на данни“ означава:  
копиране, заедно с електронния подпис, на част или на 
пълен набор файлове с данни, записани в паметта за 
данни на бордовото устройство или в паметта на тахог­ 
рафската карта, при условие че при този процес не се 
изменят или изтриват записани данни;  ▼B 
( 1 ) Този начин на изчисляване на времето на непрекъснато управлен ие на МПС и на 
общото време на прекъсване служи в уредите за регистриране на д анните за 
движението за изчисляване на предупреждението за времето на неп рекъснато 
управление на МПС. Той не предопределя юридическото тълкуване н а тези 
периоди. Може да бъдат използвани алтернативни начини за изчисл яване на 
времето на непрекъснато управление на МПС и на общото време на прекъсване 
в замяна на тези определения, ако те са остарели вследствие на актуализиране на 
останалото законодателство в дадената област. 
( 2 ) Периодите на НЕИЗВЕСТНА ДЕЙНОСТ съответстват на периодите, пр ез които 
картата на водача не е била вкарвана в уред за регистриране на данните за 
движението и за които няма извършено ръчно въвеждане на дейност ите на водача.
 02016R0799 — BG — 21.08.2023 — 003.001 — 18  
Производителите на интелигентни тахографи за превозни 
средства и производителите на оборудване, конструирано 
и предназначено за изтегляне на файлове с данни, трябва 
да предприемат всички подходящи мерки, за да 
гарантират, че изтеглянето на съответните данни може да 
бъде извършено с минимална загуба на време от страна на 
транспортните предприятия или водачите.  
Изтеглянето на файла с подробни данни за скоростта на 
движение може да не е необходимо за установяване на 
съответствие с разпоредбите на Регламент (ЕО) 
№ 561/2006, но може да бъде използвано за други цели, 
като например разследване на злополуки;  
у) „карта на водач“ означава:  
тахографска карта, издадена от органите на държава 
членка на конкретен водач, която идентифицира водача и 
служи за съхраняване на данни за дейността на водача;  
ф) „действителна обиколка на колелата“ означава:  
средната стойност от разстоянията, изминати от всяко от 
колелата, задвижващи превозното средство (двигателните 
колела) за времето на едно пълно завъртане. Измерването 
на тези разстояния се извършва при стандартни условия на 
изпитване, както е определено съгласно изискване 414, и 
се изразява във вида „l = … mm“. Производителите на 
превозни средства могат да заменят измерването на тези 
разстояния с теоретично изчисление, при което се взема 
предвид разпределението на теглото на превозното 
средство върху осите в състояние без товар и в 
готовност за движение (  1 ). Методите на това теоретично 
изчисление подлежат на одобряване от компетентен 
орган на държава членка и могат да бъдат приложени 
само преди пускането на тахографа;  
х) „събитие“ означава:  
ненормално действие, отчетено от интелигентния 
тахограф, което може да е резултат от опит за измама;  
ц) „външно устройство за GNSS“ означава  
устройство, което съдържа приемника на сигнали от 
GNSS, когато бордовото устройство не е отделно 
устройство, както и други компоненти, необходими за 
защитата на съобщаването на данни за местоположението 
към останалата част на бордовото устройство;  
ч) „неизправност“ означава:  
ненормално действие, открито от интелигентния тахограф, 
което може да се дължи на нарушено функциониране или 
повреда на уредите;  
ш) „приемник на сигнали от GNSS“ означава:  
електронно устройство, което получава и обработва по 
цифров път сигналите от един или повече спътници на 
Глобална навигационна спътникова система (на 
английски — GNSS) с цел осигуряване на информация 
за местоположението, скоростта и времето.  ▼B 
( 1 ) Регламент (ЕС) № 1230/2012 на Комисията от 12 декември 2012 г одина за 
прилагане на Регламент (ЕО) № 661/2009 на Европейския парламент  и на Съвета 
във връзка с изискванията за одобрение на типа по отношение на масите и 
размерите на моторните превозни средства и техните ремаркета и за изменение 
на Директива 2007/46/ЕО на Европейския парламент и на Съвета (О В L 353, 
21.12.2012 г., стр. 31).
 02016R0799 — BG — 21.08.2023 — 003.001 — 19  
щ) „монтиране“ означава:  
монтирането на тахограф в превозно средство;  
ъ) „оперативна съвместимост“ означава:  
способността на системите и съответните стопански 
процеси за обмен на данни и споделяне на информация;  
ю) „интерфейс“ означава:  
междусистемно устройство, осигуряващо средствата, чрез 
които системите могат да се свържат и да взаимодействат;  
я) „местоположение“ означава:  
географските координати на превозното средство в даден 
момент;  
аа) „датчик за движение“ означава:  
частта от тахографа, подаваща сигнал, който е показателен 
за скоростта и/или изминатото разстояние от превозното 
средство;  
▼M3 
бб) „невалидна карта“ означава:  
карта, която е дефектна или при която удостоверяването 
на автентичността е било неуспешно, или чиято дата за 
начало на валидността все още не е достигната, или 
чийто срок на валидност е изтекъл;  
карта се счита също така за невалидна от бордовото 
устройство:  
— ако карта със същата държава членка на издаване, със 
същата идентификация, т.е. идентификацията на водача 
или идентификацията на собственика, заедно с индекса 
за пореден номер и с по-голям индекс за подновяване 
вече е била вкарвана в бордовото устройство, или  
— ако карта със същата държава членка на издаване, със 
същата идентификация, т.е. идентификацията на водача 
или идентификацията на собственика, заедно с индекса 
за пореден номер и индекса за подновяване, но по- 
голям индекс за замяна, вече е била вкарвана в 
бордовото устройство;  
▼B 
вв) „отворен стандарт“ означава:  
стандарт, който според описанието в стандартен документ 
за спецификация се предоставя безплатно или срещу 
символична такса и който всички могат да възпро­ 
извеждат, разпространяват или използват без такса или 
срещу символична такса.  
гг) „извън обхвата“ означава:  
всички случаи, в които използването на уредите за регис­ 
триране на данните за движението не е необходимо 
съгласно Регламент (ЕО) № 561/2006;  
дд) „превишаване на скоростта“ означава:  
всяко превишаване на допустимата за съответното 
превозно средство скорост за време над 60 секунди, през 
което измерената скорост на превозното средство 
надвишава зададената в Директива 92/6/ЕИО на Съвета (  1 ), 
както е последно изменена;  ▼B 
( 1 ) Директива 92/6/ЕИО на Съвета от 10 февруари 1992 г. относно м онтирането и 
използването на устройства за ограничаване на скоростта за няко и категории 
моторни превозни средства в Общността (ОВ L 57, 2.3.1992 г., ст р. 27).
 02016R0799 — BG — 21.08.2023 — 003.001 — 20  
ее) „периодичен технически преглед“ означава:  
набор от действия, извършвани, за да се провери дали 
тахографът работи правилно, дали неговите настройки 
отговарят на параметрите на превозното средство, както 
и дали към тахографа няма прикачени устройства за мани­ 
пулиране;  
жж) „печатащо устройство“ означава:  
компонент на уредите за регистриране на данните за 
движението, който осигурява разпечатки на записаните в 
паметта данни;  
зз) „връзка с цел ранно откриване от разстояние“ означава:  
комуникация между устройството за връзка с цел ранно 
откриване от разстояние и четеца за връзка с цел ранно 
откриване от разстояние по време на целенасочени пътни 
проверки с цел дистанционно откриване на евентуална 
манипулация или злоупотреба с уреди за регистриране на 
данните за движението;  
▼M3 
ии) „устройство за връзка от разстояние“, „модул за връзка от 
разстояние“ или „устройство за ранно откриване от 
разстояние“ означава:  
оборудването в бордовото устройство, използвано за 
извършването на целенасочени пътни проверки;  
▼B 
йй) „четец за връзка с цел ранно откриване от разстояние“ 
означава:  
системата, използвана от служителите на контролните 
органи за извършването на целенасочени пътни проверки;  
▼M3 
кк) „подновяване на картата“ означава:  
издаването на нова тахографска карта, когато срокът на 
валидност на съществуваща карта изтича или тя не 
функционира правилно и е била върната на органа, 
който я е издал;  
▼B 
лл) „ремонт“ означава:  
всякакъв ремонт на датчик за движение, на бордово 
устройство или на кабел, който налага прекъсване на 
неговото електрическо захранване, прекъсване на 
връзката с други компоненти на тахографа или отваряне 
на тахографа или бордовото устройство;  
▼M3 
мм) „замяна на картата“ означава:  
издаването на нова тахографска карта, която заменя 
съществуваща карта, която е обявена за изгубена, 
открадната или за неправилно функционираща и която 
не е била върната на органа, който я е издал;  
▼B 
нн) „сертифициране по отношение на сигурността“:  
процесът, чрез който организация за сертифициране по 
единни критерии удостоверява, че уредите за регистриране 
на данните за движението (или компонент от тях) или изслед­ 
ваната тахографска карта отговарят на изискванията за 
сигурност, формулирани в съответните профили за защита;  
оо) „самоизпробване“ означава:  
изпробвания, извършвани периодично и автоматично от 
уредите за регистриране на данните за движението с цел 
откриване на неизправности;  
пп) „измерване на времето“ означава:  
непрекъснат цифров запис на координираното 
универсално време и дата (UTC);  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 21  
рр) „сверяване на часовника“ означава:  
сверяване на текущото време, сверяване на текущото 
време, което може да се извършва автоматично, като за 
еталонна стойност се използва времето, получено от 
приемника на сигнали от GNSS, или при калибриране;  
▼B 
сс) „размери на гумите“ означава:  
указването на размерите на гумите (външни задвижващи 
колела) в съответствие с Директива 92/23/ЕИО на 
Съвета (  1 ), както е последно изменена;  
тт) „идентификация на превозното средство“ означава:  
номерата, позволяващи идентифицирането на превозното 
средство: регистрационният номер (VRN) с указване на 
държавата членка, извършила регистрацията, и идентифи­ 
кационният номер на превозното средство (VIN) (  2 ); 
уу) за целите на изчисленията в уредите за регистриране на 
данните за движението „седмица“ означава:  
период между 00.00 часа UTC в понеделник и 24.00 часа 
UTC в неделя;  
фф) „карта за монтаж и настройки“ означава:  
тахографска карта, която се издава от органите на държава 
членка на определен за целта персонал на производител на 
тахографи, монтьор, производител на превозни средства 
или сервиз, одобрени от въпросната държава членка, чрез 
която се идентифицира титулярят на картата и която 
служи за изпитване, калибриране и активиране на тахог­ 
рафите и/или за изтегляне на данни от тях;  
хх) „адаптер“ означава:  
устройство, което подава сигнал в постоянно съответствие 
със скоростта на превозното средство и/или изминатото 
разстояние, различно от използваното за независимо 
откриване на движение, и което е:  
▼M3 
— монтирано и се използва само в превозни средства от 
типове M1 и N1 (както са определени в член 4 от 
Регламент (ЕС) 2018/858 на Европейския парламент и 
на Съвета (  3 ), 
▼B 
— монтирано в случаите, в които технически не е 
възможно монтирането на друг тип съществуващ 
датчик за движение, който вече е в съответствие с 
разпоредбите на настоящото приложение и допълнения 
1 — 15 към него,  ▼M3 
( 1 ) Директива 92/23/ЕИО на Съвета от 31 март 1992 година относно гумите за 
моторни превозни средства и техните ремаркета, както и тяхното монтиране 
(ОВ L 129, 14.5.1992 г., стр. 95). 
( 2 ) Директива 76/114/ЕИО на Съвета от 18 декември 1975 година за сближаването на 
законодателствата на държавите-членки относно задължителните ре гистрационни 
табели и обозначения на моторни превозни средства и техните рем аркета, 
тяхното разположение и метод на закрепване (ОВ L 24, 30.1.1976 г., стр. 1). 
( 3 ) Регламент (ЕС) 2018/858 на Европейския парламент и на Съвета от 30 май 2018 г. 
относно одобряването и надзора на пазара на моторни превозни ср едства и техните 
ремаркета, както и на системи, компоненти и отделни технически възли, предназ­ 
начени за такива превозни средства, за изменение на регламенти (ЕО) № 715/2007 
и (ЕО) № 595/2009 и за отмяна на Директива 2007/46/ЕО (ОВ L 151 , 14.6.2018 г., 
стр. 1).
 02016R0799 — BG — 21.08.2023 — 003.001 — 22  
— монтирано между бордовото устройство и мястото, в 
което се генерират импулсите за скорост/разстояние от 
вградени датчици или от алтернативни интерфейси,  
— по отношение на бордовото устройство поведението на 
адаптера е същото, като при свързване към бордовото 
устройство на датчик за движение, който е в съот­ 
ветствие с разпоредбите на настоящото приложение и 
допълнения 1 — 16 към него;  
използването на такъв адаптер в описаните по-горе 
превозни средства трябва да позволява монтажа и 
правилната употреба на бордово устройство, което е в 
съответствие с всички изисквания на настоящото 
приложение,  
при тези превозни средства интелигентният тахограф 
включва кабели, адаптер и бордово устройство;  
цц) „цялост на данните“ означава:  
точността и непротиворечивостта на записаните данни, 
указани от липсата на каквато и да е промяна в данните 
между две обновявания на запис от данни. Целостта 
означава, че данните са точно копие на оригиналната 
версия, напр. че не са били повредени в процеса на 
записване и прочитане от тахографската карта или 
специално оборудване или при предаване по канал за 
връзка;  
▼M3 
чч) резервирана за бъдеща употреба;  
▼B 
шш) интелигентна тахографска система означава:  
уредите за регистриране на данните за движението, тахог­ 
рафските карти и наборът от всякакво пряко или непряко 
взаимодействащо с тях оборудване по време на тяхното 
производство, монтаж, използване, изпитване и проверка, 
като например карти, четец за връзка с цел ранно 
откриване от разстояние и всякакво друго оборудване за 
изтегляне на данни, анализ на данни, калибриране, гене­ 
риране, управление или въвеждане на защитни елементи и 
т.н.; 
▼M3 
щщ) „дата на въвеждане“ означава:  
датата, определена в Регламент (ЕС) № 165/2014, от която 
превозните средства, регистрирани за първи път, трябва да 
са оборудвани с тахограф в съответствие с настоящия 
регламент;  
▼B 
ъъ) защитен профил означава:  
документ, който се използва като част от процедура за 
сертифициране в съответствие с общите критерии, в 
който е дадена независима от приложението спецификация 
на изискванията за сигурност по отношение на гаранти­ 
рането на информацията;  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 23  
юю) точност на GNSS:  
в контекста на регистриране с тахографи на местополо­ 
жението от Глобална навигационна спътникова 
система (GNSS) означава стойността на фактора на нама­ 
ляване на точността при определяне на местоположението 
в хоризонталната равнина (HDOP), изчислявана като мини­ 
малните стойности на HDOP, натрупани на наличните 
системи GNSS ;  
▼M1 
яя) „общо време на управление“ означава:  
стойност, представляваща общо натрупания брой минути 
управление на дадено превозно средство.  
Стойността на общото време на управление е непре­ 
къснато отброяваната стойност на всички минути, които 
функцията за следене на дейностите, извършвани от 
водача, в уредите за регистриране на данните за 
движението отчита като „УПРАВЛЕНИЕ“, и се използва 
само за да се задейства регистриране на местоположението 
на превозното средство всеки път, когато общото време на 
управление достигне кратно число на три часа. Отброя­ 
ването с натрупване започва с активирането на уреда за 
регистриране на данните за движението. То не се влияе от 
други условия, като местоположение извън обсег или 
пътуване с ферибот/влак.  
Не се предвижда показване, разпечатване или извличане на 
стойността на общото време на управление.  
▼B 
2 ОБЩИ ХАРАКТЕРИСТИКИ И ФУНКЦИИ НА УРЕДИТЕ ЗА 
РЕГИСТРИРАНЕ НА ДАННИТЕ ЗА ДВИЖЕНИЕТО  
2.1 Общи  характеристики  
Функцията на уредите за регистриране на данните за 
движението е да се записва, съхранява, изобразява, отпечатва 
и да се предоставят данни относно дейностите на водача.  
Всяко превозно средство, оборудвано с уреди за регистриране 
на данните за движението съгласно разпоредбите на настоящото 
приложение, трябва да има скоростомер и километражен брояч. 
Тези функции може да бъдат включени в уредите за регис­ 
триране на данните за движението.  
01) уредите за регистриране на данните за движението 
включват кабели, датчик за движение и бордово 
устройство.  
02) Интерфейсът между датчиците за движение и 
бордовите устройства трябва да са в съответствие с 
изискванията, специфицирани в допълнение 11.  
03) Бордовото устройство трябва да има връзка с глобална 
навигационна спътникова система(и), както е посочено 
в допълнение 12.  
04) Бордовото устройство трябва да комуникира с четците 
за връзка с цел ранно откриване от разстояние, както е 
специфицирано в допълнение 14.  
▼M3 
05) Бордовото устройство трябва да включва интерфейс с 
ITS, който е специфициран в допълнение 13.  
Уредите за регистриране на данните за движението 
могат да имат връзка с други устройства чрез допъл­ 
нителни интерфейси и/или посредством интерфейса с 
ITS. ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 24  
06) Всяко вмъкване или свързване на функция или 
устройство(а), одобрено(и) или не, във или към уреди 
за регистриране на данните за движението, не трябва да 
предизвиква смущения или да бъде в състояние да 
смущава правилната и сигурна работа на уредите за 
регистриране на данните за движението, или да бъде 
в противоречие с разпоредбите на настоящия 
регламент.  
Потребителите на уредите за регистриране на данните 
за движението указват своята самоличност посредством 
тахографски карти.  
07) Уредите за регистриране на данните за движението 
дават избирателни права за достъп до данните и 
функциите според типа и/или самоличността на потре­ 
бителя.  
Уредите за регистриране на данните за движението записват и 
съхраняват данни в своята памет, в устройството за кому­ 
никация от разстояние и в тахографски карти.  
▼M3 
Това се извършва в съответствие с приложимото законода­ 
телство на Съюза по отношение на защитата на данните и в 
съответствие с член 7 от Регламент (ЕС) № 165/2014.  
▼B 
2.2 Функции  
08) Уредите за регистриране на данните за движението 
трябва да осигуряват следните функции:  
— следене на поставянията и изважданията на картите,  
— измерване на скорост, разстояние и определяне на 
местоположение,  
— измерване на времето,  
— следене на дейностите, извършвани от водача,  
— следене на състоянието при управление на МПС,  
▼M3 
— ръчно въвеждане на данни от водача:  
— въвеждане на местоположението в началото 
и/или в края на дневните периоди на работа,  
— ръчно въвеждане на дейностите, извършвани от 
водача, и на съгласието на водача за интерфейса 
с ITS,  
— въвеждане на особени условия,  
— въвеждане на товаро-разтоварни операции,  
▼B 
— управление на блокировките, наложени от 
превозвача,  
— следене на контролните дейности,  
— откриване на събития и/или на неизправности,  
— вградени функции за изпробване и самоизпробване,  
— четене на данни от паметта,  
— записване и съхраняване на данните в паметта,  
— четене от тахографските карти,  
— записване и съхраняване на данните в тахог­ 
рафските карти,  
— изобразяване на данните,  
— отпечатване,  
— предупреждаване,  
— прехвърляне на данни към външни носители,  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 25  
— връзка от разстояние за извършване на целена­ 
сочени пътни проверки,  
— данни, прехвърляни към допълнителни устройства,  
— калибриране,  
— пътна проверка на калибрирането,  
— сверяване на часовника,  
▼M3 
— следене на пресичането на граници,  
— актуализация на софтуера.  
▼B 
2.3 Режими  на работа  
09) Уредите за регистриране на данните за движението 
трябва да осигуряват следните четири режима на 
работа:  
— работен режим,  
— контролен режим,  
— режим на калибриране,  
— режим „превозвач“.  
10) Уредите за регистриране на данните за движението 
трябва да превключват към следните режими на 
работа според валидната тахографска карта, вкарана в 
интерфейсното устройство за карта: За определянето на 
режима на работа, поколението на тахографската карта 
е без значение, при условие че вкараната карта е 
валидна. Една карта за монтаж и настройки от първо 
поколение винаги се счита за невалидна, когато се 
вкара в бордово устройство от второ поколение.  
Режим на работа  Процеп за карта на водач  
Няма карта  Карта на водач  Контролна карта  Карта за монтаж 
и настройки  Карта на 
превозвач
 Процеп за карта на втория водач Няма карта  Работен  Работен  Контролен  Калибриране  Предприятие  
карта на водач  Работен  Работен  Контролен  Калибриране  Предприятие  
Контролна 
карта  Контролен  Контролен  Контролен (*)  Работен  Работен  
Карта за 
монтаж и 
настройки  Калибриране  Калибриране  Работен  Калиб­ 
риране (*)  Работен  
Карта на 
превозвач  „Предприятие“  „Предприятие“  Работен  Работен  „Пред­ 
приятие“ (*)  
(*) В тези ситуации уредите за регистриране на данните за движе нието трябва да използват само тахографската карта, 
поставена в процепа за карта на водач.  
11) Уредите за регистриране на данните за движението 
трябва да отхвърлят вкарани невалидни карти, като 
обаче позволяват изобразяването, отпечатването и 
изтеглянето на данни от карта с изтекъл срок.  
12) Всички функции, изброени в 2.2, трябва да работят при 
всички режими на работа, с изключение на:  
— функцията за калибриране, която е достъпна само в 
режима на калибриране,  
— функцията за пътна проверка на калибрирането, 
която е достъпна само в контролния режим,  
— функцията за управление на блокиранията, 
наложени от превозвача, която е достъпна само в 
режим „превозвач“,  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 26  
— функцията за следене на контролните дейности, 
която работи само в контролния режим,  
▼M3 
— функцията за изтегляне на данни не е достъпна в 
работен режим, с изключение на:  
а) предвиденото в изискване 193,  
б) изтеглянето на данни от карта на водач, когато в 
бордовото устройство не е вкарана друга карта.  
▼B 
13) Уредите за регистриране на данните за движението 
могат да подават всякаква информация към дисплей, 
печатащо устройство или външни интерфейси, със 
следните изключения:  
— в работен режим, при който всяка идентификация 
на самоличност (фамилно име и лично(и) име(на)), 
което не отговаря на вкараната тахографска карта, 
се маскира, както и всеки номер на карта, който не 
отговаря на вкараната тахографска карта, се маскира 
частично (маскира се всеки нечетен символ отляво 
надясно),  
▼M3 
— в режим „превозвач“ данните за водача (изисквания 
102, 105, 108, 133а и 133д) могат да бъдат 
извлечени само за периодите, за които отсъства 
блокиране, или които не са блокирани от друг 
превозвач (определяно от първите 13 цифри от 
номера на картата на превозвач),  
▼B 
— когато в уредите за регистриране на данните за 
движението не е вкарана карта, данните за водача 
могат да бъдат извличани само за същия ден и за 8- 
те предшестващи календарни дни,  
▼M3 
— лични данни, записани и създадени от тахографа 
или от тахографски карти, не трябва да бъдат 
подавани навън посредством интерфейса с ITS на 
бордовото устройство, освен ако не бъде 
проверено че има съгласие на водача, за когото се 
отнасят данните,  
▼M1 
— бордовите устройства обикновено са със срок на 
валидност на действията от 15 години, считано от 
датата, на която влизат в сила сертификатите на 
бордовото устройство, но устройствата могат да се 
използват още 3 месеца само за изтегляне на данни.  
▼B 
2.4 Сигурност  
▼M1 
Сигурността на системата цели да предпазва паметта така, че да 
възпрепятства неупълномощен достъп до нея или манипулиране 
на данните и да открива опити за това, да защитава целостта и 
автентичността на данните, които се обменят между датчика за 
движение и бордовото устройство, между уредите за регис­ 
триране на данните за движението и тахографските карти, а 
също така между бордовото устройство и външното устройство 
за GNSS, ако има такова, както и да защитава поверителността, 
целостта и автентичността на данните, обменяни чрез връзката 
за ранно откриване от разстояние с контролна цел, и да 
проверява целостта и автентичността на изтеглените данни.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 27  
14) С цел постигане на сигурност на системата, следните 
компоненти трябва да отговарят на изискванията за 
сигурност, специфицирани в техните профили за 
защита, както се изисква в допълнение 10:  
— бордово устройство,  
— тахографска карта,  
— датчик за движение,  
▼M3 
— външно устройство за GNSS (този профил е 
необходим и приложим само за варианта с външно 
устройство за GNSS).  
▼B 
3 КОНСТРУКТИВНИ И ФУНКЦИОНАЛНИ ИЗИСКВАНИЯ ЗА 
УРЕДИТЕ ЗА РЕГИСТРИРАНЕ НА ДАННИТЕ ЗА ДВИЖЕНИЕТО  
3.1 Следене  на вкарването  и изваждането  на картите  
15) Уредите за регистриране на данните за движението 
трябва да следят интерфейсните устройства за карта, 
за да откриват вкарванията и на изважданията на карта.  
▼M3 
16) При вкарването на карта (или удостоверяване на автен­ 
тичността на картата от разстояние), уредите за регис­ 
триране на данните за движението трябва да 
разпознават дали картата е валидна тахографска карта 
в съответствие с определението в раздел 1, буква бб) и 
ако да, да разпознават типа и поколението ѝ.  
За да провери дали вече е вкарана карта, уредите за 
регистриране на данните за движението използват 
данните от тахографската карта, съхранени в нейната 
памет, както е определено в изискване 133.  
▼B 
17) Тахографските карти от първо поколение трябва да се 
считат за невалидни от уредите за регистриране на 
данните за движението, веднъж щом възможността за 
използване на тахографски карти от първо поколение е 
премахната от страна на сервиза, в съответствие с 
допълнение 15 (MIG003)  
18) Карти за монтаж и настройка от първо поколение, 
които се вкарват в уреди за регистриране на данните 
за движението от второ поколение, трябва да се считат 
за невалидни.  
19) Уредите за регистриране на данните за движението 
трябва да бъдат така конструирани, че тахографските 
карти да бъдат застопорявани в правилно положение в 
интерфейсното устройства за карта.  
▼M3 
20) Изваждането на тахографска карта е възможно само 
когато превозното средство е спряло и след като съот­ 
ветните данни са записани на нея. Изваждането на 
тахографската карта трябва да изисква целенасочено 
действие на потребителя.  
▼B 
3.2 Измерване  на скоростта  и разстоянието  и определяне  на 
местоположението  
21) Датчикът за движение (евентуално вграден в адаптера) 
е основният източник на сигнал за измерването на 
скоростта и на изминатото разстояние.  
22) Тази функция трябва да мери непрекъснато и да може 
да подава стойността от километражния брояч, съот­ 
ветстваща на общото разстояние, изминато от 
превозното средство, чрез използване на импулсите, 
подавани от датчика за движение.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 28  
23) Тази функция трябва да мери непрекъснато и да може 
да подава скоростта на превозното средство чрез 
използване на импулсите, подавани от датчика за 
движение.  
24) Функцията за измерване на скоростта на превозното 
средство трябва също така да подава информацията 
дали превозното средство е в движение или е спряло. 
Смята се, че превозното средство е в движение щом 
функцията засича от датчика за движение повече от 1 
имп./s за период не по-малко от 5 секунди, в противен 
случай се приема, че превозното средство е спряло.  
25) Устройствата за показване на скоростта (скоростомер) и 
общото изминато разстояние (километражен брояч), 
монтирани на всяко превозно средство, оборудвано с 
отговарящи на разпоредбите на настоящия регламент 
уреди за регистриране на данните за движението, 
трябва да отговарят на изискванията относно 
максимално допустимите толеранси (виж 3.2.1 и 
3.2.2), посочени в настоящото приложение.  
▼M3 
26) За откриване на манипулиране на данни за движението, 
информацията от датчика за движение трябва да бъде 
потвърдена от информация за движението на 
превозното средство, извлечена от приемника на 
сигнали от GNSS, и от друг(и) източник(ци), неза­ 
висими от датчика за движение. В бордовото 
устройство трябва да има най-малко още един 
независим източник за движението на превозното 
средство, без да е необходим външен интерфейс.  
27) Тази функция трябва да определя местоположението на 
превозното средство, за да се даде възможност за 
записване на:  
— места, където водачът и/или вторият водач започва 
своя дневен работен период;  
— места, където общото време на управление на 
превозното средство достигне кратно число на три 
часа;  
— места, където превозното средство е пресекло 
границата на държава;  
— места, в които са извършени товаро-разтоварни 
операции;  
— места, където водачът и/или вторият водач завършва 
своя дневен работен период.  
▼B 
3.2.1  Измерване  на изминатото  разстояние  
28) Изминатото разстояние може да бъде измервано така 
че: 
— или да се интегрира и движението напред, и 
движението на заден ход,  
— или да де включва само движението напред.  
29) Уредите за регистриране на данните за движението 
трябва да измерват разстояние от 0 до 9 999 999,9 km.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 29  
30) Измерваното разстояние трябва да бъде със следния 
толеранс (разстояния от най-малко 1 000 m):  
— ± 1 % преди монтирането,  
— ± 2 % по време на монтирането и на периодичните 
технически прегледи,  
— ± 4 % по време на работа.  
▼M3 
Толерансите не се използват за преднамерено 
изменение на измереното разстояние.  
▼B 
31) Разделителната способност при измерване на 
разстоянието трябва да бъде по-висока или равна на 
0,1 km.  
3.2.2  Измерване  на скоростта  
32) Уредите за регистриране на данните за движението 
трябва да измерват скорост от 0 до 220 km/h.  
▼M3 
33) С цел да гарантира максимален толеранс ± 6 km/h за 
показваната скорост по време на работа и като се взема 
предвид:  
— толеранс ± 2 km/h за различия в постъпващите 
данни (различия в гумите и др.),  
— толеранс ± 1 km/h за измерванията, извършвани по 
време на монтирането и на периодичните 
технически прегледи,  
при скорости между 20 и 180 km/h и при характе­ 
ристични коефициенти на превозното средство между 
2400 и 25 000 имп./km, уредите за регистриране на 
данните за движението трябва да могат да измерват 
скоростта с толеранс ± 1 km/h (при постоянна скорост).  
Забележка: Разделителната способност на записа на 
данните въвежда допълнителен толеранс от ± 0,5 km/h 
за скоростта, записвана в уредите за регистриране на 
данните за движението.  
▼B 
34) Скоростта трябва да бъде измервана правилно, в 
рамките на нормалния толеранс, в рамките на две 
секунди след промяна на скоростта, когато се е 
изменяла с темп 2 m/s  2 . 
35) Разделителната способност при измерване на скоростта 
трябва да бъде по-висока или равна на 1 km/h.  
3.2.3  Определяне  на местоположението  
36) Уредите за регистриране на данните за движението 
трябва да определят абсолютното местоположение на 
превозното средство чрез използване на приемника на 
сигнали от GNSS.  
▼M3 
37) Абсолютното местоположение се определя с 
географски координати за географска ширина и 
географска дължина в градуси и минути с разделителна 
способност 1/10 от минутата.  
▼B 
3.3 Измерване  на времето  
38) Функцията за измерване на времето трябва да 
осигурява непрекъснато измерване и изобразяването в 
цифров вид на датата и часа по координираното 
универсално време.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 30  
39) Датата и координираното универсално време се 
използват за определяне на дата за данните в уредите 
за регистриране на данните за движението (записи, 
обмен на данни) и за всички разпечатки, посочени в 
допълнение 4 „Разпечатки“.  
40) С цел показване на местното време, трябва да може да 
се коригира изместването на времето на стъпки от по 
половин час. Не се позволяват никакви други 
измествания освен отрицателни или положителни 
кратни на половин час стойности.  
▼M3 
41) Неточността на времето трябва да е ±1 секунда дневно 
или по-малко, при температурни условия в съот­ 
ветствие с изискване 213 и при липсата на сверяване 
на часовника.  
41a) Точността на времето, когато часовникът се сверява в 
сервиза в съответствие с изискване 212, трябва да бъде 
3 секунди или по-малко.  
41б) Бордовото устройство, трябва да включва брояч за 
неточността на времето, който да изчислява макси­ 
малната неточност на времето след последното 
сверяване на часовника в съответствие с точка 3.23. 
Максималната неточност на времето се определя от 
производителя на бордовото устройство и не трябва 
да надвишава 1 секунда на ден, както е определено в 
изискване 41.  
41в) Броячът за неточността на времето се нулира на 1 
секунда след всяко сверяване на часовника на уредите 
за регистриране на данните за движението в съот­ 
ветствие с точка 3.23. Това включва:  
— автоматични сверявания на часовника,  
— сверявания на часовника, извършени в режим на 
калибриране.  
▼B 
42) Разделителната способност при измерване на времето 
трябва да бъде по-висока или равна на 1 секунда.  
43) Измерването на времето не трябва да се влияе от 
прекъсване на външното електрическо захранване, с 
продължителност, по-малка от 12 месеца при 
условията за одобряване на типа.  
3.4 Следене  на дейностите  на водача  
44) Тази функция трябва да осигурява постоянно и отделно 
следене на дейностите, извършвани от един водач и 
един втори водач.  
45) Дейността, извършвана от водача, трябва да бъде 
управление на МПС, РАБОТА, НА РАЗПОЛОЖЕНИЕ 
или ПРЕКЪСВАНЕ/ПОЧИВКА.  
46) Водачът и/или вторият водач трябва да може да избира 
ръчно дейността РАБОТА, НА РАЗПОЛОЖЕНИЕ или 
ПРЕКЪСВАНЕ/ПОЧИВКА.  
47) Когато превозното средство е в движение, дейността 
управление на МПС трябва да бъде автоматично 
избрана за водача, а дейността НА РАЗПОЛОЖЕНИЕ 
трябва да бъде автоматично избрана за втория водач.  
48) Когато превозното средство спре, за водача трябва да 
бъде избрана автоматично дейността РАБОТА.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 31  
49) Приема се, че първата промяна на дейността към 
„ПРЕКЪСВАНЕ/ПОЧИВКА“ или „НА РАЗПО­ 
ЛОЖЕНИЕ“, настъпила през 120-те секунди след авто­ 
матичната промяна към „РАБОТА“ поради спирането 
на превозното средство, е настъпила в момента на 
спиране на превозното средство (и следователно евен­ 
туално е анулирала преминаването към „РАБОТА“).  
▼B 
50) Тази функция трябва да предава промените в дейността 
към функциите, осигуряващи записването на инфор­ 
мацията, с разделителна способност от една минута.  
51) За определена календарна минута, ако е регистрирана 
дейност „управление на МПС“ за непосредствено пред­ 
хождащата я минута и за непосредствено следващата я 
минута, за цялата минута се счита, че се извършва 
дейността „управление на МПС“.  
52) За определена календарна минута, за която не се счита, 
че се извършва дейността „управление на МПС“ 
съгласно изискване 051, за цялата минута се счита, че 
е извършвана дейността, която съвпада с най-дългата 
непрекъсната дейност, извършвана в рамките на 
минутата (или с най-скорошната дейност, при наличие 
на няколко дейности с еднаква продължителност).  
53) Тази функция трябва също така да позволява постоянно 
следене на непрекъснатото работно време и на общото 
време на прекъсване на водача.  
3.5 Следене  на състоянието  при управление  на МПС  
54) Тази функция трябва да осигурява постоянно и автоматично 
наблюдение на състоянието при управление на МПС.  
55) Състоянието при управление на МПС „ЕКИПАЖ“ трябва 
да бъде избрано, когато в уреда са вкарани две валидни 
карти на водач, а при всички останали случаи трябва да 
бъде избрано състоянието при управление на МПС „САМ“.  
3.6 Въвеждане  на данни  от водачите  
3.6.1  Въвеждане  на мястото , където  дневните  периоди  на работа  
започват  и/или завършват  
56) Тази функция трябва да позволява въвеждането на 
местата, където, според водача и/или втория водач, 
техните дневни периоди на работа започват и/или 
завършват.  
▼M3 
57) Под „места“ се разбира държавата и в допълнение, 
където е приложимо, регионът.  
58) При изваждане на картата на водач (или картата за 
монтаж и настройки) уредите за регистриране на 
данните за движението трябва да показват настоящото 
местоположение на превозното средство въз основа на 
информацията от GNSS и на запаметената цифрова 
карта в съответствие с точка 3.12.19 и трябва да 
поискат от титуляря на картата да потвърди или 
коригира ръчно мястото.  
59) Мястото, въведено в съответствие с изискване 58, се 
счита за мястото, където приключва дневният период 
на работа. То трябва да бъде записано на съответната 
карта на водач (или карта за монтаж и настройки) като 
временен запис и поради това по-късно може да бъде 
заместен от друг запис.  
Временно въвеждане, направено при последното 
изваждане на картата, се валидира (т.е. впоследствие 
не се замества) при следните условия:  
— въвеждане на място, където започва текущият 
дневен период на работа, при ръчно въвеждане 
съгласно изискване 61);  ▼M1
 02016R0799 — BG — 21.08.2023 — 003.001 — 32  
— следващото въвеждане на място, където започва 
текущият дневен период на работа, ако титулярът 
на картата не въведе място, където започва или 
където е свършил периодът на работа, по време на 
ръчното въвеждане съгласно изискване 61).  
Временно въвеждане, направено при последното 
изваждане на картата, се замества и новата стойност 
се валидира при следните условия:  
— следващото въвеждане на място, където започва 
текущият дневен период на работа, ако титулярът 
на картата не въведе място, където започва или 
където е свършил периодът на работа, по време на 
ръчното въвеждане съгласно изискване 61).  
▼B 
60) Трябва да е възможно въвеждането на местата, където 
дневният период на работа започва/завършва, чрез 
команди от менюто. Ако в рамките на една календарна 
минута се направят повече от едно такива въвеждания, 
трябва да се съхранят само последните извършени 
задания за начално място и крайно място.  
▼M3 
Уредите за регистриране на данните за движението 
трябва да показват настоящото местоположение на 
превозното средство въз основа на информацията от 
GNSS и на съхранената(ите) цифрова(и) карта(и) в 
съответствие с точка 3.12.19 и трябва да поискат от 
водача да потвърди или коригира ръчно мястото.  
▼B 
3.6.2  Ръчно  въвеждане  на дейностите , извършвани  от водача , и на 
съгласието  на водача  за интерфейса  с ITS 
▼M3 
61) При вкарването на карта на водач (или на карта за 
монтаж и настройки), и само в този момент, уредът за 
регистриране на данните за движението трябва да 
позволява ръчно въвеждане на дейности. Ръчното 
въвеждане на дейност се извършва, като се използват 
стойностите за местното време и дата от съответната 
часова зона (изместване спрямо координираното 
универсално време), която е текущо зададена за 
бордовото устройство.  
При вкарването на карта на водач или на карта за 
монтаж и настройки, на титуляря на картата се 
напомня за:  
— датата и часа на последния път, когато е извадил 
картата;  
— незадължително: текущо зададеното за бордовото 
устройство изместване на местното време спрямо 
UTC.  
При първото вкарване на дадена карта на водач или на 
карта за монтаж и настройка, към момента неизвестна 
за бордовото устройство, титулярят на картата трябва 
да бъде приканен да изрази своето съгласие за подаване 
на лични данни, свързани с тахографирането, 
посредством интерфейса с ITS. За да провери дали 
вече е вкарана карта, уредите за регистриране на 
данните за движението използват данните от тахог­ 
рафската карта, съхранени в нейната памет, както е 
определено в изискване 133.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 33  
Във всеки един момент, съгласието на водача 
(съответно на сервиза) може да бъде активирано или 
дезактивирано чрез команди от менюто, при условие, 
че е вкарана карта на водач (съответно карта за 
монтаж и настройка).  
Трябва да е възможно да се зададе дейност със 
следните ограничения:  
— видът на дейността трябва да бъде „РАБОТА“, „НА 
РАЗПОЛОЖЕНИЕ“ или ПРЕКЪСВАНЕ/ПОЧИВКА;  
— началото и краят на всяка дейност трябва да са в 
рамките на периода между последното изваждане на 
картата и нейното настоящо вкарване;  
— не се позволява взаимно припокриване на дейности 
във времето.  
Ако е необходимо, при първото вкарване на неиз­ 
ползвана преди карта на водач (или карта за монтаж 
и настройки) трябва да е възможно ръчно въвеждане.  
Процедурата за ръчно въвеждане на дейности трябва да 
включва толкова последователни стъпки, колкото е 
необходимо за задаване на вида и момента, като час и 
минути, на започване и завършване на всяка една 
дейност. За титуляря на картата трябва да има 
избираем вариант да не посочва дейност за която и да 
е част от периода от време между последното 
изваждане на картата и нейното настоящо вкарване.  
По време на ръчното въвеждане, съответстващо на 
вкарването на картата и, ако е необходимо, титулярят 
на картата трябва да има възможност да зададе:  
— място, където е завършил предишен дневен период 
на работа, заедно със съответното време (като по 
този начин се замества и валидира въведеното при 
последното изваждане на картата),  
— място, където започва текущият дневен период на 
работа, заедно със съответното време (като по този 
начин се валидира временното въвеждане при 
последното изваждане на картата),  
За мястото, където започва текущият дневен период на 
работа, въведено при текущото вкарване на картата, 
уредите за регистриране на данните за движението 
трябва да показват настоящото местоположение на 
превозното средство въз основа на информацията от 
GNSS и на запаметената(ите) цифрова(и) карта(и) в 
съответствие с точка 3.12.19 и трябва да поискат от 
водач да потвърди или коригира ръчно мястото.  
Ако титулярят на картата не въведе място, където 
започва или е завършил периодът на работа, по време 
на ръчните въвеждания във връзка с вкарването на 
картата, това се счита за декларация, че периодът му 
на работа не се е променил от последното изваждане на 
картата. Следващото въвеждане на място, където е 
завършил предишен дневен период на работа, трябва 
да замести временното въвеждане, извършено при 
последното изваждане на картата.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 34  
Ако е въведено място, то трябва да се запише в съот­ 
ветната тахографска карта.  
Ръчното въвеждане трябва да бъде прекъснато ако:  
— картата бъде извадена или,  
— превозното средство се движи и картата е в процепа 
за карта на водач.  
Позволени са допълнителни прекъсвания — напр. след 
изтичане на определен период от време, през който 
потребителят не е бил активен. Ако ръчното 
въвеждане бъде прекъснато, уредите за регистриране 
на данните за движението трябва да валидират вече 
въведените пълни записи за място и дейност (които 
съдържат или еднозначно посочени място и време, 
или вид, време на започване и време на завършване 
на дейността).  
Ако бъде поставена втора карта на водач или карта за 
монтаж и настройки докато е в ход ръчното въвеждане 
на дейности за вкарана преди това карта, трябва да е 
позволено завършване на ръчното въвеждане за тази 
предишна карта преди да започне ръчното въвеждане 
за втората карта.  
Титулярят на картата трябва да разполага с избираем 
вариант за ръчно въвеждане по следната минимална 
процедура:  
— ръчно задаване на дейности в хронологична послед­ 
ователност за периода от последното изваждане на 
картата до нейното настоящо вкарване,  
— като време на започване на първата дейност трябва 
да се зададе моментът на изваждане на картата. За 
всяко следващо въвеждане времето на започване 
автоматично трябва да се задава така, че непос­ 
редствено да следва времето на завършване за пред­ 
ишното въвеждане. За всяка дейност се избира и 
задава нейният вид и времето на завършване.  
Процедурата приключва, когато времето на завършване 
на ръчно зададена дейност съвпадне с времето на 
вкарване на картата.  
Уредите за регистриране на данните за движението 
трябва да позволяват на водачите и сервизите да 
качват на ротационен принцип ръчно въведени данни, 
които трябва да бъдат въведени по време на проце­ 
дурата чрез интерфейса с ITS, специфициран в 
допълнение 13, и по избор — чрез други интерфейси.  
Тогава уредите за регистриране на данните за 
движението трябва да позволяват на титуляря на 
картата да променя всяка една ръчно въведена 
дейност до нейното валидиране чрез избор на 
конкретна команда. След това трябва да е забранено 
каквато и да е изменение.  
▼B 
3.6.3  Въвеждане  на специфични  условия  
▼M3 
62) Уредите за регистриране на данните за движението 
трябва да позволяват на водача да въвежда в реално 
време следните две специфични условия:  
— „ИЗВЪН ОБХВАТ“ (начало, край)  
— „ПЪТУВАНЕ С ФЕРИБОТ/ВЛАК“ (начало, край).  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 35  
Не може да бъде зададено „ПЪТУВАНЕ С ФЕРИБОТ/ 
ВЛАК“, когато е зададено условието „ИЗВЪН 
ОБХВАТ“. Ако е отворено условие „ИЗВЪН 
ОБХВАТ“, уредите за регистриране на данните за 
движението не трябва да позволяват на потребителите 
да въведат начален флаг „ПЪТУВАНЕ С ФЕРИБОТ/ 
ВЛАК“.  
Отвореното условие „ИЗВЪН ОБХВАТ“ трябва задъл­ 
жително да бъде затворено автоматично от уреда за 
регистриране на данните за движението в случай на 
изваждане или вкарване на карта на водач.  
Ако е отворено условие „ИЗВЪН ОБХВАТ“, това води 
до забрана на следните събития и предупреждения:  
— управление без съответната карта,  
— предупреждения, свързани с времето на непре­ 
къснато управление на МПС.  
Водачът въвежда начален флаг „ПЪТУВАНЕ С 
ФЕРИБОТ/ВЛАК“ веднага след избирането на 
„ПРЕКЪСВАНЕ/ПОЧИВКА“ на ферибота или влака.  
Отворено „ПЪТУВАНЕ С ФЕРИБОТ/ВЛАК“ трябва да 
се приключи от уреда за регистриране на данните за 
движението, когато възникне някоя от следните 
ситуации:  
— водачът завършва ръчно „ПЪТУВАНЕ С ФЕРИБОТ/ 
ВЛАК“, което трябва да стане при пристигане на 
ферибота/влака в местоназначението, преди напус­ 
кането на ферибота/влака,  
— отворено е условие „ИЗВЪН ОБХВАТ“,  
— водачът изважда картата си,  
— дейността на водача се изчислява като 
„УПРАВЛЕНИЕ“ в продължение на една 
календарна минута в съответствие с точка 3.4.  
Ако в рамките на една календарна минута са въведени 
повече от едно специфични условия от един и същи 
вид, регистрира се само последното.  
3.6.4  Въвеждане  на товаро -разтоварна  операция  
62a) Уредите за регистриране на данните за движението 
трябва да позволяват на водача да въвежда и 
потвърждава в реално време информация, указваща, 
че превозното средство е в процес на товарене, разто­ 
варване или че едновременно се извършват товарене и 
разтоварване.  
Ако в рамките на една календарна минута са въведени 
повече от една товаро-разтоварни операции от един и 
същи вид, регистрира се само последната.  
62б) Операциите по товарене, разтоварване или едновре­ 
менното товарене и разтоварване се записват като 
отделни събития.  
62в) Товаро-разтоварната информация се въвежда преди 
превозното средство да напусне мястото, където се е 
извършила товаро-разтоварната операция.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 36  
3.7 Управление  на блокиранията , наложени  от превозвача  
63) Тази функция трябва да позволява управлението на 
блокировките, поставени от даден превозвач с цел да 
ограничи и запази единствено за себе си достъпа до 
данните в режим „превозвач“.  
64) Блокировките, наложени от превозвача, се състоят в 
дата и час на начало (блокиране) и дата и час на край 
(разблокиране), свързани с идентификацията на 
превозвача чрез номера на картата на превозвач (по 
време на блокирането).  
65) Блокирането и разблокирането са възможни само в 
реално време.  
66) Разблокирането трябва да може да се извърши само от 
превозвача, който е извършил блокирането (така, както 
то се идентифицира с първите 13 цифри на номера на 
картата на превозвач), или,  
67) Разблокирането трябва да става автоматично, когато 
друг превозвач извърши блокиране.  
68) В случай че даден превозвач извърши блокиране и ако 
предишното блокиране е било извършено от същия 
превозвач, се приема, че предишното блокиране не е 
разблокирано и че то все още е в сила.  
3.8 Следене  на контролните  дейности  
69) Тази функция трябва да следи дейностите по ИЗОБ­ 
РАЗЯВАНЕ, ОТПЕЧАТВАНЕ, ИЗТЕГЛЯНЕ НА 
ДАНННИ от БУ и картата, както и пътна ПРОВЕРКА 
НА КАЛИБРИРАНЕТО, провеждани в контролен 
режим.  
70) Тази функция трябва да осигурява също така следене на 
дейностите по КОНТРОЛ ЗА ПРЕВИШЕНА СКОРОСТ 
в контролен режим. Приема се, че е извършен контрол 
за превишена скорост, когато в контролен режим се 
изпраща съобщение „превишена скорост“ към печа­ 
тащото устройство или дисплея или когато данни за 
„събития или неизправности“ са изтеглени от паметта 
на бордовото устройство.  
3.9 Откриване  на събития  и/или неизправности  
71) Тази функция открива следните събития и/или неиз­ 
правности:  
3.9.1  Събитие  „вкарване  на невалидна  карта “ 
72) Това събитие се предизвиква от вкарването на 
невалидна карта, при вкарване на вече заменена карта 
на водач, и/или когато валидността на вкарана карта 
изтича.  
3.9.2  Събитие  „конфликт , предизвикан  от картата “ 
73) Това събитие се предизвиква от всяка от отбелязаните с 
хикс комбинации от карти в долната таблица:  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 37  
Конфликт, предизвикан от 
карта  Процеп за карта на водач  
Няма карта  Карта на водач  Контролна карта  Карта за монтаж 
и настройки  Карта на 
превозвач
 Процеп за карта на втория водач 
Няма карта  
Карта на водач  X  
Контролна карта  X  X  X  
Карта за монтаж и 
настройки  X X  X  X  
Карта на превозвач  X  X  X  
3.9.3  Събитие  „припокриване  във времето “ 
74) Това събитие се предизвиква когато датата/часът на 
последното изваждане на дадена карта на водач, 
прочетени от картата, са по-късни от текущите 
дата/час на уреда за регистриране на данните за 
движението, в който картата е вкарана.  
3.9.4  Събитие  „управление  на МПС  без съответната  карта “ 
75) Това събитие се предизвиква от всяка от отбелязаните с 
хикс комбинации от тахографски карти в долната 
таблица, когато дейността на водача става управление 
на МПС, или в случай на промяна на режима на работа, 
когато дейността на водача е управление на МПС:  
управление на МПС без 
съответната 
карта  Процеп за карта на водач  
Няма (или 
невалидна) 
карта  Карта на водач  Контролна карта  Карта за монтаж 
и настройки  Карта на 
превозвач
 Процеп за карта на втория водач 
Няма (или невалидна) 
карта  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) Това събитие се предизвиква при всяко превишаване на 
допустимата скорост.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 38  
3.9.8  Събитие  „прекъсване  на електрическото  захранване “ 
79) Това събитие се предизвиква в режим, различен от 
режима на калибриране или от контролния режим, 
при прекъсване за повече от 200 милисекунди на елек­ 
трическото захранване на датчика за движение и/или на 
бордовото устройство. Прагът на прекъсване се 
определя от производителя. Прекъсването на електри­ 
ческото захранване, дължащо се на пускането на 
двигателя на превозното средство, не трябва да пред­ 
извиква появата на това събитие.  
3.9.9  Събитие  „Грешка  в комуникацията  с устройството  за връзка  
от разстояние “ 
80) Това събитие трябва да се предизвиква,  извън  режима  
на калибриране , когато устройството за връзка от 
разстояние не потвърждава успешното приемане на 
данни при комуникацията от разстояние, изпратени от 
бордовото устройство, при повече от три опита.  
3.9.10  Събитие  „Липса  на информация  за местоположението  от 
приемник  на сигнали  от GNSS“  
81) Това събитие трябва да се предизвиква  извън  режима  
на калибриране , в случай на липса на информация за 
местоположението, постъпваща от приемник на сигнали 
от GNSS (вътрешен или външен) за повече от три часа 
натрупано, време на управление на МПС.  
3.9.11  Събитие  „Грешка  в комуникацията  с външното  устройство  за 
GNSS“  
82) Това събитие трябва да се предизвиква  извън  режима  
на калибриране , в случай на прекъсване на комуни­ 
кацията между външното устройство за GNSS и 
бордовото устройство за повече от 20 последователни 
минути, когато превозното средство е в движение.  
3.9.12  Събитие  „Грешка  в данните  за движението “ 
▼M3 
83) Това събитие се задейства  извън  режим  на калиб­  
риране  в случай на прекъсване на нормалния поток 
от данни между датчика за движение и бордовото 
устройство и/или в случай на грешка, свързана с 
целостта на данните или с удостоверяването на автен­ 
тичността им, по време на техния обмен между датчика 
за движение и бордовото устройство. Това събитие 
също така се задейства  извън  режим  на калибриране , 
в случай че скоростта, изчислена въз основа на 
импулсите на датчика за движение, се увеличи от 0 
до повече от 40 km/h в рамките на 1 секунда и след 
това остане над 40 km/h в продължение на най-малко 3 
секунди.  
▼B 
3.9.13  Събитие  „Противоречие  в данните  за движението  на 
превозното  средство “ 
▼M3 
84) Това събитие се задейства, както е посочено в 
допълнение 12,  извън  режим  на калибриране , в 
случай че информацията за движението, изчислена въз 
основа на датчика за движение, противоречи на инфор­ 
мацията за движение, изчислена от вътрешния 
приемник на сигнали от GNSS или от външно 
устройство за GNSS, или от друг(и) независим(и) 
източник(ци) в съответствие с изискване 26. Това 
събитие не се предизвиква по време на пътуване с 
ферибот/влак.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 39  
3.9.14  Събитие  „Опит  за нарушаване  на сигурността “ 
85) Извън режима за калибриране това събитие трябва да се 
предизвиква при настъпване на всяко друго събитие, 
засягащо сигурността на датчика за движение и/или 
на бордовото устройство и/или външното устройство 
за GNSS, така както се изисква в допълнение 10.  
▼M1 
3.9.15  Събитие  „времеви  конфликт “ 
▼M3 
86) Това събитие се предизвиква  извън  режим  на калиб­  
риране , когато бордовото устройство открие несъот­ 
ветствие между времето от функцията за измерване на 
времето на бордовото устройство и времето, произ­ 
лизащо от местоположенията с удостоверена автен­ 
тичност, изпращани от приемника на сигнали от 
GNSS или от външното устройство за GNSS. „Несъот­ 
ветствие във времето“ се установява, ако разликата във 
времето надвишава ± 3 секунди, съответстваща на 
точността на времето, определена в изискване 41а, 
като това се увеличава с максималната неточност на 
времето на ден. Това събитие се регистрира заедно 
със стойността на вътрешния часовник на уредите за 
регистриране на данните за движението. Бордовото 
устройство извършва проверка за задействането на 
събитие „времеви конфликт“ точно преди бордовото 
устройство автоматично да коригира вътрешния 
часовник на бордовото устройство в съответствие с 
изискване 211.  
▼B 
3.9.16  Неизправност  „Карта “ 
87) Тази неизправност се предизвиква при неизправност в 
тахографската карта по време на нейното функцио­ 
ниране.  
3.9.17  Неизправност  „Уред  за регистриране  на данните  за 
движението “ 
88) Тази неизправност се предизвиква при следните неиз­ 
правности, при режимите, различни от режима за 
калибриране:  
— Неизправност вътре в бордовото устройство  
— Неизправност в печатащото устройство  
— Неизправност в дисплея  
— Грешка при изтегляне на данни  
— Неизправност на датчика  
— Неизправност в приемника на сигнали от GNSS или 
външното устройство за GNSS  
— Неизправност в устройството за връзка от 
разстояние  
▼M3 
— Неизправност на интерфейса с ITS.  
3.9.18  Събитие  „Аномалия  в GNSS“  
88a) Това събитие се задейства извън режим на калибриране, 
когато приемникът на сигнали от GNSS открие атака 
или когато удостоверяването на автентичността на 
навигационните съобщения е неуспешна, както е 
посочено в допълнение 12. След задействане на 
събитието „Аномалия в GNSS“ през следващите 10 
минути бордовото устройство не генерира други 
събития „Аномалия в GNSS“  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 40  
3.10 Вградени  функции  за изпробване  и самоизпробване  
89) ►M1 Уредът за регистриране на данните за 
движението трябва да открива неизправности чрез 
функции за изпробване и самоизпробване в съот­ 
ветствие с таблицата по-долу: ◄  
Елемент за изпробване  Самоизпробване  Вградена функции за 
изпробване  
Софтуер  Работоспособност  
Памет за данни  Достъп  Достъп, цялост на 
данните  
Интерфейсни устройства 
за карта  Достъп  Достъп  
Клавиатура  Ръчна проверка  
Печатащо устройство  (по избор на 
производителя)  Разпечатка  
Дисплей  Визуална проверка  
Изтегляне на данни 
(извършвано само по 
време на изтеглянето)  Правилно 
функциониране  
Датчик  Правилно 
функциониране  Правилно 
функциониране  
Устройство за връзка от 
разстояние  Правилно 
функциониране  Правилно 
функциониране  
Устройство за GNSS  Правилно 
функциониране  Правилно 
функциониране  
▼M3 
Интерфейс с ITS  Правилно 
функциониране  
▼B 
3.11 Четене  от паметта  за данни  
90) Уредът за регистриране на данните за движението 
трябва да може да чете всякакви данни, записани в 
паметта му.  
3.12 Регистриране  и запис  в паметта  за данни  
▼M3 
За целите на настоящата точка,  
— под „365 дни“ се разбира 365 календарни дена на средна 
дейност на водачите в дадено превозно средство. Средната 
дейност на ден в дадено превозно средство се определя като 
най-малко 6 водачи или втори водачи, 6 цикъла на вкарване 
и изваждане на карта и 256 смени на дейностите. След­ 
ователно „365 дни“ включват най-малко 2190 водачи/втори 
водачи, 2190 цикъла на вкарване и изваждане на карта и 
93 440 смени на дейностите,  
— средният брой на въвежданията на местоположение на ден 
се определя като най-малко 6 въвеждания, когато дневният 
период на работа започва, и 6 въвеждания, когато дневният 
период на работа завършва, така че „365 дни“ включват най- 
малко 4380 местоположения,  
— средният брой местоположения на ден, когато общото време 
на управление достигне кратно число на три часа, се 
определя като най-малко 6 местоположения, така че „365 
дни“ включват най-малко 2190 такива местоположения,  
— средният брой пресичания на граница на ден се определя 
като най-малко 20 пресичания, така че „365 дни“ включват 
най-малко 7300 пресичания на граница,  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 41  
— средният брой товаро-разтоварни операции на ден се 
определя като най-малко 25 операции (независимо от 
типа), така че „365 дни“ включват най-малко 9125 товаро- 
разтоварни операции,  
— часовете се регистрират с точност от една минута, освен ако 
не е предвидено друго,  
— стойностите от километражния брояч се регистрират с 
разделителна способност един километър,  
— скоростите се регистрират с разделителна способност 
1 km/h,  
— местоположенията (географски ширини и дължини) се 
регистрират в градуси и минути, с разделителна способност 
1/10 от минутата, със съответните точност и време за 
снемане на данни на GNSS, както и с флаг, обозначаващ 
дали автентичността на позицията е била удостоверена.  
▼B 
91) Данните, записани в паметта, не трябва да се влияят от 
прекъсване на външното електрическо захранване с 
продължителност, по-малка от 12 месеца, при 
условията за одобряване на типа. Освен това данните, 
записани във външното устройство за връзка от 
разстояние, както е определено в допълнение 14, не 
трябва да се влияят от прекъсване на електрическото 
захранване по-краткотрайно от 28 дни.  
92) Уредите за регистриране на данните за движението 
трябва да могат да регистрират и записват по подраз­ 
биране или при задаване следните данни в своята 
памет:  
3.12.1  Данни  за идентификация  на уредите  
3.12.1.1 Д а н н и з а и д е н т и ф и к а ц и я н а б о р д о в о т о 
у с т р о й с т в о  
93) Уредът за регистриране на данните за движението 
трябва да може да записва в своята памет следните 
данни за идентификацията на бордовото устройство:  
— наименование на производителя,  
— адрес на производителя,  
— номер на частта,  
— сериен номер,  
— поколение на БУ,  
— способност за използване на тахографски карти от 
първо поколение  
— номер на версията на софтуера,  
— дата на инсталиране на версията на софтуера,  
— година на производство на уреда,  
— номер на одобрение,  
▼M3 
— идентификатор на версията на цифровата карта 
(изискване 133л).  
94) Данните за идентификацията на бордовото устройство 
се регистрират и записват еднократно от производителя 
на бордовото устройство, освен данните, които могат да 
бъдат променени в случай на актуализация на софтуера 
в съответствие с настоящия регламент, както и способ­ 
ността за използване на тахографски карти от първо 
поколение.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 42  
3.12.1.2  Д а н н и з а и д е н т и ф и к а ц и я н а д а т ч и к а з а д в и ж е н и е  
95) Датчикът за движение трябва да може да записва в 
паметта си следните данни за идентификация:  
— наименование на производителя,  
— сериен номер,  
— номер на одобрение,  
— идентификатор на вградения компонент за 
сигурност (напр. сериен номер на вътрешната 
интегрална схема/процесор),  
— идентификатор на операционната система (напр. 
номер на версията на софтуера).  
96) Данните за идентификация на датчика за движение се 
регистрират и записват еднократно в датчика от 
неговия производител.  
▼M3 
97) Бордовото устройство трябва да може да записва и 
съхранява в паметта си следните данни, свързани с 
последните 20 успешни сдвоявания на датчици за 
движение (ако в рамките на един календарен ден се 
случат няколко свързвания, в паметта се записват 
само първото и последното за деня):  
▼B 
За всяко от тези свързвания се регистрират следните 
данни:  
— данни за идентификация на датчика за движение:  
— сериен номер  
— номер на одобрение  
— данни за сдвояването на датчик за движение:  
— дата на сдвояването.  
3.12.1.3 Д а н н и з а и д е н т и ф и к а ц и я н а Г л о б а л н а н а в и г а ­ 
ц и о н н а с п ъ т н и к о в а с и с т е м а  
98) Външното устройство за GNSS трябва да може да 
записва в паметта си следните данни за идентификация:  
— наименование на производителя,  
— сериен номер,  
— номер на одобрение,  
— идентификатор на вградения компонент за 
сигурност (напр. сериен номер на вътрешната 
интегрална схема/процесор),  
— идентификатор на операционната система (напр. 
номер на версията на софтуера).  
99) Данните за идентификация се регистрират и записват 
еднократно във външното устройство за GNSS от 
неговия производител.  
▼M3 
100) Бордовото устройство трябва да може да записва и 
съхранява в паметта си следните данни, свързани с 
последните 20 успешни свързвания на външни 
устройства за GNSS (ако в рамките на един календарен 
ден се случат няколко свързвания, в паметта се 
записват само първото и последното за деня).  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 43  
За всяко от тези свързвания се регистрират следните данни:  
— данни за идентификация на външно устройство за 
GNSS:  
— пореден номер,  
— номер на одобрение,  
— данни за свързаното външно устройство за GNSS:  
— дата на свързването  
3.12.2  Ключове  и сертификати  
101) Уредите за регистриране на данните за движението 
трябва да могат да записват определен брой криптог­ 
рафски ключове и сертификати, както е посочено в 
допълнение 11, част А и част Б.  
3.12.3  Данни  за вкарването  и изваждането  на картата  на водач  или 
картата  за монтаж  и настройки  
102) За всеки цикъл на вкарване-изваждане на дадена карта 
на водач или карта за монтаж и настройки в уреда за 
регистриране на данните за движението, последното 
трябва да регистрира и записва в своята памет:  
— името и презимето на титуляря на картата така, 
както те са записани в картата,  
— номера на картата, държавата членка, която я е 
издала, и срокът на валидност, така както са 
записани на картата,  
— поколението на картата,  
— датата и часа на вкарването,  
— стойността от километражния брояч на превозното 
средство в момента на вкарването на картата,  
— процепа, в който се вкарва картата,  
— датата и часа на изваждането ѝ,  
— стойността от километражния брояч на превозното 
средство в момента на изваждането на картата,  
— следната информация относно последното превозно 
средство, използвано от водача така, както е 
записана в картата:  
— регистрационния номер на превозното средство 
(VRN) и държавата членка на регистрация,  
— поколението на БУ (когато е налично),  
— дата и час на изваждането на картата,  
— флаг, указващ дали при вкарването на картата 
титулярят на картата е въвел ръчно дейностите 
или не.  
103) Паметта трябва да може да запазва тези данни в 
продължение на най-малко 365 дни.  
104) Когато капацитетът за съхраняване на информация е 
изчерпан, новите данни заместват най-старите данни.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 44  
3.12.4  Данни  за дейностите  на водача  
105) Уредът за регистриране на данните за движението 
трябва да регистрира и записва в паметта си всяка 
промяна на дейността на водача и/или на втория 
водач, и/или всяка промяна на състоянието при 
управление на МПС, и/или всяко вкарване или 
изваждане на карта на водач или карта за монтаж и 
настройки:  
— състояние при управление на МПС (ЕКИПАЖ, 
САМ),  
— процеп (ВОДАЧ, ВТОРИ ВОДАЧ),  
— положение на картата в процепа (ВКАРАНА/ 
НЕВКАРАНА),  
— дейност (управление на МПС, НА РАЗПО­ 
ЛОЖЕНИЕ, РАБОТА, ПРЕКЪСВАНЕ/ПОЧИВКА),  
— дата и час на промяната.  
ВКАРАНА означава, че в процепа е вкарана валидна 
карта на водач или карта за монтаж и настройки. 
НЕВКАРАНА означава обратното, тоест че в процепа 
няма валидна карта на водач или карта за монтаж и 
настройки (напр. вкарана е карта на превозвач или не 
е вкарана карта)  
Въвежданите ръчно от водача данни за дейността не се 
записват в паметта.  
106) Паметта трябва да може да запазва данните за 
дейността на водача в продължение на най-малко 365 
дни. 
107) Когато капацитетът за съхраняване на информация е 
изчерпан, новите данни заместват най-старите данни.  
▼M1 
3.12.5  Места  и местоположения , където  започват  и завършват  
дневните  периоди  на работа  и/или където  общото  време  на 
управление  на МПС  достига  3 часа  
108) Уредът за регистриране на данните за движението 
трябва да регистрира и записва в своята памет за данни:  
— места и местоположения, където водачът и/или 
вторият водач започва своя дневен период на 
работа;  
— местоположения, където общото време на 
управление на МПС достига кратно число на три 
часа;  
— места и местоположения, където водачът и/или 
вторият водач приключва своя дневен период на 
работа.  
▼B 
109) Когато в тези моменти местоположението на 
превозното средство не е на разположение от 
приемника на сигнали от GNSS, уредът за регистриране 
на данните за движението трябва да използва 
последното налично местоположение и съответните 
дата и час.  
110) Заедно с всяко място или местоположение, уредът за 
регистриране на данните за движението трябва да 
регистрира и записва и в своята памет за данни:  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 45  
— номера на картата на водач и/или на втория водач и 
държавата членка, която е издала картата,  
▼B 
— поколението на картата,  
— дата и час на въвеждането,  
▼M1 
— вид на въвеждането (начало, край или 3 часа общо 
време на управление на МПС),  
▼B 
— съответната точност на GNSS, дата и час, ако е 
приложимо,  
— стойността от километражния брояч на превозното 
средство,  
▼M3 
— флаг, указващ дали автентичността на местополо­ 
жението е удостоверена.  
▼M3 
110a) За местата, където започва или завършва дневният 
период на работа, въведени по време на процедурата 
за ръчно въвеждане при вкарването на картата в съот­ 
ветствие с изискване 61, трябва в паметта да се запишат 
текущата стойност на километражния брояч и местопо­ 
ложението на превозното средство.  
▼M1 
111) Паметта за данни трябва да позволява съхраняването на 
места и местоположения, където започват и завършват 
дневните периоди на работа и/или където общото време 
на управление на МПС достига 3 часа, в продължение 
на най-малко 365 дни.  
▼B 
112) Когато капацитетът за съхраняване на информация е 
изчерпан, новите данни заместват най-старите данни.  
3.12.6  Данни  от километражния  брояч  
113) Уредът за регистриране на данните за движението 
трябва да записва в своята памет стойността от кило­ 
метражния брояч на превозното средство и съответната 
дата в полунощ всеки календарен ден.  
114) Паметта за данни трябва да позволява съхраняването 
ежедневните записи в полунощ от километражния 
брояч в продължение на най-малко 365 календарни дни.  
115) Когато капацитетът за съхраняване на информация е 
изчерпан, новите данни трябва да заместват най- 
старите данни.  
3.12.7  Подробни  данни  за скоростта  
▼M1 
116) Уредът за регистриране на данните за движението 
трябва да записва и съхранява в своята памет 
моментната скорост на превозното средство и датата и 
часа през всяка секунда най-малко от последните 24 
часа, по време на които превозното средство е било в 
движение.  
▼B 
3.12.8  Данни  за събитията  
За целите на настоящата подточка времето се записва с точност 
една секунда.  
117) Уредът за регистриране на данните за движението 
трябва да записва в своята памет следните данни за 
всяко засечено събитие, съгласно следните правила за 
запис:  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 46  
Събитие  Правила за запис в паметта  Данни, които се регистрират при всяко събитие  
Вкарване на невалидна 
карта  — 10-те най-скорошни събития.  — дата и час на събитие, 
— тип на картата(ите), номер, държава 
членка, издала картата, и поколение 
на картата, предизвикваща събитието. 
— брой сходни събития, възникнали 
същия ден  
Конфликт, предизвикан 
от карта  — 10-те най-скорошни събития.  — дата и час на начало на събитието, 
— дата и час на край на събитието, 
— тип и номер на картата(ите), държава 
членка, издала картата(ите), и 
поколение на двете карти, пред­ 
извикващи събитието.  
управление на МПС без 
съответната карта  — най-продължителното събитие за 
всеки от десетте последни дена на 
възникване на това събитие, 
— 5-те най-продължителни събития 
през последните 365 дни.  — дата и час на начало на събитието, 
— дата и час на край на събитието, 
— тип и номер на картата(ите), държава 
членка, издала картата(ите), както и 
поколение на всяка карта, вкарана в 
началото и/или в края на събитието, 
— брой сходни събития, възникнали 
същия ден.  
Вкарване на карта по 
време на управление на 
МПС  — последното събитие за всеки от 
десетте последни дена на възникване 
на това събитие,  — дата и час на събитието, 
— тип и номер на картата(ите), държава 
членка, издала картата(ите), 
поколение, 
— брой сходни събития, възникнали 
същия ден  
▼M3 
Неправилно 
приключване на 
последната картова 
сесия  — 10-те най-скорошни събития.  — дата и час на вкарване на картата, 
— тип и номер на картата(ите), държава 
членка, издала картата(ите), 
поколение, 
— данни относно последната сесия така, 
както са прочетени от картата: 
— дата и час на вкарване на картата.  
▼B 
Превишаване на 
скоростта (1)  — най-сериозното събитие (тоест 
събитието, при което е достигната 
най-висока средна скорост) през 
десетте последни дена на възникване 
на това събитие, 
— 5-те най-сериозни събития през 
последните 365 дни. 
— първото събитие, възникнало след 
последното калибриране  — дата и час на начало на събитието, 
— дата и час на край на събитието, 
— максимална скорост, измерена по 
време на събитието, 
— средноаритметична скорост, измерена 
по време на събитието, 
— тип и номер на картата, държава 
членка, издала картата, и поколение 
на картата на водач (ако е 
приложимо), 
— брой сходни събития, възникнали 
същия ден.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 47  
Събитие  Правила за запис в паметта  Данни, които се регистрират при всяко събитие  
Прекъсване на електри­ 
ческото захранване (2)  — най-продължителното събитие за 
всеки от десетте последни дена на 
възникване на това събитие, 
— 5-те най-продължителни събития 
през последните 365 дни.  — дата и час на начало на събитието, 
— дата и час на край на събитието, 
— тип и номер на картата(ите), държава 
членка, издала картата(ите), както и 
поколение на всяка карта, вкарана в 
началото и/или в края на събитието, 
— брой сходни събития, възникнали 
същия ден.  
Грешка в комуникацията 
с устройството за връзка 
от разстояние  — най-продължителното събитие за 
всеки от десетте последни дена на 
възникване на това събитие, 
— 5-те най-продължителни събития 
през последните 365 дни.  — дата и час на началото на събитие, 
— дата и час на края на събитие, 
— тип и номер на картата(ите), държава 
членка, издала картата(ите), както и 
поколение на всяка карта, вкарана в 
началото и/или в края на събитието, 
— брой сходни събития, възникнали 
същия ден.  
Липса на информация за 
местоположението от 
приемник на сигнали от 
GNSS  — най-продължителното събитие за 
всеки от десетте последни дена на 
възникване на това събитие, 
— 5-те най-продължителни събития 
през последните 365 дни.  — дата и час на началото на събитие, 
— дата и час на край на събитието, 
— тип и номер на картата(ите), държава 
членка, издала картата(ите), както и 
поколение на всяка карта, вкарана в 
началото и/или в края на събитието, 
— брой сходни събития, възникнали 
същия ден.  
▼M1 
Грешка в комуникацията 
с външното устройство 
за GNSS  — най-продължителното събитие за 
всеки от последните 10 дни на 
възникване, 
— 5-те най-продължителни събития 
през последните 365 дни.  — дата и час на началото на събитие, 
— дата и час на края на събитие, 
— тип и номер на картата(ите), държава 
членка, издала картата(ите), както и 
поколение на всяка карта, вкарана в 
началото и/или в края на събитието, 
— брой сходни събития, възникнали 
същия ден.  
▼B 
Грешка в данните за 
движението  — най-продължителното събитие за 
всеки от десетте последни дена на 
възникване на това събитие, 
— 5-те най-продължителни събития 
през последните 365 дни.  — дата и час на начало на събитието, 
— дата и час на край на събитието, 
— тип и номер на картата(ите), държава 
членка, издала картата(ите), както и 
поколение на всяка карта, вкарана в 
началото и/или в края на събитието, 
— брой сходни събития, възникнали 
същия ден.  
Противоречие в данните 
за движението на 
превозното средство  — най-продължителното събитие за 
всеки от десетте последни дена на 
възникване на това събитие, 
— 5-те най-продължителни събития 
през последните 365 дни.  — дата и час на начало на събитието, 
— дата и час на край на събитието, 
— тип и номер на картата(ите), държава 
членка, издала картата(ите), както и 
поколение на всяка карта, вкарана в 
началото и/или в края на събитието, 
— брой сходни събития, възникнали 
същия ден.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 48  
Събитие  Правила за запис в паметта  Данни, които се регистрират при всяко събитие  
Опит за нарушаване на 
сигурността  — 10-те най-скорошни събития за всеки 
тип събитие.  — дата и час на начало на събитието, 
— дата и час на края на събитие (ако е от 
значение), 
— тип и номер на картата(ите), държава 
членка, издала картата(ите), както и 
поколение на всяка карта, вкарана в 
началото и/или в края на събитието, 
— тип събитие.  
▼M1 
Времеви конфликт  — най-сериозното събитие за всеки от 
десетте последни дена на възникване 
(т.е. с най-голяма разлика между 
датата и часа на уреда за регис­ 
триране на данните за движението и 
датата и часа по GNSS). 
— 5-те най-сериозни събития през 
последните 365 дни.  — дата и час на уреда за регистриране на 
данните за движението, 
— дата и час по GNSS, 
— тип и номер на картата(ите), държава 
членка, издала картата(ите), както и 
поколение на всяка карта, вкарана в 
началото и/или в края на събитието, 
— брой сходни събития, възникнали 
същия ден.  
▼M3 
Аномалия в GNSS  — най-продължителното събитие за 
всеки от десетте последни дни на 
възникване на това събитие, 
— 5-те най-продължителни събития 
през последните 365 дни.  — дата и час на началото на събитието, 
— дата и час на края на събитието, 
— тип и номер на картата(ите), държава 
членка, издала картата(ите), както и 
поколение на всяка карта, вкарана в 
началото и/или в края на събитието, 
— брой сходни събития, възникнали 
същия ден.  
▼B 
1) Уредът за регистриране на данните за движението 
трябва да регистрира и записва също и в своята 
памет за данни:  
— датата и часа на последния КОНТРОЛ ЗА 
ПРЕВИШЕНА СКОРОСТ,  
— датата и часа на първото превишаване на 
скоростта, констатирано след този КОНТРОЛ 
ЗА ПРЕВИШЕНА СКОРОСТ.  
— броя на събитията „превишаване на скоростта 
след последния КОНТРОЛ ЗА ПРЕВИШЕНА 
СКОРОСТ“.  
2) Тези данни могат да бъдат регистрирани само при 
повторно включване на електрическото захранване, 
времената могат да бъдат известни с точност до 
минута.  
3.12.9  Данни  за неизправностите  
За целите на настоящата подточка времето се регистрира с 
разделителна способност 1 секунда.  
118) Уредите за регистриране на данните за движението 
трябва да се опитват да регистрират и записват в 
своята памет следните данни относно всяка открита 
неизправност, съгласно следните правила за запис:  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 49  
Неизправност  Правила за запис в паметта  Данни, които се регистрират при всяка неиз­ 
правност  
Неизправност на картата  — 10-те последни неизправности на 
картата на водач.  — дата и час на началото на неиз­ 
правност, 
— дата и час на края на неизправност, 
— тип и номер на картата(ите), държава 
членка, издала картата(ите), 
поколение.  
неизправности в уредите 
за регистриране на 
данните за движението  — 10-те последни неизправности за 
всеки тип неизправност, 
— първата неизправност след последното 
калибриране.  — дата и час на началото на неиз­ 
правност, 
— дата и час на края на неизправност, 
— тип на неизправността, 
— тип и номер на картата(ите), държава 
членка, издала картата(ите), както и 
поколение на всяка карта, вкарана в 
началото и/или в края на неизправ­ 
ността,  
3.12.10  Данни  за калибриране  
119) Уредът за регистриране на данните за движението 
записва и съхранява данни в своята памет, имащи 
отношение към:  
— параметрите на калибрирането, известни в момента 
на пускането,  
— своето най-първо калибриране след пускането си,  
— първото си калибриране в превозното средство, на 
което се намира в момента (идентифицирано от 
неговия VIN),  
— 20-те последни калибрирания (ако няколко калиб­ 
рирания се извършват в рамките на един календарен 
ден, са записват само първото и последното за 
деня).  
120) За всяко от тези калибрирания се регистрират следните 
данни:  
— цел на калибрирането (пускане, първо монтиране, 
монтиране, периодични технически прегледи),  
— наименование и адрес на сервиза,  
— номер на картата за монтаж и настройки, държава 
членка, която я е издала, и срок на валидност на 
картата,  
— идентификация на превозното средство,  
— актуализирани или потвърдени параметри: w, k, l, 
размер на гумите, регулировка на ограничителя на 
скоростта, брояч на километрите (стара и нова 
стойност), дата и час (стара и нова стойност),  
— типовете и идентификаторите на всички поставени 
пломби,  
▼M3 
— серийните номера на датчика за движение, 
външното устройство за GNSS (ако има такова) и 
външното устройство за връзка от разстояние (ако 
има такова),  
— типа на товара по подразбиране, свързан с 
превозното средство (товар от стоки или пътници),  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 50  
— държавата, в която е извършено калибрирането, 
както и датата и часът, в които местоположението, 
използвано за определяне на тази държава, са били 
дадени от приемника на сигнали от GNSS.  
▼B 
121) Освен това уредите за регистриране на данните за 
движението регистрират и записват в паметта си за 
данни способността си да използват тахографски 
карти от първо поколение (все още активирани или не).  
122) Датчикът за движение трябва да регистрира и записва в 
паметта си следните данни относно монтирането му:  
— първо сдвояване към бордово устройство (дата, час, 
номер на одобрение на устройството, сериен номер 
на устройството),  
— последно сдвояване с устройство, монтиран на 
превозното средство (дата, час, сертификационен 
номер на устройството, сериен номер на устрой­ 
ството).  
123) външното устройство за GNSS трябва да регистрира и 
записва в паметта си следните данни относно монти­ 
рането му:  
— първо свързване към бордово устройство (дата, час, 
номер на одобрение на устройството, сериен номер 
на устройството),  
— последно свързване към бордово устройство (дата, 
час, номер на одобрение на устройството, сериен 
номер на устройството).  
3.12.11  Данни  за сверяване  на часовника  
124) Уредът за регистриране на данните за движението 
трябва да регистрира и записва данни в своята памет, 
имащи отношение към: сверяванията на часовника, 
извършени в режим на калибриране извън рамките на 
периодичното калибриране (опр. буква е)):  
— последното сверяване на часовника,  
— 5-те най-значителни сверявания на часовника,  
125) За всяко от сверяванията на часовника се записват 
следните данни:  
— дата и час, старата стойност,  
— дата и час, новата стойност,  
— наименование и адрес на сервиза,  
— номер на картата за монтаж и настройки, държава 
членка, която я е издала, поколение на картата и 
срок на валидност на картата.  
3.12.12  Данни  за контролните  дейности  
126) Уредите за регистриране на данните за движението 
записват и съхраняват в своята памет следните данни, 
имащи отношение към последните 20 контролни 
дейности:  
— дата и час на извършения контрол,  
— номер на контролната карта, държава членка, която 
я е издала, и поколение на картата,  
— тип на контрола (изобразяване на данните и/или 
отпечатване върху хартия и/или изтегляне на 
данни от бордовото устройство и/или изтегляне на 
данни от картата и/или пътна проверка на калибри­ 
рането).  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 51  
127) При извършване на изтегляне на данни се регистрират 
също така датите на най-отдалечения и на най-близкия 
ден във времето, данните за които са изтеглени.  
3.12.13  Данни  за блокирания , извършени  от превозвач  
128) Уредите за регистриране на данните за движението 
трябва да регистрират и записват в паметта си 
следните данни, имащи отношение към последните 
255 блокирания, извършени от превозвача:  
— дата и час на блокирането,  
— дата и час на разблокирането,  
— номер на картата на превозвач, държава членка, 
която я е издала, и поколение на картата,  
— име и адрес на превозвач,  
Данните, блокирани преди чрез блокиране, което е 
заличено от паметта поради горепосоченото огра­ 
ничение, се разглеждат като неблокирани.  
3.12.14  Изтегляне  на данни  за дейностите  
129) Уредите за регистриране на данните за движението 
трябва да регистрират и записват в паметта си 
следните данни, имащи отношение към последното 
изтегляне на данни от паметта към външни носители 
в режим „превозвач“ или „калибриране“:  
— дата и час на изтеглянето на данните,  
— номер на картата на превозвач или на картата за 
монтаж и настройки, държава членка, която я е 
издала, и поколение на картата,  
— наименование на превозвача или на сервиза.  
3.12.15  Данни  за специфични  условия  
130) Уредите за регистриране на данните за движението 
трябва да регистрират и записват в паметта си 
следните данни, имащи отношение към специфични 
условия:  
— дата и час на въвеждането,  
— тип на специфичното условие.  
131) Паметта трябва да може да запазва данните за 
специфични условия в продължение на най-малко 365 
дни (като се предполага, че средно се отваря и затваря 
1 условие на ден). Когато капацитетът за съхраняване 
на данни е изчерпан, новите данни трябва да заместват 
най-старите данни.  
3.12.16  Данни  за тахографските  карти  
132) Уредите за регистриране на данните за движението 
трябва да могат да записват следните данни, свързани 
с различните тахографски карти, в които са били 
използвани в бордовото устройство:  
— номера на тахографската карта и нейния сериен 
номер,  
— производителя на тахографската карта,  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 52  
— типа на тахографската карта,  
— версията на тахографската карта,  
133) Уредите за регистриране на данните за движението 
трябва да могат да запишат най-малко 88 такива записа.  
▼M3 
3.12.17  Пресичане  на граници  
133a) Уредът за регистриране на данните за движението 
записва и съхранява в своята памет следната 
информация за пресичането на граници:  
— държавата, която превозното средство напуска,  
— държавата, в която превозното средство влиза,  
— местоположението, в което превозното средство е 
пресекло границата.  
133б) Заедно с държавата и местоположението, уредът за 
регистриране на данните за движението трябва да 
записва и съхранява в своята памет за данни:  
— номера на картата на водач и/или на втория водач и 
държавата членка, която е издала картата,  
— поколението на картата,  
— съответната точност на GNSS, датата и часа,  
— флаг, указващ дали автентичността на местополо­ 
жението е удостоверена  
— стойността на километражния брояч на превозното 
средство при откриването на пресичане на граница.  
133в) Паметта трябва да може да запазва тези пресичания на 
граници в продължение на най-малко 365 дни.  
133г) Когато капацитетът за съхраняване на данни е 
изчерпан, новите данни трябва да заместват най- 
старите данни.  
3.12.18  Товаро -разтоварни  операции  
133д) Уредът за регистриране на данните за движението 
записва и съхранява в своята памет следната 
информация за товаро-разтоварните операции на 
превозното средство:  
— типа на операцията (товарене, разтоварване или 
едновременно товарене и разтоварване),  
— местоположението, където е извършена товаро- 
разтоварната операция.  
133е) Когато в момента на товаро-разтоварната операция, 
местоположението на превозното средство не е на 
разположение от приемника на сигнали от GNSS, 
уредът за регистриране на данните за движението 
трябва използва последното налично местоположение 
и съответните дата и час.  
133ж) Заедно с типа на операцията и местоположението, 
уредът за регистриране на данните за движението 
записва и съхранява в своята памет за данни:  
— номера на картата на водач и/или на втория водач и 
държавата членка, която е издала картата,  
— поколението на картата,  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 53  
— датата и часът на товаро-разтоварната операция,  
— съответната точност на GNSS, датата и часа, ако е 
приложимо;  
— флаг, указващ дали автентичността на местополо­ 
жението е удостоверена,  
— стойността от километражния брояч на превозното 
средство.  
133з) Паметта за данни трябва да позволява съхраняването на 
товаро-разтоварните операции в продължение най- 
малко на 365 календарни дни.  
133и) Когато капацитетът за съхраняване на данни е 
изчерпан, новите данни трябва да заместват най- 
старите данни.  
3.12.19  Цифрова  карта  
133й) За целите на записването на местоположението на 
превозното средство при пресичане на границата на 
дадена държава уредите за регистриране на данните за 
движението трябва да съхраняват в своята памет 
цифрова карта.  
133к) Разрешени цифрови карти в подкрепа на функцията за 
следене на пресичането на граници на уредите за регис­ 
триране на данните за движението се предоставят от 
Европейската комисия за изтегляне в различни 
формати на специален защитен уебсайт.  
133л) За всяка от тези карти на уебсайта трябва да има иден­ 
тификатор на версията и хеш-стойност.  
133м) Картите съдържат:  
— ниво на дефиниране, съответстващо на ниво 0 по 
NUTS, съгласно номенклатурата на териториалните 
единици за статистически цели,  
— мащаб 1:1 000 000.  
133н) Производителите на тахографи си избират карта от 
уебсайта и я изтеглят по защитен начин.  
133о) Производителите на тахографи трябва да използват 
карта, изтеглена от уебсайта, само след като са 
проверили нейната цялост, използвайки хеш-стойността 
на картата.  
133п) Избраната карта се зарежда в уредите за регистриране 
на данните за движението от неговия производител в 
подходящ формат, но семантиката на заредената карта 
остава непроменена.  
133р) Производителят съхранява също така идентификатора 
на версията на картата, използвана в уредите за регис­ 
триране на данните за движението.  
133с) Трябва да има възможност съхранената цифрова карта 
да се актуализира или замени с нова, предоставена от 
Европейската комисия.  
133т) Актуализациите на цифровата карта се извършват, като 
се използват механизмите за актуализиране на 
софтуера, създадени от производителя, в изпълнение 
на изисквания 226г и 226д, така че уредите за регис­ 
триране на данните за движението да могат да 
проверяват автентичността и целостта на нова 
заредена карта, преди да я съхранят и да заменят пред­ 
ишната.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 54  
133у) Производителите на тахографи могат да добавят допъл­ 
нителна информация към основната карта, посочена в 
изискване 133м, за цели, различни от записване на 
пресичането на граници, като границите на регионите 
на ЕС, при условие че семантиката на основната карта 
не се променя.  
▼B 
3.13 Четене  на тахографските  карти  
134) Уредите за регистриране на данните за движението 
трябва при необходимост да могат да четат от тахог­ 
рафски карти от първо и второ поколение необхо­ 
димите данни:  
— идентификация на типа на картата, на титуляря на 
картата, на използваното преди това превозно 
средство, на датата и часа на последното 
изваждане на картата и на дейността, която е била 
избрана в този момент,  
— проверка, че последната картова сесия е била 
приключена правилно,  
▼M3 
— изчисляване на времето на непрекъснато управление 
на МПС на водача, общото време на прекъсване и 
на общото време на управление на МПС за пред­ 
ишната и настоящата седмица,  
▼B 
— отпечатване на заявките за разпечатка, свързани с 
данните, записани на карта на водач,  
— изтегляне на данни от карта на водач към външен 
носител.  
Това изискване се прилага само за тахографски карти 
от първо поколение, ако възможността за използването 
им не е била премахната от сервиз.  
135) При грешка в четенето, уредите за регистриране на 
данните за движението трябва да правят нов опит, 
максимум до три пъти, и при наличие на повтарящ се 
неуспех, да обявят картата за дефектна и невалидна.  
▼M3 
135a) Структурата на приложението „TACHO_G2“ зависи от 
версията. Картите от версия 2 съдържат допълнителни 
елементарни файлове към тези от картите от версия 1, и 
по-специално:  
— в карти на водач и карти за монтаж и настройки:  
— EF Places_Authentication трябва да съдържа 
статуса на удостоверяване автентичността на 
местоположението на превозното средство, 
съхранено в EF Places. Времеви печат се 
съхранява с всеки статус за удостоверяване на 
автентичността, който е точно същият като 
датата и часа на записа, съхранен със съот­ 
ветното местоположение в EF Places.  
— EF GNSS_Places_Authentication трябва да 
съдържа статуса на удостоверяване на автентич­ 
ността на местоположението на превозното 
средство, съхранено в EF GNSS_Places. 
Времеви печат се съхранява с всеки статус за 
удостоверяване на автентичността, който е 
точно същият като датата и часа на записа, 
съхранен със съответното местоположение в EF 
Places.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 55  
— EF Border_Crossings, EF Load_Unload_Operations 
и EF Load_Type_Entries трябва да съдържат 
данни, свързани с пресичането на граници, 
товаро-разтоварните операции и типовете товар.  
— в картите за монтаж и настройки:  
— EF Calibration_Add_Data трябва да съдържа 
допълнителни данни за калибриране към тези, 
съхранени в EF Calibration. Старата дата и час 
и идентификационният номер на превозното 
средство се съхраняват с всеки запис на допъл­ 
нителни данни за калибриране, които трябва да 
бъдат точно същите като старата дата и час и 
идентификационния номер на превозното 
средство, съхранени със съответните данни за 
калибриране в EF Calibration.  
— във всички тахографски карти:  
— EF VU_Configuration трябва да съдържа специ­ 
фичните настройки на тахографа на титуляря на 
картата.  
Бордовото устройство трябва да игнорира всеки статус 
на удостоверяване на автентичността, намиращ се в EF 
Places_Authentication или EF GNSS_Places_Authenti­
cation, когато в EF Places или EF GNSS_Places не 
бъде открито местоположение на превозното средство 
със същия времеви печат.  
Бордовото устройство игнорира елементарния файл EF 
VU_Configuration във всички карти, доколкото не са 
предвидени специални правила по отношение на изпол­ 
зването на такъв елементарен файл. Тези правила се 
установяват чрез изменение на приложение IB, което 
трябва да включва изменението или заличаване на 
настоящата подточка.  
▼B 
3.14 Регистриране  и запис  върху  тахографски  карти  
3.14.1  Регистриране  и запис  в тахографски  карти  от първо  
поколение  
136) При условие че използването на тахографски карти от 
първо поколение не е било премахнато от сервиз, 
уредите за регистриране на данните за движението 
трябва да регистрират и записват данни точно по 
същия начин както това би било извършвано от уреди 
от първо поколение за регистриране на данните за 
движението.  
137) Уредите за регистриране на данните за движението 
трябва да задават „данните за картовата сесия“ върху 
картата на водач или картата за монтаж и настройки 
веднага след вкарването на картата.  
138) Уредите за регистриране на данните за движението 
трябва да актуализират данните, записани върху 
валидна карта на водач, карта за монтаж и настройки, 
карта на превозвач и/или контролна карта, с всички 
необходими данни относно периода, през който 
картата е вкарана, и отнасящи се за титуляря ѝ. 
Данните, записвани върху тези карти, са специфи­ 
цирани в глава 4.  
139) Уредите за регистриране на данните за движението 
трябва да актуализират данните за дейността на 
водача и местоположенията (като е специфицирано в 
4.5.3.1.9 и 4.5.3.1.11), записани върху валидни карта 
на водач и/или карта за монтаж и настройки, при 
ръчно въведени от титуляря на картата данни за 
дейността на водача и местоположенията.  
▼M3 
140) Никакви събития и грешки, които не са дефинирани за 
уредите за регистриране на данните за движението от 
първо поколение, не се съхраняват върху карти на 
водач и за монтаж и настройки от първо поколение.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 56  
141) Актуализирането на данните, записани на тахог­ 
рафските карти се извършва по такъв начин, че когато 
това е необходимо, като се има предвид реалният 
капацитет за съхраняване на данни, най-новите данни 
да заместват най-старите данни.  
142) При грешка в записването, уредите за регистриране на 
данните за движението трябва да правят нов опит, 
максимум до три пъти, и при повтарящ се неуспех да 
обявяват картата за невалидна.  
▼M3 
143) Преди изваждането на карта на водач или карта за 
монтаж и настройки и след като всички съответни 
данни са съхранени върху картата, уредите за регис­ 
триране на данните за движението трябва да инициа­ 
лизират „данните за картовата сесия“.  
▼B 
3.14.2  Регистриране  и запис  в тахографски  карти  от второ  
поколение  
144) Тахографските карти от второ поколение трябва да 
съдържат 2 различни картови приложения, първото от 
които следва да бъде точно същото като приложението 
TACHO на тахографските карти от първо поколение, а 
второто — приложението „TACHO_G2“, както е специ­ 
фицирано в глава 4 и допълнение 2.  
▼M3 
Структурата на приложението „TACHO_G2“ зависи от 
версията. Картите от версия 2 съдържат допълнителни 
елементарни файлове към тези от картите от версия 1.  
▼B 
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), записани върху валидни карта на водач 
и/или карта за монтаж и настройки, при ръчно 
въведени от титуляря на картата данни за дейността 
на водача и местоположенията.  
▼M3 
147a) При вкарване на карта на водач или карта за монтаж и 
настройки уредите за регистриране на данните за 
движението трябва да съхраняват върху картата типа 
на товара по подразбиране на превозното средство.  
147б) При вкарване на карта на водач или карта за монтаж и 
настройки и след процедурата за ръчно въвеждане 
уредите за регистриране на данните за движението 
проверяват последното място, съхранено върху 
картата, където започва или завършва дневният 
период на работа. Това място може да бъде временно, 
както е посочено в изискване 59. Ако това място се 
намира в държава, различна от текущата, в която се 
намира превозното средство, уредите за регистриране 
на данните за движението записват върху картата 
запис за пресичане на границата с:  
— държавата, която водачът е напуснал: няма налично,  
— държавата, в която водачът влиза, текущата 
държава, в която се намира превозното средство,  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 57  
— датата и часа, когато водачът е пресекъл границата: 
часа на вкарване на картата,  
— местоположението на водача при пресичането на 
границата: няма налично,  
— стойността от километражния брояч на превозното 
средство: няма налично.  
▼B 
148) Актуализирането на данните, записани на тахог­ 
рафските карти се извършва по такъв начин, че когато 
това е необходимо, като се има предвид реалният 
капацитет за съхраняване на данни, най-новите данни 
да заместват най-старите данни.  
149) При грешка в записването, уредите за регистриране на 
данните за движението трябва да правят нов опит, 
максимум до три пъти, и при повтарящ се неуспех да 
обявяват картата за невалидна.  
150) Преди изваждането на карта на водач и след като 
всички съответни данни са записани върху двете 
картови приложения на картата, уредите за регис­ 
триране на данните за движението трябва да инициа­ 
лизират „данните за картовата сесия“.  
▼M3 
150a) Бордовото устройство игнорира елементарния файл EF 
VU_Configuration във всички карти, доколкото не са 
предвидени специални правила по отношение на изпол­ 
зването на такъв елементарен файл. Тези правила се 
установяват чрез изменение на приложение IB, което 
трябва да включва изменението или заличаване на 
настоящата подточка.  
▼B 
3.15 Извеждане  върху  дисплея  
151) Дисплеят трябва да бъде с най-малко 20 символа.  
152) Размерът на символите трябва да бъде най-малко 5 mm 
височина и 3,5 mm широчина.  
153) Дисплеят трябва да може да показва символите, 
определени в допълнение 1, глава 4 „Набори от 
символи“. Дисплеят може да използва опростено пред­ 
ставяне на символите (напр. букви с ударения може да 
бъдат изобразени без ударенията, а малките букви може 
да се показват като главни букви).  
154) Дисплеят трябва да е снабден с подходящо незасле­ 
пяващо осветяване.  
155) Показанията трябва да се виждат от външната страна на 
уредите за регистриране на данните за движението.  
156) Уредите за регистриране на данните за движението 
трябва да могат да изобразяват:  
— данните по подразбиране,  
— данни, свързани с предупрежденията,  
— данни относно достъпа до менютата,  
— други данни, поискани от потребителя.  
Уредите за регистриране на данните за движението 
може да изобразяват допълнителна информация при 
положение, че тя е ясно различима от гореизискваните 
информации.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 58  
157) При изобразяването на данните на уредите за регис­ 
триране на данните за движението трябва да се 
използват пиктограмите или комбинациите от 
пиктограми, изброени в допълнение 3. Могат да се 
използват допълнителни пиктограми или комбинации 
от пиктограми при положение, че те ся ясно 
различими от горепосочените пиктограми или 
комбинации от пиктограми.  
158) Дисплеят трябва да бъде винаги включен, когато 
превозното средство е в движение.  
159) Уредите за регистриране на данните за движението 
може да имат ръчна или автоматична функция за 
изключване на дисплея, когато превозното средство не 
е в движение.  
Форматът на изобразяване на данните е специфициран 
в допълнение 5.  
3.15.1  Изобразяване  по подразбиране  
160) Когато не е необходимо да се показва друга 
информация, уредите за регистриране на данните за 
движението трябва да показват по подразбиране 
следното:  
— местното време (координирано универсално 
време (UTC) + поправка, задавана от водача);  
— режима на работа,  
— текущата дейност на водача и на втория водач,  
— информация относно водача:  
— ако неговата текуща дейност е „управление на 
МПС“ — текущото му време на непрекъснато 
управление на МПС и текущото му общо време на 
прекъсване,  
— ако неговата текуща дейност не е „управление на 
МПС“ — текущата продължителност на тази 
дейност (от момента на нейното избиране) и 
общото време на прекъсване.  
161) Изобразяването на данните относно всеки водач трябва 
да бъде ясно, просто и недвусмислено. Когато инфор­ 
мацията за водача и втория водач не може да бъде 
изобразена едновременно, уредите за регистриране на 
данните за движението трябва да изобразяват по 
подразбиране информацията, отнасяща се за водача, и 
трябва да позволяват на потребителя да изобрази 
информацията относно втория водач.  
162) Когато широчината на изобразяването не е достатъчна 
за извеждане по подразбиране на режима на работа, 
уредите за регистриране на данните за движението 
трябва за кратко да изобразяват новия режим при 
всяка негова промяна.  
163) При вкарване на нова карта уредите за регистриране на 
данните за движението трябва да изобразяват за кратко 
време името на титуляря на картата.  
164) Когато е отворено условие „ИЗВЪН ОБСЕГ“ или 
„ПЪТУВАНЕ С ФЕРИБОТ/ВЛАК“, по подразбиране 
трябва да се изобрази съответната пиктограма, за да 
се укаже, че това конкретно условие е отворено 
(текущата активна дейност на водача може да не се 
изобразява в същото време).  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 59  
3.15.2  Изобразяване  на предупреждение  
165) Уредите за регистриране на данните за движението 
трябва да използват при предупрежденията най-вече 
пиктограмите, фигуриращи в допълнение 3, допълнени 
при нужда от информация под формата на цифров код. 
Може също така да се добави съобщение за пред­ 
упреждение на езика, избран от водача.  
3.15.3  Меню  за достъп  
166) Уредите за регистриране на данните за движението 
трябва да разполагат с необходимите команди чрез 
подходящо структурирано меню.  
3.15.4  Изобразяване  на други  данни  
167) При поискване трябва да бъде възможно избирателно 
показване на:  
— датата и часа по координираното универсално 
време, както и поправката за местното време,  
▼M3 
— съдържанието на която и да е от разпечатките, 
изброени в изискване 169 в същия формат както 
самата разпечатка,  
▼B 
— времето на непрекъснато управление на МПС и 
общото време на прекъсване от водача,  
— времето на непрекъснато управление на МПС и 
общото време на прекъсване от втория водач,  
▼M3 
— общото време на управление от водача за пред­ 
ишната и настоящата седмица,  
— общото време на управление от водача за пред­ 
ишната и настоящата седмица,  
▼B 
незадължително:  
— продължителността на текущата дейност на втория 
водач (от момента на нейното избиране),  
▼M3 
— общо време на управление на МПС на водача за 
настоящата седмица,  
— общото време на управление на МПС на втория 
водач за настоящия дневен работен период,  
— общото време на управление на МПС на втория 
водач за настоящия дневен работен период.  
▼B 
168) Изобразяването на съдържанието на разпечатката на 
хартия е последователно, ред по ред. Ако широчината 
на изобразяването е по-малка от 24 символа, потре­ 
бителят може да визуализира цялата информация чрез 
съответен способ (на няколко реда, изобразяване във 
вид на безконечен списък, …)  
При отпечатването върху хартия, редовете предвидени 
за ръчното изписване на информация, могат да бъдат 
изпуснати.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 60  
3.16 Отпечатване  
169) Уредите за регистриране на данните за движението 
трябва да могат да отпечатват информацията, записана 
в паметта им и/или върху тахографските карти в съот­ 
ветствие със следните разпечатки на хартия:  
— ежедневната разпечатка от картата за дейностите на 
водача,  
— ежедневната разпечатка от бордовото устройство за 
дейностите на водача,  
— разпечатката от картата за събитията и неизправ­ 
ностите,  
— разпечатката от бордовото устройство за събитията 
и неизправностите,  
— разпечатка за техническите данни,  
— разпечатка за превишаванията на скоростта.  
— предистория на данните върху тахографската карта 
за дадено бордово устройство (вж. глава 3.12.16)  
Подробностите относно формата и съдържанието на 
тези разпечатки са специфицирани в допълнение 4.  
В края на разпечатките може да фигурират допъл­ 
нителни данни.  
Уредите за регистриране на данните за движението 
могат също така да вадят и други разпечатки ако те 
са ясно различими от гореизброените седем разпечатки.  
170) „ежедневната разпечатка от картата за дейностите на 
водача“ и „разпечатката от картата за събитията и неиз­ 
правностите“ трябва да са достъпни само когато в 
уредите за регистриране на данните за движението е 
вкарана карта на водач или карта за монтаж и 
настройки. Уредите за регистриране на данните за 
движението актуализират данните, записани на 
въпросната карта, преди да стартира отпечатването.  
171) За да извадят „ежедневната разпечатка от картата за 
дейностите на водача“ и „разпечатката от картата за 
събитията и неизправностите“, уредите за регистриране 
на данните за движението трябва:  
— или да избират автоматично картата на водач, или 
картата за монтаж и настройки, ако е вкарана само 
една от тези карти,  
— или да имат команда, позволяваща избирането на 
картата-източник на данните, или да избират 
картата, поставена в процепа за карта на водач, 
ако са вкарани и двете карти.  
172) Печатащото устройство трябва да може да отпечатва 24 
символа на ред.  
173) Минималният размер на символите трябва да е 
височина 2,1 mm и широчина 1,5 mm.  
174) Печатащото устройство трябва да може да отпечатва 
символите, специфицирани в допълнение 1, глава 4, 
„Набори от символи“.  
175) Печатащите устройства трябва да са с такава 
конструкция, че тези разпечатки да са с ниво на разде­ 
лителна способност достатъчно, за да се избегне всяка 
двусмисленост при четенето им.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 61  
176) Разпечатките трябва да запазват размерите и съдър­ 
жанието си при нормалните условия на влажност (10- 
90 %) и температура.  
177) Хартията от одобрен тип, използвана от уредите за 
регистриране на данните за движението, трябва да 
бъде със съответен знак за одобрен тип и указание за 
типа/типовете уреди за регистриране на данните за 
движението, с който/които може да бъде използвана.  
178) Разпечатките трябва да остават четливи и разпоз­ 
наваеми при нормални условия на съхранение, 
изразени като светлинен интензитет, влажност и темпе­ 
ратура, в продължение на най-малко две години.  
179) Разпечатките трябва да отговарят минимум на специфи­ 
кациите за изпитване, определени в допълнение 9.  
180) Също така трябва да бъде възможно върху тези 
документи да се добавят бележки, написани на ръка, 
като например при подпис на водача.  
181) При свършване на хартията по време на разпечатване и 
след ново зареждане с хартия уредите за регистриране 
на данните за движението трябва да започват разпечат­ 
ването отначало или продължават от същото място, 
като осигуряват недвусмислена връзка с предишната 
разпечатана част.  
3.17 Предупреждения  
182) Уредите за регистриране на данните за движението 
трябва да предупреждават водача при откриване на 
някакво събитие и/или неизправност.  
183) Предупреждението относно прекъсване на електри­ 
ческото захранване може да бъде забавено до момента 
на възстановяване на захранването.  
184) Уредите за регистриране на данните за движението 
трябва да предупреждават водача 15 минути преди и 
по време на превишаването на максималното 
позволено време на непрекъснато управление на МПС.  
185) Предупрежденията трябва да бъдат визуални. Освен 
визуалните предупреждения може да се извършват и 
звукови предупреждения.  
186) Визуалните предупреждения трябва да бъдат ясно 
различими от потребителя, да се появяват в зрителното 
поле на водача и да бъдат четливи както през деня, така 
и през нощта.  
187) Визуалните предупреждения могат да бъдат вградени в 
уредите за регистриране на данните за движението, или 
да бъдат извън тях.  
188) В последния случай те трябва да са означени със 
символ „Т“.  
189) Предупрежденията трябва да са с продължителност не 
по-малка от 30 секунди, освен ако потребителят 
потвърди приемането им чрез натискане на един или 
няколко конкретни бутона на уредите за регистриране 
на данните за движението. Това първо потвърждаване 
на приемането на предупреждението не трябва да 
изтрива изобразяването на причината за предупреж­ 
дението, посочено в следващия параграф.  
190) Причината за съобщението трябва да бъде изобразена 
на уредите за регистриране на данните за движението и 
да остане видима докато потребителят потвърди 
приемането ѝ чрез конкретен бутон или команда на 
уредите за регистриране на данните за движението.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 62  
191) Може да има допълнителни предупреждения, при 
условие че те не объркват водачите по отношение на 
дефинираните по-горе.  
3.18 Изтегляне  на данни  към външни  носители  
192) Уредите за регистриране на данните за движението 
трябва да позволяват при поискване да се изтеглят 
данни, съхранени в паметта им или от карта на водач 
към външни носители през съединителя за калибриране/ 
изтегляне на данни. Уредите за регистриране на 
данните за движението трябва да актуализират 
данните, записани върху съответната карта, преди да 
започнат изтеглянето.  
▼M3 
193) Освен това като незадължителна функция уредите за 
регистриране на данните за движението могат при 
всички режими на работа да изтеглят данни 
посредством някакъв друг интерфейс към превозвач, 
чието разпознаване е потвърдено чрез този канал. В 
подобен случай за изтеглените данни важат правата за 
достъп, приложими в режим „превозвач“.  
▼B 
194) Изтеглянето на данни не трябва нито да променя, нито 
да изтрива записаните данни.  
195) Електрическият интерфейс за съединителя за калиб­ 
риране/изтегляне на данни е специфициран в 
допълнение 6.  
196) Протоколите за изтегляне на данни са специфицирани в 
допълнение 7.  
▼M3 
196a) Транспортното предприятие, което използва превозни 
средства, оборудвани с уреди за регистриране на 
данните за движението, отговарящи на изискванията 
на настоящото приложение и попадащи в обхвата на 
Регламент (ЕО) № 561/2006, гарантира, че всички 
данни се изтеглят от бордовото устройство и от 
картите на водачите.  
Максималният период, в рамките на който се изтеглят 
съответните данни, не надхвърля:  
— 90 дни за данните от бордовото устройство;  
— 28 дни за данните от картата на водач.  
196б) Транспортните предприятия съхраняват данните, 
изтеглени от бордовото устройство и картите на 
водачите, в продължение най-малко на дванадесет 
месеца след записването.  
▼B 
3.19 Връзка  от разстояние  за извършване  на целенасочени  пътни  
проверки  
197) Когато контактният ключ на превозното средство е в 
положение „ВКЛЮЧЕН“, бордовото устройство 
трябва да записва на всеки 60 секунди в устройството 
за връзка от разстояние най-новите данни, необходими 
за извършване на целенасочени пътни проверки. Тези 
данни трябва да са кодирани и с подпис, както е специ­ 
фицирано в допълнение 11 и допълнение 14.  
198) Данните, които се проверяват от разстояние, трябва да 
бъдат на разположение на четците за връзка от 
разстояние чрез безжична комуникация от разстояние, 
както е специфицирано в допълнение 14.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 63  
199) Данните, необходими за извършване на целенасочени 
пътни проверки, трябва да се отнасят за:  
— последния опит за нарушаване на сигурността,  
— най-дълго прекъсване на електрическото захранване,  
— неизправност на датчика,  
— грешка в данните за движението,  
— противоречие в данните за движението на 
превозното средство,  
— управление без валидна карта,  
— вкарване на карта по време на управление на МПС,  
— данни за сверяването на часовника,  
— данни за калибриране, включително датите на 
последните две записани калибрирания,  
— регистрационния номер на превозното средство,  
— скоростта, регистрирана от тахографа ,  
▼M3 
— местоположение на превозното средство,  
— индикация дали понастоящем водачът може да е в 
нарушение на времената на управление.  
3.20 Обмен  на данни  с допълнителни  външни  устройства  
200) Уредите за регистриране на данните за движението 
трябва също така да бъдат оборудвани с интерфейс с 
ITS в съответствие с допълнение 13, който да позволява 
регистрираните или генерираните данни от тахографа 
или от тахографските карти да се използват от 
външно устройство.  
В работен режим трябва да е необходимо съгласието на 
водача за предаването на лични данни чрез интерфейса 
с ITS. Въпреки това съгласието на водача не се прилага 
за данните от тахографа или картата за достъпа в режим 
„контрол“, „превозвач“ или „калибриране“. Правата за 
достъп до данните и до различните функции за тези 
режими са дадени в изисквания 12 и 13.  
За данните за ITS, предоставяни чрез същия интерфейс, 
важат следните изисквания:  
— лични данни се предоставят само след като е било 
дадено проверимото съгласие на водача, приемайки, 
че личните данни могат да напуснат мрежата на 
превозното средство.  
Набор от избрани съществуващи данни, който може 
да бъде на разположение чрез интерфейса с ITS, и 
класификацията на данните като лични или нелични 
са дадени в допълнение 13. Могат също така да 
бъдат на разположение и допълнителни данни, в 
допълнение на набора от данни, предвиден в 
допълнение 13. Производителят на бордовото 
устройство класифицира тези данни като „лични“ 
или „нелични“, при наличието на съгласие на 
водача, приложимо за данните, класифицирани 
като „лични“,  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 64  
— във всеки един момент, съгласието на водача може 
да бъде активирано или дезактивирано чрез команди 
от менюто, при условие че е вкарана картата на 
водач.  
— при всички обстоятелства, наличието на интерфейса 
с ITS не трябва да нарушава или да се отразява на 
правилната работа и сигурността на бордовото 
устройство.  
В бордовото устройство могат да съществуват 
съвместно допълни интерфейси, при условие че 
напълно съответстват на изискванията от допълнение 
13 по отношение на съгласието на водача. Уредът за 
регистриране на данните за движението трябва да 
може да съобщава статуса на съгласието на водача на 
други платформи в мрежата на превозното средство и 
на външни устройства.  
За постъпилите в мрежата на превозното средство 
лични данни, които след това се обработват извън 
мрежата на превозното средство, производителят на 
тахографа не носи отговорност това обработване да се 
извършва в съответствие с приложимото законода­ 
телство на Съюза за защитата на данните.  
Интерфейсът с ITS трябва също така да позволява 
въвеждане на данни по време на процедурата за 
ръчно въвеждане в съответствие с изискване 61 както 
за водача, така и за втория водач.  
Интерфейсът с ITS може също така да се използва за 
въвеждане на допълнителна информация в реално 
време, като например:  
— избор на дейността на водача в съответствие с 
изискване 46,  
— места в съответствие с изискванията 56,  
— специфични условия в съответствие с изискване 62,  
— товаро-разтоварни операции в съответствие с 
изискване 62а.  
Тази информация може също така да бъде въведена и 
чрез други интерфейси.  
201) Серийният ентерфейс, както е специфициран в 
приложение IБ към Регламент (ЕИО) № 3821/85, 
последно изменен, може да продължи да бъде наличен 
в тахографите с цел обратна съвместимост. Серийната 
връзка се класифицира като част от мрежата на 
превозното средство в съответствие с изискване 200.  
▼B 
3.21 Калибриране  
202) Функцията за калибриране трябва да позволява:  
— автоматичното сдвояване на датчика за движение с 
бордовото устройство,  
— автоматично свързване на външното устройство за 
GNSS с бордовото устройство, ако е приложимо,  
— цифрово адаптиране на константата (k) на уредите 
за регистриране на данните за движението към 
характеристичния коефициент на превозното 
средство (w),  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 65  
— коригиране на текущото време в рамките на срока 
на валидност на вкараната карта за монтаж и 
настройки,  
— коригиране на текущата стойност на километражния 
брояч,  
— актуализиране на данните за идентификация на 
датчика за движение, записани в паметта за данни,  
— ако е приложимо, актуализиране на данните за иден­ 
тификация на външното устройство за GNSS, 
записани в паметта за данни,  
— актуализиране на типовете и идентификаторите на 
всички поставени пломби,  
▼M3 
— актуализиране или потвърждаване на други 
параметри, известни на уредите за регистриране на 
данните за движението: идентификация на 
превозното средство, w, l, размер на гумите и 
настройка на ограничителя на скоростта, ако е 
приложимо, както и тип на товара по подразбиране,  
— автоматично съхраняване на държавата, в която е 
извършено калибрирането, както и датата и часа, в 
които местоположението, използвано за определяне 
на тази държава, са били подадени от приемника на 
сигнали от GNSS.  
▼B 
203) Освен това функцията за калибриране трябва да 
позволява потискане на използването на тахографски 
карти от първо поколение в уредите за регистриране 
на данните за движението, при положение че са 
изпълнени условията, формулирани в допълнение 15.  
204) Сдвояването на датчика за движение с бордовото 
устройство, трябва да се състои най-малкото във:  
— актуализиране на данните за монтирането на 
датчика за движение, намиращи се в него (при необ­ 
ходимост),  
— копиране от паметта за данни на датчика за 
движение в тази на бордовото устройство на необ­ 
ходимите данни за идентификация на датчика за 
движение.  
▼M3 
205) Свързването на външното устройство за GNSS с 
бордовото устройство се състои най-малкото в 
следното:  
— актуализиране на данните за монтирането на 
външното устройство за GNSS, намиращи се във 
външното устройство за GNSS (при необходимост),  
— копиране от външното устройство за GNSS към 
паметта за данни на бордовото устройство на необ­ 
ходимите данни за идентификация на външното 
устройство за GNSS, включително серийния му 
номер  
▼B 
206) Функцията за калибриране трябва да позволява въвеж­ 
дането на необходимите данни посредством съеди­ 
нителя за калибриране /изтегляне в съответствие с 
протокола за калибриране, дефиниран в допълнение 8. 
Функцията за калибриране може също така да 
позволява въвеждането на необходимите данни по 
други начини.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 66  
3.22 Пътна  проверка  на калибрирането  
207) Функцията за пътна проверка на калибрирането трябва 
да позволява прочитане на серийния номер на датчика 
за движение (евентуално намиращ се в адаптера) и 
серийния номер на външното устройство за GNSS 
(когато е приложимо), свързани към бордовото 
устройство към момента на поискването.  
208) Това прочитане трябва да бъде възможно поне на 
дисплея на бордовото устройство чрез команди от 
менюто.  
209) Функцията за пътна проверка на калибрирането трябва 
да позволява също управление на избора на входно- 
изходния режим на входно-изходната сигнална линия 
за калибриране, специфицирана в допълнение 6, 
посредством интерфейса на линията K. Това се 
извършва чрез ECUAdjustmentSession, както е специфи­ 
цирано в допълнение 8, раздел 7 „Управление на изпит­ 
вателните импулси — Функционален блок за 
управление на вход/изход“.  
▼M3 
Когато режимът вход/изход на линията за входни/ 
изходни сигнали за калибриране е активен съгласно 
това изискване, бордовото устройство не трябва да 
задейства предупреждението „Управление без 
подходяща карта“ (изискване 75).  
▼B 
3.23 Сверяване  на часовника  
210) Функцията за сверяване на часовника трябва да 
позволява автоматичното сверяване на текущото 
време. За сверяване на часовника, в уредите за регис­ 
триране на данните за движението се използват два 
времеви източника: 1) вътрешният часовник на БУ, 2) 
приемникът на сигнали от GNSS.  
▼M3 
211) Настройката на времето на вътрешния часовник на 
бордовото устройство трябва да се коригира автоматично 
на регулируеми интервали от време. Следващото авто­ 
матично коригиране на времето се задейства между 72 
ч. и 168 ч. след предходното и след като бордовото 
устройство може да получи достъп до времето на GNSS 
чрез валидно съобщение с удостоверена автентичност за 
местоположението в съответствие с допълнение 12. 
Въпреки това сверяването на часовника никога не 
трябва да е по-голямо от натрупаната максимална 
неточност на времето на ден, както е изчислена от произ­ 
водителя на бордовото устройство в съответствие с 
изискване 41б. Ако разликата между времето на 
вътрешния часовник на бордовото устройство и времето 
на приемника на сигнали от GNSS е по-голяма от натру­ 
паната максимална неточност на времето на ден, тогава 
сверяването на часовника трябва да направи вътрешния 
часовник на бордовото устройство възможно най-близък 
до времето на приемника на сигнали от GNSS. Наст­ 
ройката на времето може да се извърши само ако 
времето, предоставено от приемника на сигнали от 
GNSS, е получено чрез съобщения за местоположението 
с удостоверена автентичност, както е определено в 
допълнение 12. Еталонното време за автоматичната 
настройка на времето на вътрешния часовник на 
бордовото устройство е времето, дадено в съобщението 
за местоположението с удостоверена автентичност.  
212) Функцията за сверяване на часовника трябва също така 
да позволява предизвикано сверяване на текущото 
време в режим на калибриране.  
Сервизите могат да сверяват часовника:  
— или чрез записване на стойност за времето в 
бордовото устройство, като използват услугата 
WriteDataByIdentifier в съответствие с раздел 6.2 от 
допълнение 8,  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 67  
— или чрез заявка за сверяване на часовника на 
бордовото устройство с времето, предоставено от 
приемника на сигнали от GNSS. Това може да се 
направи само ако времето, предоставено от 
приемника на сигнали от GNSS, е получено чрез 
използване на съобщения за местоположението с 
удостоверена автентичност. В последния случай се 
използва услугата Routine Control в съответствие с 
раздел 8 от допълнение 8.  
▼B 
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) Уредите за регистриране на данните за движението 
трябва да отговарят на техническите спецификации, 
свързани с ергономичното проектиране.  
223) Уредите за регистриране на данните за движението 
трябва да бъдат защитени от случайни повреждания.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 68  
3.26 Маркировки  
224) Ако уредите за регистриране на данните за движението 
визуализират скоростта и километража на превозното 
средство, следните детайли трябва да бъдат изобразени:  
— до числото, указващо изминатото разстояние, 
мерната единица за разстояние, дадена със съкра­ 
щението „km“,  
— до числото, показващо скоростта, указанието 
„km/h“.  
Уредите за регистриране на данните за движението 
може също така да бъдат превключени да изобразяват 
скоростта в мили в час, като в този случай мерната 
единица за скоростта трябва да е указана със съкра­ 
щението „mph“. Уредите за регистриране на данните 
за движението може също така да бъдат превключени 
да изобразяват разстоянието в мили, като в този случай 
мерната единица за разстоянието трябва да е указана 
със съкращението „mi“.  
▼M1 
225) На всеки компонент, който е отделен от уредите за 
регистриране на данните за движението, трябва да се 
постави указателна табелка със следните данни:  
— наименование и адрес на производителя,  
— фабричен номер от производителя и година на 
производство,  
— сериен номер,  
— знак за одобрение на типа.  
226) Когато няма физическо място за всички горепосочени 
данни, указателната табелка трябва да указва най-малко 
следното: наименованието или логотипа на произ­ 
водителя и фабричния номер.  
▼M3 
3.27 Следене  на пресичането  на граници  
226a) Тази функция трябва да открива кога превозното 
средство е пресекло границата на държава, коя 
държава е била напусната и коя е държава на влизане.  
226б) Откриването на пресичане на граница е въз основа на 
местоположението, измерено от уредите за регис­ 
триране на данните за движението, и на съхранената 
цифрова карта в съответствие с точка 3.12.19.  
226в) Пресичания на граници, свързани с присъствие на 
превозното средство в дадена държава за период, по- 
кратък от 120s, не се записват.  
3.28 Актуализация  на софтуера  
226г) Бордовото устройство трябва да включва функция за 
извършване на актуализации на софтуера, когато тези 
актуализации не изискват наличието на допълнителни 
хардуерни ресурси, надхвърлящи ресурсите, 
определени в изискване 226е, и органите по одобряване 
на типа дават своето разрешение за актуализиране на 
софтуера на базата на съществуващото бордово 
устройство с одобрен тип, в съответствие с член 12, 
параграф 5 от Регламент (ЕС) № 165/2014.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 69  
226д) Функцията за актуализация на софтуера трябва да бъде 
проектирана така, че да поддържа следните 
функционални характеристики, когато те се изискват 
правно:  
— промяна на функциите, посочени в точка 2.2, с 
изключение на самата функция за актуализация на 
софтуера,  
— добавяне на нови функции, пряко свързани с прила­ 
гането на законодателството на Съюза в областта на 
автомобилния транспорт,  
— промяна на режимите на работа в точка 2.3,  
— промяна на структурата на файла, като например 
добавяне на нови данни или увеличаване на 
размера на файла,  
— привеждане в изпълнение на софтуерни корекции за 
отстраняване на дефекти както на софтуера, така и 
свързани със сигурността или с докладвани атаки 
срещу функциите на уредите за регистриране на 
данните за движението.  
226е) Бордовото устройство трябва да осигурява безплатни 
хардуерни ресурси от най-малко 35 % за софтуера и 
данните, необходими за изпълнението на изискване 
226д, както и безплатни хардуерни ресурси от най- 
малко 65 % за актуализацията на цифровата карта на 
базата на хардуерните ресурси, необходими за 
версията от 2021 г. на картата на ниво NUTS 0.  
▼B 
4 КОНСТРУКТИВНИ И ФУНКЦИОНАЛНИ ИЗИСКВАНИЯ ЗА 
ТАХОГРАФСКИТЕ КАРТИ  
4.1 Видими  данни  
Лицевата страна трябва да съдържа:  
227) думите „карта на водач“ или „контролна карта“ или 
„карта за монтаж и настройки“ или „карта на 
превозвач“, отпечатани с главни букви на 
официалния(ите) език(езици) на държавата членка, 
която е издала картата, според типа карта.  
228) наименованието на държавата членка, която издала 
картата (незадължително);  
229) отличителния знак на държавата членка, издала картата, 
отпечатан в бяло на син фон в правоъгълник, ограден 
от 12 жълти звезди. Отличителните знаци са както 
следва: 
B 
BG 
CZ 
CY Белгия 
България 
Чешка република 
Кипър  LV 
L 
LT 
M Латвия 
Люксембург 
Литва 
Малта  
DK Дания  N L  Нидерландия  
D 
EST Германия 
Естония  A 
PL Австрия 
Полша  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 70  
GR Гърция  P  
RO 
SK 
SLO  Португалия 
Румъния 
Словакия 
Словения  
E Испания  FIN  Финландия  
F 
HR 
H Франция 
Хърватия 
Унгария  S Швеция  
IRL Ирландия  U K  Обединено 
кралство  
I Италия  
230) информация, специфична за издадената карта, номе­ 
рирана както следва:  
Карта на водач  Контролна карта  Карта на превозвач или карта 
за монтаж и настройки  
1. фамилно име на водача  наименование на 
контролния орган  наименование на 
превозвача или на сервиза  
2. собствено(и) име(на) на 
водача  фамилно име на 
контрольора 
(ако е приложимо)  фамилно име на титуляря 
на картата 
(ако е приложимо)  
3. дата на раждане на 
водача  собствено(и) име(на) на 
контрольора 
(ако е приложимо)  собствено(и) име(на) на 
титуляря на картата 
(ако е приложимо)  
4.a дата на начало на валидността на картата  
4.б срок на валидност на картата  
4.в наименование на органа, който я е издал (може да се отпечата н а обратната 
страна)  
4.г номер, различен от указания в точка 5, по административни прич ини (незадъл­ 
жително)  
5.а Номер на свидетелството 
за управление на МПС 
(към датата на издаване 
на картата на водач)  — —  
5.б Номер на картата  
6. Снимка на водача  снимка на контрольора 
(незадължително)  снимка на монтьора (неза­ 
дължително)  
7. Подпис на титуляря (незадължително)  
8. Обичайно място на 
пребиваване или 
пощенски адрес на 
титуляря (незадъл­ 
жително)  Пощенски адрес на 
контролния орган  Пощенски адрес на 
превозвача или на сервиза  
231) датите трябва да са написани в следния формат „дд/ 
мм/гггг“ или „дд.мм. гггг“ (ден, месец, година).  
Обратната страна трябва да съдържа:  
232) легенда на номерираните позиции, налични върху 
лицевата страна на картата;  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 71  
233) с изрично писмено съгласие на титуляря на картата, 
може да бъде добавена и информация, която не е 
свързана с администрирането на картата, при 
положение че това добавяне не променя с нищо изпол­ 
зването на модела като тахографска карта.  
234) Преобладаващите цветове на фона при отпечатването 
на тахографските карти трябва да бъдат както следва:  
— карта на водач: бял,  
— контролна карта: син,  
— карта за монтаж и настройки: червен,  
— карта на превозвач: жълт.  
235) Тахографските карти трябва да имат следните елементи 
на защита на тялото на картата срещу подправяне и 
фалшифициране:  
— фон със защитни характеристики, включващ мотиви 
с плетеници (гилоши) от тънки линии и ирисов 
печат,  
— припокриване на фоновия защитен печат и на 
снимката,  
— поне една двуцветна линия с микропечат.
  
► (1) M1 
► (2) M3 
236) След консултация с Комисията държавите членки могат 
да добавят цветове или маркировки, като например 
националните символи и защитни елементи, без това 
да засяга другите разпоредби на настоящото 
приложение.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 72  
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 — 21.08.2023 — 003.001 — 73  
4.5 Записване  на данни  
За целите на настоящата точка,  
— часовете се регистрират с точност от една минута, освен ако 
не е предвидено друго,  
— стойностите от километражния брояч се регистрират с 
разделителна способност един километър,  
— скоростите се регистрират с разделителна способност 
1 km/h,  
— местоположенията (ширини и дължини) се регистрират в 
градуси и минути, с разделителна способност 1/10 от 
минутата.  
Функциите, командите и логическите структури на тахог­ 
рафските карти, които отговарят на изискванията относно 
записването на данните, са указани в допълнение 2.  
Ако не е предвидено друго, записването на данни върху тахог­ 
рафските карти трябва да бъде организирано по такъв начин, че 
новите данни да заместват най-старите записани данни, в 
случай че предвиденият размер за конкретните записи се 
изчерпа.  
245) В настоящия параграф се специфицира минималният 
капацитет за съхраняване на данни за различните 
файлове с данни на приложенията. Тахографските 
карти трябва да могат да указват на уредите за регис­ 
триране на данните за движението реалния капацитет за 
съхранение на тези файлове с данни.  
▼M3 
246) Върху тахографските карти могат да се съхраняват 
всякакви допълнителни данни, при условие че съхраня­ 
ването на тези данни е в съответствие с приложимото 
законодателство относно защитата на данните.  
▼B 
247) Всеки главен файл (MF) на която и да било тахографска 
карта трябва да съдържа до пет елементарни файла (EF) 
за управление на картата, идентификация на прило­ 
женията и на чипа, както и два специализирани 
файла (DF):  
— DF Tachograph, който съдържа приложението, 
достъпно за бордови устройства от първо 
поколение, присъстващо и в тахографските карти 
от първо поколение,  
— DF Tachograph_G2, който съдържа приложението, 
достъпно само за бордови устройства от второ 
поколение, присъстващо само в тахографските 
карти от второ поколение.  
▼M3 
Забележка: Версия 2 на картите от второ поколение 
съдържа в DF Tachograph_G2 допълнителни 
елементарни файлове.  
▼B 
Пълните подробности за структурата на тахографските 
карти, са специфицирани в допълнение 2.  
4.5.1  Елементарни  файлове  за идентификация  на управление  на 
картата  
4.5.2  Идентификация  на картите  с интегрална (и) схема (и) 
248) Тахографските карти трябва да могат да съхраняват 
следните данни за идентификация на карти с чип:  
— спиране на тактовия генератор,  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 74  
— сериен номер на картата (включително справочни 
данни за производството),  
— номер на одобрението на картата,  
— идентификация на организацията за персонали­ 
зиране на картата (ID),  
— идентификация на интегратора,  
— идентификатор на интегралната схема.  
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) Картата на водач трябва да позволява съхраняването на 
следните данни за идентификация на приложението:  
— идентификация на тахографското приложение,  
— идентификация на типа тахографска карта.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 75  
4.5.3.1.2 Ключ и сертификати  
254) Картата на водач трябва да позволява съхраняването 
определен брой криптографски ключове и сертификати, 
както е посочено в допълнение 11, част А.  
4.5.3.1.3 Идентификация на картата  
255) Картата на водач трябва да позволява съхраняването на 
следните данни за идентификация на картата:  
— номер на картата,  
— държава членка, издала картата, наименование на 
органа, който я е издал, дата на издаване,  
— дата на начало на валидността на картата, дата на 
край на валидността.  
4.5.3.1.4 Идентификация на титуляря на картата  
256) Картата на водач трябва да позволява съхраняването на 
следните данни за идентификация на титуляря на 
картата:  
— фамилно име на титуляря,  
— собствено(и) име(на) на титуляря,  
— дата на раждане,  
— предпочитан език.  
4.5.3.1.5 Изтегляне на данни от карта  
257) Картата на водач трябва да позволява съхраняването на 
следните данни относно изтеглянето на данни от нея:  
— дата и час на последното изтегляне на данни от 
картата (с цел, различна от извършването на 
контрол).  
258) Картата на водача трябва да позволява съхраняването 
на един такъв запис.  
4.5.3.1.6 Информация за свидетелството за управление  
259) Картата на водач трябва да позволява съхраняването на 
следните данни за свидетелството за управление:  
— държава членка, наименование на органа, който го е 
издал,  
— номер на свидетелството за управление (към датата 
на издаване на картата).  
4.5.3.1.7 Данни за събития  
За целите на настоящата подточка времето се регистрира с 
разделителна способност 1 секунда.  
260) Картата на водача трябва да позволява съхраняването 
на данните, свързани със следните събития, засечени от 
уредите за регистриране на данните за движението по 
времето, когато картата е вкарана:  
— Припокриване във времето (когато дадената карта е 
причина за събитието),  
— Вкарване на карта по време на управление на МПС 
(когато събитието засяга дадената карта),  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 76  
— Неправилно приключване на предишна сесия 
(когато събитието засяга дадената карта),  
— Прекъсване на електрическото захранване,  
— Грешка в данните за движението,  
— Опити за нарушаване на сигурността.  
261) Картата на водач трябва да позволява съхраняването на 
следните данни за тези събития:  
— Код на събитието,  
— Дата и час на начало на събитието (или на вкар­ 
ването на картата в случай, че в този момент 
събитието е било текущо),  
— Дата и час на край на събитието (или на изваж­ 
дането на картата в случай, че в този момент 
събитието е било текущо),  
— VRN и държава членка, извършила регистрацията 
на превозното средство, в което събитието е 
настъпило.  
Забележка : За събитието „Припокриване във времето“:  
— Датата и часът на началото на събитието трябва да 
съответстват на датата и часа на изваждане на 
картата от предишното превозно средство,  
— Датата и часът на края на събитието трябва да съот­ 
ветстват на датата и на часа на вкарването на 
картата в настоящото превозно средство,  
— Данните за превозното средство трябва да съот­ 
ветстват на настоящото превозно средство, в което 
събитието се е случило.  
Забележка : За събитието „Неправилно приключване на 
предишната сесия“:  
— Датата и часът на началото на събитието трябва да 
съответстват на датата и на часа на вкарването на 
картата, съответстващо на неправилно приклю­ 
чената сесия,  
— Датата и часът на края на събитието трябва да съот­ 
ветстват на датата и на часа на вкарването на 
картата за сесията, по време на която събитието е 
засечено (текуща сесия),  
— Данните за превозното средство трябва да съот­ 
ветстват на превозното средство, в което сесията 
не е била приключена правилно.  
262) Картата на водач трябва да позволява съхраняването на 
данните за шестте последни събития от всеки тип (т.е. 
36 събития).  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 77  
4.5.3.1.8 Данни за неизправностите  
За целите на настоящата подточка времето се регистрира с 
разделителна способност 1 секунда.  
263) Картата на водача трябва да позволява съхраняването 
на данните, свързани със следните неизправности, 
засечени от уредите за регистриране на данните за 
движението по времето, когато картата е била вкарана:  
▼M1 
— Неизправност на картата (когато неизправна е 
самата карта),  
▼B 
— Неизправност в уредите за регистриране на данните 
за движението.  
264) Картата на водач трябва да позволява съхраняването на 
следните данни за тези неизправности:  
— Код на неизправността,  
— Дата и час на начало на неизправността (или на 
вкарването на картата, в случай че неизправността 
е била текуща в този момент),  
— Дата и час на край на неизправността (или на изваж­ 
дането на картата, в случай че неизправността е 
била текуща в този момент),  
— VRN и държава членка, извършила регистрацията 
на превозното средство, в което се е появила неиз­ 
правността.  
265) Картата на водач трябва да позволява съхраняването на 
данните за дванайсетте последни неизправности от 
всеки тип (т.е. 24 неизправности).  
4.5.3.1.9 Данни за дейностите на водача  
266) Картата на водач трябва да позволява съхраняването на 
следните данни за всеки календарен ден, в който тя се 
използва, или в който водачът е въвел ръчно 
дейностите си:  
— датата;  
— брояч на присъствените дни (който се увеличава с 
една единица за всеки от тези календарни дни),  
— общо разстояние, изминато от водача през този ден,  
— статус на водача в 00:00 часа,  
— всякакви промени в дейността на водача и/или 
промени в обстановката при управление на МПС, 
и/или вкарване или изваждане на картата на водач:  
— състояние при управление на МПС (ЕКИПАЖ, 
САМ),  
— процеп (ВОДАЧ, ВТОРИ ВОДАЧ),  
— положение на картата (ВКАРАНА, 
НЕВКАРАНА),  
— дейност (управление на МПС, НА РАЗПО­ 
ЛОЖЕНИЕ, РАБОТА, ПРЕКЪСВАНЕ/ 
ПОЧИВКА),  
— час на промяната.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 78  
267) Паметта на картата на водач трябва да позволява съхра­ 
няването на данните за дейността на водача в 
продължение на най-малко 28 дни (средната дейност 
на водач се определя като 93 промени на дейността 
на ден).  
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) Картата на водач трябва да позволява съхраняването на 
следните данни относно превозното средство, в което е 
отворена текущата сесия:  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 79  
— дата и час на отваряне на сесията (тоест на вкарване 
на картата), с точност до една секунда,  
— VRN и държава членка, извършила регистрацията 
на превозното средство.  
4.5.3.1.13 Данни за контролните дейности  
274) Картата на водач трябва да позволява съхраняването на 
следните данни относно контролните дейности:  
— дата и час на извършения контрол,  
— номер на контролната карта, държава членка, която 
я е издала,  
— вид на проверката (изобразяване на данните и/или 
отпечатване и/или изтегляне на данни от БУ и/или 
изтегляне на данни от картата (виж забележката)),  
— изтеглен период, в случай на изтегляне,  
— VRN и държава членка, извършила регистрацията 
на превозното средство, в което е извършена 
проверката.  
Забележка : изтеглянето от картата се регистрира само 
ако се извърши чрез уреди за регистриране на данните 
за движението.  
275) Картата на водач трябва да позволява съхраняването на 
един такъв запис.  
4.5.3.1.14 Данни за специфични условия  
276) Картата на водач трябва да позволява съхраняването на 
следните данни, свързани със специфични условия, 
въведени докато картата е била вкарана (независимо в 
кой процеп):  
— дата и час на въвеждането,  
— тип на специфичното условие.  
277) Картата на водач трябва да позволява съхраняването 
минимум 56 такива записа.  
▼M3 
4.5.3.2 Т а х о г р а ф с к о п р и л о ж е н и е о т п о к о л  е н и е 2 ( н е е 
д о с т ъ п н о з а б о р д о в и у с т р о й с т в а о т п ъ р  в о 
п о к о л е н и е , д о с т ъ п н о е з а в е р с и я 1 и в е р  с и я 2 
н а б о р д о в и у с т р о й с т в а о т в т о р о п о к о л е  н и е )  
▼B 
4.5.3.2.1 Идентификация на приложенията  
278) Картата на водач трябва да позволява съхраняването на 
следните данни за идентификация на приложението:  
— Идентификация на тахографското приложение,  
— Идентификация на типа тахографска карта.  
▼M3 
4.5.3.2.1.1 Допълнителна идентификация на приложението (не е до стъпна 
за версия 1 на бордови устройства от второ поколение)  
278a) Картата на водач трябва да позволява съхраняването на 
данни за допълнителната идентификация на прило­ 
жението, приложими само за версия 2.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 80  
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) Картата на водач трябва да позволява съхраняването на 
следните данни за свидетелството за управление:  
— държава членка, наименование на органа, който го е 
издал,  
— номер на свидетелството за управление (към датата 
на издаване на картата).  
4.5.3.2.7 Данни за събития  
За целите на настоящата подточка времето се регистрира с 
разделителна способност 1 секунда.  
285) Картата на водач трябва да позволява съхраняване на 
данните, свързани със следните събития, засечени от 
уредите за регистриране на данните за движението по 
времето, когато картата е била вкарана:  
— Припокриване във времето (когато дадената карта е 
причина за събитието),  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 81  
— Вкарване на карта по време на управление на МПС 
(когато събитието засяга дадената карта),  
— Неправилно приключване на предишна сесия 
(когато събитието засяга дадената карта),  
— Прекъсване на електрическото захранване,  
— Грешка в комуникацията с устройството за връзка 
от разстояние,  
— Събитие „Липса на информация за местополо­ 
жението от приемник на сигнали от GNSS“  
— Грешка в комуникацията с външното устройство за 
GNSS  
— Грешка в данните за движението,  
— Противоречие в данните за движението на 
превозното средство  
— Опити за нарушаване на сигурността,  
— Времеви конфликт.  
286) Картата на водач трябва да позволява съхраняването на 
следните данни за тези събития:  
— Код на събитието,  
— Дата и час на начало на събитието (или на вкар­ 
ването на картата в случай, че събитието е било 
текущо за този момент),  
— Дата и час на край на събитието (или на изваж­ 
дането на картата в случай, че в този момент 
събитието е било текущо),  
— VRN и държава членка, извършила регистрацията 
на превозното средство, в което събитието е 
настъпило.  
Забележка : За събитието „Припокриване във времето“:  
— Датата и часът на началото на събитието трябва да 
съответстват на датата и часа на изваждане на 
картата от предишното превозно средство,  
— Датата и часът на края на събитието трябва да съот­ 
ветстват на датата и на часа на вкарването на 
картата в настоящото превозно средство,  
— Данните за превозното средство трябва да съот­ 
ветстват на настоящото превозно средство, в което 
събитието се е случило.  
Забележка : За събитието „Неправилно приключване на 
предишната сесия“:  
— Датата и часът на началото на събитието трябва да 
съответстват на датата и на часа на вкарването на 
картата, съответстващо на неправилно приклю­ 
чената сесия,  
— Датата и часът на края на събитието трябва да съот­ 
ветстват на датата и на часа на вкарването на 
картата за сесията, по време на която събитието е 
засечено (текуща сесия),  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 82  
— Данните за превозното средство трябва да съот­ 
ветстват на превозното средство, в което сесията 
не е била приключена правилно.  
▼M3 
287) Картата на водач трябва да позволява съхраняването на 
данните за 12-те последни събития от всеки тип (т.е. 
132 събития).  
▼B 
4.5.3.2.8 Данни за неизправностите  
За целите на настоящата подточка времето се регистрира с 
разделителна способност 1 секунда.  
288) Картата на водача трябва да позволява съхраняването 
на данните, свързани със следните неизправности, 
засечени от уредите за регистриране на данните за 
движението по времето, когато картата е била вкарана:  
▼M1 
— Неизправност на картата (когато неизправна е 
самата карта),  
▼B 
— Неизправност в уредите за регистриране на данните 
за движението.  
289) Картата на водач трябва да позволява съхраняването на 
следните данни за тези неизправности:  
— Код на неизправността,  
— Дата и час на начало на неизправността (или на 
вкарването на картата, в случай че неизправността 
е била текуща в този момент),  
— Дата и час на край на неизправността (или на изваж­ 
дането на картата, в случай че неизправността е 
била текуща в този момент),  
— VRN и държава членка, извършила регистрацията 
на превозното средство, в което се е появила неиз­ 
правността.  
▼M3 
290) Картата на водач трябва да позволява съхраняването на 
данните за 24-те последни грешки от всеки тип (т.е. 48 
грешки).  
▼B 
4.5.3.2.9 Данни за дейностите на водача  
291) Картата на водач трябва да позволява съхраняването на 
следните данни за всеки календарен ден, в който тя се 
използва, или в който водачът е въвел ръчно 
дейностите си:  
— датата;  
— брояч на присъствените дни (който се увеличава с 
една единица за всеки от тези календарни дни),  
— общо разстояние, изминато от водача през този ден,  
— статус на водача в 00:00 часа,  
— всякакви промени в дейността на водача и/или 
промени в обстановката при управление на МПС, 
и/или вкарване или изваждане на картата на водач:  
— състояние при управление на МПС (ЕКИП, 
САМ),  
— процеп (ВОДАЧ, ВТОРИ ВОДАЧ),  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 83  
— положение на картата (ВКАРАНА, 
НЕВКАРАНА),  
— дейност (управление на МПС, НА РАЗПО­ 
ЛОЖЕНИЕ, РАБОТА, ПРЕКЪСВАНЕ/ 
ПОЧИВКА).  
— час на промяната,  
▼M3 
292) Паметта на картата на водач трябва да позволява съхра­ 
няването на данните за дейността на водач в 
продължение на 56 дни (средната дейност на водач се 
определя за това изискване като 117 смени на дейности 
на ден).  
▼B 
293) Данните, изброени в изисквания 286, 289 и 291 трябва 
да бъдат съхранени по начин, позволяващ дейностите 
да бъдат открити по реда на тяхното настъпване, дори в 
случай на припокриване във времето.  
4.5.3.2.10 Данни за използваното превозно средство  
294) Картата на водач трябва да позволява съхраняването за 
всеки календарен ден, в който тя се използва, и за всеки 
период на използване на определено превозно средство 
през този ден (периодът на използване включва всички 
последователни цикли на вкарване/изваждане на 
картата в превозното средство, като се има предвид 
самата карта), следните данни:  
— дата и час на първото използване на превозното 
средство (т.е. първото вкарване на картата за този 
период на употреба на превозното средство, или 
00:00 часа, ако периодът на използване е протичал 
по това време),  
— стойност на километражния брояч на превозното 
средство в този момент на първо използване,  
— дата и час на последното използване на превозното 
средство (тоест последното изваждане на картата за 
този период на употреба на превозното средство, 
или 23:59 часа, ако периодът на използване е 
протичал по това време),  
— стойност на километражния брояч на превозното 
средство в този момент на последно използване,  
— VRN и държава членка, извършила регистрацията 
на превозното средство,  
— VIN на превозното средство.  
▼M3 
295) Картата на водач трябва да позволява съхраняването на 
200 такива записа.  
▼B 
4.5.3.2.11 Места и местоположения, където дневните периоди на р абота 
започват и/или завършват  
296) Картата на водач трябва да позволява съхраняването на 
следните данни относно местоположенията, където 
дневните периоди на работа започват и/или завършват, 
въведени от водача:  
— дата и час на въвеждането (или дата и час, свързани 
с въвеждането, когато то се извършва по време на 
процедурата по ръчно въвеждане),  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 84  
— типа на въвежданата информация (начало или край, 
условия на въвеждане на информацията),  
— въведените страна и област,  
— стойността от километражния брояч на превозното 
средство,  
— местоположението на превозното средство,  
— точността на ГНСС, датата и времето, когато е била 
определено местоположението.  
▼M3 
297) Паметта на картата на водач трябва да позволява съхра­ 
няването на 112 такива записа.  
▼B 
4.5.3.2.12 Данни за картовата сесия  
298) Картата на водач трябва да позволява съхраняването на 
следните данни относно превозното средство, в което е 
отворена текущата сесия:  
— дата и час на отваряне на сесията (тоест на вкарване 
на картата), с точност до една секунда,  
— VRN и държава членка, извършила регистрацията 
на превозното средство.  
4.5.3.2.13 Данни за контролните дейности  
299) Картата на водач трябва да позволява съхраняването на 
следните данни относно контролните дейности:  
— дата и час на извършения контрол,  
— номер на контролната карта, държава членка, която 
я е издала,  
— вид на проверката (изобразяване на данните и/или 
отпечатване и/или изтегляне на данни от БУ и/или 
изтегляне на данни от картата (виж забележката)),  
— изтеглен период, в случай на изтегляне,  
— VRN и държава членка, извършила регистрацията 
на превозното средство, в което е извършена 
проверката.  
Забележка : Изискванията за сигурност предполагат, че 
изтеглянето от картата се регистрира само ако се 
извърши чрез уреди за регистриране на данните за 
движението.  
300) Картата на водач трябва да позволява съхраняването на 
един такъв запис.  
4.5.3.2.14 Данни за специфични условия  
301) Картата на водач трябва да позволява съхраняването на 
следните данни, свързани със специфични условия, 
въведени докато картата е била вкарана (независимо в 
кой процеп):  
— дата и час на въвеждането,  
— тип на специфичното условие.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 85  
302) Картата на водач трябва да позволява съхраняването на 
112 такива записа.  
▼B 
4.5.3.2.15 Данни за използваните бордови устройства  
303) Картата на водач трябва да позволява съхраняването на 
следните данни, свързани с различните бордови 
устройства, в които е била използвана:  
— датата и часа на началото на периода на използване 
на превозното средство (т.е. първото вкарване на 
картата в бордовото устройство през периода),  
— наименование на производителя на бордовото 
устройство,  
— тип на бордовото устройство,  
— номер на версията на софтуера на бордовото 
устройство.  
▼M3 
304) Картата на водач трябва да позволява съхраняването на 
200 такива записа.  
▼M1 
4.5.3.2.16 Данни за местата за три часа общо управление на МПС  
305) Картата на водача трябва да позволява съхраняването 
на следните данни, свързани с местоположението на 
превозното средство, когато общото време на 
управление на МПС достигне кратно число на три часа:  
— дата и час, когато общото време на управление на 
МПС достигне кратно число на три часа,  
— местоположението на превозното средство,  
— точността на GNSS, датата и часа, когато е било 
определено местоположението,  
— стойността от километражния брояч на превозното 
средство.  
▼M3 
306) Картата на водач трябва да позволява съхраняването на 
336 такива записа.  
4.5.3.2.17 Статус на удостоверяването на местоположението, свър зано с 
местата, в които е началото и/или краят на дневните периоди на 
работа (не е достъпно за версия 1 на бордовите устройства от 
второ поколение)  
306 a) Картата на водач трябва да позволява съхраняването на 
допълнителни данни относно местата, където дневните 
периоди на работа започват и/или завършват, въведени 
от водача в съответствие с точка 4.5.3.2.11:  
— датата и часа на вписването, трябва да бъдат точно 
същите дата и време като съхранените в EF Places в 
DF Tachograph_G2,  
— флаг, указващ дали автентичността на местополо­ 
жението е удостоверена.  
306б) Паметта на картата на водач трябва да позволява съхра­ 
няването на 112 такива записа.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 86  
4.5.3.2.18 Статус на удостоверяването на местоположенията, в ко ито е 
достигнато три часа общо време на управление (не е 
достъпно за версия 1 на бордовите устройства от второ 
поколение)  
306в) Картата на водач трябва да позволява съхраняването на 
допълнителни данни, свързани с местоположението на 
превозното средство, където общото време на 
управление на превозното средство достигне кратно 
число на три часа в съответствие с точка 4.5.3.2.16:  
— датата и часа, когато общото време на управление 
достигне кратно число на три часа, които трябва да 
бъдат точно същите като датата и часа, съхранени в 
EF GNSS_Places в DF Tachograph_G2,  
— флаг, указващ дали автентичността на местополо­ 
жението е удостоверена.  
306г) Картата на водач трябва да позволява съхраняването на 
336 такива записа.  
4.5.3.2.19 Пресичане на граници (не е достъпно за версия 1 на б ордови 
устройства от второ поколение)  
306д) Картата на водач трябва да позволява съхраняването на 
следните данни, свързани с пресичането на границите, 
или при вкарването на карта в съответствие с изискване 
147б, или при вече вкарана карта:  
— държавата, която превозното средство напуска,  
— държавата, в която превозното средство влиза,  
— датата и часа, в които водачът е пресекъл границата:  
— местоположението на превозното средство при 
пресичането на границата,  
— точността на GNSS:  
— флаг, указващ дали автентичността на местополо­ 
жението е удостоверена,  
— стойността от километражния брояч на превозното 
средство.  
306е) Паметта на картата на водач трябва да позволява съхра­ 
няването на 1120 такива записа.  
4.5.3.2.20 Товаро-разтоварни операции (не е достъпно за версия 1 на 
бордови устройства от второ поколение)  
306ж) Картата на водач трябва да позволява съхраняването на 
следните данни, свързани с товаро-разтоварните 
операции:  
— тип на операцията (товарене, разтоварване или едно­ 
временно товарене и разтоварване),  
— датата и часът на товаро-разтоварната операция,  
— местоположението на превозното средство,  
— точността на GNSS, датата и часа, когато е било 
определено местоположението.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 87  
— флаг, указващ дали автентичността на местополо­ 
жението е удостоверена,  
— стойността от километражния брояч на превозното 
средство.  
306з) Картата на водач трябва да позволява съхраняването на 
1624 товаро-разтоварни операции.  
4.5.3.2.21 Вписвания за типа товарене (не е достъпно за версия 1 на 
бордови устройства от второ поколение)  
306и) Картата на водач трябва да позволява съхраняването на 
следните данни, свързани с типа на товара, автоматично 
въвеждани от бордовото устройство при всяко вкарване 
на картата:  
— въведения тип на товара (стоки или пътници),  
— дата и час на въвеждането.  
306й) Картата на водач трябва да позволява съхраняването на 
336 такива записа.  
4.5.3.2.22 Конфигурации на бордовото устройство (не са достъпни  за 
версия 1 на бордови устройства от второ поколение)  
306к) Картата на водач трябва да позволява съхраняването на 
специфичните тахографски настройки на титуляря на 
картата.  
306л) Капацитетът на картата на водач за съхраняване на 
специфичните тахографски настройки на титуляря на 
картата трябва да бъде 3072 байта.  
▼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) Картата за монтаж и настройки трябва да позволява 
съхраняването на следните данни относно идентифи­ 
кацията на картата:  
— номер на картата,  
— държава членка, издала картата, наименование на 
органа, който я е издал, дата на издаване,  
— дата на начало на валидността на картата, дата на 
край на валидността.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 88  
4.5.4.1.4 Идентификация на титуляря на картата  
311) Картата за монтаж и настройки трябва да позволява 
съхраняването на следните данни относно идентифи­ 
кацията на титуляря на картата:  
— наименование на сервиза,  
— адрес на сервиза,  
— фамилно име на титуляря,  
— собствено(и) име(на) на титуляря,  
— предпочитан език.  
4.5.4.1.5 Изтегляне на данни от карта  
312) Картата за монтаж и настройки трябва да позволява 
съхраняването на запис за изтеглянето на данни от 
картата по същия начин като картата на водач.  
4.5.4.1.6 Данни за калибрирането и сверяването на часовника  
313) Картата за монтаж и настройки трябва да позволява 
съхраняването на записи за калибрирания и/или 
сверявания на часовника, извършени когато картата е 
била вкарана в уред за регистриране на данните за 
движението.  
314) Всеки запис за калибриране трябва да позволява съхра­ 
няване на следните данни:  
— Цел на калибрирането (пускане, първо монтиране, 
монтиране, периодични технически прегледи),  
— Идентификация на превозното средство  
— Актуализирани или потвърдени параметри (w, k, l, 
размер на гумите, регулировка на ограничителя на 
скоростта, километражен брояч (стара и нова 
стойност), дата и час (стара и нова стойност)).  
— Идентификация на уредите за регистриране на 
данните за движението (фабричен и сериен номер 
на бордовото устройство, сериен номер на датчика 
за движение).  
315) Картата за монтаж и настройки трябва да позволява 
съхраняването на най-малко 88 такива записа.  
316) Картата за монтаж и настройки трябва да има брояч, 
указващ общия брой на калибриранията, извършени с 
картата.  
317) Картата за монтаж и настройки трябва да съдържа 
брояч, указващ общия брой на калибриранията, 
извършени от последното изтегляне на данни.  
4.5.4.1.7 Данни за събития и за неизправности  
318) Картата за монтаж и настройки трябва да позволява 
съхраняването на данни за събитията и неизправностите 
по същия начин като картата на водач.  
319) Картата за монтаж и настройки трябва да позволява 
съхраняването на трите последни събития от всеки 
тип (т.е. 18 събития) и на шестте последни неиз­ 
правности от всеки тип (т.е. 12 неизправности).  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 89  
4.5.4.1.8 Данни за дейностите на водача  
320) Картата за монтаж и настройки трябва да позволява 
съхраняването на данни за дейността на водача по 
същия начин като картата на водач.  
321) Картата за монтаж и настройки трябва да позволява 
съхраняването на данни за дейността на водача за 
най-малко 1 ден средна дейност на водача.  
4.5.4.1.9 Данни за използваното превозно средство  
322) Картата за монтаж и настройки трябва да позволява 
съхраняването на записи от данни за използваните 
превозни средства по същия начин като картата на 
водач.  
323) Картата за монтаж и настройки трябва да позволява 
съхраняването на най-малко 4 такива записа.  
4.5.4.1.10 Данни относно края и/или началото на дневните период и на 
работа  
324) Картата за монтаж и настройки трябва да позволява 
съхраняването на данни за началото и/или края на 
дневните периоди на работа по същия начин като 
картата на водача.  
325) Картата на водача трябва да позволява съхраняването 
на най-малко 3 двойки такива записи.  
4.5.4.1.11 Данни за картовата сесия  
326) Картата за монтаж и настройки трябва да позволява 
съхраняването на запис от данни за картова сесия по 
същия начин като картата на водач.  
4.5.4.1.12 Данни за контролните дейности  
327) Картата за монтаж и настройки трябва да позволява 
съхраняването на запис от данни за контролните 
дейности по същия начин като картата на водач.  
4.5.4.1.13 Данни за специфични условия  
328) Картата за монтаж и настройки трябва да позволява 
съхраняването на данни за специфични условия по 
същия начин като картата на водач.  
329) Картата за монтаж и настройки трябва да позволява 
съхраняването на най-малко 2 такива записа.  
▼M3 
4.5.4.2 Т а х о г р а ф с к о п р и л о ж е н и е о т п о к о л  е н и е 2 ( н е е 
д о с т ъ п н о з а б о р д о в и у с т р о й с т в а о т п ъ р  в о 
п о к о л е н и е , д о с т ъ п н о е з а в е р с и я 1 и в е р  с и я 2 
н а б о р д о в и у с т р о й с т в а о т в т о р о п о к о л е  н и е )  
▼B 
4.5.4.2.1 Идентификация на приложенията  
330) Картата за монтаж и настройки трябва да позволява 
съхраняването на следните данни за идентификация на 
приложението:  
— идентификация на тахографското приложение,  
— идентификация на типа тахографска карта.  
▼M3 
4.5.4.2.1.1 Допълнителна идентификация на приложението (не е до стъпна 
за версия 1 на бордови устройства от второ поколение)  
330 a) Картата за монтаж и настройки трябва да позволява 
съхраняването на данни за допълнителната иденти­ 
фикация на приложението, приложими само за версия 2.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 90  
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) Картата за монтаж и настройки трябва да позволява 
съхраняването на запис за изтеглянето на данни от 
картата по същия начин като картата на водач.  
4.5.4.2.6 Данни за калибрирането и сверяването на часовника  
336) Картата за монтаж и настройки трябва да позволява 
съхраняването на записи за калибрирания и/или 
сверявания на часовника, извършени когато картата е 
била вкарана в уред за регистриране на данните за 
движението.  
337) Всеки запис за калибриране трябва да позволява съхра­ 
няване на следните данни:  
— цел на калибрирането (пускане, първо монтиране, 
монтиране, периодични технически прегледи),  
— идентификация на превозното средство,  
— актуализирани или потвърдени параметри (w, k, l, 
размер на гумите, регулировка на ограничителя на 
скоростта, километражен брояч (стара и нова 
стойност), дата и час (стара и нова стойност)).  
— Идентификация на уредите за регистриране на 
данните за движението (фабричен и сериен номер 
на БУ, сериен номер на датчика за движение, 
сериен номер на устройството за връзка от 
разстояние, сериен номер на външното устройство 
за GNSS (ако е приложимо),  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 91  
— типове и идентификатори на всички поставени 
пломби,  
— способност на бордовото устройство да използва 
тахографски карти от първо поколение (може или 
не). 
▼M3 
338) Картата за монтаж и настройки трябва да позволява 
съхраняването на 255 такива записа.  
▼B 
339) Картата за монтаж и настройки трябва да има брояч, 
указващ общия брой на калибриранията, извършени с 
картата.  
340) Картата за монтаж и настройки трябва да съдържа 
брояч, указващ общия брой на калибриранията, 
извършени от последното изтегляне на данни.  
4.5.4.2.7 Данни за събития и за неизправности  
341) Картата за монтаж и настройки трябва да позволява 
съхраняването на данни за събитията и неизправностите 
по същия начин като картата на водач.  
342) Картата за монтаж и настройки трябва да позволява 
съхраняването на трите последни събития от всеки 
тип (т.е. 33 събития) и на шестте последни неиз­ 
правности от всеки тип (т.е. 12 неизправности).  
4.5.4.2.8 Данни за дейностите на водача  
343) Картата за монтаж и настройки трябва да позволява 
съхраняването на данни за дейността на водача по 
същия начин като картата на водач.  
▼M3 
344) Картата за монтаж и настройки трябва да позволява 
съхраняването на данни за дейността на водача за 1 
ден, съдържащ 240 смени на дейности.  
▼B 
4.5.4.2.9 Данни за използваното превозно средство  
345) Картата за монтаж и настройки трябва да позволява 
съхраняването на записи от данни за използваните 
превозни средства по същия начин като картата на 
водач.  
▼M3 
346) Картата за монтаж и настройки трябва да позволява 
съхраняването на 8 такива записа.  
4.5.4.2.10 Данни за места и местоположения, където дневните пер иоди на 
работа започват и/или завършват  
347) Картата за монтаж и настройки трябва да позволява 
съхраняването на записи за местата и местополо­ 
женията, където дневните периоди на работа започват 
и/или завършват, по същия начин като картата на 
водач.  
348) Картата за монтаж и настройки трябва да позволява 
съхраняването на 4 двойки такива записи.  
▼B 
4.5.4.2.11 Данни за картовата сесия  
349) Картата за монтаж и настройки трябва да позволява 
съхраняването на запис от данни за картова сесия по 
същия начин като картата на водач.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 92  
4.5.4.2.12 Данни за контролните дейности  
350) Картата за монтаж и настройки трябва да позволява 
съхраняването на запис от данни за контролните 
дейности по същия начин като картата на водач.  
4.5.4.2.13 Данни за използваните бордови устройства  
351) Картата за монтаж и настройки трябва да позволява 
съхраняването на следните данни, свързани с 
различните бордови устройства, в които е била 
използвана:  
— датата и часа на началото на периода на използване 
на превозното средство (т.е. първото вкарване на 
картата в бордовото устройство през периода),  
— наименование на производителя на бордовото 
устройство,  
— тип на бордовото устройство,  
— номер на версията на софтуера на бордовото 
устройство.  
▼M3 
352) Картата за монтаж и настройки трябва да позволява 
съхраняването на 8 такива записа.  
▼M1 
4.5.4.2.14 Данни за местата за три часа общо управление на МПС  
353) Картата за монтаж и настройки трябва да позволява 
съхраняването на следните данни, свързани с местопо­ 
ложението на превозното средство, когато общото 
време на управление на МПС достигне кратно число 
на три часа:  
— дата и час, когато общото време на управление на 
МПС достигне кратно число на три часа,  
— местоположението на превозното средство,  
— точността на GNSS, датата и часа, когато е било 
определено местоположението,  
— стойността от километражния брояч на превозното 
средство.  
▼M3 
354) Картата за монтаж и настройки трябва да позволява 
съхраняването на 24 такива записа.  
▼B 
4.5.4.2.15 Данни за специфични условия  
355) Картата за монтаж и настройки трябва да позволява 
съхраняването на данни за специфични условия по 
същия начин като картата на водач.  
▼M3 
356) Картата за монтаж и настройки трябва да позволява 
съхраняването на 4 такива записа.  
4.5.4.2.16 Статус на удостоверяването на местоположението, свър зано с 
местата, в които е началото и/или краят на дневните периоди на 
работа (не е достъпно за версия 1 на бордовите устройства от 
второ поколение)  
356a) Картата за монтаж и настройки трябва да позволява 
съхраняването на допълнителни данни относно 
началото и/или края на дневните периоди на работа 
по същия начин като картата на водач.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 93  
356б) Паметта на картата за монтаж и настройки трябва да 
позволява съхраняването на 4 двойки такива записи.  
4.5.4.2.17 Статус на удостоверяването на местоположенията, в ко ито е 
достигнато три часа общо време на управление (не е 
достъпно за версия 1 на бордовите устройства от второ 
поколение)  
356в) Картата за монтаж и настройки трябва да позволява 
съхраняването на допълнителни данни, свързани с 
местоположението на превозното средство, където 
общото време на управление на превозното средство 
достигне кратно число на три часа.  
356г) Картата за монтаж и настройки трябва да позволява 
съхраняването на 24 такива записа.  
4.5.4.2.18 Пресичане на граници (не е достъпно за версия 1 на б ордови 
устройства от второ поколение)  
356д) Картата за монтаж и настройки трябва да позволява 
съхраняването на данни за пресичането на граници по 
същия начин като картата на водач.  
356е) Паметта на картата за монтаж и настройки трябва да 
позволява съхраняването на 4 такива записа.  
4.5.4.2.19 Товаро-разтоварни операции (не е достъпно за версия 1 на 
бордови устройства от второ поколение)  
356ж) Картата за монтаж и настройки трябва да позволява 
съхраняването на данни за товаро-разтоварните 
операции по същия начин като картата на водач.  
356з) Картата за монтаж и настройки трябва да позволява 
съхраняването на 8 операции по товарене, разтоварване 
или едновременно товарене и разтоварване.  
4.5.4.2.20 Вписвания за типа товарене (не е достъпно за версия 1 на 
бордови устройства от второ поколение)  
356и) Картата за монтаж и настройки трябва да позволява 
съхраняването на данни за типа на товара по същия 
начин като картата на водач.  
356й) Картата за монтаж и настройки трябва да позволява 
съхраняването на 4 такива записа.  
4.5.4.2.21 Допълнителни данни за калибрирането (не е достъпно з а версия 
1 на бордови устройства от второ поколение)  
356к) Картата за монтаж и настройки трябва да позволява 
съхраняването на данни за допълнителното калиб­ 
риране, приложими само за версия 2.  
— старата дата и час и идентификационния номер на 
превозното средство, които трябва да бъдат точно 
същите като тези, съхранени в EF Calibration в DF 
Tachograph_G2,  
— тип на товара по подразбиране, въведен по време на 
това калибриране,  
— държавата, в която е извършено калибрирането, 
както и датата и часът, в които местоположението, 
използвано за определяне на тази държава, са били 
дадени от приемника на сигнали от GNSS.  
356л) Картата за монтаж и настройки трябва да позволява 
съхраняването на 255 такива записа.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 94  
4.5.4.2.22 Конфигурации на бордовото устройство (не са достъпни  за 
версия 1 на бордови устройства от второ поколение)  
356м) Картата за монтаж и настройки трябва да позволява 
съхраняването на специфичните тахографски 
настройки на титуляря на картата.  
356н) Капацитетът на картата за монтаж и настройки за 
съхраняване на специфичните тахографски настройки 
на титуляря на картата трябва да бъде 3072 байта.  
▼B 
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) Контролната карта трябва да позволява съхраняването 
на следните данни за контролните дейности:  
— дата и час на извършената проверка,  
▼M3 
— тип на контрола (изобразяване на данните и/или 
отпечатване, и/или изтегляне на данни от 
бордовото устройство, и/или изтегляне на данни от 
картата),  
▼B 
— изтеглен период (ако има такъв),  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 95  
— VRN и орган на държавата членка, регистрирал 
проверяваното превозно средство,  
— номер на проверяваната карта на водач и държава 
членка, която я е издала.  
362) Контролната карта трябва да позволява съхраняването 
на най-малко 230 такива записи.  
4.5.5.2 Т а х о г р а ф с к о п р и л о ж е н и е о т п о к о л  е н и е 2 ( н е е 
д о с т ъ п н о з а б о р д о в о у с т р о й с т в о о т п ъ р  в о 
п о к о л е н и е )  
4.5.5.2.1 Идентификация на приложенията  
363) Контролната карта трябва да позволява съхраняването 
на следните данни за идентификация на приложението:  
— идентификация на тахографското приложение,  
— идентификация на типа тахографска карта.  
▼M3 
4.5.5.2.1.1 Допълнителна идентификация на приложението (не е до стъпна 
за версия 1 на бордови устройства от второ поколение)  
363 a) Контролната карта трябва да позволява съхраняването 
на данни за допълнителната идентификация на прило­ 
жението, приложими само за версия 2.  
▼B 
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) Контролната карта трябва да позволява съхраняването 
на следните данни за контролните дейности:  
— дата и час на извършената проверка,  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 96  
— вид на проверката (изобразяване на данните и/или 
отпечатване върху хартия и/или изтегляне на данни 
от бордовото устройство и/или изтегляне на данни 
от картата и/или пътна проверка на калибрирането)  
— изтеглен период (ако има такъв),  
— VRN и орган на държавата членка, регистрирал 
проверяваното превозно средство,  
— номер на проверяваната карта на водач и държава 
членка, която я е издала.  
368) Контролната карта трябва да позволява съхраняването 
на най-малко 230 такива записи.  
▼M3 
4.5.5.2.6 Конфигурации на бордовото устройство (не са достъпни за 
версия 1 на бордови устройства от второ поколение)  
368a) Контролната карта трябва да позволява съхраняването 
на специфичните тахографски настройки на титуляря на 
картата.  
368б) Капацитетът на контролната карта за съхраняване на 
специфичните тахографски настройки на титуляря на 
картата трябва да бъде 3072 байта.  
▼B 
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) Картата на превозвач трябва да позволява съхраня­ 
ването на следните данни за идентифицирането на 
титуляря на картата:  
— наименование на превозвача,  
— адрес на превозвача.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 97  
4.5.6.1.5 Данни относно дейността на предприятието  
373) Картата на превозвач трябва да позволява съхраня­ 
ването на следните данни за дейностите на превозвача:  
— дата и час на дейността,  
— тип на дейността (блокиране и/или разблокиране на 
бордовото устройство, изтегляне на данни от 
бордовото устройство и/или от картата)  
— изтеглен период (ако има такъв),  
— VRN и орган на държавата членка, извършил 
регистрацията на превозното средство,  
— номер на картата и държава членка, която я е издала 
(при изтегляне на данни от картата).  
374) Картата на превозвач трябва да позволява съхраня­ 
ването на най-малко 230 такива записа.  
4.5.6.2 Т а х о г р а ф с к о п р и л о ж е н и е о т п о к о л  е н и е 2 ( н е е 
д о с т ъ п н о з а б о р д о в о у с т р о й с т в о о т п ъ р  в о 
п о к о л е н и е )  
4.5.6.2.1 Идентифициране на приложенията  
375) Картата на превозвач трябва да позволява съхраня­ 
ването на следните данни за идентификация на прило­ 
жението:  
— идентификация на тахографското приложение,  
— идентификация на типа на тахографската карта.  
▼M3 
4.5.6.2.1.1 Допълнителна идентификация на приложението (не е до стъпна 
за версия 1 на бордови устройства от второ поколение)  
375 a) Картата на превозвач трябва да позволява съхраня­ 
ването на данни за допълнителната идентификация на 
приложението, приложими само за версия 2.  
▼B 
4.5.6.2.2 Ключове и сертификати  
376) Картата на превозвач трябва да позволява съхраня­ 
ването определен брой криптографски ключове и серти­ 
фикати, както е посочено в допълнение 11, част Б.  
4.5.6.2.3 Идентифициране на картата  
377) Картата на превозвач трябва да позволява съхраня­ 
ването на следните данни за идентифицирането на 
картата:  
— номер на картата,  
— държава членка, издала картата, наименование на 
органа, който я е издал, дата на издаване,  
— дата на начало на валидността на картата, дата на 
край на валидността (ако има).  
4.5.6.2.4 Идентифициране на титуляря на картата  
378) Картата на превозвач трябва да позволява съхраня­ 
ването на следните данни за идентифицирането на 
титуляря на картата:  
— наименование на превозвача,  
— адрес на превозвача.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 98  
4.5.6.2.5 Данни за дейността на предприятието  
379) Картата на превозвач трябва да позволява съхраня­ 
ването на следните данни за дейностите на превозвача:  
— дата и час на дейността,  
— тип на дейността (блокиране и/или разблокиране на 
бордовото устройство, изтегляне на данни от 
бордовото устройство и/или от картата)  
— изтеглен период (ако има такъв),  
— VRN и орган на държавата членка, извършил 
регистрацията на превозното средство,  
— номер на картата и държава членка, която я е издала 
(при изтегляне на данни от картата).  
380) Картата на превозвач трябва да позволява съхраня­ 
ването на най-малко 230 такива записа.  
▼M3 
4.5.6.2.6 Конфигурации на бордовото устройство (не са достъпни за 
версия 1 на бордови устройства от второ поколение)  
380 a) Картата на превозвач трябва да позволява съхраня­ 
ването на специфичните тахографски настройки на 
титуляря на картата.  
380б) Капацитетът на картата на превозвач за съхраняване на 
специфичните тахографски настройки на титуляря на 
картата трябва да бъде 3072 байта.  
▼B 
5 МОНТИРАНЕ НА УРЕДИ ЗА РЕГИСТРИРАНЕ НА ДАННИТЕ 
ЗА ДВИЖЕНИЕТО  
5.1 Монтиране  
381) Новите уреди за регистриране на данните за 
движението се доставят неактивирани на монтьорите 
или на производителите на превозното средство, 
заедно с всички параметри на калибрирането, фигу­ 
риращи в списъка на глава 3.21, настроени на 
подходящи и валидни стойности по подразбиране. 
Когато не е подходяща никаква определена стойност, 
за буквените параметри се задават низове от „?“, а за 
числените параметри се задава „0“). Доставянето на 
важни за сигурността части на уредите за регистриране 
на данните за движението може да бъде ограничено ако 
това е необходимо по време на сертифицирането за 
сигурност.  
382) Преди своето активиране уредите за регистриране на 
данните за движението трябва да дадат достъп до 
функцията за калибриране, дори и да не са в режим 
на калибриране.  
▼M3 
383) Преди своето активиране уредите за регистриране на 
данните за движението не трябва нито да регистрират, 
нито да записват данни, посочени в изисквания 
102—133 включително. Независимо от това, преди 
своето активиране уредите за регистриране на данните 
за движението могат да записват и съхраняват събития, 
представляващи опит за нарушаване на сигурността, в 
съответствие с изискване 117, както и неизправностите 
на уредите за регистриране на данните за движението в 
съответствие с изискване 118.  
▼B 
384) По време на монтирането производителите на 
превозното средство трябва да настроят предварително 
всички известни параметри.  
385) Производителите на превозното средство или 
монтьорите трябва да активират монтираните уреди за 
регистриране на данните за движението най-късно 
преди да започне използването на превозното средство 
в обхвата на Регламент (ЕО) № 561/2006.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 99  
386) Активирането на уредите за регистриране на данните за 
движението трябва да се задейства автоматично при 
първото вкарване на карта за монтаж и настройки в 
кое да е от интерфейсните устройства за карта.  
387) Специфичните действия по свързването на датчика за 
движение с бордовото устройство, ако има такива, 
трябва да се извършват автоматично преди или по 
време на активирането.  
388) По подобен начин специфични действия по свързването 
на външното устройство за GNSS с бордовото 
устройство, ако има такива, трябва да се извършват 
автоматично преди или по време на активирането.  
389) След активирането си уредите за регистриране на 
данните за движението трябва да приложат в пълна 
степен контрол върху достъпа до функциите и данните.  
390) След активирането си уредите за регистриране на 
данните за движението трябва да съобщят на устрой­ 
ството за връзка от разстояние защитените данни, необ­ 
ходими за целите на целенасочените пътни проверки.  
391) Регистриращите и записващите функции на уредите за 
регистриране на данните за движението трябва да бъдат 
напълно действащи след активирането.  
▼M3 
392) Монтирането трябва да бъде последвано от калиб­ 
риране. Не е задължително първоначалното калиб­ 
риране да включва въвеждане на регистрационната 
идентификация на превозното средство (VRN и 
държавата членка), когато тази информация не е 
известна на одобрения сервиз, който трябва да 
извърши това калибриране. При такива обстоятелства 
и само по това време собственикът на превозното 
средство трябва да може да въведе регистрационния 
номер на превозното средство (VRN) и държавата 
членка, като използва своята карта на превозвач, 
преди да започне използването на превозното средство 
в обхвата на Регламент (ЕО) № 561/2006 (напр. чрез 
използване на команди посредством подходяща 
структура от менюта в интерфейса „човек — машина“ 
на бордовото устройство). Актуализирането или 
потвърждаването на това въвеждане трябва да е 
възможно само с използване на карта за монтаж и 
настройки.  
▼B 
393) За монтирането на външно устройство за GNSS е необ­ 
ходимо свързване с бордовото устройство и последваща 
проверка на информацията за местоположението от 
GNSS.  
394) Уредите за регистриране на данните за движението 
трябва да бъдат разположени така в превозното 
средство, че водачът да има достъп до необходимите 
функции от седалката си.  
5.2 Монтажна  табелка  
395) ►M3 След като монтираните уреди за регистриране на 
данните за движението бъдат проверени, е необходимо 
върху уредите да се прикрепи монтажна табелка 
(гравирана или отпечатана неизтриваемо), която да е 
добре видима и лесно достъпна. В случаи, когато това 
не е възможно, табелката трябва да се прикрепи към 
средната колона на автомобилната каросерия, така че 
да е добре видима. За превозни средства, които нямат 
средна колона на каросерията, монтажната табелка 
следва да бъде прикрепена в зоната на вратата на 
превозното средство и във всички случаи да бъде 
добре видима. ◄  
След всяко инспектиране от страна на лицензиран 
монтьор или сервиз, на мястото на старата табелка се 
поставя нова такава.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 100  
396) Табелката трябва да съдържа най-малко следните 
данни:  
— име и адрес или търговско наименование на 
одобрения монтьор или сервиз,  
— характеристичен коефициент на превозното 
средство, във вида „w = … импулса/km“,  
— константа на уредите за регистриране на данните за 
движението, във вида „k = … импулса/km“,  
— действителна обиколка на колелата с гумите, във 
вида „l = … mm“,  
— размер на гумите,  
— датата, на която са измерени характеристичният 
коефициент на превозното средство и действи­ 
телната обиколка на колелата с гумите,  
— идентификационния номер на превозното средство,  
— наличието (или не) на външно устройство за GNSS,  
— серийния номер на външното устройство за GNSS, 
ако има такова,  
▼M3 
— серийния номер на устройството за връзка от 
разстояние, ако има такова,  
▼M1 
— серийния номер на всички поставени пломби,  
— частта на превозното средство, на която е монтиран 
адаптерът, ако има такъв,  
— частта на превозното средство, на която е монтиран 
датчикът за движение, ако не е свързан с предава­ 
телната кутия или не се използва адаптер,  
— описание на цвета на кабела между адаптера и 
частта на превозното средство, която изработва 
входящите за адаптера импулси,  
— серийния номер на вградения в адаптера датчик за 
движение,  
▼M3 
— типа на товара по подразбиране, свързан с 
превозното средство,  
▼B 
397) Само за превозни средства от категории M1 и N1, 
които са оборудвани с адаптер в съответствие с 
Регламент (ЕО) № 68/2009 на Комисията (  1 ) с 
последните му изменения, и когато не е възможно да 
се включи цялата необходима информация, както е 
описано в изискване 396, може да се използва втора, 
допълнителна табелка. В такива случаи тази допъл­ 
нителна табелка трябва да съдържа поне информацията 
съгласно последните четири тирета от изискване 396.  ▼M1 
( 1 ) Регламент (ЕО) № 68/2009 на Комисията от 23 януари 2009 годин а за адаптиране 
за девети път към техническия прогрес на Регламент (ЕИО) № 3821 /85 на Съвета 
относно контролните уреди за регистриране на данните за движени ето при авто­ 
мобилен транспорт (ОВ L 21, 24.1.2009 г., стр. 3).
 02016R0799 — BG — 21.08.2023 — 003.001 — 101  
Ако се използва втора, допълнителна табелка, тя трябва 
да бъде поставена близо до първата основна табелка, 
описана в изискване 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.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 102  
Тази маркировка не трябва да закрива идентифика­ 
ционния номер на пломбата.  
▼M1 
403) След като сертифицират даден модел пломба по 
стандарт EN 16882:2016, производителите на пломби 
трябва да се регистрират в специална база данни и 
публично да оповестят своите идентификационни 
номера на пломби чрез процедура, която ще се 
определи от Европейската комисия.  
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
 02016R0799 — BG — 21.08.2023 — 003.001 — 103  
6.3 Проверка  на монтирането  
▼M1 
408) При монтирането в превозното средство всички 
монтирани компоненти (включително уредите за регис­ 
триране на данните за движението) трябва да отговарят 
на разпоредбите относно максималните толеранси, 
определени в глави 3.2.1, 3.2.2, 3.2.3 и 3.3. Всички 
монтирани компоненти трябва да бъдат пломбирани в 
съответствие с глава 5.3, като монтажът трябва да 
включва и калибриране.  
▼B 
6.4 Периодични  технически  прегледи  
▼M3 
409) Извършват се периодични технически прегледи на 
уредите, монтирани на превозните средства, след 
всеки ремонт на оборудването или след всяка промяна 
на характеристичния коефициент на превозното 
средство или на действителната обиколка на 
търкаляне на гумите, или когато часовникът, показващ 
координираното универсално време, е неточен с повече 
от 5 минути, или когато е променен регистрационният 
номер, или най-малко един път на всеки две години (24 
месеца) от последния преглед.  
▼B 
410) Тези прегледи трябва да включват следните проверки:  
— за правилно функциониране на уредите за регис­ 
триране на данните за движението, включително 
функцията за записване на данни в тахографските 
карти и комуникацията с четците за връзка с цел 
ранно откриване от разстояние.  
— че е осигурено съответствие с разпоредбите на глава 
3.2.1 и III.2.2 относно максималните толеранси при 
монтиране,  
— че е осигурено съответствие с разпоредбите на глава 
3.2.3 и 3.3,  
— че уредите за регистриране на данните за 
движението имат знак за одобрение на типа,  
— че монтажната табелка, както е определено с 
изискване 396, и указателната табелка, както е 
определено с изискване 225, са поставени,  
— на размера на гумите и действителната обиколка на 
гумите,  
— за отсъствие на устройства за манипулиране, 
прикрепени към уредите,  
— че пломбите са правилно поставени, в добро 
състояние, техните идентификационни номера са 
валидни (производител на пломбите с позоваване 
на базата данни на ЕК) и че техните идентифика­ 
ционни номера съответстват на маркировките върху 
монтажната табела (вж. изискване 401).  
▼M3 
— че идентификаторът на версията на съхранената 
цифрова карта е на последната версия.  
410a) В случай на откриване от компетентните национални 
органи на манипулация, превозното средство може да 
бъде изпратено на упълномощен сервиз за повторно 
калибриране на уредите за регистриране на данните за 
движението.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 104  
411) Ако за едно от събитията, изброени в глава 3.9 
(„Откриване на събития и/или неизправности“), е уста­ 
новено, че се е случило след последното инспектиране, 
и то се счита от производителите на тахографи и/или от 
националните органи за потенциално излагащо на риск 
сигурността на уредите, сервизът трябва:  
а. да извърши съпоставка на данните за идентификация 
на датчика за движение от свързания към предава­ 
телната кутия датчик за движение, с тези от сдвоения 
датчик за движение, регистриран в бордовото 
устройство.  
б. да провери дали информацията, записана върху 
монтажната табелка, съответства на информацията, 
съдържаща се в записа от бордовото устройство;  
в. да провери дали серийният номер на датчика за 
движение и номерът на одобрението му, ако са отпе­ 
чатани върху корпуса на датчика за движение, съот­ 
ветстват на информацията, записана в паметта за 
данни на бордовото устройство;  
г. да сравни идентификационните данни, отбелязани 
върху указателната табелка на външното устройство 
за GNSS, ако има такова, с тези, записани в паметта 
за данни на бордовото устройство;  
412) Сервизите трябва да записват в своите протоколи от 
проверки всички констатации относно счупени пломби 
или за устройства за манипулиране. Тези протоколи 
трябва да се съхраняват от сервизите поне две години 
и да се предоставят на компетентния орган при всяко 
поискване.  
413) Тези проверки трябва да включват калибриране и 
превантивна замяна на пломбите, за чието монтиране 
са отговорни сервизите..  
6.5 Измерване  на грешките  
414) Измерването на грешките при монтирането и по време 
на използването трябва да се осъществява при следните 
условия, които се разглеждат като стандартни условия 
на изпитване:  
— превозно средство без товар, в готовност за 
движение,  
— налягане в гумите в съответствие с указанията на 
производителя,  
— износване на гумите в границите, разрешени от 
националното законодателство,  
— движение на превозното средство:  
— превозното средство трябва да се движи напред под 
действие на собствения си двигател, по права линия 
и върху равна повърхност със скорост 50 ± 5 km/h. 
Измереното разстояние трябва да бъде най-малко 
1 000 m.  
— при положение са със сходна точност, за това 
изпитание могат също така да бъдат използвани 
други методи, като например подходящ изпит­ 
вателен стенд.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 105  
6.6 Поправки  
415) Сервизите трябва да могат да изтеглят данни от уредите 
за регистриране на данните за движението, за да ги 
върнат на съответното транспортно предприятие 
(превозвач).  
416) Одобрените сервизи трябва да издават на транс­ 
портните предприятия сертификат, удостоверяващ че 
данните не могат да бъдат изтеглени, когато повреда 
в уредите за регистриране на данните за движението 
не позволява записаните данни да бъдат изтеглени, 
дори след поправка в самия сервиз. Сервизите 
запазват копие от всеки издаден сертификат в 
продължение на най-малко две години.  
7 ИЗДАВАНЕ НА КАРТИ  
Процедурите, прилагани от държавите членки при издаване на 
картите, трябва да отговарят на следните изисквания:  
417) Номерът на картата при първото издаване на тахог­ 
рафска карта трябва да съдържа пореден номер (ако е 
приложимо), индекс за замяна и индекс за подновяване 
на валидността, зададен като „0“.  
418) Номерата на картата на всички тахографски карти, 
които не са поименни и са издадени от един 
контролен орган или от един сервиз или едно транс­ 
портно предприятие, трябва да са със същите първи 
13 цифри да са с различен пореден номер.  
419) Тахографска карта, издадена за замяна на друга същест­ 
вуваща тахографска карта, трябва да е със същия номер 
на картата, като този на заменената карта, с изключение 
на индекса за замяна, който трябва да се увеличи с 1 (в 
реда 0, …, 9, А, …, Z).  
420) Тахографска карта, издадена за замяна на друга същест­ 
вуваща тахографска карта, трябва да е със същата дата 
на край на валидността като картата, която заменя.  
421) Тахографска карта, издадена за подновяване на същест­ 
вуваща тахографска карта, трябва да е със същия номер 
на картата като номера на картата, чиято валидност 
подновява, с изключение на индекса за подновяване, 
който трябва да се увеличи с 1 (в реда 0, …, 9, А, 
…, Z).  
422) Замяната на съществуваща тахографска карта, с цел 
промяна на административните данни, трябва да 
следва правилата, прилагани при подновяване, ако тя 
се извършва в рамките на една и съща държава 
членка, или правилата, прилагани при първото 
издаване, ако се извършва в друга държава членка.  
423) „Фамилното име на титуляря на картата“ в случая на 
контролна карта или карта за монтаж и настройки, 
която не е поименна, трябва да бъде попълнено с 
наименованието на сервиза или на контролния орган 
или с името на монтьора или на контролиращия 
служител, ако така бъде решено от държавите членки.  
424) Държавите членки трябва да обменят данни по елек­ 
тронен път, за да гарантират уникалността на картите 
на водач, които издават, в съответствие с член 31 от 
Регламент (ЕС) № 165/2014.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 106  
8 ОДОБРЕНИЕ НА ТИПА НА УРЕДИТЕ ЗА РЕГИСТРИРАНЕ 
НА ДАННИТЕ ЗА ДВИЖЕНИЕТО И НА ТАХОГРАФСКИТЕ 
КАРТИ  
8.1 Общи  положения  
▼M1 
За целите на настоящата глава под „уреди за регистриране на 
данните за движението“ се имат предвид уредите за регис­ 
триране на данните за движението или техните компоненти. 
Не се изисква одобрение на типа на кабела или кабелите, 
свързващи датчика за движение с бордовото устройство, 
външното устройство за GNSS с бордовото устройство или 
външното устройство за връзка от разстояние с бордовото 
устройство. Хартията, използвана в уредите за регистриране 
на данните за движението, се приема като компонент на 
уредите за регистриране на данните за движението.  
Всеки производител може да поиска одобрение на типа на един 
или повече компоненти на уредите за регистриране на данните 
за движението с всеки друг компонент или компоненти на 
такива уреди, при условие че всеки компонент отговаря на 
изискванията от настоящото приложение. Като алтернатива, 
производителите могат да поискат и одобряване на типа на 
уредите за регистриране на данните за движението.  
Както се посочва в член 2, определение 10 от настоящия 
регламент, бордовите устройства могат да включват различни 
компоненти. С каквито и компоненти да е сглобено бордовото 
устройство, външната антена и (ако е приложимо) високочес­ 
тотният разклонител за антената, свързан с приемника на 
сигнали от GNSS или с устройството за връзка от разстояние, 
не са част от одобрението на типа на бордовото устройство.  
При все това производителите, получили одобрение на типа за 
бордово устройство, трябва да поддържат публично достъпен 
списък на съвместимите антени и високочестотни разклонители 
за всяко получило одобрение на типа бордово устройство, 
външно устройство за GNSS и външно устройство за връзка 
от разстояние.  
▼B 
425) Уредите за регистриране на данните за движението 
трябва да се представят за одобряване заедно с 
всички свои компоненти, както и с всички допъл­ 
нителни устройство, вградени в тях.  
426) Одобрението на типа на уреди за регистриране на 
данните за движението и на тахографски карти трябва 
да включва изпитвания, свързани със сигурността, 
изпитвания на функционирането и изпитвания за 
оперативна съвместимост. Положителните резултати 
от всяко от тези изпитвания се удостоверяват чрез 
съответен сертификат.  
▼M1 
427) Органите по одобряването на типа на държавите членки 
не предоставят сертификат за одобряване на типа, при 
положение че при тях няма:  
— сертификат за сигурност (ако съгласно настоящото 
приложение се изисква такъв),  
— сертификат за функциониране,  
— сертификат за оперативна съвместимост (ако 
съгласно настоящото приложение се изисква такъв),  
за уредите за регистриране на данните за движението 
или за тахографската карта, за които се иска одобряване 
на типа.  
▼B 
428) Всяка промяна на софтуера или хардуера, или на мате­ 
риалите, използвани при производството, трябва да 
бъде съобщена предварително на органа, който е 
издал одобрение на типа на уредите. Този орган 
трябва да потвърди на производителя разширяването 
на одобрението на типа или може да поиска актуали­ 
зиране или потвърждаване на сертификатите за 
функционирането, сигурността и/или оперативната 
съвместимост.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 107  
429) Процедурите по актуализиране на място на софтуера на 
уредите за регистриране на данните за движението 
трябва да бъдат одобрени от органа, който е издал 
одобрение на типа на въпросните уреди. Актуализи­ 
рането на софтуера не трябва да променя или да 
изтрива никаква информация относно дейността на 
водача, записана в уредите за регистриране на 
данните за движението. Софтуерът може да бъде актуа­ 
лизиран само на отговорност на производителя на 
уредите за регистриране на данните за движението.  
430) Одобряването на типа на софтуерни изменения, 
насочени към актуализиране на одобрен преди тип 
уреди за регистриране на данните за движението не 
може да бъде отказвано, ако такива изменения важат 
само за функции, които не са специфицирани в 
настоящото приложение. Актуализацията на софтуера 
на уредите за регистриране на данните за движението 
може да изключва въвеждането на нови набори от 
символи, ако това не е технически осъществимо.  
▼B 
8.2 Сертификат  за сигурност  
431) Сертификатът за сигурност се издава съгласно разпо­ 
редбите на допълнение 10 към настоящото приложение. 
Компонентите на уредите за регистриране на данните за 
движението, които се сертифицират, са бордово 
устройство, датчик за движение, външно устройство 
за GNSS и тахографските карти.  
432) При извънредното обстоятелство на отказ на органите 
за сертифициране за сигурност да сертифицират ново 
оборудване въз основа на излизане от употреба на 
механизмите за сигурност, издаването на одобрения 
на типа трябва да продължи само при това специфично 
и извънредно обстоятелство, когато не съществува 
алтернативно решение, съответстващо на регламента.  
433) При това обстоятелство въпросната държава членка 
следва незабавно да информира Европейската 
комисия, която в рамките на двадесет календарни 
месеца от издаването на одобрението на типа трябва 
да започне процедура за гарантиране, че равнището на 
сигурност е възстановено в неговото първоначално 
състояние.  
8.3 Сертификат  за функциониране  
434) Всеки кандидат за одобрение на типа трябва да пред­ 
остави на органа, извършващ типовото одобрение в 
съответната държава членка, цялата материална част и 
документацията, които този орган смята за необходими.  
435) Производителите предоставят съответните образци от 
продукти, за чието одобрение на типа се кандидатства, 
и свързаната с тях документация, изисквана от лабора­ 
ториите, определени да извършват изпитвания на 
функционирането, в срок от един месец от подаването 
на искането. Разходите, възникнали в резултат на това 
искане, се поемат от страната, която го е направила. 
Лабораториите разглеждат като поверителна цялата 
търговска информация с чувствителен характер.  
436) На производителя се издава сертификат за функцио­ 
ниране само ако всички изпитвания за функциониране, 
специфицирани в допълнение 9, са били преминати 
успешно.  
437) Сертификатът за функциониране се издава от органа по 
одобряването на типа. Освен името на притежателя си и 
наименованието на модела, този сертификат трябва да 
съдържа подробен списък на извършените изпитвания и 
на получените резултати.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 108  
438) В сертификата за функциониране на всеки компонент 
на уредите за регистриране на данните за движението 
трябва да се посочват и номерата на одобренията на 
типа на всички други одобрени съвместими компоненти 
на уредите за регистриране на данните за движението, 
изпитани за сертифицирането.  
439) В сертификата за функциониране на всеки компонент 
на уредите за регистриране на данните за движението 
също така трябва да се посочва стандарт ISO или CEN, 
по който е сертифициран функционалният интерфейс.  
8.4 Сертификат  за оперативна  съвместимост  
440) Изпитванията за оперативна съвместимост се извършват 
само от една лаборатория под контрола и отговорността 
на Европейската комисия.  
441) Лабораторията записва исканията за провеждане на 
изпитвания за оперативна съвместимост, подадени от 
производителите, по реда на тяхното постъпване.  
442) Исканията се записват официално само ако лабора­ 
торията разполага със:  
— цялата материална част и необходимите документи 
за провеждане на изпитванията за оперативна 
съвместимост,  
— съответния сертификат за сигурност,  
— съответния сертификат за функциониране,  
Датата на вписване на искането се съобщава на произ­ 
водителя.  
▼M3 
443) Лабораторията не извършва изпитвания за оперативна 
съвместимост на уреди за регистриране на данните за 
движението или на тахографски карти, които не са 
преминали анализ на уязвимостта във връзка с 
тяхната оценка на сигурността, както и оценка на 
функционирането, освен при извънредните обстоя­ 
телства, описани в изискване 432.  
▼B 
444) Всеки производител, поискал провеждането на 
изпитвания за оперативна съвместимост, трябва да се 
ангажира да остави на лабораторията, натоварена с 
изпитванията, цялата материална част и докумен­ 
тацията, необходими за целите на изпитванията.  
445) Изпитванията за оперативна съвместимост се провеждат 
в съответствие с разпоредбите на допълнение 9 към 
настоящото приложение, съответни с всички типове 
уреди за регистриране на данните за движението или 
тахографски карти:  
— валидността на одобрението на типа на които не е 
изтекла или  
— чието одобрение на типа се извършва в момента и 
за които съществува валиден сертификат за 
оперативна съвместимост.  
446) Изпитванията за оперативна съвместимост трябва да 
обхващат всички поколения уреди за регистриране на 
данните за движението или тахографски карти, които 
все още са в употреба.  
▼M3 
447) Сертификатът за оперативна съвместимост се издава на 
производителя от лабораторията само след успешното 
преминаване на всички изисквани изпитвания за 
оперативна съвместимост и след като производителят 
е показал, че за продукта са издадени валиден 
сертификат за функциониране и валиден сертификат 
за сигурност, освен при изключителните обстоятелства, 
описани в изискване 432.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 109  
448) Ако изпитванията за оперативна съвместимост не са 
преминати успешно от един или от няколко уреда за 
регистриране на данните за движението или от тахог­ 
рафска(и) карта(и), сертификат за оперативна съвмес­ 
тимост не се издава, докато заявилият производител 
не направи необходимите промени и не премине изпит­ 
ванията за оперативна съвместимост. Лабораторията 
трябва да установи причината за проблема с помощта 
на съответния производител и се опитва да му помогне 
при търсенето на техническо решение. В случай че 
производителят е променил продукта си, той трябва 
да се увери, като се обърне към компетентните 
органи, че сертификатът за сигурност и на серти­ 
фикатът за функциониране са все още валидни.  
449) Сертификатът за възможността за взаимна работа важи 
6 месеца. Той изтича в края на този период, ако произ­ 
водителят не е получил съответния сертификат за 
типово одобрение. Той се предава от производителя 
на органа, извършващ типовото одобрение в 
държавата членка, която е издала сертификата за 
функциониране.  
450) Всеки елемент, който би могъл да предизвика неиз­ 
правност свързана с оперативната съвместимост, не 
трябва да се използва за извличане на печалба или за 
придобиване на доминиращо положение на пазара.  
8.5 Сертификат  за одобрение  на типа  
451) Органът, извършващ одобряването на типа в държавата 
членка, може да издаде сертификат за одобряване на 
типа, при положение че при него са налице трите 
изисквани сертификата.  
452) В сертификата за одобряване на типа на всеки 
компонент на уредите за регистриране на данните за 
движението трябва да се посочват и номерата на одоб­ 
рението на типа на другите одобрени съвместими 
компоненти на уреди за регистриране на данните за 
движението.  
453) Копие от сертификата за одобряване на типа трябва да 
бъде предадено от органа по одобряването на типа на 
лабораторията, натоварена с изпитванията за 
оперативна съвместимост, в момента на издаването на 
този документ на производителя.  
454) Лабораторията, отговаряща за изпитванията за 
оперативна съвместимост, трябва да има публична 
интернет страница, на която да се актуализира 
списъкът на моделите на уредите за регистриране на 
данните за движението или на тахографски карти:  
— за които е било регистрирано искане за провеждане 
на изпитвания за оперативна съвместимост,  
— които са получили сертификат за оперативна 
съвместимост (дори и временен),  
— които са получили сертификат за одобряване на 
типа.  
8.6 Извънредна  процедура : първи  сертификати  за оперативна  
съвместимост  за уреди  за регистриране  на данните  за 
движението  и тахографски  карти  от 2-ро поколение  
455) За период от 4 месеца след като една първа двойка от 
уреди за регистриране на данните за движението от 2- 
ро поколение и тахографски карти от 2-ро поколение 
(карта на водач, карта за монтаж и настройки, 
контролна карта и карта на превозвач) е била 
призната за оперативно съвместима, всеки издаден 
сертификат за оперативна съвместимост (включително 
първия), имащ отношение към заявките, получени през 
този период, се счита за временен.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 110  
456) След изтичане на този период, ако всички въпросни 
продукти са оперативно съвместими, всички съответни 
сертификати за оперативна съвместимост стават окон­ 
чателни.  
457) Ако по време на този период се появят неизправности, 
свързани с оперативната съвместимост, лабораторията, 
натоварена с провеждането на изпитванията за 
оперативна съвместимост, трябва да определи 
причините за проблемите с помощта на всички 
участващи производители и да прикани последните да 
направят необходимите промени.  
458) Ако в края на този период проблемите, свързани с 
оперативната съвместимост, все още са налице, лабора­ 
торията, натоварена с провеждането на изпитванията, в 
сътрудничество със заинтересованите производители и 
с органите по одобряването на типа, определя 
причините за неизправностите, свързани с оперативната 
съвместимост, и определя промените, които всеки заин­ 
тересован производител трябва да направи. Търсенето 
на технически решения може да продължи най-много 
два месеца, след което Комисията, при липса на общо 
решение и след консултация с лабораторията, нато­ 
варена с извършването на изпитванията за оперативна 
съвместимост, решава на кой(кои) уред(и) и карти ще 
се издаде окончателен сертификат за оперативна 
съвместимост, като уточнява причините за своя избор.  
459) Всяко искане за извършване на изпитвания за 
оперативна съвместимост, заведено от лабораторията 
във времето от края на периода от четири месеца 
след издаване на първия временен сертификат за 
оперативна съвместимост до датата на вземане на 
решение от Комисията, посочена в изискване 455, се 
отлага до решаване на първоначалните проблеми, 
свързани с оперативната съвместимост. Тези искания 
след това се обработват в реда на тяхното завеждане.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 111  
Допълнение  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  
▼M3 
2.11a CardBorderCrossing  
2.11б. CardBorderCrossingRecord  
▼B 
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  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 112  
2.24a. CardLoadTypeEntries  
2.24б. CardLoadTypeEntryRecord  
2.24в. CardLoadUnloadOperations  
2.24г. CardLoadUnloadRecord  
▼B 
2.25. CardMACertificate  
2.26. CardNumber  
▼M3 
2.26а. CardPlaceAuthDailyWorkPeriod  
▼B 
2.27. CardPlaceDailyWorkPeriod  
2.28. CardPrivateKey  
2.29. CardPublicKey  
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  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 113  
2.48а. CompanyCardApplicationIdentificationV2  
▼B 
2.49. CompanyCardHolderIdentification  
2.50. ControlCardApplicationIdentification  
▼M3 
2.50а. ControlCardApplicationIdentificationV2  
▼B 
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  
▼M3 
2.60а. DownloadInterfaceVersion  
▼B 
2.61. DriverCardApplicationIdentification  
▼M3 
2.61а. DriverCardApplicationIdentificationV2  
▼B 
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  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 114  
2.74. FullCardNumberAndGeneration  
2.75. Generation  
2.76. GeoCoordinates  
2.77. GNSSAccuracy  
▼M1 
2.78. GNSSAccumulatedDriving  
2.79. GNSSAccumulatedDrivingRecord  
▼M3 
2.79a. GNSSAuthAccumulatedDriving  
2.79б. GNSSAuthStatusADRecord  
2.79в. GNSSPlaceAuthRecord  
▼B 
2.80. GNSSPlaceRecord  
2.81. HighResOdometer  
2.82. HighResTripDistance  
2.83. HolderName  
▼M3 
2.84. Резервирана за бъдеща употреба  
▼B 
2.85. K-ConstantOfRecordingEquipment  
2.86. KeyIdentifier  
2.87. KMWCKey  
2.88. Language  
2.89. LastCardDownload  
▼M3 
2.89а. LengthOfFollowingData  
▼B 
2.90. LinkCertificate  
▼M3 
2.90а. LoadType  
▼B 
2.91. L-TyreCircumference  
2.92. MAC  
2.93. ManualInputFlag  
2.94. ManufacturerCode  
2.95. ManufacturerSpecificEventFaultData  
2.96. MemberStateCertificate  
2.97. MemberStateCertificateRecordArray  
2.98. MemberStatePublicKey  
2.99. Name  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 115  
2.100. NationAlpha  
2.101. NationNumeric  
▼M3 
2.101а. NoOfBorderCrossingRecords  
▼B 
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  
▼M3 
2.111а. NoOfLoadUnloadRecords  
▼B 
2.112. NoOfSpecificConditionRecords  
▼M3 
2.112а. NoOfLoadTypeEntryRecords  
▼B 
2.113. OdometerShort  
2.114. OdometerValueMidnight  
▼M3 
2.114а. OperationType  
▼B 
2.115. OdometerValueMidnightRecordArray  
2.116. OverspeedNumber  
▼M3 
2.116а. PlaceAuthRecord  
2.116б. PlaceAuthStatusRecord  
▼B 
2.117. PlaceRecord  
▼M3 
2.117а. PositionAuthenticationStatus  
▼B 
2.118. PreviousVehicleInfo  
2.119. PublicKey  
2.120. RecordType  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 116  
2.121. RegionAlpha  
2.122. RegionNumeric  
2.123. RemoteCommunicationModuleSerialNumber  
2.124. RSAKeyModulus  
2.125. RSAKeyPrivateExponent  
2.126. RSAKeyPublicExponent  
2.127. RtmData  
2.128. SealDataCard  
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  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 117  
2.152. SpecificConditionRecord  
2.153. SpecificConditions  
2.154. SpecificConditionType  
2.155. Speed  
2.156. SpeedAuthorised  
2.157. SpeedAverage  
2.158. SpeedMax  
▼M3 
2.158а. TachographCardsGen1Suppression  
▼B 
2.159. TachographPayload  
▼M1 
2.160. Reserved for future use  
▼B 
2.161. TDesSessionKey  
2.162. TimeReal  
2.163. TyreSize  
2.164. VehicleIdentificationNumber  
2.165. VehicleIdentificationNumberRecordArray  
2.166. VehicleRegistrationIdentification  
▼M3 
2.166а. VehicleRegistrationIdentificationRecordArray  
▼B 
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  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 118  
2.179. VuCardRecord  
2.180. VuCardRecordArray  
2.181. VuCertificate  
2.182. VuCertificateRecordArray  
2.183. VuCompanyLocksData  
2.184. VuCompanyLocksRecord  
2.185. VuCompanyLocksRecordArray  
▼M3 
2.185а. VuConfigurationLengthRange  
▼B 
2.186. VuControlActivityData  
2.187. VuControlActivityRecord  
2.188. VuControlActivityRecordArray  
2.189. VuDataBlockCounter  
2.190. VuDetailedSpeedBlock  
2.191. VuDetailedSpeedBlockRecordArray  
2.192. VuDetailedSpeedData  
▼M3 
2.192а. VuDigitalMapVersion  
▼B 
2.193. VuDownloadablePeriod  
2.194. VuDownloadablePeriodRecordArray  
2.195. VuDownloadActivityData  
2.196. VuDownloadActivityDataRecordArray  
2.197. VuEventData  
2.198. VuEventRecord  
2.199. VuEventRecordArray  
2.200. VuFaultData  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 119  
2.201. VuFaultRecord  
2.202. VuFaultRecordArray  
▼M1 
2.203. VuGNSSADRecord  
▼M3 
2.203а. VuBorderCrossingRecord  
2.203б. VuBorderCrossingRecordArray  
▼M1 
2.204. VuGNSSADRecordArray  
▼M3 
2.204а. VuGnssMaximalTimeDifference  
▼B 
2.205. VuIdentification  
2.206. VuIdentificationRecordArray  
2.207. VuITSConsentRecord  
2.208. VuITSConsentRecordArray  
▼M3 
2.208а. VuLoadUnloadRecord  
2.208б. VuLoadUnloadRecordArray  
▼B 
2.209. VuManufacturerAddress  
2.210. VuManufacturerName  
2.211. VuManufacturingDate  
2.212. VuOverSpeedingControlData  
2.213. VuOverSpeedingControlDataRecordArray  
2.214. VuOverSpeedingEventData  
2.215. VuOverSpeedingEventRecord  
2.216. VuOverSpeedingEventRecordArray  
2.217. VuPartNumber  
2.218. VuPlaceDailyWorkPeriodData  
2.219. VuPlaceDailyWorkPeriodRecord  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 120  
2.220. VuPlaceDailyWorkPeriodRecordArray  
2.221. VuPrivateKey  
2.222. VuPublicKey  
▼M3 
2.222а. VuRtcTime  
▼B 
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  
▼M3 
2.234а. WorkshopCardApplicationIdentificationV2  
2.234б. WorkshopCardCalibrationAddData  
2.234в. WorkshopCardCalibrationAddDataRecord  
▼B 
2.235. WorkshopCardCalibrationData  
2.236. WorkshopCardCalibrationRecord  
2.237. WorkshopCardHolderIdentification  
2.238. WorkshopCardPIN  
2.239. W-VehicleCharacteristicConstant  
2.240. VuPowerSupplyInterruptionRecord  
2.241. VuPowerSupplyInterruptionRecordArray  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 121  
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 — 21.08.2023 — 003.001 — 122  
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. ОПРЕДЕЛЕНИЯ НА ТИПОВЕТЕ ДАННИ  
▼M3 
За всеки от следващите типове данни стойността по подразбиране 
за съдържание, което е „неизвестно“ или „не се прилага“, се със тои 
в запълване на елемента от данни с „FF“ байта по шестнайсетична та 
бройна система.  
Всички типове данни се използват за приложенията от поколение 1  
и 2, освен ако е посочено друго. Посочени са типове данни, коит о 
са използвани само за приложения от поколение 2, версия 2.  
Посоченият в настоящото допълнение размер за типовете карти за 
данни, които се използват за приложенията от поколение 1 и 2, е  
размерът за приложение от поколение 2. Предполага се, че четецъ т 
вече познава размера за приложение от поколение 1. Номерата на 
изискванията в приложение IB, свързани с тези типове данни, се 
отнасят за приложенията от поколение 1 и 2.  
Типовете картови данни, които не са определени за карти от 
поколение 1, не се съхраняват в приложение от поколение 1 за 
карти от поколение 2. По-конкретно:  
— Номерата на одобренията на типа, съхранени в приложение от 
поколение 1 на карти от поколение 2, се скъсяват до първите 8 
символа, ако е необходимо,  
— Само „FRRY/TRAIN CROSSING begin“ на специфичното 
условие „FERRY/TRAIN CROSSING“ се съхранява в 
приложение от поколение 1 на карти от поколение 2.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 123  
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: ВТОРИ ВОДАЧ,  
„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: ИЗВЕСТНА ДЕЙНОСТ (=ръчно въведена)  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 124  
„p“B Статус на картата:  
„0“B: ВКАРАНА, картата е вкарана в уред за регис­ 
триране на данните за движението,  
„1“B: НЕ Е ВКАРАНА, не е вкарана картата (или 
картата е извадена),  
„aa“B Дейност (не е от значение, когато „p“=1 и „c“=0 
освен забележката по-долу):  
„00“B: ПРЕКЪСВАНЕ/ПОЧИВКА,  
„01“B: НА РАЗПОЛОЖЕНИЕ,  
„10“B: РАБОТА,  
„11“B: УПРАВЛЕНИЕ,  
„ttttttttttt“B Време на промяната: брой минути, изтекли след 
00.00 часа на съответния ден.  
Забележка  в случай  на „Изваждане  на картата “: 
Когато картата е извадена:  
— „s“ се прилага и указва процепа, откъдето е извадена картата,  
— за „c“ трябва да се зададе 0,  
— за „p“ трябва да се зададе 1,  
— „aa“ трябва да кодира текущата дейност, избрана в същия 
момент.  
Вследствие на ръчното въвеждане битовете „c“ и „aa“ на думата 
(съхранена на карта) могат да бъдат изтрити с цел отразяване на  
постъпването на съответните данни.  
2.2. Address  
Адрес.
  
codePage  указва набор от символи, определен в глава 4.  
address  е адрес, кодиран с използването на указания набор от 
символи.  
2.3. AESKey  
Поколение  2: 
Ключ AES с дължина 128, 192 или 256 бита.
  
Присвояване  на стойност : липса на допълнителна информация.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 125  
2.4. AES128Key  
Поколение  2: 
Ключ AES128.
  
length  указва дължината на ключа AES128 в октети.  
aes128Key  е ключ AES с дължина от 128 бита.  
Присвояване  на стойност : 
Дължината трябва да е със стойност 16.  
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“.
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 126  
BCDString използва нотацията „hstring“. Най-лявото шестнад­ 
есетично число трябва да е най-старши полуоктет на първия 
октет. За да се получи кратно число на октетите, е необходимо 
според нуждите да се вмъкне съответният брой младши нулеви 
полуоктети от най-лявата позиция на полуоктета на първия октет.  
Допустими цифри: 0, 1, .. 9.  
2.8. CalibrationPurpose  
Код, указващ причината за записване на набор от параметри за 
калибриране. Този тип данни е свързан с изисквания 097 и 098 от  
приложение 1Б и изискване 119 от приложение 1В.
  
Присвояване  на стойност : 
Поколение 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). Когато  
този запис е най-старият дневен запис, за стойността на activit yPre­
viousRecordLength трябва да се зададе 0.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 127  
activityRecordLength  е общата дължина на този запис, изразена в 
байтове. Максималната стойност съответства на дължината на 
OCTET STRING, съдържащ тези записи.  
activityRecordDate  е датата на записа.  
activityDailyPresenceCounter  е състоянието за съответния ден на 
брояча на присъствените дни за картата.  
activityDayDistance  е общото изминато разстояние през съответния 
ден. 
activityChangeInfo  указва за съответния ден набора от данни Acti­
vityChangeInfo, който се отнася за водача. Той не може да съдър жа 
повече от 1440 стойности (една промяна на дейност в минута). То зи 
набор съдържа винаги ActivityChangeInfo, който кодира състояние то 
при управление в 00:00 часа.  
2.10.  CardActivityLengthRange  
Брой на байтовете в карта на водач или карта за монтаж и 
настройки, които са налични за съхранение на записите за 
дейностите на водача.
  
Присвояване  на стойност : вж. допълнение 2.  
2.11.  CardApprovalNumber  
Номер на одобрение на типа на картата.
  
Присвояване  на стойност : 
Номерът на одобрение е този, който е публикуван на съответната 
интернет страница на Европейската комисия, т.е. например, като се 
включват тиренца, ако има. Номерът на одобрение се подравнява 
отляво.  
▼M3 
2.11a.  CardBorderCrossings  
Поколение 2, версия 2:  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и отнасяща се до пресичането на граници от превозното  
средство, когато то е пресекло границата на държава (изисквания  
306е и 356е от приложение IВ).
  
borderCrossingPointerNewestRecord  е индексът на последния 
актуализиран запис в картата за пресичането на граница.  
Присвояване  на стойност  е числото, съответстващо на номератора 
на записа в картата за пресичането на граница, започващо от 0 з а 
първия случай в структурата на запис в картата за пресичане на 
граница.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 128  
CardBorderCrossingRecords  е наборът от записи в картата за 
пресичане на граници.  
2.11б.  CardBorderCrossingRecord  
Поколение 2, версия 2:  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и отнасяща се до пресичането на граници от превозното  
средство, когато то е пресекло границата на държава (изисквания  
147б, 306д и 356д от приложение IВ).
  
countryLeft  е държавата, която превозното средство е напуснало, 
или „няма налична информация“ съгласно изискване 147б от 
приложение IB. „Останалата част на света“ (NationNumeric код 
„FF“H по шестнайсетичната бройна система) се използва, когато 
бордовото устройство не е в състояние да определи държавата, в 
която се намира превозното средство (напр. настоящата държава н е 
е част от съхранените цифрови карти).  
countryEntered  е държавата, в която е влязло превозното средство, 
или държавата, в която се намира превозното средство в момента на 
вкарването на картата. „Останалата част на света“ (NationNumeri c 
код „FF“H по шестнайсетичната бройна система) се използва, 
когато бордовото устройство не е в състояние да определи 
държавата, в която се намира превозното средство (напр. 
настоящата държава не е част от съхранените цифрови карти).  
gnssPlaceAuthRecord  съдържа информация, свързана с местополо­ 
жението на превозното средство, когато бордовото устройство е 
установило, че превозното средство е преминало границата на 
държава, или „няма налична информация“ съгласно изискване 
147б от приложение IB и статуса по отношение на удостоверя­ 
ването на автентичността му.  
vehicleOdometerValue  е стойността на километражния брояч, 
когато бордовото устройство е установило, че превозното 
средство е преминало границата на държава, или „няма налична 
информация“ съгласно изискване 147б от приложение IB.  
▼B 
2.12.  CardCertificate  
Поколение 1:  
Сертификат на публичния ключ на карта.
  
2.13.  CardChipIdentification  
Информация, съхранена на карта и отнасяща се до идентификация 
на интегралната схема (ИС) на картата (изискване 249 от 
приложение 1В). icSerialNumber и icManufacturingReferences иден ти­ 
фицират уникално чипа на картата. Самостоятелно icSerialNumber 
не идентифицира уникално чипа на картата.
  
icSerialNumber  е серийният номер на ИС.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 129  
icManufacturingReferences  е специфичният идентификатор на 
производителя на ИС.  
2.14.  CardConsecutiveIndex  
Индекс за пореден номер на картата (определение з).
  
Присвояване  на стойност : (вж. приложение 1В, глава 7)  
Възходящ ред: „0, …, 9, A, …, Z, a, …, z“  
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  е идентификацията на понастоящем изпол­ 
званото превозно средство след вкарване на картата. Този елемен т 
се нулира при изваждане на картата.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 130  
2.17.  CardDriverActivity  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и отнасяща се до дейностите на водача (изисквания 267 , 
268, 292, 293, 321 и 344 от приложение 1В).
  
activityPointerOldestDayRecord  е спецификацията на началото на 
мястото на съхранение (брой на байтовете от началото на низа) н а 
най-стария пълен дневен запис в низа activityDailyRecords. Макс и­ 
малната стойност съответства на дължината на низа.  
activityPointerNewestRecord  е спецификацията на началото на 
мястото на съхранение (брой на байтовете от началото на низа) н а 
най-скорошния дневен запис в низа activityDailyRecords. Макси­ 
малната стойност съответства на дължината на низа.  
activityDailyRecords  е мястото, което е налично за съхранение на 
данните относно дейностите на водача (структура на данни: CardA c­
tivityDailyRecord) за всеки календарен ден, през който картата е 
била използвана.  
Присвояване  на стойност : този низ от октети се попълва циклично 
със записи от CardActivityDailyRecord. При първото използване 
съхранението започва на първия байт на низа. Следващите записи 
се запаметяват в края на предишния. Когато низът се запълни, 
съхранението продължава от първия байт на низа, независимо от 
прекъсването вътре в елемент от данни. Преди да се въведат нови  
данни за дейността в низа (като се разшири текущият activityDai ly­
Record или като се въведе нов activityDailyRecord), които замес тват 
по-старите данни за дейността, е необходимо да се актуализира 
activityPointerOldestDayRecord, за да се отрази новото местопо­  
ложение на най-стария пълен дневен запис, и трябва да се нулира  
activityPreviousRecordLength на този (нов) най-стар пълен дневе н 
запис.  
2.18.  CardDrivingLicenceInformation  
Информация, съхранена на карта на водач и отнасяща се до свиде­  
телството за управление на титуляря на картата (изисквания 259 и 
284 от приложение 1В).
  
drivingLicenceIssuingAuthority  е компетентният орган за издаване 
на свидетелството за управление.  
drivingLicenceIssuingNation  е националността на органа, издал 
свидетелството за управление.  
drivingLicenceNumber  е номерът на свидетелството за управление.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 131  
2.19.  CardEventData  
Поколение 1:  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и отнасяща се до събитията, свързани с титуляря на 
картата (изисквания в подточки 260 и 318 от приложение IВ).
  
CardEventData  е последователност във възходящ ред от EventFa­
ultType и cardEventRecords (с изключение на записите относно 
опитите за нарушаване на сигурността, които са групирани в 
последния блок от данни на последователността).  
cardEventRecords  е набор от записи на събития от определен тип 
(или категория от събития във връзка с опити за нарушаване на 
сигурността).  
Поколение 2:  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и отнасяща се до събитията, свързани с титуляря на 
картата (изисквания в подточки 285 и 341 от приложение IВ).
  
CardEventData  е последователност във възходящ ред от EventFa­
ultType и cardEventRecords (с изключение на записите относно 
опитите за нарушаване на сигурността, които са групирани в 
последния блок от данни на последователността).  
cardEventRecords  е набор от записи на събития от определен тип 
(или категория от събития във връзка с опити за нарушаване на 
сигурността).  
▼B 
2.20.  CardEventRecord  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и отнасяща се до събитие, свързано с титуляря на карт ата 
(изисквания 261, 286, 318 и 341 от приложение 1В).
  
eventType  е типът на събитието.  
eventBeginTime  е датата и часът на начало на събитието.  
eventEndTime  е датата и часът на край на събитието.  
eventVehicleRegistration  посочва VRN и регистриращата 
превозното средство държава членка, в която се е случило 
събитието.  ▼M1
 02016R0799 — BG — 21.08.2023 — 003.001 — 132  
2.21.  CardFaultData  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и отнасяща се до неизправности, свързани с титуляря н а 
картата (изисквания 263, 288, 318 и 341 от приложение 1В).
  
CardFaultData  е последователност, съдържаща набор от записи за 
неизправности, засягащи уредите за регистриране на данните за 
движението, и последван от набор записи за неизправностите във 
връзка с картата.  
cardFaultRecords  е набор от записи за неизправности в определена 
категория неизправности (уреди за регистриране на данните за 
движението или карти).  
2.22.  CardFaultRecord  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и отнасяща се до неизправност, свързана с титуляря на  
картата (изисквания 264, 289, 318 и 341 от приложение 1В).
  
faultType  е типът неизправност.  
faultBeginTime  е датата и часът на начало на неизправността.  
faultEndTime  е датата и часът на край на неизправността.  
faultVehicleRegistration  посочва VRN и регистриращата превозното 
средство държава членка, в която се е случила съответната неиз­  
правност.  
2.23.  CardIccIdentification  
Информация, съхранена на карта и отнасяща се до идентификация 
на картата с интегрална схема (ИС) (изискване 248 от приложение  
1В).
 
clockStop  е режимът clockStop, определен в допълнение 2.  
cardExtendedSerialNumber  е уникалният сериен номер на ИС на 
картата, допълнително специфициран от типа данни ExtendedSerial ­
Number.  
cardApprovalNumber  е номерът на одобрение на типа на картата.  
cardPersonaliserID  е идентификатор на организацията, персонали­ 
зирала картата, изразен чрез ManufacturerCode.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 133  
embedderIcAssemblerId  осигурява информация за интегратора/ 
монтажника на ИС.  
icIdentifier  е идентификаторът на ИС на картата и производителя на 
нейната ИС, определен в стандарт ISO/IEC 7816-6.  
2.24.  CardIdentification  
Информация, съхранена на карта и отнасяща се до идентификация 
на картата (изисквания 255, 280, 310, 333, 359, 365, 371 и 377 от 
приложение 1В).
  
cardIssuingMemberState  е кодът на държавата членка, издаваща 
картата.  
cardNumber  е номерът на картата.  
cardIssuingAuthorityName  е наименованието на органа, издал 
картата.  
cardIssueDate  е датата на издаване на картата на актуалния ѝ 
титуляр.  
cardValidityBegin  е първата дата на валидност на картата.  
cardExpiryDate  е датата на край на валидност на картата.  
▼M3 
2.24а.  CardLoadTypeEntries  
Поколение 2, версия 2:  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и отнасяща се до въвеждания за типа на товара, когато  
картата е вкарана в бордовото устройство (изисквания 306й и 356 й 
от приложение IВ).
  
loadTypeEntryPointerNewestRecord  е индексът на последния актуа­ 
лизиран въведен запис в картата за типа на товара.  
Присвояване  на стойност : число, съответстващо на номератора на 
въведения запис в картата за типа на товара, започващо от 0 за 
първия случай в структурата на въведен запис в картата за типа 
на товара.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 134  
cardLoadTypeEntryRecords  е наборът от записи, съдържащи датата 
и часа на въвеждане и въведения тип на товара.  
2.24б.  CardLoadTypeEntryRecord  
Поколение 2, версия 2:  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и отнасяща се до въведени промени на типа на товара, 
когато картата е вкарана в бордовото устройство (изисквания 306 и 
и 356и от приложение IВ).
  
timeStamp  е датата и часът, когато е въведен типът на товара.  
loadTypeEntered  е въведеният тип на товара.  
2.24в.  CardLoadUnloadOperations  
Поколение 2, версия 2:  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и отнасяща се до товаро-разтоварните операции на 
превозното средство (изисквания 306з и 356з от приложение IВ).
  
loadUnloadPointerNewestRecord  е индексът на последния актуа­ 
лизиран запис в картата за товаро-разтоварна операция.  
Присвояване  на стойност : е числото, съответстващо на номератора 
на записа в картата за товаро-разтоварна операция, започващо от  0  
за първия случай в структурата на запис в картата за товаро- 
разтоварна операция.  
cardLoadUnloadRecords  е наборът от записи, съдържащи указване 
на типа на извършената операция (товарене, разтоварване или едн о­ 
временно товарене и разтоварване), датата и часа на въвеждане н а 
товаро-разтоварната операция, информация за местоположението на  
превозното средство и стойността на километражния брояч на 
превозното средство.  
2.24г.  CardLoadUnloadRecord  
Поколение 2, версия 2:  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и отнасяща се до товаро-разтоварните операции на 
превозното средство (изисквания 306ж и 356ж от приложение IВ).
  
timeStamp  е датата и часът в началото на товаро-разтоварната 
операция.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 135  
operationType  е въведеният тип на операцията (товарене, разто­ 
варване или едновременно товарене и разтоварване).  
gnssPlaceAuthRecord  съдържа информация за местоположението на 
превозното средство.  
vehicleOdometerValue  е стойността на километражния брояч, 
отнасяща се до началото на товаро-разтоварната операция.  
▼B 
2.25.  CardMACertificate  
Поколение 2:  
Сертификат на публичния ключ на картата за общо удостоверяване 
с бордовото устройство. Структурата на този сертификат е посоче на 
в допълнение 11.
  
2.26.  CardNumber  
Номер на картата съгласно определение ж).
  
driverIdentification  е уникалната идентификация на водач в 
държава членка.  
ownerIdentification  е уникалната идентификация на превозвач, 
сервиз или контролен орган в държава членка.  
cardConsecutiveIndex  е индексът за пореден номер на картата.  
cardReplacementIndex  е индексът за замяна на картата.  
cardRenewalIndex  е индексът за подновяване на валидността на 
картата.  
Първата последователност от селекцията позволява да се кодира 
номерът на картата на водач, втората последователност — 
номерата на контролната карта, картата за монтаж и настройки и 
на картата на превозвач.  
▼M3 
2.26a.  CardPlaceAuthDailyWorkPeriod  
Поколение 2, версия 2:  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и предоставяща статуса на удостоверяването на автенти ч­ 
ността на местата, където дневните периоди на работа започват 
и/или завършват (изисквания 306б и 356б от приложение IВ).  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 136
  
placeAuthPointerNewestRecord  е индексът на последния актуа­ 
лизиран запис за удостоверяване на автентичността на мястото.  
Присвояване  на стойност : число, съответстващо на номератора на 
записа за статуса на удостверяването на автентичността на място то, 
започващо от 0 за първия случай в структурата на запис за стату са 
на удостоверяване на автентичността на мястото.  
placeAuthStatusRecords  е наборът от записи, съдържащи статуса на 
удостоверяване на автентичността на въведените места.  
▼B 
2.27.  CardPlaceDailyWorkPeriod  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и отнасяща се за местата в началото и/или в края на 
дневните периоди на работа (изисквания 272, 297, 325 и 348 от 
приложение 1В).
  
placePointerNewestRecord  е индексът на последния актуализиран 
запис за местоположението.  
Присвояване  на стойност : число, съответстващо на номератора на 
записа за местоположението, като се започва с 0 за първия случа й 
на записи за местоположението в структурата.  
placeRecords  е наборът от записи, съдържащ данните относно 
въведените местоположения.  
2.28.  CardPrivateKey  
Поколение 1:  
Частен ключ на карта.
  
2.29.  CardPublicKey  
Публичен ключ на карта.
  
▼M1 
2.30.  CardRenewalIndex  
Индекс за подновяване на валидността на картата (определение и) .
 ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 137  
Присвояване  на стойност : (вж. глава 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  
Код, указващ типа на картите, вкарани в двата процепа на 
бордовото устройство.
  
Присвояване  на стойност  — синхронизиран  октет : „ccccdddd“B  
„cccc“B Идентификация на типа на картата, вкарана в 
процепа за втория водач,  
„dddd“B Идентификация на типа на картата, вкарана в 
процепа за водача,  
с помощта на следните кодове за идентификация:  
„0000“B не е вкарана карта,  
„0001“B вкарана е карта на водач,  
„0010“B вкарана е карта за монтаж и настройки,  
„0011“B вкарана е контролна карта,  
„0100“B вкарана е карта на превозвач.  ▼M1
 02016R0799 — BG — 21.08.2023 — 003.001 — 138  
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  
▼M3 
„bb“H Индекс за промените, отнасящи се до използването 
на елементи от данни, определени за съответната 
структурата от старшия байт.  
„00“H за приложенията от поколение 1  
„00“H за версия 1 на приложенията от поколение 2  
„01“H за версия 2 на приложенията от поколение 2  
▼B 
2.37.  CardVehicleRecord  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и отнасяща се до период на използване на превозно 
средство през определен календарен ден (изисквания 269, 294, 32 2 
и 345 от приложение 1В).  
Поколение 1:
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 139  
vehicleOdometerBegin  е стойността от километражния брояч на 
превозното средство в началото на периода на използване на 
превозното средство.  
vehicleOdometerEnd  е стойността от километражния брояч на 
превозното средство в края на периода на използване на превозно то 
средство.  
vehicleFirstUse  е датата и часът на начало на периода на използване 
на превозното средство.  
vehicleLastUse  е датата и часът на край на периода на използване 
на превозното средство.  
vehicleRegistration  посочва VRN и държавата членка, регистрираща 
превозното средство.  
vuDataBlockCounter  е стойността на vuDataBlockCounter при 
последното извличане на периода на използване на превозното 
средство.  
Поколение 2:
  
В допълнение към поколение 1 се използва следният елемент от 
данни:  
VehicleIdentificationNumber  е идентификационният номер на 
превозното средство, обозначаващ цялото превозно средство.  
2.38.  CardVehiclesUsed  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и отнасяща се до превозните средства, използвани от 
титуляря на картата (изисквания 270, 295, 323 и 346 от приложен ие 
1В).
 
vehiclePointerNewestRecord  е индексът на последния актуализиран 
запис на превозното средство.  
Присвояване  на стойност : число, съответстващо на номератора на 
записа за превозното средство, като се започва с 0 за първия сл учай 
на записи за превозното средство в структурата.  
cardVehicleRecords  е наборът от записи, съдържащ информация за 
използваните превозни средства.  
2.39.  CardVehicleUnitRecord  
Поколение 2:  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 140  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и отнасяща се до използвано бордово устройство 
(изисквания 303 и 351 от приложение 1В).
  
timeStamp  е началото на периода на използване на бордовото 
устройство (т.е. първото вкарване на картата в бордовото 
устройство за периода).  
manufacturerCode  идентифицира производителя на бордовото 
устройство.  
deviceID  идентифицира типа бордово устройство на производител. 
Стойността е специфична за съответния производител.  
vuSoftwareVersion  е номерът на версията на софтуера на бордовото 
устройство.  
2.40.  CardVehicleUnitsUsed  
▼M3 
Поколение 2:  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и отнасяща се до използваните бордови устройства от 
титуляря на картата (изисквания 304 и 352 от приложение IВ).  
▼B
 
vehicleUnitPointerNewestRecord  е индексът на последния актуа­ 
лизиран запис на бордовото устройство.  
Присвояване  на стойност : число, съответстващо на номератора на 
записа за бордовото устройство, като се започва с 0 за първия 
случай на записи за бордовото устройство в структурата.  
cardVehicleUnitRecords  е наборът от записи, съдържащ 
информация за използваните бордови устройства.  
2.41.  Certificate  
Сертификатът на публичен ключ, издаден от сертификационен 
орган.  
Поколение 1:
  
Присвояване  на стойност : електронен подпис с частично възста­ 
новяване на CertificateContent съгласно общите механизми за 
сигурност от допълнение 11: подпис (128 байта) || Остатък от 
публичния ключ (58 байта) || Посочване на сертификационния 
орган (8 байта).  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 141  
Поколение 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 — 21.08.2023 — 003.001 — 142  
Поколение 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 — 21.08.2023 — 003.001 — 143  
keySerialNumber  е сериен номер, позволяващ да се прави разлика 
между различните ключове на сертификационния орган, ако някои 
ключове са променени.  
additionalInfo  е поле от два байта за допълнително кодиране 
(специфични за сертификационния орган).  
caIdentifier  е идентификатор, позволяващ да се прави разлика 
между идентификатор на ключ на сертификационен орган и други 
идентификатори на ключове.  
Присвояване  на стойност : „01h“.  
2.46.  CompanyActivityData  
Информация, съхранена на карта на превозвач и отнасяща се до 
дейности, извършени с картата (изисквания 373 и 379 от 
приложение 1В).
  
companyPointerNewestRecord  е индексът на последния актуа­ 
лизиран companyActivityRecord.  
Присвояване  на стойност : число, съответстващо на номератора на 
записа за дейността на превозвача, като се започва с 0 за първи я 
случай на запис за дейността на превозвача в структурата.  
companyActivityRecords  е наборът от всички записи за дейността 
на превозвача.  
companyActivityRecord  е последователността от данни, свързани с 
определена дейност на превозвача.  
companyActivityType  е типът дейност на превозвача.  
companyActivityTime  е датата и часът на дейността на превозвача.  
cardNumberInformation  е номерът на картата и ако е необходимо 
— посочване на държавата членка, където е издадена картата, от 
която са изтеглени данните.  
vehicleRegistrationInformation  посочва VRN и регистриращата 
превозното средство държава членка, като тази информация може 
да е изтеглена, блокирана или разблокирана.  
downloadPeriodBegin  и downloadPeriodEnd  са периодът, за който 
са изтеглени данни от бордовото устройство, ако има такъв.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 144  
2.47.  CompanyActivityType  
Код за дейност, провеждана от определен превозвач, използващ 
своята карта на превозвач.
  
2.48.  CompanyCardApplicationIdentification  
Информация, съхранена на карта на превозвач и отнасяща се за 
идентификация на приложението на картата (изисквания 369 и 
375 от приложение 1В).
  
typeOfTachographCardId  обозначава използвания тип карта.  
cardStructureVersion  указва версията на структурата, приложена в 
картата.  
noOfCompanyActivityRecords  е броят на записите за дейността на 
превозвача, които картата може да съхранява.  
▼M3 
2.48a.  CompanyCardApplicationIdentificationV2  
Поколение 2, версия 2:  
Информация, съхранена на карта на превозвач и отнасяща се за 
идентификация на приложението на картата (изискване 375а от 
приложение IВ).
  
lengthOfFollowingData  е броят байтове, следващи записа.  
vuConfigurationLengthRange  е броят на байтове в тахографската 
карта, който е на разположение за съхраняване на конфигурации 
на бордовото устройство.  
▼B 
2.49.  CompanyCardHolderIdentification  
Информация, съхранена на карта на превозвач и отнасяща се за 
идентификация на титуляря на картата (изисквания 372 и 378 от 
приложение 1В).
  
companyName  е наименованието на превозвача, който притежава 
картата.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 145  
companyAddress  е адресът на превозвача, който притежава картата.  
cardHolderPreferredLanguage  е предпочитаният език на титуляря 
на картата.  
2.50.  ControlCardApplicationIdentification  
Информация, съхранена на контролна карта и отнасяща се за иден­  
тификация на приложението на картата (изисквания 357 и 363 от 
приложение 1В).
  
typeOfTachographCardId  обозначава използвания тип карта.  
cardStructureVersion  указва версията на структурата, приложена в 
картата.  
noOfControlActivityRecords  е броят на записите за контролната 
дейност, които картата може да съхранява.  
▼M3 
2.50a.  ControlCardApplicationIdentificationV2  
Поколение 2, версия 2:  
Информация, съхранена върху контролната карта и отнасяща се за 
идентификацията на приложението на картата (изискване 363а от 
приложение IВ).
  
lengthOfFollowingData  е броят байтове, следващи записа.  
vuConfigurationLengthRange  е броят на байтове в тахографската 
карта, който е на разположение за съхраняване на конфигурации 
на бордовото устройство.  
▼B 
2.51.  ControlCardControlActivityData  
Информация, съхранена на контролна карта и отнасяща се до 
определена контролна дейност, извършена с картата (изисквания 
361 и 367 от приложение 1В).
  
controlPointerNewestRecord  е индексът на последния актуализиран 
запис за контролната дейност.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 146  
Присвояване  на стойност : число, съответстващо на номератора на 
записа за контролната дейност, като се започва с 0 за първия сл учай 
на запис за контролната дейност в структурата.  
controlActivityRecords  е наборът от всички записи за контролната 
дейност.  
controlActivityRecord  е последователността от информация, 
свързана с една проверка.  
controlType  е типът проверка.  
controlTime  е датата и часът на проверката.  
controlledCardNumber  посочва номера на картата и държавата 
членка, издаваща проверената карта.  
controlledVehicleRegistration  посочва VRN и регистриращата 
превозното средство държава членка, в която е извършена 
проверката.  
controlDownloadPeriodBegin  и controlDownloadPeriodEnd  са 
периодът, за който са изтеглени евентуално данни.  
2.52.  ControlCardHolderIdentification  
Информация, съхранена на контролна карта и отнасяща се за иден­  
тификация на титуляря на картата (изисквания 360 и 366 от 
приложение 1В).
  
controlBodyName  е наименованието на контролния орган на 
титуляря на картата.  
controlBodyAddress  е адресът на контролния орган на титуляря на 
картата.  
cardHolderName  е фамилията и името (и презимето) на титуляря на 
контролната карта.  
cardHolderPreferredLanguage  е предпочитаният език на титуляря 
на картата.  
2.53.  ControlType  
Код, указващ дейностите, извършени по време на проверка. Този 
тип данни е свързан с изисквания 126, 274, 299, 327 и 350 от 
приложение 1В.
  
Поколение 1:  
Присвояване  на стойност  — синхронизиран  октет : „cvpdxxxx“B 
(8 бита)  
„c“B изтегляне на данни от картата:  
„0“B: не са изтеглени данни от картата при тази 
контролна дейност,  
„1“B: изтеглени са данни от картата при тази 
контролна дейност  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 147  
„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: има отпечатване при тази контролна дейност  
„d“B изобразяване:  
„0“B: няма изобразяване при тази контролна 
дейност,  
„1“B: има изобразяване при тази контролна дейност  
„e“B пътна проверка на калибрирането:  
„0“B: не са проверени параметрите за калибриране 
при тази контролна дейност,  
„1“B: проверени са параметрите за калибриране при 
тази контролна дейност  
„xxx“B RFU.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 148  
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.  
2.57.  Datef  
Дата, изразена в цифров формат, който може да се разпечата 
веднага.
  
Присвояване  на стойност : 
yyyy Година  
mm Месец  
dd Ден  
„00000000“H Указва изрично липсата на дата.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 149  
2.58.  DateOfDayDownloaded  
Поколение 2:  
датата и часът на изтеглянето на данни.
  
Присвояване  на стойност : липса на допълнителна информация.  
2.59.  DateOfDayDownloadedRecordArray  
Поколение 2:  
Датата и часът на изтегляне плюс метаданните, използвани в 
протокола за изтегляне на данни.
  
recordType  указва типа на записа (DateOfDayDownloaded).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът на CurrentDateTime в байтове.  
noOfRecords  е броят на записите в набора от записи.  
records  е наборът от дати и часове на записите за изтегляне на 
данни.  
2.60.  Distance  
Изминатото разстояние (резултат от изчислението на разликата 
между две стойности на километражния брояч на превозното 
средство).
  
Присвояване  на стойност : двоична без знак. Стойност в km в 
работния диапазон от 0 до 9 999 km.  
▼M3 
2.60a.  DownloadInterfaceVersion  
Поколение 2, версия 2:  
Код, указващ версията на интерфейса за изтегляне на данни на 
бордово устройство.
  
Присвояване  на стойност : „aabb“H:  
„aa“H „00“H: не се използва,  
„01“H: бордово устройство от поколение 2,  
„bb“H „00“H: не се използва,  
„01“H: версия 2 на бордовото устройство от поколение 2.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 150  
2.61.  DriverCardApplicationIdentification  
Информация, съхранена на карта на водач и отнасяща се до иден­ 
тификация на приложението на картата (изисквания 253 и 278 от 
приложение 1В).  
Поколение 1:
  
typeOfTachographCardId  обозначава използвания тип карта.  
cardStructureVersion  указва версията на структурата, приложена в 
картата.  
noOfEventsPerType  е броят на събитията от всеки тип, които 
картата може да запише.  
noOfFaultsPerType  е броят на неизправностите от всеки тип, които 
картата може да запише.  
activityStructureLength  указва броя на байтовете, които могат да се 
използват за съхранение на записите за дейността.  
noOfCardVehicleRecords  е броят на записите за превозното 
средство, които картата може да съдържа.  
noOfCardPlaceRecords  е броят на местоположенията, които картата 
може да запише.  
Поколение 2:  
▼M1
 
В допълнение към поколение 1 се използват следните елементи от 
данни:  
noOfGNSSADRecords  е броят на записите за общо управление по 
GNSS, които картата може да съхранява.  
noOfSpecificConditionRecords  е броят на записите за специфични 
условия, които картата може да съхранява.  
noOfCardVehicleUnitRecords  е броят на записите за използваните 
бордови устройства, които картата може да съхранява.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 151  
2.61a.  DriverCardApplicationIdentificationV2  
Поколение 2, версия 2:  
Информация, съхранена върху карта на водача и отнасяща се за 
идентификацията на приложението на картата (изискване 278а от 
приложение IВ).
  
lengthOfFollowingData  е броят байтове, следващи записа.  
noOfBorderCrossingRecords  е броят на записите за пресичане на 
граници, които картата на водача може да съхранява.  
noOfLoadUnloadRecords  е броят на записите за товаро-разтоврани 
операции, които картата на водача може да съхранява.  
noOfLoadTypeEntryRecords  е броят на записите за типа на товара, 
които картата на водача може да съхранява.  
vuConfigurationLengthRange  е броят на байтове в тахографската 
карта, който е на разположение за съхраняване на конфигурации 
на бордовото устройство.  
▼B 
2.62.  DriverCardHolderIdentification  
Информация, съхранена на карта на водач и отнасяща се за иден­ 
тификация на титуляря на картата (изисквания 256 и 281 от 
приложение 1В).
  
cardHolderName  е фамилията и името (и презимето) на титуляря на 
картата на водач.  
cardHolderBirthDate  е рождената дата на титуляря на картата на 
водач.  
cardHolderPreferredLanguage  е предпочитаният език на титуляря 
на картата.  
▼M3 
2.63.  DSRCSecurityData  
Поколение 2:  
За определението на този тип данни вж. допълнение 11.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 152  
2.64.  EGFCertificate  
Поколение 2:  
Сертификат на публичния ключ на външното устройство за GNSS 
за общо удостоверяване с бордовото устройство. Структурата на 
този сертификат е посочена в допълнение 11.
  
2.65.  EmbedderIcAssemblerId  
Дава информация за интегратора на ИС.
  
countryCode  е двубуквеният код на държавата на интегратора на 
модула съгласно ISO 3166.  
moduleEmbedder  указва интегратора на модула.  
manufacturerInformation  за вътрешна употреба на производителя.  
2.66.  EntryTypeDailyWorkPeriod  
Код, позволяващ да се прави разлика между местоположението в 
началото и в края на един дневен период на работа и условията н а 
въвеждане на тези данни.  
Поколение 1
  
Присвояване  на стойност : съгласно стандарт ISO/IЕС 8824-1.  
▼M3 
Поколение 2
  
Присвояване  на стойност : съгласно стандарт ISO/IЕС 8824-1.  
▼B 
2.67.  EquipmentType  
Код, позволяващ да се прави разлика между различните типове 
оборудване, използвани за тахографското приложение.
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 153  
Поколение 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 — 21.08.2023 — 003.001 — 154
  
едно от 10-те най-скорошни (или последни) събития или неизправн ости 
най-дългото събитие, настъпило по време на един от 10-те послед ни дена, в 
които са отбелязани събития 
едно от 5-те най-дълги събития, записани по време на 365-те пос ледни дена 
последното събитие, настъпило по време на един от 10-те последн и дена, в 
които са отбелязани събития 
най-сериозното събитие, записано по време на един от 10-те посл едни дена, 
в които са отбелязани събития  
едно от 5-те най-сериозни събития, записани по време на 365-те последни дена 
първото събитие или неизправност, настъпила след последното кал ибриране 
активно/текущо събитие или неизправност 
RFU 
зависи от производителя  
2.70.  EventFaultType  
Код, характеризиращ събитие или неизправност.
  
Присвояване  на стойност : 
Поколение 1:
  
Общи събития, 
Няма допълнителна информация, 
Вкарване на невалидна карта, 
Конфликт, предизвикан от картата, 
Припокриване във времето, 
Управление без съответната карта, 
Вкарване на карта по време на управление, 
Неправилно приключена последна картова сесия, 
Превишаване на скоростта, 
Прекъсване на електрическото захранване, 
Грешка в данните за движението, 
Конфликт относно движението на превозното средство, 
RFU,
  
Опити за нарушаване на сигурността, свързани с бордовото устрой ство, 
Няма допълнителна информация, 
Неуспешна процедурата по удостоверяване на датчика за движение,  
Неуспешна процедурата по удостоверяване на тахографската карта,  
Неразрешена смяна на датчика за движение, 
Грешка във връзка с целостта на входящите данни на картата, 
Грешка във връзка с целостта на съхранените данни на потребител , 
Грешка при трансфер на вътрешни данни, 
Неразрешено отваряне на корпус, 
Възпрепятстване на работата на хардуера, 
RFU,
  
Опити за нарушаване на сигурността, свързани с датчика за движе ние, 
Няма допълнителна информация, 
Неуспешно удостоверяване, 
Грешка във връзка с целостта на съхранените данни, 
Грешка при трансфер на вътрешни данни, 
Неразрешено отваряне на корпус, 
Възпрепятстване на работата на хардуера, 
RFU,
  
Неизправности във връзка с уреди за регистриране на данните за движението, 
Няма допълнителна информация, 
Вътрешна неизправност в бордовото устройство, 
Неизправност на печатащото устройство, 
Неизправност на екрана, 
Неизправност при изтегляне на данни, 
Неизправност на датчика, 
RFU,  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 155
  
Неизправности във връзка с карта, 
Няма допълнителна информация, 
RFU,
  
RFU,
  
Зависи от производителя.  
▼M3 
Поколение 2, версия 1:  
▼M1
 
Общи събития, 
Няма допълнителна информация, 
Вкарване на невалидна карта, 
Конфликт, предизвикан от картата, 
Припокриване във времето, 
Управление без съответната карта, 
Вкарване на карта по време на управление, 
Неправилно приключена последна картова сесия, 
Превишаване на скоростта, 
Прекъсване на електрическото захранване, 
Грешка в данните за движението, 
Конфликт относно движението на превозното средство, 
Времеви конфликт (GNSS/вътрешния часовник на бордовото устройст во), 
Грешка в комуникацията с устройството за връзка от разстояние, 
Липса на информация за местоположението от приемник на сигнали от GNSS, 
Грешка в комуникацията с външното устройство за GNSS, 
RFU,
  
Опити за нарушаване на сигурността, свързани с бордовото устрой ство, 
Няма допълнителна информация, 
Неуспешна процедура по удостоверяване на датчика за движение, 
Неуспешна процедура по удостоверяване на тахографската карта, 
Неразрешена смяна на датчика за движение, 
Грешка във връзка с целостта на входящите данни на картата 
Грешка във връзка с целостта на съхранените данни на потребител , 
Грешка при вътрешно прехвърляне на данни, 
Неразрешено отваряне на корпус, 
Възпрепятстване на работата на хардуера, 
Установяване на вмешателство във връзка с GNSS, 
Неуспешна процедура по удостоверяване на външно устройство за G NSS, 
Изтекъл сертификат на външно устройство за GNSS, 
RFU,
  
Опити за нарушаване на сигурността, свързани с датчика за движе ние, 
Няма допълнителна информация, 
Неуспешно удостоверяване, 
Грешка във връзка с целостта на съхранените данни, 
Грешка при вътрешно прехвърляне на данни, 
Неразрешено отваряне на корпус, 
Възпрепятстване на работата на хардуера, 
RFU,  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 156
  
Неизправности във връзка с уреди за регистриране на данните за движението, 
Няма допълнителна информация, 
Вътрешна неизправност в бордовото устройство, 
Неизправност на печатащото устройство, 
Неизправност на екрана, 
Неизправност при изтегляне на данни, 
Неизправност на датчика, 
Вътрешен приемник на сигнали от GNSS, 
Външно устройство за GNSS, 
Устройство за връзка от разстояние, 
Интерфейс с ITS, 
RFU,
  
Неизправности във връзка с карта, 
Няма допълнителна информация, 
RFU,
  
RFU,
  
Зависи от производителя.  
▼M3 
Поколение 2, версия 2:  
„0x“H Общи събития,  
„00“H Няма допълнителна информация,  
„01“H Вкарване на невалидна карта,  
„02“H Конфликт, предизвикан от картата,  
„03“H Припокриване във времето,  
„04“H Управление без съответната карта,  
„05“H Вкарване на карта по време на управление,  
„06“H Неправилно приключена последна картова 
сесия,  
„07“H Превишаване на скоростта,  
„08“H Прекъсване на електрическото захранване,  
„09“H Грешка в данните за движението,  
„0A“H Конфликт относно движението на превозното 
средство,  
„0B“H Времеви конфликт (GNSS/вътрешния часовник 
на бордовото устройство),  
„0C“H Грешка в комуникацията с устройството за 
връзка от разстояние,  
„0D“H Липса на информация за местоположението от 
приемник на сигнали от GNSS,  
„0E“H Грешка във връзката с външното устройство за 
GNSS,  
„0F“H Аномалия в GNSS,  
„1x“H Опити за нарушаване на сигурността, свързани 
с бордовото устройство,  
„10“H Няма допълнителна информация,  ▼M1
 02016R0799 — BG — 21.08.2023 — 003.001 — 157  
„11“H Неуспешна процедурата по удостоверяване на 
автентичността на датчика за движение,  
„12“H Неуспешна процедурата по удостоверяване на 
автентичността на тахографската карта,  
„13“H Неразрешена смяна на датчика за движение,  
„14“H Грешка във връзка с целостта на входящите 
данни на картата,  
„15“H Грешка във връзка с целостта на съхранените 
данни на потребител,  
„16“H Грешка при трансфер на вътрешни данни,  
„17“H Неразрешено отваряне на корпус,  
„18“H Възпрепятстване на работата на хардуера,  
„19“H Установяване на вмешателство в GNSS,  
„1A“H Изтекъл сертификат на външно устройство за 
GNSS,  
„1B“H Изтекъл сертификат на външно устройство за 
GNSS,  
„1C“H Несъответствие между данните от датчика за 
движение и съхранената дейност на водача  
„1D“H до „1F“H резервирано за бъдеща употреба,  
„2x“H Опити за нарушаване на сигурността, свързани 
с датчика за движение,  
„20“H Няма допълнителна информация,  
„21“H Неуспешно удостоверяване на автентичността,  
„22“H Грешка във връзка с целостта на съхранените 
данни,  
„23“H Грешка при прехвърляне на вътрешни данни,  
„24“H Неразрешено отваряне на корпус,  
„25“H Възпрепятстване на работата на хардуера,  
„26“H до „2F“H резервирано за бъдеща употреба,  
„3x“H Неизправности във връзка с уреди за регис­ 
триране на данните за движението,  
„30“H Няма допълнителна информация,  
„31“H Вътрешна неизправност в бордовото 
устройство,  
„32“H Неизправност на печатащото устройство,  
„33“H Неизправност на екрана,  
„34“H Неизправност при изтегляне на данни,  
„35“H Неизправност на датчика,  
„36“H Неизправност на вътрешния приемник на 
сигнали от GNSS,  
„37“H Външно устройство за GNSS,  
„38“H Устройство за връзка от разстояние,  
„39“H Интерфейс с ITS  
„3A“H Неизправност на вътрешния датчик,  
„3B“H до „3F“H резервирано за бъдеща употреба,  
„4x“H Неизправности във връзка с карта,  
„40“H Няма допълнителна информация,  
„41“H до „4F“H резервирано за бъдеща употреба,  
„50“H до „7F“H резервирано за бъдеща употреба,  
„80“H до „FF“H Зависи от производителя.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 158  
2.71.  ExtendedSealIdentifier  
Generation 2:  
The extended seal identifier uniquely identifies a seal (Annex IC requi­
rement 401).
  
manufacturerCode  е код на производителя на пломбата.  
Присвояване  на стойност : вж. регистрацията в базата данни, 
която ще бъде управлявана от Европейската комисия (вж. https://  
dtc.jrc.ec.europa.eu).  
sealIdentifier  е идентификатор за пломбата, който е уникален за 
производителя.  Присвояване  на стойност : буквено-цифров номер, 
уникален в областта на производителя съгласно [ISO 8859–1].  
▼B 
2.72.  ExtendedSerialNumber  
Индивидуална идентификация на оборудване. Този номер може 
също така да се използва за идентификатор на публичния ключ на 
оборудването.  
Поколение 1:
  
serialNumber  е сериен номер на оборудване, уникален за произ­ 
водителя, типа на оборудването и месеца и годината по-долу.  
monthYear  е идентификация на месеца и годината на произ­ 
водството (или на присвояването на сериен номер).  
Присвояване  на стойност : кодиране BCD на месеца (две цифри) и 
годината (последните две цифри).  
type е идентификатор на типа оборудване.  
Присвояване  на стойност : зависи от производителя, като стой­ 
ността „FFh“ е запазена.  
manufacturerCode : е цифровият код за идентификация на произ­ 
водителя на оборудването от одобрен тип.  
Поколение 2:
  
serialNumber  вж. поколение 1.  
monthYear  вж. поколение 1.  
type указва типа оборудване.  
manufacturerCode : вж. поколение 1.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 159  
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  
2.76.  GeoCoordinates  
▼M3 
Поколение 2:  
Геокординатите се кодират като цели числа. Те са кратни числа н а 
кодирането ±DDMM.M за ширината и на ±DDDMM.M за 
дължината. В случая ±DD, съответно ±DDD, указва градусите, а 
MM.M — минутите. Географската дължина и ширината на неиз­ 
вестно местоположение се представят като „7FFFFF“ по шестнайсе­  
тичната бройна система (десетично 8388607).  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 160
  
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:  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и отнасяща се до местоположението на превозното 
средство по GNSS, ако общото време на управление на МПС 
достигне кратно число на три часа (съгласно изискванията в 
подточки 305 и 353 от приложение IВ).
  
timeStamp  е датата и часът, когато общото време на управление на 
МПС достигне кратно число на три часа.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 161  
gnssPlaceRecord  съдържа информация за местоположението на 
превозното средство.  
vehicleOdometerValue  е стойността от километражния брояч, когато 
общото време на управление на МПС достигне кратно число на три 
часа. 
▼M3 
2.79a.  GNSSAuthAccumulatedDriving  
Поколение 2, версия 2:  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и предоставяща статуса на удостоверяването на автенти ч­ 
ността на местоположението по GNSS на превозното средство, ако 
общото време на управление достигне кратно число на три часа 
(изисквания 306г и 356г от приложение IВ).
  
gnssAuthADPointerNewestRecord  е индексът на последния актуа­ 
лизиран запис за статуса на удостоверяването на автентичността 
на местоположението по GNSS.  
Присвояване  на стойност  е число, съответстващо на номератора на 
записа за статуса на удостоверяването на автентичността на мест о­ 
положението по GNSS, започващо от 0 за първия случай в струк­ 
турата на запис за статуса на удостоверяването на автентичностт а на 
местоположението по GNSS.  
gnssAuthStatusADRecords  е наборът от записи, съдържащ датата и 
часа, когато общото управление достигне кратно число на три час а, 
и статуса на удостоверяването на автентичността на местополо­ 
жението по GNSS.  
2.79б.  GNSSAuthStatusADRecord  
Поколение 2, версия 2:  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки и предоставяща статуса на удостоверяването на автенти ч­ 
ността на местоположението по GNSS на превозното средство, ако 
общото време на управление достигне кратно число на три часа 
(изисквания 306в и 356в от приложение IВ). Друга информация, 
свързана със самото местоположение по GNSS, се съхранява в 
друг запис (вж. точка 2.79 GNSSAccumulatedDrivingRecord).
  
timeStamp  е датата и часът, когато общото време на управление 
достигне кратно число на три часа (които са същата дата и час, 
както в съответния GNSSAccumulatedDrivingRecord).  
authenticationStatus  е статусът на удостоверяването на автентич­ 
ността на местоположението по GNSS, когато общото време на 
управление достигне кратно число на три часа.  ▼M1
 02016R0799 — BG — 21.08.2023 — 003.001 — 162  
2.79в.  GNSSPlaceAuthRecord  
Поколение 2, версия 2:  
Информация във връзка с местоположението по GNSS на 
превозното средство (изисквания 108, 109, 110, 296, 306а, 306в,  
306д, 306ж, 356а, 356в, 356д и 356ж от приложение IВ).
  
timeStamp  е датата и часът, когато е било определено местополо­ 
жението по GNSS на превозното средство.  
gnssAccuracy  е точността на данните за местоположението по 
GNSS.  
geoCoordinates  е записаното местоположение, като се използва 
GNSS.  
authenticationStatus  е статусът на удостоверяване на автентичността 
на местоположението по GNSS, когато е било определено.  
▼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.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 163  
2.83.  HolderName  
Фамилия и име (и презиме) на титуляря на карта.
  
holderSurname  е фамилията на титуляря, като не се посочва 
господин, госпожа или госпожица.  
Присвояване  на стойност : ако картата не е лична, holderSurname 
съдържа същите данни, като companyName, workshopName или 
controlBodyName.  
holderFirstNames  е името (и презимето) и инициалите на титуляря.  
▼M3 
2.84.  Резервирана  за бъдеща  употреба  
▼B 
Поколение 2:  
Информация дали приемникът на сигнали от GNSS е вътрешен или 
външен за бордовото устройство. Вярно означава, че приемникът н а 
сигнали от GNSS е вътрешен за бордовото устройство. Невярно 
означава, че приемникът на сигнали от GNSS е външен.
  
2.85.  K-ConstantOfRecordingEquipment  
Константа на уреда за регистриране на данните за движението 
(определение м).
  
Присвояване  на стойност : импулси на километър в работния 
диапазон от 0 до 64 255 имп./km.  
▼M1 
2.86.  KeyIdentifier  
Уникален идентификатор на публичен ключ, използван за посочване  
и избор на ключа. Този идентификатор идентифицира също така 
титуляря на ключа.
  
Първият избор е подходящ за указване на публичния ключ на 
бордово устройство, тахографска карта или външно устройство за 
GNSS.  
Вторият избор е подходящ за указване на публичния ключ на 
бордово устройство (в случай че серийният номер на бордовото 
устройство е неизвестен към момента на генериране на серти­ 
фиката).  
Третият избор е подходящ за указване на публичния ключ на 
държава членка.  
▼B 
2.87.  KMWCKey  
Поколение 2:  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 164  
Ключ AES и съответната му версия на ключа за сдвояването на 
бордово устройство — датчик за движение. За подробни данни 
вж. допълнение 11.
  
kMWCKey  е дължината на ключа AES, съединен с ключа, 
използван за сдвояването бордово устройство — датчик за 
движение.  
keyVersion  указва версията на ключа AES.  
2.88.  Language  
Код, идентифициращ език.
  
Присвояване  на стойност : код, съставен от две малки букви 
съгласно стандарт ISO 639.  
2.89.  LastCardDownload  
Дата и час, съхранени на карта на водач, на последното изтеглян е на 
данните от картата (за цели, различни от извършването на 
проверка). Изисквания 257 и 282 от приложение 1В. Тази дата 
може да се актуализира от бордово устройство или всеки четец на  
карта.
  
Присвояване  на стойност : липса на допълнителна информация.  
▼M3 
2.89a.  LengthOfFollowingData  
Поколение 2, версия 2:  
Индикатор за дължината за разширяеми записи.
  
Присвояване  на стойност : вж. допълнение 2.  
▼B 
2.90.  LinkCertificate  
Поколение 2:  
Сертификатът за връзка между двойките ключове на основния евро­  
пейски сертификационен орган.
  
▼M3 
2.90a.  LoadType  
Поколение 2, версия 2:  
Код, идентифициращ въведения тип на товара.
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 165  
Присвояване  на стойност : 
“ „00H Неопределен тип на товара,  
„01“H Стоки,  
„02“H Пътници,  
„03“H „FF“H Резервирано за бъдеща употреба.  
▼B 
2.91.  L-TyreCircumference  
Действителна обиколка на колелата (определение ф).
  
Присвояване  на стойност : двоична без знак, стойност в 1/8 mm и в 
работния диапазон от 0 до 8 031 mm.  
▼M1 
2.92.  MAC  
Поколение 2:  
Сума за криптографски контрол с дължина от 8, 12 или 16 байта, 
съответстваща на криптографските поредици, посочени в 
допълнение 11.
  
▼B 
2.93.  ManualInputFlag  
Код, позволяващ да се разбере дали титулярят на картата ръчно е  
въвел дейностите на водача при вкарване на картата (изискване 0 81 
от приложение 1Б и изискване 102 от приложение 1В).
  
Присвояване  на стойност : липса на допълнителна информация.  
2.94.  ManufacturerCode  
Код за идентификация на производителя на оборудване от одобрен 
тип.
 
Лабораторията, компетентна за изпитванията за оперативна съвмес ­ 
тимост, поддържа и публикува на своя уебсайт списъка с кодове н а 
производителите (изискване 454 от приложение 1В).  
Разработчиците на тахографско оборудване получават временно 
ManufacturerCodes след подадена заявка до лабораторията, 
компетентна за изпитванията за оперативна съвместимост.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 166  
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:  
Публичен ключ на държава членка.
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 167  
2.99.  Name  
Име.
  
codePage  указва набор от символи, определен в глава 4.  
name  е име, кодирано, като е използван указаният набор от 
символи.  
2.100.  NationAlpha  
Буквеният код за указване на държавата трябва да бъде в съот­ 
ветствие с отличителните знаци, използвани върху превозни 
средства при международен трафик (съгласно Виенската 
конвенция на ООН от 1968 г. за движението по пътищата).
  
Буквените и цифровите кодове за държави трябва да се съдържат в  
списък, поддържан на уебсайта на лабораторията, определена да 
извършва изпитванията за оперативна съвместимост, както е 
посочено в изискване 440 от приложение 1В.  
2.101.  NationNumeric  
Цифров код за указване на държавата.
  
Присвояване  на стойност : вж. данните тип 2.100 (NationAlpha).  
Изменението или актуализирането на спецификацията NationAlpha 
или NationNumeric, описана в параграфа по-горе, трябва да се 
извършва само след като определената лаборатория получи стано­ 
вищата на производителите на бордови устройства на цифрови и 
интелигентни тахографи от одобрен тип.  
▼M3 
2.101а.  NoOfBorderCrossingRecords  
Поколение 2, версия 2:  
Брой на записите за пресичане на граници, които картата на вода ч 
или картата за монтаж и настройки може да съхранява.
  
Присвояване  на стойност : вж. допълнение 2.  
▼B 
2.102.  NoOfCalibrationRecords  
Брой на записите на калибриранията, които картата за монтаж и 
настройки може да съхранява.  
Поколение 1:
  
Присвояване  на стойност : вж. допълнение 2.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 168  
Поколение 2:
  
Присвояване  на стойност : вж. допълнение 2.  
2.103.  NoOfCalibrationsSinceDownload  
Брояч, указващ броя на калибриранията, извършени с една карта з а 
монтаж и настройки от последното изтегляне на данни от нея 
(изисквания 317 и 340 от приложение 1В).
  
Присвояване  на стойност : липса на допълнителна информация.  
2.104.  NoOfCardPlaceRecords  
Брой на записите на местоположенията, които картата на водач ил и 
картата за монтаж и настройки може да съхранява.  
Поколение 1:
  
Присвояване  на стойност : вж. допълнение 2.  
Поколение 2:
  
Присвояване  на стойност : вж. допълнение 2.  
2.105.  NoOfCardVehicleRecords  
Брой на записите на използваните превозни средства, които карта та 
на водач или картата за монтаж и настройки може да съхранява.
  
Присвояване  на стойност : вж. допълнение 2.  
2.106.  NoOfCardVehicleUnitRecords  
Поколение 2:  
Брой на записите на използваните бордови устройства, които 
картата на водач или картата за монтаж и настройки може да 
съхранява.
  
Присвояване  на стойност : вж. допълнение 2.  
2.107.  NoOfCompanyActivityRecords  
Брой на записите на дейностите на превозвача, които картата на 
превозвач може да съхранява.
  
Присвояване  на стойност : вж. допълнение 2.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 169  
2.108.  NoOfControlActivityRecords  
Брой на записите за контролната дейност, които контролната карт а 
може да съхранява.
  
Присвояване  на стойност : вж. допълнение 2.  
2.109.  NoOfEventsPerType  
Брой на събитията от всеки тип, които картата може да съхранява .
 
Присвояване  на стойност : вж. допълнение 2.  
2.110.  NoOfFaultsPerType  
Брой на неизправностите от всеки тип, които картата може да 
съхранява.
  
Присвояване  на стойност : вж. допълнение 2.  
▼M1 
2.111.  NoOfGNSSADRecords  
Поколение 2:  
Брой на записите за общо управление по GNSS, които картата може  
да съхранява.
  
Присвояване  на стойност : вж. допълнение 2.  
▼M3 
2.111а.  NoOfLoadUnloadRecords  
Поколение 2, версия 2:  
Брой на записите за товаро-разтоврни операции, които картата мо же 
да съхранява.
  
Присвояване  на стойност : вж. допълнение 2.  
▼B 
2.112.  NoOfSpecificConditionRecords  
Поколение 2:  
Брой на записите за специфични условия, които картата може да 
съхранява.
  
Присвояване  на стойност : вж. допълнение 2.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 170  
2.112а.  NoOfLoadTypeEntryRecords  
Поколение 2, версия 2:  
Брой на записите за типа на товара, които картата на водач или 
картата за монтаж и настройки може да съхранява.
  
Присвояване  на стойност : вж. допълнение 2.  
▼B 
2.113.  OdometerShort  
Стойност от километражния брояч на превозното средство в 
съкратена форма.
  
Присвояване  на стойност : двоична без знак. Стойност в km в 
работния диапазон от 0 до 9 999 999 km.  
2.114.  OdometerValueMidnight  
Стойността от километражния брояч в полунощ от определено 
денонощие (изискване 090 от приложение 1Б и изискване 113 от 
приложение 1В).
  
Присвояване  на стойност : липса на допълнителна информация.  
▼M3 
2.114а.  OperationType  
Поколение 2, версия 2:  
Код, идентифициращ вида на въведената операция.
  
Присвояване  на стойност : 
„00“H Резервирано за бъдеща употреба,  
„01“H Операция по товарене,  
„02“H Операция по разтоварване,  
„03“H Операция по едновременно товарене и разто­ 
варване,  
„04“H „FF“H Резервирано за бъдеща употреба.  
▼B 
2.115.  OdometerValueMidnightRecordArray  
Поколение 2:  
OdometerValueMidnight плюс метаданните, използвани в протокола 
за изтегляне на данни.
  
recordType  указва типа на записа (OdometerValueMidnight).  
Присвояване  на стойност : вж. RecordType.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 171  
recordSize  е размерът на OdometerValueMidnight в байтове.  
noOfRecords  е броят на записите в набора от записи.  
records  е наборът от записи на OdometerValueMidnight.  
2.116.  OverspeedNumber  
Брой на събитията „превишаване на скоростта“ след последната 
проверка за превишаването на скоростта.
  
Присвояване  на стойност : 0 означава, че никакво събитие „преви­ 
шаване на скоростта“ не е настъпило след последната проверка за  
превишаването на скоростта, 1 означава, че едно събитие от този  
тип е настъпило след последната проверка за превишаването на 
скоростта … 255 означава, че броят на събитията „превишаване 
на скоростта“, настъпили след последната проверка за превиша­ 
ването на скоростта, е равен на 255 или надвишава тази стойност . 
▼M3 
2.116а.  PlaceAuthRecord  
Информация относно местоположението в началото или в края на 
един дневен период на работа (изисквания 108, 271, 296, 324 и 3 47 
от приложение IВ).  
Поколение 2, версия 2:
  
entryTime  е датата и часът, свързани с въвеждането.  
entryTypeDailyWorkPeriod  е типът въвеждане.  
dailyWorkPeriodCountry  е въведената държава.  
dailyWorkPeriodRegion  е въведеният регион.  
vehicleOdometerValue  е стойността от километражния брояч в часа 
на въвеждане на местоположението.  
EntryGNSSPlaceAuthRecord  е записаното местоположение, статуса 
на удостоверяването на автентичността на GNSS и времето.  
2.116б.  PlaceAuthStatusRecord  
Поколение 2, версия 2:  
Информация, съхранена на карта на водач или карта за монтаж и 
настройки, предоставяща статуса на удостоверяването на автентич ­ 
ността на мястото, където започва или приключва дневният период  
на работа (изисквания 306а и 356а от приложение IB). Друга 
информация, свързана със самото място, се съхранява в друг 
запис (вж. точка 2.117 PlaceRecord).  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 172
  
entryTime  е датата и часът, свързани с въвеждането (които са 
същата дата и час, както в съответния PlaceRecord).  
authenticationStatus  е статусът на удостоверяването на автентич­ 
ността на записаното местоположение по GNSS.  
▼B 
2.117.  PlaceRecord  
Информация относно местоположението в началото или в края на 
един дневен период на работа (изисквания 108, 271, 296, 324 и 3 47 
от приложение 1В).  
Поколение 1:
  
entryTime  е датата и часът във връзка с въведените данни.  
entryTypeDailyWorkPeriod  е типът въведени данни.  
dailyWorkPeriodCountry  е въведената държава.  
dailyWorkPeriodRegion  е въведеният регион.  
vehicleOdometerValue  е стойността от километражния брояч в часа 
на въвеждане на местоположението.  
Поколение 2:
  
В допълнение към поколение 1 се използва следният компонент:  
entryGNSSPlaceRecord  е записаното местоположение и час.  
▼M3 
2.117а.  PositionAuthenticationStatus  
Поколение 2, версия 2:
  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 173  
Присвояване  на стойност  (вж. допълнение 12):  
„00“H Автентичността не е удостоверена (вж. 
допълнение 12, изискване GNS_39),  
„01“H Автентичността е удостоверена (вж. допълнение 
12, изискване GNS_39),  
„02“H „FF“H Резервирано за бъдеща употреба.  
▼B 
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.
  ▼M3
02016R0799 — BG — 21.08.2023 — 003.001 — 174  
Присвояване  на стойност :
 
► (1) M1 
► (2) M3 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,  
►M3 VuBorderCrossingRecord, 
VuLoadUnloadRecord, 
VehicleRegistrationIdentification, 
Резервирано за бъдеща употреба, ◄ 
Зависи от производителя.  
2.121.  RegionAlpha  
Буквено означение на регион в определена държава.
  
Поколение 1:  
Присвояване  на стойност :
 ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 175  
Поколение 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 — 21.08.2023 — 003.001 — 176  
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 — 21.08.2023 — 003.001 — 177  
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 — 21.08.2023 — 003.001 — 178
  
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 — 21.08.2023 — 003.001 — 179  
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 — 21.08.2023 — 003.001 — 180  
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 — 21.08.2023 — 003.001 — 181  
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 — 21.08.2023 — 003.001 — 182  
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 — 21.08.2023 — 003.001 — 183  
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 — 21.08.2023 — 003.001 — 184  
2.155.  Speed  
Скорост на превозното средство (km/h).
  
Присвояване  на стойност : километри на час в работния диапазон 
от 0 до 220 km/h.  
2.156.  SpeedAuthorised  
Максимална разрешена скорост на превозното средство (опред­ 
еление зз).
  
2.157.  SpeedAverage  
Средна скорост, измерена в рамките на предварително определен 
период от време (km/h).
  
2.158.  SpeedMax  
Максимална скорост, измерена в рамките на предварително 
определен период от време.
  
▼M3 
2.158а.  TachographCardsGen1Suppression  
Поколение 2, версия 2:  
Способност на бордово устройство от второ поколение да използва  
първо поколение карти на водач, контролни карти и карти на 
превозвач (вж. допълнение 15, MIG_002).
  
Присвояване  на стойност : 
„0000“H Бордовото устройство е способно да използва 
тахографски карти от първо поколение 
(стойност по подразбиране),  
„A5E3“H Бордовото устройство не е способно да 
използва тахографски карти от първо 
поколение,  
Всички други стойности 
Не се използва.  
▼B 
2.159.  TachographPayload  
Поколение 2:  
За определението на този тип данни вж. допълнение 14.  
▼M1 
2.160.  Reserved for future use  
▼B 
2.161.  TDesSessionKey  
Поколение 1:  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 185  
Троен ключ на сесия 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.  
2.164.  VehicleIdentificationNumber  
Идентификационен номер на превозното средство (VIN), отнасящ 
се за цялото превозно средство, обикновено сериен номер на шаси  
или номер на рама.
  
Присвояване  на стойност : съгласно стандарт ISO 3779.  
2.165.  VehicleIdentificationNumberRecordArray  
Поколение 2:  
Идентификационният номер на превозното средство плюс мета­ 
данните, използвани в протокола за изтегляне на данни.
  
recordType  указва типа запис (VehicleIdentificationNumber).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът на VehicleIdentificationNumber в байтове.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 186  
noOfRecords  е броят на записите в набора от записи.  
records  е наборът от идентификационни номера на превозни 
средства.  
2.166.  VehicleRegistrationIdentification  
Идентификация на превозно средство, която е уникална за Европа 
(VRN и държава членка).
  
vehicleRegistrationNation  е държавата, в която е извършена регист­ 
рацията на превозното средство.  
vehicleRegistrationNumber  е регистрационният номер на 
превозното средство (VRN).  
▼M3 
2.166а.  VehicleRegistrationIdentificationRecordArray  
Поколение 2, версия 2:  
Регистрационната идентификация на превозното средство плюс 
метаданните, използвани в протокола за изтегляне на данни.
  
recordType  указва типа на записа (VehicleRegistrationIdentification).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът на VehicleRegistrationIdentification в байтове.  
noOfRecords  е броят на записите в набора от записи.  
records  е наборът от регистрационната идентификация на 
превозното средство.  
▼B 
2.167.  VehicleRegistrationNumber  
Регистрационен номер на превозното средство (VRN). Регистраци­ 
онният номер се определя от компетентния орган за регистрацията  
на превозните средства.
  
codePage  указва набор от символи, определен в глава 4.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 187  
vehicleRegNumber  е VRN, кодиран с използването на указания 
набор от символи.  
Присвояване  на стойност : зависи от държавата.  
2.168.  VehicleRegistrationNumberRecordArray  
▼M3 
Поколение 2, версия 1:  
▼B 
Регистрационният номер на превозното средство плюс метаданните,  
използвани в протокола за изтегляне на данни.
  
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:  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 188  
Информация, съхранена в бордово устройство и отнасяща се за 
промените на дейността и/или промените на състоянието при 
управление и/или промените на статуса на картата за определен 
календарен ден (изискване 084 от приложение 1Б и изисквания 
105, 106 и 107 от приложение 1В) и за статуса на процепите в 
00.00 часа на този ден.
  
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:
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 189  
Присвояване  на стойност : не е указана.  
Поколение 2:
  
Присвояване  на стойност : 
Номерът на одобрение е този, който е публикуван на съответната 
интернет страница на Европейската комисия, т.е. например, като се 
включват тиренца, ако има. Номерът на одобрение се подравнява 
отляво.  
2.173.  VuCalibrationData  
Поколение 1:  
Информация, съхранена в бордово устройство и отнасяща се за 
калибриранията на уредите за регистриране на данните за 
движението (изискване 098 от приложение 1Б).
  
noOfVuCalibrationRecords  е броят записи, които съдържа наборът 
vuCalibrationRecords.  
vuCalibrationRecords  е наборът записи от калибриранията.  
2.174.  VuCalibrationRecord  
Информация, съхранена в бордово устройство и отнасяща се за 
калибриране на уредите за регистриране на данните за движението  
(изискване 098 от приложение 1Б и изисквания 119 и 120 от 
приложение 1В).  
Поколение 1:
  
calibrationPurpose  е целта на калибрирането.  
workshopName, workshopAddress  са наименованието и адресът на 
сервиза.  
workshopCardNumber  идентифицира картата за монтаж и 
настройки, използвана при калибрирането.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 190  
workshopCardExpiryDate  е датата на край на валидност на картата.  
vehicleIdentificationNumber  е VIN.  
vehicleRegistrationIdentification  съдържа VRN и регистриращата 
държава членка.  
wVehicleCharacteristicConstant  е характеристичният коефициент на 
превозното средство.  
kConstantOfRecordingEquipment  е константата на уреда за регис­ 
триране на данните за движението.  
lTyreCircumference  е действителната обиколка на колелата.  
tyreSize  е обозначение на размерите на гумите, монтирани на 
превозното средство.  
authorisedSpeed  е разрешената скорост на превозното средство.  
oldOdometerValue и newOdometerValue  са старата и новата 
стойност, отчетени от километражния брояч.  
oldTimeValue, newTimeValue  са старите и новите стойности на 
датата и часа.  
nextCalibrationDate  е датата на следващото калибриране на типа в 
CalibrationPurpose, което оправомощеният инспектиращ орган 
трябва да извърши.  
▼M3 
Поколение 2, версия 1:  
▼B
 
В допълнение към поколение 1 се използва следният елемент от 
данни:  
sealDataVu  дава информация за пломбите, поставени върху 
различните компоненти на превозното средство.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 191  
Поколение 2, версия 2:
  
В допълнение към поколение 1 се използват следните елементи от 
данни:  
sensorSerialNumber  е серийният номер на датчик за движение, 
свързан с бордовото устройство в края на калибрирането.  
sensorGNSSSerialNumber  е серийният номер на външното 
устройство за GNSS, свързано с бордовото устройство в края на 
калибрирането (ако има такова).  
rcmSerialNumber  е серийният номер на устройството за връзка от 
разстояние, свързано с бордовото устройство в края на калибри­ 
рането (ако има такова).  
sealDataVu  дава информация за пломбите, поставени върху 
различните компоненти на превозното средство.  
byDefaultLoadType  е типът на товара по подразбиране на 
превозното средство (присъства само във версия 2).  
calibrationCountry  е държавата, в която е извършено калибри­ 
рането.  
calibrationCountryTimestamp  е датата и часът, когато от 
приемника на сигнали от GNSS е предоставено местоположението, 
използвано за определяне на държавата, в която е извършено кали б­ 
рирането.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 192  
2.175.  VuCalibrationRecordArray  
Поколение 2:  
Информация, съхранена в бордово устройство и отнасяща се за 
калибриранията на уредите за регистриране на данните за 
движението (изисквания 119 и 120 от приложение 1В).
  
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:
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 193  
cardHolderName  е фамилията, името и презимето на титуляря на 
картата на водач или картата за монтаж и настройки, съхранени н а 
картата.  
fullCardNumber  е типът карта, държавата членка, която я издава, и 
нейният номер на карта, съхранени на картата.  
cardExpiryDate  е датата на изтичане на валидността на картата, 
както е съхранена на нея.  
cardInsertionTime  е датата и часът на вкарване на картата.  
vehicleOdometerValueAtInsertion  е стойността, отчетена от кило­ 
метражния брояч при вкарване на картата.  
cardSlotNumber  е процепът, където се вкарва картата.  
cardWithdrawalTime  е датата и часът на изваждане на картата.  
vehicleOdometerValueAtWithdrawal  е стойността, отчетена от 
километражния брояч при изваждане на картата.  
previousVehicleInfo  съдържа информация относно предишното 
превозно средство, използвано от водача, както е съхранена на 
картата.  
manualInputFlag  е знак, позволяващ да се разбере дали титулярят 
на картата е извършил ръчно въвеждане на дейностите на водача 
при вкарване на картата.  
Поколение 2:
  
Вместо fullCardNumber структурата на данните от поколение 2 
използва следния елемент от данни.  
fullCardNumberAndGeneration  е типът карта, държавата членка, 
която я издава, нейният номер на карта и поколението, съхранени  
на картата.  
2.178.  VuCardIWRecordArray  
Поколение 2:  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 194  
Информация, съхранена в бордово устройство и отнасяща се до 
циклите на вкарване и изваждане на карти на водач или карти за 
монтаж и настройки в бордовото устройство (изискване 103 от 
приложение 1В).
  
recordType  указва типа запис (VuCardIWRecord).  Присвояване  на 
стойност : вж. RecordType.  
recordSize  е размерът на VuCardIWRecord в байтове.  
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В).
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 195  
recordType  указва типа запис (VuCardRecord).  Присвояване  на 
стойност : вж. RecordType.  
recordSize  е размерът на VuCardRecord в байтове.  
noOfRecords  е броят на записите в набора от записи.  
records  е набор от записи относно използваните тахографски карти 
с бордовото устройство.  
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  е набор от записи за блокировките на 
превозвач.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 196  
2.184.  VuCompanyLocksRecord  
Информация, съхранена в бордово устройство и отнасяща се до 
блокировка на превозвач (изискване 104 от приложение 1Б и 
изискване 128 от приложение 1В).  
Поколение 1:
  
lockInTime, lockOutTime  са датата и часът на блокиране и отбло­ 
киране.  
companyName, companyAddress  са наименованието и адресът на 
превозвача, свързан с блокирането.  
companyCardNumber  идентифицира картата, използвана при 
блокирането.  
Поколение 2:
  
Вместо companyCardNumber структурата на данните от поколение 2 
използва следния елемент от данни.  
companyCardNumberAndGeneration  идентифицира картата, вклю­ 
чително поколението ѝ, използвана при блокирането.  
2.185.  VuCompanyLocksRecordArray  
Поколение 2:  
Информация, съхранена в бордово устройство и отнасяща се за 
блокировките на превозвач (изискване 128 от приложение 1В).
  
recordType  указва типа запис (VuCompanyLocksRecord).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът на VuCompanyLocksRecord в байтове.  
noOfRecords  е броят на записите в набора от записи. Стойност 
0..255.  
records  е наборът от записи за блокировките на превозвач.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 197  
2.185а.  VuConfigurationLengthRange  
Поколение 2, версия 2:  
Брой байтове в тахографската карта, които са на разположение за  
съхранение на конфигурациите на бордовото устройство.
  
Присвояване  на стойност : вж. допълнение 2.  
▼B 
2.186.  VuControlActivityData  
Поколение 1:  
Информация, съхранена в бордово устройство и отнасяща се за 
проверките, извършени с помощта на това устройство (изискване 
102 от приложение 1Б).
  
noOfControls  е броят на проверките, посочени в vuControlActivity­
Records.  
vuControlActivityRecords  е наборът от записи за контролната 
дейност.  
2.187.  VuControlActivityRecord  
Информация, съхранена в бордово устройство и отнасяща се за 
проверка, извършена, като е използвано това устройство (изисква не 
102 от приложение 1Б и изискване 126 от приложение 1В).  
Поколение 1:
  
controlType  е типът проверка.  
controlTime  е датата и часът на проверката.  
controlCardNumber  идентифицира контролната карта, използвана 
за проверката.  
downloadPeriodBeginTime  е началото на периода на изтегляне на 
данните.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 198  
downloadPeriodEndTime  е краят на периода на изтегляне на 
данните.  
Поколение 2:
  
Вместо controlCardNumber структурата на данните от поколение 2 
използва следния елемент от данни.  
controlCardNumberAndGeneration  идентифицира контролната 
карта, включително поколението ѝ, използвана за проверката.  
2.188.  VuControlActivityRecordArray  
Поколение 2:  
Информация, съхранена в бордово устройство и отнасяща се до 
проверките, извършени с помощта на това устройство (изискване 
126 от приложение 1В).
  
recordType  указва типа запис (VuControlActivityRecord).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът на VuControlActivityRecord в байтове.  
noOfRecords  е броят на записите в набора от записи.  
records  е наборът от записи за контролната дейност на бордовото 
устройство.  
2.189.  VuDataBlockCounter  
Брояч, записан на карта и идентифициращ последователно циклите 
на вкарване и изваждане на картата в бордови устройства.
  
Присвояване  на стойност : последователни номера, с максималната 
стойност от 9999, като се започва от 0.  
2.190.  VuDetailedSpeedBlock  
Информация, съхранена в бордово устройство и отнасяща се до 
подробните данни за скоростта на превозното средство в 
продължение на една минута, по време на която превозното 
средство е било в движение (изискване 093 от приложение 1Б и 
изискване 116 от приложение 1В).  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 199
  
speedBlockBeginDate  е датата и часът на първата стойност на 
скоростта в блока.  
speedsPerSecond  е хронологичната последователност на скоростите, 
измерени във всички секунди на минутата, започвайки при 
скоростта от speedBlockBeginDate (включена).  
2.191.  VuDetailedSpeedBlockRecordArray  
Поколение 2:  
Информация, съхранена в бордово устройство и отнасяща се за 
подробните данни за скоростта на превозното средство.
  
recordType  указва типа запис (VuDetailedSpeedBlock).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът на VuDetailedSpeedBlock в байтове.  
noOfRecords  е броят на записите в набора от записи.  
records  е наборът от блокове с подробни данни за скоростта.  
2.192.  VuDetailedSpeedData  
Поколение 1:  
Информация, съхранена в бордово устройство и отнасяща се до 
подробните данни за скоростта на превозното средство.
  
noOfSpeedBlocks  е броят на блоковете с данни за скоростта в 
набора vuDetailedSpeedBlocks.  
vuDetailedSpeedBlocks  е наборът блокове с подробни данни за 
скоростта.  
▼M3 
2.192а.  VuDigitalMapVersion  
Поколение 2, версия 2:  
Версия на цифровата карта, съхранена в бордовото устройство 
(изискване 133й от приложение IB).
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 200  
Присвояване  на стойност : както е посочено на специалния 
защитен уебсайт, поддържан от Европейската комисия (изискване 
133к от приложение IB).  
▼B 
2.193.  VuDownloadablePeriod  
Най-старите и най-скорошните дати, за които определено бордово 
устройство съдържа данни относно дейностите на водачите 
(изисквания 081, 084 или 087 от приложение 1Б и изисквания 
102, 105 и 108 от приложение 1В).
  
minDownloadableTime  е датата и часът на най-отдалеченото във 
времето вкарване на карта, промяна на дейността или въвеждане 
на местоположението, съхранени в бордовото устройство.  
maxDownloadableTime  е датата и часът на последното вкарване на 
карта, промяна на дейността или въвеждане на местоположението, 
съхранени в бордовото устройство.  
2.194.  VuDownloadablePeriodRecordArray  
Поколение 2:  
VUDownloadablePeriod плюс метаданните, използвани в протокола 
за изтегляне на данни.
  
recordType  указва типа запис (VuDownloadablePeriod).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът на VuDownloadablePeriod в байтове.  
noOfRecords  е броят на записите в набора от записи.  
records  е наборът от записи от VuDownloadablePeriod.  
2.195.  VuDownloadActivityData  
Информация, съхранена в бордово устройство и отнасяща се за 
последното ѝ изтегляне (изискване 105 от приложение 1Б и 
изискване 129 от приложение 1В).  
Поколение 1:
  
downloadingTime  е датата и часът на изтегляне на данни.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 201  
fullCardNumber  идентифицира картата, използвана за разрешаване 
на изтеглянето на данните.  
companyOrWorkshopName  е наименованието на превозвача или 
сервиза.  
Поколение 2:
  
Вместо fullCardNumber структурата на данните от поколение 2 
използва следния елемент от данни.  
fullCardNumberAndGeneration  идентифицира картата, вклю­ 
чително поколението ѝ, използвана за разрешаване на изтеглянето  
на данните.  
2.196.  VuDownloadActivityDataRecordArray  
Поколение 2:  
Информация, свързана с последните изтеглени данни за бордовото 
устройство (изискване 129 от приложение 1В).
  
recordType  указва типа запис (VuDownloadActivityData).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът на VuDownloadActivityData в байтове.  
noOfRecords  е броят на записите в набора от записи.  
records  е наборът от записи на изтеглени данни за дейността.  
2.197.  VuEventData  
Поколение 1:  
Информация, съхранена в бордово устройство и отнасяща се за 
събития (изискване 094 от приложение 1Б с изключение на 
събитията „превишаване на скоростта“).
  
noOfVuEvents  е броят на събитията, посочени в набора vuEven­
tRecords.  
vuEventRecords  е набор записи за събития.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 202  
2.198.  VuEventRecord  
Информация, съхранена в бордово устройство и отнасяща се за 
събитие (изискване 094 от приложение 1Б и изискване 117 от 
приложение 1В с изключение на събитията „превишаване на 
скоростта“).  
Поколение 1:
  
eventType  е типът на събитието.  
eventRecordPurpose  е целта на записване на събитието.  
eventBeginTime  е датата и часът на начало на събитието.  
eventEndTime  е датата и часът на край на събитието.  
cardNumberDriverSlotBegin  идентифицира картата, вкарана в 
процепа за водача в началото на събитието.  
cardNumberCodriverSlotBegin  идентифицира картата, вкарана в 
процепа за втория водач в началото на събитието.  
cardNumberDriverSlotEnd  идентифицира картата, вкарана в 
процепа за водача в края на събитието.  
cardNumberCodriverSlotEnd  идентифицира картата, вкарана в 
процепа за втория водач в края на събитието.  
similarEventsNumber  е броят на сходните събития през същия ден.  
Тази последователност може да се използва за всички събития, 
различни от „превишаване на скоростта“.  
Поколение 2:
  
В допълнение към поколение 1 се използват следните елементи от 
данни:  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 203  
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.  
recordSize  е размерът на VuEventRecord в байтове.  
noOfRecords  е броят на записите в набора от записи.  
records  е набор записи за събития.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 204  
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 — 21.08.2023 — 003.001 — 205  
Поколение 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 — 21.08.2023 — 003.001 — 206  
2.203.  VuGNSSADRecord  
▼M3 
Поколение 2, версия 1:  
▼M1 
Информация, съхранена в бордово устройство и отнасяща се за 
местоположението на превозното средство по GNSS, ако общото 
време на управление на МПС достигне кратно число на три часа 
(съгласно изискванията в подточки 108 и 110 от приложение IВ).
  
timeStamp  е датата и часът, когато общото време на управление на 
МПС достигне кратно число на три часа.  
cardNumberAndGenDriverSlot  идентифицира картата, вкарана в 
процепа за водача, в т.ч. поколението ѝ.  
cardNumberAndGenCodriverSlot  идентифицира картата, вкарана в 
процепа за втория водач, в т.ч. поколението ѝ.  
gnssPlaceRecord  съдържа информация за местоположението на 
превозното средство.  
vehicleOdometerValue  е стойността от километражния брояч, 
когато общото време на управление на МПС достигне кратно 
число на три часа.  
▼M3 
Поколение 2, версия 2:  
Информация, съхранена в бордовото устройство и отнасяща се за 
местоположението по GNSS на превозното средство, ако общото 
време на управление на водача достигне кратно число на три часа  
(изисквания 108 и 110 от приложение IВ).
  
В поколение  2, версия  2, вместо gnssPlaceRecord, се използва 
gnssPlaceAuthRecord, което съдържа и статуса на удостоверяване 
на автентичността на GNSS.  
2.203а.  VuBorderCrossingRecord  
Поколение 2, версия 2:  
Информация, съхранена в бордовото устройство и отнасяща се до 
преминаването на граница от превозното средство, когато то е 
пресекло границата на държава (изисквания 133а и 133б от 
приложение IB).  ▼M1
 02016R0799 — BG — 21.08.2023 — 003.001 — 207
  
cardNumberAndGenDriverSlot  идентифицира картата, включително 
поколението ѝ, вкарана в процепа за водача.  
cardNumberAndGenCodriverSlot  идентифицира картата, вклю­ 
чително поколението ѝ, вкарана в процепа за втория водач.  
countryLeft  е държавата, която превозното средство е напуснало, 
въз основа на последната налична позиция преди установяването н а 
пресичането на граница. „Останалата част на света“ (NationNumer ic 
код „FF“H по шестнайсетичната бройна система) се използва, 
когато бордовото устройство не е в състояние да определи 
държавата, в която се намира превозното средство (напр. 
настоящата държава не е част от съхранените цифрови карти).  
countryEntered  е държавата, в която превозното средство е влязло. 
„Останалата част на света“ (NationNumeric код „FF“H по шестнай­  
сетичната бройна система) се използва, когато бордовото 
устройство не е в състояние да определи държавата, в която се 
намира превозното средство (напр. настоящата държава не е част 
от съхранените цифрови карти).  
gnssPlaceAuthRecord  съдържа информация, свързана с местополо­ 
жението на превозното средство, когато е било установено преси­  
чането на граница, както и неговия статус на удостоверяване на 
автентичността.  
vehicleOdometerValue  е стойността на километражния брояч, 
когато бордовото устройство е установило, че превозното 
средство е пресекло границата на държава.  
2.203б.  VuBorderCrossingRecordArray  
Поколение 2, версия 2:  
Информация, съхранена в бордово устройство и отнасяща се до 
пресичането на граници от превозното средство (изискване 133в 
от приложение IВ).
  
recordType  указва типа на записа (VuBorderCrossingRecord).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът на VuBorderCrossingRecord в байтове.  
noOfRecords  е броят на записите в набора от записи.  
records  е набор записи за пресичания на граници.  
▼M1 
2.204.  VuGNSSADRecordArray  
Поколение 2:  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 208  
Информация, съхранена в бордово устройство и отнасяща се за 
местоположението на превозното средство по GNSS, ако общото 
време на управление на МПС достигне кратно число на три часа 
(съгласно изискванията в подточки 108 и 110 от приложение IВ).
  
recordType  указва типа запис (VuGNSSADRecord).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът на VuGNSSADRecord в байтове.  
noOfRecords  е броят на записите в набора от записи.  
Records  е набор от записи за общо управление по GNSS.  
▼M3 
2.204а.  VuGnssMaximalTimeDifference  
Поколение 2, версия 2:  
Максималната разлика между действителното време и времето от 
часовника за реално време на бордовото устройство въз основа на  
максималната неточност на времето, дадена в приложение IB, 
изискване 041, предадена от бордовото устройство към външно 
устройство за GNSS, вж. допълнение 12, изискване GNS_3g.
  
▼B 
2.205.  VuIdentification  
Информация, съхранена в бордово устройство и отнасяща се за 
идентификация на бордовото устройство (изискване 075 от 
приложение 1Б и изисквания 93 и 121 от приложение 1В).  
Поколение 1:
  
vuManufacturerName  е наименованието на производителя на 
бордовото устройство.  
vvuManufacturerAddress  е адресът на производителя на бордовото 
устройство.  
vuPartNumber  е фабричният номер на бордовото устройство.  
vuSerialNumber  е серийният номер на бордовото устройство.  ▼M1
 02016R0799 — BG — 21.08.2023 — 003.001 — 209  
vuSoftwareIdentification  идентифицира софтуера, използван в 
бордовото устройство.  
vuManufacturingDate  е датата на производство на бордовото 
устройство.  
vuApprovalNumber  е номерът на одобрение на типа на бордовото 
устройство.  
▼M3 
Поколение 2:
  
В допълнение към поколение 1 се използват следните елементи от 
данни:  
vuGeneration  идентифицира поколението на бордовото устройство.  
vuAbility  осигурява информация дали бордовото устройство 
поддържа тахографски карти от поколение 1.  
vuDigitalMapVersion  е версията на цифровата карта, съхранена в 
бордовото устройство (присъства само във версия 2).  
▼B 
2.206.  VuIdentificationRecordArray  
Поколение 2:  
VuIdentification плюс метаданните, използвани в протокола за 
изтегляне на данни.
  
recordType  указва типа запис (VuIdentification).  Присвояване  на 
стойност : вж. RecordType.  
recordSize  е размерът на VuIdentification в байтове.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 210  
noOfRecords  е броят на записите в набора от записи.  
records  е набор записи от VuIdentification.  
2.207.  VuITSConsentRecord  
Поколение 2:  
Информация, съхранена в бордово устройство и отнасяща се за 
съгласието на водача да използва интелигентни транспортни 
системи.
  
cardNumberAndGen  идентифицира картата, включително поко­ 
лението ѝ. Това трябва да е карта на водач или карта за монтаж 
и настройки.  
consent  е флаг, който указва дали водачът е дал съгласието си за 
използването на интелигентни транспортни системи на това 
превозно средство/бордово устройство.  
Присвояване  на стойност : 
TRUE указва съгласието на водача да използва инте­ 
лигентни транспортни системи  
FALSE указва отказа на водача да използва интели­ 
гентни транспортни системи  
2.208.  VuITSConsentRecordArray  
Поколение 2:  
Информация, съхранена в бордово устройство и отнасяща се за 
съгласието на водачите да използват интелигентни транспортни 
системи (изискване 200 от приложение 1В).
  
recordType  указва типа запис (VuITSConsentRecord).  Присвояване  
на стойност : вж. RecordType.  
recordSize  е размерът на VuITSConsentRecord в байтове.  
noOfRecords  е броят на записите в набора от записи.  
records  е наборът от записи за съгласието във връзка с интели­ 
гентните транспортни системи.  
▼M3 
2.208а.  VuLoadUnloadRecord  
Поколение 2, версия 2:  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 211  
Информация, съхранена в бордовото устройство и отнасяща се до 
въведената товаро-разтоварна операция (изисквания 133д, 133е 
и 133ж от приложение IB).
  
timeStamp  е датата и часът на въвеждането на товаро-разтоварната 
операция.  
operationType  е типът на въведената операция (товарене, разто­ 
варване или едновременно товарене и разтоварване).  
cardNumberAndGenDriverSlot  идентифицира картата, включително 
поколението ѝ, вкарана в процепа за водача.  
cardNumberAndGenCodriverSlot  идентифицира картата, вклю­ 
чително поколението ѝ, вкарана в процепа за втория водач.  
gnssPlaceAuthRecord  съдържа информация за местоположението на 
превозното средство и статусът му на удостоверяване на автентич ­ 
ността.  
vehicleOdometerValue  е стойността на километражния брояч, 
отнасяща се до товаро-разтоварната операция.  
2.208б.  VuLoadUnloadRecordArray  
Поколение 2, версия 2:  
Информация, съхранена в бордовото устройство и отнасяща се до 
въведената товаро-разтоварна операция (изискване 133з от 
приложение IB).
  
recordType  указва типа на записа (VuLoadUnloadRecord). Value 
Assignment : вж. RecordType.  
recordSize  е размерът на VuLoadUnloadRecord в байтове.  
noOfRecords  е броят на записите в набора от записи.  
records  е набор записи за товаро-разтоварни операции.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 212  
2.209.  VuManufacturerAddress  
Адрес на производителя на бордовото устройство.
  
Присвояване  на стойност : не е указана.  
2.210.  VuManufacturerName  
Наименование на производителя на бордовото устройство.
  
Присвояване  на стойност : не е указана.  
2.211.  VuManufacturingDate  
Дата на производство на бордовото устройство.
  
Присвояване  на стойност : не е указана.  
2.212.  VuOverSpeedingControlData  
Информация, съхранена в бордово устройство и отнасяща се за 
събитията „превишаване на скоростта“, настъпили след извършване  
на последната проверка за превишаване на скоростта (изискване 0 95 
от приложение 1Б и изискване 117 от приложение 1В).
  
lastOverspeedControlTime  е датата и часът на последната проверка 
за превишаване на скоростта.  
firstOverspeedSince  е датата и часът на първото превишаване на 
скоростта след последната проверка за превишаване на скоростта.  
numberOfOverspeedSince  е броят на събитията „превишаване на 
скоростта“ след последната проверка за превишаване на скоростта . 
2.213.  VuOverSpeedingControlDataRecordArray  
Поколение 2:  
VuOverSpeedingControlData плюс метаданните, използвани в 
протокола за изтегляне на данни.
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 213  
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 — 21.08.2023 — 003.001 — 214  
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 — 21.08.2023 — 003.001 — 215  
2.218.  VuPlaceDailyWorkPeriodData  
Поколение 1:  
Информация, съхранена в бордово устройство и отнасяща се за 
местоположенията в началото или края на дневен период на 
работа на водачите (изискване 087 от приложение 1Б и изисквания  
108 и 110 от приложение 1В).
  
noOfPlaceRecords  е броят на записите, посочени в набора vuPlace­
DailyWorkPeriodRecords.  
vuPlaceDailyWorkPeriodRecords  е набор от записи във връзка с 
местоположения.  
2.219.  VuPlaceDailyWorkPeriodRecord  
Поколение 1:  
Информация, съхранена в бордово устройство и отнасяща се за 
местоположение в началото или края на дневен период на работа 
на водач (изискване 087 от приложение 1Б и изисквания 108 и 110  
от приложение 1В).
  
fullCardNumber  е типът карта на водач, държавата членка, която 
издава картата, и номерът на картата.  
placeRecord  съдържа данни относно въведеното местоположение.  
▼M3 
Поколение 2, версия 1:  
▼B 
Информация, съхранена в бордово устройство и отнасяща се за 
местоположение в началото или края на дневен период на работа 
на водач (изискване 087 от приложение 1Б и изисквания 108 и 110  
от приложение 1В).
  
Вместо fullCardNumber структурата на данните от поколение 2 
използва следния елемент от данни:  
fullCardNumberAndGeneration  е типът карта, държавата членка, 
която я издава, нейният номер на карта и поколението, съхранени  
на картата.  
▼M3 
Поколение 2, версия 2:  
Информация, съхранена в бордово устройство и отнасяща се за 
местоположение в началото или края на дневен период на работа 
на водач (изискване 087 от приложение IБ и изисквания 108 и 110  
от приложение IВ).  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 216
  
Вместо placeRecord структурата на данните от поколение 2, верси я 
2 използва следния елемент от данни.  
placeAuthRecord  съдържа информацията, свързана с въведеното 
място, записаното местоположение, статуса на удостоверяване на 
автентичността на GNSS и времето на определяне на местополо­ 
жението.  
▼B 
2.220.  VuPlaceDailyWorkPeriodRecordArray  
Поколение 2:  
Информация, съхранена в бордово устройство и отнасяща се до 
местоположенията в началото или края на дневен период на 
работа на водачи (изисквания 108 и 110 от приложение 1В).
  
recordType  указва типа запис (VuPlaceDailyWorkPeriodRecord).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът на VuPlaceDailyWorkPeriodRecord в байтове.  
noOfRecords  е броят на записите в набора от записи.  
records  е набор записи във връзка с местоположението.  
2.221.  VuPrivateKey  
Поколение 1:  
Частен ключ на бордово устройство.
  
2.222.  VuPublicKey  
Поколение 1:  
Публичен ключ на бордово устройство.
  
▼M3 
2.222а.  VuRtcTime  
Поколение 2, версия 2:  
Часът по часовника за реално време на бордовото устройство, 
предаден от бордовото устройство на външно устройство за 
GNSS, вж. допълнение 12, изискване GNS_3е.
  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 217  
2.223.  VuSerialNumber  
Сериен номер на бордовото устройство (изискване 075 от 
приложение 1Б и изискване 93 от приложение 1В).
  
2.224.  VuSoftInstallationDate  
Дата на инсталиране на версията на софтуера на бордовото 
устройство.
  
Присвояване  на стойност : не е указана.  
2.225.  VuSoftwareIdentification  
Информация, съхранена в бордово устройство и отнасяща се за 
инсталирания софтуер.
  
vuSoftwareVersion  е номерът на версията на софтуера на бордовото 
устройство.  
vuSoftInstallationDate  е датата на инсталиране на версията на 
софтуера.  
2.226.  VuSoftwareVersion  
Номер на версията на софтуера на бордовото устройство.
  
Присвояване  на стойност : не е указана.  
2.227.  VuSpecificConditionData  
Поколение 1:  
Информация, съхранена в бордово устройство и отнасяща се до 
специфични условия.
  
noOfSpecificConditionRecords  е броят на записите, посочени в 
набора от specificConditionRecords.  
specificConditionRecords  е набор записи във връзка със специфични 
условия.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 218  
2.228.  VuSpecificConditionRecordArray  
Поколение 2:  
Информация, съхранена в бордово устройство и отнасяща се за 
специфични условия (изискване 130 от приложение 1В).
  
recordType  указва типа запис (SpecificConditionRecord).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът на SpecificConditionRecord в байтове.  
noOfRecords  е броят на записите в набора от записи.  
records  е набор от записи във връзка със специфични условия.  
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:
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 219  
oldTimeValue, newTimeValue  са старите и новите стойности на 
датата и часа.  
workshopName, workshopAddress  са наименованието и адресът на 
сервиза.  
workshopCardNumber  идентифицира картата за монтаж и 
настройки, използвана за сверяване на часовника.  
Поколение 2:
  
Вместо workshopCardNumber структурата на данните от поколение 
2 използва следния елемент от данни.  
workshopCardNumberAndGeneration  идентифицира картата за 
монтаж и настройки, включително поколението ѝ, използвана за 
сверяване на часовника.  
2.233.  VuTimeAdjustmentRecordArray  
Поколение 2:  
Информация, съхранена в бордово устройство и отнасяща се за 
сверяването на часовника, извършено извън рамките на редовното 
калибриране (изисквания 124 и 125 от приложение 1В).
  
recordType  указва типа запис (VuTimeAdjustmentRecord).  
Присвояване  на стойност : вж. RecordType.  
recordSize  е размерът на VuTimeAdjustmentRecord в байтове.  
noOfRecords  е броят на записите в набора от записи.  
records  е набор от записи за сверяване на часовника.  
2.234.  WorkshopCardApplicationIdentification  
Информация, съхранена на карта за монтаж и настройки и отнасяща  
се за идентификация на приложението на картата (изисквания 307 и 
330 от приложение 1В).  
Поколение 1:
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 220  
typeOfTachographCardId  обозначава използвания тип карта.  
cardStructureVersion  указва версията на структурата, приложена в 
картата.  
noOfEventsPerType  е броят на събитията от всеки тип, които 
картата може да запише.  
noOfFaultsPerType  е броят на неизправностите от всеки тип, които 
картата може да запише.  
activityStructureLength  указва броя на байтовете, които могат да се 
използват за съхранение на записите за дейността.  
noOfCardVehicleRecords  е броят на записите за превозното 
средство, които картата може да съдържа.  
noOfCardPlaceRecords  е броят на местоположенията, които картата 
може да запише.  
noOfCalibrationRecords  е броят на записите за калибриранията, 
които картата може да съхрани.  
Поколение 2:  
▼M1
 
В допълнение към поколение 1 се използват следните елементи от 
данни:  
noOfGNSSADRecords  е броят на записите за общо управление по 
GNSS, които картата може да съхранява.  
noOfSpecificConditionRecords  е броят на записите за специфични 
условия, които картата може да съхранява.  
noOfCardVehicleUnitRecords  е броят на записите за използваните 
бордови устройства, които картата може да съхранява.  
▼M3 
2.234а.  WorkshopCardApplicationIdentificationV2  
Поколение 2, версия 2:  
Информация, съхранена върху карта за монтаж и настройки и 
отнасяща се за идентификацията на приложението на картата 
(изискване 330а от приложение IВ).  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 221
  
lengthOfFollowingData  е броят байтове, следващи записа.  
noOfBorderCrossingRecords  е броят на записите за пресичане на 
граници, които картата за монтаж и настройки може да съхранява.  
noOfLoadUnloadRecords  е броят на записите за товаро-разтоврани 
операции, които картата за монтаж и настройки може да съхранява . 
noOfLoadTypeEntryRecords  е броят на записите за типа на товара, 
които картата за монтаж и настройки може да съхранява.  
vuConfigurationLengthRange  е броят на байтове в тахографската 
карта, който е на разположение за съхраняване на конфигурации 
на бордовото устройство.  
2.234б.  WorkshopCardCalibrationAddData  
Поколение 2, версия 2:  
Информация, съхранена на карта за монтаж и настройки и отнасяща  се 
до допълнителните данни (т.е. типа на товара по подразбиране), 
въведени по време на калибриране (изискване 356л от приложение IB).
 
calibrationPointerNewestRecord  е индексът на последния актуа­ 
лизиран запис с допълнителни данни при калибриране.  
Присвояване  на стойност  е число, съответстващо на номератора 
на запис с допълнителни данни при калибриране, започващо от 0 з а 
първия случай в структурата на запис за допълнителни данни при 
калибриране.  
workshopCardCalibrationAddDataRecords  е наборът от записи, 
съдържащи старата дата и час, стойността за идентификацията на 
превозното средство и типа на товара по подразбиране на 
превозното средство.  
2.234в.  WorkshopCardCalibrationAddDataRecord  
Поколение 2, версия 2:  
Информации, записани на карта за монтаж и настройки и отнасящи 
се до типа на товара по подразбиране, въведен по време на калиб ­ 
риране (изискване 356к от приложение IB).  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 222
  
oldTimeValue  е старата стойност на датата и часа, съдържаща се в 
съответния WorkshopCardCalibrationRecord,  
vehicleIdentificationNumber  е идентификационният номер на 
превозното средство, който също се съдържа в съответния 
WorkshopCardCalibrationRecord,  
byDefaultLoadType  е типът на товара по подразбиране на 
превозното средство (присъства само във версия 2),  
calibrationCountry  е държавата, в която е извършено калибри­ 
рането,  
calibrationCountryTimestamp  е датата и часът, когато от 
приемника на сигнали от GNSS е предоставено местоположението, 
използвано за определяне съответната държава.  
▼B 
2.235.  WorkshopCardCalibrationData  
Информация, съхранена на карта за монтаж и настройки и отнасяща  
се до определена сервизна дейност, извършена с картата 
(изисквания 314, 316, 337 и 339 от приложение 1В).
  
calibrationTotalNumber  е общият брой на извършените с картата 
калибрирания.  
calibrationPointerNewestRecord  е индексът на последния актуа­ 
лизиран запис за калибриране.  
Присвояване  на стойност : число, съответстващо на номератора на 
запис за калибриране, като се започва с 0 за първия случай на з апис 
за калибриране в структурата.  
calibrationRecords  е набор от записи, съдържащи информация за 
калибрирането и/или сверяването на часовника.  
2.236.  WorkshopCardCalibrationRecord  
Информация, съхранена на карта за монтаж и настройки и отнасяща  
се за калибриране, извършено с картата (изисквания 314 и 337 от  
приложение 1В).  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 223  
Поколение 1:
  
calibrationPurpose  е целта на калибрирането.  
vehicleIdentificationNumber  е VIN.  
vehicleRegistration  съдържа VRN и регистриращата държава 
членка.  
wVehicleCharacteristicConstant  е характеристичният коефициент на 
превозното средство.  
kConstantOfRecordingEquipment  е константата на уреда за регис­ 
триране на данните за движението.  
lTyreCircumference  е действителната обиколка на колелата.  
tyreSize  е обозначение на размерите на гумите, монтирани на 
превозното средство.  
authorisedSpeed  е разрешената максимална скорост на превозното 
средство.  
oldOdometerValue и newOdometerValue  са старата и новата 
стойност, отчетени от километражния брояч.  
oldTimeValue, newTimeValue  са старите и новите стойности на 
датата и часа.  
nextCalibrationDate  е датата на следващото калибриране на типа в 
CalibrationPurpose, което оправомощеният инспектиращ орган 
трябва да извърши.  
vuPartNumber , vuSerialNumber  и sensorSerialNumber  са елементи 
от данни, необходими за идентификация на уредите за регистриран е 
на данните за движението.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 224  
Поколение 2:
  
В допълнение към поколение 1 се използват следните елементи от 
данни:  
sensorGNSSSerialNumber  идентифицира външното устройство за 
GNSS.  
rcmSerialNumber  идентифицира модула за връзка от разстояние.  
sealDataVu  дава информация за пломбите, поставени върху 
различните компоненти на превозното средство.  
2.237.  WorkshopCardHolderIdentification  
Информация, съхранена на карта за монтаж и настройки и отнасяща  
се за идентификация на титуляря на картата (изисквания 311 и 33 4 
от приложение 1В).
  
workshopName  е наименованието на сервиза на титуляря на 
картата.  
workshopAddress  е адресът на сервиза на титуляря на картата.  
cardHolderName  е фамилията и името (и презимето) на титуляря 
(например името на механика).  
cardHolderPreferredLanguage  е предпочитаният език на титуляря 
на картата.  
2.238.  WorkshopCardPIN  
Персонален идентификационен номер на картата за монтаж и 
настройки (изисквания 309 и 332 от приложение 1В).
  
Присвояване  на стойност : PIN, известен на титуляря на картата, 
запълнен отдясно със серия от байтове „FF“, която може да 
съдържа до 8 байта.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 225  
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 — 21.08.2023 — 003.001 — 226  
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 — 21.08.2023 — 003.001 — 227  
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 — Балтийски регион  1 3  
ISO/IEC 8859-15 латиница 9  1 5  
ISO/IEC 8859-16 латиница 10 — Югоизточна Европа  1 6  
KOI8-R латиница/кирилица  8 0  
KOI8-U латиница/кирилица  8 5  
5. КОДИРАНЕ  
Ако се прилагат правилата за кодиране ASN.1, всички определени 
типове данни трябва да се кодират съгласно приведения в съот­ 
ветствие вариант на стандарт ISO/IЕС 8825-2.  
6. ИДЕНТИФИКАТОРИ НА ОБЕКТИ И ИДЕНТИФИКАТОРИ НА 
ПРИЛОЖЕНИЯ  
6.1. Идентификатори  на обекти  
Идентификаторите на обекти (ИО), посочени в тази глава, 
се прилагат само към поколение 2. Тези ИО са определени в  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 228  
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 — 21.08.2023 — 003.001 — 229  
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 — 21.08.2023 — 003.001 — 230  
Допълнение  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 — 21.08.2023 — 003.001 — 231  
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 — 21.08.2023 — 003.001 — 232  
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 — 21.08.2023 — 003.001 — 233  
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 — 21.08.2023 — 003.001 — 234  
Долно 
равнище (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 Картата функционира в две състояния, когато е 
приложено захранващото напрежение:  
▼M3 
активно състояние, докато изпълнява команди или се 
свързва с бордовото устройство  
▼B 
пасивно състояние през останалото време; в това 
състояние картата трябва да запазва всички запаметени 
данни.  
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 — 21.08.2023 — 003.001 — 235  
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: не 
се използва.  
▼M3 __________  
▼B 
— Information Field Size Device (IFSD) се указва от IFD 
непосредствено след ATR: IFD предава заявката за 
дължината на зоната за информация (IFS) на 
S-Block след ATR и картата отговаря с IFS на 
S-Block. Препоръчва се стойността на IFSD да е 
254 байта.  
— Картата не подава искане за промяна на IFS.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 236  
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 — 21.08.2023 — 003.001 — 237  
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 — 21.08.2023 — 003.001 — 238  
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 — 21.08.2023 — 003.001 — 239  
Команда  Карта на водач  Карта за 
монтаж и 
настройки  Контролна 
карта  Карта на 
превозвач  
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 — 21.08.2023 — 003.001 — 240  
Команда  Карта на водач  Карта за 
монтаж и 
настройки  Контролна 
карта  Карта на 
превозвач  
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 — 21.08.2023 — 003.001 — 241  
Команда  INS  
PERFORM SECURITY OPERATION  „2Ah“  
— VERIFY CERTIFICATE  
— COMPUTE DIGITAL SIGNA­
TURE  
— 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 0 0  Нормална обработка  
61 X X  Нормална обработка. ХХ = брой на наличните байтове на 
отговора  
62 8 1  Предупреждение за обработката. Възможно е част от 
върнатите данни да са увредени  
63 0 0  Удостоверяването е неуспешно (предупреждение)  
63 C X  Грешка при CHV (PIN). Брояч на оставащите опити, 
осигуряван от ‘X’  
64 0 0  Грешка при изпълнението — непроменено състояние на 
енергонезависимата памет. Грешка в целостта на данните  
65 0 0  Грешка при изпълнението — променено състояние на енер­ 
гонезависимата памет  
65 8 1  Грешка при изпълнението — променено състояние на енер­ 
гонезависимата памет. Неизправност на паметта  
66 8 8  Грешка по сигурността: грешна криптографска контролна 
сума (по време на защитен обмен 
на съобщения) или 
грешен сертификат (по време на 
проверката на сертификата) или 
грешна криптограма (по време на 
външното удостоверяване) или 
грешен цифров подпис (по време 
на проверката на подписа)  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 242  
SW1  SW2  Значение  
67 0 0  Грешна дължина (грешна Lc или Le)  
68 8 3  Очаква се последната команда от веригата  
69 0 0  Забранена команда (няма възможност за отговор при Т=0)  
69 8 2  Незадоволително състояние по отношение на сигурността  
69 8 3  Блокиран метод за удостоверяване  
69 8 5  Неизпълнени условия за използване  
69 8 6  Неразрешена команда (няма активен елементарен файл)  
69 8 7  Липса на очакваните обекти от данни при защитения обмен 
на съобщения  
69 8 8  Неправилни обекти от данни при защитения обмен на 
съобщения  
6A 8 0  Неправилни параметри в поле за данни  
6A 8 2  Неоткриваем файл  
6A 8 6  Грешни параметри P1-P2  
6A 8 8  Неоткриваеми указани данни  
6B 0 0  Грешни параметри (поправка извън елементарния файл)  
6C X X  Грешна дължина, SW2 указва точната дължина. Не се връща 
като отговор поле за данни  
6D 0 0  Несъвместим или неправилен код на команда  
6E 0 0  Несъвместим клас  
6F 0 0  — Други грешки при проверката  
Може да бъдат върнати други байтове за състояние, 
определени в стандарт 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 — 21.08.2023 — 003.001 — 243  
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 — 21.08.2023 — 003.001 — 244  
Командата 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)  N N  „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 — 21.08.2023 — 003.001 — 245  
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 — 21.08.2023 — 003.001 — 246  
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 — 21.08.2023 — 003.001 — 247  
Байт  Дължи­ 
на Стойност  Описание  
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)  N N  ‘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 — 21.08.2023 — 003.001 — 248  
Байт  Дълж­ 
ина Стойност  Описание  
#(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)  M M  ‘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 — 21.08.2023 — 003.001 — 249  
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 — 21.08.2023 — 003.001 — 250  
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_Installation_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)  N N  „XX..XXh“  Изместване на обекта от данни: 
Таг „54h“ 
Дължина „01h“ или „02h“ 
Стойност изместване  
▼M1 
Le 1  ‘XXh’  Съгласно стандарта ISO/IEC 7816-4  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 251  
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 — 21.08.2023 — 003.001 — 252  
Байт  Дължи­ 
на Стойност  Описание  
#6 1  „B3h“  Таг за простата стойност на данните, кодирани по 
BER-TLV  
#7 1  „NNh“  L  PV : дължина на предадените данни  
#(8)-#(7+NN)  N N  „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 — 21.08.2023 — 003.001 — 253  
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)  N N  „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 — 21.08.2023 — 003.001 — 254  
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 — 21.08.2023 — 003.001 — 255  
Освен това могат да възникнат някои грешки, 
конкретно свързани със защитения обмен на 
съобщения. В този случай се връща само стойността 
за състоянието на обработката без участието на струк­ 
турата за защитен обмен на съобщения:  
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)  N N  „XX..XXh“  Данни, които трябва да се запишат  
TCS_63  Ответно  съобщение  
Байт  Дължи­ 
на Стойност  Описание  
SW 2  „XXXXh“  Байтове за състоянието (SW1, SW2)  
Забележка : Кратките идентификатори на EF, 
използвани за тахографското приложение от 
поколение 2, са определени в глава 4.  
Ако P1 кодира кратък идентификатор на EF и 
командата бъде изпълнена успешно, идентифицираният 
EF се селектира като текущ (активен EF).  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 256  
— Ако командата бъде изпълнена успешно, картата 
връща „ 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)  N N  „XX..XXh“  Изместване на обект от данни с таг „54h“ || Дискре­ 
ционен обект от данни с таг „53h“, в който са капсу­ 
лирани подлежащите на записване данни  
IFD кодира дължината на изместения обект от данни и 
на дискреционния обект от данни с минималния 
възможен брой октети, т.е. като използва байта за 
дължина „01h“ IFD кодира изместване / дължина от 0 
до 255, а като използва байта за дължина „02h“ — 
изместване / дължина от „256“ до „65 535“ байта.  
TCS_66  Ответно  съобщение  
Байт  Дължи­ 
на Стойност  Описание  
SW 2  „XXXXh“  Байтове за състоянието (SW1, SW2)  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 257  
— Ако командата бъде изпълнена успешно, картата 
връща „ 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+NN)  M „XX..XXh“  Криптографска контролна сума  
Le 1  „00h“  Съгласно стандарта ISO/IEC 7816-4  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 258  
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“  P 1  
P2 1  „00h“  P 2  
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 — 21.08.2023 — 003.001 — 259  
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“  P 1  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 260  
Байт  Дължи­ 
на Стойност  Описание  
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 — 21.08.2023 — 003.001 — 261  
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“  P 1  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 262  
Байт  Дължи­ 
на Стойност  Описание  
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.  
▼M3 
TCS_86 Тази команда може да бъде изпълнена в MF, DF 
Tachograph и DF Tachograph_G2, виж също TCS_34.  
▼B 
TCS_87  Командно  съобщение  
Байт  Дължи­ 
на Стойност  Описание  
CLA  1  „X0h“  Байт CLA, указващ верижно свързване на команди: 
„00h“ за единствена или последна команда във 
веригата 
„10h“ за команда, която не е последна във веригата  
INS 1  „2Ah“  Извършване на операция, свързана със защитата от 
неоторизиран достъп  
P1 1  „00h“  
P2 1  „BEh“  Проверка на самоописващ се (self-descriptive) 
сертификат  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 263  
Байт  Дължи­ 
на Стойност  Описание  
Lc 1  „XXh“  Дължина на полето за данни на командата, виж 
TCS_88 и TCS_89.  
#6-#5+L  L  „XX..XXh“  Данни, кодирани по DER-TLV: обектът от данни в 
тялото на ECC сертификата е съединен като първи 
обект от данни с обекта от данни в подписа на ECC 
сертификата като втори обект от данни или част от 
тази конкатенация. Тагът „7F21“ и съответната 
дължина не се предават. 
Тези обекти от данни са във фиксирана последова­ 
телност.  
▼M3 
TCS_88 За APDU с малка дължина се прилагат следните 
разпоредби: IFD трябва да използва минималния брой 
APDU, необходими за предаването на командите, и да 
предава максималния брой байтове в първата APDU с 
команда. Въпреки това всяка стойност на „Lc“ до 255 
байта трябва да се поддържа от картата.  
TCS_89 За APDU с увеличена дължина се прилагат следните 
разпоредби: ако сертификатът не се побира в една- 
единствена APDU, картата трябва да поддържа послед­ 
ователно свързване на команди. IFD трябва да използва 
минималния брой APDU, необходими за предаването 
на командите, и да предава максималния брой байтове 
в първата APDU с команда. Ако е необходимо послед­ 
ователно свързване, всяка стойност на „Lc“ до посо­ 
чената максимална удължена дължина трябва да бъде 
поддържана от картата.  
Забележка: съгласно допълнение 11 картата съхранява 
сертификата или съответното съдържание на серти­ 
фиката и актуализира своето currentAuthenticatedTime.  
Структурата на ответното съобщение и байтовете за 
състоянието са определени в TCS_85.  
▼B 
TCS_90 В допълнение към кодовете за грешка, посочени в 
TCS_85, картата може да върне следните кодове за 
грешка:  
— ако избраният публичен ключ (използван за 
отваряне на сертификата) има CHA.LSB (Certificate­
HolderAuthorisation.equipmentType), който не е 
подходящ за проверка на сертификата съгласно 
допълнение 11, за състоянието на обработката се 
връща „ 6985 “. 
— Ако currentAuthenticatedTime на картата е по-късно 
от датата на изтичане на срока на сертификата, а 
състоянието на обработката се връща „ 6985 “. 
— Ако се очаква последната команда от верижната 
последователност, картата връща „ 6883 “. 
— Ако са изпратени неправилни параметри в полето за 
данни на командата, картата връща „ 6A80 “ 
(използва се и когато обектите от данни не са 
изпратени в указаната последователност).  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 264  
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“  P 1  
P2 1  „00h“  P 2  
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 — 21.08.2023 — 003.001 — 265  
— Ако избраният частен ключ се счита за повреден, за 
състоянието на обработката се връща „ 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 — 21.08.2023 — 003.001 — 266  
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 изпраща обектите от данни в тази последова­ 
телност.  
▼M3 
Le 1  „00h“  Съгласно разпоредбите на стандарт ISO/IEC 7816-4  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 267  
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 — 21.08.2023 — 003.001 — 268  
Байт  Дължи­ 
на Стойност  Описание  
#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 Authentication),  
което се извършва от последващата команда 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 — 21.08.2023 — 003.001 — 269  
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 — 21.08.2023 — 003.001 — 270  
Байт  Дължи­ 
на Стойност  Описание  
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 — 21.08.2023 — 003.001 — 271  
Само за контролната карта се изисква да поддържа тази команда 
в 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 — 21.08.2023 — 003.001 — 272  
Другите видове тахографски карти могат или не могат да 
изпълняват тази команда. Ако карта на превозвач или 
контролна карта изпълнява тази команда, това трябва да става, 
както е определено в настоящата глава.  
Тази команда може или не може да е достъпна в MF. Ако 
командата е достъпна, тя се изпълнява, както е определено в 
настоящата глава, т.е. не позволява изчисляването на хеш- 
стойност, а се прекратява с подходящ код за грешка.  
TCS_118 Командата PERFORM HASH of FILE се използва за 
хеширане на зоната за данни на селектирания 
елементарен файл (EF) с прозрачна структура.  
TCS_119 Тахографската карта поддържа тази команда само за 
EF, които са изброени в глава 4 в рамките на 
DF_Tachograph и DF_Tachograph_G2, със следното 
изключение. Тахографската карта не трябва да 
поддържа командата за елементарния файл 
Sensor_Installation_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 — 21.08.2023 — 003.001 — 273  
— Ако селектираният 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 — 21.08.2023 — 003.001 — 274  
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 — 21.08.2023 — 003.001 — 275  
TCS_134  Ответно  съобщение  
Байт  Дължи­ 
на Стойност  Описание  
SW 2  „XXXXh“  Байтове за състоянието (SW1, SW2)  
— Ако командата бъде изпълнена успешно, картата 
връща „ 9000 “. 
— Ако проверката на подписа е неуспешна, за 
състоянието на обработката се връща „ 6688 “. 
Процесът на проверка е описан подробно в 
допълнение 11.  
— Ако не е избран публичен ключ, за състоянието на 
обработката се връща „ 6A88 “. 
— Ако някои очаквани обекти от данни (както е 
определено по-горе) липсват, за състоянието на 
обработката се връща „ 6987 “ Това може да стане, 
ако липсва един от изискваните тагове.  
— Ако не е наличен хеш-код за изпълнение на 
командата (в резултат на предходна команда PSO: 
Hash), за състоянието на обработката се връща 
„6985 “. 
— Ако някои обекти от данни са неправилни, за 
състоянието на обработката се връща „ 6988 “. Това 
може да се случи, ако дължината на някой от изиск­ 
ваните обекти от данни е неправилна.  
— Ако избраният публичен ключ се счита за повреден, 
за състоянието на обработката се връща „ 6400 “ или 
„6581 “. 
▼M1 
— Ако избраният публичен ключ (използван за 
проверка на въведения цифров подпис) има 
CHA.LSB (CertificateHolderAuthorisation.equip­
mentType), който не е подходящ за проверка на 
цифровия подпис съгласно допълнение 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 — 21.08.2023 — 003.001 — 276  
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“.  
▼M3 
Le 1  „00h“  Съгласно стандарт ISO/IEC 7816-4  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 277  
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 Тахографската карта трябва да поддържа поне мини­ 
малния брой записи, определен за съответните 
приложения, и да поддържа не повече от максималния 
брой записи, определен за съответните приложения.  
▼M3 
Максималният и минималният брой на записите за 
различните приложения са определени в настоящата 
глава. Във версия 2 на картите на водачи и картите за 
монтаж и настройки от поколение 2 приложението от 
поколение 1 трябва да поддържа максималния брой 
записи, посочен в TCS_150 и TCS_158.  
▼B 
Условията за сигурност, използвани в правилата за 
достъп в рамките на тази глава, са посочени в глава 
3.3. По принцип режимът на достъп „Четене“ („Read“) 
означава командата READ BINARY с четен и, ако се 
поддържа, нечетен байт INS — с изключение на 
елементарния файл (EF) Sensor_Installation_Data на 
картата за монтаж и настройки, виж TCS_156 и 
TCS_160. Режимът на достъп „Актуализация“ 
(„Update“) означава командата READ BINARY с четен 
и, ако се поддържа, нечетен байт INS, а режимът на 
достъп „Селектиране“ („Select“) — командата SELECT.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 278  
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 — 21.08.2023 — 003.001 — 279  
Стойността „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 — 21.08.2023 — 003.001 — 280
  
► (1) (2) M3 ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 281
  
▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 282  
TCS_151 Следните стойности, използвани за указване на размери 
в таблицата по-горе, определят минималния и макси­ 
малния брой на записите, който трябва да се използва 
за приложение от поколение 1 в структурата на данните 
в картата на водача:
  
4.2.2  Приложение  от поколение  2 за картата  на водача  
▼M3 
TCS_152 След персонализирането на приложението от поколение 
2 за картата на водач то трябва да е със следната 
постоянна файлова структура и правила за достъп до 
файловете:  
Забележки : 
— краткият идентификатор SFID на EF се дава като 
десетично число — например стойността 30 съот­ 
ветства на 11110 в двоичната бройна система.  
— EF Application_Identification_V2, EF Places_Authenti­
cation, EF GNSS_Places_Authentication, EF Border_ 
Crossings, EF load_Unload_Operations, EF VU_Configu­
ration и EF Load_Type_Entries присъстват само във 
версия 2 на картата на водач от поколение 2.  
— cardStructureVersion в EF Application_Identification е 
равно на {01 01} за версия 2 на картата на водача от 
поколение 2, докато за версия 1 на картата на водач 
от поколение 2 това беше равно на {01 00}.
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 283  
В тази таблица се използват следните съкращения за 
условието за сигурност:  
SC1 ALW ИЛИ SM-MAC-G2  
SC5 За командата Read Binary с четен байт INS: 
SM-C-MAC-G2 И SM-R-ENC-MAC-G2  
За командата Read Binary с нечетен байт INS (ако 
се поддържа): NEV  
▼B 
TCS_153 Структурите на всички EF трябва да бъдат прозрачни.  
▼M3 
TCS_154 Приложението от поколение 2 за картата на водач 
трябва да е със следната структура на данните:
  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 284
  
▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 285
  
▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 286  
TCS_155 Следните стойности, използвани за указване на размери 
в таблицата по-горе, определят минималния и макси­ 
малния брой на записите, който трябва да се използва 
за приложение от поколение 2 в структурата на данните 
в картата на водача:  
▼M3 
Мин . Макс . 
n 1 NoOfEventsPerType  1 2  1 2  
n 2 NoOfFaultsPerType  2 4  2 4  
n 3 NoOfCardVehicleRecords  200  200  
n 4 NoOfCardPlaceRecords  112  112  
n 6 CardActivityLengthRange  13776 байта 
(56 дни * 117 
промени на 
дейността)  13776 байта 
(56 дни * 
117 промени на 
дейността)  
n 7 NoOfCardVehicleUnitRecords  200  200  
n 8 NoOfGNSSADRecords  336  336  
n 9 NoOfSpecificConditionRecords  112  112  
n 10 NoOfBorderCrossingRecords  1120  1120  
n 11 NoOfLoadUnloadRecords  1624  1624  
n 12 NoOfLoadTypeEntryRecords  336  336  
n 13 VuConfigurationLengthRange  3072 Bytes  3072 Bytes  
▼B 
4.3. Приложения  за картата  за монтаж  и настройки  
4.3.1  Приложение  от поколение  1 за картата  за монтаж  и 
настройки  
TCS_156 След персонализирането на приложението от поколение 
1 за картата за монтаж и настройки то трябва да е със 
следната постоянна файлова структура и правила за 
достъп до файловете:
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 287  
В тази таблица се използват следните съкращения за 
условията за сигурност:  
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 — 21.08.2023 — 003.001 — 288
  
▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 289
  
▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 290
  
TCS_159 Следните стойности, използвани за указване на размери 
в таблицата по-горе, определят минималния и макси­ 
малния брой на записите, който трябва да се използва 
за приложение от поколение 1 в структурата на данните 
в картата за монтаж и настройки:
  
4.3.2  Приложение  от поколение  2 за картата  за монтаж  и 
настройки  
▼M3 
TCS_160 След персонализирането на приложението от поколение 
2 за картата за монтаж и настройки то трябва да е със 
следната постоянна файлова структура и правила за 
достъп до файловете:  
Забележки : 
— краткият идентификатор SFID на EF се дава като 
десетично число — например стойността 30 съот­ 
ветства на 11110 в двоичната бройна система.  
— EF Application_Identification_V2, EF Places_Authenti­
cation, EF GNSS_Places_Authentication, EF 
Border_Crossings, EF load_Unload_Operations, EF 
Load_Type_Entries, EF VU_Configuration и EF Calib­
ration_Add_Data присъстват само във версия 2 на 
картата за монтаж и настройки от поколение 2.  
— cardStructureVersion в EF Application_Identification е 
равно на {01 01} за версия 2 на картата за монтаж и 
настройки от поколение 2, докато за версия 1 на 
картата за монтаж и настройки от поколение 2 
това беше равно на {01 00}.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 291
  
В тази таблица се използват следните съкращения за 
условията за сигурност:  
SC1 ALW ИЛИ SM-MAC-G2  
SC5 За командата Read Binary с четен байт INS: 
SM-C-MAC-G2 И SM-R-ENC-MAC-G2  
За командата Read Binary с нечетен байт INS (ако 
се поддържа): NEV  
▼B 
TCS_161 Структурите на всички EF трябва да бъдат прозрачни.  
TCS_162 Приложението от поколение 2 за картата за монтаж и 
настройки трябва да е със следната структура на 
данните:  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 292
  
▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 293
  
▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 294
  
▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 295
  
▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 296  
TCS_163 Следните стойности, използвани за указване на размери 
в таблицата по-горе, определят минималния и макси­ 
малния брой на записите, който трябва да се използва 
за приложение от поколение 2 в структурата на данните 
в картата за монтаж и настройки:  
▼M3 
Мин . Макс . 
n 1 NoOfEventsPerType  3  3  
n 2 NoOfFaultsPerType  6  6  
n 3 NoOfCardVehicleRecords  8  8  
n 4 NoOfCardPlaceRecords  8  8  
n 5 NoOfCalibrationRecords  255  255  
n 6 CardActivityLengthRange  492 байта 
(1 ден * 
240 промени на 
дейността)  492 байта (1 ден * 
240 промени на 
дейността)  
n 7 NoOfCardVehicleUnitRecords  8  8  
n 8 NoOfGNSSADRecords  2 4  2 4  
n 9 NoOfSpecificConditionRecords  4  4  
n 10 NoOfBorderCrossingRecords  4  4  
n 11 NoOfLoadUnloadRecords  8  8  
n 12 NoOfLoadTypeEntryRecords  4  4  
n 13 VuConfigurationLengthRange  3072 байта  3072 байта  
▼B 
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 — 21.08.2023 — 003.001 — 297
  
TCS_167 Следните стойности, използвани за указване на размери 
в таблицата по-горе, определят минималния и макси­ 
малния брой на записите, който трябва да се използва 
за приложение от поколение 1 в структурата на данните 
в контролната карта:
  
4.4.2  Приложение  от поколение  2 за контролната  карта  
▼M3 
TCS_168 След персонализирането на приложението от поколение 
2 за контролната карта то трябва да е със следната 
постоянна файлова структура и правила за достъп до 
файловете:  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 298  
Забележки : 
— краткият идентификатор SFID на EF се дава като 
десетично число — например стойността 30 съот­ 
ветства на 11110 в двоичната бройна система.  
— EF Application_Identification_V2 и EF VU_Configu­
ration присъстват само във версия 2 на контролната 
карта от поколение 2,  
— cardStructureVersion в EF Application_Identification е 
равно на {01 01} за версия 2 на контролната карта 
от поколение 2, докато за версия 1 на контролната 
карта от поколение 2 това беше равно на {01 00}.
  
В тази таблица се използват следните съкращения за 
условието за сигурност:  
SC1 ALW ИЛИ SM-MAC-G2  
SC5 За командата Read Binary с четен байт INS: 
SM-C-MAC-G2 И SM-R-ENC-MAC-G2  
За командата Read Binary с нечетен байт 
INS (ако се поддържа): NEV  
▼B 
TCS_169 Структурите на всички EF трябва да бъдат прозрачни.  
TCS_170 Приложението от поколение 2 за контролната карта 
трябва да е със следната структура на данните:  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 299
  
▼B TCS_171  Следните стойности, използвани за указване на размери в 
таблицата по-горе, определят минималния и максималния 
брой на записите, който трябва да се използва за 
приложение от поколение 2 в структурата на данните в 
контролната карта:  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 300  
Мин . Макс . 
n 7 NoOfControlActivityRecords  230  520  
n 13 VuConfigurationLengthRange  3072 байта  3072 байта  
▼B 
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 за картата на превозвач 
трябва да е със следната структура на данните:
  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 301  
TCS_175 Следните стойности, използвани за указване на размери 
в таблицата по-горе, определят минималния и макси­ 
малния брой на записите, който трябва да се използва 
за приложение от поколение 1 в структурата на данните 
в картата на превозвач:
  
4.5.2  Приложение  от поколение  2 за картата  на превозвач  
▼M3 
TCS_176 След персонализирането на приложението от поколение 
2 за картата на превозвач то трябва да е със следната 
постоянна файлова структура и правила за достъп до 
файловете:  
Забележки : 
— краткият идентификатор SFID на EF се дава като 
десетично число — например стойността 30 съот­ 
ветства на 11110 в двоичната бройна система.  
— EF Application_Identification_V2 и EF VU_Configu­
ration присъстват само във версия 2 на картата на 
превозвач от поколение 2,  
— cardStructureVersion в EF Application_Identification е 
равно на {01 01} за версия 2 на картата на 
превозвач от поколение 2, докато за версия 1 на 
картата на превозвач от поколение 2 това беше 
равно на {01 00}.
  
В тази таблица се използват следните съкращения за 
условието за сигурност:  
SC1 ALW ИЛИ SM-MAC-G2  
SC5 За командата Read Binary с четен байт INS: 
SM-C-MAC-G2 И SM-R-ENC-MAC-G2  
За командата Read Binary с нечетен байт 
INS (ако се поддържа): NEV  
▼B 
TCS_177 Структурите на всички EF трябва да бъдат прозрачни.  
TCS_178 Приложението от поколение 2 за картата на превозвач 
трябва да е със следната структура на данните:  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 302
  
▼B 
TCS_179 Следните стойности, използвани за указване на размери 
в таблицата по-горе, определят минималния и макси­ 
малния брой на записите, който трябва да се използва 
за приложение от поколение 2 в структурата на данните 
в картата на превозвач:  
▼M3 
Мин . Макс . 
n 8 NoOfCompanyActivityRecords  230  520  
n 13 VuConfigurationLengthRange  3072 байта  3072 байта  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 303  
Допълнение  3 
ПИКТОГРАМИ  
PIC_001 При тахографите може по избор да се използват следните 
пиктограми и комбинации от пиктограми (или пиктограми и 
комбинации, които да са достатъчно сходни на тях, така че едно­  
значно да бъдат отъждествими с тях):  
1. ОСНОВНИ ПИКТОГРАМИ  
Хора  Действия  Режими  на работа
  
Предприятие  Режим на предприятие
  
Контрольор  Контрол  Контролен режим
  
Водач  Управление на МПС  Работен режим
  
Сервиз/изпитателен пункт  Техн. преглед/калиб­ 
риране  Режим на калибриране
  
Производител  
Дейности  Времетраене
  
На разположение  Текущ период на разположение
  
Управление на МПС  Време на непрекъснато управление на 
МПС
  
Почивка  Текущ период на почивка
  
Друга работа  Текущ период на работа
  
Прекъсване  Общо време на прекъсване
  
Неизвестна дейност  
Оборудване  Функции
  
Четящо устройство с процеп 
за картата на водача
  
Четящо устройство с процеп 
за картата на втория водач
  
Карта
  
Часовник
  
Дисплей  Показване върху дисплея
  
Външна памет  Изтегляне на данни
  
Електрическо захранване
  
Принтер / разпечатка  Разпечатване
  
Датчик
  
Размер на гумите
  
Превозно средство / бордово 
устройство
  
Устройство за GNSS
  
Устройство за откриване от 
разстояние
  
Интерфейс с ITS  ▼B
02016R0799 — BG — 21.08.2023 — 003.001 — 304  
Специфични  условия , ръчно  въвеждане
  
Извън обхват
  
Пътуване с ферибот/влак
  
Операция по товарене,
  
Операция по разтоварване,
  
Операция по едновременно товарене и разто­ 
варване,
  
Тип на товара пътници
  
Тип на товара стоки
  
Тип на товара неопределен тип на товара  
▼B 
Други
  
Събития
  Неизправности
  
Начало на дневен период на работа
  Край на дневен период на 
работа
  
Местоположение
  
Ръчно въвеждане на дейностите, 
извършвани от водача  
▼M3
 
Сигурност/данни с удостоверена 
автентичност/печати  
▼B
 
Скорост
  
Час
 
Общо/обобщение (справка)  
▼M3
 
Цифрова карта/пресичане на 
граница  
▼B 
Определения  
24h За деня
  
За седмица
  
За две седмици
  
От или към  
2. КОМБИНАЦИИ ОТ ПИКТОГРАМИ  
Други
  
Контролен пункт
  
Местоположение в началото на 
дневния период на работа
  Местоположение в края на 
дневния период на работа  
▼M1
 
Местоположение след 3 часа общо 
време на управление на МПС  
▼B
 
От … часа
  До … часа
  
От превозното средство
  
Начало на излизането извън обсег
  Край на излизането извън обсег  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 305
  
Местоположение, в което 
превозното средство е пресекло 
границата между две държави
  
Местоположение, в което е 
извършена операция по товарене
  
Местоположение, в което е 
извършена операция по разто­ 
варване
  
Местоположение, в което е 
извършена операция по едно­ 
временно товарене и разтоварване  
▼B 
Карти
  
Карта на водач
  
Карта на превозвач
  
Контролна карта
  
Карта за монтаж и настройки
  
Без карта  
Управление  на МПС
  
Управление на МПС в екип
  
Време на управление на МПС за една седмица
  
Време на управление на МПС за две седмици  
Разпечатки
  
Ежедневна разпечатка на дейностите, извършвани от водача, извле чени 
от картата
  
Ежедневна разпечатка на дейностите, извършвани от водача, извле чени 
от VU (бордовото устройство)
  
Разпечатка на събитията и неизправностите, извлечени от картата
  
Разпечатка на събитията и неизправностите, извлечени от VU
  
Разпечатка на техническите данни
  
Разпечатка за превишаването на допустимата скорост  
▼M3
 
Разпечатка за вкарвани карти в минали периоди  
▼B 
Събития
  
Вкарване на невалидна карта
  
Конфликт, предизвикан от картата
  
Припокриване във времето
  
Управление на МПС без съответната карта
  
Вкарване на карта по време на управление на МПС
  
Неправилно приключване на последната картова сесия
  
Превишаване на допустимата скорост
  
Прекъсване на електрическото захранване
  
Грешка в данните за движението
  
Противоречие в данните относно движението на превозното средств о
 
Нарушаване на сигурността  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 306
  
Времеви конфликт или сверяване на часовника (в сервиз)  
▼B
 
Контрол на превишаването на допустимата скорост  
▼M1
 
Липса на информация за местоположението от приемник на сигнали 
от GNSS или Грешка в комуникацията с външното устройство за 
GNSS
  
Грешка в комуникацията с устройството за връзка от разстояние  
▼M3
 
Аномалия на GNSS  
▼B 
Неизправности
  
Дефектна карта (в процепа на четящото устройство за картата на 
водача)
  
Дефектна карта (в процепа на четящото устройство за картата на 
втория водач)
  
Неизправност в дисплея
  
Грешка при изтеглянето на данни
  
Неизправност в принтера (печатащото устройство)
  
Неизправност на датчика
  
Неизправност вътре във VU
  
Неизправност във връзка с GNSS
  
Неизправност във връзка с откриването от разстояние  
Процедура  по ръчно  въвеждане
  
За същия дневен период на работа?
  
Край на предишен период на работа?
  
Потвърждение или въвеждане на местоположението в края на 
дневния период на работа
  
Въвеждане на часа на тръгване
  
Въвеждане на местоположението в началото на периода на работа.  
Забележка : в допълнение 4 са определени допълнителни 
комбинации от пиктограми с оглед да се получат блокове за 
разпечатване или идентификатори на записи.  ▼M1
 02016R0799 — BG — 21.08.2023 — 003.001 — 307  
Допълнение  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 Полетата с цифрови данни се отпечатват с подравняване 
отдясно и без нули в началото на числата, като групите 
от цифри за хилядите и за милионите се разделят с 
празен интервал.  
▼M3 
PRT_005 Полетата за данни, състоящи се от символни низове, се 
отпечатват с подравняване отляво и при необходимост се 
допълват с празни интервали или се отрязват съобразно 
дължината на елемента от данни. Имената и адресите 
могат да бъдат отпечатвани на два реда.  
▼B 
PRT_006  Ако се налага пренос на нов ред поради дълъг текст, като 
първи символ на новия ред следва да се отпечата 
специален знак (точка на половината височина на реда „•“).  
2. СПЕЦИФИКАЦИЯ ЗА БЛОКОВЕТЕ ДАННИ  
В настоящата глава се прилагат следните условни обозначения за 
формата:  
— символите, които са изписани с  удебелен  шрифт, обозначават 
обикновен текст (отпечатват се същите символи, но с нормален 
шрифт);  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 308  
— символите с нормален шрифт обозначават променливи 
(пиктограми или данни), които се заместват при отпечатването 
с техните съответни стойности;  
— имената на променливите се допълват от знаци за подчертаване,  
за да се посочи допустимата дължина на елемента от данни за 
съответната променлива;  
— датите се указват във формата „дд/мм/гггг“ (ден/месец/година) . 
Може да се използва и формат „дд.мм.гггг“.  
— Терминът „Идентификация на картата“ обхваща съвкупността 
от: типа на картата, обозначен чрез комбинация от пиктограми, 
кода на държавата членка, която е издала картата, наклонена 
надясно черта и номер на картата с индекс за замяна и индекс 
за подновяване, разделени от един празен интервал: 
P
 x  x  x  / x  x  x  x  x  x  x  x  x  x  x  x  x  x  x  x
 Комбинация от 
пиктограми за 
картата  
Код на издаващата 
държава членка Първите 14 символа от номера на картата 
(евентуално включително индекс за последователност)
 
Индекс за подмяна  
Индекс за подновяване 
▼M3 
— В даден блок от данни текстът след „pi=“ се отнася до съот­ 
ветната пиктограма или комбинация от пиктограми, определени 
в допълнение 3,  
— Когато се отпечатва след географската дължина и географската 
ширина на записано местоположение или след датата и часа на 
определяне на местоположението,
  пиктограмата показва, че 
това местоположение е изчислено въз основа на навигационни 
съобщения с удостоверена автентичност,  
— * данни, налични само в тахографите GEN2 (всички версии),  
— ** данни, налични само в GEN2, версия 2.  ▼B
02016R0799 — BG — 21.08.2023 — 003.001 — 309  
PRT_007 Разпечатките се състоят от следните блокове и/или запис и от 
данни със следните значения и формати:
  
► (1) (2) (3) (4) (5)  M3 ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 310
  
► (1) (2) (3)  M3 ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 311
  
► (1) (2) M3 ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 312
  
▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 313
  
► (1) (2) (3) (4)  M3 ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 314
  
▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 315
  
► (1) M3 
3. СПЕЦИФИКАЦИИ ЗА РАЗПЕЧАТКИТЕ  
В настоящата глава се прилагат следните условни обозначения: 
N Отпечатване на блока или на записа с номер N  
N Отпечатване на блока или на записа номер N, повторен толкова 
пъти, колкото е необходимо  
X/Y Отпечатване на блоковете или на записите Х и/или Y, според 
нуждите, и повторение на операцията толкова пъти, колкото е 
необходимо  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 316  
3.1. Ежедневна  разпечатка  на данните  за дейностите  на водача , 
извлечени  от карта  
▼M3 
PRT_008 Ежедневната разпечатка на данните за дейностите на 
водача, извлечени от карта, трябва да бъде в съответствие 
със следния формат:
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 317  
3.2. Ежедневна  разпечатка  на данните  за дейностите  на водача , 
извлечени  от бордовото  устройство  
▼M3 
PRT_009 Ежедневната разпечатка на данните за дейностите на 
водача, извлечени от бордовото устройство, трябва да 
бъде в съответствие със следния формат:
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 318  
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 Подпис на водача  
3.4. Разпечатка  на данните  за събития  и неизправности , извлечени  
от бордовото  устройство  
PRT_011 Разпечатката на данните за събития и неизправности, 
извлечени от бордовото устройство, трябва да е в съот­ 
ветствие със следния формат: 
1 Дата и час на отпечатване на документа  
2 Тип на разпечатката  
3 Идентификация на титуляря на картата (за всички карти, вкарани 
във VU + GEN)  
4 Идентификация на превозното средство (от което е направена 
разпечатката)  
13.2 Разграничител на данни за събитията  
13.4 Записи за събития (за всички събития, които са записани или са в 
процес на записване в бордовото устройство)  
13.3 Разграничител на данни за неизправности  
13.4 Записи за неизправности (за всички неизправности, които са 
записани или са в процес на записване в бордовото устройство)  
22.1 Контролен пункт  
22.2 Подпис на контрольора  
22.5 Подпис на водача  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 319  
3.5. Разпечатка  на техническите  данни  
▼M3 
PRT_012 Разпечатката на техническите данни трябва да е в съот­ 
ветствие със следния формат:
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 320  
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. Разпечатка  за историята  на вкараните  карти  
▼M3 
PRT_014 Разпечатката за историята на вкараните карти трябва да е 
в съответствие със следния формат:
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 321  
Допълнение  5 
ПОКАЗВАНЕ  
В настоящото допълнение се прилагат следните условни обозначени я за 
формата:  
— символите, които се изписани с  удебелен  шрифт, обозначават обикновен 
текст, който трябва да се покаже (показват се същите символи, н о с 
нормален шрифт),  
— символите с нормален шрифт обозначават променливи (пиктограми  или 
данни), които се заместват при показването с техните съответни 
стойности:  
— дд мм гггг: ден, месец, година,  
— hh: часове,  
— mm: минути,  
— D: пиктограма за времетраене,  
— EF: комбинация от пиктограми за събитие или неиз­ 
правност,  
— O: пиктограма за режим на работа.  
DIS_001 Тахографът трябва да показва данните в следните формати : 
Данни  Формат  
Показване  по подразбиране  
Местно време
  
Режим на работа
  
Информация относно водача:
  
Информация относно втория водач:
  
Отворено условие „Извън обсег“
  
Показване  на предупреждение  
Надвишаване на времето за непрекъснато управление на 
МПС
  
Събитие или неизправност
  
Показване  на други  данни  
Дата по координирано универсално време (UTC)
  
час 
Време на непрекъснато управление на МПС и общо 
време на прекъсване за водача
  
Време на непрекъснато управление на МПС и общо 
време на прекъсване за втория водач
  
Общо време на управление на МПС на водача през 
текущата и предходната седмица
  
Общо време на управление на МПС на втория водач 
през текущата и предходната седмица
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 322  
Допълнение  6 
ПРЕДЕН  СЪЕДИНИТЕЛ  ЗА КАЛИБРИРАНЕ  И ИЗТЕГЛЯНЕ  НА 
ДАННИ  
СЪДЪРЖАНИЕ  
1. ХАРДУЕР  
1.1. Съединител  
1.2. Разпределение на контактите  
1.3. Блоксхема  
2. ИНТЕРФЕЙС ЗА ИЗТЕГЛЯНЕ НА ДАННИ  
3. ИНТЕРФЕЙС ЗА КАЛИБРИРАНЕ  
1. ХАРДУЕР  
1.1. Съединител  
INT_001 Съединителят за калибриране/изтегляне на данни трябва д а е 
с шест крачета, да е достъпен върху лицевия панел, без да се 
налага разкачване на каквато и да е част на тахографа, и да е 
в съответствие със следния чертеж (всички размери са 
дадени в милиметри):
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 323  
На следната схема е показан обичаен контактен съединител 
с 6 крачета:
  
1.2. Разпределение  на контактите  
INT_002 Контактите трябва да са разпределени съгласно следната 
таблица:  
Краче  Описание  Забележка  
1 Отрицателен полюс на 
акумулатора  Свързан към отрицателната клема на акумулатора на 
превозното средство  
2 Предаване на данни  Линия K (ISO 14230-1)  
3 RxD — изтегляне на данни  Входящи данни към тахографа  
4 Входен/изходен сигнал  Калибриране  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 324  
Краче  Описание  Забележка  
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 — 21.08.2023 — 003.001 — 325  
3. ИНТЕРФЕЙС ЗА КАЛИБРИРАНЕ  
INT_007 Предаването на данни трябва да е в съответствие с ISO 1 4 
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  m A  
U high (високо ниво 
на изходния сигнал)  4 V I  =  1  m A  
INT_009 Входният/изходният сигнал трябва да е в съответствие съ с 
следните хронограми:
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 326  
Допълнение  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 — 21.08.2023 — 003.001 — 327  
2.2.5 Обработка на грешки  
2.2.5.1 Start Communication phase  
2.2.5.2 Communication phase  
2.2.6 Съдържание на съобщенията за отговор  
▼M3 
2.2.6.1 Positive Response Transfer Data Download Interface Vers ion (Поло­ 
жителен отговор за трансфер на данни — Версия на интерфейса за 
изтегляне)  
2.2.6.2 Positive Response Transfer Data Overview (Положителен о тговор за 
трансфер на данни — Преглед)  
2.2.6.3 Positive Response Transfer Data Activities (Положителен  отговор за 
трансфер на данни — Дейности  
2.2.6.4 Positive Response Transfer Data Events and Faults Activ ities (Поло­ 
жителен отговор за трансфер на данни — Дейсности, свързани със 
събитя и неизправности)  
2.2.6.5 Positive Response Transfer Data Detailed Speed Activiti es (Поло­ 
жителен отговор за трансфер на данни — Дейности за подробната 
скорост)  
2.2.6.6 Positive Response Transfer Data Technical Data(Положите лен отговор 
за трансфер на данни — Технически данни  
▼B 
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 — 21.08.2023 — 003.001 — 328  
— през бордовото устройство от тахографска карта чрез 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 — 21.08.2023 — 003.001 — 329  
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  …  …  …  C S  
4 байта  255 байта максимум  1 байт  
Байтовете TGT и SRC представляват физическите 
адреси на получателя и изпращача на съобщението. Те 
приемат стойностите F0 Hex за IDE и EE Hex за VU.  
Байтът LЕN е дължината на полето за данни.  ▼B 
(*) Поставянето на картата активира съответните права за достъп  до функцията за 
изтегляне на данни и до данните. Трябва да е възможно обаче изт еглянето на 
данни от карта на водач, вкарана в един от процепите на VU, ког ато в другия 
процеп не е поставена друга карта.
 02016R0799 — BG — 21.08.2023 — 003.001 — 330  
Байтът за контролна сума е серия от суми по 8 бита по 
модул 256, които представляват всички байтове на съоб­ 
щението с изключение на самата CS.  
Байтовете FMT, SID, DS_, TRTP и TREP са определени 
по-нататък в този документ.  
DDP_003 Ако дължината на данните, които трябва да се пренесат 
от съобщението, надхвърля свободното пространство в 
полето за данни, изпращането на това съобщение става 
под формата на няколко подсъобщения. Всяко подсъ­ 
общение съдържа заглавна част, същите SID, TREP и 
брояч на подсъобщения от 2 байта, който посочва 
номера на подсъобщението в рамките на цялото 
съобщение. С цел проверка за грешки и евентуално 
прекратяване на обмена на данни IDE потвърждава 
получаването на всяко подсъобщение. IDE може да 
приеме подсъобщение, да поиска повторното му 
предаване и да поиска от VU да възобнови или да 
прекрати предаването.  
DDP_004 Ако полето за данни на последното подсъобщение 
съдържа точно 255 байта, е необходимо да се прибави 
едно последно подсъобщение, което съдържа празно 
поле за данни (с изключение на SID TREP и брояча на 
подсъобщения), за да покаже края на съобщението.  
Пример : 
Заглавна част  SID  TREP  Съобщение  C S  
4 байта  Дължина, по-голяма от 255 байта  
Ще бъде предадено като:  
Заглавна част  SID  TREP  0 0  0 1  Подсъобщение 1  C S  
4 байта  255 байта  
Заглавна част  SID  TREP  0 0  0 2  Подсъобщение 2  C S  
4 байта  255 байта  
… 
Заглавна част  SID  TREP  x x  y y  Подсъобщение n  C S  
4 байта  По-малка от 255 байта  
или като:  
Заглавна част  SID  TREP  0 0  0 1  Подсъобщение 1  C S  
4 байта  255 байта  
Заглавна част  SID  TREP  0 0  0 2  Подсъобщение 2  C S  
4 байта  255 байта  
… 
Заглавна част  SID  TREP  x x  y y  Подсъобщение n  C S  
4 байта  255 байта  
Заглавна част  SID  TREP  x x  yy + 1  C S  
4 байта  4 байта  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 331  
2.2.2  Типове  съобщения  
Протоколът за връзка за изтегляне на данни между VU и IDE 
изисква обмен на 8 различни типа съобщения.  
Следващата таблицата обобщава тези съобщения.  
▼M3 
Структура на съобщението  4 байта максимум  255 байта максимум  1 байт  
Заглавна част  Данни  Контролна 
сума  
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DATA 
(ДАННИ)  CS 
Start Communication Request (Искане 
за започване на комуникация)  81 E E  F 0  8 1  E 0  
Positive Response Start Communi­
cation (Положителен отговор за 
започване на комуникация)  80 F 0  E E  0 3  C 1  EA, 8F  9 B  
Start Diagnostic Session Request (Искане 
за започване на сесия по диагностика)  80 E E  F 0  0 2  1 0  8 1  F 1  
Positive Response Start Diagnostic 
(Положителен отговор за започване 
на сесия по диагностика)  80 F 0  E E  0 2  5 0  8 1  3 1  
Link Control Service (Функция за 
контрол на връзката)  
Verify Baud Rate (stage 1) (Проверка 
на скоростта на предаване (етап 1))  
9 600 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,01  E C  
19 200 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,02  E D  
38 400 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,03  E E  
57 600 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,04  E F  
115 200 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,05  F 0  
Positive Response Verify Baud Rate 
(Положителен отговор за проверка 
на скоростта на предаване)  80 F 0  E E  0 2  C 7  0 1  2 8  
Transition Baud Rate (stage 2) 
(Преходна скорост на предаване 
(етап 2))  80 E E  F 0  0 3  8 7  0 2  0 3  E D  
Request Upload (Искане за качване)  8 0  E E  F 0  0 A  3 5  00,00,00,00­
,00,FF,FF, 
FF,FF  99 
Positive Response Request Upload 
(Положителен отговор на искане за 
качване)  80 F 0  E E  0 3  7 5  00,FF  D 5  
Transfer Data Request (Искане за 
трансфер на данни)  
Download interface version (Версия 
на интерфейса за изтегляне)  80 E E  F 0  0 2  3 6  0 0  9 6  
Overview (Преглед)  80 E E  F 0  0 2  3 6  01, 21 или 31  C S  
Activities(Дейности)  80 E E  F 0  0 6  3 6  02, 22 или 32  Date (Дата)  C S  
Events & Faults (Събития и неиз­ 
правности)  80 E E  F 0  0 2  3 6  03, 23 или 33  Date  C S  
Detailed Speed (Подробна скорост)  80 E E  F 0  0 2  3 6  04 or 24  Date  C S  
Technical Data (Технически данни)  80 E E  F 0  0 2  3 6  05, 25 или 35  Date  C S  
Card download (Изтегляне на 
карта)  80 E E  F 0  02 or 03  3 6  0 6  Slot (Процеп)  C S  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 332  
Структура на съобщението  4 байта максимум  255 байта максимум  1 байт  
Заглавна част  Данни  Контролна 
сума  
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DATA 
(ДАННИ)  CS 
Positive Response Transfer Data 
(Положителен отговор за трансфер 
на данни)  80 F 0  E E  Len  7 6  TREP  Data (Данни)  C S  
Request Transfer Exit (Искане за 
трансфер, излизане)  80 E E  F 0  0 1  3 7  9 6  
Positive Response Request Transfer 
Exit (Положителен отговор на 
искане за трансфер, излизане)  80 F 0  E E  0 1  7 7  D 6  
Stop Communication Request (Искане 
за прекратяване на комуникацията)  80 E E  F 0  0 1  8 2  E 1  
Positive Response Stop Communi­
cation (Положителен отговор за 
прекратяване на комуникацията)  80 F 0  E E  0 1  C 2  2 1  
Acknowledge sub message (Потв­ 
ръждение на подфункция)  80 E E  F 0  Len  8 3  Data (Данни)  C S  
Negative responses (Отрицателни 
отговори)  
General reject (Общо отхвръляне)  8 0  F 0  E E  0 3  7 F  Sid Req  1 0  C S  
Service not supported (Функцията не 
се поддържа)  80 F 0  E E  0 3  7 F  Sid Req  1 1  C S  
Sub function not supported (Подфун­ 
кцията не се поддържа)  80 F 0  E E  0 3  7 F  Sid Req  1 2  C S  
Incorrect Message Length 
(Неправилна дължина на съоб­ 
щението)  80 F 0  E E  0 3  7 F  Sid Req  1 3  C S  
Conditions not correct or Request 
sequence error (Неправилни условия 
или грешка в искането)  80 F 0  E E  0 3  7 F  Sid Req  2 2  C S  
Request out of range (Искане извън 
обхвата)  80 F 0  E E  0 3  7 F  Sid Req  3 1  C S  
Upload not accepted (Качването не е 
прието)  80 F 0  E E  0 3  7 F  Sid Req  5 0  C S  
Response pending (Очакване на 
отговор)  80 F 0  E E  0 3  7 F  Sid Req  7 8  C S  
Data not available (Данните не са 
налични)  80 F 0  E E  0 3  7 F  Sid Req  F A  C S  
Забележки : 
— Sid Req = Sid на съответната заявка.  
— TREP = TRTP на съответната заявка.  
— Черните полета означават, че нищо не е предадено.  
— Терминът „upload“ [„качване на данни“] (от IDE) се използва з а 
съвместимостта със стандарта ISO 14229. Този термин е със 
същото значение като „download“ [„изтегляне на данни“] (от 
VU).  
— В тази таблица не са показани потенциални броячи за подсъ­ 
общения от 2 байта.  
— Процеп е номерът на процепа — или 1 (карта в процепа за 
водача), или 2 (карта в процепа за втория водач).  
— Ако процепът не е посочен, VU избира процеп 1, ако картата е 
поставена в този процеп, а процеп 2 — само ако този процеп е 
специално избран от потребителя.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 333  
— TRTP 24 се използва за поколение 2, версия 1 и версия 2 на 
заявките за изтегляне на данни от бордовото устройство.  
— TRTP 00, 31, 32, 33 и 35 се използват за заявки от тип 
поколение 2, версия 2 за изтегляне на данни от бордовото 
устройство.  
— TRTP 21, 22, 23 и 25 се използват за поколение 2, версия 1 на  
заявките за изтегляне на данни от бордовото устройство.  
— TRTP 01—05 се използват за поколение 1 на заявките за 
изтегляне на данни от VU. Те могат да бъдат приети по 
избор от бордово устройство от поколение 2, но само в 
рамките на контрол на водачите, извършван от контролен 
орган извън ЕС, като се използва контролна карта от първо 
поколение.  
— TRTP 11—19 и 31—39 са запазени за заявки за специфични 
изтегляния на данни от производителя.  
▼B 
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 бода (до момента, когато тази 
скорост за предаване на данни се промени с помощта 
на съответните услуги за контрол на връзките).  
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 преминава към новата скорост за 
предаване на данни.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 334  
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 байта.  
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) на 
определен байт показва типа трансфер.  
▼M3 
Съществуват седем типа трансфер на данни. За 
изтегляне на данни от бордовото устройство за всеки 
тип трансфер могат да се използват две различни 
стойности на TRTP:  
Тип трансфер на данни  Стойност на TRTP за 
изтегляне на данни 
от бордово устройство от 
поколение 1  Стойност на TRTP за 
изтегляне на данни 
от бордово устройство от 
поколение 2, версия 1  Стойност на TRTP за 
изтегляне на данни 
от бордово устройство от 
поколение 2, версия 2  
Download interface version 
(Версия на интерфейса за 
изтегляне)  Не се използва  Не се използва  0 0  
Overview (Преглед)  0 1  2 1  3 1  
Activities of a specified date 
(Дейности на определена 
дата)  02 2 2  3 2  
Events and faults (Събития и 
неизправности)  03 2 3  3 3  
Detailed speed (Подробна 
скорост)  04 2 4  2 4  
Technical data (Технически 
данни)  05 2 5  3 5  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 335  
Тип трансфер 
на данни  Стойност на 
TRTP  
Card download  0 6  
▼M3 
DDP_054 За IDE е задължително да заяви overview data transfer 
(TRTP 01, 21 или 31) по време на сесия за изтегляне 
на данни, защото единствено това гарантира, че серти­ 
фикатите на бордовото устройство се регистрират в 
изтегления файл (и това позволява проверката на 
цифровия подпис).  
В третия случай (TRTP 02, 22 или 32) съобщението Transfer Data 
Request съдържа указание за календарния ден (формат TimeReal), 
чиито данни трябва да се изтеглят.  
▼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 на заявката.  
▼M3 
DDP_055 В първия случай (TREP 01, 21 или 31) бордовото 
устройство ще изпрати данни, предназначени да 
помогнат на потребителя на IDE при избора на 
данните, които иска да изтегли. Съобщението съдържа 
следната информация:  
▼M1 
— сертификати за сигурност,  
— идентификация на превозното средство,  
— актуалната дата и час на бордовото устройство,  
— най-ранната и най-късната дата за изтегляне на 
данните (данни от бордовото устройство),  
— указване за наличието на карти в бордовото 
устройство,  
— предишни изтеглени данни към превозвач,  
— блокировки от страна на превозвача,  
— предишни проверки.  
▼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.  ▼M1
 02016R0799 — BG — 21.08.2023 — 003.001 — 336  
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)  
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 — общо отхвърляне  
Действието не може да се изпълни по причина, 
която не се разглежда по-нататък.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 337  
— 11 — услугата не се поддържа  
SID на заявката не се разбира.  
— 12 — подфункцията не се поддържа  
DS_ или TRTP на заявката не се разбира или пред­ 
аването на подсъобщения е приключило.  
— 13 — неправилна дължина на съобщение  
Дължината на полученото съобщение е грешна.  
— 22 — неправилни условия или грешка, която засяга 
последователността на заявяването  
Заявената услуга не е активна или последовател­ 
ността на съобщенията за заявката е неправилна.  
— 31 — недопустимост на заявката  
Записването (полето за данни) на параметъра на 
заявката не е валидно.  
— 50 — качването на данни не е прието  
Заявката не може да се изпълни (VU се използва в 
несвойствен режим на работа или има някаква 
вътрешна неизправност на VU).  
— 78 — изчакване на отговор  
Заявеното действие не може да приключи в опред­ 
еленото време и VU няма готовност да приеме друга 
заявка.  
▼M1 
— Данни FA, които не са на разположение  
Обектът от данни на заявка за трансфер на данни не 
е достъпен в бордовото устройство (например не е 
поставена карта; получената заявка за изтегляне на 
данни от бордовото устройство от поколение 1 не е 
при проверка на водача от контролен орган на 
държава извън ЕС...).  
▼B 
2.2.3  Поток  на съобщенията  
При нормална процедура за изтегляне на данни потокът на съоб­ 
щенията обикновено е следният:  
IDE V U  
Start Communication Request  ⇨ 
⇦  Positive Response  
Start Diagnostic Service Request  ⇨ 
⇦  Positive Response  
Request Upload  ⇨ 
⇦  Positive Response  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 338  
IDE V U  
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 — 21.08.2023 — 003.001 — 339  
В следващата таблица са показани разрешените 
стойности за параметрите за синхронизация (разширен 
набор от параметри за синхронизация KWP, използвани 
в случай на физическо адресиране за по-бърза връзка).  
Синхронизация Параметър  Долна граница 
Стойност (в ms)  Горна граница 
Стойност (в ms)  
P1 0  2 0  
P2 2 0  1 000 (*)  
P3 1 0  5 000  
P4 5  2 0  
P5 1 0  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 — 21.08.2023 — 003.001 — 340  
Фигура  2 
Обработка  на грешки  във VU
 
▼B 
2. IDE открива  грешка  при предаването  от VU 
DDP_025 IDE извършва анализ на всяко получено съобщение, 
за да открие евентуална грешка по синхронизирането, 
структурата на байтовете (например нарушения, 
които засягат началните битове и битовете за край) 
или грешки във връзка с кадрите (приемане на грешен 
брой байтове, грешен байт за контролна сума).  
DDP_026 IDE открива грешки при последователността, като 
например погрешно увеличение на брояча на подсъ­ 
общения в последователно получени съобщения.  
DDP_027 Ако IDE открие грешка или ако VU не му изпрати 
никакъв отговор в срок от максимум Р2, съобщението 
за заявка ще бъде отново изпратено общо най-много 
три пъти. За целите на това откриване на грешки 
всяко потвърждаване за подсъобщение ще се 
разглежда като заявка до VU.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 341  
DDP_028 IDE трябва да изчака в продължение най-малко на 
Р3min, преди започване на предаване на данни; 
времето за изчакване се измерва от последната 
поява на бит за край след откриване на съответната 
грешка.  
Фигура  3 
Обработка  на грешки  на ниво  на IDE
  
2.2.6  Съдържание  на съобщенията  за отговор  
В този параграф е определено съдържанието на полетата за данни 
на различните положителни съобщения за отговор.  
Елементите от данни са определени в допълнение 1 (Речник на 
данните).  
Забележка: при изтеглените данни от поколение 2 всеки елемент 
от данни от най-високо ниво е представен от масив записи дори 
ако съдържа само един запис. Масивът записи започва със 
заглавна част, която съдържа типа, размера и броя записи. 
Масивите записи имат наименованието„…RecordArray“ (със 
заглавна част) в следващите таблици.  
▼M3 
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  D o w n l o a d 
I n t e r f a c e V e r s i o n  
DDP_028a Полето за данни на съобщението „Positive Response 
Transfer Data Download Interface Version“ трябва да 
дава данните по-долу в следния ред по SID 76 Hex, 
TRЕP 00 Hex:  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 342  
Структура на данните от поколение 2, версия 2 (TREP 00 Hex)  
Елемент от данни  Коментар  
DownloadInterfaceVersion  Поколение и версия на бордовото устройство: 
02,02 Hex за поколение 2, версия 2. 
Не се поддържа от бордови устройства 
поколение 1 и поколение 2, версия 1, които 
трябва да отговорят отрицателно (Подфун­ 
кцията не се поддържа, вж. DDP_018 — Sub 
function not supported, see DDP_018)  
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  O v e r v i e w  
DDP_029 Полето за данни на съобщението „Positive Response 
Transfer Data Overview“ трябва да дава данните по- 
долу по следния ред по SID 76 Hex, TRЕP 01, 21 
или 31 Hex и съответните критерии за разделяне и 
преброяване на подсъобщенията:  
Структура на данните от поколение 1 (TREP 01 Hex)  
Елемент от данни  Коментар  
MemberStateCertificate  Сертификати за сигурност на VU  
VUCertificate  
VehicleIdentificationNumber  Идентификация на превозното средство  
VehicleRegistrationIdentification  
CurrentDateTime  Актуална дата и час на VU  
VuDownloadablePeriod  Период за изтегляне на данни  
CardSlotsStatus  Тип карти, вкарани във VU  
VuDownloadActivityData  Предишни изтеглени данни от VU  
VuCompanyLocksData  Всички съхранени блокировки от страна на 
превозвача. Ако тази част е празна, се 
изпраща само noOfLocks = 0  
VuControlActivityData  Всички съхранени във VU контролни записи. 
Ако тази част е празна, се изпраща само noOf­
Controls = 0  
Signature  RSA подпис на всички данни (освен сертифи­ 
катите), започвайки от VehicleIdentification­
Number до последния байт на последния 
VuControlActivityData  
Структура на данните от поколение 1 (TREP 21 Hex)  
Елемент от данни  Коментар  
MemberStateCertificateRecordArray  Сертификат на държава членка  
VUCertificateRecordArray  Сертификат за VU  
VehicleIdentificationNumberRecordArray  Идентификация на превозното средство  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 343  
Елемент от данни  Коментар  
VehicleRegistrationIdentificationRecordArray  Регистрационен номер на превозното средство  
CurrentDateTimeRecordArray  Актуална дата и час на VU  
VuDownloadablePeriodRecordArray  Период за изтегляне на данни  
CardSlotsStatusRecordArray  Тип карти, вкарани във VU  
VuDownloadActivityDataRecordArray  Предишни изтеглени данни от VU  
VuCompanyLocksRecordArray  Всички съхранени блокировки от страна на 
превозвача. Ако тази част е празна, се 
изпраща заглавна част на масив с noOfRecords 
= 0 
VuControlActivityRecordArray  Всички съхранени във VU контролни записи. 
Ако тази част е празна, се изпраща заглавна 
част на масив с noOfRecords = 0  
SignatureRecordArray  ЕСС подпис на всички предходни данни освен 
сертификатите  
Структура на данните от поколение 2, версия 2 (TREP 31 Hex)  
Елемент от данни  Коментар  
MemberStateCertificateRecordArray  Сертификат на държава членка  
VUCertificateRecordArray  Сертификат за VU  
VehicleIdentificationNumberRecordArray  Идентификация на превозното средство  
VehicleRegistrationNumberRecordArray  Регистрационен номер на превозното средство  
CurrentDateTimeRecordArray  Актуална дата и час на VU  
VuDownloadablePeriodRecordArray  Период за изтегляне на данни  
CardSlotsStatusRecordArray  Тип карти, вкарани във VU  
VuDownloadActivityDataRecordArray  Предишни изтеглени данни от VU  
VuCompanyLocksRecordArray  Всички съхранени блокировки от страна на 
превозвача. Ако тази част е празна, се 
изпраща заглавна част на масив с noOfRecords 
= 0 
VuControlActivityRecordArray  Всички съхранени във VU контролни записи. 
Ако тази част е празна, се изпраща заглавна 
част на масив с noOfRecords = 0  
SignatureRecordArray  ЕСС подпис на всички предходни данни освен 
сертификатите  
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  A c t i v i t i e s  
DDP_030 Полето за данни на съобщението „Positive Response 
Transfer Data Activities“ трябва да дава данните по- 
долу по следния ред по SID 76 Hex, TRЕP 02, 22 
или 32 Hex и съответните критерии за разделяне и 
преброяване на подсъобщенията:  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 344  
Структура на данните от поколение 1 (TREP 02 Hex)  
Елемент от данни  Коментар  
TimeReal  Дата на деня, за който са изтеглени данни  
OdometerValueMidnight  Километражен брояч в края на деня, за който са 
изтеглени данни  
VuCardIWData  Данни за циклите на поставяне и изваждане на 
картите. 
— Ако тази част не съдържа данни, се изпраща 
само noOfVuCardIWRecords = 0. 
— Когато VuCardIWRecord обхваща период, който 
започва преди 00:00 ч. (поставяне на картата в 
предходния ден) или приключва след 24:00 ч. 
(изваждане на картата на следващия ден), този 
елемент от данни се появява цялостно в 
записите за двата съответни дни.  
VuActivityDailyData  Статус на процепите в 00:00 ч. и промени на 
дейността, записани за деня, за който са изтеглени 
данни  
VuPlaceDailyWorkPeriodData  Данни във връзка с местоположенията, записани за 
деня, за който са изтеглени данни. Ако тази част е 
празна, се изпраща само noOfPlaceRecords = 0  
VuSpecificConditionData  Данни във връзка със специфични условия, записани 
за деня, за който са изтеглени данни. Ако тази част е 
празна, се изпраща само noOfSpecificCondition­
Records = 0  
Signature  RSA подпис на всички данни, започвайки от 
TimeReal до последния байт на последния запис за 
специфично условие  
Структура на данните от поколение 2, версия 1 (TREP 22 Hex)  
Елемент от данни  Коментар  
DateOfDayDownloadedRecordArray  Дата на деня, за който са изтеглени данни  
OdometerValueMidnightRecordArray  Километражен брояч в края на деня, за който са 
изтеглени данни  
VuCardIWRecordArray  Данни за циклите на поставяне и изваждане на 
картите. 
— Ако тази част не съдържа налични данни, се 
изпраща заглавна част на масив с noOfRecords 
= 0. 
— Когато VuCardIWRecord обхваща период, който 
започва преди 00:00 ч. (поставяне на картата в 
предходния ден) или приключва след 24:00 ч. 
(изваждане на картата на следващия ден), този 
елемент от данни се появява цялостно в 
записите за двата съответни дни.  
VuActivityDailyRecordArray  Статус на процепите в 00:00 ч. и промени на 
дейността, записани за деня, за който са изтеглени 
данни  
VuPlaceDailyWorkPeriodRecordArray  Данни във връзка с местоположенията, записани за 
деня, за който са изтеглени данни. Ако тази част е 
празна, се изпраща заглавна част на масив с noOf­
Records = 0  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 345  
Елемент от данни  Коментар  
VuGNSSADRecordArray  Местоположения на превозното средство по GNSS, 
когато общото време на управление на превозното 
средство достигне кратно число на три часа. Ако 
тази част е празна, се изпраща заглавна част на 
масив с noOfRecords = 0  
VuSpecificConditionRecordArray  Данни във връзка със специфични условия, записани 
за деня, за който са изтеглени данни. Ако тази част е 
празна, се изпраща заглавна част на масив с noOf­
Records = 0  
SignatureRecordArray  ЕСС подпис на всички предходни данни  
Структура на данните от поколение 2, версия 2 (TREP 32 Hex)  
Елемент от данни  Коментар  
DateOfDayDownloadedRecordArray  Дата на деня, за който са изтеглени данни  
OdometerValueMidnightRecordArray  Километражен брояч в края на деня, за който са 
изтеглени данни  
VuCardIWRecordArray  Данни за циклите на поставяне и изваждане на 
картите. 
— Ако тази част не съдържа налични данни, се 
изпраща заглавна част на масив с noOfRecords 
= 0. 
— Когато VuCardIWRecord обхваща период, който 
започва преди 00:00 ч. (поставяне на картата в 
предходния ден) или приключва след 24:00 ч. 
(изваждане на картата на следващия ден), този 
елемент от данни се появява цялостно в 
записите за двата съответни дни.  
VuActivityDailyRecordArray  Статус на процепите в 00:00 ч. и промени на 
дейността, записани за деня, за който са изтеглени 
данни  
VuPlaceDailyWorkPeriodRecordArray  Данни във връзка с местоположенията, записани за 
деня, за който са изтеглени данни. Ако тази част е 
празна, се изпраща заглавна част на масив с noOf­
Records = 0  
VuGNSSADRecordArray  Местоположения на превозното средство по GNSS, 
когато общото време на управление на превозното 
средство достигне кратно число на три часа. Ако 
тази част е празна, се изпраща заглавна част на 
масив с noOfRecords = 0  
VuSpecificConditionRecordArray  Данни във връзка със специфични условия, записани 
за деня, за който са изтеглени данни. Ако тази част е 
празна, се изпраща заглавна част на масив с noOf­
Records = 0  
VuBorderCrossingRecordArray  Пресичания на граници за деня, който е изтеглен. 
Ако тази част е празна, се изпраща заглавна част 
на масив с noOfRecords = 0  
VuLoadUnloadRecordArray  Товаро-разтоварни операции за изтегления ден. Ако 
тази част е празна, се изпраща заглавна част на 
масив с noOfRecords = 0  
SignatureRecordArray  ЕСС подпис на всички предходни данни  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 346  
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  E v e n t s a n d F a u l t s  
DDP_031 Полето за данни на съобщението „Positive Response 
Transfer Data Events and Faults“ трябва да дава 
данните по-долу по следния ред по SID 76 Hex, 
TRЕP 03, 23 или 33 Hex и съответните критерии за 
разделяне и преброяване на подсъобщенията:  
Структура на данните от поколение 1 (TREP 03 Hex)  
Елемент от данни  Коментар  
VuFaultData  Всички записани или текущи неизправности във 
VU. 
Ако тази част е празна, се изпраща само noOfVu­
Faults = 0  
VuEventData  Всички записани или текущи събития във VU (освен 
превишаването на скоростта). 
Ако тази част е празна, се изпраща само noOf­
VuEvents = 0  
VuOverSpeedingControlData  Данни във връзка с последната проверка за преви­ 
шаване на скоростта (стойност по подразбиране, ако 
няма данни)  
VuOverSpeedingEventData  Всички събития „превишаване на скоростта“, 
записани във VU. 
Ако тази част е празна, се изпраща само noOfVuO­
verSpeedingEvents = 0  
VuTimeAdjustmentData  Всички събития „сверяване на часовника“, записани 
във VU (извън рамките на пълно калибриране). 
Ако тази част е празна, се изпраща само noOfVuTi­
meAdjRecords = 0  
Signature  RSA подпис на всички данни, започвайки от noOf­
VuFaults до последния байт на последния запис за 
сверяване на часовника  
Структура на данните от поколение 2, версия 1 (TREP 23 Hex)  
Елемент от данни  Коментар  
VuFaultRecordArray  Всички записани или текущи неизправности във 
VU. 
Ако тази част е празна, се изпраща заглавна част на 
масив с noOfRecords = 0  
VuEventRecordArray  Всички записани или текущи събития във VU (освен 
превишаването на скоростта). 
Ако тази част е празна, се изпраща заглавна част на 
масив с noOfRecords = 0  
VuOverSpeedingControlDataRecordArray  Данни във връзка с последната проверка за преви­ 
шаване на скоростта (стойност по подразбиране, ако 
няма данни)  
VuOverSpeedingEventRecordArray  Всички събития „превишаване на скоростта“, 
записани във VU. 
Ако тази част е празна, се изпраща заглавна част на 
масив с noOfRecords = 0  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 347  
Елемент от данни  Коментар  
VuTimeAdjustmentRecordArray  Всички събития „сверяване на часовника“, записани 
във VU (извън рамките на пълно калибриране). 
Ако тази част е празна, се изпраща заглавна част на 
масив с noOfRecords = 0  
SignatureRecordArray  ЕСС подпис на всички предходни данни  
Структура на данните от поколение 2, версия 2 (TREP 33 Hex)  
Елемент от данни  Коментар  
VuFaultRecordArray  Всички записани или текущи неизправности във 
VU. 
Ако тази част е празна, се изпраща заглавна част на 
масив с noOfRecords = 0  
VuEventRecordArray  Всички записани или текущи събития във VU (освен 
превишаването на скоростта). 
Ако тази част е празна, се изпраща заглавна част на 
масив с noOfRecords = 0  
VuOverSpeedingControlDataRecordArray  Данни във връзка с последната проверка за преви­ 
шаване на скоростта (стойност по подразбиране, ако 
няма данни)  
VuOverSpeedingEventRecordArray  Всички събития „превишаване на скоростта“, 
записани във VU. 
Ако тази част е празна, се изпраща заглавна част на 
масив с noOfRecords = 0  
VuTimeAdjustmentRecordArray  Всички събития „сверяване на часовника“, записани 
във VU (извън рамките на пълно калибриране). 
Ако тази част е празна, се изпраща заглавна част на 
масив с noOfRecords = 0  
SignatureRecordArray  ЕСС подпис на всички предходни данни  
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 D e t a i l e d S p e e d 
( П о л о ж и т е л е н о т г о в о р н а и с к а н е з а т р а  н с ф е р н а 
п о д р о б н и д а н н и о т н о с н о с к о р о с т т а н а п  р е в о з н о т о 
с р е д с т в о )  
DDP_032 Полето за данни на съобщението „Positive Response 
Transfer Data Detailed Speed“ трябва да дава данните 
по-долу по следния ред по SID 76 Hex, TRЕP 04 или 
24 Hex и съответните критерии за разделяне и 
преброяване на подсъобщенията:  
Структура на данните от поколение 1 (TREP 04 Hex)  
Елемент от данни  Коментар  
VuDetailedSpeedData  Всички подробни данни за скоростта във VU (един 
блок с данни за скоростта на минута, през която 
превозното средство е в движение) 
60 стойности на скоростта на минута (една на 
секунда)  
Signature  RSA подпис на всички данни, започвайки от noOfS­
peedBlocks до последния байт на последния блок 
данни за скоростта  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 348  
Структура на данните от поколение 2 (TREP 24 Hex)  
Елемент от данни  Коментар  
VuDetailedSpeedBlockRecordArray  Всички подробни данни за скоростта във VU (един 
блок с данни за скоростта на минута, през която 
превозното средство е в движение) 
60 стойности на скоростта на минута (една на 
секунда)  
SignatureRecordArray  ЕСС подпис на всички предходни данни  
2.2.6.6 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 Полето за данни на съобщението „Positive Response 
Transfer Data Technical Data“ трябва да дава данните 
по-долу по следния ред по SID 76 Hex, TRЕP 05, 25 
или 35 Hex и съответните критерии за разделяне и 
преброяване на подсъобщенията:  
Структура на данните от поколение 1 (TREP 05 Hex)  
Елемент от данни  Коментар  
VuIdentification  
SensorPaired  
VuCalibrationData  Всички записи за калибриране, съхранени във VU  
Signature  RSA подпис на всички данни, започвайки от vuMa­
nufacturerName до последния байт на последния 
VuCalibrationRecord  
Структура на данните от поколение 2, версия 1 (TREP 25 Hex)  
Елемент от данни  Коментар  
VuIdentificationRecordArray  
VuSensorPairedRecordArray  Всички сдвоявания с датчика за движение (MS), 
съхранени във VU  
VuSensorExternalGNSSCoupledRecor­
dArray  Всички свързвания с външното устройство за GNSS, 
съхранени във VU  
VuCalibrationRecordArray  Всички записи за калибриране, съхранени във VU  
VuCardRecordArray  Всички данни за поставяне на карти, съхранени във 
VU 
VuITSConsentRecordArray  
VuPowerSupplyInterruptionRecordArray  
SignatureRecordArray  ЕСС подпис на всички предходни данни  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 349  
Структура на данните от поколение 2, версия 2 (TREP 35 Hex)  
Елемент от данни  Коментар  
VuIdentificationRecordArray  
VuSensorPairedRecordArray  Всички сдвоявания с датчика за движение (MS), 
съхранени във VU  
VuSensorExternalGNSSCoupledRecor­
dArray  Всички свързвания с външното устройство за GNSS, 
съхранени във VU  
VuCalibrationRecordArray  Всички записи за калибриране, съхранени във VU  
VuCardRecordArray  Всички данни за поставяне на карти, съхранени във 
VU 
VuITSConsentRecordArray  
VuPowerSupplyInterruptionRecordArray  
SignatureRecordArray  ЕСС подпис на всички предходни данни  
▼B 
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 (изваждане на 
картата или следващо инициали­ 
зиране).  
Подписан  файл  за данни : файл от ICC. Този файл се 
прехвърля като обикновен текст 
към IFD. Върху ICC файлът се 
хешира и подписва, а подписът 
се прехвърля към IFD.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 350  
3.3. Изтегляне  на данни  от карта  
▼M3 
DDP_035 Изтеглянето на данни от тахографска карта съдържа 
следните операции:  
— изтегляне на общата информация на картата в EF 
ICC и IC. Тази информация е незадължителна и не 
е защитена с електронен подпис;  
— за тахографски карти от първо и второ поколение  
— изтегляне на EF в рамките на Tachograph DF:  
— изтегляне на EF Card_Certificate и CA_Certi­
ficate. Тази информация не е защитена с елек­ 
тронен подпис.  
Тези файлове трябва задължително да се 
изтеглят за всяка сесия за изтегляне на данни;  
— изтегляне на останалите елементарни файлове 
с приложни данни (в рамките на DF 
Tachograph) освен EF Card_Download. Тази 
информация е защитена с цифров подпис 
съгласно общите механизми за сигурност от 
допълнение 11, част А;  
— задължително е да се изтеглят поне EF Appli­
cation_Identification и Identification за всяка 
сесия за изтегляне на данни.  
— когато се извършва изтегляне на данни от 
карта на водач, е необходимо също да се 
изтеглят следните EF:  
Events_Data,  
Faults_Data,  
Driver_Activity_Data,  
Vehicles_Used,  
Places,  
Control_Activity_Data,  
Specific_Conditions.  
— само за тахографски карти от второ поколение:  
— с изключение на случаите, когато изтеглянето на 
данни от карта на водач, вкарана в бордовото 
устройство, се извършва при проверка на 
водача от контролен орган на държава извън 
ЕС с контролна карта от първо поколение, 
изтегляне на EF в рамките на Tachograph_G2 DF:  
— изтегляне на EF CardSignCertificate, CA_Certi­
ficate и Link_Certificate. Тази информация не е 
защитена с електронен подпис.  
— Тези файлове трябва задължително да се 
изтеглят за всяка сесия за изтегляне на данни;  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 351  
— изтегляне на останалите елементарни файлове 
с приложни данни (в рамките на DF 
Tachograph_G2) освен EF Card_Download. 
Тази информация е защитена с цифров 
подпис съгласно общите механизми за 
сигурност от допълнение 11, част Б.  
— задължително е да се изтеглят поне EF Appli­
cation_Identification, Application_Identifi­
cation_V2 (ако съществува) и Identification за 
всяка сесия за изтегляне на данни.  
— когато се извършва изтегляне на данни от 
карта на водач, е необходимо също да се 
изтеглят следните EF:  
Events_Data,  
Faults_Data,  
Driver_Activity_Data,  
Vehicles_Used,  
Places,  
Control_Activity_Data,  
Specific_Conditions,  
VehicleUnits_Used,  
GNSS_Places,  
Places_Authentication, if present,  
GNSS_Places_Authentication, if present,  
Border_Crossings, if present,  
Load_Unload_Operations, if present,  
Load_Type_Entries, if present.  
— когато се извършва изтегляне на данни от 
карта на водач, трябва да се актуализира 
датата на LastCardDownload в EF 
Card_Download, както и в Tachograph и ако 
е уместно — в DF Tachograph_G2.  
— когато се извършва изтегляне на данни от 
карта за монтаж и настройки, трябва да се 
инициализира броячът за калибриране в EF 
Card_Download, както и в DF Tachograph и 
ако е уместно — в DF Tachograph_G2.  
— когато се изтеглят данни от карта за монтаж и 
настройки, не трябва да се изтеглят данните 
от EF Sensor_Installation_Data в Tachograph и 
ако е уместно — в DF Tachograph_G2.  
▼B 
3.3.1  Последователност  при инициализиране  
DDP_036 IDE трябва да започне последователността, както 
следва:  
Карта  Посока  IDE/IFD  Значение/Забележки  
⇦ Инициализация на хардуера  
ATR ⇨ 
Възможно е да се използва РРS, за да премине към по- 
висока скорост за предаване на данни, при условие че 
ICC я поддържа.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 352  
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  
Забележка  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 и временно се 
съхранява хеш-стой­ 
ността  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 353  
Карта  Посока  IDE/IFD  Значение/Забележки  
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.  
3.3.4  Последователност  за инициализиране  на брояча  за калибриране  
DDP_039 Последователността на инициализиране на брояча
  
в EF
  
в карта за монтаж и настройки е 
следната:  
Карта  Посока  IDE/IFD  Значение/Забележки  
⇦ Select File  EF Card_Download  Изберете идентификаторите 
на файлове  
OK ⇨ 
⇦ Update Binary  
NoOfCalibrationsSince­
Download = „00 00“  
Инициализира броя на 
изтеглянията на данни 
от картата  
OK ⇨ 
Забележка : изборът и актуализацията на файл могат да 
се извършат и в една стъпка, като се използва командата 
Update Binary с кратък EF идентификатор.  ▼M1
 02016R0799 — BG — 21.08.2023 — 003.001 — 354  
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 байта  
FID (2 байта) || „02“  Таг за EF (FID) в DF
  3 байта  
FID (2 байта) || „03“  Таг за подпис на EF (FID) 
в DF
  3 байта  
xx xx  Дължина на полето за 
стойността  2 байта  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 355  
Пример за данни в изтеглен файл върху ЕSM:  
Таг Дължина  Стойност
  
— Данни от EF ICC
  
— Данни от EF Card_Certificate  
— ...
  
Данни от EF
  ( в  
DF
 )
  
Подпис на EF
  ( в  
DF
 )
  
Данни от EF
  в  D F
  
Подпис на 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 — 21.08.2023 — 003.001 — 356  
Допълнение  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 — 21.08.2023 — 003.001 — 357  
7. КОНТРОЛ НА ИЗПИТВАТЕЛНИТЕ ИМПУЛСИ — 
ФУНКЦИОНАЛЕН БЛОК ЗА КОНТРОЛ НА ВХОДНИТЕ/ 
ИЗХОДНИТЕ ДАННИ  
7.1. Услуга InputOutputControlByIdentifier  
7.1.1 Описание на съобщенията  
7.1.2 Формат на съобщенията  
7.1.3 Определяне на параметрите  
▼M3 
8. УСЛУГА ROUTINECONTROL (СВЕРЯВАНЕ НА ЧАСОВНИКА)  
8.1. Описание на съобщенията  
8.2. Формат на съобщението  
9. ФОРМАТИ НА DATARECORDS  
9.1. Диапазони от предавани параметри  
9.2. Формати на dataRecords  
▼B 
1. ВЪВЕДЕНИЕ  
В това допълнение са разгледани начините на обмен на данни 
между бордово устройство и изпитвателно оборудване 
посредством линията К, която представлява част от интерфейса 
за калибриране, описан в допълнение 6. В настоящото допълнение 
е описан също контролът на линията за входни/изходни сигнали на  
съединителя за калибриране.  
Установяването на връзките по линия К е дадено в раздел 4 
„Communication 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 — 21.08.2023 — 003.001 — 358  
2. ПОНЯТИЯ, ОПРЕДЕЛЕНИЯ И СПРАВОЧНИ МАТЕРИАЛИ  
Протоколите, съобщенията и кодовете за грешка се основават 
главно на проект на стандарт ISO 14229-1 (Пътни превозни 
средства. Системи за диагностика. Част 1: услуги за диагностика , 
версия 6 от 22 февруари 2001 г.).  
Кодирането на байтове и други шестнадесетични стойности се 
използват за идентификаторите на услуги, служебните заявки и 
отговори и стандартните параметри.  
„Изпитвателно оборудване“ е оборудването, което се използва за 
въвеждане на данни за програмиране/калибриране в бордовото 
устройство.  
Понятията „клиент“ и „сървър“ се отнасят съответно за изпитва­ 
телното оборудване и бордовото устройство.  
Понятието UCE е „електронен блок за управление“ и се отнася за 
бордовото устройство.  
Справочни  материали : 
▼M1 
ISO 14230-2: Пътни превозни средства. Системи за диагностика. 
Протокол „Keyword 2000“. Част 2: канален слой.  
Първо издание: 1999 г.  
▼B 
3. ПРЕГЛЕД НА УСЛУГИТЕ  
3.1. Налични  услуги  
В следващата таблица са представени услугите, които са налични в 
тахографа и са определени в настоящия документ.  
CPR_004 В тази таблица е посочено кои са услугите на разпо­ 
ложение по време на активна диагностична сесия.  
— В  първата  колона  са дадени наличните услуги.  
— Във  втората  колона  е посочен номерът на раздела в 
настоящото допълнение, където са представени 
допълнителни данни за услугата.  
— В  третата  колона  са указани стойностите за иден­ 
тификаторите на услугите за съобщенията за заявка.  
— В  четвъртата  колона  са дадени услугите на  
„StandardDiagnosticSession“ (SD) , които трябва да 
се изпълняват във всяко бордово устройство.  
— В  петата  колона  са уточнени услугите на  
„ECUAdjustmentSession“ (ECUAS) , които трябва 
да се изпълняват, за да се даде възможност за 
контрол на линията за входни/изходни сигнали от 
предния панел на съединителя за калибриране на 
бордовото устройство.  
— В  шестата  колона  са посочени услугите на  
„ECUProgrammingSession“ (ECUPS) , които трябва 
да се изпълняват, за да се даде възможност за 
програмиране на параметрите в бордовото 
устройство.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 359  
Таблица  1 
Обобщаваща  таблица  за стойностите  на идентификаторите  на услуги  
Диагностични сесии  
Наименование на диагностичната 
услуга  Раздел 
№ Стойности за 
съобщенията 
за заявка за 
SId SD ECUAS  ECUPS  
StartCommunication  4.1  8 1  ■  ■  ■  
StopCommunication  4.2  8 2  ■  
TesterPresent  4.3  3 E  ■  ■  ■  
StartDiagnosticSession  5.1  1 0  ■  ■  ■  
SecurityAccess  5.2  2 7  ■  ■  ■  
ReadDataByIdentifier  6.1  2 2  ■  ■  ■  
WriteDataByIdentifier  6.2  2 E  ■  
InputOutputControlByIdentifier  7.1  2 F  ■  
▼M3 
RoutineControl  8  3 1
  
▼B 
■ Този символ указва, че услугата е задължителна в тази диагност ична сесия. 
Няма символ, който да посочва, че съответната услуга не е разре шена в тази 
диагностична сесия.  
3.2. Кодове  за отговор  
Кодовете за отговор са определени за всяка услуга.  
4. СЪОБЩИТЕЛНИ УСЛУГИ  
Някои услуги са необходими за установяване и поддържане на 
връзката. Те не се появяват в приложния слой. В следващата 
таблица са посочени наличните услуги:  
Таблица  2 
Съобщителни  услуги  
Наименование на услугата  Описание  
StartCommunication  Клиентът заявява започване на съоб­ 
щителна сесия със сървъра(ите).  
StopCommunication  Клиентът заявява прекъсване на 
текущата съобщителна сесия.  
TesterPresent  Клиентът указва на сървъра, че е все 
още на линия.  
CPR_005 Услугата StartCommunication се използва за започване на  
връзка. Изпълнението на всяка услуга предполага уста­ 
новяване на връзка и избор на параметри на връзката, 
подходящи за желания режим.  
4.1. Услуга  StartCommunication  
CPR_006 При получаване на примитив за указване StartCommuni­
cation бордовото устройство проверява дали заявената 
съобщителна връзка може да се осъществи при 
дадените условия. Валидните условия за осъществяване 
на съобщителна връзка са описани в документ ISO 
14230-2.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 360  
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 — 21.08.2023 — 003.001 — 361  
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 2 0  
P2 Време между една заявка от 
изпитвателното оборудване и 
един или два отговора от 
бордовото устройство  25 250  
P3 Време между края на отго­ 
ворите на бордовото 
устройство и началото на 
нова заявка, изпратена от 
изпитвателното оборудване  55 5 000  
P4 Междубайтово време за 
заявка, изпратена от изпитва­ 
телното оборудване  5 2 0  
CPR_018 Форматът на съобщенията за бързата инициализация е 
подробно описан в следващите таблици. (ЗАБЕЛЕЖКА: 
Hex means hexadecimal)  
Таблица  5 
Съобщение  за заявка  за StartCommunication  
Байт #  Наименование на параметъра  Стойност hex.  Мнемоничен 
код 
#1 Байт за структура — 
физическо адресиране  81 FMT  
#2 Целеви байт за адреса  E E  TGT  
#3 Изходен байт за адреса  t t  SRC  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 362  
Байт #  Наименование на параметъра  Стойност hex.  Мнемоничен 
код 
#4 Идентификатор  на заявка  
за услугата  StartCommuni ­
cation  81 SCR  
#5 Контролна сума  00-FF  C S  
Таблица  6 
Съобщение  за положителен  отговор  за StartCommunication  
Байт #  Наименование на параметъра  Стойност hex.  Мнемоничен 
код 
#1 Байт за структура — 
физическо адресиране  80 FMT  
#2 Целеви байт за адреса  t t  TGT  
#3 Изходен байт за адреса  E E  SRC  
#4 Допълнителен байт за 
дължина  03 LEN  
#5 Идентификатор  на поло­  
жителен  отговор  за 
услугата  StartCommunication  C1 SCRPR  
#6 Ключов байт 1  E A  KB1  
#7 Ключов байт 2  8 F  KB2  
#8 Контролна сума  00-FF  C S  
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 — 21.08.2023 — 003.001 — 363  
4.2.2  Формат  на съобщенията  
CPR_024 Форматите на съобщенията за примитивите на StopCom­
munication са подробно описани в следващите таблици.  
Таблица  7 
Съобщение  за заявка  за StopCommunication  
Байт #  Наименование на параметъра  Стойност hex.  Мнемоничен 
код 
#1 Байт за структура — 
физическо адресиране  80 FMT  
#2 Целеви байт за адреса  E E  TGT  
#3 Изходен байт за адреса  t t  SRC  
#4 Допълнителен байт за 
дължина  01 LEN  
#5 Идентификатор  на заявка  
за услугата  StopCommuni ­
cation  82 SPR  
#6 Контролна сума  00-FF  C S  
Таблица  8 
Съобщение  за положителен  отговор  за StopCommunication  
Байт #  Наименование на параметъра  Стойност hex.  Мнемоничен 
код 
#1 Байт за структура — 
физическо адресиране  80 FMT  
#2 Целеви байт за адреса  t t  TGT  
#3 Изходен байт за адреса  E E  SRC  
#4 Допълнителен байт за 
дължина  01 LEN  
#5 Идентификатор  на поло­  
жителен  отговор  за 
услугата  StopCommunication  C2 SPRPR  
#6 Контролна сума  00-FF  C S  
Таблица  9 
Съобщение  за отрицателен  отговор  за StopCommunication  
Байт #  Наименование на параметъра  Шестнай­ 
сетична 
стойност  Мнемоничен 
код 
#1 Байт за структура — 
физическо адресиране  80 FMT  
#2 Целеви байт за адреса  t t  TGT  
#3 Изходен байт за адреса  E E  SRC  
#4 Допълнителен байт за 
дължина  03 LEN  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 364  
Байт #  Наименование на параметъра  Шестнай­ 
сетична 
стойност  Мнемоничен 
код 
#5 Идентификатор  на отри­  
цателен  отговор  за 
услугата  7F NR  
#6 Идентификация на заявка за 
услугата StopCommunication  82 SPR  
#7 responseCode = generalReject  1 0  RC_GR  
#8 Контролна сума  00-FF  C S  
4.2.3  Определяне  на параметрите  
Тази услуга не налага определяне на параметри.  
4.3. Услуга  TesterPresent  
4.3.1  Описание  на съобщенията  
Услугата TesterPresent се използва от изпитвателното оборудване , 
за да укаже на сървъра, че все още е на разположение, с цел да се 
попречи на автоматичното връщане на сървъра към режим на 
нормална работа и да се избегне евентуалното прекъсване на 
връзката. Изпращана периодично, тази услуга поддържа активна 
диагностичната сесия/връзката, като нулира брояча Р3 при всяка 
заявка за тази услуга.  
4.3.2  Формат  на съобщенията  
CPR_079 Форматите на съобщенията за примитивите за Tester­
Present са подробно описани в следващите таблици.  
Таблица  10 
Съобщение  за заявка  за TesterPresent  
Байт #  Наименование на параметъра  Шестнай­ 
сетична 
стойност  Мнемоничен 
код 
#1 Байт за структура — 
физическо адресиране  80 FMT  
#2 Целеви байт за адреса  E E  TGT  
#3 Изходен байт за адреса  t t  SRC  
#4 Допълнителен байт за 
дължина  02 LEN  
#5 Идентификатор  на заявка  
за услугата  TesterPresent  3E TP  
#6 Подфункция = 
responseRequired- 
= [ да 0 1  RESPREQ_Y  
не ] 0 2  RESPREQ_NO  
#7 Контролна сума  00-FF  C S  
CPR_080 Ако за параметъра responseRequired е зададено„да“, 
сървърът ще отговори с последващо съобщение за поло­ 
жителен отговор. Ако е зададено „не“, сървърът не 
изпраща отговор.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 365  
Таблица  11 
Съобщение  за положителен  отговор  за TesterPresent  
Байт #  Наименование на параметъра  Шестнай­ 
сетична 
стойност.  Мнемоничен 
код 
#1 Байт за структура — 
физическо адресиране  80 FMT  
#2 Целеви байт за адреса  t t  TGT  
#3 Изходен байт за адреса  E E  SRC  
#4 Допълнителен байт за 
дължина  01 LEN  
#5 Идентификатор  на поло­  
жителен  отговор  за 
услугата  TesterPresent  7E TPPR  
#6 Контролна сума  00-FF  C S  
CPR_081 Услугата трябва да поддържа следните кодове за отри­ 
цателен отговор:  
Таблица  12 
Съобщение  за отрицателен  отговор  за TesterPresent  
Байт #  Наименование на параметъра  Шест­ 
найсети­ 
чна 
стойност  Мнемоничен 
код 
#1 Байт за структура — физическо 
адресиране  80 FMT  
#2 Целеви байт за адреса  t t  TGT  
#3 Изходен байт за адреса  E E  SRC  
#4 Допълнителен байт за дължина  0 3  LEN  
#5 Идентификатор  на отрицателен  
отговор  за услугата  7F NR  
#6 Идентификация на заявка за 
услугата TesterPresent  3E T P  
#7 respon­
seCode =  [SubFunctionNotSup­
ported-InvalidFormat  12 RC_SFNS_IF  
incorrectMessage­
Length ]  13 RC_IML  
#8 Контролна сума  00-FF  C S  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 366  
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 — 21.08.2023 — 003.001 — 367  
Таблица  14 
Съобщение  за заявка  за StartDiagnosticSession  
Байт #  Наименование на параметъра  Шестнай­ 
сетична 
стойност  Мнемоничен 
код 
#1 Байт за структура — 
физическо адресиране  80 FMT  
#2 Целеви байт за адреса  E E  TGT  
#3 Изходен байт за адреса  t t  SRC  
#4 Допълнителен байт за 
дължина  02 LEN  
#5 Идентификатор  на заявка  
за услугата  StartDiagnostic ­
Session  10 STDS  
#6 diagnosticSession = [една 
стойност от таблица 17]  xx DS_…  
#7 Контролна сума  00-FF  C S  
Таблица  15 
Съобщение  за положителен  отговор  за StartDiagnosticSession  
Байт #  Наименование на параметъра  Шестнай­ 
сетична 
стойност  Мнемоничен 
код 
#1 Байт за структура — 
физическо адресиране  80 FMT  
#2 Целеви байт за адреса  t t  TGT  
#3 Байт за изходен адрес  E E  SRC  
#4 Допълнителен байт за 
дължина  02 LEN  
#5 Идентификатор  на поло­  
жителен  отговор  за 
услугата  StartDiagnostic ­
Session  50 STDSPR  
#6 diagnosticSession = [ същата 
стойност като байт #6 
таблица 14 ]  xx DS_…  
#7 Контролна сума  00-FF  C S  
Таблица  16 
Съобщение  за отрицателен  отговор  за StartDiagnosticSession  
Байт #  Наименование на параметъра  Шест­ 
найсети­ 
чна 
стойност  Мнемоничен 
код 
#1 Байт за структура — физическо 
адресиране  80 FMT  
#2 Байт за целеви адрес  t t  TGT  
#3 Байт за изходен адрес  E E  SRC  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 368  
Байт #  Наименование на параметъра  Шест­ 
найсети­ 
чна 
стойност  Мнемоничен 
код 
#4 Допълнителен байт за дължина  0 3  LEN  
#5 Идентификатор  на отрицателен  
отговор  за услугата  7F NR  
#6 Идентификатор на заявка за 
услугата StartDiagnosticSession  10 STDS  
#7 Respon­
seCode =  [subFunctionNotSup­
ported (  α ) 12 RC_SFNS  
incorrectMessage­
Length (  β ) 13 RC_IML  
conditionsNot­
Correct (  γ ) 22 RC_CNC  
#8 Контролна сума  00-FF  C S  
( α ) Въведената стойност в байт #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 — 21.08.2023 — 003.001 — 369  
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 на бордовото устройство. За управление на 
времето, необходимо за извършване на процеса по удос­ 
товеряване на картата, бордовото устройство трябва да  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 370  
използва кода за отрицателен отговор requestCorrectly­
Received-ResponsePending, за да удължи времето за 
отговор. Максималното време за отговор не трябва 
обаче да надхвърля 5 минути. След като бъде 
изпълнена заявената услуга, бордовото устройство 
изпраща съобщение за положителен или отрицателен 
отговор с код за отговор, който е различен от кода по- 
горе. Кодът за отрицателен отговор 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 Байт за целевия адрес  E E  TGT  
#3 Байт за изходен адрес  t t  SRC  
#4 Допълнителен байт за 
дължина  02 LEN  
#5 Идентификатор  на заявка  
за услугата  SecurityAccess  27 SA  
#6 accessType — requestSeed  7 D  AT_RSD  
#7 Контролна сума  00-FF  C S  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 371  
Таблица  19 
SecurityAccess — съобщение  за положителен  отговор  за requestSeed  
Байт #  Наименование на параметъра  Шестнай­ 
сетична 
стойност  Мнемоничен 
код 
#1 Байт за структура — 
физическо адресиране  80 FMT  
#2 Байт за целевия адрес  t t  TGT  
#3 Байт за изходния адрес  E E  SRC  
#4 Допълнителен байт за 
дължина  04 LEN  
#5 Идентификатор  на поло­  
жителен  отговор  за 
услугата  SecurityAccess  67 SAPR  
#6 accessType — requestSeed  7 D  AT_RSD  
#7 Инициализация от високо 
ниво  00-FF  SEEDH  
#8 Инициализация от ниско 
ниво  00-FF  SEEDL  
#9 Контролна сума  00-FF  C S  
Таблица  20 
Съобщение  за отрицателен  отговор  за SecurityAccess  
Байт #  Наименование на параметъра  Шест­ 
найсети­ 
чна 
стойност  Мнемоничен 
код 
#1 Байт за структура — физическо 
адресиране  80 FMT  
#2 Байт за целевия адрес  t t  TGT  
#3 Байт за изходния адрес  E E  SRC  
#4 Допълнителен байт за дължина  0 3  LEN  
#5 Идентификатор  на отрицателен  
отговор  за услугата  7F NR  
#6 Идентификатор на заявка за 
услугата SecurityAccess  27 S A  
#7 respon­
seCode =  [conditionsNotCorrec­
tOrRequestSequen­
ceError  22 RC_CNC  
incorrectMessage­
Length]  13 RC_IML  
#8 Контролна сума  00-FF  C S  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 372  
5.2.3  Формат  на съобщенията  — SecurityAccess — sendKey  
CPR_041 Форматите на съобщенията за примитивите на 
„sendKey“ на SecurityAccess са подробно описани в 
следващите таблици.  
Таблица  21 
Заявка  за SecurityAccess — съобщение  за sendKey  
Байт #  Наименование на параметъра  Шестнай­ 
сетична 
стойност  Мнемоничен 
код 
#1 Байт за структура — 
физическо адресиране  80 FMT  
#2 Байт за целевия адрес  E E  TGT  
#3 Байт за изходния адрес  t t  SRC  
#4 Допълнителен байт за 
дължина  m+2 LEN  
#5 Идентификатор  на заявка  
за услугата  SecurityAccess  27 SA  
#6 accessType — sendKey  7 E  AT_SK  
#7 до 
#m+6  Key #1 (High)  x x  KEY  
… …  
Key #m (ниска, стойността 
на m трябва да бъде в 
интервала между 4 и 8)  xx 
#m+7  Контролна сума  00-FF  C S  
Таблица  22 
SecurityAccess — съобщение  за положителен  отговор  за sendKey  
Байт #  Наименование на параметъра  Шестнай­ 
сетична 
стойност  Мнемоничен 
код 
#1 Байт за структура — 
физическо адресиране  80 FMT  
#2 Байт за целевия адрес  t t  TGT  
#3 Байт за изходния адрес  E E  SRC  
#4 Допълнителен байт за 
дължина  02 LEN  
#5 Идентификатор  на поло­  
жителен  отговор  за 
услугата  SecurityAccess  67 SAPR  
#6 accessType — sendKey  7 E  AT_SK  
#7 Контролна сума  00-FF  C S  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 373  
Таблица  23 
Съобщение  за отрицателен  отговор  за SecurityAccess  
Байт #  Наименование на параметъра  Шест­ 
найсети­ 
чна 
стойност  Мнемоничен 
код 
#1 Байт за структура — физическо 
адресиране  80 FMT  
#2 Байт за целевия адрес  t t  TGT  
#3 Байт за изходния адрес  E E  SRC  
#4 Допълнителен байт за дължина  0 3  LEN  
#5 Идентификатор  на отрицателен  
отговор  за услугата  7F NR  
#6 Идентификатор на заявка за 
услугата SecurityAccess  27 S A  
#7 Respon­
seCode =  [generalReject  1 0  RC_GR  
subFunctionNotSup­
ported  12 RC_SFNS  
incorrectMessage­
Length  13 RC_IML  
conditionsNotCorrec­
tOrRequestSequen­
ceError  22 RC_CNC  
invalidKey  3 5  RC_IK  
exceededNumberO­
fAttempts  36 RC_ENA  
requestCorrectlyRe­
ceived-Response­
Pending]  78 RC_RCR_RP  
#8 Контролна сума  00-FF  C S  
6. УСЛУГИ ЗА ПРЕДАВАНЕ НА ДАННИ  
В следващата таблица са посочени наличните услуги:  
Таблица  24 
Услуги  за предаване  на данни  
Наименование на 
услугата  Описание  
ReadDataByIdentifier  Клиентът заявява предаването на акту­ 
алната стойност на запис с достъп от 
recordDataIdentifier.  
WriteDataByIdentifier  Клиентът заявява запаметяване на запис, 
до който recordDataIdentifier е имал 
достъп.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 374  
6.1. Услуга  ReadDataByIdentifier  
6.1.1  Описание  на съобщенията  
CPR_050 Услугата ReadDataByIdentifier се използва от клиента, з а 
да заяви извличането на стойности, които са записани на 
сървър. Данните се идентифицират от recordDataIden­
tifier. Производителят на бордовото устройство има 
задължение да следи за изпълнението на условията на 
сървъра по време на извършването на тази услуга.  
6.1.2  Формат  на съобщенията  
CPR_051 Форматите на съобщенията за примитивите на ReadDa­
taByIdentifier са подробно описани в следващите 
таблици.  
Таблица  25 
Съобщение  за заявка  за ReadDataByIdentifier  
Байт #  Наименование на параметъра  Шестнай­ 
сетична 
стойност  Мнемоничен 
код 
#1 Байт за структура — 
физическо адресиране  80 FMT  
#2 Байт за целевия адрес  E E  TGT  
#3 Байт за изходния адрес  t t  SRC  
#4 Допълнителен байт за 
дължина  03 LEN  
#5 Идентификатор  на заявка  
за услугата  ReadDataByI ­
dentifier  22 RDBI  
#6 до #7  recordDataIdentifier = 
[стойност от таблица 28]  xxxx  RDI_…  
#8 Контролна сума  00-FF  C S  
Таблица  26 
Съобщение  за положителен  отговор  за ReadDataByIdentifier  
Байт #  Наименование на параметъра  Шест­ 
найсети­ 
чна 
стойност  Мнемоничен 
код 
#1 Байт за структура — физическо 
адресиране  80 FMT  
#2 Байт за целевия адрес  t t  TGT  
#3 Байт за изходния адрес  E E  SRC  
#4 Допълнителен байт за дължина  m  +  3  LEN  
#5 Идентификатор  на положителен  
отговор  за услугата  ReadData ­
ByIdentifier  62 RDBIPR  
#6 и #7  recordDataIdentifier = [същата 
стойност като байтовете #6 и #7 
таблица 25]  xxxx  RDI_…  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 375  
Байт #  Наименование на параметъра  Шест­ 
найсети­ 
чна 
стойност  Мнемоничен 
код 
#8 до #m 
+ 7 dataRecord[] =  [data#1  x x  DREC_DAT­
A1 
: :  :  
data#m]  x x  DREC_DAT­
Am 
#m + 8  Контролна сума  00-FF  C S  
Таблица  27 
Съобщение  за отрицателен  отговор  за ReadDataByIdentifier  
Байт #  Наименование на параметъра  Шест­ 
найсети­ 
чна 
стойност  Мнемоничен 
код 
#1 Байт за структура — физическо 
адресиране  80 FMT  
#2 Байт за целевия адрес  t t  TGT  
#3 Байт за изходния адрес  E E  SRC  
#4 Допълнителен байт за дължина  0 3  LEN  
#5 Идентификатор  на отрицателен  
отговор  за услугата  7F NR  
#6 Идентификатор на заявка за 
услугата ReadDataByIdentifier  22 RDBI  
#7 Respon­
seCode=  [requestOu­
tOfRange  31 RC_ROOR  
incorrectMessage­
Length  13 RC_IML  
conditionsNot­
Correct]  22 RC_CNC  
#8 Контролна сума  00-FF  C S  
6.1.3  Определяне  на параметрите  
CPR_052 Параметърът  recordDataIdentifier (RDI_)  в съобщението 
за заявка за ReadDataByIdentifier идентифицира запис на 
данни.  
▼M3 
CPR_053 Определените с настоящия документ стойности на recor­
dDataIdentifier са дадени в таблицата по-долу.  
Таблицата за recordDataIdentifier се състои от пет колони 
и няколко реда.  
— първата  колона  (Hex.)  указва „Hex Value.“ (шест­ 
найсетична стойност), присвоявана на recordDataI­
dentifier, посочен в третата колона.  
— втората колона (Елемент от данни) показва елемента 
от данни от допълнение 1, на който се основава 
recordDataIdentifier (понякога е необходимо преоб­ 
разуване на кода),  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 376  
— третата  колона  (описание ) показва наименованието 
на съответния recordDataIdentifier.  
— четвъртата  колона  (Права  на достъп ) показва 
правата за достъп до този recordDataIdentifier.  
— петата  колона  (Мнемоничен  код) показва мнемо­ 
ничния код, свързан с този recordDataIdentifier.  
Таблица 28 
Определяне  на стойностите  на recordDataIdentifier  
Hex.  Елемент от данни  Наименование на recordDataIden­
tifier 
(вж. формàта в точка 8.2)  Права на 
достъп 
(Четене/ 
Вписване)  Мнемоничен код  
F90B  CurrentDateTime  TimeDate  Ч / З  RDI_TD  
F912  HighResOdometer  HighResolutionTotalVehicle­
Distance  Ч/З RDI_HRTVD  
F918  K-ConstantOfRecordingEquipment  Kfactor  Ч / З  RDI_KF  
F91C  L-TyreCircumference  LfactorTyreCircumference  Ч / З  RDI_LF  
F91D  W-VehicleCharacteristicConstant  WvehicleCharacteristicFactor  Ч / З  RDI_WVCF  
F921  TyreSize  TyreSize  Ч / З  RDI_TS  
F922  nextCalibrationDate  NextCalibrationDate  Ч / З  RDI_NCD  
F92C  SpeedAuthorised  SpeedAuthorised  Ч / З  RDI_SA  
F97D  vehicleRegistrationNation  RegisteringMemberState  Ч / З  RDI_RMS  
F97E  VehicleRegistrationNumber  VehicleRegistrationNumber  Ч / З  RDI_ VRN  
F190  VehicleIdentificationNumber  VIN  Ч / З  RDI_ VIN  
F9D0  SensorSerialNumber  MotionSensorSerialNumber  Ч  RDI_SSN  
F9D1  RemoteCommunicationModuleSerial­
Number  RemoteCommunicationFacility­
SerialNumber  Ч RDI_RCSN  
F9D2  SensorGNSSSerialNumber  ExternalGNSSFacilitySerial­
Number  Ч RDI_GSSN  
F9D3  SealDataVu  SmartTachographSealsSerial­
Number  Ч/З RDI_SDV  
F9D4  VuSerialNumber  VuSerialNumber  Ч  RDI_VSN  
F9D5  ByDefaultLoadType  ByDefaultLoadType  Ч / З  RDI_BDLT  
F9D6  TachographCardsGen1Suppression  Tachograph­
CardsGen1Suppression  Ч/З RDI_TCG1S  
F9D7  VehiclePosition  VehiclePosition  Ч  RDI_VP  
F9D8  LastCalibrationCountry  CalibrationCountry  Ч  RDI_CC  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 377  
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 са подробно описани в следващите 
таблици.  
Таблица  29 
Съобщение  за заявка  за WriteDataByIdentifier  
Байт #  Наименование на параметъра  Шест­ 
найсети­ 
чна 
стойност  Мнемоничен 
код 
#1 Байт за структура — физическо 
адресиране  80 FMT  
#2 Байт за целевия адрес  E E  TGT  
#3 Байт за изходния адрес  t t  SRC  
#4 Допълнителен байт за дължина  m  +  3  LEN  
#5 Идентификатор  на заявка  за 
услугата  WriteDataByIdentifier  2E WDBI  
#6 до #7  recordDataIdentifier = [стойност от 
таблица 28]  xxxx  RDI_…  
#8 до m 
+ 7 dataRecord[] =  [data#1  x x  DREC_DAT­
A1 
: :  :  
data#m]  x x  DREC_DAT­
Am 
#m + 8  Контролна сума  00-FF  C S  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 378  
Таблица  30 
Съобщение  за положителен  отговор  за WriteDataByIdentifier  
Байт #  Наименование на параметъра  Шестнай­ 
сетична 
стойност  Мнемоничен 
код 
#1 Байт за структура — 
физическо адресиране  80 FMT  
#2 Байт за целевия адрес  t t  TGT  
#3 Байт за изходния адрес  E E  SRC  
#4 Допълнителен байт за 
дължина  03 LEN  
#5 Идентификатор  на поло­  
жителен  отговор  за 
услугата  WriteDataByIden ­
tifier  6E WDBIPR  
#6 до #7  recordDataIdentifier = [същата 
стойност като байтовете #6 и 
#7 таблица 29]  xxxx  RDI_…  
#8 Контролна сума  00-FF  C S  
Таблица  31 
Съобщение  за отрицателен  отговор  за WriteDataByIdentifier  
Байт #  Наименование на параметъра  Шест­ 
найсети­ 
чна 
стойност  Мнемоничен 
код 
#1 Байт за структура — физическо 
адресиране  80 FMT  
#2 Байт за целевия адрес  t t  TGT  
#3 Байт за изходния адрес  E E  SRC  
#4 Допълнителен байт за дължина  0 3  LEN  
#5 Идентификатор  на отрицателен  
отговор  за услугата  7F NR  
#6 Идентификатор на заявка за 
услугата WriteDataByIdentifier  2E WDBI  
#7 Respon­
seCode=  [requestOu­
tOfRange  31 RC_ROOR  
incorrectMessage­
Length  13 RC_IML  
conditionsNot­
Correct]  22 RC_CNC  
#8 Контролна сума  00-FF  C S  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 379  
6.2.3  Определяне  на параметрите  
Параметърът  recordDataIdentifier (RDI_)  е определен таблица 28.  
Параметърът  dataRecord (DREC_)  се използва от съобщението за 
заявка на WriteDataByIdentifier, за да осигури стойностите на з аписа 
от данни, идентифициран от recordDataIdentifier, на сървъра 
(бордовото устройство). Форматите на данни са посочени в раздел  8. 
7. КОНТРОЛ НА ИЗПИТВАТЕЛНИТЕ ИМПУЛСИ — 
ФУНКЦИОНАЛЕН БЛОК ЗА КОНТРОЛ НА ВХОДНИТЕ/ 
ИЗХОДНИТЕ ДАННИ  
В следващата таблица са посочени наличните услуги:  
Таблица  32 
Функционален  блок  за контрол  на входните /изходните  данни  
Наименование на 
услугата  Описание  
InputOutputControl­
ByIdentifier  Клиентът заявява извършване на контрол 
на определени входни/изходни данни на 
сървъра  
7.1. Услуга  InputOutputControlByIdentifier  
7.1.1  Описание  на съобщенията  
Връзката, която се осъществява посредством фронтално разпо­ 
ложения съединител, позволява контрола или следенето на изпит­ 
вателните импулси с помощта на съответно изпитвателно 
оборудване  
CPR_058 Възможно е да се конфигурира тази линия за входни/ 
изходни сигнали за калибриране с команда по линията 
К, като се използва услугата InputOutputControlByIden­
tifier за избора на необходимата входна или изходна 
функция за линията. Съществуват следните състояния 
по линията:  
— дезактивирана,  
— speedSignalInput, когато линията за входния/изходния 
сигнал за калибриране се използва за въвеждане на 
сигнал за скорост (изпитвателен сигнал), който 
замества сигнала за скорост на датчика за движение, 
като тази функция не съществува в режим КОНТРОЛ,  
— realTimeSpeedSignalOutputSensor, когато линията за 
входни/изходни сигнали за калибриране се използва 
за извеждане на сигнала за скорост на датчика за 
движение,  
— RTCOutput, когато линията за входни/изходни 
сигнали за калибриране се използва за извеждане 
на сигнала на часовника, работещ по координи­ 
раното универсално време, като тази функция не 
съществува в режим КОНТРОЛ.  
CPR_059  За да бъде в състояние да конфигурира състоянието на 
линията, бордовото устройство трябва да е започнало 
сесия за настройка и да работи в режим КАЛИБРИРАНЕ 
или КОНТРОЛ. Когато бордовото устройство е в режим 
КАЛИБРИРАНЕ, могат да се изберат четирите състояние 
на линията (дезактивирана, speedSignalInput, realTimeSpe­
edSignalOutputSensor и RTCOutput). Когато бордовото 
устройство е в режим КОНТРОЛ, могат да се изберат 
само двете състояние на линията (дезактивирана и realTi­
meSpeedSignalOutputSensor). При приключване на сесия за 
настройка или излизане от режим КАЛИБРИРАНЕ или 
КОНТРОЛ, бордовото устройство трябва да осигури 
линията за входни/изходни сигнали за калибриране да се 
е върнала в дезактивирано състояние (по подразбиране).  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 380  
CPR_060 В случай на получаване на импулси за скорост по 
линията за входния сигнал за моментната скорост на 
бордовото устройство, при положение че линията за 
входни/изходни сигнали работи в режим на въвеждане 
на данни, тази линия трябва да премине в режим на 
извеждане на данни или да се върне в своето дезакти­ 
вирано състояние.  
CPR_061 Последователността на операциите е следната:  
— установяване на връзки чрез услугата StartCommuni­
cation,  
— влизане в сесия за настройка чрез услугата StartDi­
agnosticSession и преминаване в режим на работа 
КАЛИБРИРАНЕ ИЛИ КОНТРОЛ (редът на 
изпълнение на тези две операции е без значение),  
— промяна на състоянието на изхода чрез услугата 
InputOutputControlBydentifier.  
7.1.2  Формат  на съобщенията  
CPR_062 Форматите на съобщенията за примитивите на InputOut­
putControlByIdentifier са подробно описани в следващите 
таблици.  
Таблица  33 
Съобщение  за заявка  за InputOutputControlByIdentifier  
Байт #  Наименование на параметъра  Шестнай­ 
сетична 
стойност  Мнемоничен 
код 
#1 Байт за структура — 
физическо адресиране  80 FMT  
#2 Байт за целевия адрес  E E  TGT  
#3 Байт за изходния адрес  t t  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  C S  
Забележка : параметърът сontrolState се появява само в 
някои случаи (вж. 7.1.3).  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 381  
Таблица  34 
Съобщение  за положителен  отговор  за InputOutputControlByIdentifier  
Байт #  Наименование на параметъра  Шестнай­ 
сетична 
стойност  Мнемоничен 
код 
#1 Байт за структура — 
физическо адресиране  80 FMT  
#2 Байт за целевия адрес  t t  TGT  
#3 Байт за изходния адрес  E E  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  C S  
Таблица  35 
Съобщение  за отрицателен  отговор  за InputOutputControlByIdentifier  
Байт #  Наименование на параметъра  Шестнай­ 
сетична 
стойност  Мнемоничен 
код 
#1 Байт за структура — 
физическо адресиране  80 FMT  
#2 Байт за целевия адрес  t t  TGT  
#3 Байт за изходния адрес  E E  SRC  
#4 Допълнителен байт за 
дължина  03 LEN  
#5 Идентификатор  на отри­  
цателен  отговор  за услугата  7F NR  
#6 Идентификатор на заявка за 
inputOutputControlByIdentifier  2F IOCBI  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 382  
Байт #  Наименование на параметъра  Шестнай­ 
сетична 
стойност  Мнемоничен 
код 
#7 responseCode=[  
incorrectMessageLength  1 3  RC_IML  
conditionsNotCorrect  2 2  RC_CNC  
requestOutOfRange  3 1  RC_ROOR  
deviceControlLimitsExceeded]  7 A  RC_DCLE  
#8 Контролна сума  00-FF  C S  
7.1.3  Определяне  на параметрите  
CPR_064 Параметърът  inputOutputControlParameter (IOCP_)  е  
определен в следващата таблица.  
Таблица  36 
Определяне  на стойностите  на inputOutputControlParameter  
Hex Описание  Мнемоничен 
код 
00 ReturnControlToECU  
Тази стойност трябва да посочва на сървъра 
(бордовото устройство), че изпитвателното 
оборудване не управлява повече линията за 
входни/изходни сигнали за калибриране.  RCTECU  
01 ResetToDefault  
Тази стойност трябва да посочва на сървъра 
(бордовото устройство), че трябва да върне 
линията за входни/изходни сигнали за кали- 
бриране към състоянието ѝ по подразбиране.  RTD  
03 ShortTermAdjustment  
Тази стойност трябва да посочва на сървъра 
(бордовото устройство), че трябва да настрои 
линията за входни/изходни сигнали за кали- 
бриране към стойността, включена в пара- 
метъра controlState.  STA  
CPR_065 Параметърът  controlState  се появява само когато inputO­
utputControlParameter е конфигуриран като ShortTermAd­
justment и е определен в следващата таблица:  
Таблица  37 
Определяне  на стойностите  на controlState  
Режим  Шестнай­ 
сетична 
стойност  Описание  
Дезак­ 
тивиран  00 Дезактивирана линия за вход/изход (по 
подразбиране)  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 383  
Режим  Шестнай­ 
сетична 
стойност  Описание  
Активиран  0 1  Активирана линия за вход/изход за калиб­ 
риране като speedSignalInput  
Активиран  0 2  Активирана линия за вход/изход за калиб­ 
риране като realTimeSpeedSignalOutput­
Sensor  
Активиран  0 3  Активирана линия за вход/изход за калиб­ 
риране като RTCOutput  
▼M3 
8. УСЛУГА ROUTINECONTROL (СВЕРЯВАНЕ НА ЧАСОВНИКА)  
8.1. Описание  на съобщенията  
CPR_065a Услугата RoutineControl (TimeAdjustment) осигурява 
възможност за сверяване на часовника на бордовото 
устройство с времето, давано от приемника на 
сигнали от GNSS.  
За изпълнението на услугата RoutineControl (TimeAd­
justment) бордовото устройство трябва да бъде в 
режим CALIBRATION.  
Предварително  условие : осигурено е бордовото 
устройство да може да получава от приемника на 
сигнали от GNSS съобщения с удостоверена автен­ 
тичност за местоположението.  
Докато се извършва сверяването на часовника, 
бордовото устройство трябва да отговаря на заявка 
RoutineControl, подфункцияRoutineResults, с routineInfo 
= 0x78.  
Забележка: сверяването на часовника може да отнеме 
известно време. Диагностичният тестер трябва да 
поиска статуса на сверяването на часовника, като 
използва подфункцията requestRoutineResults.  
8.2. Формат  на съобщенията  
CPR_065b Форматите на съобщенията за услугата RoutineControl 
(TimeAdjustment) и нейните примитиви са описани 
подробно в следващите таблици.  
Таблица  37а 
RoutineControl, процедура  (TimeAdjustment), подфункция  startRoutine, съобщение  за заявка  
Байт #  Наименование на параметъра  Шестнай­ 
сетична 
стойност  Мнемоничен 
код 
#1 Байт за структура — физическо адресиране  8 0  FMT  
#2 Байт за целевия адрес  E E  TGT  
#3 Байт за изходния адрес  t t  SRC  
#4 Допълнителен байт за дължина  x x  LEN  
#5 RoutineControl Request Sid (SID на заявка  за RoutineControl)  31  RC  
#6 routineControlType = [startRoutine]  0 1  RCTP_STR  
#7 и #8  routineIdentifier = [TimeAdjustment]  0100  RI_TA  
#9 Контролна сума  00-FF  C S  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 384  
Таблица  37б 
RoutineControl, процедура  (TimeAdjustment), подфункция  startRoutine, съобщение  за положителен  отговор  
Байт #  Наименование на параметъра  Шестнай­ 
сетична 
стойност  Мнемоничен 
код 
#1 Байт за структура — физическо адресиране  8 0  FMT  
#2 Байт за целевия адрес  t t  TGT  
#3 Байт за изходния адрес  E E  SRC  
#4 Допълнителен байт за дължина  x x  LEN  
#5 RoutineControl Positive Response Sid (SID на положителен  
отговор  за RoutineControl)  71 RCPR  
#6 routineControlType = [startRoutine]  0 1  RCTP_STR  
#7 и #8  routineIdentifier= [TimeAdjustment]  0100  RI_TA  
#9 Контролна сума  00-FF  C S  
Таблица  37в 
RoutineControl, процедура  (TimeAdjustment), подфункция  requestRoutineResults, съобщение  за заявка  
Байт #  Наименование на параметъра  Шестнай­ 
сетична 
стойност  Мнемоничен 
код 
#1 Байт за структура — физическо адресиране  8 0  FMT  
#2 Байт за целевия адрес  E E  TGT  
#3 Байт за изходния адрес  t t  SRC  
#4 Допълнителен байт за дължина  x x  LEN  
#5 RoutineControl Request Sid (SID на заявка  за RoutineControl)  31  RC  
#6 routineControlType = [requestRoutineResults]  0 3  RCTP_RRR  
#7 и #8  routineIdentifier= [TimeAdjustment]  0100  RI_TA  
#9 Контролна сума  00-FF  C S  
Таблица  37г 
RoutineControl, процедура  (TimeAdjustment), подфункция  requestRoutineResults, съобщение  за положителен  
отговор  
Байт #  Наименование на параметъра  Шестнай­ 
сетична 
стойност  Мнемоничен 
код 
#1 Байт за структура — физическо адресиране  8 0  FMT  
#2 Байт за целевия адрес  t t  TGT  
#3 Байт за изходния адрес  E E  SRC  
#4 Допълнителен байт за дължина  x x  LEN  
#5 RoutineControl Positive Response Sid (SID на положителен  
отговор  за RoutineControl)  71 RCPR  
#6 routineControlType = [requestRoutineResults]  0 3  RCTP_RRR  
#7 и #8  routineIdentifier= [TimeAdjustment]  0100  RI_TA  
#9 routineInfo (вж. таблица 37е)  X X  RINF_TA  
#10 routineStatusRecord[] = routineStatus#1 (вж. таблица 37ж)  X X  RS_TA  
#11 Контролна сума  00-FF  C S  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 385  
Таблица  37д 
RoutineControltrol, процедура  (TimeAdjustment), съобщение  за отрицателен  отговор  
Байт #  Наименование на параметъра  Шестнай­ 
сетична 
стойност  Мнемоничен 
код 
#1 Байт за структура — физическо адресиране  8 0  FMT  
#2 Байт за целевия адрес  t t  TGT  
#3 Байт за изходния адрес  E E  SRC  
#4 Допълнителен байт за дължина  0 3  LEN  
#5 negativeResponse Service Id ( Идентификатор  на услугата  за 
отрицателен  отговор ) 7F NR  
#6 Идентификатор на заявка за inputOutputControlByIdentifier  3 1  RC  
#7 responseCode=[ 
sub-functionNotSupported 
incorrectMessageLengthOrInvalidFormat 
conditionsNotCorrect 
requestOutOfRange 
] 12 
13 
22 
31 SFNS 
IMLOIF 
CNC 
ROOR  
#8 Контролна сума  00-FF  C S  
Таблица  37е 
RoutineControl, процедура  (TimeAdjustment), routineInfo  
routineInfo  Шестнай­ 
сетична 
стойност  Описание  
NormalExitWithResultAvailable  6 1  Процедурата е изпълнена изцяло; налични са допъл­ 
нителни резултати от процедурата.  
RoutineExecutionOngoing  7 8  Заявената процедура все още се изпълнява.  
Таблица  37ж 
RoutineControl, процедура  (TimeAdjustment), routineStatus  
Шестнайсетична 
стойност  Резултат от изпит­ 
ването  Описание  
01 положителен  Сверяването на часовника приключи успешно.  
02..0F  RFU  
10 отрицателен  Няма приемане на сигнал от GNSS.  
11..7F  RFU  
80..FF  Зависи от производителя  
9. ФОРМАТИ НА DATARECORDS  
В настоящия раздел са изложени подробно:  
— общите правила, които трябва да се прилагат за диапазоните от  
параметри, предавани от бордовото устройство към изпитва­ 
телното оборудване,  
— форматите, които трябва да се използват за прехвърлените 
данни чрез услугите за предаване на данни, изложени в 
раздел 6.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 386  
CPR_067 Всички идентифицирани параметри трябва да се 
поддържат от бордовото устройство.  
CPR_068 Данните, предавани от бордовото устройство към 
изпитвателното оборудване в отговор на съобщение за 
заявка, трябва да са измерими (тоест актуалната 
стойност на заявения параметър е такава, каквато е 
измерена или наблюдавана от бордовото устройство).  
9.1. Диапазони  от предавани  параметри  
CPR_069 Таблица 38 определя използваните диапазони за 
определяне валидността на даден предаван параметър.  
CPR_070 Стойностите от диапазона „индикатор за грешка“ 
позволяват на бордовото устройство да посочи 
веднага, че към съответния момент не са налице 
валидни данни за параметъра поради някакъв вид 
грешка в тахографа.  
CPR_071 Стойностите от диапазона „не е наличен“ позволяват на 
бордовото устройство да изпрати съобщение, 
съдържащо параметър, който не е наличен или не се 
поддържа в този модул. Стойностите от диапазона 
„Незаявен“ позволяват на устройството да предаде 
командно съобщение и да идентифицира параметрите, 
за които не се очаква отговор от приемащото 
устройство.  
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  Няма  
Индикатор за грешка  F E  FE00 до FEFF  FE000000 до FEFFFFFF  0  
Не е наличен или не е заявен  F F  FF00 до FFFF  FF000000 до FFFFFFFF  F F  
CPR_073 За параметрите, кодирани в ASCII, символът ASCII „*“ 
се резервира като разграничител.  
9.2. Формати  на dataRecords  
В таблица 39 до таблица 42 са изложени подробно форматите, 
които трябва да се използват чрез услугите ReadDataByIdentifier  
и WriteDataByIdentifier.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 387  
CPR_074 Tаблица 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  1 5  ASCII  ASCII  
NextCalibrationDate  3  Вж. подробна информация в таблица 41  
SpeedAuthorised  2  усилване 1/256 km/h/bit, 
отместване 0  0 до 250,996 km/h  
RegisteringMemberState  3  ASCII  ASCII  
VehicleRegistrationNumber  1 4  Вж. подробна информация в таблица 42  
VIN 1 7  ASCII  ASCII  
SealDataVu  5 5  Вж. подробна информация в таблица 43  
ByDefaultLoadType  1  Вж. подробна информация в таблица 44  
VuSerialNumber  8  Вж. подробна информация в таблица 45  
SensorSerialNumber  8  Вж. подробна информация в таблица 45  
SensorGNSSSerialNumber  8  Вж. подробна информация в таблица 45  
RemoteCommunicationModuleSeri­
alNumber  8 Вж. подробна информация в таблица 45  
TachographCardsGen1Suppression  2  Вж. подробна информация в таблица 46  
VehiclePosition  1 4  Вж. подробна информация в таблица 47  
CalibrationCountry  3  ASCII  NationAlpha, както е 
определено в допълнение 1  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 388  
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 min  
3 Часове  усилване 1 h/bit, отместване 0 часа  0 до 23 h  
4 Месец  усилване 1 месец/бит, отместване 0 месеца  1 до 12 месеца  
5 Ден  усилване 0,25 ден/бит, отместване 0 дена 
(виж по-долу забележката под Таблица 41)  0,25 до 31,75 дена  
6 Година  усилване 1 година/bit, отместване +1985 
година 
(вж. забележката под таблица 41)  1985 до 2235 година  
7 Поправка на минути 
спрямо местното време  усилване 1 min/bit, отместване -125 min  –59 до +59 min  
8 Поправка на часове 
спрямо местното време  усилване 1 h/bit, отместване -125 часа  –23 до +23 ч  
CPR_076 Таблица 41 показва подробно форматите на различните 
байтове на параметъра NextCalibrationDate:  
Таблица 41 
Подробен  формат  на NextCalibrationDate ( стойност  на recordDataIdentifier # F922)  
Байт  Определяне на параметрите  Разделителна способност  Оперативен диапазон  
1 Месец  усилване 1 месец/бит, отместване 0 месеца  1 до 12 месеца  
2 Ден  усилване 0,25 ден/бит, отместване 0 дена 
(вж. бележката по-долу)  0,25 до 31,75 дена  
3 Година  усилване 1 година/bit, отместване +1985 
година 
(вж. забележката по-долу)  1985 до 2235 година  
ЗАБЕЛЕЖКА относно използването на параметъра 
„Ден“:  
1) Стойност 0 за датата е нулева. Стойностите 1, 2, 3 
и 4 се използват, за да идентифицират първия ден от 
месеца; стойностите 5, 6, 7 и 8 указват втория ден на 
месеца; и т.н.  
2) Този параметър не влияе, нито променя параметъра 
за часовете по-горе.  
ЗАБЕЛЕЖКА относно използването на байта на пара­ 
метъра „Година“:  
Стойност 0 за годината отговаря на 1985 година; 
стойност 1 отговаря на 1986 година; и т.н.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 389  
CPR_078 Таблица 42 показва подробно структурата на 
различните байтове на параметъра „Регистрационен 
номер на превозното средство“.  
Таблица  42 
Подробен  формат  на VehicleRegistrationNumber ( стойност  на recordDataIdentifier # F97 Е) 
Байт  Определяне на параметрите  Разделителна способност  Оперативен диапазон  
1 Кодова страница (както е определена в 
допълнение 1)  не се прилага  VehicleRegistrationNumber  
2 – 14  Регистрационен номер на превозното 
средство (както е определен в допълнение 1)  не се прилага  VehicleRegistrationNumber  
CPR_090 Таблица 43 показва подробно форматите на различните 
байтове на параметъра SealDataVu:  
Таблица  43 
Подробен  формат  на SealDataVu ( стойност  на recordDataIdentifier # F9D3)  
Байт  Определяне на параметрите  Разделителна способност  Оперативен диапазон  
1 – 11  sealRecord1. Формат SealRecord, както е 
определен в допълнение 1.  не се прилага  SealRecord  
12 - 22  sealRecord2. Формат SealRecord, както е 
определен в допълнение 1.  не се прилага  SealRecord  
23 – 33  sealRecord3. Формат SealRecord, както е 
определен в допълнение 1.  не се прилага  SealRecord  
34 – 44  sealRecord4. Формат SealRecord, както е 
определен в допълнение 1.  не се прилага  SealRecord  
45 – 55  sealRecord5. Формат SealRecord, както е 
определен в допълнение 1.  не се прилага  SealRecord  
ЗАБЕЛЕЖКА: Ако има по-малко от 5 налични пломби, 
стойността на EquipmentType във всички неизползвани 
sealRecords се фиксира на 15, т.е. неизползвани.  
CPR_091 Таблица 44 показва подробно форматите на различните 
байтове на параметъра ByDefaultLoadType:  
Таблица  44 
Подробна  структура  на ByDefaultLoadType ( стойност  на recordDataIdentifier # F9D5)  
Байт  Определяне на параметрите  Разделителна способност  Оперативен диапазон  
1 LoadType 
„00“H: Неопределен тип на товара 
„01“H: Стоки 
„02“H: Пътници  не се прилага  '00'H до '02'H  
CPR_092 Таблица 45 показва подробно структурата на 
различните байтове на параметрите VuSerialNumber, 
SensorSerialNumber, SensorGNSSSerialNumber и Remote­
CommunicationModuleSerialNumber.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 390  
Таблица  45 
Подробен  формат  на VuSerialNumber, sensorSerialNumber, SensorGNSSSerialNumber и 
RemoteCommunicationModuleSerialNumber ( стойности  на recordDataIdentifier # F9D4, F9D0, F9D2, F9D1)  
Байт  Определяне на параметрите  Разделителна способност  Оперативен диапазон  
1 VuSerialNumber, SensorSerialNumber, 
SensorGNSSSerialNumber и RemoteCom­
municationModuleSerialNumber: 
Формат ExtendedSerialNumber, както е 
определен в допълнение 1.  не се прилага  ExtendedSerialNumber  
CPR_093  Таблица 46 показва подробно структурата на различните 
байтове на параметъра TachographCardsGen1Suppression.  
Таблица  46 
Подробна  структура  на TachographCardsGen1Suppression ( стойност  на recordDataIdentifier # F9D6)  
Байт  Определяне на параметрите  Разделителна способност  Оперативен диапазон  
1-2 TachographCardsGen1Suppression. Формат 
TachographCardsGen1Suppression, както е 
определен в допълнение 1.  не се прилага  '0000'H, 'A5E3'H  
CPR_094 Таблица 47 показва подробно структурата на 
различните байтове на параметъра VehiclePosition.  
Таблица  47 
Подробна  структура  на VehiclePosition ( стойност  на recordDataIdentifier # F9D7)  
Байт  Определяне на параметрите  Разделителна способност  Оперативен диапазон  
1 - 4  Времевият печат за местоположението на 
превозното средство е определен.  Не се прилага  TimeReal  
5 точност на GNSS  Не се прилага  GNSSAccuracy  
6 - 11  Местоположение на превозното средство  Не се прилага  GeoCoordinates  
12 Статус на удостоверяването на автентич­ 
ността  Не се прилага  PositionAuthenticationStatus  
13 Настояща държава  Не се прилага  NationNumeric  
14 Настоящ регион  Не се прилага  RegionNumeric  
Забележка : след актуализиране на местоположението 
на превозното средство актуализацията на настоящата 
държава и регион може да се забави.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 391  
Допълнение  9 
МИНИМАЛНО  ИЗИСКВАНИ  ИЗПИТВАНИЯ  ЗА ОДОБРЕНИЕ  НА 
ТИПА  
СЪДЪРЖАНИЕ  
1. ВЪВЕДЕНИЕ  
2. ФУНКЦИОНАЛНИ ИЗПИТВАНИЯ НА БОРДОВОТО УСТРОЙСТВО  
3. ФУНКЦИОНАЛНИ ИЗПИТВАНИЯ НА ДАТЧИКА ЗА ДВИЖЕНИЕ  
4. ФУНКЦИОНАЛНИ ИЗПИТВАНИЯ НА ТАХОГРАФСКИТЕ КАРТИ  
5. ИЗПИТВАНИЯ НА ВЪНШНОТО УСТРОЙСТВО ЗА GNSS  
▼M1 
6. ИЗПИТВАНИЯ НА ВЪНШНОТО УСТРОЙСТВО ЗА ВРЪЗКА ОТ 
РАЗСТОЯНИЕ  
▼B 
7. ФУНКЦИОНАЛНИ ИЗПИТВАНИЯ ЗА РАЗПЕЧАТВАНЕ ВЪРХУ 
ХАРТИЕН НОСИТЕЛ  
8. ИЗПИТВАНИЯ ЗА ОПЕРАТИВНА СЪВМЕСТИМОСТ  
▼M3 
9. ИЗПИТВАНИЯ OSNMA  
▼B 
1. ВЪВЕДЕНИЕ  
1.1. Одобряване  на типа  
ЕО одобряването на типа на уреди за регистриране на данните за 
движението (или на техен компонент), или съответно на тахографс ка 
карта, се основава на:  
▼M1 
— сертифициране  за сигурност , въз основа на спецификациите на 
Общите критерии, при цел за състояние на сигурност на 
системата, което да е в пълно съответствие с допълнение 10 
към настоящото приложение,  
▼B 
— сертифициране  за функционалност , извършвано от компетентния 
орган на съответната държава членка, удостоверяващо че изпит­ 
ваното устройство отговаря на изискванията в настоящото 
приложение по отношение на изпълняваните функции, на 
точността на измерванията и на характеристиките на околната сре да, 
— сертифициране  за оперативна  съвместимост , извършвано от 
компетентния орган, удостоверяващо че уредът за регистриране 
на данните за движението (или тахографската карта) е изцяло 
оперативно съвместим съответно с необходимите модели тахог­ 
рафска карта (или уред за регистриране на данните за 
движението) (виж глава 8 от настоящото приложение).  
В настоящото допълнение е уточнено кои изпитвания трябва да бъд ат 
проведени като минимум от компетентния орган на дадена държава 
членка в рамките на функционалните изпитвания, както и кои 
изпитвания трябва да бъдат проведени като минимум от компет­ 
ентния орган в рамките на изпитванията за оперативна съвместимо ст. 
Не са включени допълнителни уточнения нито за процедурите за 
провеждането на тези изпитвания, нито за типа на изпитванията.  
Също така, в настоящото допълнение не са разгледани и аспектите  на 
сертифицирането за сигурност. Ако по време на процеса за оценяв ане 
и сертифициране на сигурността са извършени някои изпитвания, 
изисквани за одобряването на типа, не е необходимо те да бъдат 
провеждани повторно. В такъв случай могат да бъдат инспектирани  
само резултатите от тези изпитания за сигурност. С информативна  
цел в настоящото допълнение са отбелязани със звездичка („*“) 
изискванията, за които се очаква да бъдат проведени изпитвания 
при сертифицирането за сигурност (или съответно изискванията, 
тясно свързани с такива изпитвания).  
Номерираните изисквания са свързани със съдържанието на настоящ ото 
приложение, а останалите изисквания са свързани с другите допъл нения 
(например PIC_001 е свързано с Допълнение 3 „Пиктограми“).  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 392  
В настоящото допълнение са разгледани поотделно одобряването на  
типа на датчика за движение, на бордовото устройство и на външн ото 
устройство за GNSS, в качеството им на компоненти на уредите за  
регистриране на данните за движението. За всеки компонент се 
издава негов отделен сертификат за одобрение, в който се посочв ат 
другите съвместими компоненти. Функционалното изпитване на 
датчика за движение (или на външното устройство за GNSS) се 
прави заедно с бордовото устройство, и обратно.  
Не се изисква оперативна съвместимост между всеки модел датчик за 
движение (респективно всеки модел външно устройство за GNSS) и 
всеки модел бордово устройство. В подобни случаи одобрението на  
типа на датчик за движение (респективно на външно устройство за  
GNSS) може да бъде дадено само в комбинация с одобрение на типа  
на съответното бордово устройство и обратно.  
▼M3 
Органът на държавите членки, който отговаря за функционалните 
изпитвания на дадено бордово устройство или на дадено външно 
устройство за GNSS, трябва да се увери, че вграденият приемник 
на сигнали от GNSS е преминал успешно изпитванията OSNMA, 
посочени в настоящото допълнение. Тези изпитвания се считат за 
част от функционалните изпитвания на бордовото устройство или 
външното устройство за GNSS.  
▼B 
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 — 21.08.2023 — 003.001 — 393  
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 Хартия и картон. Определяне на дебелина, плътност и 
специфичен обем  
▼M3 
RGODP Технически доклад на JRC — Насоки за приемника за обра­ 
ботване на данни за OSNMA  
▼B 
Правило № 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. Функционални  изпитвания  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 394  
№ Изпитване  Описание  Съответни изисквания  
▼M3 
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 до 37  
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 Данни за тахографските карти  132*, 133*  ▼M1
 02016R0799 — BG — 21.08.2023 — 003.001 — 395  
№ Изпитване  Описание  Съответни изисквания  
3.28 Пресичане на граници  133а* до 133г*  
3.29 Товаро-разтоварна операция  133д* до 133и*  
3.30 Цифрова карта  133и* до 133у*  
3.31 Записване и запаметяване върху тахографските карти  136, 137, 138*, 139*, 141*, 
142, 143 
144, 145, 146*, 147*, 147а*, 
147б*, 148*, 149, 150, 150а  
3.32 Показване върху дисплея  90, 134, 
151 до 168, 
PIC_001, DIS_001  
3.33 Разпечатване  90, 134, 
169 до 181, PIC_001, 
PRT_001 до PRT_014  
3.34 Предупреждаване  134, 182 до 191, 
PIC_001  
3.35 Изтегляне на данни към външни носители  90, 134, 192 до 196  
3.36 Връзка от разстояние за извършване на насочени пътни проверки  197 до 199  
3.37 Обмен на данни с допълнителни външни устройства  200, 201  
3.38 Калибриране  202 до 206*, 383, 384, 386 до 
391 
3.39 Крайпътна проверка на калибрирането  207 до 209  
3.40 Сверяване на часовника  210 до 212*  
3.41 Следене на пресичането на граници  226а до 226в  
3.42 Актуализация на софтуера  226г до 226е  
3.43 Отсъствие на смущения от страна на допълнителните функции  06, 425  
3.44 Интерфейс на датчика за движение  02, 122  
3.45 Външно устройство за GNSS  03, 123  
3.46 Да се провери дали бордовото устройство открива, записва и 
съхранява събитието(та) и/или неизправността(ите), определени 
от производителя на бордовото устройство, когато съответно 
свързан с него датчик за движение реагира на магнитни полета, 
смущаващи установяването на движението на превозното 
средство.  217 
3.47 Криптографска поредица (cypher suite) и стандартизирани домейн  
параметри  CSM_48, CSM_50  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 396  
№ Изпитване  Описание  Съответни изисквания  
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 
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: Търговски 
превозни средства с отделна кабина  219 ▼M1
 02016R0799 — BG — 21.08.2023 — 003.001 — 397  
№ Изпитване  Описание  Съответни изисквания  
Изпитване за случайни вибрации, 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. 
Гореописаните изпитвания се извършват 
върху различни мостри на изпитваните 
съоръжения.  
4.4 Защита срещу прон­ 
икване на вода и 
чужди тела  Изпитване съгласно ISO 20653: Пътни 
превозни средства. Степен на защита (IP 
код). Защита на електрическото оборудване 
срещу проникване на чужди тела, вода и 
достъп (запазване на характеристиките); 
Минимално допустима стойност IP 40  220, 221  
4.5 Защита срещу прена­ 
прежения  Проверява се, че бордовото устройство 
може да понесе захранващо напрежение, 
както следва: 
при варианти за напрежение 24 V: 
34 V при + 40 °C в продължение на 1 
час: 
при варианти за напрежение 24 V: 34 V 
при + 40 °C в продължение на 1 час 
при варианти за напрежение 12 V: 17 V 
при + 40 °C в продължение на 1 час: 
при варианти за напрежение 12 V: 17 V 
при + 40 °C в продължение на 1 час 
(ISO 16750-2)  216 
4.6 Защита срещу 
включване с обратна 
полярност  Проверява се, че бордовото устройство 
може да издържи на размяна на 
полюсите на електрическото му 
захранване 
(ISO 16750-2)  216 
4.7 Защита срещу къси 
съединения  Проверява се, че входно/изходните сигнали 
са защитени срещу къси съединения към 
захранването и към масата 
(ISO 16750-2)  216 
5. Изпитване  за електромагнитна  съвместимост  (EMC)  
5.1 Излъчени емисии и 
чувствителност към 
тях Съответствие с Правило № 10 на ИКЕ на 
ООН  218 
5.2 Електростатичен 
разряд  Съответствие със стандарт ISO 
10605:2008 + 
Техническа поправка: 2010 + 
AMD1:2014: +/- 4 kV за контактен разряд 
и +/- 8 kV за разряд през въздух  218 ▼M1
 02016R0799 — BG — 21.08.2023 — 003.001 — 398  
№ Изпитване  Описание  Съответни изисквания  
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 
▼B 
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*  ▼M1
 02016R0799 — BG — 21.08.2023 — 003.001 — 399  
№ Изпитване  Описание  Съответни изисквания  
3.2 Сдвояване датчик за движение — бордово устройство  122*, 204  
3.3 Установяване на движение 
Точност на измерване на движението  30 до 35  
3.4 Интерфейс към бордовото устройство  0 2  
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 
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 ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 400  
№ Изпитване  Описание  Съответни изисквания  
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 
5. Изпитание  за електромагнитна  съвместимост  
5.1 Излъчени емисии и чувст­ 
вителност към тях  Проверява се съответствието с Правило 
№ 10 на ИКЕ на ООН  218 
5.2 Електростатичен разряд  Съответствие със стандарт ISO 10605:2008 + 
Техническа поправка:2010 + AMD1:2014: +/– 
4 kV за контактен разряд и +/– 8 kV за 
разряд през въздух  218 ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 401  
№ Изпитване  Описание  Съответни изисквания  
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 — 21.08.2023 — 003.001 — 402  
№ Изпитване  Описание  Съответни изисквания  
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 — 21.08.2023 — 003.001 — 403  
№ Изпитване  Описание  Съответни изисквания  
[Сигурност] 
Приложение 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 — 21.08.2023 — 003.001 — 404  
№ Изпитване  Описание  Съответни изисквания  
[Конструкция на картата] 
Тахографските карти трябва да съответстват на 
стандарта 
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 — 21.08.2023 — 003.001 — 405  
№ Изпитване  Описание  Съответни изисквания  
[Светлина] 
Тахографските карти трябва да съответстват на 
стандарта 
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 — 21.08.2023 — 003.001 — 406  
№ Изпитване  Описание  Съответни изисквания  
[Деформации на повърхността] 
Тахографските карти трябва да съответстват на 
стандарта 
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 — 21.08.2023 — 003.001 — 407  
№ Изпитване  Описание  Съответни изисквания  
[Механична якост] 
Тахографските карти трябва да съответстват на 
стандарта 
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 — 21.08.2023 — 003.001 — 408  
№ Изпитване  Описание  Съответни изисквания  
[Температура и влажност] 
Приложение 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 — 21.08.2023 — 003.001 — 409  
№ Изпитване  Описание  Съответни изисквания  
[Статично електричество] 
Приложение 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 — 21.08.2023 — 003.001 — 410  
№ Изпитване  Описание  Съответни изисквания  
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 — 21.08.2023 — 003.001 — 411  
№ Изпитване  Описание  Съответни изисквания  
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 — 21.08.2023 — 003.001 — 412  
№ Изпитване  Описание  Съответни изисквания  
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 — 21.08.2023 — 003.001 — 413  
№ Изпитване  Описание  Съответни изисквания  
2. Случайни вибрации: 
Изпитване съгласно ISO 16750-3: Глава 4.1.2.8: Изпит- 
ване VIII: Търговски превозни средства (commercial 
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 : И з п и тван и я — И зп и тва н е F h : В и б р а ц и и ,  
широколентови случайни, и указания 
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 — 21.08.2023 — 003.001 — 414  
№ Изпитване  Описание  Съответни изисквания  
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 Записване и съхраняване на данните в паметта  9 1  
3.3 Връзка с бордовото устройство  Допълнение 14, 
раздели DSC_66 до 
DSC_70 и DSC_71 
до DSC_76  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 415  
№ Изпитване  Описание  Съответни изисквания  
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 — 21.08.2023 — 003.001 — 416  
№ Изпитване  Описание  Съответни изисквания  
импулс 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 — 21.08.2023 — 003.001 — 417  
№ Изпитване  Описание  Съответни изисквания  
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 — 21.08.2023 — 003.001 — 418  
Стойностите на оптичната плътност на съответните разпечатки тря бва 
да се измерват в съответствие с 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 — 21.08.2023 — 003.001 — 419  
9. ИЗПИТВАНИЯ НА OSNMA  
9.1. Въведение  
В настоящата глава се описват изпитванията за доказване на 
правилното прилагане на OSNMA в приемника на сигнали от 
GNSS. Тъй като удостоверяването на автентичността на спътникови  
сигнали се извършва единствено от приемника на сигнали от GNSS,  
без да има зависимост от който и да е друг компонент на тахогра фа, 
изпитванията, определени в настоящата глава, могат да се извърш ат 
върху приемника на сигнали от GNSS като самостоятелен елемент. В 
този случай производителят на тахографа представя на органите п о 
одобряване на типа протокол, съдържащ подробности за развитието  и 
резултатите от изпитванията, които се извършват на отговорност на 
производителя на приемника на сигнали от GNSS.  
9.2 Приложими  условия  
— Критериите за успешно/неуспешно преминаване на изпитването, 
определени в изпитванията на OSNMA, се считат за валидни само 
за определените условия на изпитване.  
— Критериите могат да бъдат преразгледани в момента на деклари­  
рането на услугата OSNMA на „Галилео“ и при отчитане на свър­ 
заните с нея ангажименти за изпълнение на услугата.  
9.3. Определения  и съкращения  
9.3.1 Определения  
Студен/топъл/горещ 
старт на GNSS: отнася се за условието на започване на 
работа на приемника на сигнали от 
GNSS, на базата на наличието на време 
(T), текущите алманах (A) и астроно­ 
мическа таблица (E), местоположение (P):  
— Студен старт на GNSS: Няма  
— Топъл старт на GNSS: T, A, P  
— Горещ старт на GNSS: T, A, E, P  
Студен/топъл/горещ 
старт на OSNMA: отнася се за условието на започване на 
работа на функцията OSNMA, на базата 
на наличието на публичен ключ (P) и 
информация за DSM-KROOT (K), както е 
определена в насоките за приемника за 
OSNMA, посочени в допълнение 12):  
— Студен старт на OSNMA: Няма  
— Топъл старт на OSNMA: P  
— Горещ старт OSNMA: P, K  
9.3.2 Съкращения  
ADKD  Authentication Data & Key Delay (Забавяния на данните 
за удостоверяване на автентичността и ключа)  
DSM-KROOT Digital Signature Message KROOT (Съобщение за 
цифров подпис KROOT)  
GNSS Global Navigation Satellite System (Глобална навига­ 
ционна спътникова система)  
KROOT Root Key of the TESLA key chain (Основен ключ на 
веригата TESLA за ключове)  
MAC Message Authentication Code (Код за удостоверяване 
на автентичността на съобщение)  
NMACK Number of MAC & key blocks (Брой на блоковете за 
MAC и за ключ (за 30 секунди)  
OSNMA Galileo Open Service Navigation Message Authentication 
(Удостоверяване на автентичността на навигаци­ 
онните съобщения от отворената услуга на „Галилео“)  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 420  
SLMAC Slow MAC (бавен MAC)  
TESLA Timed Efficient Stream Loss-tolerant Authentication 
(Ограничено във времето, ефикасно, поточно, толе­ 
риращо загуби удостоверяване на автентичността) 
(протокол, използван в OSNMA)  
9.4. Оборудване  за генериране  на сигналите  от GNSS  
Генерирането на сигнали от GNSS може да се извършва, като се 
използва симулатор на сигнали от GNSS за група спътници, който 
поддържа предаване на съобщения OSNMA. Като алтернатива може 
да се използва устройство за повторно излъчване на радиочестотн ите 
сигнали, способно отново да възпроизведе фрагменти от файлове с ъс 
сигнали от GNSS. Обичайната разрядност на квантуване и честотат а 
на дискретизация са съответно 4 бита I/Q и 10 MHz.  
Приема се, че приемникът на сигнали от GNSS има интерфейси за 
управление на изчистването на паметта на приемника (за само­ 
стоятелно изтриване на публичния ключ, KROOT, информацията от 
часовника, информацията за местоположението, астрономическата 
таблица и алманаха), за да се настрои реализацията на местното 
време на приемника за целите на изискването на OSNMA за 
проверка на времето и да се зареди криптографската информация. 
Тези команди могат да бъдат ограничени до целите на изпитването  
и следователно може да не са на разположение за номиналната раб ота 
на приемника.  
9.5 Условия  на изпитване  
9.5.1 Условия за GNSS  
Симулираните или повторно възпроизвежданите сигнали от GNSS 
трябва да имат следните характеристики:  
— Сценарий със статичен приемник на ползвателя;  
— Най-малко групите спътници на GPS и „Галилео“;  
— Честота E1/L1;  
— Най-малко 4 спътника „Галилео“ с ъгъл над хоризонта, по-голям  
от 5°;  
— Продължителност, както се изисква за всяко изпитване;  
— Постоянни астрономически таблици (ефемериди) за навигацията 
от спътниците по време на изпитването.  
9.5.2 Условия за OSNMA  
Съобщението OSNMA, предавано с радиочестотния сигнал, трябва да  
има следните характеристики:  
— Съобщение HKROOT със статус на OSNMA, зададен на 
оперативен или изпитвателен режим и фиксирано DSM-KROOT 
от 8 блока за веригата, която е в сила;  
— Най-малко 4 спътника на „Галилео“, предаващи OSNMA;  
— Съобщение MACK с един блок MACK (т.е. NMACK=1) и поне 
един ADKD=0 и един ADKD=12 на спътник и на блок MACK;  
— Размер на тага 40 бита;  
— Минималната еквивалентна дължина на тага, както се изисква в 
насоките за приемника за OSNMA (понастоящем 80 бита).  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 421  
Освен когато е отбелязано, реализирането на вътрешното време на  
приемника трябва да бъде известно с достатъчна точност и правил но 
синхронизирано със симулираното време. Това гарантира, че изиск ­ 
ването на OSNMA за първоначална синхронизация на времето е 
изпълнено за всяко от условията на изпитване, т.е. номиналната 
синхронизация за всички освен за изпитването на SLMAC. Вж. 
насоките за приемника за OSNMA за повече подробности относно 
инициализирането на времето.  
Следва да се отбележи, че установените критерии за успешно/ 
неуспешно преминаване са консервативни и не отразяват очакванит е 
резултати на OSNMA на „Галилео“.  
9.6. Спецификация  на изпитванията  
№ Изпитване  Описание  Съответни 
изисквания  
1. Административен  преглед  
1.1 Документация  Коректност на документацията  
2 Общи  изпитвания  
2.1 Горещ старт на 
OSNMA  Цел: проверява се дали след горещ старт 
приемникът на сигнали от GNSS изчислява место­ 
положение с OSNMA. 
Процедура:  
Приемникът на сигнали от GNSS започва да работи 
при условия на горещ старт на GNSS и OSNMA и 
получава сигнали от видимите спътници на „Галилео“. 
Приемникът удостоверява автентичността на навига­ 
ционните данни от „Галилео“ с OSNMA (ADKD = 0) 
и предоставя местоположение с данни, чиято автен­ 
тичност е удостоверена. 
Критерии за успешно/неуспешно преминаване: 
приемникът изчислява определено местоположение с 
удостоверена автентичност в рамките на 160 секунди.  Допълнение 12, 
GNS_3b  
2.2 Топъл старт на 
OSNMA  Цел: проверява се дали след топъл старт 
приемникът на сигнали от GNSS изчислява место­ 
положение с OSNMA. 
Процедура: 
Преди началото на изпитването информацията за 
астрономическите таблици и KROOT трябва да 
бъде изтрита от паметта на приемника на сигнали 
от GNSS, за да се предизвика топъл старт на GNSS 
и OSNMA.  
Приемникът на сигнали от GNSS започва да работи и 
получава сигнали от видимите спътници на „Галилео“. 
DSM-KROOT е получен и проверен. 
Приемникът удостоверява автентичността на навига­ 
ционните данни от „Галилео“ с OSNMA (ADKD=0) 
и предоставя местоположение с данни, чиято автен­ 
тичност е удостоверена. 
Критерии за успешно/неуспешно преминаване: 
приемникът изчислява определено местоположение с 
удостоверена автентичност в рамките на 430 секунди.  Допълнение 12, 
GNS_3b  
2.3 Топъл старта на 
OSNMA със SLMAC  Цел: проверява се дали след топъл старт с инициали­ 
зиране на времето, изискващо режим SLMAC, както е 
определено в насоките за приемник за OSNMA, 
приемникът на сигнали от GNSS изчислява местопо­ 
ложението с OSNMA. 
Процедура:  
Реализирането на вътрешното време на приемника се 
конфигурира по начин, при който има първоначална 
неопределеност на времето със стойност между 2 и 2,5 
минути, така че в съответствие с насоките за приемника 
за OSNMA, да се задейства режимът Slow MAC.  Допълнение 12, 
GNS_3b  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 422  
№ Изпитване  Описание  Съответни 
изисквания  
Преди началото на изпитванията информацията за астро­ 
номическите таблици и KROOT трябва да се изтрие от 
паметта на приемника на сигнали от GNSS, за да се 
предизвика топъл старт на GNSS и OSNMA. 
Приемникът на сигнали от GNSS започва да работи и 
получава сигнали от видимите спътници на „Галилео“. 
DSM-KROOT е получен и проверен. 
Приемникът удостоверява автентичността на навигаци­ 
онните данни от „Галилео“ само със Slow MAC 
OSNMA (ADKD=12) и предоставя местоположение с 
данни, чиято автентичност е удостоверена. 
Критерии за успешно/неуспешно преминаване: 
приемникът изчислява определено местоположение с 
удостоверена автентичност в рамките на 730 секунди.  
2.4 Горещ старт на 
OSNMA с повторно 
възпроизведен сигнал  Цел: Проверява се дали приемникът за GNSS 
открива повторно възпроизведен сигнал. 
Процедура: 
Приемникът на сигнали от GNSS започва да работи 
при условия на горещ старт на GNSS и OSNMA и 
получава сигнали от видимите спътници на 
„Галилео“. 
Приемникът удостоверява автентичността на нави­ 
гационните данни от „Галилео“ с OSNMA 
(ADKD=0) и предоставя местоположение с данни, 
чиято автентичност е удостоверена. 
След като приемникът предостави решение за 
местоположението, скоростта и времето с данни, 
чиято автентичност е удостоверена, той се 
изключва. 
Симулира се повторно възпроизведен сигнал със 
закъснение от 40 секунди спрямо предходния и 
приемникът се включва. 
Приемникът открива, че системното време на 
„Галилео“ от времето в космическия сигнал и 
реализацията на местното времето не отговарят на 
изискването за синхронизация, и прекратява обра­ 
ботката на данни за OSNMA, както е определено в 
насоките за приемника за OSNMA. 
Критерии за успешно/неуспешно преминаване: 
приемникът открива повторното възпроизвеждане 
и не изчислява местоположение с удостоверена 
автентичност от началото на повторното възпро­ 
извеждане до края на изпитването.  Допълнение 12, 
GNS_3b  
2.5 Горещ старт на 
OSNMA с фалшиви 
данни  Цел: Проверява се дали OSNMA открива фалшиви 
данни. 
Процедура: 
Приемникът за GNSS започва в условията горещ 
старт на GNSS и OSNMA. 
Приемникът за GNSS трябва да може да получава 
сигнала от всички видими спътници на „Галилео“ и 
да проверява автентичността на техните навига­ 
ционни съобщения посредством OSNMA. 
Най-малко един бит от данните за астрономическите 
таблици, предоставяни от всеки от спътниците на 
„Галилео“, не съответства на оригиналните данни 
с удостоверена автентичност, но съобщението I/ 
NAV на „Галилео“ трябва да бъде съгласувано, 
включително CRC. 
Критерии за успешно/неуспешно преминаване: 
приемникът открива фалшивите данни в рамките 
на 160 секунди и не изчислява местоположение с 
удостоверена автентичност до края на изпитването.  Допълнение 12, 
GNS_3b  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 423  
Допълнение  10 
ИЗИСКВАНИЯ  ЗА СИГУРНОСТ  
В настоящото допълнение са специфицирани изискванията за информ а­ 
ционна сигурност по отношение на компонентите на интелигентните  тахог­ 
рафски системи (тахографите от второ поколение).  
SEC_001 Сертифициране за сигурност по Схемата за общите критери и се 
изисква за следните компоненти на интелигентната тахографска 
система:  
— бордовото устройство,  
— тахографската карта,  
— датчика за движение,  
— външното устройство за GNSS.  
SEC_002 Минималните изисквания за информационна сигурност, на к оито 
трябва да отговаря всеки компонент, подлежащ на сертифициране 
за сигурност, се дефинират в защитен профил на компонента, в 
съответствие със Схемата за общите критерии.  
SEC_003 За посочените по-долу четири защитни профила в съответс твие с 
настоящото приложение Европейската комисия трябва да осигури 
те да бъдат спонсорирани, разработени, одобрени от държавните 
сертификационни органи по информационна сигурност, които са 
организирани в рамките на Съвместната интерпретационна 
работна група (Joint Interpretation Working Group — JIWG), 
която съдейства за взаимното признаване на сертификатите под 
егидата на Европейското споразумение за взаимно признаване на 
сертификатите за оценка на сигурността на информационните 
технологии (Agreement on Mutual Recognition of Information Tech ­
nology Security Evaluation Certificates — SOGIS-MRA), както и 
регистрирани:  
— Защитен профил за бордово устройство,  
— Защитен профил за тахографска карта,  
— Защитен профил за датчик за движение,  
— Защитен профил за външно устройство за GNSS.  
Защитният профил за бордово устройство трябва да се отнася за с лучаите, 
при които бордовият блок е проектиран да се използва със или бе з външно 
устройство за GNSS. В първия от тези два случая изискванията за  сигурност 
за външното GNSS устройство се посочват в неговия защитен профи л. 
SEC_004 Производителите на компоненти трябва да уточняват и доп ълват 
съответния защитен профил, както е необходимо, без да изменят 
или изтриват съществуващи заплахи, цели, процедурни средства и 
спецификации за функции за обезпечаване на сигурност, така че 
да формулират цел за сигурност, спрямо която да кандидатстват 
за сертифициране за сигурност на съответния компонент.  
SEC_005 По време на процеса на оценка трябва да бъде деклариран о 
наличието на строго съответствие на такава специфична цел за 
сигурност със съответния защитен профил.  
SEC_006 Нивото на сигурност на всеки защитен профил трябва да б ъде 
EAL4, увеличено с компонентите за сигурност ATE_DPT.2 и 
AVA_VAN.5.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 424  
Допълнение  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 — 21.08.2023 — 003.001 — 425  
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 — 21.08.2023 — 003.001 — 426  
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 — 21.08.2023 — 003.001 — 427  
ПРЕАМБЮЛ  
В настоящото допълнение са специфицирани механизмите за сигурно ст, 
които обезпечават:  
— взаимно удостоверяване на автентичност между различни компоне нти 
на тахографската система.  
— поверителност, цялостност, автентичност и безотказно приемане  на 
данните, предавани между различните компоненти на тахографската  
система или изтегляни от външни носители на информация.  
Настоящото допълнение се състои от две части. В Част А са дефин ирани 
механизмите за сигурност за тахографска система от първо поколе ние 
(цифров тахограф). В Част Б са дефинирани механизмите за сигурн ост за 
тахографска система от второ поколение (интелигентен тахограф).  
Механизмите, специфицирани в Част А от настоящото допълнение, с е 
прилагат ако поне един от компонентите на тахографската система , 
участващи в процес на взаимно удостоверяване на автентичност и/ или 
прехвърляне на данни, е от първо поколение.  
Механизмите, специфицирани в Част Б от настоящото допълнение, с е 
прилагат ако и двата компонента на тахографската система, участ ващи в 
процес на взаимно удостоверяване на автентичност и/или прехвърл яне на 
данни, са от второ поколение.  
Допълнителна информация относно използването на компоненти от п ърво 
поколение в комбинация с компоненти от второ поколение е дадена  в  
Допълнение 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 — 21.08.2023 — 003.001 — 428  
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 — 21.08.2023 — 003.001 — 429  
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 — 21.08.2023 — 003.001 — 430  
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 — 21.08.2023 — 003.001 — 431  
Движението на данните при този процес е обобщено на 
следната фигура:
  
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 — 21.08.2023 — 003.001 — 432  
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 — 21.08.2023 — 003.001 — 433  
Данни  Формат  Байтове  Забележки  
EOV  TimeReal  4  Изтичане на валидността 
на сертификата. Незадъл­ 
жително, може да се 
допълни с „FF“, ако не 
е използвано.  
CHR  OCTET 
STRING  8 Референтно означение на 
титуляря на сертификата  
n OCTET 
STRING  128 Публичен ключ (модул)  
е OCTET 
STRING  8 Публичен ключ (публичен 
степенен показател)  
164 
Забележки : 
1. „Идентификаторът на профила на сертификата“ (Certificate Pro file 
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 — 21.08.2023 — 003.001 — 434  
4. „Референтното означение на титуляря на сертификата“ (CHR) е 
предназначено да служи за уникално идентифициране на 
титуляря на сертификата по такъв начин, че елементът от данни 
да може да бъде използван в същото време и като идентификатор 
на предметен ключ, за означаване на публичния ключ на 
титуляря на сертификата.  
5. Идентификаторите на ключове служат за уникално идентифи­ 
циране на титуляря на сертификата или на сертифициращите 
органи. Те се кодират, както следва:  
5.1. Оборудване (бордово устройство или карта): 
Данни  Сериен 
номер на 
оборуд­ 
ването  Дата  Тип  Производител  
Дължина  4 байта  2 байта  1 байт  1 байт  
Стойн- 
ост Цяло 
число  Кодиране BCD мм 
гг Специфични 
данни за 
производителя  Код на произ­ 
водителя  
В случаите, при които става въпрос за бордово устройство, 
при исканията за сертификати е възможно производителят да 
знае или да не знае идентификационните данни на оборуд­ 
ването, в което ще бъдат въведени ключовете.  
В първия случай производителят изпраща до сертифи­ 
циращия орган в своята държава членка идентификаци­ 
онните данни на оборудването и публичния ключ. Серти­ 
фикатът в такъв случай съдържа идентификационните 
данни на оборудването и производителят трябва да осигури 
въвеждането на ключовете и сертификата в съответното 
оборудване. Идентификаторът на ключа има указаната по- 
горе форма.  
Във втория случай производителят трябва да идентифицира 
уникално всяко искане за сертификат и да изпрати до серти­ 
фициращия орган в своята държава членка тази иденти­ 
фикация и публичния ключ. В такъв случай сертификатът 
съдържа идентификацията на искането за сертификат. След 
инсталирането на ключ в оборудването производителят 
трябва да подаде до сертифициращия орган в своята 
държава членка обратна информация за определянето на 
ключ за оборудването (т.е. за идентификацията на искането 
за сертификат и за идентификацията на оборудването). Иден­ 
тификаторът на ключа има указаната по-долу форма: 
Данни  Сериен 
номер на 
искането 
за серти- 
фикат  Дата  Тип  Производител  
Дължина  4 байта  2 байта  1 байт  1 байт  
Стой- 
ност  Integer  Кодиране BCD мм 
гг „FF“  Код на произ­ 
водителя  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 435  
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 — 21.08.2023 — 003.001 — 436  
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 — 21.08.2023 — 003.001 — 437  
CSM_020 Използва се следният протокол (стрелките указват обме­ 
нените команди и данни (вж. допълнение 2)):
  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 438
  
▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 439  
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 — 21.08.2023 — 003.001 — 440  
При дадена незащитена двойка от команда и отвор:  
Заглавна част на командата  Тяло на командата  
CLA  INS  P 1  P 2  [ L  c на поле]  [Поле за данни]  [ L  e на поле]  
четири байта  Байтове L, означени като B  1 до B  L 
Тяло на отговора  Завършваща част на отговора  
[Поле за данни]  SW1  SW2  
Байтове данни L  r Два байта  
Съответната защитена двойка от команда и отговор е:  
Защитена от неоторизиран достъп команда:  
Заглавна част на 
командата (CH)  Тяло на командата  
CLA  INS  P 1  P 2  [ 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“  C C  
Данни, които се включват в контролната сума = 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“  C C  
Данни, които се включват в контролната сума = T  PV || 
L PV || PV || PB  
2. Случай, когато полето за данни на отговора не е 
празно и се нуждае от защита с цел поверителност:  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 441  
Тяло на отговора  Завършваща част на 
отговора  
[Ново поле за данни]  Нови SW1 SW2  
T PI CG  L PI 
CG PI CG  T  CC L CC CC 
„87“  PI || CG  „8E“  „04“  C C  
Данни, които се маршрутизират чрез 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“  C C  
Данни, които се включват в контролната сума = 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)).  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 442  
където съкращението E() означава криптиране с DES, а 
съкращението D() означава декриптиране с DES.  
Прехвърлят се четирите най-старши байта от криптог­ 
рафската контролна сума.  
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 — 21.08.2023 — 003.001 — 443  
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“||„0 5“||„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 — 21.08.2023 — 003.001 — 444
  
ЧАСТ Б  
ТАХОГРАФСКА  СИСТЕМА  ОТ ВТОРО  ПОКОЛЕНИЕ  
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 — 21.08.2023 — 003.001 — 445  
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 — 21.08.2023 — 003.001 — 446  
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 u ser 
X (сертифициращият орган, издал сертификата на 
ползвателя X)  
X.CAR The certificate authority reference mentioned in the cert i­
ficate of user X (референтното означение на сертифи­ 
циращия орган, посочено в сертификата на ползвателя 
X) 
X.CHR The certificate holder reference mentioned in the certifi cate 
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 (краткотраен 
(ephemeral) частен ключ на ползвателя Х)  
„xx“ A hexadecimal value (шестнадесетична стойност)  
|| Concatenation operator (оператор за конкатенация)  
7.3. Определения  
Определенията на използваните в настоящото допълнение термини 
са включени в раздел I от приложение 1В.  
8. КРИПТОГРАФСКИ СИСТЕМИ И АЛГОРИТМИ  
8.1. Криптографски  системи  
CSM_38 Бордовите устройства и тахографските карти трябва да 
използват класическа базираща се на елиптична крива 
криптографска система с публичен ключ за пред­ 
оставяне на следните механизми за сигурност:  
— взаимно удостоверяване на автентичност между 
бордово устройство и карта,  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 447  
— договаряне на AES сесийни ключове между 
бордово устройство и карта,  
— осигуряване на автентичност, цялостност и 
безотказно приемане на данните, изтегляни от 
бордовите устройства или от тахографските карти 
върху външни носители на информация.  
CSM_39 Бордовите устройства и външните устройства за GNSS 
трябва да използват класическа базираща се на 
елиптична крива криптографска система с публичен 
ключ за предоставяне на следните механизми за 
сигурност:  
— свързване на бордово устройство и външно GNSS 
устройство,  
— взаимно удостоверяване на автентичност между 
бордово устройство и външно GNSS устройство,  
— договаряне на AES сесийни ключове между 
бордово устройство и външно GNSS устройство.  
CSM_40 Бордовите устройства и тахографските карти трябва да 
използват класическа базираща се на AES симетрична 
криптографска система за предоставяне на следните 
механизми за сигурност:  
— осигуряване на автентичност и цялостност на 
данните, обменяни между бордово устройство и 
тахографска карта,  
— в съответните случаи, осигуряване на повери­ 
телност на данните, обменяни между бордово 
устройство и тахографска карта.  
CSM_41 Бордовите устройства и външните устройства за GNSS 
трябва да използват класическа базираща се на AES 
симетрична криптографска система за предоставяне 
на следните механизми за сигурност:  
— осигуряване на автентичност и цялостност на 
данните, обменяни между бордово устройство и 
тахографска карта.  
CSM_42 Бордовите устройства и датчиците за движение трябва 
да използват класическа базираща се на AES симе­ 
трична криптографска система за предоставяне на 
следните механизми за сигурност:  
— сдвояване на бордово устройство и датчик за 
движение,  
— взаимно удостоверяване на автентичност между 
бордово устройство и датчик за движение,  
— осигуряване на поверителност на данните, 
обменяни между бордово устройство и датчик за 
движение.  
CSM_43 Бордовите устройства и контролните карти трябва да 
използват класическа базираща се на AES симетрична 
криптографска система за предоставяне на следните 
механизми за сигурност:  
— осигуряване на поверителност, автентичност и 
цялостност на данните, предавани между бордово 
устройство и контролна карта,  
Забележки : 
— По-точно казано, данните се предават от бордово 
устройство към дистанционно разпитващо устройство 
под контрола на инспектор, като се използва 
устройство за връзка от разстояние, което може да е 
вътрешно или външно за бордовото устройство, вж.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 448  
допълнение 14. Дистанционното разпитващо 
устройство обаче изпраща получените данни на 
контролна карта за дешифриране и валидиране на 
автентичността. От гледна точка на сигурността, 
устройството за връзка от разстояние и дистанци­ 
онното разпитващо устройство са изцяло прозрачни.  
— Същите механизми за сигурност, които се 
изпълняват от контролната карта, се предоставят и 
от картата за монтаж и настройки по отношение на 
интерфейса за 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 — 21.08.2023 — 003.001 — 449  
Забележка : идентификаторите на обекти, споменати в 
последната колона на таблица 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  1 2  
CS#3  512/521  256  SHA-512  1 6  
Забележка : Размерите на ECC ключове от 512 бита и 
521 бита се считат за равни по сила за всички цели в 
рамките на настоящото допълнение.  
9. КЛЮЧОВЕ И СЕРТИФИКАТИ  
9.1. Двойки  от асиметрични  ключове  и сертификати  на публични  
ключове  
9.1.1  Общи  положения  
Забележка : описаните в настоящия раздел ключове се използват за 
взаимно удостоверяване на автентичност и за защитен обмен на 
съобщения между бордови устройства и тахографски карти, както 
и между бордови устройства и външни устройства за GNSS. Тези 
процеси са описани подробно в глава 10 и глава 11 от настоящото  
допълнение.  
CSM_51 В рамките на Европейската система за интелигентни 
тахографи, двойките ECC ключове и съответните 
сертификати се генерират и управляват на три 
функционални йерархични равнища:  
— европейско равнище,  
— равнище на държавата членка,  
— равнище на вид оборудване.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 450  
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 — 21.08.2023 — 003.001 — 451  
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 — 21.08.2023 — 003.001 — 452  
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 и 
трябва да използва дадена двойка краткотрайни 
(ephemeral) ключове изключително само за извършване 
на договаряне на сесиен ключ с тахографска карта или 
с външно устройство за GNSS, както е специфицирано 
в раздел 10.4 и раздел 11.4 от настоящото допълнение.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 453  
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 — 21.08.2023 — 003.001 — 454  
— Сертификата 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 — 21.08.2023 — 003.001 — 455  
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 — 21.08.2023 — 003.001 — 456  
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 — 21.08.2023 — 003.001 — 457  
— Ако съществува — сертификата 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 — 21.08.2023 — 003.001 — 458  
Забележки  към фигура  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 — 21.08.2023 — 003.001 — 459  
Таблица  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 — 21.08.2023 — 003.001 — 460  
— Както е изяснено в раздел 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 — 21.08.2023 — 003.001 — 461  
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 — 21.08.2023 — 003.001 — 462  
Фигура  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 — 21.08.2023 — 003.001 — 463  
Забележка : Това означава, че в последната година на 
валидност на даден сертификат на 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 — 21.08.2023 — 003.001 — 464  
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 
Reference) в сертификатите на бордовото устройство.  
▼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  е  K M  DSRC  . ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 465  
Стъпка 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 — 21.08.2023 — 003.001 — 466  
Фигура  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 — 21.08.2023 — 003.001 — 467  
Забележка : Това означава, че в последната година на 
валидност на даден сертификат на 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 — 21.08.2023 — 003.001 — 468  
Поле  ID на полето  Таг  Дължи-на (бай-тове)  ASN.1 тип на данните 
(вж. допълнение 1)  
Идентификатор на 
профила на серти­ 
фиката  CPI „5F 29“  „01“
  
Референтно 
означение на серти­ 
фициращия орган  CAR  „42“  „08“
  
Оторизация на 
титуляря на серти­ 
фиката  CHA  „5F 4C“  „07“
  
Публичен ключ  P K  „7F 49“  променлива  
Домейн параметри  D P  „06“  променлива
  
Публична точка  P P  „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 — 21.08.2023 — 003.001 — 469  
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 — 21.08.2023 — 003.001 — 470  
Забележка : При сертификат на карта стойността на 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 — 21.08.2023 — 003.001 — 471  
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 — 21.08.2023 — 003.001 — 472  
— Трето, и двете страни независимо изчисляват два 
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 — 21.08.2023 — 003.001 — 473  
— Сертификатът 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 — 21.08.2023 — 003.001 — 474  
Фигура  4 
Протокол  за проверка  от бордово  устройство  на веригата  на сертифициране  на карта
  
10.2.2  Проверка  от карта  на веригата  на сертифициране  на бордово  
устройство  
CSM_161  ►M1 За проверяване на веригата на сертифициране на 
бордово устройство тахографските карти трябва да 
използват протокола, описан във фигура 5. За всеки 
сертификат, представен от бордовото устройство, 
картата трябва да провери дали полето за оторизация 
на титуляра на картата (Card Holder Authorisation — 
CHA) е правилно:  
— CHA в сертификат VU.Link трябва да указва ERCA.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 475  
— CHA в сертификат VU.CA трябва да указва MSCA.  
— Полето CHA в сертификата на бордовото устройство 
трябва да указва сертификат на бордово устройство 
за взаимно удостоверяване на автентичността (вж. 
допълнение 1, тип данни EquipmentType). ◄  
Фигура  5 
Протокол  за проверка  от карта  на веригата  на сертифициране  на бордово  устройство
  
Забележки  към фигура  5: 
— Посочените във фигурата сертификати и публични ключове VU 
са тези, които се използват за взаимно удостоверяване на автен­  
тичността. В раздел 9.1.4 те са означени като VU_MA.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 476  
— Посочените във фигурата сертификати и публични ключове 
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 — 21.08.2023 — 003.001 — 477  
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 — 21.08.2023 — 003.001 — 478  
Забележка : Последното изискване означава, че картата 
трябва да може да разпознае референтното означение на 
сертифициращия орган (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 — 21.08.2023 — 003.001 — 479  
Фигура  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 — 21.08.2023 — 003.001 — 480  
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 — 21.08.2023 — 003.001 — 481  
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 — 21.08.2023 — 003.001 — 482  
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 — 21.08.2023 — 003.001 — 483  
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 indicator), открита 
(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 — 21.08.2023 — 003.001 — 484  
— Както е специфицирано в допълнение 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 — 21.08.2023 — 003.001 — 485  
По-долу са дадени три примера за преобразуване на APDU за 
команди с четен INS код. На фигура 8 е показана командна APDU 
с удостоверена автентичност — случай 4, на фигура 9 е показана 
ответна APDU с удостоверена автентичност — случай 1/случай 3, а  
на фигура 10 е показана криптирана ответна APDU с удостоверена 
автентичност — случай 2/случай 4.  
Фигура  8 
Преобразуване  на командна  APDU с удостоверена  автентичност , случай  4
 
Фигура  9 
Преобразуване  на ответна  APDU с удостоверена  автентичност , случай  
1/случай  3
 ▼M1
 02016R0799 — BG — 21.08.2023 — 003.001 — 486  
Фигура  10 
Преобразуване  на криптирана  ответна  APDU с удостоверена  автентичност , случай  2/случай  4
 
▼B 
10.5.3  Прекратяване  на сесия  на защитен  обмен  на съобщения  
CSM_192 Бордовото устройство трябва да прекрати текуща сесия 
на защитен обмен на съобщения ако и само ако е 
изпълнено едно от следните условия:  
— бордовото устройство получи ответна APDU в открит 
текст,  
— бордовото устройство открие в ответна APDU грешка 
по отношение на защитения обмен на съобщения, 
както следва:  
— Липсва очакван обект от данни за защитен обмен 
на съобщения, подреждането на обектите от данни 
е неправилно или е включен непознат обект от 
данни.  
— Даден обект от данни за защитен обмен на 
съобщения е неправилен, например стойността на 
MAC е невярна, структурата на TLV е неправилна 
или индикаторът за запълване в таг „87“ не е равен 
на „01“.  
— картата изпраща байт за състояние, показващ че тя е 
открила грешка в защитения обмен на съобщения (вж. 
CSM_194),  
— достигнат е лимитът за броя на командите и съот­ 
ветните отговори в рамките на текущата сесия. Този 
лимит за дадено бордово устройство трябва да е 
определен от неговия производител, като се имат 
предвид изискванията за сигурност във връзка с 
използвания хардуер, с максимална стойност 240 
команди и съответни отговори на сесия за защитен 
обмен на съобщения.  ▼M1
 02016R0799 — BG — 21.08.2023 — 003.001 — 487  
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 — 21.08.2023 — 003.001 — 488  
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 — 21.08.2023 — 003.001 — 489  
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 — 21.08.2023 — 003.001 — 490  
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 — 21.08.2023 — 003.001 — 491  
Фигура  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 — 21.08.2023 — 003.001 — 492  
Забележка : читателите на настоящата глава следва да са 
запознати със съдържанието на [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 — 21.08.2023 — 003.001 — 493  
като тази, която то е изпратило на датчика за движение 
при предишната стъпка. Ако е така, това доказва че 
датчикът за движение е използвал същия ключ 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 — 21.08.2023 — 003.001 — 494  
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  1 6  1 6  1 6  
11 Отговор  Данни за удостове­ 
ряване на автентич­ 
ността + съдържание 
на файла  16 или 32, зависи 
от файла  16 или 32, зависи 
от файла  32 / 48  32 / 48  32 / 48  
41 Заявка  Сериен номер на 
MoS  8 8  1 6  1 6  1 6  
41 Отговор  Ключ за сдвояване  1 6  16 / 24 / 32  1 6  3 2  3 2  
42 Заявка  Сесиен ключ  1 6  16 / 24 / 32  1 6  3 2  3 2  
43 Заявка  Информация за 
сдвояване  24 2 4  3 2  3 2  3 2  
50 Отговор  Информация за 
сдвояване  24 2 4  3 2  3 2  3 2  
70 Заявка  Данни за удостове­ 
ряване на автентич­ 
ността  8 8  1 6  1 6  1 6  
80 Отговор  Стойност на брояча 
на MoS + данни за 
удост. на автент.  8 8  1 6  1 6  1 6  
▼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 — 21.08.2023 — 003.001 — 495  
— В случай, че ключът за сдвояване 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 parameter)  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 — 21.08.2023 — 003.001 — 496  
— Не е възможно да се използва карта за монтаж и 
настройки от първо поколение за куплиране към 
датчик за движение на бордово устройство от второ 
поколение.  
13. СИГУРНОСТ ПРИ ВРЪЗКА ОТ РАЗСТОЯНИЕ ПО DSRC  
13.1.  Общи  положения  
Както е специфицирано в допълнение 14, бордовото устройство 
редовно генерира данни за дистанционен мониторинг на тахографа 
(Remote Tachograph Monitoring — RTM) и изпраща тези данни на 
(вътрешно или външно) устройство за връзка от разстояние (Remot e 
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 — 21.08.2023 — 003.001 — 497  
13.2.  Криптиране  на полезните  тахографски  данни  и генериране  на 
MAC  
CSM_226 При даден елемент от данни в открит текст от типа
  
, както е описан в допълнение 
14, съответното бордово устройство трябва да криптира 
тези данни, както е показано на фигура 12: криптиращият 
DSRC ключ на бордовото устройство K_VU  DSRC  _ENC 
(вж. раздел 9.2.2) трябва да бъде използван с AES в 
работен режим на свързване на блокове шифровани 
данни (CBC), както е дефиниран в [ISO 10116], с 
параметър на редуване (interleave parameter)  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 — 21.08.2023 — 003.001 — 498  
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 — 21.08.2023 — 003.001 — 499  
— В случай на изтегляне на данни от бордово устройство:  
— Сертификата 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 — 21.08.2023 — 003.001 — 500  
— 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 — 21.08.2023 — 003.001 — 501  
Фигура  13 
Протокол  за проверка  на подписа  върху  изтеглен  файл  с данни
  ▼M1
 02016R0799 — BG — 21.08.2023 — 003.001 — 502  
Допълнение  12 
ОПРЕДЕЛЯНЕ  НА МЕСТОПОЛОЖЕНИЕТО  ВЪЗ  ОСНОВА  НА 
ГЛОБАЛНА  НАВИГАЦИОННА  СПЪТНИКОВА  СИСТЕМА  (GNSS)  
СЪДЪРЖАНИЕ  
1. ВЪВЕДЕНИЕ  
1.1. Обхват  
▼M3 
1.1.1 Препратки  
▼B 
1.2. Съкращения и означения  
▼M3 
2. ОСНОВНИ ХАРАКТЕРИСТИКИ НА ПРИЕМНИКА НА СИГНАЛИ 
ОТ GNSS  
3. ИЗРЕЧЕНИЯ, ПРЕДОСТАВЯНИ ОТ ПРИЕМНИКА НА СИГНАЛИ 
ОТ GNSS  
▼B 
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  
▼M3 
4.2.4 Структура на командата WriteRecord  
4.2.5 Други команди  
▼B 
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. Конфигурация  
▼M3 
5.2. Прехвърляне на информация от приемника на сигнали от GNSS към 
бордовото устройство  
__________  
5.3. Прехвърляне на информация от бордовото устройство към 
приемника на сигнали от GNSS  
5.4. Обработване на грешки  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 503  
5.4.1 Липса на информация за местоположението от приемник на си гнали 
от GNSS  
6. ОБРАБОТКА И ЗАПИСВАНЕ ОТ БОРОДОВОТО УСТРОЙСТВО 
НА ДАННИ ЗА МЕСТОПОЛОЖЕНИЕТО  
7. ПРОТИВОРЕЧИЕ С ВРЕМЕТО В ДАННИТЕ ОТ GNSS  
8. ПРОТИВОРЕЧИЕ В ДАННИТЕ ЗА ДВИЖЕНИЕТО НА 
ПРЕВОЗНОТО СРЕДСТВО  
1. ВЪВЕДЕНИЕ  
В настоящото допълнение са описани техническите изисквания за 
приемника на сигнали от GNSS и данните от GNSS, използвани от 
бордовото устройство, включително протоколите, които трябва да 
бъдат приложени за обезпечаване на сигурно и правилно 
прехвърляне на данни за местоположението.  
1.1. Обхват  
GNS_1 Бордовото устройство трябва да събира данни за местопо­ 
ложението от поне една спъникова мрежа за GNSS.  
Бордовото устройство може да бъде със или без външно 
устройство за GNSS, както е описано на фигура 1:  
1.1.1  Справочни  материали  
В настоящото допълнение се използват позовавания на следните 
справочни документи:  
NMEA NMEA (Национална асоциация за морска електроника) 0183 
Стандарт за интерфейси, V4.11.  
▼B 
Фигура  1 
Различни  конфигурации  за разположението  на приемника  на сигнали  от GNSS.
  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 504  
1.2. Съкращения  и означения  
В настоящото допълнение се използват следните съкращения:  
DOP Намаление на точността при определяне на местополо­ 
жението  
EGF Елементарен файл на устройството за GNSS  
EGNOS Европейска геостационарна служба за навигационно 
покритие  
GNSS Глобална навигационна спътникова система  
GSA DOP и активни спътници на GPS  
HDOP Хоризонтално намаление на точността при определяне на 
местоположението  
ICD Документ за управление на интерфейса  
NMEA National Marine Electronics Association (Национална 
асоциация за морска електроника, САЩ)  
▼M3 
OSNMA Galileo Open Service Navigation Message Authentication 
(Удостоверяване на автентичността на навигационните 
съобщения от отворената услуга на „Галилео“)  
▼B 
PDOP Position Dilution of Precision (позиционно намаление на 
точността при определяне на местоположението)  
RMC Recommended Minimum Specific (препоръчан минимум от 
специфични [GNSS данни])  
▼M3 
RTC Real Time Clock (Часовник за реално време)  
▼B 
SIS Signal in Space (сигнал от геонавигационни спътници)  
VDOP Вертикално намаление на точността при определяне на 
местоположението  
VU Бордово устройство  
▼M3 
2. ОСНОВНИ ХАРАКТЕРИСТИКИ НА ПРИЕМНИКА НА СИГНАЛИ 
ОТ GNSS  
▼B 
Независимо дали конфигурацията на интелигентния тахограф е със 
или без външно GNSS устройство, осигуряването на точна и 
надеждна информация за местоположението е съществен елемент 
от функционирането на интелигентния тахограф. Следователно е 
целесъобразно да има изискване за съвместимост с услугите, пред ­ 
оставяни по програмата „Галилео“ и програмата за Европейската 
геостационарна служба за навигационно покритие (EGNOS), 
определени в Регламент (ЕС) № 1285/2013 на Европейския 
парламент и на Съвета (  1 ). Системата, създадена в рамките на 
програмата „Галилео“, е независима глобална спътникова навига­ 
ционна система, а системата, създадена в рамките на програмата 
EGNOS, е регионална спътникова навигационна система за подоб­ 
ряване на качеството на сигнала на Глобалната система за 
позициониране (GPS).  
GNS_2 Производителите трябва да осигуряват съвместимост на 
приемниците на сигнали от GNSS с услугите за определяне 
на местоположението, предоставяни от системите 
„Галилео“ и EGNOS. Също така, производителите могат 
допълнително да изберат да има съвместимост и с други 
навигационни спътникови системи.  ▼B 
( 1 ) Регламент (ЕС) № 1285/2013 на Европейския парламент и на Съве та от 11 декември 
2013 г. за изграждане и експлоатация на европейските навигацион ни спътникови 
системи и за отмяна на Регламент (ЕО) № 876/2002 на Съвета и на  Регламент (ЕО) 
№ 683/2008 на Европейския парламент и на Съвета (ОВ L 347, 20.1 2.2013 г., 
стр. 1).
 02016R0799 — BG — 21.08.2023 — 003.001 — 505  
GNS_3 Приемникът на сигнали от GNSS трябва да поддържа удос­ 
товеряването на автентичността на навигационните 
съобщения от отворената услуга на „Галилео“ (OSNMA).  
GNS_3a Приемникът на сигнали от GNSS трябва да извърши 
редица проверки за съответствие, за да провери дали 
измерванията, изчислени от приемника на сигнали от 
GNSS въз основа на данните от OSNMA, са довели до 
точна информация за местоположението, скоростта и 
данните на превозното средство и следователно не са 
били повлияни от външна атака, като например повторно 
излъчване на записан сигнал с цел объркване. Тези 
проверки за съответствие се състоят например от:  
— откриване на емисии с необичайна мощност пост­ 
редством комбинирано следене на автоматичното регу­ 
лиране на усилването (AGC) и отношението 
сигнал/шум за мощностите на носещия сигнал и шума 
(C/N0),  
— последователност при измерване на псевдоразстояние и 
последователност при измерването на доплеровия ефект 
във времето, включително откриването на резки 
скокове в измерванията,  
— техники за автономно следене на работоспособността 
от приемника (RAIM), включително откриване на 
измервания, несъвместими с предполагаемото местопо­ 
ложение,  
— проверки на местоположението и скоростта, вклю­ 
чително необичайни решения за местоположението и 
скоростта, внезапни скокове и поведение, което не 
съответстват на динамиката на превозното средство,  
— съгласуваност на времето и честотата, включително 
скокове и отклонения на часовника, които не са 
съвместими на характеристиките на часовника на 
приемника.  
GNS_3b Европейската комисия трябва да разработи и одобри 
следните документи:  
— Документ за контрол на интерфейса за космическия 
сигнал (SIS ICD), в който подробно се описва инфор­ 
мацията за OSNMA, предавана в сигнала на „Галилео“.  
— Насоки за приемника за OSNMA, в които се посочват 
изискванията и процесите в приемниците, за да се 
гарантира сигурното прилагане на OSNMA, както и 
препоръки за подобряване на работата на OSNMA.  
Приемниците на сигнали от GNSS, монтирани в тахографи, 
както вътрешни, така и външни, се конструират в съот­ 
ветствие с SIS ICD и насоките за приемника за OSNMA.  
GNS_3c Приемникът на сигнали от GNSS трябва да предоставя 
съобщения за местоположение, наричани в настоящото 
приложение и неговите допълнения „съобщения за место­ 
положението с удостоверена автентичност“, които са 
изготвени само с използването на спътници, за които 
автентичността на навигационните съобщения е била 
успешно проверена.  
GNS_3d Приемникът на сигнали от GNSS трябва също така да 
предоставя стандартни съобщения за местоположението, 
изготвени с използване на видимите спътници, независимо 
от това дали автентичността им е удостоверена или не.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 506  
GNS_3e  Приемникът за GNSS трябва да използва часовникът за реално 
време (RTC) на бордовото устройство като времеви еталон за 
синхронизацията на времето, необходима за OSNMA.  
GNS_3f Времето по RTC на бордовото устройство се предоставя на 
приемника за GNSS от бордовото устройство.  
GNS_3g Образецът за максималната неточност на времето в 
изискване 41 от приложение IВ се предоставя на 
приемника на сигнали от GNSS от бордовото устройство, 
заедно с времето от RTC на бордовото устройство.  
3. ИЗРЕЧЕНИЯ, ПРЕДОСТАВЯНИ ОТ ПРИЕМНИКА НА СИГНАЛИ 
ОТ GNSS  
В този раздел са описани изреченията, използвани при функциони­  
рането на интелигентния тахограф, за предаване на стандартни и 
съобщения за местоположение, чиято автентичност е удостоверена.  
Посоченото в настоящия раздел е валидно и за двата вида конфи­ 
гурации на интелигентните тахографи — със или без външно 
устройство за GNSS.  
GNS_4 Стандартните данни за местоположението се базират на 
изречението на NMEA Recommended Minimum Specific 
(RMC) GNSS Data (препоръчан минимум от специфични 
GNSS данни), което обхваща информацията за местополо­ 
жението (географска ширина и дължина), за времето във 
формат UTC (hhmmss.ss) и за скоростта спрямо земната 
повърхност във възли, плюс допълнителни величини.  
Форматът на изречението RMC е както следва (съгласно 
стандарта на NMEA V4.11):  
Фигура  2 
Структура  на изречение  RMC
  
$–RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x .x,xxxx,x.x,a,a,a* hh 
1) Час (UTC):  
2) Статус, A= валидно местоположение, V= предупреждение  
3) Географска ширина  
4) С.Ш. или Ю.Ш.  
5) Географска дължина  
6) И.Д. или З.Д.  
7) Скорост спрямо земната повърхност във възли  
8) Линия на действителния път, градуси спрямо истинския меридиа н 
9) Дата, ddmmyy  
10) Магнитно отклонение, градуси  
11) И.Д. или З.Д.  
12) Индикатор на режима на FAA  
13) Навигационен статус  
14) Контролна сума  
Навигационният статус не е задължителен и може да не 
присъства в изречението RMC.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 507  
Статусът показва дали има наличен GNSS сигнал. Докато 
стойността за статуса не стане „A“, получените данни 
(например за времето или за географската ширина/дължина) 
не могат да се използват за записване в бордовото 
устройство на местоположението на превозното средство.  
Разделителната способност за местоположението се базира 
на формата на гореописаното изречение RMC. Първата 
част от полета 3) и 5) се използва за посочване на 
градусите. Останалото пространство се използва за 
посочване на минутите с три десетични знака. След­ 
ователно разделителната способност е 1/1 000 от 
минутата или 1/60 000 от градуса (защото 1 минута е 
1/60 от градуса).  
GNS_4a Данните за местоположението с удостоверена автен­ 
тичност се базират на изречение като това на NMEA, 
Authenticated Minimum Specific (AMC) Data (минимални 
специфични данни с удостоверена автентичност), което 
обхваща информацията за местоположението (географска 
ширина и дължина), за времето във формат UTC 
(hhmmss.ss) и за скоростта спрямо земната повърхност 
във възли, плюс допълнителни величини.  
Форматът на изречението AMC е както следва (съгласно 
стандарта на NMEA V4.11, освен за стойност номер 2):  
Фигура  3 
Структура  на изречение  AMC
  
$–AMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*h h 
1) Час (UTC):  
2) Статус, A= местоположение с удостверена автентичност (устано вено с 
използване най-малко на 4 спътника, чиято автентичност на съоб­  
щенията за местоположението е проверена успешно), J=заглушаване  
или O=друга атака срещу GNSS при липса на неуспешно удостове­ 
ряване на автентичността на навигационните съобщения (чрез 
извършени проверки за съответствие съгласно GNS_3а), F = 
неуспешно удостоверяване на автентичността на навигационните 
съобщения (открита при проверките на OSNMA, описани в доку­ 
ментите, посочени в GNS_3б), V=празно (по някаква друга причина  
няма местоположение с удостоверена автентичност)  
3) Географска ширина  
4) С.Ш. или Ю.Ш.  
5) Географска дължина  
6) И.Д. или З.Д.  
7) Скорост спрямо земната повърхност във възли  
8) Линия на действителния път, градуси спрямо истинския меридиа н 
9) Дата, ddmmyy  
10) Магнитно отклонение, градуси  
11) И.Д. или З.Д.  
12) Индикатор на режима на FAA  
13) Навигационен статус  
14) Контролна сума  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 508  
Навигационният статус не е задължителен и може да не 
присъства в изречението AMC.  
Статусът указва дали дадено местоположение по GNSS с удос­ 
товерена автентичност е налично, дали е била открита атака 
срещу сигналите от GNSS, дали удостоверяването на автентич­ 
ността на навигационните е неуспешно или дали местополо­ 
жението по GNSS е празно. Когато стойността за статуса не е 
„А“, за получените данни (например времето или географската 
ширина/дължина), се счита, че не са празни и не могат да се 
използват за записване в бордовото устройство на местополо­ 
жението на превозното средство. Когато стойността на статуса 
е „J“ (заглушаване), „O“ (друга атака срещу GNSS) или „F“ 
(неуспешно удостоверяване на автентичността на навигаци­ 
онните съобщения), в бордовото устройство се записва 
събитие за аномалия на GNSS, както е определено в 
приложение IB и допълнение 1 (EventFaultCode).  
GNS_5 Бордовото устройство трябва да съхранява в своята база 
данни позиционната информация за географска ширина и 
дължина с разделителна способност 1/10 от минутата или 
1/600 от градуса, както е описано в допълнение 1 за типа 
данни „географски координати“.  
За определяне и записване на наличието на сигнал и точността 
на стандартните местоположения бордовото устройство може 
да използва командата за DOP и активните спътници на GPS 
(командата GSA) от стандарта NMEA V4.11. По-специално, 
стойността на HDOP се използва като показател за степента 
на точност на записаните данни за местоположението (вж. 
4.2.2). Бордовото устройство трябва да съхранява стойността 
на хоризонталното намаление на точността при определяне на 
местоположението (HDOP), изчислена като минималната 
измежду стойностите на HDOP, получени от наличните 
системи за GNSS.  
Идентификаторът на системата за GNSS посочва съответния 
идентификатор на NMEA за всяка група спътници на GNSS 
и за спътниковата система за диференциална корекция 
(Satellite- Based Augmentation System, SBAS).  
Фигура  4 
Структура  на изречение  GSA (стандартни  местоположения )
 
$–GSA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*h h  
1) Режим на селекция  
2) Режим  
3) Идентификатор на 1-ия спътник, използван за фиксиране  
4) Идентификатор на 2-ия спътник, използван за фиксиране  
… 
14) Идентификатор на 12-ия спътник, използван за фиксиране  
15) PDOP  
16) HDOP  
17) VDOP  
18) Идентификатор на системата  
19) Контролна сума  
Идентификаторът на системата не е задължителен и може 
да не присъства в изречението GSA.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 509  
По подобен начин, за определяне и записване на 
наличието на сигнал и точността на местоположенията с 
удостоверена автентичност бордовото устройство може да 
използва командата за изречение като това на NMEA за 
удостоверяване на автентичността на активните спътници 
(командата ASA). Стойностите от 1 до 18 са определени в 
стандарт NMEA V4.11.  
Фигура  5 
Структура  на изречението  ASA (местоположения  с удостоверена  автентичност )
 
$–ASA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*h h  
1) Режим на селекция  
2) Режим  
3) Идентификатор на 1-ия спътник, използван за фиксиране  
4) Идентификатор на 2-ия спътник, използван за фиксиране  
… 
14) Идентификатор на 12-ия спътник, използван за фиксиране  
15) PDOP  
16) HDOP  
17) VDOP  
18) Идентификатор на системата  
19) Контролна сума  
Идентификаторът на системата не е задължителен и може 
да не присъства в изречението ASA.  
GNS_6 Когато се използва външно устройство за GNSS, изре­ 
чението  GSA  трябва да се съхранява в защитения GNSS 
приемопредавател с номер на записа от „02“ до „06“, а 
изречението ASA се съхранява с номер на записа от „12“ 
до „16“.  
GNS_7 Максималният размер на изреченията (напр. RMC, AMC, 
GSA, ASA или други), който може да бъде използван за 
оразмеряване на командата „read record“, е 85 байта (вж. 
таблица 1)  
▼B 
4. БОРДОВО УСТРОЙСТВО С ВЪНШНО УСТРОЙСТВО ЗА GNSS  
4.1. Конфигурация  
4.1.1  Основни  компоненти  и интерфейси  
При тази конфигурация приемникът на сигнали от GNSS е част от 
външното устройство за GNSS.  
GNS_8 Външното устройство за GNSS трябва да бъде 
захранвано чрез специфичен интерфейс на превозното 
средство.  
▼M3 
GNS_9 Външното устройство за GNSS трябва да се състои от 
следните компоненти (вж. фигура 6):  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 510  
а) Предлаган на пазара приемник на сигнали от GNSS за 
осигуряване на данни за местоположението чрез 
интерфейс за данни от GNSS. Например, интерфейсът 
за данни от GNSS може да бъде по стандарт V4.11 на 
NMEA, където GNSS приемникът действа като 
източник на съобщения (talker) и предава изречения 
на NMEA на защитен GNSS приемопредавател с 
честота 1 Hz за предварително дефинирания набор от 
изречения на NMEA и подобни на изречения на NMEA 
, който трябва да съдържа поне изреченията RMC, 
AMC, GSA и ASA. Начинът на изпълнение на 
интерфейса за данни от GNSS се избира от производи­ 
телите на външни устройства за GNSS.  
▼B 
б) приемопредавателен модул (защитен GNSS приемо­ 
предавател) със способност да поддържа стандарт 
ISO/IEC 7816-4:2013 (вж. 4.2.1) за да комуникира с 
бордовото устройство, както и да поддържа интерфейса 
за данни от GNSS към приемника на сигнали от GNSS. 
Модулът разполага с памет за съхранение на иденти­ 
фикационните данни на приемника на сигнали от 
GNSS и на външното устройство за GNSS.  
▼M3 
в) Ограждаща система с функция за откриване на вмеша­ 
телство (tamper detection function), която капсулира 
както приемника на сигнали от GNSS, така и 
защитения GNSS приемопредавател. Функцията за 
откриване на вмешателство трябва да изпълнява 
защитните мерки за сигурност, в съответствие с изиск­ 
ванията на защитния профил на интелигентния 
тахограф.  
▼B 
г) GNSS антена, инсталирана върху превозното 
средство и свързана с приемника на сигнали от 
GNSS през ограждащата система.  
GNS_10 Външното устройство за GNSS разполага поне със 
следните външни интерфейси:  
а) Интерфейс към GNSS антената, инсталирана върху 
корпуса на превозното средство, ако се използва 
външна антена.  
б) Интерфейс към бордовото устройство.  
GNS_11 Намиращият се в бордовото устройство защитен 
приемопредавател (трансивер) на бордовото устройство 
представлява другият край на защитената връзка със 
защитения GNSS приемопредавател и той трябва да 
поддържа стандарта ISO/IEC 7816-4:2013 за връзката 
към външното устройство за GNSS.  
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,  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 511  
— ако съществува, сертификата EUR, чийто период на 
валидност непосредствено предшества този 
сертификат EUR, който се използва за проверяване 
на сертификата MSCA_VU-EGF,  
— ако съществува, свързващия сертификат, който дава 
връзка между тези два сертификата EUR,  
— разширения сериен номер на външното устройство 
за GNSS,  
— идентификатора на операционната система на 
устройството за GNSS,  
— номера на одобрението на типа на външното 
устройство за GNSS,  
— идентификатор на компонента за сигурност на 
външното устройство за GNSS.  
4.2. Връзка  между  външното  устройство  за GNSS и бордовото  
устройство  
4.2.1  Протокол  за връзка  
▼M3 
GNS_14 Протоколът за връзка между външното устройство за 
GNSS и бордовото устройство трябва да поддържа 
следните функции:  
1. Събиране и разпределяне на GNSS данни (например 
за местоположението, времето, скоростта),  
2. Събиране на конфигурационните данни за външното 
устройство за GNSS,  
3. Протокола за управление, който да поддържа купли­ 
рането, взаимното удостоверяване на автентичността 
и договарянето на сесийните ключове между 
външното устройство за GNSS и бордовото 
устройство,  
4. Предаването към външното устройство за GNSS на 
времето RTC на бордовото устройство и на макси­ 
малната разлика между действителното време и 
времето RTC на бордовото устройство.  
▼B 
GNS_15 Протоколът за връзка трябва да се базира на стандарта 
ISO/IEC 7816-4:2013, като защитеният приемопред­ 
авател на бордовото устройство играе ролята на 
главно устройство, а защитеният приемопредавател за 
GNSS играе ролята на подчинено устройство. Физи­ 
ческата връзка между външното устройство за GNSS 
и бордовото устройство се базира на стандарта 
ISO/IEC 7816-12:2005 или друг стандарт, който може 
да поддържа ISO/IEC 7816-4:2013.  
▼M1 
GNS_16 В протокола за връзка не трябва да се поддържат полета 
с увеличена дължина.  
▼B 
GNS_17 Протоколът за връзка по стандартите ISO 7816 
(съответно *-4:2013 и *-12:2005) между външното 
устройство за GNSS и бордовото устройство трябва да 
бъде зададен с T=1.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 512  
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.  
▼M3 
GNS_18a Във връзка с функция 4) предаването към външното 
устройство за GNSS на времето RTC на бордовото 
устройство и на максималната разлика между действи­ 
телното време и времето RTC на бордовото устройство, 
защитеният GNSS приемопредавател трябва да използва 
EF (EF VU) в същия DF с идентификатор на файла, 
равен на „2F30“, както е описан в таблица 1.  
▼B 
GNS_19 Защитеният GNSS приемопредавател трябва да 
съхранява във файла EF.EGF данните, идващи от 
приемника на сигнали от GNSS, и конфигурацията. 
Този файл представлява линеен файл с променлива 
дължина и е с идентификатор равен на „2F2F“ в шест­ 
надесетичен формат.  
▼M3 
GNS_19a Защитеният GNSS приемопредавател трябва да 
съхранява във файла EF.EGF данните, идващи от 
приемника на сигнали от GNSS, и конфигурацията. 
Този файл за запис представлява линеен файл с 
фиксирана дължина и е с идентификатор равен на 
„2F30“ в шестнайсетичен формат.  
GNS_20 Защитеният GNSS приемопредавател използва памет за 
съхранение на данните и трябва да може да изпълнява 
толкова цикли за четене/вписване, колкото са необ­ 
ходими в продължение най-малко на 15 години. С 
изключение на този аспект, вътрешната конструкция и 
изпълнението на защитения GNSS приемопредавател е 
по усмотрение на производителите.  
▼M1 
Разпределянето на номерата на записите и данните в 
паметта е дадено в таблица 1. Отбележете, че 
съществуват пет изречения GSA за GNSS и за спътни­ 
ковата система за диференциална корекция (SBAS).  
▼B 
GNS_21 Файловата структура е дадена в Table 1. По отношение 
на условията за достъп (ALW, NEV, SM-MAC) вж. 
допълнение 2, глава 3.5.  
▼M3 
Таблица  1 
Файлова  структура  
Условия за достъп  
Файл  Иденти­ 
фикатор на 
файла  Четене  Актуализация  Криптиран  
MF 3F00  
EF.ICC  0002  ALW  NEV 
(от VU)  Не ▼M1
 02016R0799 — BG — 21.08.2023 — 003.001 — 513  
Условия за достъп  
Файл  Иденти­ 
фикатор на 
файла  Четене  Актуализация  Криптиран  
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)  Не 
EF VU  2F30  SM-MAC  SM-MAC  Н е  
Файл / елемент от данни  Номер на 
записа  Размер (байтове)  Стойности 
по подраз­ 
биране  
Мин.  Макс.  
MF 552  1031  
EF.ICC  
sensorGNSSSerialNumber  8  8  
DF GNSS Facility  612  1023  
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'  8 5  8 5  
1-во изречение GSA NMEA  „02“  8 5  8 5  
2-ро изречение GSA NMEA  '03'  8 5  8 5  
3-то изречение GSA NMEA  '04'  8 5  8 5  
4-то изречение GSA NMEA  '05'  8 5  8 5  
5-о изречение GSA NMEA  '06'  8 5  8 5  
Разширен сериен номер на 
външното устройство за GNSS, 
дефиниран в допълнение 1 като 
SensorGNSSSerialNumber.  '07' 8  8  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 514  
Файл / елемент от данни  Номер на 
записа  Размер (байтове)  Стойности 
по подраз­ 
биране  
Идентификатор на операционната 
система на защитения приемопред­ 
авател за GNSS, дефиниран в 
допълнение 1 като SensorOSIden­
tifier.  '08' 2  2  
Номер на одобрението на типа на 
външното устройство за GNSS, 
дефиниран в допълнение 1 като 
SensorExternalGNSSApproval­
Number.  '09' 1 6  1 6  
Идентификатор на компонента за 
сигурност на външното устройство 
за GNSS, дефиниран в допълнение 
1 като SensorExternalGNSSSCIden­
tifier  '10' 8  8  
AMC изречение  '11'  8 5  8 5  
1-во ASA изречение  '12'  8 5  8 5  
2-ро ASA изречение  '13'  8 5  8 5  
3-то ASA изречение  '14'  8 5  8 5  
4-то ASA изречение  '15'  8 5  8 5  
5-о ASA изречение  '16'  8 5  8 5  
RFU — Запазен за бъдещо използване  От '17' до 
'FD' 
EF VU  
VuRtcTime (вж. допълнение 1)  '01'  4  4  {00..00}  
VuGnssMaximalTimeDifference (вж. 
допълнение 1)  '02' 2  2  {00..00}  
▼B 
4.2.2  Защитено  прехвърляне  на данни  от GNSS  
▼M3 
GNS_22 Защитеното предаване на данни за местоположението 
по GNSS, времето RTC на бордовото устройство и 
максималната разлика между действителното време и 
времето RTC на бордовото устройство е разрешено 
само при следните условия:  
▼B 
1. Завършен процес на куплиране, както е описано в 
допълнение 11. Общи механизми за сигурност.  
2. Периодично взаимно удостоверяване на автентич­ 
ността и договаряне на сесийни ключове между 
бордовото устройство и външното устройство за 
GNSS, също описано в допълнение 11. Общите 
механизми за сигурност трябва да са изпълнени с 
посочената периодичност.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 515  
GNS_23 На всеки T секунди, където T е стойност по-малка или 
равна на 20, освен когато се провежда куплиране или 
взаимно удостоверяване на автентичността и дого­ 
варяне на сесийни ключове, бордовото устройство 
иска от външното устройство за GNSS информацията 
за местоположението въз основа на следния поток от 
данни:  
1. Бордовото устройство иска от външното устройство 
за GNSS данни за местоположението, заедно с данни 
за намалението на точността (от изреченията GSA и 
ASA). Защитеният приемопредавател на бордовото 
устройство използва командите SELECT (селекция) 
и READ RECORD(S) (прочети запис(и) по ISO/IEC 
7816-4:2013 при защитен обмен на съобщения в 
режим „само с удостоверяване на автентичността“ 
(authentication-only mode), както е описано в раздел 
11.5 от допълнение 11, с идентификатор на файла 
„2F2F“ и номер на RECORD (записа), равен на 
„01“ за изречение RMC NMEA, „02“, „03“, „04“, 
„05“, „06“ за изречение GSA NMEA, „11“ за 
изречение AMC и „12“, „13“, „14“, „15“, „16“ за 
изречение ASA.  
2. Последната получена информация за местополо­ 
жението се съхранява в елементарния файл с иден­ 
тификатор „2F2F“ и в записите в защитения GNSS 
приемопредавател, описани в таблица 1, като защи­ 
теният GNSS приемопредавател получава NMEA 
данни с честота поне 1 Hz от GNSS приемника 
посредством интерфейса за GNSS данни.  
3. Защитеният GNSS приемопредавател изпраща 
отговора до защитения приемопредавател на 
бордовото устройство като използва ответно APDU 
съобщение при защитен обмен на съобщения в 
режим „само с удостоверяване на автентичността“, 
както е описано в раздел 11.5 от допълнение 11.  
4. Защитеният приемопредавател на бордовото 
устройство проверява автентичността и целостта на 
получения отговор. При положителен резултат от 
тази проверка данните за местоположението се 
прехвърлят в процесора на бордовото устройство 
посредством интерфейса за GNSS данни.  
5. Процесорът на бордовото устройство проверява 
получените данни и извлича информация (например 
географска ширина, географска дължина, време) от 
изречението RMC NMEA. Изречението RMC 
NMEA включва информация дали местоположението 
с неудостоверена автентичност е валидно. Ако 
местоположението с неудостоверена автентичност е 
валидно, процесорът на бордовото устройство 
извлича от изреченията GSA NMEA и стойностите 
на хоризонталното намаление на точността (HDOP) 
и изчислява средната стойност по наличните спът­ 
никови системи (т.е. когато има налично фиксиране).  
6. Процесорът на бордовото устройство също така 
извлича информация (например географска ширина, 
географска дължина, време) от изречението AMC 
NMEA. Изречението AMC включва информацията, 
ако местоположението с удостоверена автентичност 
не е валидно или сигналът от GNSS е бил атакуван. 
Ако местоположението е валидно, процесорът на 
бордовото устройство извлича от изреченията ASA 
и стойностите на HDOP и изчислява средната 
стойност по наличните спътникови системи (т.е. 
когато има налично фиксиране).“;  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 516  
GNS_23a Бордовото устройство изписва времето RTC на 
бордовото устройство и максималната разлика между 
действителното време и времето RTC на бордовото 
устройство, както е необходимо, като използва 
командите от ISO/IEC 7816-4:2013 SELECT (селекция) 
и WRITE RECORD(S) (вписване на запис(и) в режим 
само на удостоверяване на автентичността на 
защитения обмен на съобщения, както е описано в 
раздел 11.5 от допълнение 11, с идентификатор на 
файл „2F30“ и номер на RECORD (записа), равен на 
„01“ за VuRtccTime и „02“ за MaximalTimeDifference.  
▼B 
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 “ (неразрешена команда).  
▼M3 
— Ако записът не е намерен, защитеният GNSS 
приемопредавател отговаря с „6A83“.  
— Ако външното устройство за GNSS открие вмеша­ 
телство, то трябва да отговори с израза за статус 
„6690“  
__________  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 517  
4.2.4  Структура  на командата  WriteRecord  
В настоящия раздел е описана подробно структурата на командата 
Write Record (вписване на запис). Добавя се защитен обмен на 
съобщения (в режим само с удостоверяване на автентичността), 
както е описан в допълнение 11 „Общи механизми за сигурност“.  
GNS_26a Командата трябва да поддържа защитен обмен на 
съобщения (в режим само с удостоверяване на автен­ 
тичността), вж. допълнение 11.  
GNS_26b Командно съобщение  
Байт  Дължи­ 
на Стойност  Описание  
CLA  1  „0Ch“  Поискан е защитен обмен на 
съобщения.  
INS 1  „D2h“  Вписване на запис  
P1 1  „XXh“  Номер на записа (номерът '00' е на 
текущия запис)  
P2 1  „04h“  Вписване на записа с посочения в P1 
номер.  
Данни  X  „XXh“  Данни  
GNS_26c Посоченият в P1 запис става текущ запис.  
Байт  Дължи­ 
на Стойност  Описание  
SW 2  „XXXXh“  Байтове за състоянието (SW1, SW2)  
— Ако командата бъде изпълнена успешно, защи­ 
теният GNSS приемопредавател отговаря с „ 9000 “. 
— Ако текущият файл не е предназначен за записи, 
защитеният GNSS приемопредавател отговаря с 
„6981 “. 
— Ако командата се използва с P1 = '00' но няма 
текущ елементарен файл, защитеният GNSS 
приемопредавател отговаря с ' 6986 ' (неразрешена 
команда).  
— Ако записът не е намерен, защитеният GNSS 
приемопредавател отговаря с „ 6A83 “. 
— Ако външното устройство за GNSS открие вмеша­ 
телство, то трябва да отговори с израза за статус 
„6690 “. 
4.2.5 Други команди  
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  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 518  
4.3. Куплиране , взаимно  удостоверяване  на автентичността  и 
договаряне  на сесийни  ключове  на външното  устройство  за 
GNSS с бордовото  устройство  
Куплирането, взаимно удостоверяване на автентичността и дого­ 
варянето на сесийни ключове на външното устройство за GNSS с 
бордовото устройство са описани в допълнение 11 „Общи 
механизми за сигурност“, глава 11.  
4.4. Третиране  на грешки  
В настоящия раздел е описано как се третират и записват в 
бордовото устройство потенциалните състояния на грешка от 
страна на външното устройство за GNSS.  
4.4.1  Грешка  във връзката  с външното  устройство  за GNSS  
▼M3 
GNS_28  Събитието за грешка в комуникацията с външното 
устройство за GNSS се записва в бордовото устройство, 
както е определено в изискване 82 от приложение IB и в 
допълнение 1 (EventFaultType). В този контекст регистри­ 
рането на грешка във връзката се задейства, когато защи­ 
теният приемопредавател на бордовото устройство не 
получи съобщение-отговор, след изпращането на 
съобщение със заявка, както е описано в 4.2.  
▼B 
4.4.2  Нарушение  на физическата  цялост  на външното  устройство  за 
GNSS  
▼M3 
GNS_29  Ако сигурността на външното устройство за GNSS бъде 
нарушена, защитеният GNSS приемопредавател трябва да 
осигури неналичието на криптографския материал. Както 
е описано в GNS_25 и GNS_26, бордовото устройство 
трябва да констатира наличие на вмешателство, ако 
отговорът е със статус „6690“. След това бордовото 
устройство трябва да генерира и регистрира събитие, 
свързано с опит за нарушаване на сигурността, както е 
определено в изискване 85 от приложение IB и в 
допълнение 1 (EventFaultType за откриване на вмеша­ 
телство в GNSS). Като алтернатива, външното устройство 
за GNSS може да отговори на заявките на VU с 
незащитен обмен на информация и със статус „6A88“.  
▼B 
4.4.3  Липса  на информация  за местоположението  от приемник  на 
сигнали  от GNSS  
▼M3 
GNS_30  Ако защитеният GNSS приемопредавател не получава 
данни от приемника на сигнали от GNSS, защитеният 
GNSS приемопредавател трябва да генерира съобщение- 
отговор на командата READ RECORD (прочети запис), с 
номер на RECORD (записа), равен на „01“, и с поле за 
данни от 12 байта, всички със стойност 0xFF. При полу­ 
чаване на съобщението за отговор с тази стойност в полето 
за данни, бордовото устройство генерира и записва липсата 
на информация за местоположението от приемника на 
сигнали от GNSS, както е определено в изисквания 81 от 
приложение IB и в допълнение 1 (EventFaultType).  
▼B 
4.4.4  Изтекъл  сертификат  на външното  устройство  за GNSS  
▼M3 
GNS_31  Ако бордовото устройство установи, че сертификатът EGF, 
използван за взаимно удостоверяване на автентичността, 
вече не е валиден, бордовото устройство трябва да 
генерира и регистрира събитие, свързано с опит за нару­ 
шаване на сигурността, както е определено в изискване 85 
от приложение IB и допълнение 1 (EventFaultType за изтекъл 
сертификат за външно GNSS устройство). При това 
бордовото устройство трябва да продължи да използва полу­ 
чаваните от GNSS данни за местоположението.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 519  
Фигура  6 
Схема  на външно  устройство  за GNSS  
▼B
 
5. БОРДОВО УСТРОЙСТВО БЕЗ ВЪНШНО УСТРОЙСТВО ЗА GNSS  
5.1. Конфигурация  
При този вид конфигурация приемникът за сигнали от GNSS е 
вътре в бордовото устройство, както е описано в Figure 1.  
▼M3 
GNS_32  За предаването на местоположението, DOP данните и спът­ 
ниците, приемникът на сигнали от GNSS действа като 
източник на съобщения (talker) и предава изречения на 
NMEA или подобни на изречения на NMEA на процесора 
на бордовото устройство, който действа като приемник 
(listener) с честота по-голяма или равна на 1/10 Hz на пред­ 
варително дефинирания набор от изречения, който трябва 
да съдържа поне изреченията RMC, GSA, AMC и ASA. 
Като алтернатива процесорът на бордовото устройство и 
вътрешният приемник на сигнали от GNSS могат да 
използват други формати на данни за обмен на данните, 
съдържащи се в изреченията, NMEA или като на NMEA, 
посочени в GNS_4, GNS_4a и GNS_5.  
▼B 
GNS_33 Към бордовото устройство се свързва външна GNSS 
антена, инсталирана върху превозното средство, или 
вътрешна GNSS антена.  
▼M3 
5.2. Прехвърляне  на информация  от приемника  на сигнали  от 
GNSS към бордовото  устройство  
GNS_34 Процесорът на бордовото устройство проверява полу­ 
чените данни, като извлича информацията (например 
географска ширина, географска дължина, време) от 
изречението RMC NMEA и изречението AMC.  
GNS_35  Изречението RMC NMEA включва информация дали 
местоположението с неудостоверена автентичност е 
валидно. Ако местоположението с неудостоверена автен­ 
тичност не е валидно, данните за местоположението не са 
достъпни и не могат да се използват за записване на место­ 
положението на превозното средство. Ако местополо­ 
жението с неудостоверена автентичност е валидно, 
процесорът на бордовото устройство извлича също така 
стойностите на HDOP от GSA NMEA.  
GNS_36  Процесорът на бордовото устройство извлича също така 
информацията (например географска ширина, географска 
дължина, време) от изречението AMC NMEA. Изречението 
AMC включва информацията, ако местоположението с 
неудостоверена автентичност е валидно съгласно GNS_4a. 
Ако местоположението с неудостоверена автентичност е 
валидно, процесорът на бордовото устройство извлича 
също така стойностите на HDOP от изреченията ASA.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 520  
5.3. Прехвърляне  на информация  от бордовото  устройство  към 
приемника  на сигнали  от GNSS  
GNS_37 Процесорът на бордовото устройство осигурява на 
приемника за GNSS времето RTC на бордовото 
устройство и максималната разлика между действи­ 
телното време и времето RTC на бордовото устройство 
в съответствие с GNS_3е и GNS_3ж.  
5.4. Обработване  на грешки  
5.4.1 Липса на информация за местоположението от приемник на 
сигнали от GNSS  
GNS_38 Бордовото устройство генерира и регистрира събитие 
за липсата на информация за местоположението от 
приемника на сигнали от GNSS, както е определено в 
изискване 81 от приложение IB и в допълнение 1 
(EventFaultType).  
6. ОБРАБОТКА И ЗАПИСВАНЕ ОТ БОРДОВОТО УСТРОЙСТВО 
НА ДАННИ ЗА МЕСТОПОЛОЖЕНИЕТО  
Посоченото в настоящия раздел е валидно и за двата вида конфи­ 
гурации на интелигентните тахографи — със или без външно 
устройство за GNSS.  
GNS_39  Данните за местоположението се съхраняват в бордовото 
устройство, заедно с флаг, указващ дали местоположението 
е с удостоверена автентичност. Когато в бордовото 
устройство трябва да се запишат данни за местополо­ 
жението, се прилагат следните правила:  
а) Ако местоположението с удостоверена автентичност 
и стандартното местоположение са валидни и съгла­ 
сувани, в бордовото устройство се записва стан­ 
дартното местоположение и неговата точност, а за 
флага се задава „удостоверена автентичност“.  
б) Ако местоположението с удостоверена автентичност и 
стандартното местоположение са валидни, но не са съгла­ 
сувани, бордовото устройство съхранява местополо­ 
жението с удостоверена автентичност и неговата 
точност, а за флага се задава „удостоверена автентичност“.  
в) Ако местоположението с удостоверена автентичност е 
валидно, а стандартното местоположение е невалидно, 
бордовото устройство записва местоположението с удос­ 
товерена автентичност и неговата точност, а за флага се 
задава „удостоверена автентичност“.  
г) Ако стандартното местоположение е валидно, а 
местоположението с удостоверена автентичност не 
е валидно, бордовото устройство записва стан­ 
дартното местоположение и неговата точност, а за 
флага се задава „неудостоверена автентичноста“.  
Местоположенията с удостоверена автентичност и стан­ 
дартните местоположения се считат за съгласувани, 
както е показано на фигура 7, когато хоризонталното 
местоположение с удостоверена автентичност се 
намира в окръжност с център в хоризонталното стан­ 
дартно местоположение и с радиус, закръглен до най- 
близкото по-голямо цяло число, като стойността му 
R_H се изчислява по следната формула: 
R_H = 1,74 • σ  UERE  • HDOP  
където:  
— R_H е относителният радиус на окръжност около очак­ 
ваното хоризонтално местоположение в метри. Това е 
показател, който се използва за проверка на съгласува­ 
ността между стандартните местоположения и местопо­ 
ложенията с удостоверена автентичност.  
— σ UERE  е стандартното отклонение на потребителската 
грешка с еквивалентен обхват (UERE), която моделира 
всички измервателни гршки за целевото приложение, 
включително градска среда. Използва се константна 
стойност σ  UERE  = 10 метра.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 521  
— HDOP Хоризонтално намаление на точността при 
определяне на местоположението.  
— σ  UERE  . HDOP е оценка за средната квадратична 
грешка в хоризонталната равнина.  
Фигура  7 
Съгласувани  местоположение  с удостоверерена  автентичност  и 
стандатно  местоположение  (неудостоверена  автентичност )
 
GNS_40 Когато стойността на статуса в полученото изречение 
AMC е „J“ или „O“ или „F“ в съответствие с изискване 
GNS_4а, бордовото устройство трябва да генерира и 
регистрира събитие за аномалия на GNSS, както е 
определено в изискване 88а от приложение IB и в 
допълнение 1 (EventFaultType). Бордовото устройство 
може да извърши допълнителни проверки, преди да 
съхрани събитие за аномалия на GNSS след получа­ 
ването на настройка „J“ или „O“.  
7. ПРОТИВОРЕЧИЕ С ВРЕМЕТО В ДАННИТЕ ОТ GNSS  
GNS_41 Ако бордовото устройство открие несъответствие 
между времето на функцията за измерване на времето 
на бордовото устройство и времето, произхождащо от 
сигналите от GNSS, то трябва да генерира и регистрира 
събитие за противоречие с времето, както е определено 
в изисквания 86 от приложение IB и в допълнение 1 
(EventFaultType).  
8. ПРОТИВОРЕЧИЕ В ДАННИТЕ ЗА ДВИЖЕНИЕТО НА 
ПРЕВОЗНОТО СРЕДСТВО  
GNS_42 Бордовото устройство генерира и регистрира събитие 
за противоречие в данните за движението на 
превозното средство в съответствие с изискване 84 от 
приложение IB, в случай че информацията за 
движението, изчислена от датчика за движение, проти­ 
воречи на информацията за движението, изчислена от 
вътрешния приемник на сигнали от GNSS, от външното 
устройство за GNSS или от друг(и) независим(и) 
източник(ци) на информация за движението, както е 
посочено в изискване 26 от приложение IB.  
Събитието на противоречие в данните за движението 
на превозното средство се генерира при настъпването 
на едно от следните условия на задействане:  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 522  
Условие 1 за задействане:  
Когато е налична информацията за местоположението 
от приемника на сигнали от GNSS и когато запалването 
на превозното средство е включено, се използва пресе­ 
чената средна стойност на разликите в скоростта между 
тези източници, както е посочено по-долу:  
— Най-много на всеки 10 секунди трябва да се 
изчислява разликата между данните за скоростта 
на превозното средство, оценена от GNSS, и 
скоростта, оценена от датчика за движение.  
— За изчисляване на пресечената средна стойност се 
използват всички изчислени стойности във времеви 
интервал, съдържащ последните пет минути от 
движението на превозното средство.  
— Пресечената средна стойност се изчислява като 
средноаритметичната стойност от 80 % от стой­ 
ностите, оставащи след премахване на най- 
големите по абсолютна стойност числа.  
Събитието за противоречие в данните за движението на 
превозното средство се генерира ако пресечената 
средна стойност е над 10 km/h за пет последователни 
минути от движението на превозното средство. 
(Забележка: използването на пресечена средна 
стойност за последните 5 минути се прилага за смек­ 
чаване на риска от силно отличаващи се измерени 
резултати и преходни стойности).  
За изчисляване на пресечената средна стойност 
превозното средство се счита за движещо се, ако най- 
малко една стойност на скоростта на превозното 
средство, изчислена от датчика за движение или от 
приемника на сигнали от GNSS, не е равна на нула.  
Условие 2 за задействане:  
Събитието за противоречие в данните за движението на 
превозното средство също се генерира, ако е вярно 
следното условие:  
GnssDistance  >  [OdometerDifference  × OdometerToleran ­
ceFactor  + Minimum  (SlipDistanceUpperlimit ;(Odometer ­
Difference  × SlipFactor )) + GnssTolerance  + FerryTrain ­
Distance ] 
където:  
— GnssDistance  е разстоянието между текущото 
положение на превозното средство и предишното 
местоположение, като и двете са получени от 
валидни съобщения за местоположението с удосто­ 
верена автентичност, без да се взема предвид висо­ 
чината,  
— OdometerDifference е разликата между текущата 
стойност на километражния брояч и стойността на 
километражния брояч, съответстваща на пред­ 
ишното валидно съобщение за местоположението 
с удостоверена автентичност,  
— OdometerToleranceFactor е равен на 1.1 (коефициент 
на допустимо отклонение при най-лошия случай за 
всички допустими отклонения на измерванията за 
километражния брояч на превозното средство),  
— GnssTolerance е равно на 1 km (допустимо 
отклонение на GNSS в най-лошия случай),  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 523  
— Минимална стойност (SlipDistanceUpperLimit; 
(OdometerDifference * SlipFactor) е минималната 
стойност между:  
— SlipDistanceUpperLimit, която е равна на 10 km 
(горна граница на разстоянието при плъзгане, 
причинено от ефекта на плъзгане по време на 
спиране),  
— и OdometerDifference * SlipFactor, където Slip­
Factor е равно на 0,2 (максимално влияние на 
ефекта на плъзгане по време на спиране),  
— FerryTrainDistance се изчислява както следва: 
FerryTrainDistance =200 km/h * tFerryTrain, където 
tFerryTrain е сборът от продължителностите в 
часове на пътуванията с ферибот/влак в 
разглеждания времеви интервал. Продължител­ 
ността на пътуванията с ферибот/влак се дефинира 
като времевата разлика между неговите флаг за 
край и флаг за начало.  
Предхождащите проверки се извършват на всеки 15 
минути, ако са налице необходимите данни за место­ 
положението, в противен случай веднага щом станат 
налични данните за местоположението.  
За това условие за задействане:  
— датата и часът на началото на събитието съвпадат с 
датата и часа на получаване на предишното 
съобщение за местоположение,  
— датата и часът на приключване на събитието 
съвпадат с датата и часа, когато провереното 
състояние стане отново невярно.  
Условие 3 за задействане:  
Бордовото устройство, открива несъответствие, 
състоящо се в това за определен период от време 
датчикът за движение да не открива движение, а неза­ 
висимият източник на информация за движението да 
открива движение. Условията за записване на несъот­ 
ветствие, както и периодът на откриване на несъот­ 
ветствието се определят от производителя на 
бордовото устройство, въпреки че несъответствието 
трябва да бъде открито за не повече от три часа.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 524  
Допълнение  13 
ИНТЕРФЕЙС  С ITS  
СЪДЪРЖАНИЕ  
1. ВЪВЕДЕНИЕ  
1.1. Обхват  
1.2. Съкращения и определения  
2. СТАНДАРТИ ЗА СПРАВКА  
3. ПРИНЦИПИ НА ФУНКЦИОНИРАНЕ НА ИНТЕРФЕЙСА С ITS  
3.1. Съобщителна технология  
3.2. Налични услуги  
3.3. Достъп посредством интерфейса с ITS  
3.4. Налични данни и необходимост от съгласие на водача  
4. СПИСЪК НА НАЛИЧНИТЕ ДАННИ ПОСРЕДСТВОМ 
ИНТЕРФЕЙСА С ITS И КЛАСИФИЦИРАНЕ ЛИЧНИ/НЕЛИЧНИ  
1. ВЪВЕДЕНИЕ  
1.1. Обхват  
ITS_01 В настоящото допълнение са описани основите на комуни­ 
кацията посредством интерфейса на тахографа с интели­ 
гентните транспортни системи (ITS), изисквана в членове 10 
и 11 от Регламент (ЕС) № 165/2014.  
ITS_02 Интерфейсът с ITS трябва да позволява на външни устройст ва 
да получават данни от тахографа, да използват тахографски 
услуги, както и да предоставят данни на тахографа.  
За тази цел могат да се използват и други тахографски 
интерфейси (напр. шина CAN).  
В настоящото допълнение не се описва:  
— как данните, предоставяни посредством интерфейса с ITS, 
се събират и управляват от тахографа,  
— формата на представяне на събраните данни на прило­ 
женията, поддържани от външното устройство.  
— спецификациите за сигурността на ITS в допълнение към 
това, което предоставя Bluetooth®,  
— протоколите за Bluetooth®, използвани от интерфейса с ITS  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 525  
1.2. Съкращения  и определения  
В настоящото допълнение се използват следните съкращения и опре д­ 
еления:  
GNSS  Global Navigation Satellite System (Глобална навига­ 
ционна спътникова система)  
ITS Intelligent Transport System (интелигентна транспортна 
система — ИТС)  
OSI Open Systems Interconnection (взаимна свързаност на 
отворените системи)  
VU Vehicle Unit (бордово устройство)  
ITS устройство  
външно устройство или приложение, които използват интерфейса на  
бордовото устройство с ITS  
2. СТАНДАРТИ ЗА СПРАВКА  
ITS_03 Настоящото допълнение се отнася до и зависи от всички ил и 
части от следните регламенти и стандарти. В разделите от 
настоящото допълнение са посочени относимите стандарти 
или относимите раздели на стандарти. В случай на проти­ 
воречие разделите на настоящото допълнение имат пред­ 
имство.  
Стандартите, посочени в настоящото допълнение, са:  
— Bluetooth® — основна версия 5.0  
— ISO 16844-7: Пътни превозни средства. Тахографски 
системи. Част 7: Параметри  
— ISO/IEC 7498-1:1994 Информационни технологии. Взаимно 
свързване на отворени системи. Основен еталонен модел. 
Основен модел  
3. ПРИНЦИПИ НА ФУНКЦИОНИРАНЕ НА ИНТЕРФЕЙСА С ITS  
ITS_04 От бордовото устройство се изисква да актуализира и да 
поддържа предаваните посредством интерфейса с ITS тахог­ 
рафски данни, без никакво участие на интерфейса с ITS.  
3.1. Съобщителна  технология  
ITS_05 Комуникацията посредством интерфейса с ITS се извършва 
чрез интерфейса Bluetooth® и трябва да бъде съвместима с 
Bluetooth® Low Energy съгласно Bluetooth, версия 5.0 или 
по-нова.  
ITS_06 Комуникацията между бордовото устройство и ITS устрой­ 
ството трябва да бъде установена след завършване на 
процеса на сдвояване на Bluetooth®.  
ITS_07 Между бордовото устройство и ITS устройството трябва се 
установява сигурна и криптирана комуникация в съответствие 
с механизмите за спецификация на Bluetooth®. В настоящото 
допълнение не се описва криптирането или други механизми 
за сигурност в допълнение към това, което предоставя 
Bluetooth®.  
ITS_08 Bluetooth® използва модел сървър/клиент, за да управлява  
предаването на данни между устройствата, при което 
бордовото устройство е сървърът, а ITS устройството е 
клиентът.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 526  
3.2. Налични  услуги  
ITS_09 Данните, които се предават посредством интерфейса с ITS в 
съответствие с точка 4, се предоставят посредством услугите, 
описани в допълнение 7 и допълнение 8. В допълнение, 
бордовото устройство предоставя на ITS устройството 
услугите, необходими за ръчното въвеждане на данни в съот­ 
ветствие с изискване 61 от приложение IB, и по избор — за 
други въвеждания на данни в реално време.  
Фигура  1 
Разделяне  на комуникацията  посредством  интерфейса  с ITS в съответствие  със слоевете  на модела  на 
OSI
 
ITS_10 Когато интерфейсът за изтегляне на данни се използва чре з 
предния съединител, бордовото устройство не трябва да пред­ 
оставя услугите за изтегляне, описани в допълнение 7, чрез 
Bluetooth® връзката на ITS.  
ITS_11 Когато интерфейсът за калибриране се използва чрез предн ия 
съединител, бордовото устройство не трябва да предоставя 
услугите за калибриране, описани в допълнение 8, чрез 
Bluetooth® връзката на ITS.  
3.3. Достъп  посредством  интерфейса  с ITS  
ITS_12 Интерфейсът с ITS трябва да осигурява безжичен достъп до  
всички услуги, описани в допълнение 7 и допълнение 8, в 
замяна на кабелната връзка към предния съединител за калиб­ 
риране и изтегляне, описана в допълнение 6.  
ITS_13 Бордовото устройство трябва да осигурява наличието на 
интерфейса с ITS за потребителя в съответствие с комби­ 
нацията от валидни тахографски карти, вкарани в бордовото 
устройство, както е описано в таблица 1.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 527  
Таблица  1 
Наличие  на интерфейса  с ITS в зависимост  от вида  на картата , вкарана  в тахографа  
Наличие на интерфейса с 
ITS Процеп за карта на водач  
Няма карта  Карта на водач  Контролна карта  Карта за монтаж 
и настройки  Карта на 
превозвач
 Процеп за карта на втория водач Няма карта  Не е налична  Налична  Налична  Налична  Налична  
Карта на водач  Налична  Налична  Налична  Налична  Налична  
Контролна 
карта  Налична  Налична  Налична  Не е налична  Не е налична  
Карта за 
монтаж и 
настройки  Налична  Налична  Не е налична  Налична  Не е налична  
Карта на 
превозвач  Налична  Налична  Не е налична  Не е налична  Налична  
ITS_14  След успешно сдвояване на ITS чрез Bluetooth®, бордовото 
устройство трябва да зачисли връзката с ITS чрез Bluetooth® на 
конкретната вкарана тахографска карта в съответствие с таблица 2: 
Таблица  2 
Зачисляване  на връзката  с ITS в зависимост  от вида  на картата , вкарана  в тахографа  
Зачисляване на връзката с 
ITS чрез Bluetooth®  Процеп за карта на водач  
Няма карта  Карта на водач  Контролна карта  Карта за монтаж 
и настройки  Карта на 
превозвач
 Процеп за карта на втория водач Няма карта  Не е налична  Карта на 
водач  Контролна 
карта  Карта за 
монтаж и 
настройки  Карта на 
превозвач  
Карта на водач  Карта на 
водач  Карта на 
водач (**)  Контролна 
карта  Карта за 
монтаж и 
настройки  Карта на 
превозвач  
Контролна 
карта  Контролна 
карта  Контролна 
карта  Контролна 
карта (*)  Не е налична  Не е налична  
Карта за 
монтаж и 
настройки  Карта за 
монтаж и 
настройки  Карта за 
монтаж и 
настройки  Не е налична  Карта за 
монтаж и 
настройки (*)  Не е налична  
Карта на 
превозвач  Карта на 
превозвач  Карта на 
превозвач  Не е налична  Не е налична  Карта на 
превозвач (*)  
(*) Връзката с ITS чрез Bluetooth® се зачислява на тахографскат а карта в процепа за картата на водача на бордовото 
устройство. 
(**) Потребителят трябва да избере картата, на която се зачисля ва връзката с ITS чрез Bluetooth® (вкарана в процепа за карта 
на водача или в процепа за карта на втория водач).  
ITS_15 Ако тахографската карта бъде извадена, бордовото устройс тво 
прекратява връзката с ITS чрез Bluetooth®, която е присвоена 
на тази карта.  
ITS_16 Бордовото устройство трябва да поддържа връзката с ITS с  
най-малко едно ITS устройство и да може едновременно да 
поддържа връзки с множество ITS устройства.  
ITS_17 Правата за достъп до данните и услугите, налични чрез 
интерфейса с ITS, трябва да отговарят на изисквания 12 и 13 
от приложение IB, в допълнение към съгласието на водача, 
посочено в раздел 3.4 от настоящото допълнение.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 528  
3.4. Налични  данни  и необходимост  от съгласие  на водача  
ITS_18 Всички тахографски данни, налични чрез услугите, посочен и в 
точка 3.3, се класифицират като лични или нелични данни за 
водача, втория водач или и за двамата.  
ITS_19 Чрез интерфейса с ITS се предоставя най-малкото списъкът  с  
данни, класифицирани като задължителни в раздел 4.  
ITS_20 Данните в раздел 4, които са класифицирани като „лични“,  
трябва да бъдат достъпни само със съгласието на водача, 
като по този начин се приема, че личните данни могат да 
напуснат мрежата на превозното средство, освен в случая, 
определен в изискване ITS_25, при който съгласието на 
водача не е необходимо.  
ITS_21 Данни в допълнение към данните, обединени в точка 4 и 
считани за задължителни, могат да бъдат предоставяни чрез 
интерфейса с ITS. Допълнителни данни, които не са 
включени в точка 4, се класифицират като „лични“ или 
„нелични“ от производителя на бордовото устройство, при 
условие че е поискано съгласието на водача за онези данни, 
които са били класифицирани като лични, освен в случая, 
определен в изискване ITS_25, при който съгласието на 
водача не е необходимо.  
ITS_22 При вкарване на карта на водач, която не е известна на 
бордовото устройство, тахографът трябва да поиска от 
титуляря на картата да даде съгласие за предаване на 
резултата с личните данни посредством интерфейса с ITS в 
съответствие с изискване 61 от приложение IB.  
ITS_23 Статусът на съгласието (разрешено/неразрешено) се записв а в 
паметта за данни на бордовото устройство.  
ITS_24 В случай на няколко водачи, посредством интерфейса с ITS  
трябва да бъдат достъпни само личните данни, свързани с тези 
водачи, които са дали своето съгласие. Например в ситуацията 
на екип, ако само водачът е дал съгласието си, личните данни, 
свързани с втория водач, не трябва да бъдат достъпни.  
ITS_25 Когато бордовото устройство е в режим на контрол, превоз вач 
или калибриране, правата за достъп посредством интерфейса с 
ITS се управляват в съответствие с изисквания 12 и 13 от 
приложение IB, като така съгласието на водача не е необ­ 
ходимо.  
4. СПИСЪК НА НАЛИЧНИТЕ ДАННИ ПОСРЕДСТВОМ ИНТЕРФЕЙСА 
С ITS И КЛАСИФИЦИРАНЕ ЛИЧНИ/НЕЛИЧНИ  
Наименование на 
данните  Формат на 
данните  Източ­ 
ник Класификация на данните (лични/ 
нелични)  Съгласие за налич­ 
ността на данните  Наличност  
водач  втори водач  
VehicleIdentification­
Number  Допълнение 8  V U  нелични  нелични  не е необходимо 
съгласие  задъл­ 
жително  
CalibrationDate  ISO 16844-7  V U  нелични  нелични  не е необходимо 
съгласие  задъл­ 
жително  
TachographVehic­
leSpeed  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  задъл­ 
жително  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 529  
Наименование на 
данните  Формат на 
данните  Източ­ 
ник Класификация на данните (лични/ 
нелични)  Съгласие за налич­ 
ността на данните  Наличност  
водач  втори водач  
Driver1WorkingState  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  задъл­ 
жително  
Driver2WorkingState  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  задъл­ 
жително  
DriveRecognize  ISO 16844-7  V U  нелични  нелични  не е необходимо 
съгласие  задъл­ 
жително  
Driver1TimeRela­
tedStates  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  задъл­ 
жително  
Driver2TimeRela­
tedStates  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  задъл­ 
жително  
DriverCardDriver1  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  задъл­ 
жително  
DriverCardDriver2  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  задъл­ 
жително  
OverSpeed  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  задъл­ 
жително  
TimeDate  Допълнение 8  V U  нелични  нелични  не е необходимо 
съгласие  задъл­ 
жително  
HighResolutionTotal­
VehicleDistance  ISO 16844-7  V U  нелични  нелични  не е необходимо 
съгласие  задъл­ 
жително  
HighResolutionTri­
pDistance  ISO 16844-7  V U  нелични  нелични  не е необходимо 
съгласие  задъл­ 
жително  
ServiceComponentI­
dentification  ISO 16844-7  V U  нелични  нелични  не е необходимо 
съгласие  задъл­ 
жително  
ServiceDelayCalen­
darTimeBased  ISO 16844-7  V U  нелични  нелични  не е необходимо 
съгласие  задъл­ 
жително  
Driver1Identification  ISO 16844-7  Кар­ 
та на 
вод­ 
ач лични  не се прилага  съгласие на 
водача  задъл­ 
жително  
Driver2Identification  ISO 16844-7  Кар­ 
та на 
вод­ 
ач не се прилага  лични  съгласие на 
втория водач  задъл­ 
жително  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 530  
Наименование на 
данните  Формат на 
данните  Източ­ 
ник Класификация на данните (лични/ 
нелични)  Съгласие за налич­ 
ността на данните  Наличност  
водач  втори водач  
NextCalibrationDate  Допълнение 8  V U  нелични  нелични  не е необходимо 
съгласие  задъл­ 
жително  
Driver1ContinuousD­
rivingTime  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  задъл­ 
жително  
Driver2ContinuousD­
rivingTime  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  задъл­ 
жително  
Driver1CumulativeB­
reakTime  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  задъл­ 
жително  
Driver2CumulativeB­
reakTime  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  задъл­ 
жително  
Driver1CurrentDura­
tionOfSelectedAc­
tivity  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  задъл­ 
жително  
Driver2CurrentDura­
tionOfSelectedAc­
tivity  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  задъл­ 
жително  
SpeedAuthorised  Допълнение 8  V U  нелични  нелични  не е необходимо 
съгласие  задъл­ 
жително  
TachographCardSlot1  ISO 16844-7  V U  нелични  не се прилага  не е необходимо 
съгласие  задъл­ 
жително  
TachographCardSlot2  ISO 16844-7  V U  не се прилага  нелични  не е необходимо 
съгласие  задъл­ 
жително  
Driver1Name  ISO 16844-7  Кар­ 
та на 
вод­ 
ач лични  не се прилага  съгласие на 
водача  задъл­ 
жително  
Driver2Name  ISO 16844-7  Кар­ 
та на 
вод­ 
ач не се прилага  лични  съгласие на 
втория водач  задъл­ 
жително  
OutOfScopeCondition  ISO 16844-7  V U  нелични  нелични  не е необходимо 
съгласие  задъл­ 
жително  
ModeOfOperation  ISO 16844-7  V U  нелични  нелични  не е необходимо 
съгласие  задъл­ 
жително  
Driver1CumulatedD­
rivingTimePreviou­
sAndCurrentWeek  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  задъл­ 
жително  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 531  
Наименование на 
данните  Формат на 
данните  Източ­ 
ник Класификация на данните (лични/ 
нелични)  Съгласие за налич­ 
ността на данните  Наличност  
водач  втори водач  
Driver2CumulatedD­
rivingTimePreviou­
sAndCurrentWeek  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  задъл­ 
жително  
EngineSpeed  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  по избор  
RegisteringMem­
berState  Допълнение 8  V U  нелични  нелични  не е необходимо 
съгласие  задъл­ 
жително  
VehicleRegistration­
Number  Допълнение 8  V U  нелични  нелични  не е необходимо 
съгласие  задъл­ 
жително  
Driver1EndOfLast­
DailyRestPeriod  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  по избор  
Driver2EndOfLast­
DailyRestPeriod  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  по избор  
Driver1EndOfLast­
WeeklyRestPeriod  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  по избор  
Driver2EndOfLast­
WeeklyRestPeriod  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  по избор  
Driver1EndOfSecon­
dLastWeeklyRest­
Period  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  по избор  
Driver2EndOfSecon­
dLastWeeklyRest­
Period  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  по избор  
Driver1TimeLastLoa­
dUnloadOperation  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  по избор  
Driver2TimeLastLoa­
dUnloadOperation  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  по избор  
Driver1CurrentDai­
lyDrivingTime  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  по избор  
Driver2CurrentDai­
lyDrivingTime  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  по избор  
Driver1CurrentWeek­
lyDrivingTime  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  по избор  
Driver2CurrentWeek­
lyDrivingTime  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  по избор  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 532  
Наименование на 
данните  Формат на 
данните  Източ­ 
ник Класификация на данните (лични/ 
нелични)  Съгласие за налич­ 
ността на данните  Наличност  
водач  втори водач  
Driver1TimeLeftUn­
tilNewDailyRest­
Period  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  по избор  
Driver2TimeLeftUn­
tilNewDailyRest­
Period  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  по избор  
Driver1CardExpi­
ryDate  ISO 16844-7  Кар­ 
та на 
вод­ 
ач лични  не се прилага  съгласие на 
водача  по избор  
Driver2CardExpi­
ryDate  ISO 16844-7  Кар­ 
та на 
вод­ 
ач не се прилага  лични  съгласие на 
втория водач  по избор  
Driver1CardNext­
MandatoryDownlo­
adDate  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  по избор  
Driver2CardNext­
MandatoryDownlo­
adDate  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  по избор  
TachographNextMan­
datoryDownloadDate  ISO 16844-7  V U  нелични  нелични  не е необходимо 
съгласие  по избор  
Driver1TimeLeftUn­
tilNewWeeklyRest­
Period  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  по избор  
Driver2TimeLeftUn­
tilNewWeeklyRest­
Period  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  по избор  
Driver1Numbe­
rOfTimes9hDailyDri­
vingTimesExceeded  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  по избор  
Driver2Numbe­
rOfTimes9hDailyDri­
vingTimesExceeded  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  по избор  
Driver1CumulativeU­
ninterruptedRestTime  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  по избор  
Driver2CumulativeU­
ninterruptedRestTime  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  по избор  
Driver1MinimumDai­
lyRest  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  по избор  
Driver2MinimumDai­
lyRest  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  по избор  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 533  
Наименование на 
данните  Формат на 
данните  Източ­ 
ник Класификация на данните (лични/ 
нелични)  Съгласие за налич­ 
ността на данните  Наличност  
водач  втори водач  
Driver1MinimumWe­
eklyRest  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  по избор  
Driver2MinimumWe­
eklyRest  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  по избор  
Driver1MaximumDai­
lyPeriod  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  по избор  
Driver2MaximumDai­
lyPeriod  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  по избор  
Driver1MaximumDai­
lyDrivingTime  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  по избор  
Driver2MaximumDai­
lyDrivingTime  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  по избор  
Driver1NumberOfU­
sedReducedDaily­
RestPeriods  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  по избор  
Driver2NumberOfU­
sedReducedDaily­
RestPeriods  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  по избор  
Driver1Remainin­
gCurrentDrivingTime  ISO 16844-7  V U  лични  не се прилага  съгласие на 
водача  по избор  
Driver2Remainin­
gCurrentDrivingTime  ISO 16844-7  V U  не се прилага  лични  съгласие на 
втория водач  по избор  
VehiclePosition  Допълнение 8  V U  лични  лични  съгласие на 
водача и на 
втория водач  задъл­ 
жително  
ByDefaultLoadType  Допълнение 8  V U  лични  лични  съгласие на 
водача и на 
втория водач  задъл­ 
жително  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 534  
Допълнение  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 — 21.08.2023 — 003.001 — 535  
5.5 Reserved for Future Use (Резервирано за бъдеща употреба)  
▼B 
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), т.е. телематика за автомобилния транспорт и 
пътното движение (RTTT); Dedicated Short Range 
Communication (DSRC) transmission equipment (500 kbit/s / 
250 kbit/s) operating in the 5,8 GHz Industrial, Scientific and  
Medical (ISM) band, т.е. специализирани съобщителни  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 536  
системи с малък обсег на действие (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 — 21.08.2023 — 003.001 — 537  
средство, които удостоверяват, че е възможно това превозно 
средство да нарушава разпоредбите на Регламент (ЕС) №165/2014 
и следва да бъде набелязано за спиране с оглед на по-нататъшно 
разследване.  
Съгласно Регламент (ЕС) №165/2014 събраните данни се огра­ 
ничават до данните, които удостоверяват възможно нарушение, 
или са свързани с тези данни, както е определено в член 9 от 
Регламент (ЕС) № 165/2014.  
▼M1 
В този сценарий наличното време за връзка е ограничено, тъй кат о 
връзката  е целева и е разчетена за малък обсег. Освен това същите 
съобщителни средства за наблюдение на тахографа от 
разстояние (RTM) могат да бъдат използвани от компетентните 
контролни органи и за други приложения (например за максимално 
допустимите маси и размери на тежкотоварни превозни средства, 
определени в Директива (ЕС) 2015/719), като тези действия могат  
да бъдат отделни или последователни по преценка на компет­ 
ентните контролни органи.  
▼B 
В настоящото допълнение се определя:  
— Съобщителното оборудване, процедури и протоколи, които да 
се използват за  връзката  
— Стандартите и регламентите, на които трябва да отговаря радио ­ 
техническото оборудване  
— Представянето на  данните  на оборудването за  връзката  
— Процедурите за запитване и изтегляне на данни и последовател­  
ността на операциите  
— Данни , които трябва да бъдат предадени  
— Възможно тълкуване на  данните , предадени по  връзката  
— Разпоредби за свързаните със сигурността данни, отнасящи се 
до връзката  
— Предоставянето на данните на компетентните контролни органи  
— Как четецът за връзка с цел ранно откриване от разстояние мож е 
да заяви различни концепти на данни за теглото и други харак­ 
теристики на превозните средства  
Трябва да се поясни, че в настоящото допълнение  не се определят:  
— събирането на  данни  за функционирането и управлението в 
рамките на бордовото устройство (което се определя при проек­ 
тирането на съответния продукт, освен ако е посочено друго в 
Регламент (ЕС) № 165/2014)  
— формата на представяне на събраните данни на представителя на  
компетентните контролни органи, нито критериите, които да се 
използват от тези органи при вземането на решение кои 
превозни средства да бъдат спрени (което се определя при 
проектирането на продукта, освен ако е посочено друго в 
Регламент (ЕС) № 165/2014 или в решение за политиката на 
компетентните контролни органи). За пояснение:  данните  се 
предоставят по  връзката  на компетентните контролни органи 
само за да могат те да вземат информирани решения  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 538  
— мерките за сигурност на данните (като например криптиране), 
отнасящи се до съдържанието на  данните  (които се определят в 
допълнение 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 — 21.08.2023 — 003.001 — 539  
хармонизиране на някои разпоредби 
от социалното законодателство, 
свързани с автомобилния транспорт  
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 Communication 
(специализирана връзка или специа­ 
лизирана съобщителна система с 
малък обсег на действие)  
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 Standards) 
(„Телематични приложения за регу­ 
лирани превозни средства“ — серия 
от стандарти ISO 15638)  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 540  
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 coo pe­
rative telematics applications for regulated commercial freight  
vehicles (TARV).  
[5] EN 300 674-1 Electromagnetic compatibility and Radio spectr um 
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 
Industrial, Scientific and Medical (ISM) band; Part 1: General 
characteristics 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 — 21.08.2023 — 003.001 — 541  
[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 interfac e 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 — 21.08.2023 — 003.001 — 542  
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 Данни, свързани със сигурността  
▼M3 
DSC_17 Данните, свързани със сигурността ( DSRCSecurityData ), 
включително данните, изисквани от  REDCR , за да 
придобие пълна способност да декриптира  данните , се 
предоставят съгласно допълнение 11 относно общите 
механизми за сигурност за временно съхранение в  DSRC- 
VU като текуща версия на  DSRCSecurityData , във формата, 
определена в точка 5.4.4 от настоящото допълнение  
▼B 
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 — 21.08.2023 — 003.001 — 543  
Фигура  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 — 21.08.2023 — 003.001 — 544  
Фигура  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 и електроенергийният източник не е акумулаторна 
батерия, електроенергийният източник на DSRC-VU се 
подменя при всеки периодичен технически преглед, а  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 545  
производителят на 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 — 21.08.2023 — 003.001 — 546  
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 — 21.08.2023 — 003.001 — 547  
този начин се предоставя максимална свобода на участ­ 
ниците в пазара да проектират и доставят оборудване, 
което да покрива специфичните сценарии за разпитване 
на конкретния компетентен контролен орган.  
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 — 21.08.2023 — 003.001 — 548  
Стъпките са описани по-долу:  
а) Когато превозното средство е в действие (т.е. контактният кл юч 
е в положение „включено“), тахографът подава данни на 
функцията 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 или по идентификатори на прило­ 
жението (ApplicationID) и атрибута (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 — 21.08.2023 — 003.001 — 549  
компетентен контролен орган с оглед той да бъде подпо­ 
могнат при подбора на превозни средства, които следва 
да бъдат спрени за физическа проверка, и впоследствие те 
се унищожават съгласно член 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 — 21.08.2023 — 003.001 — 550  
Позиция №  Параметър  Стойност(и)  Забележка  
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 — 21.08.2023 — 003.001 — 551  
Позиция №  Параметър  Стойност(и)  Забележка  
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 — 21.08.2023 — 003.001 — 552  
Позиция №  Параметър  Стойност(и)  Забележка  
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 — 21.08.2023 — 003.001 — 553  
Позиция №  Параметър  Стойност(и)  Забележка  
U11 Съобщителна зона  Пространствената област, в 
рамките на която 
DSRC-VU е разположено 
така, че предадените данни 
са получени от REDCR с 
по-малка B.E.R. от посо­ 
чената в U9a.  (в съответствие с EN 12253)  
U12a  (*) Усилване при преобраз­ 
уването (долна граница)  1 dB за всяка странична 
лента Ъглов диапазон: 
кръгово симетричен 
между диаграмата на 
насоченост и ± 35° 
и 
в границите от – 45° 
до + 45° в съответствие с 
равнината, успоредна на 
повърхността на пътя, 
когато DSRC-VU по- 
късно е монтирано в 
превозното средство 
(Azimuth)  По-голямо от специфицирания 
диапазон на стойности за хори­ 
зонтални ъгли до ± 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 — 21.08.2023 — 003.001 — 554  
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 
(Freight&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 — 21.08.2023 — 003.001 — 555  
— Стъпка  № 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 — 21.08.2023 — 003.001 — 556  
Фигура  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 — 21.08.2023 — 003.001 — 557  
— 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 — 21.08.2023 — 003.001 — 558  
Пореден 
номер  Предавател  Приемник  Описание  Действие  
▼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 
Attribute=1 и се прехвърлят в RTM контейнер =10.  
DSC_40 RTM Context Mark идентифицира поддържаната част от 
стандарта в серията TARV от стандарти (RTM съот­ 
ветства на част 9)  
Модулът ASN.1 за DSRC данните в рамките на прило­ 
жението RTM е определен, както следва:  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 559
  
► (2) (3) M1 
► (1) M3 ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 560
  
5.4.5  Елементи  на RtmData, извършени  действия  и определения  
DSC_41 Стойностите на данните, които трябва да бъдат изчислени 
от бордовото устройство (VU) и използвани за актуали­ 
зиране на защитените данни в DSRC-VU, се изчисляват 
съгласно правилата, определени в таблица 14.3:  
▼M3 
Таблица  14.3  
Елементи  на RtmData, извършени  действия  и определения  
(1) 
Елемент на RTM Data  (2) 
Действие, извършено от VU  (3) 
ASN.1 определение на данните  
RTM1 
Регистрация  на 
превозното  средство  
Регистрационна  табела  VU задава стойността на 
елемента  tp15638VehicleRe ­
gistrationPlate  от данни 
RTM1 от записаната 
стойност за типа на 
данните  
VehicleRegistrationIdentifi ­
cation  както е определено в 
допълнение 1  VehicleRegist ­
rationIdentification  Регистрационен номер 
на превозното средство 
изразен като низ от 
символи  tp15638VehicleRegistrati­
onPlate LPN, 
– RegistrationPlate на 
превозното средство 
Регистрационна табела, 
използваща структурата на 
данните от ISO 14906, но 
със следното ограничение за 
приложението RTM: 
ПОСЛЕДОВАТЕЛНОСТТА 
започва с кода на държавата, 
следван от азбучен 
индикатор, следван от самия 
регистрационен номер, 
който винаги е 14 октета 
(допълнен в двата края с 
нула), така че дължината на 
типа на LPN винаги е 17 
октета (не е необходима 
определяща на дължината), 
от които 14 са „действи­ 
телният“ номер на регистра­ 
ционната табела.  
RTM2 
Превишаване  на 
допустимата  скорост  VU генерира булева 
стойност на елемента 
RTM2 на данните 
tp15638SpeedingEvent. 
Стойността на 
tp15638SpeedingEvent се 
изчислява от VU от броя на 
събитията с превишена 
скорост, регистрирани във 
VU през последните 10 
дни, както е определено в 
приложение IВ.  1 (TRUE): ако 
последното събитие на 
превишаване на 
скоростта е 
приключило през 
последните 10 дни или 
все още е в ход; 
0 (FALSE): във всички 
останали случаи,  tp15638SpeedingEvent 
BOOLEAN,  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 561  
(1) 
Елемент на RTM Data  (2) 
Действие, извършено от VU  (3) 
ASN.1 определение на данните  
RTM3 
Управление  без 
валидна  карта  VU генерира булева 
стойност на елемента 
RTM3 на данните 
tp15638DrivingWithoutVa­
lidCard. 
VU присвоява стойност 
TRUE на променливата 
tp15638DrivingWithoutVa­
lidCard, ако през 
последните 10 дни във VU 
е регистрирано най-малко 
едно събитие на управление 
без съответната карта, 
както е определено в 
приложение IB.  1 (TRUE): ако 
последното събитие на 
управление без съот­ 
ветната карта е 
приключило през 
последните 10 дни или 
все още е в ход; 
0 (FALSE): във всички 
останали случаи,  tp15638DrivingWithoutVa­
lidCard 
BOOLEAN,  
RTM4 
Валидна  карта  на 
водач  VU генерира булева 
стойност на елемента 
RTM4 на данните 
tp15638DriverCard въз 
основа на вкарана валидна 
карта на водач в процепа за 
водача.  1 (TRUE): ако в 
процепа на бордовото 
устройство за водача 
няма валидна карта на 
водач; 
0 (FALSE): ако в 
процепа на бордовото 
устройство има 
валидна карта на 
водач.  tp15638DriverCard 
BOOLEAN,  
RTM5 
Вкарване  на карта  по 
време  на 
Управление  на МПС  VU генерира булева 
стойност на елемента от 
данни RTM5 
tp15638CardInsertion. 
VU присвоява стойност 
TRUE на променливата 
tp15638CardInsertion, ако 
през последните 10 дни във 
VU е регистрирано най- 
малко едно събитие на 
вкарване на карта по време 
на управление, както е 
определено в приложение 
IB. 1 (TRUE): Ако 
последното събитие на 
вкарване на карта по 
време на управление е 
настъпило през 
последните 10 дни; 
0 (FALSE): във всички 
останали случаи,  tp15638CardInsertion 
BOOLEAN,  
RTM6 
Грешка  в данните  за 
движението  VU генерира булева 
стойност за елемента от 
данни RTM6. 
VU присвоява стойност 
TRUE на променливата 
tp15638MotionDataError, 
ако през последните 10 дни 
във VU е регистрирано 
най-малко едно събитие на 
грешка в данните за 
движението, както е 
определено в приложение 
IB. 1 (TRUE): ако 
последното събитие за 
грешка в данните за 
движението е 
приключило през 
последните 10 дни или 
все още е в ход; 
0 (FALSE): във всички 
останали случаи,  tp15638MotionDataError 
BOOLEAN,  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 562  
(1) 
Елемент на RTM Data  (2) 
Действие, извършено от VU  (3) 
ASN.1 определение на данните  
RTM7 
Движение  на 
превозното  средство  
Конфликт  VU генерира булева 
стойност за елемента от 
данни RTM7. 
VU присвоява стойност 
TRUE на променливата 
tp15638VehicleMotion­
Conflict, ако през 
последните 10 дни във VU 
е регистрирано най-малко 
едно събитие на конфликт в 
движението на превозното 
средство.  1 (TRUE): ако 
последното събитие на 
конфликт в движението 
на превозното средство 
е приключило през 
последните 10 дни или 
все още е в ход; 
0 (FALSE): във всички 
останали случаи,  tp15638VehicleMotionConflict 
BOOLEAN,  
RTM8 
Карта  на втория  водач  VU генерира булева 
стойност на елемента от 
данни RTM8 въз основа на 
приложение IВ (Данни за 
дейността на водача ЕКИП 
и ВТОРИ ВОДАЧ). 
Ако е налице валидна карта 
на водач, VU задава на 
RTM8 стойност TRUE.  1 (TRUE): ако във VU 
има валидна карта на 
втори водач; 
2 (FALSE): ако във VU 
няма валидна карта на 
втори водач.  tp156382ndDriverCard 
BOOLEAN,  
RTM9 
Текуща  дейност  VU генерира булева 
стойност за елемента от 
данни RTM9. 
Ако текущата дейност е 
записана във VU като 
дейност, различна от 
„УПРАВЛЕНИЕ НА 
МПС“ (DRIVING) съгласно 
определението в 
приложение IВ, VU задава 
на RTM9 стойност TRUE.  1 (TRUE): избрана е 
друга дейност 
0 (FALSE): избрано е 
управление на МПС  tp15638CurrentActivityD­
riving 
BOOLEAN  
RTM10 
Последната  сесия  е 
приключена  VU генерира булева 
стойност за елемента от 
данни RTM10. 
Ако последната картова 
сесия не е приключена 
правилно съгласно опред­ 
елението в приложение IВ, 
VU задава на RTM10 
стойност TRUE.  1 (TRUE): най-малко 
една от вкараните 
карти е предизвикала 
събитие на неправилно 
приключване на 
последната картова 
сесия; 
0 (FALSE): Нито една 
от вкараните карти не е 
предизвикала 
неправилно 
приключване на 
последната картова 
сесия.  tp15638LastSessionClosed 
BOOLEAN  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 563  
(1) 
Елемент на RTM Data  (2) 
Действие, извършено от VU  (3) 
ASN.1 определение на данните  
RTM11 
Прекъсване  на елек­  
трическото  
захранване  VU генерира цяло число 
стойност за елемента от 
данни RTM11. 
VU присвоява стойност на 
променливата 
tp15638PowerSupplyInter­
ruption, равна на броя през 
последните 10 дни на 
регистрираните във VU 
събития на прекъсване на 
електрическото захранване, 
както е определено в 
приложение IB. 
Ако през последните 10 
дни във VU не е било 
регистрирано прекъсване на 
електрическото захранване, 
то трябва да зададе за 
RTM11 стойност 0.  Брой на регистри­ 
раните случаи на 
прекъсване на електри­ 
ческото захранване 
през последните 10 
дни. tp15638PowerSupplyInter­
ruption 
ЦЯЛО ЧИСЛО (0..127),  
RTM12 
Неизправност  на 
датчика  VU генерира цяло число 
като стойност за елемента 
от данни RTM12. 
VU присвоява на промен­ 
ливата sensorFault стой­ 
ността: 
— 1, ако събитие от тип 
„35“H за грешка на 
датчика е приключило 
през последните 10 дни 
или все още е в ход. 
— 2, ако събитие от типа 
неизправност на 
приемника за сигнали 
от GNSS (външен или 
вътрешен със стойност 
„36“H или 
'37'H) е приключило 
през последните 10 дни 
или все още е в ход. 
— 3, ако събитие от типа 
„0E“H за грешка в 
комуникацията с 
външното устройство 
за GNSS е приключило 
през последните 10 дни 
или все още е в ход. 
— 4, ако неизправности на 
датчика и на приемника 
на сигнали от GNSS са 
приключили през 
последните 10 дни или 
все още са в ход. 
— 5, ако събития за неиз­ 
правност на датчика и 
грешка в комуни­ 
кацията с външното 
устройство за GNSS са 
приключили през 
последните 10 дни или 
все още са в ход.  – за неизправност на 
датчика — един октет 
съгласно речника на 
данните  tp15638SensorFault INTEGER 
(0..255),  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 564  
(1) 
Елемент на RTM Data  (2) 
Действие, извършено от VU  (3) 
ASN.1 определение на данните  
— 6, ако неизправност на 
приемника на сигнали 
от GNSS и грешка в 
комуникацията с 
външното устройство 
за GNSS са 
приключили през 
последните 10 дни или 
все още са в ход. 
— 7, ако всички три неиз­ 
правности на датчици 
са приключили през 
последните 10 дни или 
все още са в ход. 
Ако нито едно събитие не е 
приключило през 
последните 10 дни или все 
още е в ход, VU задава за 
RTM12 стойност 0.  
RTM13 
Сверяване  на 
часовника  VU генерира целочислена 
стойност (timeReal от 
допълнение 1) за елемента 
от данни RTM13 въз основа 
на наличните данни за 
сверяване на часовника 
съгласно определението в 
приложение IВ. 
VU присвоява като 
стойност на RTM13 часа, в 
който е станало последното 
събитие „Сверяване на 
часовника“. 
Ако в данните във VU 
липсва събитие „Сверяване 
на часовника“ съгласно 
определението в 
приложение IВ, VU задава 
на RTM13 стойност 0.  oldTimeValue от 
последното сверяване 
на часовника.  tp15638TimeAdjustment 
INTEGER(0..4294967295),  
RTM14 
Опит  за нарушаване  
на сигурността  VU генерира целочислена 
стойност (timeReal от 
допълнение 1) за елемента 
от данни RTM14 въз основа 
на наличието на събитие 
„Опит за нарушаване на 
сигурността“ съгласно 
определението в 
приложение IВ. 
VU присвоява като 
стойност момента, в който 
е възникнало последното 
събитие „Опит за нару­ 
шаване на сигурността“, 
регистрирано от VU. 
Ако в данните във VU 
липсва събитие „Опит за 
нарушаване на сигур­ 
ността“ съгласно опред­ 
елението в приложение IВ, 
VU задава за RTM14 
стойност 0.  Час на началото на 
последния записан 
опит за нарушаване на 
сигурността.  tp15638LatestBreachAttempt 
INTEGER(0..4294967295),  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 565  
(1) 
Елемент на RTM Data  (2) 
Действие, извършено от VU  (3) 
ASN.1 определение на данните  
RTM15 
Последно  калибриране  VU генерира целочислена 
стойност (timeReal от 
допълнение 1) за елемента 
от данни RTM15 въз основа 
на наличните данни за 
последното калибриране 
(Last Calibration) съгласно 
определението в 
приложение IВ и 
допълнение 1. 
VU задава за стойността на 
RTM15 стойността на 
oldTimeValue от записа за 
последното калибриране. 
Ако не е имало калиб­ 
риране, VU задава за 
RTM15 стойност 0.  oldTimeValue от 
последния запис за 
калибриране.  tp15638LastCalibrationData 
INTEGER(0..4294967295),  
RTM16 
Предишно  калиб­  
риране  VU генерира целочислена 
стойност (timeReal от 
допълнение 1) за елемента 
RTM16 на данните въз 
основа на записа за калиб­ 
риране, предхождащ 
последното калибриране. 
VU задава за стойността на 
RTM16 стойността на 
oldTimeValue от записа за 
калибриране, предхождащ 
последното калибриране. 
Ако не е имало предишно 
калибриране, VU задава за 
RTM16 стойност 0.  oldTimeValue от записа 
за калибриране, пред­ 
хождащ последния 
запис за калибриране.  tp15638PrevCalibrationData 
INTEGER(0..4294967295),  
RTM17 
Дата  на свързване  
на тахографа  VU генерира целочислена 
стойност (timeReal от 
допълнение 1) за елемента 
от данни RTM17. 
VU задава за стойността на 
RTM17 датата на първото 
калибриране на VU в 
настоящото превозно 
средство. 
VU извлича тези данни от 
VuCalibrationData 
(допълнение 1) на vuCalib­
rationRecords, като Calibra­
tionPurpose е равно на: 
„03“H 
Ако не е имало предишно 
калибриране, VU задава за 
RTM17 стойност 0.  Дата на първото 
калибриране на VU в 
настоящото превозно 
средство.  tp15638DateTachoConnected 
INTEGER(0..4294967295),  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 566  
(1) 
Елемент на RTM Data  (2) 
Действие, извършено от VU  (3) 
ASN.1 определение на данните  
RTM18 
Моментна  скорост  VU генерира цяло число 
стойност за елемента от 
данни RTM18. 
VU задава за стойностна на 
RTM18 последната 
записана моментна скорост 
при последното актуали­ 
зиране на RtmData.  Последна записана 
моментна скорост  tp15638CurrentSpeed 
INTEGER (0..255),  
RTM19 
Времеви  печат  VU генерира целочислена 
стойност за елемента от 
данни RTM19 (timeReal от 
допълнение 1). 
VU задава за стойността на 
RTM19 часа на последното 
актуализиране на RtmData.  Времеви печат на 
текущия 
запис Tachograph­
Payload  tp15638Timestamp 
INTEGER(0..4294967295),  
RTM20 
Час, в който  в било  
налично  последното  
местоположение  с 
удостоверена  автен­  
тичност  VU генерира целочислена 
стойност за елемента от 
данни RTM20 (timeReal от 
допълнение 1). 
VU задава за стойността на 
RTM20 часа, в който от 
приемника на сигнали от 
GNSS е било налично 
последното местопо­ 
ложение на превозното 
средство, чиято автен­ 
тичност е била удосто­ 
верена. 
Ако от приемника на 
сигнали от GNSS не е било 
налично местоположение 
на превозното средство с 
удостоверена автентичност, 
VU задава за RTM20 
стойност 0.  Времеви печат на 
последното местопо­ 
ложение на превозното 
средство с удосто­ 
верена автентичност  tp15638LatestAuthenticatedPo­
sition 
INTEGER(0..4294967295),  
RTM21 
Време  на непрекъснато  
управление  VU генерира цяло число 
като стойност за елемента 
от данни RTM21. 
VU задава за стойността на 
RTM21 текущото време на 
непрекъснато управление 
на водача.  Времето на непре­ 
къснато управление на 
водача, въведено като 
цяло число. 
Дължина: 1 байт 
Разделителна 
способност: 2 минути/ 
бит 
Без отместване 
Обхват на данните: 0 
до 250 
Стойност 250 означава, 
че времето на непре­ 
къснато управление на 
водача е по-голямо или 
равно на 500 минути. 
Стойности 251—254 не 
се използват. 
Стойност 255 означава, 
че информацията не е 
налична.  tp15638ContinuousDri­
vingTime INTEGER(0..255),  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 567  
(1) 
Елемент на RTM Data  (2) 
Действие, извършено от VU  (3) 
ASN.1 определение на данните  
RTM22 
Най-дългото  дневно  
време  на управление  за 
текущата  и пред­  
ходната  смяна  на 
RTM, изчислено  в 
съответствие  с 
добавката  към 
допълнение  14 VU генерира цяло число 
като стойност за елемента 
от данни RTM22. 
VU задава за стойността на 
RTM22 по-голямото от 
двете дневни времена на 
управление на водача, 
което е или текущата, или 
предходната смяна на RTM.  Дневно време на 
управление на водача, 
въведно като цяло число. 
Дължина: 1 байт 
Разделителна 
способност: 4 минути/ 
бит 
Без отместване 
Обхват на данните: 0 до 
250 
Стойност 250 означава, 
че дневното време на 
управление на водача е 
по-голямо или равно на 
1000 минути. 
Стойности 251—254 не 
се използват. 
Стойност 255 означава, 
че информацията не е 
налична.  tp15638DailyDrivingTimeShift 
INTEGER(0..255),  
RTM23 
Най-голямото  дневно  
време  на управление  в 
рамките  на текущата  
седмица , изчислено  в 
съответствие  с 
добавката  към 
допълнение  14 VU генерира цяло число 
като стойност за елемента 
от данни RTM23. 
VU задава за стойността на 
RTM23 най-голямото 
дневно време на 
управление на водача, 
което е или текущата смяна 
на RTM или някоя 
завършила смяна на RTM, 
която е започнала или е 
свършила през текущата 
седмица.  Дневно време на 
управление на водача, 
въведено като цяло 
число. 
Дължина: 1 байт 
Разделителна 
способност: 4 минути/ 
бит 
Без отместване 
Обхват на данните: 0 
до 250 
Стойност 250 означава, 
че дневното време на 
управление на водача е 
по-голямо или равно на 
1000 минути. 
Стойности 251—254 не 
се използват. 
Стойност 255 означава, 
че информацията не е 
налична.  tp15638DailyDrivingTi­
meWeek INTEGER(0..255),  
RTM24 
Седмично  време  на 
управление , изчислено  
в съответствие  с 
добавката  към 
допълнение  14 VU генерира цяло число 
като стойност за елемента 
от данни RTM24. 
VU задава за стойността на 
RTM24 седмичното време 
на управление на водача.  Седмично време на 
управление на водача, 
закодирано като цяло 
число. 
Дължина: 1 байт 
Разделителна 
способност: 20 минути/ 
бит 
Без отместване 
Обхват на данните: 0 до 
250 
Стойност 250 означава, 
че седмичното време на 
управление на водача е 
по-голямо или равно на 
5000 минути. 
Стойности 251—254 не 
се използват. 
Стойност 255 означава, 
че информацията не е 
налична.  tp15638WeeklyDrivingTime 
INTEGER(0..255),  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 568  
(1) 
Елемент на RTM Data  (2) 
Действие, извършено от VU  (3) 
ASN.1 определение на данните  
RTM25 
Двуседмично  време  на 
управление , изчислено  
в съответствие  с 
добавката  към 
допълнение  14 VU генерира цяло число 
като стойност за елемента 
от данни RTM25. 
VU задава за стойността на 
RTM25 двуседмичното 
време на управление на 
водача.  Двуседмично време на 
управление на водача, 
въведено като цяло 
число. 
Дължина: 1 байт 
Разделителна 
способност: 30 минути/ 
бит 
Без отместване 
Обхват на данните: 0 
до 250 
Стойност 250 означава, 
че двуседмичното 
време на управление на 
водача е по-голямо или 
равно на 7500 минути. 
Стойности 251—254 не 
се използват. 
Стойност 255 означава, 
че информацията не е 
налична.  tp15638FortnightlyDri­
vingTime INTEGER(0..255),  
Забележка: RTM22, RTM23, RTM24 и RTM25 се изчисляват в съответс твие 
с добавката към настоящото допълнение  
▼B 
5.4.6  Механизъм  за прехвърляне  на данни  
DSC_42 Полезните данни, определени преди, се заявяват от 
четеца (REDCR) след етапа на инициализиране и 
впоследствие се предават от  DSRC-VU  в разпределения 
прозорец. REDCR използва командата GET, за да 
извлече данните.  
▼M1 
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  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 569  
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 команда  
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
 ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 570
 Октет # 
Атрибут/поле  Битове в октета  Описание  
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  
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
  Флаг за край  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 571  
DSC_46 В отговор REDCR разпределя частен прозорец съгласно 
EN 12795 и EN 13372, 7.1.1 без специфични настройки за 
RTM.  
В таблица 14.7 се дава пример за кодирането на битовете.  
Таблица  14.7.  
Инициализиране  — съдържание  на фрейма  за разпределяне  на частен  прозорец
 Октет # 
Атрибут/поле  Битове в октета  Описание  
1 FLAG
  Флаг за начало  
2 Private LID
  Адрес на конкретното 
DSRC-VU за връзката  
3
 
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 команда  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 572  
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.  
▼M3 
Таблица  14.9  
Инициализиране  — пример  за съдържанието  на фрейма  с VST
 Октет 
Атрибут/поле  Битове в октета  Описание  
1 FLAG  0111 1110  Флаг за начало  
2 Private LID  xxxx xxxx  Адрес на конкретното 
DSRC-VU за връзката  
3 xxxx xxxx  
4 xxxx xxxx  
5 xxxx xxxx  
6 MAC Control field  1100 0000  PDU с команда  
7 LLC Control field  0000 0011  UI команда  
8 Fragmentation header  1xxx x001  Без фрагментиране  
9 VST 
SEQUENCE { 
Fill BIT STRING (SIZE(4))  1001  Отговор на инициали­ 
зиране  
0000  Не се използва и е 
зададен равен на 0  
10 Profile INTEGER (0..127,...) 
AttributeIdList SEQUENCE OF {  0000 0000  Без разширение. Пример 
за профил 0 
Без разширение, 1 
приложение  11 0000 0001  
12 SEQUENCE { 
OPTION indicator 
OPTION indicator 
AID DSRCApplicationEntityID  1 EID налице  
1 Параметърът липсва  
00 0010  Без разширение. AID= 2 
Freight&Fleet  
13 EID Dsrc-EID  xxxx xxxx  Определен в рамките на 
OBU и идентифициращ 
инстанцията на прило­ 
жението.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 573
 Октет 
Атрибут/поле  Битове в октета  Описание  
14 Parameter Container {  0000 0010  Без разширение, Container 
Choice = 02, 
Октетен низ  
15 0000 0110  Без разширение, дължина 
на Rtm Context Mark = 6  
16 Rtm-ContextMark ::= SEQUENCE { 
StandardIdentifier  0000 0101  Първият октет е 05H, 
който дава неговата 
дължина. 
Следващите 5 октета 
задават Object Identifier 
на поддържания 
стандарт, част и версия. 
{ISO (1) Standard (0) 
TARV (15638) part9(9) 
Version2 (2)}  17 standardIdentifier  0010 1000  
18 1111 1010  
19 0001 0110  
20 0000 1001  
21 0000 0010  
22 ObeConfiguration Sequence { 
OPTION indicator  0 ObeStatus липсва  
EquipmentClass INTEGER (0..32767)  xxx xxxx  В това поле се дава  
23 xxxx xxxx  указаното от произ­ 
водителя за версията на 
софтуера/хардуера на 
интерфейса за DSRC  
24 ManufacturerId INTEGER (0..65535)  xxxx xxxx  Идентификатор на произ­ 
водителя на DSRC-VU, 
както е описано в ISO 
14816 Register  25 xxxx xxxx  
26 FCS  xxxx xxxx  Контролна поредица за 
фрейма  
27 xxxx xxxx  
28 Flag  0111 1110  Флаг за край  
▼B 
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. Без 
разширение.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 574  
Поле  Настройки  
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 — 21.08.2023 — 003.001 — 575  
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 — 21.08.2023 — 003.001 — 576
 Октет # 
Атрибут/поле  Битове в октета  Описание  
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 — 21.08.2023 — 003.001 — 577
 Октет # 
Атрибут/поле  Битове в октета  Описание  
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 — 21.08.2023 — 003.001 — 578  
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 — 21.08.2023 — 003.001 — 579  
Таблица  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 — 21.08.2023 — 003.001 — 580  
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 — 21.08.2023 — 003.001 — 581  
5.5 Резервирано  за бъдеща  употреба . 
▼M2 __________  
▼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  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 582  
4. Acknowledgment („Потвърждаване на приемането“) на 
данните  
5. Termination of the communication link — Request 
(„Приключване на съобщителната връзка — заявка“)  
6. Termination of the communication link — Response 
(„Приключване на съобщителната връзка — отговор“)  
DSC_73 В ASN1.0 горните команди могат да бъдат определени, 
както следва:
  
DSC_74 Следва описание на командите и параметрите:  
—
 се 
използва за инициализиране на съобщителната 
връзка. Командата се изпраща от VU на DSRC-VU. 
LinkIdentifier се задава от VU и се съобщава на 
DSRC-VU за проследяване на конкретна съобщителна 
връзка.  
(Забележка: това е за поддържане на бъдещи връзки и 
други приложения/модули като бордово претегляне).  
—
 се 
използва от DSRC-VU за даване на отговор на 
заявката за инициализиране на съобщителната 
връзка. Командата се изпраща от DSRC-VU на VU. 
Командата предоставя резултата от инициализирането 
като отговор = 1 (Success, т.е. успешно) или 0 = 
(Failure, т.е. неуспешно).  
DSC_75 Инициализирането на съобщителната връзка се извършва 
само след монтиране, калибриране и пускане на двигателя 
/ VU е включено.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 583  
—
 се използва от 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 за конкретния LinkI­
dentifier.  
5.7 Третиране  на грешки  
5.7.1  Записване  и съобщаване  на данните  в DSRC-VU  
▼M3 
DSC_77  Данните  се предоставят, вече защитени, от функцията  
VUSM  н а DSRC-VU . VUSM  проверява дали данните, 
записани в  DSRC-VU , са били предадени правилно на 
DSRC-VU. Записването и протоколирането на всякакви 
грешки при прехвърлянето на данни от бордовото 
устройство към паметта на  DSRC-VU  се извършва с 
типа EventFaultType и изброена стойност, зададена като 
събитие „0C“H — Грешка в комуникацията с устрой­ 
ството за връзка от разстояние, заедно с времевия печат.  
VUSM  трябва да провери дали данните са предадени 
успешно на DSRC-VU.  
DSC_78 Резервирано за бъдеща употреба.  
▼B 
DSC_79 Ако VUPM се опита неуспешно да получи VU данни от 
модула за сигурност (за подаване на VU-DSRC), тя 
записва този неуспех с типа EventFaultType и изброена 
стойност, зададена като  „62“H Remote Communication 
Facility  за неизправност във връзката, заедно с времевия 
печат. Неуспешната връзка се открива, когато при повече  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 584  
от три последователни опита не се получи съобщение
  
за съответната команда
  
(т.е. със същия 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, която да се 
предвиди при неговото проектиране.  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 585  
Неуспешното извличане на данни (failure to read) технически се 
различава от „грешка“ (error). В настоящия контекст „грешка“ 
означава придобиване на погрешна стойност.  
Данните, прехвърлени към  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 Предвидени са два вида изпитвания за функцията за 
връзка от разстояние:  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 586  
1) Изпитване чрез ECHO за валидиране на  безжичния  
съобщителен канал  DSRC-REDCR  >>-:-< DSRC-VU . 
2) Изпитване за сигурност от край до край, за да се 
гарантира, че карта за монтаж и настройки може да 
получи достъп до съдържанието от криптирани и 
подписани данни, създадено от VU и предадено по 
безжичния съобщителен канал.  
6.2 ECHO  
Настоящият раздел съдържа специални разпоредби за изпитване 
само дали функционира каналът  DSRC-REDCR  >>-:-< DSRC-VU . 
Целта на командата 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 — 21.08.2023 — 003.001 — 587  
ДОБАВКА  
Правила за изчисляване на дневното, седмичното и двуседмичното време на 
управление  
1. Основни изчислителни правила  
Бордовото устройство изчислява дневното време на управление, 
седмичното време на управление и двуседмичното време на управле ние, 
като използва съответните данни, съхранени върху карта на водач  (или за 
монтаж и настройки), вкарана в процепа за водача (процеп 1, чет ец на 
карта #1) на бордовото устройство, и избрани дейности на водача , докато 
картата е вкарана в бордовото устройство.  
Времената на управление не трябва да се изчисляват, когато не е  вкарана 
карта на водача (или за монтаж и настройки).  
НЕИЗВЕСТНИЯТ(ТЕ) период(и), установен(и) по време на периода, 
необходим за изчисленията, се приема(т) за ПРЕКЪСВАНЕ/ПОЧИВКА.  
НЕИЗВЕСТНИ периоди и дейности с отрицателна продължителност (т. е. 
началото на дейността настъпва по-късно от края на дейността) п оради 
припокриване във времето между две различни бордови устройства или 
поради сверяване на часовника, не се вземат под внимание.  
Дейностите, записани върху картата на водач, съответстващи на п ериоди 
„ИЗВЪН ОБХВАТ“ в съответствие с определението в буква гг) от 
приложение IБ, се тълкуват, както следва:  
— ПРЕКЪСВАНЕ/ПОЧИВКА се изчислява като „ПРЕКЪСВАНЕ“ или 
„ПОЧИВКА“  
— РАБОТА и УПРАВЛЕНИЕ се считат за „РАБОТА“  
— НА РАЗПОЛОЖЕНИЕ се счита за „НА РАЗПОЛОЖЕНИЕ“  
В контекста на настоящата добавка бордовото устройство приема, че има 
дневен период на почивка в началото на записите на дейностите в ърху 
картата.  
2. Понятия  
Следните понятия се отнасят изключително за настоящото допълнен ие и 
са предназначени да определят изчисляването от бордовото устрой ство 
на времето на управление и предаването му на по-късен етап от у строй­ 
ството за връзка от разстояние.  
а) „смяна на RTM“ е периодът между края на дадена дневна почивк а и 
края на непосредствено следващата дневна почивка.  
Бордовото устройство трябва да започне нова смяна на RTM след 
завършване на дневната почивка.  
Текущата смяна на RTM е периодът от края на последната дневна 
почивка;  
б) „общо време на управление“ е сборът от продължителността на 
всички дейности по УПРАВЛЕНИЕ на водача в рамките на даден 
период, докато не е „ИЗВЪН ОБХВАТ“;  
в) „дневно време на управление“ е общото време на управление в 
рамките на дадена смяна на RTM;  
г) „седмично време на управление“ е общото време на управление за 
текущата седмица;  
д) „период на непрекъсната почивка“ е всеки непрекъснат период на 
ПРЕКЪСВАНЕ/ПОЧИВКА;  
е) „двуседмично време на управление“ е общото време на управлен ие за 
предходната и текущата седмица;  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 588  
ж) „дневна почивка“ е периодът на ПРЕКЪСВАНЕ/ПОЧИВКА, който 
може да бъде:  
— редовна дневна почивка,  
— разделена дневна почивка или  
— намалена дневна почивка  
В контекста на допълнение 14, когато бордово устройство изчисля ва 
седмичните почивки, тези седмични почивки се считат за дневни 
почивки;  
з) „нормална дневна почивка“ е период на непрекъсната почивка о т 
най-малко 11 часа.  
По изключение, когато е активно условието ПЪТУВАНЕ С 
ФЕРИБОТ/ВЛАК, нормалната дневна почивка може да бъде 
прекъсната най-много два пъти от дейности, различни от почивка,  с  
максимална обща продължителност от един час, т.е. нормалната 
дневна почивка, съдържаща период(и) на пътуване с ферибот/влак,  
може да бъде разделена(и) на две или три части. След това 
бордовото устройство изчислява нормална дневна почивка, когато 
общото време на почивка, изчислено съгласно точка 3, е най-малк о 
11 часа.  
Когато нормалната дневна почивка е била прекъсната, бордовото 
устройство:  
— не трябва да включва дейността по управление, извършена по 
време на тези прекъсвания, в изчисляването на дневното време 
на управление, и  
— започва нова смяна на RTM в края на нормалната дневна почивка , 
която е била прекъсната.  
Фигура  1 
Пример  за прекъсване  на дневната  почивка  поради  пътуване  с ферибот /влак
  
i) „намалена дневна почивка“ е период на непрекъсната почивка о т най- 
малко 9 часа, но по-къса от 11 часа;  
й) „разделена дневна почивка“ е дневна почивка, ползвана на две  части:  
— първата част трябва да бъде непрекъсната почивка от най-малко  3 
часа, но по-къса от 9,  
— втората част трябва да бъде непрекъсната почивка от най-малко  9 
часа.  
По изключение, когато по време на едната или и на двете части н а 
разделената дневна почивка е активно условие ПЪТУВАНЕ С 
ФЕРИБОТ/ВЛАК, разделената дневна почивка може да бъде 
прекъсната най-много два пъти от други дейности с обща продължи ­ 
телност най-много от един час, т.е.:  
— първата част от разделената дневна почивка може да бъде 
прекъсната един или два пъти, или  
— втората част от разделената дневна почивка може да бъде 
прекъсната един или два пъти, или  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 589  
— първата част от разделената дневна почивка може да бъде 
прекъсната веднъж и втората част от разделената дневна 
почивка може да бъде прекъсната веднъж.  
Тогава бордовото устройство изчислява разделена дневна почивка,  
когато общото време на почивка, изчислено в съответствие с точк а 3, е:  
— най-малко три часа и по-малко от 11 часа за първия период на 
почивка и най-малко 9 часа за втория период на почивка, когато 
първата почивка е била прекъсната от ПЪТУВАНЕ С 
ФЕРИБОТ/ВЛАК.  
— най-малко три часа и по-малко от 9 часа за първия период на 
почивка и най-малко 9 часа за втория период на почивка, 
когато първата почивка не е била прекъсната от ПЪТУВАНЕ С 
ФЕРИБОТ/ВЛАК.  
Фигура  2. 
Пример  за разделена  дневна  почивка , прекъсната  поради  пътуване  с ферибот /влак
  
Когато разделената дневната почивка е прекъсната, бордовото 
устройство:  
— не трябва да включва дейността по управление, извършена по 
време на тези прекъсвания, в изчисляването на дневното време 
на управление, и  
— започва нова смяна на RTM в края на разделената дневна 
почивка, която е била прекъсната;  
к) „седмица“ е периодът време по UTC между 00:00 часа в понедел ник 
и 24:00 часа в неделя;  
3. Изчисляване на периода на почивка, когато той е бил прекъсна т поради 
пътуване с ферибот/влак  
За изчисляването на периода на почивка, когато той е бил прекъс нат 
поради пътуване с ферибот/влак, бордовото устройство изчислява 
общото време на почивка съгласно следните стъпки:  
а) Стъпка 1  
Бордовото устройство трябва да открива прекъсвания на времето н а 
почивка, настъпили преди активирането на флага ПЪТУВАНЕ С 
ФЕРИБОТ/ВЛАК (НАЧАЛО), в съответствие с фигура 3 или фигура 
4, според случая, и за всяко установено прекъсване трябва да пр ецени 
дали са изпълнени следните условия:  
— прекъсването прави общата продължителност на откритите 
прекъсвания, включително прекъсванията, ако е приложимо, 
настъпили през първата част от разделената дневна почивка 
поради пътуване с ферибот/влак, да надвиши общо повече от 
един час,  
— прекъсването прави общия брой на откритите прекъсвания, вклю­  
чително прекъсванията, ако е приложимо, настъпили по време на 
първата част от разделената дневна почивка поради пътуване с 
ферибот/влак, по-голям от две,  
— след края на прекъсването съществува съхранено „Entry of plac e 
where daily work periods end“ (Въведено място, където завършват  
дневните периоди на работа).  
Ако нито едно от горните условия не е изпълнено, към общото вре ме 
на почивка се добавя непрекъснатата почивка непосредствено пред и 
прекъсването.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 590  
Ако е изпълнено най-малко едно от горните условия, бордовото 
устройство трябва или да спре изчисляването на общото време на 
почивка съгласно стъпка 2, или да открие прекъсвания на времето  
на почивка, настъпили след флага ПЪТУВАНЕ С ФЕРИБОТ/ВЛАК 
(НАЧАЛО) съгласно стъпка 3.  
б) Стъпка 2  
За всяко прекъсване, установено съгласно стъпка 1, бордовото 
устройство трябва да прецени дали изчисляването на общото време  
на почивка следва да спре. Бордовото устройство спира процеса н а 
изчисляване, когато към общото време на почивка са добавени два  
непрекъснати периода на почивка, възникнали преди активирането на 
флага ПЪТУВАНЕ С ФЕРИБОТ/ВЛАК (НАЧАЛО), включително, ако 
е приложимо, периодите на почивка, добавени в първата част на 
разделена дневна почивка, също прекъсната от пътуване с 
ферибот/влак. В противен случай бордовото устройство, трябва да  
изпълни предвиденото в стъпка 3.  
в) Стъпка 3  
Ако след изпълнението на стъпка 2 бордовото устройство продължи  
да изчислява общото време на почивка, бордовото устройство тряб ва 
да открие прекъсвания, настъпили след дезактивирането на услови ето 
за ПЪТУВАНЕ С ФЕРИБОТ/ВЛАК съгласно фигура 3 или фигура 4, 
според случая.  
За всяко установено прекъсване бордовото устройство трябва да 
прецени дали това прекъсване прави общото време на всички уста­  
новени прекъсвания повече от общо един час, като в този случай 
изчисляването на общото време на почивка приключва в края на 
непрекъснатия период на почивка преди прекъсването. В противен 
случай периодите на непрекъсната почивка, които настъпват след 
съответните прекъсвания, се добавят към изчисляването на дневна та 
почивка, докато условието в стъпка 4 бъде изпълнено.  
г) Стъпка 4  
Изчисляването на общото време на почивка спира, когато бордовот о 
устройство е добавило в резултат на стъпки 1 и 3 най-много две 
непрекъснати почивки към периода на почивка, за който е активир ано 
условието ПЪТУВАНЕ С ФЕРИБОТ/ВЛАК, включително, ако е 
приложимо, прекъсванията, настъпили по време на първата част на  
разделената дневна почивка поради пътуване с ферибот/влак.  
Фигура  3. 
Обработване  на времената  на почивка  от бордовото  устройство , с цел да се определи  дали  дадена  
прекъсната  почивка  трябва  да се отчете  като  нормална  дневна  почивка  или като  първата  част  на 
разделена  дневна  почивка
  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 591  
Фигура  4 
Обработване  на времената  на почивка  от бордовото  устройство , с цел да се определи  дали  дадена  
прекъсната  почивка  трябва  да се отчете  като  втората  част  на разделена  дневна  почивка
  
Фигура  5 
Пример  за дневна  почивка , прекъсната  повече  от два пъти , поради  което  почивката  H не се 
включва  в изчислението
  
Фигура  6 
Пример  за дневна  почивка , когато  периодът  на отчитане  на ферибот /влак  започва  в края  на 
работния  период
  
Фигура  7 
Пример  за дневна  почивка , прекъсната  повече  от два пъти , поради  което  почивката  B не се 
включва  в изчислението
  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 592  
Фигура  8. 
Пример  за разделена  дневна  почивка , прекъсната  веднъж  по време  на първия  период  на почивка  и 
веднъж  по време  на втория  период  на почивка
  
4. Изчисляване на дневното, седмичното и двуседмичното време на  
управление  
Бордовото устройство трябва да изчислява дневното(ите) време(на ) на 
управление за текущата и предишните смени на RTM. Времето на 
управление, настъпило по време на прекъсванията на дневните пер иоди 
на почивка, не се добавя към изчисляването на дневното време на  
управление, когато тези прекъсвания се дължат на пътуване с 
ферибот/влак и са изпълнени изискванията, предвидени в точка 2,  
букви з) и й) и в точка 3. Независимо от това, доколкото съглас но 
точка 3 бордовото устройство не е изчислило пълна нормална или 
разделена дневна почивка, времената на управление, които се слу чват 
по време на прекъсванията, се добавят към дневното време на 
управление за текущата смяна на RTM.  
Бордовото устройство изчислява също така седмичното и двуседмич ното 
време на управление. Времето на управление, което настъпва по в реме 
на прекъсванията на дневните почивки поради пътуване с ферибот/ влак, 
се добавя към изчисляването на седмичното и двуседмичното време  на 
управление.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 593  
Допълнение  15 
МИГРАЦИЯ: УПРАВЛЕНИЕ НА ЕДНОВРЕМЕННОТО СЪЩЕСТВУВАНЕ 
НА ОБОРУДВАНЕ ОТ РАЗЛИЧНИ ПОКОЛЕНИЯ И ВЕРСИИ  
▼B 
СЪДЪРЖАНИЕ  
1. ОПРЕДЕЛЕНИЯ  
2. ОБЩИ РАЗПОРЕДБИ  
2.1. Преглед на прехода  
▼M3 
2.2. Оперативна съвместимост между бордовите устройства и карти те 
▼B 
2.3. Оперативна съвместимост между бордовите устройства и датчи ците 
за движение  
2.4. Оперативна съвместимост между бордови устройства, тахограф ски 
карти и устройства за изтегляне на данни  
2.4.1 Директно изтегляне на данни от карта със специализирано и нтели­ 
гентно устройство (IDE)  
2.4.2 Изтегляне на данни от карта през бордово устройство  
2.4.3 Изтегляне на данни от бордово устройство  
2.5. Оперативна съвместимост между бордово устройство и оборудв ане 
за калибриране  
3. ОСНОВНИ СТЪПКИ ПРЕЗ ПЕРИОДА ПРЕДИ ДАТАТА НА 
ВЪВЕЖДАНЕ  
4. РАЗПОРЕДБИ ЗА ПЕРИОДА СЛЕД ДАТАТА НА ВЪВЕЖДАНЕ  
▼M3 
5. РЕГИСТРИРАНЕ НА ПРЕСИЧАНИЯ НА ГРАНИЦИ ОТ 
ТАХОГХРАФИ ОТ ВТОРО ПОКОЛЕНИЕ, ПЪРВА ВЕРСИЯ  
▼B 
1. ОПРЕДЕЛЕНИЯ  
За целите по настоящото допълнение се използват следните опред­  
еления:  
Интелигентна  тахографска  система : както е дефинирана в 
настоящото приложение (глава 1: определение ббб);  
Първо  поколение  тахографска  система : както е дефинирано в 
настоящия регламент (член 2: определение 1);  
Второ  поколение  тахографска  система : както е дефинирано в 
настоящия регламент (член 2: определение 7);  
Дата  на въвеждане : както е дефинирана в настоящото приложение 
(глава 1: определение ввв);  
Специализирано  интелигентно  устройство  (IDE):  устройство, 
използвано за изтегляне на данни, както е дефинирано в допълнен ие 
7 от настоящото приложение.  
▼M3 
2. ОБЩИ РАЗПОРЕДБИ  
2.1. Преглед  на прехода  
Във въведението към настоящото приложение е направен преглед на  
прехода между тахографските системи от първо и второ поколение и 
на въвеждането на втората версия на уредите за регистриране на 
данните за движението и тахографските карти от второ поколение.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 594  
В допълнение към положенията от въведението, може да се 
припомни следната информация:  
— датчиците за движение от първо поколение не са оперативно 
съвместими с нито една от версиите на бордовите устройства от 
второ поколение,  
— само датчици за движение от второ поколение могат да бъдат 
инсталирани в превозни средства, оборудвани с която и да е от 
версиите на бордови устройства от второ поколение,  
— оборудването за изтегляне на данни и за калибриране трябва да  
поддържа използването и на двете поколения или версии на 
уредите за регистриране на данните за движението и на тахог­ 
рафските карти.  
2.2. Оперативна  съвместимост  между  бордовите  устройства  и картите  
Подразбира се, че първото поколение тахографски карти са 
оперативно съвместими с бордовите устройства от първо поколение  
(в съответствие с приложение IБ от Регламент (ЕИО) № 3821/85), 
както и че второто поколение тахографски карти са оперативно 
съвместими с която и да е от версиите на бордовите устройства о т 
второ поколение (в съответствие с приложение IВ от настоящия 
регламент). В допълнение към това са валидни изискванията по-до лу. 
MIG_001 С изключение на посоченото в изискване MIG_004 и 
изискване MIG_005, първото поколение тахографски 
карти могат да продължат да бъдат използвани в която 
и да е версия на второто поколение бордови устройства 
до края на техния период на валидност. От друга страна, 
техните титуляри могат да поискат те да бъдат заменени с 
тахографски карти от второ поколение веднага щом се 
появят такива карти.  
MIG_002 Всички версии бордови устройства от второ поколение ще 
трябва да могат да използват всяка вкарана в тях карта от 
първо поколение от следните видове: карта на водач, 
контролна карта и карта на превозвач.  
MIG_003 Тази способност на подобни бордови устройства може 
безвъзвратно да бъде премахвана в сервизите, така че да 
не могат повече да бъдат приемани тахографски карти от 
първо поколение. Това може да се прави само след като 
Европейската комисия даде ход на процедура, имаща за 
цел да се поиска от сервизите да извършват такава 
дейност, например при всяка периодичен технически 
преглед на тахограф.  
MIG_004 По отношение на картите за монтаж и настройка, 
бордовите устройства от второ поколение трябва да 
могат да използват само второ поколение такива карти.  
MIG_005 За целите на определяне на работния режим бордовите 
устройства от второ поколение от всички версии трябва 
да вземат предвид само типовете на вкарваните валидни 
карти, без значение кое е тяхното поколение или версия.  
MIG_006 Всяка версия на валидна тахографска карта от второ 
поколение трябва да може да се използва в бордови 
устройства от първо поколение точно по същия начин 
като тахографска карта от първо поколение от същия тип.  
2.3. Оперативна  съвместимост  между  бордовите  устройства  и 
датчиците  за движение  
Подразбира се, че първото поколение датчици за движение са 
оперативно съвместими с първото поколение бордови устройство, 
както и че второто поколение датчици за движение са оперативно 
съвместими с второто поколение бордови устройства от всички 
версии. В допълнение към това са валидни изискванията по-долу.  
MIG_007 Второто поколение бордови устройства от всички версии 
не трябва да могат да се сдвояват и използват с първо 
поколение датчици за движение.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 595  
MIG_008 Възможно е датчици за движение от второ поколение да 
могат да бъдат сдвоявани и използвани или само с 
бордови устройства от второ поколение от всички 
версии, или с бордови устройства и от двете поколения.  
2.4. Оперативна  съвместимост  между  бордови  устройства , тахог­  
рафски  карти  и устройства  за изтегляне  на данни  
MIG_009 Оборудването за изтегляне на данни може да бъде 
съвместимо с всички поколения и версии на бордовите 
устройства и тахографските карти.  
2.4.1  Директно  изтегляне  на данни  от карта  със специализирано  интели­  
гентно  устройство  (IDE)  
MIG_010 IDE трябва да могат да изтеглят данни от тахографски 
карти от едно поколение, вкарани в съответните четящи 
устройства за карти, като използват механизмите за 
сигурност и протокола за изтегляне на данни за това 
поколение, и изтеглените данни трябва да са с формата, 
дефиниран за това поколение и версия.  
MIG_011 За да се даде възможност за контролиране на водачите от  
контролни органи на държави извън ЕС, трябва да е 
възможно изтегляне на данните от второ поколение 
карти на водачи (и карти за монтаж и настройки), неза­ 
висимо от версията, точно по същия начин както от първо 
поколение карти на водачи (и карти за монтаж и 
настройки). Подобно изтегляне трябва да включва:  
— неподписани елементарни файлове IC и ICC (незадъл­ 
жително),  
— неподписани елементарни файлове (първо поколение) 
Card_Certificate и CA_Certificate,  
— останалите елементарни файлове с приложни данни (в 
рамките на DF Tachograph), изисквани по протокола за 
изтегляне на данни от карти от първо поколение. 
Информацията трябва да бъде защитена с електронен 
подпис, в съответствие с механизмите за сигурност от 
първо поколение.  
Подобно изтегляне не трябва да включва елементарни 
файлове с приложни данни, които присъстват само във 
версия 1 или версия 2 на второ поколение карти на 
водачи (и карти за монтаж и настройки) — 
елементарни файлове с приложни данни в рамките 
на DF Tachograph_G2.  
2.4.2  Изтегляне  на данни  от карта  през бордово  устройство  
MIG_012 Данните от второ поколение карта от всички версии, 
вкарана в първо поколение бордово устройство, трябва 
да бъдат изтегляни с използване на протокол за 
изтегляне на данни от първо поколение. Картата трябва 
да отговаря на командите на бордовото устройство точно 
по същия начин като карта от първо поколение и изтег­ 
лените данни трябва да бъдат със същия формат като 
данните, изтеглени от карта от първо поколение.  
MIG_013 Данните от карта от първо поколение, вкарана в бордово 
устройство от второ поколение от всички версии, трябва 
да се изтеглят с използване на протокола за изтегляне на 
данни, дефиниран в допълнение 7 от настоящото 
приложение. Бордовото устройство трябва да изпраща 
команди на картата точно по същия начин като бордово 
устройство от първо поколение и изтеглените данни 
трябва да съответстват на формата, дефиниран за карти 
от първо поколение.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 596  
2.4.3  Изтегляне  на данни  от бордово  устройство  
MIG_014 С изключение на случаите на проверка на водача от 
контролни органи на държави извън ЕС, данните от 
второ поколение бордови устройства трябва да се 
изтеглят с използване на механизми за сигурност от 
второ поколение и на протокола за изтегляне на данни, 
специфициран за съответната версия в допълнение 7 към 
настоящото приложение.  
MIG_015 За да се позволи проверка на водачите от контролни 
органи на държави извън ЕС, по избор може да направи 
възможно от всякаква версия на бордово устройство от 
второ поколение да се изтеглят данни, използвайки 
механизми за сигурност от първо поколение. Изтеглените 
данни трябва да имат същия формат като данните, 
изтеглени от бордово устройство от първо поколение. 
Тази способност трябва да може да бъде избирана чрез 
команди в менюто.  
2.5. Оперативна  съвместимост  между  бордово  устройство  и 
оборудване  за калибриране  
MIG_016 Оборудването за калибриране трябва да може да 
извършва калибриране на всяко поколение или версия 
тахографи, с използване на протокола за калибриране на 
това поколение или версия. Оборудването за калибриране 
може да бъде съвместимо с всички поколения и версии на 
бордовите устройства.  
3. ОСНОВНИ СТЪПКИ ПРЕЗ ПЕРИОДА ПРЕДИ ДАТАТА НА 
ВЪВЕЖДАНЕ  
MIG_017 Изпитвателните ключове и сертификати трябва да бъдат 
на разположение на производителите на датата на публи­ 
куване на настоящото приложение.  
MIG_018 Изпитванията за оперативна съвместимост трябва да са 
готови да започнат с версия 2 на бордовите устройства 
и версия 2 на тахографските карти, ако това бъде 
поискано от производителите, най-късно  15 месеца  
преди датата на въвеждане.  
MIG_019 За поколение 2, версия 2 на тахографите, тахографските 
карти и датчиците за движение се използват същите 
ключове и сертификати, както за оборудването от 
поколение 2, версия 1.  
MIG_020 Държавите членки трябва да могат да издават карти за 
монтаж и настройки от второ поколение, версия 2 не 
по-късно  1 месец  преди датата на въвеждане.  
MIG_021 Държавите членки трябва да могат да издават всички 
други видове тахографски карти от второ поколение, 
версия 2 не по-късно от  1 месец  преди датата на 
въвеждане.  
4. РАЗПОРЕДБИ ЗА ПЕРИОДА СЛЕД ДАТАТА НА ВЪВЕЖДАНЕ  
MIG_022 От датата на въвеждане нататък, държавите членки трябва  
да издават тахографски карти само от второ поколение, 
версия 2.  
MIG_023 На производителите на бордови устройства / датчици за 
движение се разрешава да произвеждат бордови 
устройства / датчици за движение от първо поколение 
докато те се използват в практиката, така че да могат да 
се заменят неизправни компоненти.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 597  
MIG_023a От датата на въвеждане нататък, неизправната версия 1 на 
бордови устройства от второ поколение или външни 
устройства за GNSS се заменя с версия 2 на бордови 
устройства от второ поколение или на външни устройства 
за GNSS.  
MIG_024 На производителите на бордови устройства / датчици за 
движение се разрешава да искат и да получават запазване 
на одобрението на типа на бордови устройства / датчици 
за движение от първо поколение или версия 1 на бордови 
устройства от второ поколение, чийто тип вече е одобрен.  
5. РЕГИСТРИРАНЕ НА ПРЕСИЧАНИЯ НА ГРАНИЦИ ОТ 
ТАХОГРАФИ ОТ ВТОРО ПОКОЛЕНИЕ, ПЪРВА ВЕРСИЯ  
MIG_025 Символът на държавата и, ако е приложимо, на региона, в  
който навлиза водачът след пресичането на граница на 
държава членка в изпълнение на член 34, параграф 7 от 
Регламент (ЕС) № 165/2014, се вписва като мястото, 
където е започнал дневният период на работа, в съот­ 
ветствие с ръчното въвеждане на места, определено в 
изискване 60 от приложение IB към Регламент (ЕС) 
№ 165/2014 и изискване 50 от приложение IБ към 
Регламент (ЕИО) № 3821/85.  ▼M3
 02016R0799 — BG — 21.08.2023 — 003.001 — 598  
Допълнение  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 — 21.08.2023 — 003.001 — 599  
Той се монтира и използва само на типовете превозни 
средства, дефинирани в шш) „адаптор“, когато технически 
не е възможно монтирането на друг тип съществуващ 
датчик за движение, който иначе е в съответствие с разпо­ 
редбите в настоящото приложение и допълнения 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 — 21.08.2023 — 003.001 — 600  
— събитието „грешка в данните за движение“ се поражда от 
бордовото устройство в случай на прекъсване на 
нормалния поток от данни между вградения датчик за 
движение и бордовото устройство и/или в случай на 
грешка, свързана с цялостността на данните или с удосто­ 
веряването им по време на техния обмен между вградения 
датчик за движение и бордовото устройство [83]  
— събитието „опит за нарушаване на сигурността“ се 
поражда от бордовото устройство при всяко друго 
събитие от значение за сигурността на вградения 
датчик за движение, когато не е в режим на калиб­ 
риране [85]  
— грешката „уреди за регистриране на данните за 
движението“ се поражда от бордовото устройство, ако 
то не е в режим на калибриране при всяка грешка на 
вградения датчик за движение (88).  
ADA_008 Грешките на адаптора, които се откриват от уредите за 
регистриране на данните за движението, са тези грешки, 
които са свързани с вградения датчик на движение [88].  
ADA_009 Калибриращата функция на бордовото устройство трябва 
да дава възможност за автоматично сдвояване на вградения 
датчик за движение с бордовото устройство [202, 204].  
4. КОНСТРУКТИВНИ И ФУНКЦИОНАЛНИ ИЗИСКВАНИЯ КЪМ 
АДАПТОРА  
4.1. Препредаване  и адаптиране  на входящите  импулси  за скорост  
ADA_011 Входният интерфейс на адаптора трябва да приема 
честотни импулси за скоростта на превозното средство и 
изминатото от него разстояние. Електрическите характе­ 
ристики на входящите импулси:  подлежат  на определяне  
от производителя . В случай че е приложимо, за 
правилната интерфейсна връзка между входа на адаптора 
и превозното средство се допускат настройки, достъпни 
само за производителя на адаптора и за завода/сервиза 
(workshop), извършващ монтажа на адаптора.  
▼M3 
ADA_012 Входният интерфейс на адаптера трябва да може, в случай  
че е приложимо, да умножава или да дели честотните 
импулси на входящите импулси за скоростта с постоянен 
коефициент, за да адаптира сигнала към интервала от 
стойности на коефициента k, определен в настоящото 
приложение (2400 до 25 000 импулса/km). Този постоянен 
коефициент може да бъде програмиран само от произ­ 
водителя на адаптера и от завода/сервиза, извършващ 
монтажа на адаптера.  
▼B 
4.2. Индуктиране  на входящите  импулси  във вградения  датчик  за 
движение  
ADA_013 Входящите импулси, които е възможно да са адаптирани, 
както е посочено по-горе, се индуктират във вградения 
датчик за движение, така че всеки входящ импулс да се 
регистрира от датчика за движение.  
4.3. Вграден  датчик  за движение  
ADA_014 Вграденият датчик за движение се стимулира от индукти­ 
раните импулси, като по този начин генерира данни за 
движението, представящи точно движението на превозното 
средство, както при механично свързване на датчика с 
движеща се част на превозното средство.  
ADA_015 Идентификационните данни на вградения датчик за 
движение се използват от бордовото устройство за разпоз­ 
наване на адаптора [95].  ▼B
 02016R0799 — BG — 21.08.2023 — 003.001 — 601  
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 — 21.08.2023 — 003.001 — 602  
— идентификационния номер на превозното средство, на 
което е монтиран.  
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 — 21.08.2023 — 003.001 — 603  
— че адапторът е монтиран, както е показано на 
монтажната табелка,  
— че адапторът е монтиран, както е посочено от произ­ 
водителя на адаптора и/или на превозното средство,  
— че монтирането на адаптор е разрешено за преглеж­ 
даното превозно средство.  
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 — 21.08.2023 — 003.001 — 604  
№ Изпитване  Описание  Съответни изисквания  
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 — 21.08.2023 — 003.001 — 605  
ПРИЛОЖЕНИЕ  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 — 21.08.2023 — 003.001 — 606  
2. Маркировката за одобрение се поставя върху указателната табе лка на 
всеки комплект уреди и на всеки тахографски лист и върху всяка тахог­ 
рафска карта. Маркировката трябва да бъде незаличима и винаги д а бъде 
ясно четлива.  
3. Посочените по-долу размери на маркировката за одобрение (  1 ) са 
изразени в милиметри, като това са минимални стойности. Съотно­  
шението между размерите трябва да бъде запазено.
  ▼C1 
( 1 ) Показаните цифри служат само за насока.
 02016R0799 — BG — 21.08.2023 — 003.001 — 607  
II. СЕРТИФИКАТ ЗА ОДОБРЕНИЕ ЗА АНАЛОГОВИ ТАХОГРАФИ  
Държавата членка, предоставила одобрение, издава на заявителя с ертификат 
за одобрение съгласно образеца по-долу. Когато уведомява други държави 
членки за издадени одобрения или съответно за отменянето им, дъ ржавата 
членка използва копия на въпросния сертификат.  
СЕРТИФИКАТ ЗА ОДОБРЕНИЕ  
Наименование на компетентния орган  
Уведомление относно (  1 ): 
— одобрение на типа на уред за регистриране на данните за движе нието  
— отменяне на одобрението на типа на уред за регистриране на да нните за 
движението  
— одобрение на образец за тахографски лист  
— отменяне на одобрението на образец за тахографски лист  
Одобрение №:  
...................................  
1. Търговска марка или наименование  
2. Наименование на типа или модела  
3. Наименование на производителя  
4. Адрес на производителя  
5. Представено за одобрение на  
6. Изпитано в  
7. Дата и номер на изпитването/изпитванията  
8. Дата на одобрението  
9. Дата на отменяне на одобрението  
10. Тип или типове уреди за регистриране на данните за движение то, с 
които листът е предназначен да бъде използван  
11. Място  
12. Дата  
13. Приложени пояснителни документи  
14. Забележки (включително разположение на пломбите, ако е прил ожимо)  
(Подпис)  ▼C1 
( 1 ) Ненужното се зачертава.
 02016R0799 — BG — 21.08.2023 — 003.001 — 608  
III. СЕРТИФИКАТ ЗА ОДОБРЕНИЕ ЗА ЦИФРОВИ ТАХОГРАФИ  
Държавата членка, предоставила одобрение, издава на заявителя с ертификат 
за одобрение съгласно образеца по-долу. Когато уведомява други държави 
членки за издадени одобрения или съответно за отменянето им, дъ ржавата 
членка използва копия на въпросния сертификат.  
СЕРТИФИКАТ ЗА ОДОБРЕНИЕ ЗА ЦИФРОВИ ТАХОГРАФИ  
Наименование на компетентния орган  
Уведомление относно (  1 ): 
□ одобрение на:  □  отменяне на одобрението на:  
□ модел уред за регистриране на данните за 
движението  
□ компонент на уред за регистриране на данните за 
движението (  2 ) 
□ карта на водач  
□ карта за монтаж и настройки  
□ карта на превозвач  
□ контролна карта  
Одобрение №:  
1. Производствена марка или търговска марка  
2. Наименование на модела  
3. Наименование на производителя  
4. Адрес на производителя  
▼M1 
5. Представено за одобряване на  
▼C1 
6. Лаборатория(ии)  
7. Дата и номер на протокол от изпитване  
8. Дата на одобрението  
9. Дата на отменяне на одобрението  
10. Модел на уред(и) за регистриране на данните за движението, с 
който/които е предназначен да се използва компонентът  
11. Място  
12. Дата  
13. Приложени пояснителни документи  
14. Забележки (включително разположение на пломбите, ако е прил ожимо)  
(Подпис)  ▼C1 
( 1 ) Отбележете съответните полета. 
( 2 ) Посочете компонента, предмет на уведомлението.
 02016R0799 — BG — 21.08.2023 — 003.001 — 609  
IV. СЕРТИФИКАТ ЗА ОДОБРЕНИЕ ЗА ИНТЕЛИГЕНТНИ ТАХОГРАФИ  
Държавата членка, предоставила одобрение, издава на заявителя с ертификат 
за одобрение съгласно образеца по-долу. Когато уведомява други държави 
членки за издадени одобрения или съответно за отменянето им, дъ ржавата 
членка използва копия на въпросния сертификат.  
СЕРТИФИКАТ ЗА ОДОБРЕНИЕ ЗА ИНТЕЛИГЕНТНИ ТАХОГРАФИ  
Наименование на компетентния орган  
Уведомление относно (  1 ): 
□ одобрение на:  □  отменяне на одобрението на:  
□ модел уред за регистриране на данните за 
движението  
□ компонент на уред за регистриране на данните за 
движението (  2 ) 
□ карта на водач  
□ карта за монтаж и настройки  
□ карта на превозвач  
□ контролна карта  
Одобрение №:  
1. Производствена марка или търговска марка  
2. Наименование на модела  
3. Наименование на производителя  
4. Адрес на производителя  
▼M1 
5. Представено за одобряване на  
▼C1 
6. а) изпитвателна лаборатория за сертифициране за функциониран е 
б) изпитвателна лаборатория за сертифициране за сигурност  
в) изпитвателна лаборатория за сертифициране за оперативна съвм ес­ 
тимост  
7. а) дата и номер на сертификат за функциониране  
б) дата и номер на сертификат за сигурност  
в) дата и номер на сертификат за оперативна съвместимост  
8. Дата на одобрението  
9. Дата на отменяне на одобрението  
10. Модел на уред(и) за регистриране на данните за движението, с 
който/които е предназначен да се използва компонентът  
11. Място  
12. Дата  
13. Приложени пояснителни документи  
14. Забележки (включително разположение на пломбите, ако е прил ожимо)  
(Подпис)  ▼C1 
( 1 ) Отбележете съответните полета. 
( 2 ) Посочете компонента, предмет на уведомлението.