Este texto es exclusivamente un instrumento de documentación y no surte efecto jurídico. Las instituciones de la UE no 
asumen responsabilidad alguna por su contenido. Las versiones auténticas de los actos pertinentes, incluidos sus preámbulos, 
son las publicadas en el Diario Oficial de la Unión Europea, que pueden consultarse a través de EUR-Lex. Los textos oficiales 
son accesibles directamente mediante los enlaces integrados en este documento  
►B REGLAMENTO DE EJECUCIÓN (UE) 2016/799 DE LA COMISIÓN  
de 18 de marzo de 2016  
por el que se ejecuta el Reglamento (UE) n.  o 165/2014 del Parlamento Europeo y del Consejo, que 
establece los requisitos para la construcción, ensayo, instalación, funcionamiento y reparación de 
los tacógrafos y de sus componentes  
(Texto pertinente a efectos del EEE)  
(DO L 139 de 26.5.2016, p. 1)  
Modificado por:  
Diario Oficial  
n o página  fecha  
►M1 Reglamento de Ejecución (UE) 2018/502 de la Comisión de 28 de 
febrero de 2018  L 85  1  28.3.2018  
►M2 Reglamento de Ejecución (UE) 2020/158 de la Comisión de 5 de 
febrero de 2020  L 34  2 0  6.2.2020  
►M3 Reglamento de Ejecución (UE) 2021/1228 de la Comisión de 16 de  
julio de 2021  L 273  1  30.7.2021  
Rectificado por:  
►C1 Rectificación, DO L 146 de 3.6.2016, p. 31 (2016/799)  
►C2 Rectificación, DO L 27 de 1.2.2017, p. 169 (2016/799)  02016R0799 — ES — 21.08.2023 — 003.001 — 1
02016R0799 — ES — 21.08.2023 — 003.001 — 2  
REGLAMENTO DE EJECUCIÓN (UE) 2016/799 DE LA 
COMISIÓN  
de 18 de marzo de 2016  
por el que se ejecuta el Reglamento (UE) n.  o 165/2014 del 
Parlamento Europeo y del Consejo, que establece los requisitos 
para la construcción, ensayo, instalación, funcionamiento y 
reparación de los tacógrafos y de sus componentes  
(Texto pertinente a efectos del EEE)  
Articulo 1  
Objeto y ámbito de aplicación  
1. El presente Reglamento establece las disposiciones necesaria s para 
la aplicación uniforme de los siguientes aspectos en relación c on los 
tacógrafos:  
a) registro de la posición del vehículo en determinados puntos durante 
el período de trabajo diario del conductor;  
b) teledetección temprana de posibles manipulaciones o usos ind ebidos 
del tacógrafo inteligente;  
c) interfaz con los sistemas de transporte inteligentes;  
d) requisitos técnicos y administrativos para los procedimiento s de ho­
mologación de los tacógrafos, incluidos los mecanismos de 
seguridad.  
▼M1 
2. La construcción, ensayo, instalación, inspección, funcionami ento y 
reparación de los tacógrafos inteligentes y sus componentes deb erán 
cumplir los requisitos técnicos establecidos en el anexo IC del  presente 
Reglamento.  
3. Los tacógrafos distintos de los tacógrafos inteligentes segu irán 
teniendo que cumplir, en lo que se refiere a las condiciones de  cons­
trucción, ensayo, instalación, inspección, funcionamiento y rep aración, 
los requisitos establecidos en el anexo I del Reglamento (UE) 
n. o 165/2014 o en el anexo IB del Reglamento (CEE) n.  o 3821/85 
del Consejo (  1 ), según proceda.  
▼B 
4. De conformidad con el artículo 10  quinquies  de la Directiva 
96/53/CE del Parlamento Europeo y del Consejo, el dispositivo d e 
teledetección temprana transmitirá asimismo los datos sobre pes o faci­
litados por un sistema de pesaje a bordo, con miras a la pronta  detección 
de fraudes.  
▼M1 
5. El presente Reglamento se entenderá sin perjuicio de la Dire ctiva 
2014/53/UE del Parlamento Europeo y del Consejo (  2 ). 
▼B 
Articulo 2  
Definiciones  
A efectos del presente Reglamento, serán de aplicación las defi niciones 
establecidas en el artículo 2 del Reglamento (UE) n.  o 165/2014.  ▼B 
( 1 ) Reglamento (CEE) n.  o 3821/85 del Consejo, de 20 de diciembre de 1985, 
relativo al aparato de control en el sector de los transportes por carretera (DO 
L 370 de 31.12.1985, p. 8). 
( 2 ) Directiva 2014/53/UE del Parlamento Europeo y del Consejo, de  16 de abril 
de 2014, relativa a la armonización de las legislaciones de los  Estados miem­
bros sobre la comercialización de equipos radioeléctricos, y po r la que se 
deroga la Directiva 1999/5/CE (DO L 153 de 22.5.2014, p. 62).
 02016R0799 — ES — 21.08.2023 — 003.001 — 3  
Asimismo, se entenderá por:  
1) «tacógrafo digital» o «tacógrafo de primera generación»: un tacó­
grafo digital distinto de un tacógrafo inteligente;  
2) «dispositivo GNSS externo»: la instalación que contiene el r eceptor 
GNSS cuando la unidad instalada en el vehículo no sea una unida d 
única, así como otros componentes necesarios para proteger la 
comunicación de los datos de posición al resto de la unidad ins ­
talada en el vehículo;  
▼M1 
3) «expediente del fabricante»: la documentación completa, en f or­
mato electrónico o en papel, que contiene toda la información 
facilitada por el fabricante o su agente a la autoridad de homo lo­
gación a efectos de la homologación de un tacógrafo o de uno de  
sus componentes, incluidos los certificados a que se refiere el  
artículo 12, apartado 3, del Reglamento (UE) n.  o 165/2014, los 
resultados de los ensayos definidos en el anexo IC del presente  
Reglamento, así como dibujos, fotografías y demás documentos 
pertinentes;  
▼B 
4) «expediente de homologación»: el expediente del fabricante, en 
formato electrónico o en papel, acompañado de los demás docu­
mentos añadidos por la autoridad de homologación a dicho expe­
diente durante el desempeño de sus funciones, incluido, al fina lizar 
el proceso de homologación, el certificado de homologación de 
tipo CE del tacógrafo o de uno de sus componentes;  
5) «índice del expediente de homologación»: el documento que in dica 
el contenido numerado del expediente de homologación, identifi­
cando todas sus partes pertinentes; el formato de dicho documen to 
distinguirá las sucesivas etapas del proceso de homologación de  
tipo CE, incluidas las fechas de las revisiones y actualizacion es del 
expediente;  
6) «dispositivo de teledetección temprana»: el equipo de la uni dad 
instalada en el vehículo que se utiliza para llevar a cabo cont roles 
selectivos en carretera;  
▼M1 
7) «tacógrafo inteligente» o «tacógrafo de segunda generación»:  un 
tacógrafo digital que cumple lo dispuesto en los artículos 8, 9  y 10 
del Reglamento (UE) n.  o 165/2014, así como en el anexo IC del 
presente Reglamento;  
8) «componente del tacógrafo»: cualquiera de los elementos sigu ien­
tes: la unidad instalada en el vehículo, el sensor de movimient o, la 
tarjeta de tacógrafo, la hoja de registro, el dispositivo GNSS ex­
terno y el dispositivo externo de teledetección temprana;  
▼B 
9) «autoridad de homologación»: la autoridad de un Estado miemb ro 
competente para llevar a cabo la homologación del tacógrafo o d e 
sus componentes, el proceso de autorización, la expedición y, e n su 
caso, la retirada de los certificados de homologación, actuando  
como punto de contacto con las autoridades de homologación de 
los demás Estados miembros y asegurándose de que los fabricante s 
cumplen sus obligaciones relativas a la conformidad con los req ui­
sitos del presente Reglamento ;  
▼M1 
10) «unidad instalada en el vehículo»: el tacógrafo, excepto el  sensor 
de movimiento y los cables que conectan dicho sensor.  
Puede consistir en una sola unidad o en varias unidades reparti das 
por el vehículo, e incluye una unidad de procesamiento, una me­
moria de datos, una función de medición de la hora, dos disposi ­
tivos de interfaz de tarjeta inteligente para el conductor y el  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 4  
segundo conductor, una impresora, una pantalla, conectores y di s­
positivos para que el usuario introduzca datos, un receptor GNS S y 
un dispositivo de comunicación a distancia.  
La unidad instalada en el vehículo puede estar compuesta de los  
siguientes componentes sujetos a homologación:  
— la unidad instalada en el vehículo, como componente único 
(con un receptor GNSS y un dispositivo de comunicación a 
distancia incluidos),  
— el cuerpo principal de la unidad instalada en el vehículo (co n 
un dispositivo de comunicación a distancia incluido) y un dis­
positivo GNSS externo,  
— el cuerpo principal de la unidad instalada en el vehículo (co n 
un receptor GNSS incluido) y un dispositivo de comunicación a 
distancia externo,  
— el cuerpo principal de la unidad instalada en el vehículo, un  
dispositivo GNSS externo y un dispositivo de comunicación a 
distancia externo.  
Si la unidad instalada en el vehículo se compone de varias unid a­
des repartidas por el vehículo, el cuerpo principal es la unida d que 
contenga la unidad de procesamiento, la memoria de datos y la 
función de medición de la hora.  
«unidad instalada en el vehículo (VU)» se utiliza tanto para «u ni­
dad instalada en el vehículo» como para «cuerpo principal de la  
unidad instalada en el vehículo».  
▼B 
Articulo 3  
Servicios basados en la localización  
1. Los fabricantes velarán por que los tacógrafos inteligentes sean 
compatibles con los servicios de localización prestados por Gal ileo y 
por el sistema europeo de navegación por complemento geoestacio nario 
(EGNOS).  
2. Además de los sistemas a que se refiere el apartado 1, los f abri­
cantes podrán también optar por garantizar la compatibilidad co n otros 
sistemas de navegación por satélite.  
Articulo 4  
Procedimiento de homologación de los tacógrafos y de los 
componentes del tacógrafo  
1. El fabricante o su mandatario presentará la solicitud de hom olo­
gación de un tacógrafo, o de alguno de sus componentes, o grupo  de 
componentes, a las autoridades de homologación designadas por c ada 
Estado miembro. La solicitud consistirá en un expediente del fa bricante 
que contenga la información sobre cada uno de los componentes e n 
cuestión, así como, en su caso, los certificados de homologació n de 
los demás componentes necesarios para completar el tacógrafo, j unto 
con cualquier otro documento pertinente.  
2. Un Estado miembro concederá la homologación a todo tacógrafo , 
componente o grupo de componentes que se ajuste a los requisito s 
administrativos y técnicos a que se refiere el artículo 1, apar tados 2 o 
3, según proceda. En tal caso, la autoridad de homologación exp edirá al 
solicitante un certificado de homologación que deberá ajustarse  al mo­
delo establecido en el anexo II del presente Reglamento.  
3. La autoridad de homologación podrá solicitar al fabricante o  a su 
mandatario que facilite cualquier información adicional.  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 5  
4. El fabricante o su mandatario pondrá a disposición de las au tori­
dades de homologación, así como de las entidades responsables d e la 
expedición de los certificados mencionadas en el artículo 12, a partado 3, 
del Reglamento (UE) n.  o 165/2014, tantos tacógrafos o componentes del 
tacógrafo como sean necesarios para poder llevar a cabo de form a 
satisfactoria el procedimiento de homologación.  
5. Cuando el fabricante o su mandatario solicite la homologació n de 
determinados componentes o grupos de componentes de un tacógraf o, 
facilitará a las autoridades de homologación los demás componen tes, ya 
homologados, así como las demás piezas necesarias para la const rucción 
del tacógrafo completo, de manera que dichas autoridades puedan  llevar 
a cabo los ensayos necesarios.  
Articulo 5  
Modificación de las homologaciones  
1. El fabricante o su mandatario informarán sin demora a las au tori­
dades de homologación que concedieron la homologación original 
acerca de cualquier cambio que se introduzca en el  software  o el  hard­
ware  del tacógrafo o en la naturaleza de los materiales empleados e n su 
fabricación que figuran en el expediente de homologación y pres entarán 
una solicitud de modificación de la homologación.  
2. Las autoridades de homologación podrán revisar o extender un a 
homologación existente, o expedir una nueva, en función de la n atura­
leza y de las características de las modificaciones.  
Se procederá a una «revisión» cuando la autoridad de homologaci ón 
considere que las modificaciones en el  software  o  e l  hardware  del 
tacógrafo o en la naturaleza de los materiales empleados en su fabrica­
ción son de poca importancia. En estos casos, la autoridad de h omolo­
gación expedirá los documentos revisados del expediente de homo loga­
ción, indicando la naturaleza de las modificaciones efectuadas y la fecha 
de su aprobación. Bastará para satisfacer este requisito una ve rsión 
actualizada del expediente de homologación en forma consolidada , 
acompañada de una descripción pormenorizada de las modificacion es. 
Se procederá a una «extensión» cuando la autoridad de homologac ión 
considere que las modificaciones en el  software  o  e l  hardware  del 
tacógrafo o en la naturaleza de los materiales empleados en su fabrica­
ción son sustanciales. En estos casos, podrá solicitar que se l leven a 
cabo nuevos ensayos, de lo cual informará al fabricante o a su manda­
tario. Si estos ensayos resultan satisfactorios, la autoridad d e homolo­
gación expedirá un certificado de homologación revisado que con tendrá 
un número que remitirá a la extensión concedida. El certificado  de 
homologación mencionará el motivo de la extensión y la fecha de  
expedición.  
3. El índice del expediente de homologación indicará la fecha d e la 
extensión o revisión más reciente de la homologación, o la fech a de la 
consolidación más reciente de la versión actualizada de la homo loga­
ción.  
4. Será necesaria una nueva homologación cuando las modificacio nes 
solicitadas del tacógrafo homologado o de sus componentes oblig arían a 
expedir un nuevo certificado de seguridad o de interoperabilida d. ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 6  
Articulo 6  
Entrada en vigor  
El presente Reglamento entrará en vigor a los veinte días de su  publi­
cación en el  Diario Oficial de la Unión Europea . 
Será aplicable a partir del 2 de marzo de 2016.  
▼M1 
Sin embargo, el anexo IC será aplicable a partir del 15 de juni o de 
2019, a excepción del apéndice 16, que será aplicable a partir del 2 de 
marzo de 2016.  
▼B 
El presente Reglamento será obligatorio en todos sus elementos y di­
rectamente aplicable en cada Estado miembro.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 7  
ANEXO I C  
Condiciones de fabricación, ensayo, instalación y control  
INTRODUCCIÓN  
1 DEFINICIONES  
2 CARACTERÍSTICAS GENERALES Y FUNCIONES DEL APA­ 
RATO DE CONTROL  
2.1 Características generales  
2.2 Funciones  
2.3 Modos de funcionamiento  
2.4 Seguridad  
3 CONDICIONES DE FABRICACIÓN Y FUNCIONAMIENTO 
DEL APARATO DE CONTROL  
3.1 Control de la inserción y extracción de las tarjetas  
3.2 Medición de la velocidad, la posición y la distancia  
3.2.1 Medición de la distancia recorrida  
3.2.2 Medición de la velocidad  
3.2.3 Medición de la posición  
3.3 Medición de la hora  
3.4 Supervisión de las actividades del conductor  
3.5 Supervisión del régimen de conducción  
3.6 Entradas de los conductores  
3.6.1 Introducción de los lugares donde comienzan o terminan lo s perío­ 
dos de trabajo diarios  
3.6.2 Introducción manual de las actividades del conductor y de l con­ 
sentimiento del conductor a la interfaz ITS  
3.6.3 Entrada de condiciones específicas  
▼M3 
3.6.4 Entrada de la operación de carga/descarga  
▼B 
3.7 Gestión de los bloqueos introducidos por la empresa  
3.8 Supervisión de las actividades de control  
3.9 Detección de incidentes o fallos  
3.9.1 Incidente «Inserción de una tarjeta no válida»  
3.9.2 Incidente «Conflicto de tarjetas»  
3.9.3 Incidente «Solapamiento temporal»  
3.9.4 Incidente «Conducción sin tarjeta adecuada»  
3.9.5 Incidente «Inserción de tarjeta durante la conducción»  
3.9.6 Incidente «Error al cerrar la última sesión de la tarjeta » 
3.9.7 Incidente «Exceso de velocidad»  
3.9.8 Incidente «Interrupción del suministro eléctrico»  
3.9.9 Incidente «Error de comunicación con el dispositivo de co munica­ 
ción a distancia»  
3.9.10 Incidente «Ausencia de información sobre la posición pro cedente 
del receptor GNSS»  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 8  
3.9.11 Incidente «Error de comunicación con el dispositivo GNSS  ex­ 
terno»  
3.9.12 Incidente «Error de datos de movimiento»  
3.9.13 Incidente «Conflicto de movimiento del vehículo»  
3.9.14 Incidente «Intento de violación de la seguridad»  
3.9.15 Incidente «Conflicto temporal»  
3.9.16 Fallo «Tarjeta»  
3.9.17 Fallo «Aparato de control»  
▼M3 
3.9.18 Incidente «Anomalía del GNSS»  
▼B 
3.10 Autodiagnóstico y comprobaciones automáticas  
3.11 Lectura de datos de la memoria  
3.12 Registro y almacenamiento de datos en la memoria  
3.12.1 Datos de identificación de los equipos  
3.12.1.1 Datos de identificación de la unidad instalada en el v ehículo  
3.12.1.2 Datos de identificación del sensor de movimiento  
3.12.1.3 Datos de identificación de los sistemas mundiales de n avegación 
por satélite  
3.12.2 Claves y certificados  
3.12.3 Datos de inserción y extracción de la tarjeta de conduct or o de la 
tarjeta de taller  
3.12.4 Datos sobre la actividad del conductor  
▼M1 
3.12.5 Lugares y posiciones donde comienzan o terminan los perí odos de 
trabajo diarios y/o donde se alcanzan las tres horas de tiempo de 
conducción acumulado  
▼B 
3.12.6 Datos del cuentakilómetros  
3.12.7 Datos pormenorizados sobre la velocidad  
3.12.8 Datos sobre incidentes  
3.12.9 Datos sobre fallos  
3.12.10 Datos de calibrado  
3.12.11 Datos de ajuste de la hora  
3.12.12 Datos sobre actividades de control  
3.12.13 Datos sobre los bloqueos introducidos por las empresas  
3.12.14 Datos sobre actividades de transferencia  
3.12.15 Datos sobre condiciones específicas  
3.12.16 Datos de la tarjeta de tacógrafo  
▼M3 
3.12.17 Cruces de fronteras  
3.12.18 Operaciones de carga/descarga  
3.12.19 Mapa digital  
▼B 
3.13 Lectura de las tarjetas de tacógrafo  
3.14 Registro y almacenamiento de datos en las tarjetas de tacó grafo  
3.14.1 Registro y almacenamiento de datos en las tarjetas de ta cógrafo de 
primera generación  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 9  
3.14.2 Registro y almacenamiento de datos en las tarjetas de ta cógrafo de 
segunda generación  
3.15 Visualización  
3.15.1 Contenido de la pantalla por defecto  
3.15.2 Visualización de advertencias  
3.15.3 Acceso mediante menús  
3.15.4 Otras informaciones en pantalla  
3.16 Impresión  
3.17 Advertencias  
3.18 Transferencia de datos a medios externos  
3.19 Comunicación a distancia para controles de carretera selec tivos 
▼M3 
3.20 Intercambios de datos con dispositivos externos adicionale s 
▼B 
3.21 Calibrado  
3.22 Control del calibrado en carretera  
3.23 Ajuste de la hora  
3.24 Características de funcionamiento  
3.25 Materiales  
3.26 Marcas  
▼M3 
3.27 Seguimiento de los cruces de fronteras  
3.28 Actualización del  software  
▼B 
4 CONDICIONES DE FABRICACIÓN Y FUNCIONAMIENTO DE 
LAS TARJETAS DE TACÓGRAFO  
4.1 Datos visibles  
4.2 Seguridad  
4.3 Normas  
4.4 Especificaciones ambientales y eléctricas  
4.5 Almacenamiento de datos  
4.5.1 Archivos elementales para la identificación y la gestión de la tarjeta  
4.5.2 Identificación de la tarjeta CI  
4.5.2.1 Identificación del chip  
4.5.2.2 DIR (presente solo en las tarjetas de tacógrafo de segu nda genera­ 
ción).  
4.5.2.3 Información ATR (condicionalmente, presente solo en las  tarjetas 
de tacógrafo de segunda generación).  
4.5.2.4 Información de longitud extendida (condicionalmente, pr esente solo 
en las tarjetas de tacógrafo de segunda generación).  
4.5.3 Tarjeta de conductor  
4.5.3.1 Aplicación del tacógrafo (accesible a las unidades inst aladas en 
vehículos de primera y segunda generación)  
4.5.3.1.1 Identificación de la aplicación  
4.5.3.1.2 Clave y certificados  
4.5.3.1.3 Identificación de la tarjeta  
4.5.3.1.4 Identificación del titular de la tarjeta  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 10  
4.5.3.1.5 Transferencia de los datos de la tarjeta  
4.5.3.1.6 Información sobre el permiso de conducir  
4.5.3.1.7 Datos sobre incidentes  
4.5.3.1.8 Datos sobre fallos  
4.5.3.1.9 Datos sobre la actividad del conductor  
4.5.3.1.10 Datos sobre vehículos empleados  
4.5.3.1.11 Lugares donde comienzan o terminan los períodos de t rabajo dia­ 
rios 
4.5.3.1.12 Datos de la sesión  
4.5.3.1.13 Datos sobre actividades de control  
4.5.3.1.14 Datos sobre condiciones específicas  
4.5.3.2 Aplicación de tacógrafo de segunda generación (no acces ible a la 
unidad instalada en el vehículo de primera generación)  
4.5.3.2.1 Identificación de la aplicación  
▼M3 
4.5.3.2.1.1 Identificación de la aplicación adicional (no acces ible para la ver­ 
sión 1 de las unidades instaladas en el vehículo de segunda gen e­ 
ración)  
▼B 
4.5.3.2.2 Claves y certificados  
4.5.3.2.3 Identificación de la tarjeta  
4.5.3.2.4 Identificación del titular de la tarjeta  
4.5.3.2.5 Transferencia de los datos de la tarjeta  
4.5.3.2.6 Información sobre el permiso de conducir  
4.5.3.2.7 Datos sobre incidentes  
4.5.3.2.8 Datos sobre fallos  
4.5.3.2.9 Datos sobre la actividad del conductor  
4.5.3.2.10 Datos sobre vehículos empleados  
4.5.3.2.11 Lugares y posiciones donde comienzan o terminan los períodos de 
trabajo diarios  
4.5.3.2.12 Datos de la sesión  
4.5.3.2.13 Datos sobre actividades de control  
4.5.3.2.14 Datos sobre condiciones específicas  
4.5.3.2.15 Datos utilizados en unidades instaladas en vehículos  
▼M1 
4.5.3.2.16 Datos sobre lugares en tres horas de conducción acum uladas  
▼M3 
4.5.3.2.17 Estado de autenticación para posiciones relacionadas  con lugares en 
los que comienzan o terminan los períodos de trabajo diarios (n o 
accesible para la versión 1 de las unidades instaladas en el ve hículo 
de segunda generación)  
4.5.3.2.18 Estado de autenticación para posiciones en las que s e alcanza el 
tiempo de conducción acumulado de tres horas (no accesible para  
la versión 1 de las unidades instaladas en el vehículo de segun da 
generación)  
4.5.3.2.19 Cruces de fronteras (no accesible para la versión 1 de las unidades 
instaladas en el vehículo de segunda generación);  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 11  
4.5.3.2.20 Operaciones de carga/descarga (no accesible para la versión 1 de 
las unidades instaladas en el vehículo de segunda generación);  
4.5.3.2.21 Entradas de tipo de carga (no accesible para la vers ión 1 de las 
unidades instaladas en el vehículo de segunda generación);  
4.5.3.2.22 Configuraciones de la VU (no accesible para la versi ón 1 de las 
unidades instaladas en el vehículo de segunda generación)  
▼B 
4.5.4 Tarjeta de taller  
4.5.4.1 Aplicación del tacógrafo (accesible a las unidades inst aladas en 
vehículos de primera y segunda generación)  
4.5.4.1.1 Identificación de la aplicación  
4.5.4.1.2 Claves y certificados  
4.5.4.1.3 Identificación de la tarjeta  
4.5.4.1.4 Identificación del titular de la tarjeta  
4.5.4.1.5 Transferencia de los datos de la tarjeta  
4.5.4.1.6 Datos de calibrado y de ajuste de la hora  
4.5.4.1.7 Datos de incidentes y fallos  
4.5.4.1.8 Datos sobre la actividad del conductor  
4.5.4.1.9 Datos sobre vehículos empleados  
4.5.4.1.10 Datos sobre el comienzo y el final de los períodos d e trabajo 
diarios  
4.5.4.1.11 Datos de la sesión  
4.5.4.1.12 Datos sobre actividades de control  
4.5.4.1.13 Datos sobre condiciones específicas  
4.5.4.2 Aplicación de tacógrafo de segunda generación (no acces ible a la 
unidad instalada en el vehículo de primera generación)  
4.5.4.2.1 Identificación de la aplicación  
▼M3 
4.5.4.2.1.1 Identificación de la aplicación adicional (no acces ible para la ver­ 
sión 1 de las unidades instaladas en el vehículo de segunda gen e­ 
ración)  
▼B 
4.5.4.2.2 Claves y certificados  
4.5.4.2.3 Identificación de la tarjeta  
4.5.4.2.4 Identificación del titular de la tarjeta  
4.5.4.2.5 Transferencia de los datos de la tarjeta  
4.5.4.2.6 Datos de calibrado y de ajuste de la hora  
4.5.4.2.7 Datos de incidentes y fallos  
4.5.4.2.8 Datos sobre la actividad del conductor  
4.5.4.2.9 Datos sobre vehículos empleados  
4.5.4.2.10 Datos sobre el comienzo y el final de los períodos d e trabajo 
diarios  
4.5.4.2.11 Datos de la sesión  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 12  
4.5.4.2.12 Datos sobre actividades de control  
4.5.4.2.13 Datos utilizados en unidades instaladas en vehículos  
▼M1 
4.5.4.2.14 Datos sobre lugares en tres horas de conducción acum uladas  
▼B 
4.5.4.2.15 Datos sobre condiciones específicas  
▼M3 
4.5.4.2.16 Estado de autenticación para posiciones relacionadas  con lugares en 
los que comienzan o terminan los períodos de trabajo diarios (n o 
accesible para la versión 1 de las unidades instaladas en el ve hículo 
de segunda generación)  
4.5.4.2.17 Estado de autenticación para posiciones en las que s e alcanza el 
tiempo de conducción acumulado de tres horas (no accesible para  
la versión 1 de las unidades instaladas en el vehículo de segun da 
generación)  
4.5.4.2.18 Cruces de fronteras (no accesible para la versión 1 de las unidades 
instaladas en el vehículo de segunda generación);  
4.5.4.2.19 Operaciones de carga/descarga (no accesible para la versión 1 de 
las unidades instaladas en el vehículo de segunda generación);  
4.5.4.2.20 Entradas de tipo de carga (no accesible para la vers ión 1 de las 
unidades instaladas en el vehículo de segunda generación);  
4.5.4.2.21 Datos adicionales de calibrado (no accesible para la  versión 1 de 
las unidades instaladas en el vehículo de segunda generación);  
4.5.4.2.22 Configuraciones de la VU (no accesible para la versi ón 1 de las 
unidades instaladas en el vehículo de segunda generación)  
▼B 
4.5.5 Tarjeta de control  
4.5.5.1 Aplicación del tacógrafo (accesible a las unidades inst aladas en 
vehículos de primera y segunda generación)  
4.5.5.1.1 Identificación de la aplicación  
4.5.5.1.2 Claves y certificados  
4.5.5.1.3 Identificación de la tarjeta  
4.5.5.1.4 Identificación del titular de la tarjeta  
4.5.5.1.5 Datos sobre actividades de control  
4.5.5.2 Aplicación de tacógrafo G2 (no accesible para la unidad  instalada 
en el vehículo de primera generación)  
4.5.5.2.1 Identificación de la aplicación  
▼M3 
4.5.5.2.1.1 Identificación de la aplicación adicional (no acces ible para la ver­ 
sión 1 de las unidades instaladas en el vehículo de segunda gen e­ 
ración)  
▼B 
4.5.5.2.2 Claves y certificados  
4.5.5.2.3 Identificación de la tarjeta  
4.5.5.2.4 Identificación del titular de la tarjeta  
4.5.5.2.5 Datos sobre actividades de control  
▼M3 
4.5.5.2.6 Configuraciones de la VU (no accesible para la versió n 1 de las 
unidades instaladas en el vehículo de segunda generación)  
▼B 
4.5.6 Tarjeta de empresa  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 13  
4.5.6.1 Aplicación del tacógrafo (accesible a las unidades inst aladas en 
vehículos de primera y segunda generación)  
4.5.6.1.1 Identificación de la aplicación  
4.5.6.1.2 Claves y certificados  
4.5.6.1.3 Identificación de la tarjeta  
4.5.6.1.4 Identificación del titular de la tarjeta  
4.5.6.1.5 Datos sobre la actividad de la empresa  
4.5.6.2 Aplicación de tacógrafo G2 (no accesible para la unidad  instalada 
en el vehículo de primera generación)  
4.5.6.2.1 Identificación de la aplicación  
▼M3 
4.5.6.2.1.1 Identificación de la aplicación adicional (no acces ible para la ver­ 
sión 1 de las unidades instaladas en el vehículo de segunda gen e­ 
ración)  
▼B 
4.5.6.2.2 Claves y certificados  
4.5.6.2.3 Identificación de la tarjeta  
4.5.6.2.4 Identificación del titular de la tarjeta  
4.5.6.2.5 Datos sobre la actividad de la empresa  
▼M3 
4.5.6.2.6 Configuraciones de la VU (no accesible para la versió n 1 de las 
unidades instaladas en el vehículo de segunda generación)  
▼B 
5 INSTALACIÓN DEL APARATO DE CONTROL  
5.1 Instalación  
5.2 Placa de instalación  
5.3 Precintos  
6 VERIFICACIONES, CONTROLES Y REPARACIONES  
6.1 Autorización de instaladores, talleres y fabricantes de veh ículos  
▼M1 
6.2 Verificación de componentes nuevos o reparados  
▼B 
6.3 Control de la instalación  
6.4 Controles periódicos  
6.5 Determinación de errores  
6.6 Reparaciones  
7 EXPEDICIÓN DE TARJETAS  
8 HOMOLOGACIÓN DEL APARATO DE CONTROL Y DE LAS 
TARJETAS DE TACÓGRAFO  
8.1 Generalidades  
8.2 Certificado de seguridad  
8.3 Certificado funcional  
8.4 Certificado de interoperabilidad  
8.5 Certificado de homologación  
8.6 Procedimiento de excepción: primeros certificados de intero perabi­ 
lidad para los aparatos de control y las tarjetas de tacógrafo de 
segunda generación  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 14  
INTRODUCCIÓN  
El presente anexo contiene las condiciones relativas a la segun da generación de 
aparatos de control y tarjetas de tacógrafo.  
Desde el 15 de junio de 2019 se están instalando aparatos de co ntrol de segunda 
generación en los vehículos que se matriculan en la Unión por p rimera vez, y se 
están expidiendo tarjetas de tacógrafo de segunda generación.  
Con el fin de implantar sin problemas el sistema de tacógrafo d e segunda gene­
ración, se han diseñado tarjetas de tacógrafo de segunda genera ción que pueden 
ser utilizadas también en unidades instaladas en el vehículo de  primera genera­
ción fabricadas de conformidad con el anexo I B del Reglamento (CEE) 
n. o 3821/85.  
Recíprocamente, las tarjetas de tacógrafo de primera generación  pueden ser uti­
lizadas en unidades instaladas en el vehículo de segunda genera ción. 
No obstante, las unidades instaladas en el vehículo de segunda generación solo 
podrán ser calibradas utilizando tarjetas de taller de segunda generación.  
Los requisitos relativos a la interoperabilidad entre los siste mas de tacógrafo de 
primera y segunda generación se especifican en el presente anex o. A este res­
pecto, el apéndice 15 contiene información adicional sobre la g estión de la 
coexistencia de ambas generaciones.  
Además, debido a la implementación de nuevas funciones, como el  uso de la 
autenticación de mensajes de navegación de señales abiertas de Galileo, la de­
tección de los cruces de fronteras y la entrada de operaciones de carga y des­
carga, y debido también a la necesidad de aumentar la capacidad  de las tarjetas 
de conductor a cincuenta y seis días de actividades del conduct or, el presente 
Reglamento introduce los requisitos técnicos para la segunda ve rsión de los 
aparatos de control y las tarjetas de tacógrafo de segunda gene ración.  
▼B 
Lista de apéndices  
Apéndice 1: DICCIONARIO DE DATOS  
Apéndice 2: ESPECIFICACIONES DE LAS TARJETAS DE TACÓGRAFO  
Apéndice 3: PICTOGRAMAS  
Apéndice 4: DOCUMENTOS IMPRESOS  
Apéndice 5: VISUALIZACIÓN  
Apéndice 6: CONECTOR FRONTAL PARA EL CALIBRADO Y LA 
TRANSFERENCIA DE DATOS  
Apéndice 7: PROTOCOLOS DE TRANSFERENCIA DE DATOS  
Apéndice 8: PROTOCOLO DE CALIBRADO  
Apéndice 9: HOMOLOGACIÓN Y LISTA DE PRUEBAS MÍNIMAS RE­ 
QUERIDAS  
Apéndice 10: REQUISITOS DE SEGURIDAD  
Apéndice 11: MECANISMOS COMUNES DE SEGURIDAD  
Apéndice 12: POSICIONAMIENTO BASADO EN EL SISTEMA MUN­ 
DIAL DE NAVEGACIÓN POR SATÉLITE (GNSS)  
Apéndice 13: INTERFAZ ITS  
Apéndice 14: FUNCIÓN DE COMUNICACIÓN A DISTANCIA  
Apéndice 15: MIGRACIÓN: GESTIÓN DE LA COEXISTENCIA DE LAS 
GENERACIONES DE EQUIPOS  
Apéndice 16: ADAPTADOR PARA VEHÍCULOS DE LAS CATEGORÍAS 
M 1 Y N1  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 15  
1 DEFINICIONES  
A los efectos del presente anexo, se aplicarán las siguientes d efini­
ciones:  
a) Activación:  
Fase en que el tacógrafo pasa a ser totalmente operativo y 
realiza todas sus funciones, incluidas las de seguridad, me­
diante el uso de una tarjeta de taller.  
b) Autenticación:  
Función con la que se establece y verifica una identidad.  
c) Autenticidad:  
Propiedad de que una información proceda de alguien cuya 
identidad pueda verificarse.  
d) Autodiagnóstico (BIT):  
Ensayo que se lleva a cabo a petición del operario o por orden 
de un equipo externo.  
e) Día civil:  
Día comprendido entre las 00.00 y las 24.00 horas. Todos los 
días se referirán al tiempo universal coordinado (UTC).  
▼M3 
f) Calibrado de un tacógrafo digital inteligente:  
Actualización o confirmación de los parámetros del vehículo 
que han de guardarse en la memoria de datos. Los parámetros 
del vehículo incluyen la identificación del vehículo (VIN, 
VRN y el Estado miembro donde se matriculó el vehículo) 
y las características del vehículo (w, k, l, tamaño de los neu­
máticos, valor de ajuste del dispositivo limitador de la veloci ­
dad, en su caso, hora UTC actual, lectura actual del cuentaki­
lómetros, tipo de carga por defecto); durante el calibrado de u n 
aparato de control, los tipos y los identificadores de todos lo s 
precintos pertinentes de la homologación también se almace­
narán en la memoria de datos.  
Toda actualización o confirmación únicamente de la hora UTC 
se considerará un ajuste de la hora y no un calibrado, siempre 
que no contravenga el requisito 409 del punto 6.4.  
Para calibrar un aparato de control se precisa una tarjeta de 
taller.  
g) Número de tarjeta:  
Secuencia de dieciséis caracteres alfanuméricos que identifica 
de manera única una tarjeta de tacógrafo en un Estado miem­
bro. El número de tarjeta incluye una identificación, que con­
siste en la identificación del conductor, o en la identificació n 
del titular de la tarjeta junto con un índice consecutivo de la  
tarjeta, un índice de sustitución de la tarjeta y un índice de 
renovación de la tarjeta;  
por consiguiente, cada tarjeta se identifica de manera única 
con el código del Estado miembro que la expide y con el 
número de la propia tarjeta.  
▼B 
h) Índice consecutivo de la tarjeta:  
Decimocuarto carácter alfanumérico del número de la tarjeta. 
Este carácter sirve para diferenciar las distintas tarjetas asi gna­
das a una empresa, a un taller o a una autoridad de control con  
derecho a utilizar varias tarjetas de tacógrafo. La empresa, el  
taller o la autoridad de control se identifican con los trece 
primeros caracteres del número de la tarjeta.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 16  
i) Índice de renovación de la tarjeta:  
Decimosexto carácter alfanumérico de un número de tarjeta, 
que se incrementa cada vez que se renueva una tarjeta de 
tacógrafo correspondiente a una determinada identificación, 
es decir, identificación del conductor o del titular junto con 
el índice consecutivo;  
j) Índice de sustitución de la tarjeta:  
Decimoquinto carácter alfanumérico de un número de tarjeta, 
que se incrementa cada vez que se sustituye una tarjeta de 
tacógrafo correspondiente a una determinada identificación, 
es decir, identificación del conductor o del titular junto con 
el índice consecutivo.  
▼B 
k) Coeficiente característico del vehículo:  
Característica numérica que da el valor de la señal de salida 
emitida por la pieza prevista en el vehículo para su conexión 
con el aparato de control (toma de salida de la caja de cambio 
en algunos casos, rueda del vehículo en otros casos), cuando el  
vehículo recorre la distancia de un kilómetro, medida en con­
diciones normales de ensayo, según se definen en el requisito 
414. El coeficiente característico se expresa en impulsos por 
kilómetro (w = … imp/km).  
l) Tarjeta de empresa:  
Tarjeta de tacógrafo expedida por las autoridades de un Estado 
miembro a favor de una empresa de transporte que necesita 
utilizar vehículos equipados de tacógrafo, que identifica a di­
cha empresa de transporte y permite visualizar, transferir e 
imprimir los datos almacenados en los tacógrafos y bloqueados 
por tal empresa.  
m) Constante del aparato de control:  
Característica numérica que da el valor de la señal de entrada 
necesaria para obtener la indicación y el registro de una dis­
tancia recorrida de un kilómetro; dicha constante deberá ex­
presarse en impulsos por kilómetro (k = … imp/km).  
n) Tiempo de conducción continua (contabilizado por el aparato 
de control) (  1 ): 
El tiempo de conducción continua se calcula a partir de los 
tiempos de conducción acumulados actuales de un conductor 
en particular, contados desde el momento en que termina su 
último período de DISPONIBILIDAD o PAUSA/DESCANSO 
o INDETERMINADO (  2 ) de 45 minutos o más [este período 
puede haberse dividido con arreglo al Reglamento (CE) 
n. o 561/2006 del Parlamento Europeo y del Consejo (  3 )]. Los 
cálculos tienen en cuenta, según proceda, las actividades an­
teriores que han quedado registradas en la tarjeta de conductor . 
Si el conductor no ha insertado su tarjeta, los cálculos se bas an 
en los registros de la memoria de datos correspondientes al 
período actual en que no hubo tarjeta insertada y a la ranura 
que corresponda.  ▼M3 
( 1 ) Este modo de calcular el tiempo de conducción continua y el t iempo de descanso 
acumulado permite al aparato de control calcular el momento de activación del aviso 
de tiempo de conducción continua y no prejuzga la interpretació n legal que deba hacerse 
de estos tiempos. Podrán utilizarse métodos alternativos para c alcular el tiempo de 
conducción continua y el tiempo de descanso acumulado a fin de reemplazar estas 
definiciones si quedan obsoletas a raíz de las actualizaciones introducidas en otra legis­
lación pertinente. 
( 2 ) Los períodos INDETERMINADOS son aquellos en que la tarjeta de  conductor no está 
insertada en el aparato de control y tampoco se introducen manu almente las actividades 
del conductor. 
( 3 ) Reglamento (CE) n.  o 561/2006 del Parlamento Europeo y del Consejo, de 15 de marzo 
de 2006, relativo a la armonización de determinadas disposicion es en materia social en el 
sector de los transportes por carretera y por el que se modific an los Reglamentos (CEE) 
n. o 3821/85 y (CE) n.  o 2135/98 del Consejo y se deroga el Reglamento (CEE) 
n. o 3820/85 del Consejo (DO L 102 de 11.4.2006, p. 1).
 02016R0799 — ES — 21.08.2023 — 003.001 — 17  
o) Tarjeta de control:  
Tarjeta de tacógrafo expedida por las autoridades de un Estado 
miembro a una autoridad nacional de control competente, que 
identifica a este organismo y, de manera opcional, también al 
controlador, y que permite acceder a la información almace­
nada en la memoria de datos o en las tarjetas de conductor y, 
de manera opcional, en las tarjetas de taller con fines de lec­
tura, impresión y/o transferencia de datos.  
Asimismo, dará acceso a la función de control de calibrado en 
la carretera y a los datos contenidos en el lector de comuni­
caciones de teledetección temprana.  
p) Tiempo de descanso acumulado (contabilizado por el aparato 
de control) (  1 ): 
El tiempo de descanso de la conducción acumulado, referido a un  
conductor en particular, se calcula a partir de los períodos ac u­
mulados actuales de DISPONIBILIDAD, PAUSA/DESCANSO o 
INDETERMINADOS (  2 ) de 15 minutos o más, contados desde el 
momento en que terminara su último período de DISPONIBILI­
DAD o PAUSA/DESCANSO o INDETERMINADO (  2 ) de 45 
minutos o más [este período puede haberse dividido con arreglo 
al Reglamento (CE) n.  o 561/2006].  
Los cálculos tienen en cuenta, según proceda, las actividades 
anteriores que han quedado registradas en la tarjeta de con­
ductor. Los cálculos no incluyen los períodos indeterminados 
que tengan una duración negativa (comienzo del período in­
determinado > final del período indeterminado) a consecuencia 
de un solapamiento temporal entre dos aparatos de control 
distintos.  
Si el conductor no ha insertado su tarjeta, los cálculos se bas an 
en los registros de la memoria de datos correspondientes al 
período actual en que no hubo tarjeta insertada y a la ranura 
que corresponda.  
q) Memoria de datos:  
Dispositivo de almacenamiento electrónico incorporado en el 
aparato de control.  
r) Firma digital:  
Datos adjuntos a un bloque de datos, o una transformación 
criptográfica de ellos, que permiten al destinatario comprobar 
la autenticidad e integridad de dicho bloque.  
s) Transferencia:  
Copia, junto con la firma digital, de una parte o de la totalid ad 
de un conjunto de ficheros de datos almacenados en la me­
moria de datos de la unidad instalada en el vehículo o en la 
memoria de una tarjeta de tacógrafo, siempre que este proceso 
no altere ni suprima ninguno de los datos almacenados.  ▼B 
( 1 ) Este modo de calcular el tiempo de conducción continua y el t iempo de descanso 
acumulado permite al aparato de control calcular el momento de activación del aviso 
de tiempo de conducción continua y no prejuzga la interpretació n legal que deba hacerse 
de estos tiempos. Podrán utilizarse métodos alternativos para c alcular el tiempo de 
conducción continua y el tiempo de descanso acumulado a fin de reemplazar estas 
definiciones si quedan obsoletas a raíz de las actualizaciones introducidas en otra legis­
lación pertinente. 
( 2 ) Los períodos INDETERMINADOS son aquellos en que la tarjeta de  conductor no está 
insertada en el aparato de control y tampoco se introducen manu almente las actividades 
del conductor.
 02016R0799 — ES — 21.08.2023 — 003.001 — 18  
Los fabricantes de tacógrafos inteligentes instalados en el ve­
hículo y los fabricantes de aparatos diseñados y concebidos 
para transferir ficheros de datos adoptarán todas las medidas 
necesarias para garantizar que los conductores o las empresas 
de transporte puedan transferir dichos datos en el menor 
tiempo posible.  
La transferencia del fichero completo de datos sobre la velo­
cidad del vehículo puede no ser necesaria para determinar el 
cumplimiento del Reglamento (CE) n.  o 561/2006, aunque sí 
podrá utilizarse para otros fines, tales como la investigación de 
accidentes.  
t) Tarjeta de conductor:  
Tarjeta de tacógrafo expedida por las autoridades de un Estado 
miembro a un conductor concreto, que identifica a este último 
y permite almacenar los datos de su actividad.  
u) Circunferencia efectiva de las ruedas:  
Media de las distancias recorridas por cada una de las ruedas 
que arrastran el vehículo (ruedas motrices) al realizar una ro­
tación completa. La medida de dichas distancias se efectuará 
en condiciones normales de ensayo, según se define en el 
requisito 414, y se expresará en la forma «l = … mm». Los 
fabricantes de los vehículos podrán sustituir la medición de 
estas distancias por un cálculo teórico que tenga en cuenta 
el reparto del peso sobre los ejes, con el vehículo descargado 
y en condiciones normales de marcha (  1 ). Los métodos de 
dicho cálculo teórico deberán ser aprobados por la autoridad 
competente del Estado miembro y solo podrán tener lugar 
antes de la activación del tacógrafo.  
v) Incidente:  
Operación anormal detectada por el tacógrafo inteligente que 
puede deberse a un intento de fraude.  
w) Dispositivo GNSS externo:  
Instalación que contiene el receptor GNSS cuando la unidad 
instalada en el vehículo no es un módulo único, así como otros 
componentes necesarios para proteger la comunicación de los 
datos de posición al resto de la unidad instalada en el vehícul o. 
x) Fallo:  
Operación anormal detectada por el tacógrafo inteligente y que 
puede deberse a un fallo de funcionamiento.  
y) Receptor GNSS:  
Dispositivo electrónico que recibe y procesa digitalmente las 
señales digitales de uno o más sistemas mundiales de navega­
ción por satélite (GNSS por sus siglas en inglés) con el fin de  
proporcionar información de posición, velocidad y hora.  ▼B 
( 1 ) Reglamento (UE) n.  o 1230/2012 de la Comisión, de 12 de diciembre de 2012, por el qu e 
se desarrolla el Reglamento (CE) n.  o 661/2009 del Parlamento Europeo y del Consejo en 
lo que respecta a los requisitos de homologación de tipo relati vos a las masas y dimen­
siones de los vehículos de motor y de sus remolques y por el qu e se modifica la 
Directiva 2007/46/CE del Parlamento Europeo y del Consejo (DO L  353 de 21.12.2012, 
p. 31), en su versión modificada en último lugar.
 02016R0799 — ES — 21.08.2023 — 003.001 — 19  
z) Instalación:  
Montaje de un tacógrafo en un vehículo.  
aa) Interoperabilidad:  
Capacidad de los sistemas y de los procesos subyacentes para 
intercambiar datos y compartir información.  
bb) Interfaz:  
Dispositivo entre sistemas que facilita los medios de comuni­
cación a través de los cuales pueden conectarse y actuar entre 
sí. 
cc) Posición:  
Coordenadas geográficas del vehículo en un momento dado.  
dd) Sensor de movimiento:  
Parte del tacógrafo que ofrece una señal representativa de la 
velocidad del vehículo y/o de la distancia recorrida.  
▼M3 
ee) Tarjeta no válida:  
Tarjeta en la que se ha detectado un defecto, que no ha supe­
rado la autenticación, que no ha alcanzado todavía la fecha de 
comienzo de validez o que ha sobrepasado ya la fecha de 
expiración.  
La unidad instalada en el vehículo también considera no válida 
una tarjeta:  
— si ya se ha insertado en la unidad instalada en el vehículo 
una tarjeta con el mismo Estado miembro emisor de la 
tarjeta, la misma identificación, es decir, la identificación 
del conductor o del titular junto con el índice consecutivo, 
y un índice de renovación más elevado, o  
— si ya se ha insertado en la unidad instalada en el vehículo 
una tarjeta con el mismo Estado miembro emisor de la 
tarjeta, la misma identificación, es decir, la identificación 
del conductor o del titular junto con el índice consecutivo 
y el índice de renovación, pero con un índice de sustitu­
ción más elevado.  
▼B 
ff) Norma abierta:  
Norma que figura en un documento de especificación de nor­
mas que está disponible sin contrapartida financiera o por una 
contrapartida simbólica, que cualquier persona puede copiar, 
distribuir o utilizar gratuitamente o por un precio simbólico.  
gg) Fuera de ámbito:  
Cuando el uso del aparato de control no es obligatorio, de 
conformidad con lo dispuesto en el Reglamento (CE) 
n. o 561/2006.  
hh) Exceso de velocidad:  
Rebasamiento de la velocidad autorizada para el vehículo, 
definido como un período de más de sesenta segundos durante 
el cual la velocidad medida del vehículo sobrepasa el valor de 
ajuste del dispositivo limitador de la velocidad, regulado con 
arreglo a la Directiva 92/6/CEE del Consejo (  1 ), en su versión 
modificada en último lugar.  ▼B 
( 1 ) Directiva 92/6/CEE del Consejo, de 10 de febrero de 1992, rel ativa a la instalación y a la 
utilización de dispositivos de limitación de velocidad en deter minadas categorías de 
vehículos de motor en la Comunidad (DO L 57 de 2.3.1992, p. 27) .
 02016R0799 — ES — 21.08.2023 — 003.001 — 20  
ii) Control periódico:  
Conjunto de operaciones con las que se comprueba que el 
tacógrafo funciona correctamente, que sus valores de ajuste 
corresponden a los parámetros del vehículo y que no hay 
dispositivos de manipulación integrados en el tacógrafo.  
jj) Impresora:  
Componente del aparato de control que permite imprimir los 
datos almacenados.  
kk) Comunicación de teledetección temprana:  
Comunicación entre el dispositivo de comunicación de telede­
tección temprana y el lector de comunicación de teledetección 
temprana durante los controles de carretera selectivos encami­
nados a detectar una posible manipulación o utilización inde­
bida del aparato de control.  
▼M3 
ll) Dispositivo de comunicación a distancia, módulo de comuni­
cación a distancia o dispositivo de teledetección temprana:  
Equipo de la unidad instalada en el vehículo que se utiliza 
para realizar controles de carretera selectivos.  
▼B 
mm) Lector de comunicación de teledetección temprana:  
El sistema utilizado por los controladores para los controles d e 
carretera selectivos.  
▼M3 
nn) Renovación de la tarjeta:  
Emisión de una nueva tarjeta de tacógrafo cuando la tarjeta 
existente alcanza su fecha de expiración o se ha devuelto a la 
autoridad emisora por un fallo de funcionamiento.  
▼B 
oo) Reparación:  
Cualquier reparación de un sensor de movimiento o de una 
unidad instalada en el vehículo o de un cable que requiera la 
desconexión de su fuente de alimentación, o su desconexión 
de otros componentes del tacógrafo, o la apertura del sensor de  
movimiento o de la unidad instalada en el vehículo.  
▼M3 
pp) Sustitución de la tarjeta:  
Emisión de una nueva tarjeta de tacógrafo en sustitución de 
una tarjeta existente que se haya declarado perdida, robada o 
defectuosa y que no se haya devuelto a la autoridad 
expedidora.  
▼B 
qq) Certificación de seguridad:  
Procedimiento por el que un organismo de certificación de 
Criterios Comunes garantiza que el aparato de control (o com­
ponente) o la tarjeta de tacógrafo que se investiga cumple los 
requisitos de seguridad definidos en los correspondientes per­
files de protección.  
rr) Comprobación automática:  
Comprobaciones que realiza de manera cíclica y automática el 
aparato de control para detectar posibles fallos.  
ss) Medición de la hora:  
Registro digital permanente de la fecha y la hora del tiempo 
universal coordinado (UTC).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 21  
tt) Ajuste de la hora:  
Ajuste de la hora actual; este ajuste puede realizarse de maner a 
automática, utilizando como referencia la hora que proporciona 
el receptor GNSS, o efectuarse en el modo calibrado.  
▼B 
uu) Tamaño de los neumáticos:  
Designación de las dimensiones de los neumáticos (ruedas 
motrices externas) con arreglo a la Directiva 92/23/CEE del 
Consejo (  1 ), en su versión modificada en último lugar.  
vv) Identificación del vehículo:  
Números que identifican el vehículo: número de matrícula 
(VRN), con indicación del Estado miembro donde está matri­
culado, y número de identificación (VIN) (  2 ). 
ww) Semana (a efectos de cálculo en el aparato de control):  
Período que va de las 00.00 horas de un lunes a las 24.00 
horas de un domingo, referido al tiempo universal coordinado.  
xx) Tarjeta de taller:  
Tarjeta de tacógrafo expedida por las autoridades de un Estado 
miembro a personal designado de un fabricante o instalador de 
tacógrafos, fabricante de vehículos o taller aprobado por dicho  
Estado miembro, que identifica a su titular y le permite el 
ensayo, calibrado y activación de tacógrafos y/o la transferen­
cia de datos de estos.  
yy) Adaptador:  
Dispositivo que proporciona una señal en todo momento re­
presentativa de la velocidad del vehículo o la distancia reco­
rrida, excepto el utilizado para la detección de movimiento 
independiente, y que:  
▼M3 
— se instala y utiliza exclusivamente en vehículos de las 
categorías M1 y N1, según se definen en el artículo 4 
del Reglamento (UE) 2018/858 del Parlamento Europeo 
y del Consejo (  3 ); 
▼B 
— se instala cuando mecánicamente resulta imposible instalar 
ningún otro tipo de sensor de movimiento existente que 
por su parte cumpla las disposiciones de este anexo y sus 
apéndices 1 a 15;  ▼M3 
( 1 ) Directiva 92/23/CEE del Consejo, de 31 de marzo de 1992, sobr e los neumáticos de los 
vehículos de motor y de sus remolques así como de su montaje (D O L 129 de 14.5.1992, 
p. 95). 
( 2 ) Directiva 76/114/CEE del Consejo, de 18 de diciembre de 1975,  relativa a la aproxima­
ción de las legislaciones de los Estados Miembros sobre las pla cas e inscripciones 
reglamentarias, así como a su emplazamiento y modo de colocació n, en lo que se refiere 
a los vehículos a motor y a sus remolques (DO L 24 de 30.1.1976 , p. 1). 
( 3 ) Reglamento (UE) 2018/858 del Parlamento Europeo y del Consejo , de 30 de mayo de 
2018, sobre la homologación y la vigilancia del mercado de los vehículos de motor y sus 
remolques y de los sistemas, los componentes y las unidades téc nicas independientes 
destinados a dichos vehículos, por el que se modifican los Regl amentos (CE) 
n. o 715/2007 y (CE) n.  o 595/2009 y por el que se deroga la Directiva 2007/46/CE 
(DO L 151 de 14.6.2018, p. 1).
 02016R0799 — ES — 21.08.2023 — 003.001 — 22  
— se instala entre la unidad instalada en el vehículo y el luga r 
en el que se generan los impulsos de velocidad o distancia 
mediante sensores integrados o interfaces alternativas;  
— desde la perspectiva de la unidad instalada en el vehículo, 
el comportamiento del adaptador es el mismo que se ob­
tendría conectando a la unidad instalada en el vehículo un 
sensor de movimiento conforme a las disposiciones del 
presente anexo y sus apéndices 1 a 16.  
El uso de este tipo de adaptador en los vehículos indicados 
anteriormente permitirá la instalación y la utilización correct a 
de una unidad instalada en el vehículo conforme a todos los 
requisitos del presente anexo.  
En lo que respecta a esos vehículos, el tacógrafo inteligente 
incluye los cables, un adaptador y una unidad instalada en el 
vehículo.  
zz) Integridad de los datos:  
Exactitud y coherencia de los datos almacenados, indicada por 
la ausencia de alteración de los datos entre dos actualizacione s 
de un registro de datos. La integridad implica que los datos 
son copia exacta de la versión original, por ejemplo, que no 
han sido corrompidos en el proceso de su escritura o lectura en  
una tarjeta de tacógrafo o un equipo dedicado o durante la 
transmisión a través de un canal de comunicaciones.  
▼M3 
aaa) Reservado para usos futuros.  
▼B 
bbb) Sistema de tacógrafo inteligente:  
Los aparatos de control, las tarjetas de tacógrafo y el conjunt o 
de todos los equipos que interactúan, directa o indirectamente,  
durante su fabricación, instalación, utilización, ensayo y con­
trol, como las tarjetas, el lector de comunicación a distancia y 
cualquier otro equipo utilizado para transferencia de datos, 
análisis de datos, calibrado, generación, gestión o introducció n 
de elementos de seguridad, etc.  
▼M3 
ccc) Fecha de introducción:  
La fecha indicada en el Reglamento (UE) n.  o 165/2014 a partir 
de la cual los vehículos matriculados por primera vez deberán 
estar equipados con un tacógrafo conforme con el presente 
Reglamento.  
▼B 
ddd) Perfil de protección:  
Documento utilizado como parte del proceso de certificación 
según Criterios Comunes, que facilita una especificación inde­
pendiente de la implementación de los requisitos de seguridad 
de aseguramiento de la información.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 23  
eee) Exactitud del GNSS:  
En el contexto del registro de la posición a partir del sistema  
mundial de navegación por satélite (GNSS) con tacógrafos, el 
valor de la dilución horizontal de la precisión (HDOP), calcu­
lado como el mínimo de los valores de HDOP recogidos en 
los sistemas GNSS disponibles.  
▼M1 
fff) Tiempo de conducción acumulado:  
Valor que representa el número total de minutos de conduc­
ción acumulados de un vehículo determinado.  
El valor del tiempo de conducción acumulado es un recuento 
sin sincronizar de todos los minutos considerados como acti­
vidad de CONDUCCIÓN por la función de supervisión de las 
actividades de conducción del aparato de control, y solo se 
utiliza para poner en marcha el registro de la posición del 
vehículo, cada vez que se alcanza un múltiplo de tres horas 
de conducción acumuladas. La acumulación se inicia cuando 
se activa el aparato de control. No se ve afectada por ninguna 
otra condición, como «Fuera de ámbito» o «Trayecto en trans­
bordador/tren».  
El tiempo de conducción acumulado es un valor que no está 
destinado a mostrarse en pantalla, imprimirse ni transferirse.  
▼B 
2 CARACTERÍSTICAS GENERALES Y FUNCIONES DEL APA­
RATO DE CONTROL  
2.1 Características generales  
El aparato de control sirve para registrar, almacenar, visualiz ar, 
imprimir y enviar datos relacionados con las actividades del 
conductor.  
Todo vehículo que lleve instalado un aparato de control conform e a 
lo dispuesto en el presente anexo debe incorporar además un ind i­
cador de velocidad y un cuentakilómetros. Estas funciones puede n 
estar incluidas en el aparato de control.  
01) El aparato de control incluye cables, un sensor de 
movimiento y una unidad instalada en el vehí­
culo.  
02) La interfaz entre los sensores de movimiento y 
las unidades instaladas en los vehículos deberá 
ajustarse a los requisitos especificados en el 
apéndice 11.  
03) La unidad instalada en el vehículo deberá estar 
conectada a uno o más sistemas mundiales de 
navegación por satélite, tal como se especifica 
en el apéndice 12.  
04) La unidad instalada en el vehículo deberá comu­
nicar con los lectores de comunicación de telede­
tección temprana, tal como se especifica en el 
apéndice 14.  
▼M3 
05) La unidad instalada en el vehículo deberá incluir 
una interfaz ITS, que se especifica en el apén­
dice 13.  
El aparato de control podrá estar conectado a 
otros dispositivos mediante interfaces adicionales 
y/o a través de la interfaz ITS.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 24  
06) Ninguna función o dispositivo, homologado o no, 
que se incluya o se conecte al aparato de control 
deberá interferir ni ser capaz de interferir con el 
funcionamiento correcto y seguro del aparato de 
control ni con lo dispuesto en el presente Regla­
mento.  
Los usuarios del aparato de control se identifican 
ante el aparato a través de las tarjetas de tacó­
grafo.  
07) El aparato de control proporciona derechos de 
acceso selectivo a los datos y funciones según 
el tipo o la identidad del usuario.  
El aparato de control registra y almacena datos en su memoria, en el 
dispositivo de comunicación a distancia y en las tarjetas de ta có­
grafo.  
▼M3 
Esto se efectúa con arreglo a la legislación de la Unión aplica ble en 
materia de protección de datos y de conformidad con el artículo  7  
del Reglamento (UE) n.  o 165/2014.  
▼B 
2.2 Funciones  
08) El aparato de control deberá garantizar las fun­
ciones siguientes:  
— control de la inserción y extracción de las 
tarjetas,  
— medición de la velocidad, distancia y posi­
ción,  
— medición de la hora,  
— supervisión de las actividades del conductor,  
— supervisión del régimen de conducción,  
▼M3 
— entradas manuales de los conductores:  
— entrada de los lugares donde comienzan o 
terminan los períodos de trabajo diarios,  
— entrada manual de las actividades del con­
ductor y del consentimiento del conductor 
a la interfaz ITS,  
— entrada de condiciones específicas,  
— entrada de operaciones de carga/descarga,  
▼B 
— gestión de los bloqueos introducidos por la 
empresa,  
— supervisión de las actividades de control,  
— detección de incidentes o fallos,  
— autodiagnóstico y comprobaciones automáti­
cas, 
— lectura de los datos almacenados en la 
memoria,  
— registro y almacenamiento de datos en la 
memoria,  
— lectura de las tarjetas de tacógrafo,  
— registro y almacenamiento de datos en las 
tarjetas de tacógrafo,  
— visualización,  
— impresión,  
— advertencias,  
— transferencia de datos a medios externos,  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 25  
— comunicación a distancia para controles de 
carretera selectivos,  
— envío de datos a dispositivos adicionales,  
— calibrado,  
— control del calibrado en carretera,  
— ajuste de la hora,  
▼M3 
— seguimiento de los cruces de fronteras,  
— actualización del  software . 
▼B 
2.3 Modos de funcionamiento  
09) El aparato de control deberá tener cuatro modos 
de funcionamiento:  
— modo operativo,  
— modo de control,  
— modo de calibrado,  
— modo de empresa.  
10) El aparato de control pasará al siguiente modo de 
funcionamiento según las tarjetas de tacógrafo 
válidas que se inserten en los dispositivos de 
interfaz: A efectos de determinar el modo de 
funcionamiento, es irrelevante la generación de 
la tarjeta de tacógrafo, siempre que la tarjeta in­
sertada sea válida. Una tarjeta de taller de pri­
mera generación se considerará siempre no válida 
cuando se inserte en una unidad instalada en el 
vehículo de segunda generación.  
Modo de funcionamiento  Ranura del conductor  
Sin tarjeta  Tarjeta de conductor  Tarjeta de control  Tarjeta de taller  Tarjeta de empresa
 Ranura del segundo conductor Sin tarjeta  operativo  operativo  de control  de calibrado  de empresa  
Tarjeta de con­
ductor  operativo  operativo  de control  de calibrado  de empresa  
Tarjeta de con­
trol de control  de control  de control (*)  operativo  operativo  
Tarjeta de taller  de calibrado  de calibrado  operativo  de calibrado (*)  operativo  
Tarjeta de em­
presa  de empresa  de empresa  operativo  operativo  de empresa (*)  
(*) En estas situaciones, el aparato de control utilizará exclu sivamente la tarjeta de tacógrafo insertada en la ranura del co nductor.  
11) El aparato de control no tendrá en cuenta las 
tarjetas no válidas que se inserten, excepto si se 
visualizan, imprimen o transfieren los datos alma­
cenados en una tarjeta que ha expirado, cosa que 
deberá ser posible.  
12) Todas las funciones enumeradas en el apartado 
2.2 estarán disponibles en cualquier modo de 
funcionamiento, con las siguientes excepciones:  
— la función de calibrado solo está disponible 
en el modo de calibrado,  
— la función de control del calibrado en carre­
tera solo está disponible en el modo de 
control,  
— la función de gestión de los bloqueos intro­
ducidos por la empresa solo está disponible 
en el modo de empresa,  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 26  
— la función de supervisión de las actividades 
de control solo funciona en el modo de 
control,  
▼M3 
— La función de transferencia no está disponible 
en el modo operativo, excepto:  
a) según establece el requisito 193,  
b) la transferencia de datos de una tarjeta de 
conductor si no hay otro tipo de tarjeta 
insertada en la VU.  
▼B 
13) El aparato de control podrá enviar cualquier dato 
a la pantalla, a la impresora o a interfaces exter­
nas, con las siguientes excepciones:  
— en el modo operativo, toda identificación per­
sonal (nombre y apellidos) que no corres­
ponda a una tarjeta de tacógrafo insertada 
se borrará por completo, y todo número de 
tarjeta que no corresponda a una tarjeta de 
tacógrafo insertada se borrará parcialmente 
(se borrarán los caracteres impares, de iz­
quierda a derecha);  
▼M3 
— en el modo de empresa, los datos relativos al 
conductor (requisitos 102, 105, 108, 133  bis 
y 133  sexies ) tan solo podrán enviarse a dis­
positivos externos durante los períodos exen­
tos de bloqueo o que no haya bloqueado otra 
empresa (identificada por los trece primeros 
dígitos del número de la tarjeta de empresa);  
▼B 
— si no se ha insertado ninguna tarjeta en el 
aparato de control, solo podrán enviarse los 
datos relativos al conductor que correspondan 
al día actual y a los ocho días civiles 
anteriores;  
▼M3 
— los datos personales registrados y producidos 
por el tacógrafo o por las tarjetas de tacógrafo 
no se enviarán a través de la interfaz ITS de 
la VU a menos que se verifique el consenti­
miento del conductor al que se refieren los 
datos;  
▼M1 
— el período de validez operativa normal de las 
unidades instaladas en vehículos es de quince 
años a partir de la fecha efectiva de los cer­
tificados de dichas unidades, pero podrán uti­
lizarse durante tres meses adicionales solo 
para la transferencia de datos.  
▼B 
2.4 Seguridad  
▼M1 
La seguridad del sistema tiene por objeto proteger la memoria d e 
datos, de manera que se evite el acceso a la misma de terceros no 
autorizados, se excluya la manipulación de información y se det ecte 
cualquier tentativa en ese sentido; así se protege la integrida d y 
autenticidad de los datos intercambiados entre el sensor de mov i­
miento y la unidad instalada en el vehículo, de los datos inter cam­
biados entre el aparato de control y las tarjetas de tacógrafo y de los 
datos intercambiados entre la unidad instalada en el vehículo y  el 
dispositivo GNSS externo, de existir este, se protege la confid en­
cialidad, integridad y autenticidad de los datos intercambiados  a  
través de la comunicación de teledetección temprana con fines d e 
control y se verifica la integridad y autenticidad de los datos  
transferidos.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 27  
14) Al objeto de lograr la seguridad del sistema, los 
siguientes componentes deberán cumplir los re­
quisitos de seguridad que se definen en sus per­
files de protección, según exige el apéndice 10:  
— unidad instalada en el vehículo,  
— tarjeta de tacógrafo,  
— sensor de movimiento,  
▼M3 
— dispositivo GNSS externo (este perfil solo es 
necesario y aplicable para la variante del dis­
positivo GNSS externo).  
▼B 
3 CONDICIONES DE FABRICACIÓN Y FUNCIONAMIENTO 
DEL APARATO DE CONTROL  
3.1 Control de la inserción y extracción de las tarjetas  
15) El aparato de control supervisará los dispositivos 
de interfaz para detectar la inserción y extracción 
de las tarjetas.  
▼M3 
16) Al insertar la tarjeta (o al producirse su autenti­
cación remota), el aparato de control detectará si 
se trata de una tarjeta de tacógrafo válida de 
conformidad con la definición ee) del punto 1 
y, en tal caso, identificará el tipo y la generación 
de la tarjeta.  
Para comprobar si ya se ha insertado una tarjeta, 
el aparato de control utilizará los datos de la 
tarjeta de tacógrafo almacenados en su memoria 
de datos, como se indica en el requisito 133.  
▼B 
17) Las tarjetas de tacógrafo de primera generación 
serán consideradas no válidas por el aparato de 
control una vez que la posibilidad de utilizar 
tarjetas de tacógrafo de primera generación 
haya sido suprimida por un taller, de conformi­
dad con el apéndice 15 (req. MIG003).  
18) Las tarjetas de taller de primera generación que 
se inserten en aparatos de control de la segunda 
generación se considerarán no válidas.  
19) El aparato de control deberá estar construido de 
tal modo que las tarjetas de tacógrafo queden 
fijas en su posición al insertarlas correctamente 
en los dispositivos de interfaz.  
▼M3 
20) La extracción de las tarjetas de tacógrafo solo 
deberá ser posible con el vehículo parado y des­
pués de haberse almacenado en dichas tarjetas los 
datos pertinentes. La extracción de la tarjeta exi­
girá la intervención directa del usuario.  
▼B 
3.2 Medición de la velocidad, la posición y la distancia  
21) El sensor de movimiento (en su caso, integrado 
en el adaptador) es la fuente principal para la 
medición de la velocidad y la distancia.  
22) Esta función medirá de forma continua y permi­
tirá indicar en el cuentakilómetros el valor corres­
pondiente a la distancia total recorrida por el 
vehículo utilizando los impulsos proporcionados 
por el sensor de movimiento.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 28  
23) Esta función medirá de forma continua y permi­
tirá indicar la velocidad del vehículo utilizando 
los impulsos proporcionados por el sensor de 
movimiento.  
24) Asimismo, la función de medición de la veloci­
dad indicará si el vehículo está en movimiento o 
parado. Se considerará que el vehículo está en 
movimiento en cuanto la función, a través del 
sensor de movimiento, detecte más de 1 imp/seg 
durante al menos cinco segundos. De lo contra­
rio, se considerará que el vehículo está parado.  
25) Los dispositivos indicadores de la velocidad (ve­
locímetro) y de la distancia total recorrida (cuen­
takilómetros) instalados en un vehículo que in­
corpore un aparato de control conforme a lo dis­
puesto en el presente Reglamento deberán cum­
plir las condiciones relativas a las tolerancias má­
ximas (véanse los puntos 3.2.1 y 3.2.2) estable­
cidas en el presente anexo.  
▼M3 
26) Para detectar cualquier manipulación de los datos 
de movimiento, la información importada del 
sensor de movimiento deberá ser confirmada 
por aquella otra relativa al movimiento del vehí­
culo procedente del receptor GNSS y de otra(s) 
fuente(s) independiente(s) del sensor de movi­
miento. Dentro de la VU deberá haber al menos 
otra fuente independiente relativa al movimiento 
del vehículo sin necesidad de una interfaz 
externa.  
27) Esta función medirá la posición del vehículo a fin 
de permitir el registro de:  
— las posiciones donde el conductor y/o el se­
gundo conductor empiezan su período de tra­
bajo diario;  
— las posiciones donde el tiempo de conducción 
acumulado alcanza un múltiplo de tres horas;  
— las posiciones donde el vehículo ha cruzado 
la frontera de un país;  
— las posiciones donde se han llevado a cabo 
operaciones de carga/descarga;  
— las posiciones donde el conductor y/o el se­
gundo conductor finalizan su período de tra­
bajo diario.  
▼B 
3.2.1  Medición de la distancia recorrida  
28) La distancia recorrida podrá medirse:  
— bien de forma que se incluyan los movimien­
tos en marcha adelante y en marcha atrás,  
— bien únicamente en marcha adelante.  
29) El aparato de control deberá medir la distancia 
entre 0 y 9 999 999,9 km.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 29  
30) La distancia medida estará comprendida en los 
siguientes límites de tolerancia (distancias de al 
menos 1 000 m):  
— ± 1 % antes de la instalación,  
— ± 2 % después de la instalación y de un con­
trol periódico,  
— ± 4 % durante el uso.  
▼M3 
Las tolerancias no se utilizarán para alterar inten­
cionadamente la distancia medida.  
▼B 
31) La distancia medida tendrá una resolución igual o 
mejor que 0,1 km.  
3.2.2  Medición de la velocidad  
32) El aparato de control deberá medir la velocidad 
entre 0 y 220 km/h.  
▼M3 
33) A fin de garantizar una tolerancia máxima de 
± 6 km/h para la indicación de la velocidad du­
rante el uso, y teniendo en cuenta:  
— una tolerancia de ± 2 km/h para posibles va­
riaciones de los valores de entrada (variacio­
nes de los neumáticos, …),  
— una tolerancia de ± 1 km/h en las mediciones 
realizadas durante la instalación o en los con­
troles periódicos,  
el aparato de control deberá medir la velocidad 
con una tolerancia de ± 1 km/h (a velocidad 
constante) para velocidades entre 20 y 180 km/h 
y para coeficientes característicos del vehículo 
entre 2 400 y 25 000 imp/km.  
Nota: La resolución del almacenamiento de datos 
aporta una tolerancia adicional de ± 0,5 km/h a la 
velocidad registrada por el aparato de control.  
▼B 
34) La velocidad deberá medirse correctamente den­
tro de las tolerancias normales y antes de que 
hayan transcurrido dos segundos tras haberse 
producido un cambio de velocidad, si dicho cam­
bio no sobrepasa una aceleración de 2 m/s  2 . 
35) La medición de la velocidad tendrá una resolu­
ción igual o mejor que 1 km/h.  
3.2.3  Medición de la posición  
36) El aparato de control medirá la posición absoluta 
del vehículo utilizando el receptor GNSS.  
▼M3 
37) La posición absoluta deberá medirse en coorde­
nadas geográficas de latitud y longitud, en grados 
y minutos, con una resolución de 1/10 de minuto.  
▼B 
3.3 Medición de la hora  
38) La función de medición de la hora deberá medir 
de forma continua y expresar digitalmente la fe­
cha y la hora correspondientes al tiempo univer­
sal coordinado (UTC).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 30  
39) La fecha y la hora UTC deberán utilizarse para 
fechar los datos internos del aparato de control 
(registros, intercambio de datos) y para toda im­
presión especificada en el apéndice 4: «Docu­
mentos de impresión».  
40) A fin de visualizar la hora local, existirá la posi­
bilidad de cambiar el desfase horario que aparece 
en pantalla, en fracciones de media hora. Tan 
solo se podrá compensar dicho desfase añadiendo 
múltiplos negativos o positivos de fracciones de 
media hora.  
▼M3 
41) La desviación de la hora será ± 1 segundo por 
día o inferior, en condiciones de temperatura con­
formes con el requisito 213, en ausencia de ajus­
tes de la hora.  
41 bis) La exactitud de la hora cuando esta sea ajustada 
por los talleres de conformidad con el requi­
sito 212 será como mínimo de tres segundos.  
41 ter) La unidad instalada en el vehículo incluirá un 
contador de deriva que compute la desviación 
máxima de la hora desde el último ajuste de la 
hora conforme al punto 3.23. La desviación má­
xima de la hora será definida por el fabricante de 
la unidad instalada en el vehículo y no excederá 
de un segundo por día, como se indica en el 
requisito 41.  
41 quater ) El contador de deriva se reajustará a un segundo 
cada vez que se ajuste la hora del aparato de 
control conforme al punto 3.23. Esto incluye:  
— ajustes automáticos de la hora,  
— ajustes de la hora realizados en el modo de 
calibrado.  
▼B 
42) La hora medida tendrá una resolución igual o 
superior a un segundo.  
43) En las condiciones de homologación, la medición 
de la hora no deberá verse afectada por interrup­
ciones del suministro eléctrico de duración infe­
rior a doce meses.  
3.4 Supervisión de las actividades del conductor  
44) Esta función deberá controlar permanentemente y 
por separado las actividades de un conductor y 
un segundo conductor.  
45) Las actividades del conductor pueden ser CON­
DUCCIÓN, TRABAJO, DISPONIBILIDAD o 
PAUSA/DESCANSO.  
46) El conductor o el segundo conductor deberán 
tener la posibilidad de seleccionar manualmente 
las actividades de TRABAJO, DISPONIBILI­
DAD o PAUSA/DESCANSO.  
47) Cuando el vehículo esté en movimiento, el aparato 
seleccionará automáticamente la actividad de 
CONDUCCIÓN para el conductor y la actividad 
de DISPONIBILIDAD para el segundo conductor.  
48) Cuando el vehículo se detenga, se seleccionará 
automáticamente la actividad de TRABAJO 
para el conductor.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 31  
49) Si el primer cambio de actividad a PAUSA/DES­
CANSO o DISPONIBILIDAD tiene lugar antes de 
que hayan transcurrido 120 segundos tras haber cam­
biado automáticamente a TRABAJO por haberse de­
tenido el vehículo, se entenderá que ha tenido lugar a 
la hora en que se detuvo el vehículo (por consi­
guiente, podría cancelar el cambio a TRABAJO).  
▼B 
50) Esta función deberá notificar los cambios de ac­
tividad a las funciones de registro con una reso­
lución de un minuto.  
51) A partir de un minuto cualquiera, si se registra 
alguna actividad de CONDUCCIÓN en los mi­
nutos inmediatamente anterior y posterior, se 
considerará que todo el minuto es de actividad 
de CONDUCCIÓN.  
52) Dado un minuto cualquiera que no se considere 
de CONDUCCIÓN con arreglo al requisito 051, 
se considerará que todo el minuto será de un 
mismo tipo de actividad, concretamente la que 
haya tenido lugar de forma continuada y durante 
más tiempo durante ese minuto (en caso de haber 
dos actividades de la misma duración, la que se 
haya producido en último lugar).  
53) Esta función también deberá controlar permanen­
temente el tiempo de conducción continua y el 
tiempo de descanso acumulado del conductor.  
3.5 Supervisión del régimen de conducción  
54) Esta función deberá controlar permanentemente 
el régimen de conducción.  
55) Si hay dos tarjetas de conductor insertadas en el 
aparato, habrá que seleccionar el régimen EN 
EQUIPO. De otro modo se seleccionará el régi­
men EN SOLITARIO.  
3.6 Entradas de los conductores  
3.6.1  Introducción de los lugares donde comienzan o terminan los perío ­
dos de trabajo diarios  
56) Esta función deberá permitir la introducción de 
los lugares donde, según el conductor y/o el se­
gundo conductor, comienzan o terminan sus pe­
ríodos de trabajo diarios.  
▼M3 
57) Se entiende por lugar el país y, cuando proceda, 
la región.  
58) En el momento de extraer la tarjeta de conductor (o de 
taller), el aparato de control mostrará la ubicación 
actual del vehículo sobre la base de la información 
del GNSS y del mapa digital almacenado de confor­
midad con el punto 3.12.19, y pedirá al titular de la 
tarjeta que confirme o rectifique manualmente el lugar.  
59) El lugar introducido de conformidad con el re­
quisito 58 se considerará el lugar donde termina 
el período de trabajo diario. Se registrará en la 
correspondiente tarjeta de conductor (o de taller) 
como registro temporal y, por lo tanto, podrá 
sobrescribirse posteriormente.  
Si se cumplen las siguientes condiciones, se valida 
la entrada temporal efectuada en la última extrac­
ción de la tarjeta (es decir, ya no se sobrescribirá):  
— introducción de un lugar donde comienza el pe­
ríodo de trabajo diario actual durante la introduc­
ción manual de conformidad con el requisito 61;  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 32  
— la siguiente introducción de un lugar donde 
comienza el período de trabajo diario actual, 
si el titular de la tarjeta no introduce el lugar 
donde comienza o finalizó el período de tra­
bajo durante la introducción manual de con­
formidad con el requisito 61.  
Si se cumplen las siguientes condiciones, se so­
brescribe la entrada temporal efectuada en la úl­
tima extracción de la tarjeta y se valida el nuevo 
valor:  
— la siguiente introducción de un lugar donde 
termina el período de trabajo diario actual, si 
el titular de la tarjeta no introduce el lugar 
donde comienza o finalizó el período de tra­
bajo durante la introducción manual de con­
formidad con el requisito 61.  
▼B 
60) Se podrán introducir los lugares donde comien­
cen y/o terminen los períodos de trabajo diarios a 
través de comandos de los menús. Si se produce 
más de una entrada en un minuto cualquiera, tan 
solo quedarán registrados el último lugar de co­
mienzo y el último lugar de finalización de tra­
bajo introducidos en el marco temporal de dicho 
minuto.  
▼M3 
El aparato de control mostrará la ubicación actual 
del vehículo sobre la base de la información del 
GNSS y de los mapas digitales almacenados de 
conformidad con el punto 3.12.19, y pedirá al 
conductor que confirme o rectifique manualmente 
el lugar.  
▼B 
3.6.2  Introducción manual de las actividades del conductor y del consen ­
timiento del conductor a la interfaz ITS  
▼M3 
61) El aparato de control permitirá la introducción 
manual de actividades única y exclusivamente 
al insertar la tarjeta de conductor (o de taller). 
Para la introducción manual de actividades, se 
utilizarán la fecha y la hora locales de la zona 
horaria (desfase UTC) configuradas para la uni­
dad instalada en el vehículo.  
Al insertar la tarjeta de conductor o de taller, se 
recordarán al titular de la tarjeta:  
— la fecha y la hora de la última extracción de 
la tarjeta;  
— opcionalmente: el desfase horario local confi­
gurado para la unidad instalada en el vehí­
culo.  
Al insertar por primera vez determinada tarjeta de 
conductor o de taller desconocida para la unidad 
instalada en el vehículo, se invitará al titular de la 
tarjeta a dar su consentimiento a la salida de 
datos personales relacionados con el tacógrafo a 
través de la interfaz ITS. Para comprobar si ya se 
ha insertado una tarjeta, el aparato de control 
utilizará los datos de la tarjeta de tacógrafo alma­
cenados en su memoria de datos, tal como se 
indica en el requisito 133.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 33  
En cualquier momento, podrá habilitarse o inha­
bilitarse el consentimiento del conductor (respec­
tivamente, del taller) a través de comandos del 
menú, siempre que esté insertada la tarjeta de 
conductor (respectivamente, de taller).  
Se podrán introducir actividades observando las 
siguientes restricciones:  
— el tipo de actividad podrá ser: TRABAJO, 
DISPONIBILIDAD o PAUSA/DESCANSO;  
— la hora de comienzo y finalización de cada 
actividad estará enmarcada en el intervalo que 
transcurre entre la última extracción de la 
tarjeta y su inserción actual;  
— no deberá producirse ningún solapamiento 
temporal entre las diversas actividades.  
Si fuere necesario, podrán realizarse entradas ma­
nuales al insertar, por vez primera, una tarjeta de 
conductor (o de taller) no utilizada previamente.  
El procedimiento de introducción manual de ac­
tividades incluirá tantas fases consecutivas como 
sea necesario para configurar los distintos tipos 
de actividad y la hora de comienzo y finalización 
de cada actividad. El titular de la tarjeta podrá 
optar por no declarar actividad alguna durante 
cualquier intervalo de tiempo entre la última ex­
tracción de la tarjeta y la inserción actual.  
Durante el proceso de introducción manual de 
actividades asociado a la inserción de la tarjeta, 
y en los casos pertinentes, el titular de la tarjeta 
podrá introducir, asimismo:  
— un lugar en que haya terminado un período 
de trabajo diario precedente, asociado a la 
hora pertinente (sobrescribiendo y validando 
así la entrada realizada con motivo de la úl­
tima extracción de la tarjeta), o  
— un lugar en que comienza el período de tra­
bajo diario actual, asociado a la hora perti­
nente (validando así una entrada temporal re­
alizada con motivo de la última extracción de 
la tarjeta).  
Con respecto al lugar en que comienza el período 
de trabajo diario actual, introducido con la inser­
ción actual de la tarjeta, el aparato de control 
mostrará la ubicación actual del vehículo sobre 
la base de la información del GNSS y de los 
mapas digitales almacenados de conformidad 
con el punto 3.12.19, y pedirá al conductor que 
confirme o rectifique manualmente el lugar.  
Si el titular de la tarjeta no introduce el lugar 
donde comienza o finaliza el período de trabajo 
durante el proceso de introducción manual aso­
ciado a la inserción de la tarjeta, se considerará 
que declara que su período de trabajo no ha 
cambiado desde la última extracción de la tarjeta. 
La próxima entrada de un lugar donde termina el 
período de trabajo diario precedente sobrescri­
birá, pues, la entrada temporal realizada en la 
última extracción de la tarjeta.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 34  
Si se introduce un lugar, este quedará registrado 
en la tarjeta de tacógrafo pertinente.  
Se interrumpirán las introducciones manuales en 
los siguientes casos:  
— cuando se extraiga la tarjeta, o  
— cuando el vehículo se mueva permaneciendo 
insertada la tarjeta en la ranura del conductor.  
Se permiten otras interrupciones como, por ejem­
plo, la desconexión tras un cierto período de 
inactividad del usuario. En caso de interrumpirse 
el proceso de introducción manual, el aparato de 
control validará cualquier entrada completa de 
lugar y actividad ya realizada (indicando de 
forma inequívoca el lugar y la hora, o el tipo 
de actividad y la hora de comienzo y finaliza­
ción).  
Si se inserta la tarjeta de un segundo conductor o 
de un taller mientras está en curso la introducción 
manual de actividades para una tarjeta previa­
mente insertada, se permitirá completar dichas 
entradas correspondientes a la tarjeta anterior an­
tes de dar paso a la introducción manual de en­
tradas relativas a la segunda tarjeta.  
El titular de la tarjeta podrá realizar entradas ma­
nualmente conforme al siguiente procedimiento 
mínimo:  
— introducir manualmente y por orden cronoló­
gico las actividades realizadas durante el pe­
ríodo comprendido entre la última extracción 
de la tarjeta y la actual inserción;  
— la hora de comienzo de la primera actividad 
se ajustará a la hora de extracción de la tar­
jeta; la hora de comienzo de cada entrada 
sucesiva deberá ajustarse al momento inme­
diatamente posterior a la hora de finalización 
de la entrada precedente; deberá indicarse 
para cada actividad el tipo de actividad y la 
hora de finalización.  
El procedimiento concluirá cuando la hora de 
finalización de una actividad introducida manual­
mente coincida con la hora de inserción de la 
tarjeta.  
El aparato de control permitirá a los conductores 
y los talleres cargar alternativamente las entradas 
manuales que deban introducirse durante el pro­
cedimiento a través de la interfaz ITS especifi­
cada en el apéndice 13 y, opcionalmente, a través 
de otras interfaces.  
A continuación, el aparato de control permitirá al 
titular de la tarjeta modificar las actividades in­
troducidas manualmente, hasta validarlas selec­
cionando un comando específico. Una vez vali­
dadas las actividades, estará prohibido realizar 
modificaciones.  
▼B 
3.6.3  Entrada de condiciones específicas  
▼M3 
62) El aparato de control permitirá al conductor in­
troducir, en tiempo real, las dos condiciones es­
pecíficas siguientes:  
— «FUERA DE ÁMBITO» (comienzo, final),  
— «TRAYECTO EN TRANSBORDADOR/ 
TREN» (comienzo, final).  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 35  
La condición «TRAYECTO EN TRANSBOR­
DADOR/TREN» no deberá darse si está abierta 
la condición «FUERA DE ÁMBITO». Si está 
abierta la condición «FUERA DE ÁMBITO», 
el aparato de control no permitirá a los usuarios 
introducir un indicador de comienzo de «TRA­
YECTO EN TRANSBORDADOR/TREN».  
Si la condición «FUERA DE ÁMBITO» está 
abierta, el aparato de control tendrá que cerrarla 
inmediatamente en caso de insertarse o extraerse 
una tarjeta de conductor.  
El hecho de estar abierta la condición «FUERA 
DE ÁMBITO» impedirá los siguientes incidentes 
y advertencias:  
— conducción sin tarjeta adecuada,  
— advertencias asociadas al tiempo de conduc­
ción continua.  
El conductor introducirá el indicador de co­
mienzo de «TRAYECTO EN TRANSBORDA­
DOR/TREN» inmediatamente después de selec­
cionar «PAUSA/DESCANSO» en el transborda­
dor o el tren.  
El aparato de control debe finalizar una condi­
ción abierta de «TRAYECTO EN TRANSBOR­
DADOR/TREN» cuando se dé cualquiera de las 
siguientes circunstancias:  
— el conductor finaliza manualmente la condi­
ción «TRAYECTO EN TRANSBORDA­
DOR/TREN», como deberá hacer al llegar 
al destino del transbordador/tren, antes de sa­
lir del transbordador/tren,  
— se abre la condición «FUERA DE ÁM­
BITO»,  
— el conductor extrae su tarjeta,  
— la actividad del conductor se computa como 
CONDUCCIÓN durante un minuto cual­
quiera de conformidad con el punto 3.4.  
Si en un minuto cualquiera se realiza más de una 
entrada de condiciones específicas del mismo 
tipo, solo se registrará la última.  
3.6.4  Entrada de la operación de carga/descarga  
62 bis El aparato de control permitirá al conductor in­
troducir y confirmar, en tiempo real, la informa­
ción que indique que el vehículo está siendo car­
gado o descargado o que se está efectuando una 
operación de carga/descarga simultáneas.  
Si en un minuto cualquiera se realiza más de una 
entrada de operaciones de carga/descarga del 
mismo tipo, solo se registrará la última.  
62 ter Las operaciones de carga, de descarga o de 
carga/descarga simultáneas se registrarán como 
incidentes separados.  
62 quater  La información sobre carga/descarga se introdu­
cirá antes de que el vehículo abandone el lugar 
donde se realiza la operación de carga/descarga.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 36  
3.7 Gestión de los bloqueos introducidos por la empresa  
63) Esta función deberá permitir la gestión de los 
bloqueos que haya introducido una empresa con 
el fin de restringir el acceso a sus propios datos 
en el modo de empresa.  
64) Estos bloqueos consisten en una fecha/hora ini­
cial (activación del bloqueo) y una fecha/hora 
final (desactivación del bloqueo) asociadas con 
la identificación de la empresa, indicada por el 
número de la tarjeta de la empresa (al activarse el 
bloqueo).  
65) Los bloqueos se activan y desactivan siempre en 
tiempo real.  
66) Sólo podrá desactivar el bloqueo la empresa que 
lo haya activado (identificada por los trece pri­
meros dígitos del número de la tarjeta de la em­
presa), o bien  
67) El bloqueo se desactivará automáticamente si otra 
empresa activa un bloqueo.  
68) En los casos en los que la empresa que activa el 
bloqueo es la misma empresa que introdujo el 
anterior bloqueo, se considerará que el bloqueo 
previo no ha sido desactivado y se encuentra 
todavía activo.  
3.8 Supervisión de las actividades de control  
69) Esta función supervisa las actividades de VISUA­
LIZACIÓN, IMPRESIÓN, TRANSFERENCIA 
de la VU y de la tarjeta y control del CALI­
BRADO EN CARRETERA que se lleven a 
cabo en el modo de control.  
70) Esta función también supervisa las actividades de 
CONTROL DEL EXCESO DE VELOCIDAD en 
el modo de control. Se entenderá que se ha pro­
ducido un control del exceso de velocidad 
cuando, estando en el modo de control, se haya 
enviado la señal de «exceso de velocidad» a la 
impresora o a la pantalla, o cuando la memoria 
de datos de la VU haya transferido datos sobre 
«incidentes y fallos».  
3.9 Detección de incidentes o fallos  
71) Esta función detecta los siguientes incidentes o 
fallos:  
3.9.1  Incidente «Inserción de una tarjeta no válida»  
72) Este incidente se produce al insertar una tarjeta 
no válida, al insertar una tarjeta de conductor ya 
sustituida y/o cuando expira una tarjeta válida 
insertada.  
3.9.2  Incidente «Conflicto de tarjetas»  
73) Este incidente se produce cuando se produce al­
guna de las combinaciones de tarjetas válidas 
señaladas con X en el siguiente cuadro:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 37  
Conflicto de tarjetas  Ranura del conductor  
Sin tarjeta  Tarjeta de con­
ductor  Tarjeta de control  Tarjeta de taller  Tarjeta de empresa
 Ranura del segundo conductor 
Sin tarjeta  
Tarjeta de conductor  X  
Tarjeta de control  X  X  X  
Tarjeta de taller  X  X  X  X  
Tarjeta de empresa  X  X  X  
3.9.3  Incidente «Solapamiento temporal»  
74) Este incidente se produce cuando la fecha/hora 
en que se extrajo por última vez una tarjeta de 
conductor, según quede registrado en dicha tar­
jeta, es posterior a la fecha/hora actual del apa­
rato de control donde se inserta la tarjeta.  
3.9.4  Incidente «Conducción sin tarjeta adecuada»  
75) Este incidente se produce en determinadas com­
binaciones de dos tarjetas de tacógrafo válidas 
(indicadas con una X en el cuadro siguiente), 
cuando la actividad del conductor cambia a 
CONDUCCIÓN o cuando tiene lugar un cambio 
del modo de funcionamiento mientras la activi­
dad del conductor es CONDUCCIÓN:  
Conducción sin tarjeta adecuada  Ranura del conductor  
Sin tarjeta (o 
tarjeta no válida)  Tarjeta de 
conductor  Tarjeta de control  Tarjeta de taller  Tarjeta de empresa
 Ranura del segundo conductor 
Sin tarjeta (o tarjeta 
no válida)  X X  X  
Tarjeta de conductor  X  X  X  X  
Tarjeta de control  X  X  X  X  X  
Tarjeta de taller  X  X  X  X  
Tarjeta de empresa  X  X  X  X  X  
3.9.5  Incidente «Inserción de tarjeta durante la conducción»  
76) Este incidente se produce cuando se inserta una 
tarjeta de tacógrafo en una de las ranuras mien­
tras la actividad del conductor es CONDUC­
CIÓN.  
3.9.6  Incidente «Error al cerrar la última sesión de la tarjeta»  
77) Este incidente se produce cuando, al insertar la 
tarjeta, el aparato de control detecta que, a pesar 
de lo dispuesto en el punto 3.1, la sesión anterior 
de la tarjeta no se ha cerrado correctamente (se 
ha extraído la tarjeta antes de que pudieran gra­
barse en ella todos los datos pertinentes). Este 
incidente afecta exclusivamente a las tarjetas de 
conductor y a las tarjetas de taller.  
3.9.7  Incidente «Exceso de velocidad»  
78) Este incidente se produce cada vez que se sobre­
pasa la velocidad permitida.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 38  
3.9.8  Incidente «Interrupción del suministro eléctrico»  
79) Este incidente se produce cuando el suministro 
eléctrico del sensor de movimiento o de la uni­
dad instalada en el vehículo se interrumpe du­
rante más de 200 milisegundos, fuera del modo 
de calibrado o de control. El umbral de interrup­
ción deberá definirlo el fabricante. La caída de 
tensión que se produce al arrancar el motor del 
vehículo no deberá activar este incidente.  
3.9.9  Incidente «Error de comunicación con el dispositivo de comunica ­
ción a distancia»  
80) Este incidente se produce,  fuera del modo de 
calibrado , cuando el dispositivo de comunica­
ción a distancia no acusa recibo de la correcta 
recepción de los datos de comunicación a distan­
cia enviados desde la unidad instalada en el ve­
hículo durante más de tres intentos.  
3.9.10  Incidente «Ausencia de información sobre la posición procedente 
del receptor GNSS»  
81) Este incidente se produce,  fuera del modo de 
calibrado , en caso de ausencia de información 
sobre la posición procedente del receptor GNSS 
(sea interno o externo) durante más de tres horas 
de tiempo de conducción acumulado.  
3.9.11  Incidente «Error de comunicación con el dispositivo GNSS externo»  
82) Este incidente se produce,  fuera del modo de 
calibrado , en caso de interrupción de la comu­
nicación entre el receptor GNSS externo y la 
unidad instalada en el vehículo durante más de 
veinte minutos seguidos, cuando el vehículo está 
en movimiento.  
3.9.12  Incidente «Error de datos de movimiento»  
▼M3 
83) Este incidente se activará,  fuera del modo de 
calibrado , en caso de interrupción del flujo nor­
mal de datos entre el sensor de movimiento y la 
unidad instalada en el vehículo o en caso de 
producirse un error de integridad o de autentica­
ción de datos durante el intercambio entre el 
sensor de movimiento y la unidad instalada en 
el vehículo. Este incidente también se activará,  
fuera del modo de calibrado , en caso de que 
la velocidad calculada a partir de los impulsos 
del sensor de movimiento aumente de 0 a más 
de 40 km/h en un segundo y a continuación se 
mantenga por encima de 40 km/h durante al me­
nos tres segundos.  
▼B 
3.9.13  Incidente «Conflicto de movimiento del vehículo»  
▼M3 
84) Este incidente se activará, como se especifica en 
el apéndice 12,  fuera del modo de calibrado , en 
caso de que la información sobre el movimiento 
calculada a partir del sensor de movimiento esté 
en contradicción con la información sobre el mo­
vimiento calculada a partir del receptor GNSS 
interno o del dispositivo GNSS externo o con 
otras fuentes independientes de conformidad 
con el requisito 26. Este incidente no se activará 
durante un trayecto en transbordador/tren.  ▼B
02016R0799 — ES — 21.08.2023 — 003.001 — 39  
3.9.14  Incidente «Intento de violación de la seguridad»  
85) Este incidente se produce cuando por algún mo­
tivo se ha visto afectada la seguridad del sensor 
de movimiento, de la unidad instalada en el ve­
hículo o del dispositivo GNSS externo, según se 
especifica en el apéndice 10, fuera del modo de 
calibrado.  
▼M1 
3.9.15  Incidente «Conflicto temporal»  
▼M3 
86) Este incidente se activará,  fuera del modo de 
calibrado , cuando la VU detecte una discrepan­
cia entre la hora de la función de medición de la 
hora de la unidad instalada en el vehículo y la 
hora procedente de las posiciones autenticadas 
transmitidas por el receptor GNSS o el disposi­
tivo GNSS externo. Se detecta una «discrepancia 
temporal» si la diferencia horaria excede de ± 3 se­
gundos, correspondientes a la exactitud de la 
hora indicada en el requisito 41  bis, incrementada 
esta última con la desviación máxima diaria de la 
hora. Este incidente se registrará junto con el 
valor del reloj interno del aparato de control. 
La VU realizará la comprobación para activar 
el incidente «conflicto temporal» justo antes de 
reajustar automáticamente su reloj interno, de 
conformidad con el requisito 211.  
▼B 
3.9.16  Fallo «Tarjeta»  
87) Este fallo está asociado al fallo de funciona­
miento de una tarjeta de tacógrafo.  
3.9.17  Fallo «Aparato de control»  
88) Este fallo está asociado a uno de los fallos si­
guientes, fuera del modo de calibrado:  
— fallo interno de la VU,  
— fallo de la impresora,  
— fallo de la pantalla,  
— fallo de transferencia,  
— fallo del sensor,  
— fallo del receptor GNSS o del dispositivo 
GNSS externo,  
— fallo del dispositivo de comunicación a dis­
tancia ,  
▼M3 
— fallo de la interfaz ITS.  
3.9.18  Incidente «Anomalía del GNSS»  
88 bis)  Este incidente se activará, fuera del modo de 
calibrado, cuando el receptor GNSS detecte un 
ataque o cuando haya fallado la autenticación 
de los mensajes de navegación, tal como se es­
pecifica en el apéndice 12. Después de haberse 
producido un incidente de anomalía del GNSS, la 
VU no generará más incidentes de anomalía del 
GNSS durante los diez minutos siguientes.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 40  
3.10 Autodiagnóstico y comprobaciones automáticas  
89) El aparato de control deberá ser capaz de detectar 
los fallos ocurridos mediante comprobaciones au­
tomáticas y una función de autodiagnóstico, con 
arreglo al cuadro siguiente:  
Subconjunto que se verifica  Comprobación auto­
mática  Autodiagnóstico  
Software  Integridad  
Memoria de datos  Acceso  Acceso, integridad 
de los datos  
Dispositivos de interfaz 
para tarjetas  Acceso  Acceso  
Teclado  Comprobación ma­
nual 
Impresora  (depende del 
fabricante)  Documento impreso  
Pantalla  Comprobación vi­
sual 
Transferencia 
(exclusivamente durante 
la transferencia)  Funcionamiento 
correcto  
Sensor  Funcionamiento 
correcto  Funcionamiento co­
rrecto  
Dispositivo de comuni­
cación a distancia.  Funcionamiento 
correcto  Funcionamiento co­
rrecto  
Dispositivo GNSS  Funcionamiento 
correcto  Funcionamiento co­
rrecto  
▼M3 
Interfaz ITS  Funcionamiento 
correcto  
▼B 
3.11 Lectura de datos de la memoria  
90) El aparato de control deberá ser capaz de leer 
todos los datos almacenados en su memoria.  
3.12 Registro y almacenamiento de datos en la memoria  
▼M3 
A efectos del presente punto:  
— Por «365 días» se entienden 365 días civiles de actividad med ia 
de conductores en un vehículo. Por actividad media diaria en un  
vehículo se entiende al menos 6 conductores o segundos con­
ductores, 6 ciclos de inserción-extracción de tarjeta y 256 cam ­
bios de actividad. Por consiguiente, «365 días» incluyen al me­
nos 2 190 conductores o segundos conductores, 2 190 ciclos de 
inserción-extracción de tarjeta y 93 440 cambios de actividad.  
— El número medio de entradas de lugar diarias se define como a l 
menos 6 entradas donde comienza el período de trabajo diario 
y 6 entradas donde termina el período de trabajo diario, de 
manera que «365 días» incluyen al menos 4 380 entradas de 
lugar.  
— El número medio de posiciones diarias cuando el tiempo de 
conducción acumulado alcanza un múltiplo de tres horas se 
define como al menos 6 posiciones, de manera que «365 días» 
incluyen al menos 2 190 posiciones de ese tipo.  
— El número medio de cruces de fronteras diarios se define como  
al menos 20 cruces, de manera que «365 días» incluyen al 
menos 7 300 cruces de fronteras.  ▼B
02016R0799 — ES — 21.08.2023 — 003.001 — 41  
— El número medio de operaciones de carga/descarga diarias se 
define como al menos 25 operaciones (independientemente del 
tipo), de manera que «365 días» incluyen al menos 9 125 ope­
raciones de carga/descarga.  
— Las horas se registran con una resolución de un minuto, a men os 
que se especifique lo contrario.  
— Las lecturas del cuentakilómetros se registran con una resolu ción 
de un kilómetro.  
— Las velocidades se registran con una resolución de 1 km/h.  
— Las posiciones (latitudes y longitudes) se registran en grado s y 
minutos, con una resolución de 1/10 de minuto, con la exactitud  
del GNSS asociada y la hora de adquisición, y con un indicador 
que señale si la posición ha sido autenticada.  
▼B 
91) En las condiciones de homologación, los datos 
almacenados en la memoria de datos no deberán 
verse afectados por interrupciones del suministro 
eléctrico de menos de doce meses de duración. 
Además, los datos almacenados en el dispositivo 
de comunicación a distancia externo, tal como se 
definen en el apéndice 14, no deberán verse afec­
tados por interrupciones del suministro eléctrico 
de menos de 28 días de duración.  
92) El aparato de control deberá ser capaz de regis­
trar y almacenar de forma implícita o explícita en 
su memoria de datos lo siguiente:  
3.12.1  Datos de identificación de los equipos  
3.12.1.1 D a t o s d e i d e n t i f i c a c i ó n d e l a u n i d a d i n s t a l a d a 
e n e l v e h í c u l o  
93) El aparato de control deberá ser capaz de alma­
cenar en su memoria de datos los siguientes da­
tos de identificación de la unidad instalada en el 
vehículo:  
— nombre del fabricante,  
— dirección del fabricante,  
— número de pieza,  
— número de serie,  
— generación de la VU,  
— capacidad para utilizar las tarjetas de tacó­
grafo de primera generación,  
— versión de  software , 
— fecha de instalación de la versión de  soft­
ware , 
— año de fabricación del equipo,  
— número de homologación,  
▼M3 
— identificador de la versión del mapa digital 
(requisito 133  terdecies ). 
94) El fabricante de la unidad instalada en el vehí­
culo registra y almacena una sola y definitiva vez 
los datos de identificación de dicha unidad, ex­
cepto los datos que pueden modificarse en caso 
de actualización del  software  de conformidad con 
el presente Reglamento y la capacidad de utilizar 
tarjetas de tacógrafo de primera generación.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 42  
3.12.1.2 D a t o s d e i d e n t i f i c a c i ó n d e l s e n s o r d e m o v i ­
m i e n t o  
95) El sensor de movimiento deberá ser capaz de 
almacenar en su memoria los siguientes datos 
de identificación:  
— nombre del fabricante,  
— número de serie,  
— número de homologación,  
— identificador del componente de seguridad in­
tegrado (por ejemplo, número de pieza del 
chip/procesador interno),  
— identificador del sistema operativo (por ejem­
plo, versión de  software ). 
96) El fabricante del sensor de movimiento registra y 
almacena en el propio sensor de manera perma­
nente, sin posibilidad de alteración, los datos de 
identificación de dicho sensor.  
▼M3 
97) La unidad instalada en el vehículo deberá ser 
capaz de registrar y almacenar en su memoria 
los siguientes datos, correspondientes a los últi­
mos veinte emparejamientos logrados de los sen­
sores de movimiento (si se producen varios em­
parejamientos dentro de un día civil, solo se al­
macenarán el primero y el último del día).  
▼B 
Deberán almacenarse los datos siguientes para 
cada uno de estos emparejamientos:  
— datos de identificación del sensor de 
movimiento:  
— número de serie,  
— número de homologación,  
— datos de emparejamiento del sensor de 
movimiento:  
— fecha del emparejamiento.  
3.12.1.3 D a t o s d e i d e n t i f i c a c i ó n d e l o s s i s t e m a s m u n d i a ­
l e s d e n a v e g a c i ó n p o r s a t é l i t e  
98) El dispositivo GNSS externo deberá ser capaz de 
almacenar en su memoria los siguientes datos de 
identificación:  
— nombre del fabricante,  
— número de serie,  
— número de homologación,  
— identificador del componente de seguridad in­
tegrado (por ejemplo, número de pieza del 
chip/procesador interno),  
— identificador del sistema operativo (por ejem­
plo, versión de  software ). 
99) El fabricante del dispositivo GNSS externo regis­
tra y almacena en el propio dispositivo de manera 
permanente, sin posibilidad de alteración, los da­
tos de identificación.  
▼M3 
100) La unidad instalada en el vehículo deberá ser 
capaz de registrar y almacenar en su memoria 
los siguientes datos, correspondientes a los últi­
mos veinte acoplamientos logrados de dispositi­
vos GNSS externos (si se producen varios aco­
plamientos dentro de un día civil, solo se alma­
cenarán el primero y el último del día).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 43  
Deberán almacenarse los datos siguientes para 
cada uno de estos acoplamientos:  
— datos de identificación del dispositivo GNSS 
externo:  
— número de serie,  
— número de homologación,  
— datos de acoplamiento del dispositivo GNSS 
externo:  
— fecha de acoplamiento.  
3.12.2  Claves y certificados  
101) El aparato de control deberá ser capaz de alma­
cenar una serie de claves y certificados criptográ­
ficos, según lo especificado en el apéndice 11, 
parte A y parte B.  
3.12.3  Datos de inserción y extracción de la tarjeta de conductor o de la 
tarjeta de taller  
102) Por cada ciclo de inserción y extracción de una 
tarjeta de conductor o una tarjeta de taller, el 
aparato de control deberá registrar y almacenar 
en su memoria de datos:  
— el nombre y apellidos del titular de la tarjeta, 
tal y como constan en la tarjeta,  
— el número de la tarjeta, el Estado miembro 
que la ha expedido y su fecha de expiración, 
tal y como constan en la tarjeta,  
— la generación de la tarjeta,  
— la fecha y hora de inserción,  
— la lectura del cuentakilómetros del vehículo 
en el momento de insertar la tarjeta,  
— la ranura donde se inserta la tarjeta,  
— la fecha y hora de extracción,  
— la lectura del cuentakilómetros del vehículo 
en el momento de extraer la tarjeta,  
— la información siguiente acerca del vehículo 
anterior que utilizara el conductor, tal y como 
consta en la tarjeta:  
— VRN y Estado miembro donde se matri­
culó el vehículo,  
— generación de la VU (si está disponible),  
— fecha y hora de extracción de la tarjeta,  
— una bandera que indique si, en el momento 
de insertar la tarjeta, el titular ha introducido 
manualmente alguna actividad.  
103) La memoria de datos deberá ser capaz de man­
tener estos datos almacenados durante al menos 
365 días.  
104) Cuando se agote la capacidad de almacena­
miento, los datos más antiguos se sustituirán 
por otros nuevos.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 44  
3.12.4  Datos sobre la actividad del conductor  
105) Cada vez que cambie la actividad del conductor 
o del segundo conductor, o cada vez que cambie 
el régimen de conducción, o cada vez que se 
inserte o extraiga una tarjeta de conductor o 
una tarjeta de taller, el aparato de control deberá 
registrar y almacenar en su memoria de datos:  
— el régimen de conducción (EN EQUIPO, EN 
SOLITARIO),  
— la ranura (CONDUCTOR, SEGUNDO CON­
DUCTOR),  
— el estado de la tarjeta en la ranura que co­
rresponda (INSERTADA, NO INSER­
TADA),  
— la actividad (CONDUCCIÓN, DISPONIBILI­
DAD, TRABAJO, PAUSA/DESCANSO),  
— la fecha y hora del cambio.  
INSERTADA significa que se ha insertado en la 
ranura una tarjeta de conductor o una tarjeta de 
taller válidas. NO INSERTADA significa lo con­
trario, es decir, que no se ha insertado en la 
ranura una tarjeta de conductor o una tarjeta de 
taller válidas (por ejemplo, se inserta una tarjeta 
de empresa o no se inserta tarjeta).  
Los datos de actividad que introduzca manual­
mente el conductor no se registran en la memoria 
de datos.  
106) La memoria de datos deberá ser capaz de man­
tener estos datos almacenados durante al menos 
365 días.  
107) Cuando se agote la capacidad de almacena­
miento, los datos más antiguos se sustituirán 
por otros nuevos.  
▼M1 
3.12.5  Lugares y posiciones donde comienzan o terminan los períodos de 
trabajo diarios y/o donde se alcanzan las tres horas de tiempo de 
conducción acumulado  
108) El aparato de control deberá registrar y almacenar 
en su memoria de datos:  
— los lugares y las posiciones en que el conduc­
tor y/o el segundo conductor comienzan su 
período de trabajo diario;  
— las posiciones en que el tiempo de conduc­
ción acumulado llega a un múltiplo de tres 
horas;  
— los lugares y las posiciones en que el conduc­
tor y/o el segundo conductor finalizan su pe­
ríodo de trabajo diario.  
▼B 
109) Cuando la posición del vehículo no esté disponi­
ble a partir del receptor GNSS en esos momen­
tos, el aparato de control utilizará la posición más 
reciente disponible, y la fecha y hora asociadas.  
110) Junto con cada lugar y posición, el aparato de 
control deberá registrar y almacenar en su memo­
ria de datos:  ▼B
02016R0799 — ES — 21.08.2023 — 003.001 — 45  
— el número de la tarjeta de conductor o de 
segundo conductor y el Estado miembro 
que haya expedido la tarjeta,  
▼B 
— la generación de la tarjeta,  
— la fecha y hora de la entrada,  
▼M1 
— el tipo de entrada (comienzo, final o tres ho­
ras de tiempo de conducción acumulado),  
▼B 
— la exactitud, la fecha y la hora del GNSS, si 
procede,  
— la lectura del cuentakilómetros del vehículo ,  
— un indicador que señale si la posición ha sido 
autenticada.  
▼M3 
110 bis)  Con respecto a los lugares donde comienzan o 
terminan los períodos de trabajo diarios introdu­
cidos durante el procedimiento de introducción 
manual en el momento de insertar la tarjeta de 
conformidad con el requisito 61, se almacenarán 
la lectura actual del cuentakilómetros y la posi­
ción del vehículo.  
▼M1 
111) La memoria de datos deberá ser capaz de man­
tener almacenados durante al menos 365 días los 
lugares y posiciones en que comienzan o finali­
zan los períodos de trabajo diarios y/o se alcan­
zan las tres horas de tiempo de conducción 
acumulado.  
▼B 
112) Cuando se agote la capacidad de almacena­
miento, los datos más antiguos se sustituirán 
por otros nuevos.  
3.12.6  Datos del cuentakilómetros  
113) Cada día civil a medianoche, el aparato de con­
trol deberá registrar en su memoria la lectura del 
cuentakilómetros del vehículo y la fecha 
correspondiente.  
114) La memoria de datos deberá ser capaz de alma­
cenar las lecturas de los cuentakilómetros a me­
dianoche durante al menos 365 días civiles.  
115) Cuando se agote la capacidad de almacena­
miento, los datos más antiguos se sustituirán 
por otros nuevos.  
3.12.7  Datos pormenorizados sobre la velocidad  
▼M1 
116) Para cada segundo de al menos las últimas 24 
horas en que haya estado en movimiento el ve­
hículo, el aparato de control deberá registrar y 
almacenar en su memoria de datos la velocidad 
instantánea del vehículo y la fecha y hora 
correspondientes.  
▼B 
3.12.8  Datos sobre incidentes  
A efectos del presente subapartado, la hora se registrará con u na 
resolución de un segundo.  
117) El aparato de control deberá registrar y almacenar 
en su memoria los datos siguientes para cada 
incidente detectado, con arreglo a las reglas de 
almacenamiento descritas a continuación:  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 46  
Incidente  Reglas de almacenamiento  Datos que hay que registrar en cada incidente  
Inserción de una tarjeta no 
válida  — los diez incidentes más recientes.  — fecha y hora del incidente, 
— tipo de tarjeta(s), número, Estado miem­
bro emisor y generación de la tarjeta que 
creó el incidente, 
— número de incidentes similares ocurridos 
ese día.  
Conflicto de tarjetas  — los diez incidentes más recientes.  — fecha y hora de comienzo del incidente, 
— fecha y hora de finalización del inci­
dente, 
— tipo de tarjeta(s), número, Estado miem­
bro emisor y generación de las dos tar­
jetas que crearon el conflicto.  
Conducción sin tarjeta 
adecuada  — el incidente de mayor duración ocurrido 
cada uno de los últimos diez días en 
que se hayan producido incidentes de 
este tipo, 
— los cinco incidentes de mayor duración 
ocurridos en los últimos 365 días.  — fecha y hora de comienzo del incidente, 
— fecha y hora de finalización del inci­
dente, 
— tipo de tarjeta(s), número, Estado miem­
bro emisor y generación de cualquier tar­
jeta insertada al comenzar o al terminar 
el incidente, 
— número de incidentes similares ocurridos 
ese día.  
Inserción de tarjeta du­
rante la conducción  — el último incidente ocurrido en cada 
uno de los diez últimos días en que se 
hayan producido incidentes de ese tipo,  — fecha y hora del incidente, 
— tipo de tarjeta(s), número, Estado miem­
bro emisor y generación, 
— número de incidentes similares ocurridos 
ese día.  
▼M3 
Error al cerrar la última 
sesión de la tarjeta  — los diez incidentes más recientes,  — fecha y hora de inserción de la tarjeta, 
— tipo, número, Estado miembro emisor y 
generación de la tarjeta, 
— datos de la última sesión según la lectura 
de la tarjeta: 
— fecha y hora de inserción de la tarjeta  
▼B 
Exceso de velocidad (1)  — el incidente más grave en cada uno de 
los diez últimos días en que se hayan 
producido incidentes de este tipo (es 
decir, el que haya ocurrido con la ve­
locidad media más alta), 
— los cinco incidentes más graves ocurri­
dos en los últimos 365 días, 
— el primer incidente que haya ocurrido 
después del último calibrado.  — fecha y hora de comienzo del incidente, 
— fecha y hora de finalización del inci­
dente, 
— velocidad máxima medida durante el in­
cidente, 
— media aritmética de la velocidad medida 
durante el incidente, 
— tipo de tarjeta, número, Estado miembro 
emisor y generación de la tarjeta del con­
ductor (si procede), 
— número de incidentes similares ocurridos 
ese día.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 47  
Incidente  Reglas de almacenamiento  Datos que hay que registrar en cada incidente  
Interrupción del suminis­
tro eléctrico (2)  — el incidente de mayor duración ocurrido 
cada uno de los últimos diez días en 
que se hayan producido incidentes de 
este tipo, 
— los cinco incidentes de mayor duración 
ocurridos en los últimos 365 días.  — fecha y hora de comienzo del incidente, 
— fecha y hora de finalización del inci­
dente, 
— tipo de tarjeta(s), número, Estado miem­
bro emisor y generación de cualquier tar­
jeta insertada al comenzar o al terminar 
el incidente, 
— número de incidentes similares ocurridos 
ese día.  
Error de comunicación 
con el dispositivo de co­
municación a distancia  — el incidente de mayor duración ocurrido 
cada uno de los últimos diez días en 
que se hayan producido incidentes de 
este tipo, 
— los cinco incidentes de mayor duración 
ocurridos en los últimos 365 días.  — fecha y hora de comienzo del incidente, 
— fecha y hora de finalización del inci­
dente, 
— tipo de tarjeta(s), número, Estado miem­
bro emisor y generación de cualquier tar­
jeta insertada al comenzar o al terminar 
el incidente, 
— número de incidentes similares ocurridos 
ese día.  
Ausencia de información 
sobre la posición proce­
dente del receptor GNSS  — el incidente de mayor duración ocurrido 
cada uno de los últimos diez días en 
que se hayan producido incidentes de 
este tipo, 
— los cinco incidentes de mayor duración 
ocurridos en los últimos 365 días.  — fecha y hora de comienzo del incidente, 
— fecha y hora de finalización del inci­
dente, 
— tipo de tarjeta(s), número, Estado miem­
bro emisor y generación de cualquier tar­
jeta insertada al comenzar o al terminar 
el incidente, 
— número de incidentes similares ocurridos 
ese día.  
▼M1 
Error de comunicación 
con el dispositivo GNSS 
externo  — el incidente de mayor duración ocurrido 
cada uno de los últimos diez días, 
— los cinco incidentes de mayor duración 
ocurridos en los últimos 365 días.  — fecha y hora de comienzo del incidente, 
— fecha y hora de finalización del inci­
dente, 
— tipo de tarjeta(s), número, Estado miem­
bro emisor y generación de cualquier tar­
jeta insertada al comenzar o al terminar 
el incidente, 
— número de incidentes similares ocurridos 
ese día.  
▼B 
Error en datos de movi­
miento  — el incidente de mayor duración ocurrido 
cada uno de los últimos diez días en 
que se hayan producido incidentes de 
este tipo, 
— los cinco incidentes de mayor duración 
ocurridos en los últimos 365 días.  — fecha y hora de comienzo del incidente, 
— fecha y hora de finalización del inci­
dente, 
— tipo de tarjeta(s), número, Estado miem­
bro emisor y generación de cualquier tar­
jeta insertada al comenzar o al terminar 
el incidente, 
— número de incidentes similares ocurridos 
ese día.  
Conflicto de movimiento 
del vehículo  — el incidente de mayor duración ocurrido 
cada uno de los últimos diez días en 
que se hayan producido incidentes de 
este tipo, 
— los cinco incidentes de mayor duración 
ocurridos en los últimos 365 días.  — fecha y hora de comienzo del incidente, 
— fecha y hora de finalización del inci­
dente, 
— tipo de tarjeta(s), número, Estado miem­
bro emisor y generación de cualquier tar­
jeta insertada al comenzar o al terminar 
el incidente, 
— número de incidentes similares ocurridos 
ese día.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 48  
Incidente  Reglas de almacenamiento  Datos que hay que registrar en cada incidente  
Intento de violación de la 
seguridad  — los diez incidentes más recientes de 
cada tipo.  — fecha y hora de comienzo del incidente, 
— fecha y hora en que terminó el incidente 
(si es pertinente), 
— tipo de tarjeta(s), número, Estado miem­
bro emisor y generación de cualquier tar­
jeta insertada al comenzar o al terminar 
el incidente, 
— tipo de incidente.  
▼M1 
Conflicto temporal  — el incidente más grave ocurrido cada 
uno de los últimos diez días (es decir, 
los que presentan mayor diferencia en­
tre la fecha y hora del aparato de con­
trol y la fecha y hora del GNSS), 
— los cinco incidentes más graves ocurri­
dos en los últimos 365 días,  — fecha y hora del aparato de control, 
— fecha y hora del GNSS, 
— tipo de tarjeta(s), número, Estado miem­
bro emisor y generación de cualquier tar­
jeta insertada al comenzar o al terminar 
el incidente, 
— número de incidentes similares ocurridos 
ese día.  
▼M3 
Anomalía del GNSS  — los incidentes de más duración ocurri­
dos en cada uno de los diez últimos 
días en que se hayan producido inci­
dentes de ese tipo, 
— los cinco incidentes de mayor duración 
ocurridos en los últimos trescientos se­
senta y cinco días,  — fecha y hora en que comenzó el inci­
dente, 
— fecha y hora en que terminó el incidente, 
— tipo, número y Estado miembro emisor 
de la tarjeta, y generación de cualquier 
tarjeta que se haya insertado al comenzar 
o al terminar el incidente, 
— número de incidentes similares ocurridos 
ese día.  
▼B 
(1) El aparato de control deberá registrar y alma­
cenar también en su memoria de datos:  
— la fecha y la hora del último CONTROL 
DEL EXCESO DE VELOCIDAD,  
— la fecha y la hora del primer exceso de 
velocidad ocurrido tras este CONTROL 
DEL EXCESO DE VELOCIDAD,  
— el número de incidentes de exceso de 
velocidad ocurridos después del último 
CONTROL DEL EXCESO DE VELO­
CIDAD.  
(2) Estos datos solo podrán registrarse al reco­
nectar la alimentación eléctrica. Las horas se 
determinarán con una precisión de un 
minuto.  
3.12.9  Datos sobre fallos  
A efectos del presente subapartado, la hora se registrará con u na 
resolución de un segundo.  
118) El aparato de control intentará registrar y alma­
cenar en su memoria los datos siguientes para 
cada fallo detectado, con arreglo a las reglas de 
almacenamiento descritas a continuación:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 49  
Fallo  Reglas de almacenamiento  Datos que hay que registrar en cada fallo  
Fallo de la tarjeta  — los diez fallos más recientes de la tar­
jeta de conductor.  — fecha y hora en que comenzó el fallo, 
— fecha y hora en que terminó el fallo, 
— tipo de tarjeta(s), número, Estado miem­
bro emisor y generación.  
Fallos del aparato de con­
trol — los diez fallos más recientes de cada 
tipo, 
— el primer fallo ocurrido después del 
último calibrado.  — fecha y hora en que comenzó el fallo, 
— fecha y hora en que terminó el fallo, 
— tipo de fallo, 
— tipo de tarjeta(s), número, Estado miem­
bro emisor y generación de cualquier 
tarjeta insertada al comenzar o al termi­
nar el fallo.  
3.12.10  Datos de calibrado  
119) El aparato de control deberá registrar y almacenar 
en su memoria los datos correspondientes a:  
— los parámetros de calibrado conocidos en el 
momento de la activación,  
— su primer calibrado después de la activación,  
— su primer calibrado en el vehículo actual (se­
gún conste en el VIN),  
— los veinte calibrados más recientes (si el apa­
rato se ha calibrado más de una vez en un 
mismo día civil, solo se almacenarán los da­
tos correspondientes al primero y al último 
calibrados del día).  
120) Cada vez que se calibre el aparato de control, se 
registrarán los datos siguientes:  
— propósito del calibrado (activación, primera 
instalación, instalación, control periódico),  
— nombre y dirección del taller,  
— número de la tarjeta de taller, Estado miem­
bro que haya expedido la tarjeta y fecha de 
expiración de la tarjeta,  
— identificación del vehículo,  
— parámetros que se actualizan o confirman: w, 
k, l, tamaño de los neumáticos, valor de 
ajuste del dispositivo limitador de la veloci­
dad, cuentakilómetros (lectura anterior y 
nueva lectura), fecha y hora (valor anterior 
y nuevo valor),  
— los tipos y los identificadores de todos los 
precintos existentes,  
▼M3 
— número de serie del sensor de movimiento, 
del dispositivo GNSS externo (en su caso) 
y del dispositivo de comunicación a distancia 
externo (en su caso),  
— el tipo de carga por defecto asociado al vehí­
culo (carga de mercancías o de pasajeros),  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 50  
— el país en el que se ha realizado el calibrado, 
así como la fecha y la hora en las que el 
receptor GNSS proporcionó la posición utili­
zada para determinar dicho país.  
▼B 
121) Además, el aparato de control deberá registrar y 
almacenar en su memoria de datos su capacidad 
para utilizar tarjetas de tacógrafo de primera ge­
neración (aún activada o no).  
122) El sensor de movimiento deberá registrar y alma­
cenar en su memoria los siguientes datos sobre la 
instalación del sensor de movimiento:  
— primer emparejamiento con una VU (fecha, 
hora, número de homologación de la VU, 
número de serie de la VU),  
— último emparejamiento con una VU (fecha, 
hora, número de homologación de la VU, 
número de serie de la VU).  
123) El dispositivo GNSS externo deberá registrar y 
almacenar en su memoria los siguientes datos 
sobre la instalación del dispositivo GNSS 
externo:  
— primer acoplamiento con una VU (fecha, 
hora, número de homologación de la VU, 
número de serie de la VU),  
— último acoplamiento con una VU (fecha, 
hora, número de homologación de la VU, 
número de serie de la VU).  
3.12.11  Datos de ajuste de la hora  
124) El aparato de control deberá registrar y almacenar 
en su memoria los datos correspondientes a los 
ajustes de hora que se hayan realizado en el 
modo de calibrado y fuera del marco de un cali­
brado regular (def. f)):  
— la última ocasión en que se ajustara la hora,  
— los cinco casos en que el ajuste fuera mayor.  
125) Cada vez que se ajuste la hora, se registrarán los 
datos siguientes:  
— fecha y hora, valor anterior,  
— fecha y hora, nuevo valor,  
— nombre y dirección del taller,  
— número de la tarjeta de taller, Estado miem­
bro que haya expedido la tarjeta, generación 
de la tarjeta y fecha de expiración de la 
tarjeta.  
3.12.12  Datos sobre actividades de control  
126) El aparato de control deberá registrar y almacenar 
en su memoria los siguientes datos correspon­
dientes a las veinte actividades de control más 
recientes:  
— fecha y hora del control,  
— número de la tarjeta de control, Estado miem­
bro que haya expedido la tarjeta y generación 
de la tarjeta,  
— tipo de control (visualización y/o impresión 
y/o transferencia de los datos de la VU y/o 
transferencia de los datos de la tarjeta y/o 
control del calibrado en carretera).  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 51  
127) En caso de transferencia, también habrá que re­
gistrar las fechas correspondientes a los días 
transferidos más antiguos y más recientes.  
3.12.13  Datos sobre los bloqueos introducidos por las empresas  
128) El aparato de control deberá registrar y almacenar 
en su memoria los siguientes datos correspon­
dientes a los 255 últimos bloqueos introducidos 
por una empresa:  
— fecha y hora de activación del bloqueo,  
— fecha y hora de desactivación del bloqueo,  
— número de la tarjeta de empresa, Estado 
miembro que haya expedido la tarjeta y ge­
neración de la tarjeta,  
— nombre y dirección de la empresa.  
Los datos previamente bloqueados mediante un 
bloqueo eliminado de la memoria debido al lí­
mite antes mencionado se considerarán desblo­
queados.  
3.12.14  Datos sobre actividades de transferencia  
129) El aparato de control deberá registrar y almacenar 
en su memoria los siguientes datos correspon­
dientes a la última transferencia de datos de la 
memoria a medios externos, estando en el modo 
de empresa o en el modo de calibrado:  
— fecha y hora de la transferencia,  
— número de la tarjeta de empresa o de taller, 
Estado miembro que haya expedido la tarjeta 
y generación de la tarjeta,  
— nombre de la empresa o del taller.  
3.12.15  Datos sobre condiciones específicas  
130) El aparato de control deberá registrar en su me­
moria los siguientes datos correspondientes a 
condiciones específicas:  
— fecha y hora de la entrada,  
— tipo de condición específica.  
131) La memoria deberá ser capaz de mantener estos 
datos almacenados durante al menos 365 días 
(suponiendo que, como media, cada día se abra 
y se cierre una condición). Cuando se agote la 
capacidad de almacenamiento, los datos más an­
tiguos se sustituirán por otros nuevos.  
3.12.16  Datos de la tarjeta de tacógrafo  
132) El aparato de control deberá ser capaz de alma­
cenar los siguientes datos relativos a las diferen­
tes tarjetas de tacógrafo que se han utilizado en la 
VU: 
— número de la tarjeta de tacógrafo y su nú­
mero de serie,  
— fabricante de la tarjeta de tacógrafo,  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 52  
— tipo de tarjeta de tacógrafo,  
— versión de la tarjeta de tacógrafo.  
133) El aparato de control deberá ser capaz de alma­
cenar al menos 88 de estos registros.  
▼M3 
3.12.17  Cruces de fronteras  
133 bis) El aparato de control registrará y almacenará en 
su memoria de datos la siguiente información 
sobre los cruces de fronteras:  
— el país del que sale el vehículo,  
— el país en el que entra el vehículo,  
— la posición por la que el vehículo ha cruzado 
la frontera.  
133 ter) Junto con los países y la posición, el aparato de 
control registrará y almacenará en su memoria de 
datos:  
— el número de la tarjeta de conductor o de 
segundo conductor y el Estado miembro 
que haya expedido la tarjeta,  
— la generación de la tarjeta,  
— la exactitud del GNSS, la fecha y la hora 
correspondientes,  
— un indicador que señale si la posición ha sido 
autenticada,  
— el valor del cuentakilómetros del vehículo en 
el momento de detectarse el cruce de 
fronteras.  
133 quater ) La memoria de datos deberá ser capaz de man­
tener los datos de cruces de fronteras durante al 
menos 365 días.  
133 quinquies ) Cuando se agote la capacidad de almacena­
miento, los datos más antiguos se sustituirán 
por otros nuevos.  
3.12.18  Operaciones de carga/descarga  
133 sexies ) El aparato de control registrará y almacenará en 
su memoria de datos la siguiente información 
sobre las operaciones de carga y descarga del 
vehículo:  
— el tipo de operación (carga, descarga o carga/ 
descarga simultáneas),  
— la posición donde se ha producido la opera­
ción de carga/descarga.  
133 septies ) Cuando la posición del vehículo no esté disponi­
ble a partir del receptor GNSS en el momento de 
la operación de carga/descarga, el aparato de con­
trol utilizará la última posición disponible, así 
como la fecha y la hora correspondientes.  
133 octies ) Junto con el tipo de operación y la posición, el 
aparato de control registrará y almacenará en su 
memoria de datos:  
— el número de la tarjeta de conductor o de 
segundo conductor y el Estado miembro 
que haya expedido la tarjeta,  
— la generación de la tarjeta,  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 53  
— la fecha y hora de la operación de carga/des­
carga,  
— la exactitud, la fecha y la hora del GNSS 
correspondientes, si procede,  
— un indicador que señale si la posición ha sido 
autenticada,  
— el valor del cuentakilómetros del vehículo.  
133 nonies ) La memoria de datos deberá ser capaz de alma­
cenar las operaciones de carga/descarga durante 
al menos 365 días civiles.  
133 decies ) Cuando se agote la capacidad de almacena­
miento, los datos más antiguos se sustituirán 
por otros nuevos.  
3.12.19  Mapa digital  
133 undecies ) Para registrar la posición del vehículo cuando 
cruce la frontera de un país, el aparato de control 
almacenará en su memoria de datos un mapa 
digital.  
133 duodecies ) La Comisión Europea dará acceso a los mapas 
digitales permitidos como base de la función de 
seguimiento de los cruces de fronteras del apa­
rato de control, para su descarga, en diversos 
formatos, desde un sitio web protegido especí­
fico. 
133 terdecies ) Para cada uno de estos mapas estarán disponibles 
en el sitio web un identificador de la versión y un 
valor de comprobación aleatoria.  
133 quaterdecies ) Los mapas tendrán las siguientes características:  
— un nivel de definición correspondiente al ni­
vel NUTS 0, de acuerdo con la nomenclatura 
de unidades territoriales estadísticas,  
— una escala de 1:1 millón.  
133 quindecies ) Los fabricantes de tacógrafos deberán seleccionar 
un mapa en el sitio web y descargarlo de forma 
protegida.  
133 sexdecies ) Los fabricantes de tacógrafos utilizarán un mapa 
descargado desde el sitio web únicamente des­
pués de haber verificado su integridad utilizando 
el valor de comprobación aleatoria del mapa.  
133 septdecies ) El fabricante del aparato de control importará en 
este el mapa seleccionado, en un formato ade­
cuado y manteniendo intacta la semántica del 
mapa importado.  
133 octodecies ) El fabricante almacenará también el identificador 
de la versión del mapa utilizado en el aparato de 
control.  
133 novodecies ) Deberá ser posible actualizar el mapa digital al­
macenado o sustituirlo por otro nuevo puesto a 
disposición por la Comisión Europea.  
133 vicies ) Las actualizaciones de los mapas digitales se re­
alizarán utilizando los mecanismos de actualiza­
ción del  software  establecidos por el fabricante, 
en aplicación de los requisitos 226  quinquies  
y 226  sexies , de manera que el aparato de control 
pueda verificar la autenticidad e integridad de un 
nuevo mapa importado, antes de almacenarlo y 
de sustituir al anterior.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 54  
133 unvicies ) Los fabricantes de tacógrafos podrán añadir in­
formación adicional al mapa básico del requisito 
133 quaterdecies ) con fines distintos del registro 
de los cruces de fronteras, por ejemplo los límites 
de las regiones de la UE, a condición de no 
alterar la semántica del mapa básico.  
▼B 
3.13 Lectura de las tarjetas de tacógrafo  
134) El aparato de control deberá ser capaz de leer las 
tarjetas de tacógrafo de primera y segunda gene­
ración para obtener, cuando proceda, los datos 
necesarios para:  
— identificar el tipo de tarjeta, al titular de la 
tarjeta, el anterior vehículo empleado, la fe­
cha y hora en que se retirara la tarjeta por 
última vez y la actividad seleccionada 
entonces,  
— comprobar que la última sesión de la tarjeta 
se cerró correctamente,  
▼M3 
— calcular el tiempo de conducción continua del 
conductor, su tiempo de descanso acumulado 
y sus tiempos de conducción acumulados du­
rante la semana anterior y la actual,  
▼B 
— imprimir, previa solicitud, los datos registra­
dos en una tarjeta de conductor,  
— transferir a medios externos la información 
contenida en una tarjeta de conductor.  
Este requisito solo se aplica a las tarjetas de ta­
cógrafo de primera generación, siempre que su 
utilización no haya sido suprimida por un taller.  
135) En caso de producirse un error de lectura, el 
aparato de control intentará ejecutar de nuevo el 
mismo comando de lectura. Si no lo consigue 
después de tres intentos, declarará la tarjeta de­
fectuosa y no válida.  
▼M3 
135 bis) La estructura de la aplicación «TACHO_G2» de­
pende de la versión. Las tarjetas de la versión 2 
contienen archivos elementales adicionales a los 
de las tarjetas de la versión 1, en particular:  
— En las tarjetas de conductor y de taller:  
— El archivo elemental Places_Authentica­
tion contendrá el estado de autenticación 
de las posiciones del vehículo almacena­
das en el archivo elemental Places. Se 
almacenará un sello de tiempo con cada 
estado de autenticación, que se correspon­
derá exactamente con la fecha y la hora 
de la entrada almacenada con la posición 
correspondiente en el archivo elemental 
Places.  
— El archivo elemental GNSS_Places_Aut­
hentication contendrá el estado de auten­
ticación de las posiciones del vehículo 
almacenadas en el archivo elemental 
GNSS_Places. Se almacenará un sello 
de tiempo con cada estado de autentica­
ción, que se corresponderá exactamente 
con la fecha y la hora de la entrada alma­
cenada con la posición correspondiente en 
el archivo elemental Places.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 55  
— Los archivos elementales Border_Crossings, 
Load_Unload_Operations y 
Load_Type_Entries contendrán datos relati­
vos a los cruces de fronteras, las operacio­
nes de carga/descarga y los tipos de carga.  
— En las tarjetas de taller:  
— El archivo elemental Calibration_Add_Data 
contendrá datos de calibrado adicionales a 
los almacenados en el archivo elemental 
Calibration. El valor antiguo de fecha y 
hora y el número de identificación del ve­
hículo se almacenarán con cada registro 
adicional de datos de calibrado, que coinci­
dirá exactamente con el antiguo valor de la 
fecha y la hora y el número de identifica­
ción del vehículo almacenados con los da­
tos de calibrado correspondientes en el ar­
chivo elemental Calibration.  
— En todas las tarjetas de tacógrafo:  
— El archivo elemental VU_Configuration 
contendrá los ajustes específicos del tacó­
grafo del titular de la tarjeta.  
La unidad instalada en el vehículo ignorará todo 
estado de autenticación que se encuentre en los 
archivos elementales Places_Authentication o 
GNSS_Places_Authentication cuando no se en­
cuentre ninguna posición del vehículo con el 
mismo sello de tiempo en los archivos elementa­
les Places o GNSS_Places.  
La unidad instalada en el vehículo ignorará el 
archivo elemental VU_Configuration en todas 
las tarjetas mientras no se hayan facilitado nor­
mas específicas sobre el uso de ese archivo ele­
mental. Dichas normas se establecerán mediante 
una modificación del anexo I C, que incluirá la 
modificación o la supresión del presente párrafo.  
▼B 
3.14 Registro y almacenamiento de datos en las tarjetas de tacógrafo  
3.14.1  Registro y almacenamiento de datos en las tarjetas de tacógrafo de 
primera generación  
136) Siempre que un taller no haya suprimido el uso 
de las tarjetas de tacógrafo de primera genera­
ción, el aparato de control deberá registrar y al­
macenar datos exactamente de la misma manera 
que lo haría un aparato de control de primera 
generación.  
137) Nada más insertada la tarjeta de conductor o de 
taller, el aparato de control deberá configurar los 
«datos de la sesión» en dicha tarjeta.  
138) El aparato de control deberá actualizar los datos 
almacenados en las tarjetas de conductor, de ta­
ller, de empresa o de control, si son válidas. Para 
ello, escribirá en la tarjeta todos los datos nece­
sarios del titular correspondientes al período en 
que dicha tarjeta esté insertada. En el capítulo 4 
se especifican los datos almacenados en cada tipo 
de tarjeta.  
139) El aparato de control deberá actualizar los datos 
sobre la actividad del conductor y sobre los lu­
gares (según se especifica en los puntos 4.5.3.1.9 
y 4.5.3.1.11). Estos datos, almacenados en las 
tarjetas de conductor o en las tarjetas de taller, 
se sustituirán por los datos introducidos manual­
mente por el titular de la tarjeta.  
▼M3 
140) Los incidentes y fallos no definidos para los apa­
ratos de control de primera generación no se al­
macenarán en las tarjetas de conductor ni de ta­
ller de primera generación.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 56  
141) Los datos de las tarjetas de tacógrafo se actuali­
zarán de manera que, cuando sea necesario y 
teniendo en cuenta la capacidad real de almace­
namiento de la tarjeta, los datos más recientes 
sustituyan a los más antiguos.  
142) En caso de producirse un error de escritura, el 
aparato de control intentará ejecutar de nuevo el 
mismo comando de escritura. Si no lo consigue 
después de tres intentos, declarará la tarjeta de­
fectuosa y no válida.  
▼M3 
143) Antes de liberar una tarjeta de conductor o de 
taller, y después de haber almacenado en ella 
todos los datos pertinentes, el aparato de control 
deberá reiniciar los «datos de la sesión».  
▼B 
3.14.2  Registro y almacenamiento de datos en las tarjetas de tacógrafo de 
segunda generación  
144) Las tarjetas de tacógrafo de segunda generación 
deberán incluir dos aplicaciones de tarjeta dife­
rentes, la primero de las cuales será exactamente 
la misma que la aplicación TACHO de las tarje­
tas de tacógrafo de primera generación, y la se­
gunda la aplicación TACHO_G2, que se especi­
fica en el capítulo 4 y el apéndice 2.  
▼M3 
La estructura de la aplicación «TACHO_G2» de­
pende de la versión. Las tarjetas de la versión 2 
contienen archivos elementales adicionales a los 
de las tarjetas de la versión 1.  
▼B 
145) Nada más insertada la tarjeta de conductor o de 
taller, el aparato de control deberá configurar los 
«datos de la sesión» en dicha tarjeta.  
146) El aparato de control deberá actualizar los datos 
almacenados en las dos aplicaciones de las tarje­
tas de conductor, de taller, de empresa o de con­
trol, si son válidas. Para ello, escribirá en la tar­
jeta todos los datos necesarios del titular corres­
pondientes al período en que dicha tarjeta esté 
insertada. En el capítulo 4 se especifican los da­
tos almacenados en cada tipo de tarjeta.  
147) El aparato de control deberá actualizar los datos 
sobre los lugares y posiciones de actividad del 
conductor (según se especifica en los puntos 
4.5.3.1.9, 4.5.3.1.11, 4.5.3.2.9 y 4.5.3.2.11). Es­
tos datos, almacenados en las tarjetas de conduc­
tor o en las tarjetas de taller válidas, se sustituirán 
por los datos de lugares de actividad introducidos 
manualmente por el titular de la tarjeta.  
▼M3 
147 bis) Al insertar una tarjeta de conductor o de taller, el 
aparato de control almacenará en ella el tipo de 
carga por defecto del vehículo.  
147 ter) Al insertar una tarjeta de conductor o de taller, y 
tras el procedimiento de introducción manual, el 
aparato de control comprobará el último lugar de 
comienzo o final del período de trabajo diario 
almacenado en la tarjeta. Este lugar podrá ser 
temporal, como se especifica en el requisito 59. 
Si este lugar está en un país distinto de aquel en 
el que se encuentra actualmente el vehículo, el 
aparato de control almacenará en la tarjeta un 
registro de cruce de fronteras, indicando:  
— el país del que ha salido el conductor: no 
disponible,  
— el país en el que está entrando el conductor: 
el país en el que se encuentra actualmente el 
vehículo,  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 57  
— la fecha y la hora en las que el conductor ha 
cruzado la frontera: la hora de inserción de la 
tarjeta,  
— la posición del conductor cuando se ha cru­
zado la frontera: no disponible,  
— el valor del cuentakilómetros del vehículo: no 
disponible.  
▼B 
148) Los datos de las tarjetas de tacógrafo se actuali­
zarán de manera que, cuando sea necesario y 
teniendo en cuenta la capacidad real de almace­
namiento de la tarjeta, los datos más recientes 
sustituyan a los más antiguos.  
149) En caso de producirse un error de escritura, el 
aparato de control intentará ejecutar de nuevo el 
mismo comando de escritura. Si no lo consigue 
después de tres intentos, declarará la tarjeta de­
fectuosa y no válida.  
150) Antes de liberar una tarjeta de conductor, y des­
pués de haber almacenado en las dos aplicaciones 
de la tarjeta todos los datos pertinentes, el aparato 
de control deberá reiniciar los «datos de la se­
sión».  
▼M3 
150 bis) La unidad instalada en el vehículo ignorará el 
archivo elemental VU_Configuration en todas 
las tarjetas mientras no se hayan facilitado nor­
mas específicas sobre el uso de ese archivo ele­
mental. Dichas normas se establecerán mediante 
una modificación del anexo I C, que incluirá la 
modificación o la supresión del presente párrafo.  
▼B 
3.15 Visualización  
151) La pantalla deberá incluir al menos veinte 
caracteres.  
152) Los caracteres tendrán un tamaño mínimo de 
5 mm de alto y 3,5 mm de ancho.  
153) La pantalla admitirá el uso de los caracteres es­
pecificados en el apéndice 1, Capítulo 4: «Con­
juntos de caracteres». La pantalla podrá utilizar 
glifos simplificados (p.ej.: los caracteres acentua­
dos podrán aparecer sin acento, o las minúsculas 
podrán verse como mayúsculas).  
154) La pantalla deberá tener una iluminación ade­
cuada que no provoque deslumbramiento.  
155) Las indicaciones deberán ser visibles desde fuera 
del aparato de control.  
156) El aparato de control deberá ser capaz de mostrar 
en pantalla:  
— los datos por defecto,  
— los datos relacionados con advertencias,  
— los datos relacionados con el acceso a los 
menús,  
— otros datos que solicite un usuario.  
El aparato de control también podrá mostrar en 
pantalla otras informaciones, siempre que puedan 
distinguirse claramente de las arriba exigidas.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 58  
157) La pantalla del aparato de control deberá utilizar 
los pictogramas o las combinaciones de pictogra­
mas enumerados en el apéndice 3. También po­
drán utilizarse otros pictogramas o combinacio­
nes de pictogramas siempre que puedan distin­
guirse claramente de los exigidos.  
158) La pantalla deberá estar siempre encendida (ON) 
cuando el vehículo esté en movimiento.  
159) El aparato de control podrá incluir una función 
manual o automática que apague (OFF) la panta­
lla cuando el vehículo esté parado.  
El formato de visualización se especifica en el 
apéndice 5.  
3.15.1  Contenido de la pantalla por defecto  
160) Cuando no sea necesario mostrar otra informa­
ción, el aparato de control deberá presentar en 
pantalla, por defecto, los datos siguientes:  
— la hora local (correspondiente a la UTC + 
desfase configurado por el conductor),  
— el modo de funcionamiento,  
— la actividad actual del conductor y la del se­
gundo conductor,  
— información relativa al conductor:  
— si su actividad actual es CONDUCCIÓN, el 
tiempo actual de conducción continua y el 
tiempo actual de descanso acumulado hasta 
ese momento,  
— si su actividad actual no es CONDUCCIÓN, 
la duración actual de su actividad (desde que 
la haya seleccionado) y el tiempo actual de 
descanso acumulado hasta ese momento.  
161) La presentación en pantalla de los datos relativos 
a cada conductor será clara, sencilla e inequí­
voca. Si no fuera posible mostrar en pantalla 
simultáneamente la información relativa al con­
ductor y la relativa al segundo conductor, el apa­
rato de control deberá mostrar por defecto la in­
formación relativa al conductor y ofrecerá al 
usuario la posibilidad de visualizar la informa­
ción relativa al segundo conductor.  
162) Si el ancho de la pantalla no permite visualizar 
por defecto el modo de funcionamiento, el apa­
rato de control mostrará unos instantes el nuevo 
modo de funcionamiento cuando cambie.  
163) El aparato de control mostrará unos instantes el 
nombre del titular de la tarjeta en el momento de 
insertar la tarjeta.  
164) Cuando se abra una condición «FUERA DE ÁM­
BITO» o «TRAYECTO EN TRANSBORDA­
DOR/TREN», el contenido de la pantalla por 
defecto deberá mostrar, con el pictograma corres­
pondiente, que la condición está abierta (se ad­
mite que no aparezca simultáneamente en panta­
lla la actividad actual del conductor).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 59  
3.15.2  Visualización de advertencias  
165) Para las advertencias que muestre en pantalla el 
aparato de control se utilizarán principalmente los 
pictogramas del apéndice 3, completados cuando 
sea necesario por información adicional codifi­
cada en forma numérica. También se podrá aña­
dir una descripción literal de la advertencia en el 
idioma preferido del conductor.  
3.15.3  Acceso mediante menús  
166) El aparato de control ofrecerá los comandos ne­
cesarios a través de una estructura de menús 
adecuada.  
3.15.4  Otras informaciones en pantalla  
167) Se podrán visualizar en pantalla, de manera se­
lectiva y a voluntad, los siguientes datos:  
— la fecha y la hora UTC, junto con el desfase 
horario local,  
▼M3 
— el contenido de cualquiera de los documentos 
impresos enumerados en el requisito 169, con 
los mismos formatos que los propios docu­
mentos impresos,  
▼B 
— el tiempo de conducción continua y el tiempo 
de descanso acumulado del conductor,  
— el tiempo de conducción continua y el tiempo 
de descanso acumulado del segundo conduc­
tor, 
▼M3 
— el tiempo de conducción acumulado del con­
ductor durante la semana anterior y la actual, 
y 
— el tiempo de conducción acumulado del se­
gundo conductor durante la semana anterior y 
la actual.  
▼B 
Datos opcionales:  
— la duración actual de la actividad del segundo 
conductor (desde que la seleccionara),  
▼M3 
— el tiempo de conducción acumulado del con­
ductor durante la semana actual,  
— el tiempo de conducción acumulado del se­
gundo conductor durante el período de tra­
bajo diario actual,  
— el tiempo de conducción acumulado del con­
ductor durante el período de trabajo diario 
actual.  
▼B 
168) El contenido del documento impreso se mostrará 
en pantalla de manera secuencial, línea por línea. 
Si el ancho de la pantalla es menor de 24 carac­
teres, el usuario dispondrá de un medio adecuado 
para visualizar la información completa (varias 
líneas, desplazamiento del texto, …).  
No es necesario que aparezcan en pantalla las 
líneas del documento impreso destinadas a infor­
maciones manuscritas.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 60  
3.16 Impresión  
169) El aparato de control deberá ser capaz de impri­
mir la información almacenada en su memoria o 
en las tarjetas de tacógrafo. Habrá al menos siete 
tipos de documentos de impresión:  
— impresión diaria de las actividades del con­
ductor almacenadas en la tarjeta,  
— impresión diaria de las actividades del con­
ductor almacenadas en la unidad instalada en 
el vehículo,  
— impresión de incidentes y fallos almacenados 
en la tarjeta,  
— impresión de incidentes y fallos almacenados 
en la unidad instalada en el vehículo,  
— impresión de datos técnicos,  
— impresión de excesos de velocidad,  
— historial de los datos de la tarjeta de tacógrafo 
para una determinada VU (véase el 
capítulo 3.12.16).  
Los pormenores relativos al formato y al conte­
nido de estos documentos se especifican en el 
apéndice 4.  
Es posible incluir datos adicionales al final de los 
documentos de impresión.  
El aparato de control también podrá imprimir 
otros documentos, siempre que puedan distin­
guirse claramente de los siete arriba indicados.  
170) La «impresión diaria de las actividades del con­
ductor almacenadas en la tarjeta» y la «impresión 
de incidentes y fallos almacenados en la tarjeta» 
solo estarán disponibles cuando se inserte en el 
aparato de control una tarjeta de conductor o una 
tarjeta de taller. El aparato de control actualizará 
los datos almacenados en la tarjeta correspon­
diente antes de iniciar la impresión.  
171) A fin de obtener la «impresión diaria de las ac­
tividades del conductor almacenadas en la tar­
jeta» o la «impresión de incidentes y fallos alma­
cenados en la tarjeta», el aparato de control de­
berá:  
— seleccionar automáticamente la tarjeta de con­
ductor o la tarjeta de taller, si solo se ha 
insertado una de estas dos tarjetas,  
— o bien ofrecer un comando para seleccionar la 
tarjeta de origen o seleccionar la tarjeta en la 
ranura del conductor, si en el aparato de con­
trol se han insertado las dos tarjetas.  
172) La impresora deberá ser capaz de imprimir 24 
caracteres por línea.  
173) Los caracteres tendrán un tamaño mínimo de 2,1 
mm de alto y 1,5 mm de ancho.  
174) La impresora admitirá el uso de los caracteres 
especificados en el apéndice 1, capítulo 4: «Con­
juntos de caracteres».  
175) Las impresoras estarán diseñadas de tal forma 
que faciliten los documentos de impresión arriba 
mencionados con la definición necesaria para evi­
tar ambigüedades en la lectura.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 61  
176) Los documentos de impresión conservarán sus 
dimensiones y registros en las condiciones nor­
males de humedad (10-90 %) y temperatura.  
177) El tipo de papel homologado utilizado por el 
aparato de control llevará la marca de homologa­
ción pertinente y la indicación del/de los tipo(s) 
de aparato de control con que se puede utilizar.  
178) Si se mantienen las condiciones normales de al­
macenamiento en lo que respecta a intensidad 
luminosa, humedad y temperatura, los documento 
de impresión seguirán siendo claramente legibles 
e identificables durante al menos dos años.  
179) Las impresiones se ajustarán, como mínimo, a las 
especificaciones de ensayo que figuran en el 
apéndice 9.  
180) Además, deberá ser posible incluir en los citados 
documentos inscripciones adicionales hechas a 
mano, tales como la firma del conductor.  
181) En caso de que se acabe el papel durante la 
impresión de un documento, al cargarse un nuevo 
rollo el aparato de control deberá reiniciar la im­
presión desde la primera línea o bien continuar la 
impresión incluyendo una referencia inequívoca a 
la parte ya impresa.  
3.17 Advertencias  
182) El aparato de control deberá avisar al conductor 
cuando detecte algún incidente o fallo.  
183) La advertencia por un incidente de interrupción 
del suministro eléctrico podrá hacerse cuando se 
restablezca el suministro.  
184) El aparato de control deberá avisar al conductor 
quince minutos antes y en el preciso instante en 
que se exceda el límite de tiempo de conducción 
continua permitido.  
185) Las señales de advertencia serán visuales, aunque 
también se podrán instalar señales de tipo acús­
tico. 
186) Las señales de advertencia visuales deberán ser 
perfectamente reconocibles para el usuario, esta­
rán ubicadas dentro del campo de visión del con­
ductor y podrán leerse claramente tanto de día 
como de noche.  
187) Los avisadores luminosos podrán estar incorpo­
rados en el aparato de control o separados de él.  
188) En este último caso, el avisador mostrará una 
«T». 
189) Las señales de advertencia tendrán una duración 
de al menos treinta segundos, a menos que el 
usuario las confirme pulsando una o más teclas 
específicas del aparato de control. Esta primera 
confirmación no hará que desaparezca la indica­
ción en pantalla del motivo de la advertencia 
(véase el párrafo siguiente).  
190) El motivo de la advertencia se indicará en la 
pantalla del aparato de control y permanecerá 
visible hasta que lo confirme el usuario mediante 
una tecla o un comando específico del aparato de 
control.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 62  
191) También podrán instalarse otras señales de adver­
tencia, siempre que el conductor no las confunda 
con las que se han definido anteriormente.  
3.18 Transferencia de datos a medios externos  
192) El aparato de control, a petición del usuario, de­
berá ser capaz de transferir a medios de almace­
namiento externos los datos contenidos en la me­
moria o en una tarjeta de conductor, utilizando 
para ello el conector de calibrado/transferencia. 
El aparato de control actualizará los datos alma­
cenados en la tarjeta correspondiente antes de 
iniciar la transferencia.  
▼M3 
193) Asimismo, y como característica opcional, el apa­
rato de control podrá, en cualquier modo de fun­
cionamiento, transferir datos por cualquier otra 
interfaz a una empresa autentificada a través de 
este canal. En tal caso, dicha transferencia estará 
sujeta a los derechos de acceso a los datos en el 
modo de empresa.  
▼B 
194) La transferencia no deberá alterar ni borrar los 
datos almacenados.  
195) Las características de la interfaz eléctrica del co­
nector de calibrado/transferencia se especifican 
en el apéndice 6.  
196) Los protocolos de transferencia se especifican en 
el apéndice 7.  
▼M3 
196 bis) Las empresas de transporte que utilicen vehículos 
equipados con un aparato de control conforme 
con el presente anexo e incluidos en el ámbito 
de aplicación del Reglamento (CE) n.  o 561/2006 
velarán por que todos los datos se transfieran 
desde la unidad instalada en el vehículo y desde 
las tarjetas de conductor.  
El plazo máximo para transferir los datos perti­
nentes no deberá ser superior a:  
— noventa días en el caso de los datos de la 
unidad instalada en el vehículo;  
— veintiocho días en el caso de los datos de la 
tarjeta de conductor.  
196 ter) Las empresas de transporte conservarán los datos 
transferidos de la unidad instalada en el vehículo 
y de las tarjetas de conductor durante al menos 
los doce meses siguientes al registro.  
▼B 
3.19 Comunicación a distancia para controles de carretera selectivos  
197) Cuando el encendido esté activado, la unidad ins­
talada en el vehículo deberá almacenar cada se­
senta segundos en el dispositivo de comunicación 
a distancia los datos más recientes necesarios a 
efectos de los controles en carretera selectivos. 
Estos datos se cifrarán y firmarán según lo espe­
cificado en el apéndice 11 y el apéndice 14.  
198) Los datos que deben ser controlados a distancia 
estarán disponibles para los lectores de comuni­
cación a distancia mediante comunicaciones ina­
lámbricas, tal como se especifica en el apén­
dice 14.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 63  
199) Los datos necesarios a efectos de los controles en 
carretera selectivos deberán estar relacionados 
con: 
— el intento más reciente de violación de la 
seguridad,  
— la interrupción más larga del suministro eléc­
trico,  
— un fallo del sensor,  
— un error en los datos de movimiento,  
— un conflicto de movimiento del vehículo,  
— la conducción sin tarjeta válida,  
— la inserción de la tarjeta mientras se conduce,  
— los datos de ajuste de la hora,  
— los datos sobre el calibrado, incluidas las fe­
chas de los dos registros de calibrado más 
recientes almacenados,  
— el número de matrícula del vehículo,  
— la velocidad registrada por el tacógrafo,  
▼M3 
— la posición del vehículo,  
— una indicación de si el conductor puede estar 
infringiendo los tiempos de conducción.  
3.20 Intercambios de datos con dispositivos externos adicionales  
200) El aparato de control deberá ir también equipado 
de una interfaz ITS de conformidad con el apén­
dice 13, que permita que los datos registrados o 
producidos por el tacógrafo o por las tarjetas de 
tacógrafo sean utilizados por un dispositivo 
externo.  
En el modo operativo, la transmisión de datos 
personales a través de la interfaz ITS requerirá 
el consentimiento del conductor. Sin embargo, el 
consentimiento del conductor no se aplicará a los 
datos del tacógrafo o de la tarjeta a los que se 
acceda en el modo de control, de empresa o de 
calibrado. Los datos y los derechos de acceso 
funcional para estos modos se especifican en 
los requisitos 12 y 13.  
Se aplicarán los siguientes requisitos a los datos 
de ITS disponibles a través de esa interfaz:  
— Los datos personales solo estarán disponibles 
una vez que el conductor haya dado su con­
sentimiento de manera verificable, aceptando 
que los datos personales puedan salir de la 
red del vehículo.  
En el apéndice 13 se especifica un conjunto 
de datos existentes seleccionados que pueden 
estar disponibles a través de la interfaz ITS, 
así como la clasificación de los datos como 
personales o no personales. Además del con­
junto de datos establecido en el apéndice 13, 
podrán obtenerse otros datos adicionales. El 
fabricante de la VU clasificará esos datos 
como «personales» o «no personales», y el 
consentimiento del conductor será aplicable 
a los datos clasificados como «personales».  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 64  
— En cualquier momento, podrá habilitarse o 
inhabilitarse el consentimiento del conductor 
a través de comandos del menú, siempre que 
esté insertada la tarjeta de conductor.  
— En ninguna circunstancia podrá la presencia 
de la interfaz ITS perturbar ni alterar el co­
rrecto funcionamiento y la seguridad de la 
unidad instalada en el vehículo.  
Podrán coexistir otras interfaces de la unidad ins­
talada en el vehículo, siempre que cumplan ple­
namente los requisitos del apéndice 13 en cuanto 
al consentimiento del conductor. El aparato de 
control deberá ser capaz de comunicar el estado 
del consentimiento del conductor a otras platafor­
mas de la red del vehículo y a dispositivos 
externos.  
En caso de que los datos personales inyectados 
en la red del vehículo sean luego procesados 
fuera de dicha red, no será responsabilidad del 
fabricante del tacógrafo que el tratamiento de los 
datos personales sea conforme con la legislación 
de la Unión aplicable en materia de protección de 
datos.  
La interfaz ITS deberá también permitir la intro­
ducción de datos durante el procedimiento de 
introducción manual de conformidad con el re­
quisito 61, por lo que respecta tanto al conductor 
como al segundo conductor.  
La interfaz ITS también podrá utilizarse para in­
troducir información adicional, en tiempo real, 
como la siguiente:  
— selección de la actividad del conductor, de 
conformidad con el requisito 46,  
— lugares, de conformidad con el requisito 56,  
— condiciones específicas, de conformidad con 
el requisito 62,  
— operaciones de carga/descarga, de conformi­
dad con el requisito 62  bis. 
Esta información también podrá introducirse a 
través de otras interfaces.  
201) La interfaz de conexión en serie especificada en 
el anexo I B del Reglamento (CEE) n.  o 3821/85, 
en su última versión modificada, podrá seguir 
equipando los tacógrafos a efectos de retrocom­
patibilidad. La conexión en serie se clasifica 
como parte de la red del vehículo, de conformi­
dad con el requisito 200.  
▼B 
3.21 Calibrado  
202) La función de calibrado deberá permitir:  
— el emparejamiento automático del sensor de 
movimiento con la VU,  
— el acoplamiento automático del dispositivo 
GNSS externo con la VU, en su caso,  
— la adaptación digital de la constante del apa­
rato de control (k) al coeficiente característico 
del vehículo (w),  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 65  
— el ajuste de la hora actual dentro del período 
de validez de la tarjeta de taller insertada,  
— el ajuste de la lectura actual del cuentakiló­
metros,  
— la actualización de los datos de identificación 
del sensor de movimiento que hay almacena­
dos en la memoria de datos,  
— la actualización, en su caso, de los datos de 
identificación del dispositivo GNSS externo 
que hay almacenados en la memoria de datos,  
— la actualización de los tipos y los identifica­
dores de todos los precintos existentes,  
▼M3 
— la actualización o confirmación de otros pa­
rámetros que conozca el aparato de control: 
identificación del vehículo, w, l, tamaño de 
los neumáticos y valor de ajuste del disposi­
tivo limitador de la velocidad, en su caso, así 
como el tipo de carga por defecto.  
— el almacenamiento automático del país en el 
que se ha realizado el calibrado, así como la 
fecha y la hora en las que el receptor GNSS 
proporcionó la posición utilizada para deter­
minar dicho país.  
▼B 
203) Además, la función de calibrado permitirá supri­
mir la utilización de las tarjetas de tacógrafo de 
primera generación en el aparato de control, 
siempre que se cumplan las condiciones especi­
ficadas en el apéndice 15.  
204) El emparejamiento del sensor de movimiento con 
la VU deberá constar al menos de los siguientes 
pasos:  
— actualización (si es preciso) de los datos re­
lativos a la instalación del sensor de movi­
miento, almacenados en el propio sensor de 
movimiento,  
— copia, en la memoria de datos de la VU, de 
los datos necesarios para la identificación del 
sensor de movimiento, almacenados en el 
propio sensor de movimiento.  
▼M3 
205) El acoplamiento del dispositivo GNSS externo 
con la VU deberá constar al menos de los si­
guientes pasos:  
— actualización (si es preciso) de los datos re­
lativos a la instalación del dispositivo GNSS 
externo almacenados en el propio dispositivo 
GNSS externo,  
— copia, en la memoria de datos de la VU, de 
los datos necesarios para la identificación del 
dispositivo GNSS externo, almacenados en el 
propio dispositivo GNSS externo, incluido el 
número de serie de este dispositivo.  
▼B 
206) La función de calibrado deberá ser capaz de in­
troducir todos los datos necesarios a través del 
conector de calibrado/transferencia, de acuerdo 
con el protocolo de calibrado definido en el 
apéndice 8. La función de calibrado también po­
drá utilizar otros medios para introducir los datos 
necesarios.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 66  
3.22 Control del calibrado en carretera  
207) La función de control de calibrado en carretera 
permitirá la lectura del número de serie del sen­
sor de movimiento (posiblemente integrado en el 
adaptador) y el número de serie del dispositivo 
GNSS externo (cuando proceda) conectado a la 
unidad instalada en el vehículo, en el momento 
de la petición.  
208) Esta lectura será posible al menos en la pantalla 
de la unidad instalada en el vehículo a través de 
comandos en los menús.  
209) La función de control de calibrado en carretera 
también permitirá controlar la selección del modo 
I/O de la línea de señal I/O de calibrado especi­
ficada en el apéndice 6 a través de la interfaz de 
la línea K. Esto se llevará a cabo a través de 
ECUAdjustmentSession, tal como se especifica 
en el apéndice 8, sección 7, «Control de los im­
pulsos de prueba — Unidad funcional para con­
trol de entrada/salida».  
▼M3 
Cuando el modo I/O de la línea de señal I/O de 
calibrado esté activo con arreglo al presente re­
quisito, la unidad instalada en el vehículo no 
activará el aviso «Conducción sin tarjeta ade­
cuada» (requisito 75).  
▼B 
3.23 Ajuste de la hora  
210) La función de ajuste de la hora deberá permitir el 
ajuste automático de la hora actual. En el aparato 
de control se utilizan dos fuentes para el ajuste 
de la hora: 1) el reloj interno de la VU, 2) el 
receptor GNSS.  
▼M3 
211) La hora del reloj interno de la VU se reajustará 
automáticamente a intervalos variables. El si­
guiente reajuste automático de la hora se activará 
entre setenta y dos y ciento sesenta y ocho horas 
después del anterior, y después de que la VU 
pueda acceder a la hora GNSS a través de un 
mensaje de posición autenticado válido, de con­
formidad con el apéndice 12. No obstante, el 
ajuste de la hora nunca será mayor que la des­
viación máxima diaria acumulada de la hora, cal­
culada por el fabricante de la VU de conformidad 
con el requisito 41  bis. Si la diferencia entre la 
hora del reloj interno de la VU y la hora del 
receptor GNSS es mayor que la desviación má­
xima diaria acumulada de la hora, el ajuste de la 
hora pondrá el reloj interno de la VU lo más 
cerca posible de la hora del receptor GNSS. El 
ajuste de la hora solo podrá efectuarse si la hora 
proporcionada por el receptor GNSS se obtiene 
utilizando mensajes de posición autenticados, de 
conformidad con el apéndice 12. La referencia 
temporal para la fijación automática de la hora 
del reloj interno de la VU será la hora propor­
cionada en el mensaje de posición autenticado.  
212) La función de ajuste de la hora deberá permitir 
también activar el ajuste de la hora actual, en el 
modo de calibrado.  
Los talleres podrán ajustar la hora:  
— o bien escribiendo un valor horario en la VU, 
utilizando el servicio WriteDataByIdentifier 
de conformidad con el punto 6.2 del apén­
dice 8,  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 67  
— o bien solicitando una alineación del reloj de 
la VU con la hora proporcionada por el re­
ceptor GNSS. Esto solo podrá hacerse si la 
hora proporcionada por el receptor GNSS se 
obtiene utilizando mensajes de posición au­
tenticados. En este último caso, deberá utili­
zarse el servicio RoutineControl de conformi­
dad con el punto 8 del apéndice 8.  
▼B 
3.24 Características de funcionamiento  
213) La unidad instalada en el vehículo deberá funcio­
nar perfectamente en el intervalo de temperaturas 
que va de – 20 °C a 70 °C, el dispositivo GNSS 
externo en el intervalo de – 20 °C a 70 °C, y el 
sensor de movimiento en el intervalo de – 40 °C 
a 135 °C. El contenido de la memoria de datos 
no se borrará aunque la temperatura descienda 
hasta – 40 °C.  
214) El aparato de control deberá funcionar perfecta­
mente en el intervalo higrométrico del 10 % al 
90 %.  
215) Los precintos utilizados en el tacógrafo digital 
deberán resistir las mismas condiciones aplicables 
a los componentes del tacógrafo en el que estén 
colocados.  
216) El aparato de control deberá estar protegido 
frente a sobretensiones, inversiones de polaridad 
de la fuente de alimentación y cortocircuitos.  
217) Los sensores de movimiento:  
— reaccionarán a todo campo magnético que 
perturbe la detección de movimiento del ve­
hículo; en estas circunstancias, la unidad ins­
talada en el vehículo registrará y almacenará 
un fallo del sensor (requisito 88), o bien  
— estarán dotados de un sensor protegido de los 
campos magnéticos o invulnerable a estos.  
218) El aparato de control y el dispositivo GNSS ex­
terno deberán ajustarse a la reglamentación inter­
nacional UN ECE R10 y estar protegidos contra 
descargas electrostáticas y fluctuaciones de la 
tensión.  
3.25 Materiales  
219) Todos los elementos que formen parte del apa­
rato de control deberán estar fabricados con ma­
teriales de estabilidad y resistencia mecánica su­
ficientes y de características eléctricas y magné­
ticas invariables.  
220) Para unas condiciones normales de utilización, 
todas las partes internas del aparato deberán estar 
protegidas contra la humedad y el polvo.  
221) La unidad instalada en el vehículo y el disposi­
tivo GNSS externo deberán tener el grado de 
protección IP 40 y el sensor de movimiento el 
grado de protección IP 64, según la norma IEC 
60529:1989, incluidos A1:1999 y A2:2013.  
222) El aparato de control deberá ser conforme a todas 
las especificaciones técnicas aplicables relativas 
al diseño ergonómico.  
223) El aparato de control deberá estar protegido 
frente a daños accidentales.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 68  
3.26 Marcas  
224) Si el aparato de control permite visualizar la lec­
tura del cuentakilómetros y la velocidad del ve­
hículo, en su pantalla deberán figurar las preci­
siones siguientes:  
— junto a la cifra que indica la distancia, la 
unidad de medida de la distancia, indicada 
mediante la abreviatura «km»,  
— junto a la cifra que indica la velocidad, la 
abreviatura «km/h».  
El aparato de control también debe ser capaz de 
mostrar la velocidad en millas por hora, en cuyo 
caso la unidad de medición de la velocidad se 
indicará con la abreviatura «mph». El aparato de 
control también debe ser capaz de mostrar la 
distancia en millas, en cuyo caso la unidad de 
medición de la distancia se indicará con la abre­
viatura «mi».  
▼M1 
225) Cada uno de los componentes del aparato de 
control deberá llevar una placa descriptiva con 
la información siguiente:  
— nombre y dirección del fabricante,  
— número de pieza del fabricante y año de fa­
bricación,  
— número de serie,  
— marca de homologación.  
226) Cuando el espacio físico disponible no baste para 
mostrar todas las informaciones mencionadas, en 
la placa descriptiva deberá figurar al menos el 
nombre o el logotipo del fabricante y el número 
de pieza.  
▼M3 
3.27 Seguimiento de los cruces de fronteras  
226 bis) Esta función detectará cuándo el vehículo ha cru­
zado la frontera de un país, de qué país ha salido 
y en qué país ha entrado.  
226 ter) La detección del cruce de fronteras se basará en 
la posición medida por el aparato de control y el 
mapa digital almacenado de conformidad con el 
punto 3.12.19.  
226 quater ) No se registrarán los cruces de fronteras relacio­
nados con la presencia del vehículo en un país 
durante un período inferior a 120 s.  
3.28 Actualización del  software  
226 quinquies ) La unidad instalada en el vehículo incorporará 
una función para la instalación de actualizaciones 
del software , siempre que estas no requieran re­
cursos de  hardware  adicionales distintos de los 
indicados en el requisito 226  septies  y las auto­
ridades de homologación de tipo concedan su 
autorización para esas actualizaciones del  soft­
ware  sobre la base de la unidad instalada en el 
vehículo de tipo homologado, de conformidad 
con el artículo 12, apartado 5, del Regla­
mento (UE) n.  o 165/2014.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 69  
226 sexies ) La función de actualización del  software  estará 
diseñada para ser compatible con las siguientes 
características funcionales, siempre que sean jurí­
dicamente obligatorias:  
— modificación de las funciones mencionadas 
en el punto 2.2, excepto la propia función 
de actualización del  software , 
— adición de nuevas funciones relacionadas di­
rectamente con la garantía de cumplimiento 
de la legislación de la Unión sobre transporte 
por carretera,  
— modificación de los modos de funciona­
miento del punto 2.3,  
— modificación de la estructura de archivos, por 
ejemplo adición de nuevos datos o aumento 
del tamaño de los archivos,  
— despliegue de parches de  software  para hacer 
frente a los defectos del  software  o de segu­
ridad o a los ataques notificados contra las 
funciones del aparato de control.  
226 septies ) La unidad instalada en el vehículo deberá dispo­
ner de un 35 % de recursos de  hardware  libres 
para el  software  y los datos necesarios de cara a 
la ejecución del requisito 226  sexies  y de un 65 % 
de recursos de  hardware  libres para la actualiza­
ción del mapa digital sobre la base de los recur­
sos de  hardware  requeridos para la versión de 
2021 del mapa NUTS 0.  
▼B 
4 CONDICIONES DE FABRICACIÓN Y FUNCIONAMIENTO DE 
LAS TARJETAS DE TACÓGRAFO  
4.1 Datos visibles  
El anverso de la tarjeta contendrá:  
227) la mención «Tarjeta de conductor» o «Tarjeta de 
control» o «Tarjeta de taller» o «Tarjeta de la 
empresa», en mayúsculas, en la lengua o lenguas 
oficiales del Estado miembro que expida la tar­
jeta, según el tipo de tarjeta;  
228) el nombre del Estado miembro que expida la 
tarjeta (opcional);  
229) el distintivo del Estado miembro que expida la 
tarjeta, impreso en negativo en un rectángulo azul 
rodeado de doce estrellas amarillas; los distinti­
vos serán los siguientes: 
B 
BG 
CZ 
CY Bélgica 
Bulgaria 
República Checa 
Chipre  LV 
L 
LT 
M Letonia 
Luxemburgo 
Lituania 
Malta  
DK Dinamarca  N L  Países Bajos  
D 
EST Alemania 
Estonia  A 
PL Austria 
Polonia  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 70  
GR Grecia  P  
RO 
SK 
SLO  Portugal 
Rumanía 
Eslovaquia 
Eslovenia  
E España  FIN  Finlandia  
F 
HR 
H Francia 
Croacia 
Hungría  S Suecia  
IRL Irlanda  U K  Reino Unido  
I Italia  
230) las informaciones específicas de la tarjeta expe­
dida, que constarán del siguiente modo:  
Tarjeta de conductor  Tarjeta de control  Tarjeta de empresa o de ta­
ller 
1. apellido(s) del conduc­
tor nombre del organismo 
de control  nombre de la empresa o 
del taller  
2. nombre(s) del conduc­
tor apellido(s) del controla­
dor 
(en su caso)  apellido(s) del titular de 
la tarjeta 
(en su caso)  
3. fecha de nacimiento 
del conductor  nombre(s) del controla­
dor 
(en su caso)  nombre(s) del titular de 
la tarjeta 
(en su caso)  
4.a fecha de comienzo de validez de la tarjeta  
4.b fecha de expiración de la tarjeta  
4.c designación de la autoridad expedidora (puede figurar en el re verso)  
4.d un número distinto del que se recoge en la rúbrica 5, que sea útil para la 
gestión de la tarjeta (opcional)  
5. a número del permiso de 
conducir 
(en la fecha de expedi­
ción de la tarjeta de 
conductor)  — —  
5. b Número de tarjeta  
6. fotografía del conduc­
tor fotografía del controla­
dor (opcional)  fotografía del instalador 
(opcional)  
7. firma del titular (opcional)  
8. lugar de residencia ha­
bitual, o dirección pos­
tal del titular (opcio­
nal) dirección postal del or­
ganismo de control  dirección postal de la 
empresa o taller  
231) las fechas deberán escribirse con el formato «dd/ 
mm/aaaa» o bien «dd.mm.aaaa» (día, mes, año).  
El reverso de la tarjeta contendrá:  
232) una explicación de las rúbricas numeradas que 
aparecen en el anverso de la tarjeta;  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 71  
233) con autorización expresa por escrito del titular, 
podrán incluirse también informaciones que no 
estén relacionadas con la gestión de la tarjeta, 
pero sin que con ello se modifique en modo 
alguno la utilización del modelo como tarjeta 
de tacógrafo.  
234) Las tarjetas de tacógrafo deberán imprimirse con 
los siguientes colores de fondo predominantes:  
— tarjeta del conductor: blanco,  
— tarjeta de control: azul,  
— tarjeta de taller: rojo,  
— tarjeta de empresa: amarillo.  
235) Las tarjetas de tacógrafo deberán reunir al menos 
las siguientes características de protección contra 
intentos de falsificación y manipulación:  
— un fondo con diseño de seguridad, fondo la­
brado e impresión en arco iris,  
— en la zona de la fotografía, el fondo con di­
seño de seguridad y la fotografía deberán 
solaparse,  
— al menos una línea de microimpresión 
bicolor.
  
► (1) M1 
► (2) M3 
236) Previa consulta a la Comisión, los Estados miem­
bros podrán añadir colores o inscripciones, tales 
como símbolos nacionales y características de 
seguridad, sin perjuicio de las demás disposicio­
nes del presente anexo.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 72  
237) Las tarjetas temporales a que se refiere el artí­
culo 26, apartado 4, del Reglamento (UE) 
n. o 165/2014 deberán cumplir lo dispuesto en el 
presente anexo.  
4.2 Seguridad  
La seguridad del sistema tiene por misión proteger la integrida d y 
autenticidad de los datos que intercambian las tarjetas y el ap arato 
de control, proteger la integridad y la autenticidad de los dat os que 
se transfieren de las tarjetas, permitir determinadas operacion es de 
escritura en las tarjetas por parte del aparato de control excl usiva­
mente, descifrar algunos datos, descartar toda posibilidad de f alsifi­
cación de los datos almacenados en las tarjetas, impedir la man ipu­
lación y detectar todo intento en este sentido.  
238) Al objeto de lograr la seguridad del sistema, las 
tarjetas de tacógrafo deberán cumplir los requisi­
tos de seguridad que se definen en los apéndices 
10 y 11.  
239) Las tarjetas de tacógrafo podrán leerse con otros 
equipos, como por ejemplo ordenadores 
personales.  
4.3 Normas  
240) Las tarjetas de tacógrafo deberán ajustarse a las 
normas siguientes:  
— ISO/IEC 7810 Tarjetas de identificación — 
Características físicas.  
— ISO/IEC 7816 Tarjetas de identificación — 
Tarjetas con circuitos integrados,  
— Parte 1: Características físicas,  
— Parte 2: Dimensiones y ubicación de los 
contactos (ISO/IEC 7816-2:2007),  
— Parte 3: Interfaz eléctrica y protocolos de 
transmisión (ISO/IEC 7816-3:2006),  
— Parte 4: Organización, seguridad y co­
mandos para los intercambios (ISO/IEC 
7816-4:2013 + Cor 1:2014),  
— Parte 6: Elementos de datos intersectoria­
les para los intercambios (ISO/IEC 7816- 
6:2004 + Cor 1:2006),  
— Parte 8: Comandos para las operaciones 
de seguridad (ISO/IEC 7816-8: 2004).  
— Las tarjetas de tacógrafo deberán someterse a 
ensayo con arreglo a la norma ISO/IEC 
10373-3:2010 (Tarjetas de identificación — 
Métodos de ensayo — Parte 3: Tarjetas con 
circuitos integrados con contactos y disposi­
tivos de interfaz conexos.  
4.4 Especificaciones ambientales y eléctricas  
241) Las tarjetas de tacógrafo deberán estar en condi­
ciones de funcionar correctamente bajo cualquier 
condición climática habitual en el territorio de la 
Comunidad y al menos en el intervalo de tempe­
raturas comprendido entre – 25 °C y + 70 °C, 
con picos ocasionales de hasta + 85 °C («ocasio­
nal» significa no más de cuatro horas cada vez y 
no más de cien veces durante la vida útil de la 
tarjeta).  
242) Las tarjetas deberán poder funcionar correcta­
mente en el intervalo de humedad comprendido 
entre el 10 % y el 90 %.  
243) Las tarjetas de tacógrafo deberán poder funcionar 
correctamente durante cinco años si se utilizan 
con arreglo a las especificaciones ambientales y 
eléctricas.  
244) Por lo que respecta a su funcionamiento, las tar­
jetas deberán ajustarse a ECE R10, en relación 
con la compatibilidad electromagnética, y debe­
rán estar protegidas contra descargas electrostáti­
cas. ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 73  
4.5 Almacenamiento de datos  
A efectos del presente apartado:  
— las horas se registran con una resolución de un minuto, a men os 
que se especifique lo contrario,  
— las lecturas del cuentakilómetros se registran con una resolu ción 
de un kilómetro,  
— las velocidades se registran con una resolución de 1 km/h,  
— las posiciones (latitudes y longitudes) se registran en grado s y 
minutos, con una resolución de 1/10 de minuto.  
Las funciones, comandos y estructuras lógicas de las tarjetas d e 
tacógrafo, por lo que respecta al cumplimiento de las condicion es 
de almacenamiento de datos, se especifican en el apéndice 2.  
Si no se especifica otra cosa, el almacenamiento de datos en la s 
tarjetas de tacógrafo deberá organizarse de tal manera que los datos 
nuevos sustituyan a los datos más antiguos almacenados en caso de 
que el tamaño de la memoria prevista para los registros específ icos 
se agote.  
245) En este apartado se especifica la capacidad mí­
nima de almacenamiento de los diferentes archi­
vos de datos de la aplicación. Las tarjetas de 
tacógrafo deberán ser capaces de indicar al apa­
rato de control la capacidad real de almacena­
miento de dichos archivos.  
▼M3 
246) En las tarjetas de tacógrafo podrán almacenarse 
datos adicionales, siempre que el almacenamiento 
de estos datos cumpla la legislación aplicable 
sobre protección de datos.  
▼B 
247) Cada archivo maestro (MF) de cualquier tarjeta 
de tacógrafo deberá contener hasta cinco archivos 
elementales (EF) referidos a la gestión de la tar­
jeta, identificaciones de la aplicación y del chip, 
y dos archivos dedicados (DF):  
— DF Tachograph, que contiene la aplicación 
accesible a las unidades instaladas en vehícu­
los de primera generación, que también está 
presente en las tarjetas de tacógrafo de pri­
mera generación,  
— DF Tachograph_G2, que contiene la aplica­
ción únicamente accesible a las unidades ins­
taladas en vehículos de segunda generación, 
que solo está presente en las tarjetas de tacó­
grafo de segunda generación.  
▼M3 
Nota: la versión 2 de las tarjetas de segunda 
generación contiene archivos elementales adicio­
nales en el archivo dedicado Tachograph_G2.  
▼B 
Los detalles de la estructura de las tarjetas de 
tacógrafo se especifican íntegramente en el apén­
dice 2.  
4.5.1  Archivos elementales para la identificación y la gestión de la tarjeta  
4.5.2  Identificación de la tarjeta CI  
248) Las tarjetas de tacógrafo deberán ser capaces de 
almacenar los siguientes datos para la identifica­
ción de la tarjeta inteligente:  
— parada de reloj,  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 74  
— número de serie de la tarjeta (incluidas refe­
rencias de fabricación),  
— número de homologación de la tarjeta,  
— identificación personal de la tarjeta (ID),  
— ID del integrador,  
— identificador del CI.  
4.5.2.1 I d e n t i f i c a c i ó n d e l c h i p  
249) Las tarjetas de tacógrafo deberán ser capaces de 
almacenar los siguientes datos para la identifica­
ción del circuito integrado (CI):  
— número de serie del CI,  
— referencias de fabricación del CI.  
4.5.2.2 D I R ( p r e s e n t e s o l o e n l a s t a r j e t a  s d e t a c ó g r a f o 
d e s e g u n d a g e n e r a c i ó n ) .  
250) Las tarjetas de tacógrafo deberán ser capaces de 
almacenar los objetos de datos de identificación 
de la aplicación especificados en el apéndice 2.  
4.5.2.3 I n f o r m a c i ó n A T R ( c o n d i c i o n a l m e  n t e , p r e s e n t e 
s o l o e n l a s t a r j e t a s d e t a c ó g r a f o d e s e  g u n d a g e ­
n e r a c i ó n ) .  
251) Las tarjetas de tacógrafo deberán ser capaces de 
almacenar el siguiente objeto de datos de infor­
mación de longitud extendida:  
— en el caso de que la tarjeta de tacógrafo 
acepte campos de longitud extendida, el ob­
jeto de datos de información de longitud ex­
tendida especificado en el apéndice 2.  
4.5.2.4 I n f o r m a c i ó n d e l o n g i t u d e x t e n d i  d a ( c o n d i c i o ­
n a l m e n t e , p r e s e n t e s o l o e n l a s t a r j e t  a s d e t a c ó ­
g r a f o d e s e g u n d a g e n e r a c i ó n ) .  
252) Las tarjetas de tacógrafo deberán ser capaces de 
almacenar los siguientes objetos de datos de in­
formación de longitud extendida:  
— en el caso de que la tarjeta de tacógrafo 
acepte campos de longitud extendida, los ob­
jetos de datos de información de longitud 
extendida especificados en el apéndice 2.  
4.5.3  Tarjeta de conductor  
4.5.3.1 A p l i c a c i ó n d e l t a c ó g r a f o ( a c c e s  i b l e a l a s u n i d a ­
d e s i n s t a l a d a s e n v e h í c u l o s d e p r i m e r  a y s e ­
g u n d a g e n e r a c i ó n )  
4.5.3.1.1 Identificación de la aplicación  
253) La tarjeta del conductor deberá ser capaz de al­
macenar los siguientes datos de identificación de 
la aplicación:  
— identificación de la aplicación del tacógrafo,  
— identificación del tipo de tarjeta de tacógrafo.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 75  
4.5.3.1.2 Clave y certificados  
254) La tarjeta de conductor deberá ser capaz de al­
macenar una serie de claves y certificados cripto­
gráficos, según lo especificado en el apéndice 11, 
parte A.  
4.5.3.1.3 Identificación de la tarjeta  
255) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos de identificación de 
la tarjeta:  
— número de tarjeta,  
— nombre del Estado miembro y de la autoridad 
que expidieron la tarjeta, fecha de expedición,  
— fecha de comienzo de validez de la tarjeta, 
fecha de expiración de la tarjeta.  
4.5.3.1.4 Identificación del titular de la tarjeta  
256) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos de identificación del 
titular de la tarjeta:  
— apellido(s) del titular,  
— nombre(s) del titular,  
— fecha de nacimiento,  
— idioma preferido.  
4.5.3.1.5 Transferencia de los datos de la tarjeta  
257) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos relativos a las trans­
ferencias desde la tarjeta:  
— fecha y hora de la última transferencia de los 
datos de la tarjeta (para fines distintos de los 
de control).  
258) La tarjeta de conductor deberá ser capaz de man­
tener almacenado uno de dichos registros.  
4.5.3.1.6 Información sobre el permiso de conducir  
259) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos sobre el permiso de 
conducir:  
— Estado miembro y autoridad que hayan expe­
dido el permiso,  
— número del permiso de conducir (en la fecha 
de expedición de la tarjeta).  
4.5.3.1.7 Datos sobre incidentes  
A efectos del presente subapartado, la hora se almacenará con u na 
resolución de un segundo.  
260) La tarjeta de conductor deberá ser capaz de al­
macenar los datos relativos a los siguientes inci­
dentes detectados por el aparato de control con la 
tarjeta insertada:  
— solapamiento temporal (cuando esa tarjeta sea 
la causa del incidente),  
— inserción de la tarjeta durante la conducción 
(cuando esa tarjeta sea el objeto del inci­
dente),  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 76  
— error al cerrar la última sesión de la tarjeta 
(cuando esa tarjeta sea el objeto del inci­
dente),  
— interrupción del suministro eléctrico,  
— error en datos de movimiento,  
— intentos de violación de la seguridad:  
261) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos sobre dichos 
incidentes:  
— código del incidente,  
— fecha y hora en que comenzó el incidente (o 
en que se insertó la tarjeta, si el incidente 
estaba ocurriendo en ese momento),  
— fecha y hora en que terminó el incidente (o 
en que se extrajo la tarjeta, si el incidente 
estaba ocurriendo en ese momento),  
— VRN y Estado miembro donde se matriculó 
el vehículo en el que ocurrió el incidente.  
Nota: por lo que respecta al incidente de «sola­
pamiento temporal»:  
— la fecha y hora en que comenzó el incidente 
deberán coincidir con la fecha y hora en que 
se extrajo la tarjeta del vehículo anterior,  
— la fecha y hora en que terminó el incidente 
deberán coincidir con la fecha y hora en que 
se insertó la tarjeta en el vehículo actual,  
— los datos del vehículo deberán coincidir con 
los del vehículo en que se produce el 
incidente.  
Nota: por lo que respecta al incidente de «error al 
cerrar la última sesión de la tarjeta»:  
— la fecha y hora en que comenzó el incidente 
deberán coincidir con la fecha de inserción de 
la tarjeta y la hora de la sesión que no se 
cerró correctamente,  
— la fecha y hora en que terminó el incidente 
deberán coincidir con la fecha de inserción de 
la tarjeta y la hora de la sesión durante la que 
se detectó el incidente (sesión actual),  
— los datos del vehículo deberán coincidir con 
los del vehículo en que la sesión no se cerró 
correctamente.  
262) La tarjeta de conductor deberá ser capaz de al­
macenar los datos correspondientes a los seis in­
cidentes más recientes de cada tipo (es decir, un 
total de 36 incidentes).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 77  
4.5.3.1.8 Datos sobre fallos  
A efectos del presente subapartado, la hora se registrará con u na 
resolución de un segundo.  
263) La tarjeta de conductor deberá ser capaz de al­
macenar los datos relativos a los siguientes fallos 
detectados por el aparato de control estando la 
tarjeta insertada:  
▼M1 
— fallo de la tarjeta (cuando esa tarjeta sea el 
tema del fallo),  
▼B 
— fallo del aparato de control.  
264) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos sobre dichos fallos:  
— código de fallo,  
— fecha y hora en que comenzó el fallo (o en 
que se insertó la tarjeta, si el fallo estaba 
ocurriendo en ese momento),  
— fecha y hora en que terminó el fallo (o en que 
se extrajo la tarjeta, si el fallo estaba ocu­
rriendo en ese momento),  
— VRN y Estado miembro donde se matriculó 
el vehículo en el que ocurrió el fallo.  
265) La tarjeta de conductor deberá ser capaz de al­
macenar los datos correspondientes a los doce 
fallos más recientes de cada tipo (es decir, un 
total de veinticuatro fallos).  
4.5.3.1.9 Datos sobre la actividad del conductor  
266) La tarjeta de conductor deberá ser capaz de al­
macenar, para cada día civil que se haya utilizado 
la tarjeta o para el cual el conductor haya intro­
ducido actividades manualmente, los siguientes 
datos:  
— la fecha,  
— un contador de presencia diaria (incrementado 
en una unidad por cada uno de estos días 
civiles),  
— la distancia total recorrida por el conductor 
durante ese día,  
— el régimen de conducción a las 00.00 horas,  
— cada vez que el conductor cambie de activi­
dad, o cambie el régimen de conducción, o 
inserte o extraiga su tarjeta:  
— el régimen de conducción (EN EQUIPO, 
EN SOLITARIO),  
— la ranura (CONDUCTOR, SEGUNDO 
CONDUCTOR),  
— el estado de la tarjeta (INSERTADA, NO 
INSERTADA),  
— la actividad (CONDUCCIÓN, DISPONI­
BILIDAD, TRABAJO, PAUSA/DES­
CANSO),  
— la hora del cambio.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 78  
267) La memoria de la tarjeta de conductor deberá ser 
capaz de mantener almacenados durante al menos 
veintiocho días los datos sobre la actividad del 
conductor (la actividad media de un conductor se 
define como 93 cambios de actividad por día).  
268) Los datos enumerados en los requisitos 261, 264 
y 266 deberán almacenarse de manera que las 
actividades puedan recuperarse en su orden de 
ocurrencia, incluso en una situación de solapa­
miento temporal.  
4.5.3.1.10 Datos sobre vehículos empleados  
269) La tarjeta de conductor deberá ser capaz de al­
macenar, para cada día civil que se haya utilizado 
la tarjeta y para cada período de uso del vehículo 
en ese día (un período de uso incluye todos los 
ciclos consecutivos de inserción/extracción de la 
tarjeta en el vehículo, visto desde el punto de 
vista de la tarjeta), los siguientes datos:  
— fecha y hora en que se utiliza el vehículo por 
primera vez (es decir, primera inserción de la 
tarjeta en ese período de uso del vehículo, o 
bien 00.00 horas si el vehículo se está utili­
zando en ese momento),  
— valor del cuentakilómetros del vehículo en 
ese momento,  
— fecha y hora en que se utiliza el vehículo por 
última vez, (es decir, última extracción de la 
tarjeta en ese período de uso del vehículo, o 
bien 23.59 horas si el vehículo se está utili­
zando en ese momento),  
— valor del cuentakilómetros del vehículo en 
ese momento,  
— VRN y Estado miembro donde se matriculó 
el vehículo.  
270) La tarjeta de conductor deberá ser capaz de al­
macenar al menos 84 de estos registros.  
4.5.3.1.11 Lugares donde comienzan o terminan los períodos de t rabajo diarios  
271) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos, que introduce el 
conductor, relativos a los lugares donde comien­
zan o terminan los períodos de trabajo diarios:  
— la fecha y hora de la introducción (o la fecha/ 
hora relacionada con la introducción si esta 
tiene lugar durante el procedimiento de intro­
ducción manual),  
— el tipo de introducción (comienzo o final, 
condición de introducción),  
— el país y la región introducidos,  
— la lectura del cuentakilómetros del vehículo.  
272) La memoria de la tarjeta de conductor deberá ser 
capaz de mantener almacenados al menos 42 pa­
res de estos registros.  
4.5.3.1.12 Datos de la sesión  
273) La tarjeta de conductor deberá ser capaz de al­
macenar los datos relativos al vehículo que abrió 
la sesión actual:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 79  
— fecha y hora en que se abrió la sesión (es 
decir, inserción de la tarjeta), con una resolu­
ción de un segundo,  
— VRN y Estado miembro donde se matriculó 
el vehículo.  
4.5.3.1.13 Datos sobre actividades de control  
274) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos relativos a las acti­
vidades de control:  
— fecha y hora del control,  
— número de la tarjeta de control y Estado 
miembro que haya expedido la tarjeta,  
— tipo de control (visualización o impresión o 
transferencia de los datos de la VU o trans­
ferencia de los datos de la tarjeta [véase la 
nota]),  
— período transferido, en caso de transferencia,  
— VRN y Estado miembro donde se matriculó 
el vehículo en el que se produjera el control.  
Nota: la transferencia de los datos de la tarjeta 
solo quedará registrada si se lleva a cabo con un 
aparato de control.  
275) La tarjeta de conductor deberá ser capaz de man­
tener almacenado uno de dichos registros.  
4.5.3.1.14 Datos sobre condiciones específicas  
276) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos relativos a las con­
diciones específicas que se introdujeron al inser­
tar la tarjeta (en la ranura que fuese):  
— fecha y hora de la introducción,  
— tipo de condición específica.  
277) La tarjeta de conductor deberá ser capaz de al­
macenar al menos 56 de estos registros.  
▼M3 
4.5.3.2 A p l i c a c i ó n d e t a c ó g r a f o d e s e g u n  d a g e n e r a c i ó n 
( n o a c c e s i b l e p a r a l a s u n i d a d e s i n s t a  l a d a s e n e l 
v e h í c u l o d e p r i m e r a g e n e r a c i ó n , a c c e  s i b l e p a r a 
l a v e r s i ó n 1 y l a v e r s i ó n 2 d e l a s u n i d a d  e s i n s ­
t a l a d a s e n e l v e h í c u l o d e s e g u n d a g e n e  r a c i ó n )  
▼B 
4.5.3.2.1 Identificación de la aplicación  
278) La tarjeta del conductor deberá ser capaz de al­
macenar los siguientes datos de identificación de 
la aplicación:  
— identificación de la aplicación del tacógrafo,  
— identificación del tipo de tarjeta de tacógrafo.  
▼M3 
4.5.3.2.1.1 Identificación de la aplicación adicional (no acces ible para la ver­
sión 1 de las unidades instaladas en el vehículo de segunda gen e­
ración)  
278 bis) La tarjeta de conductor deberá ser capaz de al­
macenar datos adicionales de identificación de la 
aplicación solo aplicables a la versión 2.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 80  
4.5.3.2.2 Claves y certificados  
279) La tarjeta de conductor deberá ser capaz de al­
macenar una serie de claves y certificados cripto­
gráficos, según lo especificado en el apéndice 11, 
parte B.  
4.5.3.2.3 Identificación de la tarjeta  
280) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos de identificación de 
la tarjeta:  
— número de tarjeta,  
— nombre del Estado miembro y de la autoridad 
que expidieron la tarjeta, fecha de expedición,  
— fecha de comienzo de validez de la tarjeta, 
fecha de expiración de la tarjeta.  
4.5.3.2.4 Identificación del titular de la tarjeta  
281) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos de identificación del 
titular de la tarjeta:  
— apellido(s) del titular,  
— nombre(s) del titular,  
— fecha de nacimiento,  
— idioma preferido.  
4.5.3.2.5 Transferencia de los datos de la tarjeta  
282) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos relativos a las trans­
ferencias desde la tarjeta:  
— fecha y hora de la última transferencia de los 
datos de la tarjeta (para fines distintos de los 
de control).  
283) La tarjeta de conductor deberá ser capaz de man­
tener almacenado uno de dichos registros.  
4.5.3.2.6 Información sobre el permiso de conducir  
284) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos sobre el permiso de 
conducir:  
— Estado miembro y autoridad que hayan expe­
dido el permiso,  
— número del permiso de conducir (en la fecha 
de expedición de la tarjeta).  
4.5.3.2.7 Datos sobre incidentes  
A efectos del presente subapartado, la hora se almacenará con u na 
resolución de un segundo.  
285) La tarjeta de conductor deberá ser capaz de al­
macenar los datos relativos a los siguientes inci­
dentes detectados por el aparato de control con la 
tarjeta insertada:  
— solapamiento temporal (cuando esa tarjeta sea 
la causa del incidente),  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 81  
— inserción de la tarjeta durante la conducción 
(cuando esa tarjeta sea el objeto del inci­
dente),  
— error al cerrar la última sesión de la tarjeta 
(cuando esa tarjeta sea el objeto del inci­
dente),  
— interrupción del suministro eléctrico,  
— error de comunicación con el dispositivo de 
comunicación a distancia,  
— ausencia de información sobre la posición 
procedente del receptor GNSS,  
— error de comunicación con el dispositivo 
GNSS externo,  
— error en datos de movimiento,  
— conflicto de movimiento del vehículo,  
— intentos de violación de la seguridad,  
— conflicto temporal.  
286) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos sobre dichos 
incidentes:  
— código del incidente,  
— fecha y hora en que comenzó el incidente (o 
en que se insertó la tarjeta, si el incidente 
estaba ocurriendo en ese momento),  
— fecha y hora en que terminó el incidente (o 
en que se extrajo la tarjeta, si el incidente 
estaba ocurriendo en ese momento),  
— VRN y Estado miembro donde se matriculó 
el vehículo en el que ocurrió el incidente.  
Nota: por lo que respecta al incidente de «sola­
pamiento temporal»:  
— la fecha y hora en que comenzó el incidente 
deberán coincidir con la fecha y hora en que 
se extrajo la tarjeta del vehículo anterior,  
— la fecha y hora en que terminó el incidente 
deberán coincidir con la fecha y hora en que 
se insertó la tarjeta en el vehículo actual,  
— los datos del vehículo deberán coincidir con 
los del vehículo en que se produce el 
incidente.  
Nota: por lo que respecta al incidente de «error al 
cerrar la última sesión de la tarjeta»:  
— la fecha y hora en que comenzó el incidente 
deberán coincidir con la fecha de inserción de 
la tarjeta y la hora de la sesión que no se 
cerró correctamente,  
— la fecha y hora en que terminó el incidente 
deberán coincidir con la fecha de inserción de 
la tarjeta y la hora de la sesión durante la que 
se detectó el incidente (sesión actual),  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 82  
— los datos del vehículo deberán coincidir con 
los del vehículo en que la sesión no se cerró 
correctamente.  
▼M3 
287) La tarjeta de conductor deberá ser capaz de al­
macenar los datos correspondientes a los doce 
incidentes más recientes de cada tipo (es decir, 
un total de ciento treinta y dos incidentes).  
▼B 
4.5.3.2.8 Datos sobre fallos  
A efectos del presente subapartado, la hora se registrará con u na 
resolución de un segundo.  
288) La tarjeta de conductor deberá ser capaz de al­
macenar los datos relativos a los siguientes fallos 
detectados por el aparato de control estando la 
tarjeta insertada:  
▼M1 
— fallo de la tarjeta (cuando esa tarjeta sea el 
tema del fallo),  
▼B 
— fallo del aparato de control.  
289) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos sobre dichos fallos:  
— código de fallo,  
— fecha y hora en que comenzó el fallo (o en 
que se insertó la tarjeta, si el fallo estaba 
ocurriendo en ese momento),  
— fecha y hora en que terminó el fallo (o en que 
se extrajo la tarjeta, si el fallo estaba ocu­
rriendo en ese momento),  
— VRN y Estado miembro donde se matriculó 
el vehículo en el que ocurrió el fallo.  
▼M3 
290) La tarjeta de conductor deberá ser capaz de al­
macenar los datos correspondientes a los veinti­
cuatro fallos más recientes de cada tipo (es decir, 
un total de cuarenta y ocho fallos).  
▼B 
4.5.3.2.9 Datos sobre la actividad del conductor  
291) La tarjeta de conductor deberá ser capaz de al­
macenar, para cada día civil que se haya utilizado 
la tarjeta o para el cual el conductor haya intro­
ducido actividades manualmente, los siguientes 
datos:  
— la fecha,  
— un contador de presencia diaria (incrementado 
en una unidad por cada uno de estos días 
civiles),  
— la distancia total recorrida por el conductor 
durante ese día,  
— el régimen de conducción a las 00.00 horas,  
— cada vez que el conductor cambie de activi­
dad, o cambie el régimen de conducción, o 
inserte o extraiga su tarjeta:  
— el régimen de conducción (EN EQUIPO, 
EN SOLITARIO),  
— la ranura (CONDUCTOR, SEGUNDO 
CONDUCTOR),  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 83  
— el estado de la tarjeta (INSERTADA, NO 
INSERTADA),  
— la actividad (CONDUCCIÓN, DISPONI­
BILIDAD, TRABAJO, PAUSA/DES­
CANSO),  
— la hora del cambio.  
▼M3 
292) La memoria de la tarjeta de conductor deberá ser 
capaz de mantener almacenados durante al menos 
cincuenta y seis días los datos de actividad del 
conductor (a efectos del presente requisito, la 
actividad media de un conductor se define 
como ciento diecisiete cambios diarios de activi­
dad). 
▼B 
293) Los datos enumerados en los requisitos 286, 289 
y 291 deberán almacenarse de manera que las 
actividades puedan recuperarse en su orden de 
ocurrencia, incluso en una situación de solapa­
miento temporal.  
4.5.3.2.10 Datos sobre vehículos empleados  
294) La tarjeta de conductor deberá ser capaz de al­
macenar, para cada día civil que se haya utilizado 
la tarjeta y para cada período de uso del vehículo 
en ese día (un período de uso incluye todos los 
ciclos consecutivos de inserción/extracción de la 
tarjeta en el vehículo, visto desde el punto de 
vista de la tarjeta), los siguientes datos:  
— fecha y hora en que se utiliza el vehículo por 
primera vez (es decir, primera inserción de la 
tarjeta en ese período de uso del vehículo, o 
bien 00.00 horas si el vehículo se está utili­
zando en ese momento),  
— valor del cuentakilómetros del vehículo en 
ese momento de primer uso,  
— fecha y hora en que se utiliza el vehículo por 
última vez, (es decir, última extracción de la 
tarjeta en ese período de uso del vehículo, o 
bien 23.59 horas si el vehículo se está utili­
zando en ese momento),  
— valor del cuentakilómetros del vehículo en 
ese momento de último uso,  
— VRN y Estado miembro donde se matriculó 
el vehículo,  
— VIN del vehículo.  
▼M3 
295) La tarjeta de conductor deberá ser capaz de al­
macenar al menos doscientos de estos registros.  
▼B 
4.5.3.2.11 Lugares y posiciones donde comienzan o terminan los períodos de 
trabajo diarios  
296) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos, que introduce el 
conductor, relativos a los lugares donde comien­
zan o terminan los períodos de trabajo diarios:  
— la fecha y hora de la introducción (o la fecha/ 
hora relacionada con la introducción si esta 
tiene lugar durante el procedimiento de intro­
ducción manual),  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 84  
— el tipo de introducción (comienzo o final, 
condición de introducción),  
— el país y la región introducidos,  
— la lectura del cuentakilómetros del vehículo,  
— la posición del vehículo,  
— La exactitud del GNSS, fecha y hora en que 
se haya determinado la posición.  
▼M3 
297) La memoria de la tarjeta de conductor deberá ser 
capaz de mantener almacenados al menos ciento 
doce de estos registros.  
▼B 
4.5.3.2.12 Datos de la sesión  
298) La tarjeta de conductor deberá ser capaz de al­
macenar los datos relativos al vehículo que abrió 
la sesión actual:  
— fecha y hora en que se abrió la sesión (es 
decir, inserción de la tarjeta), con una resolu­
ción de un segundo,  
— VRN y Estado miembro donde se matriculó 
el vehículo.  
4.5.3.2.13 Datos sobre actividades de control  
299) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos relativos a las acti­
vidades de control:  
— fecha y hora del control,  
— número de la tarjeta de control y Estado 
miembro que haya expedido la tarjeta,  
— tipo de control (visualización o impresión o 
transferencia de los datos de la VU o trans­
ferencia de los datos de la tarjeta [véase la 
nota]),  
— período transferido, en caso de transferencia,  
— VRN y Estado miembro donde se matriculó 
el vehículo en el que se produjera el control.  
Nota: las condiciones de seguridad implican que 
la transferencia de los datos de la tarjeta solo 
quedará registrada si se lleva a cabo con un apa­
rato de control.  
300) La tarjeta de conductor deberá ser capaz de man­
tener almacenado uno de dichos registros.  
4.5.3.2.14 Datos sobre condiciones específicas  
301) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos relativos a las con­
diciones específicas que se introdujeron al inser­
tar la tarjeta (en la ranura que fuese):  
— fecha y hora de la introducción,  
— tipo de condición específica.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 85  
302) La tarjeta de conductor deberá ser capaz de al­
macenar al menos ciento doce de estos registros.  
▼B 
4.5.3.2.15 Datos utilizados en unidades instaladas en vehículos  
303) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos relativos a las dife­
rentes unidades instaladas en vehículos en que se 
utilice la tarjeta:  
— fecha y la hora en que comienza el período 
de uso de la unidad instalada en el vehículo 
(es decir, primera inserción de la tarjeta en la 
unidad instalada en el vehículo en el pe­
ríodo),  
— nombre del fabricante de la unidad instalada 
en el vehículo,  
— tipo de unidad instalada en el vehículo,  
— versión del  software  que lleva instalado la 
unidad instalada en el vehículo.  
▼M3 
304) La tarjeta de conductor deberá ser capaz de al­
macenar al menos doscientos de estos registros.  
▼M1 
4.5.3.2.16 Datos sobre lugares en tres horas de conducción acum uladas  
305) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos relativos a la posi­
ción del vehículo cuando el tiempo de conduc­
ción acumulado alcance un múltiplo de tres 
horas:  
— fecha y hora en las que el tiempo de conduc­
ción acumulado llega a un múltiplo de tres 
horas,  
— posición del vehículo,  
— la exactitud del GNSS, fecha y hora en que 
se haya determinado la posición,  
— la lectura del cuentakilómetros del vehículo.  
▼M3 
306) La tarjeta de conductor deberá ser capaz de al­
macenar al menos trescientos treinta y seis de 
estos registros.  
4.5.3.2.17 Estado de autenticación para posiciones relacionadas  con lugares en 
los que comienzan o terminan los períodos de trabajo diarios (n o 
accesible para la versión 1 de las unidades instaladas en el ve hículo 
de segunda generación)  
306 bis) La tarjeta de conductor deberá ser capaz de al­
macenar datos adicionales relativos a los lugares 
donde comienzan o terminan los períodos de tra­
bajo diarios, introducidos por el conductor de 
conformidad con el punto 4.5.3.2.11:  
— la fecha y la hora de la entrada, que deberán 
ser exactamente las mismas que las almace­
nadas en el archivo elemental Places del ar­
chivo dedicado Tachograph_G2,  
— un indicador que señale si la posición ha sido 
autenticada.  
306 ter) La memoria de la tarjeta de conductor deberá ser 
capaz de mantener almacenados ciento doce de 
estos registros.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 86  
4.5.3.2.18 Estado de autenticación para posiciones en las que s e alcanza el 
tiempo de conducción acumulado de tres horas (no accesible para  
la versión 1 de las unidades instaladas en el vehículo de segun da 
generación)  
306 quater ) La tarjeta de conductor deberá ser capaz de al­
macenar datos adicionales relativos a la posición 
del vehículo donde el tiempo de conducción acu­
mulado alcanza un múltiplo de tres horas de con­
formidad con el punto 4.5.3.2.16:  
— la fecha y la hora en las que el tiempo de 
conducción acumulado alcanza un múltiplo 
de tres horas, que deberán ser exactamente 
las mismas que las almacenadas en el archivo 
elemental GNSS_Places del archivo dedicado 
Tachograph_G2,  
— un indicador que señale si la posición ha sido 
autenticada.  
306 quinquies ) La tarjeta de conductor deberá ser capaz de al­
macenar al menos trescientos treinta y seis de 
estos registros.  
4.5.3.2.19 Cruces de fronteras (no accesible para la versión 1 de las unidades 
instaladas en el vehículo de segunda generación);  
306 sexies ) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos relativos a los cru­
ces de fronteras, bien al insertar la tarjeta de 
conformidad con el requisito 147  ter, bien con 
la tarjeta ya insertada:  
— el país del que sale el vehículo,  
— el país en el que entra el vehículo,  
— la fecha y la hora en las que el vehículo ha 
cruzado la frontera,  
— la posición del vehículo cuando se ha cruzado 
la frontera,  
— la exactitud del GNSS,  
— un indicador que señale si la posición ha sido 
autenticada,  
— el valor del cuentakilómetros del vehículo.  
306 septies ) La memoria de la tarjeta de conductor deberá ser 
capaz de almacenar mil ciento veinte de estos 
registros.  
4.5.3.2.20 Operaciones de carga/descarga (no accesible para la versión 1 de las 
unidades instaladas en el vehículo de segunda generación);  
306 octies ) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos relativos a las ope­
raciones de carga/descarga:  
— el tipo de operación (carga, descarga o carga/ 
descarga simultáneas),  
— la fecha y hora de la operación de carga/des­
carga,  
— la posición del vehículo,  
— la exactitud del GNSS, la fecha y la hora en 
las que se ha determinado la posición,  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 87  
— un indicador que señale si la posición ha sido 
autenticada,  
— el valor del cuentakilómetros del vehículo.  
306 nonies ) La tarjeta de conductor deberá ser capaz de al­
macenar al menos 1 624 operaciones de carga/ 
descarga.  
4.5.3.2.21 Entradas de tipo de carga (no accesible para la vers ión 1 de las 
unidades instaladas en el vehículo de segunda generación);  
306 decies ) La tarjeta de conductor deberá ser capaz de al­
macenar los siguientes datos relativos al tipo de 
carga introducidos automáticamente por la VU 
cada vez que se inserta la tarjeta:  
— el tipo de carga introducido (mercancías o 
pasajeros),  
— la fecha y la hora de la entrada.  
306 undecies ) La tarjeta de conductor deberá ser capaz de al­
macenar al menos trescientos treinta y seis de 
estos registros.  
4.5.3.2.22 Configuraciones de la VU (no accesible para la versi ón 1 de las 
unidades instaladas en el vehículo de segunda generación)  
306 duodecies ) La tarjeta de conductor deberá ser capaz de al­
macenar los ajustes específicos del tacógrafo del 
titular de la tarjeta.  
306 terdecies ) La capacidad de almacenamiento de la tarjeta de 
conductor para los ajustes específicos del tacó­
grafo del titular de la tarjeta deberá ser de 
3 072 bytes.  
▼B 
4.5.4  Tarjeta de taller  
4.5.4.1 A p l i c a c i ó n d e l t a c ó g r a f o ( a c c e s  i b l e a l a s u n i d a ­
d e s i n s t a l a d a s e n v e h í c u l o s d e p r i m e r  a y s e ­
g u n d a g e n e r a c i ó n )  
4.5.4.1.1 Identificación de la aplicación  
307) La tarjeta de taller deberá ser capaz de almacenar 
los siguientes datos de identificación de la apli­
cación:  
— identificación de la aplicación del tacógrafo,  
— identificación del tipo de tarjeta de tacógrafo.  
4.5.4.1.2 Claves y certificados  
308) La tarjeta de taller deberá ser capaz de almacenar 
una serie de claves y certificados criptográficos, 
según lo especificado en el apéndice 11, parte A.  
309) La tarjeta de taller deberá ser capaz de almacenar 
un número de identificación personal (código 
PIN).  
4.5.4.1.3 Identificación de la tarjeta  
310) La tarjeta de taller deberá ser capaz de almacenar 
los siguientes datos relativos a la identificación 
de la tarjeta:  
— número de tarjeta,  
— nombre del Estado miembro y de la autoridad 
que expidieron la tarjeta, fecha de expedición,  
— fecha de comienzo de validez de la tarjeta, 
fecha de expiración de la tarjeta.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 88  
4.5.4.1.4 Identificación del titular de la tarjeta  
311) La tarjeta de taller deberá ser capaz de almacenar 
los siguientes datos relativos a la identificación 
del titular de la tarjeta:  
— nombre del taller,  
— dirección del taller,  
— apellido(s) del titular,  
— nombre(s) del titular,  
— idioma preferido.  
4.5.4.1.5 Transferencia de los datos de la tarjeta  
312) La tarjeta de taller deberá ser capaz de almacenar 
un registro de datos sobre transferencias de la 
tarjeta, del mismo modo que una tarjeta de 
conductor.  
4.5.4.1.6 Datos de calibrado y de ajuste de la hora  
313) La tarjeta de taller deberá ser capaz de mantener 
almacenados los registros de los calibrados o 
ajustes de hora que se hayan realizado mientras 
la tarjeta está insertada en el aparato de control.  
314) Cada registro de calibrado deberá ser capaz de 
mantener almacenados los datos siguientes:  
— propósito del calibrado (activación, primera 
instalación, instalación, control periódico),  
— identificación del vehículo,  
— parámetros que se actualizan o confirman (w, 
k, l, tamaño de los neumáticos, valor de 
ajuste del dispositivo limitador de la veloci­
dad, cuentakilómetros (lectura anterior y 
nueva lectura), fecha y hora (valor anterior 
y nuevo valor),  
— identificación del aparato de control (número 
de pieza de la VU, número de serie de la VU, 
número de serie del sensor de movimiento).  
315) La tarjeta de taller deberá ser capaz de almacenar 
al menos 88 de estos registros.  
316) La tarjeta de taller deberá tener un contador que 
indique el número total de calibrados que se ha­
yan realizado con la tarjeta.  
317) La tarjeta de taller deberá tener un contador que 
indique el número de calibrados que se hayan 
realizado desde la última transferencia.  
4.5.4.1.7 Datos de incidentes y fallos  
318) La tarjeta de taller deberá ser capaz de almacenar 
los registros de datos sobre fallos e incidentes, 
del mismo modo que una tarjeta de conductor.  
319) La tarjeta de taller deberá ser capaz de almacenar 
los datos de los tres incidentes más recientes de 
cada tipo (es decir, dieciocho incidentes) y de los 
seis fallos más recientes de cada tipo (es decir, 
doce fallos).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 89  
4.5.4.1.8 Datos sobre la actividad del conductor  
320) La tarjeta de taller deberá ser capaz de almacenar 
datos sobre la actividad del conductor, del mismo 
modo que una tarjeta de conductor.  
321) La tarjeta de taller deberá ser capaz de mantener 
almacenados los datos sobre la actividad del con­
ductor durante al menos un día de actividad 
media.  
4.5.4.1.9 Datos sobre vehículos empleados  
322) La tarjeta de taller deberá ser capaz de almacenar 
registros de datos sobre los vehículos empleados, 
del mismo modo que una tarjeta de conductor.  
323) La tarjeta de taller deberá ser capaz de almacenar 
al menos cuatro de estos registros.  
4.5.4.1.10 Datos sobre el comienzo y el final de los períodos d e trabajo diarios  
324) La tarjeta de taller deberá ser capaz de almacenar 
los registros de datos sobre las horas de co­
mienzo o final de los períodos de trabajo diarios, 
del mismo modo que una tarjeta de conductor.  
325) La tarjeta de taller deberá ser capaz de mantener 
almacenados al menos tres pares de estos 
registros.  
4.5.4.1.11 Datos de la sesión  
326) La tarjeta de taller deberá ser capaz de almacenar 
un registro de datos de sesión, del mismo modo 
que una tarjeta de conductor.  
4.5.4.1.12 Datos sobre actividades de control  
327) La tarjeta de taller deberá ser capaz de almacenar 
un registro de datos sobre actividades de control, 
del mismo modo que una tarjeta de conductor.  
4.5.4.1.13 Datos sobre condiciones específicas  
328) La tarjeta de taller deberá ser capaz de almacenar 
los datos correspondientes a las condiciones es­
pecíficas, del mismo modo que la tarjeta de 
conductor.  
329) La tarjeta de taller deberá ser capaz de almacenar 
al menos dos de estos registros.  
▼M3 
4.5.4.2 A p l i c a c i ó n d e t a c ó g r a f o d e s e g u n  d a g e n e r a c i ó n 
( n o a c c e s i b l e p a r a l a s u n i d a d e s i n s t a  l a d a s e n e l 
v e h í c u l o d e p r i m e r a g e n e r a c i ó n , a c c e  s i b l e p a r a 
l a v e r s i ó n 1 y l a v e r s i ó n 2 d e l a s u n i d a d  e s i n s ­
t a l a d a s e n e l v e h í c u l o d e s e g u n d a g e n e  r a c i ó n )  
▼B 
4.5.4.2.1 Identificación de la aplicación  
330) La tarjeta de taller deberá ser capaz de almacenar 
los siguientes datos de identificación de la apli­
cación:  
— identificación de la aplicación del tacógrafo,  
— identificación del tipo de tarjeta de tacógrafo.  
▼M3 
4.5.4.2.1.1 Identificación de la aplicación adicional (no acces ible para la ver­
sión 1 de las unidades instaladas en el vehículo de segunda gen e­
ración)  
330 bis) La tarjeta de taller deberá ser capaz de almacenar 
datos adicionales de identificación de la aplica­
ción solo aplicables a la versión 2.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 90  
4.5.4.2.2 Claves y certificados  
331) La tarjeta de taller deberá ser capaz de almacenar 
una serie de claves y certificados criptográficos, 
según lo especificado en el apéndice 11, parte B.  
332) La tarjeta de taller deberá ser capaz de almacenar 
un número de identificación personal (código 
PIN).  
4.5.4.2.3 Identificación de la tarjeta  
333) La tarjeta de taller deberá ser capaz de almacenar 
los siguientes datos relativos a la identificación 
de la tarjeta:  
— número de tarjeta,  
— nombre del Estado miembro y de la autoridad 
que expidieron la tarjeta, fecha de expedición,  
— fecha de comienzo de validez de la tarjeta, 
fecha de expiración de la tarjeta.  
4.5.4.2.4 Identificación del titular de la tarjeta  
334) La tarjeta de taller deberá ser capaz de almacenar 
los siguientes datos relativos a la identificación 
del titular de la tarjeta:  
— nombre del taller,  
— dirección del taller,  
— apellido(s) del titular,  
— nombre(s) del titular,  
— idioma preferido.  
4.5.4.2.5 Transferencia de los datos de la tarjeta  
335) La tarjeta de taller deberá ser capaz de almacenar 
un registro de datos sobre transferencias de la 
tarjeta, del mismo modo que una tarjeta de 
conductor.  
4.5.4.2.6 Datos de calibrado y de ajuste de la hora  
336) La tarjeta de taller deberá ser capaz de mantener 
almacenados los registros de los calibrados o 
ajustes de hora que se hayan realizado mientras 
la tarjeta está insertada en el aparato de control.  
337) Cada registro de calibrado deberá ser capaz de 
mantener almacenados los datos siguientes:  
— propósito del calibrado (activación, primera 
instalación, instalación, control periódico),  
— identificación del vehículo,  
— parámetros que se actualizan o confirman (w, 
k, l, tamaño de los neumáticos, valor de 
ajuste del dispositivo limitador de la veloci­
dad, cuentakilómetros (lectura anterior y 
nueva lectura), fecha y hora (valor anterior 
y nuevo valor),  
— identificación del aparato de control (número 
de pieza de la VU, número de serie de la VU, 
número de serie del sensor de movimiento, 
número de serie del dispositivo de comunica­
ción a distancia y número de serie del dispo­
sitivo GNSS externo, si procede),  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 91  
— tipo e identificador de todos los precintos 
existentes,  
— capacidad de la VU para utilizar tarjetas de 
tacógrafo de la primera generación (habilitada 
o no).  
▼M3 
338) La tarjeta de taller deberá ser capaz de almacenar 
al menos doscientos cincuenta y cinco de estos 
registros.  
▼B 
339) La tarjeta de taller deberá tener un contador que 
indique el número total de calibrados que se ha­
yan realizado con la tarjeta.  
340) La tarjeta de taller deberá tener un contador que 
indique el número de calibrados que se hayan 
realizado desde la última transferencia.  
4.5.4.2.7 Datos de incidentes y fallos  
341) La tarjeta de taller deberá ser capaz de almacenar 
los registros de datos sobre fallos e incidentes, 
del mismo modo que una tarjeta de conductor.  
342) La tarjeta de taller deberá ser capaz de almacenar 
los datos de los tres incidentes más recientes de 
cada tipo (es decir, treinta y tres incidentes) y de 
los seis fallos más recientes de cada tipo (es 
decir, doce fallos).  
4.5.4.2.8 Datos sobre la actividad del conductor  
343) La tarjeta de taller deberá ser capaz de almacenar 
datos sobre la actividad del conductor, del mismo 
modo que una tarjeta de conductor.  
▼M3 
344) La tarjeta de taller deberá ser capaz de mantener 
los datos de actividad del conductor durante un 
día, con doscientos cuarenta cambios de 
actividad.  
▼B 
4.5.4.2.9 Datos sobre vehículos empleados  
345) La tarjeta de taller deberá ser capaz de almacenar 
registros de datos sobre los vehículos empleados, 
del mismo modo que una tarjeta de conductor.  
▼M3 
346) La tarjeta de taller deberá ser capaz de almacenar 
al menos ocho de estos registros.  
4.5.4.2.10 Datos de lugares y posiciones donde comienzan o term inan los 
períodos de trabajo diarios  
347) La tarjeta de taller deberá ser capaz de almacenar 
los registros de datos de lugares y posiciones 
donde comienzan o terminan los períodos de tra­
bajo diarios de la misma manera que una tarjeta 
de conductor.  
348) La tarjeta de taller deberá ser capaz de almacenar 
al menos cuatro pares de estos registros.  
▼B 
4.5.4.2.11 Datos de la sesión  
349) La tarjeta de taller deberá ser capaz de almacenar 
un registro de datos de sesión, del mismo modo 
que una tarjeta de conductor.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 92  
4.5.4.2.12 Datos sobre actividades de control  
350) La tarjeta de taller deberá ser capaz de almacenar 
un registro de datos sobre actividades de control, 
del mismo modo que una tarjeta de conductor.  
4.5.4.2.13 Datos utilizados en unidades instaladas en vehículos  
351) La tarjeta de taller deberá ser capaz de almacenar 
los siguientes datos relativos a las diferentes uni­
dades instaladas en vehículos en que se utilice la 
tarjeta:  
— fecha y la hora en que comienza el período 
de uso de la unidad instalada en el vehículo 
(es decir, primera inserción de la tarjeta en la 
unidad instalada en el vehículo en el pe­
ríodo),  
— nombre del fabricante de la unidad instalada 
en el vehículo,  
— tipo de unidad instalada en el vehículo,  
— versión del  software  que lleva instalado la 
unidad instalada en el vehículo.  
▼M3 
352) La tarjeta de taller deberá ser capaz de almacenar 
al menos ocho de estos registros.  
▼M1 
4.5.4.2.14 Datos sobre lugares en tres horas de conducción acum uladas  
353) La tarjeta de taller deberá ser capaz de almacenar 
los siguientes datos relativos a la posición del 
vehículo cuando el tiempo de conducción acumu­
lado alcance un múltiplo de tres horas:  
— fecha y hora en las que el tiempo de conduc­
ción acumulado llega a un múltiplo de tres 
horas,  
— posición del vehículo,  
— la exactitud del GNSS, fecha y hora en que 
se haya determinado la posición,  
— la lectura del cuentakilómetros del vehículo.  
▼M3 
354) La tarjeta de taller deberá ser capaz de almacenar 
al menos veinticuatro de estos registros.  
▼B 
4.5.4.2.15 Datos sobre condiciones específicas  
355) La tarjeta de taller deberá ser capaz de almacenar 
los datos correspondientes a las condiciones es­
pecíficas, del mismo modo que la tarjeta de 
conductor.  
▼M3 
356) La tarjeta de taller deberá ser capaz de almacenar 
al menos cuatro de estos registros.  
4.5.4.2.16 Estado de autenticación para posiciones relacionadas  con lugares en 
los que comienzan o terminan los períodos de trabajo diarios (n o 
accesible para la versión 1 de las unidades instaladas en el ve hículo 
de segunda generación)  
356 bis) La tarjeta de taller deberá ser capaz de almacenar 
datos adicionales relativos a los lugares donde 
comienzan o terminan los períodos de trabajo 
diarios de la misma manera que una tarjeta de 
conductor.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 93  
356 ter) La memoria de la tarjeta de taller deberá ser 
capaz de almacenar cuatro pares de estos 
registros.  
4.5.4.2.17 Estado de autenticación para posiciones en las que s e alcanza el 
tiempo de conducción acumulado de tres horas (no accesible para  
la versión 1 de las unidades instaladas en el vehículo de segun da 
generación)  
356 quater ) La tarjeta de taller deberá ser capaz de almacenar 
datos adicionales relativos a la posición del ve­
hículo donde el tiempo de conducción acumulado 
alcanza un múltiplo de tres horas de la misma 
manera que una tarjeta de conductor.  
356 quinquies ) La tarjeta de taller deberá ser capaz de almacenar 
al menos veinticuatro de estos registros.  
4.5.4.2.18 Cruces de fronteras (no accesible para la versión 1 de las unidades 
instaladas en el vehículo de segunda generación);  
356 sexies ) La tarjeta de taller deberá ser capaz de almacenar 
los cruces de fronteras de la misma manera que 
una tarjeta de conductor.  
356 septies ) La memoria de la tarjeta de taller deberá ser 
capaz de almacenar al menos cuatro de estos 
registros.  
4.5.4.2.19 Operaciones de carga/descarga (no accesible para la versión 1 de las 
unidades instaladas en el vehículo de segunda generación);  
356 octies ) La tarjeta de taller deberá ser capaz de almacenar 
las operaciones de carga/descarga de la misma 
manera que una tarjeta de conductor.  
356 nonies ) La tarjeta de taller deberá ser capaz de almacenar 
ocho operaciones de carga, de descarga o de 
carga/descarga simultáneas.  
4.5.4.2.20 Entradas de tipo de carga (no accesible para la vers ión 1 de las 
unidades instaladas en el vehículo de segunda generación);  
356 decies ) La tarjeta de taller deberá ser capaz de almacenar 
las entradas de tipo de carga de la misma manera 
que una tarjeta de conductor.  
356 undecies ) La tarjeta de taller deberá ser capaz de almacenar 
al menos cuatro de estos registros.  
4.5.4.2.21 Datos adicionales de calibrado (no accesible para la  versión 1 de las 
unidades instaladas en el vehículo de segunda generación);  
356 duodecies ) La tarjeta de taller deberá ser capaz de almacenar 
datos adicionales de calibrado solo aplicables a la 
versión 2:  
— la fecha y la hora antiguas y el número de 
identificación del vehículo, que deberán ser 
exactamente los mismos valores que el alma­
cenado en el archivo elemental Calibration 
del archivo dedicado Tachograph_G2,  
— el tipo de carga por defecto introducido du­
rante este calibrado,  
— el país en el que se ha realizado el calibrado, 
así como la fecha y la hora en las que el 
receptor GNSS proporcionó la posición utili­
zada para determinar dicho país.  
356 terdecies ) La tarjeta de taller deberá ser capaz de almacenar 
al menos 255 de estos registros.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 94  
4.5.4.2.22 Configuraciones de la VU (no accesible para la versi ón 1 de las 
unidades instaladas en el vehículo de segunda generación)  
356 quaterdecies ) La tarjeta de taller deberá ser capaz de almacenar 
los ajustes específicos del tacógrafo del titular de 
la tarjeta.  
356 quindecies ) La capacidad de almacenamiento de la tarjeta de 
taller para los ajustes específicos del tacógrafo 
del titular de la tarjeta deberá ser de 3 072 bytes.  
▼B 
4.5.5  Tarjeta de control  
4.5.5.1 A p l i c a c i ó n d e l t a c ó g r a f o ( a c c e s  i b l e a l a s u n i d a ­
d e s i n s t a l a d a s e n v e h í c u l o s d e p r i m e r  a y s e ­
g u n d a g e n e r a c i ó n )  
4.5.5.1.1 Identificación de la aplicación  
357) La tarjeta de control deberá ser capaz de alma­
cenar los siguientes datos de identificación de la 
aplicación:  
— identificación de la aplicación del tacógrafo,  
— identificación del tipo de tarjeta de tacógrafo.  
4.5.5.1.2 Claves y certificados  
358) La tarjeta de control deberá ser capaz de alma­
cenar una serie de claves y certificados criptográ­
ficos, según lo especificado en el apéndice 11, 
parte A.  
4.5.5.1.3 Identificación de la tarjeta  
359) La tarjeta de control deberá ser capaz de alma­
cenar los siguientes datos relativos a la identifi­
cación de la tarjeta:  
— número de tarjeta,  
— nombre del Estado miembro y de la autoridad 
que expidieron la tarjeta, fecha de expedición,  
— fecha de comienzo de validez de la tarjeta, 
fecha de expiración de la tarjeta (en su caso).  
4.5.5.1.4 Identificación del titular de la tarjeta  
360) La tarjeta de control deberá ser capaz de alma­
cenar los siguientes datos relativos a la identifi­
cación del titular de la tarjeta:  
— nombre del organismo de control,  
— dirección del organismo de control,  
— apellido(s) del titular,  
— nombre(s) del titular,  
— idioma preferido.  
4.5.5.1.5 Datos sobre actividades de control  
361) La tarjeta de control deberá ser capaz de alma­
cenar los siguientes datos sobre actividades de 
control:  
— fecha y hora del control,  
▼M3 
— tipo de control (visualización y/o impresión 
y/o transferencia de los datos de la VU y/o 
transferencia de los datos de la tarjeta),  
▼B 
— período transferido (en su caso),  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 95  
— VRN y autoridad del Estado miembro donde 
se matriculó el vehículo controlado,  
— número de tarjeta y Estado miembro que 
haya expedido la tarjeta de conductor que 
se controla.  
362) La tarjeta de control deberá ser capaz de mante­
ner almacenados al menos 230 de estos registros.  
4.5.5.2 A p l i c a c i ó n d e t a c ó g r a f o G 2 ( n o a c  c e s i b l e p a r a l a 
u n i d a d i n s t a l a d a e n e l v e h í c u l o d e p r i  m e r a g e ­
n e r a c i ó n )  
4.5.5.2.1 Identificación de la aplicación  
363) La tarjeta de control deberá ser capaz de alma­
cenar los siguientes datos de identificación de la 
aplicación:  
— identificación de la aplicación del tacógrafo,  
— identificación del tipo de tarjeta de tacógrafo.  
▼M3 
4.5.5.2.1.1 Identificación de la aplicación adicional (no acces ible para la ver­
sión 1 de las unidades instaladas en el vehículo de segunda gen e­
ración)  
363 bis) La tarjeta de control deberá ser capaz de alma­
cenar datos adicionales de identificación de la 
aplicación solo aplicables a la versión 2.  
▼B 
4.5.5.2.2 Claves y certificados  
364) La tarjeta de control deberá ser capaz de alma­
cenar una serie de claves y certificados criptográ­
ficos, según lo especificado en el apéndice 11, 
parte B.  
4.5.5.2.3 Identificación de la tarjeta  
365) La tarjeta de control deberá ser capaz de alma­
cenar los siguientes datos relativos a la identifi­
cación de la tarjeta:  
— número de tarjeta,  
— nombre del Estado miembro y de la autoridad 
que expidieron la tarjeta, fecha de expedición,  
— fecha de comienzo de validez de la tarjeta, 
fecha de expiración de la tarjeta (en su caso).  
4.5.5.2.4 Identificación del titular de la tarjeta  
366) La tarjeta de control deberá ser capaz de alma­
cenar los siguientes datos relativos a la identifi­
cación del titular de la tarjeta:  
— nombre del organismo de control,  
— dirección del organismo de control,  
— apellido(s) del titular,  
— nombre(s) del titular,  
— idioma preferido.  
4.5.5.2.5 Datos sobre actividades de control  
367) La tarjeta de control deberá ser capaz de alma­
cenar los siguientes datos sobre actividades de 
control:  
— fecha y hora del control,  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 96  
— tipo de control (visualización y/o impresión 
y/o transferencia de los datos de la VU y/o 
transferencia de los datos de la tarjeta y/o 
control del calibrado en carretera),  
— período transferido (en su caso),  
— VRN y autoridad del Estado miembro donde 
se matriculó el vehículo controlado,  
— número de tarjeta y Estado miembro que 
haya expedido la tarjeta de conductor que 
se controla.  
368) La tarjeta de control deberá ser capaz de mante­
ner almacenados al menos 230 de estos registros.  
▼M3 
4.5.5.2.6 Configuraciones de la VU (no accesible para la versió n 1 de las 
unidades instaladas en el vehículo de segunda generación)  
368 bis) La tarjeta de control deberá ser capaz de alma­
cenar los ajustes específicos del tacógrafo del 
titular de la tarjeta.  
368 ter) La capacidad de almacenamiento de la tarjeta de 
control para los ajustes específicos del tacógrafo 
del titular de la tarjeta deberá ser de 3 072 bytes.  
▼B 
4.5.6  Tarjeta de empresa  
4.5.6.1 A p l i c a c i ó n d e l t a c ó g r a f o ( a c c e s  i b l e a l a s u n i d a ­
d e s i n s t a l a d a s e n v e h í c u l o s d e p r i m e r  a y s e ­
g u n d a g e n e r a c i ó n )  
4.5.6.1.1 Identificación de la aplicación  
369) La tarjeta de empresa deberá ser capaz de alma­
cenar los siguientes datos de identificación de la 
aplicación:  
— identificación de la aplicación del tacógrafo,  
— identificación del tipo de tarjeta de tacógrafo.  
4.5.6.1.2 Claves y certificados  
370) La tarjeta de empresa deberá ser capaz de alma­
cenar una serie de claves y certificados criptográ­
ficos, según lo especificado en el apéndice 11, 
parte A.  
4.5.6.1.3 Identificación de la tarjeta  
371) La tarjeta de la empresa deberá ser capaz de 
almacenar los siguientes datos relativos a la iden­
tificación de la tarjeta:  
— número de tarjeta,  
— nombre del Estado miembro y de la autoridad 
que expidieron la tarjeta, fecha de expedición,  
— fecha de comienzo de validez de la tarjeta, 
fecha de expiración de la tarjeta (en su caso).  
4.5.6.1.4 Identificación del titular de la tarjeta  
372) La tarjeta de la empresa deberá ser capaz de 
almacenar los siguientes datos relativos a la iden­
tificación del titular de la tarjeta:  
— nombre de la empresa,  
— dirección de la empresa.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 97  
4.5.6.1.5 Datos sobre la actividad de la empresa  
373) La tarjeta de la empresa deberá ser capaz de 
almacenar los siguientes datos sobre la actividad 
de la empresa:  
— fecha y hora de la actividad,  
— tipo de actividad (activación o desactivación 
del bloqueo de la VU, o transferencia de los 
datos de la VU o transferencia de los datos de 
la tarjeta),  
— período transferido (en su caso),  
— VRN y autoridad del Estado miembro donde 
se matriculó el vehículo,  
— número de tarjeta y Estado miembro que 
haya expedido la tarjeta (en caso de trans­
ferencia de los datos de la tarjeta).  
374) La tarjeta de la empresa deberá ser capaz de 
mantener almacenados al menos 230 de estos 
registros.  
4.5.6.2 A p l i c a c i ó n d e t a c ó g r a f o G 2 ( n o a c  c e s i b l e p a r a l a 
u n i d a d i n s t a l a d a e n e l v e h í c u l o d e p r i  m e r a g e ­
n e r a c i ó n )  
4.5.6.2.1 Identificación de la aplicación  
375) La tarjeta de empresa deberá ser capaz de alma­
cenar los siguientes datos de identificación de la 
aplicación:  
— identificación de la aplicación del tacógrafo,  
— identificación del tipo de tarjeta de tacógrafo.  
▼M3 
4.5.6.2.1.1 Identificación de la aplicación adicional (no acces ible para la ver­
sión 1 de las unidades instaladas en el vehículo de segunda gen e­
ración)  
375 bis) La tarjeta de empresa deberá ser capaz de alma­
cenar datos adicionales de identificación de la 
aplicación solo aplicables a la versión 2.  
▼B 
4.5.6.2.2 Claves y certificados  
376) La tarjeta de empresa deberá ser capaz de alma­
cenar una serie de claves y certificados criptográ­
ficos, según lo especificado en el apéndice 11, 
parte B.  
4.5.6.2.3 Identificación de la tarjeta  
377) La tarjeta de la empresa deberá ser capaz de 
almacenar los siguientes datos relativos a la iden­
tificación de la tarjeta:  
— número de tarjeta,  
— nombre del Estado miembro y de la autoridad 
que expidieron la tarjeta, fecha de expedición,  
— fecha de comienzo de validez de la tarjeta, 
fecha de expiración de la tarjeta (en su caso).  
4.5.6.2.4 Identificación del titular de la tarjeta  
378) La tarjeta de la empresa deberá ser capaz de 
almacenar los siguientes datos relativos a la iden­
tificación del titular de la tarjeta:  
— nombre de la empresa,  
— dirección de la empresa.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 98  
4.5.6.2.5 Datos sobre la actividad de la empresa  
379) La tarjeta de la empresa deberá ser capaz de 
almacenar los siguientes datos sobre la actividad 
de la empresa:  
— fecha y hora de la actividad,  
— tipo de actividad (activación o desactivación 
del bloqueo de la VU, o transferencia de los 
datos de la VU o transferencia de los datos de 
la tarjeta),  
— período transferido (en su caso),  
— VRN y autoridad del Estado miembro donde 
se matriculó el vehículo,  
— número de tarjeta y Estado miembro que 
haya expedido la tarjeta (en caso de trans­
ferencia de los datos de la tarjeta).  
380) La tarjeta de la empresa deberá ser capaz de 
mantener almacenados al menos 230 de estos 
registros.  
▼M3 
4.5.6.2.6 Configuraciones de la VU (no accesible para la versió n 1 de las 
unidades instaladas en el vehículo de segunda generación)  
380 bis) La tarjeta de empresa deberá ser capaz de alma­
cenar los ajustes específicos del tacógrafo del 
titular de la tarjeta.  
380 ter) La capacidad de almacenamiento de la tarjeta de 
empresa para los ajustes específicos del tacógrafo 
del titular de la tarjeta deberá ser de 3 072 bytes.  
▼B 
5 INSTALACIÓN DEL APARATO DE CONTROL  
5.1 Instalación  
381) El aparato de control nuevo deberá entregarse 
desactivado al instalador o al fabricante del ve­
hículo, con todos los parámetros de calibrado que 
se relacionan en el capítulo 3.21 configurados 
según sus valores válidos por defecto. Si no 
existe un valor en particular que deba conside­
rarse adecuado por defecto, los parámetros litera­
les deberán configurarse con cadenas de interro­
gantes («?») y los valores numéricos deberán 
ajustarse a cero («0»). La entrega de piezas del 
aparato de control importantes para la seguridad 
podrá limitarse, si fuera necesario, durante la cer­
tificación de seguridad.  
382) Antes de ser activado, el aparato de control ten­
drá que dar acceso a la función de calibrado, 
aunque no se encuentre en el modo de calibrado.  
▼M3 
383) Antes de su activación, el aparato de control no 
registrará ni almacenará los datos a los que se 
refieren los requisitos 102 a 133, inclusive. 
No obstante, antes de su activación, el aparato 
de control podrá registrar y almacenar los inci­
dentes de intento de violación de la seguridad de 
conformidad con el requisito 117 y los fallos del 
aparato de control de conformidad con el requi­
sito 118.  
▼B 
384) Durante la instalación, el fabricante del vehículo 
deberá preconfigurar todos los parámetros 
conocidos.  
385) Los fabricantes de vehículos o los instaladores 
deberán activar el aparato de control instalado 
como máximo antes de que el vehículo se utilice 
con arreglo al Reglamento (CE) n.  o 561/2006.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 99  
386) El aparato de control se activará automáticamente 
al insertar por primera vez una tarjeta de taller 
válida en cualquiera de sus dispositivos de inter­
faz para tarjetas.  
387) Las operaciones específicas de emparejamiento 
que se precisan entre el sensor de movimiento 
y la unidad instalada en el vehículo, si las hay, 
deberán producirse automáticamente antes o du­
rante la activación.  
388) De forma semejante, las operaciones específicas 
de acoplamiento entre el dispositivo GNSS ex­
terno y la unidad instalada en el vehículo, si 
las hay, deberán producirse automáticamente an­
tes o durante la activación.  
389) Una vez activado, el aparato de control deberá 
permitir el uso de todas las funciones y derechos 
de acceso a los datos.  
390) Una vez activado, el aparato de control deberá 
comunicar al dispositivo de comunicación a dis­
tancia los datos seguros necesarios a efectos de 
los controles en carretera selectivos.  
391) Una vez activado el aparato de control, las fun­
ciones de registro y almacenamiento serán total­
mente operativas.  
▼M3 
392) Tras la instalación, deberá efectuarse un cali­
brado. El primer calibrado podrá no incluir nece­
sariamente la introducción de la identificación de 
matriculación del vehículo (VRN y Estado miem­
bro) si el taller autorizado encargado de realizar 
el calibrado no la conoce. En estas circunstan­
cias, el propietario del vehículo podrá introducir, 
tan solo por esta vez, el VRN y el Estado miem­
bro utilizando su tarjeta de empresa antes de 
destinar el vehículo a los usos consentidos por 
el Reglamento (CE) n.  o 561/2006 (por ejemplo, 
utilizando comandos mediante una estructura de 
menú apropiada de la interfaz persona-máquina 
de la unidad instalada en el vehículo). Para ac­
tualizar o confirmar los datos introducidos deberá 
utilizarse, necesariamente, una tarjeta de taller.  
▼B 
393) La instalación de un dispositivo GNSS externo 
requiere el acoplamiento con la unidad instalada 
en el vehículo y la subsiguiente verificación de la 
información de posición del GNSS.  
394) El aparato de control deberá colocarse en el ve­
hículo de modo que el conductor pueda acceder a 
las funciones necesarias desde su asiento.  
5.2 Placa de instalación  
395) ►M3 Una vez comprobado el aparato de control 
en el momento de su instalación, se le fijará una 
placa de instalación, grabada o impresa de forma 
permanente, que sea claramente visible y de fácil 
acceso. Cuando esto no sea posible, la placa se 
fijará en el montante «B» del vehículo de manera 
que sea claramente visible. En los vehículos que 
no tengan montante «B», la placa de instalación 
debe fijarse en la zona de una puerta del vehículo 
y ser claramente visible en todos los casos. ◄  
Después de cada nueva inspección por un taller o 
instalador autorizado, la placa deberá sustituirse 
por otra nueva.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 100  
396) En la placa deberán figurar, como mínimo, los 
datos siguientes:  
— nombre y domicilio o nombre comercial del 
instalador o taller autorizado,  
— coeficiente característico del vehículo, en la 
forma «w = … imp/km»,  
— constante del aparato de control, en la forma 
«k = … imp/km»,  
— circunferencia efectiva de los neumáticos de 
las ruedas, en la forma «l = … mm»,  
— tamaño de los neumáticos,  
— fecha del informe del coeficiente caracterís­
tico del vehículo y de la medida de la circun­
ferencia efectiva de los neumáticos de las 
ruedas,  
— número de identificación del vehículo (VIN),  
— presencia (o no) de un dispositivo GNSS 
externo,  
— número de serie del dispositivo GNSS ex­
terno, en su caso,  
▼M3 
— número de serie del dispositivo de comunica­
ción a distancia, de existir este,  
▼M1 
— número de serie de todos los precintos 
existentes,  
— parte del vehículo en la que, en su caso, está 
instalado el adaptador,  
— parte del vehículo en la que está instalado el 
sensor de movimiento, si no está conectado a 
la caja de cambios o si no se utiliza un 
adaptador,  
— descripción del color del cable entre el adap­
tador y la parte del vehículo que proporciona 
sus impulsos de entrada,  
— número de serie del sensor de movimiento 
integrado del adaptador.  
▼M3 
— el tipo de carga por defecto asociado al vehí­
culo. 
▼B 
397) Únicamente en los vehículos de las categorías 
M1 y N1, equipados con un adaptador conforme 
a las disposiciones del Reglamento (CE) 
n. o 68/2009 de la Comisión (  1 ) en su versión 
modificada más reciente, y cuando no se pueda 
incluir toda la información necesaria según el 
requisito 396, se podrá utilizar una segunda placa 
adicional. En estos casos, esta placa adicional 
contendrá, al menos, la información descrita en 
los últimos cuatro guiones del requisito 396.  ▼M1 
( 1 ) Reglamento (CE) n.o 68/2009 de la Comisión, de 23 de enero de  2009, por el que se 
adapta por novena vez al progreso técnico el Reglamento (CEE) n .o 3821/85 del Consejo 
relativo al aparato de control en el sector de los transportes por carretera (DO L 21 de 
24.1.2009, p. 3).
 02016R0799 — ES — 21.08.2023 — 003.001 — 101  
De instalar esta segunda placa adicional, se co­
locará junto a la primera placa principal descrita 
en el requisito 396 o cerca de ella, y se aplicará 
el mismo nivel de protección. Asimismo, la se­
gunda placa deberá indicar el nombre, dirección 
o denominación comercial del instalador o taller 
que haya efectuado la instalación, junto con la 
fecha de instalación  
5.3 Precintos  
398) Deberán precintarse los elementos siguientes:  
— cualquier conexión que, de estar desconec­
tada, ocasionaría modificaciones o pérdidas 
de datos indetectables (esto puede aplicarse, 
por ejemplo, a la instalación del sensor de 
movimiento en la caja de cambios, al adapta­
dor para vehículos M1/N1, a la conexión del 
GNSS externo o la unidad instalada en el 
vehículo),  
— la placa de instalación, salvo que esté sujeta 
de tal modo que no pueda retirarse sin des­
truir las inscripciones que figuran en ella.  
▼M1 
398 bis) Los precintos antes mencionados deberán certifi­
carse de conformidad con la norma EN 
16882:2016.  
▼B 
399) Los precintos anteriormente mencionados podrán 
quitarse:  
— en caso de urgencia,  
— para instalar, ajustar o reparar un dispositivo 
de limitación de velocidad o cualquier otro 
dispositivo que contribuya a la seguridad vial, 
siempre que el aparato de control siga funcio­
nando de forma fiable y correcta y vuelva a 
ser precintado por un instalador o taller auto­
rizado (de acuerdo con lo dispuesto en el 
capítulo 6) inmediatamente después de que 
se haya instalado el dispositivo de limitación 
de velocidad o cualquier otro dispositivo que 
contribuya a la seguridad vial, o en el plazo 
de siete días en otros casos.  
400) Siempre que se retiren estos precintos deberá re­
dactarse y ponerse a disposición de la autoridad 
competente una justificación de esta medida.  
401) Los precintos deberán llevar un número de iden­
tificación, asignado por su fabricante. Este nú­
mero deberá ser único y distinto de cualquier 
otro número de precinto asignado por otro fabri­
cante de precintos.  
▼M1 
Este número de identificación único se define del 
siguiente modo: MMNNNNNNNN mediante 
marcado que no se pueda retirar, siendo MM 
un identificador único del fabricante (registro en 
base de datos gestionada por la CE) y 
NNNNNNNN un identificador alfanumérico del 
precinto, único en el dominio del fabricante.  
▼B 
402) Los precintos dispondrán de un espacio libre en 
el que instaladores, talleres o fabricantes de ve­
hículos puedan añadir una marca especial con 
arreglo al artículo 22, apartado 3, del Regla­
mento (UE) n.  o 165/2014.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 102  
Esta marca no deberá tapar el número de identi­
ficación del precinto.  
▼M1 
403) Los fabricantes de los precintos quedarán regis­
trados en una base de datos específica cuando 
obtengan un modelo de precinto certificado de 
conformidad con la norma EN 16882:2016 y ha­
rán públicos sus identificadores de precintos a 
través de un procedimiento que establecerá la 
Comisión Europea.  
404) Los talleres autorizados y los fabricantes de ve­
hículos utilizarán únicamente, en el marco del 
Reglamento (UE) n.  o 165/2014, precintos certifi­
cados de conformidad con la norma EN 
16882:2016 procedentes de los fabricantes de 
precintos recogidos en la base de datos mencio­
nada anteriormente.  
▼B 
405) Los fabricantes de precintos y sus distribuidores 
mantendrán registros de trazabilidad completa de 
los precintos vendidos para su uso en el marco 
del Reglamento (UE) n.  o 165/2014, que podrán 
mostrar a las autoridades nacionales competentes 
cuando sea necesario.  
406) Los identificadores únicos de los precintos debe­
rán ser visible en la placa de instalación.  
6 VERIFICACIONES, CONTROLES Y REPARACIONES  
En el capítulo 5.3 del presente anexo se definen las circunstan cias 
en las que podrán quitarse los precintos, según lo indicado en el 
artículo 22, apartado 5, del Reglamento (UE) n.  o 165/2014.  
6.1 Autorización de instaladores, talleres y fabricantes de vehículos  
Los Estados miembros aprobarán, inspeccionarán periódicamente y  
certificarán los organismos encargados de realizar:  
— instalaciones,  
— verificaciones,  
— controles,  
— reparaciones.  
Las tarjetas de taller se expedirán únicamente a los instalador es o 
talleres que hayan sido autorizados para proceder a la activaci ón o 
calibrado del aparato de control de conformidad con el presente  
anexo y que además, salvo justificación:  
— no puedan optar a recibir una tarjeta de empresa,  
— sus demás actividades profesionales no supongan un compro­
miso potencial de la seguridad general del sistema tal y como 
se exige en el apéndice 10.  
▼M1 
6.2 Verificación de componentes nuevos o reparados  
407) Cada dispositivo, tanto nuevo como reparado, 
deberá verificarse individualmente en lo que se 
refiere a su correcto funcionamiento y a la exac­
titud de sus indicaciones y registros, dentro de 
los límites establecidos en los apartados 3.2.1, 
3.2.2, 3.2.3 y 3.3.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 103  
6.3 Control de la instalación  
▼M1 
408) En el momento de su instalación en un vehículo, 
la instalación en su conjunto (incluido el aparato 
de control) deberá ajustarse a las disposiciones 
sobre tolerancias máximas establecidas en los ca­
pítulos 3.2.1, 3.2.2, 3.2.3 y 3.3. El conjunto de la 
instalación deberá precintarse de conformidad 
con el capítulo 5.3 e incluirá un calibrado.  
▼B 
6.4 Controles periódicos  
▼M3 
409) Los aparatos instalados en los vehículos se some­
terán a un control periódico cada vez que se 
repare el aparato o se efectúe cualquier modifi­
cación del coeficiente característico del vehículo 
o de la circunferencia efectiva de los neumáticos 
de las ruedas, o si la hora UTC del aparato pre­
senta un retraso o un adelanto de más de cinco 
minutos, o si cambia el VRN, y al menos en el 
plazo de dos años (veinticuatro meses) desde el 
último control.  
▼B 
410) Se controlará, en particular:  
— que el aparato de control ejecute correcta­
mente todas sus funciones, incluidas la fun­
ción de almacenamiento de datos en las tar­
jetas de tacógrafo y la comunicación con los 
lectores de comunicación a distancia,  
— que se cumpla lo dispuesto en los capítulos 
3.2.1 y 3.2.2 sobre tolerancias máximas al 
realizarse la instalación,  
— que se cumpla lo dispuesto en los capítulos 
3.2.3 y 3.3,  
— que el aparato de control lleve la marca de 
homologación,  
— que se coloquen una placa de instalación, se­
gún la define el requisito 396, y una placa 
descriptiva, según la define el requisito 225,  
— el tamaño de los neumáticos y la circunferen­
cia real de los neumáticos.  
— que no haya dispositivos de manipulación in­
tegrados en el aparato,  
— que los precintos estén correctamente coloca­
dos, en buen estado, que sus identificadores 
sean válidos (fabricante del precinto incluido 
en la base de datos de la CE) y que sus 
identificadores correspondan a las marcas de 
la placa de instalación (véase el requisito 
401). 
▼M3 
— que el identificador de la versión del mapa 
digital almacenado sea el más reciente.  
410 bis) En caso de que las autoridades nacionales com­
petentes detecten una manipulación, el vehículo 
podrá enviarse a un taller autorizado para el re­
calibrado del aparato de control.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 104  
411) Si se comprueba que se ha producido alguno de 
los incidentes enumerados en el capítulo 3.9 
(«Detección de incidentes y/o fallos») desde el 
último control y los fabricantes del tacógrafo 
y/o las autoridades nacionales lo consideran po­
tencialmente peligroso para la seguridad del apa­
rato, el taller deberá:  
a. comparar los datos de identificación del sen­
sor de movimiento conectado a la caja de 
cambios con los del sensor de movimiento 
acoplado registrados en la unidad instalada 
en el vehículo;  
b. comprobar si la información registrada en la 
placa de instalación se corresponde con la re­
gistrada en la unidad instalada en el vehículo;  
c. verificar si los números de serie y homologa­
ción del sensor de movimiento, si están im­
presos en la carcasa de este último, casan con 
la información almacenada en la memoria de 
datos del aparato de control;  
d. comparar los datos de identificación marcados 
en la placa descriptiva del dispositivo GNSS 
externo, si existe, con los almacenados en la 
memoria de datos de la unidad instalada en el 
vehículo.  
412) Los talleres consignaran en sus informes de con­
trol cualquier conclusión relativa a la existencia 
de precintos rotos o de dispositivos de manipu­
lación. Los talleres deberán conservar dichos in­
formes durante al menos dos años y los pondrán 
a disposición de la autoridad competente cuando 
se les solicite.  
413) Estos controles incluirán un calibrado y una sus­
titución preventiva de los precintos cuya instala­
ción está bajo la responsabilidad de los talleres.  
6.5 Determinación de errores  
414) La determinación de los errores de instalación y 
de uso deberá efectuarse en las condiciones si­
guientes, que se considerarán condiciones norma­
les de ensayo:  
— vehículo vacío, en condiciones normales de 
marcha,  
— presión de los neumáticos conforme a las ins­
trucciones del fabricante,  
— desgaste de los neumáticos dentro de los lí­
mites admitidos por las normas nacionales en 
vigor,  
— movimiento del vehículo:  
— este deberá desplazarse, movido por su pro­
pio motor, en línea recta por una superficie 
plana a una velocidad de 50 ± 5 km/h; la 
distancia de medición será de al menos 
1 000 m,  
— el ensayo podrá realizarse también en un 
banco de pruebas adecuado o con otros mé­
todos, si garantizan una precisión similar.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 105  
6.6 Reparaciones  
415) Los talleres deberán ser capaces de extraer los 
datos del aparato de control para facilitarlos a 
la empresa de transportes que corresponda.  
416) Los talleres autorizados deberán expedir a las 
empresas de transportes un certificado de intrans­
feribilidad de los datos cuando un fallo en el 
funcionamiento del aparato impida transferir los 
datos previamente registrados, incluso después de 
una reparación por el taller en cuestión. Los ta­
lleres conservarán en su poder durante al menos 
dos años una copia de cada certificado expedido.  
7 EXPEDICIÓN DE TARJETAS  
Los procedimientos de expedición de tarjetas que establezcan lo s 
Estados miembros deberán cumplir las condiciones siguientes:  
417) En el número de la primera tarjeta de tacógrafo 
expedida para un solicitante, el índice consecu­
tivo (en su caso), el índice de sustitución y el 
índice de renovación serán «0».  
418) Los números de todas las tarjetas de tacógrafo no 
personales que se expidan a un mismo organismo 
de control, taller o empresa de transportes empe­
zarán por los mismos 13 dígitos, y todos ellos 
tendrán un índice consecutivo diferente.  
419) Cuando se expida una tarjeta de tacógrafo en 
sustitución de otra ya existente, la nueva llevará 
el mismo número de tarjeta que la sustituida, con 
excepción del índice de sustitución, que se verá 
incrementado en una unidad (en el orden 0, …, 
9, A, …, Z).  
420) Cuando se expida una tarjeta de tacógrafo en 
sustitución de otra ya existente, la nueva tendrá 
la misma fecha de expiración que la sustituida.  
421) Cuando se expida una tarjeta de tacógrafo para 
renovar otra ya existente, la nueva llevará el 
mismo número de tarjeta que la sustituida, con 
excepción del índice de sustitución, que se pon­
drá a «0», y el índice de renovación, que se verá 
incrementado en una unidad (en el orden 0, …, 
9, A, …, Z).  
422) Cuando se sustituya una tarjeta de tacógrafo exis­
tente para modificar datos administrativos, se ob­
servarán las reglas de renovación si el cambio se 
efectúa en el mismo Estado miembro, o las reglas 
de primera expedición si el cambio lo efectúa 
otro Estado miembro.  
423) La rúbrica «apellidos del titular de la tarjeta» de 
las tarjetas de control o de taller que no sean 
personales indicará el nombre del taller o del 
organismo de control, o el nombre del instalador 
o del controlador si el Estado miembro así lo 
decide.  
424) Los Estados miembros intercambiarán datos por 
vía electrónica a fin de garantizar la unicidad de 
las tarjetas de conductor que expiden, de confor­
midad con el artículo 31 del Reglamento (UE) 
n. o 165/2014.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 106  
8 HOMOLOGACIÓN DEL APARATO DE CONTROL Y DE LAS 
TARJETAS DE TACÓGRAFO  
8.1 Generalidades  
▼M1 
A efectos del presente capítulo, por «aparato de control» se en ten­
derá el «aparato de control o sus componentes». No será preciso  
homologar el cable o cables que conectan el sensor de movimient o a 
la VU, el dispositivo GNSS externo a la VU o el dispositivo de 
comunicación a distancia externo a la VU. El papel que utilice el 
aparato de control se considerará un componente de dicho aparat o. 
Todo fabricante podrá solicitar la homologación de los componen tes 
de su aparato de control con cualquier otro tipo de componentes  de 
aparato de control, siempre que cada componente cumpla los requ i­
sitos del presente anexo. De manera alternativa, los fabricante s po­
drán también solicitar la homologación del aparato de control.  
Tal como se describe en la definición 10 del artículo 2 del pre sente 
Reglamento, existen diferentes variedades de unidades de vehícu lo 
según el montaje de sus componentes. Sea cual sea el montaje de  
los componentes de la unidad instalada en el vehículo, la anten a 
exterior y, en su caso, el separador de antena conectado al rec eptor 
GNSS o al dispositivo de comunicación a distancia no forman par te 
de la homologación de la unidad instalada en el vehículo.  
No obstante, los fabricantes que hayan obtenido la homologación  
del aparato de control mantendrán una lista pública de las ante nas y 
los separadores compatibles con cada unidad instalada en el veh í­
culo, dispositivo GNSS externo y dispositivo de comunicación a 
distancia externo homologados.  
▼B 
425) El aparato de control deberá presentarse a la ho­
mologación provisto de los eventuales dispositi­
vos complementarios integrados.  
426) La homologación del aparato de control y de las 
tarjetas de tacógrafo deberá incluir ensayos rela­
cionados con la seguridad, ensayos funcionales y 
ensayos de interoperabilidad. El resultado posi­
tivo de cada uno de estos ensayos se consignará 
en un certificado.  
▼M1 
427) Las autoridades de homologación de los Estados 
miembros no concederán el certificado de homo­
logación mientras no estén en posesión de:  
— un certificado de seguridad (si se solicita en 
el presente anexo),  
— un certificado funcional, y  
— un certificado de interoperabilidad (si se so­
licita en el presente anexo)  
para el aparato de control o la tarjeta de tacógrafo 
cuya homologación se solicite.  
▼B 
428) Todo cambio que se introduzca en el  software  o  
el hardware  del aparato de control o en la natu­
raleza de los materiales empleados en su fabrica­
ción deberá notificarse, antes de su utilización, a 
la autoridad que haya homologado el aparato. 
Dicha autoridad deberá confirmar al fabricante 
la ampliación de la homologación, o bien podrá 
exigir una actualización o confirmación del cer­
tificado funcional, de seguridad o de interopera­
bilidad.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 107  
429) Los procesos de actualización  in situ  del software  
empleado por el aparato de control precisarán la 
aprobación de la autoridad que haya homologado 
el aparato. La actualización del  software  no de­
berá alterar ni borrar los datos sobre la actividad 
del conductor que haya almacenados en el apa­
rato de control. El  software  solo podrá actuali­
zarse bajo la responsabilidad del fabricante del 
aparato.  
430) No podrá denegarse la homologación de las mo­
dificaciones del  software  destinadas a la actuali­
zación de un aparato de control previamente ho­
mologado si tales modificaciones solo se aplican 
a funciones no especificadas en el presente 
anexo. La actualización del  software  de un apa­
rato de control podrá excluir la introducción de 
juegos de caracteres nuevos, si no es técnica­
mente viable.  
▼B 
8.2 Certificado de seguridad  
431) El certificado de seguridad se entrega según lo 
dispuesto en el apéndice 10 del presente anexo. 
Los componentes del aparato de control que se 
han de certificar son la unidad instalada en el 
vehículo, el sensor de movimiento, el dispositivo 
GNSS externo y las tarjetas de tacógrafo.  
432) En el caso excepcional de que las autoridades de 
certificación de la seguridad se nieguen a certifi­
car un nuevo aparato basándose en la obsolescen­
cia de los mecanismos de seguridad, la homolo­
gación seguirá concediéndose única y exclusiva­
mente en estas circunstancias específicas y ex­
cepcionales, y siempre que no exista una solu­
ción alternativa que se ajuste al Reglamento.  
433) En esta circunstancia, el Estado miembro intere­
sado informará sin dilación a la Comisión Euro­
pea, que iniciará, en un plazo de doce meses 
civiles desde la concesión de la homologación, 
un procedimiento que garantice el restableci­
miento del nivel de seguridad a sus niveles 
originales.  
8.3 Certificado funcional  
434) Cada candidato a recibir una homologación de­
berá facilitar a la autoridad de homologación del 
Estado miembro que corresponda todo el material 
y la documentación que dicha autoridad estime 
necesario.  
435) Los fabricantes deberán aportar las muestras 
oportunas de los productos candidatos a la homo­
logación y la documentación asociada solicitada 
por los laboratorios encargados de realizar los 
ensayos funcionales en el plazo de un mes desde 
que se formule dicha solicitud. Todos los costes 
derivados de dicha solicitud correrán a cargo de 
la entidad solicitante. Los laboratorios preserva­
rán la confidencialidad de todos los datos comer­
cialmente sensibles.  
436) El certificado funcional deberá entregarse al fa­
bricante solo después de haberse superado como 
mínimo todos los ensayos funcionales especifica­
dos en el apéndice 9.  
437) El certificado funcional lo entrega la autoridad de 
homologación. Dicho certificado deberá incluir, 
además del nombre de su beneficiario y la iden­
tificación del modelo, una relación pormenori­
zada de los ensayos que se hayan realizado, junto 
con los resultados obtenidos.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 108  
438) El certificado funcional de un componente del 
aparato de control deberá indicar, asimismo, los 
números de homologación de los demás compo­
nentes compatibles del aparato de control homo­
logados sometidos a ensayo para su certificación.  
439) El certificado funcional de un componente del 
aparato de control deberá indicar, asimismo, la 
norma ISO o CEN con arreglo a la cual se 
haya certificado la interfaz funcional.  
8.4 Certificado de interoperabilidad  
440) Los ensayos de interoperabilidad las lleva a cabo 
un único laboratorio bajo la autoridad y la res­
ponsabilidad de la Comisión Europea.  
441) Dicho laboratorio deberá registrar en el orden 
cronológico de recepción las solicitudes de en­
sayo que presenten los fabricantes.  
442) Las solicitudes sólo se registrarán oficialmente 
cuando el laboratorio esté en posesión de:  
— todo el material y los documentos necesarios 
para dichos ensayos de interoperabilidad,  
— el correspondiente certificado de seguridad,  
— el correspondiente certificado funcional.  
La fecha de registro de la solicitud deberá noti­
ficarse al fabricante.  
▼M3 
443) El laboratorio no realizará ensayos de interopera­
bilidad con aparatos de control o tarjetas de tacó­
grafo que no hayan superado el análisis de vul­
nerabilidad de su evaluación de seguridad y una 
evaluación funcional, salvo en las circunstancias 
excepcionales descritas en el requisito 432.  
▼B 
444) Todo el material y los documentos facilitados por 
el fabricante que solicite ensayos de interopera­
bilidad quedarán en manos del laboratorio encar­
gado de dichos ensayos.  
445) Los ensayos de interoperabilidad deberán llevarse 
a cabo con arreglo a lo dispuesto en el apéndice 
9 del presente anexo e incluirán todos los tipos 
de aparatos de control o tarjetas de tacógrafo:  
— que dispongan de una homologación válida, o 
bien 
— que estén pendientes de ser homologados y 
dispongan de un certificado de interoperabili­
dad válido.  
446) Los ensayos de interoperabilidad deberán cubrir 
todas las generaciones de aparatos de control o 
tarjetas de tacógrafo todavía en uso.  
▼M3 
447) El laboratorio expedirá el certificado de interope­
rabilidad al fabricante solo después de que se 
hayan superado con éxito todos los ensayos de 
interoperabilidad requeridos y de que el fabri­
cante haya demostrado que se han concedido 
para el producto tanto un certificado funcional 
como un certificado de seguridad válidos, salvo 
en las circunstancias excepcionales descritas en el 
requisito 432.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 109  
448) Si uno o varios aparatos de control o tarjetas de 
tacógrafo no superan los ensayos de interopera­
bilidad, el certificado de interoperabilidad no se 
entregará hasta que el fabricante que presente la 
solicitud haya realizado las modificaciones nece­
sarias y superado dichos ensayos. El laboratorio 
deberá identificar la causa del problema con 
ayuda de los fabricantes que se vean afectados 
por dicho fallo de interoperabilidad, y procurará 
ayudar al fabricante que presente la solicitud a 
encontrar una solución técnica. Si el fabricante ha 
modificado su producto, será responsabilidad 
suya comprobar, mediante consulta a las autori­
dades pertinentes, que el certificado de seguridad 
y los certificados funcionales siguen siendo váli­
dos. 
449) El certificado de interoperabilidad tendrá una va­
lidez de seis meses y quedará revocado al finali­
zar este período si el fabricante no ha recibido el 
correspondiente certificado de homologación. El 
fabricante entrega el certificado de interoperabili­
dad a la autoridad de homologación del Estado 
miembro que ha otorgado el certificado 
funcional.  
450) Ningún elemento que pudiera haber causado un 
fallo de interoperabilidad deberá utilizarse con 
afán de lucro o para lograr una posición 
dominante.  
8.5 Certificado de homologación  
451) La autoridad de homologación del Estado miem­
bro podrá entregar el certificado de homologa­
ción del modelo en cuanto esté en posesión de 
los tres certificados necesarios.  
452) El certificado de homologación de cualquier 
componente del aparato de control deberá indi­
car, asimismo, los números de homologación de 
los demás aparatos de control interoperables 
homologados.  
453) Cuando entregue el certificado de homologación 
al fabricante, la autoridad de homologación de­
berá facilitar una copia al laboratorio encargado 
de los ensayos de interoperabilidad.  
454) El laboratorio competente para los ensayos de 
interoperabilidad deberá mantener un sitio web 
público donde se pueda consultar una relación 
actualizada de los modelos de aparato de control 
o de tarjetas de tacógrafo:  
— para los que se haya registrado una solicitud 
de ensayos de interoperabilidad,  
— que hayan recibido un certificado de intero­
perabilidad (aunque sea provisional),  
— que hayan recibido un certificado de homo­
logación.  
8.6 Procedimiento de excepción: primeros certificados de interope ­
rabilidad para los aparatos de control y las tarjetas de tacógrafo 
de segunda generación  
455) Hasta cuatro meses después de haberse certifi­
cado que unå primera pareja de aparato de con­
trol de segunda generación y tarjetas de tacógrafo 
(tarjetas de conductor, de taller, de control y de 
empresa) de segunda generación es interoperable, 
se considerarán provisionales los certificados de 
interoperabilidad entregados (incluido los prime­
ros) en relación con solicitudes registradas du­
rante este período.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 110  
456) Si al finalizar este período todos los productos 
afectados interoperan sin problemas entre sí, los 
certificados de interoperabilidad correspondientes 
adquirirán un carácter definitivo.  
457) Si durante este período se detectan fallos de in­
teroperabilidad, el laboratorio encargado de los 
ensayos de interoperabilidad deberá identificar 
las causas de los problemas con ayuda de todos 
los fabricantes implicados, y les invitará a reali­
zar las modificaciones necesarias.  
458) Si al finalizar este período persisten los proble­
mas de interoperabilidad, el laboratorio encar­
gado de los ensayos de interoperabilidad, con la 
colaboración de los fabricantes implicados y con 
las autoridades de homologación que otorguen 
los correspondientes certificados funcionales, de­
berán determinar las causas de los fallos de inter­
operabilidad y establecer las modificaciones que 
debería introducir cada uno de los fabricantes 
afectados. La búsqueda de soluciones técnicas 
deberá prolongarse un máximo de dos meses. 
Si transcurre este plazo sin haberse hallado una 
solución común, la Comisión, previa consulta al 
laboratorio encargado de los ensayos de interope­
rabilidad, deberá decidir qué aparato(s) y tarjetas 
obtienen un certificado de interoperabilidad defi­
nitivo, y fundamentar su decisión.  
459) Deberá posponerse hasta que se hayan resuelto 
los problemas de interoperabilidad iniciales cual­
quier solicitud de ensayos de interoperabilidad 
que registre el laboratorio entre el final del pe­
ríodo de cuatro meses posterior al primer certifi­
cado de interoperabilidad provisional y la fecha 
en que la Comisión adopta la decisión mencio­
nada en el requisito 455. Dichas solicitudes se 
procesarán luego en el orden cronológico en 
que se registraron.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 111  
Apéndice 1  
DICCIONARIO DE DATOS  
ÍNDICE  
1. INTRODUCCIÓN  
1.1. Enfoque de la definición de los tipos de datos  
1.2. Referencias  
2. DEFINICIONES DE TIPOS DE DATOS  
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.11b. 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 — ES — 21.08.2023 — 003.001 — 112  
2.24a. CardLoadTypeEntries  
2.24b. CardLoadTypeEntryRecord  
2.24c. CardLoadUnloadOperations  
2.24d. CardLoadUnloadRecord  
▼B 
2.25. CardMACertificate  
2.26. CardNumber  
▼M3 
2.26a. 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 — ES — 21.08.2023 — 003.001 — 113  
2.48a. CompanyCardApplicationIdentificationV2  
▼B 
2.49. CompanyCardHolderIdentification  
2.50. ControlCardApplicationIdentification  
▼M3 
2.50a. 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.60a. DownloadInterfaceVersion  
▼B 
2.61. DriverCardApplicationIdentification  
▼M3 
2.61a. DriverCardApplicationIdentificationV2  
▼B 
2.62. DriverCardHolderIdentification  
▼M1 
2.63. Reservado para usos futuros  
▼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 — ES — 21.08.2023 — 003.001 — 114  
2.74. FullCardNumberAndGeneration  
2.75. Generation  
2.76. GeoCoordinates  
2.77. GNSSAccuracy  
▼M1 
2.78. GNSSAccumulatedDriving  
2.79. GNSSAccumulatedDrivingRecord  
▼M3 
2.79a. GNSSAuthAccumulatedDriving  
2.79b. GNSSAuthStatusADRecord  
2.79c. GNSSPlaceAuthRecord  
▼B 
2.80. GNSSPlaceRecord  
2.81. HighResOdometer  
2.82. HighResTripDistance  
2.83. HolderName  
▼M3 
2.84. Reservado para usos futuros  
▼B 
2.85. K-ConstantOfRecordingEquipment  
2.86. KeyIdentifier  
2.87. KMWCKey  
2.88. Language  
2.89. LastCardDownload  
▼M3 
2.89a. LengthOfFollowingData  
▼B 
2.90. LinkCertificate  
▼M3 
2.90a. 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 — ES — 21.08.2023 — 003.001 — 115  
2.100. NationAlpha  
2.101. NationNumeric  
▼M3 
2.101a. 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.111a. NoOfLoadUnloadRecords  
▼B 
2.112. NoOfSpecificConditionRecords  
▼M3 
2.112a. NoOfLoadTypeEntryRecords  
▼B 
2.113. OdometerShort  
2.114. OdometerValueMidnight  
▼M3 
2.114a. OperationType  
▼B 
2.115. OdometerValueMidnightRecordArray  
2.116. OverspeedNumber  
▼M3 
2.116a. PlaceAuthRecord  
2.116b. PlaceAuthStatusRecord  
▼B 
2.117. PlaceRecord  
▼M3 
2.117a. PositionAuthenticationStatus  
▼B 
2.118. PreviousVehicleInfo  
2.119. PublicKey  
2.120. RecordType  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 116  
2.121. RegionAlpha  
2.122. RegionNumeric  
2.123. RemoteCommunicationModuleSerialNumber  
2.124. RSAKeyModulus  
2.125. RSAKeyPrivateExponent  
2.126. RSAKeyPublicExponent  
2.127. RtmData  
2.128. SealDataCard  
2.129. SealDataVu  
2.130. SealRecord  
2.131. SensorApprovalNumber  
2.132. SensorExternalGNSSApprovalNumber  
2.133. SensorExternalGNSSCoupledRecord  
2.134. SensorExternalGNSSIdentification  
2.135. SensorExternalGNSSInstallation  
2.136. SensorExternalGNSSOSIdentifier  
2.137. SensorExternalGNSSSCIdentifier  
2.138. SensorGNSSCouplingDate  
2.139. SensorGNSSSerialNumber  
2.140. SensorIdentification  
2.141. SensorInstallation  
2.142. SensorInstallationSecData  
2.143. SensorOSIdentifier  
2.144. SensorPaired  
2.145. SensorPairedRecord  
2.146. SensorPairingDate  
2.147. SensorSCIdentifier  
2.148. SensorSerialNumber  
2.149. Signature  
2.150. SignatureRecordArray  
2.151. SimilarEventsNumber  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 117  
2.152. SpecificConditionRecord  
2.153. SpecificConditions  
2.154. SpecificConditionType  
2.155. Speed  
2.156. SpeedAuthorised  
2.157. SpeedAverage  
2.158. SpeedMax  
▼M3 
2.158a. TachographCardsGen1Suppression  
▼B 
2.159. TachographPayload  
▼M1 
2.160. Reservado para usos futuros  
▼B 
2.161. TDesSessionKey  
2.162. TimeReal  
2.163. TyreSize  
2.164. VehicleIdentificationNumber  
2.165. VehicleIdentificationNumberRecordArray  
2.166. VehicleRegistrationIdentification  
▼M3 
2.166a. 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 — ES — 21.08.2023 — 003.001 — 118  
2.179. VuCardRecord  
2.180. VuCardRecordArray  
2.181. VuCertificate  
2.182. VuCertificateRecordArray  
2.183. VuCompanyLocksData  
2.184. VuCompanyLocksRecord  
2.185. VuCompanyLocksRecordArray  
▼M3 
2.185a. 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.192a. 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 — ES — 21.08.2023 — 003.001 — 119  
2.201. VuFaultRecord  
2.202. VuFaultRecordArray  
▼M1 
2.203. VuGNSSADRecord  
▼M3 
2.203a. VuBorderCrossingRecord  
2.203b. VuBorderCrossingRecordArray  
▼M1 
2.204. VuGNSSADRecordArray  
▼M3 
2.204a. VuGnssMaximalTimeDifference  
▼B 
2.205. VuIdentification  
2.206. VuIdentificationRecordArray  
2.207. VuITSConsentRecord  
2.208. VuITSConsentRecordArray  
▼M3 
2.208a. VuLoadUnloadRecord  
2.208b. 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 — ES — 21.08.2023 — 003.001 — 120  
2.220. VuPlaceDailyWorkPeriodRecordArray  
2.221. VuPrivateKey  
2.222. VuPublicKey  
▼M3 
2.222a. 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. Reservado para usos futuros  
2.231. Reservado para usos futuros  
▼B 
2.232. VuTimeAdjustmentRecord  
2.233. VuTimeAdjustmentRecordArray  
2.234. WorkshopCardApplicationIdentification  
▼M3 
2.234a. WorkshopCardApplicationIdentificationV2  
2.234b. WorkshopCardCalibrationAddData  
2.234c. 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 — ES — 21.08.2023 — 003.001 — 121  
2.242. VuSensorExternalGNSSCoupledRecordArray  
2.243. VuSensorPairedRecordArray  
3. DEFINICIONES DE LOS INTERVALOS DE VALORES Y TAMA­ 
ÑOS ADMISIBLES  
4. JUEGOS DE CARACTERES  
5. CODIFICACIÓN  
6. IDENTIFICADORES DE OBJETO E IDENTIFICADORES DE APLI­ 
CACIÓN  
6.1. Identificadores de objeto  
6.2. Identificadores de aplicación  
1. INTRODUCCIÓN  
En el presente apéndice se especifican diversos formatos, eleme ntos y 
estructuras para su uso en el aparato de control y las tarjetas  de tacó­
grafo.  
1.1. Enfoque de la definición de los tipos de datos  
En el presente apéndice se utiliza la Notación de Sintaxis Abst racta Uno 
(ASN.1) para definir los tipos de datos. Ello permite definir d atos sim­
ples y estructurados sin necesidad de una sintaxis específica d e trans­
ferencia (reglas de codificación), que dependerá de la aplicaci ón y del 
entorno.  
Las convenciones sobre la denominación de los tipos ASN.1 se aj ustan a 
la norma ISO/CEI 8824-1. Esto significa que:  
— siempre que sea posible, el significado de un tipo de datos s e deduce 
de los nombres seleccionados,  
— cuando un tipo de datos se compone de otros tipos, el nombre del 
tipo de datos sigue siendo una secuencia única de caracteres al fabé­
ticos que comienzan con una mayúscula, aunque las mayúsculas se  
utilizan en el nombre para transmitir el correspondiente signif icado,  
— en general, los nombres de los tipos de datos están relaciona dos con 
el nombre de los tipos de datos de los que se derivan, con el e quipo 
en que se almacenan los datos y con la función asociada a dicho s 
datos.  
Si un tipo ASN.1 ya se ha definido como parte de otra norma y e s 
pertinente para su uso en el aparato de control, entonces ese t ipo ASN.1 
se definirá en el presente apéndice.  
Para que pueda haber diferentes tipos de reglas de codificación , algunos 
tipos ASN.1 del presente apéndice están limitados por identific adores de 
intervalos de valores. Dichos identificadores se definen en el apartado 3 
y en el apéndice 2.  
1.2. Referencias  
En el presente apéndice aparecen las siguientes referencias:  
ISO 639 Código para la representación de nombres de lenguas. 
Primera edición: 1988.  
ISO 3166 Códigos para la representación de los nombres de los 
países y sus subdivisiones — Parte 1: Códigos de 
país, 2013.  
ISO 3779 Vehículos de carretera — Número de identificación 
del vehículo (VIN) — Contenido y estructura. 2009.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 122  
ISO/CEI 7816-5 Tarjetas de identificación — Tarjetas con circui tos 
integrados — Parte 5: Registro de proveedores de 
aplicaciones.  
Segunda edición: 2004.  
ISO/CEI 7816-6 Tarjetas de identificación — Tarjetas con circui tos 
integrados — Parte 6: Elementos de datos intersecto­
riales para los intercambios, 2004 + Corrigendum téc­
nico 1: 2006.  
ISO/CEI 8824-1 Tecnología de la información — Notación de Sinta xis 
Abstracta 1 (ASN.1): Especificación de la notación 
básica. 2008 + Corrigendum técnico 1: 2012 y Corri­
gendum técnico 2: 2014.  
ISO/CEI 8825-2 Tecnología de la información — Reglas de codific a­
ción ASN.1: Especificación de las Reglas de Codifi­
cación por Paquetes (PER). 2008.  
ISO/CEI 8859-1 Tecnología de la información — Conjuntos de cara c­
teres gráficos codificados con un solo byte de 8 bits 
— Parte 1: Alfabeto latino n  o 1. Primera edición: 
1998.  
ISO/CEI 8859-7 Tecnología de la información — Conjuntos de cara c­
teres gráficos codificados con un solo byte de 8 bits 
— Parte 7: Alfabeto latino/griego. 2003.  
ISO 16844-3 Vehículos de carretera — Sistemas de tacógrafo — 
Interfaz del sensor de movimiento. 2004 + Corrigen­
dum técnico 1: 2006.  
TR-03110-3 BSI / ANSSI Technical Guideline TR-03110-3, Ad­
vanced Security Mechanisms for Machine Readable 
Travel Documents and eIDAS Token — Part 3 Com­
mon Specifications, version 2.20, 3. February 2015.  
2. DEFINICIONES DE TIPOS DE DATOS  
▼M3 
En todos los tipos de datos que se describen a continuación, el  valor por 
defecto para un contenido «desconocido» o «no aplicable» consis tirá en 
rellenar el elemento de datos con bytes Hex «FF», salvo que se especi­
fique otra cosa.  
Todos los tipos de datos se utilizan para las aplicaciones de p rimera y 
segunda generación, a menos que se especifique otra cosa. Se in dican 
los tipos de datos utilizados únicamente para aplicaciones de l a versión 2 
de la segunda generación.  
En el caso de los tipos de datos de la tarjeta utilizados para las aplica­
ciones de primera y segunda generación, el tamaño especificado en el 
presente apéndice es el correspondiente a la aplicación de segu nda ge­
neración. Se da por supuesto que el lector ya conoce el tamaño de la 
aplicación de primera generación. Los números de requisito del anexo I C 
correspondientes a estos tipos de datos incluyen tanto las apli caciones de 
primera generación como las de segunda generación.  
Los tipos de datos de la tarjeta no definidos para las tarjetas  de primera 
generación no se almacenan en la aplicación de primera generaci ón de 
las tarjetas de segunda generación. En particular:  
— los números de homologación almacenados en la aplicación de p ri­
mera generación de las tarjetas de segunda generación se trunca n a 
los ocho primeros caracteres en caso necesario,  
— en la aplicación de primera generación de las tarjetas de seg unda 
generación solo se almacena el comienzo de un «TRAYECTO EN 
TRANSBORDADOR/TREN» de una condición específica «TRA­
YECTO EN TRANSBORDADOR/TREN».  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 123  
2.1. ActivityChangeInfo  
Este tipo de datos permite codificar, en una palabra de dos byt es, el 
estado de la ranura a las 00.00 horas y/o el estado del conduct or a las 
00.00 horas y/o los cambios de actividad y/o los cambios del ré gimen de 
conducción y/o los cambios del estado de la tarjeta para un con ductor o 
un segundo conductor. Este tipo de datos está relacionado con e l 
anexo 1C, requisitos 105, 266, 291, 320, 321, 343 y 344.
  
Asignación de valor  — Alineación de octeto : «scpaattttttttttt»B (16 
bits) 
Para registros en la memoria de datos (o estado de la ranura):  
«s»B Ranura:  
«0»B: CONDUCTOR,  
«1»B: SEGUNDO CONDUCTOR,  
«c»B Régimen de conducción:  
«0»B: EN SOLITARIO,  
«1»B: EN EQUIPO,  
«p»B Estado de la tarjeta de conductor (o de taller) en la 
ranura que corresponda:  
«0»B: INSERTADA, hay una tarjeta insertada,  
«1»B: NO INSERTADA, no hay tarjeta insertada (o 
se ha extraído una tarjeta),  
«aa»B Actividad:  
«00»B: PAUSA/DESCANSO,  
«01»B: DISPONIBILIDAD,  
«10»B: TRABAJO,  
«11»B: CONDUCCIÓN,  
«ttttttttttt»B Hora del cambio: minutos transcurridos desde las  
00.00 horas de ese día.  
Para registros en la tarjeta de conductor (o de taller) (y esta do del 
conductor):  
«s»B Ranura (irrelevante cuando «p» = 1, excepto en el 
caso que se cita en la nota siguiente):  
«0»B: CONDUCTOR,  
«1»B: SEGUNDO CONDUCTOR,  
«c»B Régimen de conducción (caso «p» = 0) o  
Régimen en la actividad siguiente (caso «p» = 1):  
«0»B: EN SOLITARIO,  
«0»B: INDETERMINADO  
«1»B: EN EQUIPO,  
«1»B: DETERMINADO (= entrada manual)  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 124  
«p»B Estado de la tarjeta:  
«0»B: INSERTADA, la tarjeta está insertada en un 
aparato de control,  
«1»B: NO INSERTADA, la tarjeta no está insertada 
(o se ha extraído),  
«aa»B Actividad (irrelevante cuando «p» = 1 y «c» = 0, 
excepto en el caso citado en la nota siguiente):  
«00»B: PAUSA/DESCANSO,  
«01»B: DISPONIBILIDAD,  
«10»B: TRABAJO,  
«11»B: CONDUCCIÓN,  
«ttttttttttt»B Hora del cambio: minutos transcurridos desde las  
00.00 horas de ese día.  
Nota sobre el caso «extracción de la tarjeta»:  
Cuando se extrae la tarjeta:  
— «s» es relevante e indica la ranura de la que se extrae la ta rjeta,  
— «c» debe configurarse a 0,  
— «p» debe configurarse a 1,  
— «aa» debe codificar la actividad que esté seleccionada en ese  
momento.  
Como resultado de una entrada manual, los bits «c» y «aa» de la  palabra 
(almacenada en una tarjeta) se pueden sobrescribir posteriormen te para 
reflejar la entrada.  
2.2. Address  
Una dirección.
  
codePage  especifica un conjunto de caracteres definidos en el capítulo 4. 
address  representa una dirección codificada utilizando el conjunto de 
caracteres especificado.  
2.3. AESKey  
Generación 2:  
Una clave AES con una longitud de 128, 192 o 256 bits.
  
Asignación de valor : no hay más especificaciones.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 125  
2.4. AES128Key  
Generación 2:  
Una clave AES128.
  
length  indica la longitud de la clave AES128 en octetos.  
aes128Key  es una clave AES con una longitud de 128 bits.  
Asignación de valor:  
La longitud deberá tener el valor 16.  
2.5. AES192Key  
Generación 2:  
Una clave AES192.
  
length  indica la longitud de la clave AES192 en octetos.  
aes192Key  es una clave AES con una longitud de 192 bits.  
Asignación de valor:  
La longitud deberá tener el valor 24.  
2.6. AES256Key  
Generación 2:  
Una clave AES256.
  
length  indica la longitud de la clave AES256 en octetos.  
aes256Key  es una clave AES con una longitud de 256 bits.  
Asignación de valor:  
La longitud deberá tener el valor 32.  
2.7. BCDString  
La cadena BCDString se aplica para la representación decimal de  codi­
ficación binaria (BCD). Este tipo de datos se utiliza para repr esentar un 
dígito decimal en un semiocteto (4 bits). La cadena BCDString s e basa 
en el «CharacterStringType» de la norma ISO/CEI 8824-1.
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 126  
La cadena BCDString emplea una notación «hstring». El dígito he xade­
cimal situado más a la izquierda deberá ser el semiocteto más s ignifica­
tivo del primer octeto. Para obtener un múltiplo de octetos hab rá que 
insertar semioctetos nulos a la derecha, según sea necesario, a  partir de 
la posición del semiocteto situado más a la izquierda en el pri mer octeto.  
Los dígitos permitidos son: 0, 1, .. 9.  
2.8. CalibrationPurpose  
Código que explica por qué se registró un conjunto de parámetro s de 
calibrado. Este tipo de datos está relacionado con el anexo 1B,  requisitos 
097 y 098, y con el anexo 1C, requisito 119.
  
Asignación de valor:  
Generación 1:  
«00»H valor reservado,  
«01»H activación: registro de los parámetros de calibrado 
conocidos en el momento de la activación de la 
VU, 
«02»H primera instalación: primer calibrado de la VU 
después de su activación,  
«03»H instalación: primer calibrado de la VU en el ve­
hículo actual,  
«04»H control periódico.  
Generación 2:  
Además de los valores de la generación 1, se utilizan los sigui entes:  
«05»H entrada de VRN por empresa,  
«06»H ajuste de la hora sin calibrado,  
«07»H a «7F»H RFU,  
«80»H a «FF»H específicos del fabricante.  
2.9. CardActivityDailyRecord  
Información almacenada en una tarjeta y relativa a las activida des del 
conductor en un día civil concreto. Este tipo de datos está rel acionado 
con el anexo 1C, requisitos 266, 291, 320 y 343.
  
activityPreviousRecordLength  es la longitud total del registro diario 
anterior, expresada en bytes. El valor máximo viene dado por la  longitud 
de la CADENA DE OCTETOS que contiene dichos registros (véase 
CardActivityLengthRange, apéndice 2, apartado 4). Cuando este r egistro 
es el registro diario más antiguo, el valor de activityPrevious Record­
Length debe configurarse a 0.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 127  
activityRecordLength  es la longitud total de este registro, expresada en 
bytes. El valor máximo viene dado por la longitud de la CADENA DE 
OCTETOS que contiene dichos registros.  
activityRecordDate  es la fecha del registro.  
activityDailyPresenceCounter  es el contador de presencia diaria para 
esa tarjeta en ese día.  
activityDayDistance  es la distancia total recorrida ese día.  
activityChangeInfo  es el conjunto de datos de ActivityChangeInfo co­
rrespondientes al conductor en ese día. Puede contener 1 440 va lores 
como máximo (un cambio de actividad cada minuto). Este conjunto  
incluye siempre la ActivityChangeInfo que codifica el estado de l con­
ductor a las 00.00 horas.  
2.10.  CardActivityLengthRange  
Número de bytes disponibles en una tarjeta de conductor o en un a tarjeta 
de taller para almacenar registros sobre las actividades del co nductor.
  
Asignación de valor : véase el apéndice 2.  
2.11.  CardApprovalNumber  
Número de homologación de la tarjeta.
  
Asignación de valor:  
El número de homologación deberá constar según haya sido public ado 
en el correspondiente sitio web de la Comisión Europea, es deci r, por 
ejemplo, incluyendo guiones si los lleva. El número de homologa ción 
deberá estar alineado a la izquierda.  
▼M3 
2.11a.  CardBorderCrossings  
Generación 2, versión 2:  
Información almacenada en una tarjeta de conductor o de taller y relativa 
a los cruces de fronteras del vehículo cuando este ha cruzado l a frontera 
de un país (anexo I C, requisitos 306  septies  y 356  septies ).
 
borderCrossingPointerNewestRecord  es el índice del último registro 
actualizado de cruces de fronteras de la tarjeta.  
Asignación de valor : es el número correspondiente al numerador del 
registro de cruces de fronteras de la tarjeta, y al primer regi stro de cruces 
de fronteras de la tarjeta se le asigna en la estructura el núm ero «0».  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 128  
cardBorderCrossingRecords  es el conjunto de registros de cruces de 
fronteras de la tarjeta.  
2.11b.  CardBorderCrossingRecord  
Generación 2, versión 2:  
Información almacenada en una tarjeta de conductor o de taller y relativa 
a los cruces de fronteras del vehículo cuando este ha cruzado l a frontera 
de un país (anexo I C, requisitos 147  ter, 306  sexies  y 356  sexies ).
 
countryLeft  es el país del que ha salido el vehículo, o bien «no hay 
información disponible» de conformidad con el requisito 147  ter del 
anexo I C. Se utilizará «resto del mundo» (código «FF»H NationN ume­
ric) cuando la unidad instalada en el vehículo no sea capaz de determinar 
el país en el que se encuentra el vehículo (por ejemplo, porque  el país en 
el que se encuentra no forma parte de los mapas digitales almac enados).  
CountryEntered  es el país en el que ha entrado el vehículo o el país en 
el que se encuentra el vehículo en el momento de insertar la ta rjeta. Se 
utilizará «resto del mundo» (código «FF»H NationNumeric) cuando  la 
unidad instalada en el vehículo no sea capaz de determinar el p aís en el 
que se encuentra el vehículo (por ejemplo, porque el país en el  que se 
encuentra no forma parte de los mapas digitales almacenados).  
gnssPlaceAuthRecord  contiene información relativa a la posición del 
vehículo, cuando la unidad instalada en él ha detectado que ha cruzado 
la frontera de un país, o «no hay información no disponible» de  con­
formidad con el requisito 147  ter del anexo I C, y su estado de auten­
ticación.  
vehicleOdometerValue  es el valor del cuentakilómetros cuando la uni­
dad instalada en el vehículo ha detectado que este ha cruzado l a frontera 
de un país, o «no hay información disponible» de conformidad co n el 
requisito 147  ter del anexo I C.  
▼B 
2.12.  CardCertificate  
Generación 1:  
Certificado de la clave pública de una tarjeta.
  
2.13.  CardChipIdentification  
Información almacenada en una tarjeta y relativa a la identific ación del 
circuito integrado (CI) de dicha tarjeta (anexo 1C, requisito 2 49). El 
icSerialNumber y el icManufacturingReferences identifican conju nta­
mente el chip de la tarjeta de manera única. El icSerialNumber no 
identifica el chip de la tarjeta de manera única por sí solo.
  
icSerialNumber  es el número de serie del CI.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 129  
IcManufacturingReferences  es el identificador específico del fabricante 
del CI.  
2.14.  CardConsecutiveIndex  
El índice consecutivo de una tarjeta [definición h)].
  
Asignación de valor : (véase anexo 1C, capítulo 7)  
Orden de incremento: «0, …, 9, A, …, Z, a, …, z»  
2.15.  CardControlActivityDataRecord  
Información almacenada en una tarjeta de conductor o de taller y relativa 
al último control a que ha sido sometido el conductor (anexo 1C , requi­
sitos 274, 299, 327 y 350).
  
controlType  es el tipo de control.  
controlTime  es la fecha y la hora del control.  
controlCardNumber  es el FullCardNumber del controlador que ha lle­
vado a cabo el control.  
controlVehicleRegistration  es el VRN y el nombre del Estado miembro 
donde se matriculó el vehículo que ha sido objeto del control.  
controlDownloadPeriodBegin  y controlDownloadPeriodEnd  es el pe­
ríodo transferido, en caso de transferencia.  
2.16.  CardCurrentUse  
Información acerca del uso actual de la tarjeta (anexo 1C, requ isitos 273, 
298, 326 y 349).
  
sessionOpenTime  es la hora en que se inserta la tarjeta para el uso 
actual. Este elemento se pone a cero al extraer la tarjeta.  
sessionOpenVehicle  es la identificación del vehículo que se está utili­
zando actualmente. configurada al insertar la tarjeta. Este ele mento se 
pone a cero al extraer la tarjeta.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 130  
2.17.  CardDriverActivity  
Información almacenada en una tarjeta de conductor o de taller y relativa 
a las actividades del conductor (anexo 1C, requisitos 267, 268,  292, 293, 
321 y 344).
  
activityPointerOldestDayRecord  es un elemento que señala el co­
mienzo del espacio de almacenamiento (número de bytes a partir del 
principio de la cadena) que corresponde al registro diario comp leto más 
antiguo en la cadena activityDailyRecords. El valor máximo vien e dado 
por la longitud de la cadena.  
activityPointerNewestRecord  es un elemento que señala el comienzo 
del espacio de almacenamiento (número de bytes a partir del pri ncipio de 
la cadena) que corresponde al registro diario más reciente en l a cadena 
activityDailyRecords. El valor máximo viene dado por la longitu d de la 
cadena.  
activityDailyRecords  es el espacio disponible para almacenar los datos 
sobre la actividad del conductor (estructura de datos: CardActi vityDaily­
Record) en cada uno de los días civiles en que se ha utilizado la tarjeta.  
Asignación de valor : esta cadena de octetos se va llenando cíclicamente 
con registros del tipo CardActivityDailyRecord. En el primer us o, el 
almacenamiento comienza en el primer byte de la cadena. Cada nu evo 
registro se añade al final del anterior. Cuando la cadena está llena, el 
almacenamiento continúa en el primer byte de la cadena, con ind epen­
dencia de si hay alguna interrupción dentro de un elemento de d atos. 
Antes de introducir en la cadena nuevos datos de actividad (amp liando el 
actual activityDailyRecord, o introduciendo un nuevo activityDa ilyRe­
cord) que sustituyan a datos antiguos, es preciso actualizar el  activity­
PointerOldestDayRecord para reflejar la nueva ubicación del reg istro 
diario completo más antiguo, y además es preciso poner a 0 la l ongitud 
activityPreviousRecordLength de este (nuevo) registro diario co mpleto 
más antiguo.  
2.18.  CardDrivingLicenceInformation  
Información almacenada en una tarjeta de conductor y relativa a  los 
datos correspondientes al permiso de conducir del titular de la  tarjeta 
(anexo 1C, requisitos 259 y 284).
  
drivingLicenceIssuingAuthority  es la autoridad que expidió el permiso 
de conducir.  
drivingLicenceIssuingNation  es la nacionalidad de la autoridad que 
expidió el permiso de conducir.  
drivingLicenceNumber  es el número del permiso de conducir.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 131  
2.19.  CardEventData  
Generación 1:  
Información almacenada en una tarjeta de conductor o de taller relativa a 
los incidentes asociados al titular de la tarjeta (anexo IC, re quisitos 260 y 
318).
  
CardEventData  es una secuencia de cardEventRecords ordenada por 
valor ascendente del código EventFaultType (excepto los registr os rela­
cionados con intentos de violación de la seguridad, que se incl uyen en el 
último conjunto de la secuencia).  
cardEventRecords  es un conjunto de registros de incidentes de un tipo 
en particular (o de una categoría en particular, en el caso de los intentos 
de violación de la seguridad).  
Generación 2:  
Información almacenada en una tarjeta de conductor o de taller relativa a 
los incidentes asociados al titular de la tarjeta (anexo IC, re quisitos 285 y 
341).
  
CardEventData  es una secuencia de cardEventRecords ordenada por 
valor ascendente del código EventFaultType (excepto los registr os rela­
cionados con intentos de violación de la seguridad, que se incl uyen en el 
último conjunto de la secuencia).  
cardEventRecords  es un conjunto de registros de incidentes de un tipo 
en particular (o de una categoría en particular, en el caso de los intentos 
de violación de la seguridad).  
▼B 
2.20.  CardEventRecord  
Información almacenada en una tarjeta de conductor o de taller y relativa 
a un incidente asociado al titular de la tarjeta (anexo 1C, req uisitos 261, 
286, 318 y 341).
  
eventType  es el tipo de incidente.  
eventBeginTime  es la fecha y la hora de comienzo del incidente.  
eventEndTime  es la fecha y la hora en que termina el incidente.  
eventVehicleRegistration  es el VRN y el nombre del Estado miembro 
donde se matriculó el vehículo en el que se produjo el incident e. ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 132  
2.21.  CardFaultData  
Información almacenada en una tarjeta de conductor o de taller y relativa 
a los fallos asociados al titular de la tarjeta (anexo 1C, requ isitos 263, 
288, 318 y 341).
  
CardFaultData  es una secuencia integrada por un conjunto con los 
registros de los fallos del aparato de control, seguido de un c onjunto 
con los registros de los fallos de la tarjeta.  
cardFaultRecords  es un conjunto de registros de fallos de una categoría 
determinada (del aparato de control o de la tarjeta).  
2.22.  CardFaultRecord  
Información almacenada en una tarjeta de conductor o de taller y relativa 
a un fallo asociado al titular de la tarjeta (anexo 1C, requisi tos 264, 289, 
318 y 341).
  
faultType  es el tipo de fallo.  
faultBeginTime  es la fecha y la hora de comienzo del fallo.  
faultEndTime  es la fecha y la hora en que termina el fallo.  
faultVehicleRegistration  es el VRN y el nombre del Estado miembro 
donde se matriculó el vehículo en el que ocurrió el fallo.  
2.23.  CardIccIdentification  
Información almacenada en una tarjeta y relativa a la identific ación de la 
tarjeta con circuito integrado (CI) (anexo 1C, requisito 248).
  
clockStop  es el modo de parada de reloj, tal y como se define en el 
apéndice 2.  
cardExtendedSerialNumber  es el número de serie único de la tarjeta 
con CI, tal como se especifica más en detalle mediante el tipo de datos 
ExtendedSerialNumber.  
cardApprovalNumber  es el número de homologación de la tarjeta.  
cardPersonaliserID  es la identificación personal de la tarjeta codificada 
como ManufacturerCode.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 133  
embedderIcAssemblerId  proporciona información sobre el integrador/ 
montador del CI.  
icIdentifier  es el identificador del CI que incorpora la tarjeta y del 
fabricante de dicho CI, tal y como se define en la norma ISO/CE I 
7816-6.  
2.24.  CardIdentification  
Información almacenada en una tarjeta y relativa a la identific ación de la 
tarjeta (anexo 1C, requisitos 255, 280, 310, 333, 359, 365, 371  y 377).
  
cardIssuingMemberState  es el código del Estado miembro que expide 
la tarjeta.  
cardNumber  es el número de la tarjeta.  
cardIssuingAuthorityName  es el nombre de la autoridad que ha expe­
dido la tarjeta.  
cardIssueDate  es la fecha en que se expidió la tarjeta al titular actual.  
cardValidityBegin  es la fecha correspondiente al primer día de validez 
de la tarjeta.  
cardExpiryDate  es la fecha en que termina la validez de la tarjeta.  
▼M3 
2.24a.  CardLoadTypeEntries  
Generación 2, versión 2:  
Información almacenada en una tarjeta de conductor o de taller y relativa 
a las entradas de tipo de carga cuando la tarjeta se inserta en  una unidad 
instalada en el vehículo (anexo I C, requisitos 306  undecies  y 356  unde­
cies).
 
loadTypeEntryPointerNewestRecord  es el índice del último registro 
actualizado de entradas de tipo de carga de la tarjeta.  
Asignación de valor : es el número correspondiente al numerador del 
registro de entradas de tipo de carga de la tarjeta, y al prime r registro de 
entradas de tipo de carga de la tarjeta se le asigna en la estr uctura el 
número «0».  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 134  
cardLoadTypeEntryRecords  es el conjunto de registros que contienen 
la fecha y la hora de la entrada y el tipo de carga introducido . 
2.24b.  CardLoadTypeEntryRecord  
Generación 2, versión 2:  
Información almacenada en una tarjeta de conductor o de taller y relativa 
a los cambios de tipo de carga introducidos cuando la tarjeta s e inserta 
en una unidad instalada en el vehículo (anexo I C, requisitos 3 06 decies  
y 356  decies ).
 
timeStamp  es la fecha y la hora en las que se introdujo el tipo de carga . 
loadTypeEntered  es el tipo de carga introducido.  
2.24c.  CardLoadUnloadOperations  
Generación 2, versión 2:  
Información almacenada en una tarjeta de conductor o de taller y relativa 
a las operaciones de carga/descarga del vehículo (anexo I C, re quisi­
tos 306  nonies  y 356  nonies ).
 
loadUnloadPointerNewestRecord  es el índice del último registro actua­
lizado de carga/descarga de la tarjeta.  
Asignación de valor : es el número correspondiente al numerador del 
registro de carga/descarga de la tarjeta, y al primer registro de carga/ 
descarga de la tarjeta se le asigna en la estructura el número «0». 
cardLoadUnloadRecords  es el conjunto de registros que contienen la 
indicación del tipo de operación realizada (carga, descarga o c arga y 
descarga simultáneas), la fecha y la hora en las que se ha intr oducido 
la operación de carga/descarga, la información sobre la posició n del 
vehículo y el valor del cuentakilómetros del vehículo.  
2.24d.  CardLoadUnloadRecord  
Generación 2, versión 2:  
Información almacenada en una tarjeta de conductor o de taller y relativa 
a las operaciones de carga/descarga del vehículo (anexo I C, re quisi­
tos 306  octies  y 356  octies ).
 
timeStamp  es la fecha y la hora al comienzo de la operación de carga/ 
descarga.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 135  
operationType  es el tipo de operación introducido (carga, descarga o 
carga/descarga simultáneas).  
gnssPlaceAuthRecord  contiene información relacionada con la posición 
del vehículo.  
vehicleOdometerValue  es el valor del cuentakilómetros al inicio de la 
operación de carga/descarga.  
▼B 
2.25.  CardMACertificate  
Generación 2:  
Certificado de la clave pública de la tarjeta para la autentica ción mutua 
con una VU. La estructura de este certificado se especifica en el apén­
dice 11.
  
2.26.  CardNumber  
Un número de tarjeta, según se indica en la definición g).
  
driverIdentification  es la identificación exclusiva de un conductor en un 
Estado miembro.  
ownerIdentification  es la identificación exclusiva de una empresa, un 
taller o un organismo de control en un Estado miembro.  
cardConsecutiveIndex  es el índice consecutivo de la tarjeta.  
cardReplacementIndex  es el índice de sustitución de la tarjeta.  
cardRenewalIndex  es el índice de renovación de la tarjeta.  
La primera de las dos secuencias a elegir sirve para codificar el número 
de una tarjeta de conductor, mientras que la segunda secuencia sirve para 
codificar los números de las tarjetas de taller, de control y d e empresa.  
▼M3 
2.26a.  CardPlaceAuthDailyWorkPeriod  
Generación 2, versión 2:  
Información almacenada en una tarjeta de conductor o de taller que 
proporciona el estado de autenticación de los lugares donde com ienzan 
o terminan los períodos de trabajo diarios (anexo I C, requisit os 306  ter 
y 356  ter). ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 136
  
placeAuthPointerNewestRecord  es el índice del último registro actua­
lizado del estado de autenticación de los lugares.  
Asignación de valor : es el número correspondiente al numerador del 
registro del estado de autenticación de los lugares, y al prime r registro 
del estado de autenticación de los lugares se le asigna en la e structura el 
número «0».  
placeAuthStatusRecords  es el conjunto de registros que contienen el 
estado de autenticación de los lugares introducidos.  
▼B 
2.27.  CardPlaceDailyWorkPeriod  
Información almacenada en una tarjeta de conductor o en una tar jeta de 
taller y relativa a los lugares donde comienzan y/o terminan lo s períodos 
de trabajo diarios (anexo 1C, requisitos 272, 297, 325 y 348).
  
placePointerNewestRecord  es el índice del último registro actualizado 
de un lugar.  
Asignación de valor : número que corresponde al numerador del registro 
de un lugar. Al primer registro de la estructura se le asigna e l número 
«0». 
placeRecords  es el conjunto de registros que contienen la información 
relativa a los lugares introducidos.  
2.28.  CardPrivateKey  
Generación 1:  
La clave privada de una tarjeta.
  
2.29.  CardPublicKey  
La clave pública de una tarjeta.
  
▼M1 
2.30.  CardRenewalIndex  
El índice de renovación de una tarjeta [definición i)].
  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 137  
Asignación de valor : (véase el capítulo 7 del presente anexo).  
«0» Primera expedición.  
Orden de incremento: «0, …, 9, A, …, Z»  
▼B 
2.31.  CardReplacementIndex  
El índice de sustitución de una tarjeta [definición j)].
  
Asignación de valor : (véase el capítulo VII del presente anexo).  
«0» Tarjeta original.  
Orden de incremento: «0, …, 9, A, …, Z»  
2.32.  CardSignCertificate  
Generación 2:  
Certificado de la clave pública de la tarjeta para su firma. La  estructura 
de este certificado se especifica en el apéndice 11.
  
2.33.  CardSlotNumber  
Código para distinguir entre las dos ranuras de una unidad inst alada en 
el vehículo.
  
Asignación de valor : no hay más especificaciones.  
2.34.  CardSlotsStatus  
Código que indica el tipo de tarjetas insertadas en las dos ran uras de la 
unidad instalada en el vehículo.
  
Asignación de valor  — Alineación de octeto : «ccccdddd»B  
«cccc»B Identificación del tipo de tarjeta insertada en la ranu ra 
del segundo conductor,  
«dddd»B Identificación del tipo de tarjeta insertada en la ranu ra 
del conductor,  
con los siguientes códigos de identificación:  
«0000»B no hay tarjeta insertada,  
«0001»B se ha insertado una tarjeta de conductor,  
«0010»B se ha insertado una tarjeta de taller,  
«0011»B se ha insertado una tarjeta de control,  
«0100»B se ha insertado una tarjeta de empresa.  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 138  
2.35.  CardSlotsStatusRecordArray  
Generación 2:  
El CardSlotsStatus más metadatos tal como se utilizan en el pro tocolo de 
transferencia.
  
recordType  denota el tipo de registro (CardSlotsStatus).  Asignación de 
valor : véase RecordType  
recordSize  es el tamaño de CardSlotsStatus en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es el conjunto de registros de CardSlotsStatus.  
2.36.  CardStructureVersion  
Código que indica la versión de la estructura empleada en una t arjeta de 
tacógrafo.
  
Asignación de valor : «aabb»H:  
«aa»H Índice para cambios de la estructura,  
«00»H para aplicaciones de la Generación 1  
«01»H para aplicaciones de la Generación 2  
▼M3 
«bb»H Índice para cambios relativos al uso de los elementos de 
datos definidos para la estructura que viene dada por el 
byte alto.  
«00»H para las aplicaciones de primera generación  
«00»H para la versión 1 de las aplicaciones de segunda 
generación  
«01»H para la versión 2 de las aplicaciones de segunda 
generación  
▼B 
2.37.  CardVehicleRecord  
Información almacenada en una tarjeta de conductor o de taller y relativa 
a un período de uso de un vehículo durante un día civil (anexo 1C, 
requisitos 269, 294, 322 y 345).  
Generación 1:
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 139  
vehicleOdometerBegin  es la lectura del cuentakilómetros del vehículo 
al comenzar el período de uso del vehículo.  
vehicleOdometerEnd  es la lectura del cuentakilómetros del vehículo al 
terminar el período de uso del vehículo.  
vehicleFirstUse  es la fecha y la hora en que comienza el período de uso 
del vehículo.  
vehicleLastUse  es la fecha y la hora en que termina el período de uso 
del vehículo.  
vehicleRegistration  es el VRN y el Estado miembro donde se ha ma­
triculado el vehículo.  
vuDataBlockCounter  es el valor del VuDataBlockCounter en el mo­
mento de extraer la tarjeta por última vez en el período de uso  del 
vehículo.  
Generación 2:
  
Además de los de la generación 1, se utiliza el siguiente eleme nto de 
datos:  
VehicleIdentificationNumber  es el número de identificación del vehí­
culo referido al vehículo completo.  
2.38.  CardVehiclesUsed  
Información almacenada en una tarjeta de conductor o de taller relativa a 
los vehículos empleados por el titular de la tarjeta (anexo 1C,  requisitos 
270, 295, 323 y 346).
  
vehiclePointerNewestRecord  es el índice del último registro actualizado 
del vehículo.  
Asignación de valor : número correspondiente al numerador del registro 
de un vehículo. Al primer registro de la estructura se le asign a el número 
«0». 
cardVehicleRecords  es el conjunto de registros con información sobre 
los vehículos utilizados.  
2.39.  CardVehicleUnitRecord  
Generación 2:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 140  
Información almacenada en una tarjeta de conductor o de taller y relativa 
a una unidad instalada en el vehículo que ha sido utilizada (an exo 1C, 
requisitos 303 y 351).
  
timeStamp  es el comienzo del período de uso de la unidad instalada en 
el vehículo (es decir, primera inserción de la tarjeta en la un idad ins­
talada en el vehículo en el período).  
manufacturerCode  identifica al fabricante de la unidad instalada en el 
vehículo.  
deviceID  identifica el tipo de unidad instalada en el vehículo de un 
fabricante. El valor es particular del fabricante.  
vuSoftwareVersion  es el número de la versión de  software  que lleva 
instalado la unidad instalada en el vehículo.  
2.40.  CardVehicleUnitsUsed  
▼M3 
Generación 2:  
Información almacenada en una tarjeta de conductor o de taller y relativa 
a las unidades instaladas en el vehículo utilizadas por el titu lar de la 
tarjeta (anexo I C, requisitos 304 y 352)  
▼B
 
vehicleUnitPointerNewestRecord  es el índice del último registro actua­
lizado de la unidad instalada en el vehículo.  
Asignación de valor : número correspondiente al numerador del registro 
de una unidad instalada en el vehículo. Al primer registro de l a estruc­
tura se le asigna el número «0».  
cardVehicleUnitRecords  es el conjunto de registros con información 
sobre las unidades instaladas en el vehículo utilizadas.  
2.41.  Certificate  
El certificado de una clave pública expedido por una autoridad de cer­
tificación.  
Generación 1:
  
Asignación de valor : firma digital con recuperación parcial de un Cer­
tificateContent, con arreglo al apéndice 11 «Mecanismos de segu ridad 
comunes»: firma (128 bytes) || resto de la clave pública (58 by tes) || 
referencia de la autoridad de certificación (8 bytes).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 141  
Generación 2:
  
Asignación de valor: véase el apéndice 11.  
2.42.  CertificateContent  
Generación 1:  
El contenido (sin cifrar) del certificado de una clave pública,  con arreglo 
al apéndice 11 «Mecanismos de seguridad comunes».
  
certificateProfileIdentifier  es la versión del certificado que 
corresponda.  
Asignación de valor : «01h» para esta versión.  
certificationAuthorityReference  identifica a la autoridad de certifica­
ción que expide el certificado. También es una referencia a la clave 
pública de dicha autoridad de certificación.  
certificateHolderAuthorisation  identifica los derechos que asisten al 
titular del certificado.  
certificateEndOfValidity  es la fecha en que expira administrativamente 
el certificado.  
certificateHolderReference  identifica al titular del certificado. También 
es una referencia a su clave pública.  
publicKey  es la clave pública que se certifica con este certificado.  
2.43.  CertificateHolderAuthorisation  
Identificación de los derechos que asisten al titular de un cer tificado.
  
Generación 1:  
tachographApplicationID  es el identificador de la aplicación de tacó­
grafo.  
Asignación de valor : «FFh» «54h» «41h» «43h» «48h» «4Fh». Este 
AID es un identificador propio y no registrado de la aplicación , con 
arreglo a la norma ISO/CEI 7816-5.  
equipmentType  es la identificación del tipo de equipo al que se refiere 
el certificado.  
Asignación de valor : de acuerdo con el tipo de datos EquipmentType.  0 
si el certificado es de un Estado miembro.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 142  
Generación 2:  
tachographApplicationID  denota los 6 bytes más significativos del 
identificador de aplicación (AID) de la tarjeta de tacógrafo de  generación 
2. La AID de la aplicación de la tarjeta de tacógrafo se especi fica en el 
capítulo 6.2.  
Asignación de valor:  «FF 53 4D 52 44 54».  
equipmentType  es la identificación del tipo de equipo según lo espe­
cificado para la generación 2 a que se refiere el certificado.  
Asignación de valor : de acuerdo con el tipo de datos EquipmentType.  
2.44.  CertificateRequestID  
Identificacion exclusiva de una solicitud de certificado. Tambi én puede 
utilizarse como identificador de la clave pública de una unidad  instalada 
en el vehículo si en el momento de generar el certificado se de sconoce el 
número de serie de la unidad a la que se refiere la clave.
  
requestSerialNumber  es un número de serie para la solicitud de certi­
ficado, exclusivo para el fabricante y para el mes a que se ref iere la línea 
siguiente.  
requestMonthYear  es la identificación del mes y el año de la solicitud 
de certificado.  
Asignación de valor : codificación BCD del mes (dos dígitos) y el año 
(dos últimos dígitos).  
crIdentifier : es un identificador para distinguir entre una solicitud de 
certificado y un número de serie ampliado.  
Asignación de valor : «FFh».  
manufacturerCode : es el código numérico del fabricante que solicita el 
certificado.  
2.45.  CertificationAuthorityKID  
Identificador de la clave pública de una autoridad de certifica ción (un 
Estado miembro o la autoridad de certificación europea).
  
nationNumeric  es el código numérico de nación de la autoridad de 
certificación.  
nationAlpha  es el código alfanumérico de nación de la autoridad de 
certificación.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 143  
keySerialNumber  es un número de serie para distinguir las diferentes 
claves de la autoridad de certificación en caso de que estas se  cambien.  
additionalInfo  es un campo de dos bytes para codificación adicional 
(específica de la autoridad de certificación).  
caIdentifier  es un identificador para distinguir entre el identificador de 
clave de una autoridad de certificación y otros identificadores  de clave.  
Asignación de valor : «01h».  
2.46.  CompanyActivityData  
Información almacenada en una tarjeta de empresa y relativa a l as ac­
tividades que se realizan con la tarjeta (anexo 1C, requisitos 373 y 379).
  
companyPointerNewestRecord  es el índice del último companyActi­
vityRecord actualizado.  
Asignación de valor : número correspondiente al numerador del registro 
de una actividad de la empresa. Al primer registro de la estruc tura se le 
asigna el número «0».  
companyActivityRecords  es el conjunto de todos los registros de acti­
vidades de la empresa.  
companyActivityRecord  es la secuencia de información relativa a una 
actividad de la empresa.  
companyActivityType  es el tipo de actividad de la empresa.  
companyActivityTime  es la fecha y la hora de la actividad de la 
empresa.  
cardNumberInformation  es el número de tarjeta y el nombre del Es­
tado miembro que ha expedido la tarjeta cuyos datos se han tran sferido, 
en tal caso.  
vehicleRegistrationInformation  es el VRN y el nombre del Estado 
miembro donde se ha matriculado el vehículo cuyos datos se han trans­
ferido o cuyo bloqueo se ha activado o desactivado.  
downloadPeriodBegin  y downloadPeriodEnd  es el período transferido 
de la VU, en tal caso.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 144  
2.47.  CompanyActivityType  
Código que indica una actividad realizada por una empresa hacie ndo uso 
de su tarjeta de empresa.
  
2.48.  CompanyCardApplicationIdentification  
Información almacenada en una tarjeta de empresa y relativa a l a iden­
tificación de la aplicación de la tarjeta (anexo 1C, requisitos  369 y 375).
  
typeOfTachographCardId  especifica el tipo de tarjeta utilizado.  
cardStructureVersion  especifica la versión de la estructura que se uti­
liza en la tarjeta.  
noOfCompanyActivityRecords  es el número de registros de actividades 
de la empresa que puede almacenar la tarjeta.  
▼M3 
2.48a.  CompanyCardApplicationIdentificationV2  
Generación 2, versión 2:  
Información almacenada en una tarjeta de empresa y relativa a l a iden­
tificación de la aplicación de la tarjeta (anexo I C, requisito  375  bis).
 
lengthOfFollowingData  es el número de bytes que siguen en el registro.  
vuConfigurationLengthRange  es el número de bytes de una tarjeta de 
tacógrafo disponibles para almacenar configuraciones de la VU.  
▼B 
2.49.  CompanyCardHolderIdentification  
Información almacenada en una tarjeta de empresa y relativa a l a iden­
tificación del titular de dicha tarjeta (anexo 1C, requisitos 3 72 y 378).
  
companyName  es el nombre de la empresa titular.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 145  
companyAddress  es la dirección de la empresa titular.  
cardHolderPreferredLanguage  es el idioma preferido por el titular de 
la tarjeta.  
2.50.  ControlCardApplicationIdentification  
Información almacenada en una tarjeta de control y relativa a l a identi­
ficación de la aplicación de la tarjeta (anexo 1C, requisitos 3 57 y 363).
  
typeOfTachographCardId  especifica el tipo de tarjeta utilizado.  
cardStructureVersion  especifica la versión de la estructura que se uti­
liza en la tarjeta.  
noOfControlActivityRecords  es el número de registros de actividades 
de control que puede almacenar la tarjeta.  
▼M3 
2.50a.  ControlCardApplicationIdentificationV2  
Generación 2, versión 2:  
Información almacenada en una tarjeta de control y relativa a l a identi­
ficación de la aplicación de la tarjeta (anexo I C, requisito 3 63 bis).
 
lengthOfFollowingData  es el número de bytes que siguen en el registro.  
vuConfigurationLengthRange  es el número de bytes de una tarjeta de 
tacógrafo disponibles para almacenar configuraciones de la VU.  
▼B 
2.51.  ControlCardControlActivityData  
Información almacenada en una tarjeta de control y relativa a l as acti­
vidades que se realizan con la tarjeta (anexo 1C, requisitos 36 1 y 367).
  
controlPointerNewestRecord  es el índice del último registro actuali­
zado de una actividad de control.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 146  
Asignación de valor : número correspondiente al numerador del registro 
de una actividad de control. Al primer registro de la estructur a se le 
asigna el número «0».  
controlActivityRecords  es el conjunto de todos los registros de activi­
dades de control.  
controlActivityRecord  es la secuencia de información relativa a un 
control.  
controlType  es el tipo de control.  
controlTime  es la fecha y la hora del control.  
controlledCardNumber  es el número de tarjeta y el nombre del Estado 
miembro que ha expedido la tarjeta que es objeto del control.  
controlledVehicleRegistration  es el VRN y el nombre del Estado 
miembro donde se matriculó el vehículo que ha sido objeto del c ontrol.  
controlDownloadPeriodBegin  y controlDownloadPeriodEnd  es el pe­
ríodo cuyos datos se transfieren.  
2.52.  ControlCardHolderIdentification  
Información almacenada en una tarjeta de control y relativa a l a identi­
ficación del titular de la tarjeta (anexo 1C, requisitos 360 y 366).
  
controlBodyName  es el nombre del organismo de control que corres­
ponde al titular de la tarjeta.  
controlBodyAddress  es la dirección del organismo de control que co­
rresponde al titular de la tarjeta.  
cardHolderName  es el nombre y los apellidos del titular de la tarjeta de 
control.  
cardHolderPreferredLanguage  es el idioma preferido por el titular de 
la tarjeta.  
2.53.  ControlType  
Código que indica las actividades realizadas durante un control . Este 
tipo de datos está relacionado con el anexo 1C, requisitos 126,  274, 
299, 327 y 350.
  
Generación 1:  
Asignación de valor  — Alineación de octeto : «cvpdxxxx»B (8 bits)  
«c»B transferencia de los datos de la tarjeta:  
«0»B: datos de la tarjeta no transferidos durante esta 
actividad de control,  
«1»B: datos de la tarjeta transferidos durante esta acti­
vidad de control  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 147  
«v»B transferencia de los datos de la VU:  
«0»B: datos de la VU no transferidos durante esta acti­
vidad de control,  
«1»B: datos de la VU transferidos durante esta actividad 
de control  
«p»B impresión:  
«0»B: no se imprimen datos durante esta actividad de 
control,  
«1»B: se imprimen datos durante esta actividad de con­
trol 
«d»B visualización:  
«0»B: no se visualizan datos durante esta actividad de 
control,  
«1»B: se visualizan datos durante esta actividad de con­
trol 
«xxxx»B no se utiliza  
Generación 2:  
Asignación de valor  — Alineación de octeto : «cvpdexxx»B (8 bits)  
«c»B transferencia de los datos de la tarjeta:  
«0»B: datos de la tarjeta no transferidos durante esta 
actividad de control,  
«1»B: datos de la tarjeta transferidos durante esta acti­
vidad de control  
«v»B transferencia de los datos de la VU:  
«0»B: datos de la VU no transferidos durante esta acti­
vidad de control,  
«1»B: datos de la VU transferidos durante esta actividad 
de control  
«p»B impresión:  
«0»B: no se imprimen datos durante esta actividad de 
control,  
«1»B: se imprimen datos durante esta actividad de con­
trol 
«d»B visualización:  
«0»B: no se visualizan datos durante esta actividad de 
control,  
«1»B: se visualizan datos durante esta actividad de con­
trol 
«e»B control del calibrado en carretera:  
«0»B: parámetros de calibrado no controlados durante 
esta actividad de control,  
«1»B: parámetros de calibrado controlados durante esta 
actividad de control,  
«xxx»B RFU.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 148  
2.54.  CurrentDateTime  
La fecha y la hora actuales del aparato de control.
  
Asignación de valor : no hay más especificaciones.  
2.55.  CurrentDateTimeRecordArray  
Generación 2:  
La fecha y la hora actuales más metadatos tal y como se utiliza n en el 
protocolo de transferencia.
  
recordType  denota el tipo de registro (CurrentDateTime).  Asignación 
de valor : véase RecordType.  
recordSize  es el tamaño de CurrentDateTime en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es un conjunto de registros de fecha y hora actuales.  
2.56.  DailyPresenceCounter  
Contador que está almacenado en una tarjeta de conductor o de t aller y 
que se incrementa en una unidad por cada día civil que se haya insertado 
la tarjeta en una VU. Este tipo de datos está relacionado con l os requi­
sitos 266, 299, 320 y 343 del anexo 1C.
  
Asignación de valor : número consecutivo con un valor máximo de 9 
999 y que vuelve a comenzar desde 0. La primera vez que se expi de la 
tarjeta, el número se pone a 0.  
2.57.  Datef  
Fecha expresada en un formato numérico fácil de imprimir.
  
Asignación de valor:  
yyyy año  
mm mes  
dd día  
«00000000»H denota explícitamente la ausencia de fecha.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 149  
2.58.  DateOfDayDownloaded  
Generación 2:  
La fecha y hora de la transferencia.
  
Asignación de valor : no hay más especificaciones.  
2.59.  DateOfDayDownloadedRecordArray  
Generación 2:  
La fecha y la hora de la transferencia más metadatos tal y como  se 
utilizan en el protocolo de transferencia.
  
recordType  denota el tipo de registro (DateOfDayDownloaded).  Asig­
nación de valor : véase RecordType.  
recordSize  es el tamaño de CurrentDateTime en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es el conjunto de fecha y hora de los registros de transferenc ia. 
2.60.  Distance  
Una distancia recorrida (resultado de calcular la diferencia en  kilómetros 
entre dos lecturas del cuentakilómetros del vehículo).
  
Asignación de valor : número binario sin signo. Valor en km en el 
intervalo operativo de 0 a 9 999 km.  
▼M3 
2.60a.  DownloadInterfaceVersion  
Generación 2, versión 2:  
Código que indica la versión de la interfaz de transferencia de  una 
unidad instalada en el vehículo.
  
Asignación de valor : «aabb»H:  
«aa»H «00»H: no se utiliza,  
«01»H: unidad instalada en el vehículo de segunda generación,  
«bb»H «00»H: no se utiliza,  
«01»H: versión 2 de la unidad instalada en el vehículo de segun da 
generación.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 150  
2.61.  DriverCardApplicationIdentification  
Información almacenada en una tarjeta de conductor y relativa a  la 
identificación de la aplicación de la tarjeta (anexo 1C, requis itos 253 
y 278).  
Generación 1:
  
typeOfTachographCardId  especifica el tipo de tarjeta utilizado.  
cardStructureVersion  especifica la versión de la estructura que se uti­
liza en la tarjeta.  
noOfEventsPerType  es el número de incidentes de cada tipo que puede 
registrar la tarjeta.  
noOfFaultsPerType  es el número de fallos de cada tipo que puede 
registrar la tarjeta.  
activityStructureLength  indica el número de bytes disponibles para 
almacenar registros de actividad.  
noOfCardVehicleRecords  es el número de registros del vehículo que 
caben en la tarjeta.  
noOfCardPlaceRecords  es el número de lugares que puede registrar la 
tarjeta.  
Generación 2:  
▼M1
 
Además de los de la generación 1, se utilizan los siguientes el ementos 
de datos:  
noOfGNSSCDRecords  es el número de registros GNSS de conducción 
acumulada que puede almacenar la tarjeta.  
noOfSpecificConditionRecords  es el número de registros de condicio­
nes específicas que puede almacenar la tarjeta.  
noOfCardVehicleUnitRecords  es el número de registros sobre unidades 
instaladas en vehículos que puede almacenar la tarjeta.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 151  
2.61a.  DriverCardApplicationIdentificationV2  
Generación 2, versión 2:  
Información almacenada en una tarjeta de conductor y relativa a  la 
identificación de la aplicación de la tarjeta (anexo I C, requi sito 278  bis).
 
lengthOfFollowingData  es el número de bytes que siguen en el registro.  
noOfBorderCrossingRecords  es el número de registros de cruces de 
fronteras que puede almacenar la tarjeta de conductor.  
noOfLoadUnloadRecords  es el número de registros de carga/descarga 
que puede almacenar la tarjeta de conductor.  
noOfLoadTypeEntryRecords  es el número de registros de entradas de 
tipo de carga que puede almacenar la tarjeta de conductor.  
vuConfigurationLengthRange  es el número de bytes de una tarjeta de 
tacógrafo disponibles para almacenar configuraciones de la VU.  
▼B 
2.62.  DriverCardHolderIdentification  
Información almacenada en una tarjeta de conductor y relativa a  la 
identificación del titular de la tarjeta (anexo 1C, requisitos 256 y 281).
  
cardHolderName  es el nombre y los apellidos del titular de la tarjeta de 
conductor.  
cardHolderBirthDate  es la fecha de nacimiento del titular de la tarjeta 
de conductor.  
cardHolderPreferredLanguage  es el idioma preferido por el titular de 
la tarjeta.  
▼M3 
2.63.  DSRCSecurityData  
Generación 2:  
Para la definición de este tipo de datos, véase el apéndice 11.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 152  
2.64.  EGFCertificate  
Generación 2:  
Certificado de la clave pública del dispositivo GNSS externo pa ra la 
autenticación mutua con una VU. La estructura de este certifica do se 
especifica en el apéndice 11.
  
2.65.  EmbedderIcAssemblerId  
Facilita información sobre el integrador del CI.
  
countryCode  es el código de país de dos letras del integrador del 
módulo conforme a la norma ISO 3166.  
moduleEmbedder  identifica al integrador del módulo.  
manufacturerInformation  para uso interno del fabricante.  
2.66.  EntryTypeDailyWorkPeriod  
Código para distinguir entre el comienzo y el final cuando se i ntroduce 
un período diario de trabajo, el lugar y la condición de la ent rada.  
Generación 1
  
Asignación de valor : con arreglo a la norma ISO/CEI 8824-1.  
▼M3 
Generación 2
  
Asignación de valor : con arreglo a la norma ISO/CEI 8824-1.  
▼B 
2.67.  EquipmentType  
Código para distinguir diferentes tipos de equipos para la apli cación de 
tacógrafo.
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 153  
Generación 1:
  
Asignación de valor : con arreglo a la norma ISO/CEI 8824-1.  
El valor 0 se reserva para designar a un Estado miembro o a Eur opa en 
el campo CHA de los certificados.  
Generación 2:  
▼M1 
se utilizan los mismos valores que en la generación 1, con los siguientes 
añadidos:
  
Nota 1:  Pueden utilizarse en SealRecord, si procede, los valores de 
generación 2 de la placa, el adaptador y la conexión del GNSS e xterno, 
así como los valores de generación 1 de la unidad instalada en el 
vehículo y el sensor de movimiento.  
Nota 2 : En el campo CardHolderAuthorisation (CHA) de un certificado 
de generación 2, los valores 1, 2 y 6 deben interpretarse en el  sentido de 
que indican un certificado para la autenticación mutua del tipo  de equipo 
respectivo. Para indicar el certificado respectivo para crear u na firma 
digital, deben utilizarse los valores 17, 18 o 19.  
▼B 
2.68.  EuropeanPublicKey  
Generación 1:  
La clave pública europea.
  
2.69.  EventFaultRecordPurpose  
Código que explica por qué se ha registrado un incidente o fall o.
 
Asignación de valor:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 154
  
uno de los diez incidentes o fallos más recientes (o de los die z últimos) 
el incidente de más duración ocurrido en uno de los diez último s días en que se 
hayan producido incidentes de este tipo 
uno de los cinco incidentes de más duración ocurridos en los úl timos 365 días 
el último incidente ocurrido en uno de los diez últimos días en  que se hayan 
producido incidentes de este tipo 
el incidente más grave en uno de los diez últimos días en que s e hayan producido 
incidentes de este tipo 
uno de los cinco incidentes más graves ocurridos en los últimos  365 días 
el primer incidente o fallo ocurrido tras el último calibrado 
un incidente o fallo activo/en curso 
RFU 
específica del fabricante  
2.70.  EventFaultType  
Código que califica un incidente o un fallo.
  
Asignación de valor:  
Generación 1:
  
Incidentes de carácter general, 
No hay más información, 
Inserción de una tarjeta no válida, 
Conflicto de tarjetas, 
Solapamiento temporal, 
Conducción sin tarjeta adecuada, 
Inserción de tarjeta durante la conducción, 
Error al cerrar la última sesión de la tarjeta, 
Exceso de velocidad, 
Interrupción del suministro eléctrico, 
Error en datos de movimiento, 
Conflicto de movimiento del vehículo, 
RFU,
  
Intentos de violación de la seguridad relacionados con la VU, 
No hay más información, 
Fallo de autenticación del sensor de movimiento, 
Fallo de autenticación de la tarjeta de tacógrafo, 
Cambio no autorizado del sensor de movimiento, 
Error de integridad en la entrada de los datos de la tarjeta, 
Error de integridad en los datos de usuario almacenados, 
Error en una transferencia interna de datos, 
Apertura no autorizada de la carcasa, 
Sabotaje del hardware, 
RFU,
  
Intentos de violación de la seguridad relacionados con el senso r, 
No hay más información, 
Fallo de autenticación, 
Error de integridad en los datos almacenados, 
Error en una transferencia interna de datos, 
Apertura no autorizada de la carcasa, 
Sabotaje del hardware, 
RFU,
  
Fallos del aparato de control, 
No hay más información, 
Fallo interno de la VU, 
Fallo de la impresora, 
Fallo de la pantalla, 
Fallo de transferencia, 
Fallo del sensor, 
RFU,  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 155
  
Fallos de las tarjetas, 
No hay más información, 
RFU,
  
RFU,
  
específicos del fabricante.  
▼M3 
Generación 2, versión 1:  
▼M1
 
Incidentes de carácter general, 
No hay más información, 
Inserción de una tarjeta no válida, 
Conflicto de tarjetas, 
Solapamiento temporal, 
Conducción sin tarjeta adecuada, 
Inserción de tarjeta durante la conducción, 
Error al cerrar la última sesión de la tarjeta, 
Exceso de velocidad, 
Interrupción del suministro eléctrico, 
Error en datos de movimiento, 
Conflicto de movimiento del vehículo, 
Conflicto temporal (entre el GNSS y el reloj interno de la VU),  
Error de comunicación con el dispositivo de comunicación a dist ancia, 
Ausencia de información sobre la posición procedente del recept or GNSS, 
Error de comunicación con el dispositivo GNSS externo, 
RFU,
  
Intentos de violación de la seguridad relacionados con la VU, 
No hay más información, 
Fallo de autenticación del sensor de movimiento, 
Fallo de autenticación de la tarjeta de tacógrafo, 
Cambio no autorizado del sensor de movimiento, 
Error de integridad en la entrada de los datos de la tarjeta, 
Error de integridad en los datos de usuario almacenados, 
Error en una transferencia interna de datos, 
Apertura no autorizada de la carcasa, 
Sabotaje del hardware, 
Detección de manipulación de GNSS, 
Fallo de autenticación del dispositivo GNSS externo, 
Certificado del dispositivo GNSS externo expirado, 
RFU,
  
Intentos de violación de la seguridad relacionados con el senso r, 
No hay más información, 
Fallo de autenticación, 
Error de integridad en los datos almacenados, 
Error en una transferencia interna de datos, 
Apertura no autorizada de la carcasa, 
Sabotaje del hardware, 
RFU,  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 156
  
Fallos del aparato de control, 
No hay más información, 
Fallo interno de la VU, 
Fallo de la impresora, 
Fallo de la pantalla, 
Fallo de transferencia, 
Fallo del sensor, 
Receptor GNSS interno, 
Dispositivo GNSS externo, 
Dispositivo de comunicación a distancia, 
Interfaz ITS, 
RFU,
  
Fallos de las tarjetas, 
No hay más información, 
RFU,
  
RFU,
  
específicos del fabricante.  
▼M3 
Generación 2, versión 2:  
«0x»H Incidentes de carácter general,  
«00»H No hay más información,  
«01»H Inserción de una tarjeta no válida,  
«02»H Conflicto de tarjetas,  
«03»H Solapamiento temporal,  
«04»H Conducción sin tarjeta adecuada,  
«05»H Inserción de tarjeta durante la conducción,  
«06»H Error al cerrar la última sesión de la tarjeta,  
«07»H Exceso de velocidad,  
«08»H Interrupción del suministro eléctrico,  
«09»H Error en datos de movimiento,  
«0A»H Conflicto de movimiento del vehículo,  
«0B»H Conflicto temporal (entre el GNSS y el reloj in­
terno de la VU),  
«0C»H Error de comunicación con el dispositivo de co­
municación a distancia,  
«0D»H Ausencia de información sobre la posición proce­
dente del receptor GNSS,  
«0E»H Error de comunicación con el dispositivo GNSS 
externo,  
«0F»H Anomalía del GNSS,  
«1x»H Incidentes de intento de violación de la seguridad 
relacionados con la VU,  
«10»H No hay más información,  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 157  
«11»H Fallo de autenticación del sensor de movimiento,  
«12»H Fallo de autenticación de la tarjeta de tacógrafo,  
«13»H Cambio no autorizado del sensor de movimiento,  
«14»H Error de integridad en la entrada de los datos de 
la tarjeta,  
«15»H Error de integridad en los datos de usuario 
almacenados,  
«16»H Error en una transferencia interna de datos,  
«17»H Apertura no autorizada de la carcasa,  
«18»H Sabotaje del  hardware , 
«19»H Detección de manipulación del GNSS,  
«1 A»H  Fallo de autenticación del dispositivo GNSS externo,  
«1 B»H  Certificado del dispositivo GNSS externo expirado,  
«1C»H Incoherencia entre los datos de movimiento y los 
datos almacenados de actividad del conductor,  
«1D»H a «1F»H RFU,  
«2x»H Incidentes de intento de violación de la seguridad 
relacionados con el sensor,  
«20»H No hay más información,  
«21»H Fallo de autenticación,  
«22»H Error de integridad en los datos almacenados,  
«23»H Error en una transferencia interna de datos,  
«24»H Apertura no autorizada de la carcasa,  
«25»H Sabotaje del  hardware , 
«26»H a «2F»H RFU,  
«3x»H Fallos del aparato de control,  
«30»H No hay más información,  
«31»H Fallo interno de la VU,  
«32»H Fallo de la impresora,  
«33»H Fallo de la pantalla,  
«34»H Fallo de transferencia,  
«35»H Fallo del sensor,  
«36»H Receptor GNSS interno,  
«37»H Dispositivo GNSS externo,  
«38»H Dispositivo de comunicación a distancia,  
«39»H Interfaz ITS,  
«3 A»H Fallo del sensor interno,  
«3B»H a «3F»H RFU,  
«4x»H Fallos de la tarjeta,  
«40»H No hay más información,  
«41»H a «4F»H RFU,  
«50»H a «7F»H RFU,  
«80»H a «FF»H Específico del fabricante.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 158  
2.71.  ExtendedSealIdentifier  
Generación 2:  
El identificador de precinto ampliado identifica de manera únic a un 
precinto (anexo I C, requisito 401).
  
manufacturerCode  es un código del fabricante del precinto.  Asignación 
de valor:  véase el registro de la base de datos que gestionará la Comi­
sión Europea (véase https://dtc.jrc.ec.europa.eu).  
sealIdentifier  es un identificador del precinto que es exclusivo para el 
fabricante.  Asignación de valor:  número alfanumérico, único en el do­
minio del fabricante de acuerdo con [ISO 8859-1].  
▼B 
2.72.  ExtendedSerialNumber  
Identificación exclusiva de un equipo. También puede utilizarse  como el 
identificador de clave pública de un equipo.  
Generación 1:
  
serialNumber  es el número de serie de un equipo; exclusivo para el 
fabricante, para el tipo de equipo y para el mes y año a que se  refiere la 
línea siguiente.  
monthYear  es la identificación del mes y el año de fabricación (o de la 
asignación del número de serie).  
Asignación de valor : codificación BCD del mes (dos dígitos) y el año 
(dos últimos dígitos).  
type es un identificador del tipo de equipo.  
Asignación de valor : específica del fabricante, con «FFh» valor 
reservado.  
manufacturerCode : es el código numérico que identifica al fabricante 
de un equipo homologado.  
Generación 2:
  
serialNumber  véase generación 1  
monthYear  véase generación 1  
type indica el tipo de equipo  
manufacturerCode : véase generación 1.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 159  
2.73.  FullCardNumber  
Código que identifica por completo a una tarjeta de tacógrafo.
  
cardType  es el tipo de tarjeta de tacógrafo.  
cardIssuingMemberState  es el código del Estado miembro que ha ex­
pedido la tarjeta.  
cardNumber  es el número de la tarjeta.  
2.74.  FullCardNumberAndGeneration  
Generación 2:  
Código que identifica por completo a una tarjeta de tacógrafo y  su 
generación.
  
fullcardNumber  identifica la tarjeta de tacógrafo.  
generation  indica la generación de la tarjeta de tacógrafo utilizada.  
2.75.  Generation  
Generación 2:  
Indica la generación del tacógrafo utilizado.
  
Asignación de valor:  
«00»H RFU  
«01»H Generación 1  
«02»H Generación 2  
«03»H .. «FF»H RFU  
2.76.  GeoCoordinates  
▼M3 
Generación 2:  
Las coordenadas geográficas se codifican con números enteros. E stos 
números enteros son múltiplos de la codificación ± DDMM.M para la 
latitud y ± DDDMM.M para la longitud. Aquí, ± DD y ± DDD denota n 
los grados y MM.M, los minutos. La longitud y la latitud de una  posi­
ción desconocida se representarán como Hex «7FFFFF» (deci­
mal 8388607).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 160
  
latitude  se codifica como un múltiplo (factor 10) de la representación 
± GGMM.M.  
longitude  se codifica como un múltiplo (factor 10) de la representación 
± GGGMM.M.  
2.77.  GNSSAccuracy  
Generación 2:  
La exactitud de los datos de posición del GNSS (definición eee) ). Esta 
exactitud se codifica con un número entero y es un múltiplo (fa ctor 10) 
del valor X.Y facilitado por la sentencia GSA NMEA.
  
▼M1 
2.78.  GNSSAccumulatedDriving  
Generación 2:  
Información almacenada en una tarjeta de conductor o de taller y relativa 
a la posición GNSS del vehículo si el tiempo de conducción acum ulado 
alcanza un múltiplo de tres horas (anexo IC, requisitos 306 y 3 54).
 
gnssADPointerNewestRecord  es el índice del último registro actuali­
zado de conducción acumulado del GNSS.  
Asignación de valor  es el número correspondiente al numerador del 
registro de conducción acumulado del GNSS. Al primer registro d e la 
estructura se le asigna el número ‘0’.  
gnssAccumulatedDrivingRecords  es el conjunto de registros que con­
tienen la fecha y hora en que la conducción acumulada alcanza u n 
múltiplo de tres horas e información sobre la posición del vehí culo.  
2.79.  GNSSAccumulatedDrivingRecord  
Generación 2:  
Información almacenada en una tarjeta de conductor o de taller y relativa 
a la posición GNSS del vehículo si el tiempo de conducción acum ulado 
alcanza un múltiplo de tres horas (anexo IC, requisitos 305 y 3 53).
 
timeStamp  es la fecha y la hora en las que el tiempo de conducción 
acumulado llega a un múltiplo de tres horas.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 161  
gnssPlaceRecord  contiene información relacionada con la posición del 
vehículo.  
vehicleOdometerValue  es la lectura del cuentakilómetros en el mo­
mento en que el tiempo de conducción acumulado llega a un múlti plo 
de tres horas.  
▼M3 
2.79a.  GNSSAuthAccumulatedDriving  
Generación 2, versión 2:  
Información almacenada en una tarjeta de conductor o de taller que 
proporciona el estado de autenticación de las posiciones GNSS d el ve­
hículo si el tiempo de conducción acumulado alcanza un múltiplo  de tres 
horas (anexo I C, requisitos 306  quinquies  y 356  quinquies ).
 
gnssAuthADPointerNewestRecord  es el índice del último registro ac­
tualizado del estado de autenticación de la posición GNSS.  
Asignación de valor : es el número correspondiente al numerador del 
registro del estado de autenticación de la posición GNSS, y al primer 
registro del estado de autenticación de la posición GNSS se le asigna en 
la estructura el número «0».  
gnssAuthStatusADRecords  es el conjunto de registros que contienen la 
fecha y la hora en las que la conducción acumulada alcanza un m últiplo 
de tres horas y el estado de autenticación de la posición GNSS.  
2.79b.  GNSSAuthStatusADRecord  
Generación 2, versión 2:  
Información almacenada en una tarjeta de conductor o de taller que 
proporciona el estado de autenticación de la posición GNSS del vehículo 
si el tiempo de conducción acumulado alcanza un múltiplo de tre s horas 
(anexo I C, requisitos 306  quater  y 356  quater ). Otra información rela­
cionada con la posición GNSS propiamente dicha se almacena en o tro 
registro (véase 2.79 GNSSAccumulatedDrivingRecord).
  
timeStamp  es la fecha y la hora en las que el tiempo de conducción 
acumulado alcanza un múltiplo de tres horas (fecha y hora que s on 
idénticas a las del correspondiente GNSSAccumulatedDrivingRecor d). 
authenticationStatus  es el estado de autenticación de la posición GNSS 
cuando el tiempo de conducción acumulado alcanza un múltiplo de  tres 
horas.  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 162  
2.79c.  GNSSPlaceAuthRecord  
Generación 2, versión 2:  
Información relativa a la posición GNSS del vehículo (anexo I C , requi­
sitos 108, 109, 110, 296, 306  bis, 306  quater , 306  sexies , 306  octies , 
356 bis, 356  quater , 356  sexies  y 356  octies ).
 
timeStamp  es la fecha y la hora en las que se determinó la posición 
GNSS del vehículo.  
gnssAccuracy  es la exactitud de los datos de posición GNSS.  
geoCoordinates  es la localización registrada utilizando el GNSS.  
authenticationStatus  es el estado de autenticación de la posición GNSS 
cuando esta se determinó.  
▼B 
2.80.  GNSSPlaceRecord  
Generación 2:  
Información relacionada con la posición GNSS del vehículo (anex o 1C, 
requisitos 108, 109, 110, 296, 305, 347 y 353).
  
timeStamp  es la fecha y la hora en que se determinó la posición GNSS 
del vehículo.  
gnssAccuracy  es la exactitud de los datos de posición GNSS.  
geoCoordinates  es la localización registrada utilizando el GNSS.  
2.81.  HighResOdometer  
Lectura del cuentakilómetros del vehículo: distancia acumulada que ha 
recorrido el vehículo durante su funcionamiento.
  
Asignación de valor : número binario sin signo. Valor en 1/200 km en el 
intervalo operativo de 0 a 21 055 406 km.  
2.82.  HighResTripDistance  
La distancia recorrida durante todo o parte de un viaje.
  
Asignación de valor : número binario sin signo. Valor en 1/200 km en el 
intervalo operativo de 0 a 21 055 406 km.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 163  
2.83.  HolderName  
El nombre y apellidos del titular de una tarjeta.
  
holderSurname  son los apellidos del titular. No incluye el tratamiento.  
Asignación de valor : cuando una tarjeta no es personal, holderSurname 
contiene la misma información que companyName o workshopName o 
controlBodyName.  
holderFirstNames  es el nombre y las iniciales del titular.  
▼M3 
2.84.  Reservado para usos futuros  
▼B 
Generación 2:  
Información sobre si el receptor GNSS es interno o externo a la  unidad 
instalada en el vehículo. True significa que el receptor GNSS e s interno a 
la VU. False significa que el receptor GNSS es externo.
  
2.85.  K-ConstantOfRecordingEquipment  
Constante del aparato de control [definición m)].
  
Asignación de valor : impulsos por kilómetro en el intervalo operativo 
de 0 a 64 255 impulsos/km.  
▼M1 
2.86.  KeyIdentifier  
Un identificador exclusivo de una clave pública, empleado para hacer 
referencia a dicha clave y seleccionarla. También identifica al  titular de 
la clave.
  
La primera opción sirve para hacer referencia a la clave públic a de una 
unidad instalada en el vehículo, de una tarjeta de tacógrafo o de un 
dispositivo GNSS externo.  
La segunda opción sirve para hacer referencia a la clave públic a de una 
VU (en los casos en que el número de serie de dicha VU no pueda  
conocerse en el momento de generarse el certificado).  
La tercera opción sirve para hacer referencia a la clave públic a de un 
Estado miembro.  
▼B 
2.87.  KMWCKey  
Generación 2:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 164  
Clave AES y su versión de clave asociada utilizada en el empare jamiento 
VU — sensor de movimiento. Para más detalles véase el apéndice 11.
 
kMWCKey  es la longitud de la clave AES concatenada con la clave que 
se utiliza para el emparejamiento VU — sensor de movimiento.  
keyVersion  denota la versión de la clave AES.  
2.88.  Language  
Código que identifica un idioma.
  
Asignación de valor : codificación mediante dos letras en minúsculas 
con arreglo a la norma ISO 639.  
2.89.  LastCardDownload  
Fecha y hora, almacenadas en una tarjeta de conductor, de la úl tima 
transferencia de los datos de la tarjeta (para fines distintos de los de 
control), anexo 1C, requisitos 257 y 282. Esta fecha puede ser actuali­
zada por una VU o por cualquier lector de tarjetas.
  
Asignación de valor : no hay más especificaciones.  
▼M3 
2.89a.  LengthOfFollowingData  
Generación 2, versión 2:  
Indicador de longitud para registros extensibles.
  
Asignación de valor : véase el apéndice 2.  
▼B 
2.90.  LinkCertificate  
Generación 2:  
Certificado de enlace entre pares de claves de la European Root  CA.
  
▼M3 
2.90a.  LoadType  
Generación 2, versión 2:  
Código de identificación de un tipo de carga introducido.
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 165  
Asignación de valor : 
«00»H Tipo de carga indefinido,  
«01»H Mercancías,  
«02»H Pasajeros,  
«03»H .. «FF»H RFU.  
▼B 
2.91.  L-TyreCircumference  
Circunferencia efectiva de los neumáticos de las ruedas [defini ción u)].
  
Asignación de valor : número binario sin signo, valor en 1/8 mm en el 
intervalo operativo de 0 a 8 031 mm.  
▼M1 
2.92.  MAC  
Generación 2:  
Una suma de control criptográfica de 8, 12 o 16 bytes de longit ud 
correspondiente a los conjuntos de cifrado que se especifican e n el 
apéndice 11.
  
▼B 
2.93.  ManualInputFlag  
Código que indica si el titular de una tarjeta, en el momento d e insertar 
dicha tarjeta, ha introducido o no manualmente alguna actividad  del 
conductor (anexo 1B, requisito 081, y anexo 1C, requisito 102).
  
Asignación de valor : no hay más especificaciones.  
2.94.  ManufacturerCode  
Código que identifica al fabricante de un aparato homologado.
  
El laboratorio encargado de los ensayos de interoperabilidad co nservará 
y publicará en su sitio web la lista de códigos de fabricantes (anexo 1C, 
requisito 454).  
Los códigos de fabricante se asignarán provisionalmente a los d esarro­
lladores de tacógrafos al presentar una solicitud al laboratori o competente 
para realizar los ensayos de interoperabilidad.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 166  
2.95.  ManufacturerSpecificEventFaultData  
Generación 2:  
Los códigos de error específicos del fabricante simplifican el análisis de 
errores y el mantenimiento de las VU.
  
manufacturerCode  identifica al fabricante de la unidad instalada en el 
vehículo.  
manufacturerSpecificErrorCode  es un código de error específico del 
fabricante.  
2.96.  MemberStateCertificate  
El certificado de la clave pública de un Estado miembro, expedi do por la 
autoridad de certificación europea.
  
2.97.  MemberStateCertificateRecordArray  
Generación 2:  
El certificado del Estado miembro más metadatos tal y como se u tilizan 
en el protocolo de transferencia.
  
recordType  denota el tipo de registro (MemberStateCertificate).  Asig­
nación de valor : véase RecordType.  
recordSize  es el tamaño de MemberStateCertificate en bytes.  
noOfRecords  es el número de registros que hay en el conjunto. El valor 
se pondrá a 1, ya que los certificados pueden tener diferentes longitudes.  
records  es el conjunto de certificados de Estado miembro.  
2.98.  MemberStatePublicKey  
Generación 1:  
La clave pública de un Estado miembro.
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 167  
2.99.  Name  
Un nombre.
  
codePage  especifica un conjunto de caracteres definidos en el capítulo 4, 
name  representa un nombre codificado utilizando el conjunto de cara c­
teres especificado.  
2.100.  NationAlpha  
Toda referencia alfabética a un país se realizará con arreglo a  los dis­
tintivos utilizados en los vehículos en el tráfico internaciona l (Conven­
ción de Viena sobre la circulación vial de las Naciones Unidas,  1968).
  
Los códigos alfanuméricos que identifican a los distintos paíse s figurarán 
en una lista mantenida en el sitio web del laboratorio designad o para 
realizar los ensayos de interoperabilidad, tal y como establece  en el 
anexo 1C, requisito 440.  
2.101.  NationNumeric  
Referencia numérica a un país.
  
Asignación de valor : véase tipo de datos 2.100 (NationAlpha).  
Toda modificación o actualización de la especificación alfanumé rica re­
lativa a los distintos países descrita en el párrafo anterior t endrá lugar, 
únicamente, después de que el laboratorio designado haya obteni do las 
observaciones de los fabricantes de unidades instaladas en el v ehículo de 
tacógrafos digitales e inteligentes homologados.  
▼M3 
2.101a.  NoOfBorderCrossingRecords  
Generación 2, versión 2:  
Número de registros de cruces de fronteras que puede almacenar una 
tarjeta de conductor o de taller.
  
Asignación de valor : véase el apéndice 2.  
▼B 
2.102.  NoOfCalibrationRecords  
Número de registros de calibrado que puede almacenar una tarjet a de 
taller.  
Generación 1:
  
Asignación de valor : véase el apéndice 2.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 168  
Generación 2:
  
Asignación de valor : véase el apéndice 2.  
2.103.  NoOfCalibrationsSinceDownload  
Contador que indica el número de calibrados realizados con una tarjeta 
de taller desde que se transfirieran por última vez sus datos ( anexo 1C, 
requisitos 317 y 340).
  
Asignación de valor : no hay más especificaciones.  
2.104.  NoOfCardPlaceRecords  
Número de registros de lugares que puede almacenar una tarjeta de 
conductor o de taller.  
Generación 1:
  
Asignación de valor : véase el apéndice 2.  
Generación 2:
  
Asignación de valor : véase el apéndice 2.  
2.105.  NoOfCardVehicleRecords  
Número de registros sobre vehículos usados que puede almacenar una 
tarjeta de conductor o de taller.
  
Asignación de valor : véase el apéndice 2.  
2.106.  NoOfCardVehicleUnitRecords  
Generación 2:  
Número de registros sobre unidades instalas en vehículos usados  que 
puede almacenar una tarjeta de conductor o de taller.
  
Asignación de valor : véase el apéndice 2.  
2.107.  NoOfCompanyActivityRecords  
Número de registros sobre actividades de empresa que puede alma cenar 
una tarjeta de empresa.
  
Asignación de valor : véase el apéndice 2.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 169  
2.108.  NoOfControlActivityRecords  
Número de registros sobre actividades de control que puede alma cenar 
una tarjeta de control.
  
Asignación de valor : véase el apéndice 2.  
2.109.  NoOfEventsPerType  
Número de incidentes de cada tipo que puede almacenar una tarje ta.
 
Asignación de valor : véase el apéndice 2.  
2.110.  NoOfFaultsPerType  
Número de fallos de cada tipo que puede almacenar una tarjeta.
  
Asignación de valor : véase el apéndice 2.  
▼M1 
2.111.  NoOfGNSSADRecords  
Generación 2:  
Número de registros GNSS de conducción acumulada que puede alma ­
cenar una tarjeta.
  
Asignación de valor:  véase el apéndice 2.  
▼M3 
2.111a.  NoOfLoadUnloadRecords  
Generación 2, versión 2:  
Número de registros de carga/descarga que puede almacenar una t arjeta.
  
Asignación de valor : véase el apéndice 2.  
▼B 
2.112.  NoOfSpecificConditionRecords  
Generación 2:  
Número de registros de condición específica que puede almacenar  una 
tarjeta.
  
Asignación de valor : véase el apéndice 2.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 170  
2.112a.  NoOfLoadTypeEntryRecords  
Generación 2, versión 2:  
Número de registros de entradas de tipo de carga que puede alma cenar 
una tarjeta de conductor o de taller.
  
Asignación de valor : véase el apéndice 2.  
▼B 
2.113.  OdometerShort  
Lectura del cuentakilómetros del vehículo en forma abreviada.
  
Asignación de valor : número binario sin signo. Valor en km en el 
intervalo operativo de 0 a 9 999 999 km.  
2.114.  OdometerValueMidnight  
La lectura del cuentakilómetros del vehículo a medianoche de un  día 
determinado (anexo 1B, requisito 090, y anexo 1C, requisito 113 ).
 
Asignación de valor : no hay más especificaciones.  
▼M3 
2.114a.  OperationType  
Generación 2, versión 2:  
Código de identificación de un tipo de operación introducido.
  
Asignación de valor : 
«00»H RFU,  
«01»H Operación de carga,  
«02»H Operación de descarga,  
«03»H Operación de carga/descarga simultáneas,  
«04»H .. «FF»H RFU.  
▼B 
2.115.  OdometerValueMidnightRecordArray  
Generación 2:  
El OdometerValueMidnight más metadatos tal como se utilizan en el 
protocolo de transferencia.
  
recordType  denota el tipo de registro (OdometerValueMidnight).  Asig­
nación de valor : véase RecordType.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 171  
recordSize  es el tamaño de OdometerValueMidnight en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es el conjunto de registros de OdometerValueMidnight.  
2.116.  OverspeedNumber  
Número de incidentes de exceso de velocidad ocurridos desde el último 
control del exceso de velocidad.
  
Asignación de valor:  0 significa que no se ha producido ningún inci­
dente de exceso de velocidad desde el último control, 1 signifi ca que se 
ha producido un incidente de exceso de velocidad desde el últim o control 
…255 significa que se han producido 255 o más incidentes de exc eso de 
velocidad desde el último control.  
▼M3 
2.116a.  PlaceAuthRecord  
Información relativa al lugar donde comienza o termina un perío do de 
trabajo diario (anexo I C, requisitos 108, 271, 296, 324 y 347) . 
Generación 2, versión 2:
  
entryTime  es una fecha y una hora relacionadas con la entrada.  
entryTypeDailyWorkPeriod  es el tipo de entrada.  
dailyWorkPeriodCountry  es el país introducido.  
dailyWorkPeriodRegion  es la región introducida.  
vehicleOdometerValue  es el valor del cuentakilómetros en el momento 
de introducir el lugar.  
entryGNSSPlaceAuthRecord  es la localización registrada, el estado de 
autenticación del GNSS y la hora.  
2.116b.  PlaceAuthStatusRecord  
Generación 2, versión 2:  
Información almacenada en una tarjeta de conductor o de taller que 
proporciona el estado de autenticación de un lugar donde comien za o 
termina un período de trabajo diario (anexo I C, requisitos 306  bis 
y 356  bis). Otra información relacionada con el lugar propiamente dicho 
se almacena en otro registro (véase 2.117 PlaceRecord).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 172
  
entryTime  es una fecha y una hora relacionadas con la entrada (fecha y 
hora que son idénticas a las del correspondiente PlaceRecord).  
authenticationStatus  es el estado de autenticación de la posición GNSS 
registrada.  
▼B 
2.117.  PlaceRecord  
Información relativa al lugar donde comienza o termina un perío do de 
trabajo diario (anexo 1C, requisitos 108, 271, 296, 324 y 347).  
Generación 1:
  
entryTime  es una fecha y una hora relacionadas con la entrada.  
entryTypeDailyWorkPeriod  es el tipo de entrada.  
dailyWorkPeriodCountry  es el país introducido.  
dailyWorkPeriodRegion  es la región introducida.  
vehicleOdometerValue  es la lectura del cuentakilómetros en el mo­
mento de introducir el lugar.  
Generación 2:
  
Además de los de la generación 1, se utiliza el siguiente compo nente:  
entryGNSSPlaceRecord  es la localización y la hora registrada.  
▼M3 
2.117a.  PositionAuthenticationStatus  
Generación 2, versión 2:
  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 173  
Asignación de valor  (véase el apéndice 12):  
«00»H No autenticado (véase el apéndice 12, requi­
sito GNS_39)  
«01»H Autenticado (véase el apéndice 12, requisito GNS_39)  
«02»H .. «FF»H RFU.  
▼B 
2.118.  PreviousVehicleInfo  
Información relativa al vehículo que utilizara previamente un c onductor 
al insertar su tarjeta en una unidad instalada en el vehículo ( anexo 1B, 
requisito 081, y anexo 1C, requisito 102).  
Generación 1:
  
vehicleRegistrationIdentification  es el VRN y el nombre del Estado 
miembro donde se matriculara el vehículo.  
cardWithdrawalTime  es la fecha y la hora de extracción de la tarjeta.  
Generación 2:
  
Además de los de la generación 1, se utiliza el siguiente eleme nto de 
datos:  
vuGeneration  indica la generación de la unidad instalada en el vehículo.  
2.119.  PublicKey  
Generación 1:  
Una clave RSA pública.
  
rsaKeyModulus  es el módulo del par de claves.  
rsaKeyPublicExponent  es el exponente público del par de claves.  
2.120.  RecordType  
Generación 2:  
Referencia a un tipo de registro. Este tipo de datos se utiliza  en Recor­
dArrays.
  ▼M3
02016R0799 — ES — 21.08.2023 — 003.001 — 174  
Asignación de valor:
  
► (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, 
RFU, ◄ 
específicos del fabricante.  
2.121.  RegionAlpha  
Referencia alfabética a una región perteneciente a un país espe cificado.
  
Generación 1:  
Asignación de valor:
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 175  
Generación 2:  
Los códigos alfabéticos que identifican a las distintas regione s figurarán 
en una lista mantenida en el sitio web del laboratorio designad o para 
realizar los ensayos de interoperabilidad.  
2.122.  RegionNumeric  
Referencia numérica a una región perteneciente a un país especi ficado.
  
Generación 1:  
Asignación de valor:
  
Generación 2:  
Los códigos numéricos que identifican a las distintas regiones figurarán 
en una lista mantenida en el sitio web del laboratorio designad o para 
realizar los ensayos de interoperabilidad.  
2.123.  RemoteCommunicationModuleSerialNumber  
Generación 2:  
número de serie del módulo de comunicación a distancia,
  
2.124.  RSAKeyModulus  
Generación 1:  
El módulo de un par de claves RSA.
  
Asignación de valor : no especificado.  
2.125.  RSAKeyPrivateExponent  
Generación 1:  
El exponente privado de un par de claves RSA.
  
Asignación de valor : no especificado.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 176  
2.126.  RSAKeyPublicExponent  
Generación 1:  
El exponente público de un par de claves RSA.
  
Asignación de valor : no especificado.  
2.127.  RtmData  
Generación 2:  
Para la definición de este tipo de datos, véase el apéndice 14.  
2.128.  SealDataCard  
Generación 2:  
Este tipo de datos almacena información sobre los precintos col ocados en 
los distintos componentes de un vehículo y se destina al almace namiento 
en una tarjeta. Este tipo de datos está relacionado con el anex o 1C, 
requisito 337.
  
noOfSealRecords  es el número de registros que hay en sealRecords.  
sealRecords  es un conjunto de registros sobre precintos.  
2.129.  SealDataVu  
Generación 2:  
Este tipo de datos almacena información sobre los precintos col ocados en 
los distintos componentes de un vehículo y se destina al almace namiento 
en una unidad instalada en el vehículo.
  
sealRecords  es un conjunto de registros sobre precintos. Si hay menos 
de cinco precintos, el valor de EquipmentType en todos los seal Records 
no utilizados se pondrá a 16, es decir, sin utilizar.  
2.130.  SealRecord  
Generación 2:  
Este tipo de datos almacena información sobre un precinto coloc ado en 
un componente. Este tipo de datos está relacionado con el anexo  1C, 
requisito 337.
  
equipmentType  identifica el tipo de aparato en que se coloca el 
precinto.  
extendedSealIdentifier  es el identificador del precinto colocado en el 
aparato.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 177  
2.131.  SensorApprovalNumber  
Número de homologación del sensor.  
Generación 1:
  
Asignación de valor : no especificado.  
Generación 2:
  
Asignación de valor:  
El número de homologación deberá constar según haya sido public ado 
en el correspondiente sitio web de la Comisión Europea, es deci r, por 
ejemplo, incluyendo guiones si los lleva. El número de homologa ción 
deberá estar alineado a la izquierda.  
2.132.  SensorExternalGNSSApprovalNumber  
Generación 2:  
número de homologación del dispositivo GNSS externo.
  
Asignación de valor:  
El número de homologación deberá constar según haya sido public ado 
en el correspondiente sitio web de la Comisión Europea, es deci r, por 
ejemplo, incluyendo guiones si los lleva. El número de homologa ción 
deberá estar alineado a la izquierda.  
2.133.  SensorExternalGNSSCoupledRecord  
Generación 2:  
Información almacenada en una unidad instalada en el vehículo y  relativa 
a la identificación del sensor de movimiento acoplado a dicha u nidad 
(anexo 1C, requisito 100).
  
sensorSerialNumber  es el número de serie del dispositivo GNSS ex­
terno que está acoplado a la VU.  
sensorApprovalNumber  es el número de homologación de este dispo­
sitivo GNSS externo.  
sensorCouplingDate  es la fecha de acoplamiento del dispositivo GNSS 
externo con la VU.  
2.134.  SensorExternalGNSSIdentification  
Generación 2:  
Información relativa a la identificación del dispositivo GNSS e xterno 
(anexo 1C, requisito 98).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 178
  
sensorSerialNumber  es el número de serie ampliado del dispositivo 
GNSS externo.  
sensorApprovalNumber  es el número de homologación del dispositivo 
GNSS externo.  
sensorSCIdentifier  es el identificador del componente de seguridad del 
dispositivo GNSS externo.  
sensorOSIdentifier  es el identificador del sistema operativo del dispo­
sitivo GNSS externo.  
2.135.  SensorExternalGNSSInstallation  
Generación 2:  
Información almacenada en un dispositivo GNSS externo y relativ a a la 
instalación del sensor GNSS externo (anexo 1C, requisito 123).
  
sensorCouplingDateFirst  es la fecha del primer acoplamiento del dis­
positivo GNSS externo con una VU.  
firstVuApprovalNumber  es el número de homologación de la primera 
VU acoplada con el dispositivo GNSS externo.  
firstVuSerialNumber  es el número de serie de la primera VU acoplada 
con el dispositivo GNSS externo.  
sensorCouplingDateCurrent  es la fecha del acoplamiento actual del 
dispositivo GNSS externo con una VU.  
currentVuApprovalNumber  es el número de homologación de la VU 
actualmente acoplada con el dispositivo GNSS externo.  
currentVUSerialNumber  es el número de serie de la VU actualmente 
acoplada con el dispositivo GNSS externo.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 179  
2.136.  SensorExternalGNSSOSIdentifier  
Generación 2:  
Identificador del sistema operativo del dispositivo GNSS extern o.
 
Asignación de valor : específica del fabricante.  
2.137.  SensorExternalGNSSSCIdentifier  
Generación 2:  
Este tipo se utiliza, por ejemplo, para identificar el módulo c riptográfico 
del dispositivo GNSS externo.  
Identificador del componente de seguridad del dispositivo GNSS externo.
  
Asignación de valor : específica del fabricante del componente.  
2.138.  SensorGNSSCouplingDate  
Generación 2:  
Fecha de un acoplamiento entre el dispositivo GNSS externo y un a 
unidad instala en el vehículo.
  
Asignación de valor : No especificado.  
2.139.  SensorGNSSSerialNumber  
Generación 2:  
Este tipo se utiliza para almacenar el número de serie del rece ptor GNSS 
tanto cuando esté dentro de la VU como cuando esté fuera de la VU. 
Número de serie del receptor GNSS.
  
2.140.  SensorIdentification  
Información almacenada en un sensor de movimiento y relativa a la 
identificación de dicho sensor (anexo 1B, requisito 077 y anexo  1C, 
requisito 95).
  
sensorSerialNumber  es el número de serie ampliado del sensor de 
movimiento (incluye el número de pieza y el código del fabrican te). 
sensorApprovalNumber  es el número de homologación del sensor de 
movimiento.  
sensorSCIdentifier  es el identificador del componente de seguridad del 
sensor de movimiento.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 180  
sensorOSIdentifier  es el identificador del sistema operativo del sensor 
de movimiento.  
2.141.  SensorInstallation  
Información almacenada en un sensor de movimiento y relativa a la 
instalación de dicho sensor (anexo 1B, requisito 099 y anexo 1C , requi­
sito 122).
  
sensorPairingDateFirst  es la fecha del primer emparejamiento del sen­
sor de movimiento con una VU.  
firstVuApprovalNumber  es el número de homologación de la primera 
VU emparejada con el sensor de movimiento.  
firstVuSerialNumber  es el número de serie de la primera VU empare­
jada con el sensor de movimiento.  
sensorPairingDateCurrent  es la fecha del emparejamiento actual entre 
el sensor de movimiento y la VU.  
currentVuApprovalNumber  es el número de homologación de la VU 
que está emparejada actualmente con el sensor de movimiento.  
currentVUSerialNumber  es el número de serie de la VU que está 
emparejada actualmente con el sensor de movimiento.  
2.142.  SensorInstallationSecData  
Información almacenada en una tarjeta de taller y relativa a lo s datos de 
seguridad necesarios para emparejar sensores de movimiento y un idades 
instaladas en vehículos (anexo 1C, requisitos 308 y 331).  
Generación 1:
  
Asignación de valor : con arreglo a la norma ISO 16844-3.  
Generación 2:  
Tal como se describe en el apéndice 11, una tarjeta de taller d eberá 
almacenar hasta tres claves de emparejamiento del sensor de mov imiento 
con la VU. Estas claves tienen diferentes versiones de clave.
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 181  
2.143.  SensorOSIdentifier  
Identificador del sistema operativo del sensor de movimiento.
  
Asignación de valor : específica del fabricante.  
2.144.  SensorPaired  
Generación 1:  
Información almacenada en una unidad instalada en el vehículo y  relativa 
a la identificación del sensor de movimiento emparejado con dic ha uni­
dad (anexo 1B, requisito 079).
  
sensorSerialNumber  es el número de serie del sensor de movimiento 
que está emparejado actualmente con la VU.  
sensorApprovalNumber  es el número de homologación del sensor de 
movimiento que está emparejado actualmente con la VU.  
sensorPairingDateFirst  es la fecha en que el sensor de movimiento 
emparejado actualmente a la VU se emparejó por primera vez con la VU.  
2.145.  SensorPairedRecord  
Generación 2:  
Información almacenada en una unidad instalada en el vehículo y  relativa 
a la identificación de un sensor de movimiento emparejado con d icha 
unidad (anexo 1C, requisito 97).
  
sensorSerialNumber  es el número de serie de un sensor de movimiento 
emparejado con la VU.  
sensorApprovalNumber  es el número de homologación de este sensor 
de movimiento.  
sensorPairingDate  es la fecha del emparejamiento de este sensor de 
movimiento con la VU.  
2.146.  SensorPairingDate  
Fecha de un emparejamiento del sensor de movimiento con una VU.
  
Asignación de valor : no especificado.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 182  
2.147.  SensorSCIdentifier  
Identificador del componente de seguridad del sensor de movimie nto.
 
Asignación de valor : específica del fabricante del componente.  
2.148.  SensorSerialNumber  
Número de serie del sensor de movimiento.
  
2.149.  Signature  
Una firma digital.  
Generación 1:
  
Asignación de valor : con arreglo a lo dispuesto en el apéndice 11 
(Mecanismos de seguridad comunes).  
Generación 2:
  
Asignación de valor : con arreglo a lo dispuesto en el apéndice 11 
(Mecanismos de seguridad comunes).  
2.150.  SignatureRecordArray  
Generación 2:  
Conjunto de firmas más metadatos tal como se utilizan en el pro tocolo 
de transferencia.
  
recordType  denota el tipo de registro (Signature).  Asignación de valor : 
véase RecordType.  
recordSize  es el tamaño de Signature en bytes.  
noOfRecords  es el número de registros que hay en el conjunto. El valor 
se pondrá a 1, ya que las firmas pueden tener diferentes longit udes.  
records  es el conjunto de firmas.  
2.151.  SimilarEventsNumber  
El número de incidentes similares de un día determinado (anexo 1B, 
requisito 094, y anexo 1C, requisito 117).
  
Asignación de valor:  el 0 no se utiliza, el 1 significa que ese día solo ha 
ocurrido y se ha almacenado un incidente de ese tipo, el 2 sign ifica que 
ese día han ocurrido 2 incidentes de ese tipo (y solo se ha alm acenado 
uno), … 255 significa que ese día han ocurrido 255 o más incide ntes de 
ese tipo.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 183  
2.152.  SpecificConditionRecord  
Información almacenada en una tarjeta de conductor o de taller o en una 
unidad instalada en el vehículo y relativa a una condición espe cífica 
(anexo 1C, requisitos 130, 276, 301, 328 y 355).
  
entryTime  es la fecha y la hora de la entrada.  
specificConditionType  es el código que identifica la condición especí­
fica. 
2.153.  SpecificConditions  
Información almacenada en una tarjeta de conductor o de taller o en una 
unidad instalada en el vehículo y relativa a una condición espe cífica 
(anexo 1C, requisitos 131, 277, 302, 329 y 356).  
Generación 2:
  
controlPointerNewestRecord  es el índice del último registro actualizado 
de una condición específica.  
Asignación de valor : número correspondiente al numerador del registro 
de condición específica. Al primer registro de la estructura se  le asigna el 
número «0».  
specificConditionRecords  es el conjunto de registros con información 
sobre las condiciones específicas utilizadas.  
2.154.  SpecificConditionType  
Código que identifica una condición específica (anexo 1B, requi sitos 
050b, 105a, 212a y 230a y anexo 1C, requisito 62).
  
Generación 1:  
Asignación de valor:  
«00»H RFU  
«01»H Fuera de ámbito — Comienzo  
«02»H Fuera de ámbito — Final  
«03»H Trayecto en transbordador/tren  
«04»H .. «FF»H RFU  
Generación 2:  
Asignación de valor:  
«00»H RFU  
«01»H Fuera de ámbito — Comienzo  
«02»H Fuera de ámbito — Final  
«03»H Trayecto en transbordador/tren — Comienzo  
«04»H Trayecto en transbordador/tren — Final  
«05»H .. «FF»H RFU  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 184  
2.155.  Speed  
Velocidad del vehículo (km/h).
  
Asignación de valor : kilómetros por hora en el intervalo operativo de 0 
a 220 km/h.  
2.156.  SpeedAuthorised  
Velocidad máxima autorizada para el vehículo [definición hh)].
  
2.157.  SpeedAverage  
Velocidad media en un lapso de tiempo previamente definido (km/ h).
 
2.158.  SpeedMax  
Velocidad máxima medida en un lapso de tiempo previamente defin ido.
 
▼M3 
2.158a.  TachographCardsGen1Suppression  
Generación 2, versión 2:  
Capacidad de una VU de segunda generación para utilizar tarjeta s de 
conductor, de control y de empresa de primera generación (véase  el 
apéndice 15, MIG_002).
  
Asignación de valor:  
«0000»H La VU tiene capacidad para utilizar tarjetas de 
tacógrafo de primera generación (valor por de­
fecto),  
«A5E3»H La VU no tiene capacidad para utilizar tarjetas de 
tacógrafo de primera generación,  
Los demás valores No se utiliza.  
▼B 
2.159.  TachographPayload  
Generación 2:  
Para la definición de este tipo de datos, véase el apéndice 14.  
▼M1 
2.160.  Reservado para usos futuros  
▼B 
2.161.  TDesSessionKey  
Generación 1:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 185  
Una clave de sesión triple DES.
  
Asignación de valor : no hay más especificaciones.  
▼M1 
2.162.  TimeReal  
Código para un campo combinado de fecha y hora, donde ambos par á­
metros se expresan como los segundos transcurridos desde las 
00h.00m.00s. del 1 de enero de 1970, UTC.
  
Asignación de valor  — Alineación de octeto : número de segundos 
transcurridos a partir de la medianoche del día 1 de enero de 1 970, 
UTC.  
La fecha/hora máxima posible es en el año 2106.  
▼B 
2.163.  TyreSize  
Designación de las dimensiones de los neumáticos.
  
Asignación de valor : de conformidad con la Directiva 92/23/CEE de 
31 de marzo de 1992 (DO L 129 de 14.5.1992, p. 95).  
2.164.  VehicleIdentificationNumber  
Número de identificación del vehículo (VIN) referido al vehícul o com­
pleto, generalmente el número de serie del chasis o el número d e 
bastidor.
  
Asignación de valor : tal y como se define en la norma ISO 3779.  
2.165.  VehicleIdentificationNumberRecordArray  
Generación 2:  
El VehicleIdentificationNumber más metadatos tal como se utiliz an en el 
protocolo de transferencia.
  
recordType  denota el tipo de registro (VehicleIdentificationNumber).  
Asignación de valor : véase RecordType.  
recordSize  es el tamaño de VehicleIdentificationNumber en bytes.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 186  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es el conjunto de números de identificación de vehículos.  
2.166.  VehicleRegistrationIdentification  
Identificación de un vehículo, exclusiva para Europa (VRN y Est ado 
miembro).
  
vehicleRegistrationNation  es la nación donde se matriculó el vehículo.  
vehicleRegistrationNumber  es el número de matrícula del vehículo 
(VRN).  
▼M3 
2.166a.  VehicleRegistrationIdentificationRecordArray  
Generación 2, versión 2:  
La identificación de matriculación del vehículo más metadatos, tal como 
se utilizan en el protocolo de transferencia.
  
recordType  denota el tipo de registro (VehicleRegistrationIdentifica­
tion).  Asignación de valor : véase RecordType.  
recordSize  es el tamaño de VehicleRegistrationIdentification en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es el conjunto de datos de la identificación de matriculación del 
vehículo.  
▼B 
2.167.  VehicleRegistrationNumber  
Número de matrícula del vehículo (VRN). El número de matrícula lo 
asigna la autoridad de matriculación de vehículos.
  
codePage  especifica un conjunto de caracteres definidos en el capítulo 4, ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 187  
vehicleRegNumber  representa un VRN codificado utilizando el con­
junto de caracteres especificado.  
Asignación de valor : específica para cada país.  
2.168.  VehicleRegistrationNumberRecordArray  
▼M3 
Generación 2, versión 1:  
▼B 
El VehicleRegistrationNumber más metadatos tal como se utilizan  en el 
protocolo de transferencia.
  
recordType  denota el tipo de registro (VehicleRegistrationNumber).  
Asignación de valor : véase RecordType.  
recordSize  es el tamaño de VehicleRegistrationNumber en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es el conjunto de números de matrícula de vehículos.  
2.169.  VuAbility  
Generación 2:  
Información almacenada en una VU sobre la capacidad de la VU pa ra 
utilizar o no tarjetas de tacógrafo de generación 1 (anexo 1C, requisito 
121).
  
Asignación de valor  — Alineación de octeto : «xxxxxxxa»B (8 bits)  
Para la compatibilidad con la generación 1:  
«a»B Admisión de las tarjetas de tacógrafo de generación 1  
«0» B admite la generación 1,  
«1»B no admite la generación 1,  
«xxxxxxx»B RFU  
2.170.  VuActivityDailyData  
Generación 1:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 188  
Información almacenada en una VU y relativa a los cambios de ac tivi­
dad y/o los cambios del régimen de conducción y/o los cambios d el 
estado de la tarjeta que tengan lugar en un día civil determina do (anexo 
1B, requisito 084) y a los estados de las ranuras a las 00.00 h oras de ese 
día.
 
noOfActivityChanges  es el número de palabras de ActivityChangeInfo 
que hay en el conjunto activityChangeInfos.  
activityChangeInfos  es un conjunto de palabras de ActivityChangeInfo 
que se almacenan en la VU a lo largo del día Siempre incluye do s 
palabras de activityChangeInfo que dan el estado de las dos ran uras a 
las 00.00 horas de ese día.  
2.171.  VuActivityDailyRecordArray  
Generación 2:  
Información almacenada en una VU y relativa a los cambios de ac tivi­
dad y/o los cambios del régimen de conducción y/o los cambios d el 
estado de la tarjeta que tengan lugar en un día civil determina do (anexo 
1C, requisitos 105, 106 y 107) y a los estados de las ranuras a  las 00.00 
horas de ese día.
  
recordType  denota el tipo de registro (ActivityChangeInfo).  Asignación 
de valor : véase RecordType.  
recordSize  es el tamaño de ActivityChangeInfo en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es un conjunto de palabras de ActivityChangeInfo que se alma­
cenan en la VU a lo largo del día. Siempre incluye dos palabras  de 
activityChangeInfo que dan el estado de las dos ranuras a las 0 0.00 
horas de ese día.  
2.172.  VuApprovalNumber  
Número de homologación de la unidad instalada en el vehículo.  
Generación 1:
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 189  
Asignación de valor : no especificado.  
Generación 2:
  
Asignación de valor:  
el número de homologación deberá constar según haya sido public ado 
en el correspondiente sitio web de la Comisión Europea, es deci r, por 
ejemplo, incluyendo guiones si los lleva. El número de homologa ción 
deberá estar alineado a la izquierda.  
2.173.  VuCalibrationData  
Generación 1:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a los calibrados del aparato de control (anexo 1B, requisi to 098).
  
noOfVuCalibrationRecords  es el número de registros que hay en el 
conjunto vuCalibrationRecords.  
vuCalibrationRecords  es el conjunto de registros de calibrado.  
2.174.  VuCalibrationRecord  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva al calibrado del aparato de control (anexo 1B, requisito 0 98 y 
anexo 1C, requisitos 119 y 120).  
Generación 1:
  
calibrationPurpose  es el propósito del calibrado.  
workshopName, workshopAddress  son el nombre y la dirección del 
taller.  
workshopCardNumber  identifica la tarjeta de taller empleada durante 
el calibrado.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 190  
workshopCardExpiryDate  es la fecha de expiración de la tarjeta.  
vehicleIdentificationNumber  es el VIN.  
vehicleRegistrationIdentification  contiene el VRN y el nombre del 
Estado miembro donde se matriculó el vehículo.  
wVehicleCharacteristicConstant  es el coeficiente característico del 
vehículo.  
kConstantOfRecordingEquipment  es la constante del aparato de 
control.  
lTyreCircumference  es la circunferencia efectiva de los neumáticos de 
las ruedas.  
tyreSize  son las dimensiones de las ruedas montadas en el vehículo.  
authorisedSpeed  es la velocidad autorizada del vehículo.  
oldOdometerValue, newOdometerValue  son la lectura anterior y la 
nueva lectura del cuentakilómetros.  
oldTimeValue, newTimeValue  son el valor anterior y el nuevo valor de 
la fecha y la hora.  
nextCalibrationDate  es la fecha del próximo calibrado del tipo especi­
ficado en CalibrationPurpose, a cargo de la autoridad de contro l 
autorizada.  
▼M3 
Generación 2, versión 1:  
▼B
 
Además de los de la generación 1, se utiliza el siguiente eleme nto de 
datos:  
sealDataVu  da información sobre los precintos colocados en diversos 
componentes del vehículo.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 191  
Generación 2, versión 2:
  
Además de los de primera generación, se utilizan los siguientes  elemen­
tos de datos:  
sensorSerialNumber  es el número de serie del sensor de movimiento 
emparejado con la unidad instalada en el vehículo al final del calibrado,  
sensorGNSSSerialNumber  es el número de serie del dispositivo GNSS 
externo acoplado con la unidad instalada en el vehículo al fina l del 
calibrado (en su caso),  
rcmSerialNumber  es el número de serie del dispositivo de comunica­
ción a distancia acoplado con la unidad instalada en el vehícul o al final 
del calibrado (en su caso),  
sealDataVu  da información sobre los precintos colocados en diversos 
componentes del vehículo,  
byDefaultLoadType  es el tipo de carga por defecto del vehículo (solo 
presente en la versión 2),  
calibrationCountry  es el país en el que se ha realizado el calibrado,  
calibrationCountryTimestamp  es la fecha y la hora en las que el 
receptor GNSS proporcionó la posición utilizada para determinar  el 
país en el que se ha realizado el calibrado.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 192  
2.175.  VuCalibrationRecordArray  
Generación 2:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a los calibrados del aparato de control (anexo 1C, requisi tos 119 y 
120).
  
recordType  denota el tipo de registro (VuCalibrationRecord).  Asigna­
ción de valor : véase RecordType.  
recordSize  es el tamaño de VuCalibrationRecord en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es el conjunto de registros de calibrado.  
2.176.  VuCardIWData  
Generación 1:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a los ciclos de inserción y extracción de tarjetas de cond uctor o de 
taller en dicha unidad (anexo 1B, requisito 081, y anexo 1C, re quisito 
103).
  
noOfIWRecords  es el número de registros que hay en el conjunto 
vuCardIWRecords.  
vuCardIWRecords  es el conjunto de registros relativos a los ciclos de 
inserción y extracción de la tarjeta.  
2.177.  VuCardIWRecord  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva al ciclo de inserción y extracción de una tarjeta de condu ctor o de 
taller en dicha unidad (anexo 1B, requisito 081, y anexo 1C, re quisito 
102).  
Generación 1:
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 193  
cardHolderName  es el nombre y los apellidos del titular de la tarjeta de 
conductor o de taller, según los datos almacenados en la propia  tarjeta.  
fullCardNumber  es el tipo de tarjeta, el nombre del Estado miembro 
que la expidió y el número de tarjeta, según los datos almacena dos en la 
propia tarjeta.  
cardExpiryDate  es la fecha de expiración de la tarjeta, según los datos 
almacenados en la propia tarjeta.  
cardInsertionTime  es la fecha y la hora de inserción.  
vehicleOdometerValueAtInsertion  es la lectura del cuentakilómetros 
del vehículo en el momento de insertar la tarjeta.  
cardSlotNumber  es la ranura donde se inserta la tarjeta.  
cardWithdrawalTime  es la fecha y la hora de extracción.  
vehicleOdometerValueAtWithdrawal  es la lectura del cuentakilóme­
tros del vehículo en el momento de extraer la tarjeta.  
previousVehicleInfo  contiene información sobre el vehículo anterior 
que utilizara el conductor, según los datos almacenados en la t arjeta.  
manualInputFlag  es una bandera que indica si el titular de la tarjeta ha 
introducido manualmente alguna actividad del conductor en el mo mento 
de insertar la tarjeta.  
Generación 2:
  
En lugar de fullCardNumber, la estructura de datos de la genera ción 2 
utiliza el siguiente elemento de datos:  
fullCardNumberAndGeneration  es el tipo de tarjeta, el nombre del 
Estado miembro que la expidió, el número de tarjeta y su genera ción, 
según los datos almacenados en la propia tarjeta.  
2.178.  VuCardIWRecordArray  
Generación 2:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 194  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a los ciclos de inserción y extracción de tarjetas de cond uctor o de 
taller en dicha unidad (anexo 1C, requisito 103).
  
recordType  denota el tipo de registro (VuCardIWRecord).  Asignación 
de valor : véase RecordType.  
recordSize  es el tamaño de VuCardIWRecord en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es el conjunto de registros relativos a los ciclos de inserció n y 
extracción de tarjetas.  
▼M1 
2.179.  VuCardRecord  
Generación 2:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a una tarjeta de tacógrafo utilizada (anexo IC, requisito 132).
  
cardNumberAndGenerationInformation  es el número de tarjeta com­
pleto y la generación de la tarjeta utilizada (tipo de datos 2. 74). 
cardExtendedSerialNumber  según se lee del archivo EF_ICC del MF 
de la tarjeta.  
cardStructureVersion  según se lee del archivo EF_Application_Identi­
fication del DF_Tachograph_G2.  
cardNumber  según se lee del archivo EF_Identification del DF_Tacho­
graph_G2.  
▼B 
2.180.  VuCardRecordArray  
Generación 2:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a las tarjetas de tacógrafo utilizadas con dicha unidad. E sta infor­
mación se destina al análisis de los problemas VU — tarjeta (an exo 1C, 
requisito 132).
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 195  
recordType  denota el tipo de registro (VuCardRecord).  Asignación de 
valor : véase RecordType.  
recordSize  es el tamaño de VuCardRecord en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es un conjunto de registros relativos a las tarjetas de tacógr afo 
utilizadas con la VU.  
2.181.  VuCertificate  
Certificado de la clave pública de una VU.
  
2.182.  VuCertificateRecordArray  
Generación 2:  
El certificado de la VU más metadatos tal como se utilizan en e l pro­
tocolo de transferencia.
  
recordType  denota el tipo de registro (VuCertificate).  Asignación de 
valor : véase RecordType.  
recordSize  es el tamaño de VuCertificate en bytes.  
noOfRecords  es el número de registros que hay en el conjunto. El valor 
se pondrá a 1, ya que los certificados pueden tener diferentes longitudes.  
records  es un conjunto de certificados de VU.  
2.183.  VuCompanyLocksData  
Generación 1:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a bloqueos introducidos por empresas (anexo 1B, requisito 104).
  
noOfLocks  es el número de bloqueos incluidos en vuCompanyLocks­
Records.  
vuCompanyLocksRecords  es el conjunto de registros de bloqueos in­
troducidos por empresas.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 196  
2.184.  VuCompanyLocksRecord  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a bloqueos introducidos por una empresa (anexo 1B, requisi to 104, 
y anexo 1C, requisito 128).  
Generación 1:
  
lockInTime, lockOutTime  son la fecha y la hora de activación y de­
sactivación del bloqueo.  
companyName, companyAddress  son el nombre y la dirección de la 
empresa relacionada con la activación del bloqueo.  
companyCardNumber  identifica la tarjeta empleada para la activación 
del bloqueo.  
Generación 2:
  
En lugar de companyCardNumber, la estructura de datos de la gen era­
ción 2 utiliza el siguiente elemento de datos:  
companyCardNumberAndGeneration  identifica la tarjeta, incluida su 
generación, empleada para la activación del bloqueo.  
2.185.  VuCompanyLocksRecordArray  
Generación 2:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a bloqueos introducidos por empresas (anexo 1C, requisito 128).
  
recordType  denota el tipo de registro (VuCompanyLocksRecord).  Asig­
nación de valor : véase RecordType.  
recordSize  es el tamaño de VuCompanyLocksRecord en bytes.  
noOfRecords  es el número de registros que hay en el conjunto. Valor 
0..255.  
records  es el conjunto de registros de bloqueos introducidos por 
empresas.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 197  
2.185a.  VuConfigurationLengthRange  
Generación 2, versión 2:  
Número de bytes de una tarjeta de tacógrafo disponibles para al macenar 
configuraciones de la VU.
  
Asignación de valor : véase el apéndice 2.  
▼B 
2.186.  VuControlActivityData  
Generación 1:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a los controles efectuados con dicha unidad (anexo 1B, req uisito 
102).
  
noOfControls  es el número de controles incluidos en vuControlActi­
vityRecords.  
vuControlActivityRecords  es el conjunto de registros sobre actividades 
de control.  
2.187.  VuControlActivityRecord  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a un control efectuado con dicha unidad (anexo 1B, requisi to 102, y 
anexo 1C, requisito 126).  
Generación 1:
  
controlType  es el tipo de control.  
controlTime  es la fecha y la hora del control.  
ControlCardNumber  identifica la tarjeta de control empleada para el 
control.  
downloadPeriodBeginTime  es la hora de comienzo del período cuyos 
datos se transfieren, en caso de transferencia.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 198  
downloadPeriodEndTime  es la hora de conclusión del período cuyos 
datos se transfieren, en caso de transferencia.  
Generación 2:
  
En lugar de controlCardNumber, la estructura de datos de la gen eración 
2 utiliza el siguiente elemento de datos:  
controlCardNumberAndGeneration  identifica la tarjeta de control, in­
cluida su generación, empleada para el control.  
2.188.  VuControlActivityRecordArray  
Generación 2:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a los controles efectuados con dicha unidad (anexo 1C, req uisito 
126).
  
recordType  denota el tipo de registro (VuControlActivityRecord).  Asig­
nación de valor : véase RecordType.  
recordSize  es el tamaño de VuControlActivityRecord en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es el conjunto de registros sobre actividades de control de la  
VU. 
2.189.  VuDataBlockCounter  
Contador, almacenado en una tarjeta, que identifica secuencialm ente los 
ciclos de inserción/extracción de la tarjeta en unidades instal adas en 
vehículos.
  
Asignación de valor : número consecutivo con un valor máximo de 9 
999, y que vuelve a comenzar desde 0.  
2.190.  VuDetailedSpeedBlock  
Información pormenorizada almacenada en una unidad instalada en  el 
vehículo y relativa a la velocidad del vehículo durante un minu to en el 
que haya estado en movimiento (anexo 1B, requisito 093, y anexo  1C, 
requisito 116).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 199
  
speedBlockBeginDate  es la fecha y la hora del primer valor de veloci­
dad comprendido en ese bloque.  
speedsPerSecond  es la secuencia cronológica de las velocidades medi­
das cada segundo de ese minuto, empezando desde speedBlockBegin ­
Date (inclusive).  
2.191.  VuDetailedSpeedBlockRecordArray  
Generación 2:  
Información pormenorizada almacenada en una unidad instalada en  el 
vehículo y relativa a la velocidad del vehículo.
  
recordType  denota el tipo de registro (VuDetailedSpeedBlock).  Asig­
nación de valor : véase RecordType.  
recordSize  es el tamaño de VuDetailedSpeedBlock en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es el conjunto de bloques con datos pormenorizados sobre la 
velocidad.  
2.192.  VuDetailedSpeedData  
Generación 1:  
Información pormenorizada almacenada en una unidad instalada en  el 
vehículo y relativa a la velocidad del vehículo.
  
noOfSpeedBlocks  es el número de bloques con datos de velocidad que 
hay en el conjunto vuDetailedSpeedBlocks.  
vuDetailedSpeedBlocks  es el conjunto de bloques con datos pormeno­
rizados sobre la velocidad.  
▼M3 
2.192a.  VuDigitalMapVersion  
Generación 2, versión 2:  
Versión del mapa digital almacenado en la unidad instalada en e l vehí­
culo (anexo I C, requisito 133  undecies ).
 ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 200  
Asignación de valor : según se especifica en el sitio web protegido 
específico puesto a disposición por la Comisión Europea (anexo I C, 
requisito 133  duodecies ). 
▼B 
2.193.  VuDownloadablePeriod  
La fecha más antigua y la más reciente para las que una unidad instalada 
en el vehículo conserva datos relativos a las actividades de lo s conduc­
tores (anexo 1B, requisitos 081, 084 o 087, y anexo 1C, requisi tos 102, 
105 y 108).
  
minDownloadableTime  es la fecha y la hora más antiguas en que se 
insertó una tarjeta, ocurrió un cambio de actividad o se introd ujo un 
lugar; según los datos almacenados en la VU.  
maxDownloadableTime  es la fecha y la hora más recientes en que se 
insertó una tarjeta, ocurrió un cambio de actividad o se introd ujo un 
lugar; según los datos almacenados en la VU.  
2.194.  VuDownloadablePeriodRecordArray  
Generación 2:  
El VUDownloadablePeriod más metadatos tal como se utilizan en e l 
protocolo de transferencia.
  
recordType  denota el tipo de registro (VuDownloadablePeriod).  Asig­
nación de valor : véase RecordType.  
recordSize  es el tamaño de VuDownloadablePeriod en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es el conjunto de registros de VuDownloadablePeriod.  
2.195.  VuDownloadActivityData  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a su última transferencia (anexo 1B, requisito 105, y anex o 1C, 
requisito 129).  
Generación 1:
  
downloadingTime  es la fecha y la hora de la transferencia.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 201  
fullCardNumber  identifica la tarjeta empleada para autorizar la 
transferencia.  
companyOrWorkshopName  es el nombre de la empresa o del centro 
de ensayo.  
Generación 2:
  
En lugar de fullCardNumber, la estructura de datos de la genera ción 2 
utiliza el siguiente elemento de datos:  
fullCardNumberAndGeneration  identifica la tarjeta, incluida su gene­
ración, empleada para autorizar la transferencia.  
2.196.  VuDownloadActivityDataRecordArray  
Generación 2:  
Información relativa a la última transferencia de la VU (anexo 1C, 
requisito 129).
  
recordType  denota el tipo de registro (VuDownloadActivityData).  Asig­
nación de valor : véase RecordType.  
recordSize  es el tamaño de VuDownloadActivityData en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es el conjunto de registros de datos sobre actividades de 
transferencia.  
2.197.  VuEventData  
Generación 1:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a incidentes (anexo 1B, requisito 094, salvo el incidente de exceso 
de velocidad).
  
noOfVuEvents  es el número de incidentes incluidos en el conjunto 
vuEventRecords.  
vuEventRecords  es un conjunto de registros sobre incidentes.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 202  
2.198.  VuEventRecord  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a un incidente (anexo 1B, requisito 094 y anexo 1C, requis ito 117, 
salvo el incidente de exceso de velocidad).  
Generación 1:
  
eventType  es el tipo de incidente.  
eventRecordPurpose  es el propósito con que se ha registrado ese 
incidente.  
eventBeginTime  es la fecha y la hora de comienzo del incidente.  
eventEndTime  es la fecha y la hora en que termina el incidente.  
cardNumberDriverSlotBegin  identifica la tarjeta que estaba insertada 
en la ranura del conductor en el momento en que comenzó el inci dente.  
cardNumberCodriverSlotBegin  identifica la tarjeta que estaba inser­
tada en la ranura del segundo conductor en el momento en que co menzó 
el incidente.  
cardNumberDriverSlotEnd  identifica la tarjeta que estaba insertada en 
la ranura del conductor en el momento en que finalizó el incide nte. 
cardNumberCodriverSlotEnd  identifica la tarjeta que estaba insertada 
en la ranura del segundo conductor en el momento en que finaliz ó el 
incidente.  
similarEventsNumber  es el número de incidentes similares ocurridos 
ese día.  
Esta secuencia puede utilizarse para todos los incidentes, exce pto los de 
exceso de velocidad.  
Generación 2:
  
Además de los de la generación 1, se utilizan los siguientes el ementos 
de datos:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 203  
manufacturerSpecificEventFaultData  contiene información adicional 
sobre el incidente, específica del fabricante.  
En lugar de cardNumberDriverSlotBegin, cardNumberCodriverSlotBe ­
gin, cardNumberDriverSlotEnd y cardNumberCodriverSlotEnd, la es ­
tructura de datos de la generación 2 utiliza los siguientes ele mentos de 
datos:  
cardNumberAndGenDriverSlotBegin  identifica la tarjeta, incluida su 
generación, que estaba insertada en la ranura del conductor en el mo­
mento en que comenzó el incidente.  
cardNumberAndGenCodriverSlotBegin  identifica la tarjeta, incluida 
su generación, que estaba insertada en la ranura del segundo co nductor 
en el momento en que comenzó el incidente.  
cardNumberAndGenDriverSlotEnd  identifica la tarjeta, incluida su 
generación, que estaba insertada en la ranura del conductor en el mo­
mento en que terminó el incidente.  
cardNumberAndGenCodriverSlotEnd  identifica la tarjeta, incluida su 
generación, que estaba insertada en la ranura del segundo condu ctor en 
el momento en que terminó el incidente.  
Si el incidente es un conflicto temporal, eventBeginTime y even tEnd­
Time deben interpretarse como sigue:  
eventBeginTime  es la fecha y la hora del aparato de control.  
eventEndTime  es la fecha y la hora GNSS.  
2.199.  VuEventRecordArray  
Generación 2:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a incidentes (anexo 1C, requisito 117, salvo el incidente de exceso 
de velocidad).
  
recordType  denota el tipo de registro (VuEventRecord).  Asignación de 
valor : véase RecordType.  
recordSize  es el tamaño de VuEventRecord en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es un conjunto de registros sobre incidentes.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 204  
2.200.  VuFaultData  
Generación 1:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a fallos (anexo 1B, requisito 096).
  
noOfVuFaults  es el número de fallos incluidos en el conjunto vuFaul­
tRecords.  
vuFaultRecords  es un conjunto de registros sobre fallos.  
2.201.  VuFaultRecord  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a un fallo (anexo 1B, requisito 096, y anexo 1C, requisito  118).  
Generación 1:
  
faultType  es el tipo de fallo del aparato de control.  
faultRecordPurpose  es el propósito con que se ha registrado ese fallo.  
faultBeginTime  es la fecha y la hora de comienzo del fallo.  
faultEndTime  es la fecha y la hora en que termina el fallo.  
cardNumberDriverSlotBegin  identifica la tarjeta que estaba insertada 
en la ranura del conductor en el momento en que comenzó el fall o. 
cardNumberCodriverSlotBegin  identifica la tarjeta que estaba inser­
tada en la ranura del segundo conductor en el momento en que co menzó 
el fallo.  
cardNumberDriverSlotEnd  identifica la tarjeta que estaba insertada en 
la ranura del conductor en el momento en que terminó el fallo.  
cardNumberCodriverSlotEnd  identifica la tarjeta que estaba insertada 
en la ranura del segundo conductor en el momento en que terminó  el 
fallo. ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 205  
Generación 2:
  
Además de los de la generación 1, se utiliza el siguiente eleme nto de 
datos:  
manufacturerSpecificEventFaultData  contiene información adicional 
sobre el fallo, específica del fabricante.  
En lugar de cardNumberDriverSlotBegin, cardNumberCodriverSlotBe ­
gin, cardNumberDriverSlotEnd y cardNumberCodriverSlotEnd, la es ­
tructura de datos de la generación 2 utiliza los siguientes ele mentos de 
datos:  
cardNumberAndGenDriverSlotBegin  identifica la tarjeta, incluida su 
generación, que estaba insertada en la ranura del conductor en el mo­
mento en que comenzó el fallo.  
cardNumberAndGenCodriverSlotBegin  identifica la tarjeta, incluida 
su generación, que estaba insertada en la ranura del segundo co nductor 
en el momento en que comenzó el fallo.  
cardNumberAndGenDriverSlotEnd  identifica la tarjeta, incluida su 
generación, que estaba insertada en la ranura del conductor en el mo­
mento en que terminó el fallo.  
cardNumberAndGenCodriverSlotEnd  identifica la tarjeta, incluida su 
generación, que estaba insertada en la ranura del segundo condu ctor en 
el momento en que terminó el fallo.  
2.202.  VuFaultRecordArray  
Generación 2:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a fallos (anexo 1B, requisito 118).
  
recordType  denota el tipo de registro (VuFaultRecord).  Asignación de 
valor : véase RecordType.  
recordSize  es el tamaño de VuFaultRecord en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es un conjunto de registros sobre fallos.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 206  
2.203.  VuGNSSADRecord  
▼M3 
Generación 2, versión 1:  
▼M1 
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a la posición GNSS del vehículo si el tiempo de conducción  acu­
mulado alcanza un múltiplo de tres horas (anexo IC, requisitos 108 y 
110).
  
timeStamp  es la fecha y la hora en las que el tiempo de conducción 
acumulado llega a un múltiplo de tres horas.  
cardNumberAndGenDriverSlot  identifica la tarjeta, incluida su gene­
ración, que está insertada en la ranura del conductor.  
cardNumberAndGenCodriverSlot  identifica la tarjeta, incluida su ge­
neración, que está insertada en la ranura del segundo conductor . 
gnssPlaceRecord  contiene información relacionada con la posición del 
vehículo.  
vehicleOdometerValue  es la lectura del cuentakilómetros en el mo­
mento en que el tiempo de conducción acumulado llega a un múlti plo 
de tres horas.  
▼M3 
Generación 2, versión 2:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a la posición GNSS del vehículo si el tiempo de conducción  acu­
mulado alcanza un múltiplo de tres horas (anexo I C, requisitos  108 
y 110).
  
En la versión 2 de la generación 2 , en lugar de gnssPlaceRecord, se 
utiliza gnssPlaceAuthRecord, que contiene además el estado de a utenti­
cación del GNSS.  
2.203a.  VuBorderCrossingRecord  
Generación 2, versión 2:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a los cruces de fronteras del vehículo cuando este ha cruz ado la 
frontera de un país (anexo I C, requisitos 133  bis y 133  ter). ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 207
  
cardNumberAndGenDriverSlot  identifica la tarjeta, incluida su gene­
ración, que está insertada en la ranura del conductor.  
cardNumberAndGenCodriverSlot  identifica la tarjeta, incluida su ge­
neración, que está insertada en la ranura del segundo conductor . 
countryLeft  es el país del que ha salido el vehículo, según la última 
posición disponible antes de detectarse el cruce de frontera. S e utilizará 
«resto del mundo» (código «FF»H NationNumeric) cuando la unidad  
instalada en el vehículo no sea capaz de determinar el país en el que se 
encuentra el vehículo (por ejemplo, porque el país en el que se  encuentra 
no forma parte de los mapas digitales almacenados).  
countryEntered  es el país en el que ha entrado el vehículo. Se utilizará 
«resto del mundo» (código «FF»H NationNumeric) cuando la unidad  
instalada en el vehículo no sea capaz de determinar el país en el que se 
encuentra el vehículo (por ejemplo, porque el país en el que se  encuentra 
no forma parte de los mapas digitales almacenados).  
gnssPlaceAuthRecord  contiene información relacionada con la posición 
del vehículo cuando se detectó el cruce de frontera, así como s u estado 
de autenticación.  
vehicleOdometerValue  es el valor del cuentakilómetros cuando la uni­
dad instalada en el vehículo ha detectado que este ha cruzado l a frontera 
de un país.  
2.203b.  VuBorderCrossingRecordArray  
Generación 2, versión 2:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a los cruces de fronteras del vehículo (anexo I C, requisi to 133  qua­
ter).
 
recordType  denota el tipo de registro (VuBorderCrossingRecord).  Asig­
nación de valor : véase RecordType.  
recordSize  es el tamaño de VuBorderCrossingRecord en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es un conjunto de registros de cruces de fronteras.  
▼M1 
2.204.  VuGNSSADRecordArray  
Generación 2:  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 208  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a la posición GNSS del vehículo si el tiempo de conducción  acu­
mulado alcanza un múltiplo de tres horas (anexo IC, requisitos 108 y 
110).
  
recordType  denota el tipo de registro (VuGNSSADRecord).  
Asignación de valor : véase RecordType  
recordSize  es el tamaño de VuGNSSADRecord en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es un conjunto de registros GNSS sobre conducción acumulada.  
▼M3 
2.204a.  VuGnssMaximalTimeDifference  
Generación 2, versión 2:  
La diferencia máxima entre la hora verdadera y la hora del relo j de 
tiempo real de la VU, basada en la desviación máxima de la hora  
especificada en el requisito 041 del anexo I C, transmitida por  la unidad 
instalada en el vehículo a un dispositivo GNSS externo; véase e l requi­
sito GNS_3g del apéndice 12.
  
▼B 
2.205.  VuIdentification  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a la identificación de dicha unidad (anexo 1B, requisito 0 75 y 
anexo 1C, requisitos 93 y 121).  
Generación 1:
  
vuManufacturerName  es el nombre del fabricante de la VU.  
vuManufacturerAddress  es la dirección del fabricante de la VU.  
vuPartNumber  es el número de pieza de la VU.  
vuSerialNumber  es el número de serie de la VU.  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 209  
vuSoftwareIdentification  identifica el  software  instalado en la VU.  
vuManufacturingDate  es la fecha de fabricación de la VU.  
vuApprovalNumber  es el número de homologación de la VU.  
▼M3 
Generación 2:
  
Además de los de primera generación, se utilizan los siguientes  elemen­
tos de datos:  
vuGeneration  indica la generación de la unidad instalada en el vehículo.  
vuAbility  aporta información sobre si la VU admite o no las tarjetas de 
tacógrafo de primera generación.  
vuDigitalMapVersion  es la versión del mapa digital almacenado en la 
unidad instalada en el vehículo (solo presente en la versión 2) . 
▼B 
2.206.  VuIdentificationRecordArray  
Generación 2:  
El VuIdentification más metadatos tal como se utilizan en el pr otocolo 
de transferencia.
  
recordType  denota el tipo de registro (VuIdentification).  Asignación de 
valor : véase RecordType.  
recordSize  es el tamaño de VuIdentification en bytes.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 210  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es un conjunto de registros VuIdentification.  
2.207.  VuITSConsentRecord  
Generación 2:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a la autorización de un conductor en relación con la utili zación de 
sistemas de transporte inteligentes.
  
cardNumberAndGen  identifica la tarjeta, incluida su generación. Debe 
ser una tarjeta de conductor o de taller.  
consent  es una bandera que indica si el conductor ha dado su consen­
timiento en relación con el uso de sistemas de transporte intel igentes con 
este vehículo/unidad instalada en el vehículo.  
Asignación de valor:  
TRUE indica el consentimiento del conductor en relación 
con el uso de sistemas de transporte inteligentes  
FALSE indica la negativa del conductor en relación con el 
uso de sistemas de transporte inteligentes  
2.208.  VuITSConsentRecordArray  
Generación 2:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva al consentimiento del conductor en relación con el uso de sistemas 
de transporte inteligentes (anexo 1C, requisito 200).
  
recordType  denota el tipo de registro (VuITSConsentRecord).  Asigna­
ción de valor : véase RecordType.  
recordSize  es el tamaño de VuITSConsentRecord en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es el conjunto de registros de consentimiento en relación con el 
ITS. 
▼M3 
2.208a.  VuLoadUnloadRecord  
Generación 2, versión 2:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 211  
Información almacenada en la unidad instalada en el vehículo y relativa 
a una operación introducida de carga/descarga (anexo I C, requi si­
tos 133  sexies , 133  septies  y 133  octies ).
 
timeStamp  es la fecha y la hora en las que se introdujo la operación de 
carga/descarga.  
operationType  es el tipo de operación introducido (carga, descarga o 
carga/descarga simultáneas).  
cardNumberAndGenDriverSlot  identifica la tarjeta, incluida su gene­
ración, que está insertada en la ranura del conductor.  
cardNumberAndGenCodriverSlot  identifica la tarjeta, incluida su ge­
neración, que está insertada en la ranura del segundo conductor . 
gnssPlaceAuthRecord  contiene información relacionada con la posición 
del vehículo y su estado de autenticación.  
vehicleOdometerValue  es el valor del cuentakilómetros relacionado con 
la operación de carga/descarga.  
2.208b.  VuLoadUnloadRecordArray  
Generación 2, versión 2:  
Información almacenada en la unidad instalada en el vehículo y relativa 
a una operación introducida de carga/descarga del vehículo (ane xo I C, 
requisito 133  nonies ).
 
recordType  denota el tipo de registro (VuLoadUnloadRecord).  Asigna­
ción de valor : Véase RecordType.  
recordSize  es el tamaño de VuLoadUnloadRecord en b noOfRecords ­ 
ytes. 
es el número de registros que hay en el conjunto.  
records  es un conjunto de registros de operaciones de carga/descarga.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 212  
2.209.  VuManufacturerAddress  
Dirección del fabricante de la unidad instalada en el vehículo.
  
Asignación de valor : no especificado.  
2.210.  VuManufacturerName  
Nombre del fabricante de la unidad instalada en el vehículo.
  
Asignación de valor : no especificado.  
2.211.  VuManufacturingDate  
Fecha de fabricación de la unidad instalada en el vehículo.
  
Asignación de valor : no especificado.  
2.212.  VuOverSpeedingControlData  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a incidentes de exceso de velocidad ocurridos desde el últ imo con­
trol del exceso de velocidad (anexo 1B, requisito 095, y anexo 1C, 
requisito 117).
  
lastOverspeedControlTime  es la fecha y la hora del último control del 
exceso de velocidad.  
firstOverspeedSince  es la fecha y la hora del primer exceso de veloci­
dad ocurrido tras este control.  
numberOfOverspeedSince  es el número de incidentes de exceso de 
velocidad ocurridos después del último control del exceso de ve locidad.  
2.213.  VuOverSpeedingControlDataRecordArray  
Generación 2:  
El VuOverSpeedingControlData más metadatos tal como se utilizan  en 
el protocolo de transferencia.
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 213  
recordType  denota el tipo de registro (VuOverSpeedingControlData).  
Asignación de valor : véase RecordType.  
recordSize  es el tamaño de VuOverSpeedingControlData en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es un conjunto de registros de datos de controles de exceso de  
velocidad.  
2.214.  VuOverSpeedingEventData  
Generación 1:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a incidentes de exceso de velocidad (anexo 1B, requisito 0 94).
 
noOfVuOverSpeedingEvents  es el número de incidentes incluidos en el 
conjunto vuOverSpeedingEventRecords.  
vuOverSpeedingEventRecords  es un conjunto de registros sobre inci­
dentes de exceso de velocidad.  
2.215.  VuOverSpeedingEventRecord  
Generación 1:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a incidentes de exceso de velocidad (anexo 1B, requisito 0 94, y 
anexo 1C, requisito 117).
  
eventType  es el tipo de incidente.  
eventRecordPurpose  es el propósito con que se ha registrado ese 
incidente.  
eventBeginTime  es la fecha y la hora de comienzo del incidente.  
eventEndTime  es la fecha y la hora en que termina el incidente.  
maxSpeedValue  es la velocidad máxima medida durante el incidente.  
averageSpeedValue  es la media aritmética de las velocidades medidas 
durante el incidente.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 214  
cardNumberDriverSlotBegin  identifica la tarjeta que estaba insertada 
en la ranura del conductor en el momento en que comenzó el inci dente.  
similarEventsNumber  es el número de incidentes similares ocurridos 
ese día.  
Generación 2:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a incidentes de exceso de velocidad (anexo 1B, requisito 0 94, y 
anexo 1C, requisito 117).
  
En lugar de cardNumberDriverSlotBegin, la estructura de datos d e la 
generación 2 utiliza el siguiente elemento de datos:  
cardNumberAndGenDriverSlotBegin  identifica la tarjeta, incluida su 
generación, que estaba insertada en la ranura del conductor en el mo­
mento en que comenzó el incidente.  
2.216.  VuOverSpeedingEventRecordArray  
Generación 2:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a incidentes de exceso de velocidad (anexo 1C, requisito 1 17).
 
recordType  denota el tipo de registro (VuOverSpeedingEventRecord).  
Asignación de valor : véase RecordType.  
recordSize  es el tamaño de VuOverSpeedingEventRecord en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es un conjunto de registros sobre incidentes de exceso de 
velocidad.  
2.217.  VuPartNumber  
Número de pieza de la unidad instalada en el vehículo.
  
Asignación de valor : específica del fabricante de la VU.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 215  
2.218.  VuPlaceDailyWorkPeriodData  
Generación 1:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a los lugares donde los conductores comienzan o terminan u n pe­
ríodo de trabajo diario (anexo 1B, requisito 087, y anexo 1C, r equisitos 
108 y 110).
  
noOfPlaceRecords  es el número de registros incluidos en el conjunto 
vuPlaceDailyWorkPeriodRecords.  
vuPlaceDailyWorkPeriodRecords  es un conjunto de registros relativos 
a lugares.  
2.219.  VuPlaceDailyWorkPeriodRecord  
Generación 1:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a un lugar donde un conductor comienza o termina un períod o de 
trabajo diario (anexo 1B, requisito 087, y anexo 1C, requisitos  108 y 
110).
  
fullCardNumber  es el tipo de tarjeta de conductor, el Estado miembro 
que la ha expedido y el número de tarjeta.  
placeRecord  contiene la información relativa al lugar introducido.  
▼M3 
Generación 2, versión 1:  
▼B 
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a un lugar donde un conductor comienza o termina un períod o de 
trabajo diario (anexo 1B, requisito 087, y anexo 1C, requisitos  108 y 
110).
  
En lugar de fullCardNumber, la estructura de datos de la genera ción 2 
utiliza el siguiente elemento de datos:  
fullCardNumberAndGeneration  es el tipo de tarjeta, el nombre del 
Estado miembro que la expidió, el número de tarjeta y su genera ción, 
según los datos almacenados en la propia tarjeta.  
▼M3 
Generación 2, versión 2:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva al lugar donde un conductor comienza o termina un período de 
trabajo diario (anexo 1 B, requisito 087, y anexo 1 C, requisit os 108 
y 110).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 216
  
En lugar de placeRecord, la estructura de datos de la versión 2  de la 
segunda generación utiliza el siguiente elemento de datos:  
placeAuthRecord  contiene la información relativa al lugar introducido, 
la posición registrada, el estado de autenticación del GNSS y l a hora de 
determinación de la posición.  
▼B 
2.220.  VuPlaceDailyWorkPeriodRecordArray  
Generación 2:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a los lugares donde los conductores comienzan o terminan u n pe­
ríodo de trabajo diario (anexo 1C, requisitos 108 y 110).
  
recordType  denota el tipo de registro (VuPlaceDailyWorkPeriodRe­
cord).  Asignación de valor : véase RecordType.  
recordSize  es el tamaño de VuPlaceDailyWorkPeriodRecord en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es el conjunto de registros relativos a lugares.  
2.221.  VuPrivateKey  
Generación 1:  
La clave privada de una unidad instalada en el vehículo.
  
2.222.  VuPublicKey  
Generación 1:  
La clave pública de una unidad instalada en el vehículo.
  
▼M3 
2.222a.  VuRtcTime  
Generación 2, versión 2:  
La hora del reloj de tiempo real de la VU, transmitida por la V U a un 
dispositivo GNSS externo; véase el requisito GNS_3f del apéndic e 12.
  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 217  
2.223.  VuSerialNumber  
Número de serie de la unidad instalada en el vehículo (anexo 1B , 
requisito 075, y anexo 1C, requisito 93).
  
2.224.  VuSoftInstallationDate  
Fecha de instalación de la versión de  software  que lleva la unidad ins­
talada en el vehículo.
  
Asignación de valor : no especificado.  
2.225.  VuSoftwareIdentification  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva al  software  instalado.
  
vuSoftwareVersion  es el número de la versión de  software  que lleva la 
VU. 
vuSoftInstallationDate  es la fecha de instalación de la versión de  soft­
ware . 
2.226.  VuSoftwareVersion  
Número de la versión de  software  que lleva la VU.
  
Asignación de valor : no especificado.  
2.227.  VuSpecificConditionData  
Generación 1:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a condiciones específicas.
  
noOfSpecificConditionRecords  es el número de registros incluidos en 
el conjunto specificConditionRecords.  
specificConditionRecords  es el conjunto de registros relativos a condi­
ciones específicas.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 218  
2.228.  VuSpecificConditionRecordArray  
Generación 2:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a condiciones específicas (anexo 1C, requisito 130).
  
recordType  denota el tipo de registro (SpecificConditionRecord).  Asig­
nación de valor : véase RecordType.  
recordSize  es el tamaño de SpecificConditionRecord en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es un conjunto de registros relativos a condiciones específica s. 
2.229.  VuTimeAdjustmentData  
Generación 1:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a los ajustes de la hora que se han efectuado fuera del ma rco de un 
calibrado regular (anexo 1B, requisito 101).
  
noOfVuTimeAdjRecords  es el número de registros que hay en el con­
junto vuTimeAdjustmentRecords.  
vuTimeAdjustmentRecords  es un conjunto de registros sobre ajustes 
de la hora.  
▼M1 
2.230. Reservado para usos futuros  
2.231. Reservado para usos futuros  
▼B 
2.232.  VuTimeAdjustmentRecord  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a un ajuste de la hora efectuado fuera del marco de un cal ibrado 
regular (anexo 1B, requisito 101, y anexo 1C, requisitos 124 y 125).  
Generación 1:
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 219  
oldTimeValue, newTimeValue  son el valor anterior y el nuevo valor de 
la fecha y la hora.  
workshopName, workshopAddress  son el nombre y la dirección del 
taller.  
workshopCardNumber  identifica la tarjeta de taller empleada para re­
alizar el ajuste de la hora.  
Generación 2:
  
En lugar de workshopCardNumber, la estructura de datos de la ge nera­
ción 2 utiliza el siguiente elemento de datos:  
workshopCardNumberAndGeneration  identifica la tarjeta de taller, 
incluida su generación, empleada para realizar el ajuste de la hora.  
2.233.  VuTimeAdjustmentRecordArray  
Generación 2:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a ajustes de la hora que se han efectuado fuera del marco de un 
calibrado regular (anexo 1C, requisitos 124 y 125).
  
recordType  denota el tipo de registro (VuTimeAdjustmentRecord).  
Asignación de valor : véase RecordType.  
recordSize  es el tamaño de VuTimeAdjustmentRecord en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es un conjunto de registros de ajuste de la hora.  
2.234.  WorkshopCardApplicationIdentification  
Información almacenada en una tarjeta de taller y relativa a la  identifi­
cación de la aplicación de la tarjeta (anexo 1C, requisitos 307  y 330).  
Generación 1:
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 220  
typeOfTachographCardId  especifica el tipo de tarjeta utilizado.  
cardStructureVersion  especifica la versión de la estructura que se uti­
liza en la tarjeta.  
noOfEventsPerType  es el número de incidentes de cada tipo que puede 
registrar la tarjeta.  
noOfFaultsPerType  es el número de fallos de cada tipo que puede 
registrar la tarjeta.  
activityStructureLength  indica el número de bytes disponibles para 
almacenar registros de actividad.  
noOfCardVehicleRecords  es el número de registros del vehículo que 
caben en la tarjeta.  
noOfCardPlaceRecords  es el número de lugares que puede registrar la 
tarjeta.  
noOfCalibrationRecords  es el número de registros de calibrado que 
puede almacenar la tarjeta.  
Generación 2:  
▼M1
 
Además de los de la generación 1, se utilizan los siguientes el ementos 
de datos:  
noOfGNSSADRecords  es el número de registros GNSS de conducción 
acumulada que puede almacenar la tarjeta.  
noOfSpecificConditionRecords  es el número de registros de condicio­
nes específicas que puede almacenar la tarjeta.  
noOfCardVehicleUnitRecords  es el número de registros sobre unidades 
instaladas en vehículos que puede almacenar la tarjeta.  
▼M3 
2.234a.  WorkshopCardApplicationIdentificationV2  
Generación 2, versión 2:  
Información almacenada en una tarjeta de taller y relativa a la  identifi­
cación de la aplicación de la tarjeta (anexo I C, requisito 330  bis). ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 221
  
lengthOfFollowingData  es el número de bytes que siguen en el registro.  
noOfBorderCrossingRecords  es el número de registros de cruces de 
fronteras que puede almacenar la tarjeta de taller.  
noOfLoadUnloadRecords  es el número de registros de carga/descarga 
que puede almacenar la tarjeta de taller.  
noOfLoadTypeEntryRecords  es el número de registros de entradas de 
tipo de carga que puede almacenar la tarjeta de taller.  
vuConfigurationLengthRange  es el número de bytes de una tarjeta de 
tacógrafo disponibles para almacenar configuraciones de la VU.  
2.234b.  WorkshopCardCalibrationAddData  
Generación 2, versión 2:  
Información almacenada en una tarjeta de taller y relativa a lo s datos 
adicionales (es decir, el tipo de carga por defecto) introducid os durante 
un calibrado (anexo I C, requisito 356  terdecies ).
 
calibrationPointerNewestRecord  es el índice del último registro actua­
lizado de datos adicionales del calibrado.  
Asignación de valor : es el número correspondiente al numerador del 
registro de datos adicionales del calibrado, y al primer regist ro de datos 
adicionales del calibrado se le asigna en la estructura el núme ro «0».  
workshopCardCalibrationAddDataRecords  es el conjunto de registros 
que contienen el valor antiguo de fecha y hora, el valor de ide ntificación 
del vehículo y el tipo de carga por defecto del vehículo.  
2.234c.  WorkshopCardCalibrationAddDataRecord  
Generación 2, versión 2:  
Información almacenada en una tarjeta de taller y relativa al t ipo de 
carga por defecto introducido durante un calibrado (anexo I C, requisito 
356 duodecies ). ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 222
  
oldTimeValue  es el valor antiguo de fecha y hora contenido en el 
correspondiente WorkshopCardCalibrationRecord,  
vehicleIdentificationNumber  es el número de identificación del vehí­
culo, incluido también en el correspondiente WorkshopCardCalibr ation­
Record,  
byDefaultLoadType  es el tipo de carga por defecto del vehículo (solo 
presente en la versión 2),  
calibrationCountry  es el país en el que se ha realizado el calibrado,  
calibrationCountryTimestamp  es la fecha y la hora en las que el 
receptor GNSS proporcionó la posición utilizada para determinar  este 
país. 
▼B 
2.235.  WorkshopCardCalibrationData  
Información almacenada en una tarjeta de taller y relativa a la s activi­
dades del taller realizadas con dicha tarjeta (anexo 1C, requis itos 314, 
316, 337 y 339).
  
calibrationTotalNumber  es el número total de calibrados realizados 
con la tarjeta.  
calibrationPointerNewestRecord  es el índice del último registro de 
calibrado actualizado.  
Asignación de valor : número correspondiente al numerador del registro 
de calibrado. Al primer registro de la estructura se le asigna el número 
«0». 
calibrationRecords  es el conjunto de registros que contienen informa­
ción sobre calibrados y/o ajustes de la hora.  
2.236.  WorkshopCardCalibrationRecord  
Información almacenada en una tarjeta de taller y relativa a un  calibrado 
realizado con la tarjeta (anexo 1C, requisitos 314 y 337).  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 223  
Generación 1:
  
calibrationPurpose  es el propósito del calibrado.  
vehicleIdentificationNumber  es el VIN.  
vehicleRegistration  contiene el VRN y el nombre del Estado miembro 
donde se matriculó el vehículo.  
wVehicleCharacteristicConstant  es el coeficiente característico del ve­
hículo.  
kConstantOfRecordingEquipment  es la constante del aparato de 
control.  
lTyreCircumference  es la circunferencia efectiva de los neumáticos de 
las ruedas.  
tyreSize  son las dimensiones de las ruedas montadas en el vehículo.  
authorisedSpeed  es la velocidad máxima autorizada del vehículo.  
oldOdometerValue, newOdometerValue  son la lectura anterior y la 
nueva lectura del cuentakilómetros.  
oldTimeValue, newTimeValue  son el valor anterior y el nuevo valor de 
la fecha y la hora.  
nextCalibrationDate  es la fecha del próximo calibrado del tipo especi­
ficado en CalibrationPurpose, a cargo de la autoridad de contro l 
autorizada.  
vuPartNumber , vuSerialNumber  y sensorSerialNumber  son los ele­
mentos de datos para la identificación del aparato de control.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 224  
Generación 2:
  
Además de los de la generación 1, se utilizan los siguientes el ementos 
de datos:  
sensorGNSSSerialNumber  que identifica un dispositivo GNSS externo.  
rcmSerialNumber  que identifica un módulo de comunicación a 
distancia.  
sealDataCard  da información sobre los precintos colocados en diversos 
componentes del vehículo.  
2.237.  WorkshopCardHolderIdentification  
Información almacenada en una tarjeta de taller y relativa a la  identifi­
cación del titular de la tarjeta (anexo 1C, requisitos 311 y 33 4).
 
workshopName  es el nombre del taller que corresponde al titular de la 
tarjeta.  
workshopAddress  es la dirección del taller que corresponde al titular de 
la tarjeta.  
cardHolderName  es el nombre y los apellidos del titular (por ejemplo, 
el nombre del mecánico).  
cardHolderPreferredLanguage  es el idioma preferido por el titular de 
la tarjeta.  
2.238.  WorkshopCardPIN  
Número de identificación personal de la tarjeta de taller (anex o 1C. 
requisitos 309 y 332).
  
Asignación de valor : el PIN que conoce el titular de la tarjeta, rellenado 
por la derecha con bytes «FF» hasta llegar a 8 bytes.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 225  
2.239.  W-VehicleCharacteristicConstant  
Coeficiente característico del vehículo [definición k)].
  
Asignación de valor : impulsos por kilómetro en el intervalo operativo 
de 0 a 64 255 impulsos/km.  
2.240.  VuPowerSupplyInterruptionRecord  
Generación 2:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a incidentes de interrupción del suministro eléctrico (ane xo 1C, 
requisito 117).
  
eventType  es el tipo de incidente.  
eventRecordPurpose  es el propósito con que se ha registrado ese 
incidente.  
eventBeginTime  es la fecha y la hora de comienzo del incidente.  
eventEndTime  es la fecha y la hora en que termina el incidente.  
cardNumberAndGenDriverSlotBegin  identifica la tarjeta, incluida su 
generación, que estaba insertada en la ranura del conductor en el mo­
mento en que comenzó el incidente.  
cardNumberAndGenDriverSlotEnd  identifica la tarjeta, incluida su 
generación, que estaba insertada en la ranura del conductor en el mo­
mento en que terminó el incidente.  
cardNumberAndGenCodriverSlotBegin  identifica la tarjeta, incluida 
su generación, que estaba insertada en la ranura del segundo co nductor 
en el momento en que comenzó el incidente.  
cardNumberAndGenCodriverSlotEnd  identifica la tarjeta, incluida su 
generación, que estaba insertada en la ranura del segundo condu ctor en 
el momento en que terminó el incidente.  
similarEventsNumber  es el número de incidentes similares ocurridos 
ese día.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 226  
2.241.  VuPowerSupplyInterruptionRecordArray  
Generación 2:  
Información almacenada en una unidad instalada en el vehículo y  rela­
tiva a incidentes de interrupción del suministro eléctrico (ane xo 1C, 
requisito 117).
  
recordType  denota el tipo de registro (VuPowerSupplyInterruptionRe­
cord).  Asignación de valor : véase RecordType.  
recordSize  es el tamaño de VuPowerSupplyInterruptionRecord en bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es un conjunto de registros sobre incidentes de interrupción d el 
suministro eléctrico.  
2.242.  VuSensorExternalGNSSCoupledRecordArray  
Generación 2:  
Conjunto de SensorExternalGNSSCoupledRecord más metadatos tal y  
como se utiliza en el protocolo de transferencia.
  
recordType  denota el tipo de registro (SensorExternalGNSSCoupledRe­
cord).  Asignación de valor : véase RecordType.  
recordSize  es el tamaño de SensorExternalGNSSCoupledRecord en 
bytes.  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es un conjunto de registros de SensorExternalGNSSCoupled.  
2.243.  VuSensorPairedRecordArray  
Generación 2:  
Conjunto de SensorPairedRecord más metadatos tal y como se util iza en 
el protocolo de transferencia.
  
recordType  denota el tipo de registro (SensorPairedRecord).  Asigna­
ción de valor : véase RecordType.  
recordSize  es el tamaño de SensorPairedRecord en bytes.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 227  
noOfRecords  es el número de registros que hay en el conjunto.  
records  es un conjunto de registros de acoplamiento de sensor.  
3. DEFINICIONES DE LOS INTERVALOS DE VALORES Y TAMA­
ÑOS ADMISIBLES  
Definición de valores variables empleados en las definiciones d el apar­
tado 2.
  
4. JUEGOS DE CARACTERES  
Las cadenas IA5 utilizan los caracteres ASCII que se definen en  la 
norma ISO/CEI 8824-1. Para facilitar la lectura y las referenci as, a 
continuación se ofrece la asignación de valores. La norma ISO/C EI 
8824-1 prevalece sobre esta nota informativa en caso de discrep ancia.
  
Otras cadenas de caracteres (Address, Name, VehicleRegistration Num­
ber) utilizan, asimismo, los caracteres del código de caractere s decimales 
161 a 255 del código estándar de 8 bits siguiente, especificado s por el 
número de página de código: 
Conjunto de caracteres estándar  Página de código 
(Decimal)  
ISO/CEI 8859-1 Latín-1, Europa Occidental  1  
ISO/CEI 8859-2 Latín-2, Europa Central  2  
ISO/CEI 8859-3 Latín-3, Europa Meridional  3  
ISO/CEI 8859-5 Latín / Cirílico  5  
ISO/CEI 8859-7 Latín / Griego  7  
ISO/CEI 8859-9 Latín-5 / Turco  9  
ISO/CEI 8859-13 Latín-7 / Países Bálticos  1 3  
ISO/CEI 8859-15 Latín-9  1 5  
ISO/CEI 8859-16 Latín-10, Europa Sudoriental  1 6  
KOI8-R Latín / Cirílico  8 0  
KOI8-U Latín / Cirílico  8 5  
5. CODIFICACIÓN  
Si se aplican las reglas de codificación NSA.1, todos los tipos  de datos 
definidos deberán codificarse con arreglo a la norma ISO/CEI 88 25-2, 
variante alineada.  
6. IDENTIFICADORES DE OBJETO E IDENTIFICADORES DE APLI­
CACIÓN  
6.1. Identificadores de objeto  
Los identificadores de objeto (OID) que figuran en el 
presente capítulo solo son pertinentes para la generación 2. Es tos OID se  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 228  
especifican en TR-03110-3 y se repiten aquí en aras de la exhau stividad. 
Estos OID están contenidos en el subárbol de bsi-de:
  
Identificadores del protocolo de autenticación de la VU
  
Ejemplo:  Supongamos que la autenticación de la VU debe hacerse con 
SHA- 384; en tal caso, se utilizará el identificador de objeto (en notación 
ASN.1)
  . El 
valor de este identificador de objeto en notación de puntos es
  
. 
Notación de puntos  Notación de bytes
  
«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»  
Identificadores del protocolo de autenticación del chip
  
Ejemplo:  Supongamos que la autenticación del chip se hará utili­
zando el algoritmo ECDH, que da lugar a una longitud de clave 
de sesión AES de 128 bits. Esta clave de sesión se utilizará lu ego 
en el modo de funcionamiento CBC para garantizar la confiden­
cialidad de los datos y con el algoritmo CMAC para garantizar l a 
autenticidad de los datos. Por consiguiente, el identificador d e 
objeto que hay que usar es (en notación ASN.1)
  
. El valor de 
este identificador de objeto en notación de puntos es
  
. 
Notación de puntos  Notación de bytes
  
«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 — ES — 21.08.2023 — 003.001 — 229  
6.2. Identificadores de aplicación  
Generación 2:  
El identificador de aplicación (AID) para el dispositivo GNSS e xterno 
(generación 2) viene dado por «FF 44 54 45 47 4D». Se trata de un AID 
propio con arreglo a la norma ISO/CEI 7816-4.  
Nota:  Los últimos 5 bytes codifican DTEGM para el dispositivo GNSS 
externo del tacógrafo.  
El identificador de aplicación para la aplicación de la tarjeta  de tacógrafo 
de generación 2 viene dado por «FF 53 4D 52 44 54». Se trata de  un 
AID propio con arreglo a la norma ISO/CEI 7816-4.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 230  
Apéndice 2  
ESPECIFICACIONES DE LAS TARJETAS DE TACÓGRAFO  
ÍNDICE  
1. INTRODUCCIÓN  
1.1. Abreviaciones  
1.2. Referencias  
2. CARACTERÍSTICAS ELÉCTRICAS Y FÍSICAS  
2.1. Tensión de alimentación y consumo de corriente  
2.2. Tensión de programación V  pp 
2.3. Generación y frecuencia del reloj  
2.4. Contacto de entrada/salida  
2.5. Estados de la tarjeta  
3. SOPORTE FÍSICO Y COMUNICACIONES  
3.1. Introducción  
3.2. Protocolo de transmisión  
3.2.1 Protocolos  
3.2.2 ATR  
3.2.3 PTS  
3.3. Normas de acceso  
3.4. Visión general de los comandos y los códigos de error  
3.5. Descripción de los comandos  
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 — ES — 21.08.2023 — 003.001 — 231  
3.5.14 PSO: COMPUTE DIGITAL SIGNATURE  
3.5.15 PSO: VERIFY DIGITAL SIGNATURE  
3.5.16 PROCESS DSRC MESSAGE  
4. ESTRUCTURA DE LAS TARJETAS DE TACÓGRAFO  
4.1. Archivo maestro MF  
4.2. Aplicaciones de la tarjeta del conductor  
4.2.1 Aplicación de la tarjeta de conductor de generación 1  
4.2.2 Aplicación de la tarjeta de conductor de generación 2  
4.3. Aplicaciones de la tarjeta de taller  
4.3.1 Aplicación de la tarjeta de taller de generación 1  
4.3.2 Aplicación de la tarjeta de taller de generación 2  
4.4. Aplicaciones de la tarjeta de control  
4.4.1 Aplicación de la tarjeta de control de generación 1  
4.4.2 Aplicación de la tarjeta de control de generación 2  
4.5. Aplicaciones de la tarjeta de empresa  
4.5.1 Aplicación de la tarjeta de empresa de generación 1  
4.5.2 Aplicación de la tarjeta de empresa de generación 2  
1. INTRODUCCIÓN  
1.1. Abreviaciones  
A efectos del presente apéndice se utilizan las siguientes sigl as: 
AC Condiciones de acceso  
AES Norma de cifrado avanzado  
AID Identificador de aplicación  
ALW Siempre  
APDU Unidad de datos de protocolo de una aplicación (estruc­
tura de un comando)  
ATR Respuesta a reinicio  
AUT Autentificado  
C6, C7 Contactos n.  o 6 y 7 de la tarjeta, tal y como se describen 
en la norma ISO/CEI 7816-2  
cc Ciclos de reloj  
▼M1 
CHA Autorización del titular del certificado  
▼B 
CHV Información para la verificación del titular de la tarjeta  
CLA Byte de clase de un comando APDU  
▼M1 
DO Objeto de datos  
▼B 
DSRC Comunicación especializada de corto alcance  
DF Archivo dedicado. Un DF puede contener otros archivos 
(EF o DF)  
ECC Criptografía de curva elíptica  
EF Archivo elemental  
etu Unidad de tiempo elemental  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 232  
G1 Generación 1  
G2 Generación 2  
IC Circuito integrado  
ICC Tarjeta de circuito integrado  
ID Identificador  
IFD Dispositivo de interfaz  
IFS Tamaño del campo de información  
IFSC Tamaño del campo de información para la tarjeta  
IFSD Dispositivo de tamaño del campo de información (para el 
terminal)  
INS Byte de instrucción de un comando APDU  
Lc Longitud de los datos de entrada para un comando APDU  
Le Longitud de los datos esperados (datos de salida para un 
comando)  
MF Archivo principal (DF raíz)  
NAD Dirección de nodo empleada en el protocolo T=1  
NEV Nunca  
P1-P2 Bytes de parámetros  
PIN Número de identificación personal  
PRO SM Protegido con mensajería segura  
PTS Selección de la transmisión de protocolo  
RFU Reservado para uso futuro  
RST Reinicio (de la tarjeta)  
SFID Identificador EF corto  
SM Mensajería segura  
SW1-SW2 Bytes de estado  
TS Carácter ATR inicial  
VPP Tensión de programación  
VU Unidad instalada en el vehículo  
XXh Valor XX en notación hexadecimal  
«XXh» Valor XX en notación hexadecimal  
|| Símbolo de concatenación 03||04=0304  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 233  
1.2. Referencias  
En el presente apéndice se utilizan las referencias siguientes:  
ISO/CEI 7816-2 Tarjetas de identificación — Tarjetas de circuit o(s) 
integrado(s) — Parte 2: Dimensiones y ubicación 
de los contactos. ISO/CEI 7816-2:2007.  
ISO/CEI 7816-3 Tarjetas de identificación — Tarjetas de circuit o(s) 
integrado(s) — Parte 3: Interfaz eléctrica y proto­
colos de transmisión. ISO/CEI 7816-3:2006.  
ISO/CEI 7816-4 Tarjetas de identificación — Tarjetas de circuit o(s) 
integrado(s) — Parte 4: Organización, seguridad y 
comandos para intercambio. ISO/CEI 7816-4:2013 
+ Cor 1: 2014.  
ISO/CEI 7816-6 Tarjetas de identificación — Tarjetas de circuit o(s) 
integrado(s) — Parte 6: Elementos de datos inte­
rindustriales para intercambio. ISO/CEI 7816- 
6:2004 + Cor 1: 2006.  
ISO/CEI 7816-8 Tarjetas de identificación — Tarjetas de circuit o(s) 
integrado(s) — Parte 8: Comandos para operacio­
nes de seguridad. ISO/CEI 7816-8:2004.  
ISO/CEI 9797-2 Tecnología de la información — Técnicas de segu­
ridad — Códigos de autenticación de mensajes 
(MACs) — Parte 2: Mecanismos que utilizan una 
función específica de comprobación aleatoria. ISO/ 
CEI 9797-2:2011  
2. CARACTERÍSTICAS ELÉCTRICAS Y FÍSICAS  
TCS_01 Todas las señales electrónicas deberán ser conformes a l a 
norma ISO/CEI 7816-3, a menos que se especifique otra 
cosa.  
TCS_02 La ubicación y dimensiones de los contactos de las tarje tas 
se ajustarán a lo dispuesto en la norma ISO/CEI 7816-2.  
2.1. Tensión de alimentación y consumo de corriente  
TCS_03 La tarjeta deberá trabajar con arreglo a las especificac iones, 
dentro de los límites de consumo especificados en la norma 
ISO/CEI 7816-3.  
TCS_04 La tarjeta debe funcionar con Vcc = 3V (± 0,3 V) o con 
Vcc = 5V (± 0,5 V).  
La tensión deberá seleccionarse con arreglo a lo dispuesto 
en la norma ISO/CEI 7816-3.  
2.2. Tensión de programación V  pp 
TCS_05 La tarjeta no debe requerir tensión de programación en l a 
patilla C6. Se espera que la patilla C6 no esté conectada a 
un IFD. El contacto C6 podrá estar conectado a la tensión 
V cc de la tarjeta, pero no a masa. Dicha tensión no deberá 
interpretarse en ningún caso.  
2.3. Generación y frecuencia del reloj  
TCS_06 La tarjeta deberá funcionar en el intervalo de frecuenci as de 
1 a 5 MHz y debe admitir frecuencias mayores. La frecuen­
cia del reloj podrá experimentar una variación del ± 2 % 
dentro de una sesión de la tarjeta. La frecuencia del reloj la 
genera la Unidad instalada en el vehículo (VU) y no la 
propia tarjeta. El ciclo de trabajo puede variar entre el 
40 % y el 60 %.  
TCS_07 El reloj externo puede ser detenido en las condiciones q ue 
especifica el archivo EF ICC de la tarjeta. El primer byte 
del cuerpo del archivo EF ICC codifica las condiciones del 
modo clockstop:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 234  
Bajo  Alto  
Bit 3  Bit 2  Bit 1  
0 0  1  Se permite clockstop, no hay un nivel preferido  
0 1  1  Se permite clockstop, preferiblemente en el nivel 
alto 
1 0  1  Se permite clockstop, preferiblemente en el nivel 
bajo 
0 0  0  No se permite clockstop  
0 1  0  Se permite clockstop exclusivamente en el nivel 
alto 
1 0  0  Se permite clockstop exclusivamente en el nivel 
bajo 
Los bits 4 a 8 no se utilizan.  
2.4. Contacto de entrada/salida  
TCS_08 El contacto C7 de entrada/salida sirve para recibir y tr ans­
mitir datos al IFD. Durante el funcionamiento de dicho 
contacto, tan solo podrán estar en modo de transmisión la 
tarjeta o el IFD. Si ambas unidades estuvieran en el modo 
de transmisión, la tarjeta no deberá sufrir daños. A menos 
que se esté transmitiendo, la tarjeta deberá entrar en el 
modo de recepción.  
2.5. Estados de la tarjeta  
TCS_09 La tarjeta trabaja en dos estados mientras se aplica la ten­
sión de alimentación:  
▼M3 
estado de funcionamiento mientras se ejecutan los coman­
dos o se mantiene la interconexión con la unidad instalada 
en el vehículo,  
▼B 
en estado de reposo en el resto de casos; en este estado la 
tarjeta deberá retener todos los datos.  
3. SOPORTE FÍSICO Y COMUNICACIONES  
3.1. Introducción  
El presente apartado describe la funcionalidad mínima que preci san 
las tarjetas de tacógrafo y las VU para garantizar un correcto funcio­
namiento e interoperabilidad.  
Las tarjetas de tacógrafo cumplen en todo lo posible las normas  ISO/ 
CEI aplicables (en especial la norma ISO/CEI 7816). No obstante , a 
continuación se ofrece una descripción completa de los comandos  y  
protocolos a fin de especificar algunos casos de uso restringid o o 
determinadas diferencias que puedan existir. Los comandos espec ifi­
cados son totalmente conformes a las normas citadas, salvo en l os 
casos que se indican.  
3.2. Protocolo de transmisión  
TCS_10 El protocolo de transmisión deberá ser conforme a la nor ma 
ISO/CEI 7816-3 para T = 0 y T = 1. En particular, la VU 
deberá reconocer las extensiones de tiempo de espera que 
envíe la tarjeta.  
3.2.1  Protocolos  
TCS_11 La tarjeta deberá ofrecer los protocolos  T = 0  y T = 1 . 
Además, la tarjeta podrá admitir otros protocolos orientados 
a la conexión.  
TCS_12  T = 0  es el protocolo por defecto, de modo que se precisa 
un comando  PTS  para cambiar al protocolo  T = 1 . ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 235  
TCS_13 Los dispositivos deberán admitir la  convención directa  en 
ambos protocolos: por consiguiente, la convención directa 
es obligatoria para la tarjeta.  
TCS_14 El byte correspondiente al  tamaño del campo de informa ­
ción de la tarjeta  en la ATR deberá presentarse en el 
carácter TA3. Este valor deberá ser al menos «F0h» (= 
240 bytes).  
Los protocolos estarán sujetos a las restricciones siguientes:  
TCS_15  T=0  
— El dispositivo de interfaz deberá admitir una respuesta 
en la entrada/salida después del flanco ascendente de la 
señal en RST a partir de 400 cc.  
— El dispositivo de interfaz deberá ser capaz de leer ca­
racteres separados por 12 etu.  
— El dispositivo de interfaz deberá leer un carácter erró­
neo y su repetición cuando estén separados por 13 etu. 
Si se detecta un carácter erróneo, la señal de error en la 
entrada/salida puede ocurrir entre 1 etu y 2 etu más 
tarde. El dispositivo deberá admitir un retardo de 1 etu.  
— El dispositivo de interfaz deberá aceptar una respuesta 
ATR de 33 bytes (TS+32).  
— Si TC1 está presente en la respuesta ATR, el Extra 
Guard Time deberá estar presente para los caracteres 
que envíe el dispositivo de interfaz, aunque los carac­
teres que envíe la tarjeta igualmente podrán estar sepa­
rados por 12 etu. Este principio también es cierto para 
el carácter ACK que envía la tarjeta después de que el 
dispositivo de interfaz haya emitido un carácter P3.  
— El dispositivo de interfaz deberá tener en cuenta los 
caracteres NUL que pueda emitir la tarjeta.  
— El dispositivo de interfaz deberá aceptar el modo com­
plementario de ACK.  
— El comando GET RESPONSE no se puede utilizar en 
el modo de encadenamiento para obtener un dato cuya 
longitud podría sobrepasar 255 bytes.  
TCS_16  T=1  
— NAD Byte: no se utiliza (la dirección NAD deberá 
configurarse a «00»).  
— S-block ABORT: no se utiliza.  
— S-block VPP state error: no se utiliza.  
▼M3 __________  
▼B 
— El IFD deberá indicar el dispositivo de tamaño del 
campo de información (IFSD) inmediatamente después 
de la respuesta ATR: el IFD deberá transmitir la peti­
ción de S-Block IFS después de la ATR y la tarjeta 
deberá enviar el S-Block IFS. El valor recomendado 
para el IFSD es 254 bytes.  
— La tarjeta no pedirá un reajuste del IFS.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 236  
3.2.2  ATR  
TCS_17 El dispositivo comprueba los bytes ATR, de acuerdo con l a 
norma ISO/CEI 7816-3. No se verificarán los caracteres 
históricos ATR.  
Ejemplo de biprotocolo básico ATR con arreglo a la norma 
ISO/CEI 7816-3  
▼C2 
Carácter  Valor  Observaciones  
TS «3Bh»  Indica convención directa.  
T0 «85h»  TD1 presente; hay 5 bytes históricos presentes  
TD1 «80h»  TD2 presente; ha de utilizarse T = 0  
TD2 «11h»  TA3 presente; ha de utilizarse T = 1  
TA3 «XXh» (al menos 
«F0h»)  Tamaño del campo de información para la 
tarjeta (IFSC)  
TH1 a TH5  «XXh»  Caracteres históricos  
TCK  «XXh»  Comprobar carácter (OR exclusivo)  
▼B 
TCS_18 Después de la Answer To Reset (ATR), el archivo 
principal (MF) se selecciona de manera implícita y pasa a 
ser el directorio actual.  
3.2.3  PTS  
TCS_19 El protocolo por defecto es T=0. Para configurar el prot o­
colo T=1, es preciso que el dispositivo envíe a la tarjeta 
una selección PTS (también denominada PPS).  
TCS_20 Dado que tanto el protocolo T=0 como el T=1 son obliga­
torios para la tarjeta, la selección PTS básica de conmuta­
ción de protocolos es obligatoria para la tarjeta.  
La selección PTS se puede utilizar, tal y como se indica en 
la norma ISO/CEI 7816-3, para cambiar a una velocidad en 
baudios más alta que la velocidad que propone por defecto 
la tarjeta en la respuesta ATR, en su caso [byte TA(1)].  
Opcionalmente, la tarjeta puede funcionar a velocidad en 
baudios más altas.  
TCS_21 Si no se admiten otras velocidades en baudios aparte de la 
que se ajusta por defecto (o si la velocidad en baudios 
seleccionada es inadmisible), la tarjeta deberá responder a 
la selección PTS en la forma correcta según la norma ISO/ 
CEI 7816-3, es decir, omitiendo el byte PPS1.  
A continuación se ofrecen varios ejemplos de PTS básica 
selección de protocolo:  
▼C2 
Carácter  Valor  Observaciones  
PPSS  «FFh»  El carácter de inicio  
PPS0  «00h» o bien 
«01h»  PPS1 a PPS3 no están presentes; «00h» para seleccionar 
T0, «01h» para seleccionar T1  
PK «XXh»  Comprobar carácter: «XXh» = «FFh» si PPS0 = «00h», 
«XXh» = «FEh» si PPS0 = «01h»  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 237  
3.3. Normas de acceso  
TCS_22 Una norma de acceso especifica las condiciones de seguri ­
dad correspondientes para un modo de acceso, es decir, un 
comando. Si se cumplen estas condiciones de seguridad, se 
procesa el comando correspondiente.  
TCS_23 Se utilizan las condiciones de seguridad siguientes para  la 
tarjeta de tacógrafo:  
Abreviación  Significado  
ALW  La acción siempre es posible y se puede ejecutar sin restricci ones. El co­
mando y la respuesta APDU se envían en texto simple, es decir, sin mensa­
jería segura.  
NEV  La acción nunca es posible.  
PLAIN-C  El comando APDU se envía en texto simple, es decir, sin mensaj ería segura.  
PWD  La acción solo puede ejecutarse si el PIN de la tarjeta de tal ler se verifica 
correctamente, es decir, si se ha configurado el estado de segu ridad interna de 
la tarjeta «PIN_Verified». El comando debe enviarse sin mensaje ría segura.  
EXT-AUT-G1  La acción puede ejecutarse solo si se ha ejecutado correctamen te el comando 
External Authenticate para la autenticación de generación 1 (vé ase también la 
parte A del apéndice 11).  
SM-MAC-G1  El APDU (comando y respuesta) debe aplicarse con mensajería se gura de 
generación 1 en modo exclusivamente de autenticación (véase la parte A 
del apéndice 11).  
SM-C-MAC-G1  El comando APDU debe aplicarse con mensajería segura de genera ción 1 en 
modo exclusivamente de autenticación (véase la parte A del apén dice 11).  
SM-R-ENC-G1  La respuesta APDU debe aplicarse con mensajería segura de gene ración 1 en 
modo de cifrado (véase la parte A del apéndice 11), es decir, n o se devuelve 
ningún código de autenticación de mensajes.  
SM-R-ENC- 
MAC-G1  La respuesta APDU debe aplicarse con mensajería segura de gener ación 1 en 
modo de cifrado y posteriormente autenticación (véase la parte A del apéndice 
11). 
SM-MAC-G2  El APDU (comando y respuesta) debe aplicarse con mensajería se gura de 
generación 2 en modo exclusivamente de autenticación (véase la parte B 
del apéndice 11).  
SM-C-MAC-G2  El comando APDU debe aplicarse con mensajería segura de genera ción 2 en 
modo exclusivamente de autenticación (véase la parte B del apén dice 11).  
SM-R-ENC- 
MAC-G2  La respuesta APDU debe aplicarse con mensajería segura de gener ación 2 en 
modo de cifrado y posteriormente autenticación (véase la parte B del apéndice 
11). 
▼M1 
TCS_24 Estas condiciones de seguridad pueden enlazarse de los 
modos siguientes:  
AND: deben cumplirse todas las condiciones de seguridad;  
OR: debe cumplirse al menos una condición de seguridad.  
Las normas de acceso para el sistema de archivos, es decir, 
los comandos SELECT, READ BINARY y UPDATE BI­
NARY, se especifican en el apartado 4. Las normas de 
acceso para el resto de los comandos se especifican en 
las tablas siguientes. El término «no aplicable» se utiliza 
si no existe ningún requisito para admitir el comando. En 
este caso, el comando puede ser o no ser admitido, pero la 
condición de acceso es «fuera de ámbito».  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 238  
TCS_25 En la aplicación DF tacógrafo G1, se utilizan las siguie ntes 
normas de acceso:  
▼M1 
Comando  Tarjeta de con­
ductor  Tarjeta de taller  Tarjeta de con­
trol Tarjeta de em­
presa 
External Authenticate  
— Para autenticación de gene­
ración 1  ALW  ALW  ALW  ALW  
— Para autenticación de gene­
ración 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  No aplicable  No aplicable  No aplicable  No aplicable  
PSO: Compute Digital Signature  ALW OR 
SM-MAC- 
G2 ALW OR 
SM-MAC- 
G2 No aplicable  No aplicable  
PSO: Hash  No aplicable  No aplicable  ALW  No aplicable  
PERFORM HASH of FILE  ALW OR 
SM-MAC- 
G2 ALW OR 
SM-MAC- 
G2 No aplicable  No aplicable  
PSO: Verify Certificate  ALW  ALW  ALW  ALW  
PSO: Verify Digital Signature  No aplicable  No aplicable  ALW  No aplicable  
Verify  No aplicable  ALW  No aplicable  No aplicable  
▼B 
TCS_26 En la aplicación DF tacógrafo_G2, se utilizan las siguie ntes 
normas de acceso:  
▼M1 
Comando  Tarjeta de con­
ductor  Tarjeta de taller  Tarjeta de con­
trol Tarjeta de em­
presa 
External Authenticate  
— Para autenticación de gene­
ración 1  No aplicable  No aplicable  No aplicable  No aplicable  
— Para autenticación de gene­
ración 2  ALW  PWD  ALW  ALW  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 239  
Comando  Tarjeta de con­
ductor  Tarjeta de taller  Tarjeta de con­
trol Tarjeta de em­
presa 
Internal Authenticate  No aplicable  No aplicable  No aplicable  No aplicable  
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  No aplicable  ALW  ALW  No aplicable  
PSO: Compute Digital Signature  ALW OR 
SM-MAC- 
G2 ALW OR 
SM-MAC- 
G2 No aplicable  No aplicable  
PSO: Hash  No aplicable  No aplicable  ALW  No aplicable  
PERFORM HASH of FILE  ALW OR 
SM-MAC- 
G2 ALW OR 
SM-MAC- 
G2 No aplicable  No aplicable  
PSO: Verify Certificate  ALW  ALW  ALW  ALW  
PSO: Verify Digital Signature  No aplicable  No aplicable  ALW  No aplicable  
Verify  No aplicable  ALW  No aplicable  No aplicable  
▼B 
TCS_27 En el MF, se utilizan las siguientes normas de acceso:  
▼M1 
Comando  Tarjeta de con­
ductor  Tarjeta de taller  Tarjeta de con­
trol Tarjeta de em­
presa 
External Authenticate  
— Para la autenticación de ge­
neración 1  No aplicable  No aplicable  No aplicable  No aplicable  
— Para la autenticación de ge­
neración 2  ALW  PWD  ALW  ALW  
Internal Authenticate  No aplicable  No aplicable  No aplicable  No aplicable  
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 — ES — 21.08.2023 — 003.001 — 240  
Comando  Tarjeta de con­
ductor  Tarjeta de taller  Tarjeta de con­
trol Tarjeta de em­
presa 
Process DSRC Message  No aplicable  No aplicable  No aplicable  No aplicable  
PSO: Compute Digital Signature  No aplicable  No aplicable  No aplicable  No aplicable  
PSO: Hash  No aplicable  No aplicable  No aplicable  No aplicable  
PERFORM HASH of FILE  No aplicable  No aplicable  No aplicable  No aplicable  
PSO: Verify Certificate  ALW  ALW  ALW  ALW  
PSO: Verify Digital Signature  No aplicable  No aplicable  No aplicable  No aplicable  
Verify  No aplicable  ALW  No aplicable  No aplicable  
▼B 
TCS_28 Una tarjeta de tacógrafo puede o no aceptar un comando 
con un nivel de seguridad superior al especificado en las 
condiciones de seguridad. Es decir, si la condición de se­
guridad es ALW (o PLAIN-C), la tarjeta puede aceptar un 
comando con mensajería segura (modo de cifrado y/o au­
tenticación). Si la condición de seguridad requiere mensa­
jería segura con modo de autenticación, la tarjeta del tacó­
grafo puede aceptar un comando con mensajería segura de 
la misma generación en modo de autenticación y cifrado.  
Nota:  Las descripciones de los comandos ofrecen más in­
formación acerca de la compatibilidad de los comandos con 
distintos tipos de tarjetas de tacógrafo y diferentes DF.  
3.4. Visión general de los comandos y los códigos de error  
Los comandos y la organización de archivos se deducen de la nor ma 
ISO/CEI 7816-4 y se ajustan a ella.  
En esta sección se describen los siguientes pares comando 
APDU-respuesta. Las variantes de comandos que admite una aplica ­
ción de generación 1 y 2 se especifican en las descripciones co rres­
pondientes de los comandos.  
Comando  INS  
SELECT  «A4h»  
READ BINARY  «B0h», «B1h»  
UPDATE BINARY  «D6h», «D7h»  
GET CHALLENGE  «84h»  
VERIFY  «20h»  
GET RESPONSE  «C0h»  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 241  
Comando  INS  
PERFORM SECURITY OPERA­
TION  «2Ah»  
— VERIFY CERTIFICATE  
— COMPUTE DIGITAL SIGNA­
TURE  
— VERIFY DIGITAL SIGNA­
TURE  
— HASH  
— PERFORM HASH OF FILE  
— PROCESS DSRC MESSAGE  
INTERNAL AUTHENTICATE  «88h»  
EXTERNAL AUTHENTICATE  «82h»  
MANAGE SECURITY ENVIRON­
MENT  «22h»  
— SET DIGITAL SIGNATURE 
TEMPLATE  
— SET AUTHENTICATION TEM­
PLATE  
GENERAL AUTHENTICATE  «86h»  
▼M1 
TCS_29 Las palabras de estado SW1 SW2 aparecen en todos los 
mensajes de respuesta e indican el estado de procesado del 
comando.  
SW1  SW2  Significado  
90 0 0  Procesamiento normal.  
61 X X  Procesamiento normal. XX = número de bytes de respuesta 
disponibles.  
62 8 1  Procedimiento de aviso. Una parte de los datos devueltos puede  
estar dañada.  
63 0 0  Ha fallado la autenticación (Advertencia).  
63 C X  CHV (PIN) incorrecto. «X» indica el contador de intentos 
restantes.  
64 0 0  Error de ejecución. No ha variado el estado de la memoria per­
manente. Error de integridad.  
65 0 0  Error de ejecución. Ha variado el estado de la memoria 
permanente.  
65 8 1  Error de ejecución. Ha variado el estado de la memoria perma­
nente. Fallo de memoria.  
66 8 8  Error de seguridad: suma de control criptográfica incorrecta 
(durante la mensajería segura), o bien 
certificado incorrecto (durante la verifica­
ción del certificado), o bien 
criptograma incorrecto (durante la autenti­
cación externa), o bien 
firma incorrecta (durante la verificación de 
la firma).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 242  
SW1  SW2  Significado  
67 0 0  Longitud incorrecta (Lc o Le incorrecta).  
68 8 3  Último comando de la cadena esperado.  
69 0 0  Comando prohibido (no hay respuesta disponible en T=0).  
69 8 2  Estado de seguridad no satisfecho.  
69 8 3  Método de autenticación bloqueado.  
69 8 5  Condiciones de uso no satisfechas.  
69 8 6  Comando no autorizado (falta el EF actual).  
69 8 7  Faltan objetos de datos de mensajería segura que se esperaban.  
69 8 8  Objetos de datos de mensajería segura incorrectos.  
6A 8 0  Parámetros incorrectos en el campo de datos.  
6A 8 2  Archivo no encontrado.  
6A 8 6  Parámetros P1-P2 incorrectos.  
6A 8 8  Datos referenciados no encontrados.  
6B 0 0  Parámetros incorrectos (desviación fuera del EF).  
6C X X  Longitud incorrecta, SW2 indica la longitud exacta. No se de­
vuelve un campo de datos.  
6D 0 0  Código de instrucción no admitido o no válido.  
6E 0 0  Clase no admitida.  
6F 0 0  — Otros errores de comprobación  
Pueden devolverse otras palabras de estado como las defi­
nidas en la norma ISO/CEI 7816-4, si su comportamiento 
no se menciona explícitamente en el presente apéndice.  
Por ejemplo, existe la opción de devolver las siguientes 
palabras de estado:  
6881: Canal lógico no admitido  
6882: Mensajería segura no admitida.  
▼B 
TCS_30 Si se cumplen más de una condición de error en un co­
mando APDU, la tarjeta puede devolver cualquiera de las 
palabras de estado adecuada.  
3.5. Descripción de los comandos  
En el presente apartado se describen los comandos obligatorios para 
las tarjetas de tacógrafo.  
En el apéndice 11 (Mecanismos de seguridad comunes) hallará otr os 
pormenores relevantes relacionados con las operaciones criptogr áficas 
que es preciso realizar para tacógrafos de generación 1 y gener a­
ción 2.  
Todos los comandos se describen con independencia del protocolo  
utilizado (T=0 o T=1). Los bytes APDU CLA, INS, P1, P2, Lc y 
Le siempre se indican. Si el byte Lc o Le no es necesario para el 
comando descrito, entonces la longitud, el valor y la descripci ón 
asociados están vacíos.  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 243  
TCS_31 Si se solicitan los dos bytes de longitud (Lc y Le) y ad emás 
el IFD está utilizando el protocolo T=0, es preciso dividir 
en dos partes el comando descrito: el IFD envía el co­
mando del modo descrito con P3 = Lc + datos y seguida­
mente envía un comando GET RESPONSE (véase § 3.5.6) 
con P3=Le.  
TCS_32 Si se solicitan los dos bytes de longitud y Le=0 (mensaj ería 
segura):  
— en caso de utilizarse el protocolo T=1, la tarjeta deberá 
responder a Le=0 enviando todos los datos de salida 
disponibles;  
— en caso de utilizarse el protocolo T=0, el IFD deberá 
enviar el primer comando con P3 = Lc + datos, la tar­
jeta deberá responder (a este Le=0 implícito) con los 
bytes de estado « 61La », donde La es el número de 
bytes de respuesta disponibles. A continuación, el IFD 
deberá generar un comando GET RESPONSE con P3 = 
La para leer los datos.  
TCS_33 Una tarjeta de tacógrafo podría admitir campos de longit ud 
ampliada conforme a ISO/CEI 7816-4 como función opcio­
nal. Una tarjeta de tacógrafo que admita campos de longi­
tud ampliada deberá:  
— indicar la compatibilidad con los campos de longitud 
ampliada en la ATR;  
— proporcionar los tamaños de memoria temporal admiti­
dos por medio de la información de longitud ampliada 
en el EF ATR/INFO, véase TCS_146;  
— indicar si admite campos de longitud ampliada para T = 
1 y/o T = 0 en la longitud ampliada de EF, véase 
TCS_147;  
— admitir campos de longitud ampliada para la aplicación 
de tacógrafo de generación 1 y 2.  
Notas:  
Las especificaciones de todos los comandos son para cam­
pos de longitud corta. El uso de APDU de longitud am­
pliada está claro en ISO/CEI 7816-4.  
Por lo general, se especifican los comandos para el modo 
director, es decir, sin mensajería segura, ya que la capa de 
mensajería segura se especifica en el apéndice 11. Se de­
duce claramente de las normas de acceso de un comando si 
este debe admitir mensajería segura o no y si el comando 
debe admitir mensajería segura de generación 1 y/o gene­
ración 2. Algunas variantes de comandos se describen con 
mensajería segura para ilustrar el uso de la mensajería 
segura.  
TCS_34 La VU deberá ejecutar todo el protocolo de autenticación  
mutua de generación 2 VU-tarjeta durante una sesión, in­
cluida la verificación de certificados (en caso necesario) ya 
sea en el DF tacógrafo, en el DF tacógrafo_G2 o en el MF.  
3.5.1  SELECT  
Este comando cumple con lo dispuesto en la norma ISO/CEI 7816-4 , 
pero tiene un uso restringido en comparación con el comando que  se 
define en dicha norma.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 244  
El comando SELECT se utiliza:  
— para seleccionar un DF de la aplicación (es preciso utilizar la 
selección por nombre),  
— para seleccionar un archivo elemental que corresponda al ID d e 
archivo enviado.  
3.5.1.1 S e l e c c i ó n p o r n o m b r e ( A I D )  
Este comando permite seleccionar un DF de la aplicación en la t arjeta.  
TCS_35 Este comando puede ejecutarse desde cualquier punto de l a 
estructura de archivos (después de la respuesta ATR o en 
cualquier momento).  
TCS_36 Al seleccionar una aplicación se reinicia el entorno de se­
guridad actual. Tras realizar la selección de la aplicación, 
ya no se selecciona ninguna clave pública actual. También 
se pierde la condición de acceso EXT-AUT-G1. Si el co­
mando se ejecutó sin mensajería segura, las claves de la 
sesión de mensajería segura anterior dejan de estar 
disponibles.  
TCS_37  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  
INS 1  «A4h»  
P1 1  «04h»  Selección por nombre (AID)  
P2 1  «0Ch»  No se espera respuesta  
Lc 1  «NNh»  Número de bytes enviados a la tarjeta (longitud del 
AID): 
«06h» para la aplicación de tacógrafo  
#6-#(5+NN)  N N  «XX..XXh»  AID: «FF 54 41 43 48 4F» para la aplicación de tacó­
grafo de generación 1 
AID: «FF 53 4D 52 44 54» para la aplicación de tacó­
grafo de generación 2  
No se precisa respuesta para el comando SELECT (Le 
ausente en T=1, o no se pide respuesta en T=0).  
TCS_38  Mensaje de respuesta (no se pide respuesta)  
Byte  Longitud  Valor  Descripción  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— Si no se encuentra la aplicación que corresponde al 
AID, se contesta con el estado de procesado « 6A82 ». 
— En T=1, si está presente el byte Le, se contesta con el 
estado « 6700 ». 
— En T=0, si se pide una respuesta después del comando 
SELECT, se contesta con el estado « 6900 ». 
▼M1 
— Si se considera que la aplicación seleccionada está da­
ñada (se detecta un error de integridad dentro de los 
atributos del archivo), se contesta con el estado de pro­
cesado « 6400 » o « 6500 ». ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 245  
3.5.1.2 S e l e c c i ó n d e u n a r c h i v o e l e m e n t a  l u t i l i z a n d o s u 
i d e n t i f i c a d o r d e a r c h i v o  
TCS_39  Mensaje de comando  
TCS_40 Una tarjeta de tacógrafo deberá admitir mensajería segur a 
de generación 2 tal como se especifica en la parte B del 
apéndice 11 para esta variante de comando.  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  
INS 1  «A4h»  
P1 1  «02h»  Selección de un EF bajo el DF actual  
P2 1  «0Ch»  No se espera respuesta  
Lc 1  «02h»  Número de bytes enviados a la tarjeta  
#6-#7  2  «XXXXh»  Identificador de archivo  
No se precisa respuesta para el comando SELECT (Le 
ausente en T=1, o no se pide respuesta en T=0).  
TCS_41  Mensaje de respuesta (no se pide respuesta)  
Byte  Longitud  Valor  Descripción  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— Si no se encuentra el archivo que corresponde al iden­
tificador, se contesta con el estado de procesado 
«6A82 ». 
— En T=1, si está presente el byte Le, se contesta con el 
estado « 6700 ». 
— En T=0, si se pide una respuesta después del comando 
SELECT, se contesta con el estado « 6900 ». 
▼M1 
— Si se considera que el archivo seleccionado está dañado 
(se detecta un error de integridad dentro de los atributos 
del archivo), se contesta con el estado de procesado 
«6400 » o « 6500 ». 
▼B 
3.5.2  READ BINARY  
Este comando cumple con lo dispuesto en la norma ISO/CEI 7816-4 , 
pero tiene un uso restringido en comparación con el comando que  se 
define en dicha norma.  
El comando READ BINARY sirve para leer datos de un archivo 
transparente.  
La respuesta de la tarjeta consiste en devolver los datos leído s, op­
cionalmente encapsulados en una estructura de mensajería segura . 
3.5.2.1 C o m a n d o c o n d e s v i a c i ó n e n P 1 - P 2  
Este comando permite al IFD leer datos del EF actualmente selec cio­
nado, sin mensajería segura.  
Nota:  Este comando sin mensajería segura solo puede utilizarse para 
leer un archivo que admita la condición de seguridad ALW para e l 
modo de acceso de lectura.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 246  
TCS_42  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  
INS 1  «B0h»  Read Binary  
P1 1  «XXh»  Desviación en bytes desde el comienzo del archivo: byte 
más significativo  
P2 1  «XXh»  Desviación en bytes desde el comienzo del archivo: byte 
menos significativo  
Le 1  «XXh»  Longitud de los datos esperada. Número de bytes que se 
han de leer.  
Nota:  el bit 8 de P1 debe ponerse a 0.  
TCS_43  Mensaje de respuesta  
Byte  Longitud  Valor  Descripción  
#1-#X  X  «XX..XXh»  Datos leídos  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— Si no se selecciona un EF, se contesta con el estado de 
procesado « 6986 ». 
— Si no se cumplen las condiciones de seguridad del ar­
chivo seleccionado, se interrumpe el comando con 
«6982 ». 
— Si la desviación no es compatible con el tamaño del EF 
(desviación > tamaño del EF), se contesta con el estado 
de procesado « 6B00 ». 
— Si el tamaño de los datos que se han de leer no es 
compatible con el tamaño del EF (desviación + Le > 
tamaño del EF), se contesta con el estado de procesado 
«6700 » o « 6Cxx » donde «xx» indica la longitud 
exacta.  
▼M1 
— Si se detecta un error de integridad dentro de los atri­
butos del archivo, la tarjeta considerará el archivo da­
ñado e irrecuperable, se contesta con el estado de pro­
cesado « 6400 » o « 6500 ». 
▼B 
— Si se detecta un error de integridad dentro de los datos 
almacenados, la tarjeta devuelve los datos solicitados y 
contesta con el estado de procesado « 6281 ». 
3.5.2.1.1 C o m a n d o c o n m e n s a j e r í a s e g u r a (  e j e m p l o s )  
Este comando permite al IFD leer datos del EF actualmente selec cio­
nado, con mensajería segura, a fin de verificar la integridad d e los 
datos recibidos y proteger la confidencialidad de los datos si se aplica 
la condición de seguridad SM-R-ENC-MAC-G1 (generación 1) o 
SM-R-ENC-MAC-G2 (generación 2).  
TCS_44  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «0Ch»  Se pide mensajería segura  
INS 1  «B0h»  Read Binary  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 247  
Byte  Longitud  Valor  Descripción  
P1 1  «XXh»  P1 (desviación en bytes desde el comienzo del archivo): 
byte más significativo  
P2 1  «XXh»  P2 (desviación en bytes desde el comienzo del archivo): 
byte menos significativo  
Lc 1  «XXh»  Longitud de los datos de entrada para mensajería segura  
#6 1  «97h»  T  LE : Etiqueta para especificación de la longitud esperada.  
#7 1  «01h»  L  LE : Longitud de la longitud esperada  
#8 1  «NNh»  Especificación de la longitud esperada (Le original): Nú­
mero de bytes que se han de leer  
#9 1  «8Eh»  T  CC : Etiqueta para suma de control criptográfica  
#10 1  «XXh»  L  CC : Longitud de la siguiente suma de control criptográ­
fica 
«04h» para mensajería segura de generación 1 (véase la 
parte A del apéndice 11) 
«08h», «0Ch» o «10h» dependiendo de la longitud de la 
clave AES para mensajería segura de generación 2 
(véase la parte B del apéndice 11)  
#11-#(10+L)  L  «XX..XXh»  Cryptographic checksum (suma de control criptográfica),  
Le 1  «00h»  Según se especifica en la norma ISO/CEI 7816-4  
TCS_45  Mensaje de respuesta si no se requiere SM-R-ENC- 
MAC-G1 (generación 1) / SM-R-ENC-MAC-G2 (gene ­
ración 2) y si el formato de entrada de mensajería se ­
gura es correcto:  
▼M1 
Byte  Longi­
tud Valor  Descripción  
#1 1  «81h»  T  PV : Etiqueta para datos del valor plano  
#2 L  «NNh» o 
«81 NNh»  L PV : longitud de los datos devueltos (=Le 
original). 
L es 2 bytes si L  PV > 127 bytes  
#(2+L) - #(1+L+NN)  N N  «XX..XXh»  Valor de datos planos  
#(2+L+NN)  1  «99h»  Etiqueta para el estado de procesado (SW1- 
SW2) – opcional para mensajería segura de 
generación 1  
#(3+L+NN)  1  «02h»  Longitud del estado de procesado – opcional 
para mensajería segura de generación 1  
#(4+L+NN) - #(5+L+NN)  2  «XX XXh»  Estado de procesado de la respuesta APDU 
sin proteger – opcional para mensajería se­
gura de generación 1  
#(6+L+NN)  1  «8Eh»  TCC: Etiqueta para suma de control cripto­
gráfica  
#(7+L+NN)  1  «XXh»  LCC: Longitud de la siguiente suma de con­
trol criptográfica 
«04h» para mensajería segura de generación 
1 (véase la parte A del apéndice 11) 
«08h», «0Ch» o «10h» dependiendo de la 
longitud de la clave AES para mensajería 
segura de generación 2 (véase la parte B 
del apéndice 11)  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 248  
Byte  Longi­
tud Valor  Descripción  
#(8+L+NN)-#(7+M+L+NN)  M  «XX..XXh»  Suma de control criptográfica  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
▼B 
TCS_46  Mensaje de respuesta si se requiere SM-R-ENC-MAC- 
G1 (generación 1) / SM-R-ENC-MAC-G2 (generación 2) 
y si el formato de entrada de mensajería segura es 
correcto:  
▼M1 
Byte  Longi­
tud Valor  Descripción  
#1 1  «87h»  T  PI CG  : Etiqueta para datos cifrados (cripto­
grama)  
#2 L  «MMh» o 
«81 MMh»  L PI CG  : Longitud de los datos cifrados que 
se devuelven (distinta de la Le original del 
comando, debido al relleno). 
L es 2 bytes si LPI CG > 127 bytes  
#(2+L)-#(1+L+MM)  M M  «01XX..XXh»  Datos cifrados: Indicador de relleno y crip­
tograma  
#(2+L+MM)  1  «99h»  Etiqueta para el estado de procesado (SW1- 
SW2) – opcional para mensajería segura de 
generación 1  
#(3+L+MM)  1  «02h»  Longitud del estado de procesado – opcional 
para mensajería segura de generación 1  
#(4+L+MM) - #(5+L+MM)  2  «XX XXh»  Estado de procesado de la respuesta APDU 
sin proteger – opcional para mensajería se­
gura de generación 1  
#(6+L+MM)  1  «8Eh»  TCC: Etiqueta para suma de control cripto­
gráfica  
#(7+L+MM)  1  «XXh»  LCC: Longitud de la siguiente suma de con­
trol criptográfica 
«04h» para mensajería segura de generación 
1 (véase la parte A del apéndice 11) 
«08h», «0Ch» o «10h» dependiendo de la 
longitud de la clave AES para mensajería 
segura de generación 2 (véase la parte B 
del apéndice 11)  
#(8+L+MM)- 
#(7+N+L+MM)  N «XX..XXh»  Suma de control criptográfica  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
▼B 
El comando READ BINARY puede devolver estados de 
procesado normales enumerados en TCS_43 bajo la eti­
queta «99h» tal como se describe en TCS_59 utilizando 
la estructura de respuesta de mensajería segura.  
Asimismo, es posible que se produzcan algunos errores 
específicamente relacionados con la mensajería segura. En 
tal caso, el estado de procesado se devuelve tal cual, sin la 
intervención de una estructura de mensajería segura.  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 249  
TCS_47  Mensaje de respuesta si el formato de entrada de men ­
sajería segura es incorrecto  
Byte  Longitud  Valor  Descripción  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si no hay una clave disponible para la sesión actual, se 
devuelve el estado de procesado « 6A88 ». Esto ocurre si 
la clave de la sesión no se ha generado todavía o si ha 
expirado la validez de dicha clave (en tal caso, el IFD 
debe ejecutar de nuevo un proceso de autentificación 
mutua para establecer una nueva clave de sesión).  
— Si en el formato de mensajería segura faltan algunos de 
los objetos de datos que se esperaban (anteriormente 
especificados), se devuelve el estado de procesado 
«6987 »: este error se produce si falta una etiqueta es­
perada o si el cuerpo del comando no está bien 
construido.  
— Si algunos de los objetos de datos son incorrectos, se 
contesta con el estado de procesado « 6988 »: este error 
se produce si están presentes todas las etiquetas nece­
sarias pero algunas longitudes no coinciden con las 
esperadas.  
— Si falla la verificación de la suma de control criptográ­
fica, se contesta con el estado de procesado « 6688 ». 
3.5.2.2 C o m a n d o c o n i d e n t i f i c a d o r E F ( a r  c h i v o e l e m e n ­
t a l ) c o r t o  
Esta variante de comando permite al IFD seleccionar un EF por m edio 
de un identificador EF corto y leer los datos de este EF.  
TCS_48 Una tarjeta de tacógrafo deberá admitir esta variante de  
comando para todos los archivos elementales que lleven 
especificado un identificador EF corto. Estos identificado­
res EF cortos se especifican en el apartado 4.  
TCS_49  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  
INS 1  «B0h»  Read Binary  
P1 1  «XXh»  El bit 8 se pone en 1 
Los bits 7 y 6 se ponen en 00 
Los bits 5 a 1 codifican el identificador EF corto del EF 
correspondiente  
P2 1  «XXh»  Codifica una desviación desde 0 hasta 255 bytes en el 
EF referenciado por P1  
Le 1  «XXh»  Longitud de los datos esperada. Número de bytes que se 
han de leer.  
Nota:  Los identificadores EF cortos utilizados para la apli­
cación de tacógrafo de generación 2 se especifican en el 
apartado 4.  
Si P1 codifica un identificador EF corte y el comando es 
correcto, el EF identificado pasa a ser el EF seleccionado 
actualmente (EF actual).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 250  
TCS_50  Mensaje de respuesta  
Byte  Longitud  Valor  Descripción  
#1-#L  L  «XX..XXh»  Datos leídos  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— Si no se encuentra el archivo que corresponde al iden­
tificador EF corto, se contesta con el estado de proce­
sado « 6A82 ». 
— Si no se satisfacen las condiciones de seguridad del 
archivo seleccionado, se interrumpe el comando con 
«6982 ». 
— Si la desviación no es compatible con el tamaño del EF 
(desviación > tamaño del EF), se contesta con el estado 
de procesado « 6B00 ». 
— Si el tamaño de los datos que se han de leer no es 
compatible con el tamaño del EF (desviación + Le > 
tamaño del EF), se contesta con el estado de procesado 
«6700 » o « 6Cxx » donde «xx» indica la longitud 
exacta.  
▼M1 
— Si se detecta un error de integridad dentro de los atri­
butos del archivo, la tarjeta considerará el archivo da­
ñado e irrecuperable, se contesta con el estado de pro­
cesado « 6400 » o « 6500 ». 
▼B 
— Si se detecta un error de integridad dentro de los datos 
almacenados, la tarjeta devuelve los datos solicitados y 
contesta con el estado de procesado « 6281 ». 
3.5.2.3 C o m a n d o c o n b y t e d e i n s t r u c c i ó n i  m p a r  
Esta variante de comando permite al IFD leer datos de un EF de 
32 768 bytes o más.  
TCS_51 Una tarjeta de tacógrafo que admita EF de 32 768 bytes o  
más deberá admitir esta variante de comando para estos EF. 
Una tarjeta de tacógrafo puede o no admitir esta variante de 
comando para otros EF a excepción del EF Sensor_Ins­
tallation_Data; véase TCS_156 y TCS_160.  
TCS_52  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  
INS 1  «B1h»  Read Binary  
P1 1  «00h»  EF actual  
P2 1  «00h»  
Lc 1  «NNh»  Lc longitud del objeto de datos de desviación.  
#6-#(5+NN)  N N  «XX..XXh»  Objeto de datos de desviación: 
Etiqueta «54h» 
Longitud «01h» o «02h» 
Valor desviación  
▼M1 
Le 1  «XXh»  Según se especifica en la norma ISO/CEI 7816-4  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 251  
El IFD deberá codificar la longitud del objeto de datos de 
desviación con un número mínimo posible de octetos, es 
decir, utilizando el byte de longitud «01h» el IFD deberá 
codificar una desviación comprendida entre 0 y 255 y, 
mediante el byte de longitud «02h», una desviación com­
prendida entre «256» y «65 535» bytes.  
▼M1 
En T=0, la tarjeta asume el valor Le = «00h» si no se 
aplica mensajería segura.  
En T=1, se contesta con el estado de procesado «6700» si 
Le =«01h».  
▼B 
TCS_53  Mensaje de respuesta  
Byte  Longitud  Valor  Descripción  
#1-#L  L  «XX..XXh»  Datos leídos encapsulados en un objeto de datos discre­
cional con etiqueta «53h».  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— Si no se selecciona un EF, se contesta con el estado de 
procesado « 6986 ». 
— Si no se satisfacen las condiciones de seguridad del 
archivo seleccionado, se interrumpe el comando con 
«6982 ». 
— Si la desviación no es compatible con el tamaño del EF 
(desviación > tamaño del EF), se contesta con el estado 
de procesado « 6B00 ». 
— Si el tamaño de los datos que se han de leer no es 
compatible con el tamaño del EF (desviación + Le > 
tamaño del EF), se contesta con el estado de procesado 
«6700 » o « 6Cxx » donde «xx» indica la longitud 
exacta.  
▼M1 
— Si se detecta un error de integridad dentro de los atri­
butos del archivo, la tarjeta considerará el archivo da­
ñado e irrecuperable, se contesta con el estado de pro­
cesado « 6400 » o « 6500 ». 
▼B 
— Si se detecta un error de integridad dentro de los datos 
almacenados, la tarjeta devuelve los datos solicitados y 
contesta con el estado de procesado « 6281 ». 
3.5.2.3.1 C o m a n d o c o n m e n s a j e r í a s e g u r a (  e j e m p l o )  
El siguiente ejemplo ilustra el uso de la mensajería segura si se aplica 
la condición de seguridad SM-MAC-G2.  
TCS_54 Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «0Ch»  Se pide mensajería segura  
INS 1  «B1h»  Read Binary  
P1 1  «00h»  EF actual  
P2 1  «00h»  
Lc 1  «XXh»  Longitud del campo de datos seguro  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 252  
Byte  Longitud  Valor  Descripción  
#6 1  «B3h»  Etiqueta para datos del valor plano codificados en 
BER-TLV  
#7 1  «NNh»  L  PV : longitud de los datos transmitidos  
#(8)-#(7+NN)  N N  «XX..XXh»  Datos planos codificados en BER-TLV, es decir, el ob­
jeto de datos de desviación con etiqueta «54»  
#(8+NN)  1  «97h»  T  LE : Etiqueta para especificación de la longitud esperada.  
#(9+NN)  1  «01h»  L  LE : Longitud de la longitud esperada  
#(10+NN)  1  «XXh»  Especificación de la longitud esperada (Le original): Nú­
mero de bytes que se han de leer  
#(11+NN)  1  «8Eh»  T  CC : Etiqueta para suma de control criptográfica  
#(12+NN)  1  «XXh»  L  CC : Longitud de la siguiente suma de control criptográ­
fica 
«08h», «0Ch» o «10h» dependiendo de la longitud de la 
clave AES para mensajería segura de generación 2 
(véase la parte B del apéndice 11)  
#(13+NN)- 
#(12+M+NN)  M «XX..XXh»  Suma de control criptográfica  
Le 1  «00h»  Según se especifica en la norma ISO/CEI 7816-4  
TCS_55 Mensaje de respuesta si el comando es correcto  
Byte  Longitud  Valor  Descripción  
#1 1  «B3h»  Datos planos codificados en BER-TLV  
#2 L  «NNh» o 
«81 NNh»  L PV : longitud de los datos devueltos (=Le original). 
L es 2 bytes si L  PV > 127 bytes  
#(2+L)- 
#(1+L+NN)  NN «XX..XXh»  Valor de datos planos codificados en BER-TLV, es de­
cir, los datos leídos encapsulados en un objeto de datos 
discrecional con etiqueta «53h».  
#(2+L+NN)  1  «99h»  Estado de procesado de la respuesta APDU sin proteger  
#(3+L+NN)  1  «02h»  Longitud del estado de procesado  
#(4+L+NN) — 
#(5+L+NN)  2 «XX XXh»  Estado de procesado de la respuesta APDU sin proteger  
#(6+L+NN)  1  «8Eh»  T  CC : Etiqueta para suma de control criptográfica  
#(7+L+NN)  1  «XXh»  L  CC : Longitud de la siguiente suma de control criptográ­
fica 
«08h», «0Ch» o «10h» dependiendo de la longitud de la 
clave AES para mensajería segura de generación 2 
(véase la parte B del apéndice 11)  
#(8+L+NN)- 
#(7+M+L+N­
N) M «XX..XXh»  Suma de control criptográfica  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
3.5.3  UPDATE BINARY  
Este comando cumple con lo dispuesto en la norma ISO/CEI 7816-4 , 
pero tiene un uso restringido en comparación con el comando que  se 
define en dicha norma.  
El mensaje de comando UPDATE BINARY inicia la actualización 
(borrar + escribir) de los bits ya presentes en un EF binario, para 
sustituirlos por los bits dados en el comando APDU.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 253  
3.5.3.1 C o m a n d o c o n d e s v i a c i ó n e n P 1 - P 2  
Este comando permite al IFD escribir datos en el EF actualmente  
seleccionado, sin que la tarjeta verifique la integridad de los  datos 
recibidos.  
Nota:  Este comando sin mensajería segura solo puede utilizarse para 
leer un archivo que admita la condición de seguridad ALW para e l 
modo de acceso de actualización.  
TCS_56  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  
INS 1  «D6h»  Update Binary  
P1 1  «XXh»  Desviación en bytes desde el comienzo del archivo: byte 
más significativo  
P2 1  «XXh»  Desviación en bytes desde el comienzo del archivo: byte 
menos significativo  
Lc 1  «NNh»  Lc Longitud de los datos que se han de actualizar. Nú­
mero de bytes que se han de escribir.  
#6-#(5+NN)  N N  «XX..XXh»  Datos que se han de escribir  
Nota:  el bit 8 de P1 debe ponerse a 0.  
TCS_57  Mensaje de respuesta  
Byte  Longitud  Valor  Descripción  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— Si no se selecciona un EF, se contesta con el estado de 
procesado « 6986 ». 
— Si no se satisfacen las condiciones de seguridad del 
archivo seleccionado, se interrumpe el comando con 
«6982 ». 
— Si la desviación no es compatible con el tamaño del EF 
(desviación > tamaño del EF), se contesta con el estado 
de procesado « 6B00 ». 
— Si el tamaño de los datos que se han de escribir no es 
compatible con el tamaño del EF (desviación + Lc > 
tamaño del EF), se contesta con el estado de procesado 
«6700 ». 
— Si se detecta un error de integridad dentro de los atri­
butos del archivo, la tarjeta considerará el archivo da­
ñado e irrecuperable, se contesta con el estado de pro­
cesado « 6400 » o « 6500 ». 
— Si falla la escritura, se contesta con el estado de pro­
cesado « 6581 ». 
3.5.3.1.1 C o m a n d o c o n m e n s a j e r í a s e g u r a (  e j e m p l o s )  
Este comando permite al IFD escribir datos en el EF actualmente  
seleccionado, de modo que la tarjeta verifica la integridad de los datos 
recibidos. Dado que no se precisa confidencialidad, los datos n o están 
cifrados.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 254  
TCS_58  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «0Ch»  Se pide mensajería segura  
INS 1  «D6h»  Update Binary  
P1 1  «XXh»  Desviación en bytes desde el comienzo del archivo: 
byte más significativo  
P2 1  «XXh»  Desviación en bytes desde el comienzo del archivo: 
byte menos significativo  
Lc 1  «XXh»  Longitud del campo de datos seguro  
#6 1  «81h»  T  PV : Etiqueta para datos del valor plano  
#7 L  «NNh» o 
«81 NNh»  L PV : longitud de los datos transmitidos. 
L es 2 bytes si L  PV > 127 bytes.  
#(7+L)- 
#(6+L+NN)  NN «XX..XXh»  Valor de datos planos (datos que se han de escribir)  
#(7+L+NN)  1  «8Eh»  T  CC : Etiqueta para suma de control criptográfica  
#(8+L+NN)  1  «XXh»  L  CC : Longitud de la siguiente suma de control criptográ­
fica «04h» para mensajería segura de generación 1 
(véase la parte A del apéndice 11) 
«08h», «0Ch» o «10h» dependiendo de la longitud de la 
clave AES para mensajería segura de generación 2 
(véase la parte B del apéndice 11)  
#(9+L+NN)- 
#(8+M+L+NN)  M «XX..XXh»  Suma de control criptográfica  
Le 1  «00h»  Según se especifica en la norma ISO/CEI 7816-4  
TCS_59  Mensaje de respuesta si el formato de entrada de men ­
sajería segura es correcto  
Byte  Longitud  Valor  Descripción  
#1 1  «99h»  T  SW : Etiqueta para palabras de estado (con la protección 
de CC)  
#2 1  «02h»  L  SW : longitud de las palabras de estado devueltas  
#3-#4  2  «XXXXh»  Estado de procesado de la respuesta APDU sin proteger  
#5 1  «8Eh»  T  CC : Etiqueta para suma de control criptográfica  
#6 1  «XXh»  L  CC : Longitud de la siguiente suma de control criptográ­
fica 
«04h» para mensajería segura de generación 1 (véase la 
parte A del apéndice 11) 
«08h», «0Ch» o «10h» dependiendo de la longitud de la 
clave AES para mensajería segura de generación 2 
(véase la parte B del apéndice 11)  
#7-#(6+L)  L  «XX..XXh»  Suma de control criptográfica  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
Los estados de procesado «normales», descritos para el 
comando UPDATE BINARY sin mensajería segura (véase 
§3.5.3.1), se pueden devolver utilizando las estructuras de 
mensaje de respuesta descritas anteriormente.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 255  
Asimismo, es posible que se produzcan algunos errores 
específicamente relacionados con la mensajería segura. En 
tal caso, el estado de procesado se devuelve tal cual, sin la 
intervención de una estructura de mensajería segura.  
TCS_60  Mensaje de respuesta si se produce un error de mensa ­
jería segura  
Byte  Longitud  Valor  Descripción  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si no hay una clave disponible para la sesión actual, se 
devuelve el estado de procesado « 6A88 ». 
— Si en el formato de mensajería segura faltan algunos de 
los objetos de datos que se esperaban (anteriormente 
especificados), se devuelve el estado de procesado 
«6987 »: este error se produce si falta una etiqueta es­
perada o si el cuerpo del comando no está bien 
construido.  
— Si algunos de los objetos de datos son incorrectos, se 
contesta con el estado de procesado «6988»: este error 
se produce si están presentes todas las etiquetas nece­
sarias pero algunas longitudes no coinciden con las 
esperadas.  
— Si falla la verificación de la suma de control criptográ­
fica, se contesta con el estado de procesado « 6688 ». 
3.5.3.2 C o m a n d o c o n i d e n t i f i c a d o r E F c o r  t o 
Esta variante de comando permite al IFD seleccionar un EF por m edio 
de un identificador EF corto y escribir los datos de este EF.  
TCS_61 Una tarjeta de tacógrafo deberá admitir esta variante de  
comando para todos los archivos elementales que lleven 
especificado un identificador EF corto. Estos identificado­
res EF cortos se especifican en el apartado 4.  
TCS_62  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  
INS 1  «D6h»  Update Binary  
P1 1  «XXh»  El bit 8 se pone en 1 
Los bits 7 y 6 se ponen en 00 
Los bits 5 a 1 codifican el identificador EF corto del EF 
correspondiente  
P2 1  «XXh»  Codifica una desviación desde 0 hasta 255 bytes en el 
EF referenciado por P1  
Lc 1  «NNh»  Lc Longitud de los datos que se han de actualizar. Nú­
mero de bytes que se han de escribir.  
#6-#(5+NN)  N N  «XX..XXh»  Datos que se han de escribir  
TCS_63  Mensaje de respuesta  
Byte  Longitud  Valor  Descripción  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
Nota:  Los identificadores EF cortos utilizados para la apli­
cación de tacógrafo de generación 2 se especifican en el 
apartado 4.  
Si P1 codifica un identificador EF corte y el comando es 
correcto, el EF identificado pasa a ser el EF seleccionado 
actualmente (EF actual).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 256  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— Si no se encuentra el archivo que corresponde al iden­
tificador EF corto, se contesta con el estado de proce­
sado « 6A82 ». 
— Si no se satisfacen las condiciones de seguridad del 
archivo seleccionado, se interrumpe el comando con 
«6982 ». 
— Si la desviación no es compatible con el tamaño del EF 
(desviación > tamaño del EF), se contesta con el estado 
de procesado « 6B00 ». 
— Si el tamaño de los datos que se han de escribir no es 
compatible con el tamaño del EF (desviación + Lc > 
tamaño del EF), se contesta con el estado de procesado 
«6700 ». 
▼M1 
— Si se detecta un error de integridad dentro de los atri­
butos del archivo, la tarjeta considerará el archivo da­
ñado e irrecuperable, se contesta con el estado de pro­
cesado « 6400 » o « 6500 ». 
▼B 
— Si falla la escritura, se contesta con el estado de pro­
cesado « 6581 ». 
3.5.3.3 C o m a n d o c o n b y t e d e i n s t r u c c i ó n i  m p a r  
Esta variante de comando permite al IFD escribir datos de un EF  de 
32 768 bytes o más.  
TCS_64 Una tarjeta de tacógrafo que admita EF de 32 768 bytes o  
más deberá admitir esta variante de comando para estos EF. 
Una tarjeta de tacógrafo puede o no admitir esta variante de 
comando para otros EF.  
TCS_65  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  
INS 1  «D7h»  Update Binary  
P1 1  «00h»  EF actual  
P2 1  «00h»  
Lc 1  «NNh»  Lc Longitud de datos en el campo de datos del comando  
#6-#(5+NN)  N N  «XX..XXh»  Objeto de datos de desviación con etiqueta «54h» || Ob­
jeto de datos discrecional con etiqueta «53h» que encap­
sula los datos que han de escribirse  
El IFD deberá codificar la longitud del objeto de datos de 
desviación y el objeto de datos discrecional con un número 
mínimo posible de octetos, es decir, utilizando el byte de 
longitud «01h» el IFD deberá codificar una desviación/lon­
gitud comprendida entre 0 y 255 y, mediante el byte de 
longitud «02h», una desviación/longitud comprendida entre 
«256» y «65 535» bytes.  
TCS_66  Mensaje de respuesta  
Byte  Longitud  Valor  Descripción  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 257  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— Si no se selecciona un EF, se contesta con el estado de 
procesado « 6986 ». 
— Si no se satisfacen las condiciones de seguridad del 
archivo seleccionado, se interrumpe el comando con 
«6982 ». 
— Si la desviación no es compatible con el tamaño del EF 
(desviación > tamaño del EF), se contesta con el estado 
de procesado « 6B00 ». 
— Si el tamaño de los datos que se han de escribir no es 
compatible con el tamaño del EF (desviación + Lc > 
tamaño del EF), se contesta con el estado de procesado 
«6700 ». 
— Si se detecta un error de integridad dentro de los atri­
butos del archivo, la tarjeta considerará el archivo da­
ñado e irrecuperable, se contesta con el estado de pro­
cesado « 6400 » o « 6500 ». 
— Si falla la escritura, se contesta con el estado de pro­
cesado « 6581 ». 
3.5.3.3.1 C o m a n d o c o n m e n s a j e r í a s e g u r a (  e j e m p l o )  
El siguiente ejemplo ilustra el uso de la mensajería segura si se aplica 
la condición de seguridad SM-MAC-G2.  
TCS_67 Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «0Ch»  Se pide mensajería segura  
INS 1  «D7h»  Update Binary  
P1 1  «00h»  EF actual  
P2 1  «00h»  
Lc 1  «XXh»  Longitud del campo de datos seguro  
#6 1  «B3h»  Etiqueta para datos del valor plano codificados en 
BER-TLV  
#7 L  «NNh» o 
«81 NNh»  L PV : longitud de los datos transmitidos. 
L es 2 bytes si L  PV > 127 bytes.  
#(7+L)- 
#(6+L+NN)  NN «XX..XXh»  Datos planos codificados en BER-TLV, es decir, el ob­
jeto de datos de desviación con etiqueta «54h» || Objeto 
de datos discrecional con etiqueta «53h» que encapsula 
los datos que han de escribirse  
#(7+L+NN)  1  «8Eh»  T  CC : Etiqueta para suma de control criptográfica  
#(8+L+NN)  1  «XXh»  L  CC : Longitud de la siguiente suma de control criptográ­
fica 
«08h», «0Ch» o «10h» dependiendo de la longitud de la 
clave AES para mensajería segura de generación 2 
(véase la parte B del apéndice 11)  
#(9+L+NN)- 
#(8+M+L+N­
N) M «XX..XXh»  Suma de control criptográfica  
Le 1  «00h»  Según se especifica en la norma ISO/CEI 7816-4  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 258  
TCS_68 Mensaje de respuesta si el comando es correcto  
Byte  Longitud  Valor  Descripción  
#1 1  «99h»  T  SW : Etiqueta para palabras de estado (con la protección 
de CC)  
#2 1  «02h»  L  SW : longitud de las palabras de estado devueltas  
#3-#4  2  «XXXXh»  Estado de procesado de la respuesta APDU sin proteger  
#5 1  «8Eh»  T  CC : Etiqueta para suma de control criptográfica  
#6 1  «XXh»  L  CC : Longitud de la siguiente suma de control criptográfica 
«08h», «0Ch» o «10h» dependiendo de la longitud de la 
clave AES para mensajería segura de generación 2 (véase la 
parte B del apéndice 11)  
#7-#(6+L)  L  «XX..XXh»  Suma de control criptográfica  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
3.5.4  GET CHALLENGE  
Este comando cumple con lo dispuesto en la norma ISO/CEI 7816-4 , 
pero tiene un uso restringido en comparación con el comando que  se 
define en dicha norma.  
El comando GET CHALLENGE pide a la tarjeta que envíe una 
interrogación para usarla en un procedimiento relacionado con l a 
seguridad que incluya el envío de un criptograma o de unos dato s 
cifrados a la tarjeta.  
TCS_69 La interrogación que envía la tarjeta tan solo es válida  para 
el siguiente comando que utilice una interrogación y se 
envíe a la tarjeta.  
TCS_70  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  
INS 1  «84h»  INS  
P1 1  «00h»  P 1  
P2 1  «00h»  P 2  
Le 1  «08h»  Le (Longitud de la interrogación esperada)  
TCS_71  Mensaje de respuesta  
Byte  Longitud  Valor  Descripción  
#1-#8  8  «XX..XXh»  Interrogación  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— Si Le es distinto de «08h», el estado de procesado es 
«6700 ». 
— Si los parámetros P1-P2 son incorrectos, el estado de 
procesado es « 6A86 ». ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 259  
3.5.5  VERIFY  
Este comando cumple con lo dispuesto en la norma ISO/CEI 7816-4 , 
pero tiene un uso restringido en comparación con el comando que  se 
define en dicha norma.  
Solo la tarjeta de taller necesita admitir este comando.  
Otros tipos de tarjetas de tacógrafo pueden o no incorporar est e co­
mando, pero para estas tarjetas no se personaliza ninguna infor mación 
CHV de referencia. Por tanto, estas tarjetas no pueden realizar  este 
comando correctamente. En cuanto al resto de tipos de tarjetas de 
tacógrafo que no sean tarjetas de taller, el comportamiento, es  decir, 
el código de error devuelto, está fuera del alcance de esta esp ecifica­
ción si se envía este comando.  
El comando VERIFY inicia una comparación en la tarjeta, confron ­
tando los datos CHV (PIN) enviados desde el comando con la info r­
mación CHV de referencia almacenada en la tarjeta.  
▼M1 
TCS_72 El IFD debe añadir bytes «FFh» para rellenar por la dere ­
cha el PIN que introduzca el usuario y debe codificarse en 
ASCII, hasta llegar a una longitud de 8 bytes; véase tam­
bién el tipo de datos WorkshopCardPIN en el apéndice 1.  
▼B 
TCS_73 Las aplicaciones de tacógrafo de generación 1 y 2 deberá n 
utilizar la misma información CHV de referencia.  
TCS_74 La tarjeta de tacógrafo deberá comprobar si el comando 
está codificado correctamente. Si el comando no está codi­
ficado correctamente, la tarjeta no comparará los valores 
CHV, no disminuirá el contador de intentos CHV restantes 
y no reiniciará el estado de seguridad «PIN_Verified», pero 
interrumpirá el comando. Un comando está codificado co­
rrectamente si los bytes CLA, INS, P1, P2, Lc tienen los 
valores especificados, Le está ausente y el campo de datos 
del comando tiene la longitud correcta.  
TCS_75 Si el comando es correcto, el contador de intentos CHV 
restantes se reinicializa. El valor inicial del contador de 
intentos CHV restantes es 5. Si el comando es correcto, 
la tarjeta establecerá el estado de seguridad interna 
«PIN_Verified». La tarjeta restablecerá este estado de se­
guridad si se restablece la tarjeta o si el código CHV trans­
mitido en el comando no coincide con la información CHV 
de referencia almacenada.  
Nota:  utilizar la misma información CHV de referencia y 
un estado de seguridad global evita que un empleado del 
taller tenga que volver a introducir el PIN tras seleccionar 
otro DF de la aplicación de tacógrafo.  
TCS_76 En la tarjeta queda registrada cada comparación incorrec ta, 
es decir, el contador de intentos CHV restantes disminuye 
en uno, a fin de limitar el número de intentos que quedan 
para utilizar la información CHV de referencia.  
TCS_77  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  
INS 1  «20h»  INS  
P1 1  «00h»  P 1  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 260  
Byte  Longitud  Valor  Descripción  
P2 1  «00h»  P2 (la CHV verificada se conoce implícitamente)  
Lc 1  «08h»  Longitud del código CHV transmitido  
#6-#13  8  «XX..XXh»  CHV  
TCS_78  Mensaje de respuesta  
Byte  Longitud  Valor  Descripción  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— Si no se encuentra la referencia CHV, se contesta con el 
estado de procesado « 6A88 ». 
— Si la información CHV está bloqueada (el contador de 
intentos restantes de la CHV es cero), se contesta con el 
estado de procesado « 6983 ». Una vez en ese estado, ya 
no se puede volver a presentar la información CHV.  
— Si la comparación no tiene éxito, se resta una unidad a 
la lectura del contador de intentos restantes y se de­
vuelve el estado « 63CX » (X > 0 y X es igual al con­
tador de intentos CHV restantes.  
— Si se considera que la información CHV de referencia 
está dañada, se contesta con el estado de procesado 
«6400 » o « 6581 ». 
— Si Lc es distinto de «08h», el estado de procesado es 
«6700 ». 
3.5.6  GET RESPONSE  
Este comando cumple con lo dispuesto en la norma ISO/CEI 7816-4 . 
Este comando (exclusivamente necesario y disponible en el proto colo 
T=0) sirve para transmitir datos preparados de la tarjeta al di spositivo 
de interfaz (cuando el comando incluye las longitudes Lc y Le).  
El comando GET RESPONSE tiene que enviarse inmediatamente 
después del comando que prepara los datos. De lo contrario, los  datos 
se pierden. Una vez ejecutado el comando GET RESPONSE (salvo si  
se produce el error « 61xx » o « 6Cxx », véase más abajo), los datos 
preparados previamente dejan de estar disponibles.  
TCS_79  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  
INS 1  «C0h»  
P1 1  «00h»  
P2 1  «00h»  
Le 1  «XXh»  Número de bytes esperados  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 261  
TCS_80  Mensaje de respuesta  
Byte  Longitud  Valor  Descripción  
#1-#X  X  «XX..XXh»  Datos  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— Si la tarjeta no ha preparado ningún dato, se contesta 
con el estado de procesado « 6900 » o « 6F00 ». 
— Si la longitud Le sobrepasa el número de bytes dispo­
nibles o es igual a cero, se contesta con el estado de 
procesado « 6Cxx », donde xx es el número exacto de 
bytes disponibles. En ese caso, los datos preparados 
siguen estando disponibles para un comando GET RES­
PONSE posterior.  
— Si la longitud Le es distinta de cero y menor que el 
número de bytes disponibles, la tarjeta normalmente 
envía los datos necesarios y se contesta con el estado 
de procesado « 61xx », donde «xx» indica el número de 
bytes extra todavía disponibles para un comando GET 
RESPONSE posterior.  
— Si el comando no se admite (protocolo T=1), la tarjeta 
contesta con el estado « 6D00 ». 
3.5.7  PSO: VERIFY CERTIFICATE  
Este comando cumple con lo dispuesto en la norma ISO/CEI 7816-8 , 
pero tiene un uso restringido en comparación con el comando que  se 
define en dicha norma.  
El comando VERIFY CERTIFICATE lo utiliza la tarjeta para obtene r 
una clave pública del exterior y para comprobar su validez.  
3.5.7.1 C o m a n d o d e g e n e r a c i ó n 1 — P a r d e r e  s p u e s t a s  
TCS_81 Esta variante de comando es compatible únicamente con 
una aplicación de tacógrafo de generación 1.  
TCS_82 Cuando un comando VERIFY CERTIFICATE se ejecuta 
correctamente, la clave pública queda almacenada para su 
uso posterior en el entorno de seguridad. Esta clave debe 
crearla de forma explícita el comando MSE utilizando su 
identificador de clave (véase § 3.5.11) para uso en coman­
dos relacionados con la seguridad (INTERNAL AUTHEN­
TICATE, EXTERNAL AUTHENTICATE o VERIFY 
CERTIFICATE).  
TCS_83 En cualquier caso, el comando VERIFY CERTIFICATE 
utiliza la clave pública previamente seleccionada por el 
comando MSE para abrir el certificado. Esta clave pública 
debe ser la de un Estado miembro o de Europa.  
TCS_84  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  
INS 1  «2Ah»  Realizar operación de seguridad  
P1 1  «00h»  P 1  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 262  
Byte  Longitud  Valor  Descripción  
P2 1  «AEh»  P2: datos sin codificación BER-TLV (concatenación de 
elementos de datos)  
Lc 1  «C2h»  Lc: Longitud del certificado, 206 Bytes  
#6-#199  194  «XX..XXh»  Certificado: concatenación de elementos de datos (como 
se describe en el apéndice 11)  
TCS_85  Mensaje de respuesta  
Byte  Longitud  Valor  Descripción  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— Si la verificación del certificado falla, se contesta con el 
estado de procesado « 6688 ». El proceso de verificación 
y apertura del certificado se describe en el apéndice 11 
para G1 y G2.  
— Si no hay una clave pública presente en el entorno de 
seguridad, se devuelve « 6A88 ». 
— Si se considera que la clave pública seleccionada (uti­
lizada para desenvolver el certificado) está dañada, se 
contesta con el estado de procesado « 6400 » o « 6581 ». 
— Generación 1 únicamente: Si la clave pública seleccio­
nada (utilizada para desenvolver el certificado) tiene un 
CHA.LSB (
  )  
diferente de «00» (es decir, no es el de un Estado 
miembro o el de Europa), se contesta con el estado 
de procesado « 6985 ». 
3.5.7.2 C o m a n d o d e g e n e r a c i ó n 2 — P a r d e r e  s p u e s t a s  
Dependiendo del tamaño de la curva, los certificados ECC pueden  ser 
tan largos que no es posible transmitirlos en un solo APDU. En este 
caso, debe aplicarse el encadenamiento de comandos según ISO/CE I 
7816-4 y el certificado debe transmitirse en dos PSO consecutiv os: 
APDU de Verify Certificate.  
La estructura del certificado y los parámetros de dominio se de finen 
en el apéndice 11.  
▼M3 
TCS_86 El comando puede ejecutarse en el archivo principal, el 
archivo dedicado Tachograph y el archivo dedicado Tacho­
graph_G2; véase también TCS_34.  
▼B 
TCS_87  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «X0h»  Byte CLA que indica el encadenamiento de comandos: 
«00h» el único comando o el último de la cadena 
«10h» no es el último comando de una cadena  
INS 1  «2Ah»  Realizar operación de seguridad  
P1 1  «00h»  
P2 1  «BEh»  Verificar certificado autodescriptivo  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 263  
Byte  Longitud  Valor  Descripción  
Lc 1  «XXh»  Longitud del campo de datos del comando, véase 
TCS_88TCS_88 y TCS_89TCS_89.  
#6-#5+L  L  «XX..XXh»  Datos codificados en DER-TLV: Objeto de datos del 
cuerpo del certificado ECC como primer objeto de datos 
concatenado con el objeto de datos de la firma del cer­
tificado ECC como segundo objeto de datos o para de 
esta concatenación. La etiqueta «7F21» y la correspon­
diente longitud no deberán transmitirse. 
El orden de estos objetos de datos es fijo.  
▼M3 
TCS_88 Para APDU de longitud corta, se aplican las siguientes 
disposiciones: el IFD deberá utilizar el número mínimo 
de APDU necesario para transmitir los datos útiles del 
comando y transmitir el máximo número de bytes en el 
primer comando APDU. Sin embargo, la tarjeta deberá 
admitir cualquier valor de «Lc» hasta 255 bytes.  
TCS_89 Para APDU de longitud ampliada, se aplican las siguiente s 
disposiciones: si el certificado no encaja en un solo APDU, 
la tarjeta deberá admitir el encadenamiento de comandos. 
El IFD deberá utilizar el número mínimo de APDU nece­
sario para transmitir los datos útiles del comando y trans­
mitir el máximo número de bytes en el primer comando 
APDU. Si es necesario el encadenamiento, la tarjeta debe 
admitir cualquier valor de «Lc» hasta la longitud ampliada 
máxima indicada.  
Nota: Según el apéndice 11, la tarjeta almacena el certifi­
cado o el contenido relevante del certificado y actualiza su 
currentAuthenticatedTime.  
La estructura del mensaje de respuesta y las palabras de 
estado son las que se definen en TCS_85.  
▼B 
TCS_90 Además de los códigos de error enumerados en 
TCS_85TCS_85, la tarjeta puede devolver los siguientes 
códigos de error:  
— Si la clave pública seleccionada (utilizada para desen­
volver el certificado) tiene un CHA.LSB (Certificate­
HolderAuthorisation.equipmentType) que no es apro­
piado para la verificación de certificados según el apén­
dice 11, se contesta con el estado de procesado « 6985 ». 
— Si el currentAuthenticatedTime de la tarjeta es posterior 
a la fecha de caducidad del certificado, se contesta con 
el estado de procesado « 6985 ». 
— Si se espera el último comando de la cadena, la tarjeta 
contesta con el estado « 6883 ». 
— Si se envían parámetros incorrectos en el campo de 
datos del comando, la tarjeta contesta con el estado 
«6A80 » (utilizado también en caso de que los objetos 
de datos no se envíen en el orden especificado).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 264  
3.5.8  INTERNAL AUTHENTICATE  
Este comando cumple con lo dispuesto en la norma ISO/CEI 7816-4 . 
TCS_91 Todas las tarjetas de tacógrafo deberán admitir este co­
mando en el DF tacógrafo de generación 1. El comando 
puede o no estar accesible en el MF y/o el DF tacó­
grafo_G2. Si es así, el comando deberá terminar con un 
código de error apropiado ya que la clave privada de la 
tarjeta (Card.SK) para el protocolo de autenticación de ge­
neración 1 solo es accesible en el DF_tacógrafo de gene­
ración 1.  
Por medio del comando INTERNAL AUTHENTICATE, el 
IFD puede autentificar la tarjeta. El proceso de autentica­
ción se describe en el apéndice 11. Incluye las declaracio­
nes siguientes:  
TCS_92 El comando INTERNAL AUTHENTICATE utiliza la clave 
privada de la tarjeta (seleccionada implícitamente) para fir­
mar datos de autentificación, incluidos K1 (el primer ele­
mento para acordar la clave de la sesión) y RND1, y utiliza 
la clave pública actualmente seleccionada (a través del úl­
timo comando MSE) para cifrar la firma y formar el testigo 
de autentificación (hallará información más detallada al 
respecto en el apéndice 11).  
TCS_93  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  CLA  
INS 1  «88h»  INS  
P1 1  «00h»  P 1  
P2 1  «00h»  P 2  
Lc 1  «10h»  Longitud de los datos enviados a la tarjeta  
#6 — #13  8  «XX..XXh»  Interrogación empleada para autentificar la tarjeta  
#14 -#21  8  «XX..XXh»  VU.CHR (véase el apéndice 11)  
Le 1  «80h»  Longitud de los datos que se esperan de la tarjeta  
TCS_94  Mensaje de respuesta  
Byte  Longitud  Valor  Descripción  
#1-#128  128  «XX..XXh»  Testigo de autentificación de la tarjeta (véase el apéndice 
11) 
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— Si no hay una clave pública presente en el entorno de 
seguridad, se contesta con el estado de procesado 
«6A88 ». 
— Si no hay una clave privada presente en el entorno de 
seguridad, se contesta con el estado de procesado 
«6A88 ». 
— Si VU.CHR no coincide con el identificador actual de 
clave pública, se contesta con el estado de procesado 
«6A88 ». ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 265  
— Si se considera que la clave privada seleccionada está 
dañada, se contesta con el estado de procesado « 6400 » 
o «6581 ». 
▼M1 
TCS_95 Si el comando INTERNAL AUTHENTICATE se ejecuta 
correctamente, la clave de la sesión actual de generación 1, 
si la hay, se borra y deja de estar disponible. Para disponer 
de una nueva clave de sesión de generación 1, es preciso 
que se ejecute correctamente el comando EXTERNAL 
AUTHENTICATE para el mecanismo de autenticación de 
generación 1.  
Nota:  Para las claves de sesión de generación 2, véase 
el apéndice 11, CSM_193 y CSM_195. Si se establecen 
claves de sesión de generación 2 y la tarjeta de tacógrafo 
recibe el comando APDU plano INTERNAL AUTHENTI­
CATE, aborta la sesión de mensajería segura de generación 
2 y destruye las claves de sesión de generación 2.  
▼B 
3.5.9  EXTERNAL AUTHENTICATE  
Este comando cumple con lo dispuesto en la norma ISO/CEI 7816-4 . 
Por medio del comando EXTERNAL AUTHENTICATE, la tarjeta 
puede autentificar el IFD. En el apéndice 11 se describe el pro ceso 
de autenticación del tacógrafo G1 y G2 (autenticación de la VU) . 
TCS_96 La variante del comando para el mecanismo de autentica­
ción mutua de generación 1 es compatible únicamente con 
una aplicación de tacógrafo de generación 1.  
▼M1 
TCS_97 La variante del comando para la autenticación mutua de l a 
tarjeta de la VU de segunda generación puede ejecutarse en 
el MF, DF tacógrafo y DF tacógrafo_G2; véase también 
TCS_34. Si el comando EXTERNAL AUTHENTICATE 
de generación 2 se ejecuta correctamente, la clave de la 
sesión actual de generación 1, si la hay, se borra y deja 
de estar disponible.  
Nota:  Para las claves de sesión de generación 2, véase 
el apéndice 11, CSM_193 y CSM_195. Si se establecen 
claves de sesión de generación 2 y la tarjeta de tacógrafo 
recibe el comando APDU plano EXTERNAL AUTHENTI­
CATE, aborta la sesión de mensajería segura de generación 
2 y destruye las claves de sesión de generación 2.  
▼B 
TCS_98  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  CLA  
INS 1  «82h»  INS  
P1 1  «00h»  Claves y algoritmos conocidos implícitamente  
P2 1  «00h»  
Lc 1  «XXh»  Lc (Longitud de los datos enviados a la tarjeta)  
#6-#(5+L)  L  «XX..XXh»  Autenticación de generación 1: Criptograma (véase la 
parte A del apéndice 11) 
Autenticación de generación 2: Firma generada por el 
IFD (véase la parte B del apéndice 11)  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 266  
TCS_99  Mensaje de respuesta  
Byte  Longitud  Valor  Descripción  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— Si el CHA de la clave pública actualmente configurada 
no es la concatenación del AID de la aplicación de 
tacógrafo y de un tipo de equipo VU, se contesta con 
el estado de procesado « 6F00 ». 
— Si el comando no va precedido inmediatamente de un 
comando GET CHALLENGE, se contesta con el estado 
de procesado « 6985 ». 
La aplicación de tacógrafo de generación 1 puede devolver 
los siguientes códigos de error adicionales:  
— Si no hay una clave pública presente en el entorno de 
seguridad, se devuelve « 6A88 ». 
— Si no hay una clave privada presente en el entorno de 
seguridad, se contesta con el estado de procesado 
«6A88 ». 
— Si la verificación del criptograma es incorrecta, se con­
testa con el estado de procesado « 6688 ». 
— Si se considera que la clave privada seleccionada está 
dañada, se contesta con el estado de procesado « 6400 » 
o «6581 ». 
La variante del comando para la autenticación de genera­
ción 2 puede devolver el siguiente código de error 
adicional:  
— Si falla la verificación de la firma, la tarjeta contesta 
con el estado « 6300 ». 
3.5.10  GENERAL AUTHENTICATE  
Este comando sirve para el protocolo de autenticación de chips de 
generación que se especifica en la parte B del apéndice 11 y cu mple 
con lo dispuesto en la norma ISO/CEI 7816-4.  
TCS_100 El comando puede ejecutarse en el MF, DF tacógrafo y DF  
tacógrafo_G2; véase también TCS_34TCS_34.  
TCS_101  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  
INS 1  «86h»  
P1 1  «00h»  Claves y protocolo conocidos implícitamente  
P2 1  «00h»  
Lc 1  «NNh»  Lc: longitud del campo de datos subsiguiente  
#6-#(5+L)  L  «7Ch» + L  7C + 
«80h» + L  80 + 
«XX..XXh»  Valor de clave pública efímera codificada con 
DER-TLV (véase el apéndice 11) 
La VU deberá enviar los objetos de datos en este 
orden.  
▼M3 
Le 1  «00h»  Según se especifica en la norma ISO/CEI 7816-4  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 267  
TCS_102  Mensaje de respuesta  
Byte  Longitud  Valor  Descripción  
#1-#L  L  «7Ch» + L  7C + 
«81h» + «08h» + 
«XX..XXh» + «82h» 
+ L  82 + «XX..XXh»  Datos de autenticación dinámica codificados 
con DER-TLV: Testigo de autentificación espe­
cífico (véase el apéndice 11)  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— La tarjeta contesta con el estado « 6A80 » para indicar 
parámetros incorrectos en el campo de datos.  
— La tarjeta contesta con el estado « 6982 » si el comando 
de autenticación externa no se ha ejecutado correcta­
mente.  
El objeto de datos de autenticación dinámica de respuesta 
«7Ch»  
— debe estar presente si la operación se realiza con éxito, 
es decir, las palabras de estado son « 9000 », 
— debe estar ausente en caso de que se produzca un error 
de ejecución o un error de comprobación, es decir, si 
las palabras de estado se encuentran en el intervalo 
«6400 » — « 6FFF », y 
— puede estar ausente en caso de que se produzca una 
advertencia, es decir, si las palabras de estado se en­
cuentran en el intervalo « 6200 » — « 63FF ». 
3.5.11  MANAGE SECURITY ENVIRONMENT  
Este comando se utiliza para determinar una clave pública con f ines 
de autentificación.  
3.5.11.1 C o m a n d o d e g e n e r a c i ó n 1 — P a r d e r e s p u e s t a s  
Este comando cumple con lo dispuesto en la norma ISO/CEI 7816-4 . 
Este comando tiene un uso restringido en relación con dicha nor ma. 
TCS_103 Este comando es compatible únicamente con una aplicació n 
de tacógrafo de generación 1.  
TCS_104 La clave a que se hace referencia en el campo de datos 
MSE sigue siendo la clave pública actual hasta el siguiente 
comando MSE correcto, hasta que se selecciona un DF o 
hasta que se restablece la tarjeta.  
TCS_105 Si la clave a que se hace referencia no está (ya) prese nte en 
la tarjeta, el entorno de seguridad no experimenta cambio 
alguno.  
TCS_106  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  CLA  
INS 1  «22h»  INS  
P1 1  «C1h»  P1: clave a que se hace referencia, válida para todas las 
operaciones criptográficas  
P2 1  «B6h»  P2 (datos a que se hace referencia, relativos a la firma 
digital)  
Lc 1  «0Ah»  Lc: longitud del campo de datos subsiguiente  
#6 1  «83h»  Etiqueta para hacer referencia a una clave pública en 
casos asimétricos  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 268  
Byte  Longitud  Valor  Descripción  
#7 1  «08h»  Longitud de la referencia de la clave (identificador de 
clave)  
#8-#15  8  «XX..XXh»  Identificador de clave según se especifica en el 
apéndice 11  
TCS_107  Mensaje de respuesta  
Byte  Longitud  Valor  Descripción  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— Si la clave a que se hace referencia no está presente en 
la tarjeta, se contesta con el estado de procesado 
«6A88 ». 
— Si en el formato de mensajería segura faltan algunos de 
los objetos de datos que se esperaban, se devuelve el 
estado de procesado « 6987 ». Esto puede ocurrir si falta 
la etiqueta «83h».  
— Si algunos objetos de datos son incorrectos, se contesta 
con el estado de procesado « 6988 ». Esto puede ocurrir 
si la longitud del identificador de clave no es «08h».  
— Si se considera que la clave seleccionada está dañada, 
se contesta con el estado de procesado « 6400 » o 
«6581 ». 
3.5.11.2 C o m a n d o d e g e n e r a c i ó n 2 — P a r e s d e r e s p u e s t a s  
En cuanto a la autenticación de generación 2, la tarjeta de tac ógrafo 
admite los siguientes MSE: Versiones de comando establecidas qu e 
cumplen la norma ISO/CEI 7816-4. Estas versiones de comando no 
son compatibles con la autenticación de generación 1.  
3.5.11.2.1 M S E : S E T A T p a r a l a a u t e n t i c a c i ó n d e l c h i p  
El siguiente comando MSE:SET AT sirve para seleccionar los pará ­
metros de autenticación del chip que se realiza mediante un com ando 
de autenticación general subsiguiente.  
TCS_108 El comando puede ejecutarse en el MF, DF tacógrafo y DF  
tacógrafo_G2; véase también TCS_34TCS_34.  
TCS_109  Mensaje del comando MSE:SET AT para la autentica ­
ción del chip  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  
INS 1  «22h»  
P1 1  «41h»  Establecido para autenticación interna  
P2 1  «A4h»  Autenticación  
Lc 1  «NNh»  Lc: longitud del campo de datos subsiguiente  
#6-#(5+L)  L  «80h» + 
«0Ah» + 
«XX..XXh»  Referencia del mecanismo criptográfico codificado con 
DER-TLV: Identificador de objetos de autenticación 
del chip (solo el valor, se omite la etiqueta «06h»). 
Véase el apéndice 1 para conocer los valores de los 
identificadores de objetos; se utilizará la notación en 
bytes. Véase el apéndice 11 para conocer las orientacio­
nes sobre cómo seleccionar uno de estos identificadores 
de objetos.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 269  
3.5.11.2.2 M S E : S E T A T p a r a l a a u t e n t i c a c i ó n d e l a V U  
El siguiente comando MSE:SET AT sirve para seleccionar los pará ­
metros y las claves de autenticación de la VU que se realiza me diante 
un comando de autenticación externa subsiguiente.  
TCS_110 El comando puede ejecutarse en el MF, DF tacógrafo y DF  
tacógrafo_G2; véase también TCS_34TCS_34.  
TCS_111  Mensaje del comando MSE:SET AT para la autentica ­
ción de la VU  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  
INS 1  «22h»  
P1 1  «81h»  Establecido para autenticación externa  
P2 1  «A4h»  Autenticación  
Lc 1  «NNh»  Lc: longitud del campo de datos subsiguiente  
#6-#(5+L)  L  «80h» + 
«0Ah» + 
«XX..XXh»  Referencia del mecanismo criptográfico codificado con 
DER-TLV: Identificador de objetos de autenticación de 
la VU (solo el valor, se omite la etiqueta «06h»). 
Véase el apéndice 1 para conocer los valores de los 
identificadores de objetos; se utilizará la notación en 
bytes. Véase el apéndice 11 para conocer las orientacio­
nes sobre cómo seleccionar uno de estos identificadores 
de objetos.  
«83h» + 
«08h» + 
«XX..XXh»  Referencia codificada con DER-TLV de la clave pública 
de la VU por medio de la referencia al titular del certi­
ficado citado en el presente certificado.  
«91h» + 
L 91 + 
«XX..XXh»  Representación comprimida y codificada con DER-TLV 
de la clave pública efímera de la VU que se utilizará 
durante la autenticación del chip (véase el apéndice 11)  
3.5.11.2.3 M S E : S E T D S T  
El siguiente comando MSE:SET DST se utiliza para establecer una  
clave pública ya sea  
— para la verificación de una firma suministrada en un PSO subs i­
guiente: el comando Verify Digital Signature, ya sea  
— para la verificación de la firma de un certificado suministra do en 
un PSO subsiguiente: el comando Verify Certificate  
TCS_112 El comando puede ejecutarse en el MF, DF tacógrafo y DF  
tacógrafo_G2; véase también TCS_33.  
TCS_113  Mensaje del comando MSE:SET DST  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  
INS 1  «22h»  
P1 1  «81h»  Establecido para verificación  
P2 1  «B6h»  Firma digital  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 270  
Byte  Longitud  Valor  Descripción  
Lc 1  «NNh»  Lc: longitud del campo de datos subsiguiente  
#6-#(5+L)  L  «83h» + 
«08h» + 
«XX...XXh»  Referencia codificada con DER-TLV de una clave pú­
blica, es decir, la referencia al titular del certificado en el  
certificado de la clave pública (véase el apéndice 11)  
Para todas las versiones del comando, la estructura del mensaje  de 
respuesta y las palabras de estado vienen dadas por:  
TCS_114  Mensaje de respuesta  
Byte  Longitud  Valor  Descripción  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». Se ha seleccionado e ini­
cializado el protocolo.  
— « 6A80 » indica parámetros incorrectos en el campo de 
datos del comando.  
— « 6A88 » indica que los datos a que se hace referencia 
(es decir, una clave referenciada) no están disponibles.  
▼M1 
— Si el currentAuthenticatedTime de la tarjeta es posterior 
a la fecha de caducidad de la clave pública seleccio­
nada, se contesta con el estado de procesado  «6A88» . 
Nota:  En el caso del comando MSE: SET AT para la 
autenticación de la VU, la clave referenciada es una clave 
pública VU_MA. La tarjeta establecerá la clave pública 
VU_MA para su uso, si dispone de ella en su memoria, 
que coincida con la referencia al titular del 
certificado (CHR) que figura en el campo de datos del 
comando (la tarjeta puede identificar las claves públicas 
VU_MA mediante el campo CHA del certificado). La tar­
jeta devolverá el estado «6A88» a este comando solo en el 
caso de que no esté disponible en la unidad instalada en el 
vehículo la clave pública VU_Sign o ninguna otra clave 
pública. Véase la definición del campo CHA en el apéndice 
11, y la del tipo de dato equipmentType en el apéndice 1.  
Igualmente, en caso de que se envíe a una tarjeta de control 
un comando MSE: SET DST que haga referencia a un EQT 
(por ejemplo, una VU o una tarjeta), de conformidad con 
CSM_234 la clave referenciada es siempre una clave 
EQT_Sign que debe utilizarse para la verificación de una 
firma digital. Con arreglo a la figura 13 del apéndice 11, la 
tarjeta de control siempre habrá almacenado la clave pú­
blica EQT_Sign pertinente. En algunos casos, la tarjeta de 
control podrá haber almacenado la correspondiente clave 
pública EQT_MA. La tarjeta de control establecerá siempre 
la clave pública EQT_Sign para su uso cuando reciba un 
comando MSE: SET DST.  
▼B 
3.5.12  PSO: HASH  
Este comando sirve para transferir a la tarjeta el resultado de  un 
cálculo de comprobación aleatoria con unos datos determinados. 
Este comando se utiliza para la verificación de firmas digitale s. El 
valor de comprobación aleatoria se almacena temporalmente para el 
PSO del comando subsiguiente: Verify Digital Signature  
Este comando cumple con lo dispuesto en la norma ISO/CEI 7816-8 . 
Este comando tiene un uso restringido en relación con dicha nor ma. ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 271  
Solo la tarjeta de control debe admitir este comando en el DF t acó­
grafo y el DF tacógrafo_G2.  
Otros tipos de tarjetas de tacógrafo pueden o no incorporar est e co­
mando. El comando puede o no estar accesible en el MF.  
La aplicación de la tarjeta de control de generación 1 admite s olo 
SHA-1.  
TCS_115 El valor de comprobación aleatoria temporal deberá bo­
rrarse si se calcula un nuevo valor de comprobación alea­
toria por medio del comando PSO: HASH si se selecciona 
un DF y si se reinicia la tarjeta del tacógrafo.  
TCS_116  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  CLA  
INS 1  «2Ah»  Realizar operación de seguridad  
P1 1  «90h»  Devolver Hash code  
P2 1  «A0h»  Etiqueta: campo de datos contiene DO relevantes para 
comprobación aleatoria  
Lc 1  «XXh»  Longitud Lc del campo de datos subsiguiente  
#6 1  «90h»  Etiqueta para el hash code  
#7 1  «XXh»  Longitud L del hash code: 
«14h» en la aplicación generación 1 (véase la parte A del 
apéndice 11) 
«20h», «30h» o «40h» en la aplicación generación 2 
(véase la parte B del apéndice 11)  
#8-#(7+L)  L  «XX..XXh»  Hash code  
TCS_117  Mensaje de respuesta  
Byte  Longitud  Valor  Descripción  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— Si faltan algunos de los objetos de datos que se espe­
raban (anteriormente especificados), se devuelve el es­
tado de procesado « 6987 ». Esto puede ocurrir si falta 
una etiqueta «90h».  
— Si algunos objetos de datos son incorrectos, se contesta 
con el estado de procesado « 6988 ». Este error sucede si 
la etiqueta requerida está presente, pero tiene una lon­
gitud diferente desde «14h» para SHA-1, «20h» para 
SHA-256, «30h» para SHA-384, «40h» para SHA-512 
(aplicación de generación 2).  
3.5.13  PERFORM HASH of FILE  
Este comando no cumple la norma ISO/CEI 7816-8. Por consiguient e, 
el byte CLA de este comando indica que hay un uso propio del 
comando PERFORM SECURITY OPERATION/HASH.  
Solo la tarjeta del conductor y la tarjeta de taller deben admi tir este 
comando en el DF tacógrafo y el DF tacógrafo_G2.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 272  
Otros tipos de tarjetas de tacógrafo pueden o no incorporar est e co­
mando. Si una tarjeta de empresa o de control incorpora este co ­
mando, el comando deberá aplicarse del modo especificado en el 
presente apartado.  
El comando puede o no estar accesible en el MF. Si lo está, el 
comando deberá aplicarse del modo especificado en el presente a par­
tado, es decir, no deberá permitir el cálculo de un valor de co mpro­
bación aleatoria, sino que terminará con un código de error ade cuado.  
TCS_118 El comando PERFORM HASH of FILE sirve para realizar 
una comprobación aleatoria en la zona de datos del EF 
transparente actualmente seleccionado.  
TCS_119 Una tarjeta de tacógrafo deberá admitir este comando so lo 
para los EF que se relacionan en el apartado 44 dentro del 
apartado del DF_tacógrafo y del DF_tacógrafo_G2 con la 
siguiente excepción. Una tarjeta de tacógrafo no deberá 
admitir el comando para el EF Sensor_Installation_Data 
del DF tacógrafo_G2.  
TCS_120 El resultado de la operación de comprobación aleatoria se 
almacena temporalmente en la tarjeta. Posteriormente, 
puede utilizarse para obtener una firma digital del archivo 
por medio del PSO: el comando COMPUTE DIGITAL 
SIGNATURE.  
▼M1 
TCS_121 El valor de comprobación aleatoria del archivo temporal ­
mente almacenado deberá borrarse si se calcula un nuevo 
valor de comprobación aleatoria del archivo por medio del 
comando PERFORM HASH of FILE, si se selecciona un 
DF y si se reinicia la tarjeta del tacógrafo.  
▼B 
TCS_122 La aplicación del tacógrafo de generación 1 deberá admi tir 
SHA-1.  
▼M1 
TCS_123 La aplicación de tacógrafo de generación 2 deberá admit ir 
el algoritmo SHA-2 (SHA-256, SHA-384 o SHA-512), es­
pecificado en la serie de cifrado del apéndice 11, parte B, 
para la clave de firma de tarjeta Card_Sign.  
▼B 
TCS_124  Mensaje de comando  
▼M1 
Byte  Longitud  Valor  Descripción  
CLA  1  «80h»  CLA  
INS 1  «2Ah»  Realizar operación de seguridad  
P1 1  «90h»  Etiqueta: Hash  
P2 1  «00h»  Algoritmo conocido implícitamente 
Para la aplicación de tacógrafo de generación 1: SHA-1 
Para la aplicación de tacógrafo de generación 2: algo­
ritmo SHA-2 (SHA-256, SHA-384 o SHA-512), definido 
en la serie de cifrado del apéndice 11, parte B, para la 
clave de firma de tarjeta Card_Sign  
▼B 
TCS_125  Mensaje de respuesta  
Byte  Longitud  Valor  Descripción  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— Si el EF actual no admite este comando (EF Sen­
sor_Installation_Data en DF tacógrafo_G2), se contesta 
con el estado de procesado « 6985 ». ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 273  
— Si se considera que el EF seleccionado está dañado 
(errores de integridad en los atributos del archivo o 
los datos almacenados), se contesta con el estado de 
procesado « 6400 » o « 6581 ». 
— Si el archivo seleccionado no es un archivo o si no 
existen ningún EF actual, se contesta con el estado de 
procesado « 6986 ». 
3.5.14  PSO: COMPUTE DIGITAL SIGNATURE  
▼M1 
Este comando sirve para calcular la firma digital de un código de 
comprobación aleatoria calculado previamente (véase PERFORM 
HASH of FILE, §3.5.13).  
Solo la tarjeta de conductor y la tarjeta de taller deben admit ir este 
comando en el DF tacógrafo y el DF tacógrafo_G2.  
Otros tipos de tarjetas de tacógrafo pueden o no incorporar est e co­
mando. En el caso de la aplicación de tacógrafo de generación 2 , solo 
la tarjeta de conductor y la tarjeta de taller tienen una clave  de firma 
de generación 2, otras tarjetas no pueden ejecutar el comando c orrec­
tamente y terminan con un código de error adecuado.  
El comando puede o no estar accesible en el MF. Si el comando n o 
está accesible en el MF, deberá terminar con un código de error  
apropiado.  
Este comando cumple con lo dispuesto en la norma ISO/CEI 7816-8 . 
Este comando tiene un uso restringido en relación con dicha nor ma. 
▼B 
TCS_126 Este comando no deberá calcular una firma digital del c ó­
digo de comprobación aleatoria calculado anteriormente 
con el comando PSO: HASH.  
TCS_127 La tarjeta conoce implícitamente su clave privada, que se 
utiliza para calcular la firma digital.  
TCS_128 La aplicación del tacógrafo de generación 1 realiza una  
firma digital utilizando un método de relleno conforme a 
la norma PKCS1 (véanse los detalles en el apéndice 11).  
TCS_129 La aplicación del tacógrafo de generación 2 calcula una  
firma digital basada en una curva elíptica (véanse los deta­
lles en el apéndice 11).  
TCS_130  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  CLA  
INS 1  «2Ah»  Realizar operación de seguridad  
P1 1  «9Eh»  Firma digital que se ha de devolver  
P2 1  «9Ah»  Etiqueta: el campo de datos contiene los datos que se 
han de firmar. Como se incluye ningún campo de datos, 
se supone que los datos ya están presentes en la tarjeta 
(comprobación aleatoria del archivo)  
Le 1  «NNh»  Longitud de la firma esperada  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 274  
TCS_131  Mensaje de respuesta  
Byte  Longitud  Valor  Descripción  
#1-#L  L  «XX..XXh»  Firma de la comprobación aleatoria calculada previa­
mente  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— Si se considera que la clave privada seleccionada im­
plícitamente está dañada, se contesta con el estado de 
procesado « 6400 » o « 6581 ». 
— Si el valor de comprobación aleatoria que fue calculado 
en un comando anterior Perform Hash of File no está 
disponible, se contesta con el estado de procesado 
«6985 ». 
3.5.15  PSO: VERIFY DIGITAL SIGNATURE  
Este comando sirve para verificar la firma digital, suministrad a como 
entrada, cuya comprobación aleatoria conoce la tarjeta. La tarj eta 
conoce implícitamente el algoritmo de la firma.  
Este comando cumple con lo dispuesto en la norma ISO/CEI 7816-8 . 
Este comando tiene un uso restringido en relación con dicha nor ma. 
Solo la tarjeta de control debe admitir este comando en el DF t acó­
grafo y el DF tacógrafo_G2.  
Otros tipos de tarjetas de tacógrafo pueden o no incorporar est e co­
mando. El comando puede o no estar accesible en el MF.  
TCS_132 El comando VERIFY DIGITAL SIGNATURE siempre uti­
liza la clave pública seleccionada por el Manage Security 
Environment (MSE) anterior: el comando Set DST y el 
código de comprobación aleatoria anterior introducido por 
un comando PSO: HASH.  
TCS_133  Mensaje de comando  
▼M1 
Byte  Longitud  Valor  Descripción  
CLA  1  «00h»  CLA  
INS 1  «2Ah»  Realizar operación de seguridad  
P1 1  «00h»  
P2 1  «A8h»  Etiqueta: el campo de datos contiene DO relevantes para 
verificación  
Lc 1  «XXh»  Longitud Lc del campo de datos subsiguiente  
#6 1  «9Eh»  Etiqueta para firma digital  
#7 o 
#7-#8  L «NNh» o 
«81 NNh»  Longitud de la firma digital (L es 2 bytes si la firma 
digital es más larga que 127 bytes): 
128 bytes codificados conforme a la parte A del apéndice 
11 para una aplicación de tacógrafo de generación 1. 
Dependiendo de la curva seleccionada para la aplicación 
de tacógrafo de generación 2 (véase la parte B del apén­
dice 11)  
#(7+L)- 
#(6+L+NN)  NN «XX..XXh»  Contenido de la firma digital  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 275  
TCS_134  Mensaje de respuesta  
Byte  Longitud  Valor  Descripción  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— Si la verificación de la firma falla, se contesta con el 
estado de procesado « 6688 ». El proceso de verificación 
se describe en el apéndice 11.  
— Si no se selecciona una clave pública, se contesta con el 
estado de procesado « 6A88 ». 
— Si faltan algunos de los objetos de datos que se espe­
raban (anteriormente especificados), se devuelve el es­
tado de procesado « 6987 ». Esto puede ocurrir si falta 
una de las etiquetas necesarias.  
— Si no hay disponible un código de comprobación alea­
toria para procesar el comando (como resultado de un 
comando anterior PSO: comando HASH), se contesta 
con el estado de procesado « 6985 ». 
— Si algunos objetos de datos son incorrectos, se contesta 
con el estado de procesado « 6988 ». Esto puede ocurrir 
si la longitud de uno de los objetos de datos necesarios 
es incorrecta.  
— Si se considera que la clave pública seleccionada está 
dañada, se contesta con el estado de procesado « 6400 » 
o «6581 ». 
▼M1 
— Si la clave pública seleccionada (utilizada para verificar 
la firma digital) tiene un CHA.LSB (CertificateHolde­
rAuthorisation.equipmentType) que no es apropiado 
para la verificación de firmas digitales según el apén­
dice 11, se contesta con el estado de procesado « 6985 ». 
▼B 
3.5.16  PROCESS DSRC MESSAGE  
Este comando sirve para verificar la integridad y autenticidad del 
mensaje DSRC y para descifrar los datos transmitidos desde una 
VU a una autoridad de control o a un centro de ensayo a través del 
enlace DSRC. La tarjeta obtiene la clave de cifrado y la clave MAC 
utilizada para asegurar el mensaje DSRC del modo descrito en el  
apartado 13 de la parte B del apéndice 11.  
Solo la tarjeta de control y la tarjeta de taller deben admitir  este 
comando en el DF tacógrafo_G2.  
Otros tipos de tarjetas de tacógrafo pueden o no incorporar est e co­
mando, pero no tendrán una clave maestra DSRC. Por tanto, estas  
tarjetas no pueden ejecutar el comando correctamente, pero term inan 
con un código de error adecuado.  
El comando puede o no estar accesible en el MF y/o el DF tacógr afo. 
En caso afirmativo, el comando deberá terminar con un código de  
error adecuado.  
TCS_135 La clave maestra DSRC es accesible únicamente en el DT 
tacógrafo_G2, es decir, la tarjeta de control y la de taller 
deberán admitir una ejecución correcta del comando solo 
en el DF tacógrafo_G2.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 276  
TCS_136 El comando deberá descifrar solamente los datos DSRC y 
verificar la suma de control criptográfica, pero sin interpre­
tar los datos de entrada.  
TCS_137 El orden de los objetos de datos en el campo de datos d el 
comando queda fijado por la presente especificación.  
TCS_138  Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «80h»  CLA propio  
INS 1  «2Ah»  Realizar operación de seguridad  
P1 1  «80h»  Datos de respuesta: valor plano  
P2 1  «B0h»  Datos del comando: valor plano codificado en BER-TLV 
e incluye SM DO  
Lc 1  «NNh»  Longitud Lc del campo de datos subsiguiente  
#6-#(5+L)  L  «87h» + 
L 87 + 
«XX..XXh»  Byte indicador del contenido de relleno codificado con 
DET-TLV seguido de los datos útiles cifrados del tacó­
grafo. Se utilizará el valor «00h» («ninguna otra indica­
ción» según la tabla 52 de la norma ISO/CIE 7816- 
4:2013) para el byte indicador del contenido de relleno. 
Véase el apartado 13 de la parte B del apéndice 11 para 
obtener más información sobre el mecanismo de cifrado. 
Los valores permitidos para la longitud L  87 son múltiplos 
de la longitud del bloque AES más 1 para el byte indi­
cador del contenido de relleno, es decir, desde 17 bytes 
hasta 193 bytes inclusive.  
Nota:  Véase la tabla 49 de la norma ISO/CIE 7816- 
4:2013 para más información sobre el objeto de datos 
SM con etiqueta «87h».  
«81h» + 
«10h»  Plantilla de la referencia de control para confidencialidad 
codificada con DER-TLV que anida la concatenación de 
los elementos de datos siguientes (véase el apéndice 1 
DSRCSecurityData y el apartado 13 de la parte B del 
apéndice 11): 
— Indicación temporal de 4 bytes 
— Contador de 3 bytes 
— Número de serie de la VU de 8 bytes 
— Versión de la clave maestra DSRC de 1 byte  
Nota:  Véase la tabla 49 de la norma ISO/CIE 7816- 
4:2013 para más información sobre el objeto de datos 
SM con etiqueta «81h».  
«8Eh» + 
L 8E + 
«XX..XXh»  MAC codificada con DER-TLV a través del mensaje 
DSRC. Véase el apartado 13 de la parte B del apéndice 
11 para obtener más información sobre el algoritmo y 
cálculo de MAC.  
Nota:  Véase la tabla 49 de la norma ISO/CIE 7816- 
4:2013 para más información sobre el objeto de datos 
SM con etiqueta «8Eh».  
▼M3 
Le 1  «00h»  Según se especifica en la norma ISO/CEI 7816-4  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 277  
TCS_139  Mensaje de respuesta  
Byte  Longitud  Valor  Descripción  
#1-#L  L  «XX..XXh»  Ausente (en caso de error) o datos descifrados (relleno 
eliminado)  
SW 2  «XXXXh»  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, la tarjeta con­
testa con el estado « 9000 ». 
— « 6A80 » indica parámetros incorrectos en el campo de 
datos del comando (también se utiliza en caso de que 
los objetos de datos no se envíen en el orden especifi­
cado).  
— « 6A88 » indica que los datos a que se hace referencia, 
es decir, la clave maestra DSRC referenciada, no están 
disponibles.  
— « 6900 » indica que ha fallado la verificación de la suma 
de control criptográfica o el descifrado de los datos.  
▼M1 
— « 6985 » indica que el sello de tiempo de 4 bytes que 
aparece en el campo de datos del comando es anterior a 
cardValidityBegin o posterior a cardExpiryDate.  
▼B 
4. ESTRUCTURA DE LAS TARJETAS DE TACÓGRAFO  
El presente apartado especifica las estructuras de archivos de las 
tarjetas de tacógrafo para el almacenamiento de datos accesible s. 
No se especifican las estructuras internas que dependen del fab ricante 
de la tarjeta, como por ejemplo las cabeceras de archivos, ni e l alma­
cenamiento y la manipulación de elementos de datos necesarios p ara 
uso interno exclusivamente, como
  ,
  
,
 o
  .  
TCS_140 Una tarjeta de tacógrafo de generación 2 deberá incorpo rar 
el archivo maestro MF y una aplicación de tacógrafo de 
generación 1 y de generación 2 del mismo tipo (por ejem­
plo, aplicaciones de tarjeta del conductor).  
TCS_141 Una tarjeta de tacógrafo deberá admitir al menos el núm ero 
mínimo de registros especificados para las aplicaciones co­
rrespondientes y no admitirá más registros que el número 
máximo de registros especificados para las aplicaciones 
correspondientes.  
▼M3 
Los números máximo y mínimo de registros se especifican 
en este capítulo para las distintas aplicaciones. En la ver­
sión 2 de las tarjetas de conductor y de taller de segunda 
generación, la aplicación de primera generación admitirá el 
número máximo de registros especificado en TCS_150 y 
TCS_158.  
▼B 
En cuanto a las condiciones de seguridad utilizadas en las 
normas de acceso a lo largo de este apartado, véase el 
apartado 3.33.3. En general, el modo de acceso de «lec­
tura» denota el comando READ BINARY con byte INS 
par y, si se admite, impar a excepción del EF Sensor_Ins­
tallation_Data en la tarjeta de taller; véase 
TCS_156TCS_156 y TCS_160TCS_160. El modo de ac­
ceso de «actualización» denota el comando Update Binary 
con byte INS par y, si se admite, impar y el modo de 
acceso de «selección», el comando SELECT.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 278  
4.1. Archivo maestro MF  
TCS_142 Una vez personalizado el archivo maestro MF, tendrá la 
siguiente estructura permanente de archivo y las normas 
de acceso al archivo:  
Nota:  .El identificador EF corto SFID se da como número 
decimal, por ejemplo, el valor 30 se corresponde con 11110 
en binario.
  
En esta tabla se utiliza la siguiente abreviación para la 
condición de seguridad:  
SC1 ALW OR SM-MAC-G2  
TCS_143 La estructura de todos los EF deberá ser transparente.  
TCS_144 El archivo principal (MF) deberá tener la siguiente est ruc­
tura de datos:
  
TCS_145 El archivo elemental EF DIR deberá contener los siguien tes 
objetos de datos relacionados con la aplicación: «61 08 4F 
06 FF 54 41 43 48 4F 61 08 4F 06 FF 53 4D 52 44 54»  
TCS_146 El archivo elemental EF ATR/INFO deberá estar presente 
si la tarjeta de tacógrafo indica en su ATR que admite 
campos de longitud ampliada. En este caso, el EF ATR/ 
INFO llevará el objeto de datos con información de longi­
tud ampliada (DO«7F66») tal como se especifica en la 
cláusula 12.7.1 de la norma ISO/CIE 7816-4:2013.  
TCS_147 El archivo elemental EF Extended_Length deberá estar pr e­
sente si la tarjeta de tacógrafo indica en su ATR que admite 
campos de longitud ampliada. En este caso, el EF conten­
drá el siguiente objeto de datos: «02 01 xx», donde el valor 
«xx» indica si se admiten campos de longitud extendida 
para el protocolo T = 1 y/o T = 0.  
El valor «01» indica compatibilidad con el campo de lon­
gitud extendida para el protocolo T = 1.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 279  
El valor «10» indica compatibilidad con el campo de lon­
gitud extendida para el protocolo T = 0.  
El valor «11» indica compatibilidad con el campo de lon­
gitud extendida para el protocolo T = 1 y el T = 0.  
4.2. Aplicaciones de la tarjeta del conductor  
4.2.1  Aplicación de la tarjeta de conductor de generación 1  
TCS_148 Una vez personalizada, la aplicación de la tarjeta de c on­
ductor de generación 1 tendrá la siguiente estructura per­
manente de archivos y las normas de acceso a los archivos:
  
En esta tabla se utilizan las siguientes abreviaciones para 
las condiciones de seguridad:  
SC1 ALW OR SM-MAC-G2  
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2  
SC3 SM-MAC-G1 OR SM-MAC-G2  
TCS_149 La estructura de todos los EF deberá ser transparente.  
TCS_150 La aplicación de generación 1 de la tarjeta de conducto r 
deberá tener la siguiente estructura de datos:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 280
  
► (1) (2) M3 ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 281
  
▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 282  
TCS_151 Los valores siguientes, empleados para indicar tamaños en 
la tabla anterior, son los valores máximo y mínimo que la 
estructura de datos de la tarjeta de conductor debe utilizar 
para una aplicación de generación 1:
  
4.2.2  Aplicación de la tarjeta de conductor de generación 2  
▼M3 
TCS_152 Una vez personalizada, la aplicación de la tarjeta de c on­
ductor de segunda generación tendrá la estructura perma­
nente de archivos y las normas de acceso a los archivos 
siguientes:  
Notas:  
— El identificador EF corto, SFID, se da como número 
decimal, por ejemplo, el valor 30 se corresponde con 
11110 en binario.  
— Los archivos elementales Application_Identifica­
tion_V2, Places_Authentication, GNSS_Places_Authen­
tication, Border_Crossings, Load_Unload_Operations, 
VU_Configuration y Load_Type_Entries solo están pre­
sentes en la versión 2 de la tarjeta de conductor de 
segunda generación.  
— cardStructureVersion en el archivo elemental Applica­
tion_Identification es igual a {01 01} en la versión 2 de 
la tarjeta de conductor de segunda generación, mientras 
que era {01 00} en la versión 1 de la tarjeta de con­
ductor de segunda generación.
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 283  
En esta tabla se utilizan las siguientes abreviaciones para 
las condiciones de seguridad:  
SC1 ALW OR SM-MAC-G2  
SC5 Para el comando Read Binary con byte INS par: 
SM-C-MAC-G2 AND SM-R-ENC-MAC-G2  
Para el comando Read Binary con byte INS impar 
(si se admite): NEV  
▼B 
TCS_153 La estructura de todos los EF deberá ser transparente.  
▼M3 
TCS_154 La aplicación de segunda generación de la tarjeta de co n­
ductor deberá tener la siguiente estructura de datos:
  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 284
  
▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 285
  
▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 286  
TCS_155 Los valores siguientes, empleados para indicar tamaños en 
la tabla anterior, son los valores máximo y mínimo de los 
números de registro que la estructura de datos de la tarjeta 
de conductor debe utilizar para una aplicación de genera­
ción 2:  
▼M3 
Mín.  Máx.  
n 1 NoOfEventsPerType  1 2  1 2  
n 2 NoOfFaultsPerType  2 4  2 4  
n 3 NoOfCardVehicleRecords  200  200  
n 4 NoOfCardPlaceRecords  112  112  
n 6 CardActivityLengthRange  13 776 bytes 
(56 días * 
117 cambios de 
actividad)  13 776 bytes 
(56 días * 
117 cambios de 
actividad)  
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  3 072 bytes  3 072 bytes  
▼B 
4.3. Aplicaciones de la tarjeta de taller  
4.3.1  Aplicación de la tarjeta del centro de ensayo de generación 1  
TCS_156 Una vez personalizada, la aplicación de la tarjeta de t aller 
de generación 1 tendrá la siguiente estructura permanente 
de archivos y las normas de acceso a los archivos:
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 287  
En esta tabla se utilizan las siguientes abreviaciones para 
las condiciones de seguridad:  
SC1 ALW OR SM-MAC-G2  
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2  
SC3 SM-MAC-G1 OR SM-MAC-G2  
▼M1 
SC4 Para el comando READ BINARY con byte INS par:  
(SM-C-MAC-G1 Y SM-R-ENC-MAC-G1) O  
(SM-C-MAC-G2 Y SM-R-ENC-MAC-G2)  
Para el comando READ BINARY con byte INS 
impar (si se admite): NEV  
▼B 
TCS_157 La estructura de todos los EF deberá ser transparente.  
TCS_158 La aplicación de la tarjeta de taller de generación 1 d eberá 
tener la siguiente estructura de datos:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 288
  
▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 289
  
▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 290
  
TCS_159 Los valores siguientes, empleados para indicar tamaños en 
la tabla anterior, son los valores máximo y mínimo que la 
estructura de datos de la tarjeta de taller debe utilizar para 
una aplicación de generación 1:
  
4.3.2  Aplicación de la tarjeta de taller de generación 2  
▼M3 
TCS_160 Una vez personalizada, la aplicación de la tarjeta de t aller 
de segunda generación tendrá la estructura permanente de 
archivos y las normas de acceso a los archivos siguientes:  
Notas:  
— El identificador EF corto, SFID, se da como número 
decimal, por ejemplo, el valor 30 se corresponde con 
11110 en binario.  
— Los archivos elementales Application_Identifica­
tion_V2, Places_Authentication, GNSS_Places_Authen­
tication, Border_Crossings, Load_Unload_Operations, 
Load_Type_Entries, VU_Configuration y Calibra­
tion_Add_Data solo están presentes en la versión 2 
de la tarjeta de taller de segunda generación.  
— cardStructureVersion en el archivo elemental Applica­
tion_Identification es igual a {01 01} en la versión 2 de 
la tarjeta de taller de segunda generación, mientras que 
era {01 00} en la versión 1 de la tarjeta de taller de 
segunda generación.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 291
  
En esta tabla se utilizan las siguientes abreviaciones para 
las condiciones de seguridad:  
SC1 ALW OR SM-MAC-G2  
SC5 Para el comando Read Binary con byte INS par: 
SM-C-MAC-G2 AND SM-R-ENC-MAC-G2  
Para el comando Read Binary con byte INS impar 
(si se admite): NEV  
▼B 
TCS_161 La estructura de todos los EF deberá ser transparente.  
TCS_162 La aplicación de la tarjeta de taller de generación 2 d eberá 
tener la siguiente estructura de datos:  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 292
  
▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 293
  
▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 294
  
▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 295
  
▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 296  
TCS_163 Los valores siguientes, empleados para indicar tamaños en 
la tabla anterior, son los valores máximo y mínimo que la 
estructura de datos de la tarjeta de taller debe utilizar para 
una aplicación de generación 2:  
▼M3 
Mín.  Máx.  
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 bytes (1 día * 240 
cambios de actividad)  492 bytes (1 día * 
240 cambios de activi­
dad) 
n 7 NoOfCardVehicleUnitRecords  8  8  
n 8 NoOfGNSSADRecords  2 4  2 4  
n 9 NoOfSpecificConditionRecords  4  4  
n 10 NoOfBorderCrossingRecords  4  4  
n 11 NoOfLoadUnloadRecords  8  8  
n 12 NoOfLoadTypeEntryRecords  4  4  
n 13 VuConfigurationLengthRange  3 072 bytes  3 072 bytes  
▼B 
4.4. Aplicaciones de la tarjeta de control  
4.4.1  Aplicación de la tarjeta de control de generación 1  
TCS_164 Una vez personalizada, la aplicación de la tarjeta de c ontrol 
de generación 1 tendrá la siguiente estructura permanente 
de archivos y las normas de acceso a los archivos:
  
En esta tabla se utilizan las siguientes abreviaciones para 
las condiciones de seguridad:  
SC1 ALW OR SM-MAC-G2  
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2  
SC3 SM-MAC-G1 OR SM-MAC-G2  
SC6 EXT-AUT-G1 O SM-MAC-G1 O SM-MAC-G2  
TCS_165 La estructura de todos los EF deberá ser transparente.  
TCS_166 La aplicación de la tarjeta de control de generación 1 de­
berá tener la siguiente estructura de datos:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 297
  
TCS_167 Los valores siguientes, empleados para indicar tamaños en 
la tabla anterior, son los valores máximo y mínimo que la 
estructura de datos de la tarjeta de control debe utilizar para  
una aplicación de generación 1:
  
4.4.2  Aplicación de la tarjeta de control de generación 2  
▼M3 
TCS_168 Una vez personalizada, la aplicación de la tarjeta de c ontrol 
de segunda generación tendrá la estructura permanente de 
archivos y las normas de acceso a los archivos siguientes:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 298  
Notas:  
— El identificador EF corto, SFID, se da como número 
decimal, por ejemplo, el valor 30 se corresponde con 
11110 en binario.  
— Los archivos elementales Application_Identification_V2 
y VU_Configuration solo están presentes en la versión 2 
de la tarjeta de control de segunda generación.  
— cardStructureVersion en el archivo elemental Applica­
tion_Identification es igual a {01 01} en la versión 2 de 
la tarjeta de control de segunda generación, mientras 
que era {01 00} en la versión 1 de la tarjeta de control 
de segunda generación.
  
En esta tabla se utilizan las siguientes abreviaciones para 
las condiciones de seguridad:  
SC1 ALW OR SM-MAC-G2  
SC5 Para el comando Read Binary con byte INS par: 
SM-C-MAC-G2 AND SM-R-ENC-MAC-G2  
Para el comando Read Binary con byte INS 
impar (si se admite): NEV  
▼B 
TCS_169 La estructura de todos los EF deberá ser transparente.  
TCS_170 La aplicación de la tarjeta de control de generación 2 de­
berá tener la siguiente estructura de datos:  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 299
  
▼B 
TCS_171 Los valores siguientes, empleados para indicar tamaños en 
la tabla anterior, son los valores máximo y mínimo que la 
estructura de datos de la tarjeta de control debe utilizar para  
una aplicación de generación 2:  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 300  
Mín.  Máx.  
n 7 NoOfControlActivityRecords  230  520  
n 13 VuConfigurationLengthRange  3072 bytes  3 072 bytes  
▼B 
4.5. Aplicaciones de la tarjeta de empresa  
4.5.1  Aplicación de la tarjeta de empresa de generación 1  
TCS_172 Una vez personalizada, la aplicación de la tarjeta de e m­
presa de generación 1 tendrá la siguiente estructura perma­
nente de archivos y las normas de acceso a los archivos:
  
En esta tabla se utilizan las siguientes abreviaciones para 
las condiciones de seguridad:  
SC1 ALW OR SM-MAC-G2  
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2  
SC3 SM-MAC-G1 OR SM-MAC-G2  
SC6 EXT-AUT-G1 O SM-MAC-G1 O SM-MAC-G2  
TCS_173 La estructura de todos los EF deberá ser transparente.  
TCS_174 La aplicación de la tarjeta de empresa de generación 1 
deberá tener la siguiente estructura de datos:
  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 301  
TCS_175 Los valores siguientes, empleados para indicar tamaños en 
la tabla anterior, son los valores máximo y mínimo que la 
estructura de datos de la tarjeta de empresa debe utilizar 
para una aplicación de generación 1:
  
4.5.2  Aplicación de la tarjeta de empresa de generación 2  
▼M3 
TCS_176 Una vez personalizada, la aplicación de la tarjeta de e m­
presa de segunda generación tendrá la estructura perma­
nente de archivos y las normas de acceso a los archivos 
siguientes:  
Notas:  
— El identificador EF corto, SFID, se da como número 
decimal, por ejemplo, el valor 30 se corresponde con 
11110 en binario.  
— Los archivos elementales Application_Identification_V2 
y VU_Configuration solo están presentes en la versión 2 
de la tarjeta de empresa de segunda generación.  
— cardStructureVersion en el archivo elemental Applica­
tion_Identification es igual a {01 01} en la versión 2 de 
la tarjeta de empresa de segunda generación, mientras 
que era {01 00} en la versión 1 de la tarjeta de empresa 
de segunda generación.
  
En esta tabla se utilizan las siguientes abreviaciones para 
las condiciones de seguridad:  
SC1 ALW OR SM-MAC-G2  
SC5 Para el comando Read Binary con byte INS par: 
SM-C-MAC-G2 AND SM-R-ENC-MAC-G2  
Para el comando Read Binary con byte INS 
impar (si se admite): NEV  
▼B 
TCS_177 La estructura de todos los EF deberá ser transparente.  
TCS_178 La aplicación de la tarjeta de empresa de generación 2 
deberá tener la siguiente estructura de datos:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 302
  
▼B 
TCS_179 Los valores siguientes, empleados para indicar tamaños en 
la tabla anterior, son los valores máximo y mínimo que la 
estructura de datos de la tarjeta de empresa debe utilizar 
para una aplicación de generación 2:  
▼M3 
Mín.  Máx.  
n 8 NoOfCompanyActivityRecords  230  520  
n 13 VuConfigurationLengthRange  3072 bytes  3 072 bytes  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 303  
Apéndice 3  
PICTOGRAMAS  
PIC_001 El tacógrafo podrá utilizar, de forma opcional, los sig uientes picto­
gramas y combinaciones de pictogramas (o pictogramas y combina­
ciones lo suficientemente parecidas para identificarse con esta s de 
forma inequívoca):  
1. PICTOGRAMAS BÁSICOS  
Personas  Acciones  Modos de funcionamiento
  
Empresa  Modo de empresa
  
Controlador  Control  Modo de control
  
Conductor  Conducción  Modo operativo
  
Taller/centro de ensayo  Inspección/calibrado  Modo de calibrado
  
Fabricante  
Actividades  Duración
  
Disponible  Período de disponibilidad actual
  
Conducción  Tiempo de conducción continua
  
Descanso  Período de descanso actual
  
Otro trabajo  Período de trabajo actual
  
Pausa  Tiempo de pausa acumulado
  
Indeterminado  
Equipo  Funciones
  
Ranura del conductor
  
Ranura del segundo conductor
  
Tarjeta
  
Reloj
  
Pantalla  Visualización
  
Almacenamiento externo  Transferencia
  
Fuente de alimentación
  
Impresora/doc. impreso  Impresión
  
Sensor
  
Tamaño de los neumáticos
  
Vehículo/unidad instalada en el 
vehículo
  
Dispositivo GNSS
  
Dispositivo de detección a distancia
  
Interfaz STI  ▼B
02016R0799 — ES — 21.08.2023 — 003.001 — 304  
Condiciones específicas, entradas manuales
  
Fuera de ámbito
  
Trayecto en transbordador/tren
  
Operación de carga
  
Operación de descarga
  
Operación de carga/descarga simultáneas
  
Tipo de carga: pasajeros
  
Tipo de carga: mercancías
  
Tipo de carga: indefinido  
▼B 
Varios
  
Incidentes
  Fallos
  
Comienzo del período de trabajo diario
  Final del período de trabajo diario
  
Lugar
  
Entrada manual de las actividades del 
conductor  
▼M3
 
Seguridad / datos autenticados / sellos  
▼B
 
Velocidad
  
Hora
  
Total/resumen  
▼M3
 
Mapa digital / cruce de fronteras  
▼B 
Calificadores  
24h Diario
  
Semanal
  
Bisemanal
  
Desde o hasta  
2. COMBINACIONES DE PICTOGRAMAS  
Varios
  
Lugar de control
  
Lugar donde comienza el período de 
trabajo diario
  Lugar donde termina el período 
de trabajo diario  
▼M1
 
Posición tras un tiempo de conducción 
acumulado de tres horas  
▼B
 
Hora de comienzo
  Hora de conclusión
  
Desde el vehículo
  
Comienzo condición Fuera de ámbito
  Final condición Fuera de ámbito  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 305
  
Posición donde el vehículo ha cruzado 
la frontera entre dos países
  
Posición donde se ha producido una 
operación de carga
  
Posición donde se ha producido una 
operación de descarga
  
Posición donde se ha producido una 
operación de carga/descarga simultáneas  
▼B 
Tarjetas
  
Tarjeta de conductor
  
Tarjeta de empresa
  
Tarjeta de control
  
Tarjeta de taller
  
Sin tarjeta  
Conducción
  
Conducción en equipo
  
Tiempo de conducción en una semana
  
Tiempo de conducción en dos semanas  
Documentos impresos
  
Impresión diaria de las actividades del conductor almacenadas e n la tarjeta
  
Impresión diaria de las actividades del conductor almacenadas e n la VU
  
Impresión de incidentes y fallos almacenados en la tarjeta
  
Impresión de incidentes y fallos almacenados en la VU
  
Impresión de datos técnicos
  
Impresión de excesos de velocidad  
▼M3
 
Impresión del historial de tarjetas insertadas  
▼B 
Incidentes
  
Inserción de una tarjeta no válida
  
Conflicto de tarjetas
  
Solapamiento temporal
  
Conducción sin tarjeta adecuada
  
Inserción de tarjeta durante la conducción
  
Error al cerrar la última sesión de la tarjeta
  
Exceso de velocidad
  
Interrupción del suministro eléctrico
  
Error en datos de movimiento
  
Conflicto de movimiento del vehículo
  
Violación de la seguridad  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 306
  
Conflicto temporal o ajuste de la hora (por el taller)  
▼B
 
Control del exceso de velocidad  
▼M1
 
Ausencia de información de posición del receptor GNSS 
o Error de comunicación con el dispositivo GNSS ex­
terno
  
Error de comunicación con el dispositivo de comunica­
ción a distancia  
▼M3
 
Anomalía del GNSS  
▼B 
Fallos
  
Fallo de tarjeta (ranura del conductor)
  
Fallo de tarjeta (ranura del segundo conductor)
  
Fallo de la pantalla
  
Fallo de transferencia
  
Fallo de la impresora
  
Fallo del sensor
  
Fallo interno de la VU
  
Fallo del dispositivo GNSS
  
Fallo de la detección a distancia  
Procedimiento de entrada manual
  
¿Continúa el mismo período de trabajo diario?
  
¿Final del anterior período de trabajo?
  
Confirme o introduzca el lugar donde termina el período de trab ajo
 
Introduzca la hora de comienzo
  
Introduzca el lugar donde comienza el período de trabajo  
Nota:  En el apéndice 4 se definen otras combinaciones de pictogramas  
que representan bloques de impresión o identificadores de regis tro. ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 307  
Apéndice 4  
DOCUMENTOS IMPRESOS  
ÍNDICE  
1. GENERALIDADES  
2. ESPECIFICACIÓN DE LOS BLOQUES DE DATOS  
3. ESPECIFICACIONES DE LOS DOCUMENTOS IMPRESOS  
3.1. Impresión diaria de las actividades del conductor almacena das en la 
tarjeta  
3.2. Impresión diaria de las actividades del conductor almacena das en la VU  
3.3. Impresión de incidentes y fallos almacenados en la tarjeta  
3.4. Impresión de incidentes y fallos almacenados en la VU  
3.5. Impresión de datos técnicos  
3.6. Impresión de excesos de velocidad  
3.7. Historial de tarjetas insertadas  
1. GENERALIDADES  
Cada documento impreso es una concatenación de varios bloques d e 
datos, posiblemente identificados con un identificador de bloqu e. 
Un bloque de datos contiene uno o más registros, posiblemente i denti­
ficados con un identificador de registro.  
PRT_001 Cuando un identificador de bloque precede inmediatament e a 
un identificador de registro, el identificador de registro no s e 
imprime.  
PRT_002 Cuando una unidad de información se desconoce o no debe  
imprimirse por motivos relacionados con los derechos de 
acceso a los datos, en su lugar se imprimen espacios.  
PRT_003 Si el contenido de una línea entera es desconocido o no  tiene 
que imprimirse, se omite toda la línea.  
PRT_004 Los campos de datos numéricos se imprimen alineados a l a 
derecha, con un espacio como separador de las unidades de 
millar y de millón, y sin ceros a la izquierda.  
▼M3 
PRT_005 Los campos de datos en cadena se imprimen alineados a l a 
izquierda y se rellenan con espacios hasta alcanzar la longitud  
de la unidad de información, o bien se truncan para no so­
brepasar dicha longitud. Los nombres y las direcciones po­
drán imprimirse en dos líneas.  
▼B 
PRT_006 Cuando haya que dividir una línea cuyo texto sea largo,  debe 
imprimirse un carácter especial (un punto a media altura de la 
línea, «•») como primer carácter en la línea nueva.  
2. ESPECIFICACIÓN DE LOS BLOQUES DE DATOS  
En este capítulo se han utilizado las siguientes convenciones p ara la 
notación de formatos:  
— los caracteres impresos en  negrita  indican texto legible que hay que 
imprimir (en caracteres normales),  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 308  
— los caracteres normales indican variables (pictogramas o dato s) que 
hay que sustituir por sus valores antes de proceder a la impres ión, 
— los nombres de las variables se han acabado de llenar con gui ones 
bajos con el fin de mostrar la longitud disponible para la vari able en 
ese elemento de información,  
— las fechas se especifican con el formato «dd/mm/aaaa» (día, m es, 
año). También se puede utilizar el formato «dd.mm.aaaa»,  
— el término «identificación de la tarjeta» indica la composici ón de: el 
tipo de tarjeta (mediante una combinación de pictogramas), el c ó­
digo del Estado miembro que ha expedido la tarjeta, un carácter  de 
barra oblicua y el número de tarjeta con el índice de sustituci ón y el 
índice de renovación separados por espacios: 
P
 x  x  x  / x  x  x  x  x  x  x  x  x  x  x  x  x  x  x  x
 Combinaciones de 
pictogramas de 
tarjeta  
Código del Estado 
miembro emisor Primeros 14 caracteres del número de tarjeta 
(incluido posiblemente un índice consecutivo)
 
Índice de sustitución  
Índice de renovación 
▼M3 
— en un bloque de datos, el texto después de «pi=» se refiere a l 
pictograma o la combinación de pictogramas correspondientes def i­
nidos en el apéndice 3,  
— cuando se imprime después de la longitud y la latitud de una posi­
ción registrada, o después del sello de tiempo en que se determ inó la 
posición, el pictograma
  indica que esta posición se ha calculado a 
partir de mensajes de navegación autenticados,  
— * datos disponibles únicamente en tacógrafos GEN2 (todas las ver­
siones),  
— ** datos disponibles únicamente en la versión 2 de la GEN2.  ▼B
02016R0799 — ES — 21.08.2023 — 003.001 — 309  
PRT_007 Los documentos impresos deberán utilizar los siguientes  bloques de 
datos y/o registros de datos, con arreglo a los significados y formatos 
que se exponen a continuación:
  
► (1) (2) (3) (4) (5)  M3 ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 310
  
► (1) (2) (3)  M3 ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 311
  
► (1) (2) M3 ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 312
  
▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 313
  
► (1) (2) (3) (4)  M3 ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 314
  
▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 315
  
► (1) M3 
3. ESPECIFICACIONES DE LOS DOCUMENTOS IMPRESOS  
En este capítulo se han empleado las siguientes convenciones pa ra la 
notación: 
N Imprimir bloque o registro número N  
N Imprimir bloque o registro número N, repetido tantas veces como  sea 
necesario  
X/Y Imprimir bloques o registros X o Y según proceda, y repetidos t antas 
veces como sea necesario.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 316  
3.1. Impresión diaria de las actividades del conductor almacenadas en la 
tarjeta  
▼M3 
PRT_008 La impresión diaria de las actividades del conductor al mace­
nadas en la tarjeta deberá efectuarse con arreglo al formato 
siguiente:
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 317  
3.2. Impresión diaria de las actividades del conductor almacenadas en la 
VU 
▼M3 
PRT_009 La impresión diaria de las actividades del conductor al mace­
nadas en la VU deberá efectuarse con arreglo al formato 
siguiente:
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 318  
3.3. Impresión de incidentes y fallos almacenados en la tarjeta  
PRT_010 La impresión de incidentes y fallos almacenados en la t arjeta 
deberá efectuarse con arreglo al formato siguiente: 
1 Fecha y hora en la que se imprime el documento  
2 Tipo de documento impreso  
3 Identificación del controlador (si se inserta una tarjeta de co ntrol en 
la VU + GEN)  
3 Identificación del conductor (según la tarjeta cuyos datos se i mpri­
men)  
4 Identificación del vehículo (vehículo del que se obtiene el doc u­
mento impreso)  
12.2 Delimitador de incidentes  
12.4 Registros de incidentes (todos los incidentes almacenados en la  tar­
jeta) 
12.3 Delimitador de fallos  
12.4 Registros de fallos (todos los fallos almacenados en la tarjeta ) 
22.1 Lugar de control  
22.2 Firma del controlador  
22.5 Firma del conductor  
3.4. Impresión de incidentes y fallos almacenados en la VU  
PRT_011 La impresión de incidentes y fallos almacenados en la V U 
deberá efectuarse con arreglo al formato siguiente: 
1 Fecha y hora en la que se imprime el documento  
2 Tipo de documento impreso  
3 Identificación del titular de la tarjeta (para todas las tarjet as inserta­
das en la VU + GEN)  
4 Identificación del vehículo (vehículo del que se obtiene el doc u­
mento impreso)  
13.2 Delimitador de incidentes  
13.4 Registros de incidentes (todos los incidentes almacenados o en curso 
en la VU)  
13.3 Delimitador de fallos  
13.4 Registros de fallos (todos los fallos almacenados o en curso en  la 
VU) 
22.1 Lugar de control  
22.2 Firma del controlador  
22.5 Firma del conductor  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 319  
3.5. Impresión de datos técnicos  
▼M3 
PRT_012 La impresión de datos técnicos deberá efectuarse con ar reglo 
al formato siguiente:
  ▼B
02016R0799 — ES — 21.08.2023 — 003.001 — 320  
3.6. Impresión de excesos de velocidad  
PRT_013 La impresión por exceso de velocidad deberá efectuarse con 
arreglo al formato siguiente: 
1 Fecha y hora en la que se imprime el documento  
2 Tipo de documento impreso  
3 Identificación del titular de la tarjeta (para todas las tarjet as inserta­
das en la VU + GEN)  
4 Identificación del vehículo (vehículo del que se obtiene el doc u­
mento impreso)  
20 Información sobre el control del exceso de velocidad  
21.1 Identificador de los datos sobre el exceso de velocidad  
21.4/21.5  Primer exceso de velocidad después del último calibrado  
21.2 Identificador de los datos sobre el exceso de velocidad  
21.4/21.5  Los 5 incidentes más graves de exceso de velocidad ocurridos en  los 
últimos 365 días  
21.3 Identificador de los datos sobre el exceso de velocidad  
21.4/21.5  El incidente más grave de exceso de velocidad en cada uno de lo s 10 
últimos días en que hayan ocurrido incidentes de este tipo  
22.1 Lugar de control  
22.2 Firma del controlador  
22.5 Firma del conductor  
3.7. Historial de tarjetas insertadas  
▼M3 
PRT_014 La impresión del historial de tarjetas insertadas deber á efec­
tuarse con arreglo al formato siguiente:
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 321  
Apéndice 5  
VISUALIZACIÓN  
En este apéndice se utilizan las siguientes convenciones para l a notación de 
formatos:  
— los caracteres impresos  en negrita  indican texto legible en la visualización (la 
visualización aparece en caracteres normales),  
— los caracteres normales indican variables (pictogramas o dato s) que hay que 
sustituir por sus valores en la visualización:  
— dd mm aaaa: día, mes, año,  
— hh: horas,  
— mm: minutos,  
— D: pictograma de duración,  
— EF: combinación de pictogramas de incidente o fallo,  
— O: pictograma de modo de funcionamiento.  
DIS_001 En la visualización, el aparato de control deberá utili zar los formatos 
siguientes:  
Datos  Formato  
Visualización por defecto  
Hora local
  
Modo de funcionamiento
  
Información relativa al conductor
  
Información relativa al segundo conductor
  
Condición fuera de ámbito abierta
  
Visualización de alerta  
Superación del tiempo de conducción continua
  
Incidente o fallo
  
Otras visualizaciones  
Fecha UTC
  
Hora  
Tiempo de conducción continua y tiempo de descanso acu­
mulado del conductor
  
Tiempo de conducción continua y tiempo de descanso acu­
mulado del segundo conductor
  
Tiempo de conducción acumulado del conductor durante la 
semana anterior y la actual
  
Tiempo de conducción acumulado del segundo conductor 
durante la semana anterior y la actual
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 322  
Apéndice 6  
CONECTOR FRONTAL PARA EL CALIBRADO Y LA TRANSFEREN ­
CIA DE DATOS  
ÍNDICE  
1. EQUIPO INFORMÁTICO  
1.1. Conector  
1.2. Asignación de contactos  
1.3. Diagrama de conjunto  
2. INTERFAZ DE TRANSFERENCIA  
3. INTERFAZ DE CALIBRADO  
1. EQUIPO INFORMÁTICO  
1.1. Conector  
INT_001 El conector de transferencia/calibrado deberá tener 6 p atillas y 
ser accesible en el panel frontal sin necesidad de desconectar 
ninguno de los elementos del tacógrafo, y sus dimensiones se 
ajustarán al siguiente esquema (dimensiones en milímetros):
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 323  
La siguiente ilustración muestra una clavija de acoplamiento 
típica de 6 patillas:
  
1.2. Asignación de contactos  
INT_002 Los contactos se asignarán de acuerdo con la tabla sigu iente:  
Patilla  Descripción  Observaciones  
1 Polo negativo batería  Conectado al polo negativo de la batería del vehículo  
2 Comunicación de datos  Línea K (ISO 14230-1)  
3 Transferencia RxD  Entrada de datos en el tacógrafo  
4 Señal de entrada/salida  Calibrado  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 324  
Patilla  Descripción  Observaciones  
5 Salida permanente de poten­
cia Se especifica que el intervalo de tensiones debe ser el de la 
potencia del vehículo menos 3 V para tener en cuenta la 
caída de tensión en los circuitos de protección. 
Salida 40 mA  
6 Transferencia RxD  Salida de datos del tacógrafo  
1.3. Diagrama de conjunto  
INT_003 El diagrama de conjunto será el siguiente:
  
2. INTERFAZ DE TRANSFERENCIA  
INT_004 La interfaz de transferencia deberá cumplir las especif icaciones 
RS232.  
INT_005 La interfaz de transferencia deberá utilizar un bit de arranque, 
ocho bits de datos con el bit LSB primero, un bit de paridad pa r 
y un bit de parada.
  
Organización de los bytes de datos  
Bit de arranque: un bit de nivel lógico 0;  
Bits de datos: transmitidos con LSB primero;  
Bit de paridad: paridad par  
Bit de parada: un bit de nivel lógico 1  
Cuando se transmitan datos numéricos compuestos de más de un by te, el 
byte más significativo se transmitirá el primero, y el byte men os signifi­
cativo el último.  
INT_006 La velocidad de transmisión deberá poder ajustarse entr e 9 600 
bps y 115 200 bps. La transmisión deberá efectuarse a la velo­
cidad más alta posible; la velocidad inicial en baudios al come n­
zar la comunicación se fija en 9 600 bps.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 325  
3. INTERFAZ DE CALIBRADO  
INT_007 La comunicación de datos deberá cumplir lo dispuesto en  la 
norma ISO 14230-1 Vehículos de carretera — Sistemas de diag­
nóstico — Protocolo Keyword 2000 — Parte 1: Nivel físico, 
Primera edición: 1999.  
INT_008 La señal de entrada/salida deberá cumplir las siguiente s especi­
ficaciones eléctricas:  
Parámetro  Mínimo  Típico  Máximo  Observaciones  
U low (in) 1,0 V  I = 750 μA  
U high (in) 4  V  I = 200 μA  
Frecuencia  4 kHz  
U low (out)  1,0 V  I  =  1  m A  
U high (out)  4  V  I  =  1  m A  
INT_009 La señal de entrada/salida deberá cumplir los siguiente s diagra­
mas de relaciones de tiempo:
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 326  
Apéndice 7  
PROTOCOLOS DE TRANSFERENCIA DE DATOS  
ÍNDICE  
1. INTRODUCCIÓN  
1.1. Ámbito de aplicación  
1.2. Acrónimos y notaciones  
2. TRANSFERENCIA DE LOS DATOS DE LA VU  
2.1. Procedimiento de transferencia  
2.2. Protocolo de transferencia de datos  
2.2.1 Estructura del mensaje  
2.2.2 Tipos de mensajes  
2.2.2.1 Start Communication Request (petición de inicio de comu nicación) (SId 
81) 
2.2.2.2 Positive Response Start Communication (respuesta positi va a la petición 
de inicio de comunicación) (SId C1)  
2.2.2.3 Start Diagnostic Session Request (petición de inicio de  la sesión de 
diagnóstico) (SId 10)  
2.2.2.4 Positive Response Start Diagnostic (respuesta positiva a la petición de 
inicio de diagnóstico) (SId 50)  
2.2.2.5 Link Control Service (servicio de control del enlace) ( SId 87)  
2.2.2.6 Link Control Positive Response (respuesta positiva al c ontrol del en­ 
lace) (SId C7)  
2.2.2.7 Request Upload (envío de petición) (SId 35)  
2.2.2.8 Positive Response Request Upload (respuesta positiva al  envío de peti­ 
ción) (SId 75)  
2.2.2.9 Transfer Data Request (petición de transferencia de dat os) (SId 36)  
2.2.2.10 Positive Response Transfer Data (respuesta positiva a la petición de 
transferencia de datos) (SId 76)  
2.2.2.11 Request Transfer Exit (petición de salida de la transf erencia) (SId 37)  
2.2.2.12 Positive Response Request Transfer Exit (respuesta pos itiva a la peti­ 
ción de salida de la transferencia) (SId 77)  
2.2.2.13 Stop Communication Request (petición de interrupción d e la comuni­ 
cación) (SId 82)  
2.2.2.14 Positive Response Stop Communication (respuesta positi va a la petición 
de interrupción de la comunicación) (SId C2)  
2.2.2.15 Acknowledge Sub Message (confirmación de submensaje) ( SId 83)  
2.2.2.16 Negative Response (respuesta negativa) (SId 7F)  
2.2.3 Flujo del mensaje  
2.2.4 Sincronización  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 327  
2.2.5 Gestión de errores  
2.2.5.1 Fase de inicio de la comunicación  
2.2.5.2 Fase de comunicación  
2.2.6 Contenido del mensaje de respuesta  
▼M3 
2.2.6.1  Positive Response Transfer Data Download Interface Version  (Res­ 
puesta positiva a la petición de transferencia de datos «Versió n de la 
interfaz de transferencia»)  
2.2.6.2  Positive Response Transfer Data Overview  (Respuesta positiva a la 
petición de transferencia de datos «Visión general»)  
2.2.6.3  Positive Response Transfer Data Activities  (Respuesta positiva a la 
petición de transferencia de datos «Actividades»)  
2.2.6.4  Positive Response Transfer Data Events and Faults  (Respuesta positiva 
a la petición de transferencia de datos «Incidentes y fallos»)  
2.2.6.5  Positive Response Transfer Data Detailed Speed  (Respuesta positiva a 
la petición de transferencia de datos «Datos pormenorizados sob re la 
velocidad»)  
2.2.6.6  Positive Response Transfer Data Technical Data  (Respuesta positiva a 
la petición de transferencia de datos «Datos técnicos»)  
▼B 
2.3. Almacenamiento de un archivo en un ESM  
3. PROTOCOLO DE TRANSFERENCIA DE LOS DATOS ALMACE­ 
NADOS EN TARJETAS DE TACÓGRAFO  
3.1. Ámbito de aplicación  
3.2. Definiciones  
3.3. Transferencia de los datos de la tarjeta  
3.3.1 Secuencia de inicialización  
3.3.2 Secuencia para archivos de datos no firmados  
3.3.3 Secuencia para archivos de datos firmados  
3.3.4 Secuencia para reiniciar el contador del calibrado  
3.4. Formato de almacenamiento de datos  
3.4.1 Introducción  
3.4.2 Formato de archivo  
4. TRANSFERENCIA DE LOS DATOS DE UNA TARJETA DE TACÓ­ 
GRAFO A TRAVÉS DE UNA UNIDAD INSTALADA EN EL VE­ 
HÍCULO.  
1. INTRODUCCIÓN  
En el presente apéndice se especifican los procedimientos que s e deben 
utilizar para llevar a cabo los diferentes tipos de transferenc ia de datos 
a un medio de almacenamiento externo (ESM), así como los protoc olos 
que es preciso aplicar para garantizar la corrección de dichas trans­
ferencias y la total compatibilidad del formato de los datos tr ansferidos, 
a fin de que un controlador cualquiera pueda inspeccionar dicho s datos 
y comprobar su autenticidad e integridad antes de analizarlos.  
▼M1 
1.1. Ámbito de aplicación  
Se pueden transferir datos a un ESM:  
— desde una unidad instalada en el vehículo (VU), mediante un 
equipo dedicado inteligente (IDE) conectado a la VU;  
— desde una tarjeta de tacógrafo, mediante un IDE que incorpore  un 
dispositivo de interfaz de tarjeta (IFD); y  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 328  
— desde una tarjeta de tacógrafo y a través de una unidad insta lada en 
el vehículo, mediante un IDE conectado a la VU.  
Para poder verificar la autenticidad y la integridad de los dat os trans­
feridos que se encuentran almacenados en un ESM, dichos datos s e 
transfieren con una firma añadida según lo dispuesto en el apén dice 11 
(Mecanismos de seguridad comunes). También se transfieren la id en­
tificación del equipo de origen (VU o tarjeta) y sus certificad os de 
seguridad (Estado miembro y equipamiento). La persona encargada  
de verificar los datos debe estar en posesión de una clave públ ica 
europea de confianza.  
Los datos transferidos desde una VU se firman utilizando los me canis­
mos de seguridad comunes del apéndice 11, parte B (Sistema de t acó­
grafo de segunda generación), excepto cuando la supervisión del  con­
ductor la realiza una autoridad de control de un país no perten eciente a 
la UE utilizando una tarjeta de control de primera generación, en cuyo 
caso los datos se firman mediante los mecanismos de seguridad c omu­
nes del apéndice 11, parte A (Sistema de tacógrafo de primera g ene­
ración), tal y como se establece en el requisito MIG_015 del ap éndice 
15 (Migración).  
En el presente apéndice se especifican, por lo tanto, dos tipos  de trans­
ferencias de datos desde la VU:  
— Transferencia de datos desde la VU de generación 2, con la es truc­
tura de datos de segunda generación, firmada utilizando los mec a­
nismos de seguridad comunes del apéndice 11, parte B,  
— Transferencia de datos desde la VU de generación 1, con la es truc­
tura de datos de primera generación, firmada utilizando los mec a­
nismos de seguridad comunes del apéndice 11, parte A.  
Igualmente, existen dos tipos de transferencias de datos desde tarjetas 
de conductor de segunda generación insertadas en una VU, como s e 
especifica en los apartados 3 y 4 del presente apéndice.  
▼B 
1.2. Acrónimos y notaciones  
En el presente apéndice se utilizan los siguientes acrónimos:  
AID Identificador de aplicación  
ATR  Respuesta a reinicio  
CS Byte de la suma de control  
DF Archivo dedicado  
DS Sesión de diagnóstico  
EF Archivo elemental  
ESM  Medio de almacenamiento externo  
FID Identificador de archivo (ID de archivo)  
FMT  Byte de formato (primer byte de la cabecera del mensaje)  
ICC Tarjeta de circuito integrado  
IDE Equipo dedicado inteligente: equipo empleado para realizar la 
transferencia de datos al ESM (por ejemplo un ordenador per­
sonal)  
IFD Dispositivo de interfaz  
KWP  Protocolo Keyword 2000  
LEN  Byte de longitud (el último byte de la cabecera del mensaje)  
PPS Selección de los parámetros de protocolo  
PSO  Realizar operación de seguridad  
SID Identificador de servicio  
SRC  Byte de origen  
TGT  Byte de destino  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 329  
TLV  Valor de longitud de la etiqueta  
TREP  Parámetro de la respuesta a la petición de transferencia  
TRTP  Parámetro de la petición de transferencia  
VU Unidad instalada en el vehículo  
2. TRANSFERENCIA DE LOS DATOS DE LA VU  
2.1. Procedimiento de transferencia  
A fin de realizar una transferencia de los datos de la VU, el o perario 
debe efectuar las siguientes operaciones:  
— introducir su tarjeta de tacógrafo en una ranura de la VU (*) ; 
— conectar el IDE al conector de transferencia de la VU;  
— establecer una conexión entre el IDE y la VU;  
— seleccionar en el IDE los datos que se van a transferir y env iar la 
petición a la VU; y  
— cerrar la sesión de transferencia.  
2.2. Protocolo de transferencia de datos  
El protocolo presenta una estructura maestro-esclavo, de modo q ue el 
IDE actúa como maestro y la VU como esclavo.  
La estructura, los tipos y el flujo de los mensajes se basan pr incipal­
mente en el protocolo Keyword 2000 (KWP) (ISO 14230-2: Vehículo s 
de carretera — Sistemas de diagnóstico — Protocolo Keyword 2000  — 
Parte 2: Nivel de enlace de datos).  
El nivel de aplicación se basa principalmente en el proyecto ac tual de 
la norma ISO 14229-1 (Vehículos de carretera — Sistemas de diag ­
nóstico — Parte 1: Servicios de diagnóstico, versión 6 de 22 de  febrero 
de 2001).  
2.2.1  Estructura del mensaje  
DDP_002 El formato de todos los mensajes que intercambian el ID E y 
la VU presenta una estructura de tres partes:  
— una cabecera compuesta por un byte de formato (FMT), 
un byte de destino (TGT), un byte de origen (SRC) y 
posiblemente un byte de longitud (LEN);  
— un campo de datos compuesto por un byte identificador 
de servicio (SId) y un número variable de bytes de 
datos, que puede incluir un byte opcional de sesión de 
diagnóstico (DS_) o un byte opcional de parámetro de 
transferencia (TRTP o TREP); y  
— una suma de control consistente en un byte de suma de 
control (CS).  
Cabecera  Campo de datos  Suma de control  
FMT  TGT  SRC  LEN  SId  DA­
TOS  … …  …  C S  
4 bytes  Máx. 255 bytes  1 byte  
Los bytes TGT y SRC representan la dirección física del 
destinatario y del emisor del mensaje. Los valores son F0 
Hex para el IDE y EE Hex para la VU.  
El byte LEN es la longitud de la parte correspondiente al 
campo de datos.  ▼B 
(*) La tarjeta introducida activará los correspondientes derech os de acceso a la función de 
transferencia y a los datos. No obstante, se podrán transferir los datos almacenados en 
una tarjeta de conductor introducida en una de las ranuras de l a VU siempre que no haya 
otro tipo de tarjeta en la otra ranura.
 02016R0799 — ES — 21.08.2023 — 003.001 — 330  
El byte de suma de control es la suma de todos los bytes del 
mensaje tomados de 8 bits en 8 bits, en módulo 256, ex­
cluido el propio CS.  
Los bytes FMT, SId, DS, TRTP y TREP se definen más 
adelante en este mismo documento.  
DDP_003 Cuando la longitud de los datos que deba incluir el men saje 
es mayor que el espacio disponible en la parte correspon­
diente al campo de datos, el mensaje se envía dividido en 
varios submensajes. Cada submensaje incorpora una cabe­
cera, los mismos SId y TREP y un contador de dos bytes 
que indica el número de submensaje dentro del mensaje 
total. Al objeto de permitir la verificación de errores y la 
cancelación, el IDE confirma cada uno de los submensajes. 
El IDE puede aceptar el submensaje, solicitar su retrans­
misión, pedir a la VU que comience de nuevo o cancelar 
la transmisión.  
DDP_004 Si el último submensaje contiene exactamente 255 bytes en 
el campo de datos, habrá que añadir un submensaje final 
con un campo de datos vacío (exceptuando los identificado­
res SId y TREP y el contador de submensaje) para indicar el 
final del mensaje.  
Ejemplo:  
Cabecera  SId  TREP  Mensaje  C S  
4 bytes  Más de 255 bytes  
Se transmitirá como:  
Cabecera  SId  TREP  0 0  0 1  Submensaje 1  C S  
4 bytes  255 bytes  
Cabecera  SId  TREP  0 0  0 2  Submensaje 2  C S  
4 bytes  255 bytes  
… 
Cabecera  SId  TREP  x x  y y  Submensaje n  C S  
4 bytes  Menos de 255 bytes  
o bien como:  
Cabecera  SId  TREP  0 0  0 1  Submensaje 1  C S  
4 bytes  255 bytes  
Cabecera  SId  TREP  0 0  0 2  Submensaje 2  C S  
4 bytes  255 bytes  
… 
Cabecera  SId  TREP  x x  y y  Submensaje n  C S  
4 bytes  255 bytes  
Cabecera  SId  TREP  x x  yy + 1  C S  
4 bytes  4 bytes  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 331  
2.2.2  Tipos de mensajes  
El protocolo de comunicación para la transferencia de datos ent re la 
VU y el IDE exige el intercambio de ocho tipos de mensajes dife rentes.  
La siguiente tabla resume dichos mensajes.  
▼M3 
Estructura del mensaje:  Máx. 4 bytes  Máx. 255 bytes  1 byte  
Cabecera  Datos  Suma de 
control  
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DATA  C S  
Petición de inicio de comunicación  8 1  E E  F 0  8 1  E 0  
Respuesta positiva a la petición de 
inicio de comunicación  80 F 0  E E  0 3  C 1  EA, 8F  9 B  
Petición de inicio de la sesión de diag­
nóstico  80 E E  F 0  0 2  1 0  8 1  F 1  
Respuesta positiva a la petición de 
inicio de diagnóstico  80 F 0  E E  0 2  5 0  8 1  3 1  
Servicio de control del enlace  
Verificar la velocidad en baudios 
(fase 1)  
9 600 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,01  E C  
19 200 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,02  E D  
38 400 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,03  E E  
57 600 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,04  E F  
115 200 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,05  F 0  
Respuesta positiva a la petición de 
verificar la velocidad en baudios  80 F 0  E E  0 2  C 7  0 1  2 8  
Velocidad de transición en baudios 
(fase 2)  80 E E  F 0  0 3  8 7  0 2  0 3  E D  
Envío de petición  8 0  E E  F 0  0 A  3 5  00,00,00,00­
,00,FF,FF,F­
F,FF  99 
Respuesta positiva al envío de petición  8 0  F 0  E E  0 3  7 5  00,FF  D 5  
Petición de transferencia de datos  
Versión de la interfaz de trans­
ferencia  80 E E  F 0  0 2  3 6  0 0  9 6  
Visión General  80 E E  F 0  0 2  3 6  01, 21 o 31  C S  
Actividades  80 E E  F 0  0 6  3 6  02, 22 o 32  Fecha  C S  
Incidentes y fallos  80 E E  F 0  0 2  3 6  03, 23 o 33  Fecha  C S  
Datos pormenorizados sobre la ve­
locidad  80 E E  F 0  0 2  3 6  04 o 24  Fecha  C S  
Datos técnicos  80 E E  F 0  0 2  3 6  05, 25 o 35  Fecha  C S  
Transferencia de los datos de la 
tarjeta  80 E E  F 0  02 o 03  3 6  0 6  Ranura  C S  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 332  
Estructura del mensaje:  Máx. 4 bytes  Máx. 255 bytes  1 byte  
Cabecera  Datos  Suma de 
control  
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DATA  C S  
Respuesta positiva a la petición de 
transferencia de datos  80 F 0  E E  Len  7 6  TREP  Datos  C S  
Petición de salida de la transferencia  8 0  E E  F 0  0 1  3 7  9 6  
Respuesta positiva a la petición de 
salida de la transferencia  80 F 0  E E  0 1  7 7  D 6  
Petición de interrupción de la comuni­
cación  80 E E  F 0  0 1  8 2  E 1  
Respuesta positiva a la petición de 
interrupción de la comunicación  80 F 0  E E  0 1  C 2  2 1  
Confirmación de submensaje  8 0  E E  F 0  Len  8 3  Datos  C S  
Respuestas negativas  
Denegación general  8 0  F 0  E E  0 3  7 F  SID pet.  1 0  C S  
Servicio no admitido  8 0  F 0  E E  0 3  7 F  SID pet.  1 1  C S  
Subfunción no admitida  8 0  F 0  E E  0 3  7 F  SID pet.  1 2  C S  
Longitud del mensaje incorrecta  8 0  F 0  E E  0 3  7 F  SID pet.  1 3  C S  
Condiciones incorrectas o error en la 
secuencia de la petición  80 F 0  E E  0 3  7 F  SID pet.  2 2  C S  
Petición no admisible  8 0  F 0  E E  0 3  7 F  SID pet.  3 1  C S  
Envío no aceptado  8 0  F 0  E E  0 3  7 F  SID pet.  5 0  C S  
Falta respuesta  8 0  F 0  E E  0 3  7 F  SID pet.  7 8  C S  
Datos no disponibles  8 0  F 0  E E  0 3  7 F  SID pet.  F A  C S  
Notas:  
— SID pet. = el SID de la petición correspondiente.  
— TREP = el TRTP de la petición correspondiente.  
— Las casillas en negro significan que no se transmite ningún d ato. 
— El término envío (entendido desde el IDE) se utiliza para com pa­
tibilidad con la norma ISO 14229. Significa lo mismo que trans­
ferencia (entendida desde la VU).  
— Los posibles contadores de submensaje de dos bytes no aparece n en 
la tabla.  
— El valor «ranura» se corresponde con el número de la ranura, que 
puede ser «1» (tarjeta de la ranura del conductor) o «2» (tarje ta de 
la ranura del segundo conductor).  
— En caso de que no se especifique la ranura, la VU seleccionar á la 
ranura 1 si la tarjeta se inserta en esta ranura, y solamente s elec­
cionará la ranura 2 si la selecciona específicamente el usuario . ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 333  
— El TRTP 24 se utiliza para las peticiones de transferencia de  datos 
de VU de segunda generación, versiones 1 y 2.  
— Los TRTP 00, 31, 32, 33 y 35 se utilizan para las peticiones de 
transferencia de datos de VU de segunda generación, versión 2.  
— Los TRTP 21, 22, 23 y 25 se utilizan para las peticiones de t rans­
ferencia de datos de VU de segunda generación, versión 1.  
— Los TRTP 01 a 05 se utilizan para las peticiones de transfere ncia 
de datos de VU de primera generación. Opcionalmente pueden ser 
aceptadas por VU de segunda generación, pero solo en el marco d el 
control de conductores realizado por una autoridad de control d e 
fuera de la UE, utilizando una tarjeta de control de primera ge ne­
ración.  
— Los TRTP 11 a 1F se reservan para peticiones de transferencia  
específicas de los fabricantes.  
▼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 ( p e  t i c i ó n d e i n i c i o 
d e c o m u n i c a c i ó n ) ( S I d 8 1 )  
DDP_005 El IDE envía este mensaje para establecer el enlace de 
comunicación con la VU. Las comunicaciones iniciales se 
hacen siempre a 9 600 baudios (hasta que la velocidad en 
baudios se cambia utilizando los servicios adecuados de 
control del enlace).  
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 ( r e s ­
p u e s t a p o s i t i v a a l a p e t i c i ó n d e i n i c i  o d e c o m u n i ­
c a c i ó n ) ( S I d C 1 )  
DDP_006 La VU envía este mensaje para responder positivamente a  
una petición de inicio de comunicación. Incluye los dos 
bytes de clave EA y 8F, indicativos de que la unidad admite 
un protocolo con una cabecera que incluya información 
sobre el destino, el origen y la longitud del mensaje.  
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 ( p e t i c i ó n d e i n i ­
c i o d e l a s e s i ó n d e d i a g n ó s t i c o ) ( S I d 1  0 ) 
DDP_007 El IDE envía el mensaje de petición de inicio de la ses ión 
de diagnóstico para solicitar una nueva sesión de diagnós­
tico con la VU. La subfunción «sesión por defecto» ( default 
session ) (81 Hex) indica que va a abrirse una sesión de 
diagnóstico estándar.  
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 ( r e s p u e s t a p o ­
s i t i v a a l a p e t i c i ó n d e i n i c i o d e d i a g n  ó s t i c o ) ( S I d 
5 0 ) 
DDP_008 La VU envía el mensaje de respuesta positiva a la petic ión 
de inicio de diagnóstico para responder positivamente a la 
solicitud de sesión de diagnóstico.  
2.2.2.5 L i n k C o n t r o l S e r v i c e ( s e r v i c i o d  e c o n t r o l d e l e n ­
l a c e ) ( S I d 8 7 )  
DDP_052 El IDE utiliza el servicio de control del enlace para i niciar 
un cambio en la velocidad en baudios. Este cambio se lleva 
a cabo en dos etapas. En la primera, el IDE propone el 
cambio en la velocidad en baudios, indicando la nueva ve­
locidad. Al recibir un mensaje positivo de la VU, el IDE 
envía a la VU una confirmación del cambio en la velocidad 
en baudios (etapa 2). A continuación, el IDE cambia a la 
nueva velocidad en baudios. Tras recibir la confirmación la 
VU, cambia a la nueva velocidad en baudios.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 334  
2.2.2.6 L i n k C o n t r o l P o s i t i v e R e s p o n s e (  r e s p u e s t a p o s i ­
t i v a a l c o n t r o l d e l e n l a c e ) ( S I d C 7 )  
DDP_053 La VU envía la respuesta positiva al control del enlace  para 
contestar positivamente a la petición de servicio del control 
del enlace (etapa 1). Téngase en cuenta que no se da res­
puesta a la solicitud de confirmación (etapa 2).  
2.2.2.7 R e q u e s t U p l o a d ( e n v í o d e p e t i c i ó  n ) ( S I d 3 5 )  
DDP_009 El IDE emite el mensaje de envío de petición para espec i­
ficar a la VU que se solicita una operación de transferencia. 
Para cumplir los requisitos de la norma ISO 14229, se in­
cluyen entre los datos la dirección, el tamaño y el formato 
de los datos solicitados. Dado que el IDE no los conoce 
antes de la transferencia, la dirección de la memoria se 
configura a 0, el formato está descifrado y descomprimido 
y el tamaño de la memoria se fija en el máximo.  
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 ( r e s p u e s t a p o ­
s i t i v a a l e n v í o d e p e t i c i ó n ) ( S I d 7 5 )  
DDP_010 La VU envía el mensaje de respuesta positiva al envío d e 
petición para indicar al IDE que la VU está preparada para 
transferir datos. Para cumplir los requisitos de la norma ISO 
14229, en este mensaje de respuesta positiva se incluyen 
datos, indicando al IDE que los ulteriores mensajes de res­
puesta positiva a la transferencia de datos incluirán un má­
ximo de 00FF hex bytes.  
2.2.2.9 T r a n s f e r D a t a R e q u e s t ( p e t i c i ó n  d e t r a n s f e r e n c i a 
d e d a t o s ) ( S I d 3 6 )  
▼M1 
DDP_011 El IDE envía la petición de transferencia de datos para  
especificar a la VU el tipo de datos que se van a transferir. 
Un parámetro de petición de transferencia (TRTP) de un 
byte indica el tipo de transferencia.  
▼M3 
Existen siete tipos de transferencias de datos. Para la trans­
ferencia de datos desde la VU se pueden utilizar dos valores 
de TRTP distintos para cada tipo de transferencia:  
Tipo de transferencia de datos  Valor del TRTP para la trans­
ferencia de datos desde VU 
de primera generación  Valor del TRTP para la trans­
ferencia de datos desde VU 
de segunda generación, ver­
sión 1  Valor del TRTP para la trans­
ferencia de datos desde VU 
de segunda generación, ver­
sión 2  
Versión de la interfaz de 
transferencia  No se utiliza  No se utiliza  0 0  
Visión General  0 1  2 1  3 1  
Actividades de una fecha es­
pecífica  02 2 2  3 2  
Incidentes y fallos  0 3  2 3  3 3  
Datos pormenorizados sobre 
la velocidad  04 2 4  2 4  
Datos técnicos  0 5  2 5  3 5  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 335  
Tipo de trans­
ferencia de datos  Valor del TRTP  
Transferencia de 
los datos de la 
tarjeta  06 
▼M3 
DDP_054 Es obligatorio que el IDE solicite la transferencia de datos 
«Visión general» (TRTP 01, 21 o 31) durante una sesión de 
transferencia, ya que solo así se asegura que los certificados 
de la VU se registren en el archivo transferido (y se permite 
la verificación de la firma digital).  
En el segundo caso (TRTP 02, 22 o 32), el mensaje de petición d e 
transferencia de datos incluye la indicación del día civil (en formato 
TimeReal) cuyos datos se van a transferir.  
▼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 ( r e s p u e s t a p o s i ­
t i v a a l a p e t i c i ó n d e t r a n s f e r e n c i a d e  d a t o s ) ( S I d 
7 6 ) 
DDP_012 La VU envía la respuesta positiva a la petición de tran s­
ferencia de datos como contestación a la petición de trans­
ferencia de datos. Este mensaje contiene los datos solicita­
dos, junto con un parámetro de respuesta a la solicitud de 
transferencia (TREP) correspondiente al TRTP de la peti­
ción. 
▼M3 
DDP_055 En el primer caso (TREP 01, 21 o 31), la VU enviará dat os 
que ayudan al operario del IDE a seleccionar los datos que 
quiere transferir. La información contenida en este mensaje 
es la siguiente:  
▼M1 
— certificados de seguridad;  
— identificación del vehículo;  
— fecha y hora actuales de la VU;  
— fecha máxima y mínima transferible (datos de la VU);  
— indicación de presencia de tarjetas en la VU;  
— transferencia previa a una empresa;  
— bloqueos introducidos por empresas; e  
— inspecciones anteriores.  
▼B 
2.2.2.11 R e q u e s t T r a n s f e r E x i t ( p e t i c i ó n d e s a l i d a d e l a 
t r a n s f e r e n c i a ) ( S I d 3 7 )  
DDP_013 El IDE envía el mensaje de petición de salida de la tra ns­
ferencia para informar a la VU de que la sesión de trans­
ferencia ha terminado.  
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 ( r e s ­
p u e s t a p o s i t i v a a l a p e t i c i ó n d e s a l i d  a d e l a t r a n s ­
f e r e n c i a ) ( S I d 7 7 )  
DDP_014 La VU envía el mensaje de respuesta positiva a la petic ión 
de salida de la transferencia para confirmar la petición de 
salida de la transferencia.  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 336  
2.2.2.13 S t o p C o m m u n i c a t i o n R e q u e s t ( p e t i c i ó n d e i n t e ­
r r u p c i ó n d e l a c o m u n i c a c i ó n ) ( S I d 8 2 )  
DDP_015 El IDE envía el mensaje de petición de interrupción de la 
comunicación para desconectar el enlace de comunicación 
con la 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 ( r e s p u e s t a 
p o s i t i v a a l a p e t i c i ó n d e i n t e r r u p c i ó  n d e l a c o m u ­
n i c a c i ó n ) ( S I d C 2 )  
DDP_016 La VU envía el mensaje de respuesta positiva a la petic ión 
de interrupción de la comunicación para confirmar la peti­
ción de interrupción de la comunicación.  
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 ( c o n f i r m a c i ó n d e s u b ­
m e n s a j e ) ( S I d 8 3 )  
DDP_017 El IDE envía el mensaje de confirmación de submensaje 
para confirmar la recepción de cada una de las partes de 
un mensaje que se transmiten como diversos submensajes. 
El campo de datos contiene el SId recibido de la VU y un 
código de dos bytes que se interpreta de la manera 
siguiente:  
— MsgC +1 confirma la correcta recepción del submensaje 
número MsgC.  
El IDE solicita a la VU que envíe el siguiente 
submensaje.  
— MsgC indica un problema en la recepción del submen­
saje número MsgC.  
El IDE solicita a la VU que vuelva a enviar el 
submensaje.  
— FFFF solicita la terminación del mensaje.  
El IDE puede utilizar este código para terminar la trans­
misión del mensaje de la VU por el motivo que fuera.  
El último submensaje de un mensaje (byte LEN < 255) se 
puede confirmar con cualquiera de estos códigos, o bien 
puede dejarse sin confirmar.  
Respuestas de la VU que se componen de varios 
submensajes:  
— Positive Response Transfer Data (respuesta positiva a la 
petición de transferencia de datos) (SId 76)  
2.2.2.16 N e g a t i v e R e s p o n s e ( r e s p u e s t a n e g a t i v a ) ( S I d 7 F )  
DDP_018 La VU envía el mensaje de respuesta negativa como con­
testación a los mensajes de petición anteriores cuando no 
puede satisfacer la petición de que se trate. Los campos de 
datos del mensaje incluyen el SId de la respuesta (7F), el 
SId de la petición y un código que especifica el motivo de 
la respuesta negativa. Están disponibles los códigos 
siguientes:  
— 10: rechazo general  
La acción solicitada no se puede llevar a cabo por un 
motivo distinto de los enumerados a continuación.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 337  
— 11: servicio no admitido  
No se entiende el SId de la petición.  
— 12: subfunción no admitida  
No se entiende el DS_ o el TRTP de la petición, o bien 
no hay más submensajes que transmitir.  
— 13: longitud del mensaje incorrecta  
La longitud del mensaje es incorrecta.  
— 22: condiciones incorrectas o error en la secuencia de la 
petición  
El servicio requerido no está activo o la secuencia de 
mensajes de petición es incorrecta.  
— 31: solicitud no admisible  
El registro del parámetro de la solicitud (campo de da­
tos) no es válido.  
— 50: envío no aceptado  
No se puede llevar a cabo la petición (la VU se encuen­
tra en un modo de funcionamiento inadecuado o tiene 
un fallo interno).  
— 78: falta respuesta  
La acción solicitada no se puede llevar a cabo a tiempo 
y la VU no está preparada para aceptar otra petición.  
▼M1 
— FA: datos no disponibles  
El objeto de datos de una petición de transferencia de 
datos no está disponible en la VU (por ejemplo, no se ha 
introducido una tarjeta, o se solicita una transferencia de 
datos desde una VU de primera generación fuera del 
marco de la supervisión del conductor realizada por 
una autoridad de control de un país no perteneciente a 
la UE).  
▼B 
2.2.3  Flujo del mensaje  
A continuación se describe el flujo normal de un mensaje durant e un 
procedimiento normal de transferencia de datos:  
IDE V U  
Petición de inicio de comunicación  ⇨ 
⇦  Respuesta positiva  
Petición de inicio del servicio de diagnóstico  ⇨ 
⇦  Respuesta positiva  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 338  
IDE V U  
Envío de petición  ⇨ 
⇦  Respuesta positiva  
Resumen de peticiones de transferencia 
de datos  ⇨ 
⇦  Respuesta positiva  
Petición de transferencia de datos n  o 2 ⇨ 
⇦  Respuesta positiva n  o 1 
Confirmación de submensaje n  o 1 ⇨ 
⇦  Respuesta positiva n  o 2 
Confirmación de submensaje n  o 2 ⇨ 
⇦  Respuesta positiva n  o m 
Confirmación de submensaje n  o m ⇨ 
⇦  Respuesta positiva (Campo de datos < 255 
bytes)  
Confirmación de submensaje (opcional)  ⇨  
… 
Petición de transferencia de datos n  o n ⇨ 
⇦  Respuesta positiva  
Petición de salida de la transferencia  ⇨ 
⇦  Respuesta positiva  
Petición de interrupción de la comunicación  ⇨ 
⇦  Respuesta positiva  
2.2.4  Sincronización  
DDP_019 Los parámetros de sincronización que aparecen en el grá fico 
siguiente son importantes durante el funcionamiento normal:  
Gráfico 1  
Flujo del mensaje, sincronización
  
Donde:  
P1 = tiempo entre dos bytes en la respuesta de la VU.  
P2 = tiempo transcurrido desde el final de la petición del 
IDE hasta el comienzo de la respuesta de la VU, o 
desde el final de la confirmación del IDE hasta el 
comienzo de la siguiente respuesta de la VU.  
P3 = tiempo transcurrido desde el final de la respuesta de 
la VU hasta el comienzo de una nueva petición del 
IDE, o desde el final de la respuesta de la VU hasta 
el principio de la confirmación del IDE, o desde el 
final de la petición del IDE hasta el comienzo de una 
nueva petición del IDE si la VU no responde.  
P4 = tiempo entre dos bytes en la petición del IDE.  
P5 = valor ampliado de P3 para la transferencia de los 
datos de la tarjeta.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 339  
La siguiente tabla muestra los valores admisibles para los 
parámetros de sincronización (conjunto de parámetros de 
sincronización ampliados KWP, empleado en caso de direc­
cionamiento físico para lograr una comunicación más rá­
pida).  
Sincronización Parámetro  Límite inferior 
Valor (ms)  Límite superior 
Valor (ms)  
P1 0  2 0  
P2 2 0  1 000 (*)  
P3 1 0  5 000  
P4 5  2 0  
P5 1 0  20 minutos  
(*) Si la VU envía una respuesta negativa con un código que sig nifique «petición recibida correctamente, 
pendiente de respuesta», este valor se amplía hasta el mismo va lor límite máximo de P3.  
2.2.5  Gestión de errores  
Si se produce un error durante el intercambio de mensajes, el e squema 
de flujo del mensaje se modifica en función de qué equipo haya de­
tectado el error y de qué mensaje haya generado el error.  
Los gráficos 2 y 3 muestran los procedimientos de gestión de er rores 
de la VU y del IDE, respectivamente.  
2.2.5.1 F a s e d e i n i c i o d e l a c o m u n i c a c i ó n  
DDP_020 Si el IDE detecta un error durante la fase de inicio de  la 
comunicación, ya sea debido a la sincronización o a la 
corriente de bits, esperará durante un período P3 mín. antes 
de enviar de nuevo la petición.  
DDP_021 Si la VU detecta un error en la secuencia procedente de l 
IDE, no enviará respuesta y esperará durante un período P3 
máx. para recibir otro mensaje de petición de inicio de 
comunicación.  
2.2.5.2 F a s e d e c o m u n i c a c i ó n  
Se pueden definir dos zonas distintas de gestión de errores:  
1. La VU detecta un error en la transmisión del IDE  
DDP_022 Para cada mensaje que reciba, la VU buscará errores de 
sincronización, errores de formato de byte (por ejemplo, 
violaciones de los bits de inicio y de paro) y errores de 
trama (número de bytes recibidos incorrecto, byte de la 
suma de control incorrecto).  
DDP_023 Si la VU detecta uno de los errores anteriores, no enví a 
respuesta ni hace caso del mensaje recibido.  
DDP_024 La VU puede detectar otros errores en el formato o en e l 
contenido del mensaje recibido (por ejemplo, tipo de 
mensaje inadmisible), aunque el mensaje cumpla los re­
quisitos en cuanto a longitud y suma de control. En tal 
caso, la VU deberá contestar al IDE con un mensaje de 
respuesta negativa que especifique la naturaleza del error. 
(NOTA: el siguiente organigrama no debe traducirse, ni 
tampoco los que figuran en las próximas páginas).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 340  
Gráfico 2:  
Gestión de errores de la VU
  
▼B 
2. EL IDE DETECTA UN ERROR EN LA TRANSMISIÓN DE 
LA VU  
DDP_025 Para cada mensaje que reciba, el IDE buscará errores de  
sincronización, errores de formato de byte (por ejemplo, 
violaciones de los bits de inicio y de paro) y errores de 
trama (número de bytes recibidos incorrecto, byte de la 
suma de control incorrecto).  
DDP_026 El IDE deberá detectar errores de secuencia; es decir, 
errores en los incrementos del contador de submensajes 
en mensajes sucesivos.  
DDP_027 Si el IDE detecta un error o transcurre el período P2má x. 
sin que se haya recibido contestación de la VU, el men­
saje de petición se envía de nuevo hasta un máximo de 
tres transmisiones en total. A efectos de esta detección de 
errores, una confirmación de submensaje se considerará 
como petición a la VU.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 341  
DDP_028 El IDE deberá esperar durante al menos un período 
P3mín. antes de comenzar cada transmisión; el período 
de espera se medirá a partir del momento de ocurrencia 
del último bit de paro calculado después de haberse de­
tectado el error.  
Gráfico 3  
Gestión de errores del IDE
  
2.2.6  Contenido del mensaje de respuesta  
En este apartado se especifica el contenido de los campos de da tos 
incluidos en los diferentes mensajes de respuesta positiva.  
Los elementos de datos se definen en el apéndice 1 (Diccionario  de 
datos).  
Observaciones: En el caso de las transferencias de segunda gene ración, 
cada elemento de datos de primer nivel está representado por un  con­
junto de registros, incluso si solo contiene un registro. Los c onjuntos de 
registros empiezan con una cabecera, que contiene el tipo de re gistro, el 
tamaño del registro y el número de registros. En las tablas rec ogidas a 
continuación se denomina a los conjuntos de registros como «… R e­
cordArray» (con cabecera).  
▼M3 
2.2.6.1  Positive Response Transfer Data Download Interface Version  (Res­
puesta positiva a la petición de transferencia de datos «Versió n de la 
interfaz de transferencia»)  
DDP_028a El campo de datos del mensaje  Positive Response Transfer 
Data Download Interface Version  proporcionará los datos 
siguientes en el siguiente orden, con el SID 76 Hex y el 
TREP 00:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 342  
Estructura de datos de segunda generación, versión 2 (TREP 00 H ex) 
Elemento de datos  Observaciones  
DownloadInterfaceVersion  Generación y versión de la VU: 02,02 Hex para 
la segunda generación, versión 2. 
No compatible con VU de primera generación y 
de segunda generación, versión 1, que responde­
rán negativamente (subfunción no compatible, 
véase DDP_018)  
2.2.6.2  Positive Response Transfer Data Overview  (Respuesta positiva a la 
petición de transferencia de datos «Visión general»)  
DDP_029 El campo de datos del mensaje  Positive Response Trans ­
fer Data Overview  proporcionará los datos siguientes en el 
siguiente orden, con el SID 76 Hex, el TREP 01, 21 o 31 
Hex y el método adecuado de división y recuento de 
submensajes:  
Estructura de datos de primera generación (TREP 01 Hex)  
Elemento de datos  Observaciones  
MemberStateCertificate  Certificados de seguridad de la VU  
VUCertificate  
VehicleIdentificationNumber  Identificación del vehículo  
VehicleRegistrationIdentification  
CurrentDateTime  Fecha y hora actuales de la VU  
VuDownloadablePeriod  Período transferible  
CardSlotsStatus  Tipo de tarjetas insertadas en la VU  
VuDownloadActivityData  Transferencia previa de la VU  
VuCompanyLocksData  Todos los bloqueos introducidos por empresas 
almacenados. Si esta sección está vacía, única­
mente se envía el mensaje noOfLocks = 0.  
VuControlActivityData  Todos los registros de control almacenados en la 
VU. Si esta sección está vacía, únicamente se 
envía el mensaje noOfControls = 0.  
Signature  Firma RSA de todos los datos (excepto los certi­
ficados) desde VehicleIdentificationNumber hasta 
el último byte del último VuControlActivityData.  
Estructura de datos de segunda generación, versión 1 (TREP 21 H ex) 
Elemento de datos  Observaciones  
MemberStateCertificateRecordArray  Certificado del Estado miembro  
VUCertificateRecordArray  Certificado de la VU  
VehicleIdentificationNumberRecordArray  Identificación del vehículo  ▼M3
02016R0799 — ES — 21.08.2023 — 003.001 — 343  
Elemento de datos  Observaciones  
VehicleRegistrationIdentificationRecordArray  Matrícula del vehículo  
CurrentDateTimeRecordArray  Fecha y hora actuales de la VU  
VuDownloadablePeriodRecordArray  Período transferible  
CardSlotsStatusRecordArray  Tipo de tarjetas insertadas en la VU  
VuDownloadActivityDataRecordArray  Transferencia previa de la VU  
VuCompanyLocksRecordArray  Todos los bloqueos introducidos por empresas 
almacenados. Si esta sección está vacía, se envía 
una cabecera de conjunto con el mensaje noO­
fRecords = 0.  
VuControlActivityRecordArray  Todos los registros de control almacenados en la 
VU. Si esta sección está vacía, se envía una ca­
becera de conjunto con el mensaje noOfRecords = 
0. 
SignatureRecordArray  La firma ECC de todos los datos anteriores, ex­
cepto los certificados.  
Estructura de datos de segunda generación, versión 2 (TREP 31 H ex) 
Elemento de datos  Observaciones  
MemberStateCertificateRecordArray  Certificado del Estado miembro  
VUCertificateRecordArray  Certificado de la VU  
VehicleIdentificationNumberRecordArray  Identificación del vehículo  
VehicleRegistrationNumberRecordArray  Matrícula del vehículo  
CurrentDateTimeRecordArray  Fecha y hora actuales de la VU  
VuDownloadablePeriodRecordArray  Período transferible  
CardSlotsStatusRecordArray  Tipo de tarjetas insertadas en la VU  
VuDownloadActivityDataRecordArray  Transferencia previa de la VU  
VuCompanyLocksRecordArray  Todos los bloqueos introducidos por empresas 
almacenados. Si esta sección está vacía, se envía 
una cabecera de conjunto con el mensaje noO­
fRecords = 0.  
VuControlActivityRecordArray  Todos los registros de control almacenados en la 
VU. Si esta sección está vacía, se envía una ca­
becera de conjunto con el mensaje noOfRecords = 
0. 
SignatureRecordArray  La firma ECC de todos los datos anteriores, ex­
cepto los certificados.  
2.2.6.3  Positive Response Transfer Data Activities  (Respuesta positiva a la 
petición de transferencia de datos «Actividades»)  
DDP_030 El campo de datos del mensaje  Positive Response Trans ­
fer Data Activities  proporcionará los datos siguientes en el 
siguiente orden, con el SID 76 Hex, el TREP 02, 22 o 32 
Hex y el método adecuado de división y recuento de 
submensajes:  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 344  
Estructura de datos de primera generación (TREP 02 Hex)  
Elemento de datos  Observaciones  
TimeReal  Fecha del día transferido  
OdometerValueMidnight  Odómetro al final del día transmitido  
VuCardIWData  Datos de los ciclos de inserción y extracción de las 
tarjetas. 
— Si esta sección no contiene datos disponibles, úni­
camente se envía el mensaje noOfVuCardIWRe­
cords = 0. 
— Cuando un VuCardIWRecord se encuentra en 00:00 
(inserción de la tarjeta el día anterior) o en 24:00 
(extracción de la tarjeta al día siguiente) figurará 
por completo en ambos días.  
VuActivityDailyData  Estado de las ranuras a las 00:00 y cambios de actividad 
registrados en el día transferido.  
VuPlaceDailyWorkPeriodData  Datos relacionados con lugares registrados en el día 
transferido. Si esta sección está vacía, únicamente se 
envía el mensaje noOfPlaceRecords = 0.  
VuSpecificConditionData  Datos sobre condiciones específicas registrados en el día 
transferido. Si esta sección está vacía, únicamente se 
envía el mensaje noOfSpecificConditionRecords = 0.  
Signature  Firma RSA de todos los datos desde TimeReal hasta el 
último byte del último registro de condiciones específi­
cas. 
Estructura de datos de segunda generación, versión 1 (TREP 22 H ex) 
Elemento de datos  Observaciones  
DateOfDayDownloadedRecordArray  Fecha del día transferido  
OdometerValueMidnightRecordArray  Odómetro al final del día transmitido  
VuCardIWRecordArray  Datos de los ciclos de inserción y extracción de las 
tarjetas. 
— Si esta sección no contiene datos disponibles, se 
envía una cabecera de conjunto con el mensaje 
noOfRecords = 0. 
— Cuando un VuCardIWRecord se encuentra en 00:00 
(inserción de la tarjeta el día anterior) o en 24:00 
(extracción de la tarjeta al día siguiente) figurará 
por completo en ambos días.  
VuActivityDailyRecordArray  Estado de las ranuras a las 00:00 y cambios de actividad 
registrados en el día transferido.  
VuPlaceDailyWorkPeriodRecordArray  Datos relacionados con lugares registrados en el día 
transferido. Si esta sección está vacía, se envía una 
cabecera de conjunto con el mensaje noOfRecords = 0.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 345  
Elemento de datos  Observaciones  
VuGNSSADRecordArray  Posiciones GNSS del vehículo si el tiempo de conduc­
ción acumulado del vehículo alcanza un múltiplo de tres 
horas. Si esta sección está vacía, se envía una cabecera 
de conjunto con el mensaje noOfRecords = 0.  
VuSpecificConditionRecordArray  Datos sobre condiciones específicas registrados en el día 
transferido. Si esta sección está vacía, se envía una 
cabecera de conjunto con el mensaje noOfRecords = 0.  
SignatureRecordArray  La firma ECC de todos los datos anteriores.  
Estructura de datos de segunda generación, versión 2 (TREP 32 H ex) 
Elemento de datos  Observaciones  
DateOfDayDownloadedRecordArray  Fecha del día transferido  
OdometerValueMidnightRecordArray  Odómetro al final del día transmitido  
VuCardIWRecordArray  Datos de los ciclos de inserción y extracción de las 
tarjetas. 
— Si esta sección no contiene datos disponibles, se 
envía una cabecera de conjunto con el mensaje 
noOfRecords = 0. 
— Cuando un VuCardIWRecord se encuentra en 00:00 
(inserción de la tarjeta el día anterior) o en 24:00 
(extracción de la tarjeta al día siguiente) figurará 
por completo en ambos días.  
VuActivityDailyRecordArray  Estado de las ranuras a las 00:00 y cambios de actividad 
registrados en el día transferido.  
VuPlaceDailyWorkPeriodRecordArray  Datos relacionados con lugares registrados en el día 
transferido. Si esta sección está vacía, se envía una 
cabecera de conjunto con el mensaje noOfRecords = 0.  
VuGNSSADRecordArray  Posiciones GNSS del vehículo si el tiempo de conduc­
ción acumulado del vehículo alcanza un múltiplo de tres 
horas. Si esta sección está vacía, se envía una cabecera 
de conjunto con el mensaje noOfRecords = 0.  
VuSpecificConditionRecordArray  Datos sobre condiciones específicas registrados en el día 
transferido. Si esta sección está vacía, se envía una 
cabecera de conjunto con el mensaje noOfRecords = 0.  
VuBorderCrossingRecordArray  Cruces de fronteras en el día transferido. Si esta 
sección está vacía, se envía una cabecera de conjunto 
con el mensaje noOfRecords = 0.  
VuLoadUnloadRecordArray  Operaciones de carga/descarga en el día transferido. Si 
esta sección está vacía, se envía una cabecera de con­
junto con el mensaje noOfRecords = 0.  
SignatureRecordArray  La firma ECC de todos los datos anteriores.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 346  
2.2.6.4 P o s i t i v e R e s p o n s e T r a n s f e r D a t a  E v e n t s a n d F a u l t s 
( R e s p u e s t a p o s i t i v a a l a p e t i c i ó n d e t  r a n s f e r e n c i a 
d e d a t o s « I n c i d e n t e s y f a l l o s » )  
DDP_031 El campo de datos del mensaje  Positive Response Trans ­
fer Data Events and Faults  proporcionará los datos si­
guientes en el siguiente orden, con el SID 76 Hex, el 
TREP 03, 23 o 33 Hex y el método adecuado de división 
y recuento de submensajes:  
Estructura de datos de primera generación (TREP 03 Hex)  
Elemento de datos  Observaciones  
VuFaultData  Todos los fallos almacenados o en curso en la VU. 
Si esta sección está vacía, únicamente se envía el men­
saje noOfVuFaults = 0.  
VuEventData  Todos los incidentes almacenados o en curso en la VU 
(excepto excesos de velocidad). 
Si esta sección está vacía, únicamente se envía el men­
saje noOfVuEvents = 0.  
VuOverSpeedingControlData  Datos relacionados con el último control de exceso de 
velocidad (valor por defecto si no se dispone de datos)  
VuOverSpeedingEventData  Todos los incidentes de exceso de velocidad almacena­
dos en la VU. 
Si esta sección está vacía, únicamente se envía el men­
saje noOfVuOverSpeedingEvents = 0.  
VuTimeAdjustmentData  Todos los incidentes de ajuste de la hora almacenados 
en la VU (fuera del marco de un calibrado total). 
Si esta sección está vacía, únicamente se envía el men­
saje noOfVuTimeAdjRecords = 0.  
Signature  Firma RSA de todos los datos desde noOfVuFaults 
hasta el último byte del último registro de ajuste de la 
hora.  
Estructura de datos de segunda generación, versión 1 (TREP 23 H ex) 
Elemento de datos  Observaciones  
VuFaultRecordArray  Todos los fallos almacenados o en curso en la VU. 
Si esta sección está vacía, se envía una cabecera de 
conjunto con el mensaje noOfRecords = 0.  
VuEventRecordArray  Todos los incidentes almacenados o en curso en la VU 
(excepto excesos de velocidad). 
Si esta sección está vacía, se envía una cabecera de 
conjunto con el mensaje noOfRecords = 0.  
VuOverSpeedingControlDataRecordArray  Datos relacionados con el último control de exceso de 
velocidad (valor por defecto si no se dispone de datos)  
VuOverSpeedingEventRecordArray  Todos los incidentes de exceso de velocidad almacena­
dos en la VU. 
Si esta sección está vacía, se envía una cabecera de 
conjunto con el mensaje noOfRecords = 0.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 347  
Elemento de datos  Observaciones  
VuTimeAdjustmentRecordArray  Todos los incidentes de ajuste de la hora almacenados 
en la VU (fuera del marco de un calibrado total). 
Si esta sección está vacía, se envía una cabecera de 
conjunto con el mensaje noOfRecords = 0.  
SignatureRecordArray  La firma ECC de todos los datos anteriores.  
Estructura de datos de segunda generación, versión 2 (TREP 33 H ex) 
Elemento de datos  Observaciones  
VuFaultRecordArray  Todos los fallos almacenados o en curso en la VU. 
Si esta sección está vacía, se envía una cabecera de 
conjunto con el mensaje noOfRecords = 0.  
VuEventRecordArray  Todos los incidentes almacenados o en curso en la VU 
(excepto excesos de velocidad). 
Si esta sección está vacía, se envía una cabecera de 
conjunto con el mensaje noOfRecords = 0.  
VuOverSpeedingControlDataRecordArray  Datos relacionados con el último control de exceso de 
velocidad (valor por defecto si no se dispone de datos)  
VuOverSpeedingEventRecordArray  Todos los incidentes de exceso de velocidad almacena­
dos en la VU. 
Si esta sección está vacía, se envía una cabecera de 
conjunto con el mensaje noOfRecords = 0.  
VuTimeAdjustmentRecordArray  Todos los incidentes de ajuste de la hora almacenados 
en la VU (fuera del marco de un calibrado total). 
Si esta sección está vacía, se envía una cabecera de 
conjunto con el mensaje noOfRecords = 0.  
SignatureRecordArray  La firma ECC de todos los datos anteriores.  
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 
( R e s p u e s t a p o s i t i v a a l a p e t i c i ó n d e t  r a n s f e r e n c i a 
d e d a t o s « D a t o s p o r m e n o r i z a d o s s o b r e  l a v e l o c i ­
d a d » )  
DDP_032 El campo de datos del mensaje  Positive Response Trans ­
fer Data Detailed Speed  proporcionará los datos siguien­
tes en el siguiente orden, con el SID 76 Hex, el TREP 04 
o 24 Hex y el método adecuado de división y recuento de 
submensajes:  
Estructura de datos de primera generación (TREP 04 Hex)  
Elemento de datos  Observaciones  
VuDetailedSpeedData  Todos los datos pormenorizados sobre la velocidad al­
macenados en la VU (un bloque de velocidad por mi­
nuto de movimiento del vehículo). 
60 valores de velocidad por minuto (uno por segundo).  
Signature  Firma RSA de todos los datos desde noOfSpeedBlocks 
hasta el último byte del último bloque de velocidad.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 348  
Estructura de datos de segunda generación (TREP 24 Hex)  
Elemento de datos  Observaciones  
VuDetailedSpeedBlockRecordArray  Todos los datos pormenorizados sobre la velocidad al­
macenados en la VU (un bloque de velocidad por mi­
nuto de movimiento del vehículo). 
60 valores de velocidad por minuto (uno por segundo).  
SignatureRecordArray  La firma ECC de todos los datos anteriores.  
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  
( R e s p u e s t a p o s i t i v a a l a p e t i c i ó n d e t  r a n s f e r e n c i a 
d e d a t o s « D a t o s t é c n i c o s » )  
DDP_033 El campo de datos del mensaje  Positive Response Transfer 
Data Technical Data  proporcionará los datos siguientes en 
el siguiente orden, con el SID 76 Hex, el TREP 05, 25 o 35 
Hex y el método adecuado de división y recuento de 
submensajes:  
Estructura de datos de primera generación (TREP 05 Hex)  
Elemento de datos  Observaciones  
VuIdentification  
SensorPaired  
VuCalibrationData  Todos los registros de calibrado almacenados en la VU.  
Signature  Firma RSA de todos los datos desde vuManufacturer­
Name hasta el último byte del último VuCalibrationRe­
cord.  
Estructura de datos de segunda generación, versión 1 (TREP 25 H ex) 
Elemento de datos  Observaciones  
VuIdentificationRecordArray  
VuSensorPairedRecordArray  Todos los emparejamientos de sensores de movimiento 
almacenados en la VU.  
VuSensorExternalGNSSCoupledRecordA­
rray Todos los acoplamientos del dispositivo GNSS externo 
almacenados en la VU.  
VuCalibrationRecordArray  Todos los registros de calibrado almacenados en la VU.  
VuCardRecordArray  Todos los datos de inserción de tarjeta almacenados en 
la VU.  
VuITSConsentRecordArray  
VuPowerSupplyInterruptionRecordArray  
SignatureRecordArray  La firma ECC de todos los datos anteriores.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 349  
Estructura de datos de segunda generación, versión 2 (TREP 35 H ex) 
Elemento de datos  Observaciones  
VuIdentificationRecordArray  
VuSensorPairedRecordArray  Todos los emparejamientos de sensores de movimiento 
almacenados en la VU.  
VuSensorExternalGNSSCoupledRecordA­
rray Todos los acoplamientos del dispositivo GNSS externo 
almacenados en la VU.  
VuCalibrationRecordArray  Todos los registros de calibrado almacenados en la VU.  
VuCardRecordArray  Todos los datos de inserción de tarjeta almacenados en 
la VU.  
VuITSConsentRecordArray  
VuPowerSupplyInterruptionRecordArray  
SignatureRecordArray  La firma ECC de todos los datos anteriores.  
▼B 
2.3. Almacenamiento de un archivo en un ESM  
DDP_034 Si una sesión de transferencia ha incluido una transfer encia 
de datos de la VU, el IDE deberá almacenar en un único 
archivo físico todos los datos recibidos de la VU durante 
dicha sesión de transferencia dentro de los mensajes de 
respuesta positiva a la solicitud de transferencia. Los datos 
almacenados excluyen las cabeceras de mensajes, los con­
tadores de submensajes, los submensajes vacíos y las sumas 
de control, pero incluyen el SId y el TREP (del primer 
submensaje exclusivamente si es que hay varios submensa­
jes). 
3. PROTOCOLO DE TRANSFERENCIA DE LOS DATOS ALMACE­
NADOS EN TARJETAS DE TACÓGRAFO  
3.1. Ámbito de aplicación  
El presente apartado describe cómo se transfieren directamente a un 
IDE los datos almacenados en una tarjeta de tacógrafo. El IDE n o 
forma parte del entorno seguro, por tanto no se lleva a cabo un a 
autenticación entre la tarjeta y el IDE.  
3.2. Definiciones  
Sesión de transferencia : Cada vez que se transfieren los 
datos de la ICC. Esta sesión 
comprende el procedimiento 
completo desde el reinicio de 
la ICC por parte de un IFD 
hasta la desactivación de la 
ICC (extracción de la tarjeta o 
siguiente reinicio).  
Archivo de datos firmado : Un archivo de la ICC. El ar­
chivo se transfiere al IFD en 
forma de texto. En la ICC, el 
archivo se somete a una com­
probación aleatoria y se firma, 
y la firma se transfiere al IFD.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 350  
3.3. Transferencia de los datos de la tarjeta  
▼M3 
DDP_035 La transferencia de los datos de una tarjeta de tacógra fo 
consta de los pasos siguientes:  
— Transferencia de la información común de la tarjeta al­
macenada en los EF ICC e IC. Esta información es 
opcional y no se protege con una firma digital.  
— Tarjetas de tacógrafo de primera y segunda generación  
— Transferencia de los EF dentro del DF Tachograph:  
— Transferencia de los EF Card_Certificate y 
CA_Certificate. Esta información no se protege 
con una firma digital.  
Es obligatorio transferir estos archivos en cada 
sesión de transferencia.  
— Transferencia del resto de EF con datos de apli­
cación (dentro del DF Tachograph), excepto el 
EF Card_Download. Esta información se protege 
con una firma digital, utilizando los mecanismos 
de seguridad comunes del apéndice 11, parte A.  
— Es obligatorio transferir al menos los EF Appli­
cation_Identification e Identification en cada se­
sión de transferencia.  
— Cuando se transfieran los datos de una tarjeta de 
conductor, también es obligatorio transferir los 
siguientes EF:  
Events_Data,  
Faults_Data,  
Driver_Activity_Data,  
Vehicles_Used,  
Places,  
Control_Activity_Data,  
Specific_Conditions.  
— En el caso únicamente de las tarjetas de tacógrafo de 
segunda generación:  
— Transferencia de los EF dentro del DF Tacho­
graph_G2, excepto cuando la transferencia de una 
tarjeta de conductor insertada en una VU se realiza 
durante un control de conductores efectuado por una 
autoridad de control de fuera de la UE utilizando una 
tarjeta de control de primera generación:  
— Transferencia de los EF CardSignCertificate, 
CA_Certificate y Link_Certificate. Esta informa­
ción no se protege con una firma digital.  
— Es obligatorio transferir estos archivos en cada 
sesión de transferencia.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 351  
— Transferencia del resto de EF con datos de apli­
cación (dentro del DF Tachograph_G2), excepto 
el EF Card_Download. Esta información se pro­
tege con una firma digital, utilizando los meca­
nismos de seguridad comunes del apéndice 11, 
parte B.  
— Es obligatorio transferir al menos los EF Appli­
cation_Identification, Application_Identifica­
tion_V2 (si existe) e Identification en cada sesión 
de transferencia.  
— Cuando se transfieran los datos de una tarjeta de 
conductor, también es obligatorio transferir los 
siguientes 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.  
— Cuando se transfieran los datos de una tarjeta de 
conductor, se actualizará la fecha de LastCard­
Download en el EF Card_Download y en los DF 
Tachograph y, si procede, Tachograph_G2.  
— Cuando se transfieran los datos de una tarjeta de 
taller, habrá que reiniciar el contador de cali­
brado en el EF Card_Download y en los DF 
Tachograph y, si procede, Tachograph_G2.  
— Cuando se transfieran los datos de una tarjeta de 
taller, no se transferirá el EF Sensor_Installa­
tion_Data en los DF Tachograph y, si procede, 
Tachograph_G2.  
▼B 
3.3.1  Secuencia de inicialización  
DDP_036 El IDE deberá iniciar la secuencia de la manera siguien te: 
Tarjeta  Dirección  IDE/IFD  Significado/Observaciones  
⇦ Reinicio de hardware  
ATR ⇨ 
Opcionalmente se puede utilizar PPS para cambiar a una 
velocidad en baudios más alta, siempre y cuando la admita 
la ICC.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 352  
3.3.2  Secuencia para archivos de datos no firmados  
DDP_037  ►M1 A continuación se muestra la secuencia para trans­
ferir los archivos EF ICC, IC, Card_Certificate (o CardSign­
Certificate para DF tacógrafo_G2), CA_Certificate y 
Link_Certificate (solo para DF tacógrafo_G2): ◄  
Tarjeta  Dirección  IDE/IFD  Significado/Observaciones  
⇦ Select File (seleccionar 
archivo)  Selección de archivo utili­
zando su identificador.  
OK ⇨ 
⇦ Read Binary (leer archivo 
binario)  Si el archivo contiene más 
datos de los que caben en la 
memoria temporal del lector 
o de la tarjeta, habrá que re­
petir el comando hasta que se 
haya leído el archivo 
completo.  
File Data (datos del 
archivo) 
OK ⇨ Almacenar datos en un ESM  según lo previsto en el apar­
tado 3.4 Data storage format  
Nota 1:  antes de seleccionar el archivo EF Card_Certificate 
(o CardSignCertificate), es preciso seleccionar la aplicación 
de tacógrafo (selección por AID).  
Nota 2:  también es posible seleccionar y leer un archivo en 
un solo paso al utilizar un comando Read Binary con un 
identificador EF corto.  
3.3.3  Secuencia para archivos de datos firmados  
DDP_038 La siguiente secuencia debe utilizarse para cada uno de  los 
archivos siguientes que debe transferirse junto con su firma:  
▼M1 
Tarjeta  Dir  IDE/IFD  Significado/Observaciones
  
Select File (seleccionar ar ­
chivo)  
OK
 
Perform Hash of File (re ­
alizar comprobación alea ­
toria de archivo)  — Calcula el valor de com­
probación aleatoria con 
los datos contenidos en 
el archivo seleccionado, 
utilizando el algoritmo 
de comprobación aleato­
ria especificado en el 
apéndice 11, parte A o 
B. Este no es un co­
mando ISO.  
Realizar una comproba­
ción aleatoria del ar­
chivo y almacenar tem­
poralmente el valor ob­
tenido  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 353  
Tarjeta  Dir  IDE/IFD  Significado/Observaciones  
OK
 
Read Binary (leer archivo 
binario)  Si el archivo contiene más 
datos de los que caben en la 
memoria temporal del lector 
o de la tarjeta, habrá que re­
petir el comando hasta que se 
haya leído el archivo 
completo.  
File Data (datos del 
archivo) 
OK
 Almacenar los datos recibi­
dos en un ESM  según lo previsto en el apar­
tado 3.4 Data storage format
  
PSO: Compute Digital 
Signature (calcular firma 
digital)  
Realizar la operación 
de seguridad «calcular 
firma digital» utili­
zando el valor de 
comprobación aleatoria 
almacenado temporal­
mente  
Signature (firma) 
OK
 Añadir datos a los datos 
previamente almacenados en 
el ESM  según lo previsto en el apar­
tado 3.4 Data storage format  
▼B 
Nota:  también es posible seleccionar y leer un archivo en un 
solo paso al utilizar un comando Read Binary con un iden­
tificador EF corto. En este caso, se podrá seleccionar y leer 
el EF antes de ejecutar el comando Perform Hash of File 
(realizar comprobación aleatoria de archivo).  
3.3.4  Secuencia para reiniciar el contador del calibrado  
DDP_039 A continuación se muestra la secuencia para reiniciar e l 
contador
  en el 
archivo EF
  incluido en una tarjeta del 
taller:  
Tarjeta  Dir  IDE/IFD  Significado/Observaciones  
⇦ Select File  (seleccionar ar­
chivo) EF Card_Download  Selección de archivo utili­
zando su identificador  
OK ⇨ 
⇦ Update Binary (actualizar 
archivo binario)  
NoOfCalibrationsSinceDown­
load=00 00  
Reinicia el número de 
transferencia de la tar­
jeta 
OK ⇨ 
Nota:  también es posible seleccionar y actualizar un archivo 
en un solo paso al utilizar un comando Update Binary con 
un identificador EF corto.  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 354  
3.4. Formato de almacenamiento de datos  
3.4.1  Introducción  
DDP_040 Los datos transferidos deben almacenarse de acuerdo con  las 
siguientes condiciones:  
— Los datos almacenados deben ser transparentes. Es decir, 
durante el almacenamiento es preciso respetar el orden 
de los bytes que se transfieren de la tarjeta, así como el 
orden de los bits contenidos en cada byte.  
— Todos los archivos de la tarjeta cuyos datos se trans­
fieren en una sesión se almacenan en un archivo dentro 
del ESM.  
3.4.2  Formato de archivo  
DDP_041 El formato de archivo es una concatenación de varios ob je­
tos TLV.  
DDP_042 La etiqueta de un EF consiste en el FID más la terminac ión 
«00».  
DDP_043 La etiqueta de la firma de un EF consiste en el FID del  
archivo más la terminación «01».  
DDP_044 La longitud es un valor de dos bytes. Este valor define  el 
número de bytes en el campo de valor. El valor «FF FF» en 
el campo de longitud se reserva para uso futuro.  
DDP_045 Si un archivo no se transfiere, no deberá almacenarse n in­
guna información relacionada con dicho archivo (ni la eti­
queta ni la longitud cero).  
▼M1 
DDP_046 Inmediatamente después del objeto TLV que contiene los 
datos del archivo, habrá que almacenar una firma como el 
siguiente objeto TLV.  
Definición  Significado  Longitud  
FID (2 bytes) || 00  Etiqueta para EF (FID) en 
el DF
  o  
para la información común 
de la tarjeta  3 bytes  
FID (2 bytes) || 01  Etiqueta para firma de 
EF (FID) en el DF
  3 bytes  
FID (2 bytes) || 02  Etiqueta para firma de 
EF (FID) en el DF
  3 bytes  
FID (2 bytes) || 03  Etiqueta para firma de 
EF (FID) en el DF
  3 bytes  
xx xx  Longitud del campo de va­
lor 2 bytes  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 355  
Ejemplo de datos en un archivo transferido y almacenado en 
un ESM:  
Etiqueta  Longitud  Valor
  
Datos del archivo EF ICC
  
Datos del archivo EF Card_Certificate  
…
 
Datos del archivo EF
  
(en el DF ­
  
)
 
Firma del archivo EF
  
(en el DF ­
  
)
 
Datos del archivo EF
  
(en el DF ­
  
)
 
Firma del archivo EF
  
(en el DF ­
  
) 
▼B 
4. TRANSFERENCIA DE LOS DATOS DE UNA TARJETA DE TA­
CÓGRAFO A TRAVÉS DE UNA UNIDAD INSTALADA EN EL 
VEHÍCULO.  
DDP_047 La VU debe permitir la transferencia del contenido de u na 
tarjeta de conductor insertada en un IDE conectado.  
DDP_048 El IDE deberá enviar a la VU el mensaje Transfer Data 
Request Card Download (petición de transferencia de datos 
de la tarjeta) para iniciar este modo (véase el apartado 
2.2.2.9).  
▼M1 
DDP_049 Tarjetas de conductor de primera generación: Los datos se 
transferirán utilizando el protocolo de transferencia de datos 
de primera generación, y los datos transferidos deberán tener 
el mismo formato que los datos transferidos desde una uni­
dad instalada en el vehículo de primera generación.  
Tarjetas de conductor de segunda generación: la VU deberá 
transferir todos los datos de la tarjeta, archivo por archivo, 
de acuerdo con el protocolo de transferencia descrito en el 
apartado 3, para luego enviar al IDE todos los datos recibi­
dos de la tarjeta. Estos datos se enviarán con el formato 
adecuado de archivo TLV (véase el apartado 3.4.2) y en­
capsulados en un mensaje Positive Response Transfer Data 
(respuesta positiva a la petición de transferencia de datos).  
▼B 
DDP_050 El IDE deberá recuperar los datos contenidos en el mens aje 
Positive Response Transfer Data (respuesta positiva a la 
petición de transferencia de datos) (separando todas las ca­
beceras, SId, TREP, contadores de submensajes y sumas de 
control) y almacenarlos en un único archivo físico, tal y 
como se especifica en el apartado 2.3.  
DDP_051 A continuación, según proceda, la VU actualizará el arc hivo
 
o el archivo
  
de la tarjeta del conductor.  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 356  
Apéndice 8  
PROTOCOLO DE CALIBRADO  
ÍNDICE  
1. INTRODUCCIÓN  
2. TÉRMINOS, DEFINICIONES Y REFERENCIAS  
3. VISIÓN GENERAL DE LOS SERVICIOS  
3.1. Servicios disponibles  
3.2. Códigos de respuesta  
4. SERVICIOS DE COMUNICACIÓN  
4.1. Servicio StartCommunication  
4.2. Servicio StopCommunication  
4.2.1 Descripción del mensaje  
4.2.2 Formato del mensaje  
4.2.3 Definición del parámetro  
4.3. Servicio TesterPresent (presencia de verificador)  
4.3.1 Descripción del mensaje  
4.3.2 Formato del mensaje  
5. SERVICIOS DE ADMINISTRACIÓN  
5.1. Servicio StartDiagnosticSession  
5.1.1 Descripción del mensaje  
5.1.2 Formato del mensaje  
5.1.3 Definición del parámetro  
5.2. Servicio SecurityAccess  
5.2.1 Descripción del mensaje  
5.2.2 Formato del mensaje — SecurityAccess — requestSeed  
5.2.3 Formato del mensaje — SecurityAccess — sendKey  
6. SERVICIOS DE TRANSMISIÓN DE DATOS  
6.1. Servicio ReadDataByIdentifier  
6.1.1 Descripción del mensaje  
6.1.2 Formato del mensaje  
6.1.3 Definición del parámetro  
6.2. Servicio WriteDataByIdentifier  
6.2.1 Descripción del mensaje  
6.2.2 Formato del mensaje  
6.2.3 Definición del parámetro  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 357  
7. CONTROL DE LOS IMPULSOS DE PRUEBA — UNIDAD FUN­ 
CIONAL PARA CONTROL DE ENTRADA/SALIDA  
7.1. Servicio InputOutputControlByIdentifier  
7.1.1 Descripción del mensaje  
7.1.2 Formato del mensaje  
7.1.3 Definición del parámetro  
▼M3 
8. SERVICIO ROUTINECONTROL (AJUSTE DE LA HORA)  
8.1. Descripción del mensaje  
8.2. Formato del mensaje  
9. FORMATOS DATARECORDS  
9.1. Intervalos de los parámetros transmitidos  
9.2. Formatos dataRecords  
▼B 
1. INTRODUCCIÓN  
El presente apéndice define el modo en que se intercambian dato s entre 
una unidad instalada en el vehículo y un verificador a través d e la 
línea K que forma parte de la interfaz de calibrado descrita en  el apén­
dice 6. Asimismo, se explica el control de la línea de señal de  entrada/ 
salida en el conector de calibrado.  
El establecimiento de las comunicaciones con una línea K se des cribe 
en el apartado 4 (Servicios de comunicación).  
Este apéndice utiliza la idea de «sesiones de diagnóstico» para  deter­
minar el alcance del control de línea K en diferentes condicion es. La 
sesión por defecto es la «StandardDiagnosticSession», en la que  todos 
los datos se pueden leer desde una unidad instalada en el vehíc ulo pero 
no es posible escribir ningún dato en ella.  
La selección de la sesión de diagnóstico se explica en el apart ado 5 
(Servicios de administración).  
El presente apéndice debe considerarse aplicable tanto para la genera­
ción de VU como de tarjetas de taller, según lo previsto en los  requi­
sitos de interoperabilidad recogidos en el presente Reglamento.  
CPR_001 La «ECUProgrammingSessions» permite la introducción de 
datos en la unidad instalada en el vehículo. Si se introducen 
datos de calibrado, la unidad deberá estar además en el 
modo de funcionamiento CALIBRADO.  
La transferencia de datos a través de la línea K se describe 
en el apartado 6 (Servicios de transmisión de datos). Los 
formatos de los datos transferidos se detallan en el apartado 
8 (Formatos dataRecords).  
CPR_002 La «ECUAdjustmentSession» permite seleccionar el modo 
I/O de la línea de señal I/O de calibrado a través de la 
interfaz de la línea K. El procedimiento de control de la 
línea de señal I/O de calibrado se describe en el apartado 
7 (Control de los impulsos de prueba — Unidad funcional 
para control de entrada/salida).  
CPR_003 En todo el documento se hace referencia a la dirección del 
verificador como «tt». A pesar de que puedan existir direc­
ciones preferentes para los verificadores, la VU deberá res­
ponder correctamente a cualquier dirección de verificador. 
La dirección física de la VU es 0xEE.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 358  
2. TÉRMINOS, DEFINICIONES Y REFERENCIAS  
Todos los protocolos, mensajes y códigos de error se rigen prin cipal­
mente por el proyecto de la norma ISO 14229-1 (Vehículos de car re­
tera — Sistemas de diagnóstico — Parte 1: Servicios de diagnóst ico, 
versión de 6 de 22 de febrero de 2001).  
Se emplea la codificación de bytes y los valores hexadecimales para los 
identificadores de servicios, las peticiones y respuestas de se rvicio y los 
parámetros normalizados.  
El término «verificador» se refiere al equipo empleado para int roducir 
datos de programación/calibrado en la VU.  
Los términos «cliente» y «servidor» se refieren al verificador y a la 
VU, respectivamente.  
El término UCE significa «unidad de control electrónico» y se r efiere a 
la VU.  
Referencias:  
▼M1 
ISO 14230-2: Vehículos de carretera — Sistemas de diagnóstico —  
Protocolo Keyword 2000 — Parte 2: Nivel de enlace de datos.  
Primera edición: 1999.  
▼B 
3. VISIÓN GENERAL DE LOS SERVICIOS  
3.1. Servicios disponibles  
La siguiente tabla ofrece una visión general de los servicios q ue estarán 
disponibles en el tacógrafo y que se definen en el presente doc umento.  
CPR_004 La tabla indica los servicios que están disponibles en una 
sesión de diagnóstico activada.  
— La  primera columna  especifica los servicios que están 
disponibles.  
— La  segunda columna  incluye el número del apartado 
del presente apéndice donde se ofrece más información 
sobre el servicio que corresponda.  
— La  tercera columna  asigna los valores de identificador 
de servicio (SId) para los mensajes de petición.  
— La  cuarta columna  especifica los servicios de la  
«StandardDiagnosticSession» (SD)  que deben aplicarse 
en cada VU.  
— La  quinta columna  especifica los servicios de la  
«ECUAdjustmentSession» (ECUAS)  que deben apli­
carse para poder controlar la línea de señal I/O en el 
conector de calibrado de la VU, situado en el panel 
frontal.  
— La  sexta columna  especifica los servicios de la  
«ECUProgrammingSession» (ECUPS)  que deben apli­
carse para poder programar los parámetros en la VU.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 359  
Tabla 1  
Cuadro resumen con los valores de los identificadores de servicios  
Sesiones de diagnóstico  
Nombre del servicio de diagnóstico  Sección 
n o Valor SId de la 
petición  SD ECUAS  ECUPS  
StartCommunication  4.1  8 1  ■  ■  ■  
StopCommunication  4.2  8 2  ■  
Testerpresent  4.3  3 E  ■  ■  ■  
StartDiagnosticSession  5.1  1 0  ■  ■  ■  
SecurityAccess  5.2  2 7  ■  ■  ■  
ReadDataByIdentifier  6.1  2 2  ■  ■  ■  
WriteDataByIdentifier  6.2  2 E  ■  
InputOutputControlByIdentifier  7.1  2 F  ■  
▼M3 
RoutineControl  8  3 1
  
▼B 
■ Este símbolo indica que el servicio es obligatorio en esa sesi ón de diagnóstico. 
La ausencia de símbolo indica que el servicio no se admite en e sa sesión de 
diagnóstico.  
3.2. Códigos de respuesta  
Se definen los códigos de respuesta para cada servicio.  
4. SERVICIOS DE COMUNICACIÓN  
Se requieren ciertos servicios para establecer y mantener la co munica­
ción, y no aparecen en el nivel de aplicación. Los servicios di sponibles 
se describen con detalle en la siguiente tabla:  
Tabla 2  
Servicios de comunicación  
Nombre del servicio  Descripción  
StartCommunication  El cliente solicita el comienzo de una 
sesión de comunicación con uno o va­
rios servidores.  
StopCommunication  El cliente solicita el término de la se­
sión de comunicación actual.  
Testerpresent  El cliente indica al servidor que toda­
vía está presente.  
CPR_005 El servicio StartCommunication sirve para comenzar una 
comunicación. A fin de utilizar un servicio, es preciso ini­
cializar la comunicación y que los parámetros de comuni­
cación sean los adecuados para el modo deseado.  
4.1. Servicio StartCommunication  
CPR_006 Nada más recibir una indicación primitiva StartCommunic a­
tion, la VU deberá comprobar si el enlace de comunicación 
solicitado se puede inicializar en las condiciones que haya 
en ese momento. Las condiciones válidas para la inicializa­
ción de un enlace de comunicación se describen en la norma 
ISO 14230-2.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 360  
CPR_007 A continuación, la VU deberá hacer todo lo necesario pa ra 
inicializar el enlace de comunicación y enviar una primitiva 
de respuesta StartCommunication con los parámetros de 
respuesta positiva seleccionados.  
CPR_008 Si una VU que ya está inicializada (y ha entrado en una  
sesión de diagnóstico) recibe una nueva petición StartCom­
munication Request (por ejemplo, debido a la recuperación 
de un error en el verificador), la petición será aceptada y la 
VU se reinicializará.  
CPR_009 Si el enlace de comunicación no se puede inicializar po r 
algún motivo, la VU deberá seguir funcionando en el 
modo que lo estaba haciendo justo antes del intento de 
inicialización de dicho enlace de comunicación.  
CPR_010 Es preciso asignar una dirección física al mensaje Star tCom­
munication Request.  
CPR_011 La inicialización de la VU para los servicios se efectú a a 
través de un método de «inicialización rápida».  
— Antes de cualquier actividad hay un tiempo de inactivi­
dad del bus.  
— A continuación, el verificador envía una pauta de inicia­
lización.  
— La respuesta de la VU incluye toda la información ne­
cesaria para establecer la comunicación.  
CPR_012 Una vez concluida la inicialización:  
— todos los parámetros de comunicación se configuran con 
los valores definidos en la Tabla 4, de acuerdo con los 
bytes clave;  
— la VU está esperando la primera petición del verificador;  
— la VU se encuentra en el modo de diagnóstico por de­
fecto, es decir, StandardDiagnosticSession; y  
— la línea de señal I/O de calibrado se encuentra en el 
estado por defecto, es decir, desactivada.  
CPR_014 La velocidad de datos en la línea K será de 10 400 baud ios. 
CPR_016 El verificador comienza la inicialización rápida trans­
mitiendo una pauta de activación (Wup) por la línea K. 
La pauta comienza después del período de reposo de la 
línea K con un tiempo Tinil breve. El verificador transmite 
el primer bit del servicio StartCommunication después de un 
tiempo Twup que sigue al primer flanco descendente.
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 361  
CPR_017 Los valores de sincronización para la inicialización rá pida y 
las comunicaciones en general se describen con todo detalle 
en las tablas siguientes. Existen diferentes posibilidades para  
el tiempo de reposo (Trep):  
— primera transmisión después de conectar la alimentación, 
Trep=300 ms;  
— después de haber terminado un servicio StopCommuni­
cation, Trep=P3 mín.; y  
— después de haberse interrumpido la comunicación por 
exceso del tiempo límite P3 máx., Trep=0.  
Tabla 3  
Valores de sincronización para inicialización rápida  
Parámetro  Valor mínimo  Valor máximo  
Tinil  25 ± 1 ms  24 ms  26 ms  
Twup  50 ± 1 ms  49 ms  51 ms  
Tabla 4  
valores de sincronización de la comunicación  
Sincroniza­
ción Pará­
metro  Descripción del parámetro  Valores límite 
inferiores (ms)  Valores límite 
superiores (ms)  
mín. máx.  
P1 Tiempo entre dos bytes para 
respuesta de la VU  0 2 0  
P2 Tiempo transcurrido entre la 
petición del verificador y la 
respuesta de la VU o entre 
dos respuestas de la VU  25 250  
P3 Tiempo transcurrido desde el 
final de las respuestas de la 
VU hasta el comienzo de la 
nueva petición del verificador  55 5 000  
P4 Tiempo entre dos bytes para 
petición del verificador  5 2 0  
CPR_018 En las siguientes tablas se describe con detalle el for mato de 
mensaje para inicialización rápida. (NOTA: hex significa 
hexadecimal)  
Tabla 5  
Mensaje StartCommunication Request (petición de inicio de la 
comunicación)  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 1 Byte de formato — asignación 
de dirección física  81 FMT  
N o 2 Byte de dirección de destino  E E  TGT  
N o 3 Byte de dirección de origen  t t  SRC  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 362  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 4 StartCommunication Request 
Service Id (SId de petición de 
inicio de la comunicación)  81 SCR  
N o 5 Suma de control  00-FF  C S  
Tabla 6  
mensaje StartCommunication Positive Response (respuesta positiva a la 
petición de inicio de lacomunicación)  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 1 Byte de formato — asignación 
de dirección física  80 FMT  
N o 2 Byte de dirección de destino  t t  TGT  
N o 3 Byte de dirección de origen  E E  SRC  
N o 4 Byte de longitud adicional  0 3  LEN  
N o 5 StartCommunication Positive 
Response Service Id (SId de 
respuesta positiva a la peti ­
ción de inicio de la comuni ­
cación)  C1 SCRPR  
N o 6 Byte clave 1  E A  KB1  
N o 7 Byte clave 2  8 F  KB2  
N o 8 Suma de control  00-FF  C S  
CPR_019 No hay respuesta negativa al mensaje StartCommunication  
Request. Si no hay un mensaje de respuesta positiva que 
transmitir, la VU no se inicializa, no transmite ninguna 
información y continúa en el modo normal de funciona­
miento.  
4.2. Servicio StopCommunication  
4.2.1  Descripción del mensaje  
Este servicio del nivel de comunicación sirve para poner fin a una 
sesión de comunicación.  
CPR_020 Cuando reciba una indicación primitiva StopCommunica­
tion, la VU deberá comprobar si las condiciones que haya 
en ese momento permiten poner término a la comunicación. 
En caso afirmativo, la VU hará todo lo necesario para ter­
minar la comunicación.  
CPR_021 Si es posible poner fin a la comunicación, antes de que  esta 
termine la VU deberá emitir una primitiva de respuesta 
StopCommunication con los parámetros de respuesta posi­
tiva seleccionados.  
CPR_022 Si por algún motivo no es posible poner fin a la comuni ca­
ción, la VU deberá emitir una primitiva de respuesta Stop­
Communication con el parámetro de respuesta negativa 
seleccionado.  
CPR_023 Si la VU detecta que se ha sobrepasado el tiempo límite  
P3máx., la comunicación deberá terminar sin que se emita 
una primitiva de respuesta.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 363  
4.2.2  Formato del mensaje  
CPR_024 En las siguientes tablas se describen con detalle los f ormatos 
de mensaje para las primitivas StopCommunication.  
Tabla 7  
Mensaje StopCommunication Request (petición de interrupción de la 
comunicación)  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 1 Byte de formato — asignación 
de dirección física  80 FMT  
N o 2 Byte de dirección de destino  E E  TGT  
N o 3 Byte de dirección de origen  t t  SRC  
N o 4 Byte de longitud adicional  0 1  LEN  
N o 5 StopCommunication Request 
Service Id (SId de petición 
de interrupción de la comu ­
nicación)  82 SPR  
N o 6 Suma de control  00-FF  C S  
Tabla 8  
Mensaje StopCommunication Positive Response (respuesta positiva a la 
petición de interrupción de la comunicación)  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 1 Byte de formato — asignación 
de dirección física  80 FMT  
N o 2 Byte de dirección de destino  t t  TGT  
N o 3 Byte de dirección de origen  E E  SRC  
N o 4 Byte de longitud adicional  0 1  LEN  
N o 5 StopCommunication Positive 
Response Service Id (SId de 
respuesta positiva a la peti ­
ción de interrupción de la co ­
municación)  C2 SPRPR  
N o 6 Suma de control  00-FF  C S  
Tabla 9  
Mensaje StopCommunication Negative Response (respuesta negativa a la 
petición de interrupción de la comunicación)  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 1 Byte de formato — asignación 
de dirección física  80 FMT  
N o 2 Byte de dirección de destino  t t  TGT  
N o 3 Byte de dirección de origen  E E  SRC  
N o 4 Byte de longitud adicional  0 3  LEN  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 364  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 5 negative Response Service Id 
(SId de respuesta negativa)  7F NR  
N o 6 StopCommunication Request 
Service Identification (SId de 
petición de interrupción de la 
comunicación)  82 SPR  
N o 7 responseCode = generalReject  1 0  RC_GR  
N o 8 Suma de control  00-FF  C S  
4.2.3  Definición del parámetro  
Este servicio no precisa definición de parámetros.  
4.3. Servicio TesterPresent (presencia de verificador)  
4.3.1  Descripción del mensaje  
El servicio TesterPresent lo utiliza el verificador para indica r al servi­
dor que sigue presente, con el fin de evitar que retorne automá tica­
mente al funcionamiento normal, lo que podría interrumpir la co muni­
cación. Este servicio, que se envía periódicamente, mantiene ac tiva la 
comunicación o la sesión de diagnóstico al reiniciar el tempori zador P3 
cada vez que se recibe una petición de este servicio.  
4.3.2  Formato del mensaje  
CPR_079 En las siguientes tablas se describen con detalle los f ormatos 
de mensaje para las primitivas TesterPresent.  
Tabla 10  
Mensaje TesterPresent Request (petición de presencia de verificador)  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 1 Byte de formato — asignación 
de dirección física  80 FMT  
N o 2 Byte de dirección de destino  E E  TGT  
N o 3 Byte de dirección de origen  t t  SRC  
N o 4 Byte de longitud adicional  0 2  LEN  
N o 5 TesterPresent Request Ser ­
vice Id (SId de petición de 
presencia de verificador)  3E TP  
N o 6 Sub Function = res­
ponseRequired- 
= [sí 0 1  RESPREQ_Y  
no] 0 2  RESPREQ_NO  
N o 7 Suma de control  00-FF  C S  
CPR_080 Si se configura en «sí» el parámetro responseRequired, el 
servidor responderá con el mensaje de respuesta positiva 
siguiente. Si se configura en «no», el servidor no enviará 
respuesta.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 365  
Tabla 11  
Mensaje TesterPresent Positive Response (respuesta positiva a la petición 
de presencia de verificador)  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 1 Byte de formato — asignación 
de dirección física  80 FMT  
N o 2 Byte de dirección de destino  t t  TGT  
N o 3 Byte de dirección de origen  E E  SRC  
N o 4 Byte de longitud adicional  0 1  LEN  
N o 5 TesterPresent Positive Res ­
ponse Service Id (SId de res ­
puesta positiva a la petición 
de presencia de verificador)  7E TPPR  
N o 6 Suma de control  00-FF  C S  
CPR_081 El servicio admitirá los siguientes códigos de respuest a 
negativa:  
Tabla 12  
Mensaje TesterPresent Negative Response (respuesta negativa a la petición 
de presencia de verificador)  
N o de byte  Nombre del parámetro  Valor 
hex Mnemónico  
N o 1 Byte de formato — asignación de 
dirección física  80 FMT  
N o 2 Byte de dirección de destino  t t  TGT  
N o 3 Byte de dirección de origen  E E  SRC  
N o 4 Byte de longitud adicional  0 3  LEN  
N o 5 negative Response Service Id (SId 
de respuesta negativa)  7F NR  
N o 6 TesterPresent Request Service Identi­
fication (SId de petición de presencia 
de verificador)  3E T P  
N o 7 response­
Code =  [SubFunctionNotSup­
ported-InvalidFormat  12 RC_SFNS_IF  
incorrectMessage­
Length ]  13 RC_IML  
N o 8 Suma de control  00-FF  C S  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 366  
5. SERVICIOS DE ADMINISTRACIÓN  
Los servicios disponibles se describen con detalle en la siguie nte tabla:  
Tabla 13  
Servicios de administración  
Nombre del servicio  Descripción  
StartDiagnosticSession  El cliente solicita el comienzo de una sesión 
de diagnóstico con una VU.  
SecurityAccess  El cliente solicita acceso a las funciones res­
tringidas a usuarios autorizados.  
5.1. Servicio StartDiagnosticSession  
5.1.1  Descripción del mensaje  
CPR_025 El servicio StartDiagnosticSession sirve para activar d iferen­
tes sesiones de diagnóstico en el servidor. Una sesión de 
diagnóstico activa un conjunto específico de servicios de 
acuerdo con la Tabla 17. Una sesión puede activar servicios 
específicos de un fabricante de vehículos que no formen 
parte del presente documento. Las reglas de aplicación de­
berán cumplir los siguientes requisitos:  
— habrá siempre exactamente una sesión de diagnóstico 
activa en la VU;  
— la VU iniciará siempre la StandardDiagnosticSession al 
encendido. Si no se inicia ninguna otra sesión de diag­
nóstico, se estará ejecutando la StandardDiagnosticSes­
sion mientras la VU esté encendida;  
— si el verificador solicita una sesión de diagnóstico que se 
está ejecutando ya, la VU enviará un mensaje de res­
puesta positiva; y  
— cuando el verificador solicite una nueva sesión de diag­
nóstico, la VU enviará primero un mensaje de respuesta 
positiva StartDiagnosticSession antes de que la nueva 
sesión se active en la VU. Si la VU no puede iniciar 
la nueva sesión de diagnóstico solicitada, responderá con 
un mensaje de respuesta negativa StartDiagnosticSession 
y proseguirá la sesión ya activa.  
CPR_026 Solo se iniciará una sesión de diagnóstico si se ha est able­
cido comunicación entre el cliente y la VU.  
CPR_027 Los parámetros de sincronización definidos en la Tabla 4 
deberán estar activados tras comenzar la sesión de diagnós­
tico (StartDiagnosticSession). El parámetro diagnosticSes­
sion estará configurado a «StandardDiagnosticSession» (se­
sión normal) en el mensaje de petición si previamente estaba 
activada otra sesión de diagnóstico.  
5.1.2  Formato del mensaje  
CPR_028 En las siguientes tablas se describen con detalle los f ormatos 
de mensaje para las primitivas StartDiagnosticSession.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 367  
Tabla 14  
Mensaje StartDiagnosticSession Request (petición de inicio de la sesión de 
diagnóstico)  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 1 Byte de formato — asignación 
de dirección física  80 FMT  
N o 2 Byte de dirección de destino  E E  TGT  
N o 3 Byte de dirección de origen  t t  SRC  
N o 4 Byte de longitud adicional  0 2  LEN  
N o 5 StartDiagnosticSession Re ­
quest Service Id (SId de peti ­
ción de inicio de la sesión de 
diagnóstico)  10 STDS  
N o 6 diagnosticSession = [uno de 
los valores de la Tabla 17]  xx DS_…  
N o 7 Suma de control  00-FF  C S  
Tabla 15  
Mensaje StartDiagnosticSession Positive Response (respuesta positiva a la 
petición de inicio de la sesión dediagnóstico)  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 1 Byte de formato — asignación 
de dirección física  80 FMT  
N o 2 Byte de dirección de destino  t t  TGT  
N o 3 Byte de dirección de origen  E E  SRC  
N o 4 Byte de longitud adicional  0 2  LEN  
N o 5 StartDiagnosticSession Posi ­
tive Response Service Id 
(SId de respuesta positiva a 
la petición de inicio de la se ­
sión de diagnóstico)  50 STDSPR  
N o 6 diagnosticSession = [el mismo 
valor que en el byte n  o 6 de la 
Tabla 14]  xx DS_…  
N o 7 Suma de control  00-FF  C S  
Tabla 16  
Mensaje StartDiagnosticSession Negative Response (respuesta negativa a 
la petición de inicio de la sesiónde diagnóstico)  
N o de byte  Nombre del parámetro  Valor 
hex Mnemónico  
N o 1 Byte de formato — asignación de 
dirección física  80 FMT  
N o 2 Byte de dirección de destino  t t  TGT  
N o 3 Byte de dirección de origen  E E  SRC  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 368  
N o de byte  Nombre del parámetro  Valor 
hex Mnemónico  
N o 4 Byte de longitud adicional  0 3  LEN  
N o 5 Negative Response Service Id (SId 
de respuesta negativa)  7F NR  
N o 6 StartDiagnosticSession Request Ser­
vice Id (SId de petición de inicio 
de la sesión de diagnóstico)  10 STDS  
N o 7 Response­
Code =  [subFunctionNotSup­
ported (  α ) 12 RC_SFNS  
incorrectMessage­
Length (  β ) 13 RC_IML  
conditionsNotCo­
rrect (  γ ) 22 RC_CNC  
N o 8 Suma de control  00-FF  C S  
( α ) : no se admite el valor introducido en el byte n  o 6 del mensaje de petición, puesto 
que no figura en la Tabla 17. 
( β ) : la longitud del mensaje es incorrecta. 
( γ ) : no se cumplen los requisitos para la petición StartDiagnost icSession.  
5.1.3  Definición del parámetro  
CPR_029 El servicio StartDiagnosticSession utiliza el parámetro  diag­
nosticSession (DS_)  para seleccionar el comportamiento es­
pecífico del servidor o servidores. En el presente documento 
se especifican las siguientes sesiones de diagnóstico:  
Tabla 17  
Definición de valores de la sesión de diagnóstico  
Hex Descripción  Mnemónico  
81 StandardDiagnosticSession (sesión de diag ­
nóstico normal)  
Esta sesión de diagnóstico activa todos los 
servicios especificados en la  Tabla 1 , columna 
4 (SD) . Dichos servicios permiten la lectura de 
datos de un servidor (VU). Esta sesión de 
diagnóstico se activa después de haber finalizado 
con éxito la inicialización entre el cliente 
(verificador) y el servidor (VU). Es posible que 
otras sesiones de diagnóstico especificadas en 
este apartado sobrescriban esta sesión de diag- 
nóstico.  SD 
85 ECUProgrammingSession (sesión de progra ­
mación ECUPS)  
Esta sesión de diagnóstico activa todos los 
servicios especificados en la  Tabla 1 , columna 
6 (ECUPS) . Dichos servicios admiten la pro- 
gramación de memoria de un servidor (VU). Es 
posible que otras sesiones de diagnóstico espe- 
cificadas en este apartado sobrescriban esta 
sesión de diagnóstico.  ECUPS  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 369  
Hex Descripción  Mnemónico  
87 ECUAdjustmentSession (sesión de ajuste 
ECUA)  
Esta sesión de diagnóstico activa todos los 
servicios especificados en la  Tabla 1 , columna 
5 (ECUAS).  Dichos servicios admiten el control 
de entrada/salida de un servidor (VU). Es posible 
que otras sesiones de diagnóstico especificadas 
en este apartado sobrescriban esta sesión de 
diagnóstico.  ECUAS  
5.2. Servicio SecurityAccess  
No es posible escribir datos de calibrado a menos que la VU se en­
cuentre en el modo CALIBRADO. Para poder acceder al modo CALI­
BRADO es preciso insertar una tarjeta de taller válida y además  in­
troducir el PIN adecuado en la VU.  
También se podrá acceder a la línea de entrada/salida de calibr ado 
cuando la VU se encuentre en el modo CALIBRADO o CONTROL.  
El servicio SecurityAccess sirve como medio para introducir el PIN y 
para indicar al verificador si la VU se encuentra o no en el mo do 
CALIBRADO.  
El PIN también se puede introducir por otros métodos alternativ os. 
5.2.1  Descripción del mensaje  
El servicio SecurityAccess se compone de un mensaje SecurityAcc ess 
«requestSeed», seguido en su caso de un mensaje SecurityAccess 
«sendKey». El servicio SecurityAccess debe utilizarse después d el ser­
vicio StartDiagnosticSession.  
CPR_033 El verificador deberá utilizar el mensaje SecurityAcces s «re­
questSeed» para comprobar si la unidad instalada en el 
vehículo está preparada para aceptar un PIN.  
CPR_034 Si la unidad instalada en el vehículo ya se encuentra e n el 
modo CALIBRADO, deberá contestar a la petición en­
viando una «simiente» ( seed) de 0x0000, utilizando para 
ello el servicio SecurityAccess Positive Response.  
CPR_035 Si la unidad instalada en el vehículo está preparada pa ra 
aceptar un PIN para la verificación por parte de una tarjeta 
de taller, deberá contestar a la petición enviando una «si­
miente» ( seed) mayor que 0x0000, utilizando para ello el 
servicio SecurityAccess Positive Response.  
CPR_036 Si la unidad instalada en el vehículo no está preparada  para 
aceptar un PIN del verificador, ya sea porque la tarjeta de 
taller que se ha insertado no es válida, o porque no se ha 
insertado ninguna tarjeta, o porque la unidad espera el PIN 
de otro método, deberá contestar a la petición con una res­
puesta negativa, con un código de respuesta configurado a 
conditionsNotCorrectOrRequestSequenceError.  
CPR_037 A continuación, el verificador utilizará en su caso el men­
saje SecurityAccess «sendKey» para enviar un PIN a la 
unidad instalada en el vehículo. A fin de conceder tiempo 
suficiente para el proceso de autenticación de la tarjeta, la 
VU utilizará el código de respuesta negativa requestCorrect­
lyReceived-ResponsePending para ampliar el tiempo de res­
puesta. Sin embargo, el tiempo de respuesta máximo no  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 370  
excederá de cinco minutos. En cuanto finalice el servicio 
solicitado, la VU enviará un mensaje de respuesta positiva o 
un mensaje de respuesta negativa con un código de res­
puesta distinto de este. La VU podrá repetir el código de 
respuesta negativa requestCorrectlyReceived-ResponsePen­
ding hasta que finalice el servicio solicitado y se envíe el 
mensaje de respuesta final.  
CPR_038 La unidad instalada en el vehículo solamente deberá con tes­
tar a esta petición utilizando el servicio SecurityAccess Po­
sitive Response cuando se encuentre en el modo CALI­
BRADO.  
CPR_039 En los casos siguientes, la unidad instalada en el vehí culo 
deberá contestar a esta petición con una respuesta negativa 
con un código de respuesta configurado a:  
— subFunctionNotSupported: formato del parámetro de 
subfunción no válido (accessType);  
— conditionsNotCorrectOrRequestSequenceError: la unidad 
instalada en el vehículo no está lista para aceptar una 
entrada PIN;  
— invalidKey: el PIN no es válido y no se ha sobrepasado 
el número de intentos de verificación del PIN;  
— exceedNumberOfAttempts: el PIN no es válido y se ha 
sobrepasado el número de intentos de verificación del 
PIN; y  
— generalReject: el PIN es correcto pero ha fallado la au­
tenticación mutua con la tarjeta de taller.  
5.2.2  Formato del mensaje — SecurityAccess — requestSeed  
CPR_040 En las siguientes tablas se describen con detalle los f ormatos 
de mensaje para las primitivas SecurityAccess «reques­
tSeed» (petición de simiente).  
Tabla 18  
Mensaje SecurityAccess Request- requestSeed (petición de simiente)  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 1 Byte de formato — asignación 
de dirección física  80 FMT  
N o 2 Byte de dirección de destino  E E  TGT  
N o 3 Byte de dirección de origen  t t  SRC  
N o 4 Byte de longitud adicional  0 2  LEN  
N o 5 SecurityAccess Request Ser ­
vice Id (SId de petición de 
servicio SecurityAccess)  27 SA  
N o 6 accessType — requestSeed  7 D  AT_RSD  
N o 7 Suma de control  00-FF  C S  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 371  
Tabla 19  
Mensaje SecurityAccess — requestSeed Positive Response (respuesta 
positiva a la petición de simiente)  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 1 Byte de formato — asignación 
de dirección física  80 FMT  
N o 2 Byte de dirección de destino  t t  TGT  
N o 3 Byte de dirección de origen  E E  SRC  
N o 4 Byte de longitud adicional  0 4  LEN  
N o 5 SecurityAccess Positive Res ­
ponse Service Id (SId de res ­
puesta positiva a la petición 
de servicio SecurityAccess)  67 SAPR  
N o 6 accessType — requestSeed  7 D  AT_RSD  
N o 7 Seed High  00-FF  SEEDH  
N o 8 Seed Low  00-FF  SEEDL  
N o 9 Suma de control  00-FF  C S  
Tabla 20  
Mensaje SecurityAccess –requestSeed Negative Response (respuesta 
negativa a la petición de simiente)  
N o de byte  Nombre del parámetro  Valor 
hex Mnemónico  
N o 1 Byte de formato — asignación de 
dirección física  80 FMT  
N o 2 Byte de dirección de destino  t t  TGT  
N o 3 Byte de dirección de origen  E E  SRC  
N o 4 Byte de longitud adicional  0 3  LEN  
N o 5 NegativeResponse Service Id (SId 
de respuesta negativa)  7F NR  
N o 6 SecurityAccess Request Service Id 
(SId de petición de servicio Securit­
yAccess)  27 S A  
N o 7 response­
Code =  [conditionsNotCorrec­
tOrRequestSequen­
ceError  22 RC_CNC  
incorrectMessage­
Length]  13 RC_IML  
N o 8 Suma de control  00-FF  C S  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 372  
5.2.3  Formato del mensaje — SecurityAccess — sendKey  
CPR_041 En las siguientes tablas se describen con detalle los f ormatos 
de mensaje para las primitivas SecurityAccess «sendKey» 
(envío de clave).  
Tabla 21  
Mensaje SecurityAccess Request — sendKey (envío de clave)  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 1 Byte de formato — asignación 
de dirección física  80 FMT  
N o 2 Byte de dirección de destino  E E  TGT  
N o 3 Byte de dirección de origen  t t  SRC  
N o 4 Byte de longitud adicional  m+2  LEN  
N o 5 SecurityAccess Request Ser ­
vice Id (SId de petición de 
servicio SecurityAccess)  27 SA  
N o 6 accessType — sendKey  7 E  AT_SK  
N os 7 a 
m+6 Clave n  o 1 (alto)  x x  CLAVE  
… …  
Clave n  o m (bajo, m debe ser 
como mínimo 4 y como má­
ximo 8)  xx 
N o m+7 Suma de control  00-FF  C S  
Tabla 22  
Mensaje SecurityAccess — sendKey Positive Response (respuesta positiva 
a la petición de envío de clave)  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 1 Byte de formato — asignación 
de dirección física  80 FMT  
N o 2 Byte de dirección de destino  t t  TGT  
N o 3 Byte de dirección de origen  E E  SRC  
N o 4 Byte de longitud adicional  0 2  LEN  
N o 5 SecurityAccess Positive Res ­
ponse Service Id (SId de res ­
puesta positiva a la petición 
de servicio SecurityAccess)  67 SAPR  
N o 6 accessType — sendKey  7 E  AT_SK  
N o 7 Suma de control  00-FF  C S  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 373  
Tabla 23  
Mensaje SecurityAccess Negative Response (respuesta negativa)  
N o de byte  Nombre del parámetro  Valor 
hex Mnemónico  
N o 1 Byte de formato — asignación de 
dirección física  80 FMT  
N o 2 Byte de dirección de destino  t t  TGT  
N o 3 Byte de dirección de origen  E E  SRC  
N o 4 Byte de longitud adicional  0 3  LEN  
N o 5 NegativeResponse Service Id (SId 
de respuesta negativa)  7F NR  
N o 6 SecurityAccess Request Service Id 
(SId de petición de servicio Securit­
yAccess)  27 S A  
N o 7 Response­
Code =  [generalReject  1 0  RC_GR  
subFunctionNotSup­
ported  12 RC_SFNS  
incorrectMessage­
Length  13 RC_IML  
conditionsNotCorrec­
tOrRequestSequen­
ceError  22 RC_CNC  
invalidKey  3 5  RC_IK  
exceededNumberO­
fAttempts  36 RC_ENA  
requestCorrectlyRe­
ceived-ResponsePen­
ding]  78 RC_RCR_RP  
N o 8 Suma de control  00-FF  C S  
6. SERVICIOS DE TRANSMISIÓN DE DATOS  
Los servicios disponibles se describen con detalle en la siguie nte tabla:  
Tabla 24  
Servicios de transmisión de datos  
Nombre del servicio  Descripción  
ReadDataByIdentifier  El cliente solicita la transmisión del valor 
actual de un registro con acceso mediante 
recordDataIdentifier.  
WriteDataByIdentifier  El cliente solicita la escritura de un registro 
al que se acceda mediante recordDataIdenti­
fier. ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 374  
6.1. Servicio ReadDataByIdentifier  
6.1.1  Descripción del mensaje  
CPR_050 El cliente utiliza el servicio ReadDataByIdentifier par a leer 
valores de registros de datos de un servidor. Los datos se 
identifican con un recordDataIdentifier (identificador de da­
tos de registros). El fabricante de la VU es el responsable de 
que se cumplan las condiciones del servidor cuando se uti­
lice este servicio.  
6.1.2  Formato del mensaje  
CPR_051 En las siguientes tablas se describe con detalle los fo rmatos 
de mensaje para las primitivas ReadDataByIdentifier.  
Tabla 25  
Mensaje ReadDataByIdentifier Request (petición de servicio ReadDataB ­
yIdentifier)  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 1 Byte de formato — asignación 
de dirección física  80 FMT  
N o 2 Byte de dirección de destino  E E  TGT  
N o 3 Byte de dirección de origen  t t  SRC  
N o 4 Byte de longitud adicional  0 3  LEN  
N o 5 ReadDataByIdentifier Re ­
quest Service Id (SId de peti ­
ción de servicio ReadDataB ­
yIdentifier)  22 RDBI  
N os 6 a 7  recordDataIdentifier = [un va­
lor de la Tabla 28]  xxxx  RDI_…  
N o 8 Suma de control  00-FF  C S  
Tabla 26  
Mensaje ReadDataByIdentifier Positive Response (respuesta positiva a la 
petición de servicio ReadDataByIdentifier)  
N o de byte  Nombre del parámetro  Valor 
hex Mnemónico  
N o 1 Byte de formato — asignación de 
dirección física  80 FMT  
N o 2 Byte de dirección de destino  t t  TGT  
N o 3 Byte de dirección de origen  E E  SRC  
N o 4 Byte de longitud adicional  m+3  LEN  
N o 5 ReadDataByIdentifier Positive Res ­
ponse Service Id (SId de respuesta 
positiva a la petición de servicio 
ReadDataByIdentifier)  62 RDBIPR  
N os 6 y 7  recordDataIdentifier = [mismo valor 
que los bytes n  os 6 y 7 de la Tabla 
25] xxxx  RDI_…  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 375  
N o de byte  Nombre del parámetro  Valor 
hex Mnemónico  
N os 8 a 
m+7 dataRecord[] =  [data#1  x x  DREC_DAT­
A1 
: :  :  
data#m]  x x  DREC_DA­
TAm  
N o m+8 Suma de control  00-FF  C S  
Tabla 27  
Mensaje ReadDataByIdentifier Negative Response (respuesta negativa a la 
petición de servicioReadDataByIdentifier)  
N o de byte  Nombre del parámetro  Valor 
hex Mnemónico  
N o 1 Byte de formato — asignación de 
dirección física  80 FMT  
N o 2 Byte de dirección de destino  t t  TGT  
N o 3 Byte de dirección de origen  E E  SRC  
N o 4 Byte de longitud adicional  0 3  LEN  
N o 5 NegativeResponse Service Id (SId 
de respuesta negativa)  7F NR  
N o 6 ReadDataByIdentifier Request Ser­
vice Id (SId de petición de servicio 
ReadDataByIdentifier)  22 RDBI  
N o 7 Response­
Code=  [requestOutO­
fRange  31 RC_ROOR  
incorrectMessage­
Length  13 RC_IML  
conditionsNotCo­
rrect]  22 RC_CNC  
N o 8 Suma de control  00-FF  C S  
6.1.3  Definición del parámetro  
CPR_052 El parámetro  recordDataIdentifier (RDI_)  incluido en el 
mensaje ReadDataByIdentifier Request identifica un registro 
de datos.  
▼M3 
CPR_053 La siguiente tabla muestra los valores recordDataIdenti fier 
definidos en el presente documento.  
La tabla recordDataIdentifier tiene cinco columnas y múlti­
ples filas.  
— La  primera columna (Hex)  incluye el valor hexadeci­
mal asignado al recordDataIdentifier especificado en la 
tercera columna.  
— La  segunda columna (Elemento de datos)  especifica el 
elemento de datos del apéndice 1 en el que se basa el 
recordDataIdentifier (a veces es necesario transcodifi­
car). ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 376  
— La  tercera columna (Descripción)  especifica el nombre 
recordDataIdentifier correspondiente.  
— La  cuarta columna (Derechos de acceso)  especifica los 
derechos de acceso a este recordDataIdentifier.  
— La  quinta columna (Término nemónico)  especifica el 
término nemónico de este recordDataIdentifier.  
Tabla 28  
Definición de los valores recordDataIdentifier  
Hex Elemento de datos  recordDataIdentifier Nombre 
(véase el formato en el punto 8.2)  Derechos de 
acceso 
(Read/ 
Write)  Término nemónico  
F90B  CurrentDateTime  TimeDate  R/W  RDI_TD  
F912  HighResOdometer  HighResolutionTotalVehicle 
Distance  R/W  RDI_HRTVD  
F918  K-ConstantOfRecordingEquipment  Kfactor  R/W  RDI_KF  
F91C  L-TyreCircumference  LfactorTyreCircumference  R/W  RDI_LF  
F91D  W-VehicleCharacteristicConstant  WvehicleCharacteristicFactor  R/W  RDI_WVCF  
F921  TyreSize  TyreSize  R/W  RDI_TS  
F922  nextCalibrationDate  NextCalibrationDate  R/W  RDI_NCD  
F92C  SpeedAuthorised  SpeedAuthorised  R/W  RDI_SA  
F97D  vehicleRegistrationNation  RegisteringMemberState  R/W  RDI_RMS  
F97E  VehicleRegistrationNumber  VehicleRegistrationNumber  R/W  RDI_ VRN  
F190  VehicleIdentificationNumber  VIN  R/W  RDI_ VIN  
F9D0  SensorSerialNumber  MotionSensorSerialNumber  R  RDI_SSN  
F9D1  RemoteCommunicationModuleSerial­
Number  RemoteCommunication 
FacilitySerialNumber  R RDI_RCSN  
F9D2  SensorGNSSSerialNumber  ExternalGNSSFacilitySerial 
Number  R RDI_GSSN  
F9D3  SealDataVu  SmartTachographSeals 
SerialNumber  R/W  RDI_SDV  
F9D4  VuSerialNumber  VuSerialNumber  R  RDI_VSN  
F9D5  ByDefaultLoadType  ByDefaultLoadType  R/W  RDI_BDLT  
F9D6  TachographCardsGen1Suppression  TachographCardsGen1 
Suppression  R/W  RDI_TCG1S  
F9D7  VehiclePosition  VehiclePosition  R  RDI_VP  
F9D8  LastCalibrationCountry  CalibrationCountry  R  RDI_CC  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 377  
CPR_054 El mensaje ReadDataByIdentifier Positive Response utili za 
el parámetro  dataRecord (DREC_)  para facilitar al cliente 
(verificador) el valor del registro de datos identificado por e l 
recordDataIdentifier. Los formatos de datos se especifican 
en el apartado 8. Pueden aplicarse dataRecords de usuario 
adicionales opcionales, que incluyan datos específicos de la 
VU, tanto internos como de entrada y salida, pero no se 
definen en el presente documento.  
6.2. Servicio WriteDataByIdentifier  
6.2.1  Descripción del mensaje  
CPR_056 El cliente utiliza el servicio WriteDataByIdentifier pa ra es­
cribir valores de registros de datos en un servidor. Los datos 
se identifican con un recordDataIdentifier (identificador de 
datos de registros). El fabricante de la VU es el responsable 
de que se cumplan las condiciones del servidor cuando se 
utilice este servicio. Para actualizar los parámetros recogidos  
en la Tabla 28, la VU debe estar en el modo CALIBRADO.  
6.2.2  Formato del mensaje  
CPR_057 En las siguientes tablas se describen con detalle los f ormatos 
de mensaje para las primitivas WriteDataByIdentifier.  
Tabla 29  
Mensaje WriteDataByIdentifier Request (petición de servicio 
WriteDataByIdentifier)  
N o de byte  Nombre del parámetro  Valor 
hex Mnemónico  
N o 1 Byte de formato — asignación de 
dirección física  80 FMT  
N o 2 Byte de dirección de destino  E E  TGT  
N o 3 Byte de dirección de origen  t t  SRC  
N o 4 Byte de longitud adicional  m+3  LEN  
N o 5 WriteDataByIdentifier Request 
Service Id (SId de petición de ser ­
vicio WriteDataByIdentifier)  2E WDBI  
N os 6 a 7  recordDataIdentifier = [un valor de la 
Tabla 28]  xxxx  RDI_…  
N o 8 
a n  o m+7 dataRecord[] =  [data#1  x x  DREC_DAT­
A1 
: :  :  
data#m]  x x  DREC_DA­
TAm  
N o m+8 Suma de control  00-FF  C S  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 378  
Tabla 30  
Mensaje WriteDataByIdentifier Positive Response (respuesta positiva a la 
petición de servicio WriteDataByIdentifier)  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 1 Byte de formato — asignación 
de dirección física  80 FMT  
N o 2 Byte de dirección de destino  t t  TGT  
N o 3 Byte de dirección de origen  E E  SRC  
N o 4 Byte de longitud adicional  0 3  LEN  
N o 5 WriteDataByIdentifier Posi ­
tive Response Service Id 
(SId de respuesta positiva a 
la petición de servicio Write ­
DataByIdentifier)  6E WDBIPR  
N os 6 a 7  recordDataIdentifier = [mismo 
valor que los bytes n  os 6 y 7 
de la Tabla 29]  xxxx  RDI_…  
N o 8 Suma de control  00-FF  C S  
Tabla 31  
Mensaje WriteDataByIdentifier Negative Response (respuesta negativa a 
la petición de servicio WriteDataByIdentifier)  
N o de byte  Nombre del parámetro  Valor 
hex Mnemónico  
N o 1 Byte de formato — asignación de 
dirección física  80 FMT  
N o 2 Byte de dirección de destino  t t  TGT  
N o 3 Byte de dirección de origen  E E  SRC  
N o 4 Byte de longitud adicional  0 3  LEN  
N o 5 NegativeResponse Service Id (SId 
de respuesta negativa)  7F NR  
N o 6 WriteDataByIdentifier Request Ser­
vice Id (SId de petición de servicio 
WriteDataByIdentifier)  2E WDBI  
N o 7 ResponseCode 
= [requestOutO­
fRange  31 RC_ROOR  
incorrectMessage­
Length  13 RC_IML  
conditionsNotCo­
rrect]  22 RC_CNC  
N o 8 Suma de control  00-FF  C S  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 379  
6.2.3  Definición del parámetro  
El parámetro  recordDataIdentifier (RDI_)  se define en la Tabla 28.  
El parámetro  dataRecord (DREC_)  lo utiliza el mensaje de petición 
WriteDataByIdentifier para facilitar al servidor (VU) los valor es de 
registros de datos identificados por el recordDataIdentifier. L os forma­
tos de datos se especifican en el 8.  
7. CONTROL DE LOS IMPULSOS DE PRUEBA — UNIDAD FUN­
CIONAL PARA CONTROL DE ENTRADA/SALIDA  
Los servicios disponibles se describen con detalle en la siguie nte tabla:  
Tabla 32  
Unidad funcional para control de entrada/salida  
Nombre del servicio  Descripción  
InputOutputControlB­
yIdentifier  El cliente solicita el control de una entrada/ 
salida específica del servidor.  
7.1. Servicio InputOutputControlByIdentifier  
7.1.1  Descripción del mensaje  
Existe una conexión, a través del conector frontal, que permite  con­
trolar o efectuar un seguimiento de los impulsos de prueba util izando 
un verificador adecuado.  
CPR_058 Esta línea de señal I/O de calibrado se puede configura r con 
el comando de la línea K empleando el servicio InputOut­
putControlByIdentifier para seleccionar la función de en­
trada o salida que se precise para la línea. Los estados de 
la línea disponibles son:  
— desactivado;  
— speedSignalInput, donde se utiliza la línea de señal I/O 
de calibrado para introducir una señal de velocidad (se­
ñal de prueba) que sustituye a la señal de velocidad del 
sensor de movimiento. Esta función no está disponible 
en el modo CONTROL;  
— realTimeSpeedSignalOutputSensor, donde se utiliza la 
línea de señal I/O de calibrado para extraer la señal de 
velocidad del sensor de movimiento; y  
— RTCOutput, donde se utiliza la línea de señal I/O de 
calibrado para extraer la señal del reloj de TUC. Esta 
función no está disponible en el modo CONTROL.  
CPR_059 Para configurar el estado de la línea, la unidad instal ada en 
el vehículo tiene que haber entrado en una sesión de ajuste 
y debe estar en el modo CALIBRADO o CONTROL. 
Cuando la VU se encuentra en modo CALIBRADO, pueden 
seleccionarse los cuatro estados de la línea (desactivado, 
speedSignalInput, realTimeSpeedSignalOutputSensor y 
RTCOutput). Cuando la VU se encuentra en modo CON­
TROL, solo pueden seleccionarse dos estados de la línea 
(desactivado y realTimeSpeedSignalOutputSensor). Al salir 
de la sesión de ajuste o del modo CALIBRADO o CON­
TROL, la unidad instalada en el vehículo debe cerciorarse 
de que la línea de señal I/O vuelve al estado «desactivado» 
(por defecto).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 380  
CPR_060 Si se reciben impulsos de velocidad por la línea de ent rada 
de la VU para señales de velocidad en tiempo real y la línea 
de señal I/O de calibrado está configurada para transmitir 
entradas, entonces dicha línea de señal I/O deberá configu­
rarse para transmitir salidas o deberá volver al estado de 
desactivación.  
CPR_061 Se seguirá el orden siguiente:  
— establecer comunicación mediante el servicio StartCom­
munication;  
— entrar en una sesión de ajuste mediante el servicio Start­
DiagnosticSession y estar en el modo CALIBRADO o 
CONTROL (el orden de estas dos operaciones no es 
importante); y  
— cambiar el estado de la salida mediante el servicio In­
putOutputControlBylIdentifier.  
7.1.2  Formato del mensaje  
CPR_062 En las siguientes tablas se describen con detalle los f ormatos 
de mensaje para las primitivas InputOutputControlByIdenti­
fier. 
Tabla 33  
Mensaje InputOutputControlByIdentifier Request (petición de control de 
entrada/salida)  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 1 Byte de formato — asignación 
de dirección física  80 FMT  
N o 2 Byte de dirección de destino  E E  TGT  
N o 3 Byte de dirección de origen  t t  SRC  
N o 4 Byte de longitud adicional  x x  LEN  
N o 5 InputOutputControlByIden ­
tifier Request SId (SId de pe ­
tición de control de entrada/ 
salida)  2F IOCBI  
N os 6 y 7  InputOutputIdentifier = [Cali­
brationInputOutput]  F960  IOI_CIO  
N o 8 o 
n os 8 a 9  ControlOptionRecord = [  COR_…  
inputOutputControlParameter 
— un valor de la Tabla 36  xx IOCP_…  
controlState — un valor de la 
Tabla 37 (véase la nota a con­
tinuación)]  xx CS_…  
N o 9 o 10  Suma de control  00-FF  C S  
Nota:  el parámetro controlState solo está presente en algu­
nos casos (véase el apartado 7.1.3).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 381  
Tabla 34  
Mensaje InputOutputControlByIdentifier Positive Response (respuesta 
positiva a la petición de control deentrada/salida)  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 1 Byte de formato — asignación 
de dirección física  80 FMT  
N o 2 Byte de dirección de destino  t t  TGT  
N o 3 Byte de dirección de origen  E E  SRC  
N o 4 Byte de longitud adicional  x x  LEN  
N o 5 inputOutputControlByIdenti ­
fier Positive Response SId 
(SId de respuesta positiva a 
la petición de control de en ­
trada/salida)  6F IOCBIPR  
N os 6 y 7  inputOutputIdentifier = [Cali­
brationInputOutput]  F960  IOI_CIO  
N o 8 o 
n os 8 a 9  controlStatusRecord = [  CSR_  
inputOutputControlParameter 
(el mismo valor que en el byte 
n o 8 de la Tabla 33)  xx IOCP_…  
controlState (mismo valor que 
byte n  o 9 de la Tabla 33)] (en 
su caso)  xx CS_…  
N o 9 o 10  Suma de control  00-FF  C S  
Tabla 35  
Mensaje InputOutputControlByIdentifier Negative Response (respuesta 
negativa a la petición de control deentrada/salida)  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 1 Byte de formato — asignación 
de dirección física  80 FMT  
N o 2 Byte de dirección de destino  t t  TGT  
N o 3 Byte de dirección de origen  E E  SRC  
N o 4 Byte de longitud adicional  0 3  LEN  
N o 5 NegativeResponse Service Id 
(SId de respuesta negativa)  7F NR  
N o 6 inputOutputControlByIdentifier 
Request SId (SId de petición 
de control de entrada/salida)  2F IOCBI  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 382  
N o de byte  Nombre del parámetro  Valor hex  Mnemónico  
N o 7 responseCode=[  
incorrectMessageLength  1 3  RC_IML  
conditionsNotCorrect  2 2  RC_CNC  
requestOutOfRange  3 1  RC_ROOR  
deviceControlLimitsExceeded]  7 A  RC_DCLE  
N o 8 Suma de control  00-FF  C S  
7.1.3  Definición del parámetro  
CPR_064 El parámetro  inputOutputControlParameter (IOCP_)  se de­
fine en la siguiente tabla.  
Tabla 36  
Definición de los valores inputOutputControlParameter  
Hex Descripción  Mnemónico  
00 ReturnControlToECU  
Este valor deberá indicar al servidor (VU) que el 
verificador ya no tiene control sobre la línea de 
señal I/O de calibrado.  RCTECU  
01 ResetToDefault  
Este valor deberá indicar al servidor (VU) su 
obligación de reiniciar la señal de I/O de 
calibrado al estado que le corresponde por 
defecto.  RTD  
03 ShortTermAdjustment  
Este valor deberá indicar al servidor (VU) su 
obligación de ajustar la línea de señal de I/O de 
calibrado al valor incluido en el parámetro 
controlState.  STA  
CPR_065 El parámetro  controlState , definido en la siguiente tabla, 
solo está presente cuando el parámetro inputOutputControl­
Parameter se ha configurado a ShortTermAdjustment.  
Tabla 37  
Definición de valores controlState  
Modo  Valor hex  Descripción  
Desactivado  0 0  Línea I/O desactivada (estado por defecto)  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 383  
Modo  Valor hex  Descripción  
Activado  0 1  Línea I/O de calibrado activada como speed­
SignalInput  
Activado  0 2  Línea I/O de calibrado activada como real­
TimeSpeedSignalOutputSensor  
Activado  0 3  Línea I/O de calibrado activada como 
RTCOutput  
▼M3 
8. SERVICIO ROUTINECONTROL (AJUSTE DE LA HORA)  
8.1. Descripción del mensaje  
CPR_065a El servicio RoutineControl (TimeAdjustment) ofrece la ca­
pacidad de activar la alineación del reloj de la VU con la 
hora proporcionada por el receptor GNSS.  
Para la ejecución del servicio RoutineControl (TimeAdjus­
tment), la VU debe estar en el modo CALIBRADO.  
Condición previa : se garantiza que la VU es capaz de 
recibir mensajes de posición autenticados del receptor 
GNSS.  
Mientras esté en curso el ajuste de la hora, la VU respon­
derá a la petición RoutineControl, subfunción requestRou­
tineResults, con routineInfo = 0x78.  
Nota: el ajuste de la hora puede llevar algún tiempo. El 
verificador de diagnóstico solicitará el estado de ajuste de 
la hora utilizando la subfunción requestRoutineResults.  
8.2. Formato del mensaje  
CPR_065b Los formatos del mensaje para el servicio RoutineContr ol 
(TimeAdjustment) y sus primitivas se detallan en las tablas 
siguientes.  
Tabla 37a  
RoutineControl, mensaje de petición de la rutina (TimeAdjustment), subfunción startRoutine  
Byte #  Nombre del parámetro  Valor hex  Término nemó­
nico 
#1 Byte de formato – asignación de dirección física  8 0  FMT  
#2 Byte de dirección de destino  E E  TGT  
#3 Byte de dirección de origen  t t  SRC  
#4 Byte de longitud adicional  x x  LEN  
#5 RoutineControl Request Sid  (SID de la petición RoutineControl)  31  RC  
#6 routineControlType = [startRoutine]  0 1  RCTP_STR  
#7 y #8  routineIdentifier = [TimeAdjustment]  0100  RI_TA  
#9 Suma de control  00-FF  C S  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 384  
Tabla 37b  
RoutineControl, rutina (TimeAdjustment), subfunción startRoutine, mensaje de respuesta positiva  
Byte #  Nombre del parámetro  Valor hex  Término nemó­
nico 
#1 Byte de formato – asignación de dirección física  8 0  FMT  
#2 Byte de dirección de destino  t t  TGT  
#3 Byte de dirección de origen  E E  SRC  
#4 Byte de longitud adicional  x x  LEN  
#5 RoutineControl Positive Response Sid  (SID de respuesta positiva a 
RoutineControl)  71 RCPR  
#6 routineControlType = [startRoutine]  0 1  RCTP_STR  
#7 y #8  routineIdentifier= [TimeAdjustment]  0100  RI_TA  
#9 Suma de control  00-FF  C S  
Tabla 37c  
RoutineControl, mensaje de petición de la rutina (TimeAdjustment), subfunción requestRoutineResults  
Byte #  Nombre del parámetro  Valor hex  Término nemó­
nico 
#1 Byte de formato – asignación de dirección física  8 0  FMT  
#2 Byte de dirección de destino  E E  TGT  
#3 Byte de dirección de origen  t t  SRC  
#4 Byte de longitud adicional  x x  LEN  
#5 RoutineControl Request Sid  (SID de la petición RoutineControl)  31  RC  
#6 routineControlType = [requestRoutineResults]  0 3  RCTP_RRR  
#7 y #8  routineIdentifier= [TimeAdjustment]  0100  RI_TA  
#9 Suma de control  00-FF  C S  
Tabla 37d  
RoutineControl, rutina (TimeAdjustment), subfunción requestRoutineResults, mensaje de respuesta positiva  
Byte #  Nombre del parámetro  Valor hex  Término nemó­
nico 
#1 Byte de formato – asignación de dirección física  8 0  FMT  
#2 Byte de dirección de destino  t t  TGT  
#3 Byte de dirección de origen  E E  SRC  
#4 Byte de longitud adicional  x x  LEN  
#5 RoutineControl Positive Response Sid  (SID de respuesta positiva a 
RoutineControl)  71 RCPR  
#6 routineControlType = [requestRoutineResults]  0 3  RCTP_RRR  
#7 y #8  routineIdentifier= [TimeAdjustment]  0100  RI_TA  
#9 routineInfo (véase la tabla 37f)  X X  RINF_TA  
#10 routineStatusRecord[] = routineStatus#1 (véase la tabla 37g)  X X  RS_TA  
#11 Suma de control  00-FF  C S  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 385  
Tabla 37e  
RoutineControl, mensaje de respuesta negativa a la rutina (TimeAdjustment)  
Byte #  Nombre del parámetro  Valor hex  Término nemó­
nico 
#1 Byte de formato – asignación de dirección física  8 0  FMT  
#2 Byte de dirección de destino  t t  TGT  
#3 Byte de dirección de origen  E E  SRC  
#4 Byte de longitud adicional  0 3  LEN  
#5 negativeResponse Service Id  (SID de respuesta negativa)  7F  NR  
#6 inputOutputControlByIdentifier Request SId  3 1  RC  
#7 responseCode=[ 
sub-functionNotSupported 
incorrectMessageLengthOrInvalidFormat 
conditionsNotCorrect 
requestOutOfRange 
] 12 
13 
22 
31 SFNS 
IMLOIF 
CNC 
ROOR  
#8 Suma de control  00-FF  C S  
Tabla 37f  
RoutineControl, rutina(TimeAdjustment), routineInfo  
routineInfo  Valor hex  Descripción  
NormalExitWithResultAvailable  6 1  La rutina se ha ejecutado completamente; hay disponi­
bles otros resultados de la rutina.  
RoutineExecutionOngoing  7 8  La rutina solicitada sigue ejecutándose.  
Tabla 37g  
RoutineControl, rutina (TimeAdjustment), routineStatus  
Valor hex  Resultado del ensayo  Descripción  
01 positivo  El ajuste de la hora se ha terminado correctamente.  
02..0F  RFU  
10 negativo  No se recibe señal GNSS.  
11..7F  RFU  
80..FF  Específico del fabricante  
9. FORMATOS DATARECORDS  
En este punto se detallan:  
— las reglas generales que se aplicarán a los intervalos de los  paráme­
tros transmitidos por la unidad instalada en el vehículo al 
verificador,  
— los formatos que se utilizarán en los datos transferidos a tr avés de 
los servicios de transmisión de datos descritos en el punto 6.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 386  
CPR_067 La VU admitirá todos los parámetros identificados.  
CPR_068 Los datos transmitidos por la VU al verificador en resp uesta 
a un mensaje de petición serán del tipo medido (es decir, el 
valor actual del parámetro solicitado medido u observado 
por la VU).  
9.1. Intervalos de los parámetros transmitidos  
CPR_069 En la tabla 38 se definen los intervalos utilizados par a 
determinar la validez de un parámetro transmitido.  
CPR_070 Los valores del intervalo «indicador de error» sirven p ara 
que la unidad instalada en el vehículo indique inmediata­
mente que no dispone en ese momento de datos paramé­
tricos válidos por causa de algún tipo de error en el tacó­
grafo.  
CPR_071 Los valores del intervalo «no disponible» sirven para q ue la 
unidad instalada en el vehículo transmita un mensaje que 
contiene un parámetro que no está disponible o no está 
admitido en ese módulo. Los valores del intervalo «no 
solicitado» constituyen un medio para que un dispositivo 
transmita un mensaje de comando e identifique para qué 
parámetros no se espera respuesta del dispositivo receptor.  
CPR_072 Si el fallo de un componente impide la transmisión de d atos 
válidos para un parámetro, conviene utilizar en lugar de 
dichos datos el indicador de error descrito en la tabla 38. 
Sin embargo, si los datos medidos o calculados adquieren 
un valor que es válido, pero que excede del intervalo defi­
nido para el parámetro, no conviene utilizar el indicador de 
error. Los datos deberían transmitirse utilizando el valor 
mínimo o máximo del parámetro, según proceda.  
Tabla 38  
Intervalos dataRecords  
Nombre del intervalo  1 byte 
(valor hex)  2 bytes 
(valor hex)  4 bytes 
(valor hex)  ASCII  
Señal válida  00 a FA  0000 a FAFF  00000000 a FAFFFFFF  1 a 254  
Indicador específico del parámetro  F B  FB00 a FBFF  FB000000 a FBFFFFFF  ninguno  
Reservado para futuros bits de indi­
cador  FC a FD  FC00 a FDFF  FC000000 a FDFFFFFF  ninguno  
Indicador de error  F E  FE00 a FEFF  FE000000 a FEFFFFFF  0  
No disponible o no solicitado  F F  FF00 a FFFF  FF000000 a FFFFFFFF  F F  
CPR_073 Para los parámetros codificados en ASCII, el carácter A S­
CII «*» está reservado como delimitador.  
9.2. Formatos dataRecords  
De la tabla 39 a la tabla 42 se detallan los formatos que se us arán a 
través de los servicios ReadDataByIdentifier y WriteDataByIdent ifier. ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 387  
CPR_074 En la tabla 39 se ofrecen la longitud, la resolución y el 
intervalo operativo de cada parámetro identificado por su 
recordDataIdentifier:  
Tabla 39  
Formato de dataRecords  
Nombre del parámetro  Longitud de 
dato (bytes)  Resolución  Intervalo operativo  
TimeDate  8  Véanse los detalles en la tabla 40  
HighResolutionTotalVehicleDis­
tance  4 ganancia 5 m/bit, desfase 0 m  0 a +21 055 406 km  
Kfactor  2  ganancia 0,001 pulsos/m/bit, 
desfase 0  0 a 64,255 pulsos/m  
LfactorTyreCircumference  2  ganancia 0,125 10  -3 m/bit, 
desfase 0  0 a 8,031 m  
WvehicleCharacteristicFactor  2  ganancia 0,001 pulsos/m/bit, 
desfase 0  0 a 64,255 pulsos/m  
TyreSize  1 5  ASCII  ASCII  
NextCalibrationDate  3  Véanse los detalles en la tabla 41  
SpeedAuthorised  2  ganancia 1/256 km/h/bit, 
desfase 0  0 a 250,996 km/h  
RegisteringMemberState  3  ASCII  ASCII  
VehicleRegistrationNumber  1 4  Véanse los detalles en la tabla 42  
VIN 1 7  ASCII  ASCII  
SealDataVu  5 5  Véanse los detalles en la tabla 43  
ByDefaultLoadType  1  Véanse los detalles en la tabla 44  
VuSerialNumber  8  Véanse los detalles en la tabla 45  
SensorSerialNumber  8  Véanse los detalles en la tabla 45  
SensorGNSSSerialNumber  8  Véanse los detalles en la tabla 45  
RemoteCommunicationModuleSe­
rialNumber  8 Véanse los detalles en la tabla 45  
TachographCardsGen1Suppression  2  Véanse los detalles en la tabla 46  
VehiclePosition  1 4  Véanse los detalles en la tabla 47  
CalibrationCountry  3  ASCII  NationAlpha según se 
define en el apéndice 1  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 388  
CPR_075 En la tabla 40 se detallan los formatos de los distinto s bytes 
del parámetro TimeDate:  
Tabla 40  
Formato detallado de TimeDate (valor recordDataIdentifier # F90B)  
Byte  Definición del parámetro  Resolución  Intervalo operativo  
1 Segundos  ganancia 0,25 s/bit, desfase 0 s  0 a 59,75 s  
2 Minutos  ganancia 1 min/bit, desfase 0 min  0 a 59 min  
3 Horas  ganancia 1 h/bit, desfase 0 h  0 a 23 h  
4 Mes  ganancia 1 mes/bit, desfase 0 meses  1 a 12 meses  
5 Día  ganancia 0,25 días/bit, desfase 0 días (véase la 
Nota de la tabla 41)  0,25 a 31,75 días  
6 Año  ganancia 1 año/bit, desfase año + 1985 
(véase la Nota de la tabla 41)  años 1985 a 2235  
7 Desfase local de los minu­
tos ganancia 1 min/bit, desfase – 125 min  - 59 a + 59 min  
8 Desfase local de las horas  ganancia 1 h/bit, desfase – 125 h  – 23 a + 23 h  
CPR_076 En la tabla 41 se detallan los formatos de los distinto s bytes 
del parámetro NextCalibrationDate:  
Tabla 41  
Formato detallado de NextCalibrationDate (valor recordDataIdentifier # F922)  
Byte  Definición del parámetro  Resolución  Intervalo operativo  
1 Mes  ganancia 1 mes/bit, desfase 0 meses  1 a 12 meses  
2 Día  ganancia 0,25 días/bit, desfase 0 días (véase la 
Nota a continuación)  0,25 a 31,75 días  
3 Año  ganancia 1 año/bit, desfase año + 1985 
(véase la Nota a continuación)  años 1985 a 2235  
Nota relativa al uso del parámetro «Día»:  
1) El valor 0 para la fecha es nulo. Los valores 1, 2, 3 y 4 se  utilizan 
para identificar el primer día del mes; 5, 6, 7 y 8 para el seg undo; 
etc. 
2) Este parámetro no influye el parámetro de horas ni lo modifi ca. 
Nota relativa al uso del pará­
metro «Año»:  
el valor 0 para el año identifica el año 1985; el valor 1, el a ño 1986; 
etc. ▼M3
02016R0799 — ES — 21.08.2023 — 003.001 — 389  
CPR_078 En la tabla 42 se detallan los formatos de los distinto s bytes 
del parámetro VehicleRegistrationNumber:  
Tabla 42  
Formato detallado de VehicleRegistrationNumber (valor recordDataIdentifier # F97E)  
Byte  Definición del parámetro  Resolución  Intervalo operativo  
1 Página de código (según se define en el 
apéndice 1)  No aplicable  VehicleRegistrationNumber  
2 – 14  Número de matrícula del vehículo (según se 
define en el apéndice 1)  No aplicable  VehicleRegistrationNumber  
CPR_090 En la tabla 43 se detallan los formatos de los distinto s bytes 
del parámetro SealDataVu:  
Tabla 43  
Formato detallado de SealDataVu (valor recordDataIdentifier # F9D3)  
Byte  Definición del parámetro  Resolución  Intervalo operativo  
1 – 11  sealRecord1. Formato SealRecord según se 
define en el apéndice 1.  No aplicable  SealRecord  
12 - 22  sealRecord2. Formato SealRecord según se 
define en el apéndice 1.  No aplicable  SealRecord  
23 – 33  sealRecord3. Formato SealRecord según se 
define en el apéndice 1.  No aplicable  SealRecord  
34 – 44  sealRecord4. Formato SealRecord según se 
define en el apéndice 1.  No aplicable  SealRecord  
45 – 55  sealRecord5. Formato SealRecord según se 
define en el apéndice 1.  No aplicable  SealRecord  
NOTA:  Si hay menos de cinco precintos disponibles, el 
valor de EquipmentType en todos los sealRecords no utili­
zados se ajustará en 15, es decir, sin utilizar.  
CPR_091 En la tabla 44 se detallan los formatos de los distinto s bytes 
del parámetro ByDefaultLoadType:  
Tabla 44  
Formato detallado de ByDefaultLoadType (valor recordDataIdentifier # F9D5)  
Byte  Definición del parámetro  Resolución  Intervalo operativo  
1 loadType 
«00»H: Tipo de carga indefinido 
«01»H: Mercancías 
«02»H: Pasajeros  No aplicable  «00»H a «02»H  
CPR_092 En la tabla 45 se detallan los formatos de los distinto s bytes 
de los parámetros VuSerialNumber, SensorSerialNumber, 
SensorGNSSSerialNumber y RemoteCommunicationModu­
leSerialNumber:  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 390  
Tabla 45  
Formato detallado de VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber y 
RemoteCommunicationModuleSerialNumber (valores recordDataIdentifier # F9D4, F9D0, F9D2 y F9D1)  
Byte  Definición del parámetro  Resolución  Intervalo operativo  
1 VuSerialNumber, SensorSerialNumber, Sen­
sorGNSSSerialNumber y RemoteCommuni­
cationModuleSerialNumber: 
Formato ExtendedSerialNumber según se de­
fine en el apéndice 1.  No aplicable  ExtendedSerialNumber  
CPR_093 En la tabla 46 se detallan los formatos de los distinto s bytes 
del parámetro TachographCardsGen1Suppression:  
Tabla 46  
Formato detallado de TachographCardsGen1Suppression (valor recordDataIdentifier # F9D6)  
Byte  Definición del parámetro  Resolución  Intervalo operativo  
1-2 TachographCardsGen1Suppression. Formato 
TachographCardsGen1Suppression según se 
define en el apéndice 1.  No aplicable  «0000»H, «A5E3»H  
CPR_094 En la tabla 47 se detallan los formatos de los distinto s bytes 
del parámetro VehiclePosition:  
Tabla 47  
Formato detallado de VehiclePosition (valor recordDataIdentifier # F9D7)  
Byte  Definición del parámetro  Resolución  Intervalo operativo  
1 - 4  Se ha determinado el sello de tiempo de la 
posición del vehículo.  No aplicable  TimeReal  
5 Exactitud del GNSS  No aplicable  GNSSAccuracy  
6 - 11  Posición del vehículo  No aplicable  GeoCoordinates  
12 Estado de autenticación  No aplicable  PositionAuthenticationStatus  
13 País actual  No aplicable  NationNumeric  
14 Región actual  No aplicable  RegionNumeric  
Nota:  tras actualizar la posición del vehículo, la actualización del  país 
y la región actuales puede retrasarse.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 391  
Apéndice 9.  
HOMOLOGACIÓN LISTA DE PRUEBAS MÍNIMAS REQUERIDAS  
ÍNDICE  
1. INTRODUCCIÓN  
2. PRUEBAS FUNCIONALES DE LA UNIDAD INSTALADA EN EL VE­ 
HÍCULO  
3. PRUEBAS FUNCIONALES DEL SENSOR DE MOVIMIENTO  
4. PRUEBAS FUNCIONALES DE LAS TARJETAS DE TACÓGRAFO  
5. PRUEBAS DEL DISPOSITIVO GNSS EXTERNO  
▼M1 
6. PRUEBAS DEL DISPOSITIVO DE COMUNICACIÓN A DISTANCIA 
EXTERNO  
▼B 
7. PRUEBAS FUNCIONALES DEL PAPEL  
8. PRUEBAS DE INTEROPERABILIDAD  
▼M3 
9. PRUEBAS OSNMA  
▼B 
1. INTRODUCCIÓN  
1.1. Homologación  
La homologación CE de un aparato de control (o componente) o de  una 
tarjeta de tacógrafo se basa en:  
▼M1 
— una  certificación de seguridad  basada en criterios comunes especifi­
cados para acreditar el cumplimiento de un objetivo de segurida d 
conforme al apéndice 10 del presente anexo;  
▼B 
— una  certificación funcional , realizada por una autoridad de un Estado 
miembro, para certificar que el elemento sujeto a verificación cumple 
los requisitos del presente anexo en cuanto a las funciones que  de­
sempeña, la exactitud de medición y las características medioam bien­
tales; y  
— una  certificación de interoperabilidad , realizada por un organismo 
competente, para garantizar que el aparato de control (o la tar jeta de 
tacógrafo) puede interoperar sin restricciones con los modelos necesa­
rios de tarjeta de tacógrafo (o aparato de control) (véase el a partado 8 
del presente anexo).  
En el presente apéndice se especifican las pruebas mínimas que debe 
realizar la autoridad del Estado miembro durante los ensayos fu ncionales, 
así como las pruebas mínimas que debe realizar el organismo com petente 
durante los ensayos de interoperabilidad. No se determina el ti po de 
pruebas ni los procedimientos a seguir durante las mismas.  
El presente apéndice no se ocupa de los aspectos relativos a la  certifica­
ción de seguridad. Si durante la evaluación de seguridad y el p roceso de 
certificación se llevan a cabo algunas de las pruebas exigidas para la 
homologación, no habrá que repetirlas posteriormente. En ese ca so, tan 
solo se comprobarán los resultados de dichas pruebas de segurid ad. A 
título informativo, en el presente apéndice hemos marcado con u n aste­
risco («*») las condiciones que es preciso verificar (y también  las condi­
ciones estrechamente asociadas con pruebas que deban realizarse ) durante 
la certificación de seguridad.  
Los requisitos numerados se refieren al contenido de este anexo , mientras 
que el resto de requisitos se refieren al resto de apéndices (p or ejemplo, 
PIC_001 se refiere al requisito PIC_001 del apéndice 3 (pictogr amas)).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 392  
El presente apéndice trata por separado la homologación del sen sor de 
movimiento, de la unidad instalada en el vehículo y del disposi tivo GNSS 
externo como componentes del aparato de control. Cada uno de lo s com­
ponentes recibirá un certificado de homologación propio, en el que se 
indicarán el resto de componentes compatibles. La prueba de fun cionali­
dad del sensor de movilidad (o del dispositivo GNSS externo) se  realiza 
junto con la unidad instalada en el vehículo, y al contrario.  
No se requiere interoperabilidad entre el sensor de movimiento (o el 
dispositivo GNSS externo) y cada modelo de la unidad instalada en el 
vehículo. En este caso, únicamente puede concederse la homologa ción de 
un sensor de movimiento (o de un dispositivo GNSS externo) en c ombi­
nación con el tipo de aprobación de la unidad instalada en el v ehículo 
pertinente, y al contrario.  
▼M3 
La autoridad de los Estados miembros encargada de las pruebas f uncio­
nales de una unidad instalada en el vehículo o de un dispositiv o GNSS 
externo debe asegurarse de que el receptor GNSS integrado haya superado 
con éxito las pruebas OSNMA especificadas en el presente apéndi ce. Esas 
pruebas se consideran parte de las pruebas funcionales de la un idad ins­
talada en el vehículo o del dispositivo GNSS externo.  
▼B 
1.2. Referencias  
En el presente apéndice aparecen las siguientes referencias:  
IEC 60068-2-1: Verificación medioambiental — Parte 2-1: Pruebas  —  
Prueba A: Frío.  
IEC 60068-2-2: Procedimientos básicos de verificación medioambi ental; 
Parte 2: pruebas; Prueba B: Calor seco (sinusoidal).  
IEC 60068-2-6: Verificación medioambiental — Parte 2: Pruebas —  
Prueba Fc: Vibración.  
IEC 60068-2-14: Verificación medioambiental — Parte 2-14: Prueb as — 
Prueba N: Variaciones de la temperatura.  
IEC 60068-2-27: Pruebas ambientales Parte 2: Pruebas. Prueba Ea  y  
orientación: Choque.  
IEC 60068-2-30: Verificación medioambiental — Parte 2-30: Prueb as — 
Prueba Db: Calor húmedo, cíclico (ciclo de 12 + 12 horas).  
IEC 60068-2-64: Verificación medioambiental — Parte 2-64: Prueb as — 
Prueba Fh: Vibración, aleatorio de banda ancha y orientación.  
IEC 60068-2-78 Verificación medioambiental — Parte 2-78: Prueba s — 
Prueba Cab: Calor húmedo, estado estable.  
ISO 16750-3 Cargas mecánicas (2012-12).  
ISO 16750-4 Cargas climáticas (2010-04).  
ISO 20653: Vehículos de carretera — Niveles de protección (códi go IP) — 
Protección del equipo eléctrico frente a objetos extraños, al a gua y al acceso.  
ISO 10605:2008 + Corrigendum técnico 2010 + AMD1: 2014 Vehículo s 
de carretera — Métodos de prueba para perturbaciones eléctricas  por 
descarga electrostática.  
ISO 7637-1:2002 + AMD1: 2008 Vehículos de carretera — Perturbac io­
nes eléctricas por conducción y acoplamiento — Parte 1: Definic iones y 
consideraciones generales.  
ISO 7637-2 Vehículos de carretera — Perturbaciones eléctricas p or con­
ducción y acoplamiento — Parte 2: Conducción eléctrica transito ria por 
líneas de alimentación exclusivamente.  
ISO 7637-3 Vehículos de carretera — Perturbaciones eléctricas p or con­
ducción y acoplamiento — Parte 3: Transmisión eléctrica transit oria me­
diante acoplamiento capacitivo e inductivo por líneas que no se an de 
alimentación.  
ISO/IEC 7816-1 Tarjetas de identificación — Tarjetas de circuit o(s) inte­
grado(s) con contactos — Parte 1: Características físicas.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 393  
ISO/IEC 7816-2 Tecnología de la información — Tarjetas de ident ifica­
ción — Tarjetas de circuito(s) integrado(s) con contactos — Par te 2: 
Dimensiones y ubicación de los contactos.  
ISO/IEC 7816-3 Tecnología de la información — Tarjetas de ident ifica­
ción — Tarjetas de circuito(s) integrado(s) con contactos –Part e 3: Señales 
electrónicas y protocolo de transmisión.  
ISO/IEC 10373-1:2006 + AMD1:2012 Tarjetas de identificación — M é­
todos de prueba — Parte 1: Características generales  
ISO/IEC 10373-3:2010 + Corrigendum técnico 2013 Tarjetas de ide ntifi­
cación — Métodos de prueba — Parte 3: Tarjetas de circuitos int egrados 
con contactos y dispositivos de interfaz relacionados  
ISO 16844-3:2004, Cor 1:2006 Vehículos de carretera — Sistemas de 
tacógrafo — Parte 3: Interfaz del sensor de movimiento (con las  unidades 
intravehiculares).  
ISO 16844-4 Vehículos de carretera — Sistemas de tacógrafo — Pa rte 4: 
Interfaz CAN  
ISO 16844-6 Vehículos de carretera — Sistemas de tacógrafo — Pa rte 6: 
Diagnóstico  
ISO 16844-7 Vehículos de carretera — Sistemas de tacógrafo — Pa rte 7: 
Parámetros  
ISO 534 Papel y cartón — Fijación del grosor, la densidad y el volumen 
específico  
▼M3 
RGODP Informe ténico del JRC:  Receiver guidelines for OSNMA data 
processing  (Directrices del receptor para el procesamiento de datos OS­
NMA)  
▼B 
Reglamento CEPE n  o 10 sobre homologación de vehículos respecto a la 
compatibilidad electromagnética (Comisión Económica para Europa  de las 
Naciones Unidas)  
2. PRUEBAS FUNCIONALES DE LA UNIDAD INSTALADA EN EL 
VEHÍCULO  
▼M1 
N. o Prueba  Descripción  Condiciones correspondientes  
1. Examen administrativo  
1.1 Documentación  Corrección de la documentación  
1.2 Resultados de las prue­
bas del fabricante  Resultados de la prueba realizada por el fa­
bricante durante la integración. 
Demostraciones sobre papel.  88, 89, 91  
2. Inspección visual  
2.1 Cumplimiento de lo dispuesto en la documentación  
2.2 Identificación/inscripciones  224 a 226  
2.3 Materiales  219 a 223  
2.4 Precintos  398, 401 a 405  
2.5 Interfaces externas  
3. Pruebas funcionales  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 394  
N. o Prueba  Descripción  Condiciones correspondientes  
▼M3 
3.1 Funciones disponibles  02, 03, 04, 05, 07, 382,  
3.2 Modos de funcionamiento  09 a 11*, 134, 135  
3.3 Funciones y derechos de acceso a los datos  12*, 13*, 382, 383, 386 a 389  
3.4 Supervisión de la inserción y extracción de tarjetas  15, 16, 17, 18, 19*, 20*, 134  
3.5 Medición de la velocidad, la posición y la distancia  21 a 37  
3.6 Medición de la hora (ensayo realizado a 20 °C)  38 a 43  
3.7 Supervisión de las actividades del conductor  44 a 53, 134  
3.8 Supervisión del régimen de conducción  54, 55, 134  
3.9 Entradas de los conductores  56 a 62  quater  
3.10 Gestión de los bloqueos introducidos por las empresas  63 a 68  
3.11 Supervisión de las actividades de control  69, 70  
3.12 Detección de incidentes o fallos  71 a 88  bis, 134  
3.13 Datos de identificación del aparato  93*, 94*, 97, 100  
3.14 Datos de inserción y extracción de la tarjeta de conductor o d e la tarjeta 
de taller  102* a 104*  
3.15 Datos sobre la actividad del conductor  105* a 107*  
3.16 Datos sobre lugares y posiciones  108* a 112*  
3.17 Datos del cuentakilómetros  113* a 115*  
3.18 Datos pormenorizados sobre la velocidad  116*  
3.19 Datos sobre incidentes  117*  
3.20 Datos sobre fallos  118*  
3.21 Datos de calibrado  119* a 121*  
3.22 Datos de ajuste de la hora  124*, 125*  
3.23 Datos sobre actividades de control  126*, 127*  
3.24 Datos sobre los bloqueos introducidos por las empresas  128*  
3.25 Datos sobre actividades de transferencia  129*  
3.26 Datos sobre condiciones específicas  130*, 131*  
3.27 Datos de las tarjetas de tacógrafo  132*, 133*  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 395  
N. o Prueba  Descripción  Condiciones correspondientes  
3.28 Cruces de fronteras  133  bis* a 133  quinquies * 
3.29 Operación de carga/descarga  133  sexies * a 133  decies * 
3.30 Mapa digital  133  undecies * a 133  unvicies * 
3.31 Registro y almacenamiento de datos en tarjetas de tacógrafo  136, 137, 138*, 139*, 141*, 
142, 143 
144, 145, 146*, 147*, 
147 bis *, 147  ter *, 148*, 
149, 150, 150  bis 
3.32 Visualización  90, 134, 
151 a 168, 
PIC_001, DIS_001  
3.33 Impresión  90, 134, 
169 a 181, PIC_001, PRT_001 
a PRT_014  
3.34 Advertencia  134, 182 a 191, 
PIC_001  
3.35 Transferencia de datos a medios externos  90, 134, 192 a 196  
3.36 Comunicación remota para pruebas en carretera específicas  197 a 199  
3.37 Intercambios de datos con dispositivos externos adicionales  200, 201  
3.38 Calibrado  202 a 206*, 383, 384, 386 
a 391  
3.39 Verificación del calibrado en carretera  207 a 209  
3.40 Ajuste de la hora  210 a 212*  
3.41 Seguimiento de los cruces de fronteras  226  bis a 226  quater  
3.42 Actualización del  software  226  quinquies  a 226  septies  
3.43 No interferencia con funciones adicionales  06, 425  
3.44 Interfaz del sensor de movimiento  02, 122  
3.45 Dispositivo GNSS externo  03, 123  
3.46 Comprobar si la VU detecta, registra y almacena el o los incid entes o 
fallos descritos por el fabricante de la VU cuando un sensor de  movi­
miento emparejado reacciona a los campos magnéticos que perturb an la 
detección de movimiento del vehículo.  217 
3.47 Serie de cifrado y parámetros de dominio estandarizados  CSM_48, CSM_50  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 396  
N. o Prueba  Descripción  Condiciones correspondientes  
4. Pruebas ambientales  
4.1 Temperatura  Verificar la funcionalidad mediante: 
Prueba en virtud de la ISO 16750-4, apar­
tado 5.1.1.2: prueba de funcionamiento a 
temperatura baja (72 h a – 20 °C). 
Esta prueba se refiere a la IEC 60068-2-1: 
Verificación medioambiental – Parte 2-1: 
Pruebas – Prueba A: Frío 
Prueba en virtud de la ISO 16750-4: apar­
tado 5.1.2.2: prueba de funcionamiento a 
temperatura alta (72 h a 70 °C). 
Esta prueba se refiere a la IEC 60068-2-2: 
Procedimientos básicos de verificación me­
dioambiental; Parte 2: pruebas; Prueba B: 
Calor seco. 
Prueba en virtud de la ISO 16750-4, apar­
tado 5.3.2: cambio rápido de temperatura 
con una duración de transición específica (– 
20 °C/70 °C, 20 ciclos, tiempo: 2 horas en 
cada temperatura). 
Es posible llevar a cabo un conjunto redu­
cido de pruebas (de entre las que se definen 
en la sección 3 de esta tabla) a la tempera­
tura más baja, a la temperatura más alta y 
durante los ciclos de temperatura.  213 
4.2 Humedad  Verificar que la unidad instalada en el vehí­
culo puede soportar una humedad cíclica 
(prueba de calor) mediante la norma IEC 
60068-2-30, prueba Db, seis ciclos de 24 
horas, con una variación de temperatura de 
+ 25 °C a + 55 °C en cada caso y una hu­
medad relativa del 97 % a + 25 °C y del 
93 % a + 55 °C.  214 
4.3 Mecánica  1. Vibraciones sinusoidales: 
verificar que la unidad instalada en el 
vehículo es capaz de soportar vibraciones 
sinusoidales de las siguientes característi­
cas: 
desplazamiento constante entre 5 y 11 
Hz: pico de 10 mm; y 
aceleración constante entre 11 y 300 Hz: 
5 g. 
Esta exigencia se verifica mediante la 
norma IEC 60068-2-6, prueba Fc, con 
una duración mínima de 3 × 12 horas 
(12 horas por cada eje). 
La ISO 16750-3 no requiere una prueba 
de vibración sinusoidal para dispositivos 
situados en el puesto de conducción del 
vehículo desacoplado. 
2. Vibraciones aleatorias: 
Prueba en virtud de la ISO 16750-3, 
apartado 4.1.2.8: prueba VIII: vehículo 
comercial, puesto de conducción del ve­
hículo desacoplado.  219 ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 397  
N. o Prueba  Descripción  Condiciones correspondientes  
Prueba de vibraciones aleatorias, 10-2 000 
Hz, RMS vertical 21,3 m/s  2 , RMS longitu­
dinal 11,8 m/s  2 , RMS lateral 13,1 m/s  2 , 3 
ejes, 32 horas por eje, incluido un ciclo de 
temperatura – 20 - + 70 °C. 
Esta prueba se refiere a la IEC 60068-2-64: 
Verificación medioambiental – Parte 2-64: 
Pruebas – Prueba Fh: Vibración, aleatorio 
de banda ancha y orientación. 
3. Choques: 
choque mecánico con semionda sinusoi­
dal de 3 g de conformidad con la ISO 
16750. 
Las pruebas arriba descritas se llevan a cabo 
con muestras diferentes del tipo de equipo 
que se someta a prueba.  
4.4 Protección frente a la 
penetración de agua y 
cuerpos extraños  Prueba en virtud de la ISO 20653: Vehículos 
de carretera – Niveles de protección (código 
IP) – Protección del equipo eléctrico frente a 
objetos extraños, al agua y al acceso (sin 
cambio en los parámetros); valor mínimo IP 
40. 220, 221  
4.5 Protección frente a so­
bretensiones  Verificar que la unidad instalada en el vehí­
culo es capaz de soportar un suministro eléc­
trico de: 
versiones de 24 V: 34 V a + 40 °C 1 
hora; y 
versiones de 12 V: 17 V a + 40 °C 1 
hora. 
(ISO 16750-2)  216 
4.6 Protección frente a la 
inversión de la polari­
dad Verificar que la unidad instalada en el vehí­
culo es capaz de soportar una inversión de 
su fuente de alimentación. 
(ISO 16750-2)  216 
4.7 Protección frente a cor­
tocircuitos  Verificar que las señales de entrada y de 
salida están protegidas frente a cortocircuitos 
a la fuente de alimentación y a masa. 
(ISO 16750-2)  216 
5. Pruebas de compatibilidad electromagnética  
5.1 Emisiones radiadas y 
susceptibilidad  Cumplimiento del Reglamento n.  o 10 de la 
CEPE.  218 
5.2 Descarga electrostática  Cumplimiento de la norma ISO 10605:2008 
+ 
Corrigendum Técnico 2010 + 
AMD1:2014: +/– 4 kV para contacto +/– 
8 kV para descarga de aire.  218 ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 398  
N. o Prueba  Descripción  Condiciones correspondientes  
5.3 Susceptibilidad transi­
toria conducida en la 
fuente de alimentación  Para versiones 24 V: cumplimiento de la 
ISO 7637-2 + Reglamento n.  o 10 de la 
CEPE, Rev. 3: 
impulso 1a: Vs = – 450 V, Ri = 50 ohmios 
impulso 2a: Vs = + 37 V, Ri = 2 ohmios 
impulso 2b: Vs = + 20 V, Ri = 0,05 ohmios 
impulso 3a: Vs = – 150 V, Ri = 50 ohmios 
impulso 3b: Vs = + 150 V, Ri = 50 ohmios 
impulso 4: Vs = – 16 V, Va = – 12 V, t6 
=100 ms 
impulso 5: Vs = + 120 V, Ri = 2,2 ohmios, 
td = 250 ms. 
Para versiones 12 V: cumplimiento de la 
ISO 7637-1 + Reglamento n.  o 10 de la 
CEPE, Rev. 3: 
impulso 1: Vs = – 75 V, Ri = 10 ohmios 
impulso 2a: Vs = + 37 V, Ri = 2 ohmios 
impulso 2b: Vs = + 10 V, Ri = 0,05 ohmios 
impulso 3a: Vs = – 112 V, Ri = 50 ohmios 
impulso 3b: Vs = + 75 V, Ri = 50 ohmios 
impulso 4: Vs = – 6 V, Va = – 5 V, t6 = 15 
ms 
impulso 5: Vs = + 65 V, Ri = 3 ohmios, td 
= 100 ms. 
El impulso 5 deberá verificarse exclusiva­
mente en las unidades intravehiculares con­
cebidas para ser instaladas en vehículos que 
no dispongan de protección común externa 
contra volcado de la carga. 
Para las propuestas de volcado de la carga, 
remítase a la ISO 16750-2, 4.  a edición, apar­
tado 4.6.4.  218 
▼B 
3. PRUEBAS FUNCIONALES DEL SENSOR DE MOVIMIENTO  
N o Prueba  Descripción  Condiciones correspon­
dientes  
1. Examen administrativo  
1.1 Documentación  Corrección de la documentación.  
2. Inspección visual  
2.1. Cumplimiento de lo dispuesto en la documentación  
2.2. Identificación/inscripciones  225, 226  
2.3 Materiales  219 a 223  
2.4. Precintos  398, 401 a 405  
3. Pruebas funcionales  
3.1 Datos de identificación del sensor  95 a 97*  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 399  
N o Prueba  Descripción  Condiciones correspon­
dientes  
3.2 Emparejamiento del sensor de movimiento y la unidad instalada en el vehículo  122*, 204  
3.3 Detección de movimiento 
Precisión de la medición del movimiento.  30 a 35  
3.4 Interfaz de la unidad instalada en el vehículo  0 2  
3.5 Comprobar si el sensor de movimiento es invulnerable a los cam pos magnéticos 
constantes. De forma alternativa, comprobar si el sensor de mov imiento reac­
ciona a los campos magnéticos constantes perturbando la detecci ón de movi­
miento del vehículo a fin de que la VU conectada pueda detectar , registrar y 
almacenar los fallos del sensor.  217 
4. Pruebas ambientales  
4.1 Temperatura de funciona­
miento  Verificar la funcionalidad (tal y como se define 
en la prueba n  o 3.3) en el intervalo de tempe­
raturas [– 40 °C; + 135 °C] mediante: 
IEC 60068-2-1: prueba Ad, con una duración de 
96 horas a la temperatura más baja To  mín . 
IEC 60068-2-2: prueba Bd, con una duración de 
96 horas a la temperatura más alta To  máx . 
Prueba en virtud de la ISO 16750-4, 
sección 5.1.1.2: prueba de funcionamiento a 
temperatura baja (24 h a – 40 °C). 
Esta prueba se refiere a la IEC 60068-2-1: Ve­
rificación medioambiental — Parte 2-1: Pruebas 
— Prueba A: Frío. IEC 68-2-2: prueba Bd, con 
una duración de 96 horas a la temperatura más 
baja de – 40 °C. 
Prueba en virtud de la ISO 16750-4, apartado 
5.1.2.2: prueba de funcionamiento a temperatura 
alta (96 h a 135 °C). 
Esta prueba se refiere a la IEC 60068-2-2: Pro­
cedimientos básicos de verificación medioam­
biental; Parte 2: pruebas; Prueba B: Calor seco.  213 
4.2 Ciclos de temperatura  Prueba en virtud de la ISO 16750-4, apartado 
5.3.2: cambio rápido de temperatura con una 
duración de transición específica (– 40 °C/135 
°C, 20 ciclos, tiempo: 30 minutos en cada tem­
peratura). 
IEC 60068-2-14: Verificación medioambiental 
— Parte 2-14: Pruebas — Prueba N: Variacio­
nes de la temperatura.  213 
4.3 Ciclos de humedad  Verificar la funcionalidad (tal y como se define 
en la prueba n  o 3.3) mediante la IEC 60068-2- 
30, prueba Db, seis ciclos de 24 horas, con una 
variación de temperatura de + 25 °C a + 55 °C 
en cada caso y una humedad relativa del 97 % 
a + 25 °C y del 93 % a + 55 °C.  214 ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 400  
N o Prueba  Descripción  Condiciones correspon­
dientes  
4.4 Vibración  ISO 16750-3: apartado 4.1.2.6: prueba VI: ve­
hículo comercial, motor, caja de cambios. 
Prueba de vibración en modo combinado que 
incluya: 
a) una prueba de vibración sinusoidal, 20-520 
Hz, 
11,4- 120 m/s  2 , <= 0,5 oct/min; y 
b) una prueba de vibración aleatoria, 10-2 000 
Hz, RMS 177 m/s  2 
94 horas por eje, incluido un ciclo de tempera­
tura de – 20 °C a 70 °C. 
Esta prueba se refiere a la IEC 60068-2-80: 
Verificación medioambiental — Parte 2-80: 
Pruebas — Prueba Fi: Vibración — Modo com­
binado  219 
4.5 Choque mecánico  ISO 16750-3: apartado 4.2.3: prueba VI: prueba 
para los dispositivos situados en el interior o en 
la superficie de la caja de cambios. 
Choque semisinusoidal, aceleración acordada de 
entre 3 000 y 15 000 m/s  2 , duración del impulso 
acordada, sin embargo (< 1 ms), número de 
choques acordados. 
Esta prueba se refiere a la IEC 60068-2-27: 
Verificación medioambiental — Parte 2: Prue­
bas. Prueba Ea y orientación: Choque.  219 
4.6 Protección frente a la pene­
tración de agua y cuerpos ex­
traños  Prueba en virtud de la ISO 20653: Vehículos de 
carretera — Niveles de protección (código IP) 
— Protección del equipo eléctrico frente a ob­
jetos extraños, al agua y al acceso 
(valor objetivo IP 64).  220, 221  
4.7 Protección frente a la inver­
sión de la polaridad  Verificar que el sensor de movimiento es capaz 
de soportar una inversión de su fuente de ali­
mentación.  216 
4.8 Protección frente a cortocir­
cuitos  Verificar que las señales de entrada y de salida 
están protegidas frente a cortocircuitos a la 
fuente de alimentación y a masa.  216 
5. Compatibilidad electromagnética  
5.1 Emisiones radiadas y suscep­
tibilidad  Verificar el cumplimiento del Reglamento n  o 10 
de la CEPE.  218 
5.2 Descarga electrostática  Cumplimiento de la norma ISO 10605: 2008 + 
Corrigendum Técnico 2010 + AMD1: 2014: +/– 
4 kV para contacto +/– 8 kV para descarga de 
aire. 218 ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 401  
N o Prueba  Descripción  Condiciones correspon­
dientes  
5.3 Susceptibilidad transitoria 
conducida en las líneas de 
datos  Para versiones 24 V: cumplimiento de la ISO 
7637-2 + Reglamento n  o 10 de la CEPE, 
Rev. 3: 
impulso 1a: Vs = – 450 V, Ri = 50 ohmios 
impulso 2a: Vs = + 37 V, Ri = 2 ohmios 
impulso 2b: Vs = + 20 V, Ri = 0,05 ohmios 
impulso 3a: Vs = – 150 V, Ri = 50 ohmios 
impulso 3b: Vs = + 150 V, Ri = 50 ohmios 
impulso 4: Vs= – 16 V Va= – 12 V t6 = 100 
ms 
impulso 5: Vs=+120 V Ri=2,2 ohmios td=250 
ms. 
Para versiones 12 V: cumplimiento de la ISO 
7637-1 + Reglamento n  o 10 de la CEPE, 
Rev. 3: 
impulso 1: Vs = – 75 V, Ri = 10 ohmios 
impulso 2a: Vs = + 37 V, Ri = 2 ohmios 
impulso 2b: Vs = + 10 V, Ri = 0,05 ohmios 
impulso 3a: Vs = – 112 V, Ri = 50 ohmios 
impulso 3b: Vs = + 75 V, Ri = 50 ohmios 
impulso 4: Vs= – 6 V Va= – 5 V t6= 15 ms 
impulso 5: Vs= + 65 V Ri=3 ohmios td=100 
ms. 
El impulso 5 deberá verificarse exclusivamente 
en las unidades intravehiculares concebidas para 
ser instaladas en vehículos que no dispongan de 
protección común externa contra volcado de la 
carga. 
Para las propuestas de volcado de la carga, re­
mítase a la ISO 16750-2, 4  a edición, apartado 
4.6.4.  218 
4. PRUEBAS FUNCIONALES DE LAS TARJETAS DE TACÓGRAFO  
Las pruebas previstas en el apartado 4,  
n o 5 «Pruebas de protocolo»,  
n o 6 «Estructura de la tarjeta» y  
n o 7 «Pruebas funcionales»  
puede llevarlas a cabo el evaluador o el certificador durante e l proceso de 
certificación de la seguridad de los criterios comunes para el módulo del 
chip.  
Las pruebas 2.3 y 4.2 son idénticas. Se trata de pruebas mecáni cas para la 
combinación del cuerpo de la tarjeta con el módulo del chip. De ben 
realizarse estas pruebas cuando se modifique uno de estos compo nentes 
(cuerpo de la tarjeta o módulo del chip).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 402  
N o Prueba  Descripción  Condiciones correspon­
dientes  
1. Examen administrativo  
1.1 Documentación  Corrección de la documentación.  
2 Cuerpo de la tarjeta  
2.1 Diseño impreso  Cerciorarse de que todas las características de pro­
tección y todos los datos visibles están bien impresos 
en la tarjeta y se ajustan a la normativa. 
[Designador] 
Anexo 1C, apartado 4.1 (datos visibles), 227 
El anverso de la tarjeta contendrá: 
la mención «Tarjeta del conductor», «Tarjeta de con­
trol», «Tarjeta de taller» o «Tarjeta de empresa», en 
mayúsculas y en el o los idiomas oficiales del Estado 
miembro que expida la tarjeta, según el tipo de tar­
jeta. 
[Nombre del Estado miembro] 
Anexo 1C, apartado 4.1 (datos visibles), 228 
El anverso de la tarjeta contendrá: 
el nombre del Estado miembro que expida la tarjeta 
(opcional). 
[Firma] 
Anexo 1C, apartado 4.1 (datos visibles), 229 
El anverso de la tarjeta contendrá: 
el distintivo del Estado miembro que expida la tarjeta, 
impreso en negativo en un rectángulo azul rodeado de 
doce estrellas amarillas. 
[Numeración] 
Anexo 1C, apartado 4.1 (datos visibles), 232 
El reverso de la tarjeta contendrá: 
una explicación de las rúbricas numeradas que 
aparecen en la primera página de la tarjeta. 
[Color] 
Anexo 1C, apartado 4.1 (datos visibles), 234 
Las tarjetas de tacógrafo deberán imprimirse con los 
siguientes colores de fondo predominantes: 
— tarjeta del conductor: blanco, 
— tarjeta de taller: rojo, 
— tarjeta de control: azul, 
— tarjeta de empresa: amarillo.  227 a 229, 232, 234 
a 236  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 403  
N o Prueba  Descripción  Condiciones correspon­
dientes  
[Seguridad] 
Anexo 1C, apartado 4.1 (datos visibles), 235 
Las tarjetas de tacógrafo deberán reunir al menos las 
siguientes características de protección contra intentos 
de falsificación y manipulación: 
— un fondo con diseño de seguridad, fondo labrado e 
impresión en arco iris, 
— al menos una línea de microimpresión bicolor. 
[Marcas] 
Anexo 1C, apartado 4.1 (datos visibles), 236 
Los Estados miembros podrán añadir colores o 
marcas, como por ejemplo símbolos nacionales o 
características de seguridad. 
[Marca de homologación] 
Las tarjetas de tacógrafo deberán incluir una marca de 
homologación. 
La marca de homologación estará compuesta por: 
— un rectángulo en el que se inscriba la letra «e» 
minúscula seguida de un número distintivo o de 
una letra distintiva del país que haya expedido una 
homologación; y 
— un número de homologación correspondiente al 
número de la ficha de homologación de la tarjeta 
del tacógrafo, colocado en cualquier posición 
cerca del rectángulo.  
2.2 Ensayos mecánicos  [Tamaño de la tarjeta] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810: Tarjetas de identificación — Ca­
racterísticas físicas: 
[5] Dimensiones de la tarjeta 
[5.1] Tamaño de la tarjeta 
[5.1.1] Dimensiones y resistencia de la tarjeta 
Tipo de tarjeta ID-1: tarjeta no utilizada. 
[Bordes de la tarjeta] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810: Tarjetas de identificación — Caracter- 
ísticas físicas: 
[5] Dimensiones de la tarjeta 
[5.1] Tamaño de la tarjeta 
[5.1.2] Bordes de la tarjeta  240, 243 
ISO/IEC 7810  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 404  
N o Prueba  Descripción  Condiciones correspon­
dientes  
[Fabricación de la tarjeta] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810: Tarjetas de identificación — Caracter- 
ísticas físicas: 
[6] Fabricación de la tarjeta 
[Materiales de la tarjeta] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810: Tarjetas de identificación — Caracter- 
ísticas físicas: 
[7] Materiales de la tarjeta 
[Resistencia a la flexión] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810: Tarjetas de identificación — Caracter- 
ísticas físicas: 
[8] Características de la tarjeta 
[8.1] Resistencia a la flexión 
[Toxicidad] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810: Tarjetas de identificación — Caracter- 
ísticas físicas: 
[8] Características de la tarjeta 
[8.3] Toxicidad 
[Resistencia a los agentes químicos] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810: Tarjetas de identificación — Caracter- 
ísticas físicas: 
[8] Características de la tarjeta 
[8.4] Resistencia a los agentes químicos 
[Estabilidad de la tarjeta] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810: Tarjetas de identificación — Caracter- 
ísticas físicas: 
[8] Características de la tarjeta 
[8.5] Estabilidad dimensional de la tarjeta y alabeado 
con la temperatura y la humedad  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 405  
N o Prueba  Descripción  Condiciones correspon­
dientes  
[Ligera] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810: Tarjetas de identificación — Caracter- 
ísticas físicas: 
[8] Características de la tarjeta 
[8.6] Ligera 
[Durabilidad] 
Anexo 1C, apartado 4.4 (especificaciones ambientales 
y eléctricas), 241 
Las tarjetas de tacógrafo deberán poder funcionar 
correctamente durante cinco años si se utilizan con 
arreglo a las especificaciones ambientales y eléctricas. 
[Resistencia de la superficie] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810: Tarjetas de identificación — Caracter- 
ísticas físicas: 
[8] Características de la tarjeta 
[8.8] Resistencia de la superficie 
[Adherencia o bloqueo] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810: Tarjetas de identificación — Caracter- 
ísticas físicas: 
[8] Características de la tarjeta 
[8.9] Adherencia o bloqueo 
[Alabeado] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810: Tarjetas de identificación — Caracter- 
ísticas físicas: 
[8] Características de la tarjeta 
[8.11] Alabeado general de la tarjeta 
[Resistencia al calor] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810: Tarjetas de identificación — Caracter- 
ísticas físicas: 
[8] Características de la tarjeta 
[8.12] Resistencia al calor  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 406  
N o Prueba  Descripción  Condiciones correspon­
dientes  
[Distorsiones de la superficie] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810: Tarjetas de identificación — Caracter- 
ísticas físicas: 
[8] Características de la tarjeta 
[8.13] Distorsiones de la superficie 
[Contaminación] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810: Tarjetas de identificación — Caracter- 
ísticas físicas: 
[8] Características de la tarjeta 
[8.14] Contaminación e interacción entre los compo- 
nentes de la tarjeta  
2.3 Pruebas mecánicas con 
el módulo de chip inte­
grado  [Flexión] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810:2003/Amd. 1:2009, Tarjetas de iden­
tificación — Características físicas, enmienda 1: cri­
terios para las tarjetas que contienen circuitos inte­
grados: 
[9.2] Tensión por flexión dinámica 
N o total de ciclos de flexión: 4 000. 
[Torsión] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810:2003/Amd. 1:2009, Tarjetas de identi- 
ficación — Características físicas, enmienda 1: 
criterios para las tarjetas que contienen circuitos 
integrados: 
[9.3] Tensión por torsión dinámica 
N o total de ciclos de torsión: 4 000.  ISO/IEC 7810  
3 Módulo  
3.1 Módulo  El módulo está formado por el encapsulado del chip 
y el plato de contacto. 
[Perfil de la superficie] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7816-1:2011: Tarjetas de identificación — 
Tarjetas con circuitos integrados con contactos — 
Parte 1: Tarjetas con contactos — Características 
físicas: 
[4.2] Perfil de la superficie de los contactos  ISO/IEC 7816  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 407  
N o Prueba  Descripción  Condiciones correspon­
dientes  
[Resistencia mecánica] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7816-1:2011: Tarjetas de identificación — 
Tarjetas con circuitos integrados con contactos — 
Parte 1: Tarjetas con contactos — Características 
físicas: 
[4.3] Resistencia mecánica (de una tarjeta y de los 
contactos) 
[Resistencia eléctrica] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7816-1:2011: Tarjetas de identificación — 
Tarjetas con circuitos integrados con contactos — 
Parte 1: Tarjetas con contactos — Características 
físicas: 
[4.4] Resistencia eléctrica (de los contactos) 
[Dimensiones] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7816-2:2007: Tarjetas de identificación — 
Tarjetas con circuitos integrados con contactos — 
Parte 2: Tarjetas con contactos — Dimensiones y 
localización de los contactos: 
[3] Dimensiones de los contactos 
[Localización] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7816-2:2007: Tarjetas de identificación — 
Tarjetas con circuitos integrados con contactos — 
Parte 2: Tarjetas con contactos — Dimensiones y 
localización de los contactos: 
[4] Número y localización de los contactos 
En caso de los módulos con seis contactos, los 
contactos C4 y C8 no están sujetos a este requisito.  
4 Chip  
4.1 Chip  
[Temperatura de funcionamiento] 
El chip de la tarjeta de tacógrafo funcionará a una 
temperatura ambiente de entre –25 °C y +85 °C.  241 a 244 
Reglamento n  o 10 de 
la CEPE 
ISO/IEC 7810 
ISO/IEC 10373  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 408  
N o Prueba  Descripción  Condiciones correspon­
dientes  
[Temperatura y humedad] 
Anexo 1C, apartado 4.4 (especificaciones ambienta­
les y eléctricas), 241 
Las tarjetas de tacógrafo deberán estar en condicio­
nes de funcionar correctamente bajo cualquier condi­
ción climática habitual en el territorio de la Comu­
nidad y al menos en el intervalo de temperaturas 
comprendido entre – 25 °C y + 70 °C, con picos 
ocasionales de hasta + 85 °C («ocasional» significa 
no más de 4 horas cada vez y no más de 100 veces 
durante la vida útil de la tarjeta). 
Las tarjetas de tacógrafo se exponen en fases conse­
cutivas a las siguientes temperaturas y humedades 
durante un tiempo fijado. Se verifica la funcionalidad 
eléctrica de las tarjetas de tacógrafo después de cada 
una de las fases. 
1. Temperatura de – 20 °C durante 2 horas. 
2. Temperatura de +/– 0 °C durante 2 horas. 
3. Temperatura de + 20 °C y humedad relativa del 
50 % durante 2 horas. 
4. Temperatura de + 50 °C y humedad relativa del 
50 % durante 2 horas. 
5. Temperatura de + 70 °C y humedad relativa del 
50 % durante 2 horas. 
La temperatura se aumenta intermitentemente 
hasta + 85 °C, con una humedad relativa del 50 
%, durante 60 min. 
6. Temperatura de + 70 °C y humedad relativa del 
85 %, durante 2 horas. 
La temperatura se aumenta intermitentemente 
hasta + 85 °C, con una humedad relativa del 85 
%, durante 30 min. 
[Humedad] 
Anexo 1C, apartado 4.4 (especificaciones ambientales 
y eléctricas), 242 
Las tarjetas de tacógrafo deberán poder funcionar 
correctamente en el intervalo higrométrico compren- 
dido entre el 10 % y el 90 %. 
[Compatibilidad electromagnética (CEM)] 
Anexo 1C, apartado 4.4 (especificaciones ambientales 
y eléctricas), 244 
Cuando se encuentren en funcionamiento, las tarjetas 
de tacógrafo deberán cumplir el Reglamento n  o 10 de 
la CEPE en lo relativo a la compatibilidad electro- 
magnética.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 409  
N o Prueba  Descripción  Condiciones correspon­
dientes  
[Electricidad estática] 
Anexo 1C, apartado 4.4 (especificaciones ambientales 
y eléctricas), 244 
Cuando se encuentren en funcionamiento, las tarjetas 
de tacógrafo deberán estar protegidas contra descargas 
electroestáticas. 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810:2003/Amd. 1:2009: Tarjetas de identi- 
ficación — Características físicas, enmienda 1: 
criterios para las tarjetas que contienen circuitos 
integrados: 
[9.4] Electricidad estática 
[9.4.1] Tarjetas de contacto IC 
Tensión de voltaje: 4 000 V 
[Rayos X] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810:2003/Amd. 1:2009, Tarjetas de identi- 
ficación — Características físicas, enmienda 1: 
criterios para las tarjetas que contienen circuitos 
integrados: 
[9.1] Rayos X 
[Luz ultravioleta] 
ISO/IEC 10373-1:2006, Tarjetas de identificación — 
Métodos de prueba — Parte 1: Características 
generales 
[5.11] Luz ultravioleta 
[3 ruedas] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 10373-1:2006/Amd. 1:2012, Tarjetas de 
identificación — Métodos de prueba — Parte 1: 
Características generales, Enmienda 1: 
[5.22] ICC — Resistencia mecánica: prueba de las tres 
ruedas para ICC con contactos 
[Envoltura] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
MasterCard CQM V2.03:2013 
[11.1.3] R-L3-14-8: Prueba de la firmeza del en- 
voltorio 
[13.2.1.32] TM-422: Fiabilidad mecánica: Prueba del 
envoltorio  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 410  
N o Prueba  Descripción  Condiciones correspon­
dientes  
4.2 Pruebas mecánicas del 
módulo del chip inser­
tado en el cuerpo de la 
tarjeta –> ídem 2.3  [Flexión] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810:2003/Amd. 1:2009, Tarjetas de iden­
tificación — Características físicas, enmienda 1: cri­
terios para las tarjetas que contienen circuitos inte­
grados: 
[9.2] Tensión por flexión dinámica 
N o total de ciclos de flexión: 4 000. 
[Torsión] 
Las tarjetas de tacógrafo deben ser conformes a la 
norma 
ISO/IEC 7810:2003/Amd. 1:2009, Tarjetas de identi- 
ficación — Características físicas, enmienda 1: 
criterios para las tarjetas que contienen circuitos 
integrados: 
[9.3] Tensión por torsión dinámica 
N o total de ciclos de torsión: 4 000.  ISO/IEC 7810  
5 Pruebas de protocolos  
5.1 ATR  Comprobar si el ATR es conforme.  ISO/IEC 7816-3 
TCS_14, TCS_17, 
TCS_18  
5.2 T=0  Comprobar si el protocolo T=0 es conforme.  ISO/IEC 7816-3 
TCS_11, TCS_12, 
TCS_13, TCS_15  
5.3 PTS  Comprobar si el comando PTS es conforme. Para ello, 
ajustar T=1 partiendo de T=0.  ISO/IEC 7816-3 
TCS_12, TCS_19, 
TCS_20, TCS_21  
5.4 T=1  Comprobar si el protocolo T=1 es conforme.  ISO/IEC 7816-3 
TCS_11, TCS_13, 
TCS_16  
6 Estructura de la tarjeta  
6.1 Comprobar si la estructura de archivos de la tarjeta es 
conforme. Para ello, verificar la presencia de los ar­
chivos obligatorios en la tarjeta y sus condiciones de 
acceso.  TCS_22 a TCS_28 
TCS_140 a TCS_179  
7 Pruebas funcionales  
7.1 Proceso normal  Verificar al menos una vez por cada uso autorizado de 
cada comando (por ejemplo, verificar el comando UP­
DATE BINARY con CLA=00, CLA=0C y con dife­
rentes parámetros P1, P2 y Lc). 
Comprobar que las operaciones se han llevado a cabo 
en la tarjeta (por ejemplo, leyendo el archivo donde se 
ha ejecutado el comando).  TCS_29 a TCS_139  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 411  
N o Prueba  Descripción  Condiciones correspon­
dientes  
7.2 Mensajes de error  Comprobar al menos una vez cada uno de los mensa­
jes de error (especificados en el apéndice 2) para cada 
comando. 
Comprobar al menos una vez cada uno de los errores 
genéricos (excepto los errores de integridad « 6400 » 
verificados durante la certificación de seguridad).  
7.3 Serie de cifrado y parámetros de dominio estandarizados  CSM_48, CSM_50  
8 Personalización  
8.1 Personalización óptica  Anexo 1C, apartado 4.1 (datos visibles), 230 
El anverso de la tarjeta contendrá: 
información específica de la tarjeta expedida. 
Anexo 1C, apartado 4.1 (datos visibles), 231 
El anverso de la tarjeta contendrá: 
las fechas en formato «dd/mm/aaaa» o «dd.mm.aaaa» 
(día, mes, año). 
Anexo 1C, apartado 4.1 (datos visibles), 235 
Las tarjetas de tacógrafo deberán reunir al menos las 
siguientes características de protección contra intentos 
de falsificación y manipulación: 
— en la zona de la fotografía, el fondo con diseño de- 
seguridad y la fotografía deberán solaparse.  230, 231, 235  
5. PRUEBAS DEL DISPOSITIVO GNSS EXTERNO  
N o Prueba  Descripción  Condiciones correspon­
dientes  
1. Examen administrativo  
1.1 Documentación  Corrección de la documentación.  
2. Inspección visual del dispositivo GNSS externo  
2.1. Cumplimiento de lo dispuesto en la documentación  
2.2. Identificación/inscripciones  224 a 226  
2.3 Materiales  219 a 223  
3. Pruebas funcionales  
3.1 Datos de identificación del sensor  98, 99  
3.2 Acoplamiento entre el módulo GNSS externo y la unidad instalad a en el vehí­
culo 123, 205  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 412  
N o Prueba  Descripción  Condiciones correspon­
dientes  
3.3 Posición GNSS  36, 37  
3.4 Interfaz de la unidad instalada en el vehículo cuando el recep tor GNSS es 
externo a la unidad  03 
3.5 Serie de cifrado y parámetros de dominio estandarizados  CSM_48, CSM_50  
4. Pruebas ambientales  
4.1 Temperatura  Verificar la funcionalidad mediante: 
Prueba en virtud de la ISO 16750-4, apartado 5.1.1.2: prueba 
de funcionamiento a temperatura baja (72 h a –20 °C). 
Esta prueba se refiere a la IEC 60068-2-1: Verificación me­
dioambiental — Parte 2-1: Pruebas — Prueba A: Frío 
Prueba en virtud de la ISO 16750-4, apartado 5.1.2.2: prueba 
de funcionamiento a temperatura alta (72 h a 70 °C). 
Esta prueba se refiere a la IEC 60068-2-2: Procedimientos 
básicos de verificación medioambiental; Parte 2: pruebas; 
Prueba B: Calor seco. 
Prueba en virtud de la ISO 16750-4, apartado 5.3.2: cambio 
rápido de temperatura con una duración de transición espe­
cífica (– 20 °C/70 °C, 20 ciclos, tiempo: 1 hora en cada 
temperatura). 
Es posible llevar a cabo un conjunto reducido de pruebas (de 
entre las que se definen en la sección 3 de esta tabla) a la 
temperatura más baja, a la temperatura más alta y durante los 
ciclos de temperatura.  213 
4.2 Humedad  Verificar que la unidad instalada en el vehículo puede sopor­
tar una humedad cíclica (prueba de calor) mediante IEC 
60068-2-30, prueba Db, seis ciclos de 24 horas, con una 
variación de temperatura de + 25 °C a + 55 °C en cada 
caso y una humedad relativa del 97 % a + 25°C y del 
93 % a + 55°C.  214 
4.3 Mecánica  1. Vibraciones sinusoidales: 
verificar que la unidad instalada en el vehículo es capaz 
de soportar vibraciones sinusoidales de las siguientes ca­
racterísticas: 
desplazamiento constante entre 5 y 11 Hz: pico de 10 
mm; y 
aceleración constante entre 11 y 300 Hz: 5 g. 
Esta exigencia se verifica mediante la norma IEC 60068- 
2-6, prueba Fc, con una duración mínima de 3 × 12 horas 
(12 horas por cada eje). 
La ISO 16750-3 no requiere una prueba de vibración 
sinusoidal para dispositivos situados en el puesto de con­
ducción del vehículo desacoplado.  219 ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 413  
N o Prueba  Descripción  Condiciones correspon­
dientes  
2. Vibraciones aleatorias: 
Prueba en virtud de la ISO 16750-3, apartado 4.1.2.8: 
prueba VIII: vehículo comercial, puesto de conducción del 
vehículo desacoplado. 
Prueba de vibraciones aleatorias, 10-2 000 Hz, RMS 
vertical 21,3 m/s  2 , RMS longitudinal 11,8 m/s  2 , RMS 
lateral 13,1 m/s  2 , 3 ejes, 32 horas por eje, incluido un 
c i c l o d e t e m p e r a t u r a – 2 0 - + 
70 °C. 
Esta prueba se refiere a la IEC 60068-2-64: Verificación 
medioambiental — Parte 2-64: Pruebas — Prueba Fh: 
Vibración, aleatorio de banda ancha y orientación. 
3. Choques: 
choque mecánico con semionda sinusoidal de 3 g de 
conformidad con la ISO 16750. 
Las pruebas arriba descritas se llevan a cabo con muestras 
diferentes del tipo de equipo que se someta a prueba.  
4.4 Protección 
frente a la pe­
netración de 
agua y cuerpos 
extraños  Prueba en virtud de la ISO 20653: Vehículos de carretera — 
Niveles de protección (código IP) — Protección del equipo 
eléctrico frente a objetos extraños, al agua y al acceso (sin 
cambio en los parámetros).  220, 221  
4.5 Protección 
frente a sobre­
tensiones  Verificar que la unidad instalada en el vehículo es capaz de 
soportar un suministro eléctrico de:  216 
versiones de 24 V:  34 V a + 40 °C 1 hora.  
versiones de 12 V:  17 V a + 40 °C 1 hora.  
(ISO 16750-2, apartado 4.3)  
4.6 Protección 
frente a la in­
versión de la 
polaridad  Verificar que la unidad instalada en el vehículo es capaz de 
soportar una inversión de su fuente de alimentación. 
(ISO 16750-2, apartado 4.7)  216 
4.7 Protección 
frente a corto­
circuitos  Verificar que las señales de entrada y de salida están prote­
gidas frente a cortocircuitos a la fuente de alimentación y a 
masa. 
(ISO 16750-2, apartado 4.10)  216 
5 Pruebas de compatibilidad electromagnética  
5.1 Emisiones ra­
diadas y sus­
ceptibilidad  Cumplimiento del Reglamento n  o 10 de la CEPE.  218  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 414  
N o Prueba  Descripción  Condiciones correspon­
dientes  
5.2 Descarga elec­
trostática  Cumplimiento de la norma ISO 10605: 2008 + Corrigendum 
Técnico 2010 + AMD1: 2014: +/– 4 kV para contacto +/– 
8 kV para descarga de aire.  218 
5.3 Susceptibilidad 
transitoria con­
ducida en la 
fuente de ali­
mentación  Para versiones 24 V: cumplimiento de la ISO 7637-2 + Re­
glamento n  o 10 de la CEPE, Rev. 3: 
impulso 1a: Vs = – 450 V, Ri = 50 ohmios 
impulso 2a: Vs = + 37 V, Ri = 2 ohmios 
impulso 2b: Vs = + 20 V, Ri = 0,05 ohmios 
impulso 3a: Vs = – 150 V, Ri = 50 ohmios 
impulso 3b: Vs = + 150 V, Ri = 50 ohmios 
impulso 4: Vs= – 16 V Va=–12 V t6=100 ms 
impulso 5: Vs=+ 120 V Ri=2,2 ohmios td=250 ms. 
Para versiones 12 V: cumplimiento de la ISO 7637-1 + Re­
glamento n  o 10 de la CEPE, Rev. 3: 
impulso 1: Vs = – 75 V, Ri = 10 ohmios 
impulso 2a: Vs = + 37 V, Ri = 2 ohmios 
impulso 2b: Vs = + 10 V, Ri = 0,05 ohmios 
impulso 3a: Vs = – 112 V, Ri = 50 ohmios 
impulso 3b: Vs = + 75 V, Ri = 50 ohmios 
impulso 4: Vs= – 6 V Va=–5 V t6=15 ms 
impulso 5: Vs= + 65 V Ri=3 ohmios td=100 ms. 
El impulso 5 deberá verificarse exclusivamente en las unida­
des intravehiculares concebidas para ser instaladas en vehí­
culos que no dispongan de protección común externa contra 
volcado de la carga. 
Para las propuestas de volcado de la carga, remítase a la ISO 
16750-2, 4  a edición, apartado 4.6.4.  218 
▼M1 
6. PRUEBAS DEL DISPOSITIVO DE COMUNICACIÓN A DISTANCIA 
EXTERNO  
N. o Prueba  Descripción  Condiciones correspon­
dientes  
1. Examen administrativo  
1.1. Documentación  Corrección de la do­
cumentación  
2. Inspección visual  
2.1. Cumplimiento de lo dispuesto en la documentación  
2.2. Identificación/inscripciones  225, 226  
2.3. Materiales  219 a 223  
3. Pruebas funcionales  
3.1. Comunicación remota para pruebas en carretera específicas  4, 197 a 199  
3.2. Registro y almacenamiento de datos en la memoria  9 1  
3.3. Comunicación con la unidad instalada en el vehículo  Apéndice 14, 
DSC_66 a DSC_70, 
DSC_71 a DSC_76  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 415  
N. o Prueba  Descripción  Condiciones correspon­
dientes  
4. Pruebas ambientales  
4.1. Temperatura  Verificar la funcionalidad mediante: 
Prueba en virtud de la ISO 16750-4, apartado 5.1.1.2: 
prueba de funcionamiento a temperatura baja (72 h a – 
20 °C). 
Esta prueba se refiere a la IEC 60068-2-1: Verificación 
medioambiental – Parte 2-1: Pruebas – Prueba A: Frío 
Prueba en virtud de la ISO 16750-4: apartado 5.1.2.2: 
prueba de funcionamiento a temperatura alta (72 h a 70 
°C). 
Esta prueba se refiere a la IEC 60068-2-2: Procedimien­
tos básicos de verificación medioambiental; Parte 2: 
pruebas; Prueba B: Calor seco. 
Prueba en virtud de la ISO 16750-4, apartado 5.3.2: 
cambio rápido de temperatura con una duración de tran­
sición específica (– 20 °C / 70 °C, 20 ciclos, tiempo: 1 
hora en cada temperatura). 
Es posible llevar a cabo un conjunto reducido de pruebas 
(de entre las que se definen en la sección 3 de esta tabla) 
a la temperatura más baja, a la temperatura más alta y 
durante los ciclos de temperatura.  213 
4.2. Protección frente a 
la penetración de 
agua y cuerpos ex­
traños  Prueba en virtud de la ISO 20653: Vehículos de carretera 
– Niveles de protección (código IP) – Protección del 
equipo eléctrico frente a objetos extraños, al agua y al 
acceso (valor objetivo IP40)  220, 221  
5. Pruebas de compatibilidad electromagnética  
5.1. Emisiones radiadas 
y susceptibilidad  Cumplimiento del Reglamento n.  o 10 de la CEPE.  218  
5.2. Descarga electrostá­
tica Cumplimiento de la norma ISO 10605:2008 + Corrigen­
dum Técnico 2010 + AMD1:2014:+/– 4 kV para con­
tacto +/– 8 kV para descarga de aire.  218 
5.3. Susceptibilidad 
transitoria condu­
cida en la fuente 
de alimentación  Para versiones 24 V: cumplimiento de la ISO 7637-2 + 
Reglamento n.  o 10 de la CEPE, Rev. 3: 
impulso 1a: Vs = – 450 V, Ri = 50 ohmios 
impulso 2a: Vs = + 37 V, Ri = 2 ohmios 
impulso 2b: Vs = + 20 V, Ri = 0,05 ohmios 
impulso 3a: Vs = – 150 V, Ri = 50 ohmios 
impulso 3b: Vs = + 150 V, Ri = 50 ohmios 
impulso 4: Vs = – 16 V, Va = – 12 V, t6 = 100 ms 
impulso 5: Vs = + 120 V, Ri = 2,2 ohmios, td = 250 ms. 
Para versiones 12 V: cumplimiento de la ISO 7637-1 + 
Reglamento n.  o 10 de la CEPE, Rev. 3: 
impulso 1: Vs = – 75 V, Ri = 10 ohmios 
impulso 2a: Vs = + 37 V, Ri = 2 ohmios 
impulso 2b: Vs = + 10 V, Ri = 0,05 ohmios 
impulso 3a: Vs = – 112 V, Ri = 50 ohmios  218 ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 416  
N. o Prueba  Descripción  Condiciones correspon­
dientes  
impulso 3b: Vs = + 75 V, Ri = 50 ohmios 
impulso 4: Vs = – 6 V, Va = – 5 V, t6 = 15 ms 
impulso 5: Vs = + 65 V, Ri = 3 ohmios, td = 100 ms. 
El impulso 5 deberá verificarse exclusivamente en las 
unidades intravehiculares concebidas para ser instaladas 
en vehículos que no dispongan de protección común 
externa contra volcado de la carga. 
Para las propuestas de volcado de la carga, remítase a la 
ISO 16750-2, 4.  a edición, apartado 4.6.4.  
▼B 
7. PRUEBAS FUNCIONALES DEL PAPEL  
N o Prueba  Descripción  Condiciones correspon­
dientes  
1. Examen administrativo  
1.1 Documentación  Corrección de la documentación.  
2 Pruebas generales  
2.1 Número de caracte­
res por línea  Inspección visual de los documentos de impresión.  172  
2.2 Tamaño mínimo de 
los caracteres  Inspección visual de los documentos de impresión e 
inspección de los caracteres.  173 
2.3 Conjuntos de carac­
teres admitidos  La impresora admitirá el uso de los caracteres especifi­
cados en el apéndice 1, apartado 4 (Conjuntos de ca­
racteres).  174 
2.4 Definición de los do­
cumentos de impre­
sión Verificación de la homologación del tacógrafo e inspec­
ción visual de los documentos de impresión.  174 
2.5 Legibilidad e identi­
ficación de los docu­
mentos de impresión  Inspección de los documentos de impresión. 
Demostración mediante los informes de prueba y los 
protocolos de verificación del fabricante. 
Todos los números de homologación de los tacógrafos 
con los que se pueda emplear la impresora están impre­
sos en el papel.  175, 177, 178  
2.6 Inclusión de notas 
escritas a mano  Inspección visual: Existencia de un espacio para la 
firma del conductor. 
Existencia de espacios para la inclusión de otros textos 
escritos a mano.  180 
2.7 Detalles adicionales 
en el papel  Tanto el anverso como el reverso del papel pueden 
incluir detalles o información adicionales. 
Estos últimos no podrán alterar la legibilidad de los 
documentos de impresión. 
Inspección visual.  177, 178  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 417  
N o Prueba  Descripción  Condiciones correspon­
dientes  
3 Pruebas de almacenamiento  
3.1 Calor seco  Preacondicionamiento: 16 horas a +23 °C ±2 °C/hume­
dad relativa del 55 % ±3 % 
Prueba ambiental: 72 horas a +70 °C ±2 °C 
Recuperación: 16 horas a +23 °C ±2 °C/humedad rela­
tiva 
del 55 % ±3 %  176, 178 
IEC 60068-2-2-Bb  
2.2 Calor húmedo  Preacondicionamiento: 16 horas a +23 °C ±2 °C/hume­
dad relativa del 55 % ±3 % 
Prueba ambiental: 144 horas a +55 °C ±2 °C/humedad 
relativa 
del 93 % ±3 % 
Recuperación: 16 horas a +23 °C ±2 °C/humedad rela­
tiva 
del 55 % ±3 %  176, 178 
IEC 60068-2-78-Cab  
4 Pruebas del papel durante el servicio  
4.1 Resistencia a la hu­
medad del fondo (pa­
pel no impreso)  Preacondicionamiento: 16 horas a +23 °C ±2 °C/hume­
dad relativa del 55 % ±3 % 
Prueba ambiental: 144 horas a +55 °C ±2 °C/humedad 
relativa del 93 % ±3 % 
Recuperación: 16 horas a +23 °C ±2 °C/humedad rela­
tiva del 55 % ±3 %  176, 178 
IEC 60068-2-78-Cab  
4.2 Imprimabilidad  Preacondicionamiento: 24 horas a +40 °C ±2 °C/hume­
dad relativa del 93 % ± 3 % 
Prueba ambiental: documento de impresión realizado a 
+23 °C ± 2 °C 
Recuperación: 16 horas a +23 °C ±2 °C/humedad rela­
tiva del 55 % ±3 %  176, 178  
4.3 Resistencia al calor  Preacondicionamiento: 16 horas a +23 °C ±2 °C/hume­
dad relativa del 55 % ±3 % 
Prueba ambiental: 2 horas a +70 °C ±2 °C/calor seco 
Recuperación: 16 horas a +23 °C ±2 °C/humedad rela­
tiva del 55 % ±3 %  176, 178 
IEC 60068-2-2-Bb  
4.4 Resistencia a tempe­
raturas bajas  Preacondicionamiento: 16 horas a +23 °C ± 2 °C/hume­
dad relativa del 55 % ±3 % 
Prueba ambiental: 24 horas a +20 °C ±3 °C/frío seco 
Recuperación: 16 horas a +23 °C ±2 °C/humedad rela­
tiva del 55 % ±3 %  176, 178 
ISO 60068-2-1-Ab  
4.5 Resistencia a la luz  Preacondicionamiento: 16 horas a +23 °C ±2 °C/hume­
dad relativa del 55 % ±3 % 
Prueba ambiental: 100 horas con una iluminación infe­
rior a 5 000 lux a +23 °C ±2 °C/humedad relativa del 
55 % ±3 % 
Recuperación: 16 horas a +23 °C ±2 °C/humedad rela­
tiva del 55 % ±3 %  176, 178  
Criterios de legibilidad para las pruebas 3.x y 4.x:  
Queda garantizada la legibilidad de los documentos de impresión  si las 
densidades ópticas respetan los siguientes límites:  
Caracteres impresos: mín. 1,0  
Fondo (papel no impreso): máx. 0,2  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 418  
Las densidades ópticas de los documentos de impresión resultant es deben 
medirse en función de la norma DIN EN ISO 534.  
Los documentos de impresión no deberán sufrir cambios dimension ales y 
deberán mantener una legibilidad clara.  
8. PRUEBAS DE INTEROPERABILIDAD  
▼M1 
N. o Prueba  Descripción  
8.1 Pruebas de interoperabilidad entre las unidades intravehicu lares y las tarjetas de tacógrafo  
1 Autenticación mutua  Comprobar que la autenticación mutua entre la unidad instalada  en 
el vehículo y la tarjeta de tacógrafo funciona normalmente.  
2 Pruebas de lectura/escritura  Ejecutar un escenario de actividad típico en la unidad instala da en 
el vehículo. Dicho escenario deberá adaptarse al tipo de tarjet a que 
se esté verificando y deberá incluir pruebas de escritura en ta ntos 
EF como sea posible en la tarjeta. 
Verificar mediante una transferencia de la unidad instalada en el 
vehículo que todos los registros correspondientes se han realiz ado 
correctamente. 
Verificar mediante una transferencia de la tarjeta que todos lo s 
registros correspondientes se han realizado correctamente. 
Verificar mediante una impresión diaria que todos los registros  
correspondientes se pueden leer correctamente.  
8.2 Pruebas de interoperabilidad entre las unidades intravehicu lares y los sensores de movimiento  
1 Emparejamiento  Comprobar que el emparejamiento entre las unidades intravehicu ­
lares y los sensores de movimiento funciona normalmente.  
2 Pruebas de actividad  Ejecutar un escenario de actividad típico en el sensor de movi ­
miento. El escenario incluirá una actividad normal y creará el 
mayor número de incidentes o fallos posible. 
Verificar mediante una transferencia de la unidad instalada en el 
vehículo que todos los registros correspondientes se han realiz ado 
correctamente. 
Verificar mediante una transferencia de la tarjeta que todos lo s 
registros correspondientes se han realizado correctamente. 
Verificar mediante una impresión diaria que todos los registros  
correspondientes se pueden leer correctamente.  
8.3 Pruebas de interoperabilidad entre las unidades intravehicu lares y las instalaciones GNSS externas (si pro­
cede)  
1 Autenticación mutua  Comprobar que la autenticación mutua (acoplamiento) entre la 
unidad instalada en el vehículo y el módulo GNSS externo fun­
ciona normalmente.  
2 Pruebas de actividad  Ejecutar un escenario de actividad típico en el módulo GNSS 
externo. El escenario incluirá una actividad normal y creará el  
mayor número de incidentes o fallos posible. 
Verificar mediante una transferencia de la unidad instalada en el 
vehículo que todos los registros correspondientes se han realiz ado 
correctamente. 
Verificar mediante una transferencia de la tarjeta que todos lo s 
registros correspondientes se han realizado correctamente. 
Verificar mediante una impresión diaria que todos los registros  
correspondientes se pueden leer correctamente.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 419  
9. PRUEBAS OSNMA  
9.1. Introducción  
En este capítulo se describen las pruebas para demostrar la cor recta im­
plantación de la OSNMA en el receptor GNSS. Puesto que la auten tica­
ción de la señal del satélite la realiza exclusivamente el rece ptor GNSS 
con independencia de cualquier otro componente del tacógrafo, l as prue­
bas expuestas en el presente capítulo pueden realizarse con el receptor 
GNSS como elemento autónomo. En este caso, el fabricante del ta cógrafo 
presentará a las autoridades de homologación un informe en el q ue se 
detallen el desarrollo y los resultados de las pruebas realizad as bajo la 
responsabilidad del fabricante del receptor GNSS.  
9.2 Condiciones aplicables  
— Los criterios de superación o no superación definidos en las pruebas 
OSNMA se considerarán válidos únicamente en relación con las co n­
diciones de ensayo indicadas.  
— Esos criterios podrían revisarse en el momento de la declarac ión del 
servicio OSNMA de Galileo y teniendo en cuenta los compromisos de 
rendimiento del servicio asociados.  
9.3. Definiciones y acrónimos  
9.3.1 Definiciones  
Arranque GNSS en frío / en 
templado / en caliente::  se refiere a la condición de arranque de 
un receptor GNSS en función de la dis­
ponibilidad de hora (T), almanaque (A) y 
efemérides (E) actuales, y posición (P):  
— Arranque GNSS en frío: ninguno  
— Arranque GNSS en templado: T, A, P  
— Arranque GNSS en caliente: T, A, 
E, P 
Arranque OSNMA en frío / en 
templado / en caliente: se refiere a la condición de arranque de 
la función ONSMA según la disponibi­
lidad de la clave pública (P) y la infor­
mación DSM-KROOT (K) (conforme a 
la definición de las Directrices OSNMA 
para los receptores a las que se refiere 
el apéndice 12).  
— Arranque OSNMA en frío: ninguno  
— Arranque OSNMA en templado: P  
— Arranque OSNMA en caliente: P, K  
9.3.2 Acrónimos  
ADKD  Authentication Data & Key Delay  (datos de autenticación 
y retardo de la clave)  
DSM-KROOT  Digital Signature Message KROOT  (KROOT del mensaje 
de firma digital)  
GNSS  Global Navigation Satellite System  (sistema mundial de 
navegación  por satélite  
KROOT  Root Key of the TESLA key chain  (clave raíz de la cadena 
de claves TESLA)  
MAC  Message Authentication Code  (código de autenticación de 
mensajes)  
NMACK  Number of MAC & key blocks (per 30 seconds)  (número  
de MAC y bloques de claves [por cada treinta segundos])  
OSNMA  Galileo Open Service Navigation Message Authentication  
(autenticación de mensajes de navegación del servicio 
abierto de Galileo)  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 420  
SLMAC Slow MAC (MAC lento)  
TESLA  Timed Efficient Stream Loss-tolerant Authentication  (au­
tenticación sincronizada eficiente resistente a pérdidas) 
(protocolo utilizado en la OSNMA)  
9.4. Equipo para la generación de señales GNSS  
La generación de las señales GNSS puede realizarse utilizando u n simu­
lador GNSS multiconstelación que admita la transmisión de mensa jes 
OSNMA. Alternativamente puede utilizarse un reproductor de seña les de 
radiofrecuencia capaz de reproducir las muestras de señal GNSS extraidas 
de los archivos. La profundidad de bits y la velocidad de muest reo típicas 
son, respectivamente, de 4 bits I/Q y de 10 MHz.  
Se da por supuesto que el receptor GNSS tiene interfaces para o rdenar la 
limpieza de su memoria (para borrar por separado la clave públi ca, la 
KROOT, la información del reloj, la información de la posición,  las 
efemérides y el almanaque), para ajustar el establecimiento de la hora 
local a efectos del requisito de verificación de la sincronizac ión OSNMA 
y para cargar la información criptográfica. Estos comandos pued en limi­
tarse solamente a las pruebas y, por tanto, no estar disponible s para el 
funcionamiento normal del receptor.  
9.5 Condiciones de las pruebas  
9.5.1 Condiciones GNSS  
Las señales GNSS simuladas o reproducidas tendrán las siguiente s carac­
terísticas:  
— escenario de receptor de usuario estático;  
— como mínimo las constelaciones GPS y Galileo;  
— frecuencia E1/L1;  
— como mínimo cuatro satélites Galileo con un ángulo de elevaci ón 
superior a 5°;  
— duración según requiera cada prueba;  
— efemérides de navegación constantes de los satélites durante la prueba.  
9.5.2 Condiciones OSNMA  
El mensaje OSNMA transmitido en la señal de RF tendrá las sigui entes 
características:  
— un mensaje HKROOT con el estado OSNMA puesto en operacional o  
en prueba, y una DSM-KROOT fija de ocho bloques para la cadena en 
vigor;  
— como mínimo cuatro satélites Galileo que transmitan OSNMA;  
— un mensaje MACK con un bloque MACK (es decir, NMACK=1), y 
como mínimo un ADKD = 0 y un ADKD = 12 por satélite y bloque 
MACK;  
— un tamaño de etiqueta de 40 bits;  
— la longitud de etiqueta mínima equivalente requerida por las Directri­
ces OSNMA para los receptores (actualmente 80 bits).  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 421  
Salvo cuando se señale, el establecimiento de la hora del recep tor interno 
deberá conocerse con suficiente exactitud y estar debidamente a lineado 
con la hora simulada. Se garantiza así el cumplimiento del requ isito OS­
NMA de sincronización inicial de la hora en cada condición de p rueba, es 
decir, la sincronización nominal en todas las pruebas, salvo la  del 
SLMAC. Véanse más detalles sobre la iniciación de la hora en la s Direc­
trices OSNMA para los receptores.  
Téngase en cuenta que los criterios indicados de superación o n o supera­
ción son conservadores y no representan el rendimiento esperado  de la 
OSNMA de Galileo.  
9.6. Especificación de la prueba  
N. o Prueba  Descripción  Requisitos correspon­
dientes  
1. Examen administrativo  
1.1 Documentación  Corrección de la documentación  
2 Pruebas generales  
2.1 Arranque OSNMA en 
caliente  Objetivo: verificar que el receptor GNSS computa una 
posición con OSNMA tras un arranque en caliente. 
Procedimiento: 
El receptor GNSS arranca en condiciones GNSS y OS­
NMA de arranque en caliente y adquiere las señales de 
los satélites Galileo visibles. 
El receptor GNSS efectúa la autenticación de los datos 
de navegación de Galileo con la OSNMA (ADKD = 0) 
y proporciona una posición con datos autenticados. 
Criterios de superación o no superación: el receptor 
computa una posición definida autenticada en ciento 
sesenta segundos.  Apéndice 12, 
GNS_3b  
2.2 Arranque OSNMA en 
templado  Objetivo: verificar que el receptor GNSS computa una 
posición con OSNMA tras un arranque en templado. 
Procedimiento: 
Antes de comenzar la prueba, se borrarán de la memo­
ria del receptor GNSS las efemérides y la información 
KROOT, a fin de forzar un arranque GNSS y OSNMA 
en templado. 
El receptor GNSS arranca y adquiere las señales de los 
satélites Galileo visibles. 
Se recibe y verifica la DSM-KROOT. 
El receptor efectúa la autenticación de los datos de 
navegación de Galileo con la OSNMA (ADKD = 0) 
y proporciona una posición con datos autenticados. 
Criterios de superación o no superación: el receptor 
computa una posición definida autenticada válida en 
cuatrocientos treinta segundos.  Apéndice 12, 
GNS_3b  
2.3 Arranque OSNMA en 
templado con SLMAC  Objetivo: verificar que el receptor GNSS computa una 
posición con OSNMA tras un arranque en templado 
con una iniciación de la hora que requiere el modo 
SLMAC, según se define en las Directrices OSNMA 
para los receptores. 
Procedimiento: 
El establecimiento de la hora del receptor interno se 
configurará para que la incertidumbre inicial de la 
hora tenga un valor de entre 2 y 2,5 minutos, de 
modo que, de acuerdo con las Directrices OSNMA 
para los receptores, se active el modo MAC lento.  Apéndice 12, 
GNS_3b  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 422  
N. o Prueba  Descripción  Requisitos correspon­
dientes  
Antes de comenzar las pruebas, se borrarán de la me­
moria del receptor GNSS las efemérides y la informa­
ción KROOT, a fin de forzar un arranque GNSS y 
OSNMA en templado. 
El receptor GNSS arranca y adquiere las señales de los 
satélites Galileo visibles. 
Se recibe y verifica la DSM-KROOT. 
El receptor efectúa la autenticación de los datos de 
navegación de Galileo únicamente con la OSNMA en 
modo MAC lento (ADKD = 12) y proporciona una 
posición con datos autenticados. 
Criterios de superación o no superación: el receptor 
computa una posición definida autenticada válida en 
setecientos treinta segundos.  
2.4 Arranque OSNMA en 
caliente con señal re­
producida  Objetivo: verificar que el receptor GNSS detecta una 
señal reproducida. 
Procedimiento: 
El receptor GNSS arranca en condiciones GNSS y OS­
NMA de arranque en caliente y adquiere las señales de 
los satélites Galileo visibles. 
El receptor efectúa la autenticación de los datos de 
navegación de Galileo con la OSNMA (ADKD = 0) 
y proporciona una posición con datos autenticados. 
Una vez que el receptor proporciona una solución PVT 
con datos autenticados, se apaga. 
Se simula una señal reproducida con un retardo de 
cuarenta segundos respecto de la anterior, y se enciende 
el receptor. 
El receptor detecta que la hora del sistema Galileo 
ofrecida por la señal en el espacio y el establecimiento 
de la hora local no cumplen el requisito de sincroniza­
ción y deja de procesar los datos OSNMA conforme a 
las Directrices OSNMA para los receptores. 
Criterios de superación o no superación: el receptor 
detecta la reproducción y no computa una posición au­
tenticada válida desde el comienzo de la reproducción 
hasta el final de la prueba.  Apéndice 12, 
GNS_3b  
2.5 Arranque OSNMA en 
caliente con datos fal­
sos Objetivo: verificar que la OSNMA detecta datos falsos. 
Procedimiento: 
El receptor GNSS arranca en condiciones GNSS y OS­
NMA de arranque en caliente. 
El receptor GNSS deberá ser capaz de adquirir la señal 
de todos los satélites Galileo visibles y de verificar la 
autenticidad de sus mensajes de navegación por medio 
de la OSNMA. 
Como mínimo un bit de los datos de efemérides pro­
porcionados por cada satélite Galileo no se corresponde 
con los datos originales y autenticados, pero el mensaje 
Galileo I/NAV debe ser coherente, incluido el CRC. 
Criterios de superación o no superación: el receptor 
detecta los datos falsos en ciento sesenta segundos y 
no computa una posición autenticada válida hasta el 
final de la prueba.  Apéndice 12, 
GNS_3b  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 423  
Apéndice 10  
REQUISITOS DE SEGURIDAD  
En el presente apéndice se especifican los requisitos en materi a de seguridad 
informática para los componentes del sistema de tacógrafo intel igente (tacógrafo 
de segunda generación).  
SEC_001 Los componentes del sistema de tacógrafo inteligente qu e se recogen a 
continuación deberán tener una certificación de seguridad confo rme 
con el sistema de criterios comunes:  
— unidad instalada en el vehículo,  
— tarjeta de tacógrafo,  
— sensor de movimiento,  
— Dispositivo GNSS externo  
SEC_002 Los requisitos mínimos de seguridad informática que deb e cumplir 
cada componente con certificación de seguridad se determinarán en 
un Perfil de Protección de los componentes de acuerdo con el si stema 
de criterios comunes.  
SEC_003 La Comisión Europea se asegurará de que se patrocinen, elaboren y 
aprueben por los organismos de certificación de la seguridad in formá­
tica nacionales, en el marco del Grupo de Trabajo de interpreta ción 
conjunta, que es el grupo de trabajo que apoya el reconocimient o 
mutuo de certificados en el contexto del acuerdo europeo 
SOGIS-MRA (Acuerdo sobre el reconocimiento mutuo de los certifi ­
cados de evaluación de la seguridad de la tecnología de la info rma­
ción), cuatro perfiles de protección conformes con el presente anexo:  
— Perfil de Protección para la unidad instalada en el vehículo,  
— Perfil de Protección para la tarjeta de tacógrafo,  
— Perfil de Protección para el sensor de movimiento,  
— Perfil de protección para el dispositivo GNSS externo.  
El perfil de protección para la unidad instalada en el vehículo  debe abordar los 
casos en que la VU está diseñada para ser utilizada con un disp ositivo GNSS 
externo o sin él. En el primer caso los requisitos de seguridad  del dispositivo 
GNSS externo son los recogidos en el Perfil de Protección espec ífico.  
SEC_004 Los fabricantes deberán perfeccionar y completar, en la  medida de lo 
necesario, el Perfil de Protección de los componentes sin borra r o 
modificar especificaciones en materia de amenazas, objetivos, p roce­
dimientos y funciones de aplicación de las normas de seguridad con el 
fin de establecer un objetivo de seguridad conforme al cual se exigirá 
la certificación de seguridad del componente.  
SEC_005 En el proceso de evaluación se comprobará de forma estr icta la con­
formidad del objetivo de seguridad específico con el correspond iente 
Perfil de Protección.  
SEC_006 El nivel de garantía de cada Perfil de Protección será EAL4 incremen­
tado por los componentes de garantía ATE_DPT.2 y AVA_VAN.5.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 424  
Apéndice 11  
MECANISMOS COMUNES DE SEGURIDAD  
ÍNDICE  
PREÁMBULO  
PARTE A SISTEMA DE TACÓGRAFO DE PRIMERA GENERACIÓN  
1. INTRODUCCIÓN  
1.1. Referencias  
1.2. Notaciones y términos abreviados  
2. SISTEMAS Y ALGORITMOS CRIPTOGRÁFICOS  
2.1. Sistemas criptográficos  
2.2. Algoritmos criptográficos  
2.2.1 Algoritmo RSA  
2.2.2 Algoritmo de comprobación aleatoria  
2.2.3 Algoritmo de cifrado de datos  
3. CLAVES Y CERTIFICADOS  
3.1. Generación y distribución de claves  
3.1.1 Generación y distribución de claves RSA  
3.1.2 Claves de prueba RSA  
3.1.3 Claves del sensor de movimiento  
3.1.4 Generación y distribución de claves de sesión T-DES  
3.2. Claves  
3.3. Certificados  
3.3.1 Contenido de los certificados  
3.3.2 Certificados expedidos  
3.3.3 Verificación y apertura del certificado  
4. MECANISMO DE AUTENTICACIÓN MUTUA  
5. MECANISMOS DE CONFIDENCIALIDAD, INTEGRIDAD Y 
AUTENTICACIÓN EN LAS TRANSFERENCIAS DE DATOS 
ENTRE LA VU Y LAS TARJETAS  
5.1. Mensajería segura  
5.2. Tratamiento de los errores de mensajería segura  
5.3. Algoritmo para calcular sumas de control criptográficas  
5.4. Algoritmo para calcular criptogramas con los que mantener la con­ 
fidencialidad de los DO  
6. MECANISMOS DE FIRMA DIGITAL PARA LA TRANS­ 
FERENCIA DE DATOS  
6.1. Generación de firmas  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 425  
6.2. Verificación de firmas  
PARTE B SISTEMA DE TACÓGRAFO DE SEGUNDA GENERACIÓN  
7. INTRODUCCIÓN  
7.1. Referencias  
7.2. Notaciones y abreviaturas  
7.3. Definiciones  
8. SISTEMAS Y ALGORITMOS CRIPTOGRÁFICOS  
8.1. Sistemas criptográficos  
8.2. Algoritmos criptográficos  
8.2.1 Algoritmos simétricos  
8.2.2 Algoritmos asimétricos y parámetros de dominio normalizad os 
8.2.3 Algoritmos de comprobación aleatoria  
8.2.4 Conjuntos de cifrado  
9. CLAVES Y CERTIFICADOS  
9.1. Pares asimétricos de claves y certificados de clave públic a 
9.1.1 Generalidades  
9.1.2 Nivel europeo  
9.1.3 Nivel del Estado miembro  
9.1.4 Nivel de equipo: Unidades instaladas en los vehículos  
9.1.5 Nivel de equipo: Tarjetas de tacógrafo  
9.1.6 Nivel de equipo: Dispositivos GNSS externos  
9.1.7 Síntesis: Sustitución del certificado  
9.2. Claves simétricas  
9.2.1 Claves de aseguramiento de la comunicación entre la VU y el 
sensor de movimiento  
9.2.2 Claves de aseguramiento de comunicaciones dedicadas de co rto 
alcance (DSRC)  
9.3. Certificados  
9.3.1 Generalidades  
9.3.2 Contenido de los certificados  
9.3.3 Solicitud de certificados  
10. AUTENTICACIÓN MUTUA DE LA TARJETA VU_CARD Y 
MENSAJERÍA SEGURA  
10.1. Generalidades  
10.2. Verificación mutua de la cadena de certificados  
10.2.1 Verificación por la VU de la cadena de certificados de u na tarjeta  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 426  
10.2.2 Verificación por la tarjeta de la cadena de certificados  de una VU  
10.3. Autenticación de VU  
10.4. Autenticación de chip y acuerdo de claves de sesión  
10.5. Mensajería segura  
10.5.1 Generalidades  
10.5.2 Estructura de mensaje segura  
10.5.3 Aborto de sesión de mensajería segura  
11. ACOPLAMIENTO, AUTENTICACIÓN MUTUA Y MENSAJE­ 
RÍA SEGURA ENTRE LA VU Y EL DISPOSITIVO GNSS EX­ 
TERNO  
11.1. Generalidades  
11.2. Acoplamiento entre la VU y el dispositivo GNSS externo  
11.3. Verificación mutua de la cadena de certificados  
11.3.1 Generalidades  
11.3.2 Durante el acoplamiento entre la VU y la EGF  
11.3.3 Durante el funcionamiento normal  
11.4. Autenticación de la VU, autenticación del chip y acuerdo de claves 
de sesión  
11.5. Mensajería segura  
12. EMPAREJAMIENTO Y COMUNICACIÓN ENTRE UNA VU Y 
UN SENSOR DE MOVIMIENTO  
12.1. Generalidades  
12.2. Emparejamiento de la VU con el sensor de movimiento media nte 
claves de diferentes generaciones  
12.3. Emparejamiento y comunicación entre una VU y un sensor de  
movimiento mediante el algoritmo AES  
12.4. Emparejamiento del sensor de movimiento para equipos de d ife­ 
rentes generaciones  
13. SEGURIDAD PARA LA COMUNICACIÓN REMOTA ME­ 
DIANTE DSRC  
13.1. Generalidades  
13.2. Cifrado de la carga útil del tacógrafo y generación del c ódigo MAC  
13.3. Verificación y descifrado de la carga útil del tacógrafo  
14. FIRMA DE DESCARGAS DE DATOS Y VERIFICACIÓN DE 
FIRMAS  
14.1. Generalidades  
14.2. Generación de firmas  
14.3. Verificación de firmas  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 427  
PREÁMBULO  
El presente apéndice especifica los mecanismos de seguridad que  garantizan  
— la autenticación mutua entre los diferentes componentes del s istema de tacó­
grafo digital;  
— la confidencialidad, integridad, autenticidad y/o no rechazo d e los datos transferidos 
entre equipos diferentes o descargados a medios de almacenamien to externos.  
El presente apéndice consta de dos partes. La Parte A define lo s mecanismos de 
seguridad del sistema de tacógrafo de primera generación (tacóg rafo digital). La 
Parte A define los mecanismos de seguridad del sistema de tacóg rafo de segunda 
generación (tacógrafo inteligente).  
Los mecanismos especificados en la Parte A del presente apéndic e serán de 
aplicación si al menos uno de los componentes del sistema de ta cógrafo impli­
cados en una autenticación mutua y/o proceso de transferencia d e datos es de 
primera generación.  
Los mecanismos especificados en la Parte B del presente apéndic e serán de 
aplicación si los dos componentes del sistema de tacógrafo impl icados en la 
autenticación mutua y/o el proceso de transferencia de datos so n de segunda 
generación.  
El apéndice 15 contiene más información sobre el uso de compone ntes de pri­
mera generación en combinación con componentes de segunda gener ación.  
PARTE A  
SISTEMA DE TACÓGRAFO DE PRIMERA GENERACIÓN  
1. INTRODUCCIÓN  
1.1. Referencias  
En el presente apéndice aparecen las siguientes referencias:  
SHA-1 National Institute of Standards and Technology 
(NIST).  Publicación FIPS 180-1:  Norma sobre códi­
gos de comprobación seguros. Abril de 1995.  
PKCS1 RSA Laboratories. PKCS # 1: Norma de cifrado RSA. 
Versión 2.0. Octubre de 1998.  
TDES National Institute of Standards and Technology 
(NIST).  Publicación FIPS 46-3:  Norma de cifrado 
de datos. Proyecto de 1999.  
TDES-OP ANSI X9.52, Modos de funcionamiento del algoritmo 
triple de cifrado de datos. 1998.  
ISO/IEC 7816-4 Tecnologías de la Información — Tarjetas de iden ti­
ficación — Tarjetas de circuito(s) integrado(s) con 
contactos — Parte 4: Comandos interindustriales 
para intercambio. Primera edición: 1995 + Modifica­
ción 1: 1997.  
ISO/IEC 7816-6 Tecnologías de la Información — Tarjetas de iden ti­
ficación — Tarjetas de circuito(s) integrado(s) con 
contactos — Parte 6: Elementos de datos interindus­
triales. Primera edición: 1996 + Cor 1: 1998.  
ISO/IEC 7816-8 Tecnologías de la Información — Tarjetas de iden ti­
ficación — Tarjetas de circuito(s) integrado(s) con 
contactos — Parte 8: Comandos interindustriales rela­
cionados con la seguridad. Primera edición 1999.  
ISO/IEC 9796-2  Tecnología de la información — Técnicas de seguridad 
— Esquemas de firma digital con recuperación de men­
saje — Parte 2: Mecanismos que emplean una función 
de comprobación aleatoria. Primera edición: 1997.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 428  
ISO/IEC 9798-3 Tecnología de la información — Técnicas de segur i­
dad — Mecanismos de autenticación de entidades — 
Parte 3: autenticación de entidades mediante un algo­
ritmo de clave pública. Segunda edición 1998.  
ISO 16844-3 Vehículos de carretera — Sistemas de tacógrafo — 
Parte 3: Interfaz del sensor de movimiento.  
1.2. Notaciones y términos abreviados  
En el presente apéndice se emplean las siguientes notaciones y términos 
abreviados:  
(K a , K  b , K  c ) Un conjunto de claves que utiliza el algoritmo triple 
de cifrado de datos.  
CA Certification authority (/autoridad de certificación),  
CAR Certification authority reference (/referencia a la auto­
ridad de certificación),  
CC Cryptographic checksum (/suma de control criptográ­
fica),  
CG Criptograma,  
CH Command header (/cabecera de comando),  
CHA Certificate holder authorisation (/autorización del titu­
lar del certificado),  
CHR Certificate holder reference (/referencia al titular del 
certificado),  
D() Descifrado con DES,  
DE Data element (/elemento de datos),  
DO Data object (/objeto de datos),  
d Clave privada RSA, exponente privado,  
e Clave pública RSA, exponente público,  
E() Cifrado con DES,  
EQT EQT Equipment (/equipo),  
Hash()  Valor de comprobación aleatoria, una salida de Hash,  
Hash  Función de comprobación aleatoria,  
KID Key identifier (/identificador de clave),  
Km Clave TDES. Clave maestra definida en ISO 16844-3,  
Km  VU Clave TDES insertada en las unidades de vehículos,  
Km  WC Clave TDES insertada en las tarjetas de los centros de 
ensayo,  
m Representante de mensaje, un número entero entre 0 y 
n-1, 
n Claves RSA, módulo,  
PB Padding bytes (/bytes de relleno),  
PI Padding indicator byte (/byte indicador de relleno, se 
utiliza en un criptograma para confidencialidad DO),  
PV Plain value (/valor sencillo),  
s Representante de la firma, un número entero entre 0 y 
n-1, 
SSC Send sequence counter (/contador de la secuencia de 
envío),  
SM Secure messaging (/mensajería segura),  
TCBC Modo de funcionamiento por cifrado progresivo 
TDEA,  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 429  
TDEA Algoritmo triple de cifrado de datos,  
TLV Tag length value (/valor de longitud de la etiqueta),  
VU Vehicle unit (/unidad instalada en el vehículo),  
X.C Certificado del usuario X, expedido por una autoridad 
de certificación,  
X.CA Una autoridad de certificación del usuario X,  
X.CA.PK  o X.C La operación de abrir un certificado para extraer una 
clave pública. Se trata de un operador infijo, cuyo 
operando izquierdo es la clave pública de una autori­
dad de certificación, y cuyo operando derecho es el 
certificado expedido por dicha autoridad. El resultado 
es la clave pública del usuario X cuyo certificado es el 
operando derecho,  
X.PK Clave pública RDS de un usuario X,  
X.PK[I] Cifrado RSA de cierta información I, utilizando la 
clave pública del usuario X,  
X.SK Clave privada RDS de un usuario X,  
X.SK[I] Cifrado RSA de cierta información I, utilizando la 
clave privada del usuario X,  
«xx» Un valor hexadecimal,  
|| Operador de concatenación.  
2. SISTEMAS Y ALGORITMOS CRIPTOGRÁFICOS  
2.1. Sistemas criptográficos  
CSM_001 Las unidades instaladas en los vehículos y las tarjetas  de 
tacógrafo deberán emplear un sistema criptográfico RSA clá­
sico de clave pública para ofrecer los siguientes mecanismos 
de seguridad:  
— autenticación entre unidades instaladas en los vehículos y 
tarjetas,  
— transporte de claves de sesión triple DES entre las unida­
des instaladas en los vehículos y las tarjetas de tacógrafo,  
— firma digital de los datos transferidos desde unidades ins­
taladas en los vehículos o tarjetas de tacógrafo a medios 
externos.  
CSM_002 Las unidades instaladas en los vehículos y las tarjetas  de 
tacógrafo deberán emplear un sistema criptográfico simétrico 
triple DES para ofrecer un mecanismo que garantice la inte­
gridad de los datos durante los intercambios de datos de 
usuario entre las unidades instaladas en los vehículos y las 
tarjetas de tacógrafo, y para ofrecer, cuando proceda, la con­
fidencialidad en los intercambios de datos entre las unidades 
instaladas en los vehículos y las tarjetas de tacógrafo.  
2.2. Algoritmos criptográficos  
2.2.1  Algoritmo RSA  
CSM_003 El algoritmo RSA se define íntegramente con las relacio nes 
siguientes:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 430  
X.SK[ m] = s = m d mod n 
X.PK[ s] = m = s e mod n 
En el documento de referencia PKCS1 figura una descripción 
más completa de la función RSA. El exponente público e 
será, para los cálculos RSA, un entero comprendido entre 3 
y n-1, cumpliéndose que mcd(e, mcm(p-1, q-1))=1.  
2.2.2  Algoritmo de comprobación aleatoria  
CSM_004 Los mecanismos de firma digital deberán emplear el algo ­
ritmo SHA-1 de comprobación aleatoria, que se define en 
el documento de referencia SHA-1.  
2.2.3  Algoritmo de cifrado de datos  
CSM_005 En el modo de funcionamiento por cifrado progresivo deb erán 
emplearse algoritmos con base DES.  
3. CLAVES Y CERTIFICADOS  
3.1. Generación y distribución de claves  
3.1.1  Generación y distribución de claves RSA  
CSM_006 Las claves RSA deberán generarse en tres niveles jerárq uicos 
funcionales:  
— Nivel europeo  
— Nivel de Estado miembro  
— Nivel de equipo  
CSM_007 En el nivel europeo deberá generarse un único par de cl aves 
europeas (EUR.SK y EUR.PK). La clave privada europea 
deberá emplearse para certificar las claves públicas de los 
Estados miembros. Se conservarán registros de todas las cla­
ves certificadas. Todas estas tareas se realizarán bajo la ges­
tión de una autoridad de certificación europea, y bajo la au­
toridad y la responsabilidad de la Comisión Europea.  
CSM_008 En el nivel de los Estados miembros, deberá generarse u n par 
de claves de Estado miembro (MS.SK y MS.PK). La autori­
dad de certificación europea se encargará de certificar las 
claves públicas de los Estados miembros. La clave privada 
del Estado miembro deberá emplearse para certificar las cla­
ves públicas que vayan a introducirse en el equipo (unidad 
instalada en el vehículo o tarjeta de tacógrafo). Se conserva­
rán registros de todas las claves públicas certificadas, junto 
con la identificación del equipo al que están destinadas. Estas  
tareas serán efectuadas por una autoridad de certificación del 
Estado miembro que corresponda. Un Estado miembro podrá 
cambiar periódicamente su par de claves.  
CSM_009 En el nivel de equipo, deberá generarse e introducirse en cada 
equipo un único par de claves (EQT.SK y EQT.PK). Estas 
tareas serán gestionadas por una autoridad de certificación del  
Estado miembro que corresponda. Estas tareas podrán ser 
efectuadas por los fabricantes de los equipos, los personali­
zadores de los equipos o las autoridades de los Estados miem­
bros. Este par de claves se emplea para los servicios de 
autenticación, firma digital y cifrado.  
CSM_010 Se deberá mantener la confidencialidad de las claves pr ivadas 
durante su generación, transporte (en su caso) y almacena­
miento.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 431  
El gráfico siguiente resume el flujo de datos en este proceso:
  
3.1.2  Claves de prueba RSA  
CSM_011 Con el fin de verificar los equipos (incluidas las prue bas de 
interoperabilidad), la autoridad de certificación europea de­
berá generar otro par de claves de prueba europeas y al 
menos dos pares de claves de prueba de Estado miembro, 
cuyas claves públicas deberán certificarse con la clave privada  
de prueba europea. Los fabricantes deberán introducir, en el 
equipo que se someta a las pruebas de homologación, las 
claves de prueba certificadas por una de estas claves de 
prueba de Estado miembro.  
3.1.3  Claves del sensor de movimiento  
La confidencialidad de las tres claves TDES descritas a continu ación se 
mantendrá adecuadamente durante la generación, el transporte (s i lo hay) 
y el almacenamiento.  
A fin de admitir componentes de tacógrafo conformes con la norm a ISO 
16844, la autoridad de certificación europea y las autoridades de certifi­
cación de los Estados miembros garantizarán, además, lo siguien te: 
CSM_036 La autoridad de certificación europea generará KmVU y 
KmWC, dos claves Triple DES independientes y únicas, y 
generará Km como: Km = Km  VU XOR Km  WC . La autoridad 
de certificación europea remitirá estas claves, con arreglo a 
procedimientos de seguridad adecuados, a las autoridades de 
certificación de los Estados miembros a petición de éstas.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 432  
CSM_037 Las autoridades de certificación europeas:  
— utilizarán Km para cifrar los datos del sensor de movi­
miento solicitados por los fabricantes del sensor de movi­
miento (los datos que deben cifrarse con Km se definen 
en ISO 16844-3),  
— remitirán Km  VU a los fabricantes de la unidad instalada en 
el vehículo, con arreglo a procedimientos de seguridad 
adecuados, para su inserción en las unidades del vehículo,  
— se encargarán de que Km  WC se inserte en todas las tarjetas de 
centros de ensayo (
  en 
el archivo elemental
  )  
durante la personalización de la tarjeta.  
3.1.4  Generación y distribución de claves de sesión T-DES  
CSM_012 Las unidades instaladas en los vehículos y las tarjetas  de 
tacógrafo deberán, como parte del proceso de autenticación 
mutua, generar e intercambiar los datos necesarios para ela­
borar una clave común de sesión triple DES. La confidencia­
lidad de este intercambio de datos deberá estar protegida por 
un mecanismo criptográfico RSA.  
CSM_013 Esta clave deberá emplearse en todas las operaciones cr ipto­
gráficas subsiguientes que utilicen mensajería segura. Su va­
lidez expirará al término de cada sesión (al retirar o restaura r 
la tarjeta) o después de 240 usos (un uso de la clave = un 
comando que se envíe a la tarjeta y utilice mensajería segura, 
y la respuesta asociada).  
3.2. Claves  
CSM_014 Las claves RSA (con independencia de su nivel) deberán 
tener las longitudes siguientes: módulo  n 1 024 bits, expo­
nente público  e 64 bits máximo, exponente privado  d 1 024 
bits. 
CSM_015 Las claves triple DES deberán tener la forma (K  a , K  b , K  a ), 
donde K  a y K  b son claves independientes con una longitud de 
64 bits. No se configurarán bits para la detección de errores 
de paridad.  
3.3. Certificados  
CSM_016  Los certificados de clave pública RSA deberán ser «no autodes­
criptivos» y «verificables con tarjeta» (ref.: ISO/IEC 7816-8).  
3.3.1  Contenido de los certificados  
CSM_017 Los certificados de clave pública RSA incluyen los dato s 
siguientes en este orden:  
Dato  Formato  Bytes  Obs  
CPI N  o ENTERO  1  Identificador de perfil del 
certificado («01» para esta 
versión)  
CAR  CADENA DE 
OCTETOS  8 Referencia a la autoridad 
de certificación  
CHA  CADENA DE 
OCTETOS  7 Autorización del titular del 
certificado  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 433  
Dato  Formato  Bytes  Obs  
EOV  Fecha  4  Fin de la validez del certi­
ficado. Este dato es opcio­
nal y se rellena con las le­
tras «FF» si no se utiliza.  
CHR  CADENA DE 
OCTETOS  8 Referencia al titular del 
certificado  
n CADENA DE 
OCTETOS  128 Clave pública (módulo)  
e CADENA DE 
OCTETOS  8 Clave pública (exponente 
público)  
164 
Notas:  
1. El «Identificador de perfil del certificado» (CPI) define la  estructura 
exacta de un certificado de autenticación. Se puede utilizar co mo un 
identificador interno del equipo en una lista de cabeceras que describa 
la concatenación de elementos de datos en el certificado.  
A continuación se muestra la lista de cabeceras asociada al con tenido 
de este certificado: 
«4D»  «16»  «5F 
29» «01»  «42»  «08»  «5F 
4B» «07»  «5F 
24» «04»  «5F 
20» «08»  «7F 
49» «05»  «81»  «81 
80» «82»  «08»
 Etiqueta de lista de cabeceras ampliada  
Longitud de la lista de cabeceras  
Etiqueta CPI  
Longitud CPI  
Etiqueta CAR  
Longitud CAR  
Etiqueta CHA  
Longitud CHA  
Etiqueta EOV  
Longitud EOV  
Etiqueta CHR  
Longitud CHR  
Etiqueta de clave pública (construida)  
Longitud de los DO subsiguientes  
Etiqueta del módulo  
Longitud del módulo  
Etiqueta del exponente público  
Longitud del exponente público 
2. La «referencia a la autoridad de certificación» (CAR) sirve para iden­
tificar a la CA que expide el certificado, de manera que el ele mento 
de datos se puede utilizar simultáneamente como un identificado r de 
la clave de la autoridad, para señalar la clave pública de la a utoridad 
de certificación (la codificación se explica más adelante, cuan do se 
habla del identificador de clave).  
3. La «autorización del titular del certificado» (CHA) sirve pa ra identi­
ficar los derechos que posee el titular del certificado. Consta  del 
identificador de la aplicación de tacógrafo y del tipo de equip o a 
que se refiere el certificado (con arreglo al elemento de datos
  
, «00» para un Estado miembro).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 434  
4. La «referencia al titular del certificado» (CHR) sirve para identificar 
de forma inequívoca al titular del certificado, de manera que e l ele­
mento de datos se puede utilizar simultáneamente como un identi fi­
cador de clave de sujeto para señalar la clave pública del titu lar del 
certificado.  
5. Los identificadores de clave permiten identificar de forma i nequívoca 
al titular del certificado y a las autoridades de certificación . Los 
identificadores de clave se codifican de la manera siguiente:  
5.1. Equipo (VU o tarjeta): 
Dato  N  o de se­
rie del 
equipo  Fecha  Tipo  Fabricante  
Longitud  4 bytes  2 bytes  1 byte  1 byte  
Valor  Número 
entero  Codificación BCD 
mm aa  Específico del 
fabricante  Código del fa­
bricante  
En el caso de una VU, el fabricante, cuando solicita un certifi ­
cado, puede o no conocer la identificación del equipo en el que  
se introducirán las claves.  
En el primer caso, el fabricante enviará la identificación del 
equipo, junto con la clave pública, a la autoridad de certifica ción 
de su Estado miembro. El certificado que ésta expida contendrá 
la identificación del equipo. El fabricante debe cerciorarse de  que 
las claves y el certificado se introducen en el equipo que corr es­
ponde. El identificador de clave tiene la forma arriba descrita . 
En caso contrario, el fabricante debe identificar de forma ineq uí­
voca cada solicitud de certificado y enviar dicha identificació n, 
junto con la clave pública, a la autoridad de certificación de su 
Estado miembro. El certificado que ésta expida contendrá la 
identificación de la solicitud. Una vez se haya instalado la cl ave 
en el equipo, el fabricante, por su parte, debe comunicar a la 
autoridad de su Estado miembro la asignación de la clave al 
equipo (es decir, la identificación de la solicitud del certifi cado, 
la identificación del equipo). El identificador de clave posee la 
forma siguiente: 
Dato  N  o de se­
rie de so­
licitud de 
certificado  Fecha  Tipo  Fabricante  
Longitud  4 bytes  2 bytes  1 byte  1 byte  
Valor  Número 
entero  Codificación BCD 
mm aa  «FF»  Código del fa­
bricante  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 435  
5.2. Autoridad de certificación: 
Dato  Identificación de 
la autoridad  N o de serie de 
la clave  Información 
adicional  Identificador  
Longitud  4 bytes  1 byte  2 bytes  1 byte  
Valor  1 byte código nu­
mérico del país 
3 bytes código al­
fanumérico del 
país Número en­
tero Codificación 
adicional 
(específica de 
la CA) 
«FF FF» si no 
se utiliza  «01»  
El número de serie de la clave sirve para distinguir las difere ntes 
claves de un Estado miembro en caso de que se cambie la clave.  
6. Los responsables de verificar los certificados deberán saber  de forma 
implícita que la clave pública certificada es una clave RSA rel evante 
para los servicios de autenticación, verificación de la firma d igital y 
cifrado para confidencialidad (el certificado no contiene ningú n Iden­
tificador de Objeto que lo especifique).  
3.3.2  Certificados expedidos  
CSM_018 El certificado expedido es una firma digital con recupe ración 
parcial del contenido del certificado, según la norma ISO/IEC 
9796-2 (excepto su anexo A4), y se le añade una «referencia 
a la autoridad de certificación».  
X.C = X.CA.SK[«6A» || C  r || Hash  (Cc) || «BC»] || C  n || X.CAR 
Con el contenido del 
certificado = Cc =  C r || C  n 
106 bytes  58 bytes  
Notas:  
1. Este certificado tiene una longitud de 194 bytes.  
2. La referencia CAR, oculta por la firma, también se añade, de  manera 
que es posible seleccionar la clave pública de la autoridad de certifi­
cación para verificar el certificado.  
3. El responsable de verificar el certificado deberá conocer de  forma 
implícita el algoritmo empleado por la autoridad de certificaci ón 
para firmar el certificado.  
4. A continuación se muestra la lista de cabeceras asociada a e ste cer­
tificado expedido: 
«7F 21»  «09»  «5F 37»  «81 80»  «5F 38»  «3A»  «42»  «08»
 Etiqueta del certificado CV 
(Construida)  
Longitud de los DO subsiguientes  
Etiqueta de firma  
Longitud de la firma  
Etiqueta de resto  
Longitud de resto  
Etiqueta CAR  
Longitud CAR ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 436  
3.3.3  Verificación y apertura del certificado  
La verificación y apertura del certificado consiste en verifica r la firma 
con arreglo a la norma ISO/IEC 9796-2, recuperar el contenido d el 
certificado y la clave pública: X.PK = X.CA.PK  o X.C, y verificar la 
validez del certificado.  
CSM_019 Este proceso consta de las siguientes etapas:  
Verificación de la firma y recuperación del contenido: 
— conocido el X.C, recuperar la 
firma, C  n ' y CAR':  X.C =  Firma  | |  C  n ' | |  CAR'  
128 bytes  58 bytes  8 bytes  
— conocida la referencia CAR', seleccionar la clave pública 
de la autoridad de certificación (si no se ha hecho antes 
por otros medios),  
— abrir la firma con la clave pública de la CA: Sr'= 
X.CA.PK [Firma],  
— comprobar que Sr' comienza con «6A» y termina con 
«BC» 
— calcular Cr' y H' a partir de: Sr' =  «6 A»  | | C  r ' | |  H '  | |  «BC»  
106 bytes  20 bytes  
— Recuperar el contenido C' del certificado = C  r ' || C  n ', 
— comprobar que  Hash  (C') = H'  
Si estas comprobaciones arrojan un resultado positivo, el cer­
tificado es genuino y su contenido es C'.  
Una vez conocido el contenido C', verificación de la validez:  
— si procede, comprobar el final de la fecha de validez,  
Una vez conocido el contenido C', recuperación y almacena­
miento de la clave pública, el identificador de clave, la auto­
rización del titular del certificado y el fin de la validez del  
certificado:  
— X.PK =  n | | e 
— X.KID = CHR  
— X.CHA = CHA  
— X.EOV = EOV  
4. MECANISMO DE AUTENTICACIÓN MUTUA  
La autenticación mutua entre tarjetas y VU se basa en el siguie nte 
principio:  
Cada parte deberá demostrar a la otra que está en posesión de u n par de 
claves válido cuya clave pública ha sido certificada por la aut oridad de 
certificación de un Estado miembro, y que dicha autoridad ha si do cer­
tificada por la autoridad de certificación europea.  
La demostración se lleva a cabo firmando con la clave privada u n nú­
mero aleatorio enviado por la otra parte, quien debe recuperar dicho 
número cuando verifique esta firma.  
El mecanismo lo activa la VU al insertar la tarjeta. Comienza c on el 
intercambio de certificados y la apertura de claves públicas, y  termina 
con la creación de una clave de sesión.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 437  
CSM_020  Deberá utilizarse el protocolo siguiente (las flechas indican los 
comandos y datos que se intercambian [véase el apéndice 2)]:
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 438
  
▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 439  
5. MECANISMOS DE CONFIDENCIALIDAD, INTEGRIDAD Y AU­
TENTICACIÓN EN LAS TRANSFERENCIAS DE DATOS ENTRE 
LA VU Y LAS TARJETAS  
5.1. Mensajería segura  
CSM_021 La integridad de las transferencias de datos entre la V U y las 
tarjetas estará protegida por un sistema de mensajería segura, 
de conformidad con los documentos de referencia [ISO/IEC 
7816-4] e [ISO/IEC 7816-8].  
CSM_022 Cuando haya que proteger los datos durante la transfere ncia, 
se añadirá un objeto de datos consistente en una suma de 
control criptográfica a los objetos de datos que se envíen 
en el comando o la respuesta. El receptor deberá verificar 
dicha suma de control criptográfica.  
CSM_023 La suma de control criptográfica de los datos enviados en un 
comando deberá integrar la cabecera del comando y todos los 
objetos de datos que se envíen ((=>CLA = «0C», y todos los 
objetos de datos deberán estar englobados en etiquetas donde 
b1 = 1).  
CSM_024 Los bytes correspondientes a la información de estado e n la 
respuesta deberán estar protegidos por una suma de control 
criptográfica cuando dicha respuesta no contenga un campo 
de datos.  
CSM_025 Las sumas de control criptográficas deberán tener una l ongi­
tud de 4 bytes.  
Así pues, la estructura de comandos y respuestas cuando se 
utiliza un sistema de mensajería segura es así:  
Los DO empleados son un conjunto parcial de los DO de 
mensajería segura que se describen en la norma ISO/IEC 
7816-4:  
Etiqueta  Mnemónico  Significado  
«81»  T  PV Dato de valor plano no codificado en BER-TLV (con 
la protección de la suma CC)  
«97»  T  LE Valor de Le en el comando no seguro (con la pro­
tección de la suma CC)  
«99»  T  SW Información de estado (con la protección de la suma 
CC) 
«8E»  T  CC Suma de control criptográfica  
«87»  T  PI CG  Byte indicador de relleno || Criptograma (Valor plano 
no codificado en BER-TLV)  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 440  
Dado un par de respuestas para un comando no seguro:  
Cabecera de comando  Cuerpo del comando  
CLA  INS  P 1  P 2  [campo L  c ] [campo de datos]  [campo L  e ] 
cuatro bytes  L bytes, denotados por B  1 a B  L 
Cuerpo de la respuesta  Cola de la respuesta  
[campo de datos]  SW1  SW2  
L r bytes de datos  dos bytes  
El correspondiente par de respuestas para el comando seguro es:  
Comando seguro:  
Cabecera del 
comando (CH)  Cuerpo del comando  
CLA  INS  P 1  P 2  [Nuevo campo 
L c ] [Nuevo campo de datos]  [Nuevo 
campo 
L e ] 
«OC»  Longitud del 
nuevo campo de 
datos  T PV L PV PV T  LE L LE L e T CC L CC CC «00»  
«81»  L  c Campo de 
datos  «97»  «01»  L  e «8E»  «04»  C C  
Datos que habrá que integrar en la suma de control = CH || 
PB || T  PV || L  PV || PV || T  LE || L  LE || L  e || PB  
PB = Bytes de relleno (80.. 00) con arreglo a las normas 
ISO-IEC 7816-4 e ISO 9797, método 2.  
Los DO PV y LE sólo están presentes cuando existen datos 
correspondientes en el comando no seguro.  
Respuesta segura:  
1. Caso en que el campo de datos de la respuesta no está 
vacío y no es necesario protegerlo para garantizar la 
confidencialidad:  
Cuerpo de la respuesta  Cola de la respuesta  
[Nuevo campo de datos]  nuevo SW1 SW2  
T PV L PV PV T  CC L CC CC 
«81»  L  r Campo de datos  «8E»  «04»  C C  
Datos que habrá que integrar en la suma de control = T  PV 
|| L  PV || PV || PB  
2. Caso en que el campo de datos de la respuesta no está 
vacío y debe ser protegido para garantizar la confidencia­
lidad:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 441  
Cuerpo de la respuesta  Cola de la respuesta  
[Nuevo campo de datos]  nuevo SW1 SW2  
T PI CG  L PI 
CG PI CG  T  CC L CC CC 
«87»  PI || CG  «8E»  «04»  C C  
Datos que deberá llevar el CG: datos no codificados en 
BER-TLV y bytes de relleno.  
Datos que habrá que integrar en la suma de control = T  PI 
CG || L  PI CG  || PI CG || PB  
3. Caso en que el campo de datos de la respuesta está vacío:  
Cuerpo de la respuesta  Cola de la respuesta  
[Nuevo campo de datos]  nuevo SW1 SW2  
T SW L SW SW T  CC L CC CC 
«99»  «02»  Nuevo SW1 SW2  «8E»  «04»  C C  
Datos que habrá que integrar en la suma de control = T  SW 
|| L  SW || SW || PB  
5.2. Tratamiento de los errores de mensajería segura  
CSM_026 Si la tarjeta de tacógrafo detecta un error SM mientras  está 
interpretando un comando, los bytes de estado tendrán que ser 
devueltos sin SM. De acuerdo con la norma ISO/IEC 7816-4, 
se definen los siguientes bytes de estado para indicar errores 
SM: 
«66 88»: Ha fallado la verificación de la suma de control 
criptográfica,  
«69 87»: Faltan los objetos de datos SM que se esperaban,  
«69 88»: Objetos de datos SM incorrectos.  
CSM_027 Si la tarjeta de tacógrafo devuelve bytes de estado sin  DO SM 
o con un DO SM erróneo, la VU tendrá que interrumpir la 
sesión.  
5.3. Algoritmo para calcular sumas de control criptográficas  
CSM_028 Las sumas de control criptográficas se construyen utili zando 
MAC según ANSI X9.19, con DES:  
— etapa inicial: el bloque de control inicial y0 es E(Ka, 
SSC);  
— etapa secuencial: los bloques de control y1,.., yn se cal­
culan utilizando Ka;  
— etapa final: la suma de control criptográfica se calcula a 
partir del último bloque de control yn de la manera si­
guiente: E(Ka, D(Kb, yn)).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 442  
donde E() significa cifrado con DES, y D() significa desci­
frado con DES.  
Se transfieren los cuatro bytes más significativos de la suma 
de control criptográfica.  
CSM_029 El contador de la secuencia de envío (SSC) deberá inici arse 
durante el procedimiento de acuerdo de la clave:  
SSC inicial: Rnd3 (los 4 bytes menos significativos) || Rnd1 
(los 4 bytes menos significativos).  
CSM_030 El contador de la secuencia de envío deberá incrementar se en 
una unidad cada vez antes de que se calcule el MAC (es 
decir, el SSC para el primer comando es el SSC inicial + 1, 
el SSC para la primera respuesta es el SSC inicial — 2).  
El gráfico siguiente muestra el método de cálculo del MAC:
  
5.4. Algoritmo para calcular criptogramas con los que mantener la con ­
fidencialidad de los DO  
CSM_031 Los criptogramas se calculan utilizando el algoritmo TD EA 
en el modo de funcionamiento TCBC, de acuerdo con los 
documentos de referencia TDES y TDES-OP y con el vector 
nulo como bloque de valor inicial.  
El gráfico siguiente muestra la aplicación de claves en TDES:
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 443  
6. MECANISMOS DE FIRMA DIGITAL PARA LA TRANSFERENCIA 
DE DATOS  
CSM_032 El equipo dedicado inteligente (IDE) almacena en un arc hivo 
físico los datos recibidos de un equipo (VU o tarjeta) durante 
una sesión de descarga. Dicho archivo debe contener los 
certificados MSi.C y EQT.C. El archivo contiene además 
firmas digitales de bloques de datos, tal y como se especifica 
en el apéndice 7, apartado Protocolos de transferencia de 
datos.  
CSM_033 Las firmas digitales de los datos transferidos deberán utilizar 
un esquema de firma digital con apéndice, de manera que los 
datos transferidos puedan leerse sin necesidad de descifrarlos,  
si se desea.  
6.1. Generación de firmas  
CSM_034 La generación de firmas de datos por parte del equipo d eberá 
seguir el esquema de firma con apéndice que se define en el 
documento de referencia [PKCS1] con la función de compro­
bación aleatoria SHA-1:  
Firma = EQT.SK[«00» || «01» ||  PS || «00» || DER(SHA- 
1(datos))]  
PS = Cadena de octetos de relleno con un valor «FF» tal que 
la longitud sea 128.  
DER(SHA-1( M)) es la codificación de la identificación del 
algoritmo para la función de comprobación aleatoria y el 
valor de comprobación aleatoria, con el fin de obtener un 
valor ASN.1 del tipo DigestInfo (reglas de codificación dis­
tinguidas):  
«30»||«21»||«30»||«09»||«06»||«05»||«2B»||«0E»||«03»||«02»||«1A »|| 
«05»||«00»||«04»||«14»||Valor de comprobación aleatoria.  
6.2. Verificación de firmas  
CSM_035 La verificación de la firma en los datos transferidos d eberá 
seguir el esquema de firma con apéndice que se define en el 
documento de referencia [PKCS1] con la función de compro­
bación aleatoria SHA-1:  
El responsable de verificación debe conocer independiente­
mente (y confiar en) la clave pública europea EUR.PK.  
La tabla siguiente muestra el protocolo que una IDE que 
incorpore una tarjeta de control puede seguir para verificar 
la integridad de los datos transferidos y almacenados en el 
ESM (medio de almacenamiento externo). La tarjeta de con­
trol sirve para descifrar las firmas digitales. En este caso, 
puede que esta función no esté implementada en la IDE.  
El equipo que ha transferido y firmado los datos que han de 
analizarse se denota por EQT.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 444
  
PARTE B  
SISTEMA DE TACÓGRAFO DE SEGUNDA GENERACIÓN  
7. INTRODUCCIÓN  
7.1. Referencias  
En esta parte del presente apéndice aparecen las siguientes ref erencias:  
AES National Institute of Standards and Technology (NIST), 
FIPS PUB 197: Advanced Encryption Standard (AES), 
26 de noviembre de 2001  
DSS National Institute of Standards and Technology (NIST), 
FIPS PUB 186-4: Digital Signature Standard (DSS), julio 
de 2013  
ISO 7816-4 ISO/IEC 7816-4, Identification cards — Integrated ci rcuit 
cards — Part 4: Organization, security and commands for 
interchange. Tercera edición 2013-04-15  
ISO 7816-8 ISO/IEC 7816-8, Identification cards — Integrated ci rcuit 
cards — Part 8: Commands for security operations. Se­
gunda edición 2004-06-01  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 445  
ISO 8825-1 ISO/IEC 8825-1, Information technology — ASN.1 en­
coding rules: Specification of Basic Encoding Rules 
(BER), Canonical Encoding Rules (CER) and Distinguis­
hed Encoding Rules (DER). Cuarta edición, 2008-12-15  
ISO 9797-1 ISO/IEC 9797-1, Information technology — Security te ­
chniques — Message Authentication Codes (MACs) — 
Part 1: Mechanisms using a block cipher. Segunda edi­
ción, 2011-03-01  
ISO 10116 ISO/IEC 10116, Information technology — Security te­
chniques — Modes of operation of an  n-bit block cipher. 
Tercera edición, 2006-02-01  
ISO 16844-3 ISO/IEC 16844-3, Road vehicles — Tachograph systems  
— Part 3: Interfaz del sensor de movimiento. Primera 
edición de 2004, incluida la correción técnica de errores 
1 2006  
RFC 5480 Elliptic Curve Cryptography Subject Public Key Informa ­
tion, marzo de 2009  
RFC 5639 Elliptic Curve Cryptography (ECC) — Brainpool Stan­
dard Curves and Curve Generation, 2010  
RFC 5869 HMAC-based Extract-and-Expand Key Derivation Func­
tion (HKDF), mayo de 2010  
SHS National Institute of Standards and Technology (NIST), 
FIPS PUB 180-4: Secure Hash Standard, marzo de 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 Aut­
hentication, 2005  
TR-03111 BSI Technical Guideline TR-03111, Elliptic Curve 
Cryptography, versión 2.00, 2012-06-28  
7.2. Notaciones y abreviaturas  
En el presente apéndice se emplean las siguientes notaciones y términos 
abreviados:  
AES Advanced Encryption Standard (/norma de cifrado avan­
zado)  
CA Certification authority (/autoridad de certificación),  
CAR Certificate Authority Reference (/referencia a la autoridad  
de certificación)  
CBC Cipher Block Chaining (mode of operation) [/cifrado pro­
gresivo (modo de funcionamiento)]  
CH Command Header (/cabecera de comando),  
CHA Certificate Holder Authorisation (/autorización del titular  
del certificado)  
CHR Certificate Holder Reference (/referencia al titular del ce r­
tificado)  
CV Constant Vector (/vector constante)  
DER Distinguished Encoding Rules (/reglas de codificación dis­
tinguidas)  
DO Data object (/objeto de datos)  
DSRC Dedicated Short Range Communication (/comunicaciones 
especializadas de corto alcance)  
ECC Elliptic Curve Cryptography (/criptografía de curva elíp­
tica) 
ECDSA Elliptic Curve Digital Signature Algorithm (/algoritmo de  
firma digital de curva elíptica)  
ECDH Elliptic Curve Diffie-Hellman (key agreement algorithm) 
[/curva elíptica Diffie-Hellman (algoritmo de acuerdo de 
la clave)  
EGF External GNSS Facility (/dispositivo GNSS externo)  
EQT Equipment (/equipo)  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 446  
IDE Intelligent Dedicated Equipment (/equipo especializado in­
teligente)  
K M Clave maestra del sensor de movimiento que permite apa­
rear una unidad instalada en el vehículo con un sensor de 
movimiento  
K M-VU  Clave introducida en unidades de vehículo que permite a 
una VU derivar la clave maestra del sensor de movimiento 
si se introduce una tarjeta de taller en la VU  
K M-WC  Clave introducida en tarjetas de centro de ensayo que per­
mite a una VU derivar la clave maestra del sensor de 
movimiento si se introduce una tarjeta de taller en la VU  
MAC Message Authentication Code (/código de autenticación de 
mensajes)  
MoS Motion Sensor (/sensor de movimiento)  
MSB Most Significant Bit (/bit más significativo)  
PKI Public Key Infrastructure (/infraestructura de clave públic a) 
RCF Remote Communication Facility (/instalación de comuni­
cación remota)  
SSC Send sequence counter (/contador de la secuencia de en­
vío) 
SM Secure Messaging (/mensajeria segura)  
TDES Triple Data Encryption Standard (/norma de cifrado triple 
de datos)  
TLV Tag Length Value (/valor de longitud de la etiqueta)  
VU Vehicle Unit (/unidad instalada en el vehículo),  
X.C El certificado de clave pública de un usuario X  
X.CA La autoridad de certificación que haya expedido el certifi ­
cado del usuario X  
X.CAR La referencia de la autoridad de certificación mencionada  
en el certificado del usuario X  
X.CHR La referencia al titular del certificado mencionada en el  
certificado del usuario X  
X.PK Clave pública de un usuario X  
X.SK Clave privada de un usuario X  
X.PK  eph Clave pública efímera de un usuario X  
X.SK  eph Clave privada efímera de un usuario X  
«xx» Un valor hexadecimal  
|| Operador de concatenación.  
7.3. Definiciones  
Las definiciones de los términos utilizados en el presente apén dice figu­
ran en la sección I del anexo 1C.  
8. SISTEMAS Y ALGORITMOS CRIPTOGRÁFICOS  
8.1. Sistemas criptográficos  
CSM_38 Las unidades instaladas en los vehículos y las tarjetas de 
tacógrafo deberán emplear un sistema criptográfico de 
curva elíptica de clave pública para ofrecer los siguientes 
servicios de seguridad:  
— autenticación mutua entre una unidad instalada en el 
vehículo y una tarjeta;  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 447  
— acuerdo de claves de sesión AES entre una unidad 
instalada en el vehículo y una tarjeta;  
— garantía de la autenticidad, integridad y no rechazo de 
los datos descargados desde unidades instaladas en los 
vehículos o tarjetas de tacógrafo a medios externos.  
CSM_39 Las unidades instaladas en los vehículos y los dispositi vos 
GNSS externos deberán emplear un sistema criptográfico 
de curva elíptica de clave pública para ofrecer los siguien­
tes servicios de seguridad:  
— acoplamiento de una unidad instalada en el vehículo y 
un dispositivo GNSS externo;  
— autenticación mutua entre una unidad instalada en el 
vehículo y un dispositivo GNSS externo;  
— acuerdo de una clave de sesión AES entre una unidad 
instalada en el vehículo y un dispositivo GNSS 
externo.  
CSM_40 Las unidades instaladas en los vehículos y las tarjetas de 
tacógrafo deberán emplear un sistema criptográfico AES 
para ofrecer los siguientes servicios de seguridad:  
— garantía de la autenticidad e integridad de los datos 
intercambiados entre una unidad instalada en el vehí­
culo y una tarjeta de tacógrafo;  
— cuando corresponda, garantía de la confidencialidad de 
los datos intercambiados entre una unidad instalada en 
el vehículo y una tarjeta de tacógrafo.  
CSM_41 Las unidades instaladas en los vehículos y los dispositi vos 
GNSS externos deberán emplear un sistema criptográfico 
AES para ofrecer los siguientes servicios de seguridad:  
— garantía de la autenticidad e integridad de los datos 
intercambiados entre una unidad instalada en el vehí­
culo y un dispositivo GNSS externo.  
CSM_42 Las unidades instaladas en los vehículos y los sensores de 
movimiento deberán emplear un sistema criptográfico AES 
para ofrecer los siguientes servicios de seguridad:  
— emparejamiento de una unidad instalada en el vehículo 
y un sensor de movimiento;  
— autenticación mutua entre una unidad instalada en el 
vehículo y un sensor de movimiento;  
— garantía de la confidencialidad de los datos intercam­
biados entre una unidad instalada en el vehículo y un 
sensor de movimiento.  
CSM_43 Las unidades instaladas en los vehículos y las tarjetas de 
control deberán emplear un sistema criptográfico AES para 
ofrecer los siguientes servicios de seguridad en la interfaz 
de comunicación remota.  
— garantía de la autenticidad e integridad de los datos 
transmitidos desde una unidad instalada en el vehículo 
a una tarjeta de control.  
Notas:  
— Hablando con propiedad, los datos se transmiten desde 
una unidad instalada en el vehículo a un interrogador 
remoto bajo el control de un controlador a través de 
una instalación de comunicación remota que puede ser 
interna o externa a la VU, véase el apéndice 14. 
No obstante, el interrogador remoto envía los datos  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 448  
recibidos a una tarjeta de control para descifrado y 
validación de autenticidad. Desde el punto de vista 
de la seguridad, la instalación de comunicación remota 
y el interrogador remoto son plenamente transparentes.  
— Una tarjeta de taller ofrece los mismos servicios de 
seguridad para la interfaz DSRC que una tarjeta de 
control. Esto permite a un taller validar el funciona­
miento correcto de la interfaz de comunicación remota 
de una VU, incluida la seguridad. Remítase a la 
sección para 9.2.2 mayor información.  
8.2. Algoritmos criptográficos  
8.2.1  Algoritmos simétricos  
CSM_44 Las unidades instaladas en los vehículos, las tarjetas d e 
tacógrafo, los sensores de movimiento y los dispositivos 
GNSS externos admitirán el algoritmo AES según se de­
fine en [AES], con longitudes de clave de 128, 192 y 256 
bits. 
8.2.2  Algoritmos asimétricos y parámetros de dominio normalizados  
CSM_45 Las unidades instaladas en los vehículos, las tarjetas d e 
tacógrafo y los dispositivos GNSS externos admitirán crip­
tografía de curva elíptica con un tamaño de clave de 256, 
384 y 512/521 bits.  
CSM_46 Las unidades instaladas en los vehículos, las tarjetas d e 
tacógrafo y los dispositivos GNSS externos admitirán el 
algoritmo de firma ECDSA, según se especifica en [DSS].  
CSM_47 Las unidades instaladas en los vehículos, las tarjetas d e 
tacógrafo y los dispositivos GNSS externos admitirán el 
algoritmo de acuerdo de la clave ECKA-EG, según se 
especifica en la directriz técnica [TR 03111].  
CSM_48 Las unidades instaladas en los vehículos, las tarjetas d e 
tacógrafo y los dispositivos GNSS externos admitirán to­
dos los parámetros de dominio normalizados especificados 
en la Table 1 siguiente para criptografía de curva elíptica.  
Tabla 1  
Parámetros de dominio normalizados  
Nombre  Tamaño (bits)  Referencia  Identificador de objeto  
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 — ES — 21.08.2023 — 003.001 — 449  
Nota:  los identificadores de objeto mencionados en la úl­
tima columna de la Table 1 vienen especificados en [RFC 
5639] para las curvas Brainpool y en [RFC 5480] para las 
curvas NIST.
  
8.2.3  Algoritmos de comprobación aleatoria  
▼M1 
CSM_49 Las unidades instaladas en los vehículos, las tarjetas d e 
tacógrafo y los dispositivos GNSS externos admitirán los 
algoritmos SHA-256, SHA-384 y SHA-512 especificados 
en [SHS].  
▼B 
8.2.4  Conjuntos de cifrado  
CSM_50 Si se utilizan simultáneamente un algoritmo simétrico, u n 
algoritmo asimétrico y/o un algoritmo de comprobación 
aleatoria para formar un protocolo de seguridad, sus lon­
gitudes de clave y tamaños de algoritmo de autenticación 
respectivos serán de fortaleza aproximadamente equiva­
lente. La Table 2 indica los descriptores permitidos:  
Tabla 2  
Conjuntos de cifrado permitidos  
Id del conjunto de 
cifrado  Tamaño de clave ECC 
(bits)  Longitud de clave AES 
(bits)  Algoritmo de 
comprobación 
aleatoria  Longitud de 
MAC (bytes)  
CS#1  256  128  SHA-256  8  
CS#2  384  192  SHA-384  1 2  
CS#3  512/521  256  SHA-512  1 6  
Nota:  Los tamaños de clave ECC de 512 bits y 521 bits se 
consideran de fortaleza equivalente a todos los efectos en 
el presente apéndice.  
9. CLAVES Y CERTIFICADOS  
9.1. Pares asimétricos de claves y certificados de clave pública  
9.1.1  Generalidades  
Nota:  las claves descritas en esta sección se utilizan para la auten ticación 
mutua y la mensajería segura entre unidades instaladas en los v ehículos y 
tarjetas de tacógrafo, así como entre unidades instaladas en lo s vehículos 
y dispositivos GNSS externos. Estos procesos se describen en de talle en 
los capítulos 10 y 11 de este apéndice.  
CSM_51 En el sistema europeo de tacógrafo inteligente, los pare s de 
claves ECC y los certificados correspondientes se genera­
rán y gestionarán mediante tres niveles jerárquicos 
funcionales:  
— Nivel europeo  
— Nivel de Estado miembro  
— Nivel de equipo.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 450  
CSM_52 En la totalidad del sistema de Tacógrafo Inteligente Eur o­
peo, las claves públicas y privadas y los certificados se 
generarán, gestionarán y comunicarán mediante métodos 
normalizados y seguros.  
9.1.2  Nivel europeo  
CSM_53 En el nivel europeo deberá generarse un único par de 
claves ECC designado EUR compuesto de una clave pri­
vada (EUR:SK) y de una clave pública (EUR.PK). Este 
par de claves formará el par de claves raíz de la totalidad 
del Tacógrafo Inteligente Europeo PKI. Esta tarea será 
gestionada por la Autoridad del Certificado Raíz 
Europeo (ERCA), bajo la autoridad y responsabilidad de 
la Comisión Europea.  
CSM_54 La ERCA utilizará la clave privada europea para firmar u n 
certificado raíz (autofirmado) de la clave pública europea y 
comunicará este certificado raíz europeo a todos los Esta­
dos miembros.  
CSM_55 La ERCA utilizará la clave privada europea para firmar l os 
certificados de las claves públicas de los Estados miembros 
a solicitud de estos. La ERCA llevará un registro de todos 
los certificados de clave pública de los Estados miembros 
que haya firmado.  
CSM_56 Como se indica en la Figure 1 de la sección 9.1.7, la 
ERCA generará un nuevo par de claves raíz europeo 
cada 17 años. Siempre que la ERCA genera un nuevo 
par de claves raíz europeo, creará un nuevo certificado 
raíz autofirmado para la nueva clave pública europea. El 
período de validez de un certificado raíz europeo será de 
34 años y 3 meses.  
Nota:  La introducción de un nuevo par de claves raíz 
implica asimismo que la ERCA genere una nueva clave 
maestra del sensor de movimiento y una nueva clave 
maestra DSRC, véanse las secciones 9.2.1.2 y 9.2.2.2.  
CSM_57 Antes de generar un nuevo par de claves raíz europeo, la  
ERCA efectuará un análisis de la fortaleza criptográfica 
necesaria para el nuevo par de claves, habida cuenta de 
la necesidad de garantizar su seguridad durante los 34 años 
siguientes. En caso necesario, la ERCA cambiará a un 
conjunto de cifrado más fuerte que el actual, tal como se 
especifica en CSM_50.  
▼M1 
CSM_58 Siempre que genere un nuevo par de claves raíz europeo, 
la ERCA creará un certificado de enlace para la nueva 
clave pública europea y la firmará con la clave privada 
europea anterior. El período de validez del certificado de 
enlace será de 17 años y 3 meses. Lo anterior se indica 
asimismo en la figura 1 de la sección 9.1.7.  
▼B 
Nota:  Dado que un certificado de enlace contiene la clave 
pública de la generación ERCA X y está firmado con la 
clave privada de la generación ERCA X-1, el certificado 
de enlace ofrece a los equipos de la generación X-1 un 
método de confianza en los equipos de la generación X.  
CSM_59 La ERCA no utilizará la clave privada de un par de clave s 
raíz para ningún fin a partir del momento en que adquiera 
validez un nuevo certificado raíz de clave.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 451  
CSM_60 La ERCA dispondrá en cualquier momento de las siguien­
tes claves criptográficas y certificados:  
— El par de claves EUR actual y el certificado correspon­
diente.  
— Todos los certificados EUR anteriores que deberán uti­
lizarse para la verificación de certificados MSCA que 
son todavía válidos.  
— Los certificados de enlace para todas las generaciones 
de certificados EUR excepto el primero.  
9.1.3  Nivel del Estado miembro  
CSM_61 Al nivel del Estado miembro, todos los Estados miembros 
a los que se solicite la firma de certificados de tarjeta de 
tacógrafo generarán uno o varios pares de claves ECC 
únicos designados MSCA_Card. Todos los Estados miem­
bros a los que se solicite la firma de certificados para 
unidades instaladas en los vehículos o dispositivos GNSS 
externos generarán uno o varios pares de claves ECC úni­
cos designados MSCA_VU-EGF.  
CSM_62 La tarea de generar pares de claves del Estado miembro 
será gestionada por una Autoridad de Certificación del 
Estado miembro (MSCA). Siempre que una MSCA genere 
un par de claves de un Estado miembro, enviará la clave 
pública a la ERCA a fin de obtener un certificado corres­
pondiente del Estado miembro firmado por la ERCA.  
CSM_63 Una MSCA seleccionará la fortaleza de un par de claves 
de un Estado miembro igual a la fortaleza del par de claves 
raíz europeo utilizado para firmar el certificado correspon­
diente del Estado miembro.  
CSM_64 Un par de claves MSCA_VU-EGF, si está presente, estará 
compuesto por la clave privada MSCA_VU-EGF.SK y la 
clave pública MSCA_VU-EGF.PK. Una MSCA utilizará la 
clave privada MSCA_VU-EGF.SK exclusivamente para 
firmar los certificados de clave pública de las unidades 
instaladas en los vehículos y los dispositivos GNSS 
externos.  
CSM_65 Un par de claves MSCA_Card estará compuesto por la 
clave privada MSCA_Card.SK y la clave pública 
MSCA_Card.PK. Una MSCA utilizará la clave privada 
MSCA_Card.SK exclusivamente para firmar los certifica­
dos de clave pública y las tarjetas de tacógrafo.  
CSM_66 Una MSCA llevará un registro de todos los certificados 
VU, los certificados de dispositivo GNSS externo y los 
certificados de tarjeta firmados, junto con la identificación 
del equipo al que esté destinado cada certificado.  
CSM_67 El período de validez de un certificado MSCA_VU-EGF 
será de 17 años y 3 meses. El período de validez de un 
certificado MSCA_Card será de 7 años y 1 mes.  
CSM_68 Tal como muestra la Figure 1 de la sección 9.1.7, la cla ve 
privada de un par de claves MSCA_VU-EGF y la clave 
privada de un par de claves MSCA_Card tendrán un pe­
ríodo de uso de la clave de dos años.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 452  
CSM_69 Una MSCA no utilizará la clave privada de un par de 
claves MSCA_VU-EGF para ningún fin a partir del mo­
mento en que su período de uso haya finalizado. Una 
MSCA tampoco utilizará la clave privada de un par de 
claves MSCA_Card para ningún fin a partir del momento 
en que su período de uso haya finalizado.  
CSM_70 Una MSCA dispondrá en cualquier momento de las si­
guientes claves criptográficas y certificados:  
— El par de claves MSCA_Card actual y el certificado 
correspondiente.  
— Todos los certificados MSCA_Card anteriores que de­
berán utilizarse para la verificación de los certificados 
de tarjetas de tacógrafo que son todavía válidos.  
— El certificado EUR actual necesario para la verificación 
del certificado MSCA actual.  
— Todos los certificados EUR anteriores necesarios para 
la verificación de certificados MSCA que son todavía 
válidos.  
CSM_71 Si se solicita de una MSCA que firme certificados para 
unidades instaladas en los vehículos o dispositivos GNSS 
externos, la MSCA dispondrá además de las siguientes 
claves y certificados:  
— El par de claves MSCA_VU-EGF actual y el certifi­
cado correspondiente.  
— Todas las claves públicas MSCA_VU-EGF anteriores 
que deberán utilizarse para la verificación de los certi­
ficados de VU o de dispositivos GNSS externos que 
son todavía válidos.  
9.1.4  Nivel de equipo: Unidades instaladas en los vehículos  
▼M1 
CSM_72 Para cada unidad instalada en el vehículo se generarán d os 
pares de claves ECC únicos, designados VU_MA y 
VU_Sign. Esta tarea es efectuada por los fabricantes de 
VU. Siempre que se genere un nuevo par de claves VU, la 
parte que genere la clave enviará la clave pública a la 
MSCA, a fin de obtener el certificado VU correspondiente 
firmado por la MSCA. La clave privada será utilizada 
solamente por la unidad instalada en el vehículo.  
▼B 
CSM_73 Los certificados VU_MA y VU_Sign de una unidad con­
creta instalada en el vehículo tendrán la misma fecha de 
validez.  
CSM_74 Un fabricante de VU seleccionará la fortaleza de un par de 
claves VU igual a la fortaleza del par de claves MSCA 
utilizado para firmar el certificado correspondiente de la 
VU. 
CSM_75 Una unidad instalada en el vehículo utilizará su par de 
claves VU_MA, compuesto por la clave privada 
VU_MA.SK y la clave pública VU_MA.PK, exclusiva­
mente para efectuar la autenticación de la VU en tarjetas 
de tacógrafo y dispositivos GNSS externos, tal como se 
especifica en las secciones 10.3 y 11.4 del presente apén­
dice.  
CSM_76 Una unidad instalada en el vehículo deberá poder generar  
pares de claves ECC efímeros y utilizará un par de claves 
efímero exclusivamente para establecer la clave de sesión 
con una tarjeta de tacógrafo o dispositivo GNSS externo, 
tal como se especifica en las secciones 10.4 y 11.4 del 
presente apéndice.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 453  
CSM_77 Una unidad instalada en el vehículo utilizará la clave p ri­
vada VU_Sign.SK de su par de claves VU_Sign exclusi­
vamente para firmar archivos de datos descargados, tal 
como se especifica en el capítulo 14 del presente apéndice. 
La clave pública VU_Sign.PK correspondiente se utilizará 
exclusivamente para verificar las firmas creadas por la 
unidad instalada en el vehículo.  
CSM_78 Como se indica en la Figure 1 de la sección 9.1.7, el 
período de validez de un certificado VU_MA será de 15 
años y 3 meses. El período de validez de un certificado 
VU_Sign también será de 15 años y 3 meses.  
Notas:  
— El período de validez ampliado de un certificado 
VU_Sign permite a una unidad instalada en el vehículo 
crear firmas válidas en datos descargados durante los 
tres primeros meses posteriores a su caducidad, de 
conformidad con lo dispuesto en el Reglamento (UE) 
n o 581/2010.  
— El período de validez ampliado de un certificado 
VU_MA es necesario para permitir la autenticación 
de la VU con una tarjeta de control o una tarjeta de 
empresa durante los tres primeros meses posteriores a 
su caducidad, de tal modo que sea posible efectuar una 
descarga de datos.  
CSM_79 Una unidad instalada en el vehículo no utilizará la clav e 
privada de un par de claves VU para ningún fin una vez 
caducado el certificado correspondiente.  
CSM_80 Los pares de claves VU (excepto los pares de claves efí­
meros) y los certificados correspondientes de una unidad 
concreta instalada en el vehículo no se sustituirán ni reno­
varán en el campo una vez puesta en funcionamiento la 
unidad instalada en el vehículo.  
Notas:  
— Los pares de claves efímeros no están incluidos en este 
requisito, ya que una UV genera un nuevo par de 
claves efímero cada vez que se efectúa una autentica­
ción del chip y un acuerdo de claves de sesión, véase 
la sección 10.4. Obsérvese que los pares de claves 
efímeros carecen de certificados correspondientes.  
— Este requisito no prohíbe la posibilidad de sustituir 
pares de claves VU estáticos durante una renovación 
o reparación en un entorno seguro controlado por el 
fabricante de la VU.  
CSM_81 Una vez puestas en funcionamiento, las unidades instala­
das en los vehículos contendrán las siguientes claves crip­
tográficas y certificados:  
— La clave privada VU_MA y el certificado correspon­
diente.  
— La clave privada VU_Sign y el certificado correspon­
diente.  
— El certificado MSCA_VU-EGF que contiene la clave 
pública MSCA_VU-EGF que deberá utilizarse para la 
verificación del certificado VU_MA y el certificado 
VU_Sign.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 454  
— El certificado EUR que contiene la clave pública 
EUR.PK que deberá utilizarse para la verificación del 
certificado MSCA_VU-EGF.  
— El certificado EUR cuyo período de validez es direc­
tamente anterior al período de validez del certificado 
EUR que deberá utilizarse para verificar el certificado 
MSCA_VU-EGF, si existe.  
— El certificado de enlace que asocia estos dos certifica­
dos EUR, si existe.  
CSM_82 Además de las claves criptográficas y los certificados e nu­
merados en CSM_81, las unidades instaladas en los vehí­
culos deberán contener asimismo las claves y certificados 
especificados en la parte A del presente apéndice de forma 
que una unidad instalada en el vehículo pueda interactuar 
con las tarjetas de tacógrafo de primera generación.  
9.1.5  Nivel de equipo: Tarjetas de tacógrafo  
▼M1 
CSM_83 Para cada tarjeta de tacógrafo se generará un par de cla ves 
ECC único, designado Card_MA. Además, para cada tar­
jeta de conductor y cada tarjeta de taller se generará un 
segundo par de claves ECC único, designado Card_Sign. 
Esta tarea puede ser efectuada por los fabricantes de tar­
jetas o los personalizadores de tarjetas. Siempre que se 
genere un nuevo par de claves de tarjeta, la parte que 
genere la clave enviará la clave pública a la MSCA, a 
fin de obtener el certificado de la tarjeta correspondiente 
firmado por la MSCA. La clave privada será utilizada 
solamente por la tarjeta de tacógrafo.  
▼B 
CSM_84 Los certificados Card_MA y Card_Sign de una tarjeta de 
conductor o de una tarjeta de taller concretas tendrán la 
misma fecha de validez.  
CSM_85 Un fabricante de tarjetas o un personalizador de tarjeta s 
seleccionará la fortaleza de un par de claves de tarjeta 
igual a la fortaleza del par de claves MSCA utilizado 
para firmar el certificado correspondiente de la tarjeta.  
CSM_86 Una tarjeta de tacógrafo utilizará su par de claves 
Card_MA, compuesto por la clave privada Card_MA.SK 
y la clave pública Card_MA.PK, exclusivamente para efec­
tuar la autenticación mutua y establecer la clave de sesión 
con las unidades instaladas en los vehículos, tal como se 
especifica en las secciones 10.3 y 10.4 del presente apén­
dice.  
CSM_87 Una tarjeta de conductor o tarjeta de taller utilizará l a clave 
privada Card_Sign.SK de su par de claves Card_Sign ex­
clusivamente para firmar archivos de datos descargados, tal 
como se especifica en el capítulo 14 del presente apéndice. 
La clave pública Card_Sign.PK correspondiente se utili­
zará exclusivamente para verificar las firmas creadas por 
la tarjeta.  
▼M1 
CSM_88 El período de validez de un certificado Card_MA será el 
siguiente:  
— Para las tarjetas de conductor: 5 años  
— Para las tarjetas de empresa: 5 años  
— Para las tarjetas de control: 2 años  
— Para las tarjetas de taller: 1 año  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 455  
CSM_89 El período de validez de un certificado Card_Sign será e l 
siguiente: 
— Para las tarjetas de conductor:  5 años y 1 mes  
— Para las tarjetas de taller:  1 año y 1 mes  
Nota:  El período de validez ampliado de un certificado 
Card_Sign permite a una tarjeta de conductor crear firmas 
válidas en datos descargados durante el primer mes poste­
rior a su caducidad. Esto es necesario de conformidad con 
el Reglamento (UE) n  o 581/2010 que exige que sea posi­
ble efectuar una descarga de datos de una tarjeta de con­
ductor hasta transcurridos 28 días desde el último registro 
de datos.  
CSM_90 Los pares de claves y los certificados correspondientes de 
una tarjeta de tacógrafo concreta no se sustituirán ni reno­
varán una vez expedida la tarjeta.  
CSM_91 Una vez expedidas, las tarjetas de tacógrafo contendrán las 
siguientes claves criptográficas y certificados:  
— La clave privada Card_MA y el certificado 
correspondiente.  
— Además, en lo que se refiere a las tarjetas de conductor 
y las tarjetas de taller: la clave privada Card_Sign y el 
certificado correspondiente.  
— El certificado MSCA_Card que contiene la clave pú­
blica MSCA_Card.PK que deberá utilizarse para la 
verificación del certificado Card_MA y el certificado 
Card_Sign.  
— El certificado EUR que contiene la clave pública 
EUR.PK que deberá utilizarse para la verificación del 
certificado MSCA_Card.  
— El certificado EUR cuyo período de validez es direc­
tamente anterior al período de validez 
del certificado EUR que deberá utilizarse para verificar 
el certificado MSCA_Card, si existe.  
— El certificado de enlace que asocia estos 
dos certificados EUR, si existe.  
▼M1 
— Además, para las tarjetas de control, las tarjetas de 
empresa y las tarjetas de taller, y solo si estas tarjetas 
se expiden durante los tres primeros meses del período 
de validez del nuevo certificado EUR: 
el certificado EUR que sea dos generaciones más an­
tiguo, de existir este.  
Nota al último guion : por ejemplo, en los tres primeros 
meses del certificado ERCA (3) (véase la figura 1), las 
mencionadas tarjetas contendrán el certificado ERCA 
(1). Esto es necesario para garantizar que estas tarjetas 
pueden utilizarse para realizar transferencias de datos 
desde VU con certificado ERCA (1) cuyo período de 
vida normal de quince años más el período de tres 
meses para transferir los datos expira durante estos 
meses; véase el último guion del requisito 13 del 
anexo IC.  
▼B 
CSM_92 Además de las claves criptográficas y los certificados e nu­
merados en CSM_91, las tarjetas de tacógrafo deberán 
contener asimismo las claves y certificados especificados 
en la parte A del presente apéndice de forma que estas 
tarjetas puedan interactuar con las unidades instaladas en 
los vehículos de primera generación.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 456  
9.1.6  Nivel de equipo: Dispositivos GNSS externos  
▼M1 
CSM_93 Para cada dispositivo GNSS externo se generará un par de  
claves ECC único designado EGF_MA. Esta tarea es efec­
tuada por los fabricantes de dispositivos GNSS externos. 
Siempre que se genere un nuevo par de claves EGF_MA, 
la parte que genere la clave enviará la clave pública a la 
MSCA, a fin de obtener el certificado EGF_MA corres­
pondiente firmado por la MSCA. La clave privada será 
utilizada solamente por el dispositivo GNSS externo.  
▼B 
CSM_94 Un fabricante de EGF seleccionará la fortaleza de un par  
de claves EGF_MA igual a la fortaleza del par de claves 
MSCA utilizado para firmar el certificado correspondiente 
de EGF_MA.  
▼M1 
CSM_95 Una dispositivo GNSS externo utilizará su par de claves 
EGF_MA, compuesto por la clave privada EGF_MA.SK y 
la clave pública EGF_MA.PK, exclusivamente para efec­
tuar la autenticación mutua y establecer la clave de sesión 
con las unidades instaladas en los vehículos, tal como se 
especifica en el apartado 11.4 del presente apéndice.  
▼B 
CSM_96 El período de validez del certificado EGF_MA será de 15 
años.  
CSM_97 Un dispositivo GNSS externo no utilizará la clave privad a 
de su par de claves EGF_MA para acoplarse con una 
unidad instalada en el vehículo una vez caducado el certi­
ficado correspondiente.  
Nota:  tal como se indica en la sección 11.3.3, una EGF 
puede potencialmente utilizar su clave privada para la au­
tenticación mutua con la VU con la que ya esté acoplada, 
aun después de caducado el certificado correspondiente.  
CSM_98 El par de claves EGF_MA y el certificado correspondiente  
de un dispositivo GNSS externo concreto no se sustituirán 
ni renovarán en el campo una vez puesta en funciona­
miento la EGF.  
Nota:  Este requisito no prohíbe la posibilidad de sustituir 
pares de claves EGF durante una renovación o reparación 
en un entorno seguro controlado por el fabricante de la 
EGF.  
CSM_99 Una vez puesta en funcionamiento, un dispositivo GNSS 
externo contendrá las siguientes claves criptográficas y 
certificados:  
— La clave privada EGF_MA y el certificado 
correspondiente.  
— El certificado MSCA_VU-EGF que contiene la clave 
pública MSCA_VU-EGF.PK que deberá utilizarse para 
la verificación del certificado EGF_MA.  
— El certificado EUR que contiene la clave pública 
EUR.PK que deberá utilizarse para la verificación del 
certificado MSCA_VU-EGF.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 457  
— El certificado EUR cuyo período de validez es direc­
tamente anterior al período de validez del certificado 
EUR que deberá utilizarse para verificar el certificado 
MSCA_VU-EGF, si existe.  
— El certificado de enlace que asocia estos dos certifica­
dos EUR, si existe.  
9.1.7  Síntesis: Sustitución del certificado  
La Figure 1 siguiente ilustra cronológicamente la forma en que se expi­
den y utilizan los certificados raíz ERCA, los certificados de enlace 
ERCA, los certificados MSCA y los certificados de equipos (VU y  
tarjeta):  
▼M1 
Figura 1  
Expedición y uso de las diferentes generaciones de certificados raíz ERCA, certificados de enlace ERCA, 
certificados MSCA y certificados de equipos
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 458  
Notas de la Figure 1:  
1. Las diferentes generaciones del certificado raíz se indican mediante un 
número entre paréntesis. Por ejemplo, ERCA (1) es la primera ge ne­
ración del certificado raíz ERCA; ERCA (2) es la segunda genera ción, 
etc. 
2. Los demás certificados se indican mediante dos números entre  parén­
tesis, el primero de los cuales indica la generación del certif icado raíz 
correspondiente, y el segundo la generación del propio certific ado. Por 
ejemplo, MSCA_Card (1-1) es el primer certificado MSCA_Card 
expedido en el marco del ERCA (1); MSCA_Card (2-1) es el primer  
certificado MSCA_Card expedido en el marco del ERCA (2); 
MSCA_Card (2-last) es el último certificado MSCA_Card expedido 
en el marco del ERCA (2); MSCA_Card (2-1) es el primer certific ado 
para la autenticación mutua expedido en el marco del ERCA (2), etc. 
3. Los certificados MSCA_Card (2-1) y MSCA_Card (1-last) son ex pe­
didos casi en la misma fecha, pero no exactamente. MSCA_Card (2 - 
1) es el primer certificado MSCA_Card expedido en el marco del 
ERCA (2) y será expedido poco tiempo después que MSCA_Card 
(1-last), el último certificado MSCA_Card en el marco del ERCA (1). 
4. Como indica la figura, los primeros certificados VU y Card e xpedidos 
en el marco del ERCA (2) aparecerán casi dos años antes de que 
aparezcan los últimos certificados VU y Card expedidos en el ma rco 
del ERCA (1). Esto es así porque los certificados VU y Card son  
expedidos en el marco de un certificado MSCA, y no directamente  en 
el marco del certificado ERCA. El certificado MSCA (2-1) será e x­
pedido directamente después de que adquiera validez el ERCA (2) , 
pero el certificado MSCA (1-last) será expedido solamente poco 
tiempo antes, en el último momento en que el certificado ERCA ( 1) 
es todavía válido. Por consiguiente, estos dos certificados MSC A 
tendrán casi el mismo período de validez, a pesar de que sean d e 
dos generaciones diferentes.  
5. El período de validez indicado para las tarjetas es el de la s tarjetas de 
conductor (5 años).  
▼M1 
6. Por limitaciones de espacio, solamente se indica la diferenc ia entre los 
períodos de validez de los certificados Card_MA y Card_Sign de la 
primera generación.  
▼B 
9.2. Claves simétricas  
9.2.1  Claves de aseguramiento de la comunicación entre la VU y el sensor de 
movimiento  
9.2.1.1  Generalidades  
Nota:  se da por supuesto que los lectores de la presente sección est án 
familiarizados con el contenido de la norma [ISO 16844-3] que d escribe 
la interfaz entre una unidad instalada en el vehículo y un sens or de 
movimiento. El proceso de emparejamiento entre una VU y un sens or 
de movimiento se describe en detalle en el capítulo 12 del pres ente 
apéndice.  
CSM_100 Para aparear unidades instaladas en los vehículos y sen sores 
de movimiento son necesarias varias claves simétricas a 
efectos de la autenticación mutua entre las unidades instala­
das en los vehículos y los sensores de movimiento y del 
cifrado de la comunicación entre las unidades instaladas en 
los vehículos y los sensores de movimiento, como se indica 
en la Table 3. Todas estas claves serán claves AES, con una 
longitud de clave igual a la longitud de la clave maestra del 
sensor de movimiento, que estará relacionada con la longi­
tud del par de claves raíz (previsto), tal como se describe en 
CSM_50.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 459  
Tabla 3  
Claves de aseguramiento de la comunicación entre la unidad instalada en el vehículo y el sensor de movimiento  
Clave  Símbolo  Generada por  Método de generación  Almacenada por  
Clave maestra del sensor 
de movimiento — parte 
VU K M-VU  ERCA  Aleatorio  ERCA, MSCA implicadas en 
la expedición de certificados 
de VU, fabricantes de VU, uni­
dades instaladas en los vehícu­
los 
Clave maestra del sensor 
de movimiento — parte 
taller  K M-WC  ERCA  Aleatorio  ERCA, MSCA, fabricantes de 
tarjetas, tarjetas de taller  
Clave maestra del sensor 
de movimiento  K M No generada inde­
pendientemente  Calculada como K  M = 
K M-VU  XOR K  M-WC  ERCA, MSCA implicadas en 
la expedición de claves de sen­
sores de movimiento (opcional­
mente) (*)  
Clave de identificación  K  ID No generada inde­
pendientemente  Calculada como K  ID =  
K M XOR CV, donde 
CV se especifica en 
CSM_106  ERCA, MSCA implicadas en 
la expedición de claves de sen­
sores de movimiento (opcional­
mente) (*)  
Clave de emparejamiento  K  P Fabricante del sen­
sor de movimiento  Aleatorio  Un sensor de movimiento  
Clave de sesión  K  S VU (durante el 
emparejamiento de 
la VU y el sensor 
de movimiento)  Aleatorio  Una VU y un sensor de movi­
miento  
(*) El almacenamiento de K  M y K  ID es optativo, ya que estas claves pueden derivarse de K  M-VU  , K  M-WC  y CV.  
CSM_101 La Autoridad del Certificado Raíz Europeo generará K  M-VU  
yd K  M-WC  , dos claves AES aleatorias y únicas a partir de las 
cuales la clave maestra del sensor de movimiento K  M se 
puede calcular como K  M-VU  XOR K  M-WC  . La ERCA comu­
nicará previa solicitud las claves K  M , K  M-VU  y K  M-WC  a las 
autoridades de certificación de los Estados miembros.  
CSM_102 La ERCA asignará a cada clave maestra de sensor de mo­
vimiento K  M un número de versión único, que será asi­
mismo aplicable para las claves constitutivas K  M-VU  y K  M- 
WC y para la clave de identificación asociada K  ID . La ERCA 
comunicará a las MSCA el número de versión al enviarles 
las claves K  M-VU  y K  M-WC  . 
Nota:  El número de versión se usa para distinguir genera­
ciones diferentes de estas claves, como se explica en detalle 
en la sección 9.2.1.2.  
CSM_103 Las autoridades de certificación de los Estados miembro s 
remitirán previa solicitud la clave K  M-VU  , junto con su nú­
mero de versión, a los fabricantes de unidades instaladas en 
los vehículos. Los fabricantes de VU insertarán la clave K  M- 
VU y su número de versión en todas las VU fabricadas.  
CSM_104 Las autoridades de certificación de los Estados miembro s 
garantizarán que la clave K  M-WC  , junto con su número de 
versión, sea insertada en cada tarjeta de taller expedida bajo 
su responsabilidad.  
Notas:  
— Véase la descripción del tipo de dato
  
en el apéndice 2.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 460  
— Como se indica en la sección 9.2.1.2, de hecho puede 
ser necesario insertar múltiples generaciones de la clave 
K M-WC  en la misma tarjeta de taller.  
CSM_105 Además de la clave AES especificada en CSM_104, las 
MSCA garantizarán que la clave Km  WC en TDES especifi­
cada en el requisito CSM_037 de la parte A del presente 
apéndice sea también insertada en cada tarjeta de taller ex­
pedida bajo su responsabilidad.  
Notas:  
— Esto permite utilizar una tarjeta de taller de segunda 
generación para emparejar una VU de primera genera­
ción.  
— Una tarjeta de taller de segunda generación contendrá 
dos aplicaciones diferentes, una conforme con la parte 
B del presente apéndice y otra conforme con la parte A. 
Esta última contendrá la clave Km  WC en TDES.  
CSM_106 Las MSCA implicadas en la expedición de sensores de mo­
vimiento derivarán la clave de identificación a partir de la 
clave maestra del sensor de movimiento aplicándole el ope­
rador XOR con un vector constante CV. El valor de CV será 
el siguiente:  
▼M1 
— Para las claves maestras de sensor de movimiento de 128 
bits: CV = «B6 44 2C 45 0E F8 D3 62 0B 7A 8A 97 91 
E4 5D 83»  
▼B 
— Para las claves maestras de sensor de movimiento de 192 
bits: 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»  
— Para las claves maestras de sensor de movimiento de 256 
bits: 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»  
Nota:  los vectores constantes se han generado de la si­
guiente manera:  
Pi_10 = primeros 10 bytes de la porción decimal de la cons­
tante matemática π = «24 3F 6A 88 85 A3 08 D3 13 19»  
CV_128-bits = primeros 16 bytes de SHA-256(Pi_10)  
CV_192-bits = primeros 24 bytes de SHA-384(Pi_10)  
CV_256-bits = primeros 32 bytes de SHA-512(Pi_10)  
CSM_107  ►M1 Cada fabricante de sensores de movimiento generará 
una clave de emparejamiento K  P aleatoria y única para cada 
sensor de movimiento y enviará cada clave de empareja­
miento a la autoridad de certificación de su Estado miembro. 
La MSCA cifrará cada clave de emparejamiento separada­
mente con la clave maestra K  M del sensor de movimiento y 
devolverá la clave cifrada al fabricante del sensor de movi­
miento. Para cada clave cifrada, la MSCA notificará al fa­
bricante del sensor de movimiento el número de versión de 
la K  M asociada. ◄  
Nota:  como se indica en la sección 9.2.1.2, de hecho puede 
ser necesario que un fabricante de sensores de movimiento 
tenga que generar claves de emparejamiento únicas múlti­
ples para el mismo sensor de movimiento.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 461  
CSM_108 Cada fabricante de sensores de movimiento generará un 
número de serie único para cada sensor de movimiento y 
enviará todos los números de serie a la autoridad de certi­
ficación de su Estado miembro. La MSCA cifrará cada nú­
mero de serie separadamente con la clave de identificación 
maestra K  ID y devolverá el número de serie cifrado al fa­
bricante del sensor de movimiento. Para cada número de 
serie cifrado, la MSCA notificará al fabricante del sensor 
de movimiento el número de versión de la K  ID asociada.  
▼B 
CSM_109 Para los requisitos CSM_107 y CSM_108, la MSCA utili­
zará el algoritmo AES in el modo de funcionamiento de 
cifrado progresivo por bloques, tal como se define en la 
norma [ISO 10116], con un parámetro interpolar  m =  1  y  
un vector de inicialización SV = «00» {16}, es decir, die­
ciséis bytes con valor binario 0. Cuando sea necesario, la 
MSCA utilizará el método de relleno 2 definido en la norma 
[ISO 9797-1].  
CSM_110 El fabricante del sensor de movimiento almacenará la cl ave 
de emparejamiento cifrada y el número de serie cifrado en el 
sensor de movimiento de que se trate, junto con los valores 
de texto sencillo correspondientes y el número de versión de 
las claves K  M y K  ID utilizadas para el cifrado.  
Nota:  como se indica en la sección 9.2.1.2, de hecho puede 
ser necesario que un fabricante de sensores de movimiento 
tenga que insertar múltiples claves de emparejamiento cifra­
das y múltiples números de serie cifrados en el mismo sen­
sor de movimiento.  
CSM_111 Además del material criptográfico basado en la norma AE S 
especificado en CSM_110, puede ser necesario que un fa­
bricante de sensores de movimiento tenga que almacenar 
asimismo en cada sensor de movimiento el material cripto­
gráfico en TDES especificado en el requisito CSM_037 de 
la parte A del presente apéndice.  
Nota:  esto permitirá que un sensor de movimiento de se­
gunda generación pueda ser acoplado a una VU de primera 
generación.  
CSM_112 La longitud de la clave de sesión K  S generada por una VU 
durante el emparejamiento con un sensor de movimiento 
estará relacionada con la longitud de su K  M-VU  , tal como 
se describe en CSM_50.  
9.2.1.2  Sustitución de la clave maestra del sensor de movimiento en los equipos 
de segunda generación  
CSM_113 Cada clave maestra del sensor de movimiento y todas las  
claves relacionadas (véase la Table 3) está asociada a una 
generación concreta del par de claves raíz de la ERCA. 
Estas claves se pueden por tanto sustituir cada 17 años. El 
período de validez de cada generación de clave maestra del 
sensor de movimiento comenzará un año antes de que ad­
quiera validez el par de claves raíz de la ERCA asociado y 
finalizará cuando caduque el par de claves raíz de la ERCA 
asociado, tal como viene ilustrado en la Figure 2.  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 462  
Figura 2  
Expedición y uso de diferentes generaciones de la clave maestra del sensor de movimiento en las unidades 
instaladas en los vehículos, sensores de movimiento y tarjetas de taller
  
CSM_114 Al menos un año antes de generar un nuevo par de claves  
raíz europeo, tal como se describe en el punto CSM_56, la 
ERCA generará una nueva clave maestra del sensor de mo­
vimiento K  M generando las nuevas claves K  M-VU  y K  M-WC  
La longitud de la clave maestra del sensor de movimiento 
estará relacionada con la longitud prevista del nuevo par de 
claves raíz europeo, de conformidad con el punto CSM_50. 
La ERCA comunicará, previa solicitud, las nuevas claves 
K M , K  M-VU  yd K  M-WC  , junto con su número de versión, a 
las MSCA.  
CSM_115 Las MSCA garantizarán que todas las generaciones válida s 
de la clave K  M-WC  sean almacenadas en cada tarjeta de taller 
expedida bajo su autoridad, junto con su número de versión, 
tal como se indica en la Figure 2.  
Nota:  esto implica que durante el último año del período de 
validez de un certificado ERCA, las tarjetas de taller serán 
expedidas con tres generaciones diferentes de la clave K  M- 
WC , tal como se indica en la Figure 2.  
CSM_116 En relación con el proceso descrito anteriormente en 
CSM_107 y CSM_108: Las MSCA cifrarán cada clave de 
emparejamiento K  P que reciban de un fabricante de sensores 
de movimiento separadamente con cada generación válida 
de la clave maestra del sensor de movimiento K  M . Las 
MSCA cifrarán asimismo cada número de serie que reciban 
de un fabricante de sensores de movimiento separadamente 
con cada generación válida de la clave de identificación K  ID . 
Los fabricantes de sensores de movimiento almacenarán to­
dos los cifrados de la clave de emparejamiento y todos los 
cifrados del número de serie en el sensor de movimiento de 
que se trate, junto con los valores de texto sencillo corres­
pondientes y el número o los números de versión de las 
claves K  M y K  ID utilizadas para el cifrado.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 463  
Nota:  Esto implica que durante el último año del período de 
validez de un certificado ERCA, los sensores de movimiento 
serán expedidos con datos cifrados basados en tres genera­
ciones diferentes de la clave K  M , tal como se indica en la 
Figure 2.  
CSM_117 En relación con el proceso descrito anteriormente en 
CSM_107: Puesto que la longitud de la clave de empareja­
miento K  P estará relacionada con la longitud de la clave K  M 
(véase CSM_100), es posible que un fabricante de sensores 
de movimiento tenga que generar hasta tres claves de em­
parejamiento diferentes (de diferentes longitudes) para un 
sensor de movimiento, para el caso en que generaciones 
posteriores de la clave K  M tengan longitudes diferentes. 
En tal caso, el fabricante enviará cada clave de empareja­
miento a la MSCA. La MSCA garantizará que cada clave de 
emparejamiento sea cifrada con la generación correcta de la 
clave maestra del sensor de movimiento, es decir, con la que 
tenga la misma longitud.  
Nota:  En el caso de que el fabricante de sensores de movi­
miento opte por generar en TDES una clave de empareja­
miento para un sensor de movimiento de segunda genera­
ción (véase CSM_111), el fabricante indicará a la MSCA 
que para cifrar esta clave de emparejamiento debe emplearse 
la clave maestra en TDES del sensor de movimiento. Esto es 
así porque la longitud de una clave TDES puede ser igual a 
la de una clave AES, de forma que la MSCA no puede 
distinguir una de la otra solamente por la longitud de la 
clave.  
CSM_118 Los fabricantes de unidades instaladas en los vehículos  in­
sertarán solamente una generación de la clave K  M-VU  en 
cada unidad instalada en el vehículo, junto con su número 
de versión. Esta generación de clave K  M-VU  estará relacio­
nada con el certificado de la ERCA en que se basen los 
certificados de la UV.  
Notas:  
— Una unidad instalada en el vehículo basada en el certi­
ficado ERCA de generación X solamente deberá conte­
ner la clave K  M-VU  de generación X aun en el caso de 
que sea expedida después del inicio del período de va­
lidez del certificado ERCA de generación X+1. Esto 
viene ilustrado en la Figure 2.  
— Una VU de generación X no puede emparejarse con un 
sensor de movimiento de generación X-1.  
— Puesto que las tarjetas de taller tienen un período de 
validez de un año, el resultado de CSM_113 — 
CSM_118 es que todas las tarjetas de taller contendrán 
la nueva clave K  M-WC  en el momento en que sea expe­
dida la primera VU que contenga la nueva clave K  M-VU  . 
Por consiguiente, esa VU siempre podrá calcular la 
nueva clave K  M. . Además, para entonces la mayoría de 
los sensores de movimiento nuevos contendrán datos 
cifrados también basados en la nueva clave K  M. . 
9.2.2  Claves de aseguramiento de comunicaciones dedicadas de corto 
alcance (DSRC)  
9.2.2.1  Generalidades  
CSM_119 La autenticidad y confidencialidad de los datos comunic ados 
desde una unidad instalada en el vehículo a una autoridad de 
control a través de un canal de comunicación remota DSRC 
se asegurará mediante una serie de claves AES específicas 
de la VU derivadas de una única clave maestra de DSRC, 
KM  DSRC  . ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 464  
CSM_120 La clave maestra de DSRC KM  DSRC  será una clave AES 
generada, almacenada y distribuida de forma segura por la 
ERCA. La longitud de la clave será de 128, 192 o 256 bits y 
estará relacionada con la longitud del par de claves raíz 
europeo, tal como se describe en CSM_50.  
CSM_121 La ERCA comunicará previa solicitud la clave maestra 
DSRC a las autoridades de certificación de los Estados 
miembros de forma segura a fin de permitirles derivar claves 
DSRC específicas de las VU y asegurar que la clave maestra 
DSRC sea insertada en todas las tarjetas de control y tarjetas 
de taller expedidas bajo su responsabilidad.  
CSM_122 La ERCA asignará a cada clave maestra DSRC un número 
de versión único. La ERCA comunicará a las MSCA el 
número de versión al enviarles la clave maestra DSRC.  
Nota:  El número de versión se usa para distinguir genera­
ciones diferentes de la clave maestra DSRC, como se ex­
plica en detalle en la sección 9.2.2.2.  
▼M1 
CSM_123 Para cada unidad instalada en el vehículo, el fabricant e de la 
unidad instalada en el vehículo creará un número de serie de 
la VU único y lo enviará a la autoridad de certificación de 
su Estado miembro en una solicitud de obtención de un 
conjunto de dos claves DSRC específicas de la VU. El 
número de serie de la VU tendrá el tipo de dato
  
. 
Nota:  
— Este número de serie de la VU será idéntico al elemento 
vuSerialNumber de VuIdentification, véase el apéndice 1 
y la referencia del titular del certificado en los certifica­
dos de la VU.  
— El número de serie de la VU puede no conocerse en el 
momento en que el fabricante de la unidad instalada en 
el vehículo solicita las claves DSRC específicas de la 
VU. En este caso, el fabricante de la VU enviará el 
identificador único de la solicitud de certificado que 
utilizó al solicitar los certificados de la VU; véase 
CSM_153. Dicho identificador de la solicitud de certifi­
cado será, por tanto, igual a la referencia del titular del 
certificado de los certificados de la VU.  
▼B 
CSM_124 Cuando reciba una solicitud de claves DSRC específicas de 
una VU, la MSCA derivará dos claves AES para la unidad 
instalada en el vehículo, denominadas K_VU  DSRC  _ENC y 
K_VU  DSRC  _MAC. Estas claves específicas de la VU ten­
drán la misma longitud que la clave maestra DSRC. La 
MSCA utilizará la función de derivación de claves definida 
en el documento [RFC 5869]. La función resumen (o fun­
ción hash) necesaria para instanciar la función HMAC-Hash 
estará relacionada con la longitud de la clave maestra 
DSRC, tal como se describe en CSM_50. La función de 
derivación de la clave que figura en el documento [RFC 
5869] se utilizará del siguiente modo:  
Paso 1 (Extraer):  
— PRK  = HMAC-Hash ( salt, IKM ) donde  salt  es una ca­
dena vacía «» e  IKM  es KM  DSRC  . ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 465  
Paso 2 (Expandir):  
— OKM  = T(1) , donde  
T(1) = HMAC-Hash ( PRK , T(0)  | | info  || «01») con  
— T(0)  = una cadena vacía («»)  
— ►M1 info  = = número de serie o identificador de la 
solicitud de certificado de la VU tal como se espe­
cifica en CSM_123 ◄  
— K_VU  DSRC  _ENC = primeros octetos  L d e OKM  y 
K_VU  DSRC  _MAC = últimos octetos  L d e OKM  
donde  L es la longitud requerida de K_VU  DSRC  _ENC y 
K_VU  DSRC  _MAC en octetos.  
CSM_125 La MSCA distribuirá las claves K_VU  DSRC  _ENC y 
K_VU  DSRC  _MAC al fabricante de VU de forma segura 
para su inserción en la unidad instalada en el vehículo de 
que se trate.  
CSM_126 Una vez expedida, una unidad instalada en el vehículo l le­
vará almacenadas las claves K_VU  DSRC  _ENC y 
K_VU  DSRC  _MAC en su memoria protegida a fin de poder 
garantizar la integridad, autenticidad y confidencialidad de 
los datos enviados por el canal de comunicación remota. 
Una unidad instalada en el vehículo también llevará alma­
cenado el número de versión de la clave maestra DSRC 
utilizada para derivar estas claves específicas de la VU.  
CSM_127 Una vez expedidas, las tarjetas de control y las tarjet as de 
taller llevarán almacenada la clave KM  DSRC  en su memoria 
protegida a fin de poder verificar la integridad y autenticidad  
de los datos enviados por una VU por un canal de comu­
nicación remota y de descifrar estos datos. Las tarjetas de 
control y las tarjetas de taller también llevarán almacenado 
el número de versión de la clave maestra DSRC.  
Nota:  Como se indica en la sección 9.2.2.2, de hecho puede 
ser necesario insertar múltiples generaciones de la clave 
KM  DSRC  en la misma tarjeta de taller o tarjeta de control.  
▼M1 
CSM_128 La MSCA llevará un registro de todas las claves DSRC 
específicas de VU que haya generado, su número de versión 
y el número de serie o el identificador de la solicitud de 
certificado de la VU utilizados para derivarlas.  
▼B 
9.2.2.2  Sustitución de la clave maestra DSRC  
CSM_129 Cada clave maestra DSRC está asociada a una generación 
concreta del par de claves raíz de la ERCA. Por consi­
guiente, la ERCA sustituirá la clave maestra DSRC dada 
17 años. El período de validez de cada generación de clave 
maestra DSRC comenzará dos años antes de que adquiera 
validez el par de claves raíz de la ERCA asociado y finali­
zará cuando caduque el par de claves raíz de la ERCA 
asociado, tal como se ilustra en la Figure 3.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 466  
Figura 3  
Expedición y uso de diferentes generaciones de la clave maestra DSRC en las unidades instaladas en los 
vehículos, tarjetas de taller y tarjetas de control
  
CSM_130 Al menos un año antes de generar un nuevo par de claves  
raíz europeo, tal como se describe en el punto CSM_56, la 
ERCA generará una nueva clave maestra DSRC. La longi­
tud de la clave maestra DSRC estará relacionada con la 
longitud prevista del nuevo par de claves raíz europeo, de 
conformidad con el punto CSM_50. La ERCA comunicará, 
previa solicitud, la nueva clave DSRC, junto con su número 
de versión, a las MSCA.  
CSM_131 Las MSCA garantizarán que todas las generaciones válida s 
de la clave KM  DSRC  sean almacenadas en cada tarjeta de 
control expedida bajo su autoridad, junto con sus números 
de versión, tal como se indica en la Figure 2.  
Nota:  esto implica que durante los dos últimos años del 
período de validez de un certificado ERCA, las tarjetas de 
control serán expedidas con tres generaciones diferentes de 
la clave KM  DSRC  , tal como se indica en la Figure 2.  
CSM_132 Las MSCA garantizarán que todas las generaciones de la 
clave KM  DSRC  que hayan sido válidas durante al menos 
un año sean almacenadas en cada tarjeta de control expedida 
bajo su autoridad, junto con sus números de versión, tal 
como se indica en la Figure 2.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 467  
Nota:  esto implica que durante el último año del período de 
validez de un certificado ERCA, las tarjetas de taller serán 
expedidas con tres generaciones diferentes de la clave 
KM  DSRC  , tal como se indica en la Figure 2.  
CSM_133 Los fabricantes de unidades instaladas en los vehículos  in­
sertarán solamente un conjunto de claves DSRC específicas 
de la VU en cada unidad instalada en el vehículo, junto con 
su número de versión. Este conjunto de claves se derivará de 
la generación de la KM  DSRC  relacionada con el certificado 
de la ERCA en que se basen los certificados de la VU.  
Notas:  
— Esto implica que una unidad instalada en el vehículo 
basada en el certificado ERCA de la generación X sola­
mente deberá contener las claves K_VU  DSRC  _ENC K  M- 
VU y K_VU  DSRC  _MAC de la generación X, aun en el 
caso de que la VU sea expedida después del inicio del 
período de validez del certificado ERCA de la genera­
ción X+1., tal como se indica en la Figure 3.  
— Puesto que las tarjetas de taller tienen un período de 
validez de un año y las tarjetas de control de dos años, 
el resultado de CSM_131 — CSM_133 es que todas las 
tarjetas de taller y tarjetas de control contendrán la nueva 
clave maestra DSRC en el momento en que sea expedida 
la primera VU que contenga claves específicas de la VU 
basadas en esa clave maestra.  
9.3. Certificados  
9.3.1  Generalidades  
CSM_134 Todos los certificados del sistema europeo de tacógrafo  in­
teligente serán certificados autodescriptivos y verificables 
con tarjeta (CV) de acuerdo con las normas [ISO 7816-4] 
y [ISO 7816-8].  
CSM_135  ►M1 A fin de codificar los objetos de datos en los certi­
ficados, se utilizarán las reglas de codificación distinguida 
(DER) de acuerdo con la norma [ISO 8825-1]. La tabla 4 
muestra la codificación completa del certificado, incluidas 
todas las etiquetas y los bytes de longitud. ◄  
Nota:  esta codificación resulta en una estructura 
etiqueta-longitud-valor (TLV) como la siguiente:  
Etiqueta: La etiqueta está codificada en uno o dos octetos e 
indica el contenido.  
Longitud: La longitud está codificada como un número en­
tero no firmado en uno, dos, o tres octetos, que 
resultan en una longitud máxima de 65 535 octe­
tos. Se utilizará el número de octetos mínimo.  
Valor: El valor está codificado en cero o más octetos.  
9.3.2  Contenido de los certificados  
CSM_136 Todos los certificados tendrá la estructura indicada en  el 
perfil de certificado de la Table 4.  
Tabla 4  
Perfil de certificado versión 1  
Campo  ID del campo  Etiqueta  Longitud (bytes)  Tipo de dato ASN.1 
(véase el apéndice 1)  
Certificado ECC  C  «7F 21»  var  
Organismo de certifi­
cación ECC  B «7F 4E»  var  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 468  
Campo  ID del campo  Etiqueta  Longitud (bytes)  Tipo de dato ASN.1 
(véase el apéndice 1)  
Identificador del per­
fil de certificado  CPI «5F 29»  «01»
  
Referencia de la auto­
ridad de certificación  CAR  «42»  «08»
  
Autorización del titu­
lar del certificado  CHA  «5F 4C»  «07»
  
Clave pública  P K  «7F 49»  var  
Parámetros de domi­
nio DP «06»  var
  
Punto público  P P  «86»  var
  
Referencia al titular 
del certificado  CHR  «5F 20»  «08»
  
Fecha efectiva del 
certificado  CEfD  «5F 25»  «04»
  
Fecha de caducidad 
del certificado  CExD  «5F 24»  «04»
  
Firma del certificado 
ECC  S «5F 37»  var
  
Nota:  el ID del campo se utilizará más adelante en otras 
secciones del presente apéndice para indicar campos indivi­
duales de un certificado, por ejemplo, X.CAR es la referen­
cia de la autoridad de certificación mencionada en el certi­
ficado del usuario X.  
9.3.2.1 Identificador del perfil de certificado  
CSM_137 Los certificados utilizarán un identificador del perfil  de cer­
tificado para indicar el perfil de certificado utilizado. La 
versión 1, tal como se especifica en la Table 4, se identifi­
cará con el valor «00».  
9.3.2.2 Referencia de la autoridad de certificación  
CSM_138 La referencia de la autoridad de certificación se utili zará 
para identificar la clave pública que se deberá utilizar para 
verificar la firma del certificado. La referencia de la autori­
dad de certificación será por tanto igual a la referencia del 
titular del certificado en el certificado de la autoridad de 
certificación correspondiente.  
CSM_139 Un certificado raíz de la ERCA estará autofirmado, es d ecir, 
la referencia en el certificado de la autoridad de certificació n 
y del titular del certificado serán iguales.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 469  
CSM_140 Para un certificado de enlace ERCA, la referencia del t itular 
del certificado será igual a la CHR del nuevo certificado raíz 
de la ERCA. La referencia de la autoridad de certificación 
para un certificado de enlace será igual a la CHR del certi­
ficado raíz ERCA anterior.  
9.3.2.3 Autorización del titular del certificado (CHA)  
▼M1 
CSM_141 La autorización del titular del certificado servirá par a iden­
tificar el tipo de certificado. Se compone de los seis bytes 
más significativos del identificador de la aplicación del ta­
cógrafo, concatenados con el tipo de equipo, que indica el 
tipo de equipo al que está destinado el certificado. En el 
caso de un certificado de la VU, un certificado de la tarjeta 
de conductor o un certificado de la tarjeta de taller, el tipo 
de equipo también se utiliza para diferenciar entre un certi­
ficado para la autenticación mutua y un certificado para la 
creación de firmas digitales (véanse el apartado 9.1 y el 
apéndice 1, tipo de datos EquipmentType).  
▼B 
9.3.2.4 Clave pública  
La clave pública anida dos elementos de datos: los parámetros d e domi­
nio normalizados que deberán utilizarse con la clave pública en  el cer­
tificado y el valor del punto público.  
CSM_142 El elemento de datos Domain Parameters contendrá uno de  
los identificadores de objeto especificados en la Table 1 para 
referenciar un conjunto de parámetros de dominio 
normalizados.  
CSM_143 El elemento de datos Public Point contendrá el 
punto público. Los puntos públicos de curva elíptica se 
convertirán en cadenas de octetos tal como se especifica 
en la directriz técnica [TR-03111]. Se utilizará el formato 
de codificación descomprimido. Al recuperar un punto de 
curva elíptica de su formato codificado, siempre se efectua­
rán las validaciones descritas en la directriz técnica [TR- 
03111].  
9.3.2.5 Referencia del titular del certificado (CHR)  
CSM_144 La referencia del titular del certificado es un identif icador de 
la clave pública indicado en el certificado. Se utilizará para 
referenciar esta clave pública en otros certificados.  
CSM_145 Para los certificados de tarjeta y los certificados de disposi­
tivo GNSS externo, la referencia del titular del certificado 
tendrá el tipo de dato
  espe­
cificado en el apéndice 1.  
CSM_146 En relación con las unidades instaladas en los vehículo s, al 
solicitar un certificado, el fabricante puede conocer, o bien 
desconocer, el número de serie específico del fabricante de 
la VU a la que vayan destinados el certificado y la clave 
privada asociada. En el primer caso, la referencia 
del titular del certificado tendrá el tipo de dato
  
especificado en el apéndice 
1. En el segundo caso, la referencia del titular del certificad o 
tendrá el tipo de dato
  especi­
ficado en el apéndice 1.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 470  
Nota : En el caso de un certificado de la tarjeta, el valor de la 
CHR será igual al valor del cardExtendedSerialNumber del 
archivo EF_ICC; véase el apéndice 2. En el caso de un 
certificado EGF, el valor de la CHR será igual al valor 
del sensorGNSSSerialNumber del archivo EF_ICC; véase 
el apéndice 14. En el caso de un certificado de VU, el valor 
de la CHR será igual al valor del elemento vuSerialNumber 
de VuIdentification, véase el apéndice 1, a menos que el 
fabricante no conozca el número de serie específico del 
fabricante en el momento de solicitar el certificado.  
▼B 
CSM_147 En relación con los certificados ERCA y MSCA, la refere n­
cia del titular del certificado tendrá el tipo de dato
  
especificado en el 
apéndice 1.  
9.3.2.6 Fecha efectiva del certificado  
▼M1 
CSM_148 La fecha efectiva del certificado indicará la fecha y h ora de 
inicio del período de validez del certificado.  
▼B 
9.3.2.7 Fecha de caducidad del certificado  
CSM_149 La fecha efectiva de caducidad del certificado indicará  la 
fecha y hora de finalización del período de validez del 
certificado.  
9.3.2.8 Firma del certificado  
CSM_150 La firma del certificado se creará a través del conteni do 
codificado del certificado, incluidas la etiqueta y la longitud  
del contenido del certificado. El algoritmo de firma será 
ECDSA, tal como se especifica en la norma [DSS], utili­
zando el algoritmo hash relacionado con el tamaño de la 
clave de la autoridad firmante, tal como se especifica en 
CSM_50. El formato de la firma será de texto plano, tal 
como se especifica en la directriz técnica [TR-03111].  
9.3.3  Solicitud de certificados  
CSM_151  ►M1 Al solicitar un certificado, la MSCA enviará los si­
guientes datos a su ERCA: ◄  
— el identificador del perfil de certificado del certificado 
solicitado  
— la referencia de la autoridad de certificación prevista para 
la firma del certificado  
— la clave pública que deba firmarse  
CSM_152 Además de los datos indicados en CSM_151, en una soli­
citud de certificado las MSCA enviarán los siguientes datos 
a la ERCA a fin de permitirle crear la referencia del titular 
del certificado de nuevo certificado MSCA:  
— el código numérico del país de la autoridad de certifica­
ción (tipo de dato
  definido en el 
apéndice 1)  
— el código alfanumérico del país de la autoridad de cer­
tificación (tipo de dato
  definido en el 
apéndice 1)  
— el número de serie de 1 byte para distinguir las diferen­
tes claves de la autoridad de certificación en caso de que 
se cambien las claves  
— el campo de dos bytes que contiene la información adi­
cional específica de la autoridad de certificación  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 471  
CSM_153 En una solicitud de certificado, un fabricante de equip os 
enviará los siguientes datos a la MSCA a fin de permitirle 
crear la referencia del titular del certificado del nuevo certi ­
ficado de equipo:  
— si se conoce (véase CSM_154), un número de serie para 
el equipo, único para el fabricante, el tipo de equipo, y 
el mes de fabricación. En caso contrario, un identificador 
único de la solicitud de certificado.  
— El mes y año de fabricación del equipo o de solicitud del 
certificado.  
El fabricante garantizará que estos datos sean correctos y que el certifi­
cado devuelto por la MSCA sea insertado en el equipo previsto.  
▼B 
CSM_154 En el caso de una VU, al solicitar un certificado, el f abri­
cante puede conocer, o bien desconocer, el número de serie 
específico del fabricante de la VU a la que vayan destinados 
el certificado y la clave privada asociada. Si lo conoce, el 
fabricante de VU enviará el número de serie a la MSCA. Si 
no lo conoce, el fabricante identificará de forma unívoca 
cada solicitud de certificado y enviará este número de serie 
de solicitud de certificado a la MSCA. El certificado resul­
tante contendrá el número de serie de la solicitud de certi­
ficado. Una vez insertado el certificado en una VU especí­
fica, el fabricante comunicará la conexión entre el número 
de serie de la solicitud de certificado y la identificación de la 
VU a la MSCA.  
10. AUTENTICACIÓN MUTUA DE LA TARJETA VU_CARD Y MEN­
SAJERÍA SEGURA  
10.1.  Generalidades  
CSM_155 A un nivel elevado, la comunicación segura entre una un i­
dad instalada en el vehículo y una tarjeta de tacógrafo se 
basará en los siguientes pasos:  
— En primer lugar, cada parte demostrará a la otra que 
detenta un certificado de clave pública válido y firmado 
por una autoridad de certificación de un Estado miem­
bro. A su vez, el certificado de clave pública MSCA 
debe estar firmado por la Autoridad del Certificado 
Raíz Europeo. Este paso se denomina verificación de 
la cadena de certificados y se especifica en detalle en 
la sección 10.2  
— En segundo lugar, la unidad instalada en el vehículo 
demostrará a la tarjeta que está en posesión de la clave 
privada que corresponde a la clave pública en el certifi­
cado presentado firmando un número aleatorio enviado 
por la tarjeta. La tarjeta verifica la firma a través del 
número aleatorio. Si la verificación se efectúa correcta­
mente, se autentica la VU. Este paso se denomina au­
tenticación de la VU y se especifica en detalle en la 
sección 10.3  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 472  
— En tercer lugar, ambas partes calculan por separado dos 
claves de sesión AES utilizando un algoritmo de cifrado 
asimétrico. Usando una de estas claves de sesión, la 
tarjeta crea un código de autenticación de mensaje 
(MAC) a través de datos enviados por la VU. La VU 
verifica el MAC. Si la verificación se efectúa correcta­
mente, se autentica la tarjeta. Este paso se denomina 
autenticación de la tarjeta y se especifica en detalle en 
la sección 10.4  
— En cuarto lugar, la VU y la tarjeta usarán las claves de 
sesión acordadas para asegurar la confidencialidad, inte­
gridad y autenticidad de todos los mensajes intercambia­
dos. Esto se denomina mensajería segura y se especifica 
en detalle en la sección 10.5  
CSM_156 El mecanismo descrito en CSM_155 será desencadenado por  
la unidad del vehículo siempre que se inserte una tarjeta en 
una de sus ranuras para tarjeta.  
10.2.  Verificación mutua de la cadena de certificados  
10.2.1  Verificación por la VU de la cadena de certificados de una tarjeta  
CSM_157  ►M1 Las unidades instaladas en el vehículo utilizarán el 
protocolo ilustrado en la figura 4 para verificar la cadena de 
certificados de una tarjeta de tacógrafo. Para cada certificado  
que lea en la tarjeta, la VU verificará que el campo «Auto­
rización del titular del certificado» (CHA) sea correcto:  
— El campo CHA del certificado Card indicará un certifi­
cado de tarjeta para la autenticación mutua (véase apén­
dice 1, tipo de datos EquipmentType).  
— El campo CHA del certificado Card.CA indicará una 
MSCA.  
— El campo CHA del certificado Card.Link indicará una 
ERCA. ◄  
Notas de la Figure 4:  
— Los certificados de tarjeta y las claves públicas mencio­
nados en la figura son los empleados para la autentica­
ción mutua. La sección 9.1.5 los denota Card_MA.  
— Los certificados Card.CA y las claves públicas mencio­
nados en la figura son los empleados para firmar los 
certificados de tarjeta y están indicados en la referencia 
CAR del certificado Card. La sección 9.1.3 los denota 
MSCA_Card.  
— El certificado Card.CA.EUR mencionado en la figura es 
el certificado raíz europeo indicado en la referencia CAR 
del certificado Card.CA.  
— El certificado Card.Link mencionado en la figura es el 
certificado de enlace de la tarjeta, si está presente. Tal 
como se especifica en la sección 9.1.2, este es el certi­
ficado de enlace para un nuevo par de claves raíz euro­
peo creado por la ERCA y firmado por la clave privada 
europea anterior.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 473  
— El certificado Card.Link.EUR es el certificado raíz euro­
peo indicado en la referencia CAR del certificado 
Card.Link.  
CSM_158 Tal como ilustra la Figure 4, la verificación de la cad ena de 
certificados de la tarjeta se iniciará al insertar la tarjeta. La 
unidad instalada en el vehículo leerá la referencia del titular  
de la tarjeta (
  ) del nú­
mero de serie de la EF.ICC. La VU comprobará si conoce 
la tarjeta, es decir, si ha verificado correctamente la cadena 
de certificados de la tarjeta en el pasado y la ha almacenado 
para futuras referencias. Si la conoce y el certificado de la 
tarjeta es todavía válido, el proceso continúa con la verifi­
cación de la cadena de certificados de la VU. De otro modo, 
la VU leerá sucesivamente en la tarjeta el certificado 
MSCA_Card que deberá utilizarse para verificar el certifi­
cado de la tarjeta, el certificado Card.CA.EUR necesario 
para verificar el certificado MSCA_Card y, posiblemente, 
el certificado de enlace, hasta que encuentre un certificado 
que conozca o pueda verificar. Si encuentra dicho certifi­
cado, la VU lo utilizará para verificar los certificados de 
tarjeta subyacentes que ha leído en la tarjeta. Si la verifica­
ción es correcta, el proceso continúa con la verificación de 
la cadena del certificado de la VU. Si no puede efectuarse la 
verificación, la VU ignorará la tarjeta.  
Nota:  La VU puede conocer el certificado Card.CA.EUR de 
tres maneras:  
— el certificado Card.CA.EUR es el mismo certificado que 
el propio certificado EUR de la VU;  
— el certificado Card.CA.EUR precede al propio certificado 
EUR de la VU, y la VU ya contenía este certificado en 
el momento de su expedición (véase CSM_81);  
— el certificado Card.CA.EUR sucede al propio certificado 
EUR de la VU y la VU recibió un certificado de enlace 
en algún momento de otra tarjeta de tacógrafo, la veri­
ficó y la almacenó para referencias futuras.  
CSM_159 Como se indica en la Figure 4, una vez que la VU ha 
verificado la autenticidad y validez de un certificado previa­
mente desconocido, puede almacenar este certificado para 
referencias futuras, de modo que no tenga que volver a 
verificar la autenticidad del certificado si se vuelve a pre­
sentar a la VU. En lugar de almacenar la totalidad del cer­
tificado, una VU puede optar por almacenar solamente el 
contenido del certificado, tal como se especifica en la 
sección 9.3.2.  ►M1 Mientras que el almacenamiento de 
todos los demás tipos de certificados es facultativo, es obli­
gatorio que la VU almacene todo nuevo certificado de en­
lace presentado por una tarjeta. ◄  
CSM_160 La VU verificará la validez temporal de todos los certi fica­
dos leídos en la tarjeta o almacenados en su memoria, y 
rechazará los certificados caducados. Para verificar la vali­
dez temporal de un certificado presentado por la tarjeta, la 
VU utilizará su reloj interno.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 474  
Figura 4  
Protocolo para la verificación de la cadena de certificados de una tarjeta por la VU
  
10.2.2  Verificación por la tarjeta de la cadena de certificados de una VU  
CSM_161  ►M1 Las tarjetas de tacógrafo utilizarán el protocolo ilus­
trado en la figura 5 para verificar la cadena de certificados 
de una VU. Para cada certificado presentado por la VU, la 
tarjeta verificará que el campo «Autorización del titular del 
certificado» (CHA) sea correcto:  
— El campo CHA del certificado VU.Link indicará una 
ERCA.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 475  
— El campo CHA del certificado VU.CA indicará una 
MSCA.  
— El campo CHA del certificado VU indicará un certifi­
cado de VU para la autenticación mutua (véase apéndice 
1, tipo de datos EquipmentType). ◄  
Figura 5  
Protocolo para la verificación por una tarjeta de la cadena de certificados de una VU
  
Notas de la Figure 5:  
— Los certificados de VU y las claves públicas mencionados en l a 
figura son los empleados para la autenticación mutua. La 
sección 9.1.4 los denota VU_MA.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 476  
— Los certificados VU.CA y las claves públicas mencionados en l a 
figura son los empleados para firmar los certificados de VU y d e 
dispositivo GNSS externo. La sección 9.1.3 los denota MSCA_VU- 
EGF.  
— El certificado VU.CA.EUR mencionado en la figura es el certif icado 
raíz europeo indicado en la referencia CAR del certificado VU.C A. 
— El certificado VU.Link mencionado en la figura es el certific ado de 
enlace de la VU, si está presente. Tal como se especifica en la  
sección 9.1.2, este es el certificado de enlace para un nuevo p ar de 
claves raíz europeo creado por la ERCA y firmado por la clave 
privada europea anterior.  
— El certificado VU.Link.EUR es el certificado raíz europeo ind icado 
en la referencia CAR del certificado VU.Link.  
CSM_162 Como ilustra la Figure 5, la verificación de la cadena de 
certificados de la unidad instalada en el vehículo se iniciará 
cuando esta intente establecer su propia clave pública para 
su uso en la tarjeta de tacógrafo. Si esto se efectúa correc­
tamente, significa que la tarjeta ha verificado con éxito 
anteriormente la cadena de certificados de la VU y ha al­
macenado el certificado VU para referencias futuras. En este 
caso, el certificado VU está listo para usar y el proceso 
continúa con la autenticación de la VU. Si la tarjeta no 
conoce el certificado de la VU, la VU presentará sucesiva­
mente el certificado MSCA_VU necesario para verificar el 
certificado de la VU, el certificado VU.CA.EUR necesario 
para verificar el certificado MSCA_VU y, posiblemente, el 
certificado de enlace, hasta encontrar un certificado cono­
cido o verificable por la tarjeta. Si encuentra dicho certifi­
cado, la tarjeta lo utilizará para verificar los certificados V U 
subyacentes que le sean presentados. Si la verificación se 
efectúa correctamente, la VU establecerá finalmente su 
clave pública para uso en la tarjeta de tacógrafo. Si no 
puede efectuarse la verificación, la VU ignorará la tarjeta.  
Nota: La tarjeta puede conocer el certificado VU.CA.EUR 
de tres maneras:  
— el certificado VU.CA.EUR es el mismo certificado que 
el propio certificado EUR de la tarjeta;  
— el certificado VU.CA.EUR precede al propio certificado 
EUR de la tarjeta, y la tarjeta ya contenía este certifi­
cado en el momento de su expedición (véase CSM_81);  
— el certificado VU.CA.EUR sucede al propio certificado 
EUR de la tarjeta y la tarjeta recibió un certificado de 
enlace en algún momento de otra unidad instalada en el 
vehículo, la verificó y la almacenó para referencias 
futuras.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 477  
CSM_163 La VU utilizará el comando MSE (Message Security Envi­
ronment): Set AT para establecer su clave pública para uso 
en la tarjeta de tacógrafo. Como se especifica en el apéndice 
2, este comando contiene una indicación del mecanismo 
criptográfico que se utilizará con la clave establecida. Este 
mecanismo será «Autenticación de VU mediante el algo­
ritmo ECDSA, en combinación con el algoritmo hash rela­
cionado con el tamaño de clave del par de claves VU_MA 
de la VU, tal como se especifica en CSM_50».  
CSM_164 El comando MSE: Set AT también contiene una indicación 
del par de claves efímero que la VU utilizará durante el 
acuerdo de claves de sesión (véase la sección 10.4). Por 
tanto, antes de enviar el comando MSE: Set AT, la VU 
generará un par de claves ECC efímero. Para generar el 
par de claves efímero, la VU utilizará los parámetros de 
dominio normalizados indicados en el certificado de la tar­
jeta. El par de claves efímero se denota por (VU.SK  eph , 
VU.PK  eph , Card.DP). La VU considerará la coordenada x 
del punto público efímero ECDH como la identificación de 
la clave; esto se denomina la representación comprimida de 
la clave pública y se denota por Comp(VU.PK  eph ). 
▼M1 
CSM_165 Si el comando MSE: Set AT se ejecuta correctamente, la 
tarjeta establecerá la VU.PK indicada para su uso posterior 
durante la autenticación del vehículo, y almacenará tempo­
ralmente Comp(VU.PKeph). En el caso de que se envíen 
dos o más comandos MSE: Set AT ejecutados correcta­
mente antes de efectuar el acuerdo de claves de sesión, la 
tarjeta almacenará únicamente la última Comp(VU.PKeph) 
recibida. La tarjeta reiniciará Comp(VU.PKeph) después de 
un comando GENERAL AUTHENTICATE ejecutado 
correctamente.  
▼B 
CSM_166 La tarjeta verificará la validez temporal de todos los certi­
ficados presentados por la VU o referenciados por la VU 
mientras están almacenados en la memoria de la tarjeta, y 
rechazará los certificados caducados.  
CSM_167 Para verificar la validez temporal de un certificado pr esen­
tado por la VU, cada tarjeta de tacógrafo almacenará inter­
namente datos que representen la hora actual. Estos datos 
no serán directamente actualizables por una VU. En el mo­
mento de su expedición, la hora actual de una tarjeta que se 
configurará será la misma que la fecha efectiva del certifi­
cado Card_MA de la tarjeta. Una tarjeta actualizará su hora 
actual si la fecha efectiva de un certificado auténtico de 
«fuente válida de hora» presentado por una VU es más 
reciente que la hora actual de la tarjeta. En tal caso, la 
tarjeta configurará su hora actual a la fecha efectiva de 
ese certificado. La tarjeta solamente aceptará los certificados  
siguientes como fuente válida de hora:  
— Certificados de enlace ERCA de segunda generación  
— Certificados de enlace MSCA de segunda generación  
— Certificados VU de segunda generación expedidos por 
el mismo país que el propio certificado o certificados de 
tarjeta de la tarjeta.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 478  
Nota:  este último requisito implica que una tarjeta deberá 
poder reconocer la referencia CAR del certificado VU, es 
decir, el certificado MSCA_VU-EGF. Esta no será la misma 
referencia que la referencia CAR de su propio certificado, 
que es el certificado MSCA_Card.  
CSM_168 Como se indica en la Figure 5, una vez que la tarjeta h a 
verificado la autenticidad y validez de un certificado pre­
viamente desconocido, puede almacenar este certificado 
para referencias futuras, de modo que no tenga que volver 
a verificar la autenticidad del certificado si se vuelve a 
presentar a la tarjeta. En lugar de almacenar la totalidad 
del certificado, una tarjeta puede optar por almacenar sola­
mente el contenido del certificado, tal como se especifica en 
la sección 9.3.2.  
10.3.  Autenticación de VU  
CSM_169 Las unidades instaladas en los vehículos utilizarán el proto­
colo Autenticación de VU ilustrado en la Figure 6 para 
autenticar la VU ante la tarjeta. La Autenticación de VU 
permite a la tarjeta de tacógrafo verificar explícitamente que 
la VU es auténtica. Para ello, la VU utilizará su clave 
privada para firmar una comprobación generada por la 
tarjeta.  
CSM_170  ►M1 Junto a la comprobación de la tarjeta, la VU incluirá 
en la firma la referencia del titular del certificado extraída 
del certificado de la tarjeta. ◄  
Nota:  De esta forma se garantiza que la tarjeta ante la cual 
se autentica la VU es la misma tarjeta cuya cadena de 
certificados ha verificado previamente la VU.  
CSM_171 La VU incluirá asimismo en la firma el identificador de  la 
clave pública efímera Comp(VU.PK  eph ) que la VU utilizará 
para establecer la mensajería segura durante el proceso de 
autenticación del chip especificado en la sección 10.4.  
Nota:  De esta forma se garantiza que la VU con la que se 
comunica una tarjeta durante la sesión de mensajería segura 
es la misma VU que fue autenticada por la tarjeta.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 479  
Figura 6  
Protocolo de autenticación de VU
  
▼B 
CSM_172 Si durante la autenticación de VU la VU envía múltiples  
comandos GET CHALLENGE, la tarjeta devolverá una 
nueva comprobación aleatoria de 8 bytes cada vez, pero 
solamente almacenará la última comprobación.  
CSM_173 El algoritmo de firma utilizado por la VU para la auten ti­
cación de VU será el algoritmo ECDSA, tal como se espe­
cifica en la norma [DSS], utilizando el algoritmo hash re­
lacionado con el tamaño de clave del par de claves VU_MA 
de la VU, tal como se especifica en CSM_50. El formato de 
la firma será de texto plano, tal como se especifica en la 
directriz técnica [TR-03111]. La VU enviará la firma resul­
tante a la tarjeta.  
▼M1 
CSM_174 Al recibir la firma de la VU en un comando EXTERNAL 
AUTHENTICATE, la tarjeta:  
— calculará el token de autenticación concatenando 
Card.CHR, la comprobación de tarjeta rcard y el iden­
tificador de la clave pública efímera de la VU 
Comp(VU.PKeph);  
— verificará la firma de la VU mediante el algoritmo 
ECDSA, en combinación con el algoritmo hash relacio­
nado con el tamaño de clave del par de claves VU_MA 
de la VU, tal como se especifica en CSM_50, y en 
combinación con la clave VU.PK y el token de auten­
ticación calculado.  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 480  
10.4.  Autenticación de chip y acuerdo de claves de sesión  
CSM_175 Las unidades instaladas en los vehículos utilizarán el proto­
colo Autenticación de chip ilustrado en la  Figure 7  para 
autenticar la tarjeta ante la VU. La Autenticación de chip 
permite a la unidad instalada en el vehículo verificar explí­
citamente que la tarjeta es auténtica.  
Figure 7  
Autenticación de chip y acuerdo de claves de sesión
  
CSM_176 La VU y la tarjeta efectuarán los siguientes pasos:  
1. La unidad instalada en el vehículo inicia el proceso de 
Autenticación de chip enviando el comando MSE: Set 
AT que indica «Autenticación de chip mediante el algo­
ritmo ECDH que resulta en una longitud de clave de 
sesión AES relacionada con el tamaño de clave del par 
de claves Card_MA de la tarjeta, tal como se especifica 
en CSM_50». La VU determinará el tamaño de clave del 
par de claves de la tarjeta a partir del certificado de la 
tarjeta.  
▼M1 
2. La VU envía el punto público VU.PK  eph de su par de 
claves efímero a la tarjeta. El punto público se convertirá 
en una cadena de octetos tal como se especifica en la 
directriz técnica [TR-03111]. Se utilizará el formato de 
codificación descomprimido. Como se indica en 
CSM_164, la VU generó este par de claves efímero antes 
de la verificación de la cadena de certificados de la VU. 
La VU envió el identificador de la clave pública efímera 
Comp(VU.PK  eph ) a la tarjeta, y la tarjeta lo almacenó.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 481  
3. La tarjeta computa Comp(VU.PK  eph ) a partir de la clave 
VU.PK  eph y compara el resultado con el valor almace­
nado de Comp(VU.PK  eph ). 
4. Mediante el algoritmo ECDH en combinación con la 
clave privada estática de la tarjeta y la clave pública 
efímera de la VU, la tarjeta computa una clave K secreta.  
5. La tarjeta selecciona un nonce aleatorio de 8 bytes N  PICC 
mediante el cual deriva dos claves de sesión AES K  MAC 
y K  ENC a partir de K. Véase CSM_179.  
▼M1 
6. Mediante la clave K  MAC , la tarjeta computa un token de 
autenticación a través del identificador del punto público 
efímero de la VU: T  PICC = CMAC(K  MAC , VU.PK  eph ). El 
punto público deberá estar en el formato utilizado por la 
VU (véase el punto 2). La tarjeta envía N  PICC y T  PICC a 
la unidad instalada en el vehículo.  
▼B 
7. Mediante el algoritmo ECDH en combinación con la 
clave privada estática de la tarjeta y la clave pública 
efímera de la VU, la VU computa la misma clave K se­
creta que computó la tarjeta en el paso 4.  
8. La VU deriva la claves de sesión K  MAC y K  ENC a partir 
de K y N  PICC ; véase CSM_179.  
9. La VU verifica el token de autenticación T  PICC . 
CSM_177  En el paso 3 anterior, la tarjeta computará Comp(VU.PKeph) 
como la coordenada x del punto publico en VU.PKeph.E  
CSM_178 En los pasos 4 y 7 anteriores, la tarjeta y la unidad i nstalada 
en el vehículo utilizarán el algoritmo ECKA-EG tal como se 
define en la directriz técnica [TR-03111].  
CSM_179 En los pasos 5 y 8 anteriores, la tarjeta y la unidad i nstalada 
en el vehículo utilizarán la función de derivación de clave 
para las claves de sesión definidas en la directriz técnica 
[TR-03111], con las siguientes precisiones y cambios:  
— El valor del contador será «00 00 00 01» para K  ENC y 
«00 00 00 02» para K  MAC . 
— Se usará el nonce opcional r igual a N  PICC . 
— Para derivar claves AES de 128 bits, se deberá utilizar 
el algoritmo hash SHA-256.  
— Para derivar claves AES de 192 bits, se deberá utilizar 
el algoritmo hash SHA-384.  
— Para derivar claves AES de 256 bits, se deberá utilizar 
el algoritmo hash SHA-512.  
La longitud de las claves de sesión (es decir, la longitud a la  
cual se trunca la función hash) estará relacionada con el 
tamaño del par de claves Card_MA, tal como se especifica 
en CSM_50.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 482  
CSM_180 En los pasos 6 y 9 anteriores, la tarjeta y la unidad i nstalada 
en el vehículo utilizarán el algoritmo en modo CMAC, tal 
como se especifica en define en la publicación especial del 
NIST [SP 800-38B]. La longitud de T  PICC estará relacio­
nada con la longitud de las claves de sesión AES, tal como 
se especifica en CSM_50.  
10.5.  Mensajería segura  
10.5.1  Generalidades  
CSM_181 Todos los comandos y respuestas intercambiados entre un a 
unidad instalada en el vehículo y una tarjeta de tacógrafo 
tras la autenticación correcta del chip y hasta el final de la 
sesión estarán protegidos por mensajería segura.  
CSM_182 Salvo durante la lectura en un archivo con la condición  de 
acceso SM-R-ENC-MAC-G2 (véase el apéndice 2, 
sección 4), la mensajería segura se utilizará en modo solo 
autenticación. En este modo, una suma de comprobación 
criptográfica, también llamada código de autenticación de 
mensajes (MAC), se añade a todos los comandos y respues­
tas para garantizar la autenticidad e integridad de los 
mensajes.  
CSM_183 Al leer los datos de un archivo con la condición de acc eso 
SM-R-ENC-MAC-G2, la mensajería segura se utilizará en 
el modo cifrar y después autenticar, es decir, primero se 
cifran los datos de respuesta para asegurar la confidenciali­
dad del mensaje, y después se calcula un MAC con los 
datos cifrados formateados para asegurar la autenticidad e 
integridad.  
CSM_184 La mensajería segura utilizará la norma AES tal como se  
define en [AES] con las claves de sesión K  MAC y K  ENC 
acordadas durante la autenticación del chip.  
CSM_185 Se utilizará un entero no firmado como contador de enví o 
de secuencia (SSC) para impedir los ataques por repetición. 
El tamaño del SSC será igual al tamaño de bloque AES. es 
decir, 128 bits. El SSC tendrá el formato MSB primero. El 
contador de envío de secuencia se inicializará a cero (es 
decir, «00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00») cuando se inicie la mensajería segura. El SSC se in­
crementará cada vez antes de generar un comando o res­
puesta APDU, es decir, puesto que el valor de inicio del 
SSC en una sesión SM es 0, en el primer comando el valor 
del SSC será 1. El valor de SCC para la primera respuesta 
será 2.  
CSM_186 Para el cifrado de mensajes se utilizará la clave K  ENC con 
AES en el modo de operación de encadenamiento de blo­
ques de cifrado (CBC), tal como se define en la norma [ISO 
10116], con un parámetro interpolar  m = 1 y un vector de 
inicialización SV = E(K  ENC , SSC), es decir, el valor actual 
del contador de envío de secuencia cifrado con la clave 
K ENC . 
CSM_187 Para la autenticación de mensajes, se utilizará la clav e 
K MAC con AES en el modo CMAC, tal como se especifica 
en la publicación especial [SP 800-38B]. La longitud del 
MAC estará relacionada con la longitud de las claves de 
sesión AES, tal como se especifica en CSM_50. El contador 
de envío de secuencia se incluirá en el MAC copiándolo al 
principio antes del datagrama que se deba autenticar.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 483  
10.5.2  Estructura de mensaje segura  
CSM_188 La mensajería segura utilizará solamente los objetos de  da­
tos de mensajería segura (véase la norma [ISO 7816-4]) 
enumerados en la Table 5. En cualquier mensaje, estos 
objetos de datos se utilizarán en el orden especificado en 
esta tabla.  
Tabla 5  
Objetos de datos de mensajería segura  
Nombre de objeto de datos  Etiqueta  Presencia obligatoria (M), 
condicional (C) o 
prohibida (F) en  
Comandos  Respuestas  
Valor plano no codificado en 
BERL-TLV  «81»  C  C  
Valor plano codificado en BERL-TLV, 
pero excluidos los DO de SM  «B3»  C  C  
Indicador de contenido de relleno se­
guido de criptograma, valor plano no 
codificado en BER-TLV  «87»  C  C  
Le protegida  «97»  C  F  
Estado de procesamiento  «99»  F  M  
Suma de control criptográfica  «8E»  M  M  
Nota:  Tal como se especifica en el apéndice 2, las tarjetas 
de tacógrafo pueden soportar el comando READ BINARY 
y UPDATE BINARY con un byte INS impar («B1» resp. 
«D7»). Estas variantes de comando son necesarias para leer 
y actualizar ficheros de 32 768 bytes o más. En el caso de 
que se utilice una variante, en lugar de un objeto con la 
etiqueta «81» se utilizará un objeto de datos con la etiqueta 
«B3». Véase el apéndice 2 para más información.  
CSM_189 Todos los objetos de datos de SM (mensajería segura) se  
codificarán en DER TLV, tal como se especifica en la 
norma [ISO 8825-1]. Esta codificación resulta en una es­
tructura etiqueta-longitud-valor (TLV) como la siguiente:  
CSM_190 Las unidades de datos de protocolo de aplicación (APDU)  
protegidas mediante mensajería segura se crearán de la si­
guiente manera:  
— La cabecera de comando se incluirá en el cálculo del 
MAC, por consiguiente, para el byte de clase CLA se 
utilizará el valor «0C».  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 484  
— Como se especifica en el apéndice 2, todos los bytes 
INS serán pares, con la posible excepción de bytes INS 
impares para los comandos READ BINARY y UP­
DATE BINARY.  
— El valor real de Lc se modificará a Lc' tras la aplicación 
de la mensajería segura.  
— El campo Datos estará compuesto de objetos de datos 
SM. 
— En el comando protegido APDU, el nuevo byte Le se 
configurará a «00». En caso necesario, el objeto de 
datos «97» se incluirá en el campo Datos a fin de co­
municar el valor original de Le.  
▼M1 
CSM_191 Los objetos de datos que deban cifrarse se rellenarán d e 
acuerdo con la norma [ISO 7816-4] mediante el indicador 
de contenido de relleno ‘01’. Para el cálculo del MAC, los 
objetos de datos de la APDU se rellenarán conforme a la 
norma [ISO 7816-4].  
Nota:  El relleno para la mensajería segura siempre es efec­
tuado por la capa de mensajería segura, no por los algorit­
mos CMAC o CBC.  
Resumen y ejemplos  
Un comando APDU con mensajería segura aplicada tendrá la siguie nte 
estructura, dependiendo del caso del comando no securizado corr espon­
diente (DO significa objeto de datos):  
Caso 1: CLA INS P1 P2 || Lc' || DO ‘8E’ || Le  
Caso 2: CLA INS P1 P2 || Lc' || DO ‘97’ || DO ‘8E’ || 
Le 
Caso 3 (byte INS par): CLA INS P1 P2 || Lc' || DO ‘81’ || DO ‘8 E’ || 
Le 
Caso 3: (byte INS impar): CLA INS P1 P2 || Lc' || 
DO ‘B3’ || DO ‘8E’ || Le  
Caso 4 (byte INS par): CLA INS P1 P2 || Lc' || DO ‘81’ || DO ‘9 7’ || 
DO ‘8E’ || Le  
Caso 4 (byte INS impar): CLA INS P1 P2 || Lc' || DO ‘B3’ || DO ‘97’ 
|| DO ‘8E’ || Le  
donde Le = ‘00’ o ‘00 00’, dependiendo de si se usan campos de corta 
longitud o de longitud extendida; véase la norma [ISO 7816-4].  
Una respuesta APDU con mensajería segura aplicada tendrá la sig uiente 
estructura, dependiendo del caso del comando no securizado 
correspondiente:  
Caso 1o 3: DO ‘99’ || DO ‘8E’ || 
SW1SW2  
Caso 2 o 4 (byte INS par) sin cifrado: DO ‘81’ || DO ‘99’ || DO 
‘8E’ || SW1SW2  
Caso 2 o 4 (byte INS par) con cifrado: DO ‘87’ || DO ‘99’ || DO 
‘8E’ || SW1SW2  
Caso 2 o 4 (byte INS impar) sin cifrado 
: DO ‘B3’ || DO ‘99’ || DO 
‘8E’ || SW1SW2  
Nota:  El caso 2 o 4 (byte INS impar) con cifrado no se usa nunca en la 
comunicación entre una VU y una tarjeta.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 485  
A continuación figuran tres ejemplos de transformaciones APDU p ara 
comandos con código INS par. La figura 8 muestra un comando APD U 
de caso 4 autenticado, la figura 9 muestra una respuesta APDU d e caso 
1/caso 3 autenticada, y la figura 10 muestra una respuesta APDU  de caso 
2/caso 4 cifrada y autenticada.  
Figura 8  
Transformación de un comando APDU de caso 4 autenticado
  
Figura 9  
Transformación de una respuesta APDU de caso 1 / caso 3 autenticada
  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 486  
Figura 10  
Transformación de una respuesta APDU de caso 2 / caso
  
▼B 
10.5.3  Aborto de sesión de mensajería segura  
CSM_192 Una unidad instalada en el vehículo abortará una sesión  de 
mensajería segura en curso solamente si si se da una de las 
condiciones siguientes:  
— recibe una respuesta APDU plana;  
— detecta un error de mensajería segura en una respuesta 
APDU:  
— falta un objeto de datos de mensajería segura espe­
rado, el orden de los objetos de datos es incorrecto, 
o hay incluido un objeto de datos desconocido;  
— un objeto de datos de mensajería segura es incorrecto, 
por ejemplo, el valor MAC es incorrecto, la estructura 
TLC es incorrecta, o el indicador de relleno de la 
etiqueta «87» no es igual a «01»;  
— la tarjeta envía un byte de estado que indica que ha de­
tectado un error SM (véase CSM_194);  
— se ha alcanzado el límite de número de comandos y res­
puestas asociadas en la sesión actual. Este límite lo defi­
nirá para cada VU concreta su fabricante, teniendo en 
cuenta los requisitos de seguridad del soporte físico utili­
zado, con un valor máximo de 240 comandos y respuestas 
asociadas de SM por sesión.  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 487  
CSM_193 Una tarjeta de tacógrafo abortará una sesión de mensaje ría 
segura en curso solamente si se da una de las condiciones 
siguientes:  
— recibe un comando APDU plano;  
— detecta un error de mensajería segura en un comando 
APDU:  
— falta un objeto de datos de mensajería segura espe­
rado, el orden de los objetos de datos es incorrecto, 
o hay incluido un objeto de datos desconocido;  
— un objeto de datos de mensajería segura es incorrecto, 
por ejemplo, el valor MAC es incorrecto o la estruc­
tura TLC es incorrecta;  
— no recibe alimentación eléctrica o ha sido restaurada;  
— la VU inicia el proceso de autenticación de la VU;  
— se ha alcanzado el límite de número de comandos y res­
puestas asociadas en la sesión actual. Este límite lo defi­
nirá para cada tarjeta concreta su fabricante, teniendo en 
cuenta los requisitos de seguridad del soporte físico utili­
zado, con un valor máximo de 240 comandos y respuestas 
asociadas de SM por sesión.  
▼B 
CSM_194 En relación con la gestión de errores SM por la tarjeta  de 
tacógrafo:  
— Si en un comando APDU faltan objetos de datos de men­
sajería segura esperados, el orden de los objetos de datos 
es incorrecto, o hay incluidos objetos de datos incorrectos 
o desconocidos, la tarjeta de tacógrafo responderá con los 
bytes de estado «69 87».  
— Si un objeto de datos de mensajería segura en un co­
mando APDU es incorrecto, la tarjeta de tacógrafo res­
ponderá con los bytes de estado «69 88».  
En tal caso, los bytes de estado se devolverán sin usar la 
mensajería segura.  
CSM_195 Si una sesión de mensajería segura entre una VU y una t arjeta 
de tacógrafo se aborta, la VU y la tarjeta de tacógrafo:  
— destruirá de forma segura las claves de sesión 
almacenadas;  
— establecerá inmediatamente una nueva sesión de mensaje­
ría segura, como se describe en las secciones 10.2 — 
10.5.  
CSM_196 Si, por cualquier razón, la VU decide reiniciar la aute ntica­
ción mutua frente a una tarjeta insertada, el proceso se reini­
ciará con la verificación de la cadena de certificados de la 
tarjeta, tal como se describe en la sección 10.2, y continuará 
en la forma descrita en las secciones 10.2 — 10.5.  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 488  
11. ACOPLAMIENTO, AUTENTICACIÓN MUTUA Y MENSAJERÍA SE­
GURA ENTRE LA VU Y EL DISPOSITIVO GNSS EXTERNO  
11.1.  Generalidades  
CSM_197 El dispositivo GNSS utilizado por una VU para determina r su 
posición puede ser interna (es decir, montada dentro de la 
caja de la VU y no separable), o puede ser un módulo ex­
terno. En el primer caso, no hay necesidad de normalizar la 
comunicación interna entre el dispositivo GNSS y la VU, y 
los requisitos del presente capítulo no son de aplicación. En e l 
último caso, la comunicación entre la VU y el dispositivo 
GNSS externo estará normalizada y protegida tal como se 
describe en este capítulo.  
CSM_198 La comunicación segura entre una unidad instalada en el  
vehículo y un dispositivo GNSS externo tendrá lugar de la 
misma forma que una comunicación segura entre una unidad 
instalada en el vehículo y una tarjeta de tacógrafo, donde el 
dispositivo GNSS externo (EGF) tiene la función de tarjeta. 
Las EGF cumplirá todos los requisitos mencionados en el 
capítulo 10 para las tarjetas de tacógrafo teniendo en cuenta 
las desviaciones, clarificaciones y añadidos mencionados en el 
presente capítulo. En particular, la verificación mutua de la 
cadena de certificados, la autenticación de la VU y la auten­
ticación del chip se efectuará tal como se describe en las 
secciones 11.3 y 11.4.  
CSM_199 La comunicación entre una unidad instalada en el vehícu lo y 
una EGF difiere de la comunicación entre una unidad ins­
talada en el vehículo y una tarjeta en que una unidad instalada  
en el vehículo y una EGF deben acoplarse una vez en un 
taller antes de que la VU y la EGF puedan intercambiar datos 
basados en el GNSS durante el funcionamiento normal. El 
proceso de acoplamiento se describe en la sección 11.2.  
CSM_200 Para la comunicación entre una unidad instalada en el v ehí­
culo y una EGF, se usarán los comandos y respuestas APDU 
basados en las normas [ISO 7816-4] e [ISO 7816-8]. La 
estructura exacta de estas APDU está definida en el apéndice 
2 del presente anexo.  
11.2.  Acoplamiento entre la VU y el dispositivo GNSS externo  
CSM_201 Una unidad instalada en el vehículo y una EGF de un veh í­
culo se acoplarán en un taller. En funcionamiento normal, 
solamente se podrán comunicar una unidad instalada en el 
vehículo y una EGF acopladas.  
CSM_202 El acoplamiento de una unidad instalada en el vehículo y una 
EGF solamente será posible si la unidad instalada en el ve­
hículo está en modo calibración. El acoplamiento será ini­
ciado por la unidad instalada en el vehículo.  
CSM_203 Un taller puede reacoplar una unidad instalada en el ve hículo 
a otra EGF o a la misma EGF en cualquier momento. Durante 
el reacoplamiento, la VU destruirá de forma segura el certi­
ficado EGF_MA existente en su memoria y almacenará el 
certificado EGF_MA de la EGF a la que esté siendo 
acoplada.  
CSM_204 Un taller puede reacoplar un dispositivo GNSS externo a  otra 
VU o a la misma VU en cualquier momento. Durante el 
reacoplamiento, la EGF destruirá de forma segura el certifi­
cado VU_MA existente en su memoria y almacenará el cer­
tificado VU_MA de la VU a la que esté siendo acoplada.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 489  
11.3.  Verificación mutua de la cadena de certificados  
11.3.1  Generalidades  
CSM_205 La verificación mutua de la cadena de certificados entr a una 
VU y una EGF se efectuará solamente durante el acopla­
miento de la VU y la EGF por un taller. Durante el funcio­
namiento normal de una VU y una EGF acopladas, no se 
verificará ningún certificado. En lugar de eso, la VU y la 
EGF confiarán en los certificados que hayan almacenado du­
rante el acoplamiento, una vez comprobada la validez tempo­
ral de los mismos. La VU y la EGF no confiarán en ningún 
otro certificado para proteger la comunicación entre la VU y 
la EGF durante el funcionamiento normal.  
11.3.2  Durante el acoplamiento entre la VU y la EGF  
CSM_206 Durante el acoplamiento a una EGF, la unidad instalada en el 
vehículo utilizará el protocolo ilustrado en la Figure 4 (sec­
ción 10.2.1) para verificar la cadena de certificados del dis­
positivo GNSS externo.  
Notas de la Figure 4 en este contexto.  
— El control de la comunicación está fuera del ámbito del 
presente apéndice. No obstante, una EGF no es una tarjeta 
inteligente y, por consiguiente, la VU probablemente no 
mandará un comando Restaurar (Reset) para iniciar la 
comunicación y no recibirá una respuesta ATR.  
— Los certificados de tarjeta y las claves públicas mencio­
nadas en la figura se interpretarán como los certificados 
de la EGF y las claves públicas para autenticación mutua. 
La sección 9.1.6 los denota EGF_MA.  
— Los certificados de tarjeta Card.CA y las claves públicas 
mencionadas en la figura se interpretarán como los certi­
ficados de la MSCA y las claves públicas para firmar 
certificados EGF. La sección 9.1.3 los denota 
MSCA_VU-EGF.  
— El certificado Card.CA.EUR mencionado en la figura se 
interpretará como el certificado raíz europeo indicado en 
la referencia CAR del certificado MSCA_VU-EGF.  
— El certificado Card.Link mencionado en la figura se inter­
pretará como el certificado de enlace de la EGF, si está 
presente. Tal como se especifica en la sección 9.1.2, este 
es el certificado de enlace para un nuevo par de claves 
raíz europeo creado por la ERCA y firmado por la clave 
privada europea anterior.  
— El certificado Card.Link.EUR es el certificado raíz euro­
peo indicado en la referencia CAR del certificado 
Card.Link.  
— En lugar del
  , la VU 
leerá el
  del archivo EF 
ICC.  
— En lugar de seleccionar el AID del tacógrafo, la VU 
seleccionará el AID de la EGF.  
— «Ignore Card» se interpretará como «Ignore EGF».  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 490  
CSM_207 Una vez verificado el certificado EGF_MA, la unidad ins ­
talada en el vehículo almacenará el certificado para utilizarlo  
durante el funcionamiento normal. Véase la sección 11.3.3.  
CSM_208  ►M1 Durante el acoplamiento a una VU, un dispositivo 
GNSS externo utilizará el protocolo ilustrado en la figura 5 
(sección 10.2.2) para verificar la cadena de certificados de la  
VU. ◄  
Notas de la Figure 5 en este contexto.  
— La VU generará un nuevo par de claves efímero utili­
zando los parámetros de dominio del certificado EGF.  
— Los certificados de VU y las claves públicas mencionados 
en la figura son los empleados para la autenticación mu­
tua. La sección 9.1.4 los denota VU_MA.  
— Los certificados VU.CA y las claves públicas menciona­
dos en la figura son los empleados para firmar los certi­
ficados de VU y de dispositivo GNSS externo. La 
sección 9.1.3 los denota MSCA_VU-EGF.  
— El certificado VU.CA.EUR mencionado en la figura es el 
certificado raíz europeo indicado en la referencia CAR del 
certificado VU.CA.  
— El certificado VU.Link mencionado en la figura es el 
certificado de enlace de la VU, si está presente. Tal 
como se especifica en la sección 9.1.2, este es el certifi­
cado de enlace para un nuevo par de claves raíz europeo 
creado por la ERCA y firmado por la clave privada eu­
ropea anterior.  
— El certificado VU.Link.EUR es el certificado raíz europeo 
indicado en la referencia CAR del certificado VU.Link.  
CSM_209 En caso de desviación del requisito CSM_167, una EGF 
utilizará la hora del GNSS para verificar la validez temporal 
de cualquier certificado presentado.  
▼M1 
CSM_210 Una vez verificado el certificado VU_MA, el dispositivo  
GNSS externo almacenará el certificado para utilizarlo du­
rante el funcionamiento normal. Véase el apartado 11.3.3.  
▼B 
11.3.3  Durante el funcionamiento normal  
CSM_211  ►M1 Durante el funcionamiento normal, una unidad ins­
talada en el vehículo y una EGF utilizarán el protocolo ilus­
trado en la figura 11 para verificar la validez temporal del 
certificado EGF_MA almacenado y para configurar la clave 
pública VU_MA para la posterior autenticación de la VU. 
Durante el funcionamiento normal no se efectuará ninguna 
nueva verificación mutua de las cadenas de certificados. ◄  
Obsérvese que la Figure 11 consiste en esencia de los prime­
ros paso mostrados en la Figure 4 y en la Figure 5. Asi­
mismo, obsérvese que puesto que una EGF no es una tarjeta 
inteligente, la VU probablemente no mandará un comando 
Restaurar (Reset) para iniciar la comunicación y no recibirá 
una respuesta ATR. En cualquier caso, esto está fuera del 
ámbito del presente apéndice.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 491  
Figura 11  
Verificación mutua de la validez temporal del certificado durante el funcionamiento normal de la VU — EGF.
  
CSM_212 Tal como muestra la Figure 11, la unidad instalada en e l 
vehículo registrará un error si el certificado EGF_MA ha 
caducado. No obstante, la autenticación mutua, el acuerdo 
de claves y la comunicación subsiguiente a través de la men­
sajería segura procederán normalmente.  
11.4.  Autenticación de la VU, autenticación del chip y acuerdo de claves 
de sesión  
CSM_213 La autenticación de la VU, la autenticación del chip y el 
acuerdo de claves de sesión entre una VU y una EGF se 
efectuarán durante el acoplamiento y siempre que se resta­
blezca una sesión de mensajería segura durante el funciona­
miento normal. La VU y la EGF efectuarán los procesos 
descritos en las secciones 10.3 y 10.4. Todos los requisitos 
de estas secciones serán de aplicación.  
11.5.  Mensajería segura  
CSM_214 Todos los comandos y respuestas intercambiados entre un a 
unidad instalada en el vehículo y un dispositivo GNSS ex­
terno tras la autenticación correcta del chip y hasta el final de 
la sesión estarán protegidos por mensajería segura en modo 
solo autenticación. Todos los requisitos de la sección 10.5 
serán de aplicación.  
CSM_215 Si una sesión de mensajería segura entra una VU y una E GF 
se aborta, la VU establecerá inmediatamente una nueva sesión 
de mensajería segura, tal como se describe en las secciones 
11.3.3 y 11.4.  
12. EMPAREJAMIENTO Y COMUNICACIÓN ENTRE UNA VU Y UN 
SENSOR DE MOVIMIENTO  
12.1.  Generalidades  
CSM_216 Una unidad instalada en el vehículo y un sensor de movi ­
miento se comunicarán mediante el protocolo de interfaz es­
pecificado en la norma [ISO 16844-3] durante el empareja­
miento y el funcionamiento normal, con los cambios descritos 
en el presente capítulo y en la sección 9.2.1.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 492  
Nota:  se supone que los lectores del presente capítulo están 
familiarizados con el contenido de la norma [ISO 16844-3].  
12.2.  Emparejamiento de la VU con el sensor de movimiento mediante 
claves de diferentes generaciones  
Como se explica en la sección 9.2.1, la clave maestra del senso r de 
movimiento y todas las claves asociadas son sustituidas regular mente. 
Esta circunstancia da lugar a la presencia de hasta tres claves  AES 
K M-WC  (de generaciones de claves consecutivas) relacionadas con los 
sensores de movimiento en las tarjetas de taller. Análogamente,  en los 
sensores de movimiento puede haber hasta tres cifrados de datos  dife­
rentes basados en algoritmos AES resultantes de generaciones co nsecu­
tivas de la clave maestra K  M del sensor de movimiento. Una unidad 
instalada en el vehículo contiene solamente una clave K  M-VU  relacionada 
con el sensor de movimiento.  
CSM_217 Una VU de segunda generación y un sensor de movimiento 
de segunda generación se emparejarán de la siguiente manera 
(compárese la tabla 6 de la norma [ISO 16844-3]):  
1. Una tarjeta de taller de segunda generación se inserta en la  
VU, y la VU se conecta al sensor de movimiento.  
2. La VU lee todas las claves K  M-WC  disponibles en la tarjeta 
de taller, inspecciona sus números de versión de clave y 
selecciona la que tiene el número correspondiente al de la 
versión de la clave K  M-VU  de la VU. Si la clave K  M-WC  
correspondiente no está presente en la tarjeta de taller, la 
VU aborta el proceso de emparejamiento y muestra un 
mensaje de error apropiado al titular de la tarjeta de taller.  
3. La VU calcula la clave maestra K  M del sensor de movi­
miento a partir de K  M-VU  y K  M-WC  y la clave de identifi­
cación K  ID a partir de K  M , tal como se especifica en la 
sección 9.2.1.  
4. La VU envía la instrucción para iniciar el proceso de 
emparejamiento al sensor de movimiento, tal como se des­
cribe en la norma [ISO 16844-3], y cifra el número de 
serie que recibe del sensor de movimiento con la clave de 
identificación K  ID . La VU envía el número de serie cifrado 
al sensor de movimiento.  
5. El sensor de movimiento compara el número de serie ci­
frado consecutivamente con cada cifrado del número de 
serie que contiene internamente. Si encuentra una corres­
pondencia, se autentica la VU. El sensor de movimiento 
anota la clave de generación K  ID utilizada por la VU y 
devuelve la versión cifrada correspondiente de su clave de 
emparejamiento; es decir, el cifrado creado mediante la 
misma generación de K  M . 
6. La VU descifra la clave de emparejamiento mediante la 
clave K  M , genera una clave de sesión K  S , la cifra con la 
clave de emparejamiento y envía el resultado al sensor de 
movimiento. El sensor de movimiento descifra la clave K  S . 
7. La VU ensambla la información de emparejamiento tal 
como se define en la norma [ISO 16844-3], cifra la infor­
mación con la clave de emparejamiento, y envía el resul­
tado al sensor de movimiento. El sensor de movimiento 
descifra la información de emparejamiento.  
8. El sensor de movimiento cifra la información de empare­
jamiento recibida con la clave K  S recibida y la envía a la 
VU. La VU verifica que la información de emparejamiento 
es la misma información que la que la VU envíó al sensor  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 493  
de movimiento en el paso anterior. Si lo es, esto prueba 
que el sensor de movimiento utilizó la misma clave K  S 
que la VU y, por consiguiente, en el paso 5 envió su clave 
de emparejamiento cifrada con la clave K  M de la genera­
ción correcta. Por tanto, el sensor de movimiento es 
autenticado.  
Obsérvese que los pasos 2 y 5 son diferentes del proceso 
normal definido en la norma ISO 16844-3]; los demás pasos 
son normales.  
Ejemplo:  Supóngase que un emparejamiento se efectúa du­
rante el primer año de validez del certificado ERCA (3); 
véase la Figure 2 en la sección 9.2.1.2. Además  
— Supóngase que el sensor de movimiento fue expedido 
durante el último año de validez del certificado ERCA 
(1). Por consiguiente contendrá las siguientes claves y 
datos:  
— N  s [1]: su número de serie cifrado con la generación 1 
de la clave K  ID 
— N  s [2]: su número de serie cifrado con la generación 2 
de la clave K  ID 
— N  s [3]: su número de serie cifrado con la generación 3 
de la clave K  ID 
— K  P [1]: su clave de emparejamiento de generación 
1 ( 1 ), cifrada con la generación 1 de la clave K  M 
— K  P [2]: su clave de emparejamiento de generación 2, 
cifrada con la generación 2 de la clave K  M 
— K  P [3]: su clave de emparejamiento de generación 3, 
cifrada con la generación 3 de la clave K  M 
— Supóngase que la tarjeta de taller fue expedida durante el 
último año de validez del certificado ERCA (3). Por tanto 
contendrá la generación 2 y la generación 3 de la clave 
K M-WC  . 
— Supóngase que la VU es una VU de generación 2 que 
contiene la generación 2 de la clave K  M-VU  . 
En este caso, en los pasos 2 a 5 ocurrirá lo siguiente:  
— Paso 2: La VU lee la generación 2 y la generación 3 de la 
clave K  M-WC  en la tarjeta de taller e inspecciona sus 
números de versión.  
— Paso 3: La VU combina la clave K  M-WC  de generación 2 
con su clave K  M-VU  para computar las claves K  M y K ID . 
— Paso 4: La VU cifra el número de serie que recibe del 
sensor de movimiento con la clave K  ID . 
— Paso 5: El sensor de movimiento compara los datos reci­
bidos con N  s [1] y no encuentra una correspondencia. Se­
guidamente, compara los datos con N  s [2] y encuentra una 
correspondencia. Concluye que la VU es de generación 2, 
y por tanto devuelve la clave K  P [2]. ▼B 
( 1 ) Obsérvese que las claves de emparejamiento de generación 1, g eneración 2 y generación 
3 pueden de hecho ser la misma clave, o bien pueden ser tres cl aves distintas de tres 
longitudes diferentes, tal como se explica en CSM_117.
 02016R0799 — ES — 21.08.2023 — 003.001 — 494  
12.3.  Emparejamiento y comunicación entre una VU y un sensor de mo ­
vimiento mediante el algoritmo AES  
CSM_218 Tal como se especifica en la Table 3 de la sección 9.2. 1, 
todas las claves involucradas en el emparejamiento de una 
unidad instalada en el vehículo (de segunda generación) y 
un sensor de movimiento y en la comunicación subsiguiente 
serán claves AES, en lugar de las claves TDES de doble 
longitud especificadas en la norma [ISO 16844-3]. Estas cla­
ves AES pueden tener una longitud de 128, 192 o 256 bits. 
Puesto que el AES tiene un tamaño de bloque de 16 bytes, la 
longitud del mensaje cifrado deberá ser un múltiplo de 16 
bytes, en comparación con los 8 bytes para el TDES. Ade­
más. algunos de estos mensajes se utilizarán para transportar 
claves AES cuya longitud puede ser de 128, 192 o 256 bits. 
Por consiguiente, el número de bytes de datos por instrucción 
de la tabla 5 de la norma [ISO 16844-3] se modificará tal 
como ilustra la Table 6:  
▼M1 
Tabla 6  
Número de bytes de datos de texto plano y cifrados por instrucción definido en la norma [ISO 16844-3]  
Instrucción  Solicitud/res­
puesta  Descripción de los datos  # de bytes de texto 
plano según 
la norma [ISO 
16844-3]  # de bytes de datos 
de texto plano me­
diante claves AES  # de bytes de datos cifrados 
mediante claves AES de lon­
gitud en bits de  
128 192  256  
10 solicitud  Datos de autentica­
ción + número de ar­
chivo  8 8  1 6  1 6  1 6  
11 respuesta  Datos de autentica­
ción + contenido de 
archivo  16 o 32, según el 
archivo  16 o 32, según el 
archivo  32 / 48  32 / 48  32 / 48  
41 solicitud  N .  o de serie del sen­
sor 8 8  1 6  1 6  1 6  
41 respuesta  Clave de empareja­
miento  16 16 / 24 / 32  1 6  3 2  3 2  
42 solicitud  Clave de sesión  1 6  16 / 24 / 32  1 6  3 2  3 2  
43 solicitud  Información de empa­
rejamiento  24 2 4  3 2  3 2  3 2  
50 respuesta  Información de empa­
rejamiento  24 2 4  3 2  3 2  3 2  
70 solicitud  Datos de autentica­
ción 8 8  1 6  1 6  1 6  
80 respuesta  Valor de contador del 
sensor + datos de au­
tenticación  8 8  1 6  1 6  1 6  
▼B 
CSM_219 La información de emparejamiento enviada en las instruc cio­
nes 43 (solicitud de la VU) y 50 (respuesta del sensor de 
movimiento) se ensamblará tal como se especifica en la 
sección 7.6.10 de la norma [ISO 16844-3], salvo que se usará 
el algoritmo AES en lugar del algoritmo TDES en el esquema 
criptográfico basado en el emparejamiento de datos, lo que 
resulta en dos cifrados AES, y se adoptará el relleno especi­
ficado en CSM_220 a fin de adecuarla al tamaño de bloque 
del AES. La clave K'  p usada para este cifrado se generará de 
la siguiente manera:  
— En el caso de que la clave de emparejamiento K  P sea de 
16 bytes de longitud: K'  p = K  P XOR (N  s ||N s ) ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 495  
— En el caso de que la clave de emparejamiento K  P sea de 
24 bytes de longitud: K'  p = K  P XOR (N  s ||N s ||N s ) 
— En el caso de que la clave de emparejamiento K  P sea de 
32 bytes de longitud: K'  p = K  P XOR (N  s ||N s ||N s ||N s ) 
donde N  s es el número de serie de 8 bytes del sensor de 
movimiento.  
CSM_220 En el caso de que la longitud de datos de texto plano ( con 
claves AES) no sea un múltiplo de 16 bytes, se usará el 
método de relleno 2 definido en la norma [ISO 9797-1].  
Nota:  en la norma [ISO 16844-3], el número de bytes de 
datos de texto plano es siempre un múltiplo de 8, de tal 
modo que no se necesita relleno si se usa el algoritmo TDES. 
Esta parte del presente apéndice no modifica la definición de 
datos y mensajes en la norma [ISO 16844-3], y por tanto 
exige la aplicación de relleno.  
CSM_221 Para la instrucción 11 y en el caso de que deba cifrars e más 
de un bloque de datos, se usará el modo de operación de 
encadenamiento de bloques de cifrado tal como se define 
en la norma [ISO 10116], con un parámetro interpolar  m =  
1. El vector de inicialización que se deberá utilizar será el 
siguiente:  
— Para la instrucción 11: El bloque de autenticación de 8 
bytes especificado en la sección 7.6.3.3 de la norma [ISO 
16844-3], rellenado mediante el método de relleno 2 de­
finido en la norma [ISO 9797-1]; véanse asimismo las 
secciones 7.6.5 y 7.6.6 de la norma [ISO 16844-3].  
— Para todas las demás instrucciones en las que se trans­
fieran más de 16 bytes, tal como se especifica en la Table 
6: «00»{16}, es decir, dieciséis bytes de valor binario 0.  
Nota:  Tal como muestran las secciones 7.6.5 y 7.6.6 de la 
norma [ISO 16844-3]., cuando el sensor de movimiento cifra 
archivos de datos para su inclusión en la instrucción 11, el 
bloque de autenticación  
— se usa como vector de inicialización para el cifrado en 
modo de encadenamiento de bloques de cifrado de los 
archivos de datos, y  
— se cifra e incluye como el primer bloque en los datos 
enviados a la VU.  
12.4.  Emparejamiento del sensor de movimiento para equipos de diferen ­
tes generaciones  
CSM_222 Como se explica en la sección 9.2.1, un sensor de movi­
miento de segunda generación puede contener el cifrado ba­
sado en el algoritmo TDES de los datos de emparejamiento 
(tal como se define en la parte A del presente apéndice), lo 
que permite emparejar el sensor de movimiento con una VU 
de primera generación. Si es el caso, una VU de primera 
generación y un sensor de movimiento de segunda generación 
se emparejarán en la forma descrita en la parte A del presente 
apéndice y en la norma [ISO 16844-3]. Para el proceso de 
emparejamiento puede usarse una tarjeta de taller de primera 
generación o de segunda generación.  
Notas:  
— No es posible emparejar una VU de segunda generación 
con un sensor de movimiento de primera generación.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 496  
— No es posible usar una tarjeta de taller de primera gene­
ración para emparejar una VU de segunda generación con 
un sensor de movimiento.  
13. SEGURIDAD PARA LA COMUNICACIÓN REMOTA MEDIANTE 
DSRC  
13.1.  Generalidades  
Tal como se especifica en el apéndice 14, una VU genera regular mente 
datos de monitorización remota de tacógrafos (RTM) y los envía a la 
instalación (interna o externa) de comunicación remota (RCF). L a ins­
talación de comunicación remota es responsable de enviar estos datos por 
la interfaz descrita en el apéndice 14 al interrogador remoto. El apéndice 
1 especifica que los datos RTM son la concatenación de:  
Carga útil cifrada del tacógrafo  el cifrado de la carga útil de texto 
plano del tacógrafo  
Datos de seguridad DSRC  descritos a continuación  
El formato de los datos de carga útil de texto plano del tacógr afo se 
especifica en el apéndice 1 y se describe en mayor profundidad en el 
apéndice 14. Esta sección describe la estructura de los datos d e seguridad 
DSRC; la especificación formal está en el apéndice 1.  
CSM_223 Los datos
  de texto plano comuni­
cados por una VU a una instalación de comunicación remota 
(si la ICF es externa) o de la VU a un interrogador remoto a 
través de la interfaz DSRC (si la RCF es interna) se protege­
rán en modo cifrar y después autenticar, es decir, primero se 
cifran los datos de carga útil del tacógrafro para asegurar la 
confidencialidad del mensaje, y después se calcula un código 
MAC para asegurar la autenticidad e integridad de los datos.  
CSM_224 Los datos de seguridad DSRC estarán compuestos de la co n­
catenación de los siguientes elementos de datos en el orden 
siguiente: véase también la Figure 12:  
Fecha y hora actual  la fecha y hora actual de la VU (tipo de dato
  
) 
Contador  un contador de 3 bytes, véase CSM_225  
▼M1 
N. o de serie de la VU  el número de serie de la VU o el identificador de la 
solicitud de certificado (tipo de dato VuSerialNum­
ber o CertificateRequestID), véase CSM_123  
▼B 
N o de versión de la clave maestra DSRC  el número de versión de 1 byte de la clave maestra 
DSRC de la que se derivaron las claves DSRC es­
pecíficas de la VU; véase la sección 9.2.2.  
MAC  el MAC calculado a través de todos los bytes ante­
riores en los datos RTM.  
CSM_225 El contador de 3 bytes en los datos de seguridad DSRC e stará 
en el formato MSB-primero. La primera vez que una VU 
calcule un conjunto de datos RTM tras su puesta en funcio­
namiento, configurará el valor del contador en 0. Antes de 
calcular el siguiente conjunto de datos RTM, la VU incre­
mentará cada vez el valor de los datos del contador en 1.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 497  
13.2.  Cifrado de la carga útil del tacógrafo y generación del código MAC  
CSM_226 Dado un elemento de datos de texto plano con el tipo de  dato
  
descrito en el apéndice 14, una VU 
cifrará estos datos tal como muestra la Figure 12: la clave 
DSRC de la VU para el cifrado K_VU  DSRC  _ENC (véase la 
sección 9.2.2) se usará con el algoritmo AES en el modo de 
operación de encadenamiento de bloques de cifrado (CBC), 
tal como se define en la norma [ISO 10116], con un paráme­
tro interpolar  m = 1. El vector de inicialización será igual a  V 
= current date time  | | «00 00 00 00 00 00 00 00 00»  | | 
counter , donde  current date time  y counter  se especifican 
en CSM_224. Los datos que se deban cifrar se rellenarán 
por el método 2 definido en la norma [ISO 9797-1].  
CSM_227 Una VU calculará el código MAC en los datos de segurida d 
DSRC como se indica en la Figure 12: el MAC se calculará a 
través de todos los bytes anteriores en los datos RTM, hasta 
el número de versión de la clave maestra DSRC, este in­
cluido, e incluyendo las etiquetas y longitudes de los objetos 
de datos. La VU usará su clave DSRC para comprobar la 
autenticidad de K_VU  DSRC  _MAC (véase la sección 9.2.2) 
con el algoritmo AES en modo CMAC, tal como se especi­
fica en la publicación especial [SP 800-38B]. La longitud del 
código MAC estará relacionada con la longitud de las claves 
DSRC específicas de la VU, tal como se especifica en 
CSM_50.  
Figura 12  
Cifrado de la carga útil del tacógrafo y generación del código MAC
  
13.3.  Verificación y descifrado de la carga útil del tacógrafo  
CSM_228 Cuando un interrogador remoto reciba datos RTM de una 
VU, enviará la totalidad de los datos RTM a una tarjeta de 
control en el campo datos de un comando PROCESS DSRC 
MESSAGE, tal como se describe en el apéndice 2. Seguida­
mente:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 498  
1. La tarjeta de control inspeccionará el número de versión de 
la clave maestra DSRC en los datos de seguridad DSRC. 
Si la tarjeta de control no conoce la clave maestra DSRC 
indicada, devolverá un error especificado en el apéndice 2 
y abortará el proceso.  
▼M1 
2. La tarjeta de control usará la clave maestra DSRC indicada 
en combinación con el número de serie de la VU o el 
identificador de la solicitud de certificado en los datos 
de seguridad DSRC para derivar las claves DSRC 
K_VU  DSRC  _ENC y K_VU  DSRC  _MAC específicas de la 
VU, tal como se especifica en CSM_124.  
▼B 
3. La tarjeta de control usará la clave K_VU  DSRC  _MAC para 
verificar el código MAC en los datos de seguridad DSRC, 
tal como se especifica en CSM_227. Si el código MAC es 
incorrecto, la tarjeta de control devolverá un error especi­
ficado en el apéndice 2 y abortará el proceso.  
4. La tarjeta de control usará la clave K_VU  DSRC  _ENC para 
descifrar la carga útil cifrada del tacógrafo, tal como se 
especifica en CSM_226. La tarjeta de control eliminará el 
relleno y devolverá los datos de la carga útil descifrada al 
interrogador remoto.  
CSM_229 A fin de impedir los ataques por repetición, el interro gador 
remoto verificará la actualidad de los datos RTM compro­
bando que la  current date time  de los datos de seguridad 
DSRC no se desvíe demasiado de la hora actual del interro­
gador remoto.  
Notas:  
— Esto exige que el interrogador remoto tenga una fuente 
exacta y fiable de la hora.  
— Puesto que el apéndice 14 exige a una VU que calcule un 
conjunto de datos RTM nuevo cada 60 segundos, y que se 
permite que el reloj de la VU se desvíe un minuto de la 
hora real, un límite inferior de la actualidad de los datos 
RTM es 2 minutos. La actualidad real exigida depende 
asimismo de la exactitud del reloj del interrogador remoto.  
CSM_230 Cuando un taller verifique el funcionamiento correcto d e la 
funcionalidad DSRC de una VU, enviará la totalidad de los 
datos RTM recibidos de la VU a una tarjeta de taller en el 
campo datos de un comando PROCESS DSRC MESSAGE, 
tal como se describe en el apéndice 2. La tarjeta de taller 
efectuará todas las comprobaciones y acciones especificadas 
en CSM_228.  
14. FIRMA DE DESCARGAS DE DATOS Y VERIFICACIÓN DE FIR­
MAS  
14.1.  Generalidades  
CSM_231 El equipo dedicado inteligente (IDE) almacenará en un a r­
chivo físico los datos recibidos de una VU o de una tarjeta 
durante una sesión de descarga. Los datos se pueden almace­
nar en un ESM (medio de almacenamiento externo). El ar­
chivo contiene firmas digitales de bloques de datos, tal y 
como se especifica en el apéndice 7, apartado Protocolos de 
transferencia de datos. Este archivo contendrá además los 
certificados siguientes (remítase a la sección 9.1).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 499  
— En el caso de una descarga de una VU:  
— El certificado VU_Sign  
— El certificado MSCA_VU-EGF que contiene la clave 
pública que deberá utilizarse para la verificación del 
certificado VU_Sign.  
— En el caso de una descarga de una tarjeta:  
— El certificado Card_Sign.  
— El certificado MSCA_Card que contiene la clave pú­
blica que deberá utilizarse para la verificación del 
certificado Card_Sign.  
CSM_232 El IDE dispondrá asimismo de:  
— En el caso de que utilice la tarjeta de control para verifica r 
la firma, tal como muestra la Figure 13: El certificado de 
enlace que relaciona el certificado EUR más reciente con 
el certificado EUR cuyo período de validez es el directa­
mente anterior, si existe.  
— En el caso de que verifique la firma él mismo. todos los 
certificados raíz europeos válidos.  
Nota:  el método que el IDE utiliza para recuperar estos cer­
tificados no se especifica en el presente apéndice.  
14.2.  Generación de firmas  
CSM_233 El algoritmo de firma para crear firmas digitales en da tos 
descargados será el algoritmo ECDSA, tal como se especifica 
en la norma [DSS], utilizando el algoritmo hash relacionado 
con el tamaño de clave de la VU o de la tarjeta, tal como se 
especifica en CSM_50. El formato de la firma será de texto 
plano, tal como se especifica en la directriz técnica [TR- 
03111].  
14.3.  Verificación de firmas  
CSM_234  ►M1 Un IDE puede efectuar por sí mismo la verificación de 
una firma en los datos descargados o utilizar una tarjeta de 
control a tal efecto. En el caso de que utilice la tarjeta de 
control, la verificación de la firma se efectuará tal como 
muestra la Figure 13. Para verificar la validez temporal de 
un certificado presentado por el IDE, la tarjeta de control 
utilizará su reloj interno, tal como se especifica en el 
punto CSM_167. La tarjeta de control actualizará su hora 
actual si la fecha efectiva de un certificado auténtico de 
‘fuente válida de hora’ es más reciente que la hora actual 
de la tarjeta. La tarjeta solamente aceptará los certificados 
siguientes como fuente válida de hora:  
— Certificados de enlace ERCA de segunda generación  
— Certificados de enlace MSCA de segunda generación  
— Certificados VU_Sign o Card_Sign de segunda genera­
ción expedidos por el mismo país que el propio certifi­
cado de tarjeta de la tarjeta de control.  
En el caso de que efectúe la verificación de la firma por sí 
mismo, el IDE verificará la autenticidad y validez de todos 
los certificados de la cadena de certificados en el archivo de 
datos y verificará asimismo la firma en los datos de acuerdo 
con el esquema de firma definido en la norma [DSS]. En 
ambos casos, para cada certificado que lea del archivo de 
datos, es necesario verificar que el campo «Autorización del 
titular de la tarjeta» (CHA) sea correcto:  
— El campo CHA del certificado EQT indicará un certifi­
cado de VU o de tarjeta (según proceda) para la firma 
(véase apéndice 1, tipo de datos EquipmentType).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 500  
— El campo CHA del certificado EQT.CA indicará una 
MSCA.  
— El campo CHA del certificado EQT.Link indicará una 
ERCA. ◄  
Notas de la Figure 13:  
— El equipo que firmó los datos que han de analizarse se 
denota EQT.  
— Los certificados EQT y las claves públicas mencionados 
en la figura son los empleados para la firma, es decir, 
VU_Sign o Card_Sign.  
— Los certificados EQT.CA y las claves públicas menciona­
dos en la figura son los empleados para firmar los certi­
ficados VU o Card, según corresponda.  
— El certificado EQT.CA.EUR mencionado en la figura es 
el certificado raíz europeo indicado en la referencia CAR 
del certificado EQT.CA.  
— El certificado EQT.Link mencionado en la figura es el 
certificado de enlace del EQT, si está presente. Tal 
como se especifica en la sección 9.1.2, este es el certifi­
cado de enlace para un nuevo par de claves raíz europeo 
creado por la ERCA y firmado con la clave privada eu­
ropea anterior.  
— El certificado EQT.Link.EUR es el certificado raíz euro­
peo indicado en la referencia CAR del certificado 
EQT.Link.  
CSM_235 Para calcular la función hash del mensaje M enviada a l a 
tarjeta de control en el comando PSO:Hash, el IDE utilizará 
el algoritmo hash relacionado con el tamaño de clave de la 
VU o de la tarjeta de la que se descarguen los datos, tal como 
se especifica en CSM_50.  
CSM_236 Para verificar la firma del EQT, la tarjeta de control seguirá el 
esquema de firma definido en la norma [DSS].  
Nota:  El presente documento no especifica ninguna acción 
que se deba emprender si la firma en un archivo de datos 
descargado no se puede verificar o si la verificación no se 
efectúa correctamente.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 501  
Figura 13  
Protocolo para la verificación de la firma en un archivo de datos descargado
  ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 502  
Apéndice 12  
POSICIONAMIENTO BASADO EN EL SISTEMA MUNDIAL DE 
NAVEGACIÓN POR SATÉLITE (GNSS)  
ÍNDICE  
1. INTRODUCCIÓN  
1.1. Ámbito de aplicación  
▼M3 
1.1.1 Referencias  
▼B 
1.2. Acrónimos y notaciones  
▼M3 
2. CARACTERÍSTICAS BÁSICAS DEL RECEPTOR GNSS  
3. SECUENCIAS PROPORCIONADAS POR EL RECEPTOR GNSS  
▼B 
4. UNIDAD INSTALADA EN EL VEHÍCULO CON DISPOSITIVO 
GNSS EXTERNO  
4.1. Configuración  
4.1.1 Principales componentes e interfaces  
4.1.2 Estado del dispositivo GNSS externo al final de la produc ción 
4.2. Comunicación entre el dispositivo GNSS externo y la unidad  instalada en 
el vehículo  
4.2.1 Protocolo de comunicación  
4.2.2 Transferencia segura de datos GNSS  
4.2.3 Estructura del comando de lectura del registro  
▼M3 
4.2.4 Estructura del comando WriteRecord  
4.2.5 Otros comandos  
▼B 
4.3. Acoplamiento, autenticación mutua y acuerdo de la clave de  la sesión 
entre el dispositivo GNSS externo y la unidad instalada en el v ehículo  
4.4. Gestión de errores  
4.4.1 Error de comunicación con el dispositivo GNSS externo  
4.4.2 Manipulación de la integridad física del dispositivo GNSS  externo  
4.4.3 Ausencia de información de posición del receptor GNSS  
4.4.4 Certificado del dispositivo GNSS externo expirado  
5. UNIDAD INSTALADA EN EL VEHÍCULO SIN DISPOSITIVO GNSS 
EXTERNO  
5.1. Configuración  
▼M3 
5.2. Transferencia de información del receptor GNSS a la VU  
__________  
5.3. Transferencia de información de la VU al receptor GNSS  
5.4. Gestión de errores  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 503  
5.4.1 Ausencia de información sobre la posición procedente del receptor GNSS  
6. PROCESAMIENTO Y REGISTRO DE LOS DATOS DE POSICIÓN 
POR LA VU  
7. CONFLICTO TEMPORAL DEL GNSS  
8. CONFLICTO DE MOVIMIENTO DEL VEHÍCULO  
1. INTRODUCCIÓN  
El presente apéndice recoge los requisitos técnicos relativos a l receptor 
GNSS y los datos del GNSS empleados por la unidad instalada en el 
vehículo, incluidos los protocolos que deben aplicarse para gar antizar una 
transferencia de datos segura y correcta de la información sobr e el 
posicionamiento.  
1.1. Ámbito de aplicación  
GNS_1 La unidad instalada en el vehículo recabará datos de loca liza­
ción de al menos una red de satélites GNSS.  
La unidad instalada en el vehículo podrá incluir o no un dispo­
sitivo GNSS externo, tal y como se indica en el gráfico 1:  
1.1.1  Referencias  
En esta parte del presente apéndice se utilizan las siguientes referencias:  
NMEA NMEA (National Marine Electronics Association [asociación 
nacional de electrónica marina]) 0183 Interface Standard, V4.11  
▼B 
Gráfico 1  
Diferentes configuraciones del receptor GNSS.
  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 504  
1.2. Acrónimos y notaciones  
En el presente apéndice se utilizan los siguientes acrónimos:  
DOP dilución de precisión  
EGF archivo elemental del dispositivo GNSS  
EGNOS Sistema Europeo de Navegación por Complemento Geoesta­
cionario  
GNSS sistema mundial de navegación por satélite  
GSA dilución de precisión del GPS y satélites activos  
HDOP dilución de precisión horizontal  
ICD documento de control de interfaces  
NMEA National Marine Electronics Association  
▼M3 
OSNMA  Galileo Open Service Navigation Message Authentication  (au­
tenticación de mensajes de navegación del servicio abierto de 
Galileo)  
▼B 
PDOP dilución de precisión de la posición  
RMC específico mínimo recomendado  
▼M3 
RTC  Real Time Clock  (reloj de tiempo real)  
▼B 
SIS señal en el espacio  
VDOP dilución de precisión vertical  
VU unidad instalada en el vehículo  
▼M3 
2. CARACTERÍSTICAS BÁSICAS DEL RECEPTOR GNSS  
▼B 
Independientemente de la configuración del tacógrafo inteligent e, que 
puede incluir o no un dispositivo GNSS externo, la facilitación  de infor­
mación de posición precisa y fiable es un elemento esencial par a el 
funcionamiento efectivo del tacógrafo inteligente. Por consigui ente, con­
viene exigir su compatibilidad con los servicios prestados por los pro­
gramas Galileo y Sistema Europeo de Navegación por Complemento 
Geoestacionario (EGNOS), con arreglo a lo establecido en el 
Reglamento (UE) n  o 1285/2013 del Parlamento Europeo y del Con­
sejo (  1 ). El sistema establecido en el marco del programa Galileo es u n 
sistema mundial independiente de radionavegación por satélite, y el esta­
blecido en el marco del programa EGNOS es un sistema regional d e 
navegación por satélite que mejora la calidad de la señal del S istema de 
Posicionamiento Global (GPS).  
GNS_2 Los fabricantes se asegurarán de que los receptores GNSS 
integrados en los tacógrafos inteligentes sean compatibles con 
los servicios de localización prestados por los sistemas Galile o 
y EGNOS. Además, los fabricantes podrán optar por la com­
patibilidad con otros sistemas de navegación por satélite.  ▼B 
( 1 ) Reglamento (UE) n  o 1285/2013 del Parlamento Europeo y del Consejo, de 11 de di­
ciembre de 2013, relativo al establecimiento y la explotación d e los sistemas europeos de 
radionavegación por satélite y por el que se derogan el Reglame nto (CE) no 876/2002 
del Consejo y el Reglamento (CE) n  o 683/2008 del Parlamento Europeo y del Consejo 
(DO L 347 de 20.12.2013, p. 1).
 02016R0799 — ES — 21.08.2023 — 003.001 — 505  
GNS_3 El receptor GNSS deberá poder admitir la autenticación de  
mensajes de navegación en el servicio abierto de Galileo (OS­
NMA).  
GNS_3a El receptor GNSS realizará una serie de comprobaciones d e 
coherencia para verificar que las mediciones que ha computado 
basándose en los datos de la OSNMA han generado una infor­
mación correcta sobre la posición, la velocidad y los datos del  
vehículo y, por lo tanto, no han sido afectadas por ningún 
ataque externo, por ejemplo la interceptación y retransmisión 
con retardo ( meaconing ). Estas comprobaciones de coherencia 
consistirán, por ejemplo, en lo siguiente:  
— detección de emisiones de potencia anormal mediante la 
monitorización combinada del control automático de ganan­
cia y la relación de portadora a densidad de ruido (C/N0),  
— coherencia de la medición de los pseudorrangos y coheren­
cia de la medición Doppler en el tiempo, en especial la 
detección de saltos bruscos en la medición,  
— técnicas de receptor con supervisión autónoma de la inte­
gridad, en especial la detección de mediciones incoherentes 
con la posición estimada,  
— comprobaciones de la posición y la velocidad, en particular 
las soluciones anormales de posición y velocidad, los saltos 
repentinos y el comportamiento incoherente con la diná­
mica del vehículo,  
— coherencia de la hora y la frecuencia, en especial los saltos  
y las derivas del reloj que no son coherentes con las ca­
racterísticas del reloj del receptor.  
GNS_3b La Comisión Europea elaborará y aprobará los documentos 
siguientes:  
— Un documento de control de la interfaz de señal en el 
espacio (SIS ICD,  Signal in Space Interface Control Docu ­
ment ), en el que se detalle la información OSNMA trans­
mitida en la señal Galileo.  
— Las Directrices OSNMA para los receptores, que conten­
drán los requisitos y los procesos necesarios para que los 
receptores garanticen una ejecución segura de la OSNMA, 
así como recomendaciones para mejorar el rendimiento de 
esta. 
Los receptores GNSS instalados en los tacógrafos, ya sean 
internos o externos, deberán construirse de acuerdo con el 
SIS ICD y con las Directrices OSNMA para los receptores.  
GNS_3c El receptor GNSS proporcionará mensajes de posición, den o­
minados en el presente anexo y sus apéndices «mensajes de 
posición autenticados», que se elaboran utilizando exclusiva­
mente satélites que emiten mensajes de navegación cuya auten­
ticidad ha sido correctamente verificada.  
GNS_3d El receptor GNSS proporcionará asimismo mensajes de posi ­
ción estándar elaborados utilizando los satélites a la vista, e stén 
autenticados o no.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 506  
GNS_3e El receptor GNSS utilizará el reloj de tiempo real (RTC)  de la 
VU como referencia horaria en la sincronización de la hora que 
es necesaria para la OSNMA.  
GNS_3f La VU proporcionará la hora de su RTC al receptor GNSS.  
GNS_3g La VU proporcionará al receptor GNSS la desviación máxim a 
de la hora especificada en el requisito 41 del anexo I C, junto  
con la hora de su RTC.  
3. SECUENCIAS PROPORCIONADAS POR EL RECEPTOR GNSS  
En este punto se describen las secuencias utilizadas en el func ionamiento 
del tacógrafo inteligente para transmitir mensajes de posición estándar y 
autenticados. Este punto es aplicable tanto a la configuración de tacó­
grafo inteligente con dispositivo GNSS externo como sin él.  
GNS_4 Los datos de posición estándar se basan en la secuencia 
NMEA de datos específicos mínimos recomendados (RMC,  
Recommended Minimum Specific ) del GNSS, que contiene 
la información sobre la posición (latitud y longitud), la hora 
en formato UTC (hhmmss.ss) y la velocidad sobre tierra en 
nudos, además de valores adicionales.  
El formato de la secuencia RMC es el siguiente (según la 
norma NMEA V4.11):  
Gráfico 2:  
Estructura de la secuencia RMC
  
$–RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x .x,xxxx,x.x,a,a,a* hh 
1) Hora (UTC)  
2) Estado, A = Posición válida, V = Advertencia  
3) Latitud  
4) N o S  
5) Longitud  
6) E o W  
7) Velocidad sobre tierra en nudos  
8) Ruta seguida, grados verdaderos  
9) Fecha, ddmmaa  
10) Variación magnética, grados  
11) E o W  
12) Indicador de modo FAA  
13) Estado de navegación  
14) Suma de control  
El estado de navegación es opcional y puede no estar presente 
en la secuencia RMC.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 507  
El estado indica si se dispone de señal GNSS. Los datos 
recibidos (por ejemplo, hora o latitud/longitud) no podrán 
utilizarse para registrar la posición del vehículo en la VU 
hasta que el estado tenga «A» como valor.  
La resolución de la posición se basa en el formato de la 
secuencia RMC anteriormente descrita. La primera parte de 
los campos 3 y 5 sirve para representar los grados. El resto se  
emplea para representar los minutos con tres decimales. Por 
consiguiente, la resolución es de 1/1 000 de minuto o 
1/60 000 de grado (puesto que un minuto es 1/60 de un 
grado).  
GNS_4a Los datos de posición autenticados se basan en una secue ncia 
similar a NMEA, «datos específicos mínimos autenticados» 
(AMC,  Authenticated Minimum Specific ), que contiene la in­
formación sobre la posición (latitud y longitud), la hora en 
formato UTC (hhmmss.ss) y la velocidad sobre tierra en nu­
dos, además de valores adicionales.  
El formato de la secuencia AMC es el siguiente (según la 
norma NMEA V4.11, salvo con respecto al valor número 2):  
Gráfico 3  
Estructura de la secuencia AMC
  
$–AMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*h h 
1) Hora (UTC)  
2) Estado, A= posición autenticada (establecida utilizando por lo menos cuatro 
satélites que emiten mensajes de navegación cuya autenticidad h a sido co­
rrectamente verificada), J=  jamming  (interferencia intencionada) u O= otro 
ataque al GNSS en ausencia de una autenticación fallida de los mensajes de 
navegación (mediante comprobaciones de coherencia realizadas co nforme a 
GNS_3a), F= autenticación fallida de los mensajes de navegación  (detectada 
por las verificaciones OSNMA especificadas en los documentos me nciona­
dos en GNS_3b), V= vacío (posición autenticada no disponible po r cualquier 
otra razón)  
3) Latitud  
4) N o S  
5) Longitud  
6) E o W  
7) Velocidad sobre tierra en nudos  
8) Ruta seguida, grados verdaderos  
9) Fecha, ddmmaa  
10) Variación magnética, grados  
11) E o W  
12) Indicador de modo FAA  
13) Estado de navegación  
14) Suma de control  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 508  
El estado de navegación es opcional y puede no estar presente 
en la secuencia AMC.  
El estado indica si se dispone de una posición GNSS auten­
ticada, si se ha detectado un ataque sobre las señales GNSS, si  
ha fallado la autenticación de los mensajes de navegación o si 
la posición GNSS está vacía. Cuando el valor del estado no es 
«A», los datos recibidos (por ejemplo, hora o latitud/longitud)  
no se consideran válidos y no pueden utilizarse para registrar 
la posición del vehículo en la VU. Cuando el valor del estado 
es «J» ( jamming ), «O» (otro ataque al GNSS) o «F» (auten­
ticación fallida de los mensajes de navegación), se registrará 
en la VU un incidente de anomalía del GNSS, según se define 
en el anexo I C y el apéndice 1 (EventFaultCode).  
GNS_5 La unidad instalada en el vehículo almacenará en su base de 
datos la información de posición relativa a la latitud y a la 
longitud con una resolución de 1/10 de minuto o 1/600 de 
grado, tal y como se describe en el apéndice 1 para el tipo 
GeoCoordinates.  
La VU puede utilizar el comando GPS DOP y satélites 
activos (GSA), conforme a la norma NMEA V4.11, para de­
terminar y registrar la disponibilidad de la señal y la exactit ud 
de las posiciones estándar. En concreto, la dilución horizontal  
de la precisión (HDOP) se emplea para facilitar una indicación 
del nivel de exactitud de los datos de localización registrados  
(véase el punto 4.2.2). La VU almacenará el valor de la 
HDOP calculado como el mínimo de los valores HDOP reco­
gidos en los sistemas GNSS disponibles.  
El identificador GNSS indica el identificador NMEA corres­
pondiente a cada constelación GNSS y a cada sistema de 
aumentación basado en satélites (SBAS,  Satellite-Based Aug ­
mentation System ). 
Gráfico 4  
Estructura de la secuencia GSA (posiciones estándar)
  
$–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) Modo de selección  
2) Modo  
3) Identificador del primer satélite utilizado para la posición  definida  
4) Identificador del segundo satélite utilizado para la posició n definida  
… 
14) Identificador del duodécimo satélite utilizado para la posi ción definida  
15) PDOP  
16) HDOP  
17) VDOP  
18) Identificador del sistema  
19) Suma de control  
El identificador del sistema es opcional y puede no estar 
presente en la secuencia GSA.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 509  
Igualmente, la VU puede utilizar la secuencia similar a 
NMEA «comando de satélites activos autenticados» (ASA,  
authenticated active satellites ) para determinar y registrar la 
disponibilidad de la señal y la exactitud de las posiciones 
autenticadas. Los valores 1 a 18 se definen en la norma 
NMEA V4.11.  
Gráfico 5  
Estructura de la secuencia ASA (posiciones autenticadas)
  
$–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) Modo de selección  
2) Modo  
3) Identificador del primer satélite utilizado para la posición  definida  
4) Identificador del segundo satélite utilizado para la posició n definida  
… 
14) Identificador del duodécimo satélite utilizado para la posi ción definida  
15) PDOP  
16) HDOP  
17) VDOP  
18) Identificador del sistema  
19) Suma de control  
El identificador del sistema es opcional y puede no estar 
presente en la secuencia ASA.  
GNS_6 Cuando se utilice un dispositivo GNSS externo, la secuenc ia 
GSA se almacenará en el transceptor seguro GNSS con los 
números de registro «02» a «06», y la secuencia ASA se 
almacenará con los números de registro «12» a «16».  
GNS_7 El tamaño máximo de las secuencias (por ejemplo, RMC, 
AMC, GSA, ASA u otras) que pueden emplearse para medir 
el comando de lectura del registro será de 85 bytes (véase la 
tabla 1).  
▼B 
4. UNIDAD INSTALADA EN EL VEHÍCULO CON DISPOSITIVO 
GNSS EXTERNO  
4.1. Configuración  
4.1.1  Principales componentes e interfaces  
En esta configuración, el receptor GNSS forma parte de un dispo sitivo 
GNSS externo.  
GNS_8 Dicho dispositivo debe disponer de una interfaz vehicular  
específica.  
▼M3 
GNS_9 El dispositivo GNSS externo estará formado por los si­
guientes componentes (véase el gráfico 6):  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 510  
a) Un receptor GNSS comercial que facilite los datos de 
posición a través de la interfaz de datos GNSS. Por 
ejemplo, la interfaz de datos GNSS puede corresponder 
a la norma NMEA V4.11, de modo que el receptor 
GNSS actúe como emisor y transmita secuencias 
NMEA al transceptor seguro GNSS con una frecuencia 
de 1 Hz para el conjunto predefinido de secuencias 
NMEA y similares a NMEA, que debe incluir al menos 
las secuencias RMC, AMC, GSA y ASA. Serán los 
fabricantes del dispositivo GNSS externo quienes deci­
dan aplicar la interfaz de datos GNSS.  
▼B 
b) Una unidad transmisora receptora (transceptor seguro 
GNSS) con capacidad para respetar la norma ISO/IEC 
7816-4:2013 (véase el apartado 4.2.1), comunicarse con 
la unidad instalada en el vehículo y admitir la interfaz de 
transferencia de datos GNSS al receptor GNSS. La uni­
dad dispone de una memoria para almacenar los datos 
identificativos del receptor GNSS y del dispositivo 
GNSS externo.  
▼M3 
c) Un sistema de cierre con un detector de manipulaciones 
que incluya tanto el receptor GNSS como el transceptor 
seguro GNSS. El detector de manipulaciones deberá 
aplicar las medidas de protección de la seguridad soli­
citadas en el perfil de protección del tacógrafo inteli­
gente.  
▼B 
d) Una antena GNSS instalada en el vehículo y conectada 
al receptor GNSS mediante el sistema de cierre.  
GNS_10 El dispositivo GNSS externo tiene al menos las siguiente s 
interfaces externas:  
a) la interfaz de la antena GNSS instalada en el maletero 
del vehículo, en caso de que se utilice una antena ex­
terna; y  
b) la interfaz de la unidad instalada en el vehículo.  
GNS_11 En la unidad instalada en el vehículo, el transceptor se guro 
de la VU es el otro fin de la comunicación segura con el 
transceptor seguro del GNSS, y debe respetar la norma 
ISO/IEC 7816-4:2013 para la conexión con el dispositivo 
GNSS externo.  
GNS_12 Para el nivel físico de la comunicación con el dispositi vo 
GNSS externo, la unidad instalada en el vehículo respetará 
la norma ISO/IEC 7816-12:2005 y otras normas que respe­
ten la ISO/IEC 7816-4:2013. (véase el apartado 4.2.1).  
4.1.2  Estado del dispositivo GNSS externo al final de la producción  
GNS_13 El dispositivo GNSS externo deberá almacenar los siguien ­
tes valores en la memoria permanente del transceptor se­
guro del GNSS cuando salga de la fábrica:  
— la pareja de claves EGF_MA y el certificado correspon­
diente;  
— el certificado MSCA_VU-EGF que contenga la clave 
pública MSCA_VU-EGF.PK que se utilizará para veri­
ficar el certificado EGF_MA;  
— el certificado EUR que contenga la clave pública 
EUR.PK que se utilizará para verificar el certificado 
MSCA_VU-EGF;  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 511  
— el certificado EUR cuyo período de validez finalice 
exactamente antes del período de validez 
del certificado EUR empleado para verificar el certifi­
cado MSCA_VU-EGF, en caso de que exista;  
— el certificado de enlace que vincule estos dos 
certificados EUR, en caso de que exista;  
— el número de serie ampliado del dispositivo GNSS 
externo;  
— el identificador del sistema operativo del dispositivo 
GNSS;  
— el número de homologación del dispositivo GNSS ex­
terno; y  
— el identificador del componente de seguridad del mó­
dulo GNSS externo.  
4.2. Comunicación entre el dispositivo GNSS externo y la unidad ins ­
talada en el vehículo  
4.2.1  Protocolo de comunicación  
▼M3 
GNS_14 El protocolo de comunicación entre el dispositivo GNSS 
externo y la unidad instalada en el vehículo deberá admitir 
las siguientes funciones:  
1. recogida y distribución de datos GNSS (por ejemplo, 
posición, hora y velocidad);  
2. recogida de los datos de configuración del dispositivo 
GNSS externo;  
3. protocolo de administración para admitir el acopla­
miento, la autenticación mutua y el acuerdo de la clave 
de la sesión entre el dispositivo GNSS externo y la VU;  
4. transmisión al dispositivo GNSS externo de la hora del 
RTC de la VU y de la diferencia máxima entre la hora 
verdadera y la hora del RTC de la VU.  
▼B 
GNS_15 El protocolo de comunicación se basará en la norma ISO/ 
IEC 7816-4:2013, de modo que el transceptor seguro de la 
VU actuará como maestro y el transceptor seguro GNSS 
como esclavo. La conexión física entre el dispositivo GNSS 
externo y la unidad instalada en el vehículo se basa en la 
norma ISO/IEC 7816-12:2005 y en otras normas que res­
peten la norma ISO/IEC 7816-4:2013.  
▼M3 
GNS_16 En el protocolo de comunicación no se admitirán campos 
de longitud ampliada.  
▼B 
GNS_17 El protocolo de comunicación de la norma ISO 7816 (tanto  
*-4:2013 como *-12:2005) entre el dispositivo GNSS ex­
terno y la VU se configurará en T=1.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 512  
GNS_18 Para las funciones 1 (recogida y distribución de datos 
GNSS), 2 (recogida de los datos de configuración del dis­
positivo GNSS externo) y 3 (protocolo de administración), 
el transceptor seguro GNSS simulará una tarjeta inteligente 
con una arquitectura de archivos del sistema formada por: 
un archivo principal (MF); un archivo dedicado (DF) con el 
identificador de aplicación especificado en el apéndice 1, 
apartado 6.2 («FF 44 54 45 47 4D») y con tres EF que 
contengan certificados; y un archivo elemental único 
(EF.EGF) con el identificador igual a «2F2F», tal y como 
se describe en la tabla 1.  
▼M3 
GNS_18a En relación con la función 4, «transmisión al dispositi vo 
GNSS externo de la hora del RTC de la VU y de la dife­
rencia máxima entre la hora verdadera y la hora del RTC de 
la VU», el transceptor seguro GNSS utilizará un EF (EF 
VU) en el mismo DF con un identificador de archivo igual 
a «2F30», según se indica en la tabla 1.  
▼B 
GNS_19 El transceptor seguro GNSS almacenará los datos proceden ­
tes del receptor GNSS y la configuración en el EF.EGF. Se 
trata de un archivo de registro lineal y de longitud variable 
cuyo identificador es «2F2F» en formato hexadecimal.  
▼M3 
GNS_19a El transceptor seguro GNSS almacenará los datos procede n­
tes de la VU en el EF VU. Se trata de un archivo de 
registro lineal de longitud fija con un identificador igual a 
«2F30» en formato hexadecimal.  
GNS_20 El transceptor seguro GNSS utilizará una memoria para 
almacenar los datos y podrá realizar tantos ciclos de lectura/ 
escritura como sean necesarios durante una vida útil de por 
lo menos quince años. A excepción de este elemento, el 
diseño interno y la aplicación del transceptor seguro GNSS 
queda en manos de los fabricantes.  
▼M1 
El mapeado de los números de registro y de los datos se 
detalla en la tabla 1. Cabe señalarse que hay cinco secuen­
cias GSA para los sistemas satélite y el sistema de aumen­
tación basado en satélites (SBAS).  
▼B 
GNS_21 La Tabla 1 recoge la estructura de los archivos. Para la s 
condiciones de acceso (ALW, NEV, SM-MAC), véase el 
apéndice 2, apartado 3.5.  
▼M3 
Tabla 1  
Estructura de los archivos  
Condiciones de acceso  
Archivo  Identificador 
del archivo  Lectura  Actualización  Cifrado  
MF 3F00  
EF.ICC  0002  ALW  NEV 
(por parte de la 
VU) N. o ▼M1
 02016R0799 — ES — 21.08.2023 — 003.001 — 513  
Condiciones de acceso  
Archivo  Identificador 
del archivo  Lectura  Actualización  Cifrado  
DF GNSS Facility  0501  ALW  NEV  N .  o 
EF EGF_MACertificate  C100  ALW  NEV  N .  o 
EF CA_Certificate  C108  ALW  NEV  N .  o 
EF Link_Certificate  C109  ALW  NEV  N .  o 
EF EGF  2F2F  SM-MAC  NEV 
(por parte de la 
VU) N. o 
EF VU  2F30  SM-MAC  SM-MAC  N .  o 
Archivo / Elemento de datos  N. o de regis­
tro Tamaño (bytes)  Valores por 
defecto  
Mín.  Máx.  
MF 552  1031  
EF.ICC  
sensorGNSSSerialNumber  8  8  
DF GNSS Facility  612  1 023  
EF EGF_MACertificate  204  341  
EGFCertificate  204  341  {00..00}  
EF CA_Certificate  204  341  
MemberStateCertificate  204  341  {00..00}  
EF Link_Certificate  204  341  
LinkCertificate  204  341  {00..00}  
EF EGF  
Secuencia RMC NMEA  '01'  8 5  8 5  
Primera secuencia GSA NMEA  '02'  8 5  8 5  
Segunda secuencia GSA NMEA  '03'  8 5  8 5  
Tercera secuencia GSA NMEA  '04'  8 5  8 5  
Cuarta secuencia GSA NMEA  '05'  8 5  8 5  
Quinta secuencia GSA NMEA  '06'  8 5  8 5  
Número de serie ampliado del dispo­
sitivo GNSS externo definido en el 
apéndice 1 como SensorGNSSSerial­
Number.  '07' 8  8  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 514  
Archivo / Elemento de datos  N. o de regis­
tro Tamaño (bytes)  Valores por 
defecto  
Identificador del sistema operativo del 
transceptor seguro GNSS definido en 
el apéndice 1 como SensorOSIdenti­
fier. '08' 2  2  
Número de homologación del disposi­
tivo GNSS externo definido en el 
apéndice 1 como SensorExternalGNS­
SApprovalNumber.  '09' 1 6  1 6  
Identificador del componente de segu­
ridad del dispositivo GNSS externo 
definido en el apéndice 1 como Sen­
sorExternalGNSSSCIdentifier.  '10' 8  8  
Secuencia AMC  '11'  8 5  8 5  
Primera secuencia ASA  '12'  8 5  8 5  
Segunda secuencia ASA  '13'  8 5  8 5  
Tercera secuencia ASA  '14'  8 5  8 5  
Cuarta secuencia ASA  '15'  8 5  8 5  
Quinta secuencia ASA  '16'  8 5  8 5  
RFU: reservado para futuros usos.  De '17' a 
'FD' 
EF VU  
VuRtcTime (véase el apéndice 1)  '01'  4  4  {00..00}  
VuGnssMaximalTimeDifference (véase el 
apéndice 1)  '02' 2  2  {00..00}  
▼B 
4.2.2  Transferencia segura de datos GNSS  
▼M3 
GNS_22 La transferencia segura de los datos de posición GNSS, l a 
hora del RTC de la VU y la diferencia horaria máxima 
entre la hora verdadera y la hora del RTC de la VU se 
permitirá únicamente en las siguientes condiciones:  
▼B 
1. si se ha llevado a cabo el proceso de acoplamiento tal y 
como se describe en el apéndice 11 (Mecanismos de 
seguridad comunes); y  
2. si se han realizado con la frecuencia prevista la autenti­
cación mutua periódica y el acuerdo de la clave de la 
sesión entre la VU y el dispositivo GNSS externo tam­
bién descritos en el apéndice 11 (Mecanismos de segu­
ridad comunes).  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 515  
GNS_23 Cada T segundos, siendo T un valor igual o inferior a 20 , a 
menos que se estén realizando el acoplamiento, la autenti­
cación mutua o el acuerdo de las claves de sesión, la VU 
solicita al dispositivo GNSS externo información de posi­
ción mediante el siguiente proceso:  
1. La VU solicita al dispositivo GNSS externo datos de 
posición y datos sobre la dilución de precisión (de las 
secuencias GSA y ASA). El transceptor seguro de la VU 
utilizará los comandos SELECT (seleccionar) y READ 
RECORD(S) (leer registros) de la ISO/IEC 7816-4:2013 
en el modo de solo autenticación de mensajería segura 
según se describe en el punto 11.5 del apéndice 11, con 
el identificador de archivo «2F2F» y el número de regis­
tro igual a «01» para la secuencia RMC NMEA, «02», 
«03», «04», «05», «06» para la secuencia GSA NMEA, 
«11» para la secuencia AMC, y «12», «13», «14», «15», 
«16» para la secuencia ASA.  
2. Los últimos datos de posición recibidos se almacenan en 
el EF con el identificador «2F2F», y los registros des­
critos en la tabla 1 en el transceptor seguro GNSS, 
puesto que el transceptor seguro GNSS recibe del recep­
tor GNSS datos NMEA con una frecuencia de al menos 
1 Hz a través de la interfaz de datos GNSS.  
3. El transceptor seguro GNSS envía la respuesta al trans­
ceptor seguro de la VU utilizando un mensaje de res­
puesta APDU en el modo de solo autenticación de men­
sajería segura, según se describe en el punto 11.5 del 
apéndice 11.  
4. El transceptor seguro de la VU comprueba la autentici­
dad y la integridad de la respuesta recibida. En caso de 
que el resultado sea positivo, se transfieren los datos de 
posición al procesador de la VU a través de la interfaz 
de datos GNSS.  
5. El procesador de la VU comprueba los datos recibidos 
extrayendo la información (por ejemplo, latitud, longitud 
u hora) de la secuencia RMC NMEA. La secuencia 
RMC NMEA incluye la información si la posición no 
autenticada es válida. Si la posición no autenticada es 
válida, el procesador de la VU también extrae los valo­
res de HDOP de las secuencias GSA NMEA y calcula el 
valor mínimo con los sistemas de satélite disponibles (es 
decir, cuando se dispone de una posición definida).  
6. El procesador de la VU extrae asimismo la información 
(por ejemplo, latitud, longitud u hora) de la secuencia 
AMC. La secuencia AMC incluye la información si la 
posición autenticada no es válida o la señal GNSS ha 
sufrido un ataque. Si la posición es válida, el procesador 
de la VU también extrae los valores de HDOP de las 
secuencias ASA y calcula el valor mínimo con los sis­
temas de satélite disponibles (es decir, cuando se dis­
pone de una posición definida).  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 516  
GNS_23a La VU escribirá también la hora de su RTC y la diferenc ia 
horaria máxima entre la hora verdadera y la hora de su 
RTC según sea necesario, utilizando los comandos SE­
LECT (seleccionar) y WRITE RECORD(S) (escribir regis­
tros) de la ISO/IEC 7816-4:2013 en el modo de solo au­
tenticación de mensajería segura según se describe en el 
punto 11.5 del apéndice 11, con el identificador de archivo 
«2F30» y el número de registro igual a «01» para VuRtc­
Time y «02» para MaximalTimeDifference.  
▼B 
4.2.3  Estructura del comando de lectura del registro  
En la presente sección se detalla la estructura del comando de lectura 
del registro (Read Record). Se incluye la mensajería segura (mo do de 
solo autenticación) descrita en el apéndice 11 (Mecanismos de s egu­
ridad comunes).  
GNS_24 El comando admitirá el modo de solo autenticación de 
mensajería segura, véase el apéndice 11.  
GNS_25 Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  0Ch  Se pide mensajería segura  
INS 1  B2h  Lectura del registro  
P1 1  XXh  Número de registro («00» se refiere al 
registro actual)  
P2 1  04h  Lectura del registro con el número de 
registro indicado en P1  
Le 1  XXh  Longitud de datos esperada. Número de 
bytes que se deben leer.  
GNS_26 El registro con referencia P1 se convierte en el registr o 
actual.  
Byte  Longitud  Valor  Descripción  
N o 1- n  o X X  XX..XXh  Datos leídos  
SW 2  XXXXh  Palabras de estado (SW1,SW2)  
— Si el comando se ejecuta correctamente, el transceptor 
seguro GNSS contesta con el estado  «9000» . 
— Si el archivo actual no está destinado al registro, el 
transceptor seguro GNSS contesta con el estado  
«6981» . 
— Si se utiliza el comando con P1=00 pero no se dispone 
de EF, el transceptor seguro GNSS contesta con el es­
tado «6986»  (comando no permitido).  
▼M3 
— Si no se localiza el registro, el transceptor seguro GNSS 
contesta con el estado «6A83».  
— Si el dispositivo GNSS externo detecta manipulación, 
contestará con el estado «6690»;  
__________  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 517  
4.2.4 Estructura del comando WriteRecord  
En este punto se detalla la estructura del comando Write Record  
(escribir registro). Se incluye la mensajería segura (modo de s olo 
autenticación) descrita en el apéndice 11, «Mecanismos de segur idad 
comunes».  
GNS_26a El comando admitirá el modo de solo autenticación de 
mensajería segura, véase el apéndice 11.  
GNS_26b Mensaje de comando  
Byte  Longitud  Valor  Descripción  
CLA  1  «0Ch»  Se pide mensajería segura  
INS 1  «D2h»  Escribir registro  
P1 1  «XXh»  Número de registro («00» se refiere al 
registro actual)  
P2 1  «04h»  Escribir el registro con el número de 
registro indicado en P1  
Datos  X  «XXh»  Datos  
GNS_26c El registro con referencia P1 se convierte en el regist ro 
actual.  
Byte  Longitud  Valor  Descripción  
SW 2  «XXXXh»  Palabras de estado (SW1, SW2)  
— Si el comando se ejecuta correctamente, el transceptor 
seguro GNSS contesta con el estado « 9000 ». 
— Si el archivo actual no está destinado al registro, el 
transceptor seguro GNSS contesta con el estado 
«6981 ». 
— Si se utiliza el comando con P1 = «00» pero no se 
dispone de EF, el transceptor seguro GNSS contesta 
con el estado « 6986 » (comando no permitido).  
— Si no se localiza el registro, el transceptor seguro 
GNSS contesta con el estado « 6A83 ». 
— Si el dispositivo GNSS externo detecta manipulación, 
contestará con el estado « 6690 ». 
4.2.5  Otros comandos  
GNS_27 El transceptor seguro GNSS admitirá los siguientes coman ­
dos de tacógrafo de segunda generación especificados en el 
apéndice 2:  
Comando  Referencia  
Select (seleccionar)  Apéndice 2, punto 3.5.1  
Read Binary (leer archivo binario)  Apéndice 2, punto 3.5.2  
Get Challenge (obtener interrogación)  Apéndice 2, punto 3.5.4  
PSO: Verify Certificate (verificar 
certificado)  Apéndice 2, punto 3.5.7  
External Authenticate (autenticación 
externa)  Apéndice 2, punto 3.5.9  
General Authenticate (autenticación 
general)  Apéndice 2, punto 3.5.10  
MSE:SET  Apéndice 2, punto 3.5.11  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 518  
4.3. Acoplamiento, autenticación mutua y acuerdo de la clave de la 
sesión entre el dispositivo GNSS externo y la unidad instalada 
en el vehículo  
El acoplamiento, la autenticación mutua y el acuerdo de la clav e de la 
sesión entre el dispositivo GNSS externo y la unidad instalada en el 
vehículo se describen en el apéndice 11 (Mecanismos de segurida d 
comunes), apartado 11.  
4.4. Gestión de errores  
En la presente sección se explica cómo se gestionan y se regist ran en 
la VU los posibles errores del dispositivo GNSS externo.  
4.4.1  Error de comunicación con el dispositivo GNSS externo  
▼M3 
GNS_28 En la VU se registrará un incidente de error de comunica ­
ción con el dispositivo GNSS externo, según se define en 
el requisito 82 del anexo I C y el apéndice 1 (Event­
FaultType). En este contexto, se activa un error de comu­
nicación cuando el transceptor seguro de la VU no recibe 
ningún mensaje de respuesta tras un mensaje de petición 
enviado según se describe en el punto 4.2.  
▼B 
4.4.2  Manipulación de la integridad física del dispositivo GNSS externo  
▼M3 
GNS_29 Si se ha manipulado el dispositivo GNSS externo, el tran s­
ceptor seguro GNSS garantizará la indisponibilidad del 
material criptográfico. Tal y como se describe en GNS_25 
y en GNS_26, la VU detectará la manipulación si la res­
puesta tiene el estado «6690». La VU generará y registrará 
entonces un incidente de intento de violación de la segu­
ridad, según se define en el requisito 85 del anexo I C y el 
apéndice 1 (EventFaultType correspondiente a detección de 
manipulación del GNSS). Alternativamente, el dispositivo 
GNSS externo podrá responder a las peticiones de la VU 
sin mensajería segura y con el estado «6A88».  
▼B 
4.4.3  Ausencia de información de posición del receptor GNSS  
▼M3 
GNS_30 Si el transceptor seguro GNSS no recibe datos del recept or 
GNSS, generará un mensaje de respuesta al comando 
READ RECORD (leer registro) con el número de registro 
igual a «01» y con un campo de datos de 12 bytes, todos 
ellos fijados en 0xFF. Una vez recibido este mensaje de 
respuesta con este valor del campo de datos, la VU gene­
rará y registrará un incidente de ausencia de información 
sobre la posición procedente del receptor GNSS, según se 
define en el requisito 81 del anexo I C y el apéndice 1 
(EventFaultType).  
▼B 
4.4.4  Certificado del dispositivo GNSS externo expirado  
▼M3 
GNS_31 Si la VU detecta que el certificado EGF empleado para la s 
autenticaciones mutuas ya no es válido, generará y regis­
trará un incidente de intento de violación de la seguridad, 
según se define en el requisito 85 del anexo I C y el 
apéndice 1 (EventFaultType correspondiente a certificado 
del dispositivo GNSS externo expirado). La VU seguirá 
utilizando los datos GNSS de posición recibidos.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 519  
Gráfico 6  
Esquema del dispositivo GNSS externo  
▼B
 
5. UNIDAD INSTALADA EN EL VEHÍCULO SIN DISPOSITIVO 
GNSS EXTERNO  
5.1. Configuración  
En esta configuración, el receptor GNSS se encuentra dentro de la 
unidad instalada en el vehículo, tal y como se refleja en el Gr áfico 1.  
▼M3 
GNS_32 Para transmitir la posición, la DOP y los datos de los 
satélites, el receptor GNSS actuará como emisor y trans­
mitirá secuencias NMEA o similares a NMEA al procesa­
dor de la VU, que actuará como receptor con una frecuen­
cia de 1/10 Hz o superior para el conjunto predefinido de 
secuencias, que deberá incluir al menos las secuencias 
RMC, GSA, AMC y ASA. Alternativamente, el procesador 
de la VU y el receptor GNSS interno podrán utilizar otros 
formatos de datos para intercambiar los datos contenidos en 
las secuencias NMEA o similares a NMEA especificadas 
en GNS_4, GNS_4a y GNS_5.  
▼B 
GNS_33 Se conectará a la VU una antena GNSS externa instalada 
en el vehículo o una antena GNSS interna.  
▼M3 
5.2. Transferencia de información del receptor GNSS a la VU  
GNS_34 El procesador de la VU comprueba los datos recibidos 
extrayendo la información (por ejemplo, latitud, longitud 
u hora) de la secuencia RMC NMEA y la secuencia AMC.  
GNS_35 La secuencia RMC NMEA incluye la información si la 
posición no autenticada es válida. Si la posición no auten­
ticada no es válida, los datos de posición no están disponi­
bles ni pueden emplearse para registrar la posición del 
vehículo. Si la posición no autenticada es válida, el proce­
sador de la VU extrae también los valores de HDOP de la 
GSA NMEA.  
GNS_36 El procesador de la VU extrae asimismo la información 
(por ejemplo, latitud, longitud u hora) de la secuencia 
AMC. La secuencia AMC incluye la información si la 
posición no autenticada es válida conforme a GNS_4a. Si 
la posición no autenticada es válida, el procesador de la 
VU extrae también los valores de HDOP de las secuencias 
ASA.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 520  
5.3. Transferencia de información de la VU al receptor GNSS  
GNS_37 El procesador de la VU proporciona al receptor GNSS la 
hora del RTC de la VU y la diferencia máxima entre la 
hora verdadera y la hora del RTC de la VU, conforme a 
GNS_3f y GNS_3g.  
5.4. Gestión de errores  
5.4.1 Ausencia de información sobre la posición procedente del receptor 
GNSS  
GNS_38 La VU generará y registrará un incidente de ausencia de 
información sobre la posición procedente del receptor 
GNSS, según se define en el requisito 81 del anexo I C 
y el apéndice 1 (EventFaultType).  
6. PROCESAMIENTO Y REGISTRO DE LOS DATOS DE POSICIÓN 
POR LA VU  
Este punto es aplicable tanto a la configuración de tacógrafo i nteli­
gente con dispositivo GNSS externo como sin él.  
GNS_39 Los datos de posición se almacenarán en la VU junto con 
un indicador que señale si la posición ha sido autenticada. 
Cuando haya que registrar los datos de posición en la VU, 
se aplicarán las siguientes reglas:  
a) Si tanto la posición autenticada como la estándar son 
válidas y coherentes, se registrarán en la VU la posición 
estándar y su exactitud, y el indicador se ajustará en 
«autenticada».  
b) Si la posición autenticada y la posición estándar son 
válidas, pero no coherentes, la VU almacenará la posi­
ción autenticada y su exactitud, y el indicador se ajus­
tará en «autenticada».  
c) Si la posición autenticada es válida y la posición están­
dar no lo es, la VU registrará la posición autenticada y 
su exactitud, y el indicador se ajustará en «autenticada».  
d) Si la posición estándar es válida y la posición autenti­
cada no lo es, la VU registrará la posición estándar y su 
exactitud, y el indicador se ajustará en «no autenticada».  
Se considera que la posición autenticada y la posición es­
tándar son coherentes, como se muestra en el gráfico 7, 
cuando la posición autenticada horizontal puede encontrarse 
en un círculo cuyo centro es la posición estándar horizontal 
y cuyo radio resulta de redondear al entero superior más 
próximo el valor R_H calculado con la siguiente fórmula: 
R_H = 1,74 • σ  UERE  • HDOP  
donde:  
— coherencia entre las posiciones estándar y autenticada. - 
R_H es el radio relativo de un círculo en torno a la 
posición horizontal estimada, en metros. Es un indica­
dor que se utiliza para comprobar la  
— en cuestión, incluidos los entornos urbanos. Se utilizará 
un valor constante de σ  UERE  es la desviación estándar 
del error equivalente en distancia al usuario (UERE,  
user equivalent range error ), que modeliza todos los 
errores de medición de la aplicación σ  UERE  = 10 metros.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 521  
— HDOP es la dilución de precisión horizontal calculada 
por el receptor GNSS.  
— σ  UERE  . HDOP es la estimación de la raíz del error 
cuadrático medio en la horizontal.  
Gráfico 7  
Posiciones autenticada y estándar (no autenticada) coherentes
  
GNS_40 Cuando el valor del estado en una secuencia AMC recibida  
sea «J», «O» o «F» conforme al requisito GNS_4a, la VU 
generará y registrará un incidente de anomalía del GNSS, 
según se define en el requisito 88  bis del anexo I C y el 
apéndice 1 (EventFaultType). La unidad instalada en el 
vehículo podrá efectuar comprobaciones adicionales antes 
de almacenar un incidente de anomalía del GNSS tras 
recibir un estado «J» u «O».  
7. CONFLICTO TEMPORAL DEL GNSS  
GNS_41 Si la VU detecta una discrepancia entre la hora de su 
función de medición de la hora y la hora procedente de 
las señales GNSS, generará y registrará un incidente de 
conflicto temporal, según se define en el requisito 86 del 
anexo I C y el apéndice 1 (EventFaultType).  
8. CONFLICTO DE MOVIMIENTO DEL VEHÍCULO  
GNS_42 La VU activará y registrará un incidente de conflicto de  
movimiento del vehículo conforme al requisito 84 del 
anexo I C si la información de movimiento calculada a 
partir del sensor de movimiento no coincide con la infor­
mación de movimiento calculada a partir del receptor 
GNSS interno, el dispositivo GNSS externo u otra fuente 
independiente de información de movimiento conforme al 
requisito 26 del anexo I C.  
El incidente de conflicto de movimiento del vehículo se 
activará cuando se dé una de las siguientes condiciones de 
activación:  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 522  
Condición de activación 1:  
Se utilizará la media recortada de las diferencias de velo­
cidad entre estas fuentes cuando esté disponible la infor­
mación de posición procedente del receptor GNSS y 
cuando el encendido del vehículo esté activado, como se 
especifica a continuación:  
— cada diez segundos como máximo, se calculará el valor 
absoluto de la diferencia entre la velocidad del vehículo 
estimada a partir del GNSS y la estimada a partir del 
sensor de movimiento;  
— para calcular la media recortada se utilizarán todos los 
valores computados en un intervalo de tiempo que in­
cluya los últimos cinco minutos de movimiento del 
vehículo;  
— la media recortada se computará como el promedio del 
80 % de los valores restantes, después de haberse eli­
minado los más elevados en valores absolutos.  
El incidente de conflicto de movimiento del vehículo se 
activará si la media recortada es superior a 10 km/hora 
durante cinco minutos seguidos en los que el vehículo 
esté en movimiento. (Nota: (con el empleo de la media 
recortada de los últimos cinco minutos se pretende mitigar 
el riesgo de obtener mediciones discrepantes y valores tran­
sitorios).  
Para computar la media recortada, se considerará que el 
vehículo está en movimiento si por lo menos uno de los 
valores de su velocidad estimado a partir del sensor de 
movimiento o del receptor GNSS no es igual a cero.  
Condición de activación 2:  
El incidente de conflicto de movimiento del vehículo tam­
bién se activará si se da la siguiente condición:  
DistanciaGnss >[DiferenciaCuentakilómetros ×FactorTole ­
ranciaCuentakilómetros +Mínimo  (LímiteSuperiorDistancia ­
Deslizamiento ;(DiferenciaCuentakilómetros ×FactorDesliza ­
miento ))+ToleranciaGnss +DistanciaTransbordadorTren ] 
donde:  
— DistanciaGnss  es la distancia entre la posición actual 
del vehículo y la anterior, obtenidas ambas a partir de 
mensajes de posición autenticados válidos, sin conside­
rar la altura,  
— DiferenciaCuentakilómetros  es la diferencia entre el 
valor actual del cuentakilómetros y el valor del cuen­
takilómetros correspondiente al mensaje de posición 
autenticado válido anterior,  
— FactorToleranciaCuentakilómetros  es igual a 1,1 (fac­
tor de tolerancia del caso más desfavorable para todas 
las tolerancias de medición del cuentakilómetros del 
vehículo),  
— ToleranciaGnss  es igual a 1 km (caso más desfavorable 
de la tolerancia del GNSS),  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 523  
— Mínimo (LímiteSuperiorDistanciaDeslizamiento; (Dife ­
renciaCuentakilómetros * FactorDeslizamiento))  es el 
valor mínimo entre:  
— LímiteSuperiorDistanciaDeslizamiento , que es igual 
a 10 km (límite superior de la distancia de desliza­
miento causada por los efectos de deslizamiento 
durante el frenado),  
— y  DiferenciaCuentakilómetros * FactorDesliza ­
miento , donde FactorDeslizamiento es igual a 0,2 
(influencia máxima de los efectos de deslizamiento 
durante el frenado),  
— DistanciaTransbordadorTren  se computa como: Dis­
tanciaTransbordadorTren =200 km/h * tTransbordador­
Tren, donde tTransbordadorTren es la suma de la du­
ración en horas de los trayectos transbordador/tren en el 
intervalo de tiempo considerado. La duración de los 
trayectos transbordador/tren se define como la diferen­
cia horaria entre su indicador de final y su indicador de 
comienzo.  
Las verificaciones señaladas se realizarán cada quince mi­
nutos si están disponibles los datos de posición necesarios 
y, si no, tan pronto como estos estén disponibles.  
Con respecto a esta condición de activación:  
— la fecha y la hora de comienzo del incidente serán las 
mismas que aquellas en las que se recibió el mensaje 
de posición anterior,  
— la fecha y la hora de final del incidente serán las mis­
mas que aquellas en las que la condición comprobada 
vuelve a ser falsa.  
Condición de activación 3:  
La unidad instalada en el vehículo descubre una discrepan­
cia consistente en que el sensor de movimiento no detecta 
movimiento alguno y la fuente independiente de informa­
ción de movimiento detecta movimiento durante un pe­
ríodo determinado. El fabricante de la unidad instalada en 
el vehículo determinará las condiciones para registrar una 
discrepancia y el período de detección de esta, si bien la 
discrepancia deberá detectarse en no más de tres horas.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 524  
Apéndice 13  
INTERFAZ ITS  
ÍNDICE  
1. INTRODUCCIÓN  
1.1. Ámbito de aplicación  
1.2. Acrónimos y definiciones  
2. NORMAS DE REFERENCIA  
3. PRINCIPIOS DE FUNCIONAMIENTO DE LA INTERFAZ  
3.1. Tecnología de la comunicación  
3.2. Servicios disponibles  
3.3. Acceso a través de la interfaz ITS  
3.4. Datos disponibles y necesidad del consentimiento del condu ctor 
4. LISTA DE DATOS DISPONIBLES A TRAVÉS DE LA INTERFAZ ITS 
Y CLASIFICACIÓN PERSONAL / NO PERSONAL  
1. INTRODUCCIÓN  
1.1. Ámbito de aplicación  
ITS_01 En el presente apéndice se especifican los principios bá sicos de la 
comunicación a través de la interfaz del tacógrafo con los sist emas 
de transporte inteligentes (ITS), como exigen los artículos 10 y 11 
del Reglamento (UE) n.  o 165/2014.  
ITS_02 La interfaz ITS permitirá a los dispositivos externos ob tener datos 
del tacógrafo, utilizar los servicios de tacógrafo y proporcion ar 
datos al tacógrafo.  
Para ello podrán utilizarse también otras interfaces de tacógra fo 
(por ejemplo, bus CAN).  
El presente apéndice no especifica:  
— la manera en que los datos proporcionados a través de la in­
terfaz ITS se recogen y gestionan dentro del tacógrafo,  
— la forma de presentación de los datos recogidos a las aplica­
ciones alojadas en el dispositivo externo,  
— la especificación de seguridad ITS, además de lo que propor­
ciona Bluetooth®,  
— los procolos Bluetooth® usados por la interfaz ITS.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 525  
1.2. Acrónimos y definiciones  
En este apéndice se utilizan específicamente los acrónimos y la s definiciones 
siguientes:  
GNSS  Global Navigation Satellite System  (sistema mundial de na­
vegación por satélite  
ITS Intelligent Transport System  (sistema de transporte inteli­
gente)  
OSI Open Systems Interconnection  (interconexión de sistemas 
abiertos )  
VU Vehicle Unit  (unidad instalada en el vehículo)  
Unidad ITS  Dispositivo o aplicación externos que utilizan la interfaz 
ITS de la VU.  
2. NORMAS DE REFERENCIA  
ITS_03 El presente apéndice se remite a las siguientes reglamen taciones y 
normas y depende de ellas o de partes de ellas. En las cláusula s del 
presente apéndice se hace referencia a las normas pertinentes o  a  
las cláusulas pertinentes de las normas. En caso de contradicci ón, 
prevalecerán las cláusulas del presente apéndice.  
Las normas a las que se refiere el presente apéndice son:  
— Bluetooth®, versión básica 5.0.  
— ISO 16844-7: Vehículos de carretera. Sistemas de tacógrafo. 
Parte 7: Parámetros  
— ISO/IEC7498-1:1994: Tecnologías de la información. Interco­
nexión de sistemas abiertos. Modelo de referencia básico, mo­
delo básico  
3. PRINCIPIOS DE FUNCIONAMIENTO DE LA INTERFAZ ITS  
ITS_04 La VU deberá mantener actualizados y conservar los datos  del 
tacógrafo transmitidos a través de la interfaz ITS, sin partici pación 
de esta.  
3.1. Tecnología de la comunicación  
ITS_05 La comunicación a través de la interfaz ITS se efectuará  por la 
interfaz Bluetooth® y deberá ser compatible con Bluetooth® Low 
Energy (bajo consumo de energía) de conformidad con la versión 
5.0, o más reciente, de Bluetooth.  
ITS_06 La comunicación entre la VU y la unidad ITS se establece rá des­
pués de completarse el proceso de emparejamiento Bluetooth®.  
ITS_07 Entre la VU y la unidad ITS se establecerá una comunicac ión 
protegida y encriptada, de acuerdo con los mecanismos de la es­
pecificación Bluetooth®. El presente apéndice no especifica mec a­
nismos de encriptación ni de seguridad de otro tipo que se sume n a 
lo que proporciona Bluetooth®.  
ITS_08 Bluetooth® utiliza un modelo servidor-cliente para contr olar la 
transmisión de datos entre dispositivos, de modo que la VU será  
el servidor y la unidad ITS será el cliente.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 526  
3.2. Servicios disponibles  
ITS_09 Los datos que se transmitirán a través de la interfaz IT S de acuerdo 
con el punto 4 deberán estar disponibles a través de los servic ios 
especificados en el apéndice 7 y el apéndice 8. Además, la VU 
deberá poner a disposición de la unidad ITS los servicios que s on 
necesarios para la introducción manual de datos de conformidad 
con el requisito 61 del anexo I C y, opcionalmente, para la int ro­
ducción de otros datos en tiempo real.  
Figura 1.  
Distribución de la comunicación a través de la interfaz ITS de acuerdo con las capas del modelo OSI
  
ITS_10 Cuando la interfaz de transferencia se utilice a través del conector 
frontal, la VU no proporcionará los servicios de transferencia es­
pecificados en el apéndice 7 a través de la conexión ITS Blue­
tooth®.  
ITS_11 Cuando la interfaz de calibrado se utilice a través del conector 
frontal, la VU no proporcionará los servicios de calibrado espe ci­
ficados en el apéndice 8 a través de la conexión ITS Bluetooth® . 
3.3. Acceso a través de la interfaz ITS  
ITS_12 La interfaz ITS proporcionará un acceso inalámbrico a to dos los 
servicios especificados en los apéndices 7 y 8, en lugar de la 
conexión por cable al conector frontal para el calibrado y la t rans­
ferencia conforme al apéndice 6.  
ITS_13 La VU pondrá la interfaz ITS a disposición del usuario d e acuerdo 
con la combinación de tarjetas de tacógrafo válidas insertadas en la 
VU, según se indica en la tabla 1.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 527  
Tabla 1  
Disponibilidad de la interfaz ITS según el tipo de tarjeta insertada en el tacógrafo  
Disponibilidad de la interfaz 
ITS Ranura del conductor  
Sin tarjeta  Tarjeta de conduc­
tor Tarjeta de control  Tarjeta de taller  Tarjeta de empresa
 Ranura del segundo conductor Sin tarjeta  No disponible  Disponible  Disponible  Disponible  Disponible  
Tarjeta de con­
ductor  Disponible  Disponible  Disponible  Disponible  Disponible  
Tarjeta de con­
trol Disponible  Disponible  Disponible  No disponible  No disponible  
Tarjeta de taller  Disponible  Disponible  No disponible  Disponible  No disponible  
Tarjeta de em­
presa  Disponible  Disponible  No disponible  No disponible  Disponible  
ITS_14 Tras realizarse con éxito el emparejamiento ITS Bluetoot h®, la VU 
asignará la conexión ITS Bluetooth® a la tarjeta de tacógrafo 
insertada de acuerdo con la tabla 2:  
Tabla 2  
Asignación de la conexión ITS según el tipo de tarjeta insertada en el tacógrafo  
Asignación de la conexión 
ITS Bluetooth®  Ranura del conductor  
Sin tarjeta  Tarjeta de conduc­
tor Tarjeta de control  Tarjeta de taller  Tarjeta de empresa
 Ranura del segundo conductor Sin tarjeta  No disponible  Tarjeta de con­
ductor  Tarjeta de con­
trol Tarjeta de taller  Tarjeta de em­
presa  
Tarjeta de con­
ductor  Tarjeta de con­
ductor  Tarjeta de con­
ductor (**)  Tarjeta de con­
trol Tarjeta de taller  Tarjeta de em­
presa  
Tarjeta de con­
trol Tarjeta de con­
trol Tarjeta de con­
trol Tarjeta de con­
trol (*)  No disponible  No disponible  
Tarjeta de taller  Tarjeta de taller  Tarjeta de taller  No disponible  Tarjeta de ta­
ller (*)  No disponible  
Tarjeta de em­
presa  Tarjeta de em­
presa  Tarjeta de em­
presa  No disponible  No disponible  Tarjeta de em­
presa (*)  
(*) La conexión ITS Bluetooth® se asignará a la tarjeta de tacó grafo insertada en la ranura del conductor de la VU. 
(**) El usuario seleccionará la tarjeta a la que se asignará la  conexión ITS Bluetooth® (insertada en la ranura del conductor o del 
segundo conductor).  
ITS_15 Si se retira una tarjeta de tacógrafo, la VU terminará l a conexión 
ITS Bluetooth® asignada a esa tarjeta.  
ITS_16 La VU admitirá la conexión ITS por lo menos a una unidad  ITS y 
podrá admitir conexiones simultáneas a múltiples unidades ITS.  
ITS_17 Los derechos de acceso a los datos y los servicios dispo nibles a 
través de la interfaz ITS se ajustarán a los requisitos 12 y 13  del 
anexo I C, además del consentimiento del conductor especificado  
en el punto 3.4 del presente apéndice.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 528  
3.4. Datos disponibles y necesidad del consentimiento del conductor  
ITS_18 Todos los datos del tacógrafo disponibles a través de lo s servicios 
mencionados en el punto 3.3 se clasificarán como personales o 
como no personales con respecto al conductor, al segundo conduc ­
tor o a ambos.  
ITS_19 A través de la interfaz ITS deberán estar disponibles, c omo mí­
nimo, los datos clasificados como obligatorios en la lista del 
punto 4.  
ITS_20 Los datos del punto 4 clasificados como «personales» sol o serán 
accesibles con el consentimiento del conductor, que de esa mane ra 
aceptará que los datos personales puedan salir de la red del ve hí­
culo, salvo en el caso indicado en el requisito ITS_25, para el  que 
no será necesario el consentimiento del conductor.  
ITS_21 Los datos distintos a los que se recogen en el punto 4 y  conside­
rados obligatorios podrán estar disponibles a través de la inte rfaz 
ITS. Los datos adicionales no incluidos en el punto 4 serán cla si­
ficados como «personales» o «no personales» por el fabricante d e 
la VU, y el consentimiento del conductor se requerirá para los 
datos clasificados como personales, salvo en el caso indicado e n 
el requisito ITS_25, para el que no será necesario el consenti­
miento del conductor.  
ITS_22 Al insertar una tarjeta de conductor desconocida para la  unidad 
instalada en el vehículo, el tacógrafo pedirá al titular de la tarjeta 
que dé su consentimiento a la salida de datos personales a trav és 
de la interfaz ITS, de acuerdo con el requisito 61 del anexo I C. 
ITS_23 El estado del consentimiento (habilitado/inhabilitado) s e registrará 
en la memoria de datos de la unidad instalada en el vehículo.  
ITS_24 En el caso de varios conductores, solo serán accesibles a través de 
la interfaz ITS los datos personales relacionados con los condu c­
tores que hayan dado su consentimiento. Por ejemplo, en el caso  
de una situación en equipo, si solo ha dado su consentimiento e l 
conductor, los datos personales relacionados con el segundo con ­
ductor no serán accesibles.  
ITS_25 Cuando la VU esté en los modos de control, empresa o cal ibrado, 
los derechos de acceso a través de la interfaz ITS se gestionar án 
conforme a los requisitos 12 y 13 del anexo I C y, por tanto, n o 
será necesario el consentimiento del conductor.  
4. LISTA DE DATOS DISPONIBLES A TRAVÉS DE LA INTERFAZ ITS Y 
CLASIFICACIÓN PERSONAL / NO PERSONAL  
Nombre del dato  Formato del dato  Fuente  Clasificación del dato (personal / no 
personal)  Consentimiento a la 
disponibilidad del 
dato Disponibilidad  
conductor  segundo conductor  
VehicleIdentification­
Number  Apéndice 8  V U  no personal  no personal  no necesita con­
sentimiento  obligatorio  
CalibrationDate  ISO 16844-7  V U  no personal  no personal  no necesita con­
sentimiento  obligatorio  
TachographVehicleS­
peed  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  obligatorio  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 529  
Nombre del dato  Formato del dato  Fuente  Clasificación del dato (personal / no 
personal)  Consentimiento a la 
disponibilidad del 
dato Disponibilidad  
conductor  segundo conductor  
Driver1WorkingState  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  obligatorio  
Driver2WorkingState  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  obligatorio  
DriveRecognize  ISO 16844-7  V U  no personal  no personal  no necesita con­
sentimiento  obligatorio  
Driver1TimeRelatedS­
tates ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  obligatorio  
Driver2TimeRelatedS­
tates ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  obligatorio  
DriverCardDriver1  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  obligatorio  
DriverCardDriver2  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  obligatorio  
OverSpeed  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  obligatorio  
TimeDate  Apéndice 8  V U  no personal  no personal  no necesita con­
sentimiento  obligatorio  
HighResolutionTotal­
VehicleDistance  ISO 16844-7  V U  no personal  no personal  no necesita con­
sentimiento  obligatorio  
HighResolutionTrip­
Distance  ISO 16844-7  V U  no personal  no personal  no necesita con­
sentimiento  obligatorio  
ServiceComponentI­
dentification  ISO 16844-7  V U  no personal  no personal  no necesita con­
sentimiento  obligatorio  
ServiceDelayCalendar­
TimeBased  ISO 16844-7  V U  no personal  no personal  no necesita con­
sentimiento  obligatorio  
Driver1Identification  ISO 16844-7  Tar­
jeta 
de 
con­
duc­
tor personal  no aplicable  consentimiento 
del conductor  obligatorio  
Driver2Identification  ISO 16844-7  Tar­
jeta 
de 
con­
duc­
tor no aplicable  personal  consentimiento 
del segundo con­
ductor  obligatorio  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 530  
Nombre del dato  Formato del dato  Fuente  Clasificación del dato (personal / no 
personal)  Consentimiento a la 
disponibilidad del 
dato Disponibilidad  
conductor  segundo conductor  
NextCalibrationDate  Apéndice 8  V U  no personal  no personal  no necesita con­
sentimiento  obligatorio  
Driver1ContinuousDri­
vingTime  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  obligatorio  
Driver2ContinuousDri­
vingTime  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  obligatorio  
Driver1Cumulative­
BreakTime  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  obligatorio  
Driver2Cumulative­
BreakTime  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  obligatorio  
Driver1CurrentDuratio­
nOfSelectedActivity  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  obligatorio  
Driver2CurrentDuratio­
nOfSelectedActivity  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  obligatorio  
SpeedAuthorised  Apéndice 8  V U  no personal  no personal  no necesita con­
sentimiento  obligatorio  
TachographCardSlot1  ISO 16844-7  V U  no personal  no aplicable  no necesita con­
sentimiento  obligatorio  
TachographCardSlot2  ISO 16844-7  V U  no aplicable  no personal  no necesita con­
sentimiento  obligatorio  
Driver1Name  ISO 16844-7  Tar­
jeta 
de 
con­
duc­
tor personal  no aplicable  consentimiento 
del conductor  obligatorio  
Driver2Name  ISO 16844-7  Tar­
jeta 
de 
con­
duc­
tor no aplicable  personal  consentimiento 
del segundo con­
ductor  obligatorio  
OutOfScopeCondition  ISO 16844-7  V U  no personal  no personal  no necesita con­
sentimiento  obligatorio  
ModeOfOperation  ISO 16844-7  V U  no personal  no personal  no necesita con­
sentimiento  obligatorio  
Driver1CumulatedDri­
vingTimePreviousAnd­
CurrentWeek  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  obligatorio  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 531  
Nombre del dato  Formato del dato  Fuente  Clasificación del dato (personal / no 
personal)  Consentimiento a la 
disponibilidad del 
dato Disponibilidad  
conductor  segundo conductor  
Driver2CumulatedDri­
vingTimePreviousAnd­
CurrentWeek  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  obligatorio  
EngineSpeed  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  opcional  
RegisteringMemberS­
tate Apéndice 8  V U  no personal  no personal  no necesita con­
sentimiento  obligatorio  
VehicleRegistration­
Number  Apéndice 8  V U  no personal  no personal  no necesita con­
sentimiento  obligatorio  
Driver1EndOfLas­
tDailyRestPeriod  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  opcional  
Driver2EndOfLas­
tDailyRestPeriod  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  opcional  
Driver1EndOfLas­
tWeeklyRestPeriod  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  opcional  
Driver2EndOfLas­
tWeeklyRestPeriod  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  opcional  
Driver1EndOfSecond­
LastWeeklyRestPeriod  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  opcional  
Driver2EndOfSecond­
LastWeeklyRestPeriod  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  opcional  
Driver1TimeLastLoa­
dUnloadOperation  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  opcional  
Driver2TimeLastLoa­
dUnloadOperation  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  opcional  
Driver1CurrentDaily­
DrivingTime  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  opcional  
Driver2CurrentDaily­
DrivingTime  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  opcional  
Driver1CurrentWeekly­
DrivingTime  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  opcional  
Driver2CurrentWeekly­
DrivingTime  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  opcional  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 532  
Nombre del dato  Formato del dato  Fuente  Clasificación del dato (personal / no 
personal)  Consentimiento a la 
disponibilidad del 
dato Disponibilidad  
conductor  segundo conductor  
Driver1TimeLeftUntil­
NewDailyRestPeriod  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  opcional  
Driver2TimeLeftUntil­
NewDailyRestPeriod  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  opcional  
Driver1CardExpiry­
Date  ISO 16844-7  Tar­
jeta 
de 
con­
duc­
tor personal  no aplicable  consentimiento 
del conductor  opcional  
Driver2CardExpiry­
Date  ISO 16844-7  Tar­
jeta 
de 
con­
duc­
tor no aplicable  personal  consentimiento 
del segundo con­
ductor  opcional  
Driver1CardNextMan­
datoryDownloadDate  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  opcional  
Driver2CardNextMan­
datoryDownloadDate  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  opcional  
TachographNextMan­
datoryDownloadDate  ISO 16844-7  V U  no personal  no personal  no necesita con­
sentimiento  opcional  
Driver1TimeLeftUntil­
NewWeeklyRestPeriod  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  opcional  
Driver2TimeLeftUntil­
NewWeeklyRestPeriod  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  opcional  
Driver1NumberOfTi­
mes9hDailyDrivingTi­
mesExceeded  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  opcional  
Driver2NumberOfTi­
mes9hDailyDrivingTi­
mesExceeded  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  opcional  
Driver1CumulativeU­
ninterruptedRestTime  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  opcional  
Driver2CumulativeU­
ninterruptedRestTime  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  opcional  
Driver1Minimum­
DailyRest  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  opcional  
Driver2Minimum­
DailyRest  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  opcional  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 533  
Nombre del dato  Formato del dato  Fuente  Clasificación del dato (personal / no 
personal)  Consentimiento a la 
disponibilidad del 
dato Disponibilidad  
conductor  segundo conductor  
Driver1Minimum­
WeeklyRest  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  opcional  
Driver2Minimum­
WeeklyRest  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  opcional  
Driver1Maximum­
DailyPeriod  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  opcional  
Driver2Maximum­
DailyPeriod  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  opcional  
Driver1Maximum­
DailyDrivingTime  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  opcional  
Driver2Maximum­
DailyDrivingTime  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  opcional  
Driver1NumberOfUse­
dReducedDailyRestPe­
riods  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  opcional  
Driver2NumberOfUse­
dReducedDailyRestPe­
riods  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  opcional  
Driver1RemainingCu­
rrentDrivingTime  ISO 16844-7  V U  personal  no aplicable  consentimiento 
del conductor  opcional  
Driver2RemainingCu­
rrentDrivingTime  ISO 16844-7  V U  no aplicable  personal  consentimiento 
del segundo con­
ductor  opcional  
VehiclePosition  Apéndice 8  V U  personal  personal  consentimiento 
del conductor y 
del segundo con­
ductor  obligatorio  
ByDefaultLoadType  Apéndice 8  V U  personal  personal  consentimiento 
del conductor y 
del segundo con­
ductor  obligatorio  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 534  
Apéndice 14  
FUNCIÓN DE COMUNICACIÓN A DISTANCIA  
ÍNDICE  
1 INTRODUCCIÓN  
2 ALCANCE  
3 ACRÓNIMOS, DEFINICIONES Y ANOTACIONES  
4 ESCENARIOS OPERATIVOS  
4.1 Resumen  
4.1.1 Condiciones previas a la transferencia de datos mediante una interfaz 
DSRC de 5,8 GHz  
4.1.2 Perfil 1a: mediante un lector de comunicaciones de telede tección tem­ 
prana apuntado manualmente o instalado provisionalmente junto a  la 
carretera y apuntado  
4.1.3 Perfil 1b: mediante un lector de comunicaciones de telede tección 
temprana (REDCR) instalado en un vehículo y dirigido  
4.2 Seguridad/Integridad  
5 DISEÑO Y PROTOCOLOS DE COMUNICACIÓN A DISTANCIA  
5.1 Diseño  
5.2 Flujo de trabajo  
5.2.1 Operaciones  
5.2.2 Interpretación de los datos recibidos a través de la comu nicación DSRC  
5.3 Parámetros de la interfaz física de DSRC para comunicación a distancia  
5.3.1 Limitaciones de posición  
5.3.2 Parámetros de los enlaces ascendente y descendente  
5.3.3 Diseño de la antena  
5.4 Requisitos del protocolo DSRC para RTM  
5.4.1 Resumen  
5.4.2 Comandos  
5.4.3 Secuencia de comandos de interrogación  
5.4.4 Estructuras de los datos  
5.4.5 Elementos de RtmData, acciones realizadas y definiciones  
5.4.6 Mecanismo de transferencia de datos  
5.4.7 Descripción detallada de la transacción DSRC  
5.4.8 Descripción de la transacción de pruebas de la DSRC  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 535  
5.5 Reservado para usos futuros  
▼B 
5.6 Transferencia de datos entre la DSRC-VU y la VU  
5.6.1 Conexión física e interfaces  
5.6.2 Protocolo de aplicaciones  
5.7 Gestión de errores  
5.7.1 Registro y comunicación de los datos en la DSRC-VU  
5.7.2 Errores de comunicación inalámbrica  
6 PRUEBAS PARA LA PUESTA EN SERVICIO Y LAS INSPECCIO­ 
NES PERIÓDICAS DE LA FUNCIÓN DE COMUNICACIÓN A DIS­ 
TANCIA  
6.1 Generalidades  
6.2 ECHO  
6.3 Pruebas para validar el contenido de datos seguros  
1 INTRODUCCIÓN  
En este apéndice se especifican el diseño y los procedimientos que 
deben seguirse para llevar a cabo la función de comunicación a distancia 
(la Comunicación) con arreglo a los dispuesto en el artículo 9 del 
Reglamento (UE) n  o 165/2014 (el Reglamento).  
DSC_1 El Reglamento (UE) n  o 165/2014 establece que el tacógrafo 
incorporará una funcionalidad de comunicación a distancia que 
permita que los agentes de las autoridades de control compe­
tentes puedan leer la información del tacógrafo de vehículos en  
circulación mediante un equipo de interrogación a distancia (el  
lector de teledetección temprana, REDCR), específicamente, 
un equipo de interrogación que se conecta de manera inalám­
brica a través de interfaces de las comunicaciones especializa­
das de corto alcance (DSRC) de 5,8 GHz del CEN.  
Es importante entender que esta funcionalidad tiene por objeto 
servir exclusivamente como filtro previo de selección de vehí­
culos para controlarlos más detenidamente y no sustituye al 
proceso de control formal que se establece en el Reglamento 
(UE) n  o 165/2014. Véase el considerando 9 del preámbulo de 
dicho Reglamento, en el que se establece que la comunicación 
a distancia entre el tacógrafo y las autoridades de control, co n 
fines de control en carretera, facilita una mayor selectividad de 
este tipo de controles.  
DSC_2  Los Datos  se intercambiarán mediante  la Comunicación  que 
consistirá en un enlace inalámbrico a través de comunicaciones 
inalámbricas DSRC de 5,8 GHz de conformidad con el pre­
sente apéndice y evaluado con los parámetros pertinentes que 
se establecen en EN 300 674-1 {Electromagnetic compatibility 
and Radio spectrum Matters (ERM); Road Transport and  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 536  
Traffic Telematics (RTTT); Dedicated Short Range Communi­
cation (DSRC) transmission equipment (500 kbit/s / 250 
kbit/s) operating in the 5,8 GHz Industrial, Scientific and Me­
dical (ISM) band; Part 1 General characteristics and test met­
hods for Road Side Units (RSU) and On -Board Units 
(OBU)}.  
DSC_3  La Comunicación  se establecerá con el equipo de comunica­
ciones solo cuando lo solicite el equipo de la autoridad de 
control competente por medios de radiocomunicación compa­
tibles ( el lector de comunicación de teledetección temprana, 
REDCR ). 
DSC_4  Los Datos  se protegerán para garantizar su integridad.  
DSC_5 El acceso a  los Datos  comunicados se restringirá a las autori­
dades de control competentes autorizadas para verificar las 
infracciones del Reglamento (CE) n  o 561/2006 y del 
Reglamento (UE) n  o 165/2014 y a los talleres en la medida 
en que sea necesario para verificar la funcionamiento correcto 
del tacógrafo.  
DSC_6 El intercambio de  los Datos  durante  la Comunicación  se limi­
tará a aquellos necesarios para hacer más selectivos los con­
troles de carretera de los vehículos cuyo tacógrafo haya podido  
ser manipulado o utilizado indebidamente.  
DSC_7 La integridad y la seguridad de los datos se obtendrá pro te­
giendo  los Datos  dentro de la unidad instalada en el 
vehículo (VU) y transmitiendo solo los datos útiles protegidos 
y los datos relativos a la seguridad (véase el apartado 5.4.4) 
por medio de la telecomunicación inalámbrica DSRC de 5,8 
GHz, lo que implica que solo las personas autorizadas de las 
autoridades de control competentes cuentan con los medios 
para interpretar los datos transmitidos a través de  la Comuni ­
cación  y para verificar su autenticidad. Véase el Apéndice 11, 
«Mecanismos de seguridad comunes».  
DSC_8  Los Datos  incorporarán una indicación temporal con la fecha y 
hora de su última actualización.  
DSC_9 El contenido de los datos de seguridad solo se dará a con ocer 
a y quedará bajo el control exclusivo de las autoridades de 
control competentes y aquellos terceros con los que compartan 
esta información y queda fuera de las disposiciones de  la 
Comunicación  que es objeto del presente apéndice, a menos 
que la Comunicación  prevea la transferencia de un paquete de 
datos de seguridad con cada paquete de datos útiles.  
DSC_10 La misma arquitectura y equipo podrán emplearse para obt ener 
otros tipos de datos (como el peso a bordo) mediante la ar­
quitectura aquí especificada.  
DSC_11 A efectos de aclaración, de conformidad con las disposic iones 
del Reglamento (UE) n  o 165/2014 (artículo 7), los datos rela­
tivos a la identidad del conductor no se transmitirán en  la 
Comunicación . 
2 ALCANCE  
El propósito del presente apéndice es especificar el modo en qu e los 
agentes de las autoridades de control competentes utilizan una comuni­
cación inalámbrica DSRC de 5,8 GHz específica para obtener dato s a ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 537  
distancia de un vehículo seleccionado ( los Datos ) que indiquen que 
dicho vehículo ha podido infringir el Reglamento (UE) n  o 165/2014 y 
deba ser detenido para posteriores investigaciones.  
El Reglamento (UE) n  o 165/2014 exige que los datos recabados se 
limiten o correspondan a datos que identifiquen una posible inf racción, 
tal como se define en el artículo 9 del Reglamento (UE) n  o 165/2014.  
▼M1 
En estas circunstancias, el tiempo de que se dispone para la co munica­
ción es limitado porque  la Comunicación  es específica y tiene un diseño 
de corto alcance. Además, las autoridades de control competente s pue­
den aprovechar el mismo medio de comunicación utilizado en la s uper­
visión a distancia de tacógrafos (RTM) para otras aplicaciones [como los 
pesos máximos y las dimensiones de vehículos pesados que se est able­
cen en la Directiva (UE) 2015/719] y estas operaciones pueden r eali­
zarse por separado o de manera consecutiva según el criterio de  las 
autoridades de control competentes.  
▼B 
El presente apéndice especifica:  
— el equipo, los procedimientos y los protocolos de comunicacio nes 
que han de utilizarse para  la Comunicación ; 
— las normas y los reglamentos que debe cumplir el equipo radio eléc­
trico;  
— la presentación de  los Datos  al equipo de  la Comunicación ; 
— los procedimientos de consulta y transferencia y la secuencia  de las 
operaciones;  
— los Datos  que deben transferirse;  
— la posible interpretación de  los Datos  transferidos a través de  la 
Comunicación ; 
— las disposiciones de los datos de seguridad relativas a  la Comunica ­
ción; 
— la disponibilidad de  los Datos  para las autoridades de control 
competentes;  
— el modo en que el  lector de comunicación de teledetección temprana  
puede solicitar distintos tipos de datos sobre la carga y la fl ota. 
A efectos de aclaración, este apéndice  no especifica:  
— la explotación y la gestión de la recogida de  los Datos  en la VU (que 
dependerá del diseño del producto a menos que se especifique de  
otro modo en el Reglamento (UE) n  o 165/2014);  
— la forma de presentar los datos recabados al agente de las au torida­
des de control competentes, ni los criterios que aplicarán las autori­
dades de control competentes para decidir qué vehículos deben d e­
tenerse (lo que dependerá del diseño del producto a menos que s e 
especifique de otro modo en el Reglamento (UE) n  o 165/2014 o en 
una decisión política de las autoridades de control competentes ); a 
efectos de aclaración:  la Comunicación  se limita a poner  los Datos  a 
disposición de las autoridades de control competentes para que  estas 
puedan tomar decisiones bien fundadas;  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 538  
— las disposiciones sobre seguridad de los datos (como el cifra do) 
relativas a  los Datos  (que se especificarán en el apéndice 11, «Me­
canismos de seguridad comunes»);  
— detalles de cualquier tipo de datos distintos de RTM que pued an 
obtenerse con la misma arquitectura y equipo;  
— detalles del comportamiento y la gestión entre la VU y la 
DSRC-VU, o el comportamiento dentro de la DSRC-VU (al margen 
del suministro de  los Datos  cuando los solicite un REDCR).  
3 ACRÓNIMOS, DEFINICIONES Y ANOTACIONES  
Los siguientes acrónimos y definiciones son específicos del pre sente 
apéndice y se utilizan como se indica a continuación:  
Antena  Un dispositivo eléctrico que con­
vierte la energía eléctrica en ondas 
de radio y viceversa que se utiliza 
con un radiotransmisor o un radio­
rreceptor. Cuando está en funciona­
miento, un radiotransmisor suminis­
tra una corriente eléctrica que oscila 
a una determinada radiofrecuencia 
hasta los terminales de la antena y 
la antena irradia la energía de la co­
rriente en forma de ondas electro­
magnéticas (ondas de radio). Du­
rante la recepción, la antena inter­
cepta parte de la energía de una 
onda electromagnética para generar 
una pequeña tensión en sus termina­
les que se aplica a un receptor para 
amplificarlo.  
Comunicación  El intercambio de información o da­
tos entre un DSRC-REDCR y una 
DSRC-VU conforme a lo dispuesto 
en la sección 5 estableciéndose una 
relación maestro-esclavo para obte­
ner los datos.  
Datos  Los datos protegidos en un formato 
definido (véase el apartado 5.4.4) 
solicitados por el  DSRC-REDCR  y  
facilitados al  DSRC-REDCR  por la  
DSRC-VU  a través de un enlace 
DSRC de 5,8 GHz definido en la 
sección 5.  
Reglamento (CE) n  o 165/2014  El Reglamento (UE) n  o 165/2014 
del Parlamento Europeo y del Con­
sejo, de 4 de febrero de 2014, rela­
tivo a los tacógrafos en el transporte  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 539  
por carretera, por el que se deroga el 
Reglamento (CEE) n  o 3821/85 rela­
tivo al aparato de control en el sec­
tor de los transportes por carretera y 
se modifica el Reglamento (CE) 
n o 561/2006 del Parlamento Euro­
peo y del Consejo relativo a la ar­
monización de determinadas disposi­
ciones en materia social en el sector 
de los transportes por carretera.  
AID Identificador de aplicación  
BLE  Bluetooth de baja energía  
BST  Tabla de servicios de la baliza  
CIWD  Inserción de tarjeta durante la con­
ducción  
CRC  verificación por redundancia cíclica  
DSC (n)  identificador de un requisito para un 
apéndice DSRC específico  
DSRC  Dedicated Short Range Communica­
tion 
DSRC-REDCR  DSRC — lector de comunicación de 
teledetección temprana.  
DSRC-VU  DSRC — Unidad instalada en el ve­
hículo. Se trata del «dispositivo de 
teledetección temprana» definido en 
el anexo 1C.  
DWVC  Conducción sin tarjeta válida  
EID Identificador de elementos  
LLC  Control de enlace lógico  
LPDU  Unidad de datos del protocolo LLC  
OWS  Sistema de pesaje de a bordo  
PDU  Unidad de datos de protocolo  
REDCR  Lector de comunicaciones de telede­
tección temprana. Se trata del «lec­
tor de comunicación de teledetec­
ción temprana» definido en el 
anexo 1C.  
RTM  Supervisión a distancia de tacógra­
fos 
SM-REDCR  Módulo de seguridad-lector de co­
municaciones de teledetección tem­
prana  
TARV  Aplicaciones telemáticas para vehí­
culos regulados (serie de normas 
ISO 15638)  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 540  
VU Unidad instalada en el vehículo  
VUPM  Memoria útil de la unidad instalada 
en el vehículo  
VUSM  Módulo de seguridad de la unidad 
instalada en el vehículo  
VST  Tabla de servicios del vehículo  
WIM  Pesaje en movimiento  
WOB  Pesaje a bordo  
La especificación definida en este apéndice se refiere y depend e de la 
totalidad o de distintas partes de los reglamentos y normas sig uientes. En 
las cláusulas del presente apéndice se especifican las normas p ertinentes 
o las cláusulas pertinentes de las normas. En el caso de exista  alguna 
contradicción, prevalecerán las cláusulas del presente apéndice . En el 
caso de que exista alguna contradicción sin aclarar por alguna especifi­
cación en el presente apéndice, prevalecerán las operaciones su jetas al 
ERC 70-03 (y verificadas con los parámetros adecuados de EN 300  674- 
1), seguido en orden de preferencia por EN 12795, EN 12253 EN 1 2834 
y EN 13372, 6.2, 6.3, 6.4 y 7.1.  
Los Reglamentos y las normas mencionados en este apéndice son:  
[1] Reglamento (UE) n  o 165/2014 del Parlamento Europeo y del Con­
sejo, de 4 de febrero de 2014, relativo a los tacógrafos en el 
transporte por carretera, por el que se deroga el Reglamento (C EE) 
n o 3821/85 relativo al aparato de control en el sector de los tran s­
portes por carretera y se modifica el Reglamento (CE) n  o 561/2006 
del Parlamento Europeo y del Consejo relativo a la armonización  
de determinadas disposiciones en materia social en el sector de  los 
transportes por carretera.  
[2] Reglamento (UE) n  o 561/2006 del Parlamento Europeo y del Con­
sejo, de 15 de marzo de 2006, relativo a la armonización de de­
terminadas disposiciones en materia social en el sector de los trans­
portes por carretera y por el que se modifican los Reglamentos 
(CEE) n  o 3821/85 y (CE) n  o 2135/98 del Consejo y se deroga el 
Reglamento (CEE) n  o 3820/85 del Consejo (Texto pertinente a 
efectos del EEE).  
[3] ERC 70-03 CEPT: ECC Recommendation 70-03: Relating to the 
Use of Short Range Devices (SRD)  
[4] ISO 15638 Intelligent transport systems — Framework for coo ­
perative telematics applications for regulated commercial freig ht 
vehicles (TARV).  
[5] EN 300 674-1 Compatibilidad electromagnética y temas del es pec­
tro de radio (ERM); Telemática para el tráfico y el transporte por 
carretera (RTTT); Equipos de transmission (500 kbit/s / 250 kbi t/s) 
operando en la banda industrial, científica y médica (ISM) de 5 ,8 
GHz en comunicaciones dedicadas de corto alcance (DSRC); Parte 
1: Características generales y métodos de ensayo para las unida des 
del lado de la carretera (RSU) y unidades a bordo (OBU).  
[6] EN 12253 Telemática para el tráfico y el transporte por car retera 
(RTTT). Comunicaciones dedicadas de corto alcance (DSRC). 
Capa física utilizando microondas a 5,8 GHz.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 541  
[7] EN 12795 Telemática aplicada al tráfico y al transporte por  carre­
tera. Comunicaciones dedicadas de corto alcance (DSRC). Capa de  
enlace de datos DSRC: Control de acceso al medio y control lógi co 
de enlace.  
[8] EN 12834 Telemática para el tráfico y el transporte por car retera 
(RTTT). Comunicaciones dedicadas de corto alcance (DSRC) — 
Capa de aplicación.  
[9] EN 13372 Telemática para el tráfico y el transporte por car retera 
(RTTT). Comunicaciones dedicadas de corto alcance (DSRC). Per­
files para aplicaciones RTTT.  
[10] ISO 14906 Sistema de telepago. Definición de la interfaz d e la 
capa de aplicación para comunicaciones dedicadas de corto 
alcance.  
4 ESCENARIOS OPERATIVOS  
4.1 Resumen  
El Reglamento (UE) n  o 165/2014 contempla escenarios específicos y 
controlados en los que debe utilizarse  la Comunicación . 
Los escenarios contemplados son:  
«Perfil de comunicación 1: Control en carretera utilizando un lector de 
teledetección temprana mediante comunicación inalámbrica de corto 
alcance para proceder a un control físico en carretera (maestro-:-es ­
clavo)  
Perfil de lector 1a: a través de un lector de comunicaciones de telede ­
tección temprana apuntado manualmente o instalado provisionalmente 
junto a la carretera y apuntado  
Perfil de lector 1b: a través de un lector de comunicaciones de telede ­
tección temprana instalado en un vehículo y dirigido».  
4.1.1  Condiciones previas a la transferencia de datos mediante una interfaz 
DSRC de 5,8 GHz  
NOTA: a fin de entender el contexto de las condiciones previas,  se 
remite al lector a la figura 14.  
4.1.1.1 Datos alojados en la VU  
DSC_12 La VU se ocupará de actualizar cada sesenta segundos y d e 
mantener los datos almacenados en la VU sin intervención 
alguna de la función de comunicación DSRC. El medio para 
realizar esta operación se encuentra en el interior de la VU, 
especificado en el Reglamento (UE) n  o 165/2014, anexo 1C, 
sección 3.19, « Comunicación a distancia para controles de 
carretera selectivos », y no se especifica en el presente apén­
dice.  
4.1.1.2 Datos suministrados al equipo DSRC-VU  
DSC_13 La VU se ocupará de actualizar los datos del tacógrafo D SRC 
(los Datos ) siempre que los datos almacenados en la VU se 
actualicen en el intervalo especificado en el apartado 4.1.1.1 
(DSC_12), sin la intervención de la función de comunicación 
DSRC.  
DSC_14 Los datos de la VU servirán de base para completar y act ua­
lizar los Datos . El medio para realizar esta operación se espe­
cifica en el anexo 1C, sección 3.19, « Comunicación a distan ­
cia para controles de carretera selectivos », y, de no existir 
dicha especificación, dependerá del diseño del producto y no 
se especifica en este apéndice. En cuanto al diseño de la 
conexión entre el equipo DSRC-VU y la VU, consúltese la 
sección 5.6.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 542  
4.1.1.3 Contenido de los datos  
DSC_15 El contenido y el formato de  los Datos  deberán permitir que, 
una vez descifrados, se estructuren y se pongan a disposición 
del modo y con el formato especificados en el apartado 5.4.4 
del presente apéndice (Estructuras de los datos).  
4.1.1.4 Presentación de los datos  
DSC_16  Los Datos , habiéndose actualizado frecuentemente conforme a 
los procedimientos establecidos en el apartado 4.1.1.1, se pro­
tegerán antes de su presentación a la  DSRC-VU  y se presen­
tarán como un valor conceptual de datos seguros, para su 
almacenamiento temporal en la  DSRC-VU  como versión actual 
de los Datos . Estos datos se transfieren del  VUSM  a la función  
VUPM  de DSRC. El  VUSM  y  l a  VUPM  son funciones y no 
necesariamente entidades físicas. La forma de instanciación 
física para realizar estas funciones dependerá del diseño del 
producto, a menos que se especifique de otro modo en el 
Reglamento (UE) n  o 165/2014.  
4.1.1.5 Datos de seguridad  
▼M3 
DSC_17 Los datos de seguridad ( DSRCSecurityData ), que comprenden 
los datos que necesita el  REDCR  para tener la capacidad de 
descifrar  los datos , se suministrarán del modo establecido en el 
apéndice 11, «Mecanismos de seguridad comunes», para su 
almacenamiento temporal en la  DSRC-VU  como versión actual 
de DSRCSecurityData , de la forma establecida en el 
punto 5.4.4 del presente apéndice.  
▼B 
4.1.1.6 Datos de la VUPM disponibles para su transferencia a tr avés de la 
interfaz DSRC  
DSC_18 El concepto de datos que deberá estar siempre disponible  en la 
función VUPM de DSRC para su transferencia inmediata tras 
ser solicitados por el  REDCR  se define en el apartado 5.4.4 
para todas las especificaciones del módulo ASN.1.  
Descripción general del perfil de comunicación 1  
Este perfil contempla el ejemplo de uso en el que un agente de las 
autoridades de control competentes utiliza un lector de comunic aciones 
de teledetección temprana (interfaces DSRC de 5,8 GHz que opera n 
según ERC 70-03 verificadas con los parámetros apropiados de EN  
300 674-1 tal como se describe en el apartado 5) ( el REDCR ) para 
identificar a distancia un vehículo que pueda haber infringido el 
Reglamento (UE) n  o 165/2014. Una vez identificado, el agente de las 
autoridades de control competentes que realiza la interrogación  decide si 
debe detenerse el vehículo.  
4.1.2  Perfil 1a: mediante un lector de comunicaciones de teledetección tem ­
prana apuntado manualmente o instalado provisionalmente junto a la 
carretera y apuntado  
En este ejemplo de uso, el agente de las autoridades de control  compe­
tentes se sitúa junto a la carretera y dirige un  REDCR  de mano, montado 
en un trípode o algún dispositivo portátil similar desde el lat eral de la 
carretera hacia el centro del parabrisas del vehículo seleccion ado. La 
interrogación se realiza mediante interfaces DSRC de 5,8 GHz qu e ope­
ran según ERC 70-03 y se verifican con los parámetros apropiado s de 
EN 300 674-1 del modo descrito en el apartado 5. Véase la figur a 14.1 
(Ejemplo de uso 1).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 543  
Figura 14.1  
Interrogación en carretera mediante DSRC de 5,8 GHz
  
4.1.3  Perfil 1b: mediante un lector de comunicaciones de teledetección 
temprana (REDCR) instalado en un vehículo y dirigido  
En este ejemplo de uso, el agente de las autoridades de control  compe­
tentes se encuentra en un vehículo en movimiento y, o bien apun ta un 
REDCR manual portátil desde el vehículo hacia el centro del par abrisas 
del vehículo seleccionado, o bien  el REDCR  va montado en el interior o 
sobre el vehículo para apuntar hacia el centro del parabrisas d el vehículo 
seleccionado cuando el vehículo del lector de comunicaciones de  tele­
detección temprana se encuentra en una posición determinada con  rela­
ción al vehículo seleccionado (por ejemplo, directamente delant e en un 
flujo de tráfico). La interrogación se realiza mediante interfa ces DSRC 
de 5,8 GHz que operan según ERC 70-03 y se verifican con los pa rá­
metros apropiados de EN 300 674-1 del modo descrito en la secci ón 5. 
Véase la figura 14.2. (Ejemplo de uso 2).  
Figura 14.2  
Interrogación basada en vehículo mediante DSRC de 5,8 GHz 
(idem)
  
4.2 Seguridad/Integridad  
Para poder verificar la autenticidad y la integridad de los dat os trans­
feridos a través de la comunicación a distancia, los  Datos  protegidos se 
verifican y se descifran según lo dispuesto en el apéndice 11, «Meca­
nismos de seguridad comunes».  
5 DISEÑO Y PROTOCOLOS DE COMUNICACIÓN A DISTANCIA  
5.1 Diseño  
El diseño de la función de comunicación a distancia del tacógra fo inte­
ligente es el descrito en la figura 14.3.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 544  
Figura 14.3  
Diseño de la función de comunicación a distancia
  
DSC_19 Las funciones siguientes van incorporadas a la VU:  
— Módulo de seguridad ( VUSM ). Esta función incorporada a 
la VU se ocupa de proteger  los Datos  que se van a trans­
mitir desde la  DSRC-VU  hasta el agente de las autoridades 
competentes mediante comunicación a distancia.  
— Los datos protegidos se almacenan en la memoria VUSM. 
A los intervalos establecidos en el apartado 4.1.1.1 
(DSC_12), la VU cifra y repone el concepto RTMdata 
(que comprende valores conceptuales de datos útiles y 
datos de seguridad especificados más adelante en este 
apéndice) alojado en la memoria de la DSRC-VU. El fun­
cionamiento del módulo de seguridad se define en el apén­
dice 11, «Mecanismos de seguridad comunes», y queda 
fuera del ámbito del presente apéndice, su bien será nece­
sario para realizar las actualizaciones del equipo de comu­
nicación de la VU cada vez que cambien los datos del 
VUSM.  
— La comunicación entre la VU y la DSRC-VU puede ser 
una comunicación por cable o una comunicación por Blue­
tooth de baja energía (BLE) y físicamente la DSRC-VU 
puede ir integrada con la antena en el parabrisas del vehí­
culo, estar dentro de la VU o colocada en algún lugar 
intermedio.  
— La DSRC-VU dispondrá de una fuente de alimentación 
fiable en todo momento. El modo en que se le suministra 
la alimentación es una cuestión de diseño.  
— La memoria de la DSRC-VU no será volátil, con el fin de 
mantener los datos en la DSRC-VU incluso con el vehí­
culo apagado.  
— Si la comunicación entre la VU y la DSRC-VU se realiza 
mediante BLE y la fuente de alimentación es una batería 
no recargable, se sustituirá la fuente de alimentación de la 
DSRC-VU en cada inspección periódica y el fabricante del  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 545  
equipo DSRC-VU será responsable de garantizar que la 
alimentación sea suficiente para que dure de una inspec­
ción periódica a la siguiente, manteniendo el acceso nor­
mal a los datos mediante un REDCR durante todo el pe­
riodo sin fallos ni interrupciones.  
— Equipo de «memoria útil» de VU RTM ( VUPM ). Esta 
función integrada en la VU se encarga de suministrar y 
actualizar  los Datos . El contenido de  los Datos  («Tacho­
graphPayload») se define más abajo en 5.4.4/5.4.5 y se 
actualiza según el intervalo establecido en el apartado 
4.1.1.1 (DSC_12).  
— DSRC-VU. Esta es la función, dentro de la antena o co­
nectada a ella y en comunicación con la VU a través de 
una conexión por cable o inalámbrica (BLE), que aloja los 
datos actuales ( datos VUPM ) y gestiona la respuesta a una 
interrogación por medio de DSRC de 5,8 GHz. La desco­
nexión del equipo DSRC o la interferencia con el funcio­
namiento del equipo DSRC durante la utilización normal 
del vehículo se considerarán una infracción del 
Reglamento (UE) n  o 165/2014.  
— El módulo de seguridad (REDCR) ( SM-REDCR ) cons­
tituye la función que se utiliza para descifrar y comprobar 
la integridad de los datos que provienen de la VU. El 
medio para lograr esta función se establece en el apéndice 
11, «Mecanismos de seguridad comunes», y no se define 
en este apéndice.  
— La función del equipo DSRC (REDCR) ( DSRC-REDCR ) 
comprende un transceptor de 5,8 GHz y el correspondiente  
firmware  y software  para gestionar  la Comunicación  con la  
DSRC-VU  de conformidad con el presente apéndice.  
— El  DSRC-REDCR  interroga a la  DSRC-VU  sobre el vehí­
culo seleccionado y obtiene  los Datos  (los  datos VUPM  
actuales del vehículo seleccionado) a través del enlace 
DSRC y procesa y almacena los datos recibidos en su  
SM-REDCR . 
▼M1 
— La antena de la DSRC-VU se colocará en una posición en 
la que optimice la comunicación DSRC entre el vehículo y 
la antena del lector del lado de la carretera, cuando el 
lector esté instalado a quince metros de distancia por de­
lante del vehículo y a dos metros de altura, apuntando al 
centro vertical y horizontal del parabrisas. En vehículos 
ligeros, puede instalarse perfectamente en la parte superior 
del parabrisas. En el caso de los demás vehículos, la antena 
de la DSRC se instalará, bien cerca la parte inferior del 
parabrisas, o bien cerca de su parte superior.  
▼B 
DSC_20 La Antena y la Comunicación funcionarán según ERC 70-03,  
verificándose con los parámetros apropiados de EN 300 674-1 
del modo descrito en la sección 5. La Antena y la Comunica­
ción pueden incorporar técnicas para atenuar el riesgo de in­
terferencias inalámbricas según se describe en el informe ECC 
228 mediante el uso, por ejemplo, de filtros en la comunica­
ción CEN DSRC 5,8 GHz.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 546  
DSC_21 La antena DSRC se conectará al equipo DSRC-VU de forma 
directa dentro del módulo instalado en el parabrisas o cerca de  
este o mediante un cable específico fabricado de modo que 
dificulte su desconexión ilegal. La desconexión o interferencia  
con el funcionamiento de la Antena constituirá una infracción 
del Reglamento (UE) n  o 165/2014. El enmascaramiento inten­
cionado o perjudicial para el funcionamiento de la Antena 
constituirá una infracción del Reglamento (UE) n  o 165/2014.  
DSC_22  ►M1 El factor de forma de la antena no se define y cons­
tituirá una decisión comercial, siempre que la DSRC-VU ins­
talada cumpla los requisitos de conformidad establecidos en la 
sección 5. La antena se colocará del modo establecido en 
DSC_19 y responderá de manera eficaz a los ejemplos de 
uso descritos en los apartados 4.1.2 y 4.1.3. ◄  
Figura 14.4  
Ejemplo de colocación de la antena DSRC de 5,8 GHz en el 
parabrisas de vehículos regulados.
  
El factor de forma del  REDCR  y de su antena puede variar según las 
circunstancias del aparato de lectura (montado en un trípode, m anual, 
instalado en un vehículo, etc.) y el  modus operandi  del agente de las 
autoridades del control competentes.  
Se utiliza una función de visualización o notificación para mos trar los 
resultados de la función de comunicación a distancia al agente de las 
autoridades de control competentes. El modo de visualización pu ede ser 
una pantalla, una impresión en papel, una señal acústica o una combi­
nación de las mismas. Esta forma de visualización o notificació n de­
pende de las necesidades de los agentes de las autoridades de c ontrol 
competentes y del diseño del equipo, por lo que no se especific a en este 
apéndice.  
DSC_23 El diseño y el factor de forma del  REDCR  dependerá del 
diseño comercial, con sujeción a ERC 70-03 y a las especifi­
caciones del diseño y rendimiento que se definen en este  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 547  
apéndice (apartado 5.3.2), por lo que el mercado dispone de la 
máxima flexibilidad para diseñar y suministrar equipos que 
abarquen los supuestos específicos de interrogación de cual­
quier autoridad de control competente.  
DSC_24 El diseño y el factor de forma de la  DSRC-VU  y su posición 
dentro o fuera de la VU dependerán del diseño comercial, con 
sujeción a ERC 70-03 y a las especificaciones de diseño y 
rendimiento definidas en este apéndice (apartado 5.3.2) y en la  
presente sección (5.1).  
DSC_25 No obstante, la  DSRC-VU  será razonablemente capaz de acep­
tar valores conceptuales de datos de otros equipos inteligentes  
de vehículos a través de una conexión y unos protocolos 
abiertos y normalizados del sector (por ejemplo, de equipos 
de pesaje de a bordo), siempre que estos conceptos de datos 
sean identificados mediante identificadores de aplicación o 
nombres de archivo únicos y conocidos y se faciliten a la 
Comisión Europea las instrucciones para manejar estos proto­
colos y estén disponibles sin coste para los fabricantes de los  
equipos pertinentes.  
5.2 Flujo de trabajo  
5.2.1  Operaciones  
En la figura 14.5 se representa el flujo de trabajo de las oper aciones.  
Figura 14.5  
Flujo de trabajo de la función de comunicación a distancia
  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 548  
Los pasos se describen a continuación:  
a. Siempre que el vehículo esté en marcha (el encendido conecta do), el 
tacógrafo suministra datos a la función VU. La función VU prepa ra 
los Datos  para la función de comunicación a distancia (cifrada) y 
actualiza la  VUPM  y la memoria de la  DSRC-VU  (tal y como se 
define en los apartados 4.1.1.1 — 4.1.1.2).  Los Datos  obtenidos se 
formatean del modo establecido en los apartados 5.4.4 — 5.4.5.  
b. Cada vez que se actualizan  los Datos , se actualiza la indicación 
temporal definida en el concepto de datos de seguridad.  
c. La función  VUSM  protege los datos conforme a los procedimientos 
establecidos en el apéndice 11.  
d. Cada vez que se actualizan  los Datos  (véanse los apartados 4.1.1.1 
— 4.1.1.2),  los Datos  se transfieren a la  DSRC-VU , donde sustituyen 
a los datos anteriores de modo que siempre haya datos actualiza dos 
(los Datos ) que suministrar en caso de que se produzca una interro­
gación por parte de un  REDCR . Cuando la VU suministre  los Datos  
al DSRC-VU, los datos podrán identificarse por el nombre del ar ­
chivo  RTMData o  por los identificadores de aplicación y de 
atributos.  
e. Si un agente de las autoridades de control competentes decid e selec­
cionar un vehículo y recabar  los Datos  de ese vehículo específico, el 
agente de las autoridades de control competentes introducirá pr imero 
su tarjeta inteligente en  el REDCR  para habilitar  la Comunicación  y  
para que el  SM-REDCR  pueda verificar su autenticidad y descifrar 
los datos.  
f. A continuación, el agente de las autoridades de control comp etentes 
selecciona un vehículo y solicita los datos mediante comunicaci ón a 
distancia.  El REDCR  abre una sesión de interfaz de DSRC de 5,8 
GHz con la  DSRC-VU  del vehículo seleccionado y solicita  los Datos . 
Los Datos  se transfieren  al REDCR  a través del sistema de comuni­
cación inalámbrica como atributo DSRC empleando el servicio de 
aplicaciones GET definido en la sección 5.4. El Atributo contie ne los 
valores de los datos útiles cifrados y los datos de seguridad d e 
DSRC.  
g. Los datos son analizados por el equipo  REDCR  y suministrados al 
agente de la autoridad de control competente.  
h. El agente de la autoridad de control competente utiliza los datos para 
decidir si detiene o no el vehículo con el fin de realizar una ins­
pección minuciosa o solicita a otro agente de la autoridad de c ontrol 
competente que detenga el vehículo.  
5.2.2  Interpretación de los datos recibidos a través de la comunicación DSRC  
DSC_26 Los datos recibidos a través de la interfaz de 5,8 GHz l leva­
rán el significado y la importancia definidos en los apartados 
5.4.4 y 5.4.5, y solo esos, y se entenderán únicamente en el 
marco de los objetivos aquí definidos. De conformidad con  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 549  
las disposiciones del Reglamento (UE) n  o 165/2014,  los Da­
tos se utilizarán exclusivamente para facilitar información per­
tinente a una autoridad de control competente para poder 
determinar qué vehículo debe detener para realizar una ins­
pección física y, posteriormente, se destruirán conforme a lo 
dispuesto en el artículo 9 del Reglamento (UE) n  o 65/2014.  
5.3 Parámetros de la interfaz física de DSRC para comunicación a 
distancia  
5.3.1  Limitaciones de posición  
DSC_27 La interrogación a distancia de vehículos mediante una i nter­
faz DSRC de 5,8 GHz no debe utilizarse a menos de 200 
metros de un pórtico DSRC de 5,8 GHz en funcionamiento.  
5.3.2  Parámetros de los enlaces ascendente y descendente  
DSC_28 El equipo empleado para la supervisión a distancia de ta có­
grafos se ajustará y funcionará con arreglo a ERC 70-03 y a 
los parámetros establecidos en los cuadros 14.1 y 14.2.  
DSC_29 Asimismo, con el fin de garantizar la compatibilidad con  los 
parámetros operativos de otros sistemas normalizados DSRC 
de 5,8 GHz, el equipo empleado para la supervisión a distan­
cia de tacógrafos se ajustará a los parámetros que establecen 
EN 12253 y EN 13372.  
A saber:  
Cuadro 14.1  
Parámetros de enlace descendente  
N o de elemento  Parámetro  Valor(es)  Observación  
D1 Frecuencias portadoras del 
enlace descendente  Existen cuatro alternativas 
que puede utilizar un 
REDCR: 
5,7975 GHz 
5,8025 GHz 
5,8075 GHz 
5,8125 GHz  Dentro de ERC 70-03. 
El implementador puede seleccio­
nar las frecuencias portadoras del 
sistema de carretera y no tienen 
por qué conocerse en la DSRC-VU  
(Conforme a EN 12253, EN 13372)  
D1a (*) Tolerancia de las frecuen­
cias portadoras  Dentro de ± 5 ppm  (Conforme a EN 12253)  
D2 (*) Máscara del espectro del 
transmisor RSU (REDCR)  Dentro de ERC 70-03. 
El REDCR deberá ajustarse 
a la Clase B,C tal como se 
define en EN 12253 
No existe ningún otro requi­
sito específico dentro de 
este anexo  Parámetro utilizado para controlar 
las interferencias entre los interro­
gadores en proximidad (como se 
define en EN 12253 y EN 13372)  
D3 Rango mínimo de frecuen­
cias de la OBU (DSRC- 
VU) 5,795 — 5,815 GHz  (Conforme a EN 12253)  
D4 (*) E.I.R.P. máxima  Dentro de ERC 70-03 (sin 
licencia) dentro de la nor­
mativa regional 
Máximo +33 dBm  (Conforme a EN 12253)  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 550  
N o de elemento  Parámetro  Valor(es)  Observación  
D4a Máscara de E.I.R.P. angular  Según la especificación de­
clarada y publicada por el 
diseñador del interrogador  (Conforme a EN 12253)  
D5 Polarización  Circular a izquierdas  (Conforme a EN 12253)  
D5a Polarización cruzada  XPD: 
En la dirección de máxima 
radiación: (REDCR) RSU t 
≥ 15 dB 
(DSRC-VU) OBU r ≥ 10 
dB 
En un área a 
-3 dB: (REDCR) RSU t ≥ 
10 dB 
(DSRC-VU) OBU r ≥ 6 dB  (Conforme a EN 12253)  
D6 (*) Modulación  Modulación en amplitud de 
dos niveles.  (Conforme a EN 12253)  
D6a (*) Índice de modulación  0,5 … 0,9  (Conforme a EN 12253)  
D6b Patrón ocular  ≥ 90 % (tiempo) / ≥ 85 % 
(amplitud)  
D7 (*) Codificación de datos  FM0 
El bit «1» tiene transiciones 
solo al comienzo y al final 
del intervalo de bits. El bit 
«0» tiene una transición 
adicional en mitad del inter­
valo de bits en comparación 
con el bit «1».  (Conforme a EN 12253)  
D8 (*) Velocidad binaria  500 kbit/s  (Conforme a EN 12253)  
D8a Tolerancia del reloj de bit  superior a ± 100 ppm  (Conforme a EN 12253)  
D9 (*) Tasa de error de bit 
(B.E.R.) para comunicación  ≤ 10  -6 cuando la potencia 
incidente en la OBU 
(DSRC-VU) está en el 
rango dado por [D11a a 
D11b]  (Conforme a EN 12253)  
D10 Proceso de despertar a la 
OBU (DSRC-VU)  La OBU (DSRC-VU) des­
pertará al recibir una trama 
con 11 o más octetos (in­
cluido el preámbulo)  No se precisa ningún patrón de ac­
tivación especial 
La DSRC-VU puede despartarse al 
recibir una trama con menos de 11 
octetos 
(Conforme a EN 12253)  
D10a  Tiempo de comienzo má­
ximo  ≤ 5 ms  (Conforme a EN 12253)  
D11 Zona de comunicación  Región espacial dentro de la 
cual la B.E.R. alcanza el 
valor definido por D9a  (Conforme a EN 12253)  
D11a  (*) Límite superior de potencia 
en la zona de comunicación  – 24 dBm  (Conforme a EN 12253)  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 551  
N o de elemento  Parámetro  Valor(es)  Observación  
D11b  (*) Límite inferior de potencia 
en la zona de comunicación  Potencia incidente: 
– 43 dBm (dirección de má­
xima radiación) 
– 41 dBm (dentro de – 45° 
± 45° respecto del plano pa­
ralelo a la superficie de la 
carretera cuando la DSRC- 
VU se instala posterior­
mente en el vehículo (aci­
mut))  (Conforme a EN 12253) 
Requisito ampliando para ángulos 
horizontales hasta ± 45°, debido a 
los casos de uso definidos en este 
anexo.  
D12 (*) Nivel de potencia de corte 
de la OBU (DSRC-VU)  – 60 dBm  (Conforme a EN 12253)  
D13 Preámbulo  Preámbulo obligatorio  (Conforme a EN 12253)  
D13a  Longitud y patrón del 
preámbulo  16 bits ± 1 bit de bits «1» 
FM0 codificados  (Conforme a EN 12253)  
D13b  Forma de onda del preám­
bulo Una secuencia alternativa 
de niveles bajos y altos 
con una duración de pulso 
de 2 μs 
La tolerancia viene dada 
por D8a  (Conforme a EN 12253)  
D13c  Bits de cola  A la RSU (REDCR) se le 
permite transmitir un má­
ximo de 8 bits después del 
indicador de final. Para la 
OBU (DSRC-VU) no es ne­
cesario tener en cuenta es­
tos bits adicionales.  (Conforme a EN 12253)  
(*) Los parámetros de enlace descendente están sujetos a las pr uebas de conformidad de acuerdo con la prueba de parámetros per tinente 
de EN 300 674-1  
Cuadro 14.2  
Parámetros de enlace ascendente  
N o de elemento  Parámetro  Valor(es)  Observación  
U1 (*) Frecuencias de la subporta­
dora La OBU (DSRC-VU) debe 
soportar 1,5 MHz y 2,0 
MHz 
La RSU (REDCR) debe so­
portar 1,5 MHz o 2,0 MHz 
o ambos. U1-0: 1,5 MHz 
U1-1: 2,0 MHz  Selección de frecuencia subporta­
dora 
(1,5 MHz o 2,0 MHz) dependiendo 
del perfil EN 13372 elegido.  
U1a (*) Tolerancia de las frecuen­
cias de la suportadora  dentro de ± 0,1 %  (Conforme a EN 12253)  
U1b Uso de bandas laterales  Los mismos datos en ambas 
bandas  (Conforme a EN 12253)  
U2 (*) Máscara de espectro de la 
OBU transmisora (DSRC- 
VU) Conforme a EN12253 
1) Potencia fuera de la 
banda: 
véase ETSI EN 300674-1  (Conforme a EN 12253)  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 552  
N o de elemento  Parámetro  Valor(es)  Observación  
2) Potencia en la banda: 
[U4a] dBm en 500 kHz 
3) Emisiones en cualquier 
otro canal de enlace as­
cendente: 
U2(3)-1 = – 35 dBm en 
500 kHz  
U4a (*) E.I.R.P. máxima de banda 
lateral única (alineación óp­
tica) Dos opciones: 
U4a-0: – 14 dBm 
U4a-1: – 21 dBm  Según la especificación declarada y 
publicada por el diseñador del 
equipo  
U4b (*) E.I.R.P. máxima de banda 
lateral única (35°)  Dos opciones: 
— No aplicable 
— – 17 dBm  Según la especificación declarada y 
publicada por el diseñador del 
equipo  
U5 Polarización  Circular a izquierdas  (Conforme a EN 12253)  
U5a Polarización cruzada  XPD: 
En la dirección de máxima 
radiación: (REDCR) RSU r 
≥ 15 dB  
(DSRC-VU) OBU t ≥ 10 dB 
A -3 dB: (REDCR) RSU r ≥ 
10 dB 
(DSRC-VU) OBU t ≥ 6 dB  (Conforme a EN 12253)  
U6 Modulación de la subporta­
dora 2-PSK 
Datos codificados sincroni­
zados con la subportadora: 
las transiciones de los datos 
codificados coinciden con 
las transiciones de la sub­
portadora  (Conforme a EN 12253)  
U6b Ciclo de trabajo  Ciclo de trabajo: 
50 % ± α, α ≤ 5 %  (Conforme a EN 12253)  
U6c Modulación de la portadora  Multiplicación de la subpor­
tadora modulada con la 
portadora.  (Conforme a EN 12253)  
U7 (*) Codificación de datos  NRZI (Ninguna transición 
al comienzo del bit «1», 
transición al comienzo del 
bit «0», ninguna transición 
dentro del bit)  (Conforme a EN 12253)  
U8 (*) Velocidad de bit  250 kbit/s  (Conforme a EN 12253)  
U8a Tolerancia del reloj de bit  Dentro de los ± 1 000 ppm  (Conforme a EN 12253)  
U9 Tasa de error de bit (B.E.R.) 
por comunicaciones  ≤ 10  –6 (Conforme a EN 12253)  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 553  
N o de elemento  Parámetro  Valor(es)  Observación  
U11 Zona de comunicaciones  La región espacial en la que 
se sitúa la DSRC-VU de tal 
forma que sus transmisiones 
sean recibidas por el 
REDCR con una B.E.R. in­
ferior a la dada por U9a.  (Conforme a EN 12253)  
U12a  (*) Ganancia de conversión (lí­
miter inferior)  1 dB por cada banda lateral 
Rango del ángulo: circular­
mente simétrico alrededor 
de la dirección de máxima 
radiación y ± 35° 
y 
dentro de – 45° — + 45° 
respecto del plano paralelo 
a la superficie de la carre­
tera cuando la DSRC-VU se 
instala posteriormente en el 
vehículo (acimut))  Superior al rango de valores espe­
cificado para los ángulos horizonta­
les hasta ± 45°, debido a los casos 
de uso definidos en este anexo.  
U12b  (*) Ganancia de conversión (lí­
mite superior)  10 dB por cada banda late­
ral Inferior al rango de valores especi­
ficado para cada banda lateral den­
tro de un cono circular alrededor de 
la dirección de máxima radiación 
del ± ángulo de apertura de 45°  
U13 Preámbulo  Preámbulo obligatorio  (Conforme a EN 12253)  
U13a  Preámbulo 
Longitud y patrón  de 32 a 36 μs modulado 
solamente con la subporta­
dora, luego 8 bits de «0» 
codificados NRZI  (Conforme a EN 12253)  
U13b  Bits de cola  La DSRC-VU puede trans­
mitir un máximo de 8 bits 
tras el indicador de final. La 
RSU (REDCR) no necesita 
tener en cuenta estos bits 
adicionales.  (Conforme a EN 12253)  
(*) – Los parámetros de enlace ascendente están sujetos a las p ruebas de conformidad de acuerdo con la prueba de parámetros pe rtinente 
de EN 300 674-1  
5.3.3  Diseño de la antena  
5.3.3.1 Antena REDCR  
DSC_30 El diseño de la antena  REDCR  dependerá del diseño comer­
cial, ajustándose a los límites establecidos en el apartado 
5.3.2, que se ha adaptado para optimizar el rendimiento de 
lectura del  DSRC-REDCR  para el fin específico y las circuns­
tancias de lectura en las que está previsto que funcione el  
REDCR . 
5.3.3.2 Antena VU  
DSC_31 El diseño de la antena  DSRC-VU  dependerá del diseño co­
mercial, ajustándose a los límites establecidos en el apartado 
5.3.2, que se ha adaptado para optimizar el rendimiento de 
lectura del  DSRC-REDCR  para el fin específico y las circuns­
tancias de lectura en las que el  REDCR  está previsto que 
funcione.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 554  
DSC_32 La antena VU se instalará en el parabrisas delantero o c erca 
del parabrisas delantero del vehículo del modo especificado 
en la sección 5.1.  
DSC_33 En un entorno de pruebas de un taller (véase la sección 6.3), 
una antena DSRC-VU, instalada conforme a la sección 5.1, se 
conectará correctamente mediante una comunicación de en­
sayo estándar y permitirá realizar satisfactoriamente una trans ­
acción RTM del modo definido en este apéndice, a una dis­
tancia de entre 2 y 10 metros, durante un tiempo superior al 
99 % y con un promedio superior a 1 000 interrogaciones de 
lectura.  
5.4 Requisitos del protocolo DSRC para RTM  
5.4.1  Resumen  
DSC_34 El protocolo de transacciones para descargar  los Datos  a tra­
vés del enlace de interfaz DSRC de 5,8 GHz se ajustará a los 
pasos indicados a continuación. Este apartado describe un 
flujo de transacciones en condiciones ideales sin retransmisio­
nes ni interrupciones de la comunicación.  
NOTA La finalidad de la fase de inicialización (paso 1) es 
configurar la comunicación entre el  REDCR  y las DSRC-VU 
que hayan entrado en la zona de transacción (maestro-es­
clavo) DSRC de 5,8 GHz pero que aún no han establecido 
comunicación con el  REDCR , y notificar los procesos de la 
aplicación.  
— Paso 1  Inicialización. El  REDCR  envía una trama que 
contiene una «tabla de servicios de la baliza» (BST) 
que incluye los identificadores de aplicación (AID) en 
la lista de servicios que admite. En la aplicación RTM, 
consistirá simplemente en el servicio con el valor AID = 
2 (carga y flota). La  DSRC-VU  evalúa la BST recibida y 
responde (véase a continuación) con la lista de las apli­
caciones compatibles dentro del dominio de carga y flota 
o no responde en caso de que ninguna sea compatible. Si 
el REDCR  no ofrece AID = 2, la DSRC-VU no respon­
derá al REDCR.  
— Paso 2  L a DSRC-VU  envía una trama que contiene la 
solicitud de asignación de ventana privada.  
— Paso 3  E l REDCR  envía una trama que contiene una 
asignación de ventana privada.  
— Paso 4  L a DSRC-VU  utiliza la ventana privada asignada 
para enviar una trama con la tabla de servicios del 
vehículo (VST). Esta VST incluye una lista de todas las 
instanciaciones diferentes de la aplicación que admite esta  
DSRC-VU  en el marco de AID = 2. Las diferentes ins­
tanciaciones se identificarán mediante EID generadas de 
manera única, cada una de ellas asociada a un valor del 
parámetro de marca contextual de la aplicación que indica 
la aplicación y la norma que son compatibles.  
— Paso 5  A continuación, el  REDCR  analiza la VST que se 
le ofrece y, o bien finaliza la conexión (RELEASE) por­
que no le interesa nada de lo que ofrece la VST (es decir, 
está recibiendo una VST de una  DSRC-VU  que no admite 
la transacción RTM), o bien, si recibe una VST adecuada, 
inicia una instanciación de la aplicación.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 555  
— Paso 6  Para llevar esto a cabo, el REDCR enviará una 
trama que contiene el comando de recuperar los datos 
RTM e identifica la instanciación de la aplicación RTM 
al especificar el identificador correspondiente a la instan­
ciación de la aplicación RTM (tal como haya sido espe­
cificado por la DSRC-VU en la VST) y asignará una 
ventana privada.  
— Paso 7  L a DSRC-VU  utiliza la ventana privada recién 
asignada para enviar una trama que contiene el identifi­
cador direccionado correspondiente a la instanciación de 
la aplicación RTM tal como se suministró en la VST, 
seguido del atributo  RtmData  (elemento de datos útiles + 
elemento de seguridad).  
— Paso 8  Si existen varios servicios solicitados, el valor «n» 
cambia al siguiente número de referencia de servicio y se 
repite el proceso.  
— Paso 9  E l REDCR  confirma la recepción de los datos 
enviando una trama que contiene el comando RELEASE 
a la DSRC-VU  para finalizar la sesión O BIEN, si no 
consigue validar una recepción correcta de la LDPU, 
vuelve al paso 6.  
Véase en la figura 14.6 una descripción gráfica del protocolo 
de transacción.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 556  
Figura 14.6  
Flujo de procesos de RTM a través de una DSRC de 5,8 GHz
  
5.4.2  Comandos  
DSC_35 Los siguientes comandos constituyen las únicas funciones  
utilizadas en una fase de transacción RTM.  
— INITIALISATION.request : comando, enviado desde el 
REDCR en forma de difusión, con la definición de las 
aplicaciones que admite el REDCR.  
— INITIALISATION.response : respuesta desde la DSRC- 
VU que confirma la conexión y contiene una lista de las 
instancias de aplicación admitidas con las características y 
la información de cómo direccionarlas (EID).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 557  
— GET.request : comando, enviado desde  el REDCR  a  l a  
DSRC-VU , que especifica la instanciación de la aplicación 
que debe direccionarse por medio de un EID definido, tal 
y como se recibió en la VST, indicando a la  DSRC-VU  
que envíe los atributos seleccionados junto con  los Datos . 
El objetivo del comando GET es que  el REDCR  obtenga  
los Datos  de la  DSRC-VU . 
— GET.response : respuesta de la DSRC-VU que contiene  
los Datos  solicitados.  
— ACTION.request ECHO : comando que indica a la  
DSRC-VU  que devuelva los datos desde la  DSRC-VU al 
REDCR . El objetivo del comando ECHO es permitir a los 
talleres o centros de homologación que comprueben que 
el enlace DSRC funciona sin necesidad de acceder a las 
credenciales de seguridad.  
— ACTION .response ECHO: respuesta desde la DSRC VU 
al comando ECHO.  
— EVENT_REPORT.request  RELEASE: comando que in­
dica a la  DSRC-VU  que la transacción ha finalizado. El 
objetivo del comando RELEASE es finalizar la sesión 
con la  DSRC-VU . Tras recibir el comando RELEASE, 
la DSRC-VU  no responderá a ninguna otra interrogación 
durante la conexión actual. Adviértase que, según EN 
12834, una DSRC-VU no se conectará dos veces con el 
mismo interrogador a no ser que haya estado fuera de la 
zona de comunicación durante 255 segundos o se cambie 
el ID de la baliza del interrogador.  
5.4.3  Secuencia de comandos de interrogación  
DSC_36 Desde el punto de vista de la secuencia de comandos y re s­
puestas, la transacción se describe del modo siguiente:  
Secuencia  Emisor  Receptor  Descripción  Acción  
1 REDCR  >  DSRC-VU  Inicialización del enlace de 
comunicación — Solicitud  El REDCR difunde la BST  
2 DSRC-VU  >  REDCR  Inicialización del enlace de 
comunicación — Respuesta  Si la BST admite AID=2, en ­
tonces la DSRC-VU solicita 
una ventana privada  
3 REDCR  >  DSRC-VU  Concede una ventana pri­
vada  Envía una trama que contiene 
la asignación de la ventana 
privada  
4 DSRC-VU  >  REDCR  Envía una VST  Envía una trama que com ­
prende una VST  
5 REDCR  >  DSRC-VU  Envía GET.request de da­
tos en el Atributo para el 
EID específico  
6 DSRC-VU  >  REDCR  Envía GET.response con el 
Atributo solicitado para el 
EID específico  Envía el atributo (DatosRTM, 
DatosOWS…) con datos para 
el EID específico  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 558  
Secuencia  Emisor  Receptor  Descripción  Acción  
▼M1 
7 REDCR  >  DSRC-VU  Envía GET.request para da­
tos de otro Atributo (si pro­
cede)  
▼B 
8 DSRC-VU  >  REDCR  Envía GET.response con el 
Atributo solicitado  Envía el Atributo con los da ­
tos para el EID específico  
9 REDCR  >  DSRC-VU  Confirma la recepción co­
rrecta de los datos  Envía el comando RE­
LEASE, que cierra la trans­
acción  
10 DSRC-VU  Cierra la transacción  
En las cláusulas 5.4.7 y 5.4.8 se ofrece un ejemplo de la 
secuencia de transacción y el contenido de las tramas 
intercambiadas.  
5.4.4  Estructuras de los datos  
DSC_37 La estructura semántica de  los Datos  cuando pasan por la 
interfaz DSRC de 5,8 GHz se ajustará a lo descrito en el 
presente apéndice. El modo en que se estructuran estos datos 
se especifica en el presente apartado.  
DSC_38 Los datos útiles (datos RTM) consisten en la concatenaci ón 
de 
1. datos EncryptedTachographPayload, que constituye el ci­
frado de TachographPayload definido en el apartado 5.4.5 
de ASN.1. El método de cifrado se describe en el apén­
dice 11;  
2. DSRCSecurityData, especificado en el apéndice 11.  
DSC_39 Los datos RTM se están direccionando como Atributo RTM =  
1 y se transfieren en el contenedor RTM = 10.  
DSC_40 La marca contextual de RTM identificará la parte estánda r 
compatible en la serie de normas TARV (RTM se corres­
ponde con la parte 9).  
La definición del módulo ASN.1 para los datos DSRC dentro 
de la aplicación RTM se establece del modo siguiente:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 559
  
► (1) (2) M1 
► (3) M3 ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 560
  
5.4.5  Elementos de RtmData, acciones realizadas y definiciones  
DSC_41 Los valores de datos que debe calcular la VU y utilizar para 
actualizar los datos protegidos en la DSRC-VU se calcularán 
de acuerdo con las reglas definidas en el cuadro 14.3:  
▼M3 
Cuadro 14.3  
Elementos de RtmData, acciones realizadas y definiciones  
1) 
Elemento de datos RTM  2) 
Acción realizada por la VU  3) 
Definición de ASN.1 de los datos  
RTM1 
Matrícula 
del vehículo  La VU ajustará el valor del 
elemento de datos RTM1  
tp15638VehicleRegistration ­
Plate  a partir del valor regis­
trado del tipo de datos  
VehicleRegistrationIdentifica ­
tion tal como se define en el 
apéndice 1  VehicleRegistra ­
tionIdentification  Matrícula del vehículo 
expresada como una ca­
dena de caracteres  tp15638VehicleRegistration­
Plate LPN, 
–Matrícula del vehículo con la 
estructura de datos de 
ISO 14906, pero con la si­
guiente limitación para la 
aplicación RTM: 
la SECUENCIA comienza con 
el código de país, seguido de 
un indicador alfabético, se­
guido del número de matrícula 
propiamente dicho, 
que tiene siempre 14 octetos 
(rellenados con ceros), de ma­
nera que la longitud del tipo 
LPN es siempre de 17 octetos 
(no es necesario un determi­
nante de longitud), de los que 
14 son el «verdadero» número 
de matrícula.  
RTM2 
Incidente de exceso de 
velocidad  La VU generará un valor 
booleano 
para el elemento de datos 
RTM2 
tp15638SpeedingEvent. 
La VU calculará el valor 
tp15638SpeedingEvent a par­
tir de los incidentes de ex­
ceso de velocidad que haya 
registrado en los diez últimos 
días, según se definen en el 
anexo I C.  1 (VERDADERO): si el 
incidente más reciente de 
exceso de velocidad ter­
minó en los diez últimos 
días o está todavía en 
curso; 
0 (FALSO): en cualquier 
otro caso.  tp15638SpeedingEvent BOO­
LEAN,  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 561  
1) 
Elemento de datos RTM  2) 
Acción realizada por la VU  3) 
Definición de ASN.1 de los datos  
RTM3 
Conducción sin 
una tarjeta válida  La VU generará un valor 
booleano 
para el elemento de datos 
RTM3 
tp15638DrivingWithoutVa­
lidCard. 
La VU asignará el valor 
VERDADERO a la variable 
tp15638DrivingWithoutVa­
lidCard si en los diez últimos 
días ha registrado por lo me­
nos un incidente de conduc­
ción sin tarjeta adecuada, se­
gún se define en el 
anexo I C.  1 (VERDADERO): si el 
incidente más reciente de 
conducción sin tarjeta 
adecuada terminó en los 
diez últimos días o está 
todavía en curso; 
0 (FALSO): en cualquier 
otro caso.  tp15638DrivingWithoutValid­
Card 
BOOLEAN,  
RTM4 
Tarjeta de conductor 
válida  La VU generará un valor 
booleano para el elemento de 
datos RTM4 
tp15638DriverCard basán­
dose en la tarjeta de conduc­
tor válida insertada en la ra­
nura del conductor.  1 (VERDADERO): si en 
la ranura del conductor 
de la VU no hay inser­
tada una tarjeta de con­
ductor válida; 
0 (FALSO): si en la ra­
nura del conductor de la 
VU hay insertada una 
tarjeta de conductor vá­
lida. tp15638DriverCard BOO­
LEAN,  
RTM5 
Inserción de tarjeta du ­
rante 
la conducción  La VU generará un valor 
booleano para el elemento de 
datos RTM5 tp15638CardIn­
sertion. 
La VU asignará el valor 
VERDADERO a la variable 
tp15638CardInsertion si en 
los diez últimos días ha re­
gistrado por lo menos un in­
cidente de inserción de tarjeta 
durante la conducción, según 
se define en el anexo I C.  1 (VERDADERO): si el 
incidente más reciente de 
inserción de tarjeta du­
rante la conducción se 
ha producido en los diez 
últimos días; 
0 (FALSO): en cualquier 
otro caso.  tp15638CardInsertion BOO­
LEAN,  
RTM6 
Error de datos de movi ­
miento  La VU generará un valor 
booleano 
para el elemento de datos 
RTM6. 
La VU asignará el valor 
VERDADERO a la variable 
tp15638MotionDataError si 
en los diez últimos días ha 
registrado por lo menos un 
incidente de error de datos de 
movimiento, según se define 
en el anexo I C.  1 (VERDADERO): si el 
incidente más reciente de 
error de datos de movi­
miento terminó en los 
diez últimos días o está 
todavía en curso; 
0 (FALSO): en cualquier 
otro caso.  tp15638MotionDataError 
BOOLEAN,  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 562  
1) 
Elemento de datos RTM  2) 
Acción realizada por la VU  3) 
Definición de ASN.1 de los datos  
RTM7 
Conflicto de movimiento 
del vehículo  La VU generará un valor 
booleano 
para el elemento de datos 
RTM7. 
La VU asignará el valor 
VERDADERO a la variable 
tp15638VehicleMotionCon­
flict si en los diez últimos 
días ha registrado por lo me­
nos un incidente de conflicto 
de movimiento del vehículo.  1 (VERDADERO): si el 
incidente más reciente de 
conflicto de movimiento 
del vehículo terminó en 
los diez últimos días o 
está todavía en curso; 
0 (FALSO): en cualquier 
otro caso.  tp15638VehicleMotionConflict 
BOOLEAN,  
RTM8 
Tarjeta del segundo 
conductor  La VU generará un valor 
booleano 
para el elemento de datos 
RTM8 basándose en el 
anexo I C (datos de actividad 
del conductor EN EQUIPO y 
SEGUNDO CONDUCTOR). 
Si está insertada una tarjeta 
de segundo conductor válida, 
la VU ajustará el valor de 
RTM8 en VERDADERO.  1 (VERDADERO): si en 
la VU hay insertada una 
tarjeta de segundo con­
ductor válida; 
2 (FALSO): si en la VU 
no hay insertada una 
tarjeta de segundo con­
ductor válida.  tp156382ndDriverCard BOO­
LEAN,  
RTM9 
Actividad actual  La VU generará un valor 
booleano 
para el elemento de datos 
RTM9. 
Si la actividad actual se re­
gistra en la VU como cual­
quier actividad distinta de 
CONDUCCIÓN según se 
define en el anexo I C, la 
VU ajustará el valor de 
RTM9 en VERDADERO.  1 (VERDADERO): se­
leccionada 
otra actividad 
0 (FALSO): se ha selec­
cionado conducción  tp15638CurrentActivityDri­
ving 
BOOLEAN  
RTM10 
Última sesión cerrada  La VU generará un valor 
booleano para el elemento de 
datos RTM10. 
Si no se cerró correctamente 
la última sesión de la tarjeta 
tal y como se define en el 
anexo I C, la VU ajustará el 
valor de RTM10 en VER­
DADERO.  1 (VERDADERO): al 
menos una de las tarjetas 
insertadas ha activado un 
incidente de error al ce­
rrar la última sesión de 
la tarjeta; 
0 (FALSO): ninguna de 
las tarjetas insertadas ha 
activado un incidente de 
error al cerrar la última 
sesión de la tarjeta.  tp15638LastSessionClosed 
BOOLEAN  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 563  
1) 
Elemento de datos RTM  2) 
Acción realizada por la VU  3) 
Definición de ASN.1 de los datos  
RTM11 
Interrupción del sumi ­
nistro 
eléctrico  La VU generará un valor 
entero 
para el elemento de datos 
RTM11. 
La VU asignará un valor a la 
variable tp15638PowerSup­
plyInterruption igual al nú­
mero de incidentes de inte­
rrupción del suministro eléc­
trico almacenados en ella en 
los diez últimos días, según 
se definen en el anexo I C. 
Si en la VU no se ha regis­
trado ningún incidente de in­
terrupción del suministro 
eléctrico en los diez últimos 
días, la VU ajustará el valor 
de RTM11 en 0.  Número de incidentes de 
interrupción del sumi­
nistro eléctrico registra­
dos en los diez últimos 
días. tp15638PowerSupplyInterrup­
tion 
INTEGER (0..127),  
RTM12 
Fallo de sensor  La VU generará un valor 
entero para el elemento de 
datos RTM12. 
La VU asignará a la variable 
sensorFault un valor de: 
— 1 si un incidente de tipo 
«35»H fallo de sensor 
terminó en los diez últi­
mos días o está todavía 
en curso, 
— 2 si un incidente de tipo 
fallo del receptor GNSS 
(interno o externo con 
valores de enumeración 
«36»H o 
«37»H) terminó en los 
diez últimos días o está 
todavía en curso, 
— 3 si un incidente de tipo 
«0E»H error de comuni­
cación con el dispositivo 
GNSS externo terminó 
en los diez últimos días o 
está todavía en curso, 
— 4 si tanto el fallo de sen­
sor como los fallos del 
receptor GNSS termina­
ron en los diez últimos 
días o están todavía en 
curso, 
— 5 si tanto el fallo de sen­
sor como el incidente de 
error de comunicación 
con el dispositivo GNSS 
externo terminaron en los 
diez últimos días o están 
todavía en curso,  –Fallo del sensor un oc­
teto según el diccionario 
de datos  tp15638SensorFault INTEGER 
(0..255),  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 564  
1) 
Elemento de datos RTM  2) 
Acción realizada por la VU  3) 
Definición de ASN.1 de los datos  
— 6 si tanto el fallo del re­
ceptor GNSS como el 
incidente de error de co­
municación con el dis­
positivo GNSS externo 
terminaron en los diez 
últimos días o están to­
davía en curso, 
— 7 si los tres fallos de sen­
sor terminaron en los 
diez últimos días o están 
todavía en curso. 
Si ningún incidente terminó 
en los diez últimos días o 
está todavía en curso, la VU 
ajustará el valor de RTM12 
en 0.  
RTM13 
Ajuste de la hora  La VU generará un valor 
entero (timeReal del apén­
dice 1) para el elemento de 
datos RTM13 basándose en 
la presencia de datos de 
ajuste de la hora según se 
definen en el anexo I C. 
La VU ajustará el valor de 
RTM13 en la hora a la que se 
haya producido el último in­
cidente de datos de ajuste de 
la hora. 
Si en los datos de la VU no 
hay ningún incidente de 
ajuste de la hora según se 
define en el anexo I C, la 
VU ajustará el valor de 
RTM13 en 0.  oldTimeValue del ajuste 
de la hora más reciente.  tp15638TimeAdjustment 
INTEGER(0..4294967295),  
RTM14 
Intento de violación 
de la seguridad  La VU generará un valor 
entero (timeReal del apén­
dice 1) para el elemento de 
datos RTM14 basándose en 
la presencia de un incidente 
de intento de violación de la 
seguridad según se define en 
el anexo I C. 
La VU ajustará el valor de la 
hora del último incidente de 
intento de violación de la 
seguridad que haya regis­
trado. 
Si en los datos de la VU no 
hay ningún incidente de in­
tento de violación de la se­
guridad según se define en el 
anexo I C, la VU ajustará el 
valor de RTM14 en 0.  Hora de comienzo del 
último incidente almace­
nado de intento de vio­
lación de la seguridad.  tp15638LatestBreachAttempt 
INTEGER(0..4294967295),  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 565  
1) 
Elemento de datos RTM  2) 
Acción realizada por la VU  3) 
Definición de ASN.1 de los datos  
RTM15 
Último calibrado  La VU generará un valor 
entero (timeReal del apén­
dice 1) para el elemento de 
datos RTM15 basándose en 
la presencia de datos del úl­
timo calibrado según se de­
fine en el anexo I C y el 
apéndice 1. 
La VU ajustará el valor de 
RTM15 en el oldTimeValue 
del registro de calibrado más 
reciente. 
Si no ha habido ningún cali­
brado, la VU ajustará el valor 
de RTM15 en 0.  oldTimeValue del regis­
tro de calibrado más 
reciente.  tp15638LastCalibrationData 
INTEGER(0..4294967295),  
RTM16 
Calibrado anterior  La VU generará un valor 
entero (timeReal del apén­
dice 1) para el elemento de 
datos RTM16 basándose en 
el registro de calibrado ante­
rior al último calibrado. 
La VU ajustará el valor de 
RTM16 en el oldTimeValue 
del registro de calibrado an­
terior al último calibrado. 
Si no ha habido ningún cali­
brado anterior, la VU ajustará 
el valor de RTM16 en 0.  oldTimeValue del regis­
tro de calibrado anterior 
al registro de calibrado 
más reciente.  tp15638PrevCalibrationData 
INTEGER(0..4294967295),  
RTM17 
Fecha de conexión 
del tacógrafo  La VU generará un valor 
entero (timeReal del apén­
dice 1) para el elemento de 
datos RTM17. 
La VU ajustará el valor de 
RTM17 en la fecha del pri­
mer calibrado de la VU en el 
vehículo actual. 
La VU extraerá estos datos 
de VuCalibrationData (apén­
dice 1) a partir de vuCali­
brationRecords con Calibra­
tionPurpose igual a: «03»H 
Si no ha habido ningún cali­
brado anterior, la VU ajustará 
el valor de RTM17 en 0.  Fecha del primer cali­
brado de la VU en el 
vehículo actual.  tp15638DateTachoConnected 
INTEGER(0..4294967295),  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 566  
1) 
Elemento de datos RTM  2) 
Acción realizada por la VU  3) 
Definición de ASN.1 de los datos  
RTM18 
Velocidad actual  La VU generará un valor 
entero 
para el elemento de datos 
RTM18. 
La VU ajustará el valor de 
RTM18 en la última veloci­
dad actual registrada en el 
momento de la última actua­
lización de los RtmData.  Última velocidad actual 
registrada  tp15638CurrentSpeed INTE­
GER (0..255),  
RTM19 
Sello de tiempo  La VU generará un valor 
entero para el elemento de 
datos RTM19 (timeReal del 
apéndice 1). 
La VU ajustará el valor de 
RTM19 en la hora de la úl­
tima actualización de los 
RtmData.  Sello de tiempo del re­
gistro 
TachographPayload ac­
tual tp15638Timestamp 
INTEGER(0..4294967295),  
RTM20 
Hora a la que estaba 
disponible la última po ­
sición del vehículo au ­
tenticada  La VU generará un valor 
entero (timeReal del apén­
dice 1) para el elemento de 
datos RTM20. 
La VU ajustará el valor de 
RTM20 en la hora a la que 
estaba disponible la última 
posición del vehículo auten­
ticada a partir del receptor 
GNSS. 
Si en ningún momento ha 
estado disponible una posi­
ción del vehículo autenticada 
a partir del receptor GNSS, la 
VU ajustará el valor de 
RTM20 en 0.  Sello de tiempo de la 
última posición del ve­
hículo autenticada  tp15638LatestAuthenticatedPo­
sition 
INTEGER(0..4294967295),  
RTM21 
Tiempo de conducción 
continua  La VU generará un valor 
entero para el elemento de 
datos RTM21. 
La VU ajustará el valor de 
RTM21 en el tiempo de 
conducción continua en curso 
del conductor.  Tiempo de conducción 
continua del conductor, 
codificado como valor 
entero. 
Longitud: 1 byte 
Resolución: 2 minutos/ 
bit 
Sin desfase 
Intervalo de datos: 0 
a 250 
Un valor de 250 indicará 
que el tiempo de con­
ducción continua del 
conductor es igual o su­
perior a quinientos mi­
nutos. 
Los valores 251 a 254 
no se utilizan. 
El valor 255 indica que 
no hay información 
disponible.  tp15638ContinuousDriving­
Time INTEGER(0..255),  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 567  
1) 
Elemento de datos RTM  2) 
Acción realizada por la VU  3) 
Definición de ASN.1 de los datos  
RTM22 
Tiempo de conducción 
continua más largo en el 
turno RTM en curso y 
en el anterior, calculado 
conforme a la adenda 
del apéndice 14  La VU generará un valor 
entero para el elemento de 
datos RTM22. 
La VU ajustará el valor de 
RTM22 en el más largo de 
los dos tiempos de conduc­
ción diarios del conductor, 
que será, o bien el turno 
RTM en curso, o bien el 
anterior.  Tiempo de conducción 
diario del conductor, co­
dificado como valor en­
tero. 
Longitud: 1 byte 
Resolución: 4 minutos/ 
bit 
Sin desfase 
Intervalo de datos: 0 
a 250 
Un valor de 250 indicará 
que el tiempo de con­
ducción diario del con­
ductor es igual o supe­
rior a mil minutos. 
Los valores 251 a 254 
no se utilizan. 
El valor 255 indica que 
no hay información 
disponible.  tp15638DailyDrivingTimeShift 
INTEGER(0..255),  
RTM23 
Tiempo de conducción 
diario más largo en la 
semana en curso, calcu ­
lado conforme a la 
adenda del apéndice 14  La VU generará un valor 
entero para el elemento de 
datos RTM23. 
La VU ajustará el valor de 
RTM23 en el tiempo de 
conducción diario más largo 
del conductor, que será, o 
bien el turno RTM en curso, 
o bien cualquier turno RTM 
completado que haya comen­
zado o terminado en la se­
mana en curso.  Tiempo de conducción 
diario del conductor, co­
dificado como valor en­
tero. 
Longitud: 1 byte 
Resolución: 4 minutos/ 
bit 
Sin desfase 
Intervalo de datos: 0 
a 250 
Un valor de 250 indicará 
que el tiempo de con­
ducción diario del con­
ductor es igual o supe­
rior a mil minutos. 
Los valores 251 a 254 
no se utilizan. 
El valor 255 indica que 
no hay información 
disponible.  tp15638DailyDrivingTime­
Week INTEGER(0..255),  
RTM24 
Tiempo de conducción 
semanal, calculado con ­
forme a la adenda del 
apéndice 14  La VU generará un valor 
entero para el elemento de 
datos RTM24. 
La VU ajustará el valor de 
RTM24 en el tiempo de 
conducción semanal del 
conductor.  Tiempo de conducción 
semanal del conductor, 
codificado como valor 
entero. 
Longitud: 1 byte 
Resolución: 20 minutos/ 
bit 
Sin desfase 
Intervalo de datos: 0 
a 250 
Un valor de 250 indicará 
que el tiempo de con­
ducción semanal del 
conductor es igual o su­
perior a cinco mil minu­
tos. 
Los valores 251 a 254 
no se utilizan. 
El valor 255 indica que 
no hay información 
disponible.  tp15638WeeklyDrivingTime 
INTEGER(0..255),  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 568  
1) 
Elemento de datos RTM  2) 
Acción realizada por la VU  3) 
Definición de ASN.1 de los datos  
RTM25 
Tiempo de conducción 
bisemanal, calculado 
conforme a la adenda 
del apéndice 14  La VU generará un valor 
entero para el elemento de 
datos RTM25. 
La VU ajustará el valor de 
RTM25 en el tiempo de 
conducción bisemanal del 
conductor.  Tiempo de conducción 
bisemanal del conductor, 
codificado como valor 
entero. 
Longitud: 1 byte 
Resolución: 30 minutos/ 
bit 
Sin desfase 
Intervalo de datos: 0 
a 250 
Un valor de 250 indicará 
que el tiempo de con­
ducción bisemanal del 
conductor es igual o su­
perior a siete mil qui­
nientos minutos. 
Los valores 251 a 254 
no se utilizan. 
El valor 255 indica que 
no hay información 
disponible.  tp15638FortnightlyDriving­
Time INTEGER(0..255),  
Nota: RTM22, RTM23, RTM24 y RTM25 se computarán conforme a la a denda 
del presente apéndice.  
▼B 
5.4.6  Mecanismo de transferencia de datos  
DSC_42 Los datos útiles definidos anteriormente son solicitados  por el 
REDCR tras la fase de inicialización y, a continuación, son 
transmitidos por la  DSRC-VU  en la ventana asignada. El 
REDCR utiliza el comando GET para recuperar datos.  
▼M1 
DSC_43 En todos los intercambios DSRC, los datos se codificarán  
utilizando PER (Reglas de Codificación por Paquetes) NO 
ALINEADAS, excepto por lo que se refiere a
  
y
 , que se codifi­
carán utilizando OER (Reglas de Codificación por Octetos), 
definidas en la norma ISO/CEI 8825-7, Rec. ITU-T X.696.  
▼B 
5.4.7  Descripción detallada de la transacción DSRC  
DSC_44 La inicialización se lleva a cabo conforme a DSC_44 — 
DSC_48 y las cuadros 14.4 — 14.9. En la fase de inicializa­
ción, el REDCR comienza enviando una trama que contiene 
una BST (tabla de servicios de la baliza) según EN 12834 y 
EN 13372, 6.2, 6.3, 6.4 y 7.1 con los valores que se especi­
fican a continuación en el cuadro 14.4.  
Cuadro 14.4  
Inicialización: valores de trama BST  
Campo  Configuración  
Link Identifier  Dirección de difusión  
BeaconId  Según EN 12834  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 569  
Campo  Configuración  
Time  Según EN 12834  
Profile  Sin extensión, deberá usarse 
0 o 1  
MandApplications  Sin extensión, EID no pre­
sente, Parámetro no presente, 
AID=2 Carga y flota  
NoMandApplications  No presente  
ProfileList  Sin extensión, número de 
perfiles en la lista = 0  
Fragmentation header  Sin fragmentación  
Layer 2 settings  PDU de comandos, comando 
UI 
En el siguiente cuadro 14.5 se recoge un ejemplo práctico de 
los valores especificados en el cuadro 14.4, con una indica­
ción de las codificaciones de bits.  
Cuadro 14.5  
Inicialización: ejemplo del contenido de la trama BST
 No octeto 
Atributo/Campo  Bits en octeto  Descripción  
1 FLAG
  Indicador de comienzo  
2 Broadcast ID
  Dirección de difusión  
3 MAC Control Field
  PDU de comandos  
4 LLC Control field
  Comando UI  
5 Fragmentation header
  Sin fragmentación  
6 BST
  Solicitud de inicialización  
SEQUENCE {  
OPTION indicator 
BeaconID SEQUENCE { 
ManufacturerId INTEGER (0..65535)
  Aplicaciones no obligato­
rias no presentes
  
Identificador del fabri­
cante  
7
 
8
 
IndividualID INTEGER (0..134217727) 
}
 ID de 27 bits disponible 
para el fabricante  
9
 
10
 
11
 ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 570
 No octeto 
Atributo/Campo  Bits en octeto  Descripción  
12 Time INTEGER (0..4294967295)
  Hora real UNIX de 32 
bits 
13
 
14
 
15
 
16 Profile INTEGER (0..127,...)
  Sin extensión. Perfil de 
ejemplo 0  
17 MandApplications SEQUENCE 
(SIZE(0..127,...)) 
OF {
  Sin extensión, número de 
MandApplications = 1  
18 SEQUENCE {  
OPTION indicator
  EID no presente  
OPTION indicator
  Parámetro no presente  
AID DSRCApplicationEntityID } }
  Sin extensión. AID = 2 
Carga y flota  
19 ProfileList SEQUENCE (0..127,...) OF 
Profile }
  Sin extensión, número de 
perfiles en lista = 0  
20 FCS
  Secuencia de control de 
trama  
21
 
22 Flag
  Indicador de final  
DSC_45 Una  DSRC-VU , al recibir una BST, solicita la asignación de 
una ventana privada, según lo especificado por EN 12795 y 
EN 13372, 7.1.1, sin valores RTM específicos. El cuadro 14.6 
ofrece un ejemplo de codificación de bits.  
Cuadro 14.6  
Inicialización: contenido de la trama que solicita la asignación de una ventana privada
 No octeto 
Atributo/Campo  Bits en octeto  Descripción  
1 FLAG
  Indicador de comienzo  
2 Private LID
  Dirección de enlace de la 
DSRC-VU específica  
3
 
4
 
5
 
6 MAC Control field
  Solicitud de ventana pri­
vada  
7 FCS
  Secuencia de control de 
trama  
8
 
9 Flag
  Indicador de final  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 571  
DSC_46 A continuación, el REDCR responde asignando una ventana 
privada, según lo especificado por EN 12795 y EN 13372, 
7.1.1, sin valores RTM específicos.  
El cuadro 14.7 ofrece un ejemplo de codificación de bits.  
Cuadro 14.7  
Inicialización: contenido de la trama de asignación de una ventana privada
 No octeto 
Atributo/Campo  Bits en octeto  Descripción  
1 FLAG
  Indicador de comienzo  
2 Private LID
  Dirección de enlace de la 
DSRC-VU específica  
3
 
4
 
5
 
6 MAC Control field
  Asignación de ventana 
privada  
7 FCS
  Secuencia de control de 
trama  
8
 
9 Flag
  Indicador de final  
DSC_47 La  DSRC-VU , al recibir la asignación de una ventana privada, 
envía su VST (tabla de servicios del vehículo) según se define 
en EN 12834 y EN 13372, 6.2, 6.3, 6.4 y 7.1 con los valores 
especificados en el cuadro 14.8, utilizando la ventana de 
transmisión asignada.  
Cuadro 14.8  
Inicialización: valores de trama VST  
Campo  Configuración  
Private LID  Según EN 12834  
VST parameters  Relleno=0, luego para cada aplicación 
compatible: EID presente, parámetro 
presente, AID=2, EID tal como sea 
generado por la OBU  
Parameter  Sin extensión, contiene la marca de 
contexto de RTM  
ObeConfiguration  El campo opcional ObeStatus puede 
estar presente, pero no será utilizado 
por el REDCR  
Fragmentation header  Sin fragmentación  
Layer 2 settings  PDU de comandos, comando UI  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 572  
DSC_48 La  DSRC-VU  deberá ser compatible con la aplicación «Carga 
y flota», identificada mediante el identificador de aplicación 
«2». Puede que se admitan otros identificadores de aplicación, 
pero no aparecerán en esta VST, ya que la BST solo requiere 
AID = 2. El campo «Aplicaciones» contiene una lista de las 
instancias de aplicación admitidas en la  DSRC-VU . Por cada 
instanciación de aplicación admitida, se da una referencia a la  
norma correspondiente, formada por una marca contextual 
Rtm, que se compone de un IDENTIFICADOR DE OBJE­
TOS que representa la norma relacionada, su parte (9 para 
RTM) y posiblemente su versión, más un EID que genera la 
DSRC-VU y va asociado a esa instancia de aplicación.  
En el cuadro 14.9 se recoge un ejemplo práctico de los va­
lores especificados en el cuadro 14.8, con una indicación de 
las codificaciones de bits.  
▼M3 
Cuadro 14.9  
Inicialización: ejemplo del contenido de la trama VST
 Octeto 
Atributo/Campo  Bits en octeto  Descripción  
1 FLAG  0111 1110  Indicador de comienzo  
2 Private LID  xxxx xxxx  Dirección de enlace de la 
DSRC-VU específica  
3 xxxx xxxx  
4 xxxx xxxx  
5 xxxx xxxx  
6 MAC Control field  1100 0000  PDU de comandos  
7 LLC Control field  0000 0011  Comando UI  
8 Fragmentation header  1xxx x001  Sin fragmentación  
9 VST 
SEQUENCE { 
Fill BIT STRING (SIZE(4))  1001  Respuesta de inicializa­
ción 
0000  No usado y fijado en 0  
10 Profile INTEGER (0..127,...) 
Applications SEQUENCE OF {  0000 0000  Sin extensión Perfil de 
ejemplo 0 
Sin extensión, 1 aplica­
ción 11 0000 0001  
12 SEQUENCE { 
OPTION indicator 
OPTION indicator 
AID DSRCApplicationEntityID  1 EID presente  
1 Parámetro presente  
00 0010  Sin extensión AID = 2 
Carga y flota  
13 EID Dsrc-EID  xxxx xxxx  Definido dentro de la 
OBU e identifica la ins­
tancia de la aplicación.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 573
 Octeto 
Atributo/Campo  Bits en octeto  Descripción  
14 Parameter Container {  0000 0010  Sin extensión, Opción de 
contenedor = 02, 
Cadena de octetos  
15 0000 0110  Sin extensión, longitud de 
la marca de contexto de 
Rtm = 6  
16 Rtm-ContextMark ::= SEQUENCE { 
StandardIdentifier  0000 0101  El primer octeto es 05H, 
que es su longitud. 
Los cinco octetos siguien­
tes codifican el identifica­
dor de objeto de la norma, 
parte y versión admitidas. 
{ISO (1) Norma (0) 
TARV (15638) parte9(9) 
Versión2 (2)}  17 standardIdentifier  0010 1000  
18 1111 1010  
19 0001 0110  
20 0000 1001  
21 0000 0010  
22 ObeConfiguration Sequence { 
OPTION indicator  0 ObeStatus no presente  
EquipmentClass INTEGER (0..32767)  xxx xxxx  Esta campo se utilizará 
para 
23 xxxx xxxx  las indicaciones del fabri­
cante relativas a la versión 
del software /hardware  de 
la interfaz DSRC  
24 ManufacturerId INTEGER (0..65535)  xxxx xxxx  Identificador del fabri­
cante para la DSRC-VU 
tal como se describe en 
el registro ISO 14816  25 xxxx xxxx  
26 FCS  xxxx xxxx  Secuencia de control de 
trama  
27 xxxx xxxx  
28 Flag  0111 1110  Indicador de final  
▼B 
DCS_49 A continuación el REDCR lee los datos y envía un comando  
GET, conforme al comando GET definido en EN 13372, 6.2, 
6.3, 6.4 y EN 12834, con los valores especificados en el 
cuadro 14.10.  
Cuadro 14.10  
Presentación: valores de trama de una petición GET  
Campo  Configuración  
Invoker Identifier (IID)  No presente  
Link Identifier (LID)  Dirección de enlace de la DSRC-VU 
específica  
Chaining  N o  
Element Identifier (EID)  Según se especifica en la VST. Sin 
extensión  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 574  
Campo  Configuración  
Access Credentials  N o  
AttributeIdList  Sin extensión, 1 atributo, AttributeID 
= 1 (RtmData)  
Fragmentation  N o  
Layer2 settings  PDU de comandos, comando ACn 
sondeado  
El cuadro 14.11 muestra un ejemplo de lectura de los datos 
RTM.  
Cuadro 14.11  
Presentación: ejemplo de trama de una petición GET
 No octeto 
Atributo/Campo  Bits en octeto  Descripción  
1 FLAG
  Indicador de comienzo  
2 Private LID
  Dirección de enlace de la 
DSRC-VU específica  
3
 
4
 
5
 
6 MAC Control field
  PDU de comandos  
7 LLC Control field
  Comando ACn sondeado, 
bit n  
8 Fragmentation header
  Sin fragmentación  
9 Get.request 
SEQUENCE {
  Obtener solicitud  
OPTION indicator
  Credenciales de acceso no 
presentes  
OPTION indicator
  IID no presente  
OPTION indicator
  AttributeIdList presente  
Fill BIT STRING(SIZE(1))
  Fijar en 0  
10 EID INTEGER(0..127,…)
  El EID de la instancia de 
la aplicación RTM, tal 
como se especifica en la 
VST. Sin extensión  
11 AttributeIdList SEQUENCE OF { 
AttributeId }}
  Sin extensión, número de 
atributos = 1  
12
 AttributeId=1, RtmData. 
Sin extensión  
13 FCS
  Secuencia de control de 
trama  
14
 
15 Flag
  Indicador de final  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 575  
DSC_50 La  DSRC-VU , tras recibir la petición GET, envía una res­
puesta GET con los datos solicitados conforme a la respuesta 
GET definida en EN 13372, 6.2, 6.3, 6.4 y EN 12834, con 
los valores que se especifican en el cuadro 14.12.  
Cuadro 14.12  
Presentación: valores de trama de una respuesta GET  
Campo  Configuración  
Invoker Identifier (IID)  No presente  
Link Identifier (LID)  Según EN 12834  
Chaining  N o  
Element Identifier (EID)  Según se especifica en la 
VST.  
Access Credentials  N o  
Fragmentation  N o  
Layer2 settings  PDU de respuesta, Respuesta 
disponible y comando acep­
tado, comando ACn  
El cuadro 14.13 muestra un ejemplo de lectura de los datos 
RTM.  
Cuadro 14.13  
Presentación: ejemplo del contenido de una trama de respuesta
 No octeto 
Atributo/Campo  Bits en octeto  Descripción  
1 FLAG
  Indicador de comienzo  
2 Private LID
  Dirección de enlace de la 
DSRC-VU específica  
3
 
4
 
5
 
6 MAC Control field
  PDU de respuesta  
7 LLC Control field
  Respuesta disponible, bit 
n del comando ACn  
8 LLC Status field
  Respuesta disponible y 
comando aceptado  
9 Fragmentation header
  Sin fragmentación  
10 Get.response 
SEQUENCE {
  Obtener respuesta  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 576
 No octeto 
Atributo/Campo  Bits en octeto  Descripción  
OPTION indicator
  IID no presente  
OPTION indicator
  Lista de atributos presente  
OPTION indicator
  Estado de retorno no pre­
sente  
Fill BIT STRING(SIZE(1))
  No se utiliza  
11 EID INTEGER(0..127,…)
  Respondiendo de la Ins­
tancia de aplicación RTM. 
Sin extensión  
12 AttributeList SEQUENCE OF {
  Sin extensión, número de 
atributos = 1  
13 Attributes SEQUENCE { 
AttributeId
  Sin extensión, Attibu­
teId=1 (DatosRtm)  
14 AttributeValue CONTAINER {
  Sin extensión, Opción de 
contenedor = 1010.  
15
 RtmData  
16
 
17
 
… …  
n }}}}
  
n+1 FCS
  Secuencia de control de 
trama  
n+2
 
n+3 Flag
  Indicador de final  
DSC_51 A continuación, el REDCR cierra la conexión enviando un 
comando EVENT_REPORT, RELEASE conforme a EN 
13372, 6.2, 6.3, 6.4 y EN 12834,7.3.8, sin valores RTM 
específicos. El cuadro 14.14 muestra un ejemplo de codifica­
ción de bits del comando RELEASE.  
Cuadro 14.14  
Finalización. Contenido de la trama EVENT_REPORT Release
 No octeto 
Atributo/Campo  Bits en octeto  Descripción  
1 FLAG
  Indicador de comienzo  
2 Private LID
  Dirección de enlace de la 
DSRC-VU específica  
3
 
4
 ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 577
 No octeto 
Atributo/Campo  Bits en octeto  Descripción  
5
 
6 MAC Control field
  La trama contiene una 
LPDU de comandos  
7 LLC Control field
  Comando UI  
8 Fragmentation header
  Sin fragmentación  
9 EVENT_REPORT.request 
SEQUENCE {
  EVENT_REPORT (Re­
lease)  
OPTION indicator
  Credenciales de acceso no 
presentes  
OPTION indicator
  Parámetro de evento no 
presente  
OPTION indicator
  IID no presente  
Mode BOOLEAN
  No se espera respuesta  
10 EID INTEGER (0..127,…)
  Sin extensión, EID = 0 
(Sistema)  
11 EventType INTEGER (0..127,…) }
  Tipo de evento 0 = Re­
lease  
12 FCS
  Secuencia de control de 
trama  
13
 
14 Flag
  Indicador de final  
DSC_52 No se espera que la  DSRC-VU  responda al comando Release. 
La comunicación se cierra.  
5.4.8  Descripción de la transacción de pruebas de la DSRC  
DSC_53 Deben realizarse pruebas completas que comprendan la pro ­
tección de los datos tal y como se define en el apéndice 11, 
«Mecanismos de seguridad comunes», por personas autoriza­
das que tengan acceso a los procedimientos de seguridad 
mediante el comando GET normal definido anteriormente.  
DSC_54 Las pruebas para la puesta en servicio y para las inspec ciones 
periódicas que requieran el descifrado y la comprensión del 
contenido de los datos descifrados se llevarán a cabo según 
los especificado en el apéndice 11, «Mecanismos de seguri­
dad comunes», y el apéndice 9, «Homologación y lista de 
pruebas mínimas requeridas».  
No obstante, la comunicación DSRC básica puede compro­
barse mediante el comando ECHO. Estas pruebas pueden 
exigirse para la puesta en servicio, en inspecciones periódicas  
o en cualquier otro momento que lo exijan la autoridad de 
control competente o el Reglamento (UE) n  o 165/2014 (véase 
la sección 6).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 578  
DSC_55 Para realizar esta prueba de comunicación básica, el RED CR 
emite el comando ECHO durante una sesión, es decir, tras 
haberse completado satisfactoriamente una fase de inicializa­
ción. Por tanto, la secuencia de interacciones es similar a la 
de una interrogación:  
— Paso 1  El REDCR  envía una «tabla de servicios de la 
baliza» (BST) que incluye los identificadores de 
aplicación (AID) en la lista de servicios que admite. En 
las aplicaciones RTM, consistirá simplemente en el ser­
vicio con el valor AID = 2.  
La DSRC-VU  evalúa la BST recibida y, cuando identifica 
que la BST está solicitando carga y flota (AID = 2), la  
DSRC-VU  responde. Si  el REDCR  no ofrece AID = 2, la  
DSRC-VU  cerrará su transacción con  el REDCR . 
— Paso 2  La DSRC-VU  envía una solicitud de una asigna­
ción de ventana privada.  
— Paso 3 El REDCR envía una asignación de ventana 
privada.  
— Paso 4 La  DSRC-VU  utiliza la ventana privada asignada 
para enviar su tabla de servicio del vehículo (VST). Esta 
VST incluye una lista de todas las instanciaciones dife­
rentes de la aplicación que admite esta  DSRC-VU  en el 
marco de AID = 2. Las diferentes instanciaciones se 
identificarán mediante EID únicas, cada una de ellas aso­
ciada a un valor de parámetro que indica la instancia de la 
aplicación que es compatible.  
— Paso 5 A continuación  el REDCR  analiza la VST ofrecida 
y, o bien finaliza la conexión (RELEASE) porque no le 
interesa nada de lo que ofrece la VST (es decir, está 
recibiendo una VST de una  DSRC-VU  que no es una 
RTM VU, o bien, si recibe una VST adecuada, inicia 
una instanciación de aplicación.  
— Paso 6 El  REDCR  emitirá un comando (ECHO) a la  
DSRC-VU  específica y asignará una ventana privada.  
— Paso 7 La  DSRC-VU  utiliza la ventana privada recién 
asignada para enviar una trama de respuesta ECHO.  
Los cuadros siguientes ofrecen un ejemplo práctico de una sesió n de 
intercambio ECHO.  
DSC_56 La inicialización se lleva a cabo conforme a 5.4.7 (DSC_ 44 
— DSC_48) y los cuadros 14.4 — 14.9.  
DSC_57 A continuación, el REDCR envía un comando ACTION, 
ECHO conforme a ISO 14906, que contiene 100 octetos de 
datos sin valores específicos para RTM. El cuadro 14.15 
muestra el contenido de la trama que envía el REDCR.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 579  
Cuadro 14.15  
ejemplo de trama de petición ACTION,ECHO
 No octeto 
Atributo/Campo  Bits en octeto  Descripción  
1 FLAG
  Indicador de comienzo  
2 Private LID
  Dirección de enlace de la 
DSRC-VU específica  
3
 
4
 
5
 
6 MAC Control field
  PDU de comandos  
7 LLC Control field
  Comando ACn sondeado, 
bit n  
8 Fragmentation header
  Sin fragmentación  
9 ACTION.request 
SEQUENCE {
  Solicitud de acción (ECHO)  
OPTION indicator
  Credenciales de acceso no 
presentes  
OPTION indicator
  Parámetro de acción pre­
sente  
OPTION indicator
  IID no presente  
Mode BOOLEAN
  Respuesta esperada  
10 EID INTEGER (0..127,…)
  Sin extensión, EID = 0 
(Sistema)  
11 ActionType INTEGER (0..127,…)
  Sin extensión, solicitud de 
ECHO de tipo de acción  
12 ActionParameter CONTAINER {
  Sin extensión, opción de 
contenedor = 2  
13
 Sin extensión, longitud de 
cadena = 100 octetos  
14
 Datos de que se debe ha­
cer eco  
… …  
113 } }
  
114 FCS
  Secuencia de control de 
trama  
115
 
116 Flag
  Indicador de final  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 580  
DSC_58 La  DSRC-VU , al recibir la petición ECHO, envía una res­
puesta ECHO de 100 octetos de datos reflejando el comando 
recibido, según ISO 14906, sin valores específicos para RTM. 
El cuadro 14.16 muestra un ejemplo de codificación a nivel 
de bits.  
Cuadro 14.16  
ejemplo de trama de respuesta ACTION, ECHO
 No octeto 
Atributo/Campo  Bits en octeto  Descripción  
1 FLAG
  Indicador de comienzo  
2 Private LID
  Dirección de enlace de la 
VU específica  
3
 
4
 
5
 
6 MAC Control field
  PDU de respuesta  
7 LLC Control field
  comando ACn, bit n  
8 LLC status field
  Respuesta disponible  
9 Fragmentation header
  Sin fragmentación  
10 ACTION.response 
SEQUENCE {
  Respuesta de acción 
(ECHO)  
OPTION indicator
  IID no presente  
OPTION indicator
  Parámetro de respuesta 
presente  
OPTION indicator
  Estado de retorno no pre­
sente  
Fill BIT STRING (SIZE (1))
  No se utiliza  
11 EID INTEGER (0..127,…)
  Sin extensión, EID = 0 
(Sistema)  
12 ResponseParameter CONTAINER {
  Sin extensión, opción de 
contenedor = 2  
13
 Sin extensión, longitud de 
cadena = 100 octetos  
14
 Datos de eco  
… …  
113 } }
  
114 FCS
  Secuencia de control de 
trama  
115
 
116 Flag
  Indicador de final  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 581  
5.5 Reservado para usos futuros  
▼M2 __________  
▼B 
5.6 Transferencia de datos entre la DSRC-VU y la VU  
5.6.1  Conexión física e interfaces  
DSC_66 La conexión entre la  VU y  l a  DSRC-VU  puede realizarse por 
cable físico o mediante comunicación inalámbrica de corto 
alcance basada en Bluetooth v4.0 BLE.  
DSC_67 Independientemente de la conexión física y la interfaz e legi­
das, deberán cumplirse los siguientes requisitos:  
DSC_68  ►M1 a) con el fin de poder contratar a varios proveedores 
el suministro de la VU y la DSRC-VU, e incluso 
diferentes lotes de DSRC-VU, la conexión entre la 
VU y la DSRC-VU no interna será una conexión 
de norma abierta. La VU se conectará con la 
DSRC-VU: ◄  
i) mediante cable fijo de al menos 2 metros, uti­
lizando un conector macho homologado 
Straight DIN 41612 H11 de 11 patillas de la 
DSRC-VU para conectarlo a un conector hem­
bra homologado DIN/ISO del dispositivo VU;  
ii) mediante Bluetooth de baja energía (BLE);  
iii) mediante una conexión estándar ISO 11898 o 
SAE J1939.  
DSC_69 b) la definición de las interfaces y la conexión entre l a VU y 
la DSRC-VU debe admitir los comandos del protocolo de 
aplicaciones definidos en el apartado 5.6.2. y  
DSC_70 c) la VU y la DSRC-VU deben ser compatibles con el fun­
cionamiento de la transferencia de datos a través de la 
conexión en cuanto al rendimiento y al suministro eléc­
trico.  
5.6.2  Protocolo de aplicaciones  
DSC_71 El protocolo de aplicaciones entre el dispositivo de com uni­
cación a distancia VU y la DSRC-VU tiene por objeto la 
transferencia periódica de datos de comunicación a distancia 
desde la VU al DSRC.  
DSC_72 Se han identificado los siguientes comandos principales:  
1. Iniciación del enlace de comunicación: petición  
2. Iniciación del enlace de comunicación: respuesta  
3. Envío de datos con el identificador de la aplicación RTM 
y los datos útiles definidos por los datos RTM.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 582  
4. Confirmación de los datos  
5. Finalización del enlace de comunicación: petición  
6. Finalización del enlace de comunicación: respuesta  
DSC_73 En ASN1.0, los comandos anteriores pueden definirse del 
modo siguiente:
  
DSC_74 La descripción de los comandos y parámetros es la siguie nte: 
—
 se 
utiliza para inicializar el enlace de comunicación. El co­
mando lo envía la VU a la DSRC-VU. El LinkIdentifier 
lo establece la VU y lo comunica a la DSRC-VU para 
rastrear un enlace de comunicación específico.  
(Nota:  esto sirve para admitir enlaces futuros y otras apli­
caciones o módulos como el de pesaje a bordo.)  
—
 lo 
utiliza la DSRC-VU para responder a la petición de iniciar 
el enlace de comunicación. El comando lo envía la 
DSRC-VU a la VU. El comando da el resultado de la 
inicialización como respuesta = 1 (correcto) o = 0 (inco­
rrecto).  
DSC_75 La inicialización del enlace de comunicación se realizar á solo 
tras la instalación, calibrado y arranque del motor/VU.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 583  
—
 lo utiliza la VU para enviar los 
RCDTData firmados (es decir,  los Datos de comunicación 
a distancia ) a la DSRC-VU. Los datos se enviarán cada 
60 segundos. El parámetro DataTransactionId identifica la 
transmisión específica de datos. El LinkIdentifier también 
se usa para asegurarse de que el enlace correspondiente es 
el correcto.  
—
 lo envía la DSRC- 
VU para suministrar información a la VU acerca de la 
recepción de los datos de un comando RCDT–Send 
Data identificado mediante el parámetro DataTransactio­
nId. El parámetro de respuesta es 1 (correcto) o = 0 
(incorrecto). Si una VU recibe más de tres respuestas 
iguales a 0 o si
  la VU no recibe 
una confirmación de datos RCDT de un comando especí­
fico RCDT-Send Data enviado anteriormente con un Da­
taTransactionId específico, la VU generará y registrará un 
incidente.  
—
 lo envía la 
VU a la DSRC-VU para finalizar un enlace de un LinkI­
dentifier específico.  
DSC_76 Al reiniciar la DSRC-VU o una VU, todos los enlaces de 
comunicación existentes deben eliminarse, ya que podría ha­
ber enlaces «pendientes» debido a la desconexión repentina 
de una VU.  
—
 lo envía la 
DSRC-VU a la VU para confirmar la petición de finali­
zación del enlace por parte de la VU para el LinkIdentifier 
específico.  
5.7 Gestión de errores  
5.7.1  Registro y comunicación de los datos en la DSRC-VU  
▼M3 
DSC_77  Los datos  deberán ser suministrados, ya protegidos, por la 
función  VUSM  a  l a  DSRC-VU . La VUSM  verificará que los 
datos registrados en la  DSRC-VU  se han transmitido correc­
tamente a la DSRC-VU. El registro y la notificación de erro­
res en la transferencia de datos de la  VU a la memoria de la  
DSRC-VU  se registrarán con el tipo EventFaultType y el valor 
de enumeración ajustado en «0C»H, error de comunicación 
con el dispositivo de comunicación a distancia, junto con el 
sello de tiempo. La  VUSM  verificará que los datos se han 
transmitido correctamente a la DSRC-VU.  
DSC_78 Reservado para usos futuros  
▼B 
DSC_79 Si la VUPM intenta obtener datos de la VU desde el módul o 
de seguridad (para pasarlos a la DSRC-VU), pero no lo con­
sigue, registrará el fallo con el tipo EventFaultType y el valo r 
de enumeración fijado en «62» H fallo de comunicación del  
dispositivo de comunicación a distancia  junto con la indica­
ción temporal. El fallo de comunicación se detecta cuando no  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 584  
se recibe un mensaje
  para el 
correspondiente
  (es decir, con el 
mismo DataTransactionId en los mensajes
  
) durante más de tres 
veces consecutivas.  
5.7.2  Errores de comunicación inalámbrica  
DSC_80 La gestión de errores de comunicación deberá ajustarse a  las 
correspondientes normas DSRC, es decir, EN 300 674-1, EN 
12253, EN 12795, EN 12834 y los parámetros pertinentes de 
EN 13372.  
5.7.2.1  Errores de cifrado y firma  
DSC_81 Los errores de cifrado y firma se gestionarán del modo d efi­
nido en el apéndice 11, «Mecanismos de seguridad comunes», 
y no aparecen en ninguno de los mensajes de error asociados 
a transferencias de datos DSRC.  
5.7.2.2  Registro de errores  
El medio DSRC consiste en una comunicación inalámbrica dinámica  en 
un entorno de condiciones atmosféricas e interferencias inestab les, espe­
cialmente en las combinaciones de «REDCR portátil» y «vehículo en 
movimiento» que intervienen en esta aplicación. Por tanto, es p reciso 
establecer la diferencia entre un «fallo de lectura» y una cond ición de 
«error». En una transacción a través de una interfaz inalámbric a, los 
fallos de lectura son habituales y la consecuencia suele ser un  reintento, 
es decir, retransmitir la BST y volver a intentar la secuencia,  lo cual, en 
la mayoría de los casos, se traducirá en una conexión de comuni cación 
satisfactoria y la transferencia de datos, a menos que el vehíc ulo selec­
cionado se salga del alcance durante el tiempo necesario para r etrans­
mitir. (Es posible que una instancia «satisfactoria» de una «le ctura» haya 
necesitado varios intentos y reintentos.)  
El fallo de lectura puede deberse a que las antenas no estaban correc­
tamente emparejadas (fallo de «apuntado»); a que una de las ant enas esté 
apantallada (puede ser intencionado, pero también puede deberse  a la 
presencia física de otro vehículo); a interferencias radioeléct ricas, espe­
cialmente de comunicaciones WIFI de alrededor de 5,8 GHz u otra s 
comunicaciones inalámbricas de acceso público, o puede deberse a in­
terferencias de radares o a condiciones atmosféricas problemáti cas (por 
ejemplo, durante una tormenta eléctrica); o sencillamente a hab erse sa­
lido del alcance de la comunicación DSRC. Las instancias indivi duales 
de los fallos de lectura, por su naturaleza, no pueden registra rse sim­
plemente porque la comunicación no tuvo lugar.  
No obstante, si el agente de la autoridad de control competente  selec­
ciona un vehículo e intenta interrogar su  DSRC-VU  sin éxito en la 
transferencia de datos, este fallo podría deberse a una manipul ación 
intencionada y, por tanto, el agente de la autoridad de control  compe­
tente necesita un medio para registrar el fallo y alertar a otr os agentes 
que se encuentren más adelante del lugar en el que se ha produc ido una 
infracción. Estos agentes podrán detener el vehículo y realizar  una ins­
pección física. Pero, al no haber existido ninguna comunicación , la 
DSRC-VU no puede suministrar datos relacionados con el fallo. P or 
tanto, estos informes dependerán del diseño del equipo REDCR.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 585  
Técnicamente, un «fallo de lectura» es distinto a un «error». E n este 
contexto, un «error» es la obtención de un valor erróneo.  
Los datos que se transfieren a la  DSRC-VU  ya se suministran protegidos; 
por tanto, deben ser verificados por el proveedor de los datos (véase la 
sección 5.4).  
Posteriormente, se comprueban los datos transferidos a través d e la 
interfaz aérea mediante verificación por redundancia cíclica en  el nivel 
de las comunicaciones. Si se valida la CRC, los datos son corre ctos. Si 
no se valida la CRC, se retransmiten los datos. Estadísticament e, es tan 
improbable que los datos puedan pasar con éxito una CRC de form a 
incorrecta que esta posibilidad puede descartarse.  
Si la CRC no se valida y no hay tiempo para retransmitir y reci bir los 
datos correctos, el resultado no será un error, sino una instan ciación de 
un tipo específico de fallo de lectura.  
Los únicos datos de «fallo» significativos que pueden registrar se son los 
del número de iniciaciones de transacciones satisfactorias que se produ­
cen y que no se traducen en una transferencia de datos correcta  al 
REDCR.  
DSC_82 Por tanto, el  REDCR  registrará, con indicación temporal, el 
número de veces que se ha producido correctamente la fase 
de «inicialización» de una interrogación DSRC, pero se inte­
rrumpió la transacción antes de que  los Datos  fueran recupe­
rados correctamente por el REDCR. Estos datos quedarán a 
disposición del agente de la autoridad de control competente 
y se almacenarán en la memoria del equipo REDCR. El me­
dio empleado para esta operación dependerá del diseño del 
producto o de la especificación de una autoridad de control 
competente.  
Los únicos datos de «error» significativos que pueden regis­
trarse son el número de veces que el REDCR no logra desci­
frar los Datos  recibidos. No obstante, cabe señalar que esto 
estará relacionado solo con la eficacia del  software  del 
REDCR. Los datos pueden descifrarse técnicamente y, sin 
embargo, no tener sentido semántico.  
DSC_83 Por tanto, el  REDCR  registrará, con indicación temporal, el 
número de veces que ha intentado sin éxito descifrar los datos 
recibidos a través de la interfaz DSRC.  
6 PRUEBAS PARA LA PUESTA EN SERVICIO Y LAS INSPECCIO­
NES PERIÓDICAS DE LA FUNCIÓN DE COMUNICACIÓN A DIS­
TANCIA  
6.1 Generalidades  
DSC_84 Se prevén dos tipos de pruebas para la función de comuni ca­
ción a distancia:  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 586  
1) Una prueba ECHO para validar el canal de comunicación 
inalámbrica  DSRC-REDCR  >>-:-< DSRC-VU . 
2) Una prueba de seguridad de extremo a extremo para ga­
rantizar que una tarjeta de taller puede acceder al conte­
nido de los datos cifrados y firmados que ha creado la VU 
y transmitidos a través del canal de comunicación inalám­
brica.  
6.2 ECHO  
Esta sección contiene disposiciones elaboradas específicamente para 
comprobar únicamente que el enlace  DSRC-REDCR  >>-:-< DSRC-VU  
está operativo.  
El objetivo del comando ECHO es permitir a los talleres o a los  centros 
de ensayos de homologación que prueben que el enlace DSRC funci ona 
sin necesidad de acceder a las credenciales de seguridad. Por t anto, el 
equipo del evaluador solo precisa poder inicializar una comunic ación 
DSRC (enviando una BST con AID = 2) y, seguidamente, enviar un 
comando ECHO y, suponiendo que funcione el DSRC, recibirá una 
respuesta ECHO. Véanse los detalles en el apartado 5.4.8. Supon iendo 
que se recibe esta respuesta correctamente, es posible validar el funcio­
namiento correcto del enlace DSRC ( DSRC-REDCR  >>-:-< DSRC-VU ). 
6.3 Pruebas para validar el contenido de datos seguros  
DSC_85 Esta prueba se realiza para validar de extremo a extremo  el 
flujo de datos de seguridad. Se precisa un lector de pruebas 
DSRC para esta prueba. El lector de pruebas DSRC desem­
peña la misma función y se instala con las mismas especifi­
caciones que el lector que utilizan los agentes de seguridad, 
con la salvedad de que se utiliza una tarjeta de taller en luga r 
de una tarjeta de control para autenticar al usuario del lector  
de pruebas DSRC. La prueba puede realizarse tras la activa­
ción inicial de un tacógrafo inteligente o al final del proceso  
de calibrado. Tras la activación, el equipo del vehículo gene­
rará y comunicará a la DSRC-VU los datos protegidos de 
detección temprana.  
DSC_86 El personal del taller debe colocar el lector de pruebas  DSRC 
delante del vehículo a una distancia de entre 2 y 10 metros.  
DSC_87 A continuación, dicho personal insertará una tarjeta de taller 
en el lector de pruebas DSRC para solicitar la interrogación 
de los datos de detección temprana a la VU. Tras una inte­
rrogación correcta, el personal del taller accederá a los datos  
recibidos para asegurarse de que se ha validado su integridad 
y se han descifrado correctamente.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 587  
ADENDA  
Reglas para el cómputo del tiempo de conducción diario, semanal  y bisemanal  
1. Reglas de cómputo básicas  
La VU computará el tiempo de conducción diario, el tiempo de co nducción 
semanal y el tiempo de conducción bisemanal utilizando los dato s pertinentes 
almacenados en una tarjeta de conductor (o de taller) insertada  en la ranura 
del conductor (ranura 1, lector de tarjeta #1) de la propia uni dad instalada en 
el vehículo, así como las actividades del conductor seleccionad as mientras 
dicha tarjeta está insertada en la VU.  
No se calcularán tiempos de conducción mientras no haya ninguna  tarjeta de 
conductor (o de taller) insertada.  
Todo período DESCONOCIDO dentro del período de tiempo necesario  para 
los cómputos se asimilará a un período de PAUSA/DESCANSO.  
No se tendrá en cuenta ningún período DESCONOCIDO ni ninguna ac tividad 
de duración negativa (es decir, que comienza más tarde de lo qu e acaba) 
debidos a solapamientos temporales entre dos VU distintas o a u n ajuste de 
la hora.  
Las actividades registradas en la tarjeta de conductor correspo ndientes a pe­
ríodos «FUERA DE ÁMBITO» según la definición gg) del anexo I C se 
interpretarán como sigue:  
— PAUSA/DESCANSO se computará como «PAUSA» o «DESCANSO»,  
— TRABAJO y CONDUCCIÓN se considerarán «TRABAJO»,  
— DISPONIBILIDAD se considerará «DISPONIBILIDAD».  
En el contexto de la presente adenda, la VU dará por supuesto u n período de 
descanso diario al comienzo de los registros de actividades de la tarjeta.  
2. Conceptos  
Los siguientes conceptos se aplican exclusivamente al presente apéndice y 
tienen como finalidad especificar el cómputo de los tiempos de conducción 
por la VU y su posterior transmisión por el dispositivo de comu nicación a 
distancia.  
a) El «turno RTM» es el período entre el final de un período de  descanso 
diario y el final del período de descanso diario inmediatamente  posterior.  
La VU iniciará un nuevo turno RTM una vez que finalice un perío do de 
descanso diario.  
El turno RTM en curso es el período desde el final del último p eríodo de 
descanso diario.  
b) El «tiempo de conducción acumulado» es la suma de la duració n de todas 
las actividades de CONDUCCIÓN del conductor dentro de un períod o que 
no sea FUERA DE ÁMBITO.  
c) El «tiempo de conducción diario» es el tiempo de conducción acumulado 
en un turno RTM.  
d) El «tiempo de conducción semanal» es el tiempo de conducción  acumu­
lado en la semana en curso.  
e) Un «período de descanso continuo» es cualquier período inint errumpido de 
PAUSA/DESCANSO.  
f) El «tiempo de conducción bisemanal» es el tiempo de conducci ón acumu­
lado en la semana anterior y la semana en curso.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 588  
g) Un «período de descanso diario» es un período de PAUSA/DESCA NSO, 
que puede ser:  
— un período de descanso diario normal,  
— un período de descanso diario dividido,  
— un período de descanso diario reducido.  
En el contexto del apéndice 14, cuando una VU esté computando p eríodos 
de descanso semanales, estos se considerarán períodos de descan so diarios.  
h) Un «período de descanso diario normal» es un período de desc anso con­
tinuo de como mínimo once horas.  
A modo de excepción, cuando esté activa una condición de TRAYEC TO 
EN TRANSBORDADOR/TREN, el período de descanso diario normal 
podrá interrumpirse como máximo dos veces con actividades disti ntas al 
descanso, con una duración acumulada máxima de una hora, es dec ir, que 
el período de descanso diario normal que contenga uno o varios períodos 
de trayecto en transbordador/tren podrá dividirse en dos o tres  partes. La 
VU computará entonces un período de descanso diario normal cuan do el 
tiempo de descanso acumulado computado conforme al punto 3 sea de al 
menos once horas.  
Cuando un período de descanso diario normal se haya interrumpid o, la 
VU: 
— no incluirá la actividad de conducción realizada durante esas  interrup­
ciones en el cómputo del tiempo de conducción diario, e  
— iniciará un nuevo turno RTM al final del período de descanso diario 
normal que se haya interrumpido.  
Figura 1.  
Ejemplo de un período de descanso diario interrumpido debida a un trayecto en transbordador/tren
  
i) Un «período de descanso diario reducido» es un período de de scanso 
continuo de como mínimo nueve horas y de menos de once horas.  
j) Un «período de descanso diario dividido» es un período de de scanso diario 
tomado en dos partes:  
— la primera parte será un período de descanso continuo de como  mínimo 
tres horas y de menos de nueve horas,  
— la segunda parte será un período de descanso continuo de como  mí­
nimo nueve horas.  
A modo de excepción, cuando esté activa una condición de TRAYEC TO 
EN TRANSBORDADOR/TREN durante una o las dos partes de un pe­
ríodo de descanso diario dividido, este podrá interrumpirse com o máximo 
dos veces con otras actividades, con una duración acumulada máx ima de 
una hora, es decir:  
— la primera parte del período de descanso diario dividido podr á inte­
rrumpirse una o dos veces,  
— la segunda parte del período de descanso diario dividido podr á inte­
rrumpirse una o dos veces, o  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 589  
— la primera y la segunda parte del período de descanso diario dividido 
podrán interrumpirse, respectivamente, una sola vez.  
La VU computará entonces un período de descanso diario dividido  cuando 
el tiempo de descanso acumulado computado conforme al punto 3 s ea: 
— de como mínimo tres horas y de menos de once horas, en el pri mer 
período de descanso, y de como mínimo nueve horas, en el segund o 
período de descanso, cuando el primer período de descanso haya sido 
interrumpido por un TRAYECTO EN TRANSBORDADOR/TREN,  
— de como mínimo tres horas y de menos de nueve horas, en el pr imer 
período de descanso, y de como mínimo nueve horas, en el segund o 
período de descanso, cuando el primer período de descanso no ha ya 
sido interrumpido por un TRAYECTO EN TRANSBORDADOR/ 
TREN.  
Figura 2.  
Ejemplo de un período de descanso diario dividido interrumpido debido a un trayecto en transbordador/ 
tren
 
Cuando el período de descanso diario dividido se interrumpa, la  VU:  
— no incluirá la actividad de conducción realizada durante esas  interrup­
ciones en el cómputo del tiempo de conducción diario, e  
— iniciará un nuevo turno RTM al final del período de descanso diario 
dividido que se haya interrumpido.  
k) Una «semana» es el período en hora UTC transcurrido entre la s 00.00 
horas del lunes y las 24.00 horas del domingo.  
3. Cómputo del período de descanso cuando ha sido interrumpido debido a un 
trayecto en transbordador/tren  
Para computar el período de descanso cuando ha sido interrumpid o debido a 
un trayecto en transbordador/tren, la VU calculará el tiempo de  descanso 
acumulado siguiendo los pasos siguientes:  
a) Paso 1  
La VU detectará las interrupciones del tiempo de descanso que s e produz­
can antes de activarse el indicador de TRAYECTO EN TRANSBORDA­
DOR/TREN (COMIENZO), de acuerdo con la figura 3 y, en su caso, la 
figura 4, y evaluará, con respecto a cada interrupción detectad a, si se dan 
las condiciones siguientes:  
— la interrupción hace que la duración total de las interrupcio nes detec­
tadas, incluidas, en su caso, las producidas durante la primera  parte de 
un período de descanso diario dividido a causa de un trayecto e n 
transbordador/tren, excedan en total de una hora,  
— la interrupción hace que el número total de interrupciones de tectadas, 
incluidas, en su caso, las producidas durante la primera parte de un 
período de descanso diario dividido a causa de un trayecto en t rans­
bordador/tren, exceda de dos,  
— una vez finalizada la interrupción, se ha almacenado una «ent rada del 
lugar donde terminan los períodos de trabajo diarios».  
Si no se da ninguna de las condiciones señaladas, el período de  descanso 
continuo inmediatamente anterior a la interrupción se añadirá a l tiempo de 
descanso acumulado.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 590  
Si se da por lo menos una de las condiciones señaladas, la VU, o bien 
dejará de computar el tiempo de descanso acumulado conforme al paso 2, 
o bien detectará interrupciones del tiempo de descanso producid as después 
de activarse el indicador TRAYECTO EN TRANSBORDADOR/TREN 
(COMIENZO) conforme al paso 3.  
b) Paso 2  
En relación con cada interrupción detectada conforme al paso 1,  la VU 
evaluará si debe o no dejar de computar el tiempo de descanso a cumulado. 
La VU detendrá el proceso de cómputo cuando se hayan añadido al  tiempo 
de descanso acumulado dos períodos de descanso continuos produc idos 
antes de activarse el indicador TRAYECTO EN TRANSBORDADOR/ 
TREN (COMIENZO), incluidos, en su caso, períodos de descanso añ adi­
dos en la primera parte de un período de descanso diario dividi do también 
interrumpido por un trayecto en transbordador/tren. De lo contr ario, la VU 
procederá conforme al paso 3.  
c) Paso 3  
Si, tras proceder con el paso 2, la VU sigue computando el tiem po de 
descanso acumulado, deberá detectar las interrupciones que se p roduzcan 
tras desactivarse la condición TRAYECTO EN TRANSBORDADOR/ 
TREN conforme a la figura 3 y, en su caso, la figura 4.  
En relación con cada interrupción detectada, la VU evaluará si esa inte­
rrupción hace que el tiempo acumulado de todas las interrupcion es detec­
tadas exceda en total de una hora, en cuyo caso el cómputo del período de 
descanso acumulado terminará al final del período de descanso c ontinuo 
previo a la interrupción. De lo contrario, los períodos de desc anso conti­
nuos producidos después de las respectivas interrupciones se añ adirán al 
cómputo del período de descanso diario hasta que se cumpla la c ondición 
del paso 4.  
d) Paso 4  
El cómputo del tiempo de descanso acumulado se detendrá cuando la VU 
haya añadido, como consecuencia de los pasos 1 y 3, un máximo d e dos 
períodos de descanso continuos al período de descanso para el q ue esté 
activada la condición TRAYECTO EN TRANSBORDADOR/TREN, in­
cluidas, en su caso, interrupciones que se produzcan durante la  primera 
parte de un período de descanso diario dividido a causa de un t rayecto en 
transbordador/tren.  
Figura 3.  
Procesamiento de los tiempos de descanso por la VU a fin de determinar si un período de descanso 
interrumpido se computará como período de descanso diario normal o como la primera parte de un 
período de descanso diario dividido
  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 591  
Figura 4.  
Procesamiento de los tiempos de descanso por la VU a fin de determinar si un período de descanso 
interrumpido se computará como la segunda parte de un período de descanso diario dividido
  
Figura 5.  
Ejemplo de un período de descanso diario interrumpido más de dos veces, haciendo que el período de 
descanso H no se incluya en el cómputo
  
Figura 6.  
Ejemplo de un período de descanso diario en el que el período de cálculo transbordador/tren comienza al 
final del período de trabajo
  
Figura 7.  
Ejemplo de un período de descanso diario interrumpido más de dos veces, haciendo que el período de 
descanso B no se incluya en el cómputo
  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 592  
Figura 8.  
Ejemplo de un período de descanso diario dividido interrumpido una vez durante el primer período de 
descanso y una vez durante el segundo período de descanso
  
4. Reglas para el cómputo de los tiempos de conducción diario, semanal y 
bisemanal  
La VU computará los tiempos de conducción diarios correspondien tes a los 
turnos RTM en curso y anterior. El tiempo de conducción durante  las inte­
rrupciones de los períodos de descanso diarios no se añadirá al  cómputo del 
tiempo de conducción diario cuando esas interrupciones se deban  a un tra­
yecto en transbordador/tren y se hayan cumplido los requisitos establecidos en 
las letras h) y j) de los puntos 2 y 3. Sin embargo, en la medi da en que la VU 
no haya computado un período de descanso diario normal o dividi do completo 
conforme al punto 3, los tiempos de conducción durante las inte rrupciones se 
añadirán al tiempo de conducción diario correspondiente al turn o RTM en 
curso.  
La VU computará también los tiempos de conducción semanal y bis emanal. 
El tiempo de conducción durante las interrupciones de los perío dos de des­
canso diarios a causa de un trayecto en transbordador/tren se a ñadirán al 
cómputo de los tiempos de conducción semanal y bisemanal.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 593  
Apéndice 15  
MIGRACIÓN: GESTIÓN DE LA COEXISTENCIA DE LAS 
GENERACIONES Y VERSIONES DE EQUIPOS  
▼B 
ÍNDICE  
1. DEFINICIONES  
2. DISPOSICIONES GENERALES  
2.1. Visión general de la transición  
▼M3 
2.2. Interoperabilidad entre la VU y las tarjetas  
▼B 
2.3. Interoperabilidad entre la unidad instalada en el vehículo  y los sensores de 
movimiento  
2.4. Interoperabilidad entre las unidades instaladas en el vehí culo, las tarjetas 
de tacógrafo y los equipos para la transferencia de datos  
2.4.1 Transferencia de datos directamente de la tarjeta por IDE  
2.4.2 Transferencia de datos de la tarjeta a través de una unid ad instalada en el 
vehículo  
2.4.3 Transferencia de datos de la unidad instalada en el vehíc ulo 
2.5. Interoperabilidad entre las unidades instaladas en el vehí culo y el equipo 
de calibrado  
3. ETAPAS PRINCIPALES DURANTE EL PERÍODO PREVIO A LA 
FECHA DE INTRODUCCIÓN  
4. DISPOSICIONES PARA EL PERÍODO POSTERIOR A LA FECHA DE 
INTRODUCCIÓN  
▼M3 
5. REGISTRO DE LOS CRUCES DE FRONTERAS EN LOS TACÓGRA­ 
FOS DE PRIMERA GENERACIÓN Y DE LA PRIMERA VERSIÓN 
DE LA SEGUNDA GENERACIÓN  
▼B 
1. DEFINICIONES  
A efectos del presente apéndice, se aplicarán las siguientes de finiciones:  
Sistema de tacógrafo inteligente:  tal como se define en el presente 
anexo (capítulo 1: definición bbb);  
Sistema de tacógrafo de primera generación:  tal como se define en el 
presente Reglamento (artículo 2: definición 1);  
Sistema de tacógrafo de segunda generación:  tal como se define en el 
presente Reglamento (artículo 2: definición 7);  
Fecha de introducción:  tal como se define en el presente anexo (capítulo 
1: definición ccc);  
Equipo dedicado inteligente (IDE):  equipo empleado para realizar la 
transferencia de datos, tal como se define en el apéndice 7 del  presente 
anexo.  
▼M3 
2. DISPOSICIONES GENERALES  
2.1. Visión general de la transición  
En la introducción del presente anexo se ofrece una visión gene ral de la 
transición entre los sistemas de tacógrafo de primera y segunda  genera­
ción, y de la introducción de la segunda versión de los aparato s de control 
y las tarjetas de tacógrafo de segunda generación.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 594  
Además de lo dispuesto en la introducción, cabe recordar la sig uiente 
información:  
— los sensores de movimiento de primera generación no son inter opera­
bles con ninguna versión de las unidades instaladas en el vehíc ulo de 
segunda generación,  
— en los vehículos equipados con cualquier versión de unidades instala­
das en el vehículo de segunda generación solo pueden instalarse  sen­
sores de movimiento de segunda generación,  
— la transferencia de datos y el equipo de calibrado tienen que  ser 
compatibles con el uso de ambas generaciones o versiones de apa ratos 
de control y tarjetas de tacógrafo.  
2.2. Interoperabilidad entre la VU y las tarjetas  
Se entiende que las tarjetas de tacógrafo de primera generación  son inte­
roperables con las unidades instaladas en el vehículo de primer a genera­
ción [de conformidad con el anexo I B del Reglamento (CEE) 
n. o 3821/85], y que cualquier versión de las tarjetas de tacógrafo de 
segunda generación es interoperable con cualquier versión de la s unidades 
instaladas en el vehículo de segunda generación (de conformidad  con el 
anexo I C del presente Reglamento). Asimismo, serán de aplicaci ón los 
requisitos que figuran a continuación.  
MIG_001 Excepto en el caso indicado en los requisitos MIG_004 y  
MIG_005, las tarjetas de tacógrafo de primera generación 
podrán seguir utilizándose en cualquier versión de las unida­
des instaladas en el vehículo de segunda generación hasta el 
final de su fecha de validez. Sus titulares, no obstante, puede n 
solicitar su sustitución por tarjetas de tacógrafo de segunda 
generación tan pronto como estén disponibles.  
MIG_002 Cualquier versión de las unidades instaladas en el vehí culo de 
segunda generación podrá utilizar cualquier tarjeta válida de 
conductor, de control o de empresa de primera generación que 
se inserte.  
MIG_003 Esta capacidad podrá ser eliminada por el taller de for ma 
definitiva en dichas unidades instaladas en el vehículo, de 
forma que las tarjetas de tacógrafo de primera generación ya 
no puedan aceptarse. No obstante, esto solo podrá llevarse a 
cabo una vez que la Comisión Europea haya puesto en mar­
cha un procedimiento destinado a exigir a los talleres dicha 
actuación, por ejemplo durante cada control periódico del 
tacógrafo.  
MIG_004 Las unidades instaladas en el vehículo de segunda gener ación 
solo podrán utilizar las tarjetas de taller de segunda genera­
ción.  
MIG_005 Para determinar el modo de funcionamiento, cualquier ve rsión 
de las unidades instaladas en el vehículo de segunda genera­
ción solo considerará el tipo de las tarjetas válidas insertada s, 
independientemente de su generación o su versión.  
MIG_006 Cualquier versión de una tarjeta de tacógrafo válida de  se­
gunda generación deberá poder ser utilizada en unidades ins­
taladas en el vehículo de primera generación, exactamente 
como una tarjeta de tacógrafo de primera generación del 
mismo tipo.  
2.3. Interoperabilidad entre la VU y los sensores de movimiento  
Se entiende que los sensores de movimiento de primera generació n son 
interoperables con las unidades instaladas en el vehículo de pr imera ge­
neración, mientras que los sensores de movimiento de segunda ge neración 
son interoperables con cualquier versión de las unidades instal adas en el 
vehículo de segunda generación. Asimismo, serán de aplicación l os requi­
sitos que figuran a continuación.  
MIG_007 Ninguna versión de las unidades instaladas en el vehícu lo de 
segunda generación podrá emparejarse y utilizarse con senso­
res de movimiento de primera generación.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 595  
MIG_008 Los sensores de movimiento de segunda generación podrán  
emparejarse y utilizarse solo con unidades instaladas en el 
vehículo de segunda generación, sea cual sea la versión, o 
con unidades instaladas en el vehículo de las dos 
generaciones.  
2.4. Interoperabilidad entre las unidades instaladas en el vehículo, las 
tarjetas de tacógrafo y los equipos para la transferencia de datos  
MIG_009 Los equipos para la transferencia de datos podrán ser c ompa­
tibles con todas las generaciones y versiones de las unidades 
instaladas en el vehículo y las tarjetas de tacógrafo.  
2.4.1  Transferencia de datos directamente de la tarjeta por IDE  
MIG_010 La transferencia de los datos se realizará por IDE desd e las 
tarjetas de tacógrafo de una generación insertadas en sus lec­
tores de tarjetas, utilizando los mecanismos de seguridad y el 
protocolo de transferencia de datos de esa generación, y los 
datos transferidos deberán tener el formato definido para la 
generación y la versión correspondientes.  
MIG_011 Para permitir el control de los conductores por parte d e auto­
ridades de control de fuera de la UE, también será posible la 
trasferencia de datos de las tarjetas de conductor (y de taller ) 
de segunda generación, sea cual sea la versión, exactamente 
de la misma manera que las tarjetas de conductor (y de taller) 
de primera generación. Dicha transferencia incluirá:  
— EF IC e ICC no firmados (opcional),  
— EF (primera generación) no firmados Card_Certificate y 
CA_Certificate,  
— el resto de EF con datos de aplicación (dentro del DF 
Tachograph) requeridos por el protocolo de transferencia 
de datos de la tarjeta de primera generación. Esta infor­
mación deberá estar protegida con una firma digital, con­
forme a los mecanismos de seguridad de la primera gene­
ración.  
Dicha trasferencia de datos no incluirá EF con datos de 
aplicación solo presentes en la versión 1 o la versión 2 de 
las tarjetas de conductor (y de taller) de segunda genera­
ción (EF con datos de aplicación dentro del DF Tacho­
graph_G2).»;  
2.4.2  Transferencia de datos de la tarjeta a través de una unidad instalada en 
el vehículo  
MIG_012 Los datos se trasferirán desde cualquier versión de una  tarjeta 
de segunda generación insertada en una unidad instalada en el 
vehículo de primera generación utilizando el protocolo de 
transferencia de datos de primera generación. La tarjeta deberá  
responder a los comandos de la unidad instalada en el vehí­
culo exactamente del mismo modo que una tarjeta de primera 
generación y los datos transferidos deberán tener el mismo 
formato que los datos transferidos desde una tarjeta de pri­
mera generación.  
MIG_013 Los datos se transferirán desde una tarjeta de primera gene­
ración insertada en cualquier versión de una unidad instalada 
en el vehículo de segunda generación utilizando el protocolo 
de transferencia de datos definido en el apéndice 7 del pre­
sente anexo. La unidad instalada en el vehículo deberá enviar 
comandos a la tarjeta exactamente de la misma manera que 
una unidad instalada en el vehículo de primera generación, y 
los datos transferidos deberán respetar el formato definido 
para las tarjetas de primera generación.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 596  
2.4.3  Transferencia de datos de la unidad instalada en el vehículo  
MIG_014 Fuera del marco del control de conductores por parte de  las 
autoridades de control de fuera de la UE, los datos serán 
transferidos desde las unidades instaladas en el vehículo de 
segunda generación utilizando los mecanismos de seguridad 
de segunda generación, y el protocolo de transferencia de 
datos especificado en el apéndice 7 del presente anexo con 
respecto a la versión pertinente.  
MIG_015 Para permitir el control de los conductores por parte d e las 
autoridades de control de fuera de la UE, también podrá exis­
tir la opción de realizar la trasferencia de datos desde cual­
quier versión de las unidades instaladas en el vehículo de 
segunda generación utilizando los mecanismos de seguridad 
de la primera generación. Los datos transferidos deberán tener 
entonces el formato de los datos transferidos desde una unidad 
instalada en el vehículo de primera generación. Esta capacidad 
podrá seleccionarse mediante comandos del menú.  
2.5. Interoperabilidad entre la VU y el equipo de calibrado  
MIG_016 El equipo de calibrado deberá ser capaz de efectuar el cali­
brado de cada generación o versión de tacógrafos utilizando el 
protocolo de calibrado de dicha generación o versión. El 
equipo de calibrado podrá ser compatible con todas las gene­
raciones y versiones de las unidades instaladas en el vehículo.  
3. ETAPAS PRINCIPALES DURANTE EL PERÍODO PREVIO A LA FE­
CHA DE INTRODUCCIÓN  
MIG_017 Las claves y los certificados de los ensayos deberán es tar a 
disposición de los fabricantes en la fecha de publicación del 
presente anexo.  
MIG_018 Los ensayos de interoperabilidad deberán estar listos p ara 
empezar con la versión 2 de las unidades instaladas en el 
vehículo y la versión 2 de las tarjetas de tacógrafo, si los 
solicitan los fabricantes, a más tardar  quince meses  antes de 
la fecha de introducción.  
MIG_019 Para la versión 2 de los tacógrafos, las tarjetas de ta cógrafo y 
los sensores de movimiento de segunda generación se utilizan 
las mismas claves y los mismos certificados que para el 
equipo de la versión 1 de la segunda generación.  
MIG_020 Los Estados miembros deberán poder expedir la versión 2  de 
las tarjetas de taller de segunda generación a más tardar  un 
mes antes de la fecha de introducción.  
MIG_021 Los Estados miembros deberán poder expedir los demás ti pos 
de la versión 2 de las tarjetas de tacógrafo de segunda gene­
ración a más tardar  un mes  antes de la fecha de introducción.  
4. DISPOSICIONES PARA EL PERÍODO POSTERIOR A LA FECHA DE 
INTRODUCCIÓN  
MIG_022 Con efectos a partir de la fecha de introducción, los E stados 
miembros solo expedirán la versión 2 de las tarjetas de tacó­
grafo de segunda generación.  
MIG_023 Los fabricantes de unidades instaladas en el vehículo y /o de 
sensores de movimiento estarán autorizados a producir unida­
des instaladas en el vehículo y sensores de movimiento de 
primera generación en tanto se utilicen sobre el terreno, para 
que los componentes que funcionen mal puedan sustituirse.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 597  
MIG_023a Con efectos a partir de la fecha de introducción, las unidades 
instaladas en el vehículo o los dispositivos GNSS externos de 
la versión 1 de la primera generación que funcionen mal 
podrán sustituirse con unidades instaladas en el vehículo o 
dispositivos GNSS externos de la versión 2 de la segunda 
generación.  
MIG_024 Los fabricantes de unidades instaladas en el vehículo y /o de 
sensores de movimiento estarán autorizados a solicitar y ob­
tener el mantenimiento de la homologación de las unidades 
instaladas en el vehículo o los sensores de movimiento de 
primera generación o de la versión 1 de las unidades instala­
das en el vehículo de segunda generación ya homologados.  
5. REGISTRO DE LOS CRUCES DE FRONTERAS EN LOS TACÓGRA­
FOS DE PRIMERA GENERACIÓN Y DE LA PRIMERA VERSIÓN DE 
LA SEGUNDA GENERACIÓN  
MIG_025 El símbolo del país y, si procede, de la región en la q ue el 
conductor entre tras cruzar la frontera de un Estado miembro 
en aplicación del artículo 34, apartado 7, del Reglamento (UE) 
n. o 165/2014, se introducirá como lugar donde comienza el 
período de trabajo diario de conformidad con la introducción 
manual de los lugares conforme a los requisitos 60 del 
anexo I C del citado Reglamento y 50 del anexo I B del 
Reglamento (CEE) n.  o 3821/85.  ▼M3
 02016R0799 — ES — 21.08.2023 — 003.001 — 598  
Apéndice 16  
ADAPTADOR PARA VEHÍCULOS DE LAS CATEGORÍAS M 1 Y N1  
ÍNDICE  
1. ABREVIATURAS Y DOCUMENTOS DE REFERENCIA  
1.1. Abreviaturas  
1.2. Normas de referencia  
2. CARACTERÍSTICAS GENERALES Y FUNCIONES DEL ADAPTA­ 
DOR  
2.1. Descripción general del adaptador  
2.2. Funciones  
2.3. Seguridad  
3. REQUISITOS RELATIVOS AL APARATO DE CONTROL EQUIPADO 
CON UN ADAPTADOR  
4. CONDICIONES DE FABRICACIÓN Y FUNCIONAMIENTO DEL 
ADAPTADOR  
4.1. Interconexión y adaptación de los impulsos de velocidad de  entrada  
4.2. Inducción de los impulsos de entrada al sensor de movimien to integrado  
4.3. Sensor de movimiento integrado  
4.4. Requisitos de seguridad  
4.5. Características de funcionamiento  
4.6. Materiales  
4.7. Inscripciones  
5. INSTALACIÓN DEL APARATO DE CONTROL EQUIPADO CON UN 
ADAPTADOR  
5.1. Instalación  
5.2. Precintos  
6. VERIFICACIONES, CONTROLES Y REPARACIONES  
6.1. Controles periódicos  
7. HOMOLOGACIÓN DEL APARATO DE CONTROL EQUIPADO CON 
UN ADAPTADOR  
7.1. Aspectos generales  
7.2. Certificado funcional  
1. ABREVIATURAS Y DOCUMENTOS DE REFERENCIA  
1.1. Abreviaturas  
▼C2 
TBD Pendiente de definición ( to be defined ) 
VU Unidad instalada en el vehículo ( Vehicle Unit ) 
▼B 
1.2. Normas de referencia  
ISO16844-3 Vehículos de carretera — Sistemas de tacógrafo — Par te 3: 
Interfaz del sensor de movimiento  
2. CARACTERÍSTICAS GENERALES Y FUNCIONES DEL ADAPTA­
DOR  
2.1. Descripción general del adaptador  
ADA_001 El adaptador proporcionará a la VU conectada unos datos  de 
movimiento seguros representativos en todo momento de la 
velocidad del vehículo o de la distancia recorrida.  
El adaptador está destinado únicamente a los vehículos que 
deben estar provistos de un aparato de control de conformidad 
con el presente Reglamento.  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 599  
Se instalará y utilizará solo en los tipos de vehículos definid os 
en la letra yy) «adaptador» del anexo IC cuando no resulte 
posible mecánicamente instalar ningún otro tipo de sensor de 
movimiento existente que por su parte cumpla las disposiciones 
del presente anexo y sus apéndices 1 a 16.  
El adaptador no estará conectado mediante una interfaz mecá­
nica a una parte móvil del vehículo, sino a los impulsos de 
velocidad o distancia generados por sensores integrados o in­
terfaces alternativas.  
ADA_002 En la caja del adaptador se colocará un sensor de movim iento 
homologado (con arreglo a las disposiciones del presente 
anexo IC, sección 8, Homologación de aparatos de control y 
tarjetas de tacógrafo) junto con un procesador de impulsos que 
inducirá los impulsos de entrada al sensor de movimiento inte­
grado. El propio sensor de movimiento integrado estará conec­
tado a la VU, de tal modo que la interfaz entre la VU y el 
adaptador cumplirá los requisitos de la norma ISO16844-3.  
2.2. Funciones  
ADA_003 El adaptador ejercerá las siguientes funciones:  
— interconexión y adaptación de los impulsos de velocidad de 
entrada,  
— inducción de los impulsos de entrada al sensor de movi­
miento integrado,  
— todas las funciones del sensor de movimiento integrado, 
proporcionando datos de movimiento seguros a la VU.  
2.3. Seguridad  
ADA_004 El adaptador no obtendrá la certificación de seguridad de 
acuerdo con el objetivo genérico de seguridad del sensor de 
movimiento definido en el apéndice 10 del presente anexo. En 
su lugar serán de aplicación los requisitos de seguridad esta­
blecidos en la sección 4.4 del presente apéndice.  
3. REQUISITOS RELATIVOS AL APARATO DE CONTROL EQUIPADO 
CON UN ADAPTADOR  
Los requisitos que figuran en los siguientes capítulos explican  cómo deben 
entenderse los requisitos del presente anexo cuando se utiliza un adapta­
dor. Los números de requisito correspondientes del anexo IC se indican 
entre paréntesis.  
ADA_005 El aparato de control de todo vehículo que esté equipad o con 
un adaptador debe cumplir todas las disposiciones del presente 
anexo, a menos que se especifique otra cosa en el presente 
apéndice.  
ADA_006 Cuando se instala un adaptador, el aparato de control i ncluye 
los cables, el adaptador (incluido un sensor de movimiento) y 
una VU (01).  
ADA_007 La función de detección de incidentes o fallos del apar ato de 
control se modifica como sigue:  
— El incidente «Interrupción del suministro eléctrico» es ac­
tivado por la VU cuando el suministro eléctrico del sensor 
de movimiento integrado se interrumpe durante más de 200 
milisegundos, fuera del modo de calibrado (79).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 600  
— El incidente «Error de datos de movimiento» es activado 
por la VU en caso de interrupción del flujo normal de datos 
entre el sensor de movimiento integrado y la VU, o en caso 
de producirse un error de integridad o de autenticación de 
datos durante el intercambio de datos entre el sensor de 
movimiento integrado y la VU (83).  
— El incidente «Intento de violación de la seguridad» es ac­
tivado por la VU ante cualquier otro incidente que afecte a 
la seguridad del sensor de movimiento integrado, fuera del 
modo de calibrado (85).  
— El fallo «aparato de control» es activado por la VU ante un 
fallo del sensor de movimiento incorporado, fuera del 
modo de calibrado (88).  
ADA_008 Los fallos del adaptador que podrá detectar el aparato de con­
trol serán los relativos al sensor de movimiento integrado (88) . 
ADA_009 La función de calibrado de la VU permitirá el emparejam iento 
automático del sensor de movimiento integrado con la VU 
(202, 204).  
4. CONDICIONES DE FABRICACIÓN Y FUNCIONAMIENTO DEL 
ADAPTADOR  
4.1. Interconexión y adaptación de los impulsos de velocidad de entrada  
ADA_011 La interfaz de entrada del adaptador aceptará impulsos de fre­
cuencia que representarán la velocidad del vehículo y la dis­
tancia recorrida. Las características eléctricas de los impulso s 
de entrada serán:  a discreción del fabricante . Los ajustes ac­
cesibles solamente al fabricante del adaptador y al taller auto ­
rizado que efectúa la instalación del adaptador permitirán, en 
su caso, la interconexión correcta de la entrada del adaptador al 
vehículo.  
▼M3 
ADA_012 La interfaz de la entrada del adaptador podrá, en su ca so, 
multiplicar o dividir los impulsos de frecuencia de los impulso s 
de velocidad de entrada por un factor fijo, a fin de adaptar la  
señal al intervalo de valores del factor k definido en el prese nte 
anexo (2 400 a 25 000 impulsos/km). Solo el fabricante del 
adaptador y el taller autorizado que efectúa la instalación del  
adaptador podrán programar este factor fijo.  
▼B 
4.2. Inducción de los impulsos de entrada al sensor de movimiento inte ­
grado  
ADA_013 Los impulsos de entrada, adaptados posiblemente con arr eglo a 
lo expuesto anteriormente, serán inducidos al sensor de movi­
miento integrado, de modo que cada impulso de entrada será 
detectado por el sensor.  
4.3. Sensor de movimiento integrado  
ADA_014 El sensor de movimiento integrado será estimulado por l os 
impulsos inducidos, lo que le permitirá generar datos de mo­
vimiento que representarán con exactitud el movimiento del 
vehículo, como si estuviera conectado mediante una interfaz 
mecánica a una parte móvil del vehículo.  
ADA_015 La VU utilizará los datos de identificación del sensor de mo­
vimiento integrado para identificar el adaptador (95).  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 601  
ADA_016 Se considerará que los datos de instalación almacenados  en el 
sensor de movimiento integrado representan los datos de ins­
talación del adaptador (122).  
4.4. Requisitos de seguridad  
ADA_017 La caja del adaptador se diseñará de manera que no pued a 
abrirse. Se precintará para que los intentos de manipulación 
física puedan detectarse con facilidad (por ejemplo, mediante 
inspección visual, véase ADA_035). Los precintos deberán 
cumplir los mismos requisitos que los precintos del sensor de 
movimiento (398 a 406).  
ADA_018 Será imposible retirar el sensor de movimiento integrad o del 
adaptador sin romper el precinto o precintos de la caja del 
adaptador o el precinto entre el sensor y la caja del adaptador  
(véase ADA_034).  
ADA_019 El adaptador garantizará que los datos de movimiento so lo se 
puedan procesar y extraer de la entrada del adaptador.  
4.5. Características de funcionamiento  
ADA_020 El adaptador funcionará perfectamente en el intervalo d e tem­
peraturas determinado por el fabricante.  
ADA_021 El adaptador funcionará perfectamente en el intervalo h igromé­
trico del 10 % al 90 % (214).  
ADA_022 El adaptador estará protegido frente a sobretensiones, inversio­
nes de polaridad de la fuente de alimentación y cortocircuitos 
(216).  
ADA_023 Los adaptadores:  
— reaccionarán a todo campo magnético que perturbe la de­
tección de movimiento del vehículo; en estas circunstan­
cias, la unidad instalada en el vehículo registrará y alma­
cenará un fallo del sensor (88), o bien  
— estarán dotados de un sensor protegido de los campos mag­
néticos o invulnerable a estos (217).  
ADA_024 El adaptador se ajustará a la regulación internacional en el 
Reglamento n.  o 10 de la CEPE de las Naciones Unidas, rela­
tiva a la compatibilidad electromagnética, y deberá estar pro­
tegido contra descargas electromagnéticas y fluctuaciones de la  
tensión (218).  
4.6. Materiales  
ADA_025 El adaptador tendrá la clase de protección ( a discreción del 
fabricante, dependiendo de la posición de instalación ) (220, 
221).  
ADA_026 La caja del adaptador será de color amarillo.  
4.7. Inscripciones  
ADA_027 El adaptador llevará una placa descriptiva con la infor mación 
siguiente:  
— nombre y domicilio del fabricante del adaptador,  
— número de pieza del fabricante y año de fabricación del 
adaptador,  
— marca de homologación del modelo de adaptador o del 
aparato de control que incluye el adaptador,  
— fecha de instalación del adaptador,  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 602  
— VIN del vehículo en el que se ha instalado.  
ADA_028 Además, la placa descriptiva deberá contener la informa ción 
siguiente (si no es legible directamente desde fuera del sensor  
de movimiento integrado):  
— nombre del fabricante del sensor de movimiento integrado,  
— número de pieza del fabricante y año de fabricación del 
sensor de movimiento integrado,  
— marca de homologación del sensor de movimiento 
integrado.  
5. INSTALACIÓN DEL APARATO DE CONTROL EQUIPADO CON UN 
ADAPTADOR  
5.1. Instalación  
ADA_029 Los adaptadores destinados a los vehículos solo podrán ser 
instalados por los fabricantes de vehículos, o por talleres aut o­
rizados para instalar, activar y calibrar tacógrafos digitales y 
tacógrafos inteligentes.  
ADA_030 El taller autorizado que instale el adaptador ajustará la interfaz 
de entrada y seleccionará el factor de división de la señal de 
entrada (si procede).  
ADA_031 El taller autorizado que instale el adaptador precintar á su caja.  
ADA_032 El adaptador se colocará lo más cerca posible de la par te del 
vehículo que proporcione sus impulsos de entrada.  
ADA_033 Los cables que alimenten el adaptador serán rojos (carg a po­
sitiva) y negros (tierra).  
5.2. Precintos  
ADA_034 Serán de aplicación los siguientes requisitos de precin tado:  
— se precintará la caja del adaptador (véase ADA_017),  
— se colocará un precinto entre la caja del sensor integrado y 
la caja del adaptador, a menos que sea imposible retirar el 
sensor integrado sin romper el precinto o los precintos de la 
caja del adaptador (véase ADA_018),  
— se colocará un precinto entre la caja del adaptador y el 
vehículo,  
— la conexión entre el adaptador y el equipo que proporciona 
sus impulsos de entrada se precintará en ambos extremos 
(en la medida de lo razonablemente posible).  
6. VERIFICACIONES, CONTROLES Y REPARACIONES  
6.1. Controles periódicos  
ADA_035 Cuando se utilice un adaptador, en cada control periódi co (con­
troles periódicos son aquellos que se ajustan a los requisitos 
(409) a (413) del anexo IC) del aparato de control, se verifica rá 
lo siguiente:  
— si el adaptador lleva las inscripciones de homologación 
adecuadas,  
— si están intactos los precintos del adaptador y sus 
conexiones,  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 603  
— si el adaptador está instalado de acuerdo con las indicacio­
nes de la placa de instalación,  
— si el adaptador está instalado con arreglo a las especifica­
ciones del fabricante del adaptador o del vehículo,  
— si está autorizado el montaje de un adaptador en el vehículo 
inspeccionado.  
ADA_036 Dichos controles deberán incluir un calibrado y una sus titución 
de todos los precintos, sea cual sea su estado.  
7. HOMOLOGACIÓN DEL APARATO DE CONTROL EQUIPADO CON 
UN ADAPTADOR  
7.1. Aspectos generales  
ADA_037 El aparato de control se presentará completo a la homol oga­
ción, provisto del adaptador (425).  
ADA_038 Todo adaptador podrá presentarse a su propia homologaci ón o 
a la homologación como componente de un aparato de control.  
ADA_039 La homologación incluirá los ensayos funcionales del ad apta­
dor. El resultado positivo de cada uno de estos ensayos se 
consignará en un certificado (426).  
7.2. Certificado funcional  
ADA_040 Se entregará al fabricante del adaptador un certificado  funcio­
nal del adaptador o del aparato de control provisto de un 
adaptador una vez superados los siguientes ensayos funcionales 
mínimos.  
N. o Ensayo  Descripción  Requisitos correspon­
dientes  
1. Examen administrativo  
1.1 Documentación  Corrección de la do­
cumentación del 
adaptador  
2. Inspección visual  
2.1. Conformidad del adaptador con la documenta­
ción 
2.2. Identificación/inscripciones del adaptador  ADA_027, 
ADA_028  
2.3 Materiales del adaptador  (219) a (223) 
ADA_026  
2.4. Precintos  ADA_017, 
ADA_018, 
ADA_034  
3. Ensayos funcionales  
3.1 Inducción de los impulsos de velocidad al sensor 
de movimiento integrado  ADA_013  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 604  
N. o Ensayo  Descripción  Requisitos correspon­
dientes  
3.2 Interconexión y adaptación de los impulsos de 
velocidad de entrada  ADA_011, 
ADA_012  
3.3 Precisión de la medición del movimiento  (30) a (35), (217)  
4. Ensayos ambientales  
4.1 Resultados de ensayo del 
fabricante  Resultados de los 
ensayos ambientales 
del fabricante.  ADA_020, 
ADA_021, 
ADA_022, 
ADA_024  
5. EMC  
5.1 Emisiones radiadas y sus­
ceptibilidad  Verificar cumpli­
miento de la Direc­
tiva 2006/28/CE  ADA_024  
5.2 Resultados de ensayo del 
fabricante  Resultados de los 
ensayos ambientales 
del fabricante.  ADA_024  ▼B
 02016R0799 — ES — 21.08.2023 — 003.001 — 605  
ANEXO II  
MARCA Y FICHA DE HOMOLOGACIÓN  
I. MARCA DE HOMOLOGACIÓN  
1. La marca de homologación estará compuesta por:  
a) un rectángulo en el que se inscriba la letra «e» minúscula s eguida de un 
número distintivo o de una letra distintiva del país que haya e xpedido la 
homologación, con arreglo a lo siguiente: 
Bélgica  6 ,  
Bulgaria  34,  
República Checa  8 ,  
Dinamarca  18,  
Alemania  1 ,  
Estonia  29,  
Irlanda  24,  
Grecia  23,  
España  9 ,  
Francia  2 ,  
Croacia  25,  
Italia  3 ,  
Chipre  CY,  
Letonia  32,  
Lituania  36,  
Luxemburgo  13,  
Hungría  7 ,  
Malta  MT,  
Países Bajos  4 ,  
Austria  12,  
Polonia  20,  
Portugal  21,  
Rumanía  19,  
Eslovenia  26,  
Eslovaquia  27,  
Finlandia  17,  
Suecia  5 ,  
Reino Unido  11,  
y 
▼M1 
b) un número de homologación correspondiente al número del cert ificado de 
homologación que se haya asignado al prototipo del aparato de c ontrol o 
de la hoja de registro o de la tarjeta de tacógrafo, colocado e n cualquier 
posición cerca del rectángulo.  ▼C1
 02016R0799 — ES — 21.08.2023 — 003.001 — 606  
2. La marca de homologación se colocará en la placa descriptiva  de cada aparato 
y en cada hoja de registro y en cada tarjeta de tacógrafo. Debe rá ser indeleble 
y ser siempre legible.  
3. Las dimensiones de la marca de homologación reproducida a co ntinuación (  1 ), 
se expresarán en mm, y dichas dimensiones serán las mínimas. De berán 
respetarse las relaciones entre distintas dimensiones.
  ▼C1 
( 1 ) Estas cifras tienen únicamente carácter informativo.
 02016R0799 — ES — 21.08.2023 — 003.001 — 607  
II. CERTIFICADO DE HOMOLOGACIÓN DE TACÓGRAFOS ANALÓGICOS  
El Estado miembro que haya procedido a una homologación expedir á al solici­
tante un certificado de homologación, extendido de acuerdo con el siguiente 
modelo. Para la comunicación a los demás Estados miembros de la s homologa­
ciones concedidas o de las posibles retiradas, cada Estado miem bro utilizará 
copias de dicho documento.  
CERTIFICADO DE HOMOLOGACIÓN  
Administración competente  
Comunicación relativa a (  1 ): 
— la homologación de un modelo de aparato de control  
— la retirada de la homologación de un modelo de aparato de con trol 
— la homologación de un modelo de hoja de registro  
— la retirada de la homologación de un modelo de hoja de regist ro 
N o de homologació  
...................................  
1. Marca de fábrica o de comercio  
2. Denominación del modelo  
3. Nombre del fabricante  
4. Dirección del fabricante  
5. Presentado para su homologación el  
6. Laboratorio de ensayo  
7. Fecha y número del ensayo o ensayos  
8. Fecha de homologación  
9. Fecha de la retirada de la homologación  
10. Modelo o modelos de aparato de control en los que la hoja v a a ser utilizada  
11. Lugar  
12. Fecha  
13. En anexo, documentos descriptivos  
14. Observaciones (por ejemplo, la posición de los precintos si  procede)  
(Firma)  ▼C1 
( 1 ) Táchese lo que no proceda.
 02016R0799 — ES — 21.08.2023 — 003.001 — 608  
III. CERTIFICADO DE HOMOLOGACIÓN PARA TACÓGRAFOS DIGITALES  
El Estado miembro que haya procedido a una homologación expedir á al solici­
tante un certificado de homologación, extendido de acuerdo con el siguiente 
modelo. Para la comunicación a los demás Estados miembros de la s homologa­
ciones concedidas o de las posibles retiradas, cada Estado miem bro utilizará 
copias de dicho documento.  
CERTIFICADO DE HOMOLOGACIÓN PARA TACÓGRAFOS DIGITALES  
Administración competente  
Comunicación relativa a (  1 ): 
□ la homologación de:  □  la retirada de la homologación de:  
□ modelo de aparato de control  
□ componente del aparato de control (  2 ) 
□ una tarjeta de conductor  
□ una tarjeta de taller  
□ una tarjeta de empresa  
□ una tarjeta de controlador  
N o de homologación:  
1. Nombre o marca registrada del fabricante  
2. Denominación del modelo  
3. Nombre del fabricante  
4. Dirección del fabricante  
▼M1 
5. Presentado para su homologación el  
▼C1 
6. Laboratorio(s) de ensayo  
7. Fecha y número del informe de laboratorio  
8. Fecha de homologación  
9. Fecha de la retirada de la homologación  
10. Modelo o modelos de aparato de control con los que vaya a u tilizarse el 
componente  
11. Lugar  
12. Fecha  
13. En anexo, documentos descriptivos  
14. Observaciones (por ejemplo, la posición de los precintos si  procede)  
(Firma)  ▼C1 
( 1 ) Marque las casillas correspondientes. 
( 2 ) Especifique el componente de que se trata en la comunicación.
 02016R0799 — ES — 21.08.2023 — 003.001 — 609  
IV. CERTIFICADO DE HOMOLOGACIÓN DE TACÓGRAFOS INTELIGENTES  
El Estado miembro que haya procedido a una homologación expedir á al solici­
tante un certificado de homologación, extendido de acuerdo con el siguiente 
modelo. Para la comunicación a los demás Estados miembros de la s homologa­
ciones concedidas o de las posibles retiradas, cada Estado miem bro utilizará 
copias de dicho documento.  
CERTIFICADO DE HOMOLOGACIÓN DE TACÓGRAFOS INTELIGENTES  
Administración competente  
Comunicación relativa a (  1 ): 
□ la homologación de:  □  la retirada de la homologación de:  
□ modelo de aparato de control  
□ componente del aparato de control (  2 ) 
□ una tarjeta de conductor  
□ una tarjeta de taller  
□ una tarjeta de empresa  
□ una tarjeta de controlador  
N o de homologación:  
1. Nombre o marca registrada del fabricante  
2. Denominación del modelo  
3. Nombre del fabricante  
4. Dirección del fabricante  
▼M1 
5. Presentado para su homologación el  
▼C1 
6. a) Laboratorio de ensayo de certificación funcional  
b) Laboratorio de ensayo de certificación de la seguridad  
c) Laboratorio de ensayo de certificación de la interoperabilid ad 
7. a) Fecha y número del certificado funcional  
b) Fecha y número del certificado de seguridad  
c) Fecha y número del certificado de interoperabilidad  
8. Fecha de homologación  
9. Fecha de la retirada de la homologación  
10. Modelo o modelos de aparato de control con los que vaya a u tilizarse el 
componente  
11. Lugar  
12. Fecha  
13. En anexo, documentos descriptivos  
14. Observaciones (por ejemplo, la posición de los precintos si  procede)  
(Firma)  ▼C1 
( 1 ) Marque las casillas correspondientes. 
( 2 ) Especifique el componente de que se trata en la comunicación.