EUR-Lex Document 02016R0799-20230821

Този текст служи само за информационни цели и няма правно действие. Институциите на Съюза не носят
отговорност за неговото съдържание. Автентичните версии на съответните актове, включително техните преамбюли,
са версиите, публикувани в Официален вестник на Европейския съюз и налични в EUR-Lex. Тези официални
текстове са пряко достъпни чрез връзките, публикувани в настоящия документ
►B РЕГЛАМЕНТ ЗА ИЗПЪЛНЕНИЕ (ЕС) 2016/799 НА КОМИСИЯТА
от 18 март 2016 година
за прилагане на Регламент (ЕС) № 165/2014 на Европейския парламент и на Съвета по
отношение на определянето на изискванията за конструкцията, изпитването, монтирането,
експлоатацията и ремонта на тахографите и техните компоненти
(текст от значение за ЕИП)
(ОВ L 139, 26.5.2016 г., стр. 1)
Изменен със:
Официален вестник
№ страница дата
►M1 Регламент за изпълнение (ЕС) 2018/502 на Комисията от
28 февруари 2018 година
L 85 1 28.3.2018 г.
►M2 Регламент за изпълнение (ЕС) 2020/158 на Комисията от
5 февруари 2020 година
L 34 20 6.2.2020 г.
►M3 Регламент за изпълнение (ЕС) 2021/1228 на Комисията от 16 юли
2021 година
L 273 1 30.7.2021 г.
►M4 Регламент за изпълнение (ЕС) 2023/980 на Комисията от 16 май
2023 година
L 134 28 22.5.2023 г.
Поправен със:
►C1 Поправка, ОВ L 146, 3.6.2016 г., стр. 31 (2016/799)
►C2 Поправка, ОВ L 27, 1.2.2017 г., стр. 169 (2016/799)
02016R0799 — BG — 21.08.2023 — 003.002 — 1
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 5
4. Производителят или неговият представител предоставя на
органите по одобряването на типа, както и на организациите, отго­
варящи за издаването на сертификатите, посочени в член 12,
параграф 3 от Регламент (ЕС) № 165/2014, толкова на брой
тахографи или компоненти на тахографи, колкото са необходими,
за да може процедурата за одобряване на типа да се извърши по
задоволителен начин.
5. Когато производителят или неговият представител има за цел
одобряване на типа на определени компоненти или групи от
компоненти на тахограф, той предоставя на органите по одобря­
ването на типа другите компоненти, чийто тип е вече одобрен,
както и други части, необходими за конструкцията на окомплек­
тувания тахограф, за да могат въпросните органи да проведат необ­
ходимите изпитвания.
Член 5
Изменения на одобрения на типа
1. Производителят или неговият представител информира
незабавно органите по одобряването на типа, издали първона­
чалното одобрение на типа, за всяка промяна в програмното осигу­
ряване (софтуера) или апаратната част (хардуера) на тахографа или
в естеството на материалите, използвани за производството му,
които са записани в информационния пакет, и подава заявление
за изменение на одобрението на типа.
2. Органите по одобряването на типа могат да преразгледат или
разширят съществуващо одобрение на типа, или да издадат ново
одобрение на типа в зависимост от естеството и характеристиките
на измененията.
„Преразглеждане“ се прави, когато органът по одобряването на
типа счете, че промените в програмното осигуряване или в
апаратната част на тахографа или в естеството на материалите,
използвани за производството му, са незначителни. В такива
случаи органът по одобряването на типа издава преразгледани
документи от информационния пакет, като посочва естеството на
направените изменения и датата на одобряването им. За спазването
на това изискване се счита за достатъчна актуализирана версия на
информационния пакет в консолидиран вид, придружена от
подробно описание на направените изменения.
„Разширение“ се прави, когато органът по одобряването на типа
счете, че промените в програмното осигуряване или в апаратната
част на тахографа или в естеството на материалите, използвани за
производството му, са значителни. В такива случаи той може да
изиска да бъдат извършени нови изпитвания и да информира за
това производителя или представителя му. Ако изпитванията са
задоволителни, органът по одобряването на типа издава прераз­
гледан сертификат за одобрение на типа, съдържащ номер, съот­
ветстващ на издаденото разширение. В сертификата за одобрение
на типа се посочват причината за разширението и датата на изда­
ването му.
3. В указателя към информационния пакет се посочва датата на
най-новото разширение или преразглеждане на одобрението на
типа или датата на най-новото консолидиране на актуализираната
версия на одобрението на типа.
4. Когато заявените изменения на тахограф от одобрен тип или
на неговите компоненти биха довели до издаване на нов
сертификат за сигурност или за оперативна съвместимост, е необ­
ходимо ново одобрение на типа.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 6
Член 6
Влизане в сила
Настоящият регламент влиза в сила на двадесетия ден след деня на
публикуването му в Официален вестник на Европейския съюз.
Той се прилага от 2 март 2016 г.
▼M1
Приложение IВ обаче се прилага от 15 юни 2019 г., с изключение
на допълнение 16, което се прилага от 2 март 2016 г.
▼B
Настоящият регламент е задължителен в своята цялост и се прилага
пряко във всички държави членки.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 17
о) „контролна карта“ означава:
тахографска карта, издадена от органите на държава
членка на национален компетентен контролен орган,
която идентифицира контролния орган и евентуално —
конкретния негов служител, и която осигурява достъп до
данните, съхранени в паметта на тахографа или в картата
на водач, и евентуално — в картите за монтаж и
настройки, с цел тяхното прочитане, разпечатване и/или
изтегляне.
Тя следва също така да дава достъп до функцията за пътна
проверка на калибрирането и до данните на четеца за
връзка с цел ранно откриване от разстояние.
п) „общото време на прекъсване“ се изчислява в уредите за
регистриране на данните за движението като ( 1 ):
общото време на прекъсване в управлението е сумата от
периодите НА РАЗПОЛОЖЕНИЕ, на ПРЕКЪСВАНЕ/
ПОЧИВКА или на НЕИЗВЕСТНА ДЕЙНОСТ ( 2 ) от 15
или повече минути на даден водач от края на последния
му период НА РАЗПОЛОЖЕНИЕ, на ПРЕКЪСВАНЕ/
ПОЧИВКА или на НЕИЗВЕСТНА ДЕЙНОСТ ( 2 ) от 45
или повече минути (този период може да бъде разделен
в съответствие с Регламент (ЕО) № 561/2006).
При изчисленията се държи сметка, ако е необходимо, за
предишните дейности, записани на картата на водач.
Периодите на неизвестна дейност с отрицателно
времетраене (начало на периода с неизвестна дейност >
края на периода с неизвестна дейност) поради припок­
риване на времеви периоди между два различни уреда за
регистриране на данните за движението не се вземат
предвид при изчисленията.
Когато водачът не е вкарвал картата си, изчисленията се
основават на данните, записани в паметта по време на
текущия период, през който не е била вкарвана никаква
карта, като се отнасят към съответното четящо устройство;
р) „памет за данни“ означава:
електронно устройство за съхраняване на данни, вградено
в уредите за регистриране на данните за движението;
с) „електронен подпис“ означава:
данните, прибавени към блок от данни, или негово крип­
тографско преобразувание, което позволява на получателя
на този блок да получи доказателство за неговата автен­
тичност и достоверност;
т) „изтегляне на данни“ означава:
копиране, заедно с електронния подпис, на част или на
пълен набор файлове с данни, записани в паметта за
данни на бордовото устройство или в паметта на тахог­
рафската карта, при условие че при този процес не се
изменят или изтриват записани данни;
▼B
( 1 ) Този начин на изчисляване на времето на непрекъснато управление на МПС и на
общото време на прекъсване служи в уредите за регистриране на данните за
движението за изчисляване на предупреждението за времето на непрекъснато
управление на МПС. Той не предопределя юридическото тълкуване на тези
периоди. Може да бъдат използвани алтернативни начини за изчисляване на
времето на непрекъснато управление на МПС и на общото време на прекъсване
в замяна на тези определения, ако те са остарели вследствие на актуализиране на
останалото законодателство в дадената област.
( 2 ) Периодите на НЕИЗВЕСТНА ДЕЙНОСТ съответстват на периодите, през които
картата на водача не е била вкарвана в уред за регистриране на данните за
движението и за които няма извършено ръчно въвеждане на дейностите на водача.
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 20
ее) „периодичен технически преглед“ означава:
набор от действия, извършвани, за да се провери дали
тахографът работи правилно, дали неговите настройки
отговарят на параметрите на превозното средство, както
и дали към тахографа няма прикачени устройства за мани­
пулиране;
жж) „печатащо устройство“ означава:
компонент на уредите за регистриране на данните за
движението, който осигурява разпечатки на записаните в
паметта данни;
зз) „връзка с цел ранно откриване от разстояние“ означава:
комуникация между устройството за връзка с цел ранно
откриване от разстояние и четеца за връзка с цел ранно
откриване от разстояние по време на целенасочени пътни
проверки с цел дистанционно откриване на евентуална
манипулация или злоупотреба с уреди за регистриране на
данните за движението;
▼M3
ии) „устройство за връзка от разстояние“, „модул за връзка от
разстояние“ или „устройство за ранно откриване от
разстояние“ означава:
оборудването в бордовото устройство, използвано за
извършването на целенасочени пътни проверки;
▼B
йй) „четец за връзка с цел ранно откриване от разстояние“
означава:
системата, използвана от служителите на контролните
органи за извършването на целенасочени пътни проверки;
▼M3
кк) „подновяване на картата“ означава:
издаването на нова тахографска карта, когато срокът на
валидност на съществуваща карта изтича или тя не
функционира правилно и е била върната на органа,
който я е издал;
▼B
лл) „ремонт“ означава:
всякакъв ремонт на датчик за движение, на бордово
устройство или на кабел, който налага прекъсване на
неговото електрическо захранване, прекъсване на
връзката с други компоненти на тахографа или отваряне
на тахографа или бордовото устройство;
▼M3
мм) „замяна на картата“ означава:
издаването на нова тахографска карта, която заменя
съществуваща карта, която е обявена за изгубена,
открадната или за неправилно функционираща и която
не е била върната на органа, който я е издал;
▼B
нн) „сертифициране по отношение на сигурността“:
процесът, чрез който организация за сертифициране по
единни критерии удостоверява, че уредите за регистриране
на данните за движението (или компонент от тях) или изслед­
ваната тахографска карта отговарят на изискванията за
сигурност, формулирани в съответните профили за защита;
оо) „самоизпробване“ означава:
изпробвания, извършвани периодично и автоматично от
уредите за регистриране на данните за движението с цел
откриване на неизправности;
пп) „измерване на времето“ означава:
непрекъснат цифров запис на координираното
универсално време и дата (UTC);
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 22
— монтирано между бордовото устройство и мястото, в
което се генерират импулсите за скорост/разстояние от
вградени датчици или от алтернативни интерфейси,
— по отношение на бордовото устройство поведението на
адаптера е същото, като при свързване към бордовото
устройство на датчик за движение, който е в съот­
ветствие с разпоредбите на настоящото приложение и
допълнения 1 — 16 към него;
използването на такъв адаптер в описаните по-горе
превозни средства трябва да позволява монтажа и
правилната употреба на бордово устройство, което е в
съответствие с всички изисквания на настоящото
приложение,
при тези превозни средства интелигентният тахограф
включва кабели, адаптер и бордово устройство;
цц) „цялост на данните“ означава:
точността и непротиворечивостта на записаните данни,
указани от липсата на каквато и да е промяна в данните
между две обновявания на запис от данни. Целостта
означава, че данните са точно копие на оригиналната
версия, напр. че не са били повредени в процеса на
записване и прочитане от тахографската карта или
специално оборудване или при предаване по канал за
връзка;
▼M3
чч) резервирана за бъдеща употреба;
▼B
шш) интелигентна тахографска система означава:
уредите за регистриране на данните за движението, тахог­
рафските карти и наборът от всякакво пряко или непряко
взаимодействащо с тях оборудване по време на тяхното
производство, монтаж, използване, изпитване и проверка,
като например карти, четец за връзка с цел ранно
откриване от разстояние и всякакво друго оборудване за
изтегляне на данни, анализ на данни, калибриране, гене­
риране, управление или въвеждане на защитни елементи и
т.н.;
▼M3
щщ) „дата на въвеждане“ означава:
датата, определена в Регламент (ЕС) № 165/2014, от която
превозните средства, регистрирани за първи път, трябва да
са оборудвани с тахограф в съответствие с настоящия
регламент;
▼B
ъъ) защитен профил означава:
документ, който се използва като част от процедура за
сертифициране в съответствие с общите критерии, в
който е дадена независима от приложението спецификация
на изискванията за сигурност по отношение на гаранти­
рането на информацията;
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 24
06) Всяко вмъкване или свързване на функция или
устройство(а), одобрено(и) или не, във или към уреди
за регистриране на данните за движението, не трябва да
предизвиква смущения или да бъде в състояние да
смущава правилната и сигурна работа на уредите за
регистриране на данните за движението, или да бъде
в противоречие с разпоредбите на настоящия
регламент.
Потребителите на уредите за регистриране на данните
за движението указват своята самоличност посредством
тахографски карти.
07) Уредите за регистриране на данните за движението
дават избирателни права за достъп до данните и
функциите според типа и/или самоличността на потре­
бителя.
Уредите за регистриране на данните за движението записват и
съхраняват данни в своята памет, в устройството за кому­
никация от разстояние и в тахографски карти.
▼M3
Това се извършва в съответствие с приложимото законода­
телство на Съюза по отношение на защитата на данните и в
съответствие с член 7 от Регламент (ЕС) № 165/2014.
▼B
2.2 Функции
08) Уредите за регистриране на данните за движението
трябва да осигуряват следните функции:
— следене на поставянията и изважданията на картите,
— измерване на скорост, разстояние и определяне на
местоположение,
— измерване на времето,
— следене на дейностите, извършвани от водача,
— следене на състоянието при управление на МПС,
▼M3
— ръчно въвеждане на данни от водача:
— въвеждане на местоположението в началото
и/или в края на дневните периоди на работа,
— ръчно въвеждане на дейностите, извършвани от
водача, и на съгласието на водача за интерфейса
с ITS,
— въвеждане на особени условия,
— въвеждане на товаро-разтоварни операции,
▼B
— управление на блокировките, наложени от
превозвача,
— следене на контролните дейности,
— откриване на събития и/или на неизправности,
— вградени функции за изпробване и самоизпробване,
— четене на данни от паметта,
— записване и съхраняване на данните в паметта,
— четене от тахографските карти,
— записване и съхраняване на данните в тахог­
рафските карти,
— изобразяване на данните,
— отпечатване,
— предупреждаване,
— прехвърляне на данни към външни носители,
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 25
— връзка от разстояние за извършване на целена­
сочени пътни проверки,
— данни, прехвърляни към допълнителни устройства,
— калибриране,
— пътна проверка на калибрирането,
— сверяване на часовника,
▼M3
— следене на пресичането на граници,
— актуализация на софтуера.
▼B
2.3 Режими на работа
09) Уредите за регистриране на данните за движението
трябва да осигуряват следните четири режима на
работа:
— работен режим,
— контролен режим,
— режим на калибриране,
— режим „превозвач“.
10) Уредите за регистриране на данните за движението
трябва да превключват към следните режими на
работа според валидната тахографска карта, вкарана в
интерфейсното устройство за карта: За определянето на
режима на работа, поколението на тахографската карта
е без значение, при условие че вкараната карта е
валидна. Една карта за монтаж и настройки от първо
поколение винаги се счита за невалидна, когато се
вкара в бордово устройство от второ поколение.
Режим на работа
Процеп за карта на водач
Няма карта Карта на водач Контролна карта
Карта за монтаж
и настройки
Карта на
превозвач
П
ро
це
п
за
к
ар
та
н
а
вт
ор
ия
в
од
ач

Няма карта Работен Работен Контролен Калибриране Предприятие
карта на водач Работен Работен Контролен Калибриране Предприятие
Контролна
карта
Контролен Контролен Контролен (*) Работен Работен
Карта за
монтаж и
настройки
Калибриране Калибриране Работен Калиб­
риране (*)
Работен
Карта на
превозвач
„Предприятие“ „Предприятие“ Работен Работен „Пред­
приятие“ (*)
(*) В тези ситуации уредите за регистриране на данните за движението трябва да използват само тахографската карта,
поставена в процепа за карта на водач.
11) Уредите за регистриране на данните за движението
трябва да отхвърлят вкарани невалидни карти, като
обаче позволяват изобразяването, отпечатването и
изтеглянето на данни от карта с изтекъл срок.
12) Всички функции, изброени в 2.2, трябва да работят при
всички режими на работа, с изключение на:
— функцията за калибриране, която е достъпна само в
режима на калибриране,
— функцията за пътна проверка на калибрирането,
която е достъпна само в контролния режим,
— функцията за управление на блокиранията,
наложени от превозвача, която е достъпна само в
режим „превозвач“,
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 33
Във всеки един момент, съгласието на водача
(съответно на сервиза) може да бъде активирано или
дезактивирано чрез команди от менюто, при условие,
че е вкарана карта на водач (съответно карта за
монтаж и настройка).
Трябва да е възможно да се зададе дейност със
следните ограничения:
— видът на дейността трябва да бъде „РАБОТА“, „НА
РАЗПОЛОЖЕНИЕ“ или ПРЕКЪСВАНЕ/ПОЧИВКА;
— началото и краят на всяка дейност трябва да са в
рамките на периода между последното изваждане на
картата и нейното настоящо вкарване;
— не се позволява взаимно припокриване на дейности
във времето.
Ако е необходимо, при първото вкарване на неиз­
ползвана преди карта на водач (или карта за монтаж
и настройки) трябва да е възможно ръчно въвеждане.
Процедурата за ръчно въвеждане на дейности трябва да
включва толкова последователни стъпки, колкото е
необходимо за задаване на вида и момента, като час и
минути, на започване и завършване на всяка една
дейност. За титуляря на картата трябва да има
избираем вариант да не посочва дейност за която и да
е част от периода от време между последното
изваждане на картата и нейното настоящо вкарване.
По време на ръчното въвеждане, съответстващо на
вкарването на картата и, ако е необходимо, титулярят
на картата трябва да има възможност да зададе:
— място, където е завършил предишен дневен период
на работа, заедно със съответното време (като по
този начин се замества и валидира въведеното при
последното изваждане на картата),
— място, където започва текущият дневен период на
работа, заедно със съответното време (като по този
начин се валидира временното въвеждане при
последното изваждане на картата),
За мястото, където започва текущият дневен период на
работа, въведено при текущото вкарване на картата,
уредите за регистриране на данните за движението
трябва да показват настоящото местоположение на
превозното средство въз основа на информацията от
GNSS и на запаметената(ите) цифрова(и) карта(и) в
съответствие с точка 3.12.19 и трябва да поискат от
водач да потвърди или коригира ръчно мястото.
Ако титулярят на картата не въведе място, където
започва или е завършил периодът на работа, по време
на ръчните въвеждания във връзка с вкарването на
картата, това се счита за декларация, че периодът му
на работа не се е променил от последното изваждане на
картата. Следващото въвеждане на място, където е
завършил предишен дневен период на работа, трябва
да замести временното въвеждане, извършено при
последното изваждане на картата.
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 34
Ако е въведено място, то трябва да се запише в съот­
ветната тахографска карта.
Ръчното въвеждане трябва да бъде прекъснато ако:
— картата бъде извадена или,
— превозното средство се движи и картата е в процепа
за карта на водач.
Позволени са допълнителни прекъсвания — напр. след
изтичане на определен период от време, през който
потребителят не е бил активен. Ако ръчното
въвеждане бъде прекъснато, уредите за регистриране
на данните за движението трябва да валидират вече
въведените пълни записи за място и дейност (които
съдържат или еднозначно посочени място и време,
или вид, време на започване и време на завършване
на дейността).
Ако бъде поставена втора карта на водач или карта за
монтаж и настройки докато е в ход ръчното въвеждане
на дейности за вкарана преди това карта, трябва да е
позволено завършване на ръчното въвеждане за тази
предишна карта преди да започне ръчното въвеждане
за втората карта.
Титулярят на картата трябва да разполага с избираем
вариант за ръчно въвеждане по следната минимална
процедура:
— ръчно задаване на дейности в хронологична послед­
ователност за периода от последното изваждане на
картата до нейното настоящо вкарване,
— като време на започване на първата дейност трябва
да се зададе моментът на изваждане на картата. За
всяко следващо въвеждане времето на започване
автоматично трябва да се задава така, че непос­
редствено да следва времето на завършване за пред­
ишното въвеждане. За всяка дейност се избира и
задава нейният вид и времето на завършване.
Процедурата приключва, когато времето на завършване
на ръчно зададена дейност съвпадне с времето на
вкарване на картата.
Уредите за регистриране на данните за движението
трябва да позволяват на водачите и сервизите да
качват на ротационен принцип ръчно въведени данни,
които трябва да бъдат въведени по време на проце­
дурата чрез интерфейса с ITS, специфициран в
допълнение 13, и по избор — чрез други интерфейси.
Тогава уредите за регистриране на данните за
движението трябва да позволяват на титуляря на
картата да променя всяка една ръчно въведена
дейност до нейното валидиране чрез избор на
конкретна команда. След това трябва да е забранено
каквато и да е изменение.
▼B
3.6.3 Въвеждане на специфични условия
▼M3
62) Уредите за регистриране на данните за движението
трябва да позволяват на водача да въвежда в реално
време следните две специфични условия:
— „ИЗВЪН ОБХВАТ“ (начало, край)
— „ПЪТУВАНЕ С ФЕРИБОТ/ВЛАК“ (начало, край).
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 35
Не може да бъде зададено „ПЪТУВАНЕ С ФЕРИБОТ/
ВЛАК“, когато е зададено условието „ИЗВЪН
ОБХВАТ“. Ако е отворено условие „ИЗВЪН
ОБХВАТ“, уредите за регистриране на данните за
движението не трябва да позволяват на потребителите
да въведат начален флаг „ПЪТУВАНЕ С ФЕРИБОТ/
ВЛАК“.
Отвореното условие „ИЗВЪН ОБХВАТ“ трябва задъл­
жително да бъде затворено автоматично от уреда за
регистриране на данните за движението в случай на
изваждане или вкарване на карта на водач.
Ако е отворено условие „ИЗВЪН ОБХВАТ“, това води
до забрана на следните събития и предупреждения:
— управление без съответната карта,
— предупреждения, свързани с времето на непре­
къснато управление на МПС.
Водачът въвежда начален флаг „ПЪТУВАНЕ С
ФЕРИБОТ/ВЛАК“ веднага след избирането на
„ПРЕКЪСВАНЕ/ПОЧИВКА“ на ферибота или влака.
Отворено „ПЪТУВАНЕ С ФЕРИБОТ/ВЛАК“ трябва да
се приключи от уреда за регистриране на данните за
движението, когато възникне някоя от следните
ситуации:
— водачът завършва ръчно „ПЪТУВАНЕ С ФЕРИБОТ/
ВЛАК“, което трябва да стане при пристигане на
ферибота/влака в местоназначението, преди напус­
кането на ферибота/влака,
— отворено е условие „ИЗВЪН ОБХВАТ“,
— водачът изважда картата си,
— дейността на водача се изчислява като
„УПРАВЛЕНИЕ“ в продължение на една
календарна минута в съответствие с точка 3.4.
Ако в рамките на една календарна минута са въведени
повече от едно специфични условия от един и същи
вид, регистрира се само последното.
3.6.4 Въвеждане на товаро-разтоварна операция
62a) Уредите за регистриране на данните за движението
трябва да позволяват на водача да въвежда и
потвърждава в реално време информация, указваща,
че превозното средство е в процес на товарене, разто­
варване или че едновременно се извършват товарене и
разтоварване.
Ако в рамките на една календарна минута са въведени
повече от една товаро-разтоварни операции от един и
същи вид, регистрира се само последната.
62б) Операциите по товарене, разтоварване или едновре­
менното товарене и разтоварване се записват като
отделни събития.
62в) Товаро-разтоварната информация се въвежда преди
превозното средство да напусне мястото, където се е
извършила товаро-разтоварната операция.
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 43
За всяко от тези свързвания се регистрират следните данни:
— данни за идентификация на външно устройство за
GNSS:
— пореден номер,
— номер на одобрение,
— данни за свързаното външно устройство за GNSS:
— дата на свързването
3.12.2 Ключове и сертификати
101) Уредите за регистриране на данните за движението
трябва да могат да записват определен брой криптог­
рафски ключове и сертификати, както е посочено в
допълнение 11, част А и част Б.
3.12.3 Данни за вкарването и изваждането на картата на водач или
картата за монтаж и настройки
102) За всеки цикъл на вкарване-изваждане на дадена карта
на водач или карта за монтаж и настройки в уреда за
регистриране на данните за движението, последното
трябва да регистрира и записва в своята памет:
— името и презимето на титуляря на картата така,
както те са записани в картата,
— номера на картата, държавата членка, която я е
издала, и срокът на валидност, така както са
записани на картата,
— поколението на картата,
— датата и часа на вкарването,
— стойността от километражния брояч на превозното
средство в момента на вкарването на картата,
— процепа, в който се вкарва картата,
— датата и часа на изваждането ѝ,
— стойността от километражния брояч на превозното
средство в момента на изваждането на картата,
— следната информация относно последното превозно
средство, използвано от водача така, както е
записана в картата:
— регистрационния номер на превозното средство
(VRN) и държавата членка на регистрация,
— поколението на БУ (когато е налично),
— дата и час на изваждането на картата,
— флаг, указващ дали при вкарването на картата
титулярят на картата е въвел ръчно дейностите
или не.
103) Паметта трябва да може да запазва тези данни в
продължение на най-малко 365 дни.
104) Когато капацитетът за съхраняване на информация е
изчерпан, новите данни заместват най-старите данни.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 46
Събитие Правила за запис в паметта Данни, които се регистрират при всяко събитие
Вкарване на невалидна
карта
— 10-те най-скорошни събития. — дата и час на събитие,
— тип на картата(ите), номер, държава
членка, издала картата, и поколение
на картата, предизвикваща събитието.
— брой сходни събития, възникнали
същия ден
Конфликт, предизвикан
от карта
— 10-те най-скорошни събития. — дата и час на начало на събитието,
— дата и час на край на събитието,
— тип и номер на картата(ите), държава
членка, издала картата(ите), и
поколение на двете карти, пред­
извикващи събитието.
управление на МПС без
съответната карта
— най-продължителното събитие за
всеки от десетте последни дена на
възникване на това събитие,
— 5-те най-продължителни събития
през последните 365 дни.
— дата и час на начало на събитието,
— дата и час на край на събитието,
— тип и номер на картата(ите), държава
членка, издала картата(ите), както и
поколение на всяка карта, вкарана в
началото и/или в края на събитието,
— брой сходни събития, възникнали
същия ден.
Вкарване на карта по
време на управление на
МПС
— последното събитие за всеки от
десетте последни дена на възникване
на това събитие,
— дата и час на събитието,
— тип и номер на картата(ите), държава
членка, издала картата(ите),
поколение,
— брой сходни събития, възникнали
същия ден
▼M3
Неправилно
приключване на
последната картова
сесия
— 10-те най-скорошни събития. — дата и час на вкарване на картата,
— тип и номер на картата(ите), държава
членка, издала картата(ите),
поколение,
— данни относно последната сесия така,
както са прочетени от картата:
— дата и час на вкарване на картата.
▼B
Превишаване на
скоростта (1)
— най-сериозното събитие (тоест
събитието, при което е достигната
най-висока средна скорост) през
десетте последни дена на възникване
на това събитие,
— 5-те най-сериозни събития през
последните 365 дни.
— първото събитие, възникнало след
последното калибриране
— дата и час на начало на събитието,
— дата и час на край на събитието,
— максимална скорост, измерена по
време на събитието,
— средноаритметична скорост, измерена
по време на събитието,
— тип и номер на картата, държава
членка, издала картата, и поколение
на картата на водач (ако е
приложимо),
— брой сходни събития, възникнали
същия ден.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 49
Неизправност Правила за запис в паметта
Данни, които се регистрират при всяка неиз­
правност
Неизправност на картата — 10-те последни неизправности на
картата на водач.
— дата и час на началото на неиз­
правност,
— дата и час на края на неизправност,
— тип и номер на картата(ите), държава
членка, издала картата(ите),
поколение.
неизправности в уредите
за регистриране на
данните за движението
— 10-те последни неизправности за
всеки тип неизправност,
— първата неизправност след последното
калибриране.
— дата и час на началото на неиз­
правност,
— дата и час на края на неизправност,
— тип на неизправността,
— тип и номер на картата(ите), държава
членка, издала картата(ите), както и
поколение на всяка карта, вкарана в
началото и/или в края на неизправ­
ността,
3.12.10 Данни за калибриране
119) Уредът за регистриране на данните за движението
записва и съхранява данни в своята памет, имащи
отношение към:
— параметрите на калибрирането, известни в момента
на пускането,
— своето най-първо калибриране след пускането си,
— първото си калибриране в превозното средство, на
което се намира в момента (идентифицирано от
неговия VIN),
— 20-те последни калибрирания (ако няколко калиб­
рирания се извършват в рамките на един календарен
ден, са записват само първото и последното за
деня).
120) За всяко от тези калибрирания се регистрират следните
данни:
— цел на калибрирането (пускане, първо монтиране,
монтиране, периодични технически прегледи),
— наименование и адрес на сервиза,
— номер на картата за монтаж и настройки, държава
членка, която я е издала, и срок на валидност на
картата,
— идентификация на превозното средство,
— актуализирани или потвърдени параметри: w, k, l,
размер на гумите, регулировка на ограничителя на
скоростта, брояч на километрите (стара и нова
стойност), дата и час (стара и нова стойност),
— типовете и идентификаторите на всички поставени
пломби,
▼M3
— серийните номера на датчика за движение,
външното устройство за GNSS (ако има такова) и
външното устройство за връзка от разстояние (ако
има такова),
— типа на товара по подразбиране, свързан с
превозното средство (товар от стоки или пътници),
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 58
157) При изобразяването на данните на уредите за регис­
триране на данните за движението трябва да се
използват пиктограмите или комбинациите от
пиктограми, изброени в допълнение 3. Могат да се
използват допълнителни пиктограми или комбинации
от пиктограми при положение, че те ся ясно
различими от горепосочените пиктограми или
комбинации от пиктограми.
158) Дисплеят трябва да бъде винаги включен, когато
превозното средство е в движение.
159) Уредите за регистриране на данните за движението
може да имат ръчна или автоматична функция за
изключване на дисплея, когато превозното средство не
е в движение.
Форматът на изобразяване на данните е специфициран
в допълнение 5.
3.15.1 Изобразяване по подразбиране
160) Когато не е необходимо да се показва друга
информация, уредите за регистриране на данните за
движението трябва да показват по подразбиране
следното:
— местното време (координирано универсално
време (UTC) + поправка, задавана от водача);
— режима на работа,
— текущата дейност на водача и на втория водач,
— информация относно водача:
— ако неговата текуща дейност е „управление на
МПС“ — текущото му време на непрекъснато
управление на МПС и текущото му общо време на
прекъсване,
— ако неговата текуща дейност не е „управление на
МПС“ — текущата продължителност на тази
дейност (от момента на нейното избиране) и
общото време на прекъсване.
161) Изобразяването на данните относно всеки водач трябва
да бъде ясно, просто и недвусмислено. Когато инфор­
мацията за водача и втория водач не може да бъде
изобразена едновременно, уредите за регистриране на
данните за движението трябва да изобразяват по
подразбиране информацията, отнасяща се за водача, и
трябва да позволяват на потребителя да изобрази
информацията относно втория водач.
162) Когато широчината на изобразяването не е достатъчна
за извеждане по подразбиране на режима на работа,
уредите за регистриране на данните за движението
трябва за кратко да изобразяват новия режим при
всяка негова промяна.
163) При вкарване на нова карта уредите за регистриране на
данните за движението трябва да изобразяват за кратко
време името на титуляря на картата.
164) Когато е отворено условие „ИЗВЪН ОБСЕГ“ или
„ПЪТУВАНЕ С ФЕРИБОТ/ВЛАК“, по подразбиране
трябва да се изобрази съответната пиктограма, за да
се укаже, че това конкретно условие е отворено
(текущата активна дейност на водача може да не се
изобразява в същото време).
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 63
199) Данните, необходими за извършване на целенасочени
пътни проверки, трябва да се отнасят за:
— последния опит за нарушаване на сигурността,
— най-дълго прекъсване на електрическото захранване,
— неизправност на датчика,
— грешка в данните за движението,
— противоречие в данните за движението на
превозното средство,
— управление без валидна карта,
— вкарване на карта по време на управление на МПС,
— данни за сверяването на часовника,
— данни за калибриране, включително датите на
последните две записани калибрирания,
— регистрационния номер на превозното средство,
— скоростта, регистрирана от тахографа ,
▼M3
— местоположение на превозното средство,
— индикация дали понастоящем водачът може да е в
нарушение на времената на управление.
3.20 Обмен на данни с допълнителни външни устройства
200) Уредите за регистриране на данните за движението
трябва също така да бъдат оборудвани с интерфейс с
ITS в съответствие с допълнение 13, който да позволява
регистрираните или генерираните данни от тахографа
или от тахографските карти да се използват от
външно устройство.
В работен режим трябва да е необходимо съгласието на
водача за предаването на лични данни чрез интерфейса
с ITS. Въпреки това съгласието на водача не се прилага
за данните от тахографа или картата за достъпа в режим
„контрол“, „превозвач“ или „калибриране“. Правата за
достъп до данните и до различните функции за тези
режими са дадени в изисквания 12 и 13.
За данните за ITS, предоставяни чрез същия интерфейс,
важат следните изисквания:
— лични данни се предоставят само след като е било
дадено проверимото съгласие на водача, приемайки,
че личните данни могат да напуснат мрежата на
превозното средство.
Набор от избрани съществуващи данни, който може
да бъде на разположение чрез интерфейса с ITS, и
класификацията на данните като лични или нелични
са дадени в допълнение 13. Могат също така да
бъдат на разположение и допълнителни данни, в
допълнение на набора от данни, предвиден в
допълнение 13. Производителят на бордовото
устройство класифицира тези данни като „лични“
или „нелични“, при наличието на съгласие на
водача, приложимо за данните, класифицирани
като „лични“,
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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 Дания NL Нидерландия
D
EST
Германия
Естония
A
PL
Австрия
Полша
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 70
GR Гърция P
RO
SK
SLO
Португалия
Румъния
Словакия
Словения
E Испания FIN Финландия
F
HR
H
Франция
Хърватия
Унгария
S Швеция
IRL Ирландия UK Обединено
кралство
I Италия
230) информация, специфична за издадената карта, номе­
рирана както следва:
Карта на водач Контролна карта
Карта на превозвач или карта
за монтаж и настройки
1. фамилно име на водача наименование на
контролния орган
наименование на
превозвача или на сервиза
2. собствено(и) име(на) на
водача
фамилно име на
контрольора
(ако е приложимо)
фамилно име на титуляря
на картата
(ако е приложимо)
3. дата на раждане на
водача
собствено(и) име(на) на
контрольора
(ако е приложимо)
собствено(и) име(на) на
титуляря на картата
(ако е приложимо)
4.a дата на начало на валидността на картата
4.б срок на валидност на картата
4.в наименование на органа, който я е издал (може да се отпечата на обратната
страна)
4.г номер, различен от указания в точка 5, по административни причини (незадъл­
жително)
5.а Номер на свидетелството
за управление на МПС
(към датата на издаване
на картата на водач)
— —
5.б Номер на картата
6. Снимка на водача снимка на контрольора
(незадължително)
снимка на монтьора (неза­
дължително)
7. Подпис на титуляря (незадължително)
8. Обичайно място на
пребиваване или
пощенски адрес на
титуляря (незадъл­
жително)
Пощенски адрес на
контролния орган
Пощенски адрес на
превозвача или на сервиза
231) датите трябва да са написани в следния формат „дд/
мм/гггг“ или „дд.мм.гггг“ (ден, месец, година).
Обратната страна трябва да съдържа:
232) легенда на номерираните позиции, налични върху
лицевата страна на картата;
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 71
233) с изрично писмено съгласие на титуляря на картата,
може да бъде добавена и информация, която не е
свързана с администрирането на картата, при
положение че това добавяне не променя с нищо изпол­
зването на модела като тахографска карта.
234) Преобладаващите цветове на фона при отпечатването
на тахографските карти трябва да бъдат както следва:
— карта на водач: бял,
— контролна карта: син,
— карта за монтаж и настройки: червен,
— карта на превозвач: жълт.
235) Тахографските карти трябва да имат следните елементи
на защита на тялото на картата срещу подправяне и
фалшифициране:
— фон със защитни характеристики, включващ мотиви
с плетеници (гилоши) от тънки линии и ирисов
печат,
— припокриване на фоновия защитен печат и на
снимката,
— поне една двуцветна линия с микропечат.
► (1) M1
► (2) M3
236) След консултация с Комисията държавите членки могат
да добавят цветове или маркировки, като например
националните символи и защитни елементи, без това
да засяга другите разпоредби на настоящото
приложение.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 76
— Неправилно приключване на предишна сесия
(когато събитието засяга дадената карта),
— Прекъсване на електрическото захранване,
— Грешка в данните за движението,
— Опити за нарушаване на сигурността.
261) Картата на водач трябва да позволява съхраняването на
следните данни за тези събития:
— Код на събитието,
— Дата и час на начало на събитието (или на вкар­
ването на картата в случай, че в този момент
събитието е било текущо),
— Дата и час на край на събитието (или на изваж­
дането на картата в случай, че в този момент
събитието е било текущо),
— VRN и държава членка, извършила регистрацията
на превозното средство, в което събитието е
настъпило.
Забележка: За събитието „Припокриване във времето“:
— Датата и часът на началото на събитието трябва да
съответстват на датата и часа на изваждане на
картата от предишното превозно средство,
— Датата и часът на края на събитието трябва да съот­
ветстват на датата и на часа на вкарването на
картата в настоящото превозно средство,
— Данните за превозното средство трябва да съот­
ветстват на настоящото превозно средство, в което
събитието се е случило.
Забележка: За събитието „Неправилно приключване на
предишната сесия“:
— Датата и часът на началото на събитието трябва да
съответстват на датата и на часа на вкарването на
картата, съответстващо на неправилно приклю­
чената сесия,
— Датата и часът на края на събитието трябва да съот­
ветстват на датата и на часа на вкарването на
картата за сесията, по време на която събитието е
засечено (текуща сесия),
— Данните за превозното средство трябва да съот­
ветстват на превозното средство, в което сесията
не е била приключена правилно.
262) Картата на водач трябва да позволява съхраняването на
данните за шестте последни събития от всеки тип (т.е.
36 събития).
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 81
— Вкарване на карта по време на управление на МПС
(когато събитието засяга дадената карта),
— Неправилно приключване на предишна сесия
(когато събитието засяга дадената карта),
— Прекъсване на електрическото захранване,
— Грешка в комуникацията с устройството за връзка
от разстояние,
— Събитие „Липса на информация за местополо­
жението от приемник на сигнали от GNSS“
— Грешка в комуникацията с външното устройство за
GNSS
— Грешка в данните за движението,
— Противоречие в данните за движението на
превозното средство
— Опити за нарушаване на сигурността,
— Времеви конфликт.
286) Картата на водач трябва да позволява съхраняването на
следните данни за тези събития:
— Код на събитието,
— Дата и час на начало на събитието (или на вкар­
ването на картата в случай, че събитието е било
текущо за този момент),
— Дата и час на край на събитието (или на изваж­
дането на картата в случай, че в този момент
събитието е било текущо),
— VRN и държава членка, извършила регистрацията
на превозното средство, в което събитието е
настъпило.
Забележка: За събитието „Припокриване във времето“:
— Датата и часът на началото на събитието трябва да
съответстват на датата и часа на изваждане на
картата от предишното превозно средство,
— Датата и часът на края на събитието трябва да съот­
ветстват на датата и на часа на вкарването на
картата в настоящото превозно средство,
— Данните за превозното средство трябва да съот­
ветстват на настоящото превозно средство, в което
събитието се е случило.
Забележка: За събитието „Неправилно приключване на
предишната сесия“:
— Датата и часът на началото на събитието трябва да
съответстват на датата и на часа на вкарването на
картата, съответстващо на неправилно приклю­
чената сесия,
— Датата и часът на края на събитието трябва да съот­
ветстват на датата и на часа на вкарването на
картата за сесията, по време на която събитието е
засечено (текуща сесия),
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 104
411) Ако за едно от събитията, изброени в глава 3.9
(„Откриване на събития и/или неизправности“), е уста­
новено, че се е случило след последното инспектиране,
и то се счита от производителите на тахографи и/или от
националните органи за потенциално излагащо на риск
сигурността на уредите, сервизът трябва:
а. да извърши съпоставка на данните за идентификация
на датчика за движение от свързания към предава­
телната кутия датчик за движение, с тези от сдвоения
датчик за движение, регистриран в бордовото
устройство.
б. да провери дали информацията, записана върху
монтажната табелка, съответства на информацията,
съдържаща се в записа от бордовото устройство;
в. да провери дали серийният номер на датчика за
движение и номерът на одобрението му, ако са отпе­
чатани върху корпуса на датчика за движение, съот­
ветстват на информацията, записана в паметта за
данни на бордовото устройство;
г. да сравни идентификационните данни, отбелязани
върху указателната табелка на външното устройство
за GNSS, ако има такова, с тези, записани в паметта
за данни на бордовото устройство;
412) Сервизите трябва да записват в своите протоколи от
проверки всички констатации относно счупени пломби
или за устройства за манипулиране. Тези протоколи
трябва да се съхраняват от сервизите поне две години
и да се предоставят на компетентния орган при всяко
поискване.
413) Тези проверки трябва да включват калибриране и
превантивна замяна на пломбите, за чието монтиране
са отговорни сервизите..
6.5 Измерване на грешките
414) Измерването на грешките при монтирането и по време
на използването трябва да се осъществява при следните
условия, които се разглеждат като стандартни условия
на изпитване:
— превозно средство без товар, в готовност за
движение,
— налягане в гумите в съответствие с указанията на
производителя,
— износване на гумите в границите, разрешени от
националното законодателство,
— движение на превозното средство:
— превозното средство трябва да се движи напред под
действие на собствения си двигател, по права линия
и върху равна повърхност със скорост 50 ± 5 km/h.
Измереното разстояние трябва да бъде най-малко
1 000 m.
— при положение са със сходна точност, за това
изпитание могат също така да бъдат използвани
други методи, като например подходящ изпит­
вателен стенд.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 106
8 ОДОБРЕНИЕ НА ТИПА НА УРЕДИТЕ ЗА РЕГИСТРИРАНЕ
НА ДАННИТЕ ЗА ДВИЖЕНИЕТО И НА ТАХОГРАФСКИТЕ
КАРТИ
8.1 Общи положения
▼M1
За целите на настоящата глава под „уреди за регистриране на
данните за движението“ се имат предвид уредите за регис­
триране на данните за движението или техните компоненти.
Не се изисква одобрение на типа на кабела или кабелите,
свързващи датчика за движение с бордовото устройство,
външното устройство за GNSS с бордовото устройство или
външното устройство за връзка от разстояние с бордовото
устройство. Хартията, използвана в уредите за регистриране
на данните за движението, се приема като компонент на
уредите за регистриране на данните за движението.
Всеки производител може да поиска одобрение на типа на един
или повече компоненти на уредите за регистриране на данните
за движението с всеки друг компонент или компоненти на
такива уреди, при условие че всеки компонент отговаря на
изискванията от настоящото приложение. Като алтернатива,
производителите могат да поискат и одобряване на типа на
уредите за регистриране на данните за движението.
Както се посочва в член 2, определение 10 от настоящия
регламент, бордовите устройства могат да включват различни
компоненти. С каквито и компоненти да е сглобено бордовото
устройство, външната антена и (ако е приложимо) високочес­
тотният разклонител за антената, свързан с приемника на
сигнали от GNSS или с устройството за връзка от разстояние,
не са част от одобрението на типа на бордовото устройство.
При все това производителите, получили одобрение на типа за
бордово устройство, трябва да поддържат публично достъпен
списък на съвместимите антени и високочестотни разклонители
за всяко получило одобрение на типа бордово устройство,
външно устройство за GNSS и външно устройство за връзка
от разстояние.
▼B
425) Уредите за регистриране на данните за движението
трябва да се представят за одобряване заедно с
всички свои компоненти, както и с всички допъл­
нителни устройство, вградени в тях.
426) Одобрението на типа на уреди за регистриране на
данните за движението и на тахографски карти трябва
да включва изпитвания, свързани със сигурността,
изпитвания на функционирането и изпитвания за
оперативна съвместимост. Положителните резултати
от всяко от тези изпитвания се удостоверяват чрез
съответен сертификат.
▼M1
427) Органите по одобряването на типа на държавите членки
не предоставят сертификат за одобряване на типа, при
положение че при тях няма:
— сертификат за сигурност (ако съгласно настоящото
приложение се изисква такъв),
— сертификат за функциониране,
— сертификат за оперативна съвместимост (ако
съгласно настоящото приложение се изисква такъв),
за уредите за регистриране на данните за движението
или за тахографската карта, за които се иска одобряване
на типа.
▼B
428) Всяка промяна на софтуера или хардуера, или на мате­
риалите, използвани при производството, трябва да
бъде съобщена предварително на органа, който е
издал одобрение на типа на уредите. Този орган
трябва да потвърди на производителя разширяването
на одобрението на типа или може да поиска актуали­
зиране или потвърждаване на сертификатите за
функционирането, сигурността и/или оперативната
съвместимост.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 110
456) След изтичане на този период, ако всички въпросни
продукти са оперативно съвместими, всички съответни
сертификати за оперативна съвместимост стават окон­
чателни.
457) Ако по време на този период се появят неизправности,
свързани с оперативната съвместимост, лабораторията,
натоварена с провеждането на изпитванията за
оперативна съвместимост, трябва да определи
причините за проблемите с помощта на всички
участващи производители и да прикани последните да
направят необходимите промени.
458) Ако в края на този период проблемите, свързани с
оперативната съвместимост, все още са налице, лабора­
торията, натоварена с провеждането на изпитванията, в
сътрудничество със заинтересованите производители и
с органите по одобряването на типа, определя
причините за неизправностите, свързани с оперативната
съвместимост, и определя промените, които всеки заин­
тересован производител трябва да направи. Търсенето
на технически решения може да продължи най-много
два месеца, след което Комисията, при липса на общо
решение и след консултация с лабораторията, нато­
варена с извършването на изпитванията за оперативна
съвместимост, решава на кой(кои) уред(и) и карти ще
се издаде окончателен сертификат за оперативна
съвместимост, като уточнява причините за своя избор.
459) Всяко искане за извършване на изпитвания за
оперативна съвместимост, заведено от лабораторията
във времето от края на периода от четири месеца
след издаване на първия временен сертификат за
оперативна съвместимост до датата на вземане на
решение от Комисията, посочена в изискване 455, се
отлага до решаване на първоначалните проблеми,
свързани с оперативната съвместимост. Тези искания
след това се обработват в реда на тяхното завеждане.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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). Когато
този запис е най-старият дневен запис, за стойността на activityPre­
viousRecordLength трябва да се зададе 0.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 128
CardBorderCrossingRecords е наборът от записи в картата за
пресичане на граници.
2.11б. CardBorderCrossingRecord
Поколение 2, версия 2:
Информация, съхранена на карта на водач или карта за монтаж и
настройки и отнасяща се до пресичането на граници от превозното
средство, когато то е пресекло границата на държава (изисквания
147б, 306д и 356д от приложение IВ).
countryLeft е държавата, която превозното средство е напуснало,
или „няма налична информация“ съгласно изискване 147б от
приложение IB. „Останалата част на света“ (NationNumeric код
„FF“H по шестнайсетичната бройна система) се използва, когато
бордовото устройство не е в състояние да определи държавата, в
която се намира превозното средство (напр. настоящата държава не
е част от съхранените цифрови карти).
countryEntered е държавата, в която е влязло превозното средство,
или държавата, в която се намира превозното средство в момента на
вкарването на картата. „Останалата част на света“ (NationNumeric
код „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.002 — 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.002 — 130
2.17. CardDriverActivity
Информация, съхранена на карта на водач или карта за монтаж и
настройки и отнасяща се до дейностите на водача (изисквания 267,
268, 292, 293, 321 и 344 от приложение 1В).
activityPointerOldestDayRecord е спецификацията на началото на
мястото на съхранение (брой на байтовете от началото на низа) на
най-стария пълен дневен запис в низа activityDailyRecords. Макси­
малната стойност съответства на дължината на низа.
activityPointerNewestRecord е спецификацията на началото на
мястото на съхранение (брой на байтовете от началото на низа) на
най-скорошния дневен запис в низа activityDailyRecords. Макси­
малната стойност съответства на дължината на низа.
activityDailyRecords е мястото, което е налично за съхранение на
данните относно дейностите на водача (структура на данни: CardAc­
tivityDailyRecord) за всеки календарен ден, през който картата е
била използвана.
Присвояване на стойност: този низ от октети се попълва циклично
със записи от CardActivityDailyRecord. При първото използване
съхранението започва на първия байт на низа. Следващите записи
се запаметяват в края на предишния. Когато низът се запълни,
съхранението продължава от първия байт на низа, независимо от
прекъсването вътре в елемент от данни. Преди да се въведат нови
данни за дейността в низа (като се разшири текущият activityDaily­
Record или като се въведе нов activityDailyRecord), които заместват
по-старите данни за дейността, е необходимо да се актуализира
activityPointerOldestDayRecord, за да се отрази новото местопо­
ложение на най-стария пълен дневен запис, и трябва да се нулира
activityPreviousRecordLength на този (нов) най-стар пълен дневен
запис.
2.18. CardDrivingLicenceInformation
Информация, съхранена на карта на водач и отнасяща се до свиде­
телството за управление на титуляря на картата (изисквания 259 и
284 от приложение 1В).
drivingLicenceIssuingAuthority е компетентният орган за издаване
на свидетелството за управление.
drivingLicenceIssuingNation е националността на органа, издал
свидетелството за управление.
drivingLicenceNumber е номерът на свидетелството за управление.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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, 322
и 345 от приложение 1В).
Поколение 1:
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 155
Неизправности във връзка с карта,
Няма допълнителна информация,
RFU,
RFU,
Зависи от производителя.
▼M3
Поколение 2, версия 1:
▼M1
Общи събития,
Няма допълнителна информация,
Вкарване на невалидна карта,
Конфликт, предизвикан от картата,
Припокриване във времето,
Управление без съответната карта,
Вкарване на карта по време на управление,
Неправилно приключена последна картова сесия,
Превишаване на скоростта,
Прекъсване на електрическото захранване,
Грешка в данните за движението,
Конфликт относно движението на превозното средство,
Времеви конфликт (GNSS/вътрешния часовник на бордовото устройство),
Грешка в комуникацията с устройството за връзка от разстояние,
Липса на информация за местоположението от приемник на сигнали от GNSS,
Грешка в комуникацията с външното устройство за GNSS,
RFU,
Опити за нарушаване на сигурността, свързани с бордовото устройство,
Няма допълнителна информация,
Неуспешна процедура по удостоверяване на датчика за движение,
Неуспешна процедура по удостоверяване на тахографската карта,
Неразрешена смяна на датчика за движение,
Грешка във връзка с целостта на входящите данни на картата
Грешка във връзка с целостта на съхранените данни на потребител,
Грешка при вътрешно прехвърляне на данни,
Неразрешено отваряне на корпус,
Възпрепятстване на работата на хардуера,
Установяване на вмешателство във връзка с GNSS,
Неуспешна процедура по удостоверяване на външно устройство за GNSS,
Изтекъл сертификат на външно устройство за GNSS,
RFU,
Опити за нарушаване на сигурността, свързани с датчика за движение,
Няма допълнителна информация,
Неуспешно удостоверяване,
Грешка във връзка с целостта на съхранените данни,
Грешка при вътрешно прехвърляне на данни,
Неразрешено отваряне на корпус,
Възпрепятстване на работата на хардуера,
RFU,
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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
Код, позволяващ да се разбере дали титулярят на картата ръчно е
въвел дейностите на водача при вкарване на картата (изискване 081
от приложение 1Б и изискване 102 от приложение 1В).
Присвояване на стойност: липса на допълнителна информация.
2.94. ManufacturerCode
Код за идентификация на производителя на оборудване от одобрен
тип.
Лабораторията, компетентна за изпитванията за оперативна съвмес­
тимост, поддържа и публикува на своя уебсайт списъка с кодове на
производителите (изискване 454 от приложение 1В).
Разработчиците на тахографско оборудване получават временно
ManufacturerCodes след подадена заявка до лабораторията,
компетентна за изпитванията за оперативна съвместимост.
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 171
recordSize е размерът на OdometerValueMidnight в байтове.
noOfRecords е броят на записите в набора от записи.
records е наборът от записи на OdometerValueMidnight.
2.116. OverspeedNumber
Брой на събитията „превишаване на скоростта“ след последната
проверка за превишаването на скоростта.
Присвояване на стойност: 0 означава, че никакво събитие „преви­
шаване на скоростта“ не е настъпило след последната проверка за
превишаването на скоростта, 1 означава, че едно събитие от този
тип е настъпило след последната проверка за превишаването на
скоростта … 255 означава, че броят на събитията „превишаване
на скоростта“, настъпили след последната проверка за превиша­
ването на скоростта, е равен на 255 или надвишава тази стойност.
▼M3
2.116а. PlaceAuthRecord
Информация относно местоположението в началото или в края на
един дневен период на работа (изисквания 108, 271, 296, 324 и 347
от приложение 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.002 — 172
entryTime е датата и часът, свързани с въвеждането (които са
същата дата и час, както в съответния PlaceRecord).
authenticationStatus е статусът на удостоверяването на автентич­
ността на записаното местоположение по GNSS.
▼B
2.117. PlaceRecord
Информация относно местоположението в началото или в края на
един дневен период на работа (изисквания 108, 271, 296, 324 и 347
от приложение 1В).
Поколение 1:
entryTime е датата и часът във връзка с въведените данни.
entryTypeDailyWorkPeriod е типът въведени данни.
dailyWorkPeriodCountry е въведената държава.
dailyWorkPeriodRegion е въведеният регион.
vehicleOdometerValue е стойността от километражния брояч в часа
на въвеждане на местоположението.
Поколение 2:
В допълнение към поколение 1 се използва следният компонент:
entryGNSSPlaceRecord е записаното местоположение и час.
▼M3
2.117а. PositionAuthenticationStatus
Поколение 2, версия 2:
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 191
Поколение 2, версия 2:
В допълнение към поколение 1 се използват следните елементи от
данни:
sensorSerialNumber е серийният номер на датчик за движение,
свързан с бордовото устройство в края на калибрирането.
sensorGNSSSerialNumber е серийният номер на външното
устройство за GNSS, свързано с бордовото устройство в края на
калибрирането (ако има такова).
rcmSerialNumber е серийният номер на устройството за връзка от
разстояние, свързано с бордовото устройство в края на калибри­
рането (ако има такова).
sealDataVu дава информация за пломбите, поставени върху
различните компоненти на превозното средство.
byDefaultLoadType е типът на товара по подразбиране на
превозното средство (присъства само във версия 2).
calibrationCountry е държавата, в която е извършено калибри­
рането.
calibrationCountryTimestamp е датата и часът, когато от
приемника на сигнали от GNSS е предоставено местоположението,
използвано за определяне на държавата, в която е извършено калиб­
рирането.
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 207
cardNumberAndGenDriverSlot идентифицира картата, включително
поколението ѝ, вкарана в процепа за водача.
cardNumberAndGenCodriverSlot идентифицира картата, вклю­
чително поколението ѝ, вкарана в процепа за втория водач.
countryLeft е държавата, която превозното средство е напуснало,
въз основа на последната налична позиция преди установяването на
пресичането на граница. „Останалата част на света“ (NationNumeric
код „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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 212
2.209. VuManufacturerAddress
Адрес на производителя на бордовото устройство.
Присвояване на стойност: не е указана.
2.210. VuManufacturerName
Наименование на производителя на бордовото устройство.
Присвояване на стойност: не е указана.
2.211. VuManufacturingDate
Дата на производство на бордовото устройство.
Присвояване на стойност: не е указана.
2.212. VuOverSpeedingControlData
Информация, съхранена в бордово устройство и отнасяща се за
събитията „превишаване на скоростта“, настъпили след извършване
на последната проверка за превишаване на скоростта (изискване 095
от приложение 1Б и изискване 117 от приложение 1В).
lastOverspeedControlTime е датата и часът на последната проверка
за превишаване на скоростта.
firstOverspeedSince е датата и часът на първото превишаване на
скоростта след последната проверка за превишаване на скоростта.
numberOfOverspeedSince е броят на събитията „превишаване на
скоростта“ след последната проверка за превишаване на скоростта.
2.213. VuOverSpeedingControlDataRecordArray
Поколение 2:
VuOverSpeedingControlData плюс метаданните, използвани в
протокола за изтегляне на данни.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 224
Поколение 2:
В допълнение към поколение 1 се използват следните елементи от
данни:
sensorGNSSSerialNumber идентифицира външното устройство за
GNSS.
rcmSerialNumber идентифицира модула за връзка от разстояние.
sealDataVu дава информация за пломбите, поставени върху
различните компоненти на превозното средство.
2.237. WorkshopCardHolderIdentification
Информация, съхранена на карта за монтаж и настройки и отнасяща
се за идентификация на титуляря на картата (изисквания 311 и 334
от приложение 1В).
workshopName е наименованието на сервиза на титуляря на
картата.
workshopAddress е адресът на сервиза на титуляря на картата.
cardHolderName е фамилията и името (и презимето) на титуляря
(например името на механика).
cardHolderPreferredLanguage е предпочитаният език на титуляря
на картата.
2.238. WorkshopCardPIN
Персонален идентификационен номер на картата за монтаж и
настройки (изисквания 309 и 332 от приложение 1В).
Присвояване на стойност: PIN, известен на титуляря на картата,
запълнен отдясно със серия от байтове „FF“, която може да
съдържа до 8 байта.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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 — Балтийски регион 13
ISO/IEC 8859-15 латиница 9 15
ISO/IEC 8859-16 латиница 10 — Югоизточна Европа 16
KOI8-R латиница/кирилица 80
KOI8-U латиница/кирилица 85
5. КОДИРАНЕ
Ако се прилагат правилата за кодиране ASN.1, всички определени
типове данни трябва да се кодират съгласно приведения в съот­
ветствие вариант на стандарт ISO/IЕС 8825-2.
6. ИДЕНТИФИКАТОРИ НА ОБЕКТИ И ИДЕНТИФИКАТОРИ НА
ПРИЛОЖЕНИЯ
6.1. Идентификатори на обекти
Идентификаторите на обекти (ИО), посочени в тази глава,
се прилагат само към поколение 2. Тези ИО са определени в
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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 00 Нормална обработка
61 XX Нормална обработка. ХХ = брой на наличните байтове на
отговора
62 81 Предупреждение за обработката. Възможно е част от
върнатите данни да са увредени
63 00 Удостоверяването е неуспешно (предупреждение)
63 CX Грешка при CHV (PIN). Брояч на оставащите опити,
осигуряван от ‘X’
64 00 Грешка при изпълнението — непроменено състояние на
енергонезависимата памет. Грешка в целостта на данните
65 00 Грешка при изпълнението — променено състояние на енер­
гонезависимата памет
65 81 Грешка при изпълнението — променено състояние на енер­
гонезависимата памет. Неизправност на паметта
66 88 Грешка по сигурността: грешна криптографска контролна
сума (по време на защитен обмен
на съобщения) или
грешен сертификат (по време на
проверката на сертификата) или
грешна криптограма (по време на
външното удостоверяване) или
грешен цифров подпис (по време
на проверката на подписа)
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 242
SW1 SW2 Значение
67 00 Грешна дължина (грешна Lc или Le)
68 83 Очаква се последната команда от веригата
69 00 Забранена команда (няма възможност за отговор при Т=0)
69 82 Незадоволително състояние по отношение на сигурността
69 83 Блокиран метод за удостоверяване
69 85 Неизпълнени условия за използване
69 86 Неразрешена команда (няма активен елементарен файл)
69 87 Липса на очакваните обекти от данни при защитения обмен
на съобщения
69 88 Неправилни обекти от данни при защитения обмен на
съобщения
6A 80 Неправилни параметри в поле за данни
6A 82 Неоткриваем файл
6A 86 Грешни параметри P1-P2
6A 88 Неоткриваеми указани данни
6B 00 Грешни параметри (поправка извън елементарния файл)
6C XX Грешна дължина, SW2 указва точната дължина. Не се връща
като отговор поле за данни
6D 00 Несъвместим или неправилен код на команда
6E 00 Несъвместим клас
6F 00 — Други грешки при проверката
Може да бъдат върнати други байтове за състояние,
определени в стандарт ISO/IEC 7816-4, ако поведението
им не е изрично упоменато в настоящото допълнение.
Например по избор може да бъдат върнати следните
байтове за състояние:
6881: Несъвместим логически канал
6882: Не се поддържа защитен обмен на съобщения
▼B
TCS_30 Ако в една APDU с команда е изпълнено повече от
едно условие за грешка, картата може да върне който
и да е от съответните байтове за състояние.
3.5. Описание на командите
В настоящата глава са описани задължителните команди за тахог­
рафските карти.
Още важни подробности относно използваните криптографски
операции се дават в допълнение 11 „Общи механизми за
сигурност за тахографи от поколение 1 и поколение 2“.
Всички команди са описани независимо от използвания протокол
(T=0 или T=1). Винаги са посочени байтовете CLA, INS, P1, P2,
Lc и Le на APDU. Ако за описаната команда не е необходим байт
Lc или Le, за него не се дават дължина, стойност и описание.
▼M1
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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) NN „XX..XXh“ AID: „FF 54 41 43 48 4F“ за тахографското
приложение от поколение 1
AID: „FF 53 4D 52 44 54“ за тахографското
приложение от поколение 2
Не е нужно да се отговаря на командата SELECT (Le
липсва при T=1 или не се изисква отговор при T=0).
TCS_38 Ответно съобщение (не се изисква отговор)
Байт
Дължи­
на
Стойност Описание
SW 2 „XXXXh“ Байтове за състоянието (SW1, SW2)
— Ако командата бъде изпълнена успешно, картата
връща „9000“.
— Ако приложението, съответстващо на AID, е неот­
криваемо, за състоянието на обработката се връща
„6A82“.
— При T=1 за състоянието се връща „6700“, ако е
наличен байтът Le.
— При Т=0 за състоянието се връща „6900“, ако се
изисква отговор след командата SELECT.
▼M1
— Ако избраното приложение се смята за повредено
(открита е грешка в целостта на атрибутите на
файла), за състоянието на обработката се връща
„6400“ или „6500“.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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) NN ‘XX..XXh’ Проста стойност на данните
#(2+L+NN) 1 ‘99h’ Таг за състоянието на обработката (SW1-
SW2) — по избор за защитен обмен на
съобщения от поколение 1
#(3+L+NN) 1 ‘02h’ Дължина на стойността за състоянието на
обработката — по избор за защитен
обмен на съобщения от поколение 1
#(4+L+NN) - #(5+L+NN) 2 ‘XX XXh’ Състояние на обработката на незащи­
тената ответна APDU, т.е. с отговора —
незадължително при защитен обмен на
съобщения от поколение 1
#(6+L+NN) 1 ‘8Eh’ TCC: таг за криптографската контролна
сума
#(7+L+NN) 1 ‘XXh’ LCC: дължина на следната криптографска
контролна сума
‘04h’ за защитения обмен на съобщения от
поколение 1 (вж. допълнение 11, част А)
‘08h’, ‘0Ch’ или ‘10h’ в зависимост от
дължината на ключа по AES за защитен
обмен на съобщения от поколение 2 (вж.
допълнение 11, част Б)
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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) MM ‘01XX..XXh’ Криптирани данни: индикатор за
запълване и криптограма
#(2+L+MM) 1 ‘99h’ Таг за състоянието на обработката (SW1-
SW2) — по избор за защитен обмен на
съобщения от поколение 1
#(3+L+MM) 1 ‘02h’ Дължина на стойността за състоянието на
обработката — по избор за защитен
обмен на съобщения от поколение 1
#(4+L+MM) - #(5+L+MM) 2 ‘XX XXh’ Състояние на обработката на незащи­
тената ответна APDU, т.е. с отговора —
незадължително при защитен обмен на
съобщения от поколение 1
#(6+L+MM) 1 ‘8Eh’ TCC: таг за криптографската контролна
сума
#(7+L+MM) 1 ‘XXh’ LCC: дължина на следната криптографска
контролна сума
‘04h’ за защитения обмен на съобщения
от поколение 1 (вж. допълнение 11, част
А)
‘08h’, ‘0Ch’ или ‘10h’ в зависимост от
дължината на ключа по AES за защитен
обмен на съобщения от поколение 2 (вж.
допълнение 11, част Б)
#(8+L+MM)-
#(7+N+L+MM)
N ‘XX..XXh’ Криптографска контролна сума
SW 2 ‘XXXXh’ Байтове за състоянието (SW1, SW2)
▼B
Командата READ BINARY може да върне стойности за
нормални състояния на обработка, изброени в TCS_43
под тага „99h“, както е описано в TCS_59, използвайки
за отговора структурата за защитен обмен на
съобщения.
Освен това могат да възникнат някои грешки,
конкретно свързани със защитения обмен на
съобщения. В този случай се връща само стойност за
състоянието на обработката без участието на струк­
турата за защитен обмен на съобщения:
▼M1
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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) NN „XX..XXh“ Изместване на обекта от данни:
Таг „54h“
Дължина „01h“ или „02h“
Стойност изместване
▼M1
Le 1 ‘XXh’ Съгласно стандарта ISO/IEC 7816-4
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 252
Байт
Дължи­
на
Стойност Описание
#6 1 „B3h“ Таг за простата стойност на данните, кодирани по
BER-TLV
#7 1 „NNh“ L PV : дължина на предадените данни
#(8)-#(7+NN) NN „XX..XXh“ Прости данни, кодирани по BER-TLV, т.е. измес­
теният обект от данни с таг „54“
#(8+NN) 1 „97h“ T LE : таг за спецификацията на очакваната дължина
#(9+NN) 1 „01h“ L LE : Очаквана дължина
#(10+NN) 1 „XXh“ Спецификация на очакваната дължина (първоначална
Le): брой на байтовете, които трябва да се извлекат.
#(11+NN) 1 „8Eh“ T CC : таг за криптографската контролна сума
#(12+NN) 1 „XXh“ L CC : дължина на следната криптографска контролна
сума
„08h“, „0Ch“ или „10h“ в зависимост от дължината на
ключа по AES за защитен обмен на съобщения от
поколение 2 (виж допълнение 11, част Б)
#(13+NN)-
#(12+M+NN)
M „XX..XXh“ Криптографска контролна сума
Le 1 „00h“ Съгласно стандарта ISO/IEC 7816-4
TCS_55 Ответно съобщение, ако командата бъде изпълнена
успешно
Байт
Дължи­
на
Стойност Описание
#1 1 „B3h“ Прости данни, кодирани по BER-TLV
#2 L „NNh“ или
„81 NNh“
L PV : дължина на върнатите данни (= първоначална
Le)
L е 2 байта, ако L PV >127 байта
#(2+L)-
#(1+L+NN)
NN „XX..XXh“ Стойност на простите данни, кодирана по BER-TLV,
т.е. извлечените данни, капсулирани в дискреционен
обект от данни с таг „53h“.
#(2+L+NN) 1 „99h“ Състояние на обработката на незащитената ответна
APDU
#(3+L+NN) 1 „02h“ Дължина на стойността за състоянието на обра­
ботката
#(4+L+NN) —
#(5+L+NN)
2 „XX XXh“ Състояние на обработката на незащитената ответна
APDU
#(6+L+NN) 1 „8Eh“ T CC : таг за криптографската контролна сума
#(7+L+NN) 1 „XXh“ L CC : дължина на следната криптографска контролна
сума
„08h“, „0Ch“ или „10h“ в зависимост от дължината на
ключа по AES за защитен обмен на съобщения от
поколение 2 (виж допълнение 11, част Б)
#(8+L+NN)-
#(7+M+L+N­
N)
M „XX..XXh“ Криптографска контролна сума
SW 2 „XXXXh“ Байтове за състоянието (SW1, SW2)
3.5.3 UPDATE BINARY
Тази команда е в съответствие със стандарта ISO/IEC 7816-4, но е
с по-ограничена употреба в сравнение с аналогичната команда,
описана в този стандарт.
Съобщението с командата UPDATE BINARY инициализира
актуализирането (изтриване + записване) на битовете, които
вече присъстват в определен двоичен елементарен файл (EF), с
битовете, които се съдържат в APDU с командата.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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) NN „XX..XXh“ Данни, които трябва да се запишат
Забележка: бит 8 на байт P1 трябва да бъде равен на
нула.
TCS_57 Ответно съобщение
Байт
Дължи­
на
Стойност Описание
SW 2 „XXXXh“ Байтове за състоянието (SW1, SW2)
— Ако командата бъде изпълнена успешно, картата
връща „9000“.
— Ако не е селектиран елементарен файл (EF), за
състоянието на обработката се връща „6986“.
— Ако условията за сигурност за селектирания файл
не са изпълнени, изпълнението на командата се
прекъсва с „6982“.
— Ако изместването не е съвместимо с размера на EF
(изместването > размера на EF), за състоянието на
обработката се връща „6B00“:
— Ако обемът на данните, които ще се записват, не е
съвместим с размера на елементарния файл (измест­
ването + Lc > размера на елементарния файл), за
състоянието на обработката се връща „6700“.
— Ако е открита грешка в цялостността на атрибутите
на файла, картата счита файла за повреден и невъз­
становим, а за състоянието на обработката се връща
„6400“ или „6500“.
— Ако записването е неуспешно, за състоянието на
обработката се връща „6581“.
3.5.3.1.1 К о м а н д а с ъ с з а щ и т е н о б м е н н а с ъ о б щ е н и я
( п р и м е р и )
Тази команда позволява на IFD да запише данните в селек­
тирания елементарен файл, като картата проверява цялостността
на получените данни. Тъй като няма изискване за поверителност,
данните не са криптирани.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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) NN „XX..XXh“ Данни, които трябва да се запишат
TCS_63 Ответно съобщение
Байт
Дължи­
на
Стойност Описание
SW 2 „XXXXh“ Байтове за състоянието (SW1, SW2)
Забележка: Кратките идентификатори на EF,
използвани за тахографското приложение от
поколение 2, са определени в глава 4.
Ако P1 кодира кратък идентификатор на EF и
командата бъде изпълнена успешно, идентифицираният
EF се селектира като текущ (активен EF).
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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) NN „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.002 — 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.002 — 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“ P1
P2 1 „00h“ P2
Le 1 „08h“ Le (дължина на очакваното произволно число)
TCS_71 Ответно съобщение
Байт
Дължи­
на
Стойност Описание
#1-#8 8 „XX..XXh“ Произволно число
SW 2 „XXXXh“ Байтове за състоянието (SW1, SW2)
— Ако командата бъде изпълнена успешно, картата
връща „9000“.
— Ако байтът Le се различава от „08h“, състоянието
на обработката е „6700“.
— Ако параметрите P1-P2 са неправилни, състоянието
на обработката е „6A86“.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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“ P1
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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“ P1
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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“ P1
P2 1 „00h“ P2
Lc 1 „10h“ Дължина на данните, изпратени на картата
#6 — #13 8 „XX..XXh“ Искане за достъп, използвано за удостоверяване
автентичността на картата
#14 -#21 8 „XX..XXh“ VU.CHR (виж допълнение 11)
Le 1 „80h“ Дължина на очакваните данни, идващи от картата
TCS_94 Ответно съобщение
Байт
Дължи­
на
Стойност Описание
#1-#128 128 „XX..XXh“ Маркер за удостоверяването на картата (виж
допълнение 11)
SW 2 „XXXXh“ Байтове за състоянието (SW1, SW2)
— Ако командата бъде изпълнена успешно, картата
връща „9000“.
— Ако не е наличен публичен ключ в средата,
свързана със защитата от неоторизиран достъп, за
състоянието на обработката се връща „6A88“.
— Ако не е наличен частен ключ в средата, свързана
със защитата от неоторизиран достъп, за
състоянието на обработката се връща „6A88“.
— Ако VU.CHR не съвпада с идентификатора на
активния публичен ключ, за състоянието на обра­
ботката се връща „6A88“.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 280
► (1) (2) M3
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 281
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 284
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 285
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 286
TCS_155 Следните стойности, използвани за указване на размери
в таблицата по-горе, определят минималния и макси­
малния брой на записите, който трябва да се използва
за приложение от поколение 2 в структурата на данните
в картата на водача:
▼M3
Мин. Макс.
n 1 NoOfEventsPerType 12 12
n 2 NoOfFaultsPerType 24 24
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.002 — 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.002 — 288
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 289
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 292
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 293
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 294
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 295
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 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 24 24
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.002 — 297
TCS_167 Следните стойности, използвани за указване на размери
в таблицата по-горе, определят минималния и макси­
малния брой на записите, който трябва да се използва
за приложение от поколение 1 в структурата на данните
в контролната карта:
4.4.2 Приложение от поколение 2 за контролната карта
▼M3
TCS_168 След персонализирането на приложението от поколение
2 за контролната карта то трябва да е със следната
постоянна файлова структура и правила за достъп до
файловете:
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 299
▼B TCS_171 Следните стойности, използвани за указване на размери в
таблицата по-горе, определят минималния и максималния
брой на записите, който трябва да се използва за
приложение от поколение 2 в структурата на данните в
контролната карта:
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 302
▼B
TCS_179 Следните стойности, използвани за указване на размери
в таблицата по-горе, определят минималния и макси­
малния брой на записите, който трябва да се използва
за приложение от поколение 2 в структурата на данните
в картата на превозвач:
▼M3
Мин. Макс.
n 8 NoOfCompanyActivityRecords 230 520
n 13 VuConfigurationLengthRange 3072 байта 3072 байта
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 303
Допълнение 3
ПИКТОГРАМИ
PIC_001 При тахографите може по избор да се използват следните
пиктограми и комбинации от пиктограми (или пиктограми и
комбинации, които да са достатъчно сходни на тях, така че едно­
значно да бъдат отъждествими с тях):
1. ОСНОВНИ ПИКТОГРАМИ
Хора Действия Режими на работа
Предприятие Режим на предприятие
Контрольор Контрол Контролен режим
Водач Управление на МПС Работен режим
Сервиз/изпитателен пункт Техн. преглед/калиб­
риране
Режим на калибриране
Производител
Дейности Времетраене
На разположение Текущ период на разположение
Управление на МПС Време на непрекъснато управление на
МПС
Почивка Текущ период на почивка
Друга работа Текущ период на работа
Прекъсване Общо време на прекъсване
Неизвестна дейност
Оборудване Функции
Четящо устройство с процеп
за картата на водача
Четящо устройство с процеп
за картата на втория водач
Карта
Часовник
Дисплей Показване върху дисплея
Външна памет Изтегляне на данни
Електрическо захранване
Принтер / разпечатка Разпечатване
Датчик
Размер на гумите
Превозно средство / бордово
устройство
Устройство за GNSS
Устройство за откриване от
разстояние
Интерфейс с ITS
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 304
Специфични условия, ръчно въвеждане
Извън обхват
Пътуване с ферибот/влак
Операция по товарене,
Операция по разтоварване,
Операция по едновременно товарене и разто­
варване,
Тип на товара пътници
Тип на товара стоки
Тип на товара неопределен тип на товара
▼B
Други
Събития Неизправности
Начало на дневен период на работа Край на дневен период на
работа
Местоположение
Ръчно въвеждане на дейностите,
извършвани от водача
▼M3
Сигурност/данни с удостоверена
автентичност/печати
▼B
Скорост
Час
Общо/обобщение (справка)
▼M3
Цифрова карта/пресичане на
граница
▼B
Определения
24h За деня
За седмица
За две седмици
От или към
2. КОМБИНАЦИИ ОТ ПИКТОГРАМИ
Други
Контролен пункт
Местоположение в началото на
дневния период на работа
Местоположение в края на
дневния период на работа
▼M1
Местоположение след 3 часа общо
време на управление на МПС
▼B
От … часа До … часа
От превозното средство
Начало на излизането извън обсег Край на излизането извън обсег
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 305
Местоположение, в което
превозното средство е пресекло
границата между две държави
Местоположение, в което е
извършена операция по товарене
Местоположение, в което е
извършена операция по разто­
варване
Местоположение, в което е
извършена операция по едно­
временно товарене и разтоварване
▼B
Карти
Карта на водач
Карта на превозвач
Контролна карта
Карта за монтаж и настройки
Без карта
Управление на МПС
Управление на МПС в екип
Време на управление на МПС за една седмица
Време на управление на МПС за две седмици
Разпечатки
Ежедневна разпечатка на дейностите, извършвани от водача, извлечени
от картата
Ежедневна разпечатка на дейностите, извършвани от водача, извлечени
от VU (бордовото устройство)
Разпечатка на събитията и неизправностите, извлечени от картата
Разпечатка на събитията и неизправностите, извлечени от VU
Разпечатка на техническите данни
Разпечатка за превишаването на допустимата скорост
▼M3
Разпечатка за вкарвани карти в минали периоди
▼B
Събития
Вкарване на невалидна карта
Конфликт, предизвикан от картата
Припокриване във времето
Управление на МПС без съответната карта
Вкарване на карта по време на управление на МПС
Неправилно приключване на последната картова сесия
Превишаване на допустимата скорост
Прекъсване на електрическото захранване
Грешка в данните за движението
Противоречие в данните относно движението на превозното средство
Нарушаване на сигурността
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 306
Времеви конфликт или сверяване на часовника (в сервиз)
▼B
Контрол на превишаването на допустимата скорост
▼M1
Липса на информация за местоположението от приемник на сигнали
от GNSS или Грешка в комуникацията с външното устройство за
GNSS
Грешка в комуникацията с устройството за връзка от разстояние
▼M3
Аномалия на GNSS
▼B
Неизправности
Дефектна карта (в процепа на четящото устройство за картата на
водача)
Дефектна карта (в процепа на четящото устройство за картата на
втория водач)
Неизправност в дисплея
Грешка при изтеглянето на данни
Неизправност в принтера (печатащото устройство)
Неизправност на датчика
Неизправност вътре във VU
Неизправност във връзка с GNSS
Неизправност във връзка с откриването от разстояние
Процедура по ръчно въвеждане
За същия дневен период на работа?
Край на предишен период на работа?
Потвърждение или въвеждане на местоположението в края на
дневния период на работа
Въвеждане на часа на тръгване
Въвеждане на местоположението в началото на периода на работа.
Забележка: в допълнение 4 са определени допълнителни
комбинации от пиктограми с оглед да се получат блокове за
разпечатване или идентификатори на записи.
▼M1
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 309
PRT_007 Разпечатките се състоят от следните блокове и/или записи от
данни със следните значения и формати:
► (1) (2) (3) (4) (5) M3
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 310
► (1) (2) (3) M3
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 311
► (1) (2) M3
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 312
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 313
► (1) (2) (3) (4) M3
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 314
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 315
► (1) M3
3. СПЕЦИФИКАЦИИ ЗА РАЗПЕЧАТКИТЕ
В настоящата глава се прилагат следните условни обозначения:
N Отпечатване на блока или на записа с номер N
N
Отпечатване на блока или на записа номер N, повторен толкова
пъти, колкото е необходимо
X/Y
Отпечатване на блоковете или на записите Х и/или Y, според
нуждите, и повторение на операцията толкова пъти, колкото е
необходимо
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 316
3.1. Ежедневна разпечатка на данните за дейностите на водача,
извлечени от карта
▼M3
PRT_008 Ежедневната разпечатка на данните за дейностите на
водача, извлечени от карта, трябва да бъде в съответствие
със следния формат:
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 317
3.2. Ежедневна разпечатка на данните за дейностите на водача,
извлечени от бордовото устройство
▼M3
PRT_009 Ежедневната разпечатка на данните за дейностите на
водача, извлечени от бордовото устройство, трябва да
бъде в съответствие със следния формат:
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 319
3.5. Разпечатка на техническите данни
▼M3
PRT_012 Разпечатката на техническите данни трябва да е в съот­
ветствие със следния формат:
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 321
Допълнение 5
ПОКАЗВАНЕ
В настоящото допълнение се прилагат следните условни обозначения за
формата:
— символите, които се изписани с удебелен шрифт, обозначават обикновен
текст, който трябва да се покаже (показват се същите символи, но с
нормален шрифт),
— символите с нормален шрифт обозначават променливи (пиктограми или
данни), които се заместват при показването с техните съответни
стойности:
— дд мм гггг: ден, месец, година,
— hh: часове,
— mm: минути,
— D: пиктограма за времетраене,
— EF: комбинация от пиктограми за събитие или неиз­
правност,
— O: пиктограма за режим на работа.
DIS_001 Тахографът трябва да показва данните в следните формати:
Данни Формат
Показване по подразбиране
Местно време
Режим на работа
Информация относно водача:
Информация относно втория водач:
Отворено условие „Извън обсег“
Показване на предупреждение
Надвишаване на времето за непрекъснато управление на
МПС
Събитие или неизправност
Показване на други данни
Дата по координирано универсално време (UTC)
час
Време на непрекъснато управление на МПС и общо
време на прекъсване за водача
Време на непрекъснато управление на МПС и общо
време на прекъсване за втория водач
Общо време на управление на МПС на водача през
текущата и предходната седмица
Общо време на управление на МПС на втория водач
през текущата и предходната седмица
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 322
Допълнение 6
ПРЕДЕН СЪЕДИНИТЕЛ ЗА КАЛИБРИРАНЕ И ИЗТЕГЛЯНЕ НА
ДАННИ
СЪДЪРЖАНИЕ
1. ХАРДУЕР
1.1. Съединител
1.2. Разпределение на контактите
1.3. Блоксхема
2. ИНТЕРФЕЙС ЗА ИЗТЕГЛЯНЕ НА ДАННИ
3. ИНТЕРФЕЙС ЗА КАЛИБРИРАНЕ
1. ХАРДУЕР
1.1. Съединител
INT_001 Съединителят за калибриране/изтегляне на данни трябва да е
с шест крачета, да е достъпен върху лицевия панел, без да се
налага разкачване на каквато и да е част на тахографа, и да е
в съответствие със следния чертеж (всички размери са
дадени в милиметри):
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 323
На следната схема е показан обичаен контактен съединител
с 6 крачета:
1.2. Разпределение на контактите
INT_002 Контактите трябва да са разпределени съгласно следната
таблица:
Краче Описание Забележка
1 Отрицателен полюс на
акумулатора
Свързан към отрицателната клема на акумулатора на
превозното средство
2 Предаване на данни Линия K (ISO 14230-1)
3 RxD — изтегляне на данни Входящи данни към тахографа
4 Входен/изходен сигнал Калибриране
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 325
3. ИНТЕРФЕЙС ЗА КАЛИБРИРАНЕ
INT_007 Предаването на данни трябва да е в съответствие с ISO 14
230-1: Пътни превозни средства. Системи за диагностика.
Протокол с ключови думи 2000 — част I: физически слой.
Първо издание, 1999 г.
INT_008 Входният/изходният сигнал трябва да е в съответствие със
следната електрическа спецификация:
Параметър Минимум
Обичайна
стойност
Максимум Забележка
U low (ниско ниво на
входния сигнал)
1,0 V I = 750 μА
U high (високо ниво
на входния сигнал)
4 V I = 200 μА
Честота 4 kHz
U low (ниско ниво на
изходния сигнал)
1,0 V I = 1 mA
U high (високо ниво
на изходния сигнал)
4 V I = 1 mA
INT_009 Входният/изходният сигнал трябва да е в съответствие със
следните хронограми:
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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 Version (Поло­
жителен отговор за трансфер на данни — Версия на интерфейса за
изтегляне)
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 Activities (Поло­
жителен отговор за трансфер на данни — Дейсности, свързани със
събитя и неизправности)
2.2.6.5 Positive Response Transfer Data Detailed Speed Activities (Поло­
жителен отговор за трансфер на данни — Дейности за подробната
скорост)
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.002 — 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.002 — 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 … … … CS
4 байта 255 байта максимум 1 байт
Байтовете TGT и SRC представляват физическите
адреси на получателя и изпращача на съобщението. Те
приемат стойностите F0 Hex за IDE и EE Hex за VU.
Байтът LЕN е дължината на полето за данни.
▼B
(*) Поставянето на картата активира съответните права за достъп до функцията за
изтегляне на данни и до данните. Трябва да е възможно обаче изтеглянето на
данни от карта на водач, вкарана в един от процепите на VU, когато в другия
процеп не е поставена друга карта.
02016R0799 — BG — 21.08.2023 — 003.002 — 330
Байтът за контролна сума е серия от суми по 8 бита по
модул 256, които представляват всички байтове на съоб­
щението с изключение на самата CS.
Байтовете FMT, SID, DS_, TRTP и TREP са определени
по-нататък в този документ.
DDP_003 Ако дължината на данните, които трябва да се пренесат
от съобщението, надхвърля свободното пространство в
полето за данни, изпращането на това съобщение става
под формата на няколко подсъобщения. Всяко подсъ­
общение съдържа заглавна част, същите SID, TREP и
брояч на подсъобщения от 2 байта, който посочва
номера на подсъобщението в рамките на цялото
съобщение. С цел проверка за грешки и евентуално
прекратяване на обмена на данни IDE потвърждава
получаването на всяко подсъобщение. IDE може да
приеме подсъобщение, да поиска повторното му
предаване и да поиска от VU да възобнови или да
прекрати предаването.
DDP_004 Ако полето за данни на последното подсъобщение
съдържа точно 255 байта, е необходимо да се прибави
едно последно подсъобщение, което съдържа празно
поле за данни (с изключение на SID TREP и брояча на
подсъобщения), за да покаже края на съобщението.
Пример:
Заглавна част SID TREP Съобщение CS
4 байта Дължина, по-голяма от 255 байта
Ще бъде предадено като:
Заглавна част SID TREP 00 01 Подсъобщение 1 CS
4 байта 255 байта
Заглавна част SID TREP 00 02 Подсъобщение 2 CS
4 байта 255 байта
…
Заглавна част SID TREP xx yy Подсъобщение n CS
4 байта По-малка от 255 байта
или като:
Заглавна част SID TREP 00 01 Подсъобщение 1 CS
4 байта 255 байта
Заглавна част SID TREP 00 02 Подсъобщение 2 CS
4 байта 255 байта
…
Заглавна част SID TREP xx yy Подсъобщение n CS
4 байта 255 байта
Заглавна част SID TREP xx yy + 1 CS
4 байта 4 байта
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 331
2.2.2 Типове съобщения
Протоколът за връзка за изтегляне на данни между VU и IDE
изисква обмен на 8 различни типа съобщения.
Следващата таблицата обобщава тези съобщения.
▼M3
Структура на съобщението 4 байта максимум 255 байта максимум 1 байт
Заглавна част Данни
Контролна
сума
IDE ->
(ДАННИ)
CS
Start Communication Request (Искане
за започване на комуникация)
81 EE F0 81 E0
Positive Response Start Communi­
cation (Положителен отговор за
започване на комуникация)
80 F0 EE 03 C1 EA, 8F 9B
Start Diagnostic Session Request (Искане
за започване на сесия по диагностика)
80 EE F0 02 10 81 F1
Positive Response Start Diagnostic
(Положителен отговор за започване
на сесия по диагностика)
80 F0 EE 02 50 81 31
Link Control Service (Функция за
контрол на връзката)
Verify Baud Rate (stage 1) (Проверка
на скоростта на предаване (етап 1))
9 600 Bd 80 EE F0 04 87 01 01,01 EC
19 200 Bd 80 EE F0 04 87 01 01,02 ED
38 400 Bd 80 EE F0 04 87 01 01,03 EE
57 600 Bd 80 EE F0 04 87 01 01,04 EF
115 200 Bd 80 EE F0 04 87 01 01,05 F0
Positive Response Verify Baud Rate
(Положителен отговор за проверка
на скоростта на предаване)
80 F0 EE 02 C7 01 28
Transition Baud Rate (stage 2)
(Преходна скорост на предаване
(етап 2))
80 EE F0 03 87 02 03 ED
Request Upload (Искане за качване) 80 EE F0 0A 35 00,00,00,00­
,00,FF,FF,
FF,FF
99
Positive Response Request Upload
(Положителен отговор на искане за
качване)
80 F0 EE 03 75 00,FF D5
Transfer Data Request (Искане за
трансфер на данни)
Download interface version (Версия
на интерфейса за изтегляне)
80 EE F0 02 36 00 96
Overview (Преглед) 80 EE F0 02 36 01, 21 или 31 CS
Activities(Дейности) 80 EE F0 06 36 02, 22 или 32 Date (Дата) CS
Events & Faults (Събития и неиз­
правности)
80 EE F0 02 36 03, 23 или 33 Date CS
Detailed Speed (Подробна скорост) 80 EE F0 02 36 04 or 24 Date CS
Technical Data (Технически данни) 80 EE F0 02 36 05, 25 или 35 Date CS
Card download (Изтегляне на
карта)
80 EE F0 02 or 03 36 06 Slot (Процеп) CS
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 332
Структура на съобщението 4 байта максимум 255 байта максимум 1 байт
Заглавна част Данни
Контролна
сума
IDE ->
(ДАННИ)
CS
Positive Response Transfer Data
(Положителен отговор за трансфер
на данни)
80 F0 EE Len 76 TREP Data (Данни) CS
Request Transfer Exit (Искане за
трансфер, излизане)
80 EE F0 01 37 96
Positive Response Request Transfer
Exit (Положителен отговор на
искане за трансфер, излизане)
80 F0 EE 01 77 D6
Stop Communication Request (Искане
за прекратяване на комуникацията)
80 EE F0 01 82 E1
Positive Response Stop Communi­
cation (Положителен отговор за
прекратяване на комуникацията)
80 F0 EE 01 C2 21
Acknowledge sub message (Потв­
ръждение на подфункция)
80 EE F0 Len 83 Data (Данни) CS
Negative responses (Отрицателни
отговори)
General reject (Общо отхвръляне) 80 F0 EE 03 7F Sid Req 10 CS
Service not supported (Функцията не
се поддържа)
80 F0 EE 03 7F Sid Req 11 CS
Sub function not supported (Подфун­
кцията не се поддържа)
80 F0 EE 03 7F Sid Req 12 CS
Incorrect Message Length
(Неправилна дължина на съоб­
щението)
80 F0 EE 03 7F Sid Req 13 CS
Conditions not correct or Request
sequence error (Неправилни условия
или грешка в искането)
80 F0 EE 03 7F Sid Req 22 CS
Request out of range (Искане извън
обхвата)
80 F0 EE 03 7F Sid Req 31 CS
Upload not accepted (Качването не е
прието)
80 F0 EE 03 7F Sid Req 50 CS
Response pending (Очакване на
отговор)
80 F0 EE 03 7F Sid Req 78 CS
Data not available (Данните не са
налични)
80 F0 EE 03 7F Sid Req FA CS
Забележки:
— Sid Req = Sid на съответната заявка.
— TREP = TRTP на съответната заявка.
— Черните полета означават, че нищо не е предадено.
— Терминът „upload“ [„качване на данни“] (от IDE) се използва за
съвместимостта със стандарта ISO 14229. Този термин е със
същото значение като „download“ [„изтегляне на данни“] (от
VU).
— В тази таблица не са показани потенциални броячи за подсъ­
общения от 2 байта.
— Процеп е номерът на процепа — или 1 (карта в процепа за
водача), или 2 (карта в процепа за втория водач).
— Ако процепът не е посочен, VU избира процеп 1, ако картата е
поставена в този процеп, а процеп 2 — само ако този процеп е
специално избран от потребителя.
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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
(Версия на интерфейса за
изтегляне)
Не се използва Не се използва 00
Overview (Преглед) 01 21 31
Activities of a specified date
(Дейности на определена
дата)
02 22 32
Events and faults (Събития и
неизправности)
03 23 33
Detailed speed (Подробна
скорост)
04 24 24
Technical data (Технически
данни)
05 25 35
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 335
Тип трансфер
на данни
Стойност на
TRTP
Card download 06
▼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.002 — 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
от тези кодове.
Отговорите на 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.002 — 337
— 11 — услугата не се поддържа
SID на заявката не се разбира.
— 12 — подфункцията не се поддържа
DS_ или TRTP на заявката не се разбира или пред­
аването на подсъобщения е приключило.
— 13 — неправилна дължина на съобщение
Дължината на полученото съобщение е грешна.
— 22 — неправилни условия или грешка, която засяга
последователността на заявяването
Заявената услуга не е активна или последовател­
ността на съобщенията за заявката е неправилна.
— 31 — недопустимост на заявката
Записването (полето за данни) на параметъра на
заявката не е валидно.
— 50 — качването на данни не е прието
Заявката не може да се изпълни (VU се използва в
несвойствен режим на работа или има някаква
вътрешна неизправност на VU).
— 78 — изчакване на отговор
Заявеното действие не може да приключи в опред­
еленото време и VU няма готовност да приеме друга
заявка.
▼M1
— Данни FA, които не са на разположение
Обектът от данни на заявка за трансфер на данни не
е достъпен в бордовото устройство (например не е
поставена карта; получената заявка за изтегляне на
данни от бордовото устройство от поколение 1 не е
при проверка на водача от контролен орган на
държава извън ЕС...).
▼B
2.2.3 Поток на съобщенията
При нормална процедура за изтегляне на данни потокът на съоб­
щенията обикновено е следният:
IDE VU
Start Communication Request ⇨
⇦ Positive Response
Start Diagnostic Service Request ⇨
⇦ Positive Response
Request Upload ⇨
⇦ Positive Response
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 338
IDE VU
Transfer Data Request Overview ⇨
⇦ Positive Response
Transfer Data Request #2 ⇨
⇦ Positive Response #1
Acknowledge Sub Message #1 ⇨
⇦ Positive Response #2
Acknowledge Sub Message #2 ⇨
⇦ Positive Response #m
Acknowledge Sub Message #m ⇨
⇦ Positive Response (Data Field
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.002 — 339
В следващата таблица са показани разрешените
стойности за параметрите за синхронизация (разширен
набор от параметри за синхронизация KWP, използвани
в случай на физическо адресиране за по-бърза връзка).
Синхронизация Параметър
Долна граница
Стойност (в ms)
Горна граница
Стойност (в ms)
P1 0 20
P2 20 1 000 (*)
P3 10 5 000
P4 5 20
P5 10 20 минути
(*) ако VU отговори с Negative Response, съдържащ код със значение „request correctly received, response
pending“ („правилно получена заявка, очаква се отговор“), тази стойност се разширява до същата
горна стойност на P3.
2.2.5 Обработка на грешки
Ако се появи грешка по време на обмена на съобщения, схемата за
поток на съобщенията се променя в зависимост от устройството,
което е открило грешката, и от съобщението, което е породило
тази грешка.
На фигури 2 и 3 са показани процедурите за обработване на
грешки, които се прилагат съответно за VU и IDE.
2.2.5.1 S t a r t C o m m u n i c a t i o n p h a s e
DDP_020 Ако IDE открие грешка по време на Start Communication
phase, както на ниво синхронизация, така и на ниво
последователност на битовете, тогава то изчаква за
период от P3 min, преди да изпрати отново заявката.
DDP_021 Ако VU открие грешка в последователността, която
идва от IDE, то не изпраща никакъв отговор и изчаква
друго съобщение Start Communication Request в рамките
на период от Р3 max.
2.2.5.2 C o m m u n i c a t i o n p h a s e
Могат да се определят две различни процедури за обработване на
грешки:
1. VU открива грешка в предаването от IDE
DDP_022 VU извършва анализ на всяко получено съобщение, за
да открие евентуална грешка по синхронизирането,
структурата на байтовете (например нарушения,
които засягат началните битове и битовете за край)
или грешки във връзка с кадрите (приемане на грешен
брой байтове, грешен байт за контролна сума).
DDP_023 Ако VU открие една от горепосочените грешки, то не
изпраща никакъв отговор и не взема под внимание
полученото съобщение.
DDP_024 VU може да открие други грешки, които засягат
структурата или съдържанието на полученото
съобщение (например съобщението не се поддържа)
даже и ако съобщението отговаря на изискванията за
дължина и контролна сума; в такъв случай VU трябва
да отговори на IDE със съобщение Negative Response,
което указва характера на грешката.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 355
Пример за данни в изтеглен файл върху ЕSM:
Таг Дължина Стойност
— Данни от EF ICC
— Данни от EF Card_Certificate
— ...
Данни от EF (в
DF )
Подпис на EF (в
DF )
Данни от EF в DF
Подпис на EF в
DF
▼B
4. ИЗТЕГЛЯНЕ НА ДАННИ ОТ ТАХОГРАФСКА КАРТА ЧРЕЗ
БОРДОВО УСТРОЙСТВО
DDP_047 VU трябва да позволява изтеглянето на съдържанието на
карта на водач, поставена в свързано IDE.
DDP_048 IDE трябва да изпрати съобщение „Transfer Data Request
Card Download“ до VU, за да се започне този режим (вж.
2.2.2.9).
▼M1
DDP_049 Карти на водач от първо поколение: Данните трябва да
се изтеглят, като се използва протоколът за изтегляне на
данни от първо поколение, и изтеглените данни трябва
да са със същия формат като данните, изтеглени от
бордово устройство от първо поколение.
Карти на водач от второ поколение: Тогава бордовото
устройство трябва да извърши цялостното изтегляне на
данни от картата, файл по файл, в съответствие с
протокола за изтегляне на данни от карта, определен в
параграф 3, както и да изпрати към IDE всички данни,
които са получени от картата в съответния файлов
формат ТLV (вж. 3.4.2) и са капсулирани в съобщение
„Positive Response Transfer Data“.
▼B
DDP_050 IDE трябва да извлече данните от картата от съоб­
щението „Positive Response Transfer Data“ (като
премахне всички заглавни части, SID, ТRЕР, броячи на
подсъобщения и контролни суми) и да ги запише в един
физически файл, както е описано в параграф 2.3.
DDP_051 След това, в зависимост от случая, VU трябва да
извърши актуализиране на файла
или на картата на водач.
▼M1
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 359
Таблица 1
Обобщаваща таблица за стойностите на идентификаторите на услуги
Диагностични сесии
Наименование на диагностичната
услуга
Раздел
№
Стойности за
съобщенията
за заявка за
SId
SD ECUAS ECUPS
StartCommunication 4.1 81 ■ ■ ■
StopCommunication 4.2 82 ■
TesterPresent 4.3 3E ■ ■ ■
StartDiagnosticSession 5.1 10 ■ ■ ■
SecurityAccess 5.2 27 ■ ■ ■
ReadDataByIdentifier 6.1 22 ■ ■ ■
WriteDataByIdentifier 6.2 2E ■
InputOutputControlByIdentifier 7.1 2F ■
▼M3
RoutineControl 8 31
▼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.002 — 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.002 — 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 20
P2 Време между една заявка от
изпитвателното оборудване и
един или два отговора от
бордовото устройство
25 250
P3 Време между края на отго­
ворите на бордовото
устройство и началото на
нова заявка, изпратена от
изпитвателното оборудване
55 5 000
P4 Междубайтово време за
заявка, изпратена от изпит­
вателното оборудване
5 20
CPR_018 Форматът на съобщенията за бързата инициализация е
подробно описан в следващите таблици. (ЗАБЕЛЕЖКА:
Hex means hexadecimal)
Таблица 5
Съобщение за заявка за StartCommunication
Байт # Наименование на параметъра Стойност hex.
Мнемоничен
код
#1 Байт за структура —
физическо адресиране
81 FMT
#2 Целеви байт за адреса EE TGT
#3 Изходен байт за адреса tt SRC
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 362
Байт # Наименование на параметъра Стойност hex.
Мнемоничен
код
#4 Идентификатор на заявка
за услугата StartCommuni­
cation
81 SCR
#5 Контролна сума 00-FF CS
Таблица 6
Съобщение за положителен отговор за StartCommunication
Байт # Наименование на параметъра Стойност hex.
Мнемоничен
код
#1 Байт за структура —
физическо адресиране
80 FMT
#2 Целеви байт за адреса tt TGT
#3 Изходен байт за адреса EE SRC
#4 Допълнителен байт за
дължина
03 LEN
#5 Идентификатор на поло­
жителен отговор за
услугата StartCommunication
C1 SCRPR
#6 Ключов байт 1 EA KB1
#7 Ключов байт 2 8F KB2
#8 Контролна сума 00-FF CS
CPR_019 Няма отрицателен отговор на съобщението за заявка за
StartCommunication. Поради липса на съобщение за
положителен отговор за изпращане, бордовото
устройство не се инициализира, никакви данни не се
предават и то остава в режим на нормална работа.
4.2. Услуга StopCommunication
4.2.1 Описание на съобщенията
Целта на тази услуга е да се прекрати съобщителната сесия.
CPR_020 При получаване на примитив за указване StopCommuni­
cation бордовото устройство трябва да провери дали
актуалните условия позволяват да се прекрати тази
връзка. В такъв случай бордовото устройство трябва
да извърши всички необходими операции, за да
прекрати връзката.
CPR_021 Ако е възможно прекратяване на връзката, бордовото
устройство трябва да изпрати примитив за отговор Stop­
Communication с избраните параметри за положителен
отговор, преди да прекрати връзката.
CPR_022 Ако по една или друга причина се окаже невъзможно
прекратяването на връзката, бордовото устройство
трябва да изпрати примитив за отговор StopCommuni­
cation с избрания параметър за отрицателен отговор.
CPR_023 Ако бордовото устройство установи надвишаване на
времетраенето P3max, връзката се прекратява без
примитив за отговор.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 363
4.2.2 Формат на съобщенията
CPR_024 Форматите на съобщенията за примитивите на StopCom­
munication са подробно описани в следващите таблици.
Таблица 7
Съобщение за заявка за StopCommunication
Байт # Наименование на параметъра Стойност hex.
Мнемоничен
код
#1 Байт за структура —
физическо адресиране
80 FMT
#2 Целеви байт за адреса EE TGT
#3 Изходен байт за адреса tt SRC
#4 Допълнителен байт за
дължина
01 LEN
#5 Идентификатор на заявка
за услугата StopCommuni­
cation
82 SPR
#6 Контролна сума 00-FF CS
Таблица 8
Съобщение за положителен отговор за StopCommunication
Байт # Наименование на параметъра Стойност hex.
Мнемоничен
код
#1 Байт за структура —
физическо адресиране
80 FMT
#2 Целеви байт за адреса tt TGT
#3 Изходен байт за адреса EE SRC
#4 Допълнителен байт за
дължина
01 LEN
#5 Идентификатор на поло­
жителен отговор за
услугата StopCommunication
C2 SPRPR
#6 Контролна сума 00-FF CS
Таблица 9
Съобщение за отрицателен отговор за StopCommunication
Байт # Наименование на параметъра
Шестнай­
сетична
стойност
Мнемоничен
код
#1 Байт за структура —
физическо адресиране
80 FMT
#2 Целеви байт за адреса tt TGT
#3 Изходен байт за адреса EE SRC
#4 Допълнителен байт за
дължина
03 LEN
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 364
Байт # Наименование на параметъра
Шестнай­
сетична
стойност
Мнемоничен
код
#5 Идентификатор на отри­
цателен отговор за
услугата
7F NR
#6 Идентификация на заявка за
услугата StopCommunication
82 SPR
#7 responseCode = generalReject 10 RC_GR
#8 Контролна сума 00-FF CS
4.2.3 Определяне на параметрите
Тази услуга не налага определяне на параметри.
4.3. Услуга TesterPresent
4.3.1 Описание на съобщенията
Услугата TesterPresent се използва от изпитвателното оборудване,
за да укаже на сървъра, че все още е на разположение, с цел да се
попречи на автоматичното връщане на сървъра към режим на
нормална работа и да се избегне евентуалното прекъсване на
връзката. Изпращана периодично, тази услуга поддържа активна
диагностичната сесия/връзката, като нулира брояча Р3 при всяка
заявка за тази услуга.
4.3.2 Формат на съобщенията
CPR_079 Форматите на съобщенията за примитивите за Tester­
Present са подробно описани в следващите таблици.
Таблица 10
Съобщение за заявка за TesterPresent
Байт # Наименование на параметъра
Шестнай­
сетична
стойност
Мнемоничен
код
#1 Байт за структура —
физическо адресиране
80 FMT
#2 Целеви байт за адреса EE TGT
#3 Изходен байт за адреса tt SRC
#4 Допълнителен байт за
дължина
02 LEN
#5 Идентификатор на заявка
за услугата TesterPresent
3E TP
#6 Подфункция =
responseRequired-
=
[ да 01 RESPREQ_Y
не ] 02 RESPREQ_NO
#7 Контролна сума 00-FF CS
CPR_080 Ако за параметъра responseRequired е зададено„да“,
сървърът ще отговори с последващо съобщение за поло­
жителен отговор. Ако е зададено „не“, сървърът не
изпраща отговор.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 365
Таблица 11
Съобщение за положителен отговор за TesterPresent
Байт # Наименование на параметъра
Шестнай­
сетична
стойност.
Мнемоничен
код
#1 Байт за структура —
физическо адресиране
80 FMT
#2 Целеви байт за адреса tt TGT
#3 Изходен байт за адреса EE SRC
#4 Допълнителен байт за
дължина
01 LEN
#5 Идентификатор на поло­
жителен отговор за
услугата TesterPresent
7E TPPR
#6 Контролна сума 00-FF CS
CPR_081 Услугата трябва да поддържа следните кодове за отри­
цателен отговор:
Таблица 12
Съобщение за отрицателен отговор за TesterPresent
Байт # Наименование на параметъра
Шест­
найсети­
чна
стойност
Мнемоничен
код
#1 Байт за структура — физическо
адресиране
80 FMT
#2 Целеви байт за адреса tt TGT
#3 Изходен байт за адреса EE SRC
#4 Допълнителен байт за дължина 03 LEN
#5 Идентификатор на отрицателен
отговор за услугата
7F NR
#6 Идентификация на заявка за
услугата TesterPresent
3E TP
#7 respon­
seCode =
[SubFunctionNotSup­
ported-InvalidFormat
12 RC_SFNS_IF
incorrectMessage­
Length ]
13 RC_IML
#8 Контролна сума 00-FF CS
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 367
Таблица 14
Съобщение за заявка за StartDiagnosticSession
Байт # Наименование на параметъра
Шестнай­
сетична
стойност
Мнемоничен
код
#1 Байт за структура —
физическо адресиране
80 FMT
#2 Целеви байт за адреса EE TGT
#3 Изходен байт за адреса tt SRC
#4 Допълнителен байт за
дължина
02 LEN
#5 Идентификатор на заявка
за услугата StartDiagnostic­
Session
10 STDS
#6 diagnosticSession = [една
стойност от таблица 17]
xx DS_…
#7 Контролна сума 00-FF CS
Таблица 15
Съобщение за положителен отговор за StartDiagnosticSession
Байт # Наименование на параметъра
Шестнай­
сетична
стойност
Мнемоничен
код
#1 Байт за структура —
физическо адресиране
80 FMT
#2 Целеви байт за адреса tt TGT
#3 Байт за изходен адрес EE SRC
#4 Допълнителен байт за
дължина
02 LEN
#5 Идентификатор на поло­
жителен отговор за
услугата StartDiagnostic­
Session
50 STDSPR
#6 diagnosticSession = [ същата
стойност като байт #6
таблица 14 ]
xx DS_…
#7 Контролна сума 00-FF CS
Таблица 16
Съобщение за отрицателен отговор за StartDiagnosticSession
Байт # Наименование на параметъра
Шест­
найсети­
чна
стойност
Мнемоничен
код
#1 Байт за структура — физическо
адресиране
80 FMT
#2 Байт за целеви адрес tt TGT
#3 Байт за изходен адрес EE SRC
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 368
Байт # Наименование на параметъра
Шест­
найсети­
чна
стойност
Мнемоничен
код
#4 Допълнителен байт за дължина 03 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 CS
( α ) Въведената стойност в байт #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.002 — 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.002 — 370
използва кода за отрицателен отговор requestCorrect­
lyReceived-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 Байт за целевия адрес EE TGT
#3 Байт за изходен адрес tt SRC
#4 Допълнителен байт за
дължина
02 LEN
#5 Идентификатор на заявка
за услугата SecurityAccess
27 SA
#6 accessType — requestSeed 7D AT_RSD
#7 Контролна сума 00-FF CS
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 371
Таблица 19
SecurityAccess — съобщение за положителен отговор за requestSeed
Байт # Наименование на параметъра
Шестнай­
сетична
стойност
Мнемоничен
код
#1 Байт за структура —
физическо адресиране
80 FMT
#2 Байт за целевия адрес tt TGT
#3 Байт за изходния адрес EE SRC
#4 Допълнителен байт за
дължина
04 LEN
#5 Идентификатор на поло­
жителен отговор за
услугата SecurityAccess
67 SAPR
#6 accessType — requestSeed 7D AT_RSD
#7 Инициализация от високо
ниво
00-FF SEEDH
#8 Инициализация от ниско
ниво
00-FF SEEDL
#9 Контролна сума 00-FF CS
Таблица 20
Съобщение за отрицателен отговор за SecurityAccess
Байт # Наименование на параметъра
Шест­
найсети­
чна
стойност
Мнемоничен
код
#1 Байт за структура — физическо
адресиране
80 FMT
#2 Байт за целевия адрес tt TGT
#3 Байт за изходния адрес EE SRC
#4 Допълнителен байт за дължина 03 LEN
#5 Идентификатор на отрицателен
отговор за услугата
7F NR
#6 Идентификатор на заявка за
услугата SecurityAccess
27 SA
#7 respon­
seCode =
[conditionsNotCorrec­
tOrRequestSequen­
ceError
22 RC_CNC
incorrectMessage­
Length]
13 RC_IML
#8 Контролна сума 00-FF CS
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 372
5.2.3 Формат на съобщенията — SecurityAccess — sendKey
CPR_041 Форматите на съобщенията за примитивите на
„sendKey“ на SecurityAccess са подробно описани в
следващите таблици.
Таблица 21
Заявка за SecurityAccess — съобщение за sendKey
Байт # Наименование на параметъра
Шестнай­
сетична
стойност
Мнемоничен
код
#1 Байт за структура —
физическо адресиране
80 FMT
#2 Байт за целевия адрес EE TGT
#3 Байт за изходния адрес tt SRC
#4 Допълнителен байт за
дължина
m+2 LEN
#5 Идентификатор на заявка
за услугата SecurityAccess
27 SA
#6 accessType — sendKey 7E AT_SK
#7 до
#m+6
Key #1 (High) xx KEY
… …
Key #m (ниска, стойността
на m трябва да бъде в
интервала между 4 и 8)
xx
#m+7 Контролна сума 00-FF CS
Таблица 22
SecurityAccess — съобщение за положителен отговор за sendKey
Байт # Наименование на параметъра
Шестнай­
сетична
стойност
Мнемоничен
код
#1 Байт за структура —
физическо адресиране
80 FMT
#2 Байт за целевия адрес tt TGT
#3 Байт за изходния адрес EE SRC
#4 Допълнителен байт за
дължина
02 LEN
#5 Идентификатор на поло­
жителен отговор за
услугата SecurityAccess
67 SAPR
#6 accessType — sendKey 7E AT_SK
#7 Контролна сума 00-FF CS
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 373
Таблица 23
Съобщение за отрицателен отговор за SecurityAccess
Байт # Наименование на параметъра
Шест­
найсети­
чна
стойност
Мнемоничен
код
#1 Байт за структура — физическо
адресиране
80 FMT
#2 Байт за целевия адрес tt TGT
#3 Байт за изходния адрес EE SRC
#4 Допълнителен байт за дължина 03 LEN
#5 Идентификатор на отрицателен
отговор за услугата
7F NR
#6 Идентификатор на заявка за
услугата SecurityAccess
27 SA
#7 Respon­
seCode =
[generalReject 10 RC_GR
subFunctionNotSup­
ported
12 RC_SFNS
incorrectMessage­
Length
13 RC_IML
conditionsNotCorrec­
tOrRequestSequen­
ceError
22 RC_CNC
invalidKey 35 RC_IK
exceededNumberO­
fAttempts
36 RC_ENA
requestCorrectlyRe­
ceived-Response­
Pending]
78 RC_RCR_RP
#8 Контролна сума 00-FF CS
6. УСЛУГИ ЗА ПРЕДАВАНЕ НА ДАННИ
В следващата таблица са посочени наличните услуги:
Таблица 24
Услуги за предаване на данни
Наименование на
услугата
Описание
ReadDataByIdentifier Клиентът заявява предаването на акту­
алната стойност на запис с достъп от
recordDataIdentifier.
WriteDataByIdentifier Клиентът заявява запаметяване на запис,
до който recordDataIdentifier е имал
достъп.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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 Байт за целевия адрес EE TGT
#3 Байт за изходния адрес tt SRC
#4 Допълнителен байт за
дължина
03 LEN
#5 Идентификатор на заявка
за услугата ReadDataByI­
dentifier
22 RDBI
#6 до #7 recordDataIdentifier =
[стойност от таблица 28]
xxxx RDI_…
#8 Контролна сума 00-FF CS
Таблица 26
Съобщение за положителен отговор за ReadDataByIdentifier
Байт # Наименование на параметъра
Шест­
найсети­
чна
стойност
Мнемоничен
код
#1 Байт за структура — физическо
адресиране
80 FMT
#2 Байт за целевия адрес tt TGT
#3 Байт за изходния адрес EE SRC
#4 Допълнителен байт за дължина m + 3 LEN
#5 Идентификатор на положителен
отговор за услугата ReadData­
ByIdentifier
62 RDBIPR
#6 и #7 recordDataIdentifier = [същата
стойност като байтовете #6 и #7
таблица 25]
xxxx RDI_…
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 375
Байт # Наименование на параметъра
Шест­
найсети­
чна
стойност
Мнемоничен
код
#8 до #m
+ 7
dataRecord[] = [data#1 xx DREC_DAT­
A1
: : :
data#m] xx DREC_DAT­
Am
#m + 8 Контролна сума 00-FF CS
Таблица 27
Съобщение за отрицателен отговор за ReadDataByIdentifier
Байт # Наименование на параметъра
Шест­
найсети­
чна
стойност
Мнемоничен
код
#1 Байт за структура — физическо
адресиране
80 FMT
#2 Байт за целевия адрес tt TGT
#3 Байт за изходния адрес EE SRC
#4 Допълнителен байт за дължина 03 LEN
#5 Идентификатор на отрицателен
отговор за услугата
7F NR
#6 Идентификатор на заявка за
услугата ReadDataByIdentifier
22 RDBI
#7 Respon­
seCode=
[requestOu­
tOfRange
31 RC_ROOR
incorrectMessage­
Length
13 RC_IML
conditionsNot­
Correct]
22 RC_CNC
#8 Контролна сума 00-FF CS
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.002 — 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.002 — 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 Байт за целевия адрес EE TGT
#3 Байт за изходния адрес tt SRC
#4 Допълнителен байт за дължина m + 3 LEN
#5 Идентификатор на заявка за
услугата WriteDataByIdentifier
2E WDBI
#6 до #7 recordDataIdentifier = [стойност от
таблица 28]
xxxx RDI_…
#8 до m
+ 7
dataRecord[] = [data#1 xx DREC_DAT­
A1
: : :
data#m] xx DREC_DAT­
Am
#m + 8 Контролна сума 00-FF CS
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 378
Таблица 30
Съобщение за положителен отговор за WriteDataByIdentifier
Байт # Наименование на параметъра
Шестнай­
сетична
стойност
Мнемоничен
код
#1 Байт за структура —
физическо адресиране
80 FMT
#2 Байт за целевия адрес tt TGT
#3 Байт за изходния адрес EE SRC
#4 Допълнителен байт за
дължина
03 LEN
#5 Идентификатор на поло­
жителен отговор за
услугата WriteDataByIden­
tifier
6E WDBIPR
#6 до #7 recordDataIdentifier = [същата
стойност като байтовете #6 и
#7 таблица 29]
xxxx RDI_…
#8 Контролна сума 00-FF CS
Таблица 31
Съобщение за отрицателен отговор за WriteDataByIdentifier
Байт # Наименование на параметъра
Шест­
найсети­
чна
стойност
Мнемоничен
код
#1 Байт за структура — физическо
адресиране
80 FMT
#2 Байт за целевия адрес tt TGT
#3 Байт за изходния адрес EE SRC
#4 Допълнителен байт за дължина 03 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 CS
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 380
CPR_060 В случай на получаване на импулси за скорост по
линията за входния сигнал за моментната скорост на
бордовото устройство, при положение че линията за
входни/изходни сигнали работи в режим на въвеждане
на данни, тази линия трябва да премине в режим на
извеждане на данни или да се върне в своето дезакти­
вирано състояние.
CPR_061 Последователността на операциите е следната:
— установяване на връзки чрез услугата StartCommuni­
cation,
— влизане в сесия за настройка чрез услугата StartDi­
agnosticSession и преминаване в режим на работа
КАЛИБРИРАНЕ ИЛИ КОНТРОЛ (редът на
изпълнение на тези две операции е без значение),
— промяна на състоянието на изхода чрез услугата
InputOutputControlBydentifier.
7.1.2 Формат на съобщенията
CPR_062 Форматите на съобщенията за примитивите на InputOut­
putControlByIdentifier са подробно описани в следващите
таблици.
Таблица 33
Съобщение за заявка за InputOutputControlByIdentifier
Байт # Наименование на параметъра
Шестнай­
сетична
стойност
Мнемоничен
код
#1 Байт за структура —
физическо адресиране
80 FMT
#2 Байт за целевия адрес EE TGT
#3 Байт за изходния адрес tt SRC
#4 Допълнителен байт за
дължина
xx LEN
#5 Идентификатор на заявка
за InputOutputControlByI­
dentifier
2F IOCBI
#6 и #7 InputOutputIdentifier = [Calib­
rationInputOutput]
F960 IOI_CIO
#8 или
#8 до #9
ControlOptionRecord = [ COR_…
inputOutputControlParameter
— една стойност от таблица
36
xx IOCP_…
controlState — една стойност
от таблица 37 (вж. забе­
лежката по-долу)]
xx CS_…
#9 или #10 Контролна сума 00-FF CS
Забележка: параметърът сontrolState се появява само в
някои случаи (вж. 7.1.3).
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 381
Таблица 34
Съобщение за положителен отговор за InputOutputControlByIdentifier
Байт # Наименование на параметъра
Шестнай­
сетична
стойност
Мнемоничен
код
#1 Байт за структура —
физическо адресиране
80 FMT
#2 Байт за целевия адрес tt TGT
#3 Байт за изходния адрес EE SRC
#4 Допълнителен байт за
дължина
xx LEN
#5 Идентификатор на поло­
жителен отговор за inputO­
utputControlByIdentifier
6F IOCBIPR
#6 и #7 inputOutputIdentifier = [Calib­
rationInputOutput]
F960 IOI_CIO
#8 или
#8 до #9
controlStatusRecord = [ CSR_
inputOutputControlParameter
(същата стойност като байт
#8 таблица 33)
xx IOCP_…
controlState (същата стойност
като байт #9 таблица 33)]
(ако е приложимо)
xx CS_…
#9 или #10 Контролна сума 00-FF CS
Таблица 35
Съобщение за отрицателен отговор за InputOutputControlByIdentifier
Байт # Наименование на параметъра
Шестнай­
сетична
стойност
Мнемоничен
код
#1 Байт за структура —
физическо адресиране
80 FMT
#2 Байт за целевия адрес tt TGT
#3 Байт за изходния адрес EE SRC
#4 Допълнителен байт за
дължина
03 LEN
#5 Идентификатор на отри­
цателен отговор за услугата
7F NR
#6 Идентификатор на заявка за
inputOutputControlByIdentifier
2F IOCBI
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 382
Байт # Наименование на параметъра
Шестнай­
сетична
стойност
Мнемоничен
код
#7 responseCode=[
incorrectMessageLength 13 RC_IML
conditionsNotCorrect 22 RC_CNC
requestOutOfRange 31 RC_ROOR
deviceControlLimitsExceeded] 7A RC_DCLE
#8 Контролна сума 00-FF CS
7.1.3 Определяне на параметрите
CPR_064 Параметърът inputOutputControlParameter (IOCP_) е
определен в следващата таблица.
Таблица 36
Определяне на стойностите на inputOutputControlParameter
Hex Описание
Мнемоничен
код
00 ReturnControlToECU
Тази стойност трябва да посочва на сървъра
(бордовото устройство), че изпитвателното
оборудване не управлява повече линията за
входни/изходни сигнали за калибриране.
RCTECU
01 ResetToDefault
Тази стойност трябва да посочва на сървъра
(бордовото устройство), че трябва да върне
линията за входни/изходни сигнали за кали-
бриране към състоянието ѝ по подразбиране.
RTD
03 ShortTermAdjustment
Тази стойност трябва да посочва на сървъра
(бордовото устройство), че трябва да настрои
линията за входни/изходни сигнали за кали-
бриране към стойността, включена в пара-
метъра controlState.
STA
CPR_065 Параметърът controlState се появява само когато inputO­
utputControlParameter е конфигуриран като ShortTermAd­
justment и е определен в следващата таблица:
Таблица 37
Определяне на стойностите на controlState
Режим
Шестнай­
сетична
стойност
Описание
Дезак­
тивиран
00 Дезактивирана линия за вход/изход (по
подразбиране)
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 383
Режим
Шестнай­
сетична
стойност
Описание
Активиран 01 Активирана линия за вход/изход за калиб­
риране като speedSignalInput
Активиран 02 Активирана линия за вход/изход за калиб­
риране като realTimeSpeedSignalOutput­
Sensor
Активиран 03 Активирана линия за вход/изход за калиб­
риране като 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 Байт за структура — физическо адресиране 80 FMT
#2 Байт за целевия адрес EE TGT
#3 Байт за изходния адрес tt SRC
#4 Допълнителен байт за дължина xx LEN
#5 RoutineControl Request Sid (SID на заявка за RoutineControl) 31 RC
#6 routineControlType = [startRoutine] 01 RCTP_STR
#7 и #8 routineIdentifier = [TimeAdjustment] 0100 RI_TA
#9 Контролна сума 00-FF CS
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 384
Таблица 37б
RoutineControl, процедура (TimeAdjustment), подфункция startRoutine, съобщение за положителен отговор
Байт # Наименование на параметъра
Шестнай­
сетична
стойност
Мнемоничен
код
#1 Байт за структура — физическо адресиране 80 FMT
#2 Байт за целевия адрес tt TGT
#3 Байт за изходния адрес EE SRC
#4 Допълнителен байт за дължина xx LEN
#5 RoutineControl Positive Response Sid (SID на положителен
отговор за RoutineControl)
71 RCPR
#6 routineControlType = [startRoutine] 01 RCTP_STR
#7 и #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA
#9 Контролна сума 00-FF CS
Таблица 37в
RoutineControl, процедура (TimeAdjustment), подфункция requestRoutineResults, съобщение за заявка
Байт # Наименование на параметъра
Шестнай­
сетична
стойност
Мнемоничен
код
#1 Байт за структура — физическо адресиране 80 FMT
#2 Байт за целевия адрес EE TGT
#3 Байт за изходния адрес tt SRC
#4 Допълнителен байт за дължина xx LEN
#5 RoutineControl Request Sid (SID на заявка за RoutineControl) 31 RC
#6 routineControlType = [requestRoutineResults] 03 RCTP_RRR
#7 и #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA
#9 Контролна сума 00-FF CS
Таблица 37г
RoutineControl, процедура (TimeAdjustment), подфункция requestRoutineResults, съобщение за положителен
отговор
Байт # Наименование на параметъра
Шестнай­
сетична
стойност
Мнемоничен
код
#1 Байт за структура — физическо адресиране 80 FMT
#2 Байт за целевия адрес tt TGT
#3 Байт за изходния адрес EE SRC
#4 Допълнителен байт за дължина xx LEN
#5 RoutineControl Positive Response Sid (SID на положителен
отговор за RoutineControl)
71 RCPR
#6 routineControlType = [requestRoutineResults] 03 RCTP_RRR
#7 и #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA
#9 routineInfo (вж. таблица 37е) XX RINF_TA
#10 routineStatusRecord[] = routineStatus#1 (вж. таблица 37ж) XX RS_TA
#11 Контролна сума 00-FF CS
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 385
Таблица 37д
RoutineControltrol, процедура (TimeAdjustment), съобщение за отрицателен отговор
Байт # Наименование на параметъра
Шестнай­
сетична
стойност
Мнемоничен
код
#1 Байт за структура — физическо адресиране 80 FMT
#2 Байт за целевия адрес tt TGT
#3 Байт за изходния адрес EE SRC
#4 Допълнителен байт за дължина 03 LEN
#5 negativeResponse Service Id (Идентификатор на услугата за
отрицателен отговор)
7F NR
#6 Идентификатор на заявка за inputOutputControlByIdentifier 31 RC
#7 responseCode=[
sub-functionNotSupported
incorrectMessageLengthOrInvalidFormat
conditionsNotCorrect
requestOutOfRange
]
12
13
22
31
SFNS
IMLOIF
CNC
ROOR
#8 Контролна сума 00-FF CS
Таблица 37е
RoutineControl, процедура (TimeAdjustment), routineInfo
routineInfo
Шестнай­
сетична
стойност
Описание
NormalExitWithResultAvailable 61 Процедурата е изпълнена изцяло; налични са допъл­
нителни резултати от процедурата.
RoutineExecutionOngoing 78 Заявената процедура все още се изпълнява.
Таблица 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.002 — 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 Няма
Индикатор за грешка FE FE00 до FEFF FE000000 до FEFFFFFF 0
Не е наличен или не е заявен FF FF00 до FFFF FF000000 до FFFFFFFF FF
CPR_073 За параметрите, кодирани в ASCII, символът ASCII „*“
се резервира като разграничител.
9.2. Формати на dataRecords
В таблица 39 до таблица 42 са изложени подробно форматите,
които трябва да се използват чрез услугите ReadDataByIdentifier
и WriteDataByIdentifier.
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 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 15 ASCII ASCII
NextCalibrationDate 3 Вж. подробна информация в таблица 41
SpeedAuthorised 2 усилване 1/256 km/h/bit,
отместване 0
0 до 250,996 km/h
RegisteringMemberState 3 ASCII ASCII
VehicleRegistrationNumber 14 Вж. подробна информация в таблица 42
VIN 17 ASCII ASCII
SealDataVu 55 Вж. подробна информация в таблица 43
ByDefaultLoadType 1 Вж. подробна информация в таблица 44
VuSerialNumber 8 Вж. подробна информация в таблица 45
SensorSerialNumber 8 Вж. подробна информация в таблица 45
SensorGNSSSerialNumber 8 Вж. подробна информация в таблица 45
RemoteCommunicationModuleSeri­
alNumber
8 Вж. подробна информация в таблица 45
TachographCardsGen1Suppression 2 Вж. подробна информация в таблица 46
VehiclePosition 14 Вж. подробна информация в таблица 47
CalibrationCountry 3 ASCII NationAlpha, както е
определено в допълнение 1
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 399
№ Изпитване Описание Съответни изисквания
3.2 Сдвояване датчик за движение — бордово устройство 122*, 204
3.3 Установяване на движение
Точност на измерване на движението
30 до 35
3.4 Интерфейс към бордовото устройство 02
3.5 Проверява се дали датчикът за движение е защитен срещу въздействието
на постоянно магнитно поле. Като алтернативна възможност се проверява
дали датчикът за движение реагира по такъв начин на постоянни магнитни
полета, смущаващи установяването на движение на превозното средство,
че свързано с него бордово устройство да може да открива, записва и
съхранява данни за неизправности във функционирането на датчика
217
4. Изпитания за въздействията на околната среда
4.1 Работна температура Проверява се функционалността (както е
дефинирана за изпитване № 3.3) за темпера­
турния обхват [– 40 °C; + 135 °C] чрез:
изпитване Ad по IEC 60068-2-1, с продължи­
телност на изпитването 96 часа при мини­
малната температура To min ,
изпитване Bd по IEC 60068-2-2, с продължи­
телност на изпитването 96 часа при
максимална температура To max
Изпитване съгласно ISO 16750-4: Глава
5.1.1.2 Изпитване за работа при ниска темпе­
ратура (24 часа при – 40 °C)
Това изпитване е с позоваване на IEC 60068-
2-1: Изпитване на въздействия на околната
среда — Част 2-1: Изпитвания. Изпитване
А: Студ, IEC 68-2-2 изпитване Вd, с продъл­
жителност на изпитването 96 часа при мини­
малната температура – 40 °C.
Изпитване съгласно ISO 16750-4: Глава
5.1.2.2 Изпитване за работа при висока
температура (96 часа при 135 °C)
Това изпитване е с позоваване на IEC 60068-
2-2: Основни процедури за изпитване на
въздействия на околната среда; Част 2:
Изпитвания; Изпитвания В: Суха топлина
213
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.002 — 400
№ Изпитване Описание Съответни изисквания
4.4 Вибрации ISO 16750-3: Глава 4.1.2.6: Изпитване VI:
Търговско превозно средство (commercial
vehicle), двигател, скоростна кутия
Смесен режим на изпитване за вибрации,
включително
а) Изпитване със синусоидални вибрации,
20…520 Hz, 11.4 … 120 m/s 2 ,
октави/минута
б) Изпитване за случайни вибрации, 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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 Записване и съхраняване на данните в паметта 91
3.3 Връзка с бордовото устройство Допълнение 14,
раздели DSC_66 до
DSC_70 и DSC_71
до DSC_76
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 433
Данни Формат Байтове Забележки
EOV TimeReal 4 Изтичане на валидността
на сертификата. Незадъл­
жително, може да се
допълни с „FF“, ако не
е използвано.
CHR OCTET
STRING
8 Референтно означение на
титуляря на сертификата
n OCTET
STRING
128 Публичен ключ (модул)
е OCTET
STRING
8 Публичен ключ (публичен
степенен показател)
164
Забележки:
1. „Идентификаторът на профила на сертификата“ (Certificate Profile
Identifier — CPI) определя точната структура на даден сертификат
за удостоверяване на автентичност. Той изпълнява функция на
вътрешен идентификатор на оборудване в съответен списък на
заглавни части (Headerlist), който описва конкатенацията на
елементите от данни, съдържащи се в сертификата.
Списъкът на заглавни части, свързан със съдържанието на този
сертификат, има следния вид:
„4D“ „16“ „5F
29“
„01“ „42“ „08“ „5F
4B“
„07“ „5F
24“
„04“ „5F
20“
„08“ „7F
49“
„05“ „81“ „81
80“
„82“ „08“
Т
аг
з
а
ра
зш
ир
ен
H
ea
de
rl
is
t
Д
ъл
ж
ин
а
на
H
ea
de
rl
is
t
Т
аг
з
а
ид
ен
ти
ф
ик
ат
ор
н
а
пр
оф
ил
а
на
с
ер
ти
ф
ик
ат
а
(C
P
I)

Д
ъл
ж
ин
а
на
C
P
I
Т
аг
з
а
C
A
R

Д
ъл
ж
ин
а
на
C
A
R

Т
аг
з
а
от
ор
из
ац
ия
н
а
ти
ту
ля
ря
н
а
се
рт
иф
ик
ат
а
Д
ъл
ж
ин
а
на
C
H
A

Т
аг
з
а
E
O
V

Д
ъл
ж
ин
а
на
E
O
V

Т
аг
з
а
C
H
R

Д
ъл
ж
ин
а
на
C
H
R

Т
аг
з
а
пу
бл
ич
ен
к
лю
ч
(к
он
ст
ру
ир
ан
)
Д
ъл
ж
ин
а
на

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

ст
еп
ен
ен
п
ок
аз
ат
ел

2. „Референтното означение на сертифициращия орган“ (CAR) е
предназначено да идентифицира издалия сертификата орган по
такъв начин, че елементът от данни да може да изпълнява едно­
временно функцията на идентификатор на органа за ключа,
посочващ кой е сертифициращият орган, генерирал публичния
ключ (за кодирането вж. по-долу „Идентификатор на ключ“).
3. „Оторизация на титуляря на сертификата“ (CHA) се издава за
посочване на правата на титуляря на сертификата. Тя се състои
от идентификатор на заявката за тахограф и от типа на оборуд­
ването, за което се отнася сертификатът (в зависимост от
елемента от данни , за държава членка този
идентификатор е „00“).
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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“
Т
аг
з
а
пр
ов
ер
им
с

ка
рт
а
се
рт
иф
ик
ат

(к
он
ст
ру
ир
ан
)
Д
ъл
ж
ин
а
на

по
сл
ед
ва
щ
ит
е
об
ек
ти

от
д
ан
ни

Т
аг
з
а
по
дп
ис
а
Д
ъл
ж
ин
а
на
п
од
пи
са

Т
аг
з
а
ос
та
тъ
ка

Д
ъл
ж
ин
а
на
о
ст
ат
ък
а
Т
аг
з
а
C
A
R

Д
ъл
ж
ин
а
на
C
A
R

▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 437
CSM_020 Използва се следният протокол (стрелките указват обме­
нените команди и данни (вж. допълнение 2)):
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 438
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 440
При дадена незащитена двойка от команда и отвор:
Заглавна част на командата Тяло на командата
CLA INS P1 P2 [L c на поле] [Поле за данни] [L e на поле]
четири байта Байтове L, означени като B 1 до B L
Тяло на отговора Завършваща част на отговора
[Поле за данни] SW1 SW2
Байтове данни L r Два байта
Съответната защитена двойка от команда и отговор е:
Защитена от неоторизиран достъп команда:
Заглавна част на
командата (CH)
Тяло на командата
CLA INS P1 P2 [L c на новото
поле]
[Ново поле за данни] [L e на
новото
поле]
„OC“ Дължина на
новото поле за
данни
T PV L PV PV T LE L LE L e T CC L CC CC „00“
„81“ L c Поле за
данни
„97“ „01“ L e „8E“ „04“ CC
Данни, които се включват в контролната сума = CH || PB
|| T PV || L PV || PV || T LE || L LE || L e || PB
PB = допълващи байтове (80 .. 00) съгласно ISO-IEC
7816-4 и ISO 9797, метод 2.
PV и LE на обекта от данни (DO) присъстват единствено
ако незащитената команда съдържа съответстващи данни.
Защитен отговор:
1. Случай, когато полето за данни в отговора не е празно
и не се нуждае от защита с цел поверителност:
Тяло на отговора
Завършваща част на
отговора
[Ново поле за данни] Нови SW1 SW2
T PV L PV PV T CC L CC CC
„81“ L r Поле за данни „8E“ „04“ CC
Данни, които се включват в контролната сума = T PV ||
L PV || PV || PB
2. Случай, когато полето за данни на отговора не е
празно и се нуждае от защита с цел поверителност:
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 441
Тяло на отговора
Завършваща част на
отговора
[Ново поле за данни] Нови SW1 SW2
T PI CG L PI
CG
PI CG T CC L CC CC
„87“ PI || CG „8E“ „04“ CC
Данни, които се маршрутизират чрез CG: некодирани с
BER-TLV данни и допълващи байтове.
Данни, които се включват в контролната сума = T PI CG
|| L PI CG || PI CG || PB
3. Случай, когато полето за данни на отговора е празно:
Тяло на отговора
Завършваща част на
отговора
[Ново поле за данни] Нови SW1 SW2
T SW L SW SW T CC L CC CC
„99“ „02“ Нови SW1 SW2 „8E“ „04“ CC
Данни, които се включват в контролната сума = T SW ||
L SW || SW || PB
5.2. Третиране на грешки при защитен обмен на съобщения
CSM_026 Когато тахографската карта при интерпретирането на
дадена команда разпознае грешка при защитен обмен на
съобщения, необходимо е байтовете за състоянието да
бъдат върнати без защитен обмен. В съответствие с
ISO/IEC 7816-4, за посочване на грешки при защитен
обмен на съобщения са определени следните байтове за
състояние:
„66 88“: Неуспешна проверка на криптографската
контролна сума,
„69 87“: Липса на очаквани обекти от данни за защитен
обмен,
„69 88“: Неверни обекти от данни за защитен обмен.
CSM_027 Когато тахографската карта върне байтове за състояние
без посочени обекти от данни за защитен обмен (SM
DOs) или с погрешен обект от данни за защитен обмен
(SM DO), бордовото устройство трябва да прекрати
сесията.
5.3. Алгоритъм за изчисляване на криптографските контролни суми
CSM_028 Криптографските контролни суми се съставят с
използване на подробни кодове за автентификация на
съобщенията (retail MACs), в съответствие със стандарт
ANSI X9.19, с използване на DES:
— Начален стадий: Първоначалният контролен блок y0 е
E(Ka, SSC).
— Последващ стадий: Контролните блокове y1, .., yn се
изчисляват с използване на Ka.
— Краен стадий: Криптографската контролна сума се
изчислява въз основа на последния контролен блок
yn, както следва: E(Ka, D(Kb, yn)).
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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“||„05“||„2B“||„0E“||„03“||„02“||„1A“||
„05“||„00“||„04“||„14“||Хеш-стойност.
6.2. Проверка на подписите
CSM_035 При проверката на електронните подписи на изтеглените
данни трябва да се следва схемата за електронни подписи
с допълнение, дефинирана в референтния документ
[PKCS1] с функцията за хеширане SHA-1.
Необходимо е европейският публичен ключ EUR.PK да
бъде познат на проверителя по независим път и прове­
рителят да има доверие в него.
В следната таблица е илюстриран протоколът, който
може да бъде следван от специализирано интелигентно
устройство (IDE) с вложена в него контролна карта за
проверка на цялостността на данните, изтеглени и
съхранени на външен носител на информация (ESM).
Контролната карта се използва за дешифриране на елек­
тронните подписи. В такъв случай тази функция може да
не е въведена в IDE.
Оборудването, което е изтеглило и подписало подле­
жащите на анализ данни, е означено със съкращението
EQT.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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 user
X (сертифициращият орган, издал сертификата на
ползвателя X)
X.CAR The certificate authority reference mentioned in the certi­
ficate of user X (референтното означение на сертифи­
циращия орган, посочено в сертификата на ползвателя
X)
X.CHR The certificate holder reference mentioned in the certificate
of user X (референтното означение на титуляря на
сертификата, посочено в сертификата на ползвателя X)
X.PK Public key of user X (публичен ключ на ползвателя Х)
X.SK Private key of user X (частен ключ на ползвателя Х)
X.PK eph Ephemeral public key of user X (краткотраен (ephemeral)
публичен ключ на ползвателя Х)
X.SK eph Ephemeral private key of user X (краткотраен
(ephemeral) частен ключ на ползвателя Х)
„xx“ A hexadecimal value (шестнадесетична стойност)
|| Concatenation operator (оператор за конкатенация)
7.3. Определения
Определенията на използваните в настоящото допълнение термини
са включени в раздел I от приложение 1В.
8. КРИПТОГРАФСКИ СИСТЕМИ И АЛГОРИТМИ
8.1. Криптографски системи
CSM_38 Бордовите устройства и тахографските карти трябва да
използват класическа базираща се на елиптична крива
криптографска система с публичен ключ за пред­
оставяне на следните механизми за сигурност:
— взаимно удостоверяване на автентичност между
бордово устройство и карта,
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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 12
CS#3 512/521 256 SHA-512 16
Забележка: Размерите на ECC ключове от 512 бита и
521 бита се считат за равни по сила за всички цели в
рамките на настоящото допълнение.
9. КЛЮЧОВЕ И СЕРТИФИКАТИ
9.1. Двойки от асиметрични ключове и сертификати на публични
ключове
9.1.1 Общи положения
Забележка: описаните в настоящия раздел ключове се използват за
взаимно удостоверяване на автентичност и за защитен обмен на
съобщения между бордови устройства и тахографски карти, както
и между бордови устройства и външни устройства за GNSS. Тези
процеси са описани подробно в глава 10 и глава 11 от настоящото
допълнение.
CSM_51 В рамките на Европейската система за интелигентни
тахографи, двойките ECC ключове и съответните
сертификати се генерират и управляват на три
функционални йерархични равнища:
— европейско равнище,
— равнище на държавата членка,
— равнище на вид оборудване.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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 е KM DSRC .
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 468
Поле ID на полето Таг Дължи-на (бай-тове)
ASN.1 тип на данните
(вж. допълнение 1)
Идентификатор на
профила на серти­
фиката
CPI „5F 29“ „01“
Референтно
означение на серти­
фициращия орган
CAR „42“ „08“
Оторизация на
титуляря на серти­
фиката
CHA „5F 4C“ „07“
Публичен ключ PK „7F 49“ променлива
Домейн параметри DP „06“ променлива
Публична точка PP „86“ променлива
Референтно
означение на
титуляря на серти­
фиката
CHR „5F 20“ „08“
Дата на влизане в
сила на сертификата
CEfD „5F 25“ „04“
Дата на изтичане на
сертификата
CExD „5F 24“ „04“
Подпис на ECC
сертификат
S „5F 37“ променлива
Забележка: идентификаторите на полета се използват в
следващи раздели на настоящото приложение за озна­
чаване на отделните полета в даден сертификат,
например X.CAR е референтно означение на сертифи­
циращия орган, посочен в сертификата на ползвател X.
9.3.2.1 Идентификатор на профила на сертификата
CSM_137 Сертификатите трябва да имат идентификатор на
профила на сертификата, показващ какъв е използваният
профил на сертификат. Версия 1, посочена във таблица
4, се идентифицира със стойността „00“.
9.3.2.2 Референтно означение на сертифициращия орган
CSM_138 Референтното означение на сертифициращия орган се
използва за идентифициране на публичния ключ, който
служи за проверяване на подписа на сертификата. След­
ователно референтното означение на сертифициращия
орган трябва да е еднакво с референтното означение
на титуляря на сертификата на съответния серти­
фициращ орган.
CSM_139 Всеки основен сертификат на ERCA трябва да е само­
подписан, т.е. референтното означение на сертифи­
циращия орган и референтното означение на титуляря
на сертификата в този сертификат трябва да са еднакви.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 474
Фигура 4
Протокол за проверка от бордово устройство на веригата на сертифициране на карта
10.2.2 Проверка от карта на веригата на сертифициране на бордово
устройство
CSM_161 ►M1 За проверяване на веригата на сертифициране на
бордово устройство тахографските карти трябва да
използват протокола, описан във фигура 5. За всеки
сертификат, представен от бордовото устройство,
картата трябва да провери дали полето за оторизация
на титуляра на картата (Card Holder Authorisation —
CHA) е правилно:
— CHA в сертификат VU.Link трябва да указва ERCA.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 475
— CHA в сертификат VU.CA трябва да указва MSCA.
— Полето CHA в сертификата на бордовото устройство
трябва да указва сертификат на бордово устройство
за взаимно удостоверяване на автентичността (вж.
допълнение 1, тип данни EquipmentType). ◄
Фигура 5
Протокол за проверка от карта на веригата на сертифициране на бордово устройство
Забележки към фигура 5:
— Посочените във фигурата сертификати и публични ключове VU
са тези, които се използват за взаимно удостоверяване на автен­
тичността. В раздел 9.1.4 те са означени като VU_MA.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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 16 16 16
11 Отговор Данни за удостове­
ряване на автентич­
ността + съдържание
на файла
16 или 32, зависи
от файла
16 или 32, зависи
от файла
32 / 48 32 / 48 32 / 48
41 Заявка Сериен номер на
MoS
8 8 16 16 16
41 Отговор Ключ за сдвояване 16 16 / 24 / 32 16 32 32
42 Заявка Сесиен ключ 16 16 / 24 / 32 16 32 32
43 Заявка Информация за
сдвояване
24 24 32 32 32
50 Отговор Информация за
сдвояване
24 24 32 32 32
70 Заявка Данни за удостове­
ряване на автентич­
ността
8 8 16 16 16
80 Отговор Стойност на брояча
на MoS + данни за
удост. на автент.
8 8 16 16 16
▼B
CSM_219 Информацията за сдвояване, изпращана с инструкции
номер 43 (заявка от бордовото устройство) и номер 50
(отговор от датчика за движение) трябва да бъде
събрана, както е специфицирано в раздел 7.6.10 от [ISO
16844-3], с тази разлика, че в схемата за криптиране на
данните за сдвояване се използва алгоритъмът AES
вместо алгоритъма TDES, като по този начин се
получават две криптирания AES и се възприема специфи­
цираното в CSM_220 запълване, за да има съответствие с
размера на AES блок. Използваният за това криптиране
ключ K' p трябва да бъде генериран както следва:
— В случай, че ключът за сдвояване K P е с дължина 16
байта: K' p = K P XOR (N s ||N s )
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 496
— Не е възможно да се използва карта за монтаж и
настройки от първо поколение за куплиране към
датчик за движение на бордово устройство от второ
поколение.
13. СИГУРНОСТ ПРИ ВРЪЗКА ОТ РАЗСТОЯНИЕ ПО DSRC
13.1. Общи положения
Както е специфицирано в допълнение 14, бордовото устройство
редовно генерира данни за дистанционен мониторинг на тахографа
(Remote Tachograph Monitoring — RTM) и изпраща тези данни на
(вътрешно или външно) устройство за връзка от разстояние (Remote
Communication Facility — RCF). Устройството за връзка от
разстояние има за задача да изпраща тези данни по описаната в
допълнение 14 DSRC до дистанционното разпитващо устройство.
В допълнение 1 е посочено, че RTM данните представляват конка­
тенация на:
Криптирани полезни данни от тахографа (криптирането на
открития текст на полезните данни от тахографа)
Данни за сигурността на DSRC (описани по-долу)
Форматът на тахографските полезни данни в открит текст е специ­
фициран в допълнение 1 и доуточнен в допълнение 14. В
настоящата секция е описана структурата на данните за сигурността
на DSRC; официалната спецификация е в допълнение 1.
CSM_223 Данните в открит текст, които се
съобщават от бордово устройство на устройство за връзка
от разстояние (RCF — ако това устройство е външно за
бордовото устройство) или от бордово устройство на
дистанционно разпитващо устройство по DSRC
интерфейс (ако RCF е вътрешно устройство в бордовото
устройство) трябва да бъдат защитени в режим „крип­
тиране с последващо автентифициране“, т.е. тахог­
рафските полезни данни първо се криптират за да се
осигури поверителността на съобщението и след това се
изчислява автентификационен код (MAC) за съоб­
щението, за да се осигури автентичност и цялостност на
данните.
CSM_224 Данните за сигурността на DSRC трябва да представляват
конкатенация на следните елементи от данни в следния
ред; вж. също фигура 12:
Текуща дата и час (текущата дата и час на бордовото
устройство (тип данни ))
Брояч (3-байтов брояч, вж. CSM_225)
▼M1
Сериен номер на бордовото устройство (серийният номер на бордовото устройство
или идентификаторът на искането за
сертификат (тип данни VuSerialNumber
или CertificateRequestID) — вж. CSM_123
▼B
номер на версията на главния ключ за DSRC (1-байтовият номер на версията на главния
ключ за DSRC, от който са изведени
специфични за бордовото устройство
ключове за DSRC, вж. раздел 9.2.2.)
MAC (Стойността на MAC, изчислена върху
всички предходни байтове в RTM данните).
CSM_225 3-байтовият брояч в данните за сигурността на DSRC
трябва да бъде във формат с най-старшия байт на първо
място (MSB-first format). Когато дадено бордово
устройство за пръв път изчислява набор от RTM данни
след неговото влизане в експлоатация, стойността в
брояча му трябва да е настроена да е 0. Бордовото
устройство трябва да увеличава стойността в брояча на
данните с 1 преди всяко изчисление от него на нов набор
от RTM данни.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 501
Фигура 13
Протокол за проверка на подписа върху изтеглен файл с данни
▼M1
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.12.2013 г.,
стр. 1).
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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*hh
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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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' 85 85
1-во изречение GSA NMEA „02“ 85 85
2-ро изречение GSA NMEA '03' 85 85
3-то изречение GSA NMEA '04' 85 85
4-то изречение GSA NMEA '05' 85 85
5-о изречение GSA NMEA '06' 85 85
Разширен сериен номер на
външното устройство за GNSS,
дефиниран в допълнение 1 като
SensorGNSSSerialNumber.
'07' 8 8
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 514
Файл / елемент от данни
Номер на
записа
Размер (байтове)
Стойности
по подраз­
биране
Идентификатор на операционната
система на защитения приемопред­
авател за GNSS, дефиниран в
допълнение 1 като SensorOSIden­
tifier.
'08' 2 2
Номер на одобрението на типа на
външното устройство за GNSS,
дефиниран в допълнение 1 като
SensorExternalGNSSApproval­
Number.
'09' 16 16
Идентификатор на компонента за
сигурност на външното устройство
за GNSS, дефиниран в допълнение
1 като SensorExternalGNSSSCIden­
tifier
'10' 8 8
AMC изречение '11' 85 85
1-во ASA изречение '12' 85 85
2-ро ASA изречение '13' 85 85
3-то ASA изречение '14' 85 85
4-то ASA изречение '15' 85 85
5-о ASA изречение '16' 85 85
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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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 VU нелични нелични не е необходимо
съгласие
задъл­
жително
CalibrationDate ISO 16844-7 VU нелични нелични не е необходимо
съгласие
задъл­
жително
TachographVehic­
leSpeed
ISO 16844-7 VU лични не се прилага съгласие на
водача
задъл­
жително
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 529
Наименование на
данните
Формат на
данните
Източ­
ник
Класификация на данните (лични/
нелични) Съгласие за налич­
ността на данните
Наличност
водач втори водач
Driver1WorkingState ISO 16844-7 VU лични не се прилага съгласие на
водача
задъл­
жително
Driver2WorkingState ISO 16844-7 VU не се прилага лични съгласие на
втория водач
задъл­
жително
DriveRecognize ISO 16844-7 VU нелични нелични не е необходимо
съгласие
задъл­
жително
Driver1TimeRela­
tedStates
ISO 16844-7 VU лични не се прилага съгласие на
водача
задъл­
жително
Driver2TimeRela­
tedStates
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
задъл­
жително
DriverCardDriver1 ISO 16844-7 VU лични не се прилага съгласие на
водача
задъл­
жително
DriverCardDriver2 ISO 16844-7 VU не се прилага лични съгласие на
втория водач
задъл­
жително
OverSpeed ISO 16844-7 VU лични не се прилага съгласие на
водача
задъл­
жително
TimeDate Допълнение 8 VU нелични нелични не е необходимо
съгласие
задъл­
жително
HighResolutionTotal­
VehicleDistance
ISO 16844-7 VU нелични нелични не е необходимо
съгласие
задъл­
жително
HighResolutionTri­
pDistance
ISO 16844-7 VU нелични нелични не е необходимо
съгласие
задъл­
жително
ServiceComponentI­
dentification
ISO 16844-7 VU нелични нелични не е необходимо
съгласие
задъл­
жително
ServiceDelayCalen­
darTimeBased
ISO 16844-7 VU нелични нелични не е необходимо
съгласие
задъл­
жително
Driver1Identification ISO 16844-7 Кар­
та на
вод­
ач
лични не се прилага съгласие на
водача
задъл­
жително
Driver2Identification ISO 16844-7 Кар­
та на
вод­
ач
не се прилага лични съгласие на
втория водач
задъл­
жително
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 530
Наименование на
данните
Формат на
данните
Източ­
ник
Класификация на данните (лични/
нелични) Съгласие за налич­
ността на данните
Наличност
водач втори водач
NextCalibrationDate Допълнение 8 VU нелични нелични не е необходимо
съгласие
задъл­
жително
Driver1ContinuousD­
rivingTime
ISO 16844-7 VU лични не се прилага съгласие на
водача
задъл­
жително
Driver2ContinuousD­
rivingTime
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
задъл­
жително
Driver1CumulativeB­
reakTime
ISO 16844-7 VU лични не се прилага съгласие на
водача
задъл­
жително
Driver2CumulativeB­
reakTime
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
задъл­
жително
Driver1CurrentDura­
tionOfSelectedAc­
tivity
ISO 16844-7 VU лични не се прилага съгласие на
водача
задъл­
жително
Driver2CurrentDura­
tionOfSelectedAc­
tivity
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
задъл­
жително
SpeedAuthorised Допълнение 8 VU нелични нелични не е необходимо
съгласие
задъл­
жително
TachographCardSlot1 ISO 16844-7 VU нелични не се прилага не е необходимо
съгласие
задъл­
жително
TachographCardSlot2 ISO 16844-7 VU не се прилага нелични не е необходимо
съгласие
задъл­
жително
Driver1Name ISO 16844-7 Кар­
та на
вод­
ач
лични не се прилага съгласие на
водача
задъл­
жително
Driver2Name ISO 16844-7 Кар­
та на
вод­
ач
не се прилага лични съгласие на
втория водач
задъл­
жително
OutOfScopeCondition ISO 16844-7 VU нелични нелични не е необходимо
съгласие
задъл­
жително
ModeOfOperation ISO 16844-7 VU нелични нелични не е необходимо
съгласие
задъл­
жително
Driver1CumulatedD­
rivingTimePreviou­
sAndCurrentWeek
ISO 16844-7 VU лични не се прилага съгласие на
водача
задъл­
жително
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 531
Наименование на
данните
Формат на
данните
Източ­
ник
Класификация на данните (лични/
нелични) Съгласие за налич­
ността на данните
Наличност
водач втори водач
Driver2CumulatedD­
rivingTimePreviou­
sAndCurrentWeek
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
задъл­
жително
EngineSpeed ISO 16844-7 VU лични не се прилага съгласие на
водача
по избор
RegisteringMem­
berState
Допълнение 8 VU нелични нелични не е необходимо
съгласие
задъл­
жително
VehicleRegistration­
Number
Допълнение 8 VU нелични нелични не е необходимо
съгласие
задъл­
жително
Driver1EndOfLast­
DailyRestPeriod
ISO 16844-7 VU лични не се прилага съгласие на
водача
по избор
Driver2EndOfLast­
DailyRestPeriod
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
по избор
Driver1EndOfLast­
WeeklyRestPeriod
ISO 16844-7 VU лични не се прилага съгласие на
водача
по избор
Driver2EndOfLast­
WeeklyRestPeriod
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
по избор
Driver1EndOfSecon­
dLastWeeklyRest­
Period
ISO 16844-7 VU лични не се прилага съгласие на
водача
по избор
Driver2EndOfSecon­
dLastWeeklyRest­
Period
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
по избор
Driver1TimeLastLoa­
dUnloadOperation
ISO 16844-7 VU лични не се прилага съгласие на
водача
по избор
Driver2TimeLastLoa­
dUnloadOperation
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
по избор
Driver1CurrentDai­
lyDrivingTime
ISO 16844-7 VU лични не се прилага съгласие на
водача
по избор
Driver2CurrentDai­
lyDrivingTime
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
по избор
Driver1CurrentWeek­
lyDrivingTime
ISO 16844-7 VU лични не се прилага съгласие на
водача
по избор
Driver2CurrentWeek­
lyDrivingTime
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
по избор
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 532
Наименование на
данните
Формат на
данните
Източ­
ник
Класификация на данните (лични/
нелични) Съгласие за налич­
ността на данните
Наличност
водач втори водач
Driver1TimeLeftUn­
tilNewDailyRest­
Period
ISO 16844-7 VU лични не се прилага съгласие на
водача
по избор
Driver2TimeLeftUn­
tilNewDailyRest­
Period
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
по избор
Driver1CardExpi­
ryDate
ISO 16844-7 Кар­
та на
вод­
ач
лични не се прилага съгласие на
водача
по избор
Driver2CardExpi­
ryDate
ISO 16844-7 Кар­
та на
вод­
ач
не се прилага лични съгласие на
втория водач
по избор
Driver1CardNext­
MandatoryDownlo­
adDate
ISO 16844-7 VU лични не се прилага съгласие на
водача
по избор
Driver2CardNext­
MandatoryDownlo­
adDate
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
по избор
TachographNextMan­
datoryDownloadDate
ISO 16844-7 VU нелични нелични не е необходимо
съгласие
по избор
Driver1TimeLeftUn­
tilNewWeeklyRest­
Period
ISO 16844-7 VU лични не се прилага съгласие на
водача
по избор
Driver2TimeLeftUn­
tilNewWeeklyRest­
Period
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
по избор
Driver1Numbe­
rOfTimes9hDailyDri­
vingTimesExceeded
ISO 16844-7 VU лични не се прилага съгласие на
водача
по избор
Driver2Numbe­
rOfTimes9hDailyDri­
vingTimesExceeded
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
по избор
Driver1CumulativeU­
ninterruptedRestTime
ISO 16844-7 VU лични не се прилага съгласие на
водача
по избор
Driver2CumulativeU­
ninterruptedRestTime
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
по избор
Driver1MinimumDai­
lyRest
ISO 16844-7 VU лични не се прилага съгласие на
водача
по избор
Driver2MinimumDai­
lyRest
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
по избор
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 533
Наименование на
данните
Формат на
данните
Източ­
ник
Класификация на данните (лични/
нелични) Съгласие за налич­
ността на данните
Наличност
водач втори водач
Driver1MinimumWe­
eklyRest
ISO 16844-7 VU лични не се прилага съгласие на
водача
по избор
Driver2MinimumWe­
eklyRest
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
по избор
Driver1MaximumDai­
lyPeriod
ISO 16844-7 VU лични не се прилага съгласие на
водача
по избор
Driver2MaximumDai­
lyPeriod
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
по избор
Driver1MaximumDai­
lyDrivingTime
ISO 16844-7 VU лични не се прилага съгласие на
водача
по избор
Driver2MaximumDai­
lyDrivingTime
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
по избор
Driver1NumberOfU­
sedReducedDaily­
RestPeriods
ISO 16844-7 VU лични не се прилага съгласие на
водача
по избор
Driver2NumberOfU­
sedReducedDaily­
RestPeriods
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
по избор
Driver1Remainin­
gCurrentDrivingTime
ISO 16844-7 VU лични не се прилага съгласие на
водача
по избор
Driver2Remainin­
gCurrentDrivingTime
ISO 16844-7 VU не се прилага лични съгласие на
втория водач
по избор
VehiclePosition Допълнение 8 VU лични лични съгласие на
водача и на
втория водач
задъл­
жително
ByDefaultLoadType Допълнение 8 VU лични лични съгласие на
водача и на
втория водач
задъл­
жително
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 537
средство, които удостоверяват, че е възможно това превозно
средство да нарушава разпоредбите на Регламент (ЕС) №165/2014
и следва да бъде набелязано за спиране с оглед на по-нататъшно
разследване.
Съгласно Регламент (ЕС) №165/2014 събраните данни се огра­
ничават до данните, които удостоверяват възможно нарушение,
или са свързани с тези данни, както е определено в член 9 от
Регламент (ЕС) № 165/2014.
▼M1
В този сценарий наличното време за връзка е ограничено, тъй като
връзката е целева и е разчетена за малък обсег. Освен това същите
съобщителни средства за наблюдение на тахографа от
разстояние (RTM) могат да бъдат използвани от компетентните
контролни органи и за други приложения (например за максимално
допустимите маси и размери на тежкотоварни превозни средства,
определени в Директива (ЕС) 2015/719), като тези действия могат
да бъдат отделни или последователни по преценка на компет­
ентните контролни органи.
▼B
В настоящото допълнение се определя:
— Съобщителното оборудване, процедури и протоколи, които да
се използват за връзката
— Стандартите и регламентите, на които трябва да отговаря радио­
техническото оборудване
— Представянето на данните на оборудването за връзката
— Процедурите за запитване и изтегляне на данни и последовател­
ността на операциите
— Данни, които трябва да бъдат предадени
— Възможно тълкуване на данните, предадени по връзката
— Разпоредби за свързаните със сигурността данни, отнасящи се
до връзката
— Предоставянето на данните на компетентните контролни органи
— Как четецът за връзка с цел ранно откриване от разстояние може
да заяви различни концепти на данни за теглото и други харак­
теристики на превозните средства
Трябва да се поясни, че в настоящото допълнение не се определят:
— събирането на данни за функционирането и управлението в
рамките на бордовото устройство (което се определя при проек­
тирането на съответния продукт, освен ако е посочено друго в
Регламент (ЕС) № 165/2014)
— формата на представяне на събраните данни на представителя на
компетентните контролни органи, нито критериите, които да се
използват от тези органи при вземането на решение кои
превозни средства да бъдат спрени (което се определя при
проектирането на продукта, освен ако е посочено друго в
Регламент (ЕС) № 165/2014 или в решение за политиката на
компетентните контролни органи). За пояснение: данните се
предоставят по връзката на компетентните контролни органи
само за да могат те да вземат информирани решения
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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 coope­
rative telematics applications for regulated commercial freight
vehicles (TARV).
[5] EN 300 674-1 Electromagnetic compatibility and Radio spectrum
Matters (ERM); Road Transport and Traffic Telematics (RTTT);
Dedicated Short Range Communication (DSRC) transmission
equipment (500 kbit/s / 250 kbit/s) operating in the 5,8 GHz
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.002 — 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 interface defi­
nition for dedicated short- range communication (Електронно
събиране на такси. Определяне на приложния интерфейс за
обмен на информация на близки разстояния).
4 ОПЕРАТИВНИ СЦЕНАРИИ
4.1 Преглед
Регламент (ЕС) № 165/2014 предоставя конкретни и контролирани
сценарии, в рамките на които да се използва връзката.
Поддържат се следните сценарии:
„Communication Profile 1:(Профил 1 за връзката:) Roadside
inspection using a short range wireless communication Remote Early
Detection Communication Reader instigating a physical roadside
inspection (master-:-slave) (Пътна проверка, използвайки четец за
връзка с цел ранно откриване от разстояние чрез съобщителна
система с малък обсег на действие, която да предизвика
физическа пътна проверка (главен-:-подчинен)
Reader Profile 1a: (Профил 1а за четеца:) via a hand aimed or
temporary roadside mounted and aimed Remote Early Detection
Communication (чрез ръчно насочен или временно монтиран край
пътя четец за връзка с цел ранно откриване)
Reader Profile 1b: (Профил 1б за четеца:) via a vehicle mounted and
directed Remote Early Detection Communication Reader (чрез
монтиран на превозно средство и насочен четец за връзка с цел
ранно откриване)“.
4.1.1 Условия за прехвърляне на данни чрез интерфейса към DSRC на
5,8 GHz
ЗАБЕЛЕЖКА: за разбиране на контекста за предварителните
условия трябва да се направи справка с фигура 14.3 по-долу.
4.1.1.1 Данни, съхранявани в бордовото устройство (VU)
DSC_12 От бордовото устройство се изисква да актуализира на
всеки 60 секунди и да поддържа данните, които трябва
да се съхраняват в него, без никакво участие на
функцията за специализирана връзка с малък обсег на
действие (DSRC). Това се постига по вътрешен за
бордовото устройство начин, който е определен не в
настоящото допълнение, а в раздел 3.19 „Връзка от
разстояние за целеви пътни проверки“ от приложение
1В към Регламент (ЕС) № 165/2014.
4.1.1.2 Данни, предоставяни на средството за DSRC на бордовото
устройство (DSRC-VU)
DSC_13 От бордовото устройство се изисква да актуализира пред­
аваните по DSRC тахографски данни (данните) всеки път
когато съхраняваните в него данни се актуализират през
интервала, определен в точка 4.1.1.1 (DSC_12), без
никакво участие на функцията за DSRC.
DSC_14 Данните в бордовото устройство се използват като основа
за получаване и актуализиране на полезните данни
(данните), като начинът за постигане на това е
определен в раздел 3.19 „Връзка от разстояние за
целеви пътни проверки“ от приложение 1В, а ако не е
определен там, се определя не в настоящото допълнение,
а при проектирането на съответния продукт. Проекти­
рането на връзката между средството за DSRC на
бордовото устройство и самото бордово устройство се
разглежда в раздел 5.6.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 559
► (2) (3) M1
► (1) M3
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 561
(1)
Елемент на RTM Data
(2)
Действие, извършено от VU
(3)
ASN.1 определение на данните
RTM3
Управление без
валидна карта
VU генерира булева
стойност на елемента
RTM3 на данните
tp15638DrivingWithout­
ValidCard.
VU присвоява стойност
TRUE на променливата
tp15638DrivingWithout­
ValidCard, ако през
последните 10 дни във VU
е регистрирано най-малко
едно събитие на управление
без съответната карта,
както е определено в
приложение IB.
1 (TRUE): ако
последното събитие на
управление без съот­
ветната карта е
приключило през
последните 10 дни или
все още е в ход;
0 (FALSE): във всички
останали случаи,
tp15638DrivingWithout­
ValidCard
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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 586
1) Изпитване чрез ECHO за валидиране на безжичния
съобщителен канал DSRC-REDCR >>-:-
2) Изпитване за сигурност от край до край, за да се
гарантира, че карта за монтаж и настройки може да
получи достъп до съдържанието от криптирани и
подписани данни, създадено от VU и предадено по
безжичния съобщителен канал.
6.2 ECHO
Настоящият раздел съдържа специални разпоредби за изпитване
само дали функционира каналът DSRC-REDCR >>-:-
Целта на командата ECHO е да даде възможност на сервизи или
изпитателни пунктове за одобрение на типа да проверят дали DSRC
функционира, без да е нужен достъп до сертификати за сигурност.
Поради това от изпитвателното оборудване се изисква само да е в
състояние да инициализира връзка по DSRC (изпращайки BST с
AID=2), след това да изпрати команда ECHO и, ако DSRC
функционира, да приеме отговора на ECHO. Виж 5.4.8 за
подробности. Ако то получи правилно този отговор, каналът за
DSRC (DSRC-REDCR >>-:-
като функциониращ правилно.
6.3 Изпитване за валидиране на съдържанието от защитени данни
DSC_85 Това изпитване се извършва за валидиране на защитения
от край до край поток от данни. За такова изпитване е
необходим тестов DSRC четец. Тестовият DSRC четец
изпълнява същите функции и спецификации, както изпол­
званият от правоприлагащите органи, като разликата се
състои в това, че за удостоверяване на автентичността
на ползвателя на тестовия DSRC четец се използва
карта за монтаж и настройки, а не контролна карта.
Изпитването може да бъде извършено след първона­
чалното активиране на интелигентен тахограф или в
края на процедурата на калибриране. След активирането
превозното средство генерира и съобщава на DSRC-VU
защитените данни за равно откриване.
DSC_86 Сервизният техник поставя тестовия DSRC четец на
разстояние между 2 и 10 метра пред превозното средство.
DSC_87 После сервизният техник вкарва карта за монтаж и
настройки в тестовия DSRC четец, за да заяви разпит­
ването на бордовото устройство за данни за ранно
откриване. След успешно разпитване сервизният техник
осъществява достъп до получените данни, за да се
убеди, че те са валидирани успешно за цялост и са
декриптирани.
▼B
02016R0799 — BG — 21.08.2023 — 003.002 — 587
ДОБАВКА
Правила за изчисляване на дневното, седмичното и двуседмичното време на
управление
1. Основни изчислителни правила
Бордовото устройство изчислява дневното време на управление,
седмичното време на управление и двуседмичното време на управление,
като използва съответните данни, съхранени върху карта на водач (или за
монтаж и настройки), вкарана в процепа за водача (процеп 1, четец на
карта #1) на бордовото устройство, и избрани дейности на водача, докато
картата е вкарана в бордовото устройство.
Времената на управление не трябва да се изчисляват, когато не е вкарана
карта на водача (или за монтаж и настройки).
НЕИЗВЕСТНИЯТ(ТЕ) период(и), установен(и) по време на периода,
необходим за изчисленията, се приема(т) за ПРЕКЪСВАНЕ/ПОЧИВКА.
НЕИЗВЕСТНИ периоди и дейности с отрицателна продължителност (т.е.
началото на дейността настъпва по-късно от края на дейността) поради
припокриване във времето между две различни бордови устройства или
поради сверяване на часовника, не се вземат под внимание.
Дейностите, записани върху картата на водач, съответстващи на периоди
„ИЗВЪН ОБХВАТ“ в съответствие с определението в буква гг) от
приложение IБ, се тълкуват, както следва:
— ПРЕКЪСВАНЕ/ПОЧИВКА се изчислява като „ПРЕКЪСВАНЕ“ или
„ПОЧИВКА“
— РАБОТА и УПРАВЛЕНИЕ се считат за „РАБОТА“
— НА РАЗПОЛОЖЕНИЕ се счита за „НА РАЗПОЛОЖЕНИЕ“
В контекста на настоящата добавка бордовото устройство приема, че има
дневен период на почивка в началото на записите на дейностите върху
картата.
2. Понятия
Следните понятия се отнасят изключително за настоящото допълнение и
са предназначени да определят изчисляването от бордовото устройство
на времето на управление и предаването му на по-късен етап от устрой­
ството за връзка от разстояние.
а) „смяна на RTM“ е периодът между края на дадена дневна почивка и
края на непосредствено следващата дневна почивка.
Бордовото устройство трябва да започне нова смяна на RTM след
завършване на дневната почивка.
Текущата смяна на RTM е периодът от края на последната дневна
почивка;
б) „общо време на управление“ е сборът от продължителността на
всички дейности по УПРАВЛЕНИЕ на водача в рамките на даден
период, докато не е „ИЗВЪН ОБХВАТ“;
в) „дневно време на управление“ е общото време на управление в
рамките на дадена смяна на RTM;
г) „седмично време на управление“ е общото време на управление за
текущата седмица;
д) „период на непрекъсната почивка“ е всеки непрекъснат период на
ПРЕКЪСВАНЕ/ПОЧИВКА;
е) „двуседмично време на управление“ е общото време на управление за
предходната и текущата седмица;
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 588
ж) „дневна почивка“ е периодът на ПРЕКЪСВАНЕ/ПОЧИВКА, който
може да бъде:
— редовна дневна почивка,
— разделена дневна почивка или
— намалена дневна почивка
В контекста на допълнение 14, когато бордово устройство изчислява
седмичните почивки, тези седмични почивки се считат за дневни
почивки;
з) „нормална дневна почивка“ е период на непрекъсната почивка от
най-малко 11 часа.
По изключение, когато е активно условието ПЪТУВАНЕ С
ФЕРИБОТ/ВЛАК, нормалната дневна почивка може да бъде
прекъсната най-много два пъти от дейности, различни от почивка, с
максимална обща продължителност от един час, т.е. нормалната
дневна почивка, съдържаща период(и) на пътуване с ферибот/влак,
може да бъде разделена(и) на две или три части. След това
бордовото устройство изчислява нормална дневна почивка, когато
общото време на почивка, изчислено съгласно точка 3, е най-малко
11 часа.
Когато нормалната дневна почивка е била прекъсната, бордовото
устройство:
— не трябва да включва дейността по управление, извършена по
време на тези прекъсвания, в изчисляването на дневното време
на управление, и
— започва нова смяна на RTM в края на нормалната дневна почивка,
която е била прекъсната.
Фигура 1
Пример за прекъсване на дневната почивка поради пътуване с ферибот/влак
i) „намалена дневна почивка“ е период на непрекъсната почивка от най-
малко 9 часа, но по-къса от 11 часа;
й) „разделена дневна почивка“ е дневна почивка, ползвана на две части:
— първата част трябва да бъде непрекъсната почивка от най-малко 3
часа, но по-къса от 9,
— втората част трябва да бъде непрекъсната почивка от най-малко 9
часа.
По изключение, когато по време на едната или и на двете части на
разделената дневна почивка е активно условие ПЪТУВАНЕ С
ФЕРИБОТ/ВЛАК, разделената дневна почивка може да бъде
прекъсната най-много два пъти от други дейности с обща продължи­
телност най-много от един час, т.е.:
— първата част от разделената дневна почивка може да бъде
прекъсната един или два пъти, или
— втората част от разделената дневна почивка може да бъде
прекъсната един или два пъти, или
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 589
— първата част от разделената дневна почивка може да бъде
прекъсната веднъж и втората част от разделената дневна
почивка може да бъде прекъсната веднъж.
Тогава бордовото устройство изчислява разделена дневна почивка,
когато общото време на почивка, изчислено в съответствие с точка 3, е:
— най-малко три часа и по-малко от 11 часа за първия период на
почивка и най-малко 9 часа за втория период на почивка, когато
първата почивка е била прекъсната от ПЪТУВАНЕ С
ФЕРИБОТ/ВЛАК.
— най-малко три часа и по-малко от 9 часа за първия период на
почивка и най-малко 9 часа за втория период на почивка,
когато първата почивка не е била прекъсната от ПЪТУВАНЕ С
ФЕРИБОТ/ВЛАК.
Фигура 2.
Пример за разделена дневна почивка, прекъсната поради пътуване с ферибот/влак
Когато разделената дневната почивка е прекъсната, бордовото
устройство:
— не трябва да включва дейността по управление, извършена по
време на тези прекъсвания, в изчисляването на дневното време
на управление, и
— започва нова смяна на RTM в края на разделената дневна
почивка, която е била прекъсната;
к) „седмица“ е периодът време по UTC между 00:00 часа в понеделник
и 24:00 часа в неделя;
3. Изчисляване на периода на почивка, когато той е бил прекъснат поради
пътуване с ферибот/влак
За изчисляването на периода на почивка, когато той е бил прекъснат
поради пътуване с ферибот/влак, бордовото устройство изчислява
общото време на почивка съгласно следните стъпки:
а) Стъпка 1
Бордовото устройство трябва да открива прекъсвания на времето на
почивка, настъпили преди активирането на флага ПЪТУВАНЕ С
ФЕРИБОТ/ВЛАК (НАЧАЛО), в съответствие с фигура 3 или фигура
4, според случая, и за всяко установено прекъсване трябва да прецени
дали са изпълнени следните условия:
— прекъсването прави общата продължителност на откритите
прекъсвания, включително прекъсванията, ако е приложимо,
настъпили през първата част от разделената дневна почивка
поради пътуване с ферибот/влак, да надвиши общо повече от
един час,
— прекъсването прави общия брой на откритите прекъсвания, вклю­
чително прекъсванията, ако е приложимо, настъпили по време на
първата част от разделената дневна почивка поради пътуване с
ферибот/влак, по-голям от две,
— след края на прекъсването съществува съхранено „Entry of place
where daily work periods end“ (Въведено място, където завършват
дневните периоди на работа).
Ако нито едно от горните условия не е изпълнено, към общото време
на почивка се добавя непрекъснатата почивка непосредствено преди
прекъсването.
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 590
Ако е изпълнено най-малко едно от горните условия, бордовото
устройство трябва или да спре изчисляването на общото време на
почивка съгласно стъпка 2, или да открие прекъсвания на времето
на почивка, настъпили след флага ПЪТУВАНЕ С ФЕРИБОТ/ВЛАК
(НАЧАЛО) съгласно стъпка 3.
б) Стъпка 2
За всяко прекъсване, установено съгласно стъпка 1, бордовото
устройство трябва да прецени дали изчисляването на общото време
на почивка следва да спре. Бордовото устройство спира процеса на
изчисляване, когато към общото време на почивка са добавени два
непрекъснати периода на почивка, възникнали преди активирането на
флага ПЪТУВАНЕ С ФЕРИБОТ/ВЛАК (НАЧАЛО), включително, ако
е приложимо, периодите на почивка, добавени в първата част на
разделена дневна почивка, също прекъсната от пътуване с
ферибот/влак. В противен случай бордовото устройство, трябва да
изпълни предвиденото в стъпка 3.
в) Стъпка 3
Ако след изпълнението на стъпка 2 бордовото устройство продължи
да изчислява общото време на почивка, бордовото устройство трябва
да открие прекъсвания, настъпили след дезактивирането на условието
за ПЪТУВАНЕ С ФЕРИБОТ/ВЛАК съгласно фигура 3 или фигура 4,
според случая.
За всяко установено прекъсване бордовото устройство трябва да
прецени дали това прекъсване прави общото време на всички уста­
новени прекъсвания повече от общо един час, като в този случай
изчисляването на общото време на почивка приключва в края на
непрекъснатия период на почивка преди прекъсването. В противен
случай периодите на непрекъсната почивка, които настъпват след
съответните прекъсвания, се добавят към изчисляването на дневната
почивка, докато условието в стъпка 4 бъде изпълнено.
г) Стъпка 4
Изчисляването на общото време на почивка спира, когато бордовото
устройство е добавило в резултат на стъпки 1 и 3 най-много две
непрекъснати почивки към периода на почивка, за който е активирано
условието ПЪТУВАНЕ С ФЕРИБОТ/ВЛАК, включително, ако е
приложимо, прекъсванията, настъпили по време на първата част на
разделената дневна почивка поради пътуване с ферибот/влак.
Фигура 3.
Обработване на времената на почивка от бордовото устройство, с цел да се определи дали дадена
прекъсната почивка трябва да се отчете като нормална дневна почивка или като първата част на
разделена дневна почивка
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 591
Фигура 4
Обработване на времената на почивка от бордовото устройство, с цел да се определи дали дадена
прекъсната почивка трябва да се отчете като втората част на разделена дневна почивка
Фигура 5
Пример за дневна почивка, прекъсната повече от два пъти, поради което почивката H не се
включва в изчислението
Фигура 6
Пример за дневна почивка, когато периодът на отчитане на ферибот/влак започва в края на
работния период
Фигура 7
Пример за дневна почивка, прекъсната повече от два пъти, поради което почивката B не се
включва в изчислението
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 592
Фигура 8.
Пример за разделена дневна почивка, прекъсната веднъж по време на първия период на почивка и
веднъж по време на втория период на почивка
4. Изчисляване на дневното, седмичното и двуседмичното време на
управление
Бордовото устройство трябва да изчислява дневното(ите) време(на) на
управление за текущата и предишните смени на RTM. Времето на
управление, настъпило по време на прекъсванията на дневните периоди
на почивка, не се добавя към изчисляването на дневното време на
управление, когато тези прекъсвания се дължат на пътуване с
ферибот/влак и са изпълнени изискванията, предвидени в точка 2,
букви з) и й) и в точка 3. Независимо от това, доколкото съгласно
точка 3 бордовото устройство не е изчислило пълна нормална или
разделена дневна почивка, времената на управление, които се случват
по време на прекъсванията, се добавят към дневното време на
управление за текущата смяна на RTM.
Бордовото устройство изчислява също така седмичното и двуседмичното
време на управление. Времето на управление, което настъпва по време
на прекъсванията на дневните почивки поради пътуване с ферибот/влак,
се добавя към изчисляването на седмичното и двуседмичното време на
управление.
▼M3
02016R0799 — BG — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 605
Допълнение 17
ПРЕХОДНИ РАЗПОРЕДБИ ОТНОСНО ИЗПОЛЗВАНЕТО НА OSNMA
ОТ ТАХОГРАФИТЕ
1. ОПРЕДЕЛЕНИЯ И СЪКРАЩЕНИЯ
1.1. Определения
Декларация за услугата за удостоверяване на автентичността на
навигационните съобщения от отворената услуга на
„Галилео“ (OSNMA) означава декларацията на Европейската
комисия, че OSNMA на „Галилео“ навлиза в експлоатационния си
етап.
Преходно бордово устройство: бордовото устройство отговаря на
разпоредбите на настоящото допълнение.
Преходните бордови устройства са конструирани в съответствие с
насоките на SIS ICD и OSNMA за приемника, приложими за етапа
на публично изпитване на OSNMA. Те съдържат приемник за GNSS,
който е в състояние да използва OSNMA, разполагаемо по време на
етапа на публично изпитване.
Преходните бордови устройства обаче не могат да удостоверяват
автентичността на навигационните съобщения, налични след декла­
рацията за услугата OSNMA, поради необходимостта от актуализация
на криптографския материал в бордовото устройство. Трябва да се
извърши подходяща актуализация на софтуера, така че устройствата
да могат да започнат да използват OSNMA и да отговарят на всички
изисквания на приложение IB и допълнения 1—16 към него. Преди
да бъдат актуализирани, в преходните бордови устройства са реали­
зирани функционалните възможности, свързани с OSNMA, както е
посочено в настоящото допълнение. Функционалните възможности,
които не са свързани с OSNMA, остават непроменени.
Ако се извършва подходяща актуализация на софтуера, в преходните
бордови устройства са реализирани насоките на SIS ICD и OSNMA за
приемника, приложими за експлоатационния етап на OSNMA, и
отговарят на всички изисквания на приложение IB и допълнения
1—16 към него, като използват OSNMA, разполагаемо по време на
експлоатационния етап.
Преходен тахограф: тахограф, включително преходно бордово
устройство.
1.2. Съкращения
ICD Документ за контрол на интерфейса
OSNMA Удостоверяване на автентичността на навигаци­
онните съобщения от отворената услуга на
„Галилео“ (Galileo Open Service Navigation
Message Authentication)
SIS Сигнал в космическото пространство
БУ Бордово устройство
▼M4
02016R0799 — BG — 21.08.2023 — 003.002 — 606
2. ОБЩИ СЪОБРАЖЕНИЯ, СВЪРЗАНИ С OSNMA
За да може превозните средства, регистрирани за първи път, да бъдат
оборудвани с тахографи от второ поколение, версия 2, считано от
поисканата дата на въвеждане, както е определено в раздел 1, буква
щщ) от приложение IВ към Регламент за изпълнение (ЕС) 2016/799, е
необходимо да бъде одобрен типът им, да се произвеждат и да се
пускат на пазара бордови устройства преди декларацията за услугата
OSNMA. За бордовите устройства, наричани преходни бордови
устройства, свързаните с OSNMA изисквания от приложение IB и
допълнения 1—16 към него трябва да бъдат адаптирани, така че
типът на устройствата да бъде одобрен и те да бъдат използвани в
реални условия.
С разпоредбите, предвидени в настоящото допълнение, се определят
специфичните изисквания, приложими за преходните бордови
устройства. Те се прилагат само за бордови устройства с вътрешен
приемник на сигнали от GNSS.
3. ИЗИСКВАНИЯ, ПРИЛОЖИМИ ЗА ПРИЕМНИКА НА СИГНАЛИ
ОТ GNSS НА ПРЕХОДНИТЕ ТАХОГРАФИ
TRA_001 Преходните бордови устройства трябва да включват
приемник на сигнали от GNSS, който може да използва OSNMA,
разполагаемо по време на етапа на публично изпитване.
TRA_002 Изискванията на допълнение 12 се прилагат за приемника
на сигнали от GNSS, включен в преходните бордови устройства, при
следните тълкувания:
— посочените насоки на SIS ICD и OSNMA за приемника са доку­
ментите, които са на разположение за етапа на публично
изпитване:
— потребителски документ за контрол на интерфейса за удосто­
веряване на автентичността на навигационните съобщения от
отворената услуга на „Галилео“ (OSNMA) за етапа на
изпитване, издание 1.0, ноември 2021 г.,
— насоки за удостоверяване на автентичността на навигационните
съобщения от отворената услуга на „Галилео“ (OSNMA) за
приемника за етапа на изпитване, издание 1.0, ноември 2021 г.,
— OSNMA е услугата, разполагаема по време на етапа на публично
изпитване,
— SIS е сигналът в космическото пространство, разполагаем по
време на етапа на публично изпитване.
TRA_003 Приемникът на сигнали от GNSS, включен в преходните
бордови устройства, трябва да бъде проектиран така, че след актуа­
лизация на софтуера му, направена чрез актуализация на софтуера на
бордовото устройство, да отговаря напълно на изискванията на
приложение 12, като използва OSNMA, разполагаемо по време на
експлоатационния етап.
4. ИЗИСКВАНИЯ, ПРИЛОЖИМИ ЗА ПРЕХОДНИТЕ БОРДОВИ
УСТРОЙСТВА
Преходните бордови устройства може да обработват сигнала за
OSNMA, разполагаем по време на етапа на публично изпитване, но
не са в състояние да докладват статуса по удостоверяването на автен­
тичността на навигационните съобщения от SIS, разполагаем по
време на експлоатационния етап на OSNMA, докато не бъде
извършена подходяща актуализация на софтуера. Поради това те
приемат, че стандартните местоположения, предоставяни от
приемника на сигнали от GNSS, винаги са с удостоверена автен­
тичност.
Прилагат се изискванията на приложение IB и допълнения 1—16 към
него, при следните тълкувания.
▼M4
02016R0799 — BG — 21.08.2023 — 003.002 — 607
TRA_004 Приложение IB, точка 3.9.15 „Времеви конфликт“,
изискване 86, се разбира по следния начин:
Това събитие се предизвиква извън режим на калибриране, когато
бордовото устройство открие несъответствие между времето от
функцията за измерване на времето на бордовото устройство и
времето, произлизащо от стандартните местоположения, предавани
от приемника на сигнали от GNSS или от външното устройство за
GNSS. „Времеви конфликт“ се установява, ако разликата във
времето надвишава ± 3 секунди, съответстваща на точността на
времето, определена в изискване 41а, като това се увеличава с макси­
малната неточност на времето на ден. Това събитие се регистрира
заедно със стойността на вътрешния часовник на уредите за регис­
триране на данните за движението. Бордовото устройство извършва
проверка за задействането на събитие „времеви конфликт“ точно
преди бордовото устройство автоматично да коригира вътрешния
часовник на бордовото устройство в съответствие с изискване 211.
TRA_005 Приложение IB, точка 3.9.18 Събитие „Аномалия в GNSS“,
изискване 88а, се разбира по следния начин:
Това събитие се задейства извън режим на калибриране, когато
приемникът на сигнали от GNSS открие атака , както е посочено в
допълнение 12. След задействане на събитието „Аномалия в GNSS“
през следващите 10 минути бордовото устройство не генерира
други събития „Аномалия в GNSS“
TRA_006 Приложение IB, точка 3.12.5 Записване и съхраняване на
данните в паметта, места и местоположения, където започват и
завършват дневните периоди на работа и/или където общото време на
управление на МПС достига 3 часа, изискване 110, се разбира по
следния начин:
Заедно с всяко място или местоположение, уредът за записване на
данните за движението трябва да записва и съхранява в своята
памет за данни:
— номера на картата на водач и/или на втория водач и държавата
членка, която е издала картата,
— поколението на картата,
— дата и час на въвеждането,
— вид на въвеждането (начало, край или 3 часа общо време на
управление на МПС),
— съответната точност на GNSS, датата и часа, ако е
приложимо,
— стойността от километражния брояч на превозното средство,
— флаг, указващ дали автентичността на местоположението се
приема за удостоверена.
TRA_007 Приложение IB, точка 3.12.17 Записване и съхраняване на
данните в паметта, пресичане на граници, изискване 133б, се разбира
по следния начин:
Заедно с държавата и местоположението, уредът за записване на
данните за движението трябва да записва и съхранява в своята
памет за данни:
— номера на картата на водач и/или на втория водач и държавата
членка, която е издала картата,
— поколението на картата,
— съответната точност на GNSS, датата и часа,
— флаг, указващ дали автентичността на местоположението се
приема за удостоверена,
— стойността на километражния брояч на превозното средство
при откриването на пресичане на граница.
▼M4
02016R0799 — BG — 21.08.2023 — 003.002 — 608
TRA_008 Приложение IB, точка 3.12.18 Записване и съхраняване на
данните в паметта, товаро-разтоварни операции, изискване 133ж, се
разбира по следния начин:
Заедно с типа на операцията и местоположението, уредът за
записване на данните за движението записва и съхранява в своята
памет за данни:
— номера на картата на водач и/или на втория водач и държавата
членка, която е издала картата,
— поколението на картата,
— датата и часът на товаро-разтоварната операция,
— съответната точност на GNSS, датата и часа, ако е
приложимо,
— флаг, указващ дали автентичността на местоположението се
приема за удостоверена,
— стойността от километражния брояч на превозното средство.
TRA_009 Приложение IB, точка 3.23 Сверяване на часовника,
изискване 211, се разбира по следния начин:
Настройката на времето на вътрешния часовник на бордовото
устройство трябва да се коригира автоматично на регулируеми
интервали от време. Следващото автоматично коригиране на
времето се задейства между 72 ч. и 168 ч. след предходното и
след като бордовото устройство може да получи достъп до
времето на GNSS чрез валидно стандартно съобщение за местополо­
жението в съответствие с допълнение 12. Въпреки това сверя­
ването на часовника никога не трябва да е по-голямо от натру­
паната максимална неточност на времето на ден, както е
изчислена от производителя на бордовото устройство в съот­
ветствие с изискване 41б. Ако разликата между времето на
вътрешния часовник на бордовото устройство и времето на
приемника на сигнали от GNSS е по-голяма от натрупаната
максимална неточност на времето на ден, тогава сверяването на
часовника трябва да направи вътрешния часовник на бордовото
устройство възможно най-близък до времето на приемника на
сигнали от GNSS. Настройката на времето може да се извърши
само ако времето, предоставено от приемника на сигнали от
GNSS, е получено чрез стандартни съобщения за местоположението,
както е определено в допълнение 12. Еталонното време за автома­
тичната настройка на времето на вътрешния часовник на
бордовото устройство е времето, дадено в стандартното
съобщение за местоположението.
TRA_010 Приложение IB, точка 3.23 Сверяване на часовника,
изискване 212, се разбира по следния начин:
Функцията за сверяване на часовника трябва също така да
позволява предизвикано сверяване на текущото време в режим на
калибриране.
Сервизите могат да сверяват часовника:
— или чрез записване на стойност за времето в бордовото
устройство, като използват услугата WriteDataByIdentifier в
съответствие с раздел 6.2 от допълнение 8,
— или чрез заявка за сверяване на часовника на бордовото
устройство с времето, предоставено от приемника на сигнали
от GNSS. Това може да се направи само ако времето, пред­
оставено от приемника на сигнали от GNSS, е получено чрез
използване на стандартни съобщения за местоположението. В
последния случай се използва услугата RoutineControl в съот­
ветствие с раздел 8 от допълнение 8.
▼M4
02016R0799 — BG — 21.08.2023 — 003.002 — 609
TRA_011 Допълнение 4, точка 2. Спецификация за блоковете данни,
първи абзац, седмо тире, се разбира по следния начин:
Когато се отпечатва след географската дължина и географската
ширина на записано местоположение или след датата и часа на
определяне на местоположението, пиктограмата показва, че
автентичността на това местоположение се приема за удосто­
верена.
TRA_012 Допълнение 8, точка 8.1 Услуга RoutineControl (сверяване
на часовника), описание на съобщението, изискване CPR_065a, се
разбира по следния начин:
Услугата RoutineControl (TimeAdjustment) осигурява възможност за
сверяване на часовника на бордовото устройство с времето, пред­
оставено от приемника на сигнали от GNSS.
За изпълнението на услугата RoutineControl (TimeAdjustment)
бордовото устройство трябва да бъде в режим CALIBRATION.
Предварително условие: осигурено е бордовото устройство да може
да получава от приемника на сигнали от GNSS стандартни
съобщения за местоположението.
Докато се извършва сверяването на часовника, бордовото
устройство трябва да отговаря на заявка RoutineControl,
подфункция requestRoutineResults, с routineInfo = 0x78.
Забележка: сверяването на часовника може да отнеме известно
време. Диагностичният тестер трябва да поиска статуса на сверя­
ването на часовника, като използва подфункцията requestRoutine­
Results.
TRA_013 В допълнение 12, точка 3 Изречения, предоставяни от
приемника на сигнали от GNSS, изискване GNS_4a:
Данните, съдържащи се в изреченията на AMC, предоставяни от
приемника на сигнали от GNSS, ако има такива, не се използват от
бордовото устройство, с изключение на следните стойности за
статуса:
J = заглушаване или O = друга атака срещу GNSS (чрез извършени
проверки за съответствие съгласно GNS_3a),
V = празно (по някаква друга причина няма местоположение с удос­
товерена автентичност).
TRA_014 В допълнение 12, точка 3 Изречения, предоставяни от
приемника на сигнали от GNSS, изискване GNS_5:
Данните, съдържащи се в изреченията на ASA, предоставяни от
приемника на сигнали от GNSS, ако има такива, не се използват
от бордовото устройство.
TRA_015 В допълнение 12, точка 5.2 Бордово устройство без
външно устройство за GNSS, прехвърляне на информация от
приемника на сигнали от GNSS към бордовото устройство,
изисквания GNS_34 и 36:
Процесорът на бордовото устройство не трябва да използва
информация, извлечена от изречението AMC, освен за следните
стойности на статуса:
J = заглушаване или O = друга атака срещу GNSS (чрез извършени
проверки за съответствие съгласно GNS_3a),
V = празно (по някаква друга причина няма местоположение с удос­
товерена автентичност).
Процесорът на бордовото устройство не трябва да използва
информация, извлечена от изречението ASA.
▼M4
02016R0799 — BG — 21.08.2023 — 003.002 — 610
TRA_016 Допълнение 12, точка 6 Обработка и записване от
бордовото устройство на данни за местоположението, изискване
GNS_39, се разбира по следния начин:
Данните за местоположението се съхраняват в бордовото
устройство, заедно с флаг, указващ дали автентичността на
местоположението се приема за удостоверена. Когато в
бордовото устройство трябва да се запишат данни за местополо­
жението, се прилага следното правило:
а) Ако стандартното местоположение е валидно, в бордовото
устройство се записва стандартното местоположение и
неговата точност, а за флага се задава „удостоверена автен­
тичност“.
TRA_017 Допълнение 12, точка 6 Обработка и записване от
бордовото устройство на данни за местоположението, изискване
GNS_40, се разбира по следния начин:
Когато за стойността на статуса в полученото изречение AMC е
зададено „J“или „O“ в съответствие с изискване GNS_4a, бордовото
устройство трябва да генерира и да запише събитие „Аномалия в
GNSS“, както е определено в изискване 88а от приложение IB и в
допълнение 1 (EventFaultType). Бордовото устройство може да
извърши допълнителни проверки, преди да запамети събитие
„Аномалия в GNSS“ след получаване на зададено „J“ или „O“.
TRA_018 Допълнение 12, точка 8 Конфликт относно движението на
превозното средство, изискване GNS_42, Условие 2 за задействане,
първо и второ тире след формулата се разбират по следния начин:
— GnssDistance е разстоянието между текущото местоположение
на превозното средство и предишното местоположение, като и
двете са получени от валидни стандартни съобщения за место­
положението, без да се взема предвид височината,
— OdometerDifference е разликата между текущата стойност на
километражния брояч и стойността на километражния брояч,
съответстваща на предишното валидно стандартно съобщение
за местоположението.
TRA_019 Допълнение 14, точка 5.4.5 Изисквания към протокола
DSRC за елементи на RtmData, извършени действия и определения,
изискване DSC_41, таблица 14.3, втора клетка на ред RTM20, се
разбира по следния начин:
Бордовото устройство генерира целочислена стойност за елемента
от данни RTM20 (timeReal от допълнение 1).
Бордовото устройство задава за стойността на RTM20 часа, в
който от приемника на сигнали от GNSS е било налично последното
стандартно местоположение на превозното средство.
Ако от приемника на сигнали от GNSS не е било налично стандартно
местоположение на превозното средство, бордовото устройство
задава за RTM20 стойност 0.
TRA_020 Производителят на преходно бордово устройство,
получило одобрение на типа, информира Комисията за неговите
версии на софтуера. Комисията публикува тези версии на софтуера
на публично достъпен уебсайт.
▼M4
02016R0799 — BG — 21.08.2023 — 003.002 — 611
5. СПЕЦИФИЧНИ РАЗПОРЕДБИ ЗА ОДОБРЯВАНЕ НА ТИПА И ЗА
ИЗПОЛЗВАНЕ НА ПРЕХОДНИ ТАХОГРАФИ
TRA_021 Типът на преходните бордови устройства трябва да бъде
одобрен в съответствие с изискванията на приложение IB и
приложения 1—16 към него, допълнени от разпоредбите на
настоящото допълнение.
TRA_022 Сертификати за одобрение на типа на преходните бордови
устройства и преходните тахографи могат да се изискват само до
31 декември 2023 г. или до датата на декларацията за услугата
OSNMA, в зависимост от това коя от двете дати е по-късна.
TRA_023 Преходните бордови устройства могат да се монтират на
превозни средства, регистрирани за първи път, само до 31 май 2024 г.
или 5 месеца след датата на декларацията за услугата OSNMA, в
зависимост от това коя от двете дати е по-късна.
▼M4
02016R0799 — BG — 21.08.2023 — 003.002 — 612
ПРИЛОЖЕНИЕ 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.002 — 613
2. Маркировката за одобрение се поставя върху указателната табелка на
всеки комплект уреди и на всеки тахографски лист и върху всяка тахог­
рафска карта. Маркировката трябва да бъде незаличима и винаги да бъде
ясно четлива.
3. Посочените по-долу размери на маркировката за одобрение ( 1 ) са
изразени в милиметри, като това са минимални стойности. Съот­
ношението между размерите трябва да бъде запазено.
▼C1
( 1 ) Показаните цифри служат само за насока.
02016R0799 — BG — 21.08.2023 — 003.002 — 614
II. СЕРТИФИКАТ ЗА ОДОБРЕНИЕ ЗА АНАЛОГОВИ ТАХОГРАФИ
Държавата членка, предоставила одобрение, издава на заявителя сертификат
за одобрение съгласно образеца по-долу. Когато уведомява други държави
членки за издадени одобрения или съответно за отменянето им, държавата
членка използва копия на въпросния сертификат.
СЕРТИФИКАТ ЗА ОДОБРЕНИЕ
Наименование на компетентния орган
Уведомление относно ( 1 ):
— одобрение на типа на уред за регистриране на данните за движението
— отменяне на одобрението на типа на уред за регистриране на данните за
движението
— одобрение на образец за тахографски лист
— отменяне на одобрението на образец за тахографски лист
Одобрение №:
...................................
1. Търговска марка или наименование
2. Наименование на типа или модела
3. Наименование на производителя
4. Адрес на производителя
5. Представено за одобрение на
6. Изпитано в
7. Дата и номер на изпитването/изпитванията
8. Дата на одобрението
9. Дата на отменяне на одобрението
10. Тип или типове уреди за регистриране на данните за движението, с
които листът е предназначен да бъде използван
11. Място
12. Дата
13. Приложени пояснителни документи
14. Забележки (включително разположение на пломбите, ако е приложимо)
(Подпис)
▼C1
( 1 ) Ненужното се зачертава.
02016R0799 — BG — 21.08.2023 — 003.002 — 615
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.002 — 616
IV. СЕРТИФИКАТ ЗА ОДОБРЕНИЕ ЗА ИНТЕЛИГЕНТНИ ТАХОГРАФИ
Държавата членка, предоставила одобрение, издава на заявителя сертификат
за одобрение съгласно образеца по-долу. Когато уведомява други държави
членки за издадени одобрения или съответно за отменянето им, държавата
членка използва копия на въпросния сертификат.
СЕРТИФИКАТ ЗА ОДОБРЕНИЕ ЗА ИНТЕЛИГЕНТНИ ТАХОГРАФИ
Наименование на компетентния орган
Уведомление относно ( 1 ):
□ одобрение на: □ отменяне на одобрението на:
□ модел уред за регистриране на данните за
движението
□ компонент на уред за регистриране на данните за
движението ( 2 )
□ карта на водач
□ карта за монтаж и настройки
□ карта на превозвач
□ контролна карта
Одобрение №:
1. Производствена марка или търговска марка
2. Наименование на модела
3. Наименование на производителя
4. Адрес на производителя
▼M1
5. Представено за одобряване на
▼C1
6. а) изпитвателна лаборатория за сертифициране за функциониране
б) изпитвателна лаборатория за сертифициране за сигурност
в) изпитвателна лаборатория за сертифициране за оперативна съвмес­
тимост
7. а) дата и номер на сертификат за функциониране
б) дата и номер на сертификат за сигурност
в) дата и номер на сертификат за оперативна съвместимост
8. Дата на одобрението
9. Дата на отменяне на одобрението
10. Модел на уред(и) за регистриране на данните за движението, с
който/които е предназначен да се използва компонентът
11. Място
12. Дата
13. Приложени пояснителни документи
14. Забележки (включително разположение на пломбите, ако е приложимо)
(Подпис)
▼C1
( 1 ) Отбележете съответните полета.
( 2 ) Посочете компонента, предмет на уведомлението.


Full & Egal Universal Law Academy