EUR-Lex Document 02016R0799-20230821

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 20 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
►M4 Reglamento de Ejecución (UE) 2023/980 de la Comisión de 16 de
mayo de 2023
L 134 28 22.5.2023
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.002 — 1
02016R0799 — ES — 21.08.2023 — 003.002 — 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 necesarias para
la aplicación uniforme de los siguientes aspectos en relación con 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 indebidos
del tacógrafo inteligente;
c) interfaz con los sistemas de transporte inteligentes;
d) requisitos técnicos y administrativos para los procedimientos de ho­
mologación de los tacógrafos, incluidos los mecanismos de
seguridad.
▼M1
2. La construcción, ensayo, instalación, inspección, funcionamiento y
reparación de los tacógrafos inteligentes y sus componentes deberán
cumplir los requisitos técnicos establecidos en el anexo IC del presente
Reglamento.
3. Los tacógrafos distintos de los tacógrafos inteligentes seguirán
teniendo que cumplir, en lo que se refiere a las condiciones de cons­
trucción, ensayo, instalación, inspección, funcionamiento y reparació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 de
teledetección temprana transmitirá asimismo los datos sobre peso 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 Directiva
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 definiciones
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 por la que se
deroga la Directiva 1999/5/CE (DO L 153 de 22.5.2014, p. 62).
02016R0799 — ES — 21.08.2023 — 003.002 — 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 receptor
GNSS cuando la unidad instalada en el vehículo no sea una unidad
ú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 for­
mato electrónico o en papel, que contiene toda la información
facilitada por el fabricante o su agente a la autoridad de homolo­
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 finalizar
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 indica
el contenido numerado del expediente de homologación, identifi­
cando todas sus partes pertinentes; el formato de dicho documento
distinguirá las sucesivas etapas del proceso de homologación de
tipo CE, incluidas las fechas de las revisiones y actualizaciones del
expediente;
6) «dispositivo de teledetección temprana»: el equipo de la unidad
instalada en el vehículo que se utiliza para llevar a cabo controles
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 siguien­
tes: la unidad instalada en el vehículo, el sensor de movimiento, 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 miembro
competente para llevar a cabo la homologación del tacógrafo o de
sus componentes, el proceso de autorización, la expedición y, en 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 fabricantes
cumplen sus obligaciones relativas a la conformidad con los requi­
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 repartidas
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.002 — 4
segundo conductor, una impresora, una pantalla, conectores y dis­
positivos para que el usuario introduzca datos, un receptor GNSS 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 (con
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 (con
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 unida­
des repartidas por el vehículo, el cuerpo principal es la unidad 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 «uni­
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 Galileo y
por el sistema europeo de navegación por complemento geoestacionario
(EGNOS).
2. Además de los sistemas a que se refiere el apartado 1, los fabri­
cantes podrán también optar por garantizar la compatibilidad con 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 homolo­
gación de un tacógrafo, o de alguno de sus componentes, o grupo de
componentes, a las autoridades de homologación designadas por cada
Estado miembro. La solicitud consistirá en un expediente del fabricante
que contenga la información sobre cada uno de los componentes en
cuestión, así como, en su caso, los certificados de homologación de
los demás componentes necesarios para completar el tacógrafo, junto
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 requisitos
administrativos y técnicos a que se refiere el artículo 1, apartados 2 o
3, según proceda. En tal caso, la autoridad de homologación expedirá 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.002 — 5
4. El fabricante o su mandatario pondrá a disposición de las autori­
dades de homologación, así como de las entidades responsables de la
expedición de los certificados mencionadas en el artículo 12, apartado 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 forma
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ógrafo,
facilitará a las autoridades de homologación los demás componentes, ya
homologados, así como las demás piezas necesarias para la construcció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 autori­
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 en su
fabricación que figuran en el expediente de homologación y presentarán
una solicitud de modificación de la homologación.
2. Las autoridades de homologación podrán revisar o extender una
homologación existente, o expedir una nueva, en función de la natura­
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 el 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 homolo­
gación expedirá los documentos revisados del expediente de homologa­
ción, indicando la naturaleza de las modificaciones efectuadas y la fecha
de su aprobación. Bastará para satisfacer este requisito una versión
actualizada del expediente de homologación en forma consolidada,
acompañada de una descripción pormenorizada de las modificaciones.
Se procederá a una «extensión» cuando la autoridad de homologación
considere que las modificaciones en el software o el 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 lleven a
cabo nuevos ensayos, de lo cual informará al fabricante o a su manda­
tario. Si estos ensayos resultan satisfactorios, la autoridad de homolo­
gación expedirá un certificado de homologación revisado que contendrá
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 de la
extensión o revisión más reciente de la homologación, o la fecha de la
consolidación más reciente de la versión actualizada de la homologa­
ción.
4. Será necesaria una nueva homologación cuando las modificaciones
solicitadas del tacógrafo homologado o de sus componentes obligarían a
expedir un nuevo certificado de seguridad o de interoperabilidad.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 junio 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.002 — 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 los perío­
dos de trabajo diarios
3.6.2 Introducción manual de las actividades del conductor y del 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 comunica­
ción a distancia»
3.9.10 Incidente «Ausencia de información sobre la posición procedente
del receptor GNSS»
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 vehí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 navegación
por satélite
3.12.2 Claves y certificados
3.12.3 Datos de inserción y extracción de la tarjeta de conductor 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 tacógrafo de
primera generación
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 9
3.14.2 Registro y almacenamiento de datos en las tarjetas de tacó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 selectivos
▼M3
3.20 Intercambios de datos con dispositivos externos adicionales
▼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 segunda 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, presente 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 instaladas 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.002 — 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 trabajo 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 accesible 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 accesible para la ver­
sión 1 de las unidades instaladas en el vehículo de segunda gene­
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 acumuladas
▼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 (no
accesible para la versión 1 de las unidades instaladas en el vehículo
de segunda generación)
4.5.3.2.18 Estado de autenticación para posiciones en las que se 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 segunda
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.002 — 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 versió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 instaladas 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 de 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 accesible 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 accesible para la ver­
sión 1 de las unidades instaladas en el vehículo de segunda gene­
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 de trabajo
diarios
4.5.4.2.11 Datos de la sesión
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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 acumuladas
▼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 (no
accesible para la versión 1 de las unidades instaladas en el vehículo
de segunda generación)
4.5.4.2.17 Estado de autenticación para posiciones en las que se 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 segunda
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 versió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 instaladas 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 accesible para la ver­
sión 1 de las unidades instaladas en el vehículo de segunda gene­
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.002 — 13
4.5.6.1 Aplicación del tacógrafo (accesible a las unidades instaladas 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 accesible para la ver­
sión 1 de las unidades instaladas en el vehículo de segunda gene­
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 interoperabi­
lidad para los aparatos de control y las tarjetas de tacógrafo de
segunda generación
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 14
INTRODUCCIÓN
El presente anexo contiene las condiciones relativas a la segunda generación de
aparatos de control y tarjetas de tacógrafo.
Desde el 15 de junio de 2019 se están instalando aparatos de control de segunda
generación en los vehículos que se matriculan en la Unión por primera 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 de segunda gene­
ración, se han diseñado tarjetas de tacógrafo de segunda generació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 generació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 sistemas de tacógrafo de
primera y segunda generación se especifican en el presente anexo. A este res­
pecto, el apéndice 15 contiene información adicional sobre la gestió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 conductor, el presente
Reglamento introduce los requisitos técnicos para la segunda versión de los
aparatos de control y las tarjetas de tacógrafo de segunda generació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.002 — 15
1 DEFINICIONES
A los efectos del presente anexo, se aplicarán las siguientes defini­
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 un
aparato de control, los tipos y los identificadores de todos los
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 asigna­
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.002 — 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 basan
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 tiempo 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 calcular 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 manualmente 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 disposiciones en materia social en el
sector de los transportes 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 (DO L 102 de 11.4.2006, p. 1).
02016R0799 — ES — 21.08.2023 — 003.002 — 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 acu­
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 basan
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 totalidad
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 tiempo 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 calcular 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 manualmente las actividades
del conductor.
02016R0799 — ES — 21.08.2023 — 003.002 — 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ículo.
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 que
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 relativos a las masas y dimen­
siones de los vehículos de motor y de sus remolques y por el que 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.002 — 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, relativa a la instalación y a la
utilización de dispositivos de limitación de velocidad en determinadas 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.002 — 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 de
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.002 — 21
tt) Ajuste de la hora:
Ajuste de la hora actual; este ajuste puede realizarse de manera
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, sobre los neumáticos de los
vehículos de motor y de sus remolques así como de su montaje (DO 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 placas 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écnicas independientes
destinados a dichos vehículos, por el que se modifican los Reglamentos (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.002 — 22
— se instala entre la unidad instalada en el vehículo y el lugar
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 correcta
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 actualizaciones
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 conjunto
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.002 — 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, visualizar,
imprimir y enviar datos relacionados con las actividades del
conductor.
Todo vehículo que lleve instalado un aparato de control conforme a
lo dispuesto en el presente anexo debe incorporar además un indi­
cador de velocidad y un cuentakilómetros. Estas funciones pueden
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.002 — 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 tacó­
grafo.
▼M3
Esto se efectúa con arreglo a la legislación de la Unión aplicable 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.002 — 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
R
an
ur
a
de
l
se
gu
nd
o
co
nd
uc
to
r 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á exclusivamente la tarjeta de tacógrafo insertada en la ranura del conductor.
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.002 — 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 de
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 detecte
cualquier tentativa en ese sentido; así se protege la integridad y
autenticidad de los datos intercambiados entre el sensor de movi­
miento y la unidad instalada en el vehículo, de los datos intercam­
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 confiden­
cialidad, integridad y autenticidad de los datos intercambiados a
través de la comunicación de teledetección temprana con fines de
control y se verifica la integridad y autenticidad de los datos
transferidos.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 37
Conflicto de tarjetas
Ranura del conductor
Sin tarjeta
Tarjeta de con­
ductor
Tarjeta de control Tarjeta de taller Tarjeta de empresa
R
an
ur
a
de
l
se
gu
nd
o
co
nd
uc
to
r 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
R
an
ur
a
de
l
se
gu
nd
o
co
nd
uc
to
r 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.002 — 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.002 — 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.002 — 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 media
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 al
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.002 — 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 menos
que se especifique lo contrario.
— Las lecturas del cuentakilómetros se registran con una resolució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 grados 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.002 — 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.002 — 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.002 — 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.002 — 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 una
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.002 — 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.002 — 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.002 — 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 una
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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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 NL Países Bajos
D
EST
Alemania
Estonia
A
PL
Austria
Polonia
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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 UK 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 reverso)
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.002 — 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.002 — 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 integridad y
autenticidad de los datos que intercambian las tarjetas y el aparato
de control, proteger la integridad y la autenticidad de los datos que
se transfieren de las tarjetas, permitir determinadas operaciones de
escritura en las tarjetas por parte del aparato de control exclusiva­
mente, descifrar algunos datos, descartar toda posibilidad de falsifi­
cación de los datos almacenados en las tarjetas, impedir la manipu­
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.002 — 73
4.5 Almacenamiento de datos
A efectos del presente apartado:
— las horas se registran con una resolución de un minuto, a menos
que se especifique lo contrario,
— las lecturas del cuentakilómetros se registran con una resolució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 grados y
minutos, con una resolución de 1/10 de minuto.
Las funciones, comandos y estructuras lógicas de las tarjetas de
tacógrafo, por lo que respecta al cumplimiento de las condiciones
de almacenamiento de datos, se especifican en el apéndice 2.
Si no se especifica otra cosa, el almacenamiento de datos en las
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íficos
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.002 — 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.002 — 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 una
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.002 — 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.002 — 77
4.5.3.1.8 Datos sobre fallos
A efectos del presente subapartado, la hora se registrará con una
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.002 — 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 trabajo 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.002 — 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 accesible para la ver­
sión 1 de las unidades instaladas en el vehículo de segunda gene­
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.002 — 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 una
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.002 — 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.002 — 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 una
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.002 — 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.002 — 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.002 — 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 acumuladas
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 (no
accesible para la versión 1 de las unidades instaladas en el vehí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.002 — 86
4.5.3.2.18 Estado de autenticación para posiciones en las que se 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 segunda
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.002 — 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 versió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.002 — 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.002 — 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 de 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 accesible para la ver­
sión 1 de las unidades instaladas en el vehículo de segunda gene­
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.002 — 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.002 — 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 terminan 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.002 — 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 acumuladas
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 (no
accesible para la versión 1 de las unidades instaladas en el vehí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.002 — 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 se 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 segunda
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 versió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.002 — 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.002 — 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 accesible para la ver­
sión 1 de las unidades instaladas en el vehículo de segunda gene­
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.002 — 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.002 — 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 accesible para la ver­
sión 1 de las unidades instaladas en el vehículo de segunda gene­
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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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 circunstancias
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 instaladores 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.002 — 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.002 — 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.002 — 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 los
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.002 — 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 enten­
derá el «aparato de control o sus componentes». No será preciso
homologar el cable o cables que conectan el sensor de movimiento 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 aparato.
Todo fabricante podrá solicitar la homologación de los componentes
de su aparato de control con cualquier otro tipo de componentes de
aparato de control, siempre que cada componente cumpla los requi­
sitos del presente anexo. De manera alternativa, los fabricantes 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 presente
Reglamento, existen diferentes variedades de unidades de vehículo
según el montaje de sus componentes. Sea cual sea el montaje de
los componentes de la unidad instalada en el vehículo, la antena
exterior y, en su caso, el separador de antena conectado al receptor
GNSS o al dispositivo de comunicación a distancia no forman parte
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 antenas 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 114
2.74. FullCardNumberAndGeneration
2.75. Generation
2.76. GeoCoordinates
2.77. GNSSAccuracy
▼M1
2.78. GNSSAccumulatedDriving
2.79. GNSSAccumulatedDrivingRecord
▼M3
2.79a. GNSSAuthAccumulatedDriving
2.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.002 — 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.002 — 116
2.121. RegionAlpha
2.122. RegionNumeric
2.123. RemoteCommunicationModuleSerialNumber
2.124. RSAKeyModulus
2.125. RSAKeyPrivateExponent
2.126. RSAKeyPublicExponent
2.127. RtmData
2.128. SealDataCard
2.129. SealDataVu
2.130. SealRecord
2.131. SensorApprovalNumber
2.132. SensorExternalGNSSApprovalNumber
2.133. SensorExternalGNSSCoupledRecord
2.134. SensorExternalGNSSIdentification
2.135. SensorExternalGNSSInstallation
2.136. SensorExternalGNSSOSIdentifier
2.137. SensorExternalGNSSSCIdentifier
2.138. SensorGNSSCouplingDate
2.139. SensorGNSSSerialNumber
2.140. SensorIdentification
2.141. SensorInstallation
2.142. SensorInstallationSecData
2.143. SensorOSIdentifier
2.144. SensorPaired
2.145. SensorPairedRecord
2.146. SensorPairingDate
2.147. SensorSCIdentifier
2.148. SensorSerialNumber
2.149. Signature
2.150. SignatureRecordArray
2.151. SimilarEventsNumber
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 117
2.152. SpecificConditionRecord
2.153. SpecificConditions
2.154. SpecificConditionType
2.155. Speed
2.156. SpeedAuthorised
2.157. SpeedAverage
2.158. SpeedMax
▼M3
2.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.002 — 118
2.179. VuCardRecord
2.180. VuCardRecordArray
2.181. VuCertificate
2.182. VuCertificateRecordArray
2.183. VuCompanyLocksData
2.184. VuCompanyLocksRecord
2.185. VuCompanyLocksRecordArray
▼M3
2.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.002 — 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.002 — 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.002 — 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, elementos 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 Abstracta Uno
(ASN.1) para definir los tipos de datos. Ello permite definir datos sim­
ples y estructurados sin necesidad de una sintaxis específica de 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 ajustan a
la norma ISO/CEI 8824-1. Esto significa que:
— siempre que sea posible, el significado de un tipo de datos se 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 alfabé­
ticos que comienzan con una mayúscula, aunque las mayúsculas se
utilizan en el nombre para transmitir el correspondiente significado,
— en general, los nombres de los tipos de datos están relacionados con
el nombre de los tipos de datos de los que se derivan, con el equipo
en que se almacenan los datos y con la función asociada a dichos
datos.
Si un tipo ASN.1 ya se ha definido como parte de otra norma y es
pertinente para su uso en el aparato de control, entonces ese tipo 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 identificadores 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.002 — 122
ISO/CEI 7816-5 Tarjetas de identificación — Tarjetas con circuitos
integrados — Parte 5: Registro de proveedores de
aplicaciones.
Segunda edición: 2004.
ISO/CEI 7816-6 Tarjetas de identificación — Tarjetas con circuitos
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 Sintaxis
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 codifica­
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 carac­
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 carac­
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» consistirá 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 primera y
segunda generación, a menos que se especifique otra cosa. Se indican
los tipos de datos utilizados únicamente para aplicaciones de la 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 segunda 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 aplicaciones 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 pri­
mera generación de las tarjetas de segunda generación se truncan a
los ocho primeros caracteres en caso necesario,
— en la aplicación de primera generación de las tarjetas de segunda
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.002 — 123
2.1. ActivityChangeInfo
Este tipo de datos permite codificar, en una palabra de dos bytes, el
estado de la ranura a las 00.00 horas y/o el estado del conductor 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 conductor o
un segundo conductor. Este tipo de datos está relacionado con el
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 estado 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.002 — 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 tarjeta,
— «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 posteriormente 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.002 — 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 representar un
dígito decimal en un semiocteto (4 bits). La cadena BCDString se basa
en el «CharacterStringType» de la norma ISO/CEI 8824-1.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 126
La cadena BCDString emplea una notación «hstring». El dígito hexade­
cimal situado más a la izquierda deberá ser el semiocteto más significa­
tivo del primer octeto. Para obtener un múltiplo de octetos habrá 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 primer octeto.
Los dígitos permitidos son: 0, 1, .. 9.
2.8. CalibrationPurpose
Código que explica por qué se registró un conjunto de parámetros 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 siguientes:
«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 actividades del
conductor en un día civil concreto. Este tipo de datos está relacionado
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 registro
es el registro diario más antiguo, el valor de activityPreviousRecord­
Length debe configurarse a 0.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 valores
como máximo (un cambio de actividad cada minuto). Este conjunto
incluye siempre la ActivityChangeInfo que codifica el estado del con­
ductor a las 00.00 horas.
2.10. CardActivityLengthRange
Número de bytes disponibles en una tarjeta de conductor o en una tarjeta
de taller para almacenar registros sobre las actividades del conductor.
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 publicado
en el correspondiente sitio web de la Comisión Europea, es decir, por
ejemplo, incluyendo guiones si los lleva. El número de homologació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 la 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 registro de cruces
de fronteras de la tarjeta se le asigna en la estructura el número «0».
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 la 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 NationNume­
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 almacenados).
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 tarjeta. 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 relativa a la posición del ve­
hí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 conformidad
con el requisito 147 ter del anexo I C, y su 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 la frontera
de un país, o «no hay información disponible» de conformidad con 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 identificación del
circuito integrado (CI) de dicha tarjeta (anexo 1C, requisito 249). El
icSerialNumber y el icManufacturingReferences identifican conjunta­
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.002 — 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, requisitos 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 elemento se
pone a cero al extraer la tarjeta.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 completo más
antiguo en la cadena activityDailyRecords. El valor máximo viene 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 principio de
la cadena) que corresponde al registro diario más reciente en la cadena
activityDailyRecords. El valor máximo viene dado por la longitud de la
cadena.
activityDailyRecords es el espacio disponible para almacenar los datos
sobre la actividad del conductor (estructura de datos: CardActivityDaily­
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 uso, el
almacenamiento comienza en el primer byte de la cadena. Cada nuevo
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 indepen­
dencia de si hay alguna interrupción dentro de un elemento de datos.
Antes de introducir en la cadena nuevos datos de actividad (ampliando el
actual activityDailyRecord, o introduciendo un nuevo activityDailyRe­
cord) que sustituyan a datos antiguos, es preciso actualizar el activity­
PointerOldestDayRecord para reflejar la nueva ubicación del registro
diario completo más antiguo, y además es preciso poner a 0 la longitud
activityPreviousRecordLength de este (nuevo) registro diario completo
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.002 — 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, requisitos 260 y
318).
CardEventData es una secuencia de cardEventRecords ordenada por
valor ascendente del código EventFaultType (excepto los registros rela­
cionados con intentos de violación de la seguridad, que se incluyen 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, requisitos 285 y
341).
CardEventData es una secuencia de cardEventRecords ordenada por
valor ascendente del código EventFaultType (excepto los registros rela­
cionados con intentos de violación de la seguridad, que se incluyen 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, requisitos 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 incidente.
▼M1
02016R0799 — ES — 21.08.2023 — 003.002 — 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, requisitos 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 conjunto
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, requisitos 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 identificació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.002 — 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/CEI
7816-6.
2.24. CardIdentification
Información almacenada en una tarjeta y relativa a la identificació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 primer registro de
entradas de tipo de carga de la tarjeta se le asigna en la estructura el
número «0».
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 se inserta
en una unidad instalada en el vehículo (anexo I C, requisitos 306 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, requisi­
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 carga y
descarga simultáneas), la fecha y la hora en las que se ha introducido
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, requisi­
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.002 — 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 autenticació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 de 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 comienzan
o terminan los períodos de trabajo diarios (anexo I C, requisitos 306 ter
y 356 ter).
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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 primer registro
del estado de autenticación de los lugares se le asigna en la estructura 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 tarjeta de
taller y relativa a los lugares donde comienzan y/o terminan los 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 el 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.002 — 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 instalada 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 ranuras 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 ranura
del segundo conductor,
«dddd»B Identificación del tipo de tarjeta insertada en la ranura
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.002 — 138
2.35. CardSlotsStatusRecordArray
Generación 2:
El CardSlotsStatus más metadatos tal como se utilizan en el protocolo 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 tarjeta 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.002 — 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 elemento 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 asigna 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.002 — 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 (anexo 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 unidad 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 titular 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 la 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 seguridad
comunes»: firma (128 bytes) || resto de la clave pública (58 bytes) ||
referencia de la autoridad de certificación (8 bytes).
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 certificado.
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.002 — 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 especifica 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 desconoce 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 refiere 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 certificació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.002 — 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 las 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 estructura 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 transferido,
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.002 — 144
2.47. CompanyActivityType
Código que indica una actividad realizada por una empresa haciendo uso
de su tarjeta de empresa.
2.48. CompanyCardApplicationIdentification
Información almacenada en una tarjeta de empresa y relativa a la 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 la 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 la iden­
tificación del titular de dicha tarjeta (anexo 1C, requisitos 372 y 378).
companyName es el nombre de la empresa titular.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 la identi­
ficación de la aplicación de la tarjeta (anexo 1C, requisitos 357 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 la identi­
ficación de la aplicación de la tarjeta (anexo I C, requisito 363 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 las acti­
vidades que se realizan con la tarjeta (anexo 1C, requisitos 361 y 367).
controlPointerNewestRecord es el índice del último registro actuali­
zado de una actividad de control.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 146
Asignación de valor: número correspondiente al numerador del registro
de una actividad de control. Al primer registro de la estructura 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 control.
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 la 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.002 — 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.002 — 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 utilizan 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 taller 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 los 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 expide 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.002 — 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 transferencia.
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 segunda
generación.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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, requisitos 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 elementos
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.002 — 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, requisito 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.002 — 152
2.64. EGFCertificate
Generación 2:
Certificado de la clave pública del dispositivo GNSS externo para la
autenticación mutua con una VU. La estructura de este certificado 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 introduce
un período diario de trabajo, el lugar y la condición de la entrada.
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 aplicación de
tacógrafo.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 Europa 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 externo,
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 una 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 fallo.
Asignación de valor:
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 154
uno de los diez incidentes o fallos más recientes (o de los diez últimos)
el incidente de más duración ocurrido en uno de los diez últimos días en que se
hayan producido incidentes de este tipo
uno de los cinco incidentes de más duración ocurridos en los últimos 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 se 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 sensor,
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.002 — 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 distancia,
Ausencia de información sobre la posición procedente del receptor 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 sensor,
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.002 — 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.002 — 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.002 — 158
2.71. ExtendedSealIdentifier
Generación 2:
El identificador de precinto ampliado identifica de manera única 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.002 — 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. Estos
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 denotan
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.002 — 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 (factor 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 acumulado
alcanza un múltiplo de tres horas (anexo IC, requisitos 306 y 354).
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 de 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 un
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 acumulado
alcanza un múltiplo de tres horas (anexo IC, requisitos 305 y 353).
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.002 — 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últiplo
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 del 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 tres 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 otro
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 son
idénticas a las del correspondiente GNSSAccumulatedDrivingRecord).
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.002 — 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 (anexo 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.002 — 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 es 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ública 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ública 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ública de un
Estado miembro.
▼B
2.87. KMWCKey
Generación 2:
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 164
Clave AES y su versión de clave asociada utilizada en el emparejamiento
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 última
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.002 — 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 [definició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 longitud
correspondiente a los conjuntos de cifrado que se especifican en el
apéndice 11.
▼B
2.93. ManualInputFlag
Código que indica si el titular de una tarjeta, en el momento de 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 conservará
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 desarro­
lladores de tacógrafos al presentar una solicitud al laboratorio competente
para realizar los ensayos de interoperabilidad.
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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, expedido 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 utilizan
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.002 — 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 carac­
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 internacional (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íses figurarán
en una lista mantenida en el sitio web del laboratorio designado 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 tendrá lugar,
únicamente, después de que el laboratorio designado haya obtenido las
observaciones de los fabricantes de unidades instaladas en el vehí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 tarjeta de
taller.
Generación 1:
Asignación de valor: véase el apéndice 2.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 almacenar
una tarjeta de empresa.
Asignación de valor: véase el apéndice 2.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 169
2.108. NoOfControlActivityRecords
Número de registros sobre actividades de control que puede almacenar
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 tarjeta.
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 tarjeta.
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.002 — 170
2.112a. NoOfLoadTypeEntryRecords
Generación 2, versión 2:
Número de registros de entradas de tipo de carga que puede almacenar
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.002 — 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 significa que se
ha producido un incidente de exceso de velocidad desde el último control
…255 significa que se han producido 255 o más incidentes de exceso de
velocidad desde el último control.
▼M3
2.116a. PlaceAuthRecord
Información relativa al lugar donde comienza o termina un período 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 comienza 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.002 — 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íodo 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 componente:
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.002 — 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 conductor
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 elemento 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.002 — 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 especificado.
Generación 1:
Asignación de valor:
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 175
Generación 2:
Los códigos alfabéticos que identifican a las distintas regiones figurarán
en una lista mantenida en el sitio web del laboratorio designado para
realizar los ensayos de interoperabilidad.
2.122. RegionNumeric
Referencia numérica a una región perteneciente a un país especificado.
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 designado 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.002 — 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 colocados en
los distintos componentes de un vehículo y se destina al almacenamiento
en una tarjeta. Este tipo de datos está relacionado con el anexo 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 colocados en
los distintos componentes de un vehículo y se destina al almacenamiento
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 sealRecords
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 colocado 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.002 — 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 publicado
en el correspondiente sitio web de la Comisión Europea, es decir, por
ejemplo, incluyendo guiones si los lleva. El número de homologació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 publicado
en el correspondiente sitio web de la Comisión Europea, es decir, por
ejemplo, incluyendo guiones si los lleva. El número de homologació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 unidad
(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 externo
(anexo 1C, requisito 98).
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 relativa 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.002 — 179
2.136. SensorExternalGNSSOSIdentifier
Generación 2:
Identificador del sistema operativo del dispositivo GNSS externo.
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 criptográ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 una
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 receptor 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 fabricante).
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.002 — 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 los datos de
seguridad necesarios para emparejar sensores de movimiento y unidades
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 deberá
almacenar hasta tres claves de emparejamiento del sensor de movimiento
con la VU. Estas claves tienen diferentes versiones de clave.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 dicha 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 dicha
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.002 — 182
2.147. SensorSCIdentifier
Identificador del componente de seguridad del sensor de movimiento.
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 protocolo
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 longitudes.
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 significa que
ese día han ocurrido 2 incidentes de ese tipo (y solo se ha almacenado
uno), … 255 significa que ese día han ocurrido 255 o más incidentes de
ese tipo.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 especí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 especí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, requisitos
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.002 — 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 definido.
▼M3
2.158a. TachographCardsGen1Suppression
Generación 2, versión 2:
Capacidad de una VU de segunda generación para utilizar tarjetas 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.002 — 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 1970,
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ículo com­
pleto, generalmente el número de serie del chasis o el número de
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 utilizan 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.002 — 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 Estado
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.002 — 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 para
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.002 — 188
Información almacenada en una VU y relativa a los cambios de activi­
dad y/o los cambios del régimen de conducción y/o los cambios del
estado de la tarjeta que tengan lugar en un día civil determinado (anexo
1B, requisito 084) y a los estados de las ranuras a las 00.00 horas 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 dos
palabras de activityChangeInfo que dan el estado de las dos ranuras 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 activi­
dad y/o los cambios del régimen de conducción y/o los cambios del
estado de la tarjeta que tengan lugar en un día civil determinado (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 00.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.002 — 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 publicado
en el correspondiente sitio web de la Comisión Europea, es decir, por
ejemplo, incluyendo guiones si los lleva. El número de homologació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, requisito 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 098 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.002 — 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 control
autorizada.
▼M3
Generación 2, versión 1:
▼B
Además de los de la generación 1, se utiliza el siguiente elemento de
datos:
sealDataVu da información sobre los precintos colocados en diversos
componentes del vehículo.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 final 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ículo 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.002 — 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, requisitos 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 conductor o de
taller en dicha unidad (anexo 1B, requisito 081, y anexo 1C, requisito
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 conductor o de
taller en dicha unidad (anexo 1B, requisito 081, y anexo 1C, requisito
102).
Generación 1:
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 almacenados 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 tarjeta.
manualInputFlag es una bandera que indica si el titular de la tarjeta ha
introducido manualmente alguna actividad del conductor en el momento
de insertar la tarjeta.
Generación 2:
En lugar de fullCardNumber, la estructura de datos de la generació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 generación,
según los datos almacenados en la propia tarjeta.
2.178. VuCardIWRecordArray
Generación 2:
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 conductor 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. Esta infor­
mación se destina al análisis de los problemas VU — tarjeta (anexo 1C,
requisito 132).
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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ógrafo
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 el 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.002 — 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, requisito 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 genera­
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.002 — 197
2.185a. VuConfigurationLengthRange
Generación 2, versión 2:
Número de bytes de una tarjeta de tacógrafo disponibles para almacenar
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, requisito
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, requisito 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.002 — 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 generació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, requisito
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 secuencialmente los
ciclos de inserción/extracción de la tarjeta en unidades instaladas 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 minuto en el
que haya estado en movimiento (anexo 1B, requisito 093, y anexo 1C,
requisito 116).
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 el vehí­
culo (anexo I C, requisito 133 undecies).
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 los conduc­
tores (anexo 1B, requisitos 081, 084 o 087, y anexo 1C, requisitos 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 introdujo 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 introdujo 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 el
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 anexo 1C,
requisito 129).
Generación 1:
downloadingTime es la fecha y la hora de la transferencia.
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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 generació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.002 — 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, requisito 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 incidente.
cardNumberCodriverSlotBegin identifica la tarjeta que estaba inser­
tada en la ranura del segundo conductor en el momento en que comenzó
el incidente.
cardNumberDriverSlotEnd identifica la tarjeta que estaba insertada en
la ranura del conductor en el momento en que finalizó el incidente.
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, excepto los de
exceso de velocidad.
Generación 2:
Además de los de la generación 1, se utilizan los siguientes elementos
de datos:
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 elementos 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 conductor
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 conductor en
el momento en que terminó el incidente.
Si el incidente es un conflicto temporal, eventBeginTime y eventEnd­
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.002 — 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 fallo.
cardNumberCodriverSlotBegin identifica la tarjeta que estaba inser­
tada en la ranura del segundo conductor en el momento en que comenzó
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.002 — 205
Generación 2:
Además de los de la generación 1, se utiliza el siguiente elemento 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 elementos 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 conductor
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 conductor 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.002 — 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últiplo
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 autenti­
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 cruzado la
frontera de un país (anexo I C, requisitos 133 bis y 133 ter).
▼M1
02016R0799 — ES — 21.08.2023 — 003.002 — 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. 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).
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 su 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 la 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, requisito 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.002 — 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 reloj 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 el 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 075 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.002 — 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 protocolo
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.002 — 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 utilizació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 inteligentes 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.002 — 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, requisi­
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 (anexo 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 bnoOfRecords­
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.002 — 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 último 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 velocidad.
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.002 — 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 094).
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 094, 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.002 — 214
cardNumberDriverSlotBegin identifica la tarjeta que estaba insertada
en la ranura del conductor en el momento en que comenzó el incidente.
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 094, y
anexo 1C, requisito 117).
En lugar de cardNumberDriverSlotBegin, la estructura de datos de 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 117).
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.002 — 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 un pe­
ríodo de trabajo diario (anexo 1B, requisito 087, y anexo 1C, requisitos
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íodo 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íodo de
trabajo diario (anexo 1B, requisito 087, y anexo 1C, requisitos 108 y
110).
En lugar de fullCardNumber, la estructura de datos de la generació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 generació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, requisitos 108
y 110).
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 la 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 un 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 VU a un
dispositivo GNSS externo; véase el requisito GNS_3f del apéndice 12.
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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.002 — 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íficas.
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 marco 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 calibrado
regular (anexo 1B, requisito 101, y anexo 1C, requisitos 124 y 125).
Generación 1:
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 genera­
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.002 — 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 elementos
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.002 — 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 los datos
adicionales (es decir, el tipo de carga por defecto) introducidos 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 registro de datos
adicionales del calibrado se le asigna en la estructura el número «0».
workshopCardCalibrationAddDataRecords es el conjunto de registros
que contienen el valor antiguo de fecha y hora, el valor de identificació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 tipo de
carga por defecto introducido durante un calibrado (anexo I C, requisito
356 duodecies).
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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 WorkshopCardCalibration­
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 las activi­
dades del taller realizadas con dicha tarjeta (anexo 1C, requisitos 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.002 — 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 control
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.002 — 224
Generación 2:
Además de los de la generación 1, se utilizan los siguientes elementos
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 334).
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 (anexo 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.002 — 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 (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.
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 conductor
en el momento en que comenzó el incidente.
cardNumberAndGenCodriverSlotEnd identifica la tarjeta, incluida su
generación, que estaba insertada en la ranura del segundo conductor 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.002 — 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 (anexo 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 del
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 utiliza 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.002 — 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 del 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 referencias, a
continuación se ofrece la asignación de valores. La norma ISO/CEI
8824-1 prevalece sobre esta nota informativa en caso de discrepancia.
Otras cadenas de caracteres (Address, Name, VehicleRegistrationNum­
ber) utilizan, asimismo, los caracteres del código de caracteres decimales
161 a 255 del código estándar de 8 bits siguiente, especificados 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 13
ISO/CEI 8859-15 Latín-9 15
ISO/CEI 8859-16 Latín-10, Europa Sudoriental 16
KOI8-R Latín / Cirílico 80
KOI8-U Latín / Cirílico 85
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 8825-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. Estos OID se
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 228
especifican en TR-03110-3 y se repiten aquí en aras de la exhaustividad.
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á luego
en el modo de funcionamiento CBC para garantizar la confiden­
cialidad de los datos y con el algoritmo CMAC para garantizar la
autenticidad de los datos. Por consiguiente, el identificador de
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.002 — 229
6.2. Identificadores de aplicación
Generación 2:
El identificador de aplicación (AID) para el dispositivo GNSS externo
(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.002 — 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.002 — 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 siglas:
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.002 — 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.002 — 233
1.2. Referencias
En el presente apéndice se utilizan las referencias siguientes:
ISO/CEI 7816-2 Tarjetas de identificación — Tarjetas de circuito(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 circuito(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 circuito(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 circuito(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 circuito(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 la
norma ISO/CEI 7816-3, a menos que se especifique otra
cosa.
TCS_02 La ubicación y dimensiones de los contactos de las tarjetas
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 especificaciones,
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 la
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 frecuencias 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 que
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.002 — 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 trans­
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 precisan
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 restringido o
determinadas diferencias que puedan existir. Los comandos especifi­
cados son totalmente conformes a las normas citadas, salvo en los
casos que se indican.
3.2. Protocolo de transmisión
TCS_10 El protocolo de transmisión deberá ser conforme a la norma
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.002 — 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.002 — 236
3.2.2 ATR
TCS_17 El dispositivo comprueba los bytes ATR, de acuerdo con la
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 proto­
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.002 — 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 restricciones. 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 mensajería segura.
PWD La acción solo puede ejecutarse si el PIN de la tarjeta de taller se verifica
correctamente, es decir, si se ha configurado el estado de seguridad interna de
la tarjeta «PIN_Verified». El comando debe enviarse sin mensajería segura.
EXT-AUT-G1 La acción puede ejecutarse solo si se ha ejecutado correctamente 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 segura 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 generación 1 en
modo exclusivamente de autenticación (véase la parte A del apéndice 11).
SM-R-ENC-G1 La respuesta APDU debe aplicarse con mensajería segura de generación 1 en
modo de cifrado (véase la parte A del apéndice 11), es decir, no 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 generació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 segura 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 generación 2 en
modo exclusivamente de autenticación (véase la parte B del apéndice 11).
SM-R-ENC-
MAC-G2
La respuesta APDU debe aplicarse con mensajería segura de generació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.002 — 238
TCS_25 En la aplicación DF tacógrafo G1, 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 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 siguientes
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.002 — 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.002 — 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 norma
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 corres­
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.002 — 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 00 Procesamiento normal.
61 XX Procesamiento normal. XX = número de bytes de respuesta
disponibles.
62 81 Procedimiento de aviso. Una parte de los datos devueltos puede
estar dañada.
63 00 Ha fallado la autenticación (Advertencia).
63 CX CHV (PIN) incorrecto. «X» indica el contador de intentos
restantes.
64 00 Error de ejecución. No ha variado el estado de la memoria per­
manente. Error de integridad.
65 00 Error de ejecución. Ha variado el estado de la memoria
permanente.
65 81 Error de ejecución. Ha variado el estado de la memoria perma­
nente. Fallo de memoria.
66 88 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.002 — 242
SW1 SW2 Significado
67 00 Longitud incorrecta (Lc o Le incorrecta).
68 83 Último comando de la cadena esperado.
69 00 Comando prohibido (no hay respuesta disponible en T=0).
69 82 Estado de seguridad no satisfecho.
69 83 Método de autenticación bloqueado.
69 85 Condiciones de uso no satisfechas.
69 86 Comando no autorizado (falta el EF actual).
69 87 Faltan objetos de datos de mensajería segura que se esperaban.
69 88 Objetos de datos de mensajería segura incorrectos.
6A 80 Parámetros incorrectos en el campo de datos.
6A 82 Archivo no encontrado.
6A 86 Parámetros P1-P2 incorrectos.
6A 88 Datos referenciados no encontrados.
6B 00 Parámetros incorrectos (desviación fuera del EF).
6C XX Longitud incorrecta, SW2 indica la longitud exacta. No se de­
vuelve un campo de datos.
6D 00 Código de instrucción no admitido o no válido.
6E 00 Clase no admitida.
6F 00 — 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á otros
pormenores relevantes relacionados con las operaciones criptográficas
que es preciso realizar para tacógrafos de generación 1 y genera­
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.002 — 243
TCS_31 Si se solicitan los dos bytes de longitud (Lc y Le) y ademá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 (mensajerí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 longitud
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.002 — 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 de
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 tarjeta.
TCS_35 Este comando puede ejecutarse desde cualquier punto de la
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) NN «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.002 — 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 segura
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ídos, 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 seleccio­
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 el
modo de acceso de lectura.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 seleccio­
nado, con mensajería segura, a fin de verificar la integridad de 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.002 — 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) NN «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.002 — 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) MM «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.002 — 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 medio
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.002 — 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) NN «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.002 — 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.002 — 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) NN «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.002 — 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 el
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) NN «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 no están
cifrados.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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.002 — 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 medio
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) NN «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.002 — 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) NN «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.002 — 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.002 — 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 la
seguridad que incluya el envío de un criptograma o de unos datos
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» P1
P2 1 «00h» P2
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.002 — 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 este co­
mando, pero para estas tarjetas no se personaliza ninguna informació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 especifica­
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 infor­
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 incorrecta,
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» P1
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 protocolo
T=0) sirve para transmitir datos preparados de la tarjeta al dispositivo
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.002 — 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 obtener
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» P1
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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/CEI
7816-4 y el certificado debe transmitirse en dos PSO consecutivos:
APDU de Verify Certificate.
La estructura del certificado y los parámetros de dominio se definen
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.002 — 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 siguientes
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.002 — 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» P1
P2 1 «00h» P2
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.002 — 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 proceso
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 la
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.002 — 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 cumple
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.002 — 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 fines
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 norma.
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) presente 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.002 — 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 que
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 comando
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.002 — 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 mediante
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 subsi­
guiente: el comando Verify Digital Signature, ya sea
— para la verificación de la firma de un certificado suministrado 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.002 — 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 digitales. 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 norma.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 271
Solo la tarjeta de control debe admitir este comando en el DF tacó­
grafo y el DF tacógrafo_G2.
Otros tipos de tarjetas de tacógrafo pueden o no incorporar este 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 solo
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 consiguiente,
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 admitir este
comando en el DF tacógrafo y el DF tacógrafo_G2.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 272
Otros tipos de tarjetas de tacógrafo pueden o no incorporar este 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 apar­
tado, es decir, no deberá permitir el cálculo de un valor de compro­
bación aleatoria, sino que terminará con un código de error adecuado.
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 solo
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á admitir
SHA-1.
▼M1
TCS_123 La aplicación de tacógrafo de generación 2 deberá admitir
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.002 — 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 admitir este
comando en el DF tacógrafo y el DF tacógrafo_G2.
Otros tipos de tarjetas de tacógrafo pueden o no incorporar este 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 correc­
tamente y terminan con un código de error adecuado.
El comando puede o no estar accesible en el MF. Si el comando no
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 norma.
▼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.002 — 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, suministrada como
entrada, cuya comprobación aleatoria conoce la tarjeta. La tarjeta
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 norma.
Solo la tarjeta de control debe admitir este comando en el DF tacó­
grafo y el DF tacógrafo_G2.
Otros tipos de tarjetas de tacógrafo pueden o no incorporar este 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.002 — 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 este co­
mando, pero no tendrán una clave maestra DSRC. Por tanto, estas
tarjetas no pueden ejecutar el comando correctamente, pero terminan
con un código de error adecuado.
El comando puede o no estar accesible en el MF y/o el DF tacógrafo.
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.002 — 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 del
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.002 — 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 accesibles.
No se especifican las estructuras internas que dependen del fabricante
de la tarjeta, como por ejemplo las cabeceras de archivos, ni el alma­
cenamiento y la manipulación de elementos de datos necesarios para
uso interno exclusivamente, como ,
, o .
TCS_140 Una tarjeta de tacógrafo de generación 2 deberá incorporar
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úmero
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.002 — 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 estruc­
tura de datos:
TCS_145 El archivo elemental EF DIR deberá contener los siguientes
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 pre­
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.002 — 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 con­
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 conductor
deberá tener la siguiente estructura de datos:
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 280
► (1) (2) M3
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 281
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 con­
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.002 — 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 con­
ductor deberá tener la siguiente estructura de datos:
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 284
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 285
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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 12 12
n 2 NoOfFaultsPerType 24 24
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 taller
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.002 — 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 deberá
tener la siguiente estructura de datos:
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 288
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 289
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 taller
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.002 — 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 deberá
tener la siguiente estructura de datos:
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 292
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 293
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 294
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 295
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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 24 24
n 9 NoOfSpecificConditionRecords 4 4
n 10 NoOfBorderCrossingRecords 4 4
n 11 NoOfLoadUnloadRecords 8 8
n 12 NoOfLoadTypeEntryRecords 4 4
n 13 VuConfigurationLengthRange 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 control
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.002 — 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 control
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.002 — 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.002 — 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.002 — 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 em­
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.002 — 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 em­
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.002 — 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.002 — 303
Apéndice 3
PICTOGRAMAS
PIC_001 El tacógrafo podrá utilizar, de forma opcional, los siguientes picto­
gramas y combinaciones de pictogramas (o pictogramas y combina­
ciones lo suficientemente parecidas para identificarse con estas 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.002 — 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.002 — 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 en la tarjeta
Impresión diaria de las actividades del conductor almacenadas en 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.002 — 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 trabajo
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 registro.
▼M1
02016R0799 — ES — 21.08.2023 — 003.002 — 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 almacenadas en la
tarjeta
3.2. Impresión diaria de las actividades del conductor almacenadas 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 de
datos, posiblemente identificados con un identificador de bloque.
Un bloque de datos contiene uno o más registros, posiblemente identi­
ficados con un identificador de registro.
PRT_001 Cuando un identificador de bloque precede inmediatamente a
un identificador de registro, el identificador de registro no se
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 la
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 la
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 para 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.002 — 308
— los caracteres normales indican variables (pictogramas o datos) que
hay que sustituir por sus valores antes de proceder a la impresión,
— los nombres de las variables se han acabado de llenar con guiones
bajos con el fin de mostrar la longitud disponible para la variable en
ese elemento de información,
— las fechas se especifican con el formato «dd/mm/aaaa» (día, mes,
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
C
om
bi
na
ci
on
es
d
e
pi
ct
og
ra
m
as
d
e
ta
rj
et
a
C
ód
ig
o
de
l
E
st
ad
o
m
ie
m
br
o
em
is
or
Primeros 14 caracteres del número de tarjeta
(incluido posiblemente un índice consecutivo)
Ín
di
ce
d
e
su
st
it
uc
ió
n
Ín
di
ce
d
e
re
no
va
ci
ón

▼M3
— en un bloque de datos, el texto después de «pi=» se refiere al
pictograma o la combinación de pictogramas correspondientes defi­
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 determinó 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.002 — 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.002 — 310
► (1) (2) (3) M3
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 311
► (1) (2) M3
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 312
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 313
► (1) (2) (3) (4) M3
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 314
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 315
► (1) M3
3. ESPECIFICACIONES DE LOS DOCUMENTOS IMPRESOS
En este capítulo se han empleado las siguientes convenciones para 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 tantas
veces como sea necesario.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 almace­
nadas en la tarjeta deberá efectuarse con arreglo al formato
siguiente:
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 almace­
nadas en la VU deberá efectuarse con arreglo al formato
siguiente:
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 tarjeta
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 control en
la VU + GEN)
3 Identificación del conductor (según la tarjeta cuyos datos se impri­
men)
4 Identificación del vehículo (vehículo del que se obtiene el docu­
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 VU
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 tarjetas inserta­
das en la VU + GEN)
4 Identificación del vehículo (vehículo del que se obtiene el docu­
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.002 — 319
3.5. Impresión de datos técnicos
▼M3
PRT_012 La impresión de datos técnicos deberá efectuarse con arreglo
al formato siguiente:
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 tarjetas inserta­
das en la VU + GEN)
4 Identificación del vehículo (vehículo del que se obtiene el docu­
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 los 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.002 — 321
Apéndice 5
VISUALIZACIÓN
En este apéndice se utilizan las siguientes convenciones para la 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 datos) 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á utilizar 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.002 — 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 patillas 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.002 — 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 siguiente:
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.002 — 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 especificaciones
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 par
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 byte, el
byte más significativo se transmitirá el primero, y el byte menos signifi­
cativo el último.
INT_006 La velocidad de transmisión deberá poder ajustarse entre 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 comen­
zar la comunicación se fija en 9 600 bps.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 siguientes 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 mA
U high (out) 4 V I = 1 mA
INT_009 La señal de entrada/salida deberá cumplir los siguientes diagra­
mas de relaciones de tiempo:
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 comunicación) (SId
81)
2.2.2.2 Positive Response Start Communication (respuesta positiva 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 control 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 datos) (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 transferencia) (SId 37)
2.2.2.12 Positive Response Request Transfer Exit (respuesta positiva a la peti­
ción de salida de la transferencia) (SId 77)
2.2.2.13 Stop Communication Request (petición de interrupción de la comuni­
cación) (SId 82)
2.2.2.14 Positive Response Stop Communication (respuesta positiva 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.002 — 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 sobre 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 se deben
utilizar para llevar a cabo los diferentes tipos de transferencia de datos
a un medio de almacenamiento externo (ESM), así como los protocolos
que es preciso aplicar para garantizar la corrección de dichas trans­
ferencias y la total compatibilidad del formato de los datos transferidos,
a fin de que un controlador cualquiera pueda inspeccionar dichos 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.002 — 328
— desde una tarjeta de tacógrafo y a través de una unidad instalada en
el vehículo, mediante un IDE conectado a la VU.
Para poder verificar la autenticidad y la integridad de los datos trans­
feridos que se encuentran almacenados en un ESM, dichos datos se
transfieren con una firma añadida según lo dispuesto en el apéndice 11
(Mecanismos de seguridad comunes). También se transfieren la iden­
tificación del equipo de origen (VU o tarjeta) y sus certificados de
seguridad (Estado miembro y equipamiento). La persona encargada
de verificar los datos debe estar en posesión de una clave pública
europea de confianza.
Los datos transferidos desde una VU se firman utilizando los mecanis­
mos de seguridad comunes del apéndice 11, parte B (Sistema de tacó­
grafo de segunda generación), excepto cuando la supervisión del con­
ductor la realiza una autoridad de control de un país no perteneciente a
la UE utilizando una tarjeta de control de primera generación, en cuyo
caso los datos se firman mediante los mecanismos de seguridad comu­
nes del apéndice 11, parte A (Sistema de tacógrafo de primera gene­
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 estruc­
tura de datos de segunda generación, firmada utilizando los meca­
nismos de seguridad comunes del apéndice 11, parte B,
— Transferencia de datos desde la VU de generación 1, con la estruc­
tura de datos de primera generación, firmada utilizando los meca­
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 se
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.002 — 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 operario
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 enviar 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 que el
IDE actúa como maestro y la VU como esclavo.
La estructura, los tipos y el flujo de los mensajes se basan principal­
mente en el protocolo Keyword 2000 (KWP) (ISO 14230-2: Vehículos
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 actual 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 IDE 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
… … … CS
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 derechos 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 la VU siempre que no haya
otro tipo de tarjeta en la otra ranura.
02016R0799 — ES — 21.08.2023 — 003.002 — 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 mensaje
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 CS
4 bytes Más de 255 bytes
Se transmitirá como:
Cabecera SId TREP 00 01 Submensaje 1 CS
4 bytes 255 bytes
Cabecera SId TREP 00 02 Submensaje 2 CS
4 bytes 255 bytes
…
Cabecera SId TREP xx yy Submensaje n CS
4 bytes Menos de 255 bytes
o bien como:
Cabecera SId TREP 00 01 Submensaje 1 CS
4 bytes 255 bytes
Cabecera SId TREP 00 02 Submensaje 2 CS
4 bytes 255 bytes
…
Cabecera SId TREP xx yy Submensaje n CS
4 bytes 255 bytes
Cabecera SId TREP xx yy + 1 CS
4 bytes 4 bytes
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 331
2.2.2 Tipos de mensajes
El protocolo de comunicación para la transferencia de datos entre la
VU y el IDE exige el intercambio de ocho tipos de mensajes diferentes.
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 ->
Petición de inicio de comunicación 81 EE F0 81 E0
Respuesta positiva a la petición de
inicio de comunicación
80 F0 EE 03 C1 EA, 8F 9B
Petición de inicio de la sesión de diag­
nóstico
80 EE F0 02 10 81 F1
Respuesta positiva a la petición de
inicio de diagnóstico
80 F0 EE 02 50 81 31
Servicio de control del enlace
Verificar la velocidad en baudios
(fase 1)
9 600 Bd 80 EE F0 04 87 01 01,01 EC
19 200 Bd 80 EE F0 04 87 01 01,02 ED
38 400 Bd 80 EE F0 04 87 01 01,03 EE
57 600 Bd 80 EE F0 04 87 01 01,04 EF
115 200 Bd 80 EE F0 04 87 01 01,05 F0
Respuesta positiva a la petición de
verificar la velocidad en baudios
80 F0 EE 02 C7 01 28
Velocidad de transición en baudios
(fase 2)
80 EE F0 03 87 02 03 ED
Envío de petición 80 EE F0 0A 35 00,00,00,00­
,00,FF,FF,F­
F,FF
99
Respuesta positiva al envío de petición 80 F0 EE 03 75 00,FF D5
Petición de transferencia de datos
Versión de la interfaz de trans­
ferencia
80 EE F0 02 36 00 96
Visión General 80 EE F0 02 36 01, 21 o 31 CS
Actividades 80 EE F0 06 36 02, 22 o 32 Fecha CS
Incidentes y fallos 80 EE F0 02 36 03, 23 o 33 Fecha CS
Datos pormenorizados sobre la ve­
locidad
80 EE F0 02 36 04 o 24 Fecha CS
Datos técnicos 80 EE F0 02 36 05, 25 o 35 Fecha CS
Transferencia de los datos de la
tarjeta
80 EE F0 02 o 03 36 06 Ranura CS
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 332
Estructura del mensaje: Máx. 4 bytes Máx. 255 bytes 1 byte
Cabecera Datos
Suma de
control
IDE ->
Respuesta positiva a la petición de
transferencia de datos
80 F0 EE Len 76 TREP Datos CS
Petición de salida de la transferencia 80 EE F0 01 37 96
Respuesta positiva a la petición de
salida de la transferencia
80 F0 EE 01 77 D6
Petición de interrupción de la comuni­
cación
80 EE F0 01 82 E1
Respuesta positiva a la petición de
interrupción de la comunicación
80 F0 EE 01 C2 21
Confirmación de submensaje 80 EE F0 Len 83 Datos CS
Respuestas negativas
Denegación general 80 F0 EE 03 7F SID pet. 10 CS
Servicio no admitido 80 F0 EE 03 7F SID pet. 11 CS
Subfunción no admitida 80 F0 EE 03 7F SID pet. 12 CS
Longitud del mensaje incorrecta 80 F0 EE 03 7F SID pet. 13 CS
Condiciones incorrectas o error en la
secuencia de la petición
80 F0 EE 03 7F SID pet. 22 CS
Petición no admisible 80 F0 EE 03 7F SID pet. 31 CS
Envío no aceptado 80 F0 EE 03 7F SID pet. 50 CS
Falta respuesta 80 F0 EE 03 7F SID pet. 78 CS
Datos no disponibles 80 F0 EE 03 7F SID pet. FA CS
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 dato.
— El término envío (entendido desde el IDE) se utiliza para compa­
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 aparecen 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» (tarjeta 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 selec­
cionará la ranura 2 si la selecciona específicamente el usuario.
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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 trans­
ferencia de datos de VU de segunda generación, versión 1.
— Los TRTP 01 a 05 se utilizan para las peticiones de transferencia
de datos de VU de primera generación. Opcionalmente pueden ser
aceptadas por VU de segunda generación, pero solo en el marco del
control de conductores realizado por una autoridad de control de
fuera de la UE, utilizando una tarjeta de control de primera gene­
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 sesió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 petició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 iniciar
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.002 — 334
2.2.2.6 L i n k C o n t r o l P o s i t i v e R e s p o n s e ( 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 especi­
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 de
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 00
Visión General 01 21 31
Actividades de una fecha es­
pecífica
02 22 32
Incidentes y fallos 03 23 33
Datos pormenorizados sobre
la velocidad
04 24 24
Datos técnicos 05 25 35
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 de
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 trans­
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á datos
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 trans­
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 petición
de salida de la transferencia para confirmar la petición de
salida de la transferencia.
▼M1
02016R0799 — ES — 21.08.2023 — 003.002 — 336
2.2.2.13 S t o p C o m m u n i c a t i o n R e q u e s t ( 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 petició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
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.002 — 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 durante un
procedimiento normal de transferencia de datos:
IDE VU
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.002 — 338
IDE VU
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
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.002 — 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 20
P2 20 1 000 (*)
P3 10 5 000
P4 5 20
P5 10 20 minutos
(*) Si la VU envía una respuesta negativa con un código que signifique «petición recibida correctamente,
pendiente de respuesta», este valor se amplía hasta el mismo valor límite máximo de P3.
2.2.5 Gestión de errores
Si se produce un error durante el intercambio de mensajes, el esquema
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 errores
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 del
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 el
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.002 — 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.002 — 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 datos
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 generación,
cada elemento de datos de primer nivel está representado por un con­
junto de registros, incluso si solo contiene un registro. Los conjuntos de
registros empiezan con una cabecera, que contiene el tipo de registro, el
tamaño del registro y el número de registros. En las tablas recogidas a
continuación se denomina a los conjuntos de registros como «… Re­
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.002 — 342
Estructura de datos de segunda generación, versión 2 (TREP 00 Hex)
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 Hex)
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.002 — 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 Hex)
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.002 — 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 noOfVuCardIW­
Records = 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 Hex)
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.002 — 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 Hex)
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.002 — 346
2.2.6.4 P o s i t i v e R e s p o n s e T r a n s f e r D a t a E v e n t s a n d F a u l t s
( 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 Hex)
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.002 — 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 Hex)
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.002 — 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 Hex)
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.002 — 349
Estructura de datos de segunda generación, versión 2 (TREP 35 Hex)
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 transferencia
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 no
forma parte del entorno seguro, por tanto no se lleva a cabo una
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.002 — 350
3.3. Transferencia de los datos de la tarjeta
▼M3
DDP_035 La transferencia de los datos de una tarjeta de tacógrafo
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.002 — 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 siguiente:
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.002 — 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.002 — 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 el
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.002 — 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 obje­
tos TLV.
DDP_042 La etiqueta de un EF consiste en el FID más la terminació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 nin­
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.002 — 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 una
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 mensaje
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 archivo
o el archivo
de la tarjeta del conductor.
▼M1
02016R0799 — ES — 21.08.2023 — 003.002 — 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.002 — 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 datos entre
una unidad instalada en el vehículo y un verificador a través de 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 describe
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 condiciones. La
sesión por defecto es la «StandardDiagnosticSession», en la que todos
los datos se pueden leer desde una unidad instalada en el vehículo pero
no es posible escribir ningún dato en ella.
La selección de la sesión de diagnóstico se explica en el apartado 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.002 — 358
2. TÉRMINOS, DEFINICIONES Y REFERENCIAS
Todos los protocolos, mensajes y códigos de error se rigen principal­
mente por el proyecto de la norma ISO 14229-1 (Vehículos de carre­
tera — Sistemas de diagnóstico — Parte 1: Servicios de diagnóstico,
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 servicio y los
parámetros normalizados.
El término «verificador» se refiere al equipo empleado para introducir
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 refiere 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 que estarán
disponibles en el tacógrafo y que se definen en el presente documento.
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.002 — 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 81 ■ ■ ■
StopCommunication 4.2 82 ■
Testerpresent 4.3 3E ■ ■ ■
StartDiagnosticSession 5.1 10 ■ ■ ■
SecurityAccess 5.2 27 ■ ■ ■
ReadDataByIdentifier 6.1 22 ■ ■ ■
WriteDataByIdentifier 6.2 2E ■
InputOutputControlByIdentifier 7.1 2F ■
▼M3
RoutineControl 8 31
▼B
■ 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 esa 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 comunica­
ción, y no aparecen en el nivel de aplicación. Los servicios disponibles
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 StartCommunica­
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.002 — 360
CPR_007 A continuación, la VU deberá hacer todo lo necesario para
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 por
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 StartCom­
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 baudios.
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.002 — 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 20
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 20
CPR_018 En las siguientes tablas se describe con detalle el formato 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 EE TGT
N o 3 Byte de dirección de origen tt SRC
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 CS
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 tt TGT
N o 3 Byte de dirección de origen EE SRC
N o 4 Byte de longitud adicional 03 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 EA KB1
N o 7 Byte clave 2 8F KB2
N o 8 Suma de control 00-FF CS
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 comunica­
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.002 — 363
4.2.2 Formato del mensaje
CPR_024 En las siguientes tablas se describen con detalle los formatos
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 EE TGT
N o 3 Byte de dirección de origen tt SRC
N o 4 Byte de longitud adicional 01 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 CS
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 tt TGT
N o 3 Byte de dirección de origen EE SRC
N o 4 Byte de longitud adicional 01 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 CS
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 tt TGT
N o 3 Byte de dirección de origen EE SRC
N o 4 Byte de longitud adicional 03 LEN
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 10 RC_GR
N o 8 Suma de control 00-FF CS
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 indicar 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 comuni­
cación. Este servicio, que se envía periódicamente, mantiene activa la
comunicación o la sesión de diagnóstico al reiniciar el temporizador 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 formatos
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 EE TGT
N o 3 Byte de dirección de origen tt SRC
N o 4 Byte de longitud adicional 02 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í 01 RESPREQ_Y
no] 02 RESPREQ_NO
N o 7 Suma de control 00-FF CS
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.002 — 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 tt TGT
N o 3 Byte de dirección de origen EE SRC
N o 4 Byte de longitud adicional 01 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 CS
CPR_081 El servicio admitirá los siguientes códigos de respuesta
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 tt TGT
N o 3 Byte de dirección de origen EE SRC
N o 4 Byte de longitud adicional 03 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 TP
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 CS
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 366
5. SERVICIOS DE ADMINISTRACIÓN
Los servicios disponibles se describen con detalle en la siguiente 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 diferen­
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 estable­
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 formatos
de mensaje para las primitivas StartDiagnosticSession.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 EE TGT
N o 3 Byte de dirección de origen tt SRC
N o 4 Byte de longitud adicional 02 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 CS
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 tt TGT
N o 3 Byte de dirección de origen EE SRC
N o 4 Byte de longitud adicional 02 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 CS
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 tt TGT
N o 3 Byte de dirección de origen EE SRC
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 368
N o de byte Nombre del parámetro
Valor
hex
Mnemónico
N o 4 Byte de longitud adicional 03 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 CS
( α ) : 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 StartDiagnosticSession.
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.002 — 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 calibrado
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 modo
CALIBRADO.
El PIN también se puede introducir por otros métodos alternativos.
5.2.1 Descripción del mensaje
El servicio SecurityAccess se compone de un mensaje SecurityAccess
«requestSeed», seguido en su caso de un mensaje SecurityAccess
«sendKey». El servicio SecurityAccess debe utilizarse después del ser­
vicio StartDiagnosticSession.
CPR_033 El verificador deberá utilizar el mensaje SecurityAccess «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 en 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 para
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.002 — 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á contes­
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 formatos
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 EE TGT
N o 3 Byte de dirección de origen tt SRC
N o 4 Byte de longitud adicional 02 LEN
N o 5 SecurityAccess Request Ser­
vice Id (SId de petición de
servicio SecurityAccess)
27 SA
N o 6 accessType — requestSeed 7D AT_RSD
N o 7 Suma de control 00-FF CS
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 tt TGT
N o 3 Byte de dirección de origen EE SRC
N o 4 Byte de longitud adicional 04 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 7D 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 CS
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 tt TGT
N o 3 Byte de dirección de origen EE SRC
N o 4 Byte de longitud adicional 03 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 SA
N o 7 response­
Code =
[conditionsNotCorrec­
tOrRequestSequen­
ceError
22 RC_CNC
incorrectMessage­
Length]
13 RC_IML
N o 8 Suma de control 00-FF CS
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 372
5.2.3 Formato del mensaje — SecurityAccess — sendKey
CPR_041 En las siguientes tablas se describen con detalle los formatos
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 EE TGT
N o 3 Byte de dirección de origen tt 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 7E AT_SK
N os 7 a
m+6
Clave n o 1 (alto) xx 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 CS
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 tt TGT
N o 3 Byte de dirección de origen EE SRC
N o 4 Byte de longitud adicional 02 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 7E AT_SK
N o 7 Suma de control 00-FF CS
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 tt TGT
N o 3 Byte de dirección de origen EE SRC
N o 4 Byte de longitud adicional 03 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 SA
N o 7 Response­
Code =
[generalReject 10 RC_GR
subFunctionNotSup­
ported
12 RC_SFNS
incorrectMessage­
Length
13 RC_IML
conditionsNotCorrec­
tOrRequestSequen­
ceError
22 RC_CNC
invalidKey 35 RC_IK
exceededNumberO­
fAttempts
36 RC_ENA
requestCorrectlyRe­
ceived-ResponsePen­
ding]
78 RC_RCR_RP
N o 8 Suma de control 00-FF CS
6. SERVICIOS DE TRANSMISIÓN DE DATOS
Los servicios disponibles se describen con detalle en la siguiente 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.002 — 374
6.1. Servicio ReadDataByIdentifier
6.1.1 Descripción del mensaje
CPR_050 El cliente utiliza el servicio ReadDataByIdentifier para 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 formatos
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 EE TGT
N o 3 Byte de dirección de origen tt SRC
N o 4 Byte de longitud adicional 03 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 CS
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 tt TGT
N o 3 Byte de dirección de origen EE 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.002 — 375
N o de byte Nombre del parámetro
Valor
hex
Mnemónico
N os 8 a
m+7
dataRecord[] = [data#1 xx DREC_DAT­
A1
: : :
data#m] xx DREC_DA­
TAm
N o m+8 Suma de control 00-FF CS
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 tt TGT
N o 3 Byte de dirección de origen EE SRC
N o 4 Byte de longitud adicional 03 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 CS
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 recordDataIdentifier
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.002 — 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.002 — 377
CPR_054 El mensaje ReadDataByIdentifier Positive Response utiliza
el parámetro dataRecord (DREC_) para facilitar al cliente
(verificador) el valor del registro de datos identificado por el
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 para 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 formatos
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 EE TGT
N o 3 Byte de dirección de origen tt 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 xx DREC_DAT­
A1
: : :
data#m] xx DREC_DA­
TAm
N o m+8 Suma de control 00-FF CS
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 tt TGT
N o 3 Byte de dirección de origen EE SRC
N o 4 Byte de longitud adicional 03 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 CS
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 tt TGT
N o 3 Byte de dirección de origen EE SRC
N o 4 Byte de longitud adicional 03 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 CS
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 valores de
registros de datos identificados por el recordDataIdentifier. Los 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 siguiente 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 utilizando
un verificador adecuado.
CPR_058 Esta línea de señal I/O de calibrado se puede configurar 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 instalada 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.002 — 380
CPR_060 Si se reciben impulsos de velocidad por la línea de entrada
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 formatos
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 EE TGT
N o 3 Byte de dirección de origen tt SRC
N o 4 Byte de longitud adicional xx 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 CS
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.002 — 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 tt TGT
N o 3 Byte de dirección de origen EE SRC
N o 4 Byte de longitud adicional xx 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 CS
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 tt TGT
N o 3 Byte de dirección de origen EE SRC
N o 4 Byte de longitud adicional 03 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.002 — 382
N o de byte Nombre del parámetro Valor hex Mnemónico
N o 7 responseCode=[
incorrectMessageLength 13 RC_IML
conditionsNotCorrect 22 RC_CNC
requestOutOfRange 31 RC_ROOR
deviceControlLimitsExceeded] 7A RC_DCLE
N o 8 Suma de control 00-FF CS
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 00 Línea I/O desactivada (estado por defecto)
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 383
Modo Valor hex Descripción
Activado 01 Línea I/O de calibrado activada como speed­
SignalInput
Activado 02 Línea I/O de calibrado activada como real­
TimeSpeedSignalOutputSensor
Activado 03 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 RoutineControl
(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 80 FMT
#2 Byte de dirección de destino EE TGT
#3 Byte de dirección de origen tt SRC
#4 Byte de longitud adicional xx LEN
#5 RoutineControl Request Sid (SID de la petición RoutineControl) 31 RC
#6 routineControlType = [startRoutine] 01 RCTP_STR
#7 y #8 routineIdentifier = [TimeAdjustment] 0100 RI_TA
#9 Suma de control 00-FF CS
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 80 FMT
#2 Byte de dirección de destino tt TGT
#3 Byte de dirección de origen EE SRC
#4 Byte de longitud adicional xx LEN
#5 RoutineControl Positive Response Sid (SID de respuesta positiva a
RoutineControl)
71 RCPR
#6 routineControlType = [startRoutine] 01 RCTP_STR
#7 y #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA
#9 Suma de control 00-FF CS
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 80 FMT
#2 Byte de dirección de destino EE TGT
#3 Byte de dirección de origen tt SRC
#4 Byte de longitud adicional xx LEN
#5 RoutineControl Request Sid (SID de la petición RoutineControl) 31 RC
#6 routineControlType = [requestRoutineResults] 03 RCTP_RRR
#7 y #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA
#9 Suma de control 00-FF CS
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 80 FMT
#2 Byte de dirección de destino tt TGT
#3 Byte de dirección de origen EE SRC
#4 Byte de longitud adicional xx LEN
#5 RoutineControl Positive Response Sid (SID de respuesta positiva a
RoutineControl)
71 RCPR
#6 routineControlType = [requestRoutineResults] 03 RCTP_RRR
#7 y #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA
#9 routineInfo (véase la tabla 37f) XX RINF_TA
#10 routineStatusRecord[] = routineStatus#1 (véase la tabla 37g) XX RS_TA
#11 Suma de control 00-FF CS
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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 80 FMT
#2 Byte de dirección de destino tt TGT
#3 Byte de dirección de origen EE SRC
#4 Byte de longitud adicional 03 LEN
#5 negativeResponse Service Id (SID de respuesta negativa) 7F NR
#6 inputOutputControlByIdentifier Request SId 31 RC
#7 responseCode=[
sub-functionNotSupported
incorrectMessageLengthOrInvalidFormat
conditionsNotCorrect
requestOutOfRange
]
12
13
22
31
SFNS
IMLOIF
CNC
ROOR
#8 Suma de control 00-FF CS
Tabla 37f
RoutineControl, rutina(TimeAdjustment), routineInfo
routineInfo Valor hex Descripción
NormalExitWithResultAvailable 61 La rutina se ha ejecutado completamente; hay disponi­
bles otros resultados de la rutina.
RoutineExecutionOngoing 78 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 través de
los servicios de transmisión de datos descritos en el punto 6.
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 386
CPR_067 La VU admitirá todos los parámetros identificados.
CPR_068 Los datos transmitidos por la VU al verificador en respuesta
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 para
determinar la validez de un parámetro transmitido.
CPR_070 Los valores del intervalo «indicador de error» sirven para
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 que 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 datos
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 FB 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 FE FE00 a FEFF FE000000 a FEFFFFFF 0
No disponible o no solicitado FF FF00 a FFFF FF000000 a FFFFFFFF FF
CPR_073 Para los parámetros codificados en ASCII, el carácter AS­
CII «*» está reservado como delimitador.
9.2. Formatos dataRecords
De la tabla 39 a la tabla 42 se detallan los formatos que se usarán a
través de los servicios ReadDataByIdentifier y WriteDataByIdentifier.
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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 15 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 14 Véanse los detalles en la tabla 42
VIN 17 ASCII ASCII
SealDataVu 55 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 14 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.002 — 388
CPR_075 En la tabla 40 se detallan los formatos de los distintos 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 distintos 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 segundo;
etc.
2) Este parámetro no influye el parámetro de horas ni lo modifica.
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.002 — 389
CPR_078 En la tabla 42 se detallan los formatos de los distintos 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 distintos 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 distintos 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 distintos bytes
de los parámetros VuSerialNumber, SensorSerialNumber,
SensorGNSSSerialNumber y RemoteCommunicationModu­
leSerialNumber:
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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 distintos 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 distintos 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.002 — 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 seguridad
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 medioambien­
tales; y
— una certificación de interoperabilidad, realizada por un organismo
competente, para garantizar que el aparato de control (o la tarjeta de
tacógrafo) puede interoperar sin restricciones con los modelos necesa­
rios de tarjeta de tacógrafo (o aparato de control) (véase el apartado 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 funcionales,
así como las pruebas mínimas que debe realizar el organismo competente
durante los ensayos de interoperabilidad. No se determina el tipo 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 proceso de
certificación se llevan a cabo algunas de las pruebas exigidas para la
homologación, no habrá que repetirlas posteriormente. En ese caso, tan
solo se comprobarán los resultados de dichas pruebas de seguridad. A
título informativo, en el presente apéndice hemos marcado con un 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 (por ejemplo,
PIC_001 se refiere al requisito PIC_001 del apéndice 3 (pictogramas)).
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 392
El presente apéndice trata por separado la homologación del sensor de
movimiento, de la unidad instalada en el vehículo y del dispositivo GNSS
externo como componentes del aparato de control. Cada uno de los com­
ponentes recibirá un certificado de homologación propio, en el que se
indicarán el resto de componentes compatibles. La prueba de funcionali­
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 homologación de
un sensor de movimiento (o de un dispositivo GNSS externo) en combi­
nación con el tipo de aprobación de la unidad instalada en el vehículo
pertinente, y al contrario.
▼M3
La autoridad de los Estados miembros encargada de las pruebas funcio­
nales de una unidad instalada en el vehículo o de un dispositivo GNSS
externo debe asegurarse de que el receptor GNSS integrado haya superado
con éxito las pruebas OSNMA especificadas en el presente apéndice. Esas
pruebas se consideran parte de las pruebas funcionales de la unidad 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 medioambiental;
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: Pruebas —
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: Pruebas —
Prueba Db: Calor húmedo, cíclico (ciclo de 12 + 12 horas).
IEC 60068-2-64: Verificación medioambiental — Parte 2-64: Pruebas —
Prueba Fh: Vibración, aleatorio de banda ancha y orientación.
IEC 60068-2-78 Verificación medioambiental — Parte 2-78: Pruebas —
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ódigo IP) —
Protección del equipo eléctrico frente a objetos extraños, al agua y al acceso.
ISO 10605:2008 + Corrigendum técnico 2010 + AMD1: 2014 Vehículos
de carretera — Métodos de prueba para perturbaciones eléctricas por
descarga electrostática.
ISO 7637-1:2002 + AMD1: 2008 Vehículos de carretera — Perturbacio­
nes eléctricas por conducción y acoplamiento — Parte 1: Definiciones y
consideraciones generales.
ISO 7637-2 Vehículos de carretera — Perturbaciones eléctricas por con­
ducción y acoplamiento — Parte 2: Conducción eléctrica transitoria por
líneas de alimentación exclusivamente.
ISO 7637-3 Vehículos de carretera — Perturbaciones eléctricas por con­
ducción y acoplamiento — Parte 3: Transmisión eléctrica transitoria me­
diante acoplamiento capacitivo e inductivo por líneas que no sean de
alimentación.
ISO/IEC 7816-1 Tarjetas de identificación — Tarjetas de circuito(s) inte­
grado(s) con contactos — Parte 1: Características físicas.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 393
ISO/IEC 7816-2 Tecnología de la información — Tarjetas de identifica­
ción — Tarjetas de circuito(s) integrado(s) con contactos — Parte 2:
Dimensiones y ubicación de los contactos.
ISO/IEC 7816-3 Tecnología de la información — Tarjetas de identifica­
ción — Tarjetas de circuito(s) integrado(s) con contactos –Parte 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 identifi­
cación — Métodos de prueba — Parte 3: Tarjetas de circuitos integrados
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 — Parte 4:
Interfaz CAN
ISO 16844-6 Vehículos de carretera — Sistemas de tacógrafo — Parte 6:
Diagnóstico
ISO 16844-7 Vehículos de carretera — Sistemas de tacógrafo — Parte 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.002 — 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 de 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.002 — 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 incidentes o
fallos descritos por el fabricante de la VU cuando un sensor de movi­
miento emparejado reacciona a los campos magnéticos que perturban 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.002 — 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.002 — 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.002 — 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.002 — 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 02
3.5 Comprobar si el sensor de movimiento es invulnerable a los campos magnéticos
constantes. De forma alternativa, comprobar si el sensor de movimiento 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.002 — 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 ,
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 (
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.002 — 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 el 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ánicas para la
combinación del cuerpo de la tarjeta con el módulo del chip. Deben
realizarse estas pruebas cuando se modifique uno de estos componentes
(cuerpo de la tarjeta o módulo del chip).
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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 instalada en el vehí­
culo
123, 205
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 receptor 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.002 — 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.002 — 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 91
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.002 — 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.002 — 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.002 — 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.002 — 418
Las densidades ópticas de los documentos de impresión resultantes deben
medirse en función de la norma DIN EN ISO 534.
Los documentos de impresión no deberán sufrir cambios dimensionales 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 intravehiculares 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 instalada en
el vehículo. Dicho escenario deberá adaptarse al tipo de tarjeta que
se esté verificando y deberá incluir pruebas de escritura en tantos
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 realizado
correctamente.
Verificar mediante una transferencia de la tarjeta que todos los
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 intravehiculares 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 realizado
correctamente.
Verificar mediante una transferencia de la tarjeta que todos los
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 intravehiculares 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 realizado
correctamente.
Verificar mediante una transferencia de la tarjeta que todos los
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.002 — 419
9. PRUEBAS OSNMA
9.1. Introducción
En este capítulo se describen las pruebas para demostrar la correcta im­
plantación de la OSNMA en el receptor GNSS. Puesto que la autentica­
ción de la señal del satélite la realiza exclusivamente el receptor GNSS
con independencia de cualquier otro componente del tacógrafo, las prue­
bas expuestas en el presente capítulo pueden realizarse con el receptor
GNSS como elemento autónomo. En este caso, el fabricante del tacógrafo
presentará a las autoridades de homologación un informe en el que se
detallen el desarrollo y los resultados de las pruebas realizadas 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 con­
diciones de ensayo indicadas.
— Esos criterios podrían revisarse en el momento de la declaració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.002 — 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 un simu­
lador GNSS multiconstelación que admita la transmisión de mensajes
OSNMA. Alternativamente puede utilizarse un reproductor de señales de
radiofrecuencia capaz de reproducir las muestras de señal GNSS extraidas
de los archivos. La profundidad de bits y la velocidad de muestreo típicas
son, respectivamente, de 4 bits I/Q y de 10 MHz.
Se da por supuesto que el receptor GNSS tiene interfaces para ordenar la
limpieza de su memoria (para borrar por separado la clave pública, 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 sincronización OSNMA
y para cargar la información criptográfica. Estos comandos pueden limi­
tarse solamente a las pruebas y, por tanto, no estar disponibles 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 siguientes 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 siguientes
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.002 — 421
Salvo cuando se señale, el establecimiento de la hora del receptor interno
deberá conocerse con suficiente exactitud y estar debidamente alineado
con la hora simulada. Se garantiza así el cumplimiento del requisito OS­
NMA de sincronización inicial de la hora en cada condición de prueba, 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 las Direc­
trices OSNMA para los receptores.
Téngase en cuenta que los criterios indicados de superación o no 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.002 — 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.002 — 423
Apéndice 10
REQUISITOS DE SEGURIDAD
En el presente apéndice se especifican los requisitos en materia de seguridad
informática para los componentes del sistema de tacógrafo inteligente (tacógrafo
de segunda generación).
SEC_001 Los componentes del sistema de tacógrafo inteligente que se recogen a
continuación deberán tener una certificación de seguridad conforme
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 debe cumplir
cada componente con certificación de seguridad se determinarán en
un Perfil de Protección de los componentes de acuerdo con el sistema
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 informá­
tica nacionales, en el marco del Grupo de Trabajo de interpretación
conjunta, que es el grupo de trabajo que apoya el reconocimiento
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 informa­
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 dispositivo 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 borrar o
modificar especificaciones en materia de amenazas, objetivos, proce­
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 estricta la con­
formidad del objetivo de seguridad específico con el correspondiente
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.002 — 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.002 — 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 normalizados
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ública
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 corto
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 una tarjeta
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 mediante
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 dife­
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.002 — 427
PREÁMBULO
El presente apéndice especifica los mecanismos de seguridad que garantizan
— la autenticación mutua entre los diferentes componentes del sistema de tacó­
grafo digital;
— la confidencialidad, integridad, autenticidad y/o no rechazo de los datos transferidos
entre equipos diferentes o descargados a medios de almacenamiento externos.
El presente apéndice consta de dos partes. La Parte A define los mecanismos de
seguridad del sistema de tacógrafo de primera generación (tacógrafo digital). La
Parte A define los mecanismos de seguridad del sistema de tacógrafo de segunda
generación (tacógrafo inteligente).
Los mecanismos especificados en la Parte A del presente apéndice serán de
aplicación si al menos uno de los componentes del sistema de tacógrafo impli­
cados en una autenticación mutua y/o proceso de transferencia de datos es de
primera generación.
Los mecanismos especificados en la Parte B del presente apéndice serán de
aplicación si los dos componentes del sistema de tacógrafo implicados en la
autenticación mutua y/o el proceso de transferencia de datos son de segunda
generación.
El apéndice 15 contiene más información sobre el uso de componentes de pri­
mera generación en combinación con componentes de segunda generació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 identi­
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 identi­
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 identi­
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.002 — 428
ISO/IEC 9798-3 Tecnología de la información — Técnicas de seguri­
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.002 — 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 relaciones
siguientes:
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 deberá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árquicos
funcionales:
— Nivel europeo
— Nivel de Estado miembro
— Nivel de equipo
CSM_007 En el nivel europeo deberá generarse un único par de claves
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 un 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 privadas
durante su generación, transporte (en su caso) y almacena­
miento.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 pruebas 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 continuación se
mantendrá adecuadamente durante la generación, el transporte (si lo hay)
y el almacenamiento.
A fin de admitir componentes de tacógrafo conformes con la norma ISO
16844, la autoridad de certificación europea y las autoridades de certifi­
cación de los Estados miembros garantizarán, además, lo siguiente:
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.002 — 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 cripto­
gráficas subsiguientes que utilicen mensajería segura. Su va­
lidez expirará al término de cada sesión (al retirar o restaurar
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 datos
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.002 — 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 como 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 contenido
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»
E
ti
qu
et
a
de
l
is
ta
d
e
ca
be
ce
ra
s
am
pl
ia
da

L
on
gi
tu
d
de
l
a
li
st
a
de
c
ab
ec
er
as

E
ti
qu
et
a
C
P
I
L
on
gi
tu
d
C
P
I
E
ti
qu
et
a
C
A
R

L
on
gi
tu
d
C
A
R

E
ti
qu
et
a
C
H
A

L
on
gi
tu
d
C
H
A

E
ti
qu
et
a
E
O
V

L
on
gi
tu
d
E
O
V

E
ti
qu
et
a
C
H
R

L
on
gi
tu
d
C
H
R

E
ti
qu
et
a
de
c
la
ve
p
úb
li
ca
(
co
ns
tr
ui
da
)
L
on
gi
tu
d
de
l
os
D
O
s
ub
si
gu
ie
nt
es

E
ti
qu
et
a
de
l
m
ód
ul
o
L
on
gi
tu
d
de
l
m
ód
ul
o
E
ti
qu
et
a
de
l
ex
po
ne
nt
e
pú
bl
ic
o
L
on
gi
tu
d
de
l
ex
po
ne
nt
e
pú
bl
ic
o
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 elemento
de datos se puede utilizar simultáneamente como un identificador de
la clave de la autoridad, para señalar la clave pública de la autoridad
de certificación (la codificación se explica más adelante, cuando se
habla del identificador de clave).
3. La «autorización del titular del certificado» (CHA) sirve para identi­
ficar los derechos que posee el titular del certificado. Consta del
identificador de la aplicación de tacógrafo y del tipo de equipo a
que se refiere el certificado (con arreglo al elemento de datos
, «00» para un Estado miembro).
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 434
4. La «referencia al titular del certificado» (CHR) sirve para identificar
de forma inequívoca al titular del certificado, de manera que el ele­
mento de datos se puede utilizar simultáneamente como un identifi­
cador de clave de sujeto para señalar la clave pública del titular del
certificado.
5. Los identificadores de clave permiten identificar de forma inequí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 certificació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 corres­
ponde. El identificador de clave tiene la forma arriba descrita.
En caso contrario, el fabricante debe identificar de forma inequí­
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 clave
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 certificado,
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.002 — 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 diferentes
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 relevante
para los servicios de autenticación, verificación de la firma digital 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 recuperació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 este cer­
tificado expedido:
«7F 21» «09» «5F 37» «81 80» «5F 38» «3A» «42» «08»
E
ti
qu
et
a
de
l
ce
rt
if
ic
ad
o
C
V

(C
on
st
ru
id
a)

L
on
gi
tu
d
de
l
os
D
O
s
ub
si
gu
ie
nt
es

E
ti
qu
et
a
de
f
ir
m
a
L
on
gi
tu
d
de
l
a
fi
rm
a
E
ti
qu
et
a
de
r
es
to

L
on
gi
tu
d
de
r
es
to

E
ti
qu
et
a
C
A
R

L
on
gi
tu
d
C
A
R

▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 436
3.3.3 Verificación y apertura del certificado
La verificación y apertura del certificado consiste en verificar la firma
con arreglo a la norma ISO/IEC 9796-2, recuperar el contenido del
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 siguiente
principio:
Cada parte deberá demostrar a la otra que está en posesión de un par de
claves válido cuya clave pública ha sido certificada por la autoridad de
certificación de un Estado miembro, y que dicha autoridad ha sido cer­
tificada por la autoridad de certificación europea.
La demostración se lleva a cabo firmando con la clave privada un 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 con 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.002 — 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.002 — 438
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 VU 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 transferencia,
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 en 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 longi­
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.002 — 440
Dado un par de respuestas para un comando no seguro:
Cabecera de comando Cuerpo del comando
CLA INS P1 P2 [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 P1 P2 [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» CC
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» CC
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.002 — 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» CC
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» CC
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 utilizando
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.002 — 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á iniciarse
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á incrementarse 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 TDEA
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.002 — 443
6. MECANISMOS DE FIRMA DIGITAL PARA LA TRANSFERENCIA
DE DATOS
CSM_032 El equipo dedicado inteligente (IDE) almacena en un archivo
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 deberá
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 deberá
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.002 — 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 referencias:
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 circuit
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 circuit
cards — Part 8: Commands for security operations. Se­
gunda edición 2004-06-01
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 cer­
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.002 — 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ública)
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éndice 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.002 — 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 dispositivos
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 dispositivos
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.002 — 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 de
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 de
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 de
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 de
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 de
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.002 — 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 de
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, un
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 12
CS#3 512/521 256 SHA-512 16
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 autenticación
mutua y la mensajería segura entre unidades instaladas en los vehículos y
tarjetas de tacógrafo, así como entre unidades instaladas en los vehículos
y dispositivos GNSS externos. Estos procesos se describen en detalle en
los capítulos 10 y 11 de este apéndice.
CSM_51 En el sistema europeo de tacógrafo inteligente, los pares 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.002 — 450
CSM_52 En la totalidad del sistema de Tacógrafo Inteligente Euro­
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 un
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 los
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 claves
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.002 — 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 clave
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.002 — 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 dos
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.002 — 453
CSM_77 Una unidad instalada en el vehículo utilizará la clave pri­
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 clave
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.002 — 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 enu­
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 claves
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 tarjetas
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á la 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.002 — 455
CSM_89 El período de validez de un certificado Card_Sign será el
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 enu­
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.002 — 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 privada
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.002 — 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.002 — 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 gene­
ración del certificado raíz ERCA; ERCA (2) es la segunda generació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 certificado raíz
correspondiente, y el segundo la generación del propio certificado. 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 certificado
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 expe­
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 expedidos
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 marco
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á ex­
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 MSCA
tendrán casi el mismo período de validez, a pesar de que sean de
dos generaciones diferentes.
5. El período de validez indicado para las tarjetas es el de las tarjetas de
conductor (5 años).
▼M1
6. Por limitaciones de espacio, solamente se indica la diferencia 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 describe
la interfaz entre una unidad instalada en el vehículo y un sensor de
movimiento. El proceso de emparejamiento entre una VU y un sensor
de movimiento se describe en detalle en el capítulo 12 del presente
apéndice.
CSM_100 Para aparear unidades instaladas en los vehículos y sensores
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.002 — 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 miembros
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 miembros
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.002 — 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.002 — 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 clave
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 AES
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.002 — 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álidas
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.002 — 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 comunicados
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.002 — 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 fabricante 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.002 — 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 de OKM y
K_VU DSRC _MAC = últimos octetos L de 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 lle­
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 tarjetas 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.002 — 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álidas
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.002 — 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.002 — 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 PK «7F 49» var
Parámetros de domi­
nio
DP «06» var
Punto público PP «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 utilizará
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 decir,
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.002 — 469
CSM_140 Para un certificado de enlace ERCA, la referencia del titular
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á para 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 de 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 identificador 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ículos, 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 certificado
tendrá el tipo de dato especi­
ficado en el apéndice 1.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 referen­
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 hora 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 contenido
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.002 — 471
CSM_153 En una solicitud de certificado, un fabricante de equipos
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 fabri­
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 uni­
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.002 — 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.002 — 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 cadena 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 certifica­
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.002 — 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.002 — 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 la
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.002 — 476
— Los certificados VU.CA y las claves públicas mencionados en la
figura son los empleados para firmar los certificados 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 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 VU.Link.EUR es el certificado raíz europeo indicado
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 VU
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.002 — 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 presen­
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.002 — 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 ha
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.002 — 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 autenti­
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.002 — 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.002 — 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 instalada
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 instalada
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.002 — 482
CSM_180 En los pasos 6 y 9 anteriores, la tarjeta y la unidad instalada
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 una
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 acceso
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 clave
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.002 — 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.002 — 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 de
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 siguiente
estructura, dependiendo del caso del comando no securizado correspon­
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 ‘8E’ ||
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 ‘97’ ||
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 siguiente
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.002 — 485
A continuación figuran tres ejemplos de transformaciones APDU para
comandos con código INS par. La figura 8 muestra un comando APDU
de caso 4 autenticado, la figura 9 muestra una respuesta APDU de 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.002 — 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.002 — 487
CSM_193 Una tarjeta de tacógrafo abortará una sesión de mensajerí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 tarjeta
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 autentica­
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.002 — 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 determinar 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 el
ú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ículo 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 vehí­
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 vehí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.002 — 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 entra 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.002 — 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.002 — 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 el
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 una
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 EGF
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.002 — 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 sensor de
movimiento y todas las claves asociadas son sustituidas regularmente.
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 consecu­
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.002 — 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, generación 2 y generación
3 pueden de hecho ser la misma clave, o bien pueden ser tres claves distintas de tres
longitudes diferentes, tal como se explica en CSM_117.
02016R0799 — ES — 21.08.2023 — 003.002 — 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 16 16 16
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 16 16 16
41 respuesta Clave de empareja­
miento
16 16 / 24 / 32 16 32 32
42 solicitud Clave de sesión 16 16 / 24 / 32 16 32 32
43 solicitud Información de empa­
rejamiento
24 24 32 32 32
50 respuesta Información de empa­
rejamiento
24 24 32 32 32
70 solicitud Datos de autentica­
ción
8 8 16 16 16
80 respuesta Valor de contador del
sensor + datos de au­
tenticación
8 8 16 16 16
▼B
CSM_219 La información de emparejamiento enviada en las instruccio­
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.002 — 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 cifrarse 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.002 — 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 regularmente
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). La 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ógrafo 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 de 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 con­
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 estará
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.002 — 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 seguridad
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.002 — 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 interrogador
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 de 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 ar­
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.002 — 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 verificar
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 datos
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.002 — 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 la
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.002 — 501
Figura 13
Protocolo para la verificación de la firma en un archivo de datos descargado
▼M1
02016R0799 — ES — 21.08.2023 — 003.002 — 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 producció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 vehí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.002 — 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 al receptor
GNSS y los datos del GNSS empleados por la unidad instalada en el
vehículo, incluidos los protocolos que deben aplicarse para garantizar una
transferencia de datos segura y correcta de la información sobre el
posicionamiento.
1.1. Ámbito de aplicación
GNS_1 La unidad instalada en el vehículo recabará datos de localiza­
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.002 — 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 inteligente, 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 para el
funcionamiento efectivo del tacógrafo inteligente. Por consiguiente, 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 un
sistema mundial independiente de radionavegación por satélite, y el esta­
blecido en el marco del programa EGNOS es un sistema regional de
navegación por satélite que mejora la calidad de la señal del Sistema 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 Galileo
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 de los sistemas europeos de
radionavegación por satélite y por el que se derogan el Reglamento (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.002 — 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 de
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, deno­
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, estén
autenticados o no.
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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áxima
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 funcionamiento
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.002 — 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 secuencia
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*hh
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 ha 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 conforme a
GNS_3a), F= autenticación fallida de los mensajes de navegación (detectada
por las verificaciones OSNMA especificadas en los documentos menciona­
dos en GNS_3b), V= vacío (posición autenticada no disponible por 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.002 — 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 exactitud
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 posició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.002 — 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 posició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 secuencia
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 dispositivo
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.002 — 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 siguientes
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 seguro
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 dispositivo
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.002 — 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.002 — 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 dispositivo
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 proceden­
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 las
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.002 — 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' 85 85
Primera secuencia GSA NMEA '02' 85 85
Segunda secuencia GSA NMEA '03' 85 85
Tercera secuencia GSA NMEA '04' 85 85
Cuarta secuencia GSA NMEA '05' 85 85
Quinta secuencia GSA NMEA '06' 85 85
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.002 — 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' 16 16
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' 85 85
Primera secuencia ASA '12' 85 85
Segunda secuencia ASA '13' 85 85
Tercera secuencia ASA '14' 85 85
Cuarta secuencia ASA '15' 85 85
Quinta secuencia ASA '16' 85 85
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, la
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.002 — 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.002 — 516
GNS_23a La VU escribirá también la hora de su RTC y la diferencia
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 (modo de
solo autenticación) descrita en el apéndice 11 (Mecanismos de segu­
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 registro
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.002 — 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 solo
autenticación) descrita en el apéndice 11, «Mecanismos de seguridad
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 registro
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.002 — 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 clave 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 seguridad
comunes), apartado 11.
4.4. Gestión de errores
En la presente sección se explica cómo se gestionan y se registran 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 trans­
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 receptor
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 las
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.002 — 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.002 — 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 inteli­
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.002 — 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.002 — 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.002 — 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.002 — 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 conductor
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 sistemas
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 obtener datos
del tacógrafo, utilizar los servicios de tacógrafo y proporcionar
datos al tacógrafo.
Para ello podrán utilizarse también otras interfaces de tacógrafo
(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.002 — 525
1.2. Acrónimos y definiciones
En este apéndice se utilizan específicamente los acrónimos y las 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 reglamentaciones y
normas y depende de ellas o de partes de ellas. En las cláusulas 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 participació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 establecerá des­
pués de completarse el proceso de emparejamiento Bluetooth®.
ITS_07 Entre la VU y la unidad ITS se establecerá una comunicación
protegida y encriptada, de acuerdo con los mecanismos de la es­
pecificación Bluetooth®. El presente apéndice no especifica meca­
nismos de encriptación ni de seguridad de otro tipo que se sumen a
lo que proporciona Bluetooth®.
ITS_08 Bluetooth® utiliza un modelo servidor-cliente para controlar 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.002 — 526
3.2. Servicios disponibles
ITS_09 Los datos que se transmitirán a través de la interfaz ITS de acuerdo
con el punto 4 deberán estar disponibles a través de los servicios
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 son
necesarios para la introducción manual de datos de conformidad
con el requisito 61 del anexo I C y, opcionalmente, para la intro­
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 especi­
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 todos 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 trans­
ferencia conforme al apéndice 6.
ITS_13 La VU pondrá la interfaz ITS a disposición del usuario de 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.002 — 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
R
an
ur
a
de
l
se
gu
nd
o
co
nd
uc
to
r 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 Bluetooth®, 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
R
an
ur
a
de
l s
eg
un
do
c
on
du
ct
or

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á la 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 disponibles 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.002 — 528
3.4. Datos disponibles y necesidad del consentimiento del conductor
ITS_18 Todos los datos del tacógrafo disponibles a través de los 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, como mí­
nimo, los datos clasificados como obligatorios en la lista del
punto 4.
ITS_20 Los datos del punto 4 clasificados como «personales» solo serán
accesibles con el consentimiento del conductor, que de esa manera
aceptará que los datos personales puedan salir de la red del vehí­
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 interfaz
ITS. Los datos adicionales no incluidos en el punto 4 serán clasi­
ficados como «personales» o «no personales» por el fabricante de
la VU, y el consentimiento del conductor se requerirá para los
datos clasificados como personales, salvo en el caso indicado en
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) se 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 conduc­
tores que hayan dado su consentimiento. Por ejemplo, en el caso
de una situación en equipo, si solo ha dado su consentimiento el
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 calibrado,
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, no
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 VU no personal no personal no necesita con­
sentimiento
obligatorio
CalibrationDate ISO 16844-7 VU no personal no personal no necesita con­
sentimiento
obligatorio
TachographVehicleS­
peed
ISO 16844-7 VU personal no aplicable consentimiento
del conductor
obligatorio
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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 VU personal no aplicable consentimiento
del conductor
obligatorio
Driver2WorkingState ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
obligatorio
DriveRecognize ISO 16844-7 VU no personal no personal no necesita con­
sentimiento
obligatorio
Driver1TimeRelatedS­
tates
ISO 16844-7 VU personal no aplicable consentimiento
del conductor
obligatorio
Driver2TimeRelatedS­
tates
ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
obligatorio
DriverCardDriver1 ISO 16844-7 VU personal no aplicable consentimiento
del conductor
obligatorio
DriverCardDriver2 ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
obligatorio
OverSpeed ISO 16844-7 VU personal no aplicable consentimiento
del conductor
obligatorio
TimeDate Apéndice 8 VU no personal no personal no necesita con­
sentimiento
obligatorio
HighResolutionTotal­
VehicleDistance
ISO 16844-7 VU no personal no personal no necesita con­
sentimiento
obligatorio
HighResolutionTrip­
Distance
ISO 16844-7 VU no personal no personal no necesita con­
sentimiento
obligatorio
ServiceComponentI­
dentification
ISO 16844-7 VU no personal no personal no necesita con­
sentimiento
obligatorio
ServiceDelayCalendar­
TimeBased
ISO 16844-7 VU 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.002 — 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 VU no personal no personal no necesita con­
sentimiento
obligatorio
Driver1ContinuousDri­
vingTime
ISO 16844-7 VU personal no aplicable consentimiento
del conductor
obligatorio
Driver2ContinuousDri­
vingTime
ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
obligatorio
Driver1Cumulative­
BreakTime
ISO 16844-7 VU personal no aplicable consentimiento
del conductor
obligatorio
Driver2Cumulative­
BreakTime
ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
obligatorio
Driver1CurrentDuratio­
nOfSelectedActivity
ISO 16844-7 VU personal no aplicable consentimiento
del conductor
obligatorio
Driver2CurrentDuratio­
nOfSelectedActivity
ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
obligatorio
SpeedAuthorised Apéndice 8 VU no personal no personal no necesita con­
sentimiento
obligatorio
TachographCardSlot1 ISO 16844-7 VU no personal no aplicable no necesita con­
sentimiento
obligatorio
TachographCardSlot2 ISO 16844-7 VU 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 VU no personal no personal no necesita con­
sentimiento
obligatorio
ModeOfOperation ISO 16844-7 VU no personal no personal no necesita con­
sentimiento
obligatorio
Driver1CumulatedDri­
vingTimePreviousAnd­
CurrentWeek
ISO 16844-7 VU personal no aplicable consentimiento
del conductor
obligatorio
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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 VU no aplicable personal consentimiento
del segundo con­
ductor
obligatorio
EngineSpeed ISO 16844-7 VU personal no aplicable consentimiento
del conductor
opcional
RegisteringMemberS­
tate
Apéndice 8 VU no personal no personal no necesita con­
sentimiento
obligatorio
VehicleRegistration­
Number
Apéndice 8 VU no personal no personal no necesita con­
sentimiento
obligatorio
Driver1EndOfLas­
tDailyRestPeriod
ISO 16844-7 VU personal no aplicable consentimiento
del conductor
opcional
Driver2EndOfLas­
tDailyRestPeriod
ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
opcional
Driver1EndOfLas­
tWeeklyRestPeriod
ISO 16844-7 VU personal no aplicable consentimiento
del conductor
opcional
Driver2EndOfLas­
tWeeklyRestPeriod
ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
opcional
Driver1EndOfSecond­
LastWeeklyRestPeriod
ISO 16844-7 VU personal no aplicable consentimiento
del conductor
opcional
Driver2EndOfSecond­
LastWeeklyRestPeriod
ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
opcional
Driver1TimeLastLoa­
dUnloadOperation
ISO 16844-7 VU personal no aplicable consentimiento
del conductor
opcional
Driver2TimeLastLoa­
dUnloadOperation
ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
opcional
Driver1CurrentDaily­
DrivingTime
ISO 16844-7 VU personal no aplicable consentimiento
del conductor
opcional
Driver2CurrentDaily­
DrivingTime
ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
opcional
Driver1CurrentWeekly­
DrivingTime
ISO 16844-7 VU personal no aplicable consentimiento
del conductor
opcional
Driver2CurrentWeekly­
DrivingTime
ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
opcional
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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 VU personal no aplicable consentimiento
del conductor
opcional
Driver2TimeLeftUntil­
NewDailyRestPeriod
ISO 16844-7 VU 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 VU personal no aplicable consentimiento
del conductor
opcional
Driver2CardNextMan­
datoryDownloadDate
ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
opcional
TachographNextMan­
datoryDownloadDate
ISO 16844-7 VU no personal no personal no necesita con­
sentimiento
opcional
Driver1TimeLeftUntil­
NewWeeklyRestPeriod
ISO 16844-7 VU personal no aplicable consentimiento
del conductor
opcional
Driver2TimeLeftUntil­
NewWeeklyRestPeriod
ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
opcional
Driver1NumberOfTi­
mes9hDailyDrivingTi­
mesExceeded
ISO 16844-7 VU personal no aplicable consentimiento
del conductor
opcional
Driver2NumberOfTi­
mes9hDailyDrivingTi­
mesExceeded
ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
opcional
Driver1CumulativeU­
ninterruptedRestTime
ISO 16844-7 VU personal no aplicable consentimiento
del conductor
opcional
Driver2CumulativeU­
ninterruptedRestTime
ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
opcional
Driver1Minimum­
DailyRest
ISO 16844-7 VU personal no aplicable consentimiento
del conductor
opcional
Driver2Minimum­
DailyRest
ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
opcional
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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 VU personal no aplicable consentimiento
del conductor
opcional
Driver2Minimum­
WeeklyRest
ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
opcional
Driver1Maximum­
DailyPeriod
ISO 16844-7 VU personal no aplicable consentimiento
del conductor
opcional
Driver2Maximum­
DailyPeriod
ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
opcional
Driver1Maximum­
DailyDrivingTime
ISO 16844-7 VU personal no aplicable consentimiento
del conductor
opcional
Driver2Maximum­
DailyDrivingTime
ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
opcional
Driver1NumberOfUse­
dReducedDailyRestPe­
riods
ISO 16844-7 VU personal no aplicable consentimiento
del conductor
opcional
Driver2NumberOfUse­
dReducedDailyRestPe­
riods
ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
opcional
Driver1RemainingCu­
rrentDrivingTime
ISO 16844-7 VU personal no aplicable consentimiento
del conductor
opcional
Driver2RemainingCu­
rrentDrivingTime
ISO 16844-7 VU no aplicable personal consentimiento
del segundo con­
ductor
opcional
VehiclePosition Apéndice 8 VU personal personal consentimiento
del conductor y
del segundo con­
ductor
obligatorio
ByDefaultLoadType Apéndice 8 VU personal personal consentimiento
del conductor y
del segundo con­
ductor
obligatorio
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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 teledetecció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 teledetecció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 comunicació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.002 — 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, con
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.002 — 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á prote­
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 conocer
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 obtener
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 disposiciones
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 que los
agentes de las autoridades de control competentes utilizan una comuni­
cación inalámbrica DSRC de 5,8 GHz específica para obtener datos a
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 infracció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 comunica­
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 competentes pue­
den aprovechar el mismo medio de comunicación utilizado en la super­
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 estable­
cen en la Directiva (UE) 2015/719] y estas operaciones pueden reali­
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 comunicaciones
que han de utilizarse para la Comunicación;
— las normas y los reglamentos que debe cumplir el equipo radioelé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 flota.
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 autorida­
des de control competentes, ni los criterios que aplicarán las autori­
dades de control competentes para decidir qué vehículos deben de­
tenerse (lo que dependerá del diseño del producto a menos que se
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.002 — 538
— las disposiciones sobre seguridad de los datos (como el cifrado)
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 puedan
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 presente
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.002 — 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.002 — 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 depende de la
totalidad o de distintas partes de los reglamentos y normas siguientes. En
las cláusulas del presente apéndice se especifican las normas pertinentes
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 sujetas 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 12834
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 (CEE)
n o 3821/85 relativo al aparato de control en el sector de los trans­
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 freight
vehicles (TARV).
[5] EN 300 674-1 Compatibilidad electromagnética y temas del espec­
tro de radio (ERM); Telemática para el tráfico y el transporte por
carretera (RTTT); Equipos de transmission (500 kbit/s / 250 kbit/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 unidades
del lado de la carretera (RSU) y unidades a bordo (OBU).
[6] EN 12253 Telemática para el tráfico y el transporte por carretera
(RTTT). Comunicaciones dedicadas de corto alcance (DSRC).
Capa física utilizando microondas a 5,8 GHz.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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ógico
de enlace.
[8] EN 12834 Telemática para el tráfico y el transporte por carretera
(RTTT). Comunicaciones dedicadas de corto alcance (DSRC) —
Capa de aplicación.
[9] EN 13372 Telemática para el tráfico y el transporte por carretera
(RTTT). Comunicaciones dedicadas de corto alcance (DSRC). Per­
files para aplicaciones RTTT.
[10] ISO 14906 Sistema de telepago. Definición de la interfaz de 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 de
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 DSRC
(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 actua­
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.002 — 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 la 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 travé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 comunicaciones
de teledetección temprana (interfaces DSRC de 5,8 GHz que operan
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 lateral de la
carretera hacia el centro del parabrisas del vehículo seleccionado. La
interrogación se realiza mediante interfaces DSRC de 5,8 GHz que ope­
ran según ERC 70-03 y se verifican con los parámetros apropiados de
EN 300 674-1 del modo descrito en el apartado 5. Véase la figura 14.1
(Ejemplo de uso 1).
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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 apunta un
REDCR manual portátil desde el vehículo hacia el centro del parabrisas
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 del 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 delante en un
flujo de tráfico). La interrogación se realiza mediante interfaces DSRC
de 5,8 GHz que operan según ERC 70-03 y se verifican con los pará­
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 datos 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ógrafo inte­
ligente es el descrito en la figura 14.3.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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, manual,
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 mostrar los
resultados de la función de comunicación a distancia al agente de las
autoridades de control competentes. El modo de visualización puede 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 control
competentes y del diseño del equipo, por lo que no se especifica 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.002 — 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 operaciones.
Figura 14.5
Flujo de trabajo de la función de comunicación a distancia
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 548
Los pasos se describen a continuación:
a. Siempre que el vehículo esté en marcha (el encendido conectado), el
tacógrafo suministra datos a la función VU. La función VU prepara
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 actualizados
(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 decide selec­
cionar un vehículo y recabar los Datos de ese vehículo específico, el
agente de las autoridades de control competentes introducirá primero
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 competentes
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 contiene los
valores de los datos útiles cifrados y los datos de seguridad de
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 control
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 lleva­
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.002 — 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 inter­
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 tacó­
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.002 — 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.002 — 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 pruebas de conformidad de acuerdo con la prueba de parámetros pertinente
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.002 — 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.002 — 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 pruebas de conformidad de acuerdo con la prueba de parámetros pertinente
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.002 — 554
DSC_32 La antena VU se instalará en el parabrisas delantero o cerca
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 La DSRC-VU envía una trama que contiene la
solicitud de asignación de ventana privada.
— Paso 3 El REDCR envía una trama que contiene una
asignación de ventana privada.
— Paso 4 La 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.002 — 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 La 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 El 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.002 — 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.002 — 557
— GET.request: comando, enviado desde el REDCR a la
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 res­
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.002 — 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ándar
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.002 — 559
► (1) (2) M1
► (3) M3
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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 adenda
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.002 — 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
N
o
o
ct
et
o
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.002 — 570
N
o
o
ct
et
o
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
N
o
o
ct
et
o
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.002 — 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
N
o
o
ct
et
o
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.002 — 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
O
ct
et
o
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.002 — 573
O
ct
et
o
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 No
Element Identifier (EID) Según se especifica en la VST. Sin
extensión
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 574
Campo Configuración
Access Credentials No
AttributeIdList Sin extensión, 1 atributo, AttributeID
= 1 (RtmData)
Fragmentation No
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
N
o
o
ct
et
o
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.002 — 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 No
Element Identifier (EID) Según se especifica en la
VST.
Access Credentials No
Fragmentation No
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
N
o
o
ct
et
o
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.002 — 576
N
o
o
ct
et
o
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
N
o
o
ct
et
o
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.002 — 577
N
o
o
ct
et
o
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 inspecciones
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.002 — 578
DSC_55 Para realizar esta prueba de comunicación básica, el REDCR
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.002 — 579
Cuadro 14.15
ejemplo de trama de petición ACTION,ECHO
N
o
o
ct
et
o
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.002 — 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
N
o
o
ct
et
o
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.002 — 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 la 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 elegi­
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 la 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 comuni­
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.002 — 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 siguiente:
— 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.002 — 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 la 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ódulo
de seguridad (para pasarlos a la DSRC-VU), pero no lo con­
sigue, registrará el fallo con el tipo EventFaultType y el valor
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.002 — 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 defi­
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 inestables, espe­
cialmente en las combinaciones de «REDCR portátil» y «vehículo en
movimiento» que intervienen en esta aplicación. Por tanto, es preciso
establecer la diferencia entre un «fallo de lectura» y una condición de
«error». En una transacción a través de una interfaz inalámbrica, 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 comunicación
satisfactoria y la transferencia de datos, a menos que el vehículo selec­
cionado se salga del alcance durante el tiempo necesario para retrans­
mitir. (Es posible que una instancia «satisfactoria» de una «lectura» 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 antenas esté
apantallada (puede ser intencionado, pero también puede deberse a la
presencia física de otro vehículo); a interferencias radioeléctricas, espe­
cialmente de comunicaciones WIFI de alrededor de 5,8 GHz u otras
comunicaciones inalámbricas de acceso público, o puede deberse a in­
terferencias de radares o a condiciones atmosféricas problemáticas (por
ejemplo, durante una tormenta eléctrica); o sencillamente a haberse sa­
lido del alcance de la comunicación DSRC. Las instancias individuales
de los fallos de lectura, por su naturaleza, no pueden registrarse 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 manipulación
intencionada y, por tanto, el agente de la autoridad de control compe­
tente necesita un medio para registrar el fallo y alertar a otros agentes
que se encuentren más adelante del lugar en el que se ha producido 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. Por
tanto, estos informes dependerán del diseño del equipo REDCR.
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 585
Técnicamente, un «fallo de lectura» es distinto a un «error». En 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 de 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 correctos. Si
no se valida la CRC, se retransmiten los datos. Estadísticamente, es tan
improbable que los datos puedan pasar con éxito una CRC de forma
incorrecta que esta posibilidad puede descartarse.
Si la CRC no se valida y no hay tiempo para retransmitir y recibir los
datos correctos, el resultado no será un error, sino una instanciación de
un tipo específico de fallo de lectura.
Los únicos datos de «fallo» significativos que pueden registrarse 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 comunica­
ción a distancia:
▼B
02016R0799 — ES — 21.08.2023 — 003.002 — 586
1) Una prueba ECHO para validar el canal de comunicación
inalámbrica DSRC-REDCR >>-:-
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 >>-:-
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 funciona
sin necesidad de acceder a las credenciales de seguridad. Por tanto, el
equipo del evaluador solo precisa poder inicializar una comunicació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. Suponiendo
que se recibe esta respuesta correctamente, es posible validar el funcio­
namiento correcto del enlace DSRC (DSRC-REDCR >>-:-
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 lugar
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.002 — 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 conducción
semanal y el tiempo de conducción bisemanal utilizando los datos 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 unidad instalada en
el vehículo, así como las actividades del conductor seleccionadas 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 actividad
de duración negativa (es decir, que comienza más tarde de lo que acaba)
debidos a solapamientos temporales entre dos VU distintas o a un ajuste de
la hora.
Las actividades registradas en la tarjeta de conductor correspondientes 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 un 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 comunicació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íodo de
descanso diario.
El turno RTM en curso es el período desde el final del último perí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íodo 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 ininterrumpido 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.002 — 588
g) Un «período de descanso diario» es un período de PAUSA/DESCANSO,
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 períodos
de descanso semanales, estos se considerarán períodos de descanso diarios.
h) Un «período de descanso diario normal» es un período de descanso con­
tinuo de como mínimo once horas.
A modo de excepción, cuando esté activa una condición de TRAYECTO
EN TRANSBORDADOR/TREN, el período de descanso diario normal
podrá interrumpirse como máximo dos veces con actividades distintas al
descanso, con una duración acumulada máxima de una hora, es decir, 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 cuando 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 interrumpido, 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 descanso
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 descanso 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 TRAYECTO
EN TRANSBORDADOR/TREN durante una o las dos partes de un pe­
ríodo de descanso diario dividido, este podrá interrumpirse como máximo
dos veces con otras actividades, con una duración acumulada máxima 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.002 — 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 sea:
— de como mínimo tres horas y de menos de once horas, en el primer
período de descanso, y de como mínimo nueve horas, en el segundo
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 primer
período de descanso, y de como mínimo nueve horas, en el segundo
período de descanso, cuando el primer período de descanso no haya
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 las 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 interrumpido 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 se 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 detectada, si se dan
las condiciones siguientes:
— la interrupción hace que la duración total de las interrupciones 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 en
transbordador/tren, excedan en total de una hora,
— la interrupción hace que el número total de interrupciones detectadas,
incluidas, en su caso, las producidas durante la primera parte de un
período de descanso diario dividido a causa de un trayecto en trans­
bordador/tren, exceda de dos,
— una vez finalizada la interrupción, se ha almacenado una «entrada 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á al tiempo de
descanso acumulado.
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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 producidas 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 acumulado.
La VU detendrá el proceso de cómputo cuando se hayan añadido al tiempo
de descanso acumulado dos períodos de descanso continuos producidos
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 dividido también
interrumpido por un trayecto en transbordador/tren. De lo contrario, la VU
procederá conforme al paso 3.
c) Paso 3
Si, tras proceder con el paso 2, la VU sigue computando el tiempo de
descanso acumulado, deberá detectar las interrupciones que se produzcan
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 interrupciones 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 continuo
previo a la interrupción. De lo contrario, los períodos de descanso 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 condició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 de dos
períodos de descanso continuos al período de descanso para el que 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 trayecto 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.002 — 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.002 — 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 correspondientes 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 medida en que la VU
no haya computado un período de descanso diario normal o dividido completo
conforme al punto 3, los tiempos de conducción durante las interrupciones se
añadirán al tiempo de conducción diario correspondiente al turno RTM en
curso.
La VU computará también los tiempos de conducción semanal y bisemanal.
El tiempo de conducción durante las interrupciones de los períodos 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.002 — 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 unidad instalada en el
vehículo
2.4.3 Transferencia de datos de la unidad instalada en el vehículo
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 definiciones:
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 general 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 aparatos de control
y las tarjetas de tacógrafo de segunda generación.
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 594
Además de lo dispuesto en la introducción, cabe recordar la siguiente
información:
— los sensores de movimiento de primera generación no son interopera­
bles con ninguna versión de las unidades instaladas en el vehículo 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 aparatos
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 primera 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 las 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, pueden
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 forma
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 generación
solo podrán utilizar las tarjetas de taller de segunda genera­
ción.
MIG_005 Para determinar el modo de funcionamiento, cualquier versión
de las unidades instaladas en el vehículo de segunda genera­
ción solo considerará el tipo de las tarjetas válidas insertadas,
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 primera ge­
neración, mientras que los sensores de movimiento de segunda generación
son interoperables con cualquier versión de las unidades instaladas en el
vehículo de segunda generación. Asimismo, serán de aplicación los requi­
sitos que figuran a continuación.
MIG_007 Ninguna versión de las unidades instaladas en el vehículo de
segunda generación podrá emparejarse y utilizarse con senso­
res de movimiento de primera generación.
▼M3
02016R0799 — ES — 21.08.2023 — 003.002 — 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 compa­
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 desde 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 de 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.002 — 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 de 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 estar 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 para
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 tacó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 tipos
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 Estados
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.002 — 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 que 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.002 — 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 movimiento 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 — Parte 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.002 — 599
Se instalará y utilizará solo en los tipos de vehículos definidos
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 movimiento
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é equipado 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 incluye
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 aparato 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.002 — 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 emparejamiento
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 impulsos
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 caso,
multiplicar o dividir los impulsos de frecuencia de los impulsos
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 presente
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 arreglo 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 los
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.002 — 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 pueda
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 integrado 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 solo 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 de tem­
peraturas determinado por el fabricante.
ADA_021 El adaptador funcionará perfectamente en el intervalo higromé­
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 informació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.002 — 602
— VIN del vehículo en el que se ha instalado.
ADA_028 Además, la placa descriptiva deberá contener la informació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 auto­
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 parte del
vehículo que proporcione sus impulsos de entrada.
ADA_033 Los cables que alimenten el adaptador serán rojos (carga po­
sitiva) y negros (tierra).
5.2. Precintos
ADA_034 Serán de aplicación los siguientes requisitos de precintado:
— 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ódico (con­
troles periódicos son aquellos que se ajustan a los requisitos
(409) a (413) del anexo IC) del aparato de control, se verificará
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.002 — 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 sustitució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 homologa­
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 adapta­
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.002 — 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.002 — 605
Apéndice 17
DISPOSICIONES TRANSITORIAS RELATIVAS A LA UTILIZACIÓN
DEL SERVICIO OSNMA POR LOS TACÓGRAFOS
1. DEFINICIONES Y ACRONIMOS
1.1. Definiciones
Declaración de servicio de la autenticación de mensajes de navegación
del servicio abierto de Galileo (OSNMA): declaración de la Comisión
Europea de que la OSNMA de Galileo entra en su fase operativa.
Unidad de transición instalada en el vehículo: unidad instalada en el
vehículo que cumple las disposiciones del presente apéndice.
Las unidades de transición instaladas en el vehículo se construyen de
conformidad con el SIS ICD y las Directrices OSNMA para los receptores
aplicables a la fase de ensayo público de la OSNMA. Están equipadas con
un receptor GNSS capaz de utilizar el servicio OSNMA disponible du­
rante su fase de ensayo público.
No obstante, las unidades de transición instaladas en el vehículo no pue­
den autenticar los mensajes de navegación disponibles después de la de­
claración de servicio OSNMA, debido a la necesidad de actualizar el
material criptográfico de la unidad instalada en el vehículo. Debe reali­
zarse una actualización adecuada del software para que puedan empezar a
utilizar la OSNMA y cumplir todos los requisitos del anexo I C y sus
apéndices 1 a 16. Antes de la actualización, las unidades de transición
instaladas en el vehículo aplicarán las funcionalidades relacionadas con la
OSNMA especificadas en el presente apéndice. Las funcionalidades no
relacionadas con el servicio OSNMA se mantienen sin cambios.
Si se procede a la actualización adecuada del software, las unidades de
transición instaladas en el vehículo deben implementar el SIS ICD y las
Directrices OSNMA para los receptores aplicables a la fase operativa de la
OSNMA, y cumplir todos los requisitos del anexo I C y sus apéndices 1
a 16, utilizando la OSNMA disponible durante la fase operativa.
Tacógrafo de transición: tacógrafo que incluye una unidad de transición
instalada en el vehículo.
1.2. Acrónimos
ICD documento de control de interfaces
OSNMA autenticación de mensajes de navegación del servi­
cio abierto de Galileo
SIS señal en el espacio
VU unidad instalada en el vehículo
▼M4
02016R0799 — ES — 21.08.2023 — 003.002 — 606
2. CONSIDERACIONES GENERALES RELACIONADAS CON LA OS­
NMA
A fin de que los vehículos matriculados por primera vez puedan estar
equipados con la versión 2 de los tacógrafos de segunda generación, a
partir de la fecha de introducción solicitada tal como se define en el
anexo I C, sección 1, letra ccc), del Reglamento de Ejecu­
ción (UE) 2016/799, es necesario homologar, fabricar y comercializar
unidades instaladas en el vehículo antes de la declaración de servicio de
la OSNMA. Para estas unidades instaladas en el vehículo, denominadas
unidades de transición instaladas en el vehículo, es necesario adaptar los
requisitos relacionados con la OSNMA del anexo I C y sus apéndices 1
a 16, de modo que puedan homologarse y utilizarse sobre el terreno.
Las disposiciones establecidas en el presente apéndice definen los requi­
sitos específicos aplicables a las unidades de transición instaladas en el
vehículo. Solo se aplican a las unidades instaladas en el vehículo equipa­
das con un receptor GNSS interno.
3. REQUISITOS APLICABLES AL RECEPTOR GNSS DE LOS TACO­
GRAFOS DE TRANSICION
TRA_001 Las unidades de transición instaladas en el vehículo deberán ir
equipadas con un receptor GNSS capaz de utilizar el servicio OSNMA
disponible durante su fase de ensayo público.
TRA_002 Los requisitos del apéndice 12 se aplican al receptor GNSS
integrado en las unidades de transición instaladas en el vehículo, con las
siguientes interpretaciones:
— el SIS ICD y las Directrices OSNMA para los receptores a las que se
hace referencia son los documentos disponibles para la fase de ensayo
público:
— “Galileo Open Service Navigation Message Autentication (OS­
NMA) User DCI for the Test Phase” [usuario ICD de la autenti­
cación de mensajes de navegación del servicio abierto
Galileo (OSNMA) para la fase de ensayo] edición 1.0, noviembre
de 2021;
— “Galileo Open Service Navigation Message Authentication (OS­
NMA) Receiver Guidelines for the Test Phase” [Directrices OS­
NMA para los receptores para la fase de ensayo], edición 1.0,
noviembre de 2021.
— OSNMA es el servicio disponible durante la fase de ensayo público.
— SIS es la señal en el espacio disponible durante la fase de ensayo
público.
TRA_003 El receptor GNSS integrado en las unidades de transición ins­
taladas en el vehículo debe diseñarse de tal manera que, tras una actua­
lización de su software efectuada mediante la actualización del software de
la unidad instalada en el vehículo, cumpla plenamente los requisitos del
anexo 12 y que utilice el servicio OSNMA disponible durante su fase
operativa.
4. REQUISITOS APLICABLES A LAS UNIDADES DE TRANSICION
INSTALADAS EN EL VEHICULO
Las unidades de transición instaladas en el vehículo podrán procesar la
señal OSNMA disponible durante su fase de ensayo público, pero no
podrán notificar el estado de autenticación de los mensajes de navegación
del SIS disponible durante la fase operativa de la OSNMA, hasta que se
aplique una actualización adecuada del software. Por lo tanto, dan por
supuesto que las posiciones estándar transmitidas por el receptor GNSS
siempre están autenticadas.
Los requisitos del anexo I C y sus apéndices 1 a 16 se aplican con las
siguientes interpretaciones.
▼M4
02016R0799 — ES — 21.08.2023 — 003.002 — 607
TRA_004 En el anexo I C, punto 3.9.15 Incidente “conflicto temporal”,
el requisito 86 debe entenderse como sigue:
Este incidente se activará, fuera del modo de calibrado, cuando la VU
detecte una discrepancia 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 estándar transmitidas por el receptor GNSS o el dispositivo
GNSS externo. Se detecta una “discrepancia temporal” si la diferencia
horaria excede de ± 3 segundos, 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.
TRA_005 En el anexo I C, punto 3.9.18 Incidente “Anomalía del
GNSS”, el requisito 88 bis debe entenderse como sigue:
Este incidente se activará, fuera del modo de calibrado, cuando el recep­
tor GNSS detecte un ataque o cuando haya fallado, tal como se especifica
en el apéndice 12. Después de haberse producido un incidente de ano­
malía del GNSS, la VU no generará más incidentes de anomalía del
GNSS durante los diez minutos siguientes.
TRA_006 En el anexo I C, punto 3.12.5 Registro y almacenamiento en la
memoria de datos, 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 acumulada, el requisito 110 debe entenderse como sigue:
Junto con cada lugar y posición, el aparato de control deberá 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 fecha y hora de la entrada,
— el tipo de entrada (comienzo, final o tres horas de tiempo de conduc­
ción acumulado),
— la exactitud, la fecha y la hora del GNSS correspondientes, si procede,
— la lectura del cuentakilómetros del vehículo,
— un indicador que señale que la posición ha sido autenticada.
TRA_007 En el anexo I C, punto 3.12.17 Registro y almacenamiento en
la memoria de datos, Cruces de fronteras, el requisito 133 ter debe enten­
derse como sigue:
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 que la posición ha sido autenticada,
— el valor del cuentakilómetros del vehículo en el momento de detectarse
el cruce de fronteras.
▼M4
02016R0799 — ES — 21.08.2023 — 003.002 — 608
TRA_008 En el anexo I C, punto 3.12.18 Registro y almacenamiento en
la memoria de datos, Operaciones de carga/descarga, el requisito 133
octies debe entenderse como sigue:
Junto con el tipo de operación y la posición, el aparato de control regis­
trará 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 fecha y hora de la operación de carga/descarga,
— la exactitud, la fecha y la hora del GNSS correspondientes, si procede,
— un indicador que señale que la posición ha sido autenticada,
— la lectura del cuentakilómetros del vehículo.
TRA_009 En el anexo I C, punto 3.23 Ajuste de la hora, el requisito 211
debe entenderse como sigue:
La hora del reloj interno de la VU se reajustará automáticamente a
intervalos variables. El siguiente reajuste automático de la hora se acti­
vará entre setenta y dos y ciento sesenta y ocho horas después del ante­
rior, y después de que la VU pueda acceder a la hora GNSS a través de
un mensaje de posición estándar válido, de conformidad con el apéndice
12. No obstante, el ajuste de la hora nunca será mayor que la desviación
máxima diaria acumulada de la hora, calculada por el fabricante de la
VU de conformidad con el requisito 41 ter. 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 estándar , 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 proporcionada en el mensaje de posición estándar.
TRA_010 En el anexo I C, punto 3.23 Ajuste de la hora, el requisito 212
debe entenderse como sigue:
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éndice 8,
— o bien solicitando una alineación del reloj de la VU con la hora
proporcionada por el receptor GNSS. Esto solo podrá hacerse si la
hora proporcionada por el receptor GNSS se obtiene utilizando men­
sajes de posición estándar. En este último caso, deberá utilizarse el
servicio RoutineControl de conformidad con el punto 8 del apéndice 8.
▼M4
02016R0799 — ES — 21.08.2023 — 003.002 — 609
TRA_011 En el apéndice 4, punto 2 Especificación de los bloques de
datos, el párrafo primero, séptimo guion, debe entenderse como sigue:
Cuando se imprime después de la longitud y la latitud de una posición
registrada, o después del sello de tiempo en que se determinó la posición,
el pictograma indica que esta posición se ha considerado auténtica.
TRA_012 En el apéndice 8, punto 8.1 Servicio RoutineControl (Ajuste de
la hora), Descripción del mensaje, el requisito CPR_065a, debe entenderse
como sigue:
El servicio RoutineControl (TimeAdjustment) ofrece la capacidad de ac­
tivar la alineación del reloj de la VU con la hora proporcionada por el
receptor GNSS.
Para la ejecución del servicio RoutineControl (TimeAdjustment), la VU
debe estar en el modo CALIBRADO.
Condición previa: se garantiza que la VU es capaz de recibir mensajes de
posición estándar del receptor GNSS.
Mientras esté en curso el ajuste de la hora, la VU responderá a la
petición RoutineControl, subfunción requestRoutineResults, con routi­
neInfo = 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 subfun­
ción requestRoutineResults.
TRA_013 En el apéndice 12, punto 3 Secuencias proporcionadas por el
receptor GNSS, el requisito GNS_4a debe entenderse como sigue:
Los datos contenidos en las secuencias AMC facilitados por el receptor
GNSS, en su caso, no serán utilizados por la unidad instalada en el
vehículo, excepto los siguientes valores del estado:
J = jamming (interferencia intencionada) u O = otro ataque al GNSS
(mediante comprobaciones de coherencia realizadas conforme a
GNS_3.a),
V = vacío (posición autenticada no disponible por cualquier otra razón).
TRA_014 En el apéndice 12, punto 3 Secuencias facilitadas por el recep­
tor GNSS, el requisito GNS_5 debe entenderse como sigue:
Los datos contenidos en las secuencias ASA facilitados por el receptor
GNSS, en su caso, no serán utilizados por la unidad instalada en el
vehículo.
TRA_015 En el apéndice 12, punto 5.2 Unidad instalada en el vehículo
sin dispositivo GNSS externo, Transferencia de información del receptor
GNSS a la VU, los requisitos GNS_34 y 36 deben entenderse como sigue:
El procesador de la VU no utilizará la información extraída de la se­
cuencia AMC, excepto para los siguientes valores del estado:
J = jamming (interferencia intencionada) u O = otro ataque al GNSS
(mediante comprobaciones de coherencia realizadas conforme a
GNS_3.a),
V = vacío (posición autenticada no disponible por cualquier otra razón).
El procesador de la VU no utilizará la información extraída de la se­
cuencia ASA.
▼M4
02016R0799 — ES — 21.08.2023 — 003.002 — 610
TRA_016 En el apéndice 12, punto 6 Procesamiento y registro de los
datos de posición por la VU, el requisito GNS_39 debe entenderse como
sigue:
Los datos de posición se almacenarán en la VU junto con un indicador
que señale si la posición ha sido considerada autenticada. Cuando haya
que registrar los datos de posición en la VU, se aplicarán las siguientes
reglas:
a) Si la posición estándar es válida, se registrarán en la VU la posición
estándar y su exactitud, y el indicador se ajustará en “autenticada”.
TRA_017 En el apéndice 12, punto 6 Procesamiento y registro de los
datos de posición por la VU, el requisito GNS_40 debe entenderse como
sigue:
Cuando el valor del estado en una secuencia AMC recibida sea “J” u
“O” conforme al requisito GNS_4.a, la VU generará y registrará un
incidente de anomalía GNSS, tal como se define en el requisito 88 bis
del anexo IC y el apéndice 1 (EventFaultType). La unidad instalada en el
vehículo podrá realizar comprobaciones adicionales antes de almacenar
un incidente de anomalía GNSS tras la recepción de un ajuste “J” u “O”.
TRA_018 En el apéndice 12, punto 8 Conflicto del movimiento del ve­
hículo, el requisito GNS_42, condición de activación 2, el primer y se­
gundo incisos después de la fórmula deben entenderse como sigue:
— DistanciaGnss es la distancia entre la posición actual del vehículo y
la anterior, obtenidas ambas a partir de mensajes de posición estándar
válidos, sin considerar la altura,
— DiferenciaCuentakilómetros es la diferencia entre el valor actual del
cuentakilómetros y el valor del cuentakilómetros correspondiente al
mensaje de posición estándar válido anterior,
TRA_019 En el apéndice 14, punto 5.4.5, los requisitos del protocolo
DSRC para los elementos RTME de RtmData, acciones realizadas y de­
finiciones, requisito DSC_41, cuadro 14.3, la segunda celda de la fila
RTM20 debe entenderse como sigue:
La VU generará un valor entero (timeReal del apéndice 1) para el ele­
mento de datos RTM20.
La VU ajustará el valor de RTM20 en la hora a la que estaba disponible
la última posición estándar del vehículo a partir del receptor GNSS.
Si en ningún momento ha estado disponible una posición estándar del
vehículo a partir del receptor GNSS, la VU ajustará el valor de RTM20
en 0.
TRA_020 El fabricante de una unidad de transición homologada de tipo
instalada en el vehículo informará a la Comisión de sus versiones de
software. La Comisión publicará estas versiones de software en un sitio
web de acceso público.
▼M4
02016R0799 — ES — 21.08.2023 — 003.002 — 611
5. DISPOSICIONES ESPECIFICAS PARA LA HOMOLOGACION DE
TIPO Y EL USO DE TACOGRAFOS DE TRANSICION
TRA_021 Las unidades de transición instaladas en el vehículo estarán
homologadas de tipo conforme a los requisitos del anexo I C y sus anexos
1 a 16, completados con las disposiciones del presente apéndice.
TRA_022 Los certificados de homologación de tipo de las unidades de
transición instaladas en el vehículo y de los tacógrafos de transición solo
podrán solicitarse hasta el 31 de diciembre de 2023 o hasta la fecha de la
declaración de servicio de la OSNMA, si esta es posterior.
TRA_023 Las unidades de transición instaladas en el vehículo podrán ser
instaladas en vehículos matriculados por primera vez solo hasta el
31 de mayo de 2024 o cinco meses después de la fecha de la declaración
de servicio de la OSNMA, si esta es posterior.
▼M4
02016R0799 — ES — 21.08.2023 — 003.002 — 612
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 seguida de un
número distintivo o de una letra distintiva del país que haya expedido 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 certificado de
homologación que se haya asignado al prototipo del aparato de control o
de la hoja de registro o de la tarjeta de tacógrafo, colocado en cualquier
posición cerca del rectángulo.
▼C1
02016R0799 — ES — 21.08.2023 — 003.002 — 613
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. Deberá ser indeleble
y ser siempre legible.
3. Las dimensiones de la marca de homologación reproducida a continuación ( 1 ),
se expresarán en mm, y dichas dimensiones serán las mínimas. Deberán
respetarse las relaciones entre distintas dimensiones.
▼C1
( 1 ) Estas cifras tienen únicamente carácter informativo.
02016R0799 — ES — 21.08.2023 — 003.002 — 614
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 las homologa­
ciones concedidas o de las posibles retiradas, cada Estado miembro 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 control
— la homologación de un modelo de hoja de registro
— la retirada de la homologación de un modelo de hoja de registro
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 va 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.002 — 615
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 las homologa­
ciones concedidas o de las posibles retiradas, cada Estado miembro 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 utilizarse 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.002 — 616
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 las homologa­
ciones concedidas o de las posibles retiradas, cada Estado miembro 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 interoperabilidad
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 utilizarse 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.


Full & Egal Universal Law Academy