II 
(Actos no legislativo s) 
REGL AMENTOS 
REGL AMENTO DE EJECUCIÓN (UE) 2016/799 DE LA COMISIÓN 
de 18 de marzo de 2016 
por el que se ejecuta el Reglament o (UE) n.o 165/2014 del Parlamento Europeo y del Consejo, que 
establece los requisit os para la constr ucción, ensay o, inst alación, funcionamient o y reparación de 
los tacóg rafo s y de sus componentes 
(Texto pertinente a efectos del EEE) 
LA COMISIÓN EUR OPEA, 
Visto el Tratado de Funcionamiento de la Unión Europea, 
Visto el Reglamento (UE) n.o 165/2014 del Parlamento Europeo y del Consejo, de 4 de febrero de 2014, relativ o a los 
tacógraf os en el transpor te por carretera (1), y en particular su artículo 11 y su artículo 12, apar tado 7, 
Considerando lo siguient e: 
(1)  El Reglamento (UE) n.o 165/2014 ha introducido el tacógraf o digital de segunda generación denominado 
tacógraf o intelig ente, que incluye una conexión con el dispositivo GNSS (sistema mundial de radiona vegación por 
satélite), un dispositivo de comunicación a efect os de teledetección temprana y una interfaz con los sistem as de 
transpor te intelig entes. Deben establecerse las especificaciones de los requisit os técnicos para la fabricación de 
tacógraf os inteli gent es. 
(2)  El dispositivo de teledet ección temprana establecido por el artículo 9, apar tado 4, del Reglamento (UE) 
n.o 165/2014 debe transmitir a un agente de control en carretera los datos del tacógraf o digital y la información 
relativa a los pesos y pesos por eje de todo el conjunto del vehículo (tractores y remolques o semir remolques), de 
conf ormidad con la Directiva 96/53/CE del Parlamento Europeo y del Consejo (2). De este modo, las autor idades 
de control podrán efectuar una comprobación rápida y eficaz de los vehículos, con menos dispositivo s 
electrónicos en la cabina del vehículo. 
(3)  De conf ormidad con la Directiva 96/53/CE, el dispositivo de teledet ección temprana debe utilizar las normas CEN 
DSR C (3) a que se refiere dicha Directiva, en la banda de frecuencias de 5 795-5 805 MHz. Toda vez que dicha 
banda de frecuencias se utiliza también en el telepea je, y a fin de evitar interfe rencias entre las aplicaciones de 
peaje y de control, los controladores no deben utilizar el dispositivo de teledet ección temprana en un área de 
peaje. 
(4)  Con el tacógraf o inteli gent e deben introducirse nuevos mecanismos de segur idad para manten er el nivel de 
segur idad del tacógraf o digital, a fin de corregir los actuales punt os vulnerables en mater ia de segur idad. Uno de 
esos punt os vulnerables es la ausencia de fechas de expiración de los certificados digitales. Con el fin de respetar 
las mejores prácticas en mater ia de segur idad, se recomienda evitar el uso de certificado s digitales sin fecha de 
expiración. El período de validez operativa normal de las unidades instaladas en vehículos debe ser de quince 
años, a partir de la fecha de emisión de los certificados digitales de dichas unidades. Las unidades instaladas en 
vehículos deben ser reemplazad as al concluir el período de validez. 26.5.2016 L 139/1 Diar io Oficial de la Unión Europea ES    
(1)DO L 60 de 28.2.2014, p. 1. 
(2)Directiva 96/53/CE del Consejo, de 25 de julio de 1996, por la que se establecen, para determinados vehículos de carretera que circulan 
en la Comunidad, las dimensiones máximas autorizadas en el tráfico nacional e internacional y los pesos máximos auto rizados en el 
tráfico inter nacional (DO L 235 de 17.9.1996, p. 59). 
(3)Nor mas de comunicaciones dedicadas de corto alcance del Comité Europeo de Nor malización (CEN) EN 12253, EN 12795, EN 12834, 
EN 13372 e ISO 14906. 
(5)  El suministro de información fiable y segura sobre la localización constituye un elemento esencial del buen 
funcionamient o de los tacógraf os inteligent es. Por tanto, conviene garantizar su compatibilidad con los servicios 
de valor añadido prestados por el programa Galileo, según lo dispuesto en el Reglamento (UE) n.o 1285/2013 del 
Parlamento Europeo y del Consejo (1), a fin de mejorar la segur idad del tacógraf o intelig ente. 
(6)  De conf ormidad con el artículo 8, apar tado 1, el artículo 9, apar tado 1, y el artículo 10, apar tados 1 y 2, del 
Reglamento (UE) n.o 165/2014, los mecanismos de segur idad introducidos por dicho Reglamento deben aplicarse 
36 meses después de la entrada en vigor de los actos de ejecución necesar ios con el fin de permitir a los 
fabricantes el desar rollo de la nueva generación de tacógraf os inteligent es, y recibir de las autori dades 
compet entes sus certificados de homologa ción. 
(7)  De conf ormidad con el Reglamento (UE) n.o 165/2014, los vehículos matr iculados por primera vez en un Estado 
miembro 36 meses después de la entrada en vigor del presente Reglamento de la Comisión deben estar equipados 
con un tacógraf o inteli gent e que cumpla los requisitos en él cont enidos. En cualquier caso, todos los vehículos 
que circulen en un Estado miembro distinto de su Estado miembro de matr iculación deben estar equipados con 
un tacógraf o intelig ente que cumpla los requisitos quince años después de la fecha de aplicación de estos. 
(8)  El Reglamento (CE) n.o 68/2009 de la Comisión (2) permitió, durante un período transito rio que finalizó el 31 de 
diciembre de 2013, la utilización de un adapt ador para hacer posible la instalación de tacógraf os en vehículos de 
tipo M1 y N1. Debido a dificultades técn icas relacionadas con la búsqueda de una altern ativa a la utilización del 
adap tador , los exper tos de la industr ia del automó vil y del tacógraf o, junto con la Comisión, llegaro n a la 
conclusión de que no era viable ninguna solución alternativa al adap tador que no supusiera un coste elevado para 
el sector , que sería desproporcionado en relación con el tamaño del mercado. Por lo tanto, debe autor izarse por 
tiempo indefinido la utilización de un adap tador en vehículos de tipo M1 y N1. 
(9)  Las medidas previstas en el present e Reglamento se ajustan al dictamen del Comité a que se refie re el artículo 42, 
apar tado 3, del Reglamento (UE) n.o 165/2014. 
HA ADOPT ADO EL PRESENTE REGL AMENTO: 
Articulo 1 
Objeto y ámbito de aplicación 
1. El present e Reglamento establece las disposiciones necesar ias para la aplicación unif orme de los siguientes aspectos 
en relación con los tacógraf os: 
a)  registro de la posición del vehículo en deter minados punt os durant e el período de traba jo diar io del conduct or; 
b)  teled etección temprana de posibles manipulaciones o usos indebidos del tacógraf o intelig ente; 
c)  interf az con los sistemas de transpor te inteligent es; 
d)  requisitos técn icos y administrativ os para los procedimiento s de homolog ación de los tacógraf os, incluidos los 
mecanismos de segur idad. 
2. La constr ucción, ensa yo, instalación, inspección, funcionamient o y reparación de los tacógraf os intelig entes y sus 
compo nentes deberán cumplir los requisitos técnicos establecidos en el anex o 1C del present e Reglamento. 
3. Los tacógraf os distintos de los tacógraf os inteli gent es seguirán teniendo que cumplir , en lo que se refie re a las 
condiciones de constr ucción, ensa yo, instalación, inspección, funcionamient o y reparación, los requisit os establecidos en 
el anex o 1 o el anex o 1B del Reglamento (CEE) n.o 3821/85 del Consejo (3), según proceda. 26.5.2016 L 139/2 Diar io Oficial de la Unión Europea ES    
(1)Reglamento (UE) no 1285/2013 del Parlament o Europeo y del Consejo, de 11 de diciembre de 2013, relativo al establecimient o y la 
explotación de los sistem as europeos de radionaveg ación por satélit e y por el que se derogan el Reglamento (CE) no 876/2002 del 
Consejo y el Reglament o (CE) no 683/2008 del Parlamento Europeo y del Consejo (DO L 347 de 20.12.2013, p. 1). 
(2)Reglamento (CE) no 68/2009 de la Comisión, de 23 de enero de 2009, por el que se adapta por novena vez al progreso técni co el 
Reglamento (CEE) no 3821/85 del Consejo relativo al aparato de control en el secto r de los transpor tes por carretera (DO L 339 de 
24.1.2009, p. 3). 
(3)Reglamento (CEE) no 3821/85 del Consejo, de 20 de diciembre de 1985, relativo al aparato de control en el secto r de los transpor tes por 
carretera (DO L 370 de 31.12.1985, p. 8). 
4. De conf ormidad con el artículo 10 quinquies de la Directiva 96/53/CE del Parlamento Europeo y del Consejo, el 
dispositivo de teledet ección temprana transmitirá asimismo los datos sobre peso facilitados por un sistema de pesaje a 
bordo, con miras a la pronta detección de fraudes. 
Articulo 2 
Def iniciones 
A efectos del present e Reglamento, serán de aplicación las definicione s establecidas en el artículo 2 del Reglamento (UE) 
n.o 165/2014. 
Asimismo, se entenderá por:  
1) «tacógraf o digital» o «tacógraf o de primera generación»: un tacógraf o digital distinto de un tacógraf o inteli gent e;  
2) «dispositivo GNSS extern o»: la instalación que contiene el recep tor GNSS cuando la unidad instalada en el vehículo 
no sea una unidad única, así como otros compo nentes necesar ios para proteg er la comunicación de los datos de 
posición al resto de la unidad instalada en el vehículo;  
3) «expediente del fabricante»: la documentación compl eta, en formato electrónico o en papel, que contiene toda la 
información facilitada por el fabricante o su agente a la autor idad de homologació n a efectos de la homologación de 
un tacógraf o o de uno de sus compo nentes , incluidos los certificad os a que se refiere el artículo 12, apar tado 3, del 
Reglamento (UE) n.o 165/2014, los resultados de los ensa yos definidos en el anex o 1C del present e Reglamento, así 
como dibujos, fotografías y demás documentos pertinentes;  
4) «expediente de homolog ación»: el expediente del fabricante, en formato electrónico o en papel, acompa ñado de los 
demás documentos añadidos por la autor idad de homologación a dicho expediente durante el desempeño de sus 
funciones, incluido, al finalizar el proceso de homolog ación, el certificado de homolog ación de tipo CE del tacógraf o 
o de uno de sus compo nentes;  
5) «índice del expediente de homologación»: el documento que indica el cont enido numerado del expedient e de 
homologació n, identif icando todas sus partes pertinentes ; el format o de dicho documento distinguirá las sucesivas 
etapas del proceso de homolog ació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 selectiv os en carretera;  
7) «tacógraf o intelig ente» o «tacógraf o de segunda generación»: un tacógraf o digital que cumple lo dispuesto en los 
artículos 8, 9 y 10 del Reglamento (UE) n.o 165/2014, así como en el anex o 1C del present e Reglamento;  
8) «compon ente del tacógraf o» o «com ponente»: cualquiera de los elementos siguient es: la unidad instalada en el 
vehículo, el sensor de movimient o, la tarjeta de tacógraf o, la hoja de registro, el dispositivo GNSS externo y el 
dispositivo de teledet ección temprana;  
9) «autoridad de homologació n»: la autoridad de un Estado miembro compet ente para llevar a cabo la homologació n 
del tacógraf o o de sus compo nentes , el proceso de autori zación, la expedición y, en su caso, la retirada de los 
certificados de homologa ción, actuando como punt o de contacto con las autori dades de homologació n de los demás 
Estados miembros y asegurándose de que los fabr icante s cumplen sus oblig aciones relativas a la conf ormidad con los 
requisitos del present e Reglamento. 
Articulo 3 
Servicios basados en la localización 
1. Los fabricantes velarán por que los tacógraf os inteligent es sean compatibles con los servicios de localización 
prestados por Galileo y por el sistema europeo de navegación por complement o geoestacionari o (EGNOS). 
2. Además de los sistemas a que se refiere el apar tado 1, los fabr icantes podrán también optar por garantizar la 
compati bilidad con otros sistema s de naveg ación por satélit e. 26.5.2016 L 139/3 Diar io Oficial de la Unión Europea ES    
Articulo 4 
Procedimiento de homologación de los tacóg rafos y de los componentes del tacóg rafo 
1. El fabricante o su mandatar io presentará la solicitud de homologación de un tacógraf o, o de alguno de sus 
compo nentes , o grupo de compo nentes, a las autoridades de homologación designadas por cada Estado miembro. La 
solicitud consistirá en un expediente del fabricante que conteng a la información sobre cada uno de los compo nent es en 
cuestión, así como, en su caso, los certificados de homolog ación de los demás compo nentes necesar ios para compl etar 
el tacógraf o, junto con cualquier otro document o pertinente. 
2. Un Estado miembro concederá la homologació n a todo tacógraf o, compo nente o grupo de compo nentes que se 
ajuste a los requisitos administrativ os y técnicos a que se refie re el artículo 1, apar tados 2 o 3, según proceda. En tal 
caso, la autori dad de homolog ación expedirá al solicitante un certificado de homologación que deberá ajustarse al 
modelo establecido en el anex o II del presente Reglamento. 
3. La autori dad de homologació n podrá solicitar al fabricante o a su mandatar io que facilite cualquier información 
adicional. 
4. El fabr icante o su mandatar io pondrá a disposición de las autori dades de homolog ación, así como de las entidades 
responsables de la expedición de los certificados mencionadas en el artículo 12, apar tado 3, del Reglamento (UE) 
n.o 165/2014, tantos tacógraf os o compo nente s del tacógraf o como sean necesar ios para poder llevar a cabo de forma 
satisf actor ia el procedimiento de homolog ación. 
5. Cuando el fabricante o su mandatar io solicite la homologa ción de determinados compo nentes o grupos de 
compo nentes de un tacógraf o, facilita rá a las autoridades de homolog ación los demás component es, ya homologad os, 
así como las demás piezas necesar ias para la constr ucción del tacógraf o compl eto, de manera que dichas autori dades 
puedan llevar a cabo los ensa yos necesar ios. 
Articulo 5 
Modif icación de las homologaciones 
1. El fabr icante o su mandatar io informarán sin demora a las autor idades de homologació n que concedieron la 
homologa ción original acerca de cualquier cambio que se introduzca en el software o el hardware del tacógraf o o en la 
naturaleza de los mat eriales empleados en su fabricación que figuran en el expedient e de homologació n y presentarán 
una solicitud de modificación de la homologació n. 
2. Las autor idades de homologación podrán revisar o extender una homologación existen te, o expedir una nueva, en 
función de la naturaleza y de las caracte rísticas de las modifi caciones. 
Se procederá a una «revisión» cuando la autor idad de homologación considere que las modifi caciones en el software o el 
hardware del tacógraf o o en la naturaleza de los mater iales empleados en su fabr icación son de poca impor tancia. En 
estos casos, la autori dad de homologación expedirá los documentos revisados del expediente de homologación, 
indicando la naturaleza de las modifi caciones 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 
descr ipción pormenor izada de las modificaciones. 
Se procederá a una «extensión» cuando la autoridad de homolog ación considere que las modifi caciones en el software o el 
hardware del tacógraf o o en la naturaleza de los mater iales empleados en su fabr icación son sustanciales. En estos casos, 
podrá solicitar que se lleven a cabo nuevos ensa yos, de lo cual informará al fabricante o a su mandatar io. Si estos 
ensa yos resultan satisf actorios , la autoridad de homologació n expedirá un certificado de homologació n revisado que 
conte ndrá un número que remitirá a la extensión concedida. El certificad o de homolog ació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 
homologa ción, o la fecha de la consolidación más reciente de la versión actualizada de la homologación. 26.5.2016 L 139/4 Diar io Oficial de la Unión Europea ES    
4. Será necesar ia una nueva homologació n cuando las modifi caciones solicitadas del tacógraf o homologad o o de sus 
compo nentes oblig arían a expedir un nuevo certificado de segur idad o de interoperabilidad. 
Articulo 6 
Entrada en vigor 
El present e Reglamento entrará en vigor a los veinte días de su publicación en el Diar io Oficial de la Unión Europea. 
Será aplicable a partir del 2 de marzo de 2016. 
Sin embargo, los anex os serán aplicables a partir del 2 de marzo de 2019, a exce pción del apéndice 16, que será 
aplicable a partir del 2 de marzo de 2016. 
El present e Reglamento será oblig ator io en todos sus elementos y directament e aplicable en 
cada Estado miembro. 
Hecho en Bruselas, el 18 de marzo de 2016. 
Por la Comisión 
El Presidente 
Jean-Claude JUNCKER  26.5.2016 L 139/5 Diar io Oficial de la Unión Europea ES    
ANEX O I C 
Condiciones de fabr icación, ensa yo, inst alación y control 
INTR ODUCCIÓN ............................................................................................................................................ 12 
1 DEFINICIONES ................................................................................................................ 13 
2 CARACTERÍSTIC AS GENERALES Y FUNCIONES DEL APARA TO DE CONTR OL ........................... 19 
2.1 Caracter ísticas generales ..................................................................................................... 19 
2.2 Funciones ....................................................................................................................... 20 
2.3 Modos de funcionamient o.................................................................................................. 21 
2.4 Segur idad ....................................................................................................................... 22 
3 CONDICI ONES DE FABRICA CIÓN Y FUNCIONAMIENTO DEL APARA TO DE CONTR OL ............... 22 
3.1 Control de la inserción y extracción de las tarjetas ................................................................... 22 
3.2 Medición de la velocidad, la posición y la distancia .................................................................. 23 
3.2.1 Medición de la distancia recor rida ........................................................................................ 23 
3.2.2 Medición de la velocidad .................................................................................................... 23 
3.2.3 Medición de la posición ..................................................................................................... 24 
3.3 Medición de la hora .......................................................................................................... 24 
3.4 Super visión de las actividades del conduct or........................................................................... 24 
3.5 Super visión del régimen de conducción ................................................................................. 25 
3.6 Entradas de los conduct ores ................................................................................................ 25 
3.6.1 Introducción de los lugares donde comienzan o terminan los períodos de traba jo diar ios ................. 25 
3.6.2 Introducción manual de las actividades del conduct or y del consentimiento del conductor a la interfaz 
ITS ................................................................................................................................ 25 
3.6.3 Entrada de condiciones específi cas ....................................................................................... 27 
3.7 Gestión de los bloqueos introducidos por la empresa ............................................................... 27 
3.8 Super visión de las actividades de control ............................................................................... 28 
3.9 Detección de incidentes o fallos ........................................................................................... 28 
3.9.1 Incident e «Inserción de una tarjeta no válida» .......................................................................... 28 
3.9.2 Incident e «Conf licto de tarjetas» ........................................................................................... 28 
3.9.3 Incident e «Solapamiento temporal» ....................................................................................... 28 
3.9.4 Incident e «Conducción sin tarjeta adecuada» ........................................................................... 29 
3.9.5 Incident e «Inserción de tarjeta durante la conducción» .............................................................. 29 
3.9.6 Incident e «Error al cerrar la última sesión de la tarjeta» ............................................................. 29 
3.9.7 Incident e «Exces o de velocidad» ........................................................................................... 29 
3.9.8 Incident e «Interrupción del suministro eléctr ico» ...................................................................... 29 
3.9.9 Incident e «Error de comunicación con el dispositivo de comunicación a distancia» .......................... 29 
3.9.10 Incident e «Ausenc ia de información sobre la posición procedente del recept or GNSS» ...................... 29 26.5.2016 L 139/6 Diar io Oficial de la Unión Europea ES    
3.9.11 Incident e «Error de comunicación con el dispositivo GNSS exte rno» ............................................ 30 
3.9.12 Incident e «Error de datos de movimient o».............................................................................. 30 
3.9.13 Incident e «Conf licto de movimiento del vehículo» .................................................................... 30 
3.9.14 Incident e «Intento de violación de la segur idad» ....................................................................... 30 
3.9.15 Incident e «Conf licto temporal» ............................................................................................ 30 
3.9.16 Fallo «Tarjeta» .................................................................................................................. 30 
3.9.17 Fallo «Aparato de control» .................................................................................................. 30 
3.10 Autodiagnóstico y comprobacio nes automáticas ...................................................................... 31 
3.11 Lectura de datos de la memor ia........................................................................................... 31 
3.12 Registro y almacenamient o de datos en la memor ia................................................................. 31 
3.12.1 Datos de identif icación de los equipos ................................................................................... 32 
3.12.1.1 Datos de identif icación de la unidad instalada en el vehículo ...................................................... 32 
3.12.1.2 Datos de identif icación del sensor de movimient o.................................................................... 32 
3.12.1.3 Datos de identif icación de los sistemas mundiales de navegaci ón por satélit e................................. 33 
3.12.2 Claves y certificados .......................................................................................................... 33 
3.12.3 Datos de inserción y extracción de la tarjeta de conduct or o de la tarjeta de taller ........................... 33 
3.12.4 Datos sobre la actividad del conductor .................................................................................. 34 
3.12.5 Lugares y posiciones donde comienzan o term inan los períodos de trabajo diar ios y/o donde se alcan ­
zan las tres horas de tiempo de conducción continua ............................................................... 34 
3.12.6 Datos del cuentakilómetros ................................................................................................ 35 
3.12.7 Datos pormenor izados sobre la velocidad .............................................................................. 35 
3.12.8 Datos sobre incidentes ....................................................................................................... 35 
3.12.9 Datos sobre fallos ............................................................................................................. 37 
3.12.10 Datos de calibrado ............................................................................................................ 38 
3.12.11 Datos de ajust e de la hora .................................................................................................. 39 
3.12.12 Datos sobre actividades de control ....................................................................................... 39 
3.12.13 Datos sobre los bloqueos introducidos por las empresas ........................................................... 39 
3.12.14 Datos sobre actividades de transfer encia ................................................................................ 39 
3.12.15 Datos sobre condiciones específi cas ...................................................................................... 40 
3.12.16 Datos de la tarjeta de tacógraf o........................................................................................... 40 
3.13 Lectura de las tarjetas de tacógraf o....................................................................................... 40 
3.14 Registro y almacenamient o de datos en las tarjetas de tacógraf o.................................................. 40 
3.14.1 Registro y almacenamient o de datos en las tarjetas de tacógraf o de primera generación .................... 40 
3.14.2 Registro y almacenamient o de datos en las tarjetas de tacógraf o de segunda generación ................... 41 
3.15 Visualización ................................................................................................................... 41 
3.15.1 Contenid o de la pantalla por defecto .................................................................................... 42 26.5.2016 L 139/7 Diar io Oficial de la Unión Europea ES    
3.15.2 Visualización de adver tencias .............................................................................................. 43 
3.15.3 Acceso mediante menús ..................................................................................................... 43 
3.15.4 Otras informaciones en pantalla .......................................................................................... 43 
3.16 Imp resión ....................................................................................................................... 43 
3.17 Advertencias ................................................................................................................... 44 
3.18 Transferencia de datos a medios externos ............................................................................... 45 
3.19 Comunicación a distancia para controles de carretera selectiv os.................................................. 45 
3.20 Envío de datos a dispositivo s externos adicionales ................................................................... 46 
3.21 Calibrado ....................................................................................................................... 47 
3.22 Control del calibrado en carretera ........................................................................................ 47 
3.23 Ajuste de la hora .............................................................................................................. 48 
3.24 Caracter ísticas de funcionamient o........................................................................................ 48 
3.25 Materiales ....................................................................................................................... 48 
3.26 Marcas ........................................................................................................................... 49 
4 CONDICI ONES DE FABRICA CIÓN Y FUNCIONAMIENTO DE LAS TARJET AS DE TACÓGRA FO ...... 49 
4.1 Datos visibles .................................................................................................................. 49 
4.2 Segur idad ....................................................................................................................... 52 
4.3 Nor mas .......................................................................................................................... 53 
4.4 Especifi caciones ambientales y eléctr icas ................................................................................ 53 
4.5 Almacenamiento de datos .................................................................................................. 53 
4.5.1 Archivos elementales para la identificación y la gestión de la tarjeta ............................................. 54 
4.5.2 Identif icación de la tarjeta CI.............................................................................................. 54 
4.5.2.1 Identif icación del chip ....................................................................................................... 54 
4.5.2.2 DIR (present e solo en las tarjetas de tacógraf o de segunda generación). ......................................... 54 
4.5.2.3 Información ATR (condicionalmente, present e solo en las tarjetas de tacógraf o de segunda genera ­
ción). ............................................................................................................................. 54 
4.5.2.4 Información de longitud extendida (condicionalmente, present e solo en las tarjetas de tacógraf o de se­
gunda generación). ........................................................................................................... 55 
4.5.3 Tarjeta de conduct or......................................................................................................... 55 
4.5.3.1 Aplicación del tacógraf o (accesible a las unidades instaladas en vehículos de primera y segunda genera ­
ción) ............................................................................................................................. 55 
4.5.3.1.1 Identif icación de la aplicación ............................................................................................. 55 
4.5.3.1.2 Clave y certificados ........................................................................................................... 55 
4.5.3.1.3 Identif icación de la tarjeta .................................................................................................. 55 
4.5.3.1.4 Identif icación del titular de la tarjeta ..................................................................................... 55 
4.5.3.1.5 Transferencia de los datos de la tarjeta .................................................................................. 55 
4.5.3.1.6 Información sobre el permiso de conducir ............................................................................. 55 
4.5.3.1.7 Datos sobre incidentes ....................................................................................................... 56 26.5.2016 L 139/8 Diar io Oficial de la Unión Europea ES    
4.5.3.1.8 Datos sobre fallos ............................................................................................................. 56 
4.5.3.1.9 Datos sobre la actividad del conductor .................................................................................. 57 
4.5.3.1.10 Datos sobre vehículos empleados ......................................................................................... 57 
4.5.3.1.11 Lugares donde comienzan o term inan los períodos de traba jo diar ios .......................................... 58 
4.5.3.1.12 Datos de la sesión ............................................................................................................ 58 
4.5.3.1.13 Datos sobre actividades de control ....................................................................................... 58 
4.5.3.1.14 Datos sobre condiciones específi cas ...................................................................................... 58 
4.5.3.2 Aplicación de tacógraf o de segunda generación (no accesible a la unidad instalada en el vehículo de 
primera generación) .......................................................................................................... 59 
4.5.3.2.1 Identif icación de la aplicación ............................................................................................. 59 
4.5.3.2.2 Claves y certificados .......................................................................................................... 59 
4.5.3.2.3 Identif icación de la tarjeta .................................................................................................. 59 
4.5.3.2.4 Identif icación del titular de la tarjeta ..................................................................................... 59 
4.5.3.2.5 Transferencia de los datos de la tarjeta .................................................................................. 59 
4.5.3.2.6 Información sobre el permiso de conducir ............................................................................. 59 
4.5.3.2.7 Datos sobre incidentes ....................................................................................................... 59 
4.5.3.2.8 Datos sobre fallos ............................................................................................................. 60 
4.5.3.2.9 Datos sobre la actividad del conductor .................................................................................. 61 
4.5.3.2.10 Datos sobre vehículos empleados ......................................................................................... 61 
4.5.3.2.11 Lugares y posiciones donde comienzan o term inan los períodos de traba jo diar ios.......................... 62 
4.5.3.2.12 Datos de la sesión ............................................................................................................ 62 
4.5.3.2.13 Datos sobre actividades de control ....................................................................................... 62 
4.5.3.2.14 Datos sobre condiciones específi cas ...................................................................................... 63 
4.5.3.2.15 Datos utilizados en unidades instaladas en vehículos ................................................................ 63 
4.5.3.2.16 Datos sobre lugares en tres horas de conducción continua ......................................................... 63 
4.5.4 Tarjeta de taller ................................................................................................................ 63 
4.5.4.1 Aplicación del tacógraf o (accesible a las unidades instaladas en vehículos de primera y segunda genera ­
ción) ............................................................................................................................. 63 
4.5.4.1.1 Identif icación de la aplicación ............................................................................................. 63 
4.5.4.1.2 Claves y certificados .......................................................................................................... 63 
4.5.4.1.3 Identif icación de la tarjeta .................................................................................................. 64 
4.5.4.1.4 Identif icación del titular de la tarjeta ..................................................................................... 64 
4.5.4.1.5 Transferencia de los datos de la tarjeta .................................................................................. 64 
4.5.4.1.6 Datos de calibrado y de ajuste de la hora ............................................................................... 64 26.5.2016 L 139/9 Diar io Oficial de la Unión Europea ES    
4.5.4.1.7 Datos de incidentes y fallos ................................................................................................ 65 
4.5.4.1.8 Datos sobre la actividad del conductor .................................................................................. 65 
4.5.4.1.9 Datos sobre vehículos empleados ......................................................................................... 65 
4.5.4.1.10 Datos sobre el comienzo y el final de los períodos de traba jo diar ios ........................................... 65 
4.5.4.1.11 Datos de la sesión ............................................................................................................ 65 
4.5.4.1.12 Datos sobre actividades de control ....................................................................................... 65 
4.5.4.1.13 Datos sobre condiciones específi cas ...................................................................................... 65 
4.5.4.2 Aplicación de tacógraf o de segunda generación (no accesible a la unidad instalada en el vehículo de 
primera generación) .......................................................................................................... 65 
4.5.4.2.1 Identif icación de la aplicación ............................................................................................. 65 
4.5.4.2.2 Claves y certificados .......................................................................................................... 66 
4.5.4.2.3 Identif icación de la tarjeta .................................................................................................. 66 
4.5.4.2.4 Identif icación del titular de la tarjeta ..................................................................................... 66 
4.5.4.2.5 Transferencia de los datos de la tarjeta .................................................................................. 66 
4.5.4.2.6 Datos de calibrado y de ajuste de la hora ............................................................................... 66 
4.5.4.2.7 Datos de incidentes y fallos ................................................................................................ 67 
4.5.4.2.8 Datos sobre la actividad del conductor .................................................................................. 67 
4.5.4.2.9 Datos sobre vehículos empleados ......................................................................................... 67 
4.5.4.2.10 Datos sobre el comienzo y el final de los períodos de traba jo diar ios ........................................... 67 
4.5.4.2.11 Datos de la sesión ............................................................................................................ 67 
4.5.4.2.12 Datos sobre actividades de control ....................................................................................... 67 
4.5.4.2.13 Datos utilizados en unidades instaladas en vehículos ................................................................ 67 
4.5.4.2.14 Datos sobre lugares en tres horas de conducción continua ......................................................... 68 
4.5.4.2.15 Datos sobre condiciones específi cas ...................................................................................... 68 
4.5.5 Tarjeta de control ............................................................................................................. 68 
4.5.5.1 Aplicación del tacógraf o (accesible a las unidades instaladas en vehículos de primera y segunda genera ­
ción) ............................................................................................................................. 68 
4.5.5.1.1 Identif icación de la aplicación ............................................................................................. 68 
4.5.5.1.2 Claves y certificados .......................................................................................................... 68 
4.5.5.1.3 Identif icación de la tarjeta .................................................................................................. 68 
4.5.5.1.4 Identif icación del titular de la tarjeta ..................................................................................... 68 
4.5.5.1.5 Datos sobre actividades de control ....................................................................................... 69 
4.5.5.2 Aplicación de tacógraf o G2 (no accesible para la unidad instalada en el vehículo de primera genera ­
ción) ............................................................................................................................. 69 
4.5.5.2.1 Identif icación de la aplicación ............................................................................................. 69 
4.5.5.2.2 Claves y certificados .......................................................................................................... 69 26.5.2016 L 139/10 Diar io Oficial de la Unión Europea ES    
4.5.5.2.3 Identif icación de la tarjeta .................................................................................................. 69 
4.5.5.2.4 Identif icación del titular de la tarjeta ..................................................................................... 69 
4.5.5.2.5 Datos sobre actividades de control ....................................................................................... 70 
4.5.6 Tarjeta de empresa ............................................................................................................ 70 
4.5.6.1 Aplicación del tacógraf o (accesible a las unidades instaladas en vehículos de primera y segunda genera ­
ción) ............................................................................................................................. 70 
4.5.6.1.1 Identif icación de la aplicación ............................................................................................. 70 
4.5.6.1.2 Claves y certificados .......................................................................................................... 70 
4.5.6.1.3 Identif icación de la tarjeta .................................................................................................. 70 
4.5.6.1.4 Identif icación del titular de la tarjeta ..................................................................................... 70 
4.5.6.1.5 Datos sobre la actividad de la empr esa .................................................................................. 70 
4.5.6.2 Aplicación de tacógraf o G2 (no accesible para la unidad instalada en el vehículo de primera genera ­
ción) ............................................................................................................................. 71 
4.5.6.2.1 Identif icación de la aplicación ............................................................................................. 71 
4.5.6.2.2 Claves y certificados .......................................................................................................... 71 
4.5.6.2.3 Identif icación de la tarjeta .................................................................................................. 71 
4.5.6.2.4 Identif icación del titular de la tarjeta ..................................................................................... 71 
4.5.6.2.5 Datos sobre la actividad de la empr esa .................................................................................. 71 
5 INST ALACIÓN DEL APARA TO DE CONTR OL ....................................................................... 72 
5.1 Instalación ...................................................................................................................... 72 
5.2 Placa de instalación ........................................................................................................... 73 
5.3 Precintos ........................................................................................................................ 74 
6 VERIFICA CIONES, CONTR OLES Y REPARA CIONES ................................................................ 74 
6.1 Autorización de instaladores, talleres y fabricante s de vehículos .................................................. 74 
6.2 Verificación de instr umentos nuevos o reparados .................................................................... 75 
6.3 Control de la instalación .................................................................................................... 75 
6.4 Controles periódicos ......................................................................................................... 75 
6.5 Determinación de errores ................................................................................................... 76 
6.6 Reparaciones ................................................................................................................... 76 
7 EXPEDICIÓN DE TARJET AS ............................................................................................... 76 
8 HOMOLOGA CIÓN DEL APARA TO DE CONTR OL Y DE LAS TARJET AS DE TACÓGRAFO .............. 77 
8.1 Generalidades .................................................................................................................. 77 
8.2 Certificad o de segur idad .................................................................................................... 78 
8.3 Certificad o funcional ......................................................................................................... 78 
8.4 Certificad o de interoperabilidad ........................................................................................... 78 
8.5 Certificad o de homolog ación .............................................................................................. 79 
8.6 Procedimient o de excep ción: primeros certificados de inter operabilidad para los aparat os de control y 
las tarjetas de tacógraf o de segunda generación ....................................................................... 80  26.5.2016 L 139/11 Diar io Oficial de la Unión Europea ES    
INTR ODUCCIÓN 
El sistema de tacógraf o digital de primera generación está desplegado desde el 1 de mayo de 2006. Podrá utilizarse hasta 
el final de su vida útil para el transpor te nacional. En el caso del transpor te internacional, sin embargo, 15 años después 
de la entrada en vigor del presente Reglamento de la Comisión todos los vehículos deberán estar equipados con el 
tacógraf o intelig ente de segunda generación conf orme que introduce el presente Reglamento. 
El present e anex o contiene las condiciones relativas a la segunda generación de aparatos de control y tarjetas de 
tacógraf o. A partir de su fecha de introducción, se instalará el aparat o de control de segunda generación en los vehículos 
matr iculados por vez primera, y se expedirán tarjetas de tacógraf o de segunda generación. 
Con el fin de fomentar una integración gradual del sistema de tacógraf o de segunda generación, 
—  las tarjetas de tacógraf o de segunda generación se diseñarán para ser también utilizadas en las unidades instaladas en 
vehículos de primera generación, 
—  no se exigirá la sustitución de las tarjetas de tacógraf o de primera generación válidas en la fecha de introducción. 
Esto permitirá a los conduct ores conser var una única tarjeta de conduct or y utilizar ambos sistemas con ella. 
Los aparatos de control de segunda generación, sin embargo, solo se calibrarán utilizando tarjetas de taller de segunda 
generación. 
El presente anex o contiene todos los requisit os relacionados con la inter operabilidad entre la primera y la segunda 
generación del sistema de tacógraf o. 
El apéndice 15 contiene más detalles sobre cómo gestionar la coexistencia de los dos sistem as. 
Lista de apéndices 
Apéndice 1: DICCIONARIO DE DATOS 
Apéndice 2: ESPECIFICA CIONES DE LAS TARJET AS DE TACÓGRAFO 
Apéndice 3: PICTOGRAMAS 
Apéndice 4: DOCUMENTOS IMPRESOS 
Apéndice 5: VISU ALIZA CIÓN 
Apéndice 6: CONECTOR FRONT AL PARA EL CAL IBRADO Y LA TRANSFERENCIA DE DATOS 
Apéndice 7: PROTOCOL OS DE TRANSFERENCIA DE DATOS 
Apéndice 8: PROTOCOL O DE CALIBRADO 
Apéndice 9: HOMOL OGA CIÓN Y LIST A DE PRUEBAS MÍNIMAS REQUERID AS 
Apéndice 10: REQUISITOS DE SEGURID AD 
Apéndice 11: MECANISMOS COMUNES DE SEGURID AD 
Apéndice 12: POSICIONAMIENTO BAS ADO EN EL SISTEMA MUNDIAL DE NAVEGA CIÓN POR SATÉLITE (GNSS) 
Apéndice 13: INTERF AZ ITS 
Apéndice 14: FUNCIÓN DE COMUNICA CIÓN A DIST ANCIA 
Apéndice 15: MIGRA CIÓN: GESTIÓN DE LA COEXISTENCIA DE LAS GENERA CIONES DE EQUIPOS 
Apéndice 16: ADAPT ADOR PARA VEHÍCUL OS DE LAS CATEGORÍAS M 1 Y N1  26.5.2016 L 139/12 Diar io Oficial de la Unión Europea ES    
1  DEFINICIONES 
A los efectos del present e anex o, se aplicarán las siguientes definiciones: 
a)  Activación: 
Fase en que el tacógraf o pasa a ser totalme nte operativo y realiza todas sus funciones, incluidas las de 
segur idad, mediante el uso de una tarjeta de taller . 
b)  Auten ticación: 
Función con la que se establece y verifica una identidad. 
c)  Auten ticidad: 
Propiedad de que una información proceda de alguien cuya identidad pueda verificarse. 
d)  Autodi agnóstico (BIT): 
Ensa yo que se lleva a cabo a petición del operar io o por orden de un equipo externo. 
e)  Día civil: 
Día compre ndido entre las 00.00 y las 24.00 horas. Todos los días se referirán al tiempo universal 
coordinado (UTC). 
f)  Calibrado (de un tacógraf o digital inteli gent e): 
Actualización o conf irmación de los parámetros del vehículo que han de guardarse en la memor ia de 
datos. Los parámetros del vehículo incluyen la identif icación del vehículo (VIN, VRN y el Estado 
miembro donde se matr iculó el vehículo) y las caracte rísticas del vehículo (w, k, l, tamaño de los 
neumáticos, valor de ajuste del dispositivo limitador de la velocidad, en su caso, hora UTC actual, 
lectura actual del cuentakilómetros); durante el calibrado de un aparat o de control, los tipos y los 
identificadores de todos los precintos pertinentes de la homologación también se almacenarán en la 
memor ia de datos. 
Toda actualización o confir mación únicamente de la hora UTC se considerará un ajuste de la hora y 
no un calibrado, siempre que no contrav enga el requisit o 409. 
Para calibr ar un apar ato de control se precisa una tarjeta de taller . 
g)  Número de tarjeta: 
Secuencia de 16 caracteres alfanumér icos que identifica una tarjeta de tacógraf o en un Estado 
miembro. El número de tarjeta incluye un índice consecutivo de la tarjeta (en su caso), un índice de 
sustitución de la tarjeta y un índice de reno vación de la tarjeta. 
Por consiguiente, cada tarjeta se identif ica de manera única con el código del Estado miembro que la 
expide y con el número de la propia tarjeta. 
h)  Índice consecutivo de la tarjeta: 
Decimocuar to carácter alfanumér ico del número de la tarjeta. Este carácte r sirve para diferenciar las 
distintas tarjetas asignadas a una empr esa, a un taller o a una autor idad de control con derecho a 
utilizar varias tarjetas de tacógraf o. La empresa, el taller o la autor idad de control se identif ican con 
los trece primeros caract eres del número de la tarjeta. 
i)  Índice de reno vación de la tarjeta: 
Decimosext o carácter alfanumér ico del número de la tarjeta. Este carácte r se incrementa en una 
unidad cada vez que se renueva la tarjeta de tacógraf o. 
j)  Índice de sustitución de la tarjeta: 
Decimoquinto carácter alfanumér ico del número de la tarjeta. Este carácter se incrementa en una 
unidad cada vez que se sustituye la tarjeta de tacógraf o. 26.5.2016 L 139/13 Diar io Oficial de la Unión Europea ES    
k)  Coeficiente caract erístico del vehículo: 
Caract erística numér ica 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 aparat o de control (toma de salida de la caja de cambio en algunos 
casos, rueda del vehículo en otros casos), cuando el vehículo recor re la distancia de un kilómetro, 
medida en condiciones normales de ensa yo, según se definen en el requisito 414. El coefi cient e 
caract erístico se expresa en imp ulsos por kilómetro (w = … imp/km). 
l)  Tarjeta de empr esa: 
Tarjeta de tacógraf o expedida por las autor idades de un Estado miembro a favor de una empresa de 
transpor te que necesita utilizar vehículos equipados de tacógraf o, que identif ica a dicha empr esa de 
transpor te y permite visualizar , transferir e imprimir los datos almacenados en los tacógraf os y 
bloqueados por tal empresa. 
m)  Constant e del aparato de control: 
Caract erística numér ica que da el valor de la señal de entrada necesar ia para obtener la indicación y el 
registro de una distancia recor rida de un kilómetro; dicha constante deberá expresarse en impulsos 
por kilómetro (k = … imp/km). 
n)  Tiem po 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 term ina su último período 
de DISPONIBILID AD o PAUSA /DESCA NSO o INDETERMINADO (2) de 45 minut os 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 anteriores que han 
quedado registradas en la tarjeta de conductor . Si el conduct or no ha inser tado su tarjeta, los cálculos 
se basan en los registros de la memor ia de datos correspondientes al período actual en que no hubo 
tarjeta inser tada y a la ranura que corresponda. 
o)  Tarjeta de control: 
Tarjeta de tacógraf o expedida por las autori dades de un Estado miembro a una autori dad nacional de 
control compe tent e, que identif ica a este organismo y, de manera opcional, también al controlador , y 
que permite acceder a la información almacenada en la memor ia de datos o en las tarjetas de 
conduct or y, de manera opcional, en las tarjetas de taller con fines de lectura, impresión y/o transfe ­
rencia de datos. 
Asimismo, dará acceso a la función de control de calibrado en la carretera y a los datos conteni dos en 
el lector de comunicaciones de teledet ección temprana. 
p)  Tiem po de descanso acumulado (contabilizado por el aparat o de control) (1): 
El tiempo de descanso de la conducción acumulado, refer ido a un conductor en particular , se calcula a 
partir de los períodos acumulados actuales de DISPONIBILID AD, PAUSA /DESCA NSO o INDETER ­
MINADOS (2) de 15 minutos o más, contados desde el momento en que term inara su último período 
de DISPONIBILID AD o PAUSA /DESCA NSO o INDETERMINADO (2) de 45 minut os 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 conduct or. Los cálculos no incluy en los períodos indet erminados que tengan una 
duración negat iva (comienzo del período indet erminado > final del período indet erminado) a 
consecuencia de un solapamient o temporal entre dos aparat os de control distintos. 
Si el conduct or no ha inser tado su tarjeta, los cálculos se basan en los registros de la memor ia de 
datos correspondientes al período actual en que no hubo tarjeta inser tada y a la ranura que 
corresponda. 26.5.2016 L 139/14 Diar io Oficial de la Unión Europea ES    
(1)Este modo de calcular el tiempo de conducción continua y el tiemp o 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 
tiemp os. Podrán utilizarse métodos alter nativos para calcular el tiempo de conducción continua y el tiemp o de descanso acumulado a fin 
de reemplazar estas defin iciones si quedan obsoletas a raíz de las actualizaciones introducidas en otra legislación pertinente. 
(2)Los períodos INDETERMINADOS son aquellos en que la tarjeta de conducto r no está inser tada en el aparato de control y tampoco se 
introducen manualment e las actividades del conducto r. 
(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 transpor tes por carretera y por el que se modifican los Reglament os (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). 
q)  Memor ia de datos: 
Dispositivo de almacenamient o electrónico incor porado en el aparat o de control. 
r)  Firma digital: 
Datos adjuntos a un bloque de datos, o una transf ormación criptográfi ca de ellos, que permiten al 
destinatar io compr obar la autenticidad e integridad de dicho bloque. 
s)  Transf erencia: 
Copia, junto con la firma digital, de una parte o de la totalidad de un conjunt o de ficheros de datos 
almacenados en la memor ia de datos de la unidad instalada en el vehículo o en la memor ia de una 
tarjeta de tacógraf o, siempre que este proceso no altere ni supr ima ninguno de los datos almacenados. 
Los fabricantes de tacógraf os inteli gent es instalados en el vehículo y los fabricantes de aparat os 
diseñados y concebidos para transferi r ficheros de datos adoptarán todas las medidas necesar ias para 
garantizar que los conduct ores o las empr esas de transpor te puedan transfe rir dichos datos en el 
menor tiempo posible. 
La transfer encia del fichero compl eto de datos sobre la velocidad del vehículo puede no ser necesar ia 
para deter minar el cumplimient o del Reglamento (CE) n.o 561/2006, aunque sí podrá utilizarse para 
otros fines, tales como la investigación de accident es. 
t)  Tarjeta de conduct or: 
Tarjeta de tacógraf o expedida por las autori dades de un Estado miembro a un conductor concreto, 
que identifica a este último y permite almacenar los datos de su actividad. 
u)  Circunf erencia efectiva de las ruedas: 
Media de las distancias recor ridas por cada una de las ruedas que arrastran el vehículo (ruedas 
motr ices) al realizar una rotación compl eta. La medida de dichas distancias se efectuará en 
condiciones normales de ensa yo, 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 repar to 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 autori dad compet ente del Estado miembro y solo podrán tener lugar antes de la activación del 
tacógraf o. 
v)  Incident e: 
Operación anor mal detectada por el tacógraf o inteligent e que puede deberse a un intent o de fraude. 
w)  Dispositivo GNSS extern o: 
Instalación que contiene el recep tor GNSS cuando la unidad instalada en el vehículo no es un módulo 
único, así como otros compo nente s necesar ios para prote ger la comunicación de los datos de 
posición al resto de la unidad instalada en el vehículo. 
x)  Fallo: 
Operación anor mal detectada por el tacógraf o intelig ente y que puede deberse a un fallo de funciona ­
mient o. 
y)  Recep tor GNSS: 
Dispositivo electrónico que recibe y procesa digitalmente las señales digitales de uno o más sistemas 
mundiales de naveg ación por satélite (GNSS por sus siglas en inglés) con el fin de proporcionar 
información de posición, velocidad y hora. 
z)  Instalación: 
Monta je de un tacógraf o en un vehículo. 26.5.2016 L 139/15 Diar io Oficial de la Unión Europea ES    
(1)Reglamento (UE) n.o 1230/2012 de la Comisión, de 12 de diciembre de 2012, por el que se desar rolla 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 dimensiones de 
los vehículos de motor y de sus remolques y por el que se modifica la Directiva 2007/46/CE del Parlament o Europeo y del Consejo (DO L 
353 de 21.12.2012, p. 31), en su versión modificad a en último lugar . 
aa)  Interoperabilidad: 
Capacidad de los sistemas y de los procesos suby acentes para intercambiar datos y compar tir 
información. 
bb)  Interfaz: 
Dispositivo entre sistemas que facilita los medios de comunicación a través de los cuales pueden 
conectarse y actuar entre sí. 
cc)  Posición: 
Coordenadas geográfi cas del vehículo en un momento dado. 
dd)  Sensor de movimiento: 
Parte del tacógraf o que ofrece una señal representativa de la velocidad del vehículo y/o de la distancia 
recor rida. 
ee)  Tarjeta no válida: 
Tarjeta en la que se ha detectado un defect o, o que no ha superado la aute nticación inicial, o que no 
ha alcanzado toda vía la fecha de comienzo de validez, o que ha sobrepasado ya la fecha de expiración. 
ff)  Nor ma abier ta: 
Nor ma que figur a en un documento de especificación de normas que está disponible sin contrapar tida 
financiera o por una contrapar tida simbólica, que cualquier persona puede copiar , distr ibuir o utilizar 
gratuitamente o por un precio simbólico. 
gg)  Fuera de ámbito: 
Cuando el uso del aparat o de control no es obligat orio, de conf ormidad con lo dispuest o en el 
Reglamento (CE) n.o 561/2006. 
hh)  Exceso de velocidad: 
Rebasamient o de la velocidad autori zada para el vehículo, definido como un período de más de 
sesenta segundos durant e 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 modif icada en último lugar . 
ii)  Control periódico: 
Conjunt o de operaciones con las que se comprueba que el tacógraf o funciona correctamente, que sus 
valores de ajus te corresponden a los parámetros del vehículo y que no hay dispositivo s de 
manipulación integrad os en el tacógraf o. 
jj)  Impresora: 
Com ponente del aparat o de control que permite imprimir los datos almacenados. 
kk)  Comunicación de teledetección temprana: 
Comunicación entre el dispositivo de comunicación de teledetección temprana y el lector de 
comunicación de teledetección temprana durante los controles de carretera selectivos encaminados a 
detectar una posible manipulación o utilización indebida del aparat o de control. 
ll)  Dispositivo de comunicación a distancia: 
Equipo de la unidad instalada en el vehículo que se utiliza para realizar controles de carretera 
selectiv os. 26.5.2016 L 139/16 Diar io Oficial de la Unión Europea ES    
(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). 
mm)  Lect or de comunicación de teledet ección temprana: 
El sistema utilizado por los controladores para los controles de carretera selectiv os. 
nn)  Reno vación: 
Asignación de una nueva tarjeta de tacógraf o cuando la tarjeta existen te alcanza su fecha de 
expiración o se ha devuelto a la autoridad emisora por un fallo de funcionamient o. La reno vación 
implica siempre la certeza de que no coexistirán dos tarjetas válidas. 
oo)  Reparación: 
Cualquier reparación de un sensor de movimient o 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 
compo nent es del tacógraf o, o la aper tura del sensor de movimient o o de la unidad instalada en el 
vehículo. 
pp)  Sustitución de la tarjeta: 
Emisión de una tarjeta de tacógraf o en sustitución de una tarjeta existen te que se haya declarado 
perdida, robada o defe ctuosa y que no se haya devuelto a la autoridad expedidora. La sustitución 
implica siempre el riesgo de que coexistan dos tarjetas válidas. 
qq)  Certificación de segur idad: 
Procedimient o por el que un organismo de certificación de Criterios Comunes garantiza que el 
aparat o de control (o compo nent e) o la tarjeta de tacógraf o que se investig a cumple los requisitos de 
segur idad definidos en los correspondientes perf iles de prote cción. 
rr)  Com probación automática: 
Com probaciones que realiza de manera cíclica y automá tica el aparato de control para detec tar 
posibles fallos. 
ss)  Medición de la hora: 
Registro digital permanent e de la fecha y la hora del tiempo universal coordinado (UTC). 
tt)  Ajust e de la hora: 
Ajust e automá tico de la hora actual a intervalos regulares y con un máximo de tolerancia de un 
minut o, o un ajuste efectuado durante el calibrado. 
uu)  Tamaño de los neumáticos: 
Designación de las dimensiones de los neumáticos (ruedas motr ices 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 identif ican el vehículo: número de matrícula (VRN), con indicación del Estado miembro 
donde está matr iculado, y número de identif icación (VIN) (2). 
ww)  Semana (a efectos de cálculo en el aparat o 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. 26.5.2016 L 139/17 Diar io Oficial de la Unión Europea ES    
(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 monta je (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 apro ximación de las legislaciones de los Estados Miembros 
sobre las placas e inscr ipciones reglamentar ias, así como a su emplazamient o 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). 
xx)  Tarjeta de taller: 
Tarjeta de tacógraf o expedida por las autor idades de un Estado miembro a personal designado de un 
fabricante o instalador de tacógraf os, fabr icante de vehículos o taller aprobado por dicho Estado 
miembro, que identif ica a su titular y le permite el ensa yo, calibrado y activación de tacógraf os y/o la 
transfe rencia de datos de estos. 
yy)  Adaptador: 
Dispositivo que proporciona una señal en todo momento representativa de la velocidad del vehículo o 
la distancia recor rida, excep to el utilizado para la detección de movimient o independiente , y que: 
—  se instala y utiliza excl usivamente en vehículos de las cate gorías M1 y N1 (según se definen en el 
anex o II de la Directiva 2007/46/CEE del Parlamento Europeo y del Consejo (1), en su versión 
modifi cada más reciente) puestos en servicio a partir del 1 de mayo de 2006; 
—  se instala cuando mecánicamente resulta imp osible instalar ningún otro tipo de sensor de 
movimient o existen te que por su parte cumpla las disposiciones de este anex o y sus apéndices 1 a 
15; 
—  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 integra dos o interfaces alternativas; 
—  desde la perspectiva de la unidad instalada en el vehículo, el compo rtamiento del adaptador es el 
mismo que se obtendr ía conectando a la unidad instalada en el vehículo un sensor de movimiento 
conf orme a las disposiciones del present e anex o y sus apéndices 1 a 16. 
El uso de este tipo de adap tador en los vehículos indicados anter iormente permitirá la instalación y la 
utilización correcta de una unidad instalada en el vehículo conf orme a todos los requisit os del 
present e anex o. 
En lo que respecta a esos vehículos, el tacógraf o inteli gent e incluye los cables, un adap tador 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 integrid ad implica que los datos son copia exacta 
de la versión original, por ejemplo, que no han sido corrompidos en el proceso de su escr itura o 
lectura en una tarjeta de tacógraf o o un equipo dedicado o durant e la transmisión a través de un canal 
de comunicaciones. 
aaa)  Privacidad de los datos: 
Conjunt o de las medidas técn icas adopt adas para garantizar la adecuada aplicación de los principios 
establecidos en la Directiva 95/46/CE del Parlamento Europeo y del Consejo (2), así como de los 
establecidos en la Directiva 2002/58/CE del Parlament o Europeo y del Consejo (3). 
bbb)  Siste ma de tacógraf o inteligent e: 
Los aparat os de control, las tarjetas de tacógraf o y el conjunt o de todos los equipos que interactúan, 
directa o indirectament e, durante su fabr icación, instalación, utilización, ensa yo y control, 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 segur idad, etc. 
ccc)  Fech a de introducción: 
Treinta y seis meses después de la entrada en vigor de las disposiciones específicas indicadas en el 
artículo 11 del Reglamento (UE) n.o 165/2014 del Parlamento Europeo y del Consejo (4). 26.5.2016 L 139/18 Diar io Oficial de la Unión Europea ES    
(1)Directtiva 2007/46/CE del Parlament o Europeo y del Consejo, de 5 de septiembre de 2007, por la que se crea un marco para la 
homolog ación de los vehículos de motor y de los remolques, sistemas, component es y unidades técnicas independientes destinados a 
dichos vehículos (Directiva marco) (DO L 263 de 9.10.2007, p. 1). 
(2)Directiva 95/46/CE del Parlamento Europeo y del Consejo, de 24 de octubre de 1995, relativa a la prot ección de las personas físicas en lo 
que respecta al tratamiento de datos personales y a la libre circulación de estos datos (DO L 281 de 23.11.1995, p. 31) 
(3)Directiva 2002/58/CE del Parlamento Europeo y del Consejo, de 12 de julio de 2002, relativa al tratamiento de los datos personales y a la 
prot ección de la intimidad en el sector de las comunicaciones electrónicas (Directiva sobre la privacidad y las comunicaciones 
electrónicas) (DO L 201 de 31.7.2002, p. 37). 
(4)Reglamento (UE) n.o 165/2014 del Parlament o Europeo y del Consejo, de 4 de febrero de 2014, relativo a los tacógraf os en el transpor te 
por carretera, por el que se deroga el Reglament o (CEE) n.o 3821/85 del Consejo relativo al aparato de control en el sector de los 
transpor tes por carretera y se modifica el Reglamento (CE) n.o 561/2006 del Parlament o Europeo y del Consejo relativo a la 
armonización de determinadas disposiciones en materia social en el sector de los transpor tes por carretera (DO L 60 de 28.2.2014, p. 1). 
Esta es la fecha a partir de la cual los vehículos matr iculados por primer a vez: 
—  estar án dotados de un tacóg rafo conectado a un servicio de posicionamiento basado en un sistema de 
naveg ación por satélite; 
—  podr án comunicar datos para contro les de carreter a selectiv os a las autor idades de contro l competentes 
mientr as el vehículo está en movimiento; 
—  y podr án ir equipados de interfaces normalizadas que permitan que un dispositivo exter no utilice en modo 
operativo los datos registrados o producidos por el tacóg rafo. 
ddd)  Perfil de prot ección: 
Document o utilizado como parte del proceso de certificación según Criterios Comunes, que facilita 
una especificación independient e de la implementación de los requisitos de segur idad de asegura ­
mient o de la información. 
eee)  Exactitud del GNSS: 
En el context o del registro de la posición a partir del sistema mundial de naveg ación por satélite 
(GNSS) con tacógraf os, el valor de la dilución horizontal de la precisión (HDOP), calculado como el 
mínimo de los valores de HDOP recogidos en los sistemas GNSS disponibles. 
2  CARA CTERÍSTICAS GENERALES Y FUNCIONES DEL APARA TO DE CONTR OL 
2.1  Caracterís ticas generales 
El aparat o de control sirve para registrar , almacenar , visualizar , imprimir y enviar datos relacionados con las 
actividades del conduct or. 
Todo vehículo que lleve instalado un aparato de control conf orme a lo dispuesto en el presente anex o debe 
incor porar además un indicador de velocidad y un cuentakilómetros. Estas funciones pueden estar incluidas 
en el aparato de control. 
01)  El aparat o de control incluy e cables, un sensor de movimient o 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 requisit os especifi cados en el apéndice 11. 
03)  La unidad instalada en el vehículo deberá estar conectada a uno o más sistemas mundiales de 
naveg ación por satélit e, tal como se especifi ca en el apéndice 12. 
04) La unidad instalada en el vehículo deberá comunicar con los lectores de comunicación de telede ­
tección temprana, tal como se especifica en el apéndice 14. 
05)  La unidad instalada en el vehículo podrá incluir una interf az ITS, que se especifi ca en el apéndice 13. 
El aparato de control podrá estar conectado a otros dispositivo s mediante interface s adicionales y/o a 
través de la interfaz ITS opcional. 
06)  Ninguna función o dispositivo , homologad o o no, que se incluya o se conecte al aparato de control 
deberá interferir ni ser capaz de interfer ir con el funcionamient o correcto y seguro del aparat o de 
control ni con lo dispuesto en el presente Reglamento. 
Los usuar ios del aparat o de control se identifican ante el aparato a través de las tarjetas de tacógraf o. 
07)  El aparat o de control proporciona derechos de acceso selectiv o a los datos y funciones según el tipo 
o la identidad del usuar io. 26.5.2016 L 139/19 Diar io Oficial de la Unión Europea ES    
El aparat o de control registra y almacena datos en su memor ia, en el dispositivo de comunicación a 
distancia y en las tarjetas de tacógraf o. 
Esto se efectúa con arreglo a la Directiva 95/46/CE, de 24 de octubre de 1995, relativa a la prot ección de 
las personas físicas en lo que respecta al tratamient o de datos personales y a la libre circulación de estos 
datos (1), con la Directiva 2002/58/CE, de 12 de julio de 2002, relativa al tratamient o de los datos 
personales y a la protección de la intimidad en el sector de las comunicaciones electrónicas (2), y de 
conf ormidad con el artículo 7 del Reglamento (UE) n.o 165/2014. 
2.2  Funciones 
08)  El aparat o de control deberá garantizar las funciones siguient es: 
—  control de la inserción y extracción de las tarjetas, 
—  medición de la velocidad, distancia y posición, 
—  medición de la hora, 
—  super visión de las actividades del conduct or, 
—  super visión del régimen de conducción, 
—  entradas manuales de los conductores: 
—  entrada de los lugares donde comienzan o term inan los períodos de traba jo diar ios, 
—  entrada manual de las actividades del conductor , 
—  entrada de condiciones específicas, 
—  gestión de los bloqueos introducidos por la empr esa, 
—  super visión de las actividades de control, 
—  detección de incidentes o fallos, 
—  autodiag nóstico y comprobacio nes automáticas, 
—  lectura de los datos almacenados en la memor ia, 
—  registro y almacenamient o de datos en la memor ia, 
—  lectura de las tarjetas de tacógraf o, 
—  registro y almacenamient o de datos en las tarjetas de tacógraf o, 
—  visualización, 
—  impresión, 
—  adver tencias, 
—  transfer encia de datos a medios extern os, 
—  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. 26.5.2016 L 139/20 Diar io Oficial de la Unión Europea ES    
(1)DO L 281 de 23.11.1995, p. 31. 
(2)DO L 201 de 31.7.2002, p. 37. 
2.3  Modos de funcionamient o 
09)  El aparat o de control deberá tener cuatro modos de funcionamient o: 
—  modo operativo, 
—  modo de control, 
—  modo de calibrado, 
—  modo de empresa. 
10)  El aparato de control pasará al siguient e modo de funcionamiento según las tarjetas de tacógraf o 
válidas que se inser ten en los dispositivos de interfaz: A efectos de deter minar el modo de funciona ­
miento, es irrelevante la generación de la tarjeta de tacógraf o, siempr e que la tarjeta inser tada sea 
válida. Una tarjeta de taller de primera generación se considerará siempre no válida cuando se inser te 
en una unidad instalada en el vehículo de segunda generación. 
Modo de funcionamiento Ranura del conducto r 
Sin tarjeta Tarjeta de 
conductor Tarjeta de control Tarjeta de taller Tarjeta de empresa Ranura del segundo conductor Sin tarjeta operativo operativo de control de calibrado de empresa 
Tarjeta de con­
ductor operativo operativo de control de calibrado de empresa 
Tarjeta de con­
trol de control de control de control (*) operativo operativo 
Tarjeta de taller de calibrado de calibrado operativo de calibrado (*) operativo 
Tarjeta de em­
presa de empresa de empresa operativo operativo de empresa (*) 
(*)  En estas situaciones, el aparato de control utilizará excl usivamente la tarjeta de tacógraf o inser tada en la ranura del conductor .  
11)  El aparat o de control no tendrá en cuenta las tarjetas no válidas que se inser ten, excep to si se 
visualizan, imprimen o transf ieren los datos almacenados en una tarjeta que ha expirado, cosa que 
deberá ser posible. 
12) Todas las funciones enumeradas en el apar tado 2.2 estarán disponibles en cualquier modo de funcio ­
namiento, con las siguient es exce pciones: 
—  la función de calibrado solo está disponible en el modo de calibrado, 
—  la función de control del calibrado en carretera solo está disponible en el modo de control, 
—  la función de gestión de los bloqueos introducidos por la empresa solo está disponible en el 
modo de empresa, 
—  la función de super visión de las actividades de control solo funciona en el modo de control, 
—  la función de transfer encia no está disponible en el modo operativo (salvo en el caso indicado en 
el requisit o 193), excep tuada la descarga de datos de una tarjeta de conductor si no hay otro tipo 
de tarjeta inser tada en la VU. 
13)  El aparat o de control podrá enviar cualquier dato a la pantalla, a la impresora o a interf aces extern as, 
con las siguientes excepciones: 
—  en el modo operativo , toda identificación personal (nombre y apellidos) que no corresponda a 
una tarjeta de tacógraf o inser tada se borrará por compl eto, y todo número de tarjeta que no 
corresponda a una tarjeta de tacógraf o inser tada se borrará parcialmente (se borrarán los 
caracte res impares, de izquierda a derecha); 26.5.2016 L 139/21 Diar io Oficial de la Unión Europea ES    
—  en el modo de empr esa, los datos relativos al conduct or (requisitos 102, 105 y 108) tan solo 
podrán enviarse a dispositivos extern os durante los períodos exen tos de bloqueo o que no haya 
bloqueado otra empr esa (identifi cada por los 13 primeros dígitos del número de la tarjeta de 
empr esa); 
—  si no se ha inser tado ninguna tarjeta en el aparat o de control, solo podrán enviarse los datos 
relativ os al conduct or que correspondan al día actual y a los ocho días civiles anteriores; 
—  los datos personales procedent es de la VU no podrán enviarse a través de la interfa z ITS de la VU 
a menos que se haya verificado el consentimiento del conductor al que se refieran los datos; 
—  el período de validez operativa normal de las unidades instaladas en vehículos es de quince años a 
partir de la fecha de expedición de los certificados de dichas unidades, pero podrán utilizarse 
durante tres meses adicionales solo para la transfer encia de datos. 
2.4  Segur idad 
La segur idad del sistem a tiene por objeto prot eger la memor ia de datos, de manera que se evite el acceso a 
la misma de terceros no autori zados, se excl uya la manipulación de información y se detecte cualquier 
tentativa en ese sentido; así se proteg e la integrid ad y aute nticidad de los datos intercambiados entre el 
sensor de movimiento y la unidad instalada en el vehículo, de los datos intercambiados entre el aparat o de 
control y las tarjetas de tacógraf o y de los datos inter cambiados entre el aparat o de control y el dispositivo 
GNSS externo , se proteg e la confidencialidad, integridad y aute nticidad de los datos inter cambiados a través 
de la comunicación de teledetección temprana con fines de control y se verifica la integridad y autenti cidad 
de los datos transferi dos. 
14)  Al objeto de lograr la segur idad del sistema, los siguient es component es deberán cumplir los 
requisitos de segur idad que se definen en sus perfiles de prot ección, según exige el apéndice 10: 
—  unidad instalada en el vehículo, 
—  tarjeta de tacógraf o, 
—  sensor de movimient o, 
—  dispositivo GNSS exte rno (este perf il solo es necesar io y aplicable para la variante del GNSS 
externo). 
3  CON DICIONES DE FABRICA CIÓN Y FUNCIONAMIENTO DEL APARA TO DE CONTR OL 
3.1  Control de la inserción y extracción de las tarjetas 
15)  El aparat o de control super visará los dispositivo s de interfaz para detectar la inserción y extracción de 
las tarjetas. 
16)  Nada más inser tar la tarjeta, el aparato de control detectará si se trata de una tarjeta de tacógraf o 
válida y, en tal caso, identif icará el tipo y la generación de la tarjeta. 
Si en el aparato de control se ha inser tado ya una tarjeta con el mismo número de tarjeta y un índice 
de reno vación super ior, la tarjeta será declarada no válida. 
Si en el aparat o de control se ha inser tado ya una tarjeta con los mismos número de tarjeta y de 
índice de reno vación, pero con un índice de sustitución super ior, la tarjeta será declarada no válida. 
17)  Las tarjetas de tacógraf o de primera generación serán consideradas no válidas por el aparat o de 
control una vez que la posibilidad de utilizar tarjetas de tacógraf o de primera generación haya sido 
supr imida por un taller , de conf ormidad con el apéndice 15 (req. MIG003). 
18)  Las tarjetas de taller de primera generación que se inser ten en aparatos de control de la segunda 
generación se considerarán no válidas. 
19)  El aparato de control deberá estar constr uido de tal modo que las tarjetas de tacógraf o queden fijas 
en su posición al inser tarlas correctamente en los dispositivo s de interfaz. 26.5.2016 L 139/22 Diar io Oficial de la Unión Europea ES    
20)  La extracción de las tarjetas de tacógraf o solo deberá ser posible con el vehículo parado y después de 
haberse almacenado en dichas tarjetas los datos pertinentes. La extracción de la tarjeta exigirá la 
inter vención directa del usuar io. 
3.2  Medición de la velocidad, la posición y la dist ancia 
21)  El sensor de movimient o (en su caso, integrado en el adapt ador) es la fuent e principal para la 
medición de la velocidad y la distancia. 
22) Esta función medirá de forma continua y permitirá indicar en el cuentakilómetros el valor correspon ­
diente a la distancia total recor rida por el vehículo utilizando los impulsos proporcionados por el 
sensor de movimient o. 
23)  Esta función medirá de forma continua y permitirá indicar la velocidad del vehículo utilizando los 
impulsos proporcionados por el sensor de movimient o. 
24)  Asimismo, la función de medición de la velocidad indicará si el vehículo está en movimient o o 
parado. Se considerará que el vehículo está en movimient o en cuant o la función, a través del sensor 
de movimient o, detect e más de 1 imp /seg durante al menos cinco segundos. De lo contrar io, se 
considerará que el vehículo está parado. 
25) Los dispositivo s indicadores de la velocidad (velocímetro) y de la distancia total recor rida (cuentakiló ­
metros) instalados en un vehículo que incor pore un aparat o de control conf orme a lo dispuest o en el 
presente Reglamento deberán cumplir las condiciones relativas a las tolerancias máximas (véanse los 
puntos 3.2.1 y 3.2.2) establecidas en el present e anex o. 
26)  Para detectar cualquier manipulación de los datos de movimient o, la información impor tada del 
sensor de movimiento deberá ser conf irmada por aquella otra relativa al movimient o del vehículo 
procedente del recep tor GNSS y, opcionalmente, de otra(s) fuent e(s) independiente(s) del sensor de 
movimient o. 
27)  Esta función medirá la posición del vehículo a fin de permitir el registro automático de: 
—  las posiciones en que el conduct or y/o el segundo conduct or empiezan su período de traba jo 
diar io; 
—  las posiciones en que el tiempo de conducción continua del conductor llega a un múltiplo de tres 
horas; 
—  las posiciones en que el conduct or y/o el segundo conductor finalizan su período de trabajo 
diar io. 
3.2.1  Medición de la distancia recorrida 
28)  La distancia recor rida podrá medirse: 
—  bien de forma que se incluyan los movimient os en march a adelante y en march a atrás, 
—  bien únicamente en marc ha adelante . 
29)  El aparat o de control deberá medir la distancia entre 0 y 9 999 999,9 km. 
30)  La distancia medida estará comprendida en los siguient es 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 control periódico, 
—  ± 4 % durante el uso. 
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 aparat o de control deberá medir la velocidad entre 0 y 220 km/h. 26.5.2016 L 139/23 Diar io Oficial de la Unión Europea ES    
33)  A fin de garantizar una tolerancia máxima de ± 6 km/h para la indicación de la velocidad durante el 
uso, y teniendo en cuenta: 
—  una tolerancia de ± 2 km/h para posibles variaciones de los valores de entrada (var iaciones de los 
neumáticos, …), 
—  una tolerancia de ± 1 km/h en las mediciones realizadas durant e la instalación o en los controles 
periódicos, 
el aparat o 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 coefi ciente s caract erísticos del vehículo entre 
4 000 y 25 000 imp/km. 
Nota: La resolución del almacenamiento de datos apor ta una tolerancia adicional de ± 0,5 km/h a la 
velocidad registrada por el aparat o de control. 
34)  La velocidad deberá medirse correctamente dentro de las tolerancias normales y antes de que hayan 
transcur rido dos segundos tras haberse producido un cambio de velocidad, si dicho cambio no 
sobrepasa una aceleración de 2 m/s2. 
35)  La medición de la velocidad tendrá una resolución igual o mejor que 1 km/h. 
3.2.3  Medición de la posición 
36)  El aparat o de control medirá la posición absoluta del vehículo utilizando el recept or GNSS. 
37)  La posición absoluta se mide en coordenadas geográficas de latitud y longitud, en grados y minutos, 
con una resolución de 1/10 de minut o. 
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 fecha y 
la hora correspondiente s al tiempo universal coordinado (UTC). 
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 impresión especifi cada en el apéndice 4: «Document os 
de impresión». 
40)  A fin de visualizar la hora local, existirá la posibilidad de cambiar el desfase horar io que aparece en 
pantalla, en fracciones de media hora. Tan solo se podrá compen sar dicho desfase añadiendo 
múltiplos negativ os o positiv os de fracciones de media hora. 
41)  La desviación de la hora no superará los ± 2 segundos por día en condiciones de homologa ción, en 
ausencia de ajustes de la hora. 
42)  La hora medida tendrá una resolución igual o super ior 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éctr ico de duración inferior a doce meses. 
3.4  Super visión de las actividades del conductor 
44)  Esta función deberá controlar permanent emente y por separado las actividades de un conductor y un 
segundo conductor . 
45)  Las actividades del conduct or pueden ser CONDUCCIÓN, TRABAJO, DISPONIBILID AD o PAUSA / 
DESC ANSO. 
46)  El conduct or o el segundo conduct or deberán tener la posibilidad de seleccionar manualmente las 
actividades de TRABAJO, DISPONIBILID AD o PAUSA/DESCANSO. 
47)  Cuando el vehículo esté en movimient o, el aparat o seleccionará automát icamente la actividad de 
CONDUCCIÓN para el conductor y la actividad de DISPONIBILID AD para el segundo conductor . 26.5.2016 L 139/24 Diar io Oficial de la Unión Europea ES    
48)  Cuando el vehículo se detenga, se seleccionará autom áticamente la actividad de TRABAJO para el 
conductor . 
49)  Si el primer cambio de actividad a DESCAN SO o DISPONIBILID AD tiene lugar antes de que hayan 
transcur rido 120 segundos tras haber cambiado automáticament e a TRABAJO por haberse detenido 
el vehículo, se entenderá que ha tenido lugar a la hora en que se detuvo el vehículo (por consiguiente , 
podría cancelar el cambio a TRAB AJO). 
50)  Esta función deberá notificar los cambios de actividad a las funciones de registro con una resolución 
de un minut o. 
51)  A partir de un minuto cualquiera, si se registra alguna actividad de CONDUCCIÓN en los minutos 
inmediatament e anterior y posteri or, se considerará que todo el minuto es de actividad de 
CONDUCCIÓN. 
52)  Dado un minuto cualquiera que no se considere de CONDU CCIÓN con arreglo al requisito 051, se 
considerará que todo el minuto será de un mismo tipo de actividad, concretament e la que haya 
tenido lugar de forma continuada y durant e 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 permanent emente el tiempo de conducción continua y el 
tiempo de descanso acumulado del conductor . 
3.5  Super visión del régimen de conducción 
54)  Esta función deberá controlar permanentement e el régimen de conducción. 
55)  Si hay dos tarjetas de conduct or inser tadas en el aparat o, habrá que seleccionar el régimen EN 
EQUIPO. De otro modo se seleccionará el régimen EN SOLIT ARIO. 
3.6  Entradas de los conductor es 
3.6.1  Intro ducción de los lugares donde comienzan o terminan los períodos de trabajo diarios 
56)  Esta función deberá permitir la introducción de los lugares donde, según el conductor y/o el segundo 
conductor , comienzan o term inan sus períodos de traba jo diar ios. 
57)  Se entiende por lugar el país y, cuando proceda, la región, que se introducirán o conf irmarán 
manualment e. 
58)  En el momento de extraer la tarjeta del conduct or, el aparato de control deberá pedir al conduct or (o 
segundo conductor) que introduzca el «lug ar donde term ina el período de trabajo diar io». 
59)  El conductor deberá introducir entonces el lugar en que se encuentra actualmente el vehículo, que se 
considerará una entrada temporal. 
60)  Se podrán introducir los luga res donde comiencen y/o terminen los períodos de trabajo diar ios a 
través de comandos de los menús. Si se produce más de una entrada en un minut o cualquiera, tan 
solo quedarán registrados el último lugar de comienzo y el último lugar de finalización de traba jo 
introducidos en el marco temporal de dicho minuto. 
3.6.2  Intro ducción manual de las actividades del conductor y del consentimiento del conductor a la interf az ITS 
61)  El aparat o de control permitirá la introducción manual de actividades única y excl usivamente al 
inser tar la tarjeta de conduct or (o de taller). Para la introducción manual de actividades, se utilizarán 
la fecha y hora locales de la zona horar ia (desfa se UTC) configuradas para la unidad instalada en el 
vehículo. 
Al inser tar 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; 
—  opcionalment e: el desfas e horar io local conf igurado para la unidad instalada en el vehículo. 26.5.2016 L 139/25 Diar io Oficial de la Unión Europea ES    
Al inser tar por primera vez determinada tarjeta de conduct or o de taller desconocida en la unidad 
instalada en el vehículo, se invitará al titular de la tarjeta a dar su consentimient o a la salida de datos 
personales relacionados con el tacógraf o a través de la interfaz ITS opcional. 
En cualquier momento, podrá habilitarse o inhabilitarse el consentimient o del conduct or (respecti ­
vamente, del taller) a través de comandos del menú, siempre que esté inser tada la tarjeta de 
conductor (respectivamente, de taller). 
Se podrán introducir actividades obser vando las siguient es restr icciones: 
—  el tipo de actividad podrá ser: TRABAJO, DISPONIBILID AD o PAUSA /DESCA NSO; 
—  la hora de comienzo y finalización de cada actividad estará enmarcada en el inter valo que 
transcur re 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 necesar io, podrán realizarse entradas manuales al inser tar, por vez primera, una tarjeta de 
conductor (o de taller) no utilizada previamente. 
El procedimiento de introducción manual de actividades incluirá tantas fases consecutivas como sea 
necesar io para conf igurar los distint os 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 
inter valo de tiempo entre la última extracció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 luga r en que haya term inado un período de traba jo diar io precedente, asociado a la hora 
pertinente (sobreescr ibiendo así la entrada realizada con motivo de la última extracción de la 
tarjeta), o 
—  un lugar en que comience el período de traba jo diar io actual, asociado a la hora pertinente. 
Si el titular de la tarjeta no introduce el lugar donde comienza o finaliza el período de traba jo 
durante el proceso de introducción manual asociado 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 term ina el período de traba jo diar io precedente sobreescr ibirá, 
pues, la entrada temporal realizada en la última extracción de la tarjeta. 
Si se introduce un lugar, este quedará registrado en la tarjeta de tacógraf o pertinente. 
Se interr umpirán las introducciones manuales en los siguientes casos: 
—  cuando se extraiga la tarjeta, o 
—  cuando el vehículo se mueva permaneciendo inser tada la tarjeta en la ranura del conduct or. 
Se permiten otras interr upciones como, por ejemplo, la desconexión tras un cierto período de 
inactividad del usuar io. En caso de interr umpi rse el proceso de introducción manual, el aparat o de 
control validará cualquier entrada completa de lugar y actividad ya realizada (indicando de forma 
inequív oca el lugar y la hora, o el tipo de actividad y la hora de comienzo y finalización). 
Si se inser ta la tarjeta de un segundo conduct or o de un taller mientras está en curso la introducción 
manual de actividades para una tarjeta previamente inser tada, se permitirá completar dichas entradas 
correspondiente s a la tarjeta anterior antes de dar paso a la introducción manual de entradas relativas 
a la segunda tarjeta. 
El titular de la tarjeta podrá realizar entradas manualment e conf orme al siguient e procedimiento 
mínimo: 
—  introducir manualmente y por orden cronológico las actividades realizadas durant e el período 
compre ndido entre la última extracción de la tarjeta y la actual inserción; 26.5.2016 L 139/26 Diar io Oficial de la Unión Europea ES    
—  la hora de comienzo de la primera actividad se ajustará a la hora de extracción de la tarjeta; la 
hora de comienzo de cada entrada sucesiva deberá ajustarse al momento inmediatament e 
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 manualment e 
coincida con la hora de inserción de la tarjeta. A continuación, el aparat o de control podrá permitir 
opcionalment e al titular de la tarjeta modifi car las actividades introducidas manualment e, hasta 
validarlas seleccionando un comando específico . Una vez validadas las actividades, ya no se podrán 
realizar modificaciones. 
3.6.3  Entr ada de condiciones específic as 
62)  El aparat o de control permitirá al conductor introducir , en tiempo real, las dos condiciones 
específi cas siguiente s: 
—  «FUERA DE ÁMBITO» (comienzo, final), 
—  «TRA YECTO EN TRANSBORD ADOR/TREN» (comienzo, final). 
La condición «TRA YECTO EN TRANSBORD ADOR/TREN» no puede darse si está abier ta la condición 
«FUERA DE ÁMBITO». 
Si la condición «FUERA DE ÁMBITO» está abier ta, el aparat o de control tendrá que cerrarla inmedia ­
tamente en caso de inser tarse o extraerse una tarjeta de conduct or. 
El hecho de estar abier ta la condición «FUERA DE ÁMBITO» impedi rá los siguientes incident es y 
adver tencias: 
—  conducción sin tarjeta adecuada, 
—  adver tencias asociadas al tiempo de conducción continua. 
El indicador de comienzo de «TRA YECTO EN TRANSBORD ADOR/TREN» deberá activarse antes de 
apagar el motor en el transbordador/tren. 
Un «TRA YECTO EN TRANSBORD ADOR/TREN» abier to deberá cerrarse cuando se produzca alguna 
de las circunstancias siguient es: 
—  el conduct or finaliza de forma manual el «TRA YECTO EN TRANSBORD ADOR/TREN», 
—  el conduct or extrae su tarjeta. 
Un «TRA YECTO EN TRANSBORD ADOR/TREN» abier to se cerrará cuando deje de ser válido sobre la 
base de las normas establecidas en el Reglamento (CE) n.o 561/2006. 
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 empr esa con el fin 
de restr ingir el acceso a sus propios datos en el modo de empresa. 
64)  Estos bloqueos consisten en una fecha/hora inicial (activación del bloqueo) y una fecha/hora final 
(desactivación del bloqueo) asociadas con la identif icación de la empr esa, 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 empr esa que lo haya activado (identifi cada por los trece primeros 
dígitos del número de la tarjeta de la empresa), o bien 26.5.2016 L 139/27 Diar io Oficial de la Unión Europea ES    
67)  El bloqueo se desactivará automát icamente si otra emp resa activa un bloqueo. 
68)  En los casos en los que la empr esa que activa el bloqueo es la misma empr esa que introdujo el 
anterior bloqueo, se considerará que el bloqueo previo no ha sido desactivado y se encuentra toda vía 
activo. 
3.8  Super visión de las actividades de control 
69)  Esta función super visa las actividades de VISU ALIZA CIÓN, IMPRESIÓN, TRANSFERENCIA de la VU 
y de la tarjeta y control del CALIBRADO EN CARRETERA que se lleven a cabo en el modo de 
control. 
70)  Esta función también super visa las actividades de CONTR OL DEL EXCESO DE VELOCID AD en el 
modo de control. Se entenderá que se ha producido un control del exces o de velocidad cuando, 
estando en el modo de control, se haya enviado la señal de «exces o de velocidad» a la impresora o a 
la pantalla, o cuando la memor ia de datos de la VU haya transferido datos sobre «incidentes y fallos». 
3.9  Detección de incidentes o fallos 
71)  Esta función detec ta los siguient es incident es o fallos: 
3.9.1  Incidente «Inser ción de una tarjeta no válida» 
72)  Este incidente se produce al inser tar una tarjeta no válida, al inser tar una tarjeta de conductor ya 
sustituida y/o cuando expira una tarjeta válida inser tada. 
3.9.2  Incidente «Conf licto de tarjetas» 
73)  Este incidente se produce cuando se produce alguna de las combinaciones de tarjetas válidas 
señaladas con X en el siguiente cuadro: 
Conf licto de tarjetas Ranura del conducto r 
Sin tarjeta Tarjeta de 
conductor Tarjeta de control Tarjeta de taller Tarjeta de empresa Ranura del segundo conductor Sin tarjeta      
Tarjeta de con­
ductor    X  
Tarjeta de con­
trol   X X X 
Tarjeta de taller  X X X X 
Tarjeta de em­
presa   X X X  
3.9.3  Incidente «Solapamiento tempor al» 
74)  Este incident e se produce cuando la fecha/hora en que se extrajo por última vez una tarjeta de 
conductor , según quede registrado en dicha tarjeta, es posteri or a la fecha/hora actual del aparat o de 
control donde se inser ta la tarjeta. 26.5.2016 L 139/28 Diar io Oficial de la Unión Europea ES    
3.9.4  Incidente «Conducción sin tarjeta adecuada» 
75)  Este incident e se produce en determi nadas combinaciones de dos tarjetas de tacógraf o válidas 
(indicadas con una X en el cuadro siguient e), cuando la actividad del conductor cambia a 
CONDUCCIÓN o cuando tiene lugar un cambio del modo de funcionamient o mientras la actividad 
del conduct or es CONDUCCIÓN: 
Conducción sin tarjeta 
adecuada Ranura del conducto r 
Sin tarjeta (o 
tarjeta no válida) Tarjeta de 
conductor Tarjeta de control Tarjeta de taller Tarjeta de empresa Ranura del segundo conductor Sin tarjeta (o 
tarjeta no vá­
lida) X  X  X 
Tarjeta de con­
ductor X  X X X 
Tarjeta de con­
trol X X X X X 
Tarjeta de taller X X X  X 
Tarjeta de em­
presa X X X X X  
3.9.5  Incidente «Inser ción de tarjeta durante la conducción» 
76)  Este incidente se produce cuando se inser ta una tarjeta de tacógraf o en una de las ranuras mientras la 
actividad del conduct or es CONDUCCIÓN. 
3.9.6  Incidente «Error al cerrar la última sesión de la tarjeta» 
77)  Este incident e se produce cuando, al inser tar la tarjeta, el aparato de control detecta que, a pesar de lo 
dispuesto en el punt o 3.1, la sesión anterior de la tarjeta no se ha cerrado correctamente (se ha 
extraído la tarjeta antes de que pudieran grabarse en ella todos los datos pertinente s). Este incident e 
afecta excl usivamente a las tarjetas de conductor y a las tarjetas de taller . 
3.9.7  Incidente «Exceso de velocidad» 
78)  Este incident e se produce cada vez que se sobrepasa la velocidad permitida. 
3.9.8  Incidente «Inter rupción del suministr o eléctr ico» 
79)  Este incident e se produce cuando el suministro eléctr ico del sensor de movimiento o de la unidad 
instalada en el vehículo se interr umpe durant e más de 200 milisegundos, fuera del modo de 
calibrado o de control. El umbral de interrupció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 dispositiv o de comunicación a distancia» 
80)  Este incidente se produce, fuera del modo de calibrado, cuando el dispositivo de comunicación a 
distancia no acusa recibo de la correcta recepción de los datos de comunicación a distancia envi ados 
desde la unidad instalada en el vehículo durante más de tres intentos. 
3.9.10  Incidente «Ausencia de infor mación sobre la posición procedente del receptor GNSS» 
81)  Este incident e se produce, fuera del modo de calibrado, en caso de ausencia de información sobre 
la posición procedente del recept or GNSS (sea intern o o externo) durante más de tres horas de 
tiempo de conducción acumulado. 26.5.2016 L 139/29 Diar io Oficial de la Unión Europea ES    
3.9.11  Incidente «Error de comunicación con el dispositiv o GNSS exter no» 
82)  Este incident e se produce, fuera del modo de calibrado, en caso de interr upción de la 
comunicación entre el recep tor GNSS exte rno 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 movim iento» 
83)  Este incident e se produce, fuera del modo de calibrado, en caso de interr upción del flujo normal 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 autenticación de datos durant e el inter cambio entre el sensor de movimiento 
y la unidad instalada en el vehículo. 
3.9.13  Incidente «Conf licto de movimiento del vehíc ulo» 
84)  Este incident e se produce, fuera del modo de calibrado, en caso de que la información sobre el 
movimient o calculada a partir del sensor de movimient o esté en contradicción con la información 
sobre el movimient o calculada a partir del recept or GNSS intern o o del dispositivo GNSS externo y 
eventualment e con otras fuent es independient es, tal como se especifica en el apéndice 12. Este 
incidente no debe producirse durant e un trayect o en transbordador/tren o una condición «FUERA DE 
ÁMBITO», ni cuando no esté disponible la información sobre posición del recep tor GNSS. 
3.9.14  Incidente «Intento de violación de la segur idad» 
85)  Este incidente se produce cuando por algún motivo se ha visto afectada la segur idad del sensor de 
movimient o, de la unidad instalada en el vehículo o del dispositivo GNSS extern o, según se especifi ca 
en el apéndice 10, fuera del modo de calibrado. 
3.9.15  Incidente «Conf licto tempor al» 
86)  Este incident e se produce cuando, fuera del modo de calibrado, la VU detecta una discrepancia de 
más de un minuto entre la hora de la función de medición de la hora de la unidad instalada en el 
vehículo y la hora procedent e del recep tor GNSS. Este incident e se registra junto con el valor del reloj 
intern o de la unidad instalada en el vehículo y va acompañ ado de un ajust e de la hora automát ico. 
Después de haberse producido un incident e de conf licto temporal, la VU no generará más incident es 
del mismo tipo durant e las doce horas siguient es. Este incident e no se producirá cuando no hubiera 
una señal GNSS válida detectable por el recep tor GNSS en los últimos treinta días. No obstante, 
cuando vuelva a estar disponible la información sobre la posición del recep tor GNSS, se efectuará el 
ajust e de la hora automático. 
3.9.16  Fallo «Tarjeta» 
87)  Este fallo está asociado al fallo de funcionamient o de una tarjeta de tacógraf o. 
3.9.17  Fallo «Apar ato de contro l» 
88)  Este fallo está asociado a uno de los fallos siguient es, fuera del modo de calibrado: 
—  fallo interno de la VU, 
—  fallo de la impresora, 
—  fallo de la pantalla, 
—  fallo de transfer encia, 
—  fallo del sensor , 
—  fallo del recep tor GNSS o del dispositivo GNSS exte rno, 
—  fallo del dispositivo de comunicación a distancia. 26.5.2016 L 139/30 Diar io Oficial de la Unión Europea ES    
3.10  Autod iagnóst ico y comprobaciones auto máticas 
89)  El aparat o de control deberá ser capaz de detectar los fallos ocur ridos mediante compr obaciones 
automáticas y una función de autodiag nóstico, con arreglo al cuadro siguiente: 
Subconjunto que se verifica Comprobación auto mática Autodiagnóstico 
Software  Integr idad 
Memor ia de datos Acceso Acceso, integr idad de los 
datos 
Dispositivos de interfaz para tarjetas Acceso Acceso 
Teclado  Comprobación manual 
Impresora (depende del fabr icante) Documento impreso 
Pantalla  Comprobación visual 
Transferencia 
(exclusivament e durante la transfer encia) Funcionamiento correcto  
Sensor Funcionamiento correcto Funcionamiento correcto 
Dispositivo de comunicación a distancia. Funcionamiento correcto Funcionamiento correcto 
Dispositivo GNSS Funcionamiento correcto Funcionamiento correcto  
3.11  Lectura de datos de la memor ia 
90)  El aparat o de control deberá ser capaz de leer todos los datos almacenados en su memor ia. 
3.12  Registro y almacenamiento de dato s en la memor ia 
A efect os del presente apar tado: 
—  Por «365 días» se entienden 365 días civiles de actividad media de un conductor en un vehículo. Por 
actividad media diar ia en un vehículo se entiende al menos 6 conduct ores o segundos conduct ores, 6 
ciclos de inserción-extracción de tarjeta y 256 cambios de actividad. Por consiguiente, «365 días» 
incluy en al menos 2 190 (segundos) conduct ores, 2 190 ciclos de inserción-extracción de tarjeta y 
93 440 cambios de actividad. 
—  El número medio de posiciones por día se define como al menos 6 posiciones en las que comienza el 
período de trabajo diar io, 6 posiciones en las que el tiempo de conducción continua del conduct or llega 
a un múltiplo de tres horas, y 6 posiciones en las que term ina el período de traba jo diar io, por lo que 
«365 días» incluye n al menos 6 570 posiciones. 
—  Las horas se registran con una resolución de un minuto, a menos que se especifique lo contrar io. 
—  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 
minut o, con la exactitud del GNSS asociada y la hora de adquisición. 26.5.2016 L 139/31 Diar io Oficial de la Unión Europea ES    
91)  En las condiciones de homologa ción, los datos almacenados en la memor ia de datos no deberán 
verse afectados por interr upciones del suministro eléctr ico 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 afectados por interr upciones del suministro eléctr ico de 
menos de 28 días de duración. 
92)  El aparat o de control deberá ser capaz de registrar y almacenar de forma implícita o explícita en su 
memor ia de datos lo siguiente: 
3.12.1  Datos de identifica ción de los equipos 
3.12.1.1  Datos de identificación de la unidad instalada en el vehículo 
93)  El aparat o de control deberá ser capaz de almacenar en su memor ia de datos los siguiente s datos de 
identif icació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ógraf o de primera generación, 
—  versión de software, 
—  fecha de instalación de la versión de software, 
—  año de fabr icación del equipo, 
—  número de homolog ación. 
94)  El fabr icante de la unidad instalada en el vehículo registra y almacena de manera permanente, sin 
posibilidad de alteración, los datos de identificación de dicha unidad, exce pto los datos relacionados 
con el software y el número de homologació n, que pueden cambiar en caso de actualizar el software y 
la capacidad para utilizar las tarjetas de tacógraf o de primera generación. 
3.12.1.2  Datos de identificación del sensor de movimiento 
95) El sensor de movimiento deberá ser capaz de almacenar en su memor ia los siguientes datos de identi ­
ficación: 
—  nombre del fabricante, 
—  número de serie, 
—  número de homolog ación, 
—  identif icador del compo nente de segur idad integrad o (por ejemplo, número de pieza del chip/ 
procesador interno), 
—  identif icador 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 
permanent e, sin posibilidad de alter ación, los datos de identif icación de dicho sensor . 
97)  La unidad instalada en el vehículo deberá ser capaz de registrar y almacenar en su memor ia los 
siguiente s datos, correspondientes a los últimos veinte emparej amientos de los sensores de 
movimient o (si se producen varios emparejamient os dentro de un día civil, solo se almacenarán el 
primero y el último del día). 
Deberán almacenarse los datos siguient es para cada uno de estos emparej amientos: 
—  datos de identif icación del sensor de movimient o: 
—  número de serie, 
—  número de homologación, 26.5.2016 L 139/32 Diar io Oficial de la Unión Europea ES    
—  datos de emparejamient o del sensor de movimiento: 
—  fecha del emparej amiento. 
3.12.1.3  Datos de identificación de los sistemas mundiales de navegación por satélite 
98)  El dispositivo GNSS exte rno deberá ser capaz de almacenar en su memor ia los siguient es datos de 
identif icación: 
—  nombre del fabricante, 
—  número de serie, 
—  número de homolog ación, 
—  identif icador del compo nente de segur idad integrad o (por ejemplo, número de pieza del chip/ 
procesador interno), 
—  identif icador del sistema operativo (por ejem plo, versión de software). 
99)  El fabr icante del dispositivo GNSS externo registra y almacena en el propio dispositivo de manera 
permanent e, sin posibilidad de alter ación, los datos de identif icación. 
100)  La unidad instalada en el vehículo deberá ser capaz de registrar y almacenar en su memor ia los 
siguiente s datos, correspondientes a los últimos veinte acoplamientos de dispositivo s GNSS exte rnos 
(si se producen varios acoplamient os dentro de un día civil, solo se almacenarán el primero y el 
último del día). 
Deberán almacenarse los datos siguient es para cada uno de estos acoplamient os: 
—  datos de identif icación del dispositivo GNSS exte rno: 
—  número de serie, 
—  número de homologación, 
—  datos de acoplamiento del dispositivo GNSS externo: 
—  fecha de acoplamient o. 
3.12.2  Clave s y certificados 
101)  El aparat o de control deberá ser capaz de almacenar una serie de claves y certificados criptográfico s, 
según lo especifi cado en el apéndice 11, parte A y parte B. 
3.12.3  Datos de inser ció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 memor ia 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 inser tar la tarjeta, 
—  la ranura donde se inser ta la tarjeta, 
—  la fecha y hora de extracción, 
—  la lectura del cuentakilómetros del vehículo en el momento de extraer la tarjeta, 26.5.2016 L 139/33 Diar io Oficial de la Unión Europea ES    
—  la información siguiente acerca del vehículo anterior que utilizara el conduct or, tal y como consta 
en la tarjeta: 
—  VRN y Estado miembro donde se matr iculó 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 inser tar la tarjeta, el titular ha introducido 
manualment e alguna actividad. 
103)  La memor ia de datos deberá ser capaz de mantener estos datos almacenados durant e al menos 365 
días. 
104)  Cuando se agot e la capacidad de almacenamiento, los datos más antiguos se sustituirán por otros 
nuevos. 
3.12.4  Datos sobre la actividad del conductor 
105)  Cada vez que cambie la actividad del conductor o del segundo conduct or, o cada vez que cambie el 
régimen de conducción, o cada vez que se inser te o extraig a una tarjeta de conduct or o una tarjeta de 
taller , el aparat o de control deberá registrar y almacenar en su memor ia de datos: 
—  el régimen de conducción (EN EQUIPO, EN SOLIT ARIO), 
—  la ranura (COND UCTOR, SEGUNDO CONDUCTOR), 
—  el estado de la tarjeta en la ranura que corresponda (INSERT ADA, NO INSER TADA), 
—  la actividad (COND UCCIÓN, DISPONIBILID AD, TRABAJO, PAUSA/DESCANSO), 
—  la fecha y hora del cambio. 
INSERT ADA signif ica que se ha inser tado en la ranura una tarjeta de conductor o una tarjeta de taller 
válidas. NO INSERT ADA signif ica lo contrar io, es decir , que no se ha inser tado en la ranura una 
tarjeta de conduct or o una tarjeta de taller válidas (por ejemplo, se inser ta una tarjeta de empr esa o 
no se inser ta tarjeta). 
Los datos de actividad que introduzca manualment e el conduct or no se registran en la memor ia de 
datos. 
106)  La memor ia de datos deberá ser capaz de mantener estos datos almacenados durant e al menos 365 
días. 
107)  Cuando se agot e la capacidad de almacenamiento, los datos más antiguos se sustituirán por otros 
nuevos. 
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 continua 
108)  El aparat o de control deberá registrar y almacenar en su memor ia de datos: 
—  los lugar es y las posiciones en que el conduct or y/o el segundo conductor comienzan su período 
de traba jo diar io; 
—  las posiciones en que el tiempo de conducción continua del conductor llega a un múltiplo de tres 
horas; 
—  los lugares y las posiciones en que el conduct or y/o el segundo conduct or finalizan su período de 
traba jo diar io. 
109)  Cuando la posición del vehículo no esté disponible a partir del recep tor GNSS en esos momentos, 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 aparat o de control deberá registrar y almacenar en su memor ia de 
datos: 
—  el número de tarjeta del (segundo) conductor y el Estado miembro que haya expedido la tarjeta, 
—  la generación de la tarjeta, 26.5.2016 L 139/34 Diar io Oficial de la Unión Europea ES    
—  la fecha y hora de la entrada, 
—  el tipo de entrada (comienzo, final o tres horas de tiempo de conducción continua), 
—  la exactitud, la fecha y la hora del GNSS, si procede, 
—  la lectura del cuentakilómetros del vehículo. 
111)  La memor ia de datos deberá ser capaz de manten er almacenados durante al menos 365 días los 
lugares y posiciones en que comienzan o finalizan los períodos de traba jo diar ios y/o se alcanzan las 
tres horas de tiempo de conducción continua. 
112)  Cuando se agot e la capacidad de almacenamiento, los datos más antiguos se sustituirán por otros 
nuevos. 
3.12.6  Datos del cuentakilómetro s 
113)  Cada día civil a medianoc he, el aparato de control deberá registrar en su memor ia la lectura del 
cuentakilómetros del vehículo y la fecha correspondiente. 
114)  La memor ia de datos deberá ser capaz de almacenar las lecturas de los cuentakilómetros a 
medianoche durante al menos 365 días civiles. 
115)  Cuando se agot e la capacidad de almacenamiento, los datos más antiguos se sustituirán por otros 
nuevos. 
3.12.7  Datos pormenor izados sobre la velocidad 
116)  Para cada segundo de al menos las últimas 24 horas en que haya estado en movimient o el vehículo, 
el aparat o de control deberá registrar y almacenar en su memor ia de datos la velocidad instantánea 
del vehículo y la fecha y hora correspondiente s. 
3.12.8  Datos sobre incidentes 
A efect os del presente subapar tado, la hora se registrará con una resolución de un segundo. 
117)  El aparat o de control deberá registrar y almacenar en su memor ia los datos siguient es para cada 
incidente detec tado, con arreglo a las reglas de almacenamiento descr itas a continuación: 
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 incident e, 
—tipo de tarjeta(s), número, Estado miem ­
bro emisor y generación de la tarjeta 
que creó el incidente, 
—número de incident es similares ocur ri­
dos ese día. 
Conf licto de tarjetas —  los diez incidentes más recientes. —  fecha y hora de comienzo del incident e, 
—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 conf licto. 
Conducción sin tarjeta ade­
cuada —el incident e de mayor duración ocu­
rrido cada uno de los últimos diez días 
en que se hayan producido incident es 
de este tipo, 
—  los cinco incident es de mayor duración 
ocur ridos en los últimos 365 días. —  fecha y hora de comienzo del incident e, 
—fecha y hora de finalización del inci­
dente, 
—tipo de tarjeta(s), número, Estado miem ­
bro emisor y generación de cualquier 
tarjeta inser tada al comenzar o al termi­
nar el incident e, 
—número de incident es similares ocur ri­
dos ese día. 26.5.2016 L 139/35 Diar io Oficial de la Unión Europea ES    
Incidente Reglas de almacenamiento Datos que hay que registrar en cada incidente 
Inserción de tarjeta durante 
la conducción —  el último incidente ocur rido en cada 
uno de los diez últimos días en que se 
hayan producido incident es de ese 
tipo, —  fecha y hora del incident e, 
—tipo de tarjeta(s), número, Estado miem ­
bro emisor y generación, 
—número de incident es similares ocur ri­
dos ese día. 
Error al cerrar la última se­
sión de la tarjeta —  los diez incidentes más recientes. —  fecha y hora de inserción de la tarjeta, 
—tipo de tarjeta(s), número, Estado miem ­
bro emisor y generación, 
—datos de la última sesión según la lec­
tura de la tarjeta: 
—fecha y hora de inserción de la tar­
jeta, 
—VRN, Estado miembro de matr icula ­
ción y generación de la VU. 
Exceso de velocidad (1) —  el incident e 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 ocur rido con la velo ­
cidad media más alta), 
—los cinco incidentes más graves ocur ri­
dos en los últimos 365 días, 
—  el primer incident e que haya ocur rido 
después del último calibrado. —  fecha y hora de comienzo del incident e, 
—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 
conductor (si procede), 
—número de incident es similares ocur ri­
dos ese día. 
Interr upción del suministro 
eléctr ico (2) —el incident e de mayor duración ocu­
rrido cada uno de los últimos diez días 
en que se hayan producido incident es 
de este tipo, 
—  los cinco incident es de mayor duración 
ocur ridos en los últimos 365 días. —  fecha y hora de comienzo del incident e, 
—fecha y hora de finalización del inci­
dente, 
—tipo de tarjeta(s), número, Estado miem ­
bro emisor y generación de cualquier 
tarjeta inser tada al comenzar o al termi­
nar el incident e, 
—número de incident es similares ocur ri­
dos ese día. 
Error de comunicación con 
el dispositivo de comunica ­
ción a distancia —el incident e de mayor duración ocu­
rrido cada uno de los últimos diez días 
en que se hayan producido incident es 
de este tipo, 
—  los cinco incident es de mayor duración 
ocur ridos en los últimos 365 días. —  fecha y hora de comienzo del incident e, 
—fecha y hora de finalización del inci­
dente, 
—tipo de tarjeta(s), número, Estado miem ­
bro emisor y generación de cualquier 
tarjeta inser tada al comenzar o al termi­
nar el incident e, 
—número de incident es similares ocur ri­
dos ese día. 
Ausencia de información so­
bre la posición procedente 
del recept or GNSS —el incident e de mayor duración ocu­
rrido cada uno de los últimos diez días 
en que se hayan producido incident es 
de este tipo, 
—  los cinco incident es de mayor duración 
ocur ridos en los últimos 365 días. —  fecha y hora de comienzo del incident e, 
—fecha y hora de finalización del inci­
dente, 
—tipo de tarjeta(s), número, Estado miem ­
bro emisor y generación de cualquier 
tarjeta inser tada al comenzar o al termi­
nar el incident e, 
—número de incident es similares ocur ri­
dos ese día. 26.5.2016 L 139/36 Diar io Oficial de la Unión Europea ES    
Incidente Reglas de almacenamiento Datos que hay que registrar en cada incidente 
Error en datos de movi­
mient o —el incident e de mayor duración ocu­
rrido cada uno de los últimos diez días 
en que se hayan producido incident es 
de este tipo, 
—  los cinco incident es de mayor duración 
ocur ridos en los últimos 365 días. —  fecha y hora de comienzo del incident e, 
—fecha y hora de finalización del inci­
dente, 
—tipo de tarjeta(s), número, Estado miem ­
bro emisor y generación de cualquier 
tarjeta inser tada al comenzar o al termi­
nar el incident e, 
—número de incident es similares ocur ri­
dos ese día. 
Conf licto de movimient o del 
vehículo —el incident e de mayor duración ocu­
rrido cada uno de los últimos diez días 
en que se hayan producido incident es 
de este tipo, 
—  los cinco incident es de mayor duración 
ocur ridos en los últimos 365 días. —  fecha y hora de comienzo del incident e, 
—fecha y hora de finalización del inci­
dente, 
—tipo de tarjeta(s), número, Estado miem ­
bro emisor y generación de cualquier 
tarjeta inser tada al comenzar o al termi­
nar el incident e, 
—número de incident es similares ocur ri­
dos ese día. 
Intent o de violación de la se­
guridad —  los diez incident es más recientes de 
cada tipo. —  fecha y hora de comienzo del incident e, 
—  fecha y hora en que term inó el incident e 
(si es pertinente ), 
—tipo de tarjeta(s), número, Estado miem ­
bro emisor y generación de cualquier 
tarjeta inser tada al comenzar o al termi­
nar el incident e, 
—  tipo de incident e. 
Conf licto temporal —el incident e de mayor duración ocu­
rrido cada uno de los últimos diez días 
en que se hayan producido incident es 
de este tipo, 
—  los cinco incident es de mayor duración 
ocur ridos en los últimos 365 días. —  fecha y hora del aparat o de control, 
—  fecha y hora del GNSS, 
—tipo de tarjeta(s), número, Estado miem ­
bro emisor y generación de cualquier 
tarjeta inser tada al comenzar o al termi­
nar el incident e, 
—número de incident es similares ocur ri­
dos ese día.   
(1) El aparat o de control deberá registrar y almacenar también en su memor ia de datos: 
—  la fecha y la hora del último CONTR OL DEL EXCESO DE VELOCI DAD, 
—  la fecha y la hora del primer exceso de velocidad ocur rido tras este CONTR OL DEL EXCESO 
DE VELOCI DAD, 
—  el número de incidentes de exceso de velocidad ocur ridos después del último CONTR OL DEL 
EXCESO DE VEL OCID AD.  
(2) Estos datos solo podrán registrarse al reconectar la alimentación eléctr ica. Las horas se 
determinarán con una precisión de un minuto. 
3.12.9  Datos sobre fallos 
A efect os del presente subapar tado, la hora se registrará con una resolución de un segundo. 26.5.2016 L 139/37 Diar io Oficial de la Unión Europea ES    
118)  El aparat o de control intentar á registrar y almacenar en su memor ia los datos siguient es para cada 
fallo detectado, con arreglo a las reglas de almacenamiento descr itas a continuación: 
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 conduct or. —  fecha y hora en que comenzó el fallo, 
—  fecha y hora en que term inó el fallo, 
—tipo de tarjeta(s), número, Estado miem ­
bro emisor y generación. 
Fallos del aparato de control —  los diez fallos más recientes de cada 
tipo, 
—el primer fallo ocur rido después del úl­
timo calibrado. —  fecha y hora en que comenzó el fallo, 
—  fecha y hora en que term inó el fallo, 
—  tipo de fallo, 
—tipo de tarjeta(s), número, Estado miem ­
bro emisor y generación de cualquier 
tarjeta inser tada al comenzar o al termi­
nar el fallo.  
3.12.10  Datos de calibr ado 
119)  El aparat o de control deberá registrar y almacenar en su memor ia 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 (según const e en el VIN), 
—  los veinte calibrados más reciente s (si el aparat o se ha calibrado más de una vez en un mismo día 
civil, solo se almacenarán los datos 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 siguiente s: 
—  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 miembro que haya expedido la tarjeta y fecha de expiración 
de la tarjeta, 
—  identif icación del vehículo, 
—  parámetros que se actualizan o confir man: w, k, l, tamaño de los neumáticos, valor de ajust e del 
dispositivo limitador de la velocidad, cuentakilómetros (lectura anterior y nueva lectura), fecha y 
hora (valor anterior y nuevo valor), 
—  los tipos y los identificadores de todos los precint os existent es. 
121)  Además, el aparat o de control deberá registrar y almacenar en su memor ia de datos su capacidad 
para utilizar tarjetas de tacógraf o de primera generación (aún activada o no). 
122)  El sensor de movimiento deberá registrar y almacenar en su memor ia los siguiente s datos sobre la 
instalación del sensor de movimient o: 
—  primer emparej amiento 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 homologa ción de la VU, número de 
serie de la VU). 26.5.2016 L 139/38 Diar io Oficial de la Unión Europea ES    
123)  El dispositivo GNSS extern o deberá registrar y almacenar en su memor ia los siguiente s datos sobre la 
instalación del dispositivo GNSS externo: 
—  primer acoplamiento con una VU (fecha, hora, número de homolog ació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 memor ia los datos correspondiente s a los 
ajust es de hora que se hayan realizado en el modo de calibrado y fuera del marco de un calibrado 
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 ajus te la hora, se registrarán los datos siguientes: 
—  fecha y hora, valor anter ior, 
—  fecha y hora, nuevo valor , 
—  nombre y dirección del taller , 
—  número de la tarjeta de taller , Estado miembro 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 contro l 
126) El aparat o de control deberá registrar y almacenar en su memor ia los siguient es 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 miembro 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 transfe ­
rencia de los datos de la tarjeta y/o control del calibrado en carretera). 
127)  En caso de transferencia, también habrá que registrar las fechas correspondientes a los días 
transferi dos más antiguos y más reciente s. 
3.12.13  Datos sobre los bloqueos introd ucidos por las empr esas 
128) El aparat o de control deberá registrar y almacenar en su memor ia los siguient es 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 empr esa, Estado miembro que haya expedido la tarjeta y generación de la 
tarjeta, 
—  nombre y dirección de la empr esa. 
Los datos previamente bloqueados mediante un bloqueo eliminado de la memor ia debido al límite 
antes mencionado se considerarán desbloqueados. 
3.12.14  Datos sobre actividades de transfer encia 
129) El aparat o de control deberá registrar y almacenar en su memor ia los siguient es datos correspon ­
dientes a la última transfe rencia de datos de la memor ia a medios externo s, estando en el modo de 
empresa o en el modo de calibrado: 
—  fecha y hora de la transfer encia, 26.5.2016 L 139/39 Diar io Oficial de la Unión Europea ES    
—  número de la tarjeta de empr esa 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ífi cas 
130)  El aparat o de control deberá registrar en su memor ia los siguiente s datos correspondientes a 
condiciones específi cas: 
—  fecha y hora de la entrada, 
—  tipo de condición específica. 
131)  La memor ia 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 almacenamient o, los datos más antiguos se sustituirán por otros nuevos. 
3.12.16  Datos de la tarjeta de tacóg rafo 
132)  El aparato de control deberá ser capaz de almacenar los siguient es datos relativ os a las diferentes 
tarjetas de tacógraf o que se han utilizado en la VU: 
—  número de la tarjeta de tacógraf o y su número de serie, 
—  fabricante de la tarjeta de tacógraf o, 
—  tipo de tarjeta de tacógraf o, 
—  versión de la tarjeta de tacógraf o. 
133)  El aparat o de control deberá ser capaz de almacenar al menos 88 de estos registros. 
3.13  Lectura de las tarjetas de tacóg rafo 
134)  El aparat o de control deberá ser capaz de leer las tarjetas de tacógraf o de primera y segunda 
generación para obte ner, cuando proceda, los datos necesar ios para: 
—  identif icar el tipo de tarjeta, al titular de la tarjeta, el anterior vehículo empleado, la fecha 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 , 
—  calcular el tiempo de conducción continua del conduct or, su tiempo de descanso acumulado y sus 
tiempos de conducción acumulados durante la semana anterior y la actual, 
—  imprimir , previa solicitud, los datos registrados en una tarjeta de conduct or, 
—  transferir a medios exte rnos la información conte nida en una tarjeta de conductor . 
Este requisit o solo se aplica a las tarjetas de tacógraf o de primera generación, siempre que su 
utilización no haya sido supr imida por un taller . 
135)  En caso de producirse un error de lectura, el aparat o de control intentará ejecutar de nuevo el mismo 
comando de lectura. Si no lo consigue después de tres intent os, declarará la tarjeta defect uosa y no 
válida. 
3.14  Registro y almacenamiento de dato s en las tarjetas de tacóg rafo 
3.14.1  Regi stro y almacenamiento de datos en las tarjetas de tacóg rafo de primer a generación 
136)  Siempre que un taller no haya supr imido el uso de las tarjetas de tacógraf o de primera generación, el 
aparato de control deberá registrar y almacenar datos exactament e de la misma manera que lo haría 
un aparato de control de primera generación. 26.5.2016 L 139/40 Diar io Oficial de la Unión Europea ES    
137)  Nada más inser tada la tarjeta de conduct or o de taller , el aparato de control deberá configurar los 
«dato s de la sesión» en dicha tarjeta. 
138)  El aparat o de control deberá actualizar los datos almacenados en las tarjetas de conductor , de taller , 
de empresa o de control, si son válidas. Para ello, escr ibirá en la tarjeta todos los datos necesar ios del 
titular correspondientes al período en que dicha tarjeta esté inser tada. En el capítulo 4 se especifican 
los datos almacenados en cada tipo de tarjeta. 
139)  El aparat o de control deberá actualizar los datos sobre la actividad del conductor y sobre los lugar es 
(según se especifica en los punt os 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 manualment e por el 
titular de la tarjeta. 
140)  Los incidentes no definidos para los aparatos de control de primera generación no se almacenarán en 
las tarjetas de conductor ni de taller . 
141)  Los datos de las tarjetas de tacógraf o se actualizarán de manera que, cuando sea necesar io y teniendo 
en cuenta la capacidad real de almacenamient o de la tarjeta, los datos más recientes sustituyan a los 
más antiguos. 
142)  En caso de producirse un error de escr itura, el aparat o de control intentará ejecutar de nuev o el 
mismo comando de escr itura. Si no lo consigue después de tres intent os, declarará la tarjeta 
defectuosa y no válida. 
143)  Antes de liberar una tarjeta de conduct or, y después de haber almacenado en ella todos los datos 
pertinentes , el aparat o de control deberá reiniciar los «dato s de la sesión». 
3.14.2  Regi stro y almacenamiento de datos en las tarjetas de tacóg rafo de segunda gener ación 
144)  Las tarjetas de tacógraf o de segunda generación deberán incluir dos aplicaciones de tarjeta diferentes, 
la primero de las cuales será exactamente la misma que la aplicación TACHO de las tarjetas de 
tacógraf o de primera generación, y la segunda la aplicación TACHO_G2, que se especifi ca en el 
capítulo 4 y el apéndice 2. 
145)  Nada más inser tada la tarjeta de conduct or o de taller , el aparato de control deberá configurar los 
«dato s de la sesión» en dicha tarjeta. 
146)  El aparat o de control deberá actualizar los datos almacenados en las dos aplicaciones de las tarjetas 
de conduct or, de taller , de emp resa o de control, si son válidas. Para ello, escr ibirá en la tarjeta todos 
los datos necesar ios del titular correspondiente s al período en que dicha tarjeta esté inser tada. En el 
capítulo 4 se especifican los datos almacenados en cada tipo de tarjeta. 
147)  El aparat o de control deberá actualizar los datos sobre los lugar es y posiciones de actividad del 
conductor (según se especifi ca en los punt os 4.5.3.1.9, 4.5.3.1.11, 4.5.3.2.9 y 4.5.3.2.11). Estos 
datos, almacenados en las tarjetas de conductor o en las tarjetas de taller válidas, se sustituirán por 
los datos de lugares de actividad introducidos manualment e por el titular de la tarjeta. 
148)  Los datos de las tarjetas de tacógraf o se actualizarán de manera que, cuando sea necesar io y teniendo 
en cuenta la capacidad real de almacenamient o de la tarjeta, los datos más recientes sustituyan a los 
más antiguos. 
149)  En caso de producirse un error de escr itura, el aparat o de control intentará ejecutar de nuev o el 
mismo comando de escr itura. Si no lo consigue después de tres intent os, declarará la tarjeta 
defectuosa y no válida. 
150)  Antes de liberar una tarjeta de conduct or, y después de haber almacenado en las dos aplicaciones de 
la tarjeta todos los datos pertinentes , el aparato de control deberá reiniciar los «dato s de la sesión». 
3.15  Visualización 
151)  La pantalla deberá incluir al menos veinte caract eres. 
152)  Los caracteres tendrán un tamaño mínimo de 5 mm de alto y 3,5 mm de anch o. 26.5.2016 L 139/41 Diar io Oficial de la Unión Europea ES    
153)  La pantalla admitirá el uso de los caract eres especificados en el apéndice 1, Capítulo 4: «Conjunt os de 
caracteres». La pantalla podrá utilizar glifos simplificados (p.ej.: los caract eres acentuados podrán 
aparecer sin acento , o las minúsculas podrán verse como mayúsculas). 
154)  La pantalla deberá tener una iluminación adecuada que no provoque deslumbramiento. 
155)  Las indicaciones deberán ser visibles desde fuera del aparat o de control. 
156)  El aparat o de control deberá ser capaz de mostrar en pantalla: 
—  los datos por defecto, 
—  los datos relacionados con adver tencias, 
—  los datos relacionados con el acceso a los menús, 
—  otros datos que solicite un usuar io. 
El aparato de control también podrá mostrar en pantalla otras informaciones, siempr e que puedan 
distinguirse clarament e de las arriba exigidas. 
157)  La pantalla del aparat o de control deberá utilizar los pictogramas o las combinaciones de pictogramas 
enumerados en el apéndice 3. También podrán utilizarse otros pictogramas o combinaciones de 
pictogramas siempre que puedan distinguirse claramente de los exigidos. 
158)  La pantalla deberá estar siempre encendida (ON) cuando el vehículo esté en movimiento. 
159)  El aparat o de control podrá incluir una función manual o autom ática que apague (OFF) la pantalla 
cuando el vehículo esté parado. 
El formato de visualización se especific a en el apéndice 5. 
3.15.1  Contenido de la pantalla por defecto 
160)  Cuando no sea necesar io mostrar otra información, el aparat o de control deberá presentar en 
pantalla, por defect o, los datos siguient es: 
—  la hora local (cor respondiente a la UTC + desfase conf igurado por el conduct or), 
—  el modo de funcionamient o, 
—  la actividad actual del conduct or y la del segundo conduct or, 
—  información relativa al conduct or: 
—  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 relativ os a cada conduct or será clara, sencilla e inequív oca. Si 
no fuera posible mostrar en pantalla simultáneamente la información relativa al conduct or y la 
relativa al segundo conduct or, el aparato de control deberá mostrar por defe cto la información 
relativa al conduct or y ofrecerá al usuar io la posibilidad de visualizar la información relativa al 
segundo conductor . 
162)  Si el anch o de la pantalla no permite visualizar por defe cto el modo de funcionamient o, el aparato de 
control mostrará unos instantes el nuevo modo de funcionamient o cuando cambie. 
163)  El aparat o de control mostrará unos instantes el nombre del titular de la tarjeta en el momento de 
inser tar la tarjeta. 26.5.2016 L 139/42 Diar io Oficial de la Unión Europea ES    
164)  Cuando se abra una condición «FUERA DE ÁMBITO» o «TRA YECTO EN TRANSBORD ADOR/TREN», 
el contenido de la pantalla por defecto deberá mostrar , con el pictograma correspondiente, que la 
condición está abier ta (se admit e que no aparezca simultáneamente en pantalla la actividad actual del 
conductor). 
3.15.2  Visualización de advertencias 
165)  Para las adver tencias que muestre en pantalla el aparat o de control se utilizarán principalment e los 
pictogramas del apéndice 3, compl etados cuando sea necesar io por información adicional codif icada 
en forma numér ica. También se podrá añadir una descr ipción literal de la adver tencia en el idioma 
prefer ido del conductor . 
3.15.3  Acceso mediante menús 
166)  El aparat o de control ofrecerá los comandos necesar ios 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 selectiva y a volun tad, los siguiente s datos : 
—  la fecha y la hora UTC, junto con el desf ase horar io local, 
—  el cont enido de cualquiera de los siete documentos impresos, con el mismo formato que el 
propio documento, 
—  el tiempo de conducción continua y el tiempo de descanso acumulado del conduct or, 
—  el tiempo de conducción continua y el tiempo de descanso acumulado del segundo conduct or, 
—  el tiempo de conducción acumulado del conduct or durant e la semana anterior y la actual, y 
—  el tiempo de conducción acumulado del segundo conduct or durant e la semana anterior y la 
actual. 
Datos opcionales: 
—  la duración actual de la actividad del segundo conduct or (desde que la seleccionara), 
—  el tiempo de conducción acumulado del conduct or durant e la semana actual, 
—  el tiempo de conducción acumulado del segundo conductor durante el período de trabajo diar io 
actual, 
—  el tiempo de conducción acumulado del conduct or durant e el período de traba jo diar io actual. 
168)  El conte nido 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 caracteres, el usuar io dispondrá de un medio adecuado para 
visualizar la información compl eta (var ias líneas, desplazamiento del texto, …). 
No es necesar io que aparezcan en pantalla las líneas del documento impreso destinadas a informa­
ciones manuscr itas. 
3.16  Impresión 
169)  El aparat o de control deberá ser capaz de imprimir la información almacenada en su memor ia o en 
las tarjetas de tacógraf o. Habrá al menos siete tipos de documentos de imp resión: 
—  impresión diar ia de las actividades del conductor almacenadas en la tarjeta, 
—  impresión diar ia de las actividades del conductor 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écn icos, 26.5.2016 L 139/43 Diar io Oficial de la Unión Europea ES    
—  impresión de excesos de velocidad, 
—  histo rial de los datos de la tarjeta de tacógraf o para una determinada VU (véase el 
capítulo 3.12.16). 
Los pormenores relativ os 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 aparat o de control también podrá imprimir otros documentos, siempr e que puedan distinguirse 
claramente de los siete arriba indicados. 
170)  La «impresión diar ia de las actividades del conduct or almacenadas en la tarjeta» y la «impr esión de 
incidentes y fallos almacenados en la tarjeta» solo estarán disponibles cuando se inser te 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 correspondiente antes de iniciar la impresión. 
171)  A fin de obtener la «impr esión diar ia de las actividades del conduct or almacenadas en la tarjeta» o la 
«impresión de incidentes y fallos almacenados en la tarjeta», el aparat o de control deberá: 
—  seleccionar automáticament e la tarjeta de conduct or o la tarjeta de taller , si solo se ha inser tado 
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 aparat o de control se han inser tado las dos tarjetas. 
172)  La impresora deberá ser capaz de impr imir 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 caract eres especifi cados en el apéndice 1, capítulo 4: «Conjunt os 
de caracteres». 
175)  Las impresor as estarán diseñadas de tal forma que faciliten los documentos de impresión arriba 
mencionados con la definición necesar ia para evitar ambigüedades en la lectura. 
176)  Los document os de impresión conser varán sus dimensiones y registros en las condiciones normales 
de humedad (10-90 %) y temperatura. 
177)  El tipo de papel homolog ado utilizado por el aparat o de control llevará la marca de homologació 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 almacenamiento en lo que respecta a intensidad 
luminosa, humedad y temperatura, los documento de impresión seguirán siendo claramente legibles e 
identif icables durant e al menos dos años. 
179)  Las impresiones se ajustarán, como mínimo, a las especific aciones de ensa yo que figur an en el 
apéndice 9. 
180)  Además, deberá ser posible incluir en los citados document os inscr ipciones 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 nuev o rollo 
el aparat o de control deberá reiniciar la impresión desde la primera línea o bien continuar la 
impresión incluy endo una referencia inequív oca a la parte ya impresa. 
3.17  Advertencias 
182)  El aparat o de control deberá avisar al conduct or cuando detecte algún incidente o fallo. 
183)  La adver tencia por un incident e de interr upción del suministro eléctr ico podrá hacerse cuando se 
restablezca el suministro. 26.5.2016 L 139/44 Diar io Oficial de la Unión Europea ES    
184)  El aparato de control deberá avisar al conduct or quince minutos antes y en el preciso instante en que 
se exce da el límite de tiempo de conducción continua permitido. 
185)  Las señales de adver tencia serán visuales, aunque también se podrán instalar señales de tipo acústico. 
186)  Las señales de adver tencia visuales deberán ser perfectamente reconocibles para el usuar io, estarán 
ubicadas dentro del campo de visión del conduct or y podrán leerse clarament e tanto de día como de 
noche. 
187)  Los avisadores luminosos podrán estar incor porados en el aparat o de control o separados de él. 
188)  En este último caso, el avisador mostrará una «T». 
189)  Las señales de adver tencia tendrán una duración de al menos treinta segundos, a menos que el 
usuar io las conf irme pulsando una o más teclas específicas del aparat o de control. Esta primera 
conf irmación no hará que desaparezca la indicación en pantalla del motivo de la adver tencia (véase el 
párrafo siguiente). 
190)  El motiv o de la adver tencia se indicará en la pantalla del aparat o de control y permanecerá visible 
hasta que lo conf irme el usuar io mediante una tecla o un comando específi co del aparat o de control. 
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  Transf erencia de datos a medios exter nos 
192) El aparat o de control, a petición del usuar io, deberá ser capaz de transferi r a medios de almacena ­
miento exte rnos los datos conte nidos en la memor ia o en una tarjeta de conductor , utilizando para 
ello el conector de calibrado/transfe rencia. El aparat o de control actualizará los datos almacenados en 
la tarjeta correspondiente antes de iniciar la transferencia. 
193) Asimismo, y como caract erística opcional, el aparat o de control podrá, en cualquier modo de funcio ­
namiento, transferir datos por cualquier otro medio a una empr esa aute ntifi cada 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. 
194)  La transferencia no deberá alter ar ni borrar los datos almacenados. 
195)  Las caract erísticas de la interfaz eléctr ica del conect or de calibrado/transf erencia se especifi can en el 
apéndice 6. 
196)  Los protocolos de transferencia se especifican en el apéndice 7. 
3.19  Comunicación a distancia para controles de carretera selectiv os 
197)  Cuando el encendido esté activado, la unidad instalada en el vehículo deberá almacenar cada sesenta 
segundos en el dispositivo de comunicación a distancia los datos más recientes necesar ios a efectos 
de los controles en carretera selectiv os. Estos datos se cifrarán y firmarán según lo especific ado en el 
apéndice 11 y el apéndice 14. 
198)  Los datos que deben ser controlados a distancia estarán disponibles para los lectore s de 
comunicación a distancia mediante comunicaciones inalámbr icas, tal como se especifica en el 
apéndice 14. 
199)  Los datos necesar ios a efect os de los controles en carretera selectivos deberán estar relacionados con: 
—  el intento más reciente de violación de la segur idad, 
—  la interrupción más larga del suministro eléctr ico, 26.5.2016 L 139/45 Diar io Oficial de la Unión Europea ES    
—  un fallo del sensor , 
—  un error en los datos de movimient o, 
—  un conf licto de movimient o del vehículo, 
—  la conducción sin tarjeta válida, 
—  la inserción de la tarjeta mientras se conduce, 
—  los datos de ajust e de la hora, 
—  los datos sobre el calibrado, incluidas las fechas 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ógraf o. 
3.20  Envío de datos a dispositiv os exter nos adicionales 
200)  El aparat o de control podrá ir también equipado de interfaces normalizadas que permitan que un 
aparato extern o utilice en modo operativo o de calibrado los datos registrados o producidos por el 
tacógraf o. 
En el apéndice 13 se especifi ca y normaliza una interfaz ITS opcional. Podrán coexistir otras 
interfaces similares, siempre que se cumplan plenamente los requisitos del apéndice 13 en térm inos 
de lista mínima de datos, segur idad y consentimiento del conduct or. 
Se aplicarán los siguient es requisitos a los datos de ITS facilitados a través de esa interfaz: 
—  estos datos constituirán una selección de los datos existen tes a partir del diccionar io de datos del 
tacógraf o (apéndice 1), 
—  un subconjunto de esta selección de datos se identificará como «dato s personales», 
—  el subconjunto de «datos personales» solo estará disponible si está habilitado el consentimient o 
verificable del conduct or, aceptando que sus datos personales puedan abandonar la red del 
vehículo, 
—  en cualquier momento, podrá habilitarse o inhabilitarse el consentimient o del conduct or a través 
de comandos del menú, siempr e que esté inser tada la tarjeta de conduct or, 
—  la selección y el subconjunto de datos se emitirán a través del protocolo inalámbr ico Bluetooth en 
el radio de la cabina del vehículo, con una frecuencia de refresco de un minuto, 
—  el emparejamient o del dispositivo exterior con la interfaz ITS estará protegido por un PIN 
aleatorio y dedicado de al menos cuatro dígitos, registrado y disponible a través de la pantalla de 
cada unidad instalada en el vehículo, 
—  en ninguna circunstancia podrá la presencia de la interf az ITS perturbar ni alter ar el correcto 
funcionamient o y la segur idad de la unidad instalada en el vehículo. 
También se podrán enviar otros datos, además de la selección de datos existen tes, que se considera la 
lista mínima, siempr e que no se puedan considerar datos personales. 
El aparat o de control deberá notificar a otros dispositivo s extern os el consentimient o del conduct or. 
Cuando el encendido del vehículo esté activado (ON), estos datos se envi arán de manera permanente. 
201)  La interfaz de conexión en serie especifi cada en el anex o 1B del Reglamento (CEE) n.o 3821/85, en su 
última versión modificada, podrá seguir equipando los tacógraf os a efectos de retrocompatibilidad. 
De todos modos, seguirá siendo necesar io el consentimient o del conductor en caso de transmisión de 
datos personales. 26.5.2016 L 139/46 Diar io Oficial de la Unión Europea ES    
3.21  Calibrado 
202)  La función de calibrado deberá permitir: 
—  el emparejamiento automático del sensor de movimiento con la VU, 
—  el acoplamient o automático del dispositivo GNSS extern o con la VU, en su caso, 
—  la adaptación digital de la constante del aparat o de control (k) al coeficiente caracterís tico del 
vehículo (w), 
—  el ajuste de la hora actual dentro del período de validez de la tarjeta de taller inser tada, 
—  el ajuste de la lectura actual del cuentakilómetros, 
—  la actualización de los datos de identif icación del sensor de movimient o que hay almacenados en 
la memor ia de datos, 
—  la actualización, en su caso, de los datos de identif icación del dispositivo GNSS externo que hay 
almacenados en la memor ia de datos, 
—  la actualización de los tipos y los identificadores de todos los precint os existent es, 
—la actualización o conf irmación de otros parámetros que conozca el aparat o de control: identifi ­
cación del vehículo, w, l, tamaño de los neumáticos y valor de ajuste del dispositivo limitador de 
la velocidad, en su caso. 
203)  Además, la función de calibrado permitirá supr imir la utilización de las tarjetas de tacógraf o de 
primera generación en el aparat o de control, siempr e que se cumplan las condiciones especificadas en 
el apéndice 15. 
204)  El empa rejamiento del sensor de movimiento con la VU deberá constar al menos de los siguiente s 
pasos: 
—  actualización (si es preciso) de los datos relativos a la instalación del sensor de movimient o, 
almacenados en el propio sensor de movimient o, 
—  copia, en la memor ia de datos de la VU, de los datos necesar ios para la identificaci ón del sensor 
de movimiento, almacenados en el propio sensor de movimient o. 
205)  El acoplamient o del dispositivo GNSS externo con la VU deberá constar al menos de los siguient es 
pasos: 
—  actualización (si es preciso) de los datos relativos al dispositivo GNSS extern o almacenados en el 
propio dispositivo GNSS exte rno, 
—  copia, en la memor ia de datos de la VU, de los datos necesar ios para la identificación del 
dispositivo GNSS externo, almacenados en el propio dispositivo GNSS externo, incluido el 
número de serie de este dispositivo . 
El acoplamiento irá seguido de la verificació n de la información de posición GNSS. 
206)  La función de calibrado deberá ser capaz de introducir todos los datos necesar ios a través del 
conector de calibrado/transfe rencia, de acuerdo con el protocolo de calibrado definido en el apéndice 
8. La función de calibrado también podrá utilizar otros medios para introducir los datos necesar ios. 
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 sensor de 
movimient o (posiblement e integrado en el adapta dor) 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. 26.5.2016 L 139/47 Diar io Oficial de la Unión Europea ES    
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 especificada 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 ECU AdjustmentSession, tal como se especifica en el apéndice 8, 
sección 7, «Control de los impulsos de prueba — Unidad funcional para control de entrada/salida». 
3.23  Ajuste de la hora 
210)  La función de ajust e de la hora deberá permitir el ajust e automá tico de la hora actual. En el aparat o 
de control se utilizan dos fuent es para el ajust e de la hora: 1) el reloj interno de la VU, 2) el recep tor 
GNSS. 
211)  La hora del reloj interno de la VU se reajustará automáticament e a inter valos de doce horas como 
máximo. Cuando este plazo haya expirado y no se disponga de señal GNSS, se fijará la hora tan 
pronto como la VU pueda acceder a una hora válida facilitada por el recep tor GNSS, según las 
condiciones de encendido del vehículo. La referencia temporal para la fijación automática de la hora 
del reloj interno de la VU se derivará del recep tor GNSS. Se producirá un incident e de conf licto 
temporal si la hora actual se desvía más de un (1) minut o de la información horar ia suministrada por 
el recep tor GNSS. 
212)  La función de ajuste de la hora deberá permitir también el ajuste de la hora actual, en el modo de 
calibrado. 
3.24  Caracterís ticas de funcionamient o 
213)  La unidad instalada en el vehículo deberá funcionar perfectamente en el inter valo de temperaturas 
que va de – 20 °C a 70 °C, el dispositivo GNSS externo en el inter valo de – 20 °C a 70 °C, y el 
sensor de movimiento en el inter valo de – 40 °C a 135 °C. El contenido de la memor ia de datos no 
se borrará aunque la temperatura descienda hasta – 40 °C. 
214)  El aparat o de control deberá funcionar perfectamente en el inter valo higrométr ico del 10 % al 90 %. 
215)  Los precint os utilizados en el tacógraf o digital deberán resistir las mismas condiciones aplicables a los 
compo nentes del tacógraf o en el que estén colocados. 
216)  El aparat o de control deberá estar protegido frente a sobretensiones, inversiones de polar idad de la 
fuente de alimentación y cortocircuit os. 
217)  Los sensores de movimient o: 
—  reaccionarán a todo campo magnético que perturbe la detección de movimient o del vehículo; en 
estas circunstancias, la unidad instalada en el vehículo registrará y almacenará un fallo del sensor 
(requisito 88), o bien 
—  estarán dotados de un sensor prote gido de los campos magnéticos o invulnerable a estos. 
218) El aparat o de control y el dispositivo GNSS externo deberán ajustarse a la reglamentación interna­
cional UN ECE R10 y estar protegidos contra descarg as electrostáticas y fluctuaciones de la tensión. 
3.25  Mater iales 
219)  Todos los elementos que formen parte del aparat o de control deberán estar fabricados con mater iales 
de estabilidad y resist encia mecánica suficie ntes y de caract erísticas eléctr icas y magnéticas inva riables. 
220)  Para unas condiciones normales de utilización, todas las partes internas del aparat o deberán estar 
protegidas contra la humedad y el polv o. 
221)  La unidad instalada en el vehículo y el dispositivo GNSS exte rno deberán tener el grado de protección 
IP 40 y el sensor de movimient o el grado de protección IP 64, según la norma IEC 60529:1989, 
incluidos A1:1999 y A2:2013. 26.5.2016 L 139/48 Diar io Oficial de la Unión Europea ES    
222)  El aparat o de control deberá ser conf orme a todas las especifi caciones técn icas aplicables relativas al 
diseño ergonómico. 
223)  El aparat o de control deberá estar protegi do frente a daños accidentales. 
3.26  Marcas 
224)  Si el aparat o de control permite visualizar la lectura del cuentakilómetros y la velocidad del vehículo, 
en su pantalla deberán figurar las precisiones siguiente s: 
—  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 aparat o 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 aparat o 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 abreviatura «mi». 
225)  Cada uno de los compo nente s del aparat o de control deberá llevar una placa descr iptiva con la 
información siguient e: 
—  nombre y dirección del fabr icante del aparat o, 
—  número de pieza del fabricante y año de fabricación del aparato, 
—  número de serie del aparat o, 
—  marca de homologació n del modelo de aparato de control. 
226)  Cuando el espacio físico disponible no baste para mostrar todas las informaciones mencionadas, en la 
placa descr iptiv a deberá figurar al menos: el nombre o el logotipo del fabricante y el número de 
pieza del aparato. 
4  CON DICIONES DE FABRICA CIÓN Y FUNCIONAMIENTO DE LAS TARJET AS DE TACÓGRAFO 
4.1  Dat os visibles 
El anverso de la tarjeta contendrá: 
227)  la mención «Tarjeta de conduct or» 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 tarjeta, 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 negativ o en un rectángulo azul 
rodeado de doce estrellas amar illas; los distintivos serán los siguient es: 
B 
BG 
CZ 
CY Bélgica 
Bulgar ia 
República Checa 
Chipre LV 
L 
LT 
M Leto nia 
Luxemburgo 
Lituania 
Malta 
DK Dinamarca NL Países Bajos 26.5.2016 L 139/49 Diar io Oficial de la Unión Europea ES    
D 
EST Alemania 
Estonia A 
PL Aust ria 
Polonia 
GR Grecia P 
RO 
SK 
SLO Portugal 
Rumanía 
Eslo vaquia 
Eslo venia 
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 expedida, que constarán del siguiente modo:  
Tarjeta de conductor Tarjeta de control Tarjeta de empresa o de taller 
1. apellido(s) del conductor nombre del organismo de 
control nombre de la empr esa o del 
taller 
2. nombre(s) del conduct or apellido(s) del controlador 
(en su caso) apellido(s) del titular de la tar­
jeta 
(en su caso) 
3. fecha de nacimient o del con­
ductor nombre(s) del controlador 
(en su caso) nombre(s) del titular de la tar­
jeta 
(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 autori dad expedidora (puede figurar en el reverso) 
4.d un número distint o del que se recoge en la rúbr ica 5, que sea útil para la gestión de la tarjeta 
(opcional) 
5. a número del permiso de con­
ducir 
(en la fecha de expedición de 
la tarjeta de conductor) — — 
5. b Número de tarjeta 
6. fotografía del conductor fotografía del controlador 
(opcional) fotografía del instalador (op­
cional) 26.5.2016 L 139/50 Diar io Oficial de la Unión Europea ES    
Tarjeta de conductor Tarjeta de control Tarjeta de empresa o de taller 
7. firma del titular (opcional) 
8. lugar de residencia habitual, 
o dirección postal del titular 
(opcional) dirección postal del orga ­
nismo de control dirección postal de la empresa 
o taller  
231)  las fechas deberán escr ibirse con el formato «dd/mm/aaaa» o bien «dd.mm.aaaa» (día, mes, año). 
El reverso de la tarjeta conte ndrá: 
232)  una explicación de las rúbr icas numeradas que aparecen en el anverso de la tarjeta; 
233)  con autorización expresa por escr ito 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ógraf o. 
234)  Las tarjetas de tacógraf o deberán imprimirse con los siguientes colores de fondo predominante s:  
— tarjeta del conduct or:blanco,  
— tarjeta de control: azul,  
— tarjeta de taller: rojo,  
— tarjeta de empresa: amar illo. 
235)  Las tarjetas de tacógraf o deberán reunir al menos las siguiente s caract erísticas de prot ección contra 
intent os de falsificación y manipulación: 
—  un fondo con diseño de segur idad, fondo labrado e imp resión en arco iris, 
—  en la zona de la fotografía, el fondo con diseño de segur idad y la fotografía deberán solaparse, 
—  al menos una línea de microimpresió n bicolor .  26.5.2016 L 139/51 Diar io Oficial de la Unión Europea ES    
236)  Previa consulta a la Comisión, los Estados miembros podrán añadir colores o inscr ipciones, tales 
como símbolos nacionales y características de segur idad, sin perjuicio de las demás disposiciones del 
presente anex o. 
237)  Las tarjetas temporales a que se refiere el artículo 26, apar tado 4, del Reglamento (UE) n.o 165/2014 
deberán cumplir lo dispuesto en el present e anex o. 
4.2  Segur idad 
La segur idad del sistema tiene por misión prote ger la integridad y autenti cidad de los datos que 
inter cambian las tarjetas y el aparato de control, proteg er la integr idad y la autenticidad de los datos que se 
transfieren de las tarjetas, permitir deter minadas operaciones de escr itura en las tarjetas por parte del 
aparat o de control excl usivamente , descifrar algunos datos, descar tar toda posibilidad de falsif icación de los 
datos almacenados en las tarjetas, imp edir la manipulación y detectar todo intent o en este sentido. 
238)  Al objeto de lograr la segur idad del sistema, las tarjetas de tacógraf o deberán cumpli r los requisitos 
de segur idad que se definen en los apéndices 10 y 11. 26.5.2016 L 139/52 Diar io Oficial de la Unión Europea ES    
239)  Las tarjetas de tacógraf o podrán leerse con otros equipos, como por ejemplo ordenadores personales. 
4.3  Nor mas 
240)  Las tarjetas de tacógraf o deberán ajustarse a las normas siguiente s: 
—  ISO/IEC 7810 Tarjetas de identif icación — Caracter ísticas físicas. 
—  ISO/IEC 7816 Tarjetas de identif icación — Tarjetas con circuit os integrad os, 
—  Parte 1: Caracter ísticas físicas, 
—  Parte 2: Dimensiones y ubicación de los contact os (ISO/IEC 7816-2:2007), 
—  Parte 3: Interfa z eléctr ica y prot ocolos de transmisión (ISO/IEC 7816-3:2006), 
—  Parte 4: Org anización, segur idad y comandos para los inter cambios (ISO/IEC 7816-4:2013 + 
Cor 1:2014), 
—  Parte 6: Elementos de datos intersector iales para los inter cambios (ISO/IEC 7816-6:2004 + 
Cor 1:2006), 
—  Parte 8: Comandos para las operaciones de segur idad (ISO/IEC 7816-8: 2004). 
—  Las tarjetas de tacógraf o deberán somet erse a ensa yo con arreglo a la norma ISO/IEC 10373- 
3:2010 (Tarjetas de identificación — Métodos de ensa yo — Parte 3: Tarjetas con circuitos 
integrad os con contactos y dispositivo s de interfaz conex os. 
4.4  Especif icaciones ambienta les y eléctr icas 
241)  Las tarjetas de tacógraf o deberán estar en condiciones de funcionar correctamente bajo cualquier 
condición climática habitual en el territorio de la Comunidad y al menos en el inter valo de 
temperaturas comprendido entre – 25 °C y + 70 °C, con picos ocasionales de hasta + 85 °C 
(«ocasional» 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 correctamente en el inter valo de humedad comprendido entre el 
10 % y el 90 %. 
243)  Las tarjetas de tacógraf o deberán poder funcionar correctamente durant e cinco años si se utilizan con 
arreglo a las especificaciones ambientales y eléctr icas. 
244)  Por lo que respecta a su funcionamiento, las tarjetas deberán ajus tarse a ECE R10, en relación con la 
compatib ilidad electromagnética, y deberán estar prote gidas contra descargas electrostáticas. 
4.5  Almacenamient o de datos 
A efect os del presente apar tado: 
—  las horas se registran con una resolución de un minuto, a menos que se especifique lo contrar io, 
—  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 
minut o. 
Las funciones, comandos y estructuras lógicas de las tarjetas de tacógraf o, por lo que respecta al 
cumplim iento 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ógraf o 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 memor ia prevista para los registros específi cos se agot e. 26.5.2016 L 139/53 Diar io Oficial de la Unión Europea ES    
245)  En este apar tado se especifica la capacidad mínima de almacenamiento de los diferentes archiv os de 
datos de la aplicación. Las tarjetas de tacógraf o deberán ser capaces de indicar al aparato de control la 
capacidad real de almacenamient o de dichos archiv os. 
246)  Cualquier dato adicional que pueda almacenarse en una tarjeta de tacógraf o, relacionado con otras 
aplicaciones eventualmente alojadas en la tarjeta, deberá almacenarse de conf ormidad con la Directiva 
95/46/CE, y con la Directiva 2002/58/CE, y dando cumplim iento al artículo 7 del Reglamento (UE) 
n.o 165/2014. 
247)  Cada archiv o maestro (MF) de cualquier tarjeta de tacógraf o deberá contener hasta cinco archiv os 
elementales (EF) refer idos a la gestión de la tarjeta, identif icaciones de la aplicación y del chip, y dos 
archiv os dedicados (DF): 
—  DF Tachog raph, que contiene la aplicación accesible a las unidades instaladas en vehículos de 
primera generación, que también está present e en las tarjetas de tacógraf o de primera generación, 
—  DF Tachograph_G2, que contiene la aplicación únicamente accesible a las unidades instaladas en 
vehículos de segunda generación, que solo está present e en las tarjetas de tacógraf o de segunda 
generación. 
Los detalles de la estructura de las tarjetas de tacógraf o se especifican íntegramente en el apéndice 2. 
4.5.1  Archivos elementales para la identificación y la gestió n de la tarjeta 
4.5.2  Identific ación de la tarjeta CI 
248)  Las tarjetas de tacógraf o deberán ser capaces de almacenar los siguient es datos para la identificación 
de la tarjeta inteligent e: 
—  parada de reloj, 
—  número de serie de la tarjeta (incluidas referencias de fabr icación), 
—  número de homolog ación de la tarjeta, 
—  identif icación personal de la tarjeta (ID), 
—  ID del integrad or, 
—  identif icador del CI. 
4.5.2.1  Identificaci ón del chip 
249)  Las tarjetas de tacógraf o deberán ser capaces de almacenar los siguient es datos para la identificación 
del circuit o integrado (CI): 
—  número de serie del CI, 
—  referen cias de fabricación del CI. 
4.5.2.2  DIR (presente solo en las tarjetas de tacógraf o de segunda generación). 
250)  Las tarjetas de tacógraf o deberán ser capaces de almacenar los objeto s de datos de identif icación de la 
aplicación especificados en el apéndice 2. 
4.5.2.3  Información ATR (condicionalmente, presente solo en las tarjetas de tacógraf o de 
segunda generación). 
251)  Las tarjetas de tacógraf o deberán ser capaces de almacenar el siguient e objeto de datos de 
información de longitud exte ndida: 
—  en el caso de que la tarjeta de tacógraf o acept e campos de longitud exte ndida, el objeto de datos 
de información de longitud extendida especific ado en el apéndice 2. 26.5.2016 L 139/54 Diar io Oficial de la Unión Europea ES    
4.5.2.4  Información de longitud extendida (condicionalmente , present e solo en las tarjetas de 
tacógraf o de segunda generación). 
252)  Las tarjetas de tacógraf o deberán ser capaces de almacenar los siguiente s objetos de datos de 
información de longitud exte ndida: 
—  en el caso de que la tarjeta de tacógraf o acept e campos de longitud exte ndida, los objeto s de 
datos de información de longitud extendida especifi cados en el apéndice 2. 
4.5.3  Tarjeta de conductor 
4.5.3.1  Aplicación del tacógraf o (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 
253)  La tarjeta del conductor deberá ser capaz de almacenar los siguient es datos de identif icación de la 
aplicación: 
—  identif icación de la aplicación del tacógraf o, 
—  identif icación del tipo de tarjeta de tacógraf o. 
4.5.3.1.2  Clave y certificados 
254) La tarjeta de conduct or deberá ser capaz de almacenar una serie de claves y certificados cripto­
gráfi cos, según lo especifi cado 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 almacenar los siguiente s datos de identif icación de la 
tarjeta: 
—  número de tarjeta, 
—  nombre del Estado miembro y de la autor idad 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 almacenar los siguient es datos de identif icación del titular 
de la tarjeta: 
—  apellido(s) del titular , 
—  nombre(s) del titular , 
—  fecha de nacimiento, 
—  idioma prefer ido. 
4.5.3.1.5  Transf erencia de los datos de la tarjeta 
257) La tarjeta de conduct or deberá ser capaz de almacenar los siguiente s datos relativos a las transfe ­
rencias 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 conduct or deberá ser capaz de manten er almacenado uno de dicho s registros. 
4.5.3.1.6  Información sobre el permiso de conducir 
259)  La tarjeta de conduct or deberá ser capaz de almacenar los siguient es datos sobre el permiso de 
conducir: 
—  Estado miembro y autoridad que hayan expedido el permiso, 
—  número del permiso de conducir (en la fecha de expedición de la tarjeta). 26.5.2016 L 139/55 Diar io Oficial de la Unión Europea ES    
4.5.3.1.7  Datos sobre incident es 
A efect os del presente subapar tado, la hora se almacenará con una resolución de un segundo. 
260)  La tarjeta de conduct or deberá ser capaz de almacenar los datos relativ os a los siguiente s incident es 
detec tados por el aparat o de control con la tarjeta inser tada: 
—  solapamient o 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 incident e), 
—  error al cerrar la última sesión de la tarjeta (cuando esa tarjeta sea el objeto del incident e), 
—  interr upción del suministro eléctr ico, 
—  error en datos de movimient o, 
—  intent os de violación de la segur idad: 
261)  La tarjeta de conduct or deberá ser capaz de almacenar los siguient es datos sobre dichos incident es: 
—  código del incident e, 
—  fecha y hora en que comenzó el incident e (o en que se inser tó la tarjeta, si el incident e estaba 
ocur riendo en ese momento) , 
—  fecha y hora en que terminó el incident e (o en que se extrajo la tarjeta, si el incident e estaba 
ocur riendo en ese momento) , 
—  VRN y Estado miembro donde se matr iculó el vehículo en el que ocur rió el incident e. 
Nota: por lo que respecta al incidente de «solapamiento temporal»: 
—  la fecha y hora en que comenzó el incidente deberán coincidir con la fecha y hora en que se 
extra jo la tarjeta del vehículo anterior, 
—  la fecha y hora en que terminó el incident e deberán coincidir con la fecha y hora en que se 
inser tó 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 incident e. 
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 incident e 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ó correc­
tamente . 
262)  La tarjeta de conduct or deberá ser capaz de almacenar los datos correspondiente s a los seis incidentes 
más reciente s de cada tipo (es decir , un total de 36 incident es). 
4.5.3.1.8  Datos sobre fallos 
A efect os del presente subapar tado, la hora se registrará con una resolución de un segundo. 
263)  La tarjeta de conductor deberá ser capaz de almacenar los datos relativos a los siguientes fallos 
detec tados por el aparat o de control estando la tarjeta inser tada: 
—  fallo de la tarjeta (cuando esa tarjeta sea el tema del incidente), 
—  fallo del aparat o de control. 26.5.2016 L 139/56 Diar io Oficial de la Unión Europea ES    
264)  La tarjeta de conduct or deberá ser capaz de almacenar los siguient es datos sobre dichos fallos: 
—  código de fallo, 
—  fecha y hora en que comenzó el fallo (o en que se inser tó la tarjeta, si el fallo estaba ocur riendo 
en ese momento) , 
—  fecha y hora en que term inó el fallo (o en que se extrajo la tarjeta, si el fallo estaba ocur riendo en 
ese momento) , 
—  VRN y Estado miembro donde se matr iculó el vehículo en el que ocur rió el fallo. 
265)  La tarjeta de conduct or deberá ser capaz de almacenar los datos correspondientes a los doce fallos 
más reciente s 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 almacenar , para cada día civil que se haya utilizado la 
tarjeta o para el cual el conduct or haya introducido actividades manualment e, los siguiente s datos: 
—  la fecha, 
—  un contador de presencia diar ia (incrementado en una unidad por cada uno de estos días civiles), 
—  la distancia total recor rida por el conduct or durant e ese día, 
—  el régimen de conducción a las 00.00 horas, 
—  cada vez que el conduct or cambie de actividad, o cambie el régimen de conducción, o inser te o 
extraig a su tarjeta: 
—  el régimen de conducción (EN EQUIPO, EN SOLIT ARIO), 
—  la ranura (CONDUCTOR, SEGUNDO CONDU CTOR), 
—  el estado de la tarjeta (INSER TADA, NO INSER TADA), 
—  la actividad (CONDUCCIÓN, DISPONIBILID AD, TRABAJO, PAUSA/ DESC ANSO), 
—  la hora del cambio. 
267)  La memor ia de la tarjeta de conductor deberá ser capaz de manten er almacenados durant e al menos 
veintiocho días los datos sobre la actividad del conduct or (la actividad media de un conduct or 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 ocur rencia, incluso en una situación de solapamiento 
temporal. 
4.5.3.1.10  Datos sobre vehículos empleados 
269)  La tarjeta de conductor deberá ser capaz de almacenar , 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 incluy e todos los ciclos 
consecutivos de inserción/extracción de la tarjeta en el vehículo, visto desde el punt o 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á utilizando 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á utilizando en ese 
momento) , 
—  valor del cuentakilómetros del vehículo en ese momento, 
—  VRN y Estado miembro donde se matr iculó el vehículo. 26.5.2016 L 139/57 Diar io Oficial de la Unión Europea ES    
270)  La tarjeta de conduct or deberá ser capaz de almacenar al menos 84 de estos registros. 
4.5.3.1.11  Lugares donde comienzan o term inan los períodos de traba jo diar ios 
271)  La tarjeta de conductor deberá ser capaz de almacenar los siguient es datos, que introduce el 
conductor , relativ os a los lugares donde comienzan o term inan los períodos de traba jo diar ios: 
—  la fecha y hora de la introducción (o la fecha/h ora relacionada con la introducción si esta tiene 
lugar durante el procedimiento de introducció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 memor ia de la tarjeta de conduct or deberá ser capaz de manten er almacenados al menos 42 pares 
de estos registros. 
4.5.3.1.12  Datos de la sesión 
273)  La tarjeta de conduct or deberá ser capaz de almacenar los datos relativ os 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 resolución de un 
segundo, 
—  VRN y Estado miembro donde se matr iculó el vehículo. 
4.5.3.1.13  Datos sobre actividades de control 
274)  La tarjeta de conduct or deberá ser capaz de almacenar los siguient es datos relativ os a las actividades 
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 transfer encia de los datos de la VU o transfe rencia de 
los datos de la tarjeta [véase la nota]), 
—  período transferi do, en caso de transfer encia, 
—  VRN y Estado miembro donde se matr iculó 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 conduct or deberá ser capaz de manten er almacenado uno de dicho s registros. 
4.5.3.1.14  Datos sobre condiciones específic as 
276)  La tarjeta de conduct or deberá ser capaz de almacenar los siguientes datos relativ os a las condiciones 
específi cas 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 conduct or deberá ser capaz de almacenar al menos 56 de estos registros. 26.5.2016 L 139/58 Diar io Oficial de la Unión Europea ES    
4.5.3.2  Aplicación de tacógraf o 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 
278)  La tarjeta del conductor deberá ser capaz de almacenar los siguient es datos de identif icación de la 
aplicación: 
—  identif icación de la aplicación del tacógraf o, 
—  identif icación del tipo de tarjeta de tacógraf o. 
4.5.3.2.2  Claves y certificados 
279) La tarjeta de conduct or deberá ser capaz de almacenar una serie de claves y certificados cripto­
gráfi cos, según lo especifi cado 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 almacenar los siguiente s datos de identif icación de la 
tarjeta: 
—  número de tarjeta, 
—  nombre del Estado miembro y de la autor idad 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 almacenar los siguient es datos de identif icación del titular 
de la tarjeta: 
—  apellido(s) del titular , 
—  nombre(s) del titular , 
—  fecha de nacimiento, 
—  idioma prefer ido. 
4.5.3.2.5  Transf erencia de los datos de la tarjeta 
282) La tarjeta de conduct or deberá ser capaz de almacenar los siguiente s datos relativos a las transfe ­
rencias 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 conduct or deberá ser capaz de manten er almacenado uno de dicho s registros. 
4.5.3.2.6  Información sobre el permiso de conducir 
284)  La tarjeta de conduct or deberá ser capaz de almacenar los siguient es datos sobre el permiso de 
conducir: 
—  Estado miembro y autoridad que hayan expedido el permiso, 
—  número del permiso de conducir (en la fecha de expedición de la tarjeta). 
4.5.3.2.7  Datos sobre incident es 
A efect os del presente subapar tado, la hora se almacenará con una resolución de un segundo. 26.5.2016 L 139/59 Diar io Oficial de la Unión Europea ES    
285)  La tarjeta de conduct or deberá ser capaz de almacenar los datos relativ os a los siguiente s incident es 
detec tados por el aparat o de control con la tarjeta inser tada: 
—  solapamient o 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 incident e), 
—  error al cerrar la última sesión de la tarjeta (cuando esa tarjeta sea el objeto del incident e), 
—  interr upción del suministro eléctr ico, 
—  error de comunicación con el dispositivo de comunicación a distancia, 
—  ausencia de información sobre la posición procedent e del recep tor GNSS, 
—  error de comunicación con el dispositivo GNSS externo, 
—  error en datos de movimient o, 
—  conf licto de movimient o del vehículo, 
—  intent os de violación de la segur idad, 
—  conf licto temporal. 
286)  La tarjeta de conduct or deberá ser capaz de almacenar los siguient es datos sobre dichos incident es: 
—  código del incident e, 
—  fecha y hora en que comenzó el incident e (o en que se inser tó la tarjeta, si el incident e estaba 
ocur riendo en ese momento) , 
—  fecha y hora en que terminó el incident e (o en que se extrajo la tarjeta, si el incident e estaba 
ocur riendo en ese momento) , 
—  VRN y Estado miembro donde se matr iculó el vehículo en el que ocur rió el incident e. 
Nota: por lo que respecta al incidente de «solapamiento temporal»: 
—  la fecha y hora en que comenzó el incidente deberán coincidir con la fecha y hora en que se 
extra jo la tarjeta del vehículo anterior, 
—  la fecha y hora en que terminó el incident e deberán coincidir con la fecha y hora en que se 
inser tó 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 incident e. 
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 incident e 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ó correc­
tamente . 
287)  La tarjeta de conduct or deberá ser capaz de almacenar los datos correspondiente s a los seis incidentes 
más reciente s de cada tipo (es decir , un total de 66 incident es). 
4.5.3.2.8  Datos sobre fallos 
A efect os del presente subapar tado, la hora se registrará con una resolución de un segundo. 26.5.2016 L 139/60 Diar io Oficial de la Unión Europea ES    
288)  La tarjeta de conductor deberá ser capaz de almacenar los datos relativos a los siguientes fallos 
detec tados por el aparat o de control estando la tarjeta inser tada: 
—  fallo de la tarjeta (cuando esa tarjeta sea el tema del incidente), 
—  fallo del aparat o de control. 
289)  La tarjeta de conduct or deberá ser capaz de almacenar los siguient es datos sobre dichos fallos: 
—  código de fallo, 
—  fecha y hora en que comenzó el fallo (o en que se inser tó la tarjeta, si el fallo estaba ocur riendo 
en ese momento) , 
—  fecha y hora en que term inó el fallo (o en que se extrajo la tarjeta, si el fallo estaba ocur riendo en 
ese momento) , 
—  VRN y Estado miembro donde se matr iculó el vehículo en el que ocur rió el fallo. 
290)  La tarjeta de conduct or deberá ser capaz de almacenar los datos correspondientes a los doce fallos 
más reciente s de cada tipo (es decir , un total de veinticuatro fallos). 
4.5.3.2.9  Datos sobre la actividad del conductor 
291)  La tarjeta de conductor deberá ser capaz de almacenar , para cada día civil que se haya utilizado la 
tarjeta o para el cual el conduct or haya introducido actividades manualment e, los siguiente s datos: 
—  la fecha, 
—  un contador de presencia diar ia (incrementado en una unidad por cada uno de estos días civiles), 
—  la distancia total recor rida por el conduct or durant e ese día, 
—  el régimen de conducción a las 00.00 horas, 
—  cada vez que el conduct or cambie de actividad, o cambie el régimen de conducción, o inser te o 
extraig a su tarjeta: 
—  el régimen de conducción (EN EQUIPO, EN SOLIT ARIO), 
—  la ranura (CONDUCTOR, SEGUNDO CONDU CTOR), 
—  el estado de la tarjeta (INSER TADA, NO INSER TADA), 
—  la actividad (CONDUCCIÓN, DISPONIBILID AD, TRABAJO, PAUSA/ DESC ANSO), 
—  la hora del cambio. 
292)  La memor ia de la tarjeta de conductor deberá ser capaz de manten er almacenados durant e al menos 
veintiocho días los datos sobre la actividad del conduct or (la actividad media de un conduct or se 
define como 93 cambios de actividad por día). 
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 ocur rencia, incluso en una situación de solapamiento 
temporal. 
4.5.3.2.10  Datos sobre vehículos empleados 
294)  La tarjeta de conductor deberá ser capaz de almacenar , 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 incluy e todos los ciclos 
consecutivos de inserción/extracción de la tarjeta en el vehículo, visto desde el punt o 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á utilizando en ese 
momento) , 26.5.2016 L 139/61 Diar io Oficial de la Unión Europea ES    
—  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á utilizando en ese 
momento) , 
—  valor del cuentakilómetros del vehículo en ese momento de último uso, 
—  VRN y Estado miembro donde se matr iculó el vehículo, 
—  VIN del vehículo. 
295)  La tarjeta de conduct or deberá ser capaz de almacenar al menos 84 de estos registros. 
4.5.3.2.11  Lugares y posiciones donde comienzan o term inan los períodos de traba jo diar ios 
296)  La tarjeta de conductor deberá ser capaz de almacenar los siguient es datos, que introduce el 
conductor , relativ os a los lugares donde comienzan o term inan los períodos de traba jo diar ios: 
—  la fecha y hora de la introducción (o la fecha/h ora relacionada con la introducción si esta tiene 
lugar durante el procedimiento de introducció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, 
—  la posición del vehículo, 
—  La exactitud del GNSS, fecha y hora en que se haya determinado la posición. 
297)  La memor ia de la tarjeta de conduct or deberá ser capaz de manten er almacenados al menos 84 pares 
de estos registros. 
4.5.3.2.12  Datos de la sesión 
298)  La tarjeta de conduct or deberá ser capaz de almacenar los datos relativ os 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 resolución de un 
segundo, 
—  VRN y Estado miembro donde se matr iculó el vehículo. 
4.5.3.2.13  Datos sobre actividades de control 
299)  La tarjeta de conduct or deberá ser capaz de almacenar los siguient es datos relativ os a las actividades 
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 transfer encia de los datos de la VU o transfe rencia de 
los datos de la tarjeta [véase la nota]), 
—  período transferi do, en caso de transfer encia, 
—  VRN y Estado miembro donde se matr iculó el vehículo en el que se produjera el control. 
Nota: las condiciones de segur idad implican que la transfer encia de los datos de la tarjeta solo 
quedará registrada si se lleva a cabo con un aparat o de control. 
300)  La tarjeta de conduct or deberá ser capaz de manten er almacenado uno de dicho s registros. 26.5.2016 L 139/62 Diar io Oficial de la Unión Europea ES    
4.5.3.2.14  Datos sobre condiciones específic as 
301)  La tarjeta de conduct or deberá ser capaz de almacenar los siguientes datos relativ os a las condiciones 
específi cas 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. 
302)  La tarjeta de conduct or deberá ser capaz de almacenar al menos 56 de estos registros. 
4.5.3.2.15  Datos utilizados en unidades instaladas en vehículos 
303)  La tarjeta de conduct or deberá ser capaz de almacenar los siguient es datos relativos a las diferentes 
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 perí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. 
304)  La tarjeta de conduct or deberá ser capaz de almacenar al menos 84 de estos registros. 
4.5.3.2.16  Datos sobre lugar es en tres horas de conducción continua 
305)  La tarjeta de conductor deberá ser capaz de almacenar los siguiente s datos relativ os a la posición del 
vehículo cuando el tiempo de conducción continua del conduct or alcance un múltiplo de tres horas: 
—  fecha y hora en las que el tiempo de conducción continua del titular de la tarjeta 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. 
306)  La tarjeta de conduct or deberá ser capaz de almacenar al menos 252 de estos registros. 
4.5.4  Tarjeta de taller 
4.5.4.1  Aplicación del tacógraf o (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 
307)  La tarjeta de taller deberá ser capaz de almacenar los siguient es datos de identif icación de la 
aplicación: 
—  identif icación de la aplicación del tacógraf o, 
—  identif icación del tipo de tarjeta de tacógraf o. 
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áfico s, 
según lo especifi cado en el apéndice 11, parte A. 26.5.2016 L 139/63 Diar io Oficial de la Unión Europea ES    
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 siguient es datos relativ os a la identificación de la 
tarjeta: 
—  número de tarjeta, 
—  nombre del Estado miembro y de la autor idad 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.1.4  Identificaci ón del titular de la tarjeta 
311)  La tarjeta de taller deberá ser capaz de almacenar los siguientes datos relativ os 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 prefer ido. 
4.5.4.1.5  Transf erencia de los datos de la tarjeta 
312)  La tarjeta de taller deberá ser capaz de almacenar un registro de datos sobre transfer encias de la 
tarjeta, del mismo modo que una tarjeta de conduct or. 
4.5.4.1.6  Datos de calibrado y de ajust e de la hora 
313)  La tarjeta de taller deberá ser capaz de manten er almacenados los registros de los calibrados o ajustes 
de hora que se hayan realizado mientras la tarjeta está inser tada en el aparat o de control. 
314)  Cada registro de calibrado deberá ser capaz de manten er almacenados los datos siguient es: 
—  propósito del calibrado (activación, primera instalación, instalación, control periódico), 
—  identif icación del vehículo, 
—  parámetros que se actualizan o conf irman (w, k, l, tamaño de los neumáticos, valor de ajuste del 
dispositivo limitador de la velocidad, cuentakilómetros (lectura anterior y nueva lectura), fecha y 
hora (valor anterior y nuevo valor), 
—  identif icación del aparat o 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 hayan 
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 transfe rencia. 26.5.2016 L 139/64 Diar io Oficial de la Unión Europea ES    
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 incident es más recientes de 
cada tipo (es decir , dieciocho incident es) y de los seis fallos más recientes de cada tipo (es decir , doce 
fallos). 
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 
conductor 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 empleado s, 
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 traba jo diar ios 
324)  La tarjeta de taller deberá ser capaz de almacenar los registros de datos sobre las horas de comienzo 
o final de los períodos de trabajo diar ios, del mismo modo que una tarjeta de conductor . 
325)  La tarjeta de taller deberá ser capaz de manten er 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 conduct or. 
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ífic as 
328)  La tarjeta de taller deberá ser capaz de almacenar los datos correspondientes a las condiciones 
específi cas, del mismo modo que la tarjeta de conduct or. 
329)  La tarjeta de taller deberá ser capaz de almacenar al menos dos de estos registros. 
4.5.4.2  Aplicación de tacógraf o 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 
330)  La tarjeta de taller deberá ser capaz de almacenar los siguient es datos de identif icación de la 
aplicación: 
—  identif icación de la aplicación del tacógraf o, 
—  identif icación del tipo de tarjeta de tacógraf o. 26.5.2016 L 139/65 Diar io Oficial de la Unión Europea ES    
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áfico s, 
según lo especifi cado 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 siguient es datos relativ os a la identificación de la 
tarjeta: 
—  número de tarjeta, 
—  nombre del Estado miembro y de la autor idad 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 relativ os 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 prefer ido. 
4.5.4.2.5  Transf erencia de los datos de la tarjeta 
335)  La tarjeta de taller deberá ser capaz de almacenar un registro de datos sobre transfer encias de la 
tarjeta, del mismo modo que una tarjeta de conduct or. 
4.5.4.2.6  Datos de calibrado y de ajust e de la hora 
336)  La tarjeta de taller deberá ser capaz de manten er almacenados los registros de los calibrados o ajustes 
de hora que se hayan realizado mientras la tarjeta está inser tada en el aparat o de control. 
337)  Cada registro de calibrado deberá ser capaz de manten er almacenados los datos siguient es: 
—  propósito del calibrado (activación, primera instalación, instalación, control periódico), 
—  identif icación del vehículo, 
—  parámetros que se actualizan o conf irman (w, k, l, tamaño de los neumáticos, valor de ajuste del 
dispositivo limitador de la velocidad, cuentakilómetros (lectura anterior y nueva lectura), fecha y 
hora (valor anterior y nuevo valor), 
—  identif icación del aparat o de control (número de pieza de la VU, número de serie de la VU, 
número de serie del sensor de movimient o, número de serie del dispositivo de comunicación a 
distancia y número de serie del dispositivo GNSS externo, si procede), 
—  tipo e identificador de todos los precintos existent es, 
—  capacidad de la VU para utilizar tarjetas de tacógraf o de la primera generación (habilitada o no). 26.5.2016 L 139/66 Diar io Oficial de la Unión Europea ES    
338)  La tarjeta de taller deberá ser capaz de almacenar al menos 88 de estos registros. 
339)  La tarjeta de taller deberá tener un contador que indique el número total de calibrados que se hayan 
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 transfe rencia. 
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 incident es más recientes de 
cada tipo (es decir , treinta y tres incident es) 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 . 
344)  La tarjeta de taller deberá ser capaz de mantener almacenados los datos sobre la actividad del 
conductor durante al menos un día de actividad media. 
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 empleado s, 
del mismo modo que una tarjeta de conductor . 
346)  La tarjeta de taller deberá ser capaz de almacenar al menos cuatro de estos registros. 
4.5.4.2.10  Datos sobre el comienzo y el final de los períodos de traba jo diar ios 
347)  La tarjeta de taller deberá ser capaz de almacenar los registros de datos sobre las horas de comienzo 
o final de los períodos de trabajo diar ios, del mismo modo que una tarjeta de conductor . 
348)  La tarjeta de taller deberá ser capaz de manten er almacenados al menos tres pares de estos registros. 
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 conduct or. 
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 
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 período), 
—  nombre del fabricante de la unidad instalada en el vehículo, 26.5.2016 L 139/67 Diar io Oficial de la Unión Europea ES    
—  tipo de unidad instalada en el vehículo, 
—  versión del software que lleva instalado la unidad instalada en el vehículo. 
352)  La tarjeta de taller deberá ser capaz de almacenar al menos cuatro de estos registros. 
4.5.4.2.14  Datos sobre lugar es en tres horas de conducción continua 
353)  La tarjeta de taller deberá ser capaz de almacenar los siguient es datos relativ os a la posición del 
vehículo cuando el tiempo de conducción continua del conduct or alcance un múltiplo de tres horas: 
—  fecha y hora en las que el tiempo de conducción continua del titular de la tarjeta 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. 
354)  La tarjeta de taller deberá ser capaz de almacenar al menos diecioch o de estos registros. 
4.5.4.2.15  Datos sobre condiciones específic as 
355)  La tarjeta de taller deberá ser capaz de almacenar los datos correspondientes a las condiciones 
específi cas, del mismo modo que la tarjeta de conduct or. 
356)  La tarjeta de taller deberá ser capaz de almacenar al menos dos de estos registros. 
4.5.5  Tarjeta de control 
4.5.5.1  Aplicación del tacógraf o (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 
357)  La tarjeta de control deberá ser capaz de almacenar los siguientes datos de identificación de la 
aplicación: 
—  identif icación de la aplicación del tacógraf o, 
—  identif icación del tipo de tarjeta de tacógraf o. 
4.5.5.1.2  Claves y certificados 
358)  La tarjeta de control deberá ser capaz de almacenar una serie de claves y certificados criptográficos, 
según lo especifi cado 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 almacenar los siguiente s datos relativ os a la identif icación de 
la tarjeta: 
—  número de tarjeta, 
—  nombre del Estado miembro y de la autor idad 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 almacenar los siguiente s datos relativos a la identif icación 
del titular de la tarjeta: 
—  nombre del organismo de control, 
—  dirección del organismo de control, 26.5.2016 L 139/68 Diar io Oficial de la Unión Europea ES    
—  apellido(s) del titular , 
—  nombre(s) del titular , 
—  idioma prefer ido. 
4.5.5.1.5  Datos sobre actividades de control 
361)  La tarjeta de control deberá ser capaz de almacenar los siguiente s datos sobre actividades de control: 
—  fecha y hora del control, 
—tipo de control (visualización y/o impresión y/o transferencia de los datos de la VU y/o transfe ­
rencia de los datos de la tarjeta y/o control del calibrado en carretera), 
—  período transferi do (en su caso), 
—  VRN y autori dad del Estado miembro donde se matr iculó el vehículo controlado, 
—  número de tarjeta y Estado miembro que haya expedido la tarjeta de conduct or que se controla. 
362)  La tarjeta de control deberá ser capaz de manten er almacenados al menos 230 de estos registros. 
4.5.5.2  Aplicación de tacógraf o 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 
363)  La tarjeta de control deberá ser capaz de almacenar los siguientes datos de identificación de la 
aplicación: 
—  identif icación de la aplicación del tacógraf o, 
—  identif icación del tipo de tarjeta de tacógraf o. 
4.5.5.2.2  Claves y certificados 
364)  La tarjeta de control deberá ser capaz de almacenar una serie de claves y certificados criptográficos, 
según lo especifi cado 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 almacenar los siguiente s datos relativ os a la identif icación de 
la tarjeta: 
—  número de tarjeta, 
—  nombre del Estado miembro y de la autor idad 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 almacenar los siguiente s datos relativos a la identif icació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 prefer ido. 26.5.2016 L 139/69 Diar io Oficial de la Unión Europea ES    
4.5.5.2.5  Datos sobre actividades de control 
367)  La tarjeta de control deberá ser capaz de almacenar los siguiente s datos sobre actividades de control: 
—  fecha y hora del control, 
—tipo de control (visualización y/o impresión y/o transferencia de los datos de la VU y/o transfe ­
rencia de los datos de la tarjeta y/o control del calibrado en carretera), 
—  período transferi do (en su caso), 
—  VRN y autori dad del Estado miembro donde se matr iculó el vehículo controlado, 
—  número de tarjeta y Estado miembro que haya expedido la tarjeta de conduct or que se controla. 
368)  La tarjeta de control deberá ser capaz de manten er almacenados al menos 230 de estos registros. 
4.5.6  Tarjeta de empresa 
4.5.6.1  Aplicación del tacógraf o (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 
369)  La tarjeta de empr esa deberá ser capaz de almacenar los siguient es datos de identif icación de la 
aplicación: 
—  identif icación de la aplicación del tacógraf o, 
—  identif icación del tipo de tarjeta de tacógraf o. 
4.5.6.1.2  Claves y certificados 
370)  La tarjeta de empresa deberá ser capaz de almacenar una serie de claves y certificados criptográficos, 
según lo especifi cado 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 siguient es datos relativ os a la identif icación 
de la tarjeta: 
—  número de tarjeta, 
—  nombre del Estado miembro y de la autor idad 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 siguient es datos relativ os a la identif icación 
del titular de la tarjeta: 
—  nombre de la empresa, 
—  dirección de la empresa. 
4.5.6.1.5  Datos sobre la actividad de la empr esa 
373)  La tarjeta de la empr esa 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 transfer encia de los datos de 
la VU o transfer encia de los datos de la tarjeta), 
—  período transferi do (en su caso), 26.5.2016 L 139/70 Diar io Oficial de la Unión Europea ES    
—  VRN y autori dad del Estado miembro donde se matr iculó el vehículo, 
—  número de tarjeta y Estado miembro que haya expedido la tarjeta (en caso de transferencia de los 
datos de la tarjeta). 
374)  La tarjeta de la emp resa deberá ser capaz de mantener almacenados al menos 230 de estos registros. 
4.5.6.2  Aplicación de tacógraf o 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 
375)  La tarjeta de empr esa deberá ser capaz de almacenar los siguient es datos de identif icación de la 
aplicación: 
—  identif icación de la aplicación del tacógraf o, 
—  identif icación del tipo de tarjeta de tacógraf o. 
4.5.6.2.2  Claves y certificados 
376)  La tarjeta de empresa deberá ser capaz de almacenar una serie de claves y certificados criptográficos, 
según lo especifi cado 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 siguient es datos relativ os a la identif icación 
de la tarjeta: 
—  número de tarjeta, 
—  nombre del Estado miembro y de la autor idad 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 siguient es datos relativ os a la identif icación 
del titular de la tarjeta: 
—  nombre de la empresa, 
—  dirección de la empresa. 
4.5.6.2.5  Datos sobre la actividad de la empr esa 
379)  La tarjeta de la empr esa 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 transfer encia de los datos de 
la VU o transfer encia de los datos de la tarjeta), 
—  período transferi do (en su caso), 
—  VRN y autori dad del Estado miembro donde se matr iculó el vehículo, 
—  número de tarjeta y Estado miembro que haya expedido la tarjeta (en caso de transferencia de los 
datos de la tarjeta). 
380)  La tarjeta de la emp resa deberá ser capaz de mantener almacenados al menos 230 de estos registros. 26.5.2016 L 139/71 Diar io Oficial de la Unión Europea ES    
5  INST ALACIÓN DEL APARA TO DE CONTR OL 
5.1  Inst alación 
381)  El aparat o de control nuevo deberá entregar se desactivado al instalador o al fabr icante del vehículo, 
con todos los parámetros de calibrado que se relacionan en el capítulo 3.21 configurad os según sus 
valores válidos por defect o. Si no existe un valor en particular que deba considerarse adecuado por 
defect o, los parámetros literales deberán conf igurarse con cadenas de interrogantes («?») y los valores 
numér icos deberán ajustarse a cero («0»). La entrega de piezas del aparato de control importantes 
para la segur idad podrá limitarse, si fuera necesar io, durante la certificació n de segur idad. 
382)  Antes de ser activado, el aparat o de control tendrá que dar acceso a la función de calibrado, aunque 
no se encuentre en el modo de calibrado. 
383)  Antes de ser activado, el aparato de control no deberá registrar ni almacenar los datos mencionados 
en los punt os 3.12.3, 3.12.9 y 3.12.12 a 3.12.15 inclusive. 
384)  Durante la instalación, el fabricant e del vehículo deberá preconfi gurar 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. 
386)  El aparato de control se activará automáticament e al inser tar por primera vez una tarjeta de taller 
válida en cualquiera de sus dispositivo s de interfaz para tarjetas. 
387)  Las operaciones específicas de emparejamient o que se precisan entre el sensor de movimient o y la 
unidad instalada en el vehículo, si las hay, deberán producirse automát icamente antes o durante la 
activación. 
388)  De forma semejante, las operaciones específicas de acoplamiento entre el dispositivo GNSS externo y 
la unidad instalada en el vehículo, si las hay, deberán producirse automáticament e antes o durante la 
activación. 
389)  Una vez activado, el aparat o de control deberá permitir el uso de todas las funciones y derechos de 
acceso a los datos. 
390)  Una vez activado, el aparat o de control deberá comunicar al dispositivo de comunicación a distancia 
los datos seguros necesar ios a efect os de los controles en carretera selectiv os. 
391)  Una vez activado el aparat o de control, las funciones de registro y almacenamiento serán totalment e 
operativas. 
392) Tras la instalación, deberá efectuarse un calibrado. El primer calibrado podrá no incluir necesa ­
riamente la introducción del número de matrícula del vehículo (VRN) si el taller autorizado 
encargado de realizar el calibrado no lo conoce. En estas circunstancias, el propietar io del vehículo 
podrá introducir , tan solo por esta vez, el VRN utilizando su tarjeta de empr esa 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) (1). Para actualizar o confir mar los datos introducidos deberá utilizarse, 
necesar iamente, una tarjeta de taller . 
393)  La instalación de un dispositivo GNSS extern o requiere el acoplamiento con la unidad instalada en el 
vehículo y la subsiguient e verificación de la información de posición del GNSS. 
394)  El aparato de control deberá colocarse en el vehículo de modo que el conductor pueda acceder a las 
funciones necesar ias desde su asiento. 26.5.2016 L 139/72 Diar io Oficial de la Unión Europea ES    
(1)DO L 102, 11.4.2006, p.1 
5.2  Placa de inst alación 
395)  Después de haber instalado y verificado el aparat o de control, se le fijará una placa de instalación, 
grabada o impresa de forma permanent e, que sea bien visible y de fácil acceso. Cuando esto no sea 
posible, la placa se fijará en el montant e «B» del vehículo para que sea clarament e visible. En aquellos 
vehículos sin montante «B», la placa se fijará en el marco de la puer ta del lado del conduct or del 
vehículo y deberá quedar a la vista en cualquier caso. 
Después de cada nueva inspección por un taller o instalador autor izado, la placa deberá sustituirse 
por otra nueva. 
396)  En la placa deberán figurar , como mínimo, los datos siguient es: 
—  nombre y domicilio o nombre comercial del instalador o taller autorizado, 
—  coeficiente caract erístico del vehículo, en la forma «w = … imp/km», 
—  constante del aparato de control, en la forma «k = … imp/km», 
—  circunfer encia efectiva de los neumáticos de las ruedas, en la forma «l = … mm», 
—  tamaño de los neumáticos, 
—  fecha del informe del coefi ciente característico del vehículo y de la medida de la circunfer encia 
efectiva de los neumáticos de las ruedas, 
—  número de identificación del vehículo (VIN), 
—  presencia (o no) de un dispositivo GNSS extern o, 
—  número de serie del dispositivo GNSS externo, 
—  número de serie del dispositivo de comunicación a distancia, 
—  número de serie de todos los precint os existen tes. 
—  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 , 
—  descr ipció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 . 
397)  Únicament e en los vehículos de las categorías M1 y N1, equipados con un adap tador conf orme a las 
disposiciones del Reglamento (CE) n.o 68/2009 de la Comisión (1) en su versión modifi cada más 
reciente, y cuando no se pueda incluir toda la información necesar ia según el requisito 396, se podrá 
utilizar una segunda placa adicional. En estos casos, esta placa adicional cont endrá, al menos, la 
información descr ita en los últimos cuatro guiones del requisito 396. 
De instalar esta segunda placa adicional, se colocará junto a la primera placa principal descr ita en el 
requisito 396 o cerca de ella, y se aplicará el mismo nivel de protección. Asimismo, la segunda placa 
deberá indicar el nombre, dirección o denominación comercial del instalador o taller que haya 
efectuado la instalación, junt o con la fecha de instalación 26.5.2016 L 139/73 Diar io Oficial de la Unión Europea ES    
(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 aparat o de control en el sector de los transpor tes por carretera (DO L 21 de 
24.1.2009, p. 3). 
5.3  Precinto s 
398)  Deberán precintarse los elementos siguiente s: 
—  cualquier conexión que, de estar desconectada, ocasionaría modificaciones o pérdidas de datos 
indet ectables (esto puede aplicarse, por ejemplo, a la instalación del sensor de movimient o en la 
caja de cambios, al adap tador para vehículos M1/N1, a la conexión del GNSS exte rno 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 destr uir las 
inscr ipciones que figuran en ella. 
399)  Los precintos anter iormente 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 contr ibuya a la segur idad vial, siempr e que el aparato de control siga funcionando 
de forma fiable y correcta y vuelva a ser precintado por un instalador o taller autorizado (de 
acuerdo con lo dispuesto en el capítulo 6) inmediatament e después de que se haya instalado el 
dispositivo de limitación de velocidad o cualquier otro dispositivo que contr ibuya a la segur idad 
vial, o en el plazo de siete días en otros casos. 
400)  Siempre que se retiren estos precintos deberá redactarse y ponerse a disposición de la autori dad 
compet ente una justif icación de esta medida. 
401)  Los precint os deberán llevar un número de identif icación, asignado por su fabr icante . Este número 
deberá ser único y distinto de cualquier otro número de precint o asignado por otro fabricante de 
precintos . 
Este número de identif icación único se define del siguient e modo: MM NNNNNN mediante marcado 
que no se pueda retirar , siendo MM un identificador único del fabr icante (registro en base de datos 
gestionada por la CE) y NNNNNN identif icador alfanumér ico del precinto, único en el dominio del 
fabricante . 
402)  Los precint os dispondrán de un espacio libre en el que instaladores, talleres o fabricantes de vehículos 
puedan añadir una marca especial con arreglo al artículo 22, apar tado 3, del Reglamento (UE) 
n.o 165/2014. 
Esta marca no deberá tapar el número de identif icación del precint o. 
403)  Los fabricantes de los precint os quedarán registrados en una base de datos específi ca y hará públicos 
sus identificadores de precint os a través de un procedimiento que establecerá la Comisión Europea. 
404)  Los talleres autorizados y los fabricantes de vehículos utilizarán únicament e, en el marco del 
Reglamento (UE) n.o 165/2014, precint os procedent es de los fabr icantes de precint os recogidos en la 
base de datos mencionada anteriormente. 
405)  Los fabr icantes de precintos y sus distr ibuidores manten drán registros de trazabilidad compl eta 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 compet entes cuando sea necesar io. 
406)  Los identif icadores únicos de los precint os deberán ser visible en la placa de instalación. 
6  VERIFICA CIONES, CONTR OLES Y REPARA CIONES 
En el capítulo 5.3 del present e anex o se definen las circunstancias en las que podrán quitarse los precint os, 
según lo indicado en el artículo 22, apar tado 5, del Reglamento (UE) n.o 165/2014. 
6.1  Autori zación de inst aladores, talleres y fabr icantes de vehículos 
Los Estados miembros aprobarán, inspeccionarán periódicament e y certificarán los organismos encarg ados 
de realizar: 
—  instalaciones, 
—  verificaciones, 26.5.2016 L 139/74 Diar io Oficial de la Unión Europea ES    
—  controles, 
—  reparaciones. 
Las tarjetas de taller se expedirán únicamente a los instaladores o talleres que hayan sido autori zados para 
proceder a la activación o calibrado del aparat o de control de conf ormidad con el present e anex o y que 
además, salvo justif icación: 
—  no puedan optar a recibir una tarjeta de empresa, 
—  sus demás actividades profesio nales no suponga n un compromiso potencial de la segur idad general del 
sistem a tal y como se exige en el apéndice 10. 
6.2  Verificación de instr umento s nuev os o reparados 
407)  Cada dispositivo , tanto nuev o como reparado, deberá verificarse individualment e en lo que se refiere 
a su correcto funcionamient o y a la exactitud de sus indicaciones y registros, dentro de los límites 
establecidos en los capítulos 3.2.1, 3.2.2, 3.2.3 y 3.3, mediante la colocación de un precint o, de 
acuerdo con lo dispuest o en el capítulo 5.3, y la realización de un calibrado. 
6.3  Control de la inst alación 
408)  En el momento de su instalación en un vehículo, la instalación en su conjunt o (incluido el aparat o de 
control) deberá ajustarse a las disposiciones sobre tolerancias máximas establecidas en los capítulos 
3.2.1, 3.2.2, 3.2.3 y 3.3. 
6.4  Controles periódicos 
409)  Los aparat os instalados en los vehículos se somete rán a un control periódico cada vez que se repare 
el aparat o o se efectúe cualquier modificación del coeficiente caracterís tico del vehículo o de la 
circunferencia efectiva de los neumáticos de las ruedas, o si la hora UTC del aparat o presenta un 
retraso o un adelanto de más de 20 minutos, o si cambia el VRN, o al menos en el plazo de dos años 
(24 meses) desde el último control. 
410)  Se controlará, en particular: 
—  que el aparat o de control ejecute correctamente todas sus funciones, incluidas la función de 
almacenamient o de datos en las tarjetas de tacógraf o 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 aparat o de control lleve la marca de homologació n, 
—  que se coloquen una placa de instalación, según la define el requisit o 396, y una placa 
descr iptiva, según la define el requisit o 225, 
—  el tamaño de los neumáticos y la circunferencia real de los neumáticos. 
—  que no haya dispositivos de manipulación integrad os en el aparat o, 
—  que los precint os estén correctamente colocados, en buen estado, que sus identif icadores sean 
válidos (fabricante del precint o incluido en la base de datos de la CE) y que sus identif icadores 
correspondan a las marcas de la placa de instalación (véase el requisito 401). 
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 fabr icante s del tacógraf o y/o las 
autori dades nacionales lo consideran poten cialmente peligroso para la segur idad del aparat o, el taller 
deberá: 
a.  compar ar los datos de identificación del sensor de movimient o conectado a la caja de cambios 
con los del sensor de movimient o acoplado registrados en la unidad instalada en el vehículo; 26.5.2016 L 139/75 Diar io Oficial de la Unión Europea ES    
b.  compr obar si la información registrada en la placa de instalación se corresponde con la registrada 
en la unidad instalada en el vehículo; 
c.  verificar si los números de serie y homologació n del sensor de movimient o, si están impresos en 
la carcasa de este último, casan con la información almacenada en la memor ia de datos del 
aparat o de control; 
d.  compar ar los datos de identif icación marcados en la placa descr iptiva del dispositivo GNSS 
exte rno, si existe, con los almacenados en la memor ia de datos de la unidad instalada en el 
vehículo. 
412)  Los talleres consignaran en sus informes de control cualquier conclusión relativa a la existencia de 
precintos rotos o de dispositivos de manipulación. Los talleres deberán conser var dichos informes 
durante al menos dos años y los pondrán a disposición de la autori dad compet ente cuando se les 
solicite. 
413)  Estos controles incluirán un calibrado y una sustitución preventiva de los precint os cuya instalación 
está bajo la responsabilidad de los talleres. 
6.5  Deter minación de errores 
414)  La deter minación de los errores de instalación y de uso deberá efectuarse en las condiciones 
siguiente s, que se considerarán condiciones normales de ensa yo: 
—  vehículo vacío, en condiciones normales de marcha, 
—  presión de los neumáticos conf orme a las instr ucciones del fabricante, 
—  desgast e 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 propio motor , en línea recta por una superf icie plana a 
una velocidad de 50 ± 5 km/h; la distancia de medición será de al menos 1 000 m, 
—  el ensa yo podrá realizarse también en un banco de pruebas adecuado o con otros métodos, si 
garantizan una precisión similar . 
6.6  Reparaciones 
415)  Los talleres deberán ser capaces de extraer los datos del aparat o de control para facilitarlos a la 
empresa de transpor tes que corresponda. 
416) Los talleres autorizados deberán expedir a las empresas de transpor tes un certificado de intransferi ­
bilidad de los datos cuando un fallo en el funcionamiento del aparat o impida transferi r los datos 
previamente registrados, incluso después de una reparación por el taller en cuestión. Los talleres 
conser varán en su poder durant e al menos dos años una copia de cada certificado expedido. 
7  EXPEDICIÓN DE TARJET AS 
Los procedimientos de expedición de tarjetas que establezcan los Estados miembros deberán cumpli r las 
condiciones siguiente s: 
417)  En el número de la primera tarjeta de tacógraf o expedida para un solicitante, el índice consecutivo 
(en su caso), el índice de sustitución y el índice de reno vación serán «0». 
418)  Los números de todas las tarjetas de tacógraf o no personales que se expidan a un mismo orga nismo 
de control, taller o empresa de transpor tes empezarán por los mismos 13 dígitos, y todos ellos 
tendrán un índice consecutivo diferente. 
419)  Cuando se expida una tarjeta de tacógraf o en sustitución de otra ya existent e, 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). 26.5.2016 L 139/76 Diar io Oficial de la Unión Europea ES    
420)  Cuando se expida una tarjeta de tacógraf o en sustitución de otra ya existent e, la nueva tendrá la 
misma fecha de expiración que la sustituida. 
421)  Cuando se expida una tarjeta de tacógraf o para reno var otra ya existen te, la nueva llevará el mismo 
número de tarjeta que la sustituida, con excepción del índice de sustitución, que se pondrá a «0», y el 
índice de reno vación, que se verá incrementado en una unidad (en el orden 0, …, 9, A, …, Z). 
422)  Cuando se sustituya una tarjeta de tacógraf o existen te para modifi car datos administrativos, se 
obser varán las reglas de reno vació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úbr ica «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 inter cambiarán datos por vía electrónica a fin de garantizar la unicidad de las 
tarjetas de conductor que expiden, de conf ormidad con el artículo 31 del Reglamento (UE) 
n.o 165/2014. 
8  HOMOL OGA CIÓN DEL APARA TO DE CONTR OL Y DE LAS TARJET AS DE TACÓGRAFO 
8.1  Generalidades 
A efectos del presente capítulo, por «aparato de control» se entenderá el «aparato de control o sus 
compo nentes ». No será preciso homolog ar el cable o cables que conectan el sensor de movimient o a la VU, 
el dispositivo GNSS externo a la VU o el dispositivo de comunicación a distancia a la VU. El papel que 
utilice el aparat o de control se considerará un component e de dicho aparat o. 
Todo fabricante podrá solicitar la homologación de su component e con cualquier tipo de sensor de 
movimiento, dispositivo GNSS externo y viceversa, siempre que cada compo nente cumpla los requisitos del 
present e anex o. De manera altern ativa, los fabr icante s podrán también solicitar la homologa ción del aparato 
de control. 
425)  El aparato de control deberá presentarse a la homologació n provisto de los eventuales dispositivo s 
complementari os integrados. 
426)  La homolog ación del aparat o de control y de las tarjetas de tacógraf o deberá incluir ensa yos 
relacionados con la segur idad, ensa yos funcionales y ensa yos de interoperabilidad. El resultado 
positiv o de cada uno de estos ensa yos se consignará en un certificado. 
427)  Las autori dades de homologación de los Estados miembros no concederán el certificado de 
homologació n si no están en posesión de: 
—  un certificado de segur idad, 
—  un certificado funcional, y 
—  un certificado de interoperabilidad 
para el aparat o de control o la tarjeta de tacógraf o cuya homologación se solicite. 
428)  Todo cambio que se introduzca en el software o el hardware del aparat o de control o en la naturaleza 
de los mater iales empleado s en su fabricación deberá notificarse, antes de su utilización, a la 
autori dad que haya homologado el aparat o. Dicha autori dad deberá confir mar al fabr icante la 
ampliación de la homologación, o bien podrá exigir una actualización o conf irmación del certificado 
funcional, de segur idad o de interoperabilidad. 
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 homolog ado el aparato. La actualización del software no deberá 
alterar ni borrar los datos sobre la actividad del conduct or que haya almacenados en el aparat o de 
control. El software sólo podrá actualizarse bajo la responsabilidad del fabricante del aparat o. 26.5.2016 L 139/77 Diar io Oficial de la Unión Europea ES    
430)  No podrá denegarse la homologació n de las modifi caciones del software destinadas a la mejora de un 
aparato de control previamente homologad o si tales modifi caciones solo se aplican a funciones no 
especifi cadas en el present e anex o. La actualización del software de un aparat o de control podrá 
excluir la introducción de juegos de caracte res nuevos, si no es técnicament e viable. 
8.2  Cer tificado de segur idad 
431)  El certificado de segur idad se entrega según lo dispuest o en el apéndice 10 del presente anex o. Los 
compo nentes del aparato de control que se han de certificar son la unidad instalada en el vehículo, el 
sensor de movimient o, el dispositivo GNSS exte rno y las tarjetas de tacógraf o. 
432)  En el caso excepci onal de que las autor idades de certificación de la segur idad se nieguen a certificar 
un nuev o aparato basándose en la obsolescencia de los mecanismos de segur idad, la homologació n 
seguirá concediéndose única y excl usivamente en estas circunstancias específicas y excep cionales, y 
siempre que no exista una solución altern ativa que se ajuste al Reglamento. 
433)  En esta circunstancia, el Estado miembro interesado informará sin dilación a la Comisión Europea, 
que iniciará, en un plazo de doce meses civiles desde la concesión de la homologació n, un procedi ­
miento que garantice el restablecimiento del nivel de segur idad a sus niveles originales. 
8.3  Cer tificado funcional 
434)  Cada candidato a recibir una homologación deberá facilitar a la autori dad de homolog ación del 
Estado miembro que corresponda todo el mat erial y la documentación que dicha autori dad estime 
necesar io. 
435)  Los fabricantes deberán apor tar las muestras opor tunas de los productos candidato s a la 
homologació n y la documentación asociada solicitada por los laboratori os encarga dos de realizar los 
ensa yos 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 preser varán la 
conf idencialidad de todos los datos comercialmente sensibles. 
436)  El certificado funcional deberá entregar se al fabricante solo después de haberse superado como 
mínimo todos los ensa yos funcionales especificados en el apéndice 9. 
437)  El certificado funcional lo entrega la autori dad de homolog ación. Dicho certificado deberá incluir , 
además del nombre de su beneficiar io y la identificación del modelo, una relación pormenor izada de 
los ensa yos que se hayan realizado, junto con los resultados obtenidos. 
438)  El certificado funcional de un compo nente del aparat o de control deberá indicar , asimismo, los 
números de homolog ación de los demás compo nentes compatib les del aparato de control 
homologad os sometidos a ensa yo para su certificación. 
439)  El certificado funcional de un compo nente del aparat o de control deberá indicar , asimismo, la norma 
ISO o CEN con arreglo a la cual se haya certificado la interfaz funcional. 
8.4  Cer tificado de interoperabilidad 
440) Los ensa yos de inter operabilidad las lleva a cabo un único laborat orio bajo la autori dad y la responsa ­
bilidad de la Comisión Europea. 
441)  Dicho laborat orio deberá registrar en el orden cronológico de recepción las solicitudes de ensa yo que 
presenten los fabr icantes . 26.5.2016 L 139/78 Diar io Oficial de la Unión Europea ES    
442)  Las solicitudes sólo se registrarán oficialmente cuando el laboratorio esté en posesión de: 
—  todo el mater ial y los documentos necesar ios para dichos ensa yos de inter operabilidad, 
—  el correspondiente certificado de segur idad, 
—  el correspondiente certificado funcional. 
La fecha de registro de la solicitud deberá notificarse al fabricante. 
443)  El laboratorio no realizará ensa yos de interoperabilidad con aparatos de control o tarjetas de 
tacógraf o que no hayan obtenid o un certificado de segur idad y un certificado funcional, salvo en las 
circunstancias excepci onales descr itas en el requisito 432. 
444) Todo el mat erial y los documentos facilitados por el fabricante que solicite ensa yos de inter opera ­
bilidad quedarán en manos del laborat orio encarg ado de dichos ensa yos. 
445)  Los ensa yos de interoperabilidad deberán llevarse a cabo con arreglo a lo dispuest o en el apéndice 9 
del present e anex o e incluirán todos los tipos de aparatos de control o tarjetas de tacógraf o: 
—  que dispongan de una homologación válida, o bien 
—  que estén pendientes de ser homolog ados y dispongan de un certificado de inter operabilidad 
válido. 
446)  Los ensa yos de interoperabilidad deberán cubr ir todas las generaciones de aparatos de control o 
tarjetas de tacógraf o toda vía en uso. 
447)  El laboratori o no entregar á el certificad o de interoperabilidad al fabr icante hasta que se hayan 
superado todos los ensa yos de interoperabilid ad exigidos. 
448) Si uno o varios aparatos de control o tarjetas de tacógraf o no superan los ensa yos de inter opera ­
bilidad, el certificado de interoperabilid ad no se entrega rá hasta que el fabricante que present e la 
solicitud haya realizado las modificaciones necesar ias y superado dichos ensa yos. El laborat orio 
deberá identif icar la causa del problema con ayuda de los fabricantes que se vean afectados por dicho 
fallo de interoperabilidad, y procurará ayudar al fabricante que present e la solicitud a encontrar una 
solución técn ica. Si el fabr icante ha modif icado su product o, será responsabilidad suya comprobar , 
mediante consulta a las autori dades pertinentes , que el certificado de segur idad y los certificados 
funcionales siguen siendo válidos. 
449)  El certificado de inter operabilidad tendrá una validez de seis meses y quedará revocado al finalizar 
este período si el fabricante no ha recibido el correspondiente certificado de homologación. El 
fabricante entrega el certificado de interoperabilidad a la autor idad de homologació n del Estado 
miembro que ha otorgado el certificado funcional. 
450)  Ningún elemento que pudiera haber causado un fallo de inter operabilidad deberá utilizarse con afán 
de lucro o para lograr una posición dominant e. 
8.5  Cer tificado de homologación 
451)  La autoridad de homolog ación del Estado miembro podrá entregar el certificado de homologació n 
del modelo en cuant o esté en posesión de los tres certificados necesar ios. 
452)  El certificado de homologación de cualquier compo nente del aparat o de control deberá indicar , 
asimismo, los números de homologació n de los demás aparat os de control interoperables 
homologad os. 
453)  Cuando entregue el certificad o de homologa ción al fabr icante, la autori dad de homologación deberá 
facilitar una copia al laborat orio encarg ado de los ensa yos de inter operabilidad. 26.5.2016 L 139/79 Diar io Oficial de la Unión Europea ES    
454)  El laboratori o compet ente para los ensa yos de inter operabilidad deberá mantener un sitio web 
público donde se pueda consultar una relación actualizada de los modelos de aparat o de control o de 
tarjetas de tacógraf o: 
—  para los que se haya registrado una solicitud de ensa yos de interoperabilid ad, 
—  que hayan recibido un certificado de inter operabilidad (aunque sea provisional), 
—  que hayan recibido un certificado de homolog ación. 
8.6  Procedimiento de excepción: primeros certificados de interoperabilidad para los aparato s de control 
y las tarjetas de tacóg rafo de segunda generación 
455)  Hasta cuatro meses después de haberse certificado que una primera pareja de aparato de control de 
segunda generación y tarjetas de tacógraf o (tarjetas de conduct or, de taller , de control y de emp resa) 
de segunda generación es interoperable, se considerarán provisionales los certificados de inter opera ­
bilidad entregados (incluido los primeros) en relación con solicitudes registradas durante este período. 
456)  Si al finalizar este período todos los productos afectados interoperan sin problemas entre sí, los 
certificados de interoperabilidad correspondientes adquir irán un caráct er definitiv o. 
457)  Si durante este período se detectan fallos de interoperabilidad, el laboratorio encarg ado de los ensa yos 
de inter operabilidad deberá identif icar las causas de los problemas con ayuda de todos los fabricantes 
implicados, y les invitará a realizar las modifi caciones necesar ias. 
458)  Si al finalizar este período persisten los problemas de interoperabilidad, el laboratorio encarg ado de 
los ensa yos de inter operabilidad, con la colaboración de los fabr icantes imp licados y con las 
autori dades de homologación que otorguen los correspondiente s certificad os funcionales, deberán 
deter minar las causas de los fallos de inter operabilidad y establecer las modificaciones que debería 
introducir cada uno de los fabricante s afectados. La búsqueda de soluciones técn icas deberá 
prolongarse un máximo de dos meses. Si transcur re este plazo sin haberse hallado una solución 
común, la Comisión, previa consulta al laboratorio encarga do de los ensa yos de interoperabilidad, 
deberá decidir qué aparato(s) y tarjetas obtienen un certificado de inter operabilidad definitiv o, y 
fundamentar su decisión. 
459)  Deberá posponerse hasta que se hayan resuelto los problemas de interoperabilidad iniciales cualquier 
solicitud de ensa yos de interoperabilidad que registre el laboratorio entre el final del período de 
cuatro meses posteri or al primer certificado de interoperabilid ad provisional y la fecha en que la 
Comisión adop ta la decisión mencionada en el requisit o 455. Dichas solicitudes se procesarán luego 
en el orden cronológico en que se registraron.  26.5.2016 L 139/80 Diar io Oficial de la Unión Europea ES    
Apéndice 1 
DICCIONARIO DE DATOS 
ÍNDICE 
1. INTR ODUCCIÓN .............................................................................................................................. 88 
1.1. Enfoque de la definición de los tipos de datos............................................................................. 88 
1.2. Referencias ......................................................................................................................... 88 
2. DEFINICIONES DE TIPOS DE DATOS .................................................................................................... 89 
2.1. ActivityChang eInfo............................................................................................................... 89 
2.2. Address .............................................................................................................................. 90 
2.3. AESKe y.............................................................................................................................. 91 
2.4. AES128Key ......................................................................................................................... 91 
2.5. AES192Key ......................................................................................................................... 91 
2.6. AES256Key ......................................................................................................................... 92 
2.7. BCDStr ing .......................................................................................................................... 92 
2.8. CalibrationPur pose ............................................................................................................... 92 
2.9. CardA ctivityDailyRecord ........................................................................................................ 93 
2.10. CardA ctivityLengthRa nge ....................................................................................................... 93 
2.11. CardAppro valNumber ........................................................................................................... 93 
2.12. CardCer tificate..................................................................................................................... 94 
2.13. CardChipIdentification ........................................................................................................... 94 
2.14. CardConsecutiveIndex ........................................................................................................... 94 
2.15. CardControlA ctivityDataRecord ............................................................................................... 94 
2.16. CardCur rentUse ................................................................................................................... 95 
2.17. CardDr iverA ctivity ................................................................................................................ 95 
2.18. CardDr ivingLicenceInf ormation ............................................................................................... 95 
2.19. CardEventData ..................................................................................................................... 96 
2.20. CardEventRecord .................................................................................................................. 96 
2.21. CardF aultData ...................................................................................................................... 96 
2.22. CardF aultRecord .................................................................................................................. 97 
2.23. CardIccIdentification ............................................................................................................. 97 
2.24. CardIdentification ................................................................................................................. 97 
2.25. CardMA Certificate................................................................................................................ 98 
2.26. CardNumber ....................................................................................................................... 98 
2.27. CardPlaceDailyW orkPer iod ..................................................................................................... 99 
2.28. CardPr ivateKe y.................................................................................................................... 99 26.5.2016 L 139/81 Diar io Oficial de la Unión Europea ES    
2.29. CardPublicKe y..................................................................................................................... 99 
2.30. CardRenewalIndex ................................................................................................................ 99 
2.31. CardReplacementIndex .......................................................................................................... 99 
2.32. CardSignCer tificate............................................................................................................... 100 
2.33. CardSlotNumber .................................................................................................................. 100 
2.34. CardSlotsStatus .................................................................................................................... 100 
2.35. CardSlotsStatusRecordAr ray.................................................................................................... 100 
2.36. CardStr uctureV ersion ............................................................................................................ 101 
2.37. CardV ehicleRecord ................................................................................................................ 101 
2.38. CardV ehiclesUsed ................................................................................................................. 102 
2.39. CardV ehicleU nitRecord .......................................................................................................... 102 
2.40. CardV ehicleU nitsUsed ............................................................................................................ 102 
2.41. Certificate ........................................................................................................................... 103 
2.42. CertificateCont ent ................................................................................................................ 103 
2.43. CertificateHolderAuth orisation ................................................................................................ 104 
2.44. CertificateRequestID .............................................................................................................. 104 
2.45. CertificationAuthor ityKID ...................................................................................................... 104 
2.46. Com panyA ctivityData ........................................................................................................... 105 
2.47. Com panyA ctivityT ype ........................................................................................................... 106 
2.48. Com panyCard ApplicationIdentif ication ..................................................................................... 106 
2.49. Com panyCard HolderIdentif ication ........................................................................................... 106 
2.50. ControlCardApplicationIdentification ........................................................................................ 106 
2.51. ControlCardControlA ctivityData .............................................................................................. 107 
2.52. ControlCardHolderIdentification .............................................................................................. 107 
2.53. ControlT ype ........................................................................................................................ 108 
2.54. CurrentDateTime ................................................................................................................. 109 
2.55. CurrentDateTimeRecordArr ay................................................................................................. 109 
2.56. DailyPresenceCount er............................................................................................................ 109 
2.57. Datef................................................................................................................................. 109 
2.58. DateOfDa yDo wnloaded ......................................................................................................... 110 
2.59. DateOfDa yDo wnloadedRecordAr ray......................................................................................... 110 
2.60. Distance ............................................................................................................................. 110 
2.61. DriverCardApplicationIdentifi cation ......................................................................................... 110 
2.62. DriverCardHolderIdentifi cation ................................................................................................ 111 
2.63. DSR CSecur ityData ................................................................................................................ 112 
2.64. EGFCer tificate...................................................................................................................... 112 
2.65. EmbedderIcAssemblerId ......................................................................................................... 112 26.5.2016 L 139/82 Diar io Oficial de la Unión Europea ES    
2.66. Entr yTypeDailyW orkPer iod ..................................................................................................... 113 
2.67. EquipmentT ype .................................................................................................................... 113 
2.68. EuropeanPublicKe y............................................................................................................... 114 
2.69. EventF aultRecordPur pose ....................................................................................................... 114 
2.70. EventF aultT ype .................................................................................................................... 114 
2.71. Exten dedSealIdentifi er........................................................................................................... 115 
2.72. Exten dedSer ialNumber .......................................................................................................... 116 
2.73. FullCardNumber .................................................................................................................. 116 
2.74. FullCardNumberAndGeneration ............................................................................................... 117 
2.75. Generation .......................................................................................................................... 117 
2.76. GeoCoordinates ................................................................................................................... 117 
2.77. GNSS Accuracy ..................................................................................................................... 118 
2.78. GNSSContinuousDr iving ........................................................................................................ 118 
2.79. GNSSContinuousDr ivingRecord ............................................................................................... 118 
2.80. GNSSPlaceRecord ................................................................................................................. 118 
2.81. HighResOdomete r................................................................................................................ 119 
2.82. HighResT ripDistance ............................................................................................................. 119 
2.83. HolderName ....................................................................................................................... 119 
2.84. InternalGNSSReceiver ............................................................................................................ 119 
2.85. K-ConstantOfRecordingEquipment ........................................................................................... 119 
2.86. KeyIdentifier ....................................................................................................................... 120 
2.87. KMW CKey.......................................................................................................................... 120 
2.88. Languag e............................................................................................................................ 120 
2.89. LastCardDo wnload ............................................................................................................... 120 
2.90. LinkCer tificate ..................................................................................................................... 120 
2.91. L-TyreCircumf erence ............................................................................................................. 121 
2.92. MAC................................................................................................................................. 121 
2.93. ManualIn putFlag .................................................................................................................. 121 
2.94. Manufa cturerCode ................................................................................................................ 121 
2.95. Manufa cturerSpecifi cEventF aultData ......................................................................................... 121 
2.96. MemberStat eCer tificate .......................................................................................................... 122 
2.97. MemberStat eCer tificateRecordAr ray.......................................................................................... 122 
2.98. MemberStat ePublicKey .......................................................................................................... 122 
2.99. Name ................................................................................................................................ 122 
2.100. NationAlpha ....................................................................................................................... 123 
2.101. NationNumer ic.................................................................................................................... 123 
2.102. NoOfCalibrationRecords ........................................................................................................ 123 26.5.2016 L 139/83 Diar io Oficial de la Unión Europea ES    
2.103. NoOfCalibrationsSinceDo wnload ............................................................................................. 123 
2.104. NoOfCardPlaceRecords .......................................................................................................... 123 
2.105. NoOfCardV ehicleRecords ....................................................................................................... 124 
2.106. NoOfCardV ehicleU nitRecords .................................................................................................. 124 
2.107. NoOfComp anyA ctivityRecords ................................................................................................ 124 
2.108. NoOfControlA ctivityRecords .................................................................................................. 124 
2.109. NoOfEventsPe rType .............................................................................................................. 124 
2.110. NoOfF aultsPerT ype ............................................................................................................... 124 
2.111. NoOfGNSSCDRecords ........................................................................................................... 124 
2.112. NoOfSpecificConditionRecords ................................................................................................ 125 
2.113. Odomet erShor t.................................................................................................................... 125 
2.114. Odomet erValueMidnight ........................................................................................................ 125 
2.115. Odomet erValueMidnightRecordAr ray........................................................................................ 125 
2.116. OverspeedNumber ................................................................................................................ 125 
2.117. PlaceRecord ........................................................................................................................ 126 
2.118. PreviousV ehicleInf o............................................................................................................... 126 
2.119. PublicKey ........................................................................................................................... 127 
2.120. RecordT ype ......................................................................................................................... 127 
2.121. RegionAlpha ....................................................................................................................... 128 
2.122. RegionNumer ic.................................................................................................................... 128 
2.123. Remot eCommunicationModuleSer ialNumber .............................................................................. 129 
2.124. RSA KeyModulus .................................................................................................................. 129 
2.125. RSA KeyPrivate Exponent ......................................................................................................... 129 
2.126. RSA KeyPublicExponent ......................................................................................................... 129 
2.127. RtmData ............................................................................................................................ 129 
2.128. SealDataCard ....................................................................................................................... 129 
2.129. SealDataV u......................................................................................................................... 130 
2.130. SealRecord .......................................................................................................................... 130 
2.131. SensorAppro valNumber ......................................................................................................... 130 
2.132. SensorExt ernalGNSSA ppro valNumber ....................................................................................... 131 
2.133. SensorExt ernalGNSSCoupledRecord ......................................................................................... 131 
2.134. SensorExt ernalGNSSIdentifi cation ............................................................................................ 131 
2.135. SensorExt ernalGNSSInstallation ............................................................................................... 132 
2.136. SensorExt ernalGNSSOSIdentifi er.............................................................................................. 132 
2.137. SensorExt ernalGNSSSCIdentifie r.............................................................................................. 132 
2.138. SensorGNSSCouplingDate ...................................................................................................... 133 26.5.2016 L 139/84 Diar io Oficial de la Unión Europea ES    
2.139. SensorGNSSSer ialNumber ...................................................................................................... 133 
2.140. SensorIdentification .............................................................................................................. 133 
2.141. SensorInstallation ................................................................................................................. 133 
2.142. SensorInstallationSecData ....................................................................................................... 134 
2.143. SensorOSIdentifier ................................................................................................................ 134 
2.144. SensorP aired ....................................................................................................................... 134 
2.145. SensorP airedRecord .............................................................................................................. 135 
2.146. SensorP airingDate ................................................................................................................ 135 
2.147. SensorSCIdentifier ................................................................................................................ 135 
2.148. SensorSer ialNumber .............................................................................................................. 135 
2.149. Signature ............................................................................................................................ 135 
2.150. SignatureRecordAr ray........................................................................................................... 136 
2.151. SimilarEventsNumber ............................................................................................................ 136 
2.152. SpecificConditionRecord ........................................................................................................ 136 
2.153. SpecificConditions ................................................................................................................ 136 
2.154. SpecificCondition Type ........................................................................................................... 137 
2.155. Speed ................................................................................................................................ 137 
2.156. SpeedA uthor ised .................................................................................................................. 137 
2.157. SpeedA verag e...................................................................................................................... 138 
2.158. SpeedMax ........................................................................................................................... 138 
2.159. TachographP ayload ............................................................................................................... 138 
2.160. TachographP ayloadEncr ypted .................................................................................................. 138 
2.161. TDesSessionKe y................................................................................................................... 138 
2.162. TimeReal ............................................................................................................................ 139 
2.163. TyreSize ............................................................................................................................. 139 
2.164. VehicleIdentif icationNumber ................................................................................................... 139 
2.165. VehicleIdentif icationNumberRecordAr ray................................................................................... 139 
2.166. VehicleRegistrationIdentificat ion .............................................................................................. 139 
2.167. VehicleRegistrationNumber ..................................................................................................... 140 
2.168. VehicleRegistrationNumberRecordAr ray.................................................................................... 140 
2.169. VuAbility ............................................................................................................................ 140 
2.170. VuActivityDailyData .............................................................................................................. 141 
2.171. VuActivityDailyRecordAr ray................................................................................................... 141 
2.172. VuAppro valNumber .............................................................................................................. 141 
2.173. VuCalibrationData ................................................................................................................ 142 
2.174. VuCalibrationRecord ............................................................................................................. 142 
2.175. VuCalibrationRecordAr ray...................................................................................................... 143 26.5.2016 L 139/85 Diar io Oficial de la Unión Europea ES    
2.176. VuCardIWData .................................................................................................................... 144 
2.177. VuCardIWRecord ................................................................................................................. 144 
2.178. VuCardIWRecordAr ray.......................................................................................................... 145 
2.179. VuCardRecord ..................................................................................................................... 145 
2.180. VuCardRecordAr ray.............................................................................................................. 146 
2.181. VuCer tificate ....................................................................................................................... 146 
2.182. VuCer tificateRecordAr ray....................................................................................................... 146 
2.183. VuCom panyL ocksData .......................................................................................................... 147 
2.184. VuCom panyL ocksRecord ....................................................................................................... 147 
2.185. VuCom panyL ocksRecordAr ray................................................................................................ 148 
2.186. VuControlA ctivityData .......................................................................................................... 148 
2.187. VuControlA ctivityRecord ....................................................................................................... 148 
2.188. VuControlA ctivityRecordAr ray................................................................................................ 149 
2.189. VuDataBloc kCounter ............................................................................................................. 149 
2.190. VuDetailedSpeedBlock ........................................................................................................... 149 
2.191. VuDetailedSpeedBlockRe cordAr ray........................................................................................... 150 
2.192. VuDetailedSpeedData ............................................................................................................ 150 
2.193. VuDo wnloadableP eriod.......................................................................................................... 150 
2.194. VuDo wnloadableP eriodRecordAr ray......................................................................................... 151 
2.195. VuDo wnloadA ctivityData ....................................................................................................... 151 
2.196. VuDo wnloadA ctivityDataRecordAr ray....................................................................................... 151 
2.197. VuEventData ....................................................................................................................... 152 
2.198. VuEventRecord .................................................................................................................... 152 
2.199. VuEventRecordAr ray............................................................................................................. 153 
2.200. VuFaul tData ........................................................................................................................ 154 
2.201. VuFaul tRecord ..................................................................................................................... 154 
2.202. VuFaul tRecordAr ray.............................................................................................................. 155 
2.203. VuGNSSCDRecord ................................................................................................................ 155 
2.204. VuGNSSCDRecordAr ray........................................................................................................ 156 
2.205. VuIdentification ................................................................................................................... 156 
2.206. VuIdentificationRecordAr ray................................................................................................... 157 
2.207. VuITSConsentRecord ............................................................................................................ 157 
2.208. VuITSConsentRecordAr ray..................................................................................................... 158 
2.209. VuManufa cturerAddress ......................................................................................................... 158 
2.210. VuManufa cturerName ............................................................................................................ 158 
2.211. VuManufa ctur ingDate ............................................................................................................ 158 26.5.2016 L 139/86 Diar io Oficial de la Unión Europea ES    
2.212. VuOverSpeedingControlData .................................................................................................. 159 
2.213. VuOverSpeedingControlDataRecordAr ray.................................................................................. 159 
2.214. VuOverSpeedingEventData ..................................................................................................... 159 
2.215. VuOverSpeedingEventRecord .................................................................................................. 159 
2.216. VuOverSpeedingEventRecordAr ray........................................................................................... 160 
2.217. VuPartNumber ..................................................................................................................... 161 
2.218. VuPlaceDailyW orkPe riodData .................................................................................................. 161 
2.219. VuPlaceDailyW orkPe riodRecord ............................................................................................... 161 
2.220. VuPlaceDailyW orkPe riodRecordAr ray....................................................................................... 162 
2.221. VuPrivate Key ....................................................................................................................... 162 
2.222. VuPublicKey ........................................................................................................................ 162 
2.223. VuSer ialNumber ................................................................................................................... 162 
2.224. VuSof tInstallationDate ........................................................................................................... 162 
2.225. VuSof twareIdentif ication ........................................................................................................ 163 
2.226. VuSof twareV ersion ............................................................................................................... 163 
2.227. VuSpecificConditionData ....................................................................................................... 163 
2.228. VuSpecificConditionRecordAr ray............................................................................................. 163 
2.229. VuTimeAd justmentData ......................................................................................................... 164 
2.230. VuTimeAd justmentGNSSRecord .............................................................................................. 164 
2.231. VuTimeAd justmentGNSSRecordAr ray....................................................................................... 164 
2.232. VuTimeAd justmentRecord ...................................................................................................... 165 
2.233. VuTimeAd justmentRecordAr ray.............................................................................................. 165 
2.234. WorkshopCardApplicationIdentification .................................................................................... 166 
2.235. WorkshopCardCalibrationData ................................................................................................ 166 
2.236. WorkshopCardCalibrationRecord ............................................................................................. 167 
2.237. WorkshopCardHolderIdentificat ion .......................................................................................... 168 
2.238. WorkshopCardPIN ................................................................................................................ 168 
2.239. W-VehicleCharact eristicConstant .............................................................................................. 169 
2.240. VuPowerSupplyInt erruptionRecord ........................................................................................... 169 
2.241. VuPowerSupplyInt erruptionRecordArr ay................................................................................... 169 
2.242. VuSensorExt ernalGNSSCoupledRecordAr ray............................................................................... 170 
2.243. VuSensorP airedRecordAr ray.................................................................................................... 170 
3. DEFINICIONES DE LOS INTER VALOS DE VALORES Y TAMAÑOS ADMISIBLES ............................................... 171 
4. JUEGOS DE CARA CTERES .................................................................................................................. 171 
5. CODIFIC ACIÓN ............................................................................................................................... 171 
6. IDENTIFICADORES DE OBJETO E IDENTIFICADORES DE APLICA CIÓN ........................................................ 171 
6.1. Identificadores de objeto ........................................................................................................ 171 
6.2. Identificadores de aplicación ................................................................................................... 172  26.5.2016 L 139/87 Diar io Oficial de la Unión Europea ES    
1.  INTR ODUCCIÓN 
En el presente apéndice se especific an diversos formatos, elementos y estructuras para su uso en el aparat o de 
control y las tarjetas de tacógraf o. 
1.1.  Enfoque de la definición de los tipos de datos 
En el present e apéndice se utiliza la Notación de Sintaxis Abstracta Uno (ASN.1) para definir los tipos de datos. 
Ello permite definir datos simples y estructurados sin necesidad de una sintaxis específica de transferencia (reglas 
de codif icació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 
signif ica que: 
—  siempr e que sea posible, el significado de un tipo de datos se deduce de los nombres seleccionados, 
—  cuando un tipo de datos se compo ne 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 signif icado, 
—  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 aparat o de 
control, entonces ese tipo ASN.1 se definirá en el presente apéndice. 
Para que pueda haber diferent es tipos de reglas de codificación, algunos tipos ASN.1 del presente apéndice están 
limitados por identificadores de inter valos de valores. Dichos identificadores se definen en el apar tado 3 y en el 
apéndice 2. 
1.2.  Referencia s 
En el present e 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) — Contenid o y 
estructura. 2009. 
ISO/CEI 7816-5  Tarjetas de identif icación — Tarjetas con circuit os integrados — Parte 5: Registro de 
proveedores de aplicaciones. 
Segunda edición: 2004. 
ISO/CEI 7816-6  Tarjetas de identif icación — Tarjetas con circuitos integrad os — Parte 6: Elementos de datos 
intersect oriales para los intercambios, 2004 + Corrigen dum técnico 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 + Corrigen dum técnico 1: 2012 y Corrigendum técn ico 2: 2014. 
ISO/CEI 8825-2  Tecnología de la información — Reglas de codif icación ASN.1: Especificación de las Reglas de 
Codif icación por Paquetes (PER). 2008. 
ISO/CEI 8859-1  Tecnología de la información — Conjuntos de caracteres gráfi cos codif icados con un solo byte 
de 8 bits — Parte 1: Alfabet o latino no 1. Primera edición: 1998. 
ISO/CEI 8859-7  Tecnología de la información — Conjuntos de caracteres gráfi cos codif icados con un solo byte 
de 8 bits — Parte 7: Alfabet o latino/gr iego. 2003. 26.5.2016 L 139/88 Diar io Oficial de la Unión Europea ES    
ISO 16844-3  Vehículos de carretera — Sistem as de tacógraf o — Interfaz del sensor de movimient o. 2004 + 
Corrigendum técn ico 1: 2006. 
TR-03110-3  BSI / ANSSI Techn ical Guideline TR-03110-3, Advanced Secur ity Mechanisms for Machine 
Readable Travel Documents and eIDAS Token — Part 3 Common Specifications, version 2.20, 
3. Febr uary 2015. 
2.  DEFINICIONES DE TIPOS DE DATOS 
En todos los tipos de datos que se descr iben a continuación, el valor por defect o para un cont enido 
«desconocido» o «no aplicable» consistirá en rellenar el element o de datos con bytes ‘FF’. 
Todos los tipos de datos se utilizan para las aplicaciones de la generación 1 y de la generación 2, a menos que se 
especifique otra cosa. 
2.1.  Acti vityChangeInfo 
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 conduct or. Este tipo de datos está 
relacionado con el anex o 1C, requisit os 105, 266, 291, 320, 321, 343 y 344. 
Asignación de valor — Alineación de octeto: ‘scpaattttttttttt’B (16 bits) 
Para registros en la memor ia 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 SOLIT ARIO, 
‘1’B: EN EQUIPO, 
‘p’B  Estado de la tarjeta de conductor (o de taller) en la ranura que corresponda: 
‘0’B: INSER TADA, hay una tarjeta inser tada, 
‘1’B: NO INSER TADA, no hay tarjeta inser tada (o se ha extraído una tarjeta), 
‘aa’B  Actividad: 
‘00’B: PAUSA /DESCA NSO, 
‘01’B: DISPONIBILID AD, 
‘10’B: TRABAJO, 
‘11’B: CONDU CCIÓN, 
‘ttttttttttt’B  Hora del cambio: minutos transcur ridos desde las 00.00 horas de ese día. 26.5.2016 L 139/89 Diar io Oficial de la Unión Europea ES    
Para registros en la tarjeta de conductor (o de taller) (y estado del conduct or): 
‘s’B  Ranura (irrelevante cuando ‘p’ = 1, exce pto 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 siguient e (caso ‘p’ = 1): 
‘0’B: EN SOLIT ARIO, 
‘0’B: INDETERMINADO 
‘1’B: EN EQUIPO, 
‘1’B: DETERMINADO (= entrada manual) 
‘p’B  Estado de la tarjeta: 
‘0’B: INSER TADA, la tarjeta está inser tada en un aparato de control, 
‘1’B: NO INSER TADA, la tarjeta no está inser tada (o se ha extraído), 
‘aa’B  Actividad (irrelevante cuando ‘p’ = 1 y ‘c’ = 0, excep to en el caso citado en la nota siguiente ): 
‘00’B: PAUSA /DESCA NSO, 
‘01’B: DISPONIBILID AD, 
‘10’B: TRABAJO, 
‘11’B: CONDU CCIÓN, 
‘ttttttttttt’B  Hora del cambio: minutos transcur ridos 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 conf igurarse a 0, 
—  ‘p’ debe conf igurarse 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 
sobrescr ibir posterior mente para reflejar la entrada. 
2.2.  Addre ss 
Una dirección. 
26.5.2016 L 139/90 Diar io Oficial de la Unión Europea ES    
codePage especifica un conjunto de caract eres definidos en el capítulo 4. 
address representa una dirección codif icada utilizando el conjunt o 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. 
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. 26.5.2016 L 139/91 Diar io Oficial de la Unión Europea ES    
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.  BCDStr ing 
La cadena BCDStr ing se aplica para la representación decimal de codificación binar ia (BCD). Este tipo de datos se 
utiliza para representar un dígito decimal en un semioctet o (4 bits). La cadena BCDStr ing se basa en el ‘Charac ­
terStri ngType’ de la norma ISO/CEI 8824-1. 
La cadena BCDStr ing emplea una notación «hstr ing». El dígito hexadecimal situado más a la izquierda deberá ser 
el semiocte to más signif icativ o del primer octeto. Para obtener un múltiplo de octet os habrá que inser tar 
semioctet os nulos a la derech a, según sea necesar io, a partir de la posición del semioctet o situado más a la 
izquierda en el primer octeto. 
Los dígitos permitidos son: 0, 1, .. 9. 
2.8.  CalibrationPur pose 
Código que explica por qué se registró un conjunt o de parámetros de calibrado. Este tipo de datos está 
relacionado con el anex o 1B, requisitos 097 y 098, y con el anex o 1C, requisit o 119. 
Asignación de valor : 
Generación 1: 
‘00’H  valor reser vado, 
‘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 vehículo actual, 
‘04’H  control periódico. 26.5.2016 L 139/92 Diar io Oficial de la Unión Europea ES    
Generación 2: 
Además de los valores de la generación 1, se utilizan los siguient es: 
‘05’H  entrada de VRN por empr esa, 
‘06’H  ajust e de la hora sin calibrado, 
‘07’H a ‘7F’H  RFU, 
‘80’H a ‘FF’H  específi cos del fabricante. 
2.9.  CardActi vityDailyRecord 
Información almacenada en una tarjeta y relativa a las actividades del conduct or en un día civil concreto. Este 
tipo de datos está relacionado con el anex o 1C, requisitos 266, 291, 320 y 343. 
activityPreviousRecordLength es la longitud total del registro diar io anterior, expresada en bytes. El valor 
máximo viene dado por la longitud de la CADENA DE OCTETOS que contiene dichos registros (véase CardA cti­
vityLengthR ange , apéndice 2, apar tado 4). Cuando este registro es el registro diar io más antiguo, el valor de 
activityPreviousRecordLength debe conf igurarse a 0. 
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 diar ia para esa tarjeta en ese día. 
activityDayDi stance es la distancia total recor rida ese día. 
activityChangeInfo es el conjunt o de datos de ActivityChange Info correspondientes al conduct or en ese día. 
Puede cont ener 1 440 valores como máximo (un cambio de actividad cada minuto). Este conjunt o incluye 
siempre la ActivityChang eInfo que codifica el estado del conductor a las 00.00 horas. 
2.10.  CardActi vityLengthR ange 
Número de bytes disponibles en una tarjeta de conductor o en una tarjeta de taller para almacenar registros 
sobre las actividades del conduct or. 
Asignación de valor: véase el apéndice 2. 
2.11.  CardAppro valNumber 
Número de homologación de la tarjeta. 
26.5.2016 L 139/93 Diar io Oficial de la Unión Europea ES    
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 ejem plo, incluyendo guiones si los lleva. El número de homologació n deberá 
estar alineado a la izquierda. 
2.12.  CardCer tificate 
Generación 1: 
Certificad o de la clave pública de una tarjeta. 
2.13.  CardChipIdentif ication 
Información almacenada en una tarjeta y relativa a la identif icación del circuito integrad o (CI) de dicha tarjeta 
(anex o 1C, requisito 249). El icSer ialNumber y el icManufactur ingRef erences identifican conjuntamente el chip 
de la tarjeta de manera única. El icSer ialNumber no identifica el chip de la tarjeta de manera única por sí solo. 
icSer ialNumber es el número de serie del CI. 
IcManufactur ingReferences es el identificad or específico del fabricante del CI. 
2.14.  CardConsecutiv eIndex 
El índice consecutivo de una tarjeta [definición h)]. 
Asignación de valor: (véase anex o 1C, capítulo 7) 
Orden de incremento: ‘0, …, 9, A, …, Z, a, …, z’ 
2.15.  CardControlActivit yDat aRecord 
Información almacenada en una tarjeta de conduct or o de taller y relativa al último control a que ha sido 
sometido el conductor (anex o 1C, requisitos 274, 299, 327 y 350). 
controlT ype es el tipo de control. 
controlTime es la fecha y la hora del control. 26.5.2016 L 139/94 Diar io Oficial de la Unión Europea ES    
controlCardNumber es el FullCardNumber del controlador que ha llevado a cabo el control. 
controlV ehicleRegistration es el VRN y el nombre del Estado miembro donde se matr iculó el vehículo que ha 
sido objeto del control. 
controlDo wnloadPeriodBegin y controlDo wnloadPerio dEnd es el período transferido, en caso de transfe ­
rencia. 
2.16.  CardCur rentUse 
Información acerca del uso actual de la tarjeta (anex o 1C, requisit os 273, 298, 326 y 349). 
sessionOpen Time es la hora en que se inser ta la tarjeta para el uso actual. Este elemento se pone a cero al 
extraer la tarjeta. 
sessionOpenV ehicle es la identif icación del vehículo que se está utilizando actualmente. conf igurada al inser tar 
la tarjeta. Este elemento se pone a cero al extraer la tarjeta. 
2.17.  CardDr iverActivity 
Información almacenada en una tarjeta de conduct or o de taller y relativa a las actividades del conduct or 
(anex o 1C, requisitos 267, 268, 292, 293, 321 y 344). 
activityPointer Oldest Day Record es un element o que señala el comienzo del espacio de almacenamiento 
(número de bytes a partir del principio de la cadena) que corresponde al registro diar io compl eto más antiguo 
en la cadena activityDailyRecords. El valor máximo viene dado por la longitud de la cadena. 
activityPointer New estRecord es un element o que señala el comienzo del espacio de almacenamiento (número 
de bytes a partir del principio de la cadena) que corresponde al registro diar io más reciente en la cadena activity ­
DailyRecords. 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 conduct or 
(estr uctura de datos: CardA ctivityDailyRecord) 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 CardA ctivity ­
DailyRecord. En el primer uso, el almacenamient o 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 independencia de si hay alguna interr upció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 activity ­
DailyRecord) que sustituyan a datos antiguos, es preciso actualizar el activityP ointerOldestDa yRecord para 
reflejar la nueva ubicación del registro diar io compl eto más antiguo, y además es preciso poner a 0 la longitud 
activityPreviousRecordLength de este (nuevo) registro diar io compl eto más antiguo. 
2.18.  CardDr ivingLicenceInfo rmation 
Información almacenada en una tarjeta de conductor y relativa a los datos correspondientes al permiso de 
conducir del titular de la tarjeta (anex o 1C, requisit os 259 y 284). 26.5.2016 L 139/95 Diar io Oficial de la Unión Europea ES    
drivingLicenceIssuingAuthor ity es la autori dad que expidió el permiso de conducir . 
drivingLicenceIssuingNation es la nacionalidad de la autori dad que expidió el permiso de conducir . 
drivingLicenceNumber es el número del permiso de conducir . 
2.19.  CardEv entData 
Información almacenada en una tarjeta de conduct or o de taller relativa a los incidentes asociados al titular de la 
tarjeta (anex o 1C, requisitos 260, 285, 318 y 341). 
CardEv entData es una secuencia de cardEventRecords ordenada por valor ascendente del código EventFaultT ype 
(except o los registros relacionados con intentos de violación de la segur idad, que se incluyen en el último 
conjunto de la secuencia). 
cardEv entRecords es un conjunt o de registros de incident es de un tipo en particular (o de una catego ría en 
particular , en el caso de los intentos de violación de la segur idad). 
2.20.  CardEv entRecord 
Información almacenada en una tarjeta de conduct or o de taller y relativa a un incidente asociado al titular de la 
tarjeta (anex o 1C, requisitos 261, 286, 318 y 341). 
eventT ype es el tipo de incidente. 
eventBegin Time es la fecha y la hora de comienzo del incidente. 
eventEndTime es la fecha y la hora en que term ina el incident e. 
eventV ehicleRegist ration es el VRN y el nombre del Estado miembro donde se matr iculó el vehículo en el que 
se produjo el incident e. 
2.21.  CardFaultData 
Información almacenada en una tarjeta de conduct or o de taller y relativa a los fallos asociados al titular de la 
tarjeta (anex o 1C, requisitos 263, 288, 318 y 341). 
26.5.2016 L 139/96 Diar io Oficial de la Unión Europea ES    
CardFaultData es una secuencia integrad a por un conjunt o con los registros de los fallos del aparato de control, 
seguido de un conjunt o con los registros de los fallos de la tarjeta. 
cardFaultRecords es un conjunto de registros de fallos de una cate goría determinada (del aparato de control o 
de la tarjeta). 
2.22.  CardFaultRecord 
Información almacenada en una tarjeta de conduct or o de taller y relativa a un fallo asociado al titular de la 
tarjeta (anex o 1C, requisitos 264, 289, 318 y 341). 
faultT ype es el tipo de fallo. 
faultBegin Time es la fecha y la hora de comienzo del fallo. 
faultEndTime es la fecha y la hora en que termina el fallo. 
faultV ehicleRegist ration es el VRN y el nombre del Estado miembro donde se matr iculó el vehículo en el que 
ocur rió el fallo. 
2.23.  CardIccIdentif ication 
Información almacenada en una tarjeta y relativa a la identif icación de la tarjeta con circuito integrado (CI) 
(anex o 1C, requisito 248). 
clockStop es el modo de parada de reloj, tal y como se define en el apéndice 2. 
cardExtendedSer ialNumber es el número de serie único de la tarjeta con CI, tal como se especifi ca más en 
detalle mediante el tipo de datos Exten dedSer ialNumber . 
cardAppro valNumber es el número de homologación de la tarjeta. 
cardPers onaliserID es la identificación personal de la tarjeta codificada como Manufact urerCode. 
embedderIcAssemblerId proporciona información sobre el integrador/montador del CI. 
icIdentif ier es el identif icador del CI que incor pora la tarjeta y del fabr icante de dicho CI, tal y como se define 
en la norma ISO/CEI 7816-6. 
2.24.  CardIdentif ication 
Información almacenada en una tarjeta y relativa a la identif icación de la tarjeta (anex o 1C, requisit os 255, 280, 
310, 333, 359, 365, 371 y 377). 26.5.2016 L 139/97 Diar io Oficial de la Unión Europea ES    
cardIssuingMemberStat e es el código del Estado miembro que expide la tarjeta. 
cardNumber es el número de la tarjeta. 
cardIssuingAuthor ityName es el nombre de la autor idad que ha expedido la tarjeta. 
cardIssueDate es la fecha en que se expidió la tarjeta al titular actual. 
cardV alidityBegin es la fecha correspondiente al primer día de validez de la tarjeta. 
cardExpir yDate es la fecha en que term ina la validez de la tarjeta. 
2.25.  CardMA Cer tificate 
Generación 2: 
Certificad o de la clave pública de la tarjeta para la autenti cación mutua con una VU. La estructura de este 
certificado se especifica en el apéndice 11. 
2.26.  CardNumber 
Un número de tarjeta, según se indica en la definición g). 
driverIdentif ication es la identif icación excl usiva de un conductor en un Estado miembro. 
ownerIdentif ication es la identificación excl usiva de una empr esa, un taller o un orga nismo de control en un 
Estado miembro. 
cardConsecutiv eIndex es el índice consecutivo de la tarjeta. 
cardReplacementIndex es el índice de sustitución de la tarjeta. 26.5.2016 L 139/98 Diar io Oficial de la Unión Europea ES    
cardRenewalIndex es el índice de reno vación de la tarjeta. 
La primera de las dos secuencias a elegir sirve para codificar el número de una tarjeta de conduct or, mientras 
que la segunda secuencia sirve para codificar los números de las tarjetas de taller , de control y de empr esa. 
2.27.  CardPlaceDailyW orkPeriod 
Información almacenada en una tarjeta de conductor o en una tarjeta de taller y relativa a los lugar es donde 
comienzan y/o term inan los períodos de traba jo diar ios (anex o 1C, requisit os 272, 297, 325 y 348). 
placeP ointerNew estR ecord 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 conjunt o de registros que contienen la información relativa a los lugares introducidos. 
2.28.  CardPr ivateKey 
Generación 1: 
La clave privada de una tarjeta. 
2.29.  CardPublicKey 
La clave pública de una tarjeta. 
2.30.  CardRenewalIndex 
El índice de reno vación de una tarjeta [def inición i)]. 
Asignación de valor: (véase el capítulo VII del present e anex o). 
‘0’  Primera expedición. 
Orden de incremento: ‘0, …, 9, A, …, Z’ 
2.31.  CardReplacementIndex 
El índice de sustitución de una tarjeta [def inición j)]. 
Asignación de valor: (véase el capítulo VII del present e anex o). 
‘0’  Tarjeta original. 
Orden de incremento: ‘0, …, 9, A, …, Z’ 26.5.2016 L 139/99 Diar io Oficial de la Unión Europea ES    
2.32.  CardSignCer tificate 
Generación 2: 
Certificad o de la clave pública de la tarjeta para su firma. La estructura de este certificado se especific a 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.  CardSlotsSt atus 
Código que indica el tipo de tarjetas inser tadas en las dos ranuras de la unidad instalada en el vehículo. 
Asignación de valor — Alineación de octeto: ‘ccccdddd’B 
‘cccc’B  Identif icación del tipo de tarjeta inser tada en la ranura del segundo conductor , 
‘dddd’B  Identif icación del tipo de tarjeta inser tada en la ranura del conductor , 
con los siguientes códigos de identificación: 
‘0000’B  no hay tarjeta inser tada, 
‘0001’B  se ha inser tado una tarjeta de conduct or, 
‘0010’B  se ha inser tado una tarjeta de taller , 
‘0011’B  se ha inser tado una tarjeta de control, 
‘0100’B  se ha inser tado una tarjeta de empresa. 
2.35.  CardSlotsSt atusRecordAr ray 
Generación 2: 
El CardSlotsStatus más metadatos tal como se utilizan en el protocolo de transfer encia. 
recordT ype denota el tipo de registro (CardSlotsStatus). Asignación de valor : véase RecordT ype 
recordSize es el tamaño de CardSlotsStatus en bytes. 26.5.2016 L 139/100 Diar io Oficial de la Unión Europea ES    
noOfRecords es el número de registros que hay en el conjunt o. 
records es el conjunt o de registros de CardSlotsStatus. 
2.36.  CardStr uctureV ersion 
Código que indica la versión de la estructura empleada en una tarjeta de tacógraf o. 
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 
‘bb’H  Índice para cambios relativ os al uso de los elementos de datos definidos para la estructura que 
viene dada por el byte alto. 
‘00’H para esta versión de las aplicaciones de la Generación 1 
‘00’H para esta versión de las aplicaciones de la Generación 2 
2.37.  CardV ehicleRecord 
Información almacenada en una tarjeta de conduct or o de taller y relativa a un período de uso de un vehículo 
durante un día civil (anex o 1C, requisitos 269, 294, 322 y 345). 
Generación 1: 
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 term inar el período de uso del vehículo. 
vehicleFi rstUse es la fecha y la hora en que comienza el período de uso del vehículo. 
vehicleLas tUse es la fecha y la hora en que term ina el período de uso del vehículo. 
vehicleRegist ration es el VRN y el Estado miembro donde se ha matr iculado el vehículo. 
vuData BlockCounter es el valor del VuDataBlock Counter en el momento de extraer la tarjeta por última vez en 
el período de uso del vehículo. 26.5.2016 L 139/101 Diar io Oficial de la Unión Europea ES    
Generación 2: 
Además de los de la generación 1, se utiliza el siguient e element o de datos: 
VehicleIdentif icationNumber es el número de identif icación del vehículo refer ido al vehículo compl eto. 
2.38.  CardV ehiclesUsed 
Información almacenada en una tarjeta de conduct or o de taller relativa a los vehículos empleados por el titular 
de la tarjeta (anex o 1C, requisitos 270, 295, 323 y 346). 
vehiclePointer New estRecord 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’. 
cardV ehicleRecords es el conjunto de registros con información sobre los vehículos utilizados. 
2.39.  CardV ehicleUnitRecord 
Generación 2: 
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 (anex o 1C, requisitos 303 y 351). 
timeSt amp 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 instalada en el vehículo en el período). 
manufacturerCode identif ica al fabricante de la unidad instalada en el vehículo. 
deviceID identif ica el tipo de unidad instalada en el vehículo de un fabricante. El valor es particular del 
fabricant e. 
vuSof twareV ersion es el número de la versión de software que lleva instalado la unidad instalada en el vehículo. 
2.40.  CardV ehicleUnitsUsed 
Generación 2: 
Información almacenada en una tarjeta de conduct or o de taller y relativa a las unidades instaladas en el vehículo 
utilizadas por el titular de la tarjeta (anex o 1C, requisitos 306 y 352). 26.5.2016 L 139/102 Diar io Oficial de la Unión Europea ES    
vehicleUnitPoi nterNew estR ecord es el índice del último registro actualizado 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 estructura se le asigna el número ‘0’. 
cardV ehicleUnitRecords es el conjunt o de registros con información sobre las unidades instaladas en el 
vehículo utilizadas. 
2.41.  Cer tificate 
El certificado de una clave pública expedido por una autori dad de certificación. 
Generación 1: 
Asignación de valor : firma digital con recuperación parcial de un CertificateCont ent, con arreglo al apéndice 
11 «Mecanismos de segur idad comunes»: firma (128 bytes) || resto de la clave pública (58 bytes) || referencia de 
la autori dad de certificación (8 bytes). 
Generación 2: 
Asignación de valor: véase el apéndice 11. 
2.42.  Cer tificateContent 
Generación 1: 
El contenido (sin cifrar) del certificado de una clave pública, con arreglo al apéndice 11 «Mecanismos de 
segur idad comunes». 
certificateProf ileIdentif ier es la versión del certificado que corresponda. 
Asignación de valor: ‘01h’ para esta versión. 
certificationAuthor ityRefer ence identif ica a la autor idad de certificaci ón que expide el certificado. También es 
una referencia a la clave pública de dicha autori dad de certificación. 
certificateHolderAuthor isation identifica los derechos que asisten al titular del certificado. 
certificateEndOfV alidity es la fecha en que expira administrativamente el certificado. 
certificateHolderRef erence identifica al titular del certificad o. También es una referencia a su clave pública. 
publicKey es la clave pública que se certifica con este certificado. 26.5.2016 L 139/103 Diar io Oficial de la Unión Europea ES    
2.43.  Cer tificateHolderAuthor isation 
Identif icación de los derechos que asisten al titular de un certificado. 
Generación 1: 
tacho graphApplicationID es el identif icador de la aplicación de tacógraf o. 
Asignación de valor: ‘FFh’ ‘54h’ ‘41h’ ‘43h’ ‘48h’ ‘4Fh’. Este AID es un identif icador propio y no registrado de la 
aplicación, con arreglo a la norma ISO/CEI 7816-5. 
equipmentT ype es la identif icación del tipo de equipo al que se refiere el certificado. 
Asignación de valor: de acuerdo con el tipo de datos EquipmentT ype. 0 si el certificado es de un Estado 
miembro. 
Generación 2: 
tacho graphApplicationID denota los 6 bytes más signif icativ os del identif icador de aplicación (AID) de la 
tarjeta de tacógraf o de generación 2. La AID de la aplicación de la tarjeta de tacógraf o se especifica en el capítulo 
6.2. 
Asignación de valor : ‘FF 53 4D 52 44 54’. 
equipmentT ype es la identif icación del tipo de equipo según lo especificado para la generación 2 a que se 
refie re el certificado. 
Asignación de valor: de acuerdo con el tipo de datos EquipmentT ype. 
2.44.  Cer tificateRequest ID 
Identif icacion exclusiva de una solicitud de certificado. También puede utilizarse como identif icador de la clave 
pública de una unidad instalada en el vehículo si en el moment o de generar el certificado se desconoce el 
número de serie de la unidad a la que se refiere la clave. 
request SerialNumber es un número de serie para la solicitud de certificado, excl usivo para el fabr icante y para 
el mes a que se refie re la línea siguiente . 
request MonthY ear es la identif icació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) . 
crIdentif ier: 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ér ico del fabr icante que solicita el certificado. 
2.45.  Cer tificationAuthor ityKID 
Identif icador de la clave pública de una autoridad de certificación (un Estado miembro o la autor idad de certifi­
cación europea). 26.5.2016 L 139/104 Diar io Oficial de la Unión Europea ES    
nationNumer ic es el código numér ico de nación de la autoridad de certificación. 
nationAlpha es el código alfanumér ico de nación de la autori dad de certificación. 
keySer ialNumber es un número de serie para distinguir las diferente s claves de la autori dad de certificación en 
caso de que estas se cambien. 
additionalInfo es un campo de dos bytes para codif icación adicional (específica de la autori dad de certificación). 
caIdentif ier es un identificad or para distinguir entre el identif icador de clave de una autori dad de certificaci ón y 
otros identif icadores de clave. 
Asignación de valor: ‘01h’ . 
2.46.  CompanyA ctivityData 
Información almacenada en una tarjeta de empresa y relativa a las actividades que se realizan con la tarjeta 
(anex o 1C, requisitos 373 y 379). 
companyP ointerNew estRecord es el índice del último compan yActivityRecord 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’. 
companyA ctivityRecords es el conjunto de todos los registros de actividades de la empresa. 
companyA ctivityRecord es la secuencia de información relativa a una actividad de la emp resa. 
companyA ctivityT ype es el tipo de actividad de la empresa. 
companyA ctivityTime es la fecha y la hora de la actividad de la empr esa. 
cardNumberInfo rmation es el número de tarjeta y el nombre del Estado miembro que ha expedido la tarjeta 
cuyos datos se han transferi do, en tal caso. 
vehicleRegist rationInf ormation es el VRN y el nombre del Estado miembro donde se ha matr iculado el 
vehículo cuyos datos se han transferido o cuyo bloqueo se ha activado o desactivado. 
downloadPerio dBegin y downloadPerio dEnd es el período transferido de la VU, en tal caso. 26.5.2016 L 139/105 Diar io Oficial de la Unión Europea ES    
2.47.  CompanyA ctivityT ype 
Código que indica una actividad realizada por una empr esa haciendo uso de su tarjeta de empresa. 
2.48.  CompanyCardApplicat ionIdentif ication 
Información almacenada en una tarjeta de empresa y relativa a la identif icación de la aplicación de la tarjeta 
(anex o 1C, requisitos 369 y 375). 
typeOfT achog raphCardId especifica el tipo de tarjeta utilizado. 
cardStr uctureV ersion especifica la versión de la estructura que se utiliza en la tarjeta. 
noOfCompan yActivityRecords es el número de registros de actividades de la emp resa que puede almacenar la 
tarjeta. 
2.49.  CompanyCardHo lderIdentif ication 
Información almacenada en una tarjeta de empresa y relativa a la identificación del titular de dicha tarjeta (anex o 
1C, requisitos 372 y 378). 
companyName es el nombre de la emp resa titular . 
companyA ddress es la dirección de la empr esa titular . 
cardHolderPreferredLan guage es el idioma prefer ido por el titular de la tarjeta. 
2.50.  ControlCardApplicationIdentif ication 
Información almacenada en una tarjeta de control y relativa a la identificaci ón de la aplicación de la tarjeta 
(anex o 1C, requisitos 357 y 363). 
typeOfT achog raphCardId especifica el tipo de tarjeta utilizado. 
cardStr uctureV ersion especifica la versión de la estructura que se utiliza en la tarjeta. 
noOfControlAc tivityRecords es el número de registros de actividades de control que puede almacenar la 
tarjeta. 26.5.2016 L 139/106 Diar io Oficial de la Unión Europea ES    
2.51.  ControlCardControlActivityDa ta 
Información almacenada en una tarjeta de control y relativa a las actividades que se realizan con la tarjeta (anex o 
1C, requisitos 361 y 367). 
controlPoin terNew estRecord es el índice del último registro actualizado de una actividad de control. 
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’. 
controlActivi tyRecords es el conjunto de todos los registros de actividades de control. 
controlActivi tyRecord es la secuencia de información relativa a un control. 
controlT ype 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. 
controlledV ehicleRegistration es el VRN y el nombre del Estado miembro donde se matr iculó el vehículo que 
ha sido objeto del control. 
controlDo wnloadPeriodBegin y controlDo wnloadPerio dEnd es el período cuyos datos se transfieren. 
2.52.  ControlCardHolderIdentif ication 
Información almacenada en una tarjeta de control y relativa a la identif icación del titular de la tarjeta (anex o 1C, 
requisitos 360 y 366). 
controlBodyName es el nombre del organismo de control que corresponde al titular de la tarjeta. 
controlBodyA ddress es la dirección del organismo de control que corresponde al titular de la tarjeta. 
cardHolderName es el nombre y los apellidos del titular de la tarjeta de control. 
cardHolderPreferredLan guage es el idioma prefer ido por el titular de la tarjeta. 26.5.2016 L 139/107 Diar io Oficial de la Unión Europea ES    
2.53.  ControlT ype 
Código que indica las actividades realizadas durant e un control. Este tipo de datos está relacionado con el anex o 
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 durant e esta actividad de control, 
‘1’B: datos de la tarjeta transfe ridos durante esta actividad de control 
‘v’B  transferencia de los datos de la VU: 
‘0’B: datos de la VU no transferidos durant e esta actividad de control, 
‘1’B: datos de la VU transferi dos durante esta actividad de control 
‘p’B  impresión: 
‘0’B: no se imprimen datos durant e esta actividad de control, 
‘1’B: se impr imen datos durante esta actividad de control 
‘d’B  visualización: 
‘0’B: no se visualizan datos durante esta actividad de control, 
‘1’B: se visualizan datos durant e esta actividad de control 
‘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 durant e esta actividad de control, 
‘1’B: datos de la tarjeta transfe ridos durante esta actividad de control 
‘v’B  transferencia de los datos de la VU: 
‘0’B: datos de la VU no transferidos durant e esta actividad de control, 
‘1’B: datos de la VU transferi dos durante esta actividad de control 
‘p’B  impresión: 
‘0’B: no se imprimen datos durant e esta actividad de control, 
‘1’B: se impr imen datos durante esta actividad de control 
‘d’B  visualización: 
‘0’B: no se visualizan datos durante esta actividad de control, 
‘1’B: se visualizan datos durant e esta actividad de control 26.5.2016 L 139/108 Diar io Oficial de la Unión Europea ES    
‘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. 
2.54.  Cur rentDateTime 
La fecha y la hora actuales del aparato de control. 
Asignación de valor: no hay más especificaciones. 
2.55.  Cur rentDateTimeRecordAr ray 
Generación 2: 
La fecha y la hora actuales más metadatos tal y como se utilizan en el protocolo de transferencia. 
recordT ype denota el tipo de registro (Cur rentDateTime). Asignación de valor: véase RecordT ype. 
recordSize es el tamaño de CurrentDateTim e en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es un conjunt o de registros de fecha y hora actuales. 
2.56.  DailyPresenceCounter 
Contador que está almacenado en una tarjeta de conduct or o de taller y que se incrementa en una unidad por 
cada día civil que se haya inser tado la tarjeta en una VU. Este tipo de datos está relacionado con los requisitos 
266, 299, 320 y 343 del anex o 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ér ico fácil de impr imir . 
26.5.2016 L 139/109 Diar io Oficial de la Unión Europea ES    
Asignación de valor: 
yyyy  año 
mm  mes 
dd  día 
‘00000000’H  denota explícitamente la ausencia de fecha. 
2.58.  DateOfDa yDo wnloaded 
Generación 2: 
La fecha y hora de la transfer encia. 
Asignación de valor: no hay más especificaciones. 
2.59.  DateOfDa yDo wnloadedRecordAr ray 
Generación 2: 
La fecha y la hora de la transfer encia más metadatos tal y como se utilizan en el prot ocolo de transfer encia. 
recordT ype denota el tipo de registro (DateOfDa yDo wnloaded). Asignación de valor : véase RecordT ype. 
recordSize es el tamaño de CurrentDateTim e en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es el conjunt o de fecha y hora de los registros de transfer encia. 
2.60.  Dist ance 
Una distancia recor rida (resultado de calcular la diferencia en kilómetros entre dos lecturas del cuentakilómetros 
del vehículo). 
Asignación de valor: número binar io sin signo. Valor en km en el inter valo operativo de 0 a 9 999 km. 
2.61.  DriverCardApplicationIdentif ication 
Información almacenada en una tarjeta de conduct or y relativa a la identif icación de la aplicación de la tarjeta 
(anex o 1C, requisitos 253 y 278). 26.5.2016 L 139/110 Diar io Oficial de la Unión Europea ES    
Generación 1: 
typeOfT achog raphCardId especifica el tipo de tarjeta utilizado. 
cardStr uctureV ersion especifica la versión de la estructura que se utiliza en la tarjeta. 
noOfEv entsP erType es el número de incident es de cada tipo que puede registrar la tarjeta. 
noOfFaultsPerT ype es el número de fallos de cada tipo que puede registrar la tarjeta. 
activityStr uctureLength indica el número de bytes disponibles para almacenar registros de actividad. 
noOfCardV ehicleRecords 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: 
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 continua que puede almacenar la tarjeta. 
noOfSpecif icConditionRecords es el número de registros de condiciones específi cas que puede almacenar la 
tarjeta. 
2.62.  DriverCardHolderIdentif ication 
Información almacenada en una tarjeta de conductor y relativa a la identif icación del titular de la tarjeta (anex o 
1C, requisitos 256 y 281). 
cardHolderName es el nombre y los apellidos del titular de la tarjeta de conduct or. 26.5.2016 L 139/111 Diar io Oficial de la Unión Europea ES    
cardHolderBir thDate es la fecha de nacimiento del titular de la tarjeta de conduct or. 
cardHolderPreferredLan guage es el idioma prefer ido por el titular de la tarjeta. 
2.63.  DSR CSecur ityData 
Generación 2: 
La información en texto sin formato y el MAC que deben transmitirse a través de DSR C desde el tacógraf o al 
interr ogador remot o (RI), véanse detalles en el apéndice 11, parte B, capítulo 13. 
tagL ength forma parte de la codificación DER -TLV y debe ponerse a ‘81 10’ (véase el apéndice 11, parte B, 
capítulo 13). 
currentDateTime es la fecha y la hora actuales de la unidad instalada en el vehículo. 
counter enumera los mensa jes RTM. 
vuSer ialNumber es el número de serie de la unidad instalada en el vehículo. 
dSR CMKV ersionNumber es el número de versión de la clave maestra DSR C de la que se derivaron las claves 
DSR C específic as de VU. 
tagL engthMac es la etiqueta y la longitud del objeto de datos MAC como parte de la codificación DER -TLV. La 
etiqueta deberá ser ‘8E’ y la longitud codificará la longitud del MAC en octetos (véase el apéndice 11, parte B, 
capítulo 13). 
mac es el MAC calculado sobre el mensaje RTM (véase el apéndice 11, parte B, capítulo 13). 
2.64.  EGFCer tificate 
Generación 2: 
Certificad o de la clave pública del dispositivo GNSS extern o para la autenticación mutua con una VU. La 
estructura de este certificado se especifica en el apéndice 11. 
2.65.  EmbedderIcAssemblerId 
Facili ta información sobre el integrad or del CI. 
26.5.2016 L 139/112 Diar io Oficial de la Unión Europea ES    
countr yCode es el código de país de dos letras del integrador del módulo conf orme a la norma ISO 3166. 
moduleEmbedder identifica al integrador del módulo. 
manufacturerInfor mation para uso intern o del fabricante. 
2.66.  Entr yTypeDailyW orkPeriod 
Código para distinguir entre el comienzo y el final cuando se introduce un período diar io de traba jo, 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. 
Generación 2 
Asignación de valor: con arreglo a la norma ISO/CEI 8824-1. 
2.67.  EquipmentT ype 
Código para distinguir diferentes tipos de equipos para la aplicación de tacógraf o. 
Generación 1: 
Asignación de valor: con arreglo a la norma ISO/CEI 8824-1. 
El valor 0 se reser va para designar a un Estado miembro o a Europa en el campo CHA de los certificados. 26.5.2016 L 139/113 Diar io Oficial de la Unión Europea ES    
Generación 2: 
se utilizan los mismos valores que en la generación 1, con los siguiente s añadidos: 
Nota: Pueden utilizarse en SealRecord, si procede, los valores de generación 2 de la placa, el adaptador y la 
conexión del GNSS exte rno, así como los valores de generación 1 de la unidad instalada en el vehículo y el 
sensor de movimient o.  
2.68.  EuropeanPublicKey 
Generación 1: 
La clave pública europea. 
2.69.  EventFaultRecordPur pose 
Código que explica por qué se ha registrado un incident e o fallo. 
Asignación de valor : 
uno de los diez incidentes o fallos más recient es (o de los diez últimos) 
el incidente de más duración ocur rido en uno de los diez últimos días en que se hayan produ ­
cido incidentes de este tipo 
uno de los cinco incidentes de más duración ocur ridos en los últimos 365 días 
el último incidente ocur rido en uno de los diez últimos días en que se hayan producido inci­
dentes 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 ocur ridos en los últimos 365 días 
el primer incidente o fallo ocur rido tras el último calibrado 
un incidente o fallo activo/en curso 
RFU 
específi ca del fabricante  
2.70.  EventFaultT ype 
Código que calif ica 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, 
Conf licto 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, 
Interr upción del suministro eléctr ico, 
Error en datos de movimiento, 
Conf licto de movimiento del vehículo, 
RFU, 26.5.2016 L 139/114 Diar io Oficial de la Unión Europea ES    
Inten tos de violación de la segur idad relacionados con la VU, 
No hay más información, 
Fallo de aute nticación del sensor de movimiento, 
Fallo de aute nticación de la tarjeta de tacógraf o, 
Cambio no auto rizado del sensor de movimiento, 
Error de integr idad en la entrada de los datos de la tarjeta, 
Error de integr idad en los datos de usuar io almacenados, 
Error en una transferencia inter na de datos, 
Aper tura no autor izada de la carcasa, 
Sabotaje del hardware, 
RFU, 
Inten tos de violación de la segur idad relacionados con el sensor , 
No hay más información, 
Fallo de aute nticación, 
Error de integr idad en los datos almacenados, 
Error en una transferencia inter na de datos, 
Aper tura no autor izada 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 transferen cia, 
Fallo del sensor , 
RFU, 
Fallos de las tarjetas, 
No hay más información, 
RFU, 
RFU, 
específi cos del fabri cante.   
Generación 2: 
se utilizan los mismos valores que en la generación 1, con los siguiente s añadidos: 
Conf licto temporal (entre el GNSS y el reloj interno de la VU), 
RFU, 
Fallos relacionados con el GNSS, 
No hay más información, 
Fallo del recept or GNSS interno, 
Fallo del recept or GNSS externo, 
Fallo del dispositivo de comunicación GNSS extern o, 
Ause ncia de datos de posición GNSS, 
Detecci ón de manipulación de GNSS, 
Certificado del dispositivo GNSS extern o expirado, 
RFU, 
Fallos relacionados con el módulo de comunicación a distancia, 
No hay más información, 
Fallo del módulo de comunicación a distancia, 
Fallo de comunicación del módulo de comunicación a distancia, 
RFU, 
Fallos de la interfaz ITS, 
No hay más información, 
RFU.   
2.71.  ExtendedSealIdentif ier 
Generación 2: 
El identif icador de precinto ampli ado identifica de manera única un precint o (anex o 1C, requisito 401). 26.5.2016 L 139/115 Diar io Oficial de la Unión Europea ES    
manufacturerCode es un código del fabricante del precint o. 
sealIdentif ier es un identificador del precinto que es excl usivo para el fabricante. 
2.72.  ExtendedSer ialNumber 
Identif icación excl usiva de un equipo. También puede utilizarse como el identif icador de clave pública de un 
equipo. 
Generación 1: 
serialNumber es el número de serie de un equipo; excl usivo para el fabr icante , para el tipo de equipo y para el 
mes y año a que se refiere la línea siguient e. 
monthY ear es la identif icació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 identif icador del tipo de equipo. 
Asignación de valor: específica del fabr icante , con ‘FFh’ valor reser vado. 
manufacturerCode: es el código numér ico que identif ica al fabricante de un equipo homolog ado. 
Generación 2: 
serialNumber véase generación 1 
monthY ear véase generación 1 
type indica el tipo de equipo 
manufacturerCode: véase generación 1. 
2.73.  FullCardNumber 
Código que identif ica por complet o a una tarjeta de tacógraf o. 26.5.2016 L 139/116 Diar io Oficial de la Unión Europea ES    
cardT ype es el tipo de tarjeta de tacógraf o. 
cardIssuingMemberStat e es el código del Estado miembro que ha expedido la tarjeta. 
cardNumber es el número de la tarjeta. 
2.74.  FullCardNumberAndGeneration 
Generación 2: 
Código que identif ica por complet o a una tarjeta de tacógraf o y su generación. 
fullcardNumber identifica la tarjeta de tacógraf o. 
generation indica la generación de la tarjeta de tacógraf o utilizada. 
2.75.  Generation 
Generación 2: 
Indica la generación del tacógraf o 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 
Generación 2: 
Las coordenadas geográfic as se codifican con números enteros. Estos enteros son múltiplos de la codificación 
± GGMM.M para la latitud y ± GGGMM.M para la longitud, donde ± GG y ± GGG denotan los grados y MM.M 
los minutos. 
latitude se codifica como un múltiplo (factor 10) de la representación ± GGMM.M. 
longitude se codifica como un múltiplo (fact or 10) de la representación ± GGGMM.M. 26.5.2016 L 139/117 Diar io Oficial de la Unión Europea ES    
2.77.  GNSSA ccuracy 
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 (fact or 10) del valor X.Y facilitado por la sente ncia GSA NMEA. 
2.78.  GNSSContinuousDr iving 
Generación 2: 
Información almacenada en una tarjeta de conduct or o de taller y relativa a la posición GNSS del vehículo si el 
tiempo de conducción continua del conduct or alcanza un múltiplo de tres horas (anex o 1C, requisitos 306 y 
354). 
gnssCDPoin terNew estRecord es el índice del último registro actualizado de conducción continua del GNSS. 
Asignación de valor: número correspondiente al numerador del registro de conducción continua del GNSS. Al 
primer registro de la estructura se le asigna el número ‘0’. 
gnssContinuousDr ivingRecords es el conjunt o de registros que contienen la fecha y hora en que la 
conducción continua alcanza un múltiplo de tres horas e información sobre la posición del vehículo. 
2.79.  GNSSContinuousDr ivingRecord 
Generación 2: 
Información almacenada en una tarjeta de conduct or o de taller y relativa a la posición GNSS del vehículo si el 
tiempo de conducción continua del conduct or alcanza un múltiplo de tres horas (anex o 1C, requisitos 305 y 
353). 
timeSt amp es la fecha y hora en las que el tiempo de conducción continua del titular de la tarjeta llega a un 
múltiplo de tres horas. 
gnssPlaceRecord contiene información relacionada con la posición del vehículo. 
2.80.  GNSSPlaceRecord 
Generación 2: 
Información relacionada con la posición GNSS del vehículo (anex o 1C, requisitos 108, 109, 110, 296, 305, 347 
y 353). 
26.5.2016 L 139/118 Diar io Oficial de la Unión Europea ES    
timeSt amp es la fecha y la hora en que se determi nó la posición GNSS del vehículo. 
gnssAccu racy 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 recor rido el vehículo durante su funciona ­
miento. 
Asignación de valor: número binar io sin signo. Valor en 1/200 km en el inter valo operativo de 0 a 
21 055 406 km. 
2.82.  HighResT ripDist ance 
La distancia recor rida durante todo o parte de un viaje. 
Asignación de valor: número binar io sin signo. Valor en 1/200 km en el inter valo operativo de 0 a 
21 055 406 km. 
2.83.  HolderName 
El nombre y apellidos del titular de una tarjeta. 
holderSur name son los apellidos del titular . No incluy e el tratamient o. 
Asignación de valor : cuando una tarjeta no es personal, holderSur name contiene la misma información que 
compan yName o workshopNam e o controlBodyName. 
holderFir stNames es el nombre y las iniciales del titular . 
2.84.  Inter nalGNSSReceiv er 
Generación 2: 
Información sobre si el recep tor GNSS es interno o exte rno a la unidad instalada en el vehículo. True signif ica 
que el recep tor GNSS es interno a la VU. False signif ica que el recep tor GNSS es externo. 
2.85.  K-Cons tantOfRecordingEquipment 
Constante del aparat o de control [def inición m)]. 
Asignación de valor: impulsos por kilómetro en el intervalo operativo de 0 a 64 255 impulsos/km. 26.5.2016 L 139/119 Diar io Oficial de la Unión Europea ES    
2.86.  KeyIdent ifier 
Un identif icador excl usivo de una clave pública, empleado para hacer referencia a dicha clave y seleccionarla. 
También identif ica 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 o de una 
tarjeta de tacógraf o. 
La segunda opción sirve para hacer referencia a la clave pública de una VU (en caso de que el número de serie 
de dicha VU no pueda conocerse en el momento de generarse el certificado). 
La terce ra opción sirve para hacer referencia a la clave pública de un Estado miembro. 
2.87.  KMW CKey 
Generación 2: 
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. 
kMW CKey es la longitud de la clave AES concatenada con la clave que se utiliza para el emparejamient o VU — 
sensor de movimient o. 
keyVersion denota la versión de la clave AES. 
2.88.  Language 
Código que identif ica un idioma. 
Asignación de valor: codificación mediante dos letras en minúsculas con arreglo a la norma ISO 639. 
2.89.  Last CardDo wnload 
Fecha y hora, almacenadas en una tarjeta de conduct or, de la última transferencia de los datos de la tarjeta (para 
fines distintos de los de control), anex o 1C, requisitos 257 y 282. Esta fecha puede ser actualizada por una VU o 
por cualquier lector de tarjetas. 
Asignación de valor: no hay más especificaciones. 
2.90.  LinkCer tificate 
Generación 2: 
Certificad o de enlace entre pares de claves de la European Root CA. 
26.5.2016 L 139/120 Diar io Oficial de la Unión Europea ES    
2.91.  L-TyreCircumference 
Circunferencia efectiva de los neumáticos de las ruedas [definición u)]. 
Asignación de valor: número binar io sin signo, valor en 1/8 mm en el intervalo operativo de 0 a 8 031 mm. 
2.92.  MA C 
Generación 2: 
Una suma de control criptográfi ca de 8, 12 o 16 bytes de longitud correspondiente a los conjuntos de cifrado 
que se especifi can en el apéndice 11. 
2.93.  ManualInputFlag 
Código que indica si el titular de una tarjeta, en el momento de inser tar dicha tarjeta, ha introducido o no 
manualment e alguna actividad del conduct or (anex o 1B, requisito 081, y anex o 1C, requisit o 102). 
Asignación de valor: no hay más especificaciones. 
2.94.  ManufacturerCode 
Código que identif ica al fabricante de un aparat o homologad o. 
El laboratori o encarg ado de los ensa yos de inter operabilidad conser vará y publicará en su sitio web la lista de 
códigos de fabricantes (anex o 1C, requisito 454). 
Los códigos de fabricante se asignarán provisionalment e a los desar rolladores de tacógraf os al presentar una 
solicitud al laboratori o compe tent e para realizar los ensa yos de interoperabilidad. 
2.95.  ManufacturerSpecif icEv entFaultData 
Generación 2: 
Los códigos de error específicos del fabr icante simplifican el análisis de errores y el manten imiento de las VU. 
26.5.2016 L 139/121 Diar io Oficial de la Unión Europea ES    
manufacturerCode identif ica al fabricante de la unidad instalada en el vehículo. 
manufacturerSpecif icEr rorCode es un código de error específico del fabr icante . 
2.96.  MemberSta teCer tificate 
El certificado de la clave pública de un Estado miembro, expedido por la autor idad de certificación europea. 
2.97.  MemberSta teCer tificateRecordAr ray 
Generación 2: 
El certificado del Estado miembro más metadatos tal y como se utilizan en el prot ocolo de transfer encia. 
recordT ype denota el tipo de registro (MemberStateCer tificate). Asignación de valor: véase RecordT ype. 
recordSize es el tamaño de MemberStat eCer tificate en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. El valor se pondrá a 1, ya que los certificados 
pueden tener diferentes longitudes. 
records es el conjunt o de certificados de Estado miembro. 
2.98.  MemberSta tePublicKe y 
Generación 1: 
La clave pública de un Estado miembro. 
2.99.  Name 
Un nombre. 
codePage especifica un conjunto de caract eres definidos en el capítulo 4, 
name representa un nombre codificado utilizando el conjunt o de caracte res especifi cado. 26.5.2016 L 139/122 Diar io Oficial de la Unión Europea ES    
2.100.  NationAlpha 
Toda referencia alfabética a un país se realizará con arreglo a los distintiv os utilizados en los vehículos en el 
tráfico internacional (Con vención de Viena sobre la circulación vial de las Naciones Unidas, 1968). 
Los códigos alfanumér icos que identif ican a los distintos países figurarán en una lista manten ida en el sitio web 
del laborat orio designado para realizar los ensa yos de inter operabilidad, tal y como establece en el anex o 1C, 
requisito 440. 
2.101.  NationNumer ic 
Referencia numér ica a un país. 
Asignación de valor: véase tipo de datos 2.100 (NationAlpha). 
Toda modificación o actualización de la especifi cación alfanumér ica relativa a los distintos países descr ita en el 
párrafo anterior tendrá lugar , únicamente, después de que el laborat orio designado haya obtenido las obser va­
ciones de los fabricantes de unidades instaladas en el vehículo de tacógraf os digitales e inteli gent es homolog ados. 
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. 
Generación 2: 
Asignación de valor: véase el apéndice 2. 
2.103.  NoOfCalibrationsSinceDo wnload 
Contador que indica el número de calibrados realizados con una tarjeta de taller desde que se transf irieran por 
última vez sus datos (anex o 1C, requisit os 317 y 340). 
Asignación de valor: no hay más especificaciones. 
2.104.  NoOfCardPlaceRecords 
Número de registros de lugar es que puede almacenar una tarjeta de conduct or 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. 26.5.2016 L 139/123 Diar io Oficial de la Unión Europea ES    
2.105.  NoOfCardV ehicleRecords 
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.  NoOfCardV ehicleUnitRecords 
Generación 2: 
Número de registros sobre unidades instalas en vehículos usados que puede almacenar una tarjeta de conduct or 
o de taller . 
Asignación de valor: véase el apéndice 2. 
2.107.  NoOfCompanyA ctivityRecords 
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. 
2.108.  NoOfControlActivityRe cords 
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.  NoOfEv entsPerT ype 
Número de incidentes de cada tipo que puede almacenar una tarjeta. 
Asignación de valor: véase el apéndice 2. 
2.110.  NoOfFaultsPerT ype 
Número de fallos de cada tipo que puede almacenar una tarjeta. 
Asignación de valor: véase el apéndice 2. 
2.111.  NoOfGNSSCDRecords 
Generación 2: 
Número de registros GNSS de conducción continua que puede almacenar una tarjeta. 
Asignación de valor: véase el apéndice 2. 26.5.2016 L 139/124 Diar io Oficial de la Unión Europea ES    
2.112.  NoOfSpecif icConditionRecords 
Generación 2: 
Número de registros de condición específi ca que puede almacenar una tarjeta. 
Asignación de valor: véase el apéndice 2. 
2.113.  OdometerShor t 
Lectura del cuentakilómetros del vehículo en forma abreviada. 
Asignación de valor: número binar io sin signo. Valor en km en el inter valo operativo de 0 a 9 999 999 km. 
2.114.  OdometerV alueMidnight 
La lectura del cuentakilómetros del vehículo a medianoc he de un día determinado (anex o 1B, requisit o 090, y 
anex o 1C, requisit o 113). 
Asignación de valor: no hay más especificaciones. 
2.115.  OdometerV alueMidnightRecordAr ray 
Generación 2: 
El Odomet erValueMidnight más metadatos tal como se utilizan en el protocolo de transfe rencia. 
recordT ype denota el tipo de registro (OdometerV alueMidnight). Asignación de valor : véase RecordT ype. 
recordSize es el tamaño de Odomet erValueMidnight en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es el conjunt o de registros de Odomet erValueMidnight. 
2.116.  OverspeedNumber 
Número de incidentes de exceso de velocidad ocur ridos desde el último control del exceso de velocidad. 
Asignación de valor : 0 signif ica que no se ha producido ningún incidente de exceso de velocidad desde el 
último control, 1 signif ica que se ha producido un incident e de exces o de velocidad desde el último control … 
255 significa que se han producido 255 o más incident es de exceso de velocidad desde el último control. 26.5.2016 L 139/125 Diar io Oficial de la Unión Europea ES    
2.117.  PlaceRecord 
Información relativa al lugar donde comienza o term ina un período de traba jo diar io (anex o 1C, requisitos 108, 
271, 296, 324 y 347). 
Generación 1: 
entr yTime es una fecha y una hora relacionadas con la entrada. 
entr yTypeDailyW orkPeriod es el tipo de entrada. 
dailyW orkPeriod Countr y es el país introducido. 
dailyW orkPeriod Region es la región introducida. 
vehicleOdometerV alue es la lectura del cuentakilómetros en el momento de introducir el luga r. 
Generación 2: 
Además de los de la generación 1, se utiliza el siguient e compo nente : 
entr yGNSSPlaceRecord es la localización y la hora registrada. 
2.118.  PreviousV ehicleInfo 
Información relativa al vehículo que utilizara previamente un conduct or al inser tar su tarjeta en una unidad 
instalada en el vehículo (anex o 1B, requisito 081, y anex o 1C, requisito 102). 
Generación 1: 
vehicleRegist rationIdentif ication es el VRN y el nombre del Estado miembro donde se matr iculara el vehículo. 
cardWithdrawa lTime es la fecha y la hora de extracción de la tarjeta. 
Generación 2: 
26.5.2016 L 139/126 Diar io Oficial de la Unión Europea ES    
Además de los de la generación 1, se utiliza el siguient e element o 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. 
rsaKeyMod ulus es el módulo del par de claves. 
rsaKeyPu blicExponent es el exponente público del par de claves. 
2.120.  RecordT ype 
Generación 2: 
Referencia a un tipo de registro. Este tipo de datos se utiliza en RecordAr rays. 
Asignación de valor : 
ActivityChangeI nfo, 
CardSlotsStatus, 
CurrentDateTime, 
MemberStateCer tificate, 
OdometerV alueMidnight, 
DateOfD ayDo wnloaded, 
SensorPaired, 
Signature, 
Specific ConditionRecord, 
VehicleIdentif icationNumber , 
VehicleRegistrationNumber , 
VuCalibrationRecord, 
VuCardIWRecord, 
VuCardRecord, 
VuCer tificate, 
VuCom panyLoc ksRe cord, 
VuControlA ctivityRecord, 
VuDetailedSpeedBlock, 
VuDo wnloadableP eriod, 
VuDo wnloadA ctivityData, 
VuEventRecord, 
VuGNSSCDRecord, 
VuITSConsentRecord, 
VuFaultRecord, 
VuIdentification, 
VuOverSpeedingControlData, 
VuOverSpeedingEventRecord, 
VuPlaceDailyW orkP eriodRecord, 
VuTimeA djustmentGNSSRecord, 
VuTimeA djustmentRecord, 
VuPowerSupplyInter ruptionRecord, 
SensorPairedRecord, 
SensorExternalGNSSC oupledRecord, 
RFU, 
específi cos del fabri cante.  26.5.2016 L 139/127 Diar io Oficial de la Unión Europea ES    
2.121.  RegionAlpha 
Referencia alfab ética a una región pertenecient e a un país especificado. 
Generación 1: 
Asignación de valor : 
Generación 2: 
Los códigos alfabéticos que identif ican a las distintas regiones figur arán en una lista mantenida en el sitio web 
del laboratori o designado para realizar los ensa yos de interoperabilidad. 
2.122.  RegionNumer ic 
Referencia numér ica a una región perteneciente a un país especific ado. 
Generación 1: 
Asignación de valor : 
26.5.2016 L 139/128 Diar io Oficial de la Unión Europea ES    
Generación 2: 
Los códigos numér icos que identif ican a las distintas regiones figur arán en una lista mantenida en el sitio web 
del laboratori o designado para realizar los ensa yos de interoperabilidad. 
2.123.  RemoteCommunicationModuleSer ialNumber 
Generación 2: 
número de serie del módulo de comunicación a distancia, 
2.124.  RSAKe yModulus 
Generación 1: 
El módulo de un par de claves RSA. 
Asignación de valor: no especifi cado. 
2.125.  RSAKe yPrivateExponent 
Generación 1: 
El exponente privado de un par de claves RSA. 
Asignación de valor: no especifi cado. 
2.126.  RSAKe yPublicExponent 
Generación 1: 
El exponente público de un par de claves RSA. 
Asignación de valor: no especifi cado. 
2.127.  RtmDat a 
Generación 2: 
Para la definición de este tipo de datos, véase el apéndice 14. 
2.128.  SealDat aCard 
Generación 2: 
Este tipo de datos almacena información sobre los precintos colocados en los distintos compo nentes de un 
vehículo y se destina al almacenamient o en una tarjeta. Este tipo de datos está relacionado con el anex o 1C, 
requisito 337. 26.5.2016 L 139/129 Diar io Oficial de la Unión Europea ES    
noOfSealRecords es el número de registros que hay en sealRecords. 
sealRecords es un conjunt o de registros sobre precintos. 
2.129.  SealDat aVu 
Generación 2: 
Este tipo de datos almacena información sobre los precintos colocados en los distintos compo nentes de un 
vehículo y se destina al almacenamient o en una unidad instalada en el vehículo. 
sealRecords es un conjunt o de registros sobre precintos . Si hay menos de cinco precint os, el valor de 
EquipmentT ype 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 precint o colocado en un compo nente. Este tipo de datos está 
relacionado con el anex o 1C, requisit o 337. 
equipmentT ype identif ica el tipo de aparat o en que se coloca el precinto. 
extendedSealIdentif ier es el identif icador del precint o colocado en el aparato. 
2.131.  SensorAppro valNumber 
Número de homologación del sensor . 
Generación 1: 
Asignación de valor: no especifi cado. 
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 ejem plo, incluyendo guiones si los lleva. El número de homologació n deberá 
estar alineado a la izquierda. 26.5.2016 L 139/130 Diar io Oficial de la Unión Europea ES    
2.132.  SensorExter nalGNSSA ppro valNumber 
Generación 2: 
número de homolog ació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 ejem plo, incluyendo guiones si los lleva. El número de homologació n deberá 
estar alineado a la izquierda. 
2.133.  SensorExter nalGNSSCoupledRecord 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a la identif icación del sensor de 
movimiento acoplado a dicha unidad (anex o 1C, requisit o 100). 
sensorSer ialNumber es el número de serie del dispositivo GNSS externo que está acoplado a la VU. 
sensorAppro valNumber es el número de homologació n de este dispositivo GNSS exte rno. 
sensorCouplingDate es la fecha de acoplamient o del dispositivo GNSS extern o con la VU. 
2.134.  SensorExter nalGNSSIdentif ication 
Generación 2: 
Información relativa a la identificación del dispositivo GNSS externo (anex o 1C, requisito 98). 
sensorSer ialNumber es el número de serie ampli ado del dispositivo GNSS externo. 
sensorAppro valNumber es el número de homologació n del dispositivo GNSS exte rno. 
sensorSCIdentif ier es el identif icador del component e de segur idad del dispositivo GNSS externo. 
sensorOSIdentif ier es el identif icador del sistema operativo del dispositivo GNSS exte rno. 26.5.2016 L 139/131 Diar io Oficial de la Unión Europea ES    
2.135.  SensorExter nalGNSSInst allation 
Generación 2: 
Información almacenada en un dispositivo GNSS externo y relativa a la instalación del sensor GNSS externo 
(anex o 1C, requisito 123). 
sensorCouplingDateFir st es la fecha del primer acoplamiento del dispositivo GNSS externo con una VU. 
firstV uAppro valNumber es el número de homologació n de la primera VU acoplada con el dispositivo GNSS 
externo. 
firstV uSer ialNumber es el número de serie de la primera VU acoplada con el dispositivo GNSS extern o. 
sensorCouplingDateCur rent es la fecha del acoplamiento actual del dispositivo GNSS exte rno con una VU. 
currentV uAppro valNumber es el número de homolog ación de la VU actualmente acoplada con el dispositivo 
GNSS externo. 
currentVUSer ialNumber es el número de serie de la VU actualmente acoplada con el dispositivo GNSS 
externo. 
2.136.  SensorExter nalGNSSOSIdentif ier 
Generación 2: 
Identif icador del sistem a operativo del dispositivo GNSS extern o. 
Asignación de valor: específica del fabr icante . 
2.137.  SensorExter nalGNSSSCIdentif ier 
Generación 2: 
Este tipo se utiliza, por ejemp lo, para identif icar el módulo criptográfi co del dispositivo GNSS exte rno. 
Identif icador del compo nente de segur idad del dispositivo GNSS externo. 
Asignación de valor: específica del fabr icante del component e. 26.5.2016 L 139/132 Diar io Oficial de la Unión Europea ES    
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.  SensorGNSSSer ialNumber 
Generación 2: 
Este tipo se utiliza para almacenar el número de serie del recept or GNSS tanto cuando esté dentro de la VU 
como cuando esté fuera de la VU. 
Número de serie del recept or GNSS. 
2.140.  SensorIdentif ication 
Información almacenada en un sensor de movimient o y relativa a la identif icación de dicho sensor (anex o 1B, 
requisito 077 y anex o 1C, requisito 95). 
sensorSer ialNumber es el número de serie ampli ado del sensor de movimient o (incluye el número de pieza y el 
código del fabricante). 
sensorAppro valNumber es el número de homologació n del sensor de movimient o. 
sensorSCIdentif ier es el identif icador del component e de segur idad del sensor de movimient o. 
sensorOSIdentif ier es el identif icador del sistema operativo del sensor de movimient o. 
2.141.  SensorInst allation 
Información almacenada en un sensor de movimient o y relativa a la instalación de dicho sensor (anex o 1B, 
requisito 099 y anex o 1C, requisito 122). 
sensorPair ingDateF irst es la fecha del primer emparejamiento del sensor de movimiento con una VU. 
firstV uAppro valNumber es el número de homolog ación de la primera VU emparej ada con el sensor de 
movimiento. 26.5.2016 L 139/133 Diar io Oficial de la Unión Europea ES    
firstV uSer ialNumber es el número de serie de la primera VU emparej ada con el sensor de movimiento. 
sensorPair ingDateCur rent es la fecha del emp arejamiento actual entre el sensor de movimient o y la VU. 
currentV uAppro valNumber es el número de homologa ción de la VU que está emparejada actualmente con el 
sensor de movimient o. 
currentVUSer ialNumber es el número de serie de la VU que está emparejada actualmente con el sensor de 
movimiento. 
2.142.  SensorInst allationSecData 
Información almacenada en una tarjeta de taller y relativa a los datos de segur idad necesar ios para emparej ar 
sensores de movimient o y unidades instaladas en vehículos (anex o 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 descr ibe en el apéndice 11, una tarjeta de taller deberá almacenar hasta tres claves de empareja ­
miento del sensor de movimient o con la VU. Estas claves tienen diferentes versiones de clave. 
2.143.  SensorOSIdentif ier 
Identif icador del sistem a operativo del sensor de movimiento. 
Asignación de valor: específica del fabr icante . 
2.144.  SensorPaired 
Generación 1: 
Información almacenada en una unidad instalada en el vehículo y relativa a la identif icación del sensor de 
movimiento emp arejado con dicha unidad (anex o 1B, requisito 079). 
sensorSer ialNumber es el número de serie del sensor de movimiento que está empa rejado actualmente con la 
VU. 
sensorAppro valNumber es el número de homolog ación del sensor de movimiento que está emparej ado 
actualmente con la VU. 
sensorPair ingDateF irst es la fecha en que el sensor de movimiento emparej ado actualmente a la VU se 
emparej ó por primera vez con la VU. 26.5.2016 L 139/134 Diar io Oficial de la Unión Europea ES    
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 emp arejado con dicha unidad (anex o 1C, requisito 97). 
sensorSer ialNumber es el número de serie de un sensor de movimient o emparej ado con la VU. 
sensorAppro valNumber es el número de homologació n de este sensor de movimient o. 
sensorPair ingDate es la fecha del emparej amiento de este sensor de movimient o con la VU. 
2.146.  SensorPair ingDate 
Fecha de un emparej amiento del sensor de movimient o con una VU. 
Asignación de valor: no especifi cado. 
2.147.  SensorSCIdentif ier 
Identif icador del compo nente de segur idad del sensor de movimient o. 
Asignación de valor: específica del fabr icante del component e. 
2.148.  SensorSer ialNumber 
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 segur idad comunes). 
Generación 2: 
Asignación de valor: con arreglo a lo dispuesto en el apéndice 11 (Mecanismos de segur idad comunes). 26.5.2016 L 139/135 Diar io Oficial de la Unión Europea ES    
2.150.  SignatureRecordAr ray 
Generación 2: 
Conjunto de firmas más metadatos tal como se utilizan en el protocolo de transferencia. 
recordT ype denota el tipo de registro (Signature). Asignación de valor : véase RecordT ype. 
recordSize es el tamaño de Signature en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. El valor se pondrá a 1, ya que las firmas 
pueden tener diferentes longitudes. 
records es el conjunt o de firmas. 
2.151.  SimilarEv entsNumber 
El número de incident es similares de un día deter minado (anex o 1B, requisito 094, y anex o 1C, requisito 117). 
Asignación de valor : el 0 no se utiliza, el 1 signif ica que ese día solo ha ocur rido y se ha almacenado un 
incident e de ese tipo, el 2 signif ica que ese día han ocur rido 2 incident es de ese tipo (y solo se ha almacenado 
uno), … 255 signif ica que ese día han ocur rido 255 o más incidentes de ese tipo. 
2.152.  Specif icConditionRecord 
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ífi ca (anex o 1C, requisitos 130, 276, 301, 328 y 355). 
entr yTime es la fecha y la hora de la entrada. 
specif icCondition Type es el código que identif ica la condición específica. 
2.153.  Specif icConditions 
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ífi ca (anex o 1C, requisitos 131, 277, 302, 329 y 356). 
Generación 2: 
26.5.2016 L 139/136 Diar io Oficial de la Unión Europea ES    
controlPoin terNew estRecord es el índice del último registro actualizado de una condición específi ca. 
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’. 
specif icConditionRecords es el conjunto de registros con información sobre las condiciones específicas 
utilizadas. 
2.154.  Specif icCondition Type 
Código que identif ica una condición específica (anex o 1B, requisitos 050b, 105a, 212a y 230a y anex o 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 
2.155.  Speed 
Velocidad del vehículo (km/h). 
Asignación de valor: kilómetros por hora en el inter valo operativo de 0 a 220 km/h. 
2.156.  SpeedAuthor ised 
Velocidad máxima autorizada para el vehículo [def inición hh)]. 
26.5.2016 L 139/137 Diar io Oficial de la Unión Europea ES    
2.157.  SpeedA verage 
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. 
2.159.  Tachog raphPayload 
Generación 2: 
Para la definición de este tipo de datos, véase el apéndice 14. 
2.160.  Tachog raphPayloadEncr ypted 
Generación 2: 
Carga útil del tacógraf o cifrado DER -TLV, es decir , los datos enviados cifrados en el mensaje RTM. Para el cifrado, 
véase el apéndice 11, parte B, capítulo 13. 
tag forma parte de la codificación DER -TLV y debe ponerse a ‘87’ (véase el apéndice 11, parte B, capítulo 13). 
length es parte de la codif icación DER -TLV y codificará la longitud del siguient e paddingCont entIndicatorByt e y 
el encr yptedData. 
paddingContentIndicatorB yte deberá ser ‘00’. 
encr yptedDat a es la tachog raphPa yload cifrada, según lo especifi cado en el apéndice 11, parte B, capítulo 13. 
La longitud de estos datos en octetos siempr e deberá ser múltiplo de 16. 
2.161.  TDesSessionKey 
Generación 1: 
Una clave de sesión triple DES. 
Asignación de valor: no hay más especificaciones. 26.5.2016 L 139/138 Diar io Oficial de la Unión Europea ES    
2.162.  TimeReal 
Código para un campo combinado de fecha y hora, donde ambos parámetros se expresan como los segundos 
transcur ridos desde las 00h00m00s del 1 de enero de 1970, tiempo medio de Green wich. 
Asignación de valor — Alineación de octet o: número de segundos transcur ridos a partir de la medianoc he 
del día 1 de enero de 1970, tiempo medio de Green wich. 
La fecha/hora máxima posible es en el año 2106. 
2.163.  TyreSize 
Designación de las dimensiones de los neumáticos. 
Asignación de valor : de conf ormidad con la Directiva 92/23/CEE de 31 de marzo de 1992 (DO L 129 de 
14.5.1992, p. 95). 
2.164.  VehicleIdentif icationNumber 
Número de identificación del vehículo (VIN) refer ido al vehículo complet o, 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.  VehicleIdentif icationNumberRecordAr ray 
Generación 2: 
El VehicleIdentif icationNumber más metadatos tal como se utilizan en el protocolo de transferencia. 
recordT ype denota el tipo de registro (VehicleIdentif icationNumber). Asignación de valor: véase RecordT ype. 
recordSize es el tamaño de VehicleIdentif icationNumber en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es el conjunt o de números de identif icación de vehículos. 
2.166.  VehicleRegist rationIdentif ication 
Identif icación de un vehículo, excl usiva para Europa (VRN y Estado miembro). 26.5.2016 L 139/139 Diar io Oficial de la Unión Europea ES    
vehicleRegist rationNation es la nación donde se matr iculó el vehículo. 
vehicleRegist rationNumber es el número de matrícula del vehículo (VRN). 
2.167.  VehicleRegist rationNumber 
Número de matrícula del vehículo (VRN). El número de matrícula lo asigna la autori dad de matr iculación de 
vehículos. 
codePage especifica un conjunto de caract eres definidos en el capítulo 4, 
vehicleRegNumber representa un VRN codif icado utilizando el conjunt o de caract eres especificado. 
Asignación de valor: específica para cada país. 
2.168.  VehicleRegist rationNumberRecordAr ray 
Generación 2: 
El VehicleRegistrationNumber más metadatos tal como se utilizan en el protocolo de transferencia. 
recordT ype denota el tipo de registro (VehicleRegistrationNumber). Asignación de valor : véase RecordT ype. 
recordSize es el tamaño de VehicleRegistrationNumber en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es el conjunt o 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ógraf o de 
generación 1 (anex o 1C, requisito 121). 
Asignación de valor — Alineación de octeto: ‘xxxxxxxa’B (8 bits) 26.5.2016 L 139/140 Diar io Oficial de la Unión Europea ES    
Para la compatibilidad con la generación 1: 
‘a’B  Admisión de las tarjetas de tacógraf o 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: 
Información almacenada en una VU y relativa a los cambios de actividad y/o los cambios del régimen de 
conducción y/o los cambios del estado de la tarjeta que teng an lugar en un día civil deter minado (anex o 1B, 
requisito 084) y a los estados de las ranuras a las 00.00 horas de ese día. 
noOfAc tivityChanges es el número de palabras de ActivityChangeInf o que hay en el conjunto activityChan ­
geIn fos. 
activityChangeInfos es un conjunt o de palabras de ActivityChange Info que se almacenan en la VU a lo largo 
del día Siempr e incluye dos palabras de activityChangeInf o que dan el estado de las dos ranuras a las 00.00 
horas de ese día. 
2.171.  VuActivityDailyRecordAr ray 
Generación 2: 
Información almacenada en una VU y relativa a los cambios de actividad 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 (anex o 1C, 
requisitos 105, 106 y 107) y a los estados de las ranuras a las 00.00 horas de ese día. 
recordT ype denota el tipo de registro (ActivityChang eInfo). Asignación de valor : véase RecordT ype. 
recordSize es el tamaño de ActivityChangeInf o en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es un conjunto de palabras de ActivityChang eInfo que se almacenan en la VU a lo largo del día. 
Siempre incluye dos palabras de activityChang eInfo que dan el estado de las dos ranuras a las 00.00 horas de ese 
día. 
2.172.  VuAppro valNumber 
Número de homologación de la unidad instalada en el vehículo. 26.5.2016 L 139/141 Diar io Oficial de la Unión Europea ES    
Generación 1: 
Asignación de valor: no especifi cado. 
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 ejem plo, incluyendo guiones si los lleva. El número de homologació n deberá 
estar alineado a la izquierda. 
2.173.  VuCalibrationDat a 
Generación 1: 
Información almacenada en una unidad instalada en el vehículo y relativa a los calibrados del aparat o de control 
(anex o 1B, requisito 098). 
noOfV uCalibrationRecords 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 relativa al calibrado del aparat o de control 
(anex o 1B, requisito 098 y anex o 1C, requisitos 119 y 120). 
Generación 1: 
calibrationPur pose es el propósito del calibrado. 
workshopName, workshopA ddress son el nombre y la dirección del taller . 26.5.2016 L 139/142 Diar io Oficial de la Unión Europea ES    
workshopCardNumber identifica la tarjeta de taller empleada durante el calibrado. 
workshopCardExpir yDate es la fecha de expiración de la tarjeta. 
vehicleIdentif icationNumber es el VIN. 
vehicleRegist rationIdentif ication contiene el VRN y el nombre del Estado miembro donde se matr iculó el 
vehículo. 
wVehicleCharacter isticCons tant es el coefi ciente caracte rístico del vehículo. 
kCons tantOfRecordingEquipment es la constante del aparat o 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. 
author isedSpeed es la velocidad autori zada del vehículo. 
oldOdometerV alue, newOdometerV alue son la lectura anterior y la nueva lectura del cuentakilómetros. 
oldTimeV alue, newTimeV alue son el valor anterior y el nuev o valor de la fecha y la hora. 
nextCalibrationDate es la fecha del próximo calibrado del tipo especifi cado en CalibrationPur pose, a cargo de 
la autori dad de control autori zada. 
Generación 2: 
Además de los de la generación 1, se utiliza el siguient e element o de datos: 
sealDataV u da información sobre los precint os colocados en diversos compo nentes del vehículo. 
2.175.  VuCalibrationRecordAr ray 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a los calibrados del aparat o de control 
(anex o 1C, requisitos 119 y 120). 26.5.2016 L 139/143 Diar io Oficial de la Unión Europea ES    
recordT ype denota el tipo de registro (VuCalibrationRecord). Asignación de valor : véase RecordT ype. 
recordSize es el tamaño de VuCalibrationRecord en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es el conjunt o de registros de calibrado. 
2.176.  VuCardIWDat a 
Generación 1: 
Información almacenada en una unidad instalada en el vehículo y relativa a los ciclos de inserción y extracción 
de tarjetas de conduct or o de taller en dicha unidad (anex o 1B, requisito 081, y anex o 1C, requisito 103). 
noOfIWRecords es el número de registros que hay en el conjunt o vuCardIWRecords. 
vuCardIWRecords es el conjunto de registros relativ os 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 relativa al ciclo de inserción y extracción de 
una tarjeta de conduct or o de taller en dicha unidad (anex o 1B, requisito 081, y anex o 1C, requisit o 102). 
Generación 1: 
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. 
cardExpir yDate es la fecha de expiración de la tarjeta, según los datos almacenados en la propia tarjeta. 26.5.2016 L 139/144 Diar io Oficial de la Unión Europea ES    
cardInser tion Time es la fecha y la hora de inserción. 
vehicleOdometerV alueAtInser tion es la lectura del cuentakilómetros del vehículo en el momento de inser tar 
la tarjeta. 
cardSlotNumber es la ranura donde se inser ta la tarjeta. 
cardWithdrawa lTime es la fecha y la hora de extracción. 
vehicleOdometerV alueAtWithdra wal es la lectura del cuentakilómetros del vehículo en el momento de extraer 
la tarjeta. 
previousV ehicleInfo contiene información sobre el vehículo anterior que utilizara el conduct or, 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 conduct or en el momento de inser tar la tarjeta. 
Generación 2: 
En lugar de fullCardNumber , la estructura de datos de la generación 2 utiliza el siguiente element o 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.  VuCardIWRecordAr ray 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a los ciclos de inserción y extracción 
de tarjetas de conduct or o de taller en dicha unidad (anex o 1C, requisito 103). 
recordT ype denota el tipo de registro (VuCardIWRecord). Asignación de valor: véase RecordT ype. 
recordSize es el tamaño de VuCardIWRecord en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es el conjunt o de registros relativ os a los ciclos de inserción y extracción de tarjetas. 
2.179.  VuCardRecord 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a una tarjeta de tacógraf o utilizada 
(anex o 1C, requisito 132). 26.5.2016 L 139/145 Diar io Oficial de la Unión Europea ES    
cardExtendedSer ialNumber según se lee del archivo EF_ICC del MF de la tarjeta. 
cardPers onaliserID según se lee del arch ivo EF_ICC del MF de la tarjeta. 
typeOfT achog raphCardId según se lee del archiv o EF_Application_Identifi cation del DF_T achograph_G2 
cardStr uctureV ersion según se lee del arch ivo EF_Application_Identif ication del DF_T achograph_G2 
cardNumber según se lee del archiv o EF_Identification del DF_T achog raph_G2 
2.180.  VuCardRecordAr ray 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a las tarjetas de tacógraf o utilizadas 
con dicha unidad. Esta información se destina al análisis de los problemas VU — tarjeta (anex o 1C, requisito 
132). 
recordT ype denota el tipo de registro (VuCardRecord). Asignación de valor: véase RecordT ype. 
recordSize es el tamaño de VuCardRecord en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es un conjunt o de registros relativos a las tarjetas de tacógraf o utilizadas con la VU. 
2.181.  VuCer tificate 
Certificad o de la clave pública de una VU. 
2.182.  VuCer tificateRecordAr ray 
Generación 2: 
El certificado de la VU más metadatos tal como se utilizan en el protocolo de transferencia. 
26.5.2016 L 139/146 Diar io Oficial de la Unión Europea ES    
recordT ype denota el tipo de registro (VuCer tificate). Asignación de valor: véase RecordT ype. 
recordSize es el tamaño de VuCer tificate en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. El valor se pondrá a 1, ya que los certificados 
pueden tener diferentes longitudes. 
records es un conjunt o de certificados de VU. 
2.183.  VuCompan yLocksDat a 
Generación 1: 
Información almacenada en una unidad instalada en el vehículo y relativa a bloqueos introducidos por empr esas 
(anex o 1B, requisito 104). 
noOfLocks es el número de bloqueos incluidos en vuCompan yLocksRecords. 
vuCompany Lock sRecords es el conjunt o de registros de bloqueos introducidos por empresas. 
2.184.  VuCompan yLocksR ecord 
Información almacenada en una unidad instalada en el vehículo y relativa a bloqueos introducidos por una 
empr esa (anex o 1B, requisito 104, y anex o 1C, requisito 128). 
Generación 1: 
lockIn Time, lockOutTime son la fecha y la hora de activación y desactivación del bloqueo. 
companyName, companyA ddress son el nombre y la dirección de la empresa relacionada con la activación del 
bloqueo. 
companyCardNumber identifica la tarjeta emp leada para la activación del bloqueo. 
Generación 2: 
En luga r de compan yCardNumber , la estructura de datos de la generación 2 utiliza el siguiente element o de 
datos: 
companyCardNumberAndGeneration identifica la tarjeta, incluida su generación, emp leada para la activación 
del bloqueo. 26.5.2016 L 139/147 Diar io Oficial de la Unión Europea ES    
2.185.  VuCompan yLocksR ecordAr ray 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a bloqueos introducidos por empr esas 
(anex o 1C, requisito 128). 
recordT ype denota el tipo de registro (VuCom panyL ocksRecord). Asignación de valor: véase RecordT ype. 
recordSize es el tamaño de VuCom panyL ocksRecord en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. Valor 0..255. 
records es el conjunt o de registros de bloqueos introducidos por empresas. 
2.186.  VuControlA ctivityData 
Generación 1: 
Información almacenada en una unidad instalada en el vehículo y relativa a los controles efectuados con dicha 
unidad (anex o 1B, requisito 102). 
noOfControls es el número de controles incluidos en vuControlA ctivityRecords. 
vuControlAct ivityRecords es el conjunt o de registros sobre actividades de control. 
2.187.  VuControlA ctivityRecord 
Información almacenada en una unidad instalada en el vehículo y relativa a un control efectuado con dicha 
unidad (anex o 1B, requisito 102, y anex o 1C, requisito 126). 
Generación 1: 
controlT ype es el tipo de control. 
controlTime es la fecha y la hora del control. 
ControlCardNumber identif ica la tarjeta de control empleada para el control. 26.5.2016 L 139/148 Diar io Oficial de la Unión Europea ES    
downloadPerio dBegin Time es la hora de comienzo del período cuyos datos se transfieren, en caso de transfe ­
rencia. 
downloadPerio dEndTime es la hora de conclusión del período cuyos datos se transf ieren, en caso de transfe ­
rencia. 
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, incluida su generación, empleada para el 
control. 
2.188.  VuControlA ctivityRecordAr ray 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a los controles efectuados con dicha 
unidad (anex o 1C, requisito 126). 
recordT ype denota el tipo de registro (VuControlA ctivityRecord). Asignación de valor : véase RecordT ype. 
recordSize es el tamaño de VuControlA ctivityRecord en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es el conjunt o de registros sobre actividades de control de la VU. 
2.189.  VuDat aBlockCounter 
Contador , almacenado en una tarjeta, que identif ica 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.  VuDetai ledSpeedBlock 
Información pormenor izada almacenada en una unidad instalada en el vehículo y relativa a la velocidad del 
vehículo durant e un minuto en el que haya estado en movimient o (anex o 1B, requisit o 093, y anex o 1C, 
requisito 116). 
26.5.2016 L 139/149 Diar io Oficial de la Unión Europea ES    
speedBlockBeginDate es la fecha y la hora del primer valor de velocidad comprendido en ese bloque. 
speedsPerSecon d es la secuencia cronológica de las velocidades medidas cada segundo de ese minuto, 
empez ando desde speedBloc kBeginDate (inclusive). 
2.191.  VuDetai ledSpeedBlockRecordAr ray 
Generación 2: 
Información pormenor izada almacenada en una unidad instalada en el vehículo y relativa a la velocidad del 
vehículo. 
recordT ype denota el tipo de registro (VuDetailedSpeedBlock) . Asignación de valor : véase RecordT ype. 
recordSize es el tamaño de VuDetailedSpeedBlock en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es el conjunt o de bloques con datos pormenor izados sobre la velocidad. 
2.192.  VuDetai ledSpeedData 
Generación 1: 
Información pormenor izada almacenada en una unidad instalada en el vehículo y relativa a la velocidad del 
vehículo. 
noOfSpeedBlock s es el número de bloques con datos de velocidad que hay en el conjunto vuDetailedSpeed ­
Blocks. 
vuDetail edSpeedBlocks es el conjunto de bloques con datos pormenor izados sobre la velocidad. 
2.193.  VuDo wnloadableP eriod 
La fecha más antigua y la más reciente para las que una unidad instalada en el vehículo conser va datos relativ os 
a las actividades de los conduct ores (anex o 1B, requisitos 081, 084 o 087, y anex o 1C, requisitos 102, 105 y 
108). 
minDo wnloadableTime es la fecha y la hora más antiguas en que se inser tó una tarjeta, ocur rió un cambio de 
actividad o se introdujo un lugar; según los datos almacenados en la VU. 
maxDo wnloadableTime es la fecha y la hora más recientes en que se inser tó una tarjeta, ocur rió un cambio de 
actividad o se introdujo un lugar; según los datos almacenados en la VU. 26.5.2016 L 139/150 Diar io Oficial de la Unión Europea ES    
2.194.  VuDo wnloadableP eriodRecordAr ray 
Generación 2: 
El VUDo wnloadableP eriod más metadatos tal como se utilizan en el protocolo de transferencia. 
recordT ype denota el tipo de registro (VuDo wnloadableP eriod). Asignación de valor : véase RecordT ype. 
recordSize es el tamaño de VuDo wnloadableP eriod en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es el conjunt o de registros de VuDo wnloadableP eriod. 
2.195.  VuDo wnloadA ctivityData 
Información almacenada en una unidad instalada en el vehículo y relativa a su última transferencia (anex o 1B, 
requisito 105, y anex o 1C, requisit o 129). 
Generación 1: 
downloadingTime es la fecha y la hora de la transfer encia. 
fullCardNumber identif ica la tarjeta empleada para autori zar la transfer encia. 
companyOrW orkshopName es el nombre de la empresa o del centro de ensa yo. 
Generación 2: 
En lugar de fullCardNumber , la estructura de datos de la generación 2 utiliza el siguiente element o de datos: 
fullCardNumberAndGeneration identifica la tarjeta, incluida su generación, empleada para autori zar la transfe ­
rencia. 
2.196.  VuDo wnloadA ctivityData RecordAr ray 
Generación 2: 
Información relativa a la última transfer encia de la VU (anex o 1C, requisit o 129). 
26.5.2016 L 139/151 Diar io Oficial de la Unión Europea ES    
recordT ype denota el tipo de registro (VuDo wnloadA ctivityData). Asignación de valor: véase RecordT ype. 
recordSize es el tamaño de VuDo wnloadA ctivityData en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es el conjunt o de registros de datos sobre actividades de transfer encia. 
2.197.  VuEv entData 
Generación 1: 
Información almacenada en una unidad instalada en el vehículo y relativa a incident es (anex o 1B, requisito 094, 
salvo el incidente de exceso de velocidad). 
noOfV uEv ents es el número de incident es incluidos en el conjunto vuEventRecords. 
vuEv entRecords es un conjunt o de registros sobre incidentes. 
2.198.  VuEv entRecord 
Información almacenada en una unidad instalada en el vehículo y relativa a un incidente (anex o 1B, requisito 
094 y anex o 1C, requisito 117, salvo el incidente de exceso de velocidad). 
Generación 1: 
eventT ype es el tipo de incidente. 
eventRecordPur pose es el propósito con que se ha registrado ese incidente. 
eventBegin Time es la fecha y la hora de comienzo del incidente. 
eventEndTime es la fecha y la hora en que term ina el incident e. 
cardNumberDr iverSlotBegin identif ica la tarjeta que estaba inser tada en la ranura del conduct or en el 
momento en que comenzó el incidente. 
cardNumberCodr iverSlotBegin identif ica la tarjeta que estaba inser tada en la ranura del segundo conductor en 
el momento en que comenzó el incidente. 
cardNumberDr iverSlotEnd identif ica la tarjeta que estaba inser tada en la ranura del conduct or en el momento 
en que finalizó el incident e. 
cardNumberCodr iverSlotEnd identif ica la tarjeta que estaba inser tada en la ranura del segundo conductor en 
el momento en que finalizó el incident e. 26.5.2016 L 139/152 Diar io Oficial de la Unión Europea ES    
similarEv entsNumber es el número de incidentes similares ocur ridos ese día. 
Esta secuencia puede utilizarse para todos los incident es, excep to los de exceso de velocidad. 
Generación 2: 
Además de los de la generación 1, se utilizan los siguientes elementos de datos: 
manufacturerSpecif icEv entFaultData contiene información adicional sobre el incident e, específica del 
fabricant e. 
En lugar de cardNumberDr iverSlotBegin, cardNumberCodr iverSlotBegin, cardNumberDr iverSlotEnd y cardNum ­
berCodr iverSlotEnd, la estructura de datos de la generación 2 utiliza los siguient es elementos de datos: 
cardNumberAndGenDr iverSlotBegin identif ica la tarjeta, incluida su generación, que estaba inser tada en la 
ranura del conduct or en el momento en que comenzó el incident e. 
cardNumberAndGenCodr iverSlotBegin identifica la tarjeta, incluida su generación, que estaba inser tada en la 
ranura del segundo conduct or en el momento en que comenzó el incident e. 
cardNumberAndGenDr iverSlotEnd identifica la tarjeta, incluida su generación, que estaba inser tada en la 
ranura del conduct or en el momento en que term inó el incidente. 
cardNumberAndGenCodr iverSlotEnd identif ica la tarjeta, incluida su generación, que estaba inser tada en la 
ranura del segundo conduct or en el momento en que term inó el incidente. 
Si el incident e es un conf licto temporal, eventBegin Time y eventEndTime deben interpretarse como sigue: 
eventBegin Time es la fecha y la hora del aparat o de control. 
eventEndTime es la fecha y la hora GNSS. 
2.199.  VuEv entRecordAr ray 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a incident es (anex o 1C, requisito 117, 
salvo el incidente de exceso de velocidad). 
26.5.2016 L 139/153 Diar io Oficial de la Unión Europea ES    
recordT ype denota el tipo de registro (VuEventRecord). Asignación de valor: véase RecordT ype. 
recordSize es el tamaño de VuEventRecord en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es un conjunt o de registros sobre incidentes. 
2.200.  VuFaultData 
Generación 1: 
Información almacenada en una unidad instalada en el vehículo y relativa a fallos (anex o 1B, requisito 096). 
noOfV uFaults es el número de fallos incluidos en el conjunto vuFaultRe cords. 
vuFaultRecords es un conjunt o de registros sobre fallos. 
2.201.  VuFaultRecord 
Información almacenada en una unidad instalada en el vehículo y relativa a un fallo (anex o 1B, requisito 096, y 
anex o 1C, requisit o 118). 
Generación 1: 
faultT ype es el tipo de fallo del aparat o de control. 
faultRecordPur pose es el propósito con que se ha registrado ese fallo. 
faultBegin Time es la fecha y la hora de comienzo del fallo. 
faultEndTime es la fecha y la hora en que termina el fallo. 
cardNumberDr iverSlotBegin identif ica la tarjeta que estaba inser tada en la ranura del conduct or en el 
momento en que comenzó el fallo. 
cardNumberCodr iverSlotBegin identif ica la tarjeta que estaba inser tada en la ranura del segundo conductor en 
el momento en que comenzó el fallo. 
cardNumberDr iverSlotEnd identif ica la tarjeta que estaba inser tada en la ranura del conduct or en el momento 
en que term inó el fallo. 
cardNumberCodr iverSlotEnd identif ica la tarjeta que estaba inser tada en la ranura del segundo conductor en 
el momento en que terminó el fallo. 26.5.2016 L 139/154 Diar io Oficial de la Unión Europea ES    
Generación 2: 
Además de los de la generación 1, se utiliza el siguient e element o de datos: 
manufacturerSpecif icEv entFaultData contiene información adicional sobre el fallo, específi ca del fabricante. 
En lugar de cardNumberDr iverSlotBegin, cardNumberCodr iverSlotBegin, cardNumberDr iverSlotEnd y cardNum ­
berCodr iverSlotEnd, la estructura de datos de la generación 2 utiliza los siguient es elementos de datos: 
cardNumberAndGenDr iverSlotBegin identif ica la tarjeta, incluida su generación, que estaba inser tada en la 
ranura del conduct or en el momento en que comenzó el fallo. 
cardNumberAndGenCodr iverSlotBegin identifica la tarjeta, incluida su generación, que estaba inser tada en la 
ranura del segundo conduct or en el momento en que comenzó el fallo. 
cardNumberAndGenDr iverSlotEnd identifica la tarjeta, incluida su generación, que estaba inser tada en la 
ranura del conduct or en el momento en que term inó el fallo. 
cardNumberAndGenCodr iverSlotEnd identif ica la tarjeta, incluida su generación, que estaba inser tada en la 
ranura del segundo conduct or en el momento en que term inó el fallo. 
2.202.  VuFaultRecordAr ray 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a fallos (anex o 1B, requisito 118). 
recordT ype denota el tipo de registro (VuFaul tRecord). Asignación de valor : véase RecordT ype. 
recordSize es el tamaño de VuFaul tRecord en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es un conjunt o de registros sobre fallos. 
2.203.  VuGNSSCDRecord 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a la posición GNSS del vehículo si el 
tiempo de conducción continua del conduct or alcanza un múltiplo de tres horas (anex o 1C, requisitos 108 y 
110). 26.5.2016 L 139/155 Diar io Oficial de la Unión Europea ES    
timeSt amp es la fecha y hora en las que el tiempo de conducción continua del titular de la tarjeta llega a un 
múltiplo de tres horas. 
cardNumberAndGenDr iverSlot identif ica la tarjeta, incluida su generación, que está inser tada en la ranura del 
conductor . 
cardNumberAndGenCodr iverSlot identif ica la tarjeta, incluida su generación, que está inser tada en la ranura 
del segundo conductor . 
gnssPlaceRecord contiene información relacionada con la posición del vehículo. 
2.204.  VuGNSSCDRecordAr ray 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a la posición GNSS del vehículo si el 
tiempo de conducción continua del conduct or alcanza un múltiplo de tres horas (anex o 1C, requisitos 108 y 
110). 
recordT ype denota el tipo de registro (VuGNSSCDRecord). Asignación de valor : véase RecordT ype. 
recordSize es el tamaño de VuGNSSCDRecord en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es un conjunt o de registros GNSS sobre conducción continua. 
2.205.  VuIdentif ication 
Información almacenada en una unidad instalada en el vehículo y relativa a la identificación de dicha unidad 
(anex o 1B, requisito 075 y anex o 1C, requisitos 93 y 121). 
Generación 1: 
vuManufacturerName es el nombre del fabricante de la VU. 
vuManufacturerAdd ress es la dirección del fabricante de la VU. 26.5.2016 L 139/156 Diar io Oficial de la Unión Europea ES    
vuPar tNumber es el número de pieza de la VU. 
vuSer ialNumber es el número de serie de la VU. 
vuSof twareIdentif ication identif ica el software instalado en la VU. 
vuManufactur ingDate es la fecha de fabricación de la VU. 
vuAppro valNumber es el número de homologació n de la VU. 
Generación 2: 
Además de los de la generación 1, se utiliza el siguient e element o de datos: 
vuGeneration indica la generación de la VU. 
vuAbility apor ta información sobre si la VU sopor ta o no las tarjetas de tacógraf o de la generación 1. 
2.206.  VuIdentif icationRecordAr ray 
Generación 2: 
El VuIdentif ication más metadatos tal como se utilizan en el protocolo de transferencia. 
recordT ype denota el tipo de registro (VuIdentification). Asignación de valor : véase RecordT ype. 
recordSize es el tamaño de VuIdentification en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es un conjunt o de registros VuIdentif ication. 
2.207.  VuITSConsentRecord 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a la autori zación de un conduct or en 
relación con la utilización de sistemas de transpor te inteli gent es. 
26.5.2016 L 139/157 Diar io Oficial de la Unión Europea ES    
cardNumberAndGen identif ica la tarjeta, incluida su generación. Debe ser una tarjeta de conductor o de taller . 
consent es una bandera que indica si el conduct or ha dado su consentimient o en relación con el uso de siste mas 
de transpor te intelig entes con este vehículo/unidad instalada en el vehículo. 
Asignación de valor : 
TRUE  indica el consentimient o del conduct or en relación con el uso de sistem as de transpor te intelig entes 
FALSE  indica la negativ a del conductor en relación con el uso de sistem as de transpor te intelig entes 
2.208.  VuITSConsentRecordAr ray 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa al consentimiento del conduct or en 
relación con el uso de sistemas de transpor te inteli gent es (anex o 1C, requisito 200). 
recordT ype denota el tipo de registro (VuITSConsentRecord). Asignación de valor: véase RecordT ype. 
recordSize es el tamaño de VuITSConsentRecord en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es el conjunt o de registros de consentimient o en relación con el ITS. 
2.209.  VuManufacturerA ddress 
Dirección del fabricante de la unidad instalada en el vehículo. 
Asignación de valor: no especifi cado. 
2.210.  VuManufacturerName 
Nombre del fabr icante de la unidad instalada en el vehículo. 
Asignación de valor: no especifi cado. 
2.211.  VuManufactur ingDate 
Fecha de fabricación de la unidad instalada en el vehículo. 
Asignación de valor: no especifi cado. 26.5.2016 L 139/158 Diar io Oficial de la Unión Europea ES    
2.212.  VuOv erSpeedingControlDat a 
Información almacenada en una unidad instalada en el vehículo y relativa a incident es de exces o de velocidad 
ocur ridos desde el último control del exceso de velocidad (anex o 1B, requisito 095, y anex o 1C, requisito 117). 
lastOverspeedControlTime es la fecha y la hora del último control del exces o de velocidad. 
firstOv erspeedSince es la fecha y la hora del primer exceso de velocidad ocur rido tras este control. 
numberOfOv erspeedSince es el número de incident es de exceso de velocidad ocur ridos después del último 
control del exce so de velocidad. 
2.213.  VuOv erSpeedingControlDat aRecordAr ray 
Generación 2: 
El VuOverSpeedingControlData más metadat os tal como se utilizan en el prot ocolo de transfer encia. 
recordT ype denota el tipo de registro (VuOverSpeedingControlData). Asignación de valor: véase RecordT ype. 
recordSize es el tamaño de VuOverSpeedingControlData en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es un conjunt o de registros de datos de controles de exces o de velocidad. 
2.214.  VuOv erSpeedingEv entData 
Generación 1: 
Información almacenada en una unidad instalada en el vehículo y relativa a incident es de exces o de velocidad 
(anex o 1B, requisito 094). 
noOfV uOv erSpeedingEv ents es el número de incident es incluidos en el conjunt o vuOverSpeedingEven ­
tRecords. 
vuOv erSpeedingEv entRecords es un conjunt o de registros sobre incident es de exceso de velocidad. 
2.215.  VuOv erSpeedingEv entRecord 
Generación 1: 
Información almacenada en una unidad instalada en el vehículo y relativa a incident es de exces o de velocidad 
(anex o 1B, requisito 094, y anex o 1C, requisito 117). 26.5.2016 L 139/159 Diar io Oficial de la Unión Europea ES    
eventT ype es el tipo de incidente. 
eventRecordPur pose es el propósito con que se ha registrado ese incidente. 
eventBegin Time es la fecha y la hora de comienzo del incidente. 
eventEndTime es la fecha y la hora en que term ina el incident e. 
maxSpeedV alue es la velocidad máxima medida durante el incident e. 
averageSpeedV alue es la media aritmética de las velocidades medidas durante el incidente. 
cardNumberDr iverSlotBegin identif ica la tarjeta que estaba inser tada en la ranura del conduct or en el 
momento en que comenzó el incidente. 
similarEv entsNumber es el número de incidentes similares ocur ridos ese día. 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a incident es de exces o de velocidad 
(anex o 1B, requisito 094, y anex o 1C, requisito 117). 
En lugar de cardNumberDr iverSlotBegin, la estructura de datos de la generación 2 utiliza el siguient e elemento 
de datos: 
cardNumberAndGenDr iverSlotBegin identif ica la tarjeta, incluida su generación, que estaba inser tada en la 
ranura del conduct or en el momento en que comenzó el incident e. 
2.216.  VuOv erSpeedingEv entRecordAr ray 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a incident es de exces o de velocidad 
(anex o 1C, requisito 117). 
26.5.2016 L 139/160 Diar io Oficial de la Unión Europea ES    
recordT ype denota el tipo de registro (VuOverSpeedingEventRecord). Asignación de valor: véase RecordT ype. 
recordSize es el tamaño de VuOverSpeedingEventRecord en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es un conjunt o de registros sobre incidentes de exceso de velocidad. 
2.217.  VuPar tNumber 
Número de pieza de la unidad instalada en el vehículo. 
Asignación de valor: específica del fabr icante de la VU. 
2.218.  VuPlaceDailyW orkPeriodD ata 
Generación 1: 
Información almacenada en una unidad instalada en el vehículo y relativa a los luga res donde los conductores 
comienzan o terminan un período de trabajo diar io (anex o 1B, requisit o 087, y anex o 1C, requisitos 108 y 110). 
noOfPlaceRecords es el número de registros incluidos en el conjunto vuPlaceDailyW orkP eriodRecords. 
vuPlaceDailyW orkPeriodRecords es un conjunto de registros relativos a lugar es. 
2.219.  VuPlaceDailyW orkPeriodR ecord 
Generación 1: 
Información almacenada en una unidad instalada en el vehículo y relativa a un lugar donde un conduct or 
comienza o term ina un período de traba jo diar io (anex o 1B, requisito 087, y anex o 1C, requisitos 108 y 110). 
fullCardNumber es el tipo de tarjeta de conduct or, el Estado miembro que la ha expedido y el número de 
tarjeta. 
placeRecord contiene la información relativa al lugar introducido. 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a un lugar donde un conduct or 
comienza o term ina un período de traba jo diar io (anex o 1B, requisito 087, y anex o 1C, requisitos 108 y 110). 
26.5.2016 L 139/161 Diar io Oficial de la Unión Europea ES    
En lugar de fullCardNumber , la estructura de datos de la generación 2 utiliza el siguiente element o 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.220.  VuPlaceDailyW orkPeriodR ecordAr ray 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a los luga res donde los conductores 
comienzan o terminan un período de trabajo diar io (anex o 1C, requisitos 108 y 110). 
recordT ype denota el tipo de registro (VuPlaceDailyW orkPer iodRecord). Asignación de valor: véase 
RecordT ype. 
recordSize es el tamaño de VuPlaceDailyW orkP eriodRecord en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es el conjunt o de registros relativ os a lugares. 
2.221.  VuPrivateKe y 
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. 
2.223.  VuSer ialNumber 
Número de serie de la unidad instalada en el vehículo (anex o 1B, requisito 075, y anex o 1C, requisit o 93). 
2.224.  VuSof tInst allationDate 
Fecha de instalación de la versión de software que lleva la unidad instalada en el vehículo. 
Asignación de valor: no especifi cado. 26.5.2016 L 139/162 Diar io Oficial de la Unión Europea ES    
2.225.  VuSof twareIdentif ication 
Información almacenada en una unidad instalada en el vehículo y relativa al software instalado. 
vuSof twareV ersion es el número de la versión de software que lleva la VU. 
vuSof tIns tallationDate es la fecha de instalación de la versión de software. 
2.226.  VuSof twareV ersion 
Número de la versión de software que lleva la VU. 
Asignación de valor: no especifi cado. 
2.227.  VuSpecif icConditionData 
Generación 1: 
Información almacenada en una unidad instalada en el vehículo y relativa a condiciones específicas. 
noOfSpecif icConditionRecords es el número de registros incluidos en el conjunt o specifi cConditionRecords. 
specif icConditionRecords es el conjunt o de registros relativ os a condiciones específicas. 
2.228.  VuSpecif icConditionRecordAr ray 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a condiciones específicas (anex o 1C, 
requisito 130). 
recordT ype denota el tipo de registro (Specif icConditionRecord). Asignación de valor: véase RecordT ype. 
recordSize es el tamaño de SpecificConditionRecord en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es un conjunt o de registros relativos a condiciones específi cas. 26.5.2016 L 139/163 Diar io Oficial de la Unión Europea ES    
2.229.  VuTimeA djus tmentData 
Generación 1: 
Información almacenada en una unidad instalada en el vehículo y relativa a los ajus tes de la hora que se han 
efectuado fuera del marco de un calibrado regular (anex o 1B, requisito 101). 
noOfV uTimeA djRecords es el número de registros que hay en el conjunt o vuTimeA djustmentRecords. 
vuTimeAdjustmentRecords es un conjunt o de registros sobre ajust es de la hora. 
2.230.  VuTimeA djus tmentGNSSRecord 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a un ajust e de la hora basado en datos 
horar ios procedent es del GNSS (anex o 1C, requisit os 124 y 125). 
oldTimeV alue, newTimeV alue son el valor anterior y el nuev o valor de la fecha y la hora. 
2.231.  VuTimeA djus tmentGNSSRecordAr ray 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a un ajuste de la hora realizado con 
datos horar ios procedent es del GNSS (anex o 1C, requisitos 124 y 125). 
recordT ype denota el tipo de registro (VuTimeAd justmentGNSSRecord). Asignación de valor: véase 
RecordT ype. 
recordSize es el tamaño de VuTimeAd justmentGNSSRecord en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es un conjunt o de registros de ajust e de la hora basado en el GNSS. 26.5.2016 L 139/164 Diar io Oficial de la Unión Europea ES    
2.232.  VuTimeA djus tmentRecord 
Información almacenada en una unidad instalada en el vehículo y relativa a un ajuste de la hora efectuado fuera 
del marco de un calibrado regular (anex o 1B, requisito 101, y anex o 1C, requisit os 124 y 125). 
Generación 1: 
oldTimeV alue, newTimeV alue son el valor anterior y el nuev o valor de la fecha y la hora. 
workshopName, workshopA ddress son el nombre y la dirección del taller . 
workshopCardNumber identifica la tarjeta de taller empleada para realizar el ajuste de la hora. 
Generación 2: 
En lugar de workshopCardNumber , la estructura de datos de la generación 2 utiliza el siguient e elemento de 
datos: 
workshopCardNumberAndGeneration identifica la tarjeta de taller , incluida su generación, empleada para 
realizar el ajuste de la hora. 
2.233.  VuTimeA djus tmentRecordAr ray 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a ajus tes de la hora que se han 
efectuado fuera del marco de un calibrado regular (anex o 1C, requisitos 124 y 125). 
recordT ype denota el tipo de registro (VuTimeAd justmentRecord). Asignación de valor: véase RecordT ype. 
recordSize es el tamaño de VuTimeAd justmentRecord en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es un conjunt o de registros de ajust e de la hora. 26.5.2016 L 139/165 Diar io Oficial de la Unión Europea ES    
2.234.  WorkshopCardApplicationIdentif ication 
Información almacenada en una tarjeta de taller y relativa a la identif icación de la aplicación de la tarjeta (anex o 
1C, requisitos 307 y 330). 
Generación 1: 
typeOfT achog raphCardId especifica el tipo de tarjeta utilizado. 
cardStr uctureV ersion especifica la versión de la estructura que se utiliza en la tarjeta. 
noOfEv entsP erType es el número de incident es de cada tipo que puede registrar la tarjeta. 
noOfFaultsPerT ype es el número de fallos de cada tipo que puede registrar la tarjeta. 
activityStr uctureLength indica el número de bytes disponibles para almacenar registros de actividad. 
noOfCardV ehicleRecords 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: 
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 continua que puede almacenar la tarjeta. 
noOfSpecif icConditionRecords es el número de registros de condiciones específi cas que puede almacenar la 
tarjeta. 
2.235.  WorkshopCardCalibrationDat a 
Información almacenada en una tarjeta de taller y relativa a las actividades del taller realizadas con dicha tarjeta 
(anex o 1C, requisitos 314, 316, 337 y 339). 26.5.2016 L 139/166 Diar io Oficial de la Unión Europea ES    
calibration TotalNumber es el número total de calibrados realizados con la tarjeta. 
calibrationPoin terNew estRecord 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 información sobre calibrados y/o ajust es de la 
hora. 
2.236.  WorkshopCardCalibrationRecord 
Información almacenada en una tarjeta de taller y relativa a un calibrado realizado con la tarjeta (anex o 1C, 
requisitos 314 y 337). 
Generación 1: 
calibrationPur pose es el propósito del calibrado. 
vehicleIdentif icationNumber es el VIN. 
vehicleRegist ration contiene el VRN y el nombre del Estado miembro donde se matr iculó el vehículo. 
wVehicleCharacter isticCons tant es el coefi ciente caracte rístico del vehículo. 
kCons tantOfRecordingEquipment es la constante del aparat o 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. 
author isedSpeed es la velocidad máxima autorizada del vehículo. 
oldOdometerV alue, newOdometerV alue son la lectura anterior y la nueva lectura del cuentakilómetros. 
oldTimeV alue, newTimeV alue son el valor anterior y el nuev o valor de la fecha y la hora. 26.5.2016 L 139/167 Diar io Oficial de la Unión Europea ES    
nextCalibrationDate es la fecha del próximo calibrado del tipo especifi cado en CalibrationPur pose, a cargo de 
la autori dad de control autori zada. 
vuPar tNumber , vuSer ialNumber y sensorSer ialNumber son los element os de datos para la identif icación del 
aparat o de control. 
Generación 2: 
Además de los de la generación 1, se utilizan los siguientes elementos de datos: 
sensorGNSSSer ialNumber que identif ica un dispositivo GNSS externo. 
rcmSer ialNumber que identif ica un módulo de comunicación a distancia. 
sealDataCard da información sobre los precintos colocados en diversos component es del vehículo. 
2.237.  WorkshopCardHolderIdentif ication 
Información almacenada en una tarjeta de taller y relativa a la identif icación del titular de la tarjeta (anex o 1C, 
requisitos 311 y 334). 
workshopName es el nombre del taller que corresponde al titular de la tarjeta. 
workshopAd dress 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). 
cardHolderPreferredLan guage es el idioma prefer ido por el titular de la tarjeta. 
2.238.  WorkshopCardPIN 
Número de identif icación personal de la tarjeta de taller (anex o 1C. requisit os 309 y 332). 26.5.2016 L 139/168 Diar io Oficial de la Unión Europea ES    
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. 
2.239.  W-VehicleCharacter isticCons tant 
Coefi ciente caracterís tico 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.  VuPo werSupplyInter ruptionRecord 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a incident es de interr upción del 
suministro eléctr ico (anex o 1C, requisito 117). 
eventT ype es el tipo de incidente. 
eventRecordPur pose es el propósito con que se ha registrado ese incidente. 
eventBegin Time es la fecha y la hora de comienzo del incidente. 
eventEndTime es la fecha y la hora en que term ina el incident e. 
cardNumberAndGenDr iverSlotBegin identif ica la tarjeta, incluida su generación, que estaba inser tada en la 
ranura del conduct or en el momento en que comenzó el incident e. 
cardNumberAndGenDr iverSlotEnd identifica la tarjeta, incluida su generación, que estaba inser tada en la 
ranura del conduct or en el momento en que term inó el incidente. 
cardNumberAndGenCodr iverSlotBegin identifica la tarjeta, incluida su generación, que estaba inser tada en la 
ranura del segundo conduct or en el momento en que comenzó el incident e. 
cardNumberAndGenCodr iverSlotEnd identif ica la tarjeta, incluida su generación, que estaba inser tada en la 
ranura del segundo conduct or en el momento en que term inó el incidente. 
similarEv entsNumber es el número de incidentes similares ocur ridos ese día. 
2.241.  VuPo werSupplyInter ruptionRecordAr ray 
Generación 2: 
Información almacenada en una unidad instalada en el vehículo y relativa a incident es de interr upción del 
suministro eléctr ico (anex o 1C, requisito 117). 26.5.2016 L 139/169 Diar io Oficial de la Unión Europea ES    
recordT ype denota el tipo de registro (VuPowerSupplyInt erruptionRecord). Asignación de valor : véase 
RecordT ype. 
recordSize es el tamaño de VuPowerSupplyInt erruptionRecord en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es un conjunt o de registros sobre incidentes de interr upción del suministro eléctr ico. 
2.242.  VuSensorExter nalGNSSCoupledRecordAr ray 
Generación 2: 
Conjunto de SensorExte rnalGNSSCoupledRecord más metadatos tal y como se utiliza en el prot ocolo de transfe ­
rencia. 
recordT ype denota el tipo de registro (SensorExter nalGNSSCoupledRecord). Asignación de valor: véase 
RecordT ype. 
recordSize es el tamaño de SensorExt ernalGNSSCoupledRecord en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es un conjunt o de registros de SensorExter nalGNSSCoupled. 
2.243.  VuSensorPairedRecordAr ray 
Generación 2: 
Conjunto de SensorPaire dRecord más metadatos tal y como se utiliza en el prot ocolo de transfer encia. 
recordT ype denota el tipo de registro (SensorPairedRecord). Asignación de valor : véase RecordT ype. 
recordSize es el tamaño de SensorP airedRecord en bytes. 
noOfRecords es el número de registros que hay en el conjunt o. 
records es un conjunt o de registros de acoplamiento de sensor . 26.5.2016 L 139/170 Diar io Oficial de la Unión Europea ES    
3.  DEFINICIONES DE LOS INTER VALOS DE VALORES Y TAMAÑOS ADMISIBLES 
Defi nición de valores variables empleados en las definicione s del apar tado 2. 
4.  JUEGOS DE CARA CTERES 
Las cadenas IA5 utilizan los caracte res 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, VehicleRegistrationNumber) utilizan, asimismo, los carac ­
teres del código de caracteres decimales 161 a 255 del código estándar de 8 bits siguiente, especifica ­
dos 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 Mer idional 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 Sudor iental 16 
KOI8-R Latín / Cirílico 80 
KOI8-U Latín / Cirílico 85  
5.  CODIFICA CIÓN 
Si se aplican las reglas de codif icación NSA.1, todos los tipos de datos definidos deberán codificarse con arreglo 
a la norma ISO/CEI 8825-2, variante alineada. 
6.  IDENTIFICA DORES DE OBJETO E IDENTIFICA DORES DE APLICA CIÓN 
6.1.  Identif icadores de objeto 
Los identif icadores de objeto (OID) que figuran en el present e capítulo solo son pertinentes para la generación 2. 
Estos OID se especifican en TR-03110-3 y se repiten aquí en aras de la exhaustividad. Estos OID están 
conteni dos en el subárbol de bsi-de: 
26.5.2016 L 139/171 Diar io Oficial de la Unión Europea ES    
Identif icadores del prot ocolo de autenticación de la VU 
Ejemplo: Supongamos que la aute nticación de la VU debe hacerse con SHA- 384; en tal caso, se utilizará el identi ­
ficador de objeto (en notación ASN.1) 
 . El valor de este 
identif icador de objeto en notación de punt os 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’  
Identif icadores del prot ocolo de autenticación del chip 
Ejemplo: Supongam os que la autenticación del chip se hará utilizando el algor itmo ECDH, que da luga r a una 
longitud de clave de sesión AES de 128 bits. Esta clave de sesión se utilizará luego en el modo de funciona ­
miento CBC para garantizar la conf idencialidad de los datos y con el algor itmo CMA C para garant izar la 
autenticidad de los datos. Por consiguiente, el identif icador de objeto que hay que usar es (en notación ASN.1) 
. El valor de este identificad or 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’  
6.2.  Identif icadores de aplicación 
Generación 2: 
El identificador de aplicación (AID) para el dispositivo GNSS externo (gener ació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. 26.5.2016 L 139/172 Diar io Oficial de la Unión Europea ES    
Nota: Los últimos 5 bytes codifican DTEGM para el dispositivo GNSS externo del tacógraf o. 
El identif icador de aplicación para la aplicación de la tarjeta de tacógraf o 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.  26.5.2016 L 139/173 Diar io Oficial de la Unión Europea ES    
Apéndice 2 
ESPECIFIC ACIONES DE LAS TARJET AS DE TACÓGRAFO 
ÍNDICE 
1. INTR ODUCCIÓN .............................................................................................................................. 175 
1.1. Abreviaciones ...................................................................................................................... 175 
1.2. Referencias ......................................................................................................................... 176 
2. CARA CTERÍSTICAS ELÉCTRICAS Y FÍSICAS ........................................................................................... 176 
2.1. Tensión de alimentación y consumo de corriente ......................................................................... 177 
2.2. Tensión de programación Vpp.................................................................................................. 177 
2.3. Generación y frecuencia del reloj ............................................................................................. 177 
2.4. Contact o de entrada/salida ...................................................................................................... 177 
2.5. Estados de la tarjeta .............................................................................................................. 177 
3. SOPORTE FÍSICO Y COMUNICA CIONES ................................................................................................ 177 
3.1. Introducción ....................................................................................................................... 177 
3.2. Protocol o de transmisión ....................................................................................................... 178 
3.2.1 Protocol os.......................................................................................................................... 178 
3.2.2 ATR .................................................................................................................................. 179 
3.2.3 PTS ................................................................................................................................... 179 
3.3. Nor mas de acceso ................................................................................................................ 180 
3.4. Visión general de los comandos y los códigos de error ................................................................. 183 
3.5. Descr ipción de los comandos .................................................................................................. 185 
3.5.1 SELECT .......................................................................................................................................... 186 
3.5.2 READ BINAR Y................................................................................................................................. 187 
3.5.3 UPD ATE BINAR Y.............................................................................................................................. 194 
3.5.4 GET CHALLENGE ............................................................................................................................. 200 
3.5.5 VERIFY .......................................................................................................................................... 200 
3.5.6 GET RESPONSE ................................................................................................................................ 202 
3.5.7 PSO: VERIFY CERTIFICA TE.................................................................................................................. 202 
3.5.8 INTERNAL AUTHENTICA TE................................................................................................................ 204 
3.5.9 EXTERNAL AUTHENTICA TE ............................................................................................................... 205 
3.5.10 GENERAL AUTHENTICA TE................................................................................................................. 206 
3.5.11 MANA GE SECURIT Y ENVIR ONMENT .................................................................................................... 207 
3.5.12 PSO: HASH ..................................................................................................................................... 210 
3.5.13 PERFORM HASH of FILE .................................................................................................................... 211 
3.5.14 PSO: COMP UTE DIGIT AL SIGNA TURE ................................................................................................... 212 
3.5.15 PSO: VERIFY DIGIT AL SIGNA TURE ....................................................................................................... 213 
3.5.16 PROCESS DSR C MESSA GE .................................................................................................................. 214 
4. ESTR UCTURA DE LAS TARJET AS DE TACÓGRAFO .................................................................................. 216 
4.1. Archivo maestro MF ............................................................................................................. 216 26.5.2016 L 139/174 Diar io Oficial de la Unión Europea ES    
4.2. Aplicaciones de la tarjeta del conduct or..................................................................................... 217 
4.2.1 Aplicación de la tarjeta de conductor de generación 1.................................................................. 217 
4.2.2 Aplicación de la tarjeta de conductor de generación 2.................................................................. 221 
4.3. Aplicaciones de la tarjeta de taller ............................................................................................ 224 
4.3.1 Aplicación de la tarjeta de taller de generación 1......................................................................... 224 
4.3.2 Aplicación de la tarjeta de taller de generación 2......................................................................... 228 
4.4. Aplicaciones de la tarjeta de control ......................................................................................... 233 
4.4.1 Aplicación de la tarjeta de control de generación 1...................................................................... 233 
4.4.2 Aplicación de la tarjeta de control de generación 2...................................................................... 235 
4.5. Aplicaciones de la tarjeta de empresa ........................................................................................ 237 
4.5.1 Aplicación de la tarjeta de empr esa de generación 1..................................................................... 237 
4.5.2 Aplicación de la tarjeta de empr esa de generación 2..................................................................... 238  
1.  INTR ODUCCIÓN 
1.1.  Abreviaciones 
A efect os del present e apéndice se utilizan las siguiente s siglas: 
AC  Condiciones de acceso 
AES  Nor ma de cifrado avanzado 
AID  Identificador de aplicación 
ALW  Siempr e 
APDU  Unidad de datos de prot ocolo de una aplicación (estr uctura de un comando) 
ATR  Respuesta a reinicio 
AUT  Autentificado 
C6, C7  Contact os n.o 6 y 7 de la tarjeta, tal y como se descr iben en la norma ISO/CEI 7816-2 
cc  Ciclos de reloj 
CHV  Información para la verificación del titular de la tarjeta 
CLA  Byte de clase de un comando APDU 
DSR C  Comunicación especializada de corto alcance 
DF  Archivo dedicado. Un DF puede contener otros archiv os (EF o DF) 
ECC  Criptografía de curva elíptica 
EF  Archivo elemental 
etu  Unidad de tiempo elemental 
G1  Generación 1 
G2  Generación 2 
IC  Circuito integrado 
ICC  Tarjeta de circuito integrad o 
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 26.5.2016 L 139/175 Diar io Oficial de la Unión Europea ES    
IFSD  Dispositivo de tamaño del campo de información (para el term inal) 
INS  Byte de instr ucció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 prot ocolo T=1 
NEV  Nunca 
P1-P2  Bytes de parámetros 
PIN  Número de identif icación personal 
PRO SM  Prote gido con mensaj ería segura 
PTS  Selección de la transmisión de prot ocolo 
RFU  Reser vado para uso futuro 
RST  Reinicio (de la tarjeta) 
SFID  Identificador EF corto 
SM  Mensaj ería segura 
SW1-SW2  Bytes de estado 
TS  Carácte r 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 concate nación 03||04=0304 
1.2.  Referencia s 
En el present e apéndice se utilizan las referencias siguient es: 
ISO/CEI 7816-2  Tarjetas de identif icación — Tarjetas de circuito(s) integrad o(s) — Parte 2: Dimensiones y 
ubicación de los contact os. ISO/CEI 7816-2:2007. 
ISO/CEI 7816-3  Tarjetas de identificación — Tarjetas de circuito(s) integrado(s) — Parte 3: Interfaz eléctr ica 
y protocolos de transmisión. ISO/CEI 7816-3:2006. 
ISO/CEI 7816-4  Tarjetas de identif icación — Tarjetas de circuito(s) integrado(s) — Parte 4: Organización, 
segur idad y comandos para intercambio. ISO/CEI 7816-4:2013 + Cor 1: 2014. 
ISO/CEI 7816-6  Tarjetas de identificación — Tarjetas de circuit o(s) integrado(s) — Parte 6: Elementos de 
datos interindustr iales para inter cambio. ISO/CEI 7816-6:2004 + Cor 1: 2006. 
ISO/CEI 7816-8  Tarjetas de identificación — Tarjetas de circuito(s) integrad o(s) — Parte 8: Comandos para 
operaciones de segur idad. ISO/CEI 7816-8:2004. 
ISO/CEI 9797-2  Tecnología de la información — Técnicas de segur idad — Códigos de aute nticación de 
mensajes (MA Cs) — Parte 2: Mecanismos que utilizan una función específica de 
comprobación aleatoria. ISO/CEI 9797-2:2011 
2.  CARA CTERÍSTICAS ELÉCTRICAS Y FÍSICAS 
TCS_01  Todas las señales electrónicas deberán ser conf ormes a la norma ISO/CEI 7816-3, a menos que se 
especifi que 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. 26.5.2016 L 139/176 Diar io Oficial de la Unión Europea ES    
2.1.  Tensión de alimentación y consumo de corriente 
TCS_03 La tarjeta deberá traba jar con arreglo a las especificaciones, dentro de los límites de consumo especi ­
ficados 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 prog ramación Vpp 
TCS_05  La tarjeta no debe requer ir 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 Vcc 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 inter valo de frecuencias de 1 a 5 MHz y debe admitir frecuencias 
mayores. La frecuencia del reloj podrá exper imentar 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 traba jo puede variar entre el 40 % y el 60 %. 
TCS_07  El reloj exte rno puede ser detenido en las condiciones que especifica el arch ivo EF ICC de la tarjeta. 
El primer byte del cuer po del archiv o EF ICC codif ica las condiciones del modo clockstop: 
Bajo Alto   
Bit 3 Bit 2 Bit 1 
0 0 1 Se permite cloc kstop, no hay un nivel prefer ido 
0 1 1 Se permite cloc kstop, prefer iblement e en el nivel alto 
1 0 1 Se permite cloc kstop, prefer iblement e en el nivel bajo 
0 0 0 No se permite cloc kstop 
0 1 0 Se permite cloc kstop excl usivamente en el nivel alto 
1 0 0 Se permite cloc kstop excl usivamente en el nivel bajo  
Los bits 4 a 8 no se utilizan. 
2.4.  Conta cto de entrada/salida 
TCS_08 El contacto C7 de entrada/salida sirve para recibir y transmitir datos al IFD. Durante el funciona ­
miento 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á sufr ir 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 traba ja en dos estados mientras se aplica la tensión de alimentación: 
en estado de funcionamient o mientras se ejecutan los comandos o se mantiene la interconexión con 
la unidad digital, 
en estado de reposo en el resto de casos; en este estado la tarjeta deberá retener todos los datos. 
3.  SOPORTE FÍSICO Y COMUNICA CIONES 
3.1.  Introducción 
El presente apar tado descr ibe la funcionalidad mínima que precisan las tarjetas de tacógraf o y las VU para 
garan tizar un correcto funcionamiento e inter operabilidad. 26.5.2016 L 139/177 Diar io Oficial de la Unión Europea ES    
Las tarjetas de tacógraf o 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 descr ipción completa de los comandos y 
protocolo s a fin de especificar algunos casos de uso restr ingido o deter minadas diferencias que puedan 
existir . Los comandos especifi cados son totalment e conf ormes a las normas citadas, salvo en los casos que se 
indican. 
3.2.  Protoc olo de transmisión 
TCS_10  El prot ocolo de transmisión deberá ser conf orme 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 protocolo s T = 0 y T = 1. Además, la tarjeta podrá admitir otros 
protocolo s orientados a la conexión. 
TCS_12  T = 0 es el protocolo por defect o, de modo que se precisa un comando PTS para cambiar al 
protocolo T = 1. 
TCS_13  Los dispositivo s deberán admitir la conv ención directa en ambos protocolo s: por consiguiente, la 
convención directa es oblig atori a para la tarjeta. 
TCS_14  El byte correspondiente al tamaño del campo de información de la tarjeta en la ATR deberá 
presentarse en el caráct er TA3. Este valor deberá ser al menos ‘F0h’ (= 240 bytes). 
Los protocolo s estarán sujetos a las restr icciones siguiente s: 
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 caracte res 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 ocur rir 
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á present e en la respuesta ATR, el Extra Guard Time deberá estar present e para los 
caracte res que envíe el dispositivo de interfaz, aunque los caracteres que enví e la tarjeta 
igualmente podrán estar separados por 12 etu. Este principio también es cierto para el caráct er 
ACK que envía la tarjeta después de que el dispositivo de interfaz haya emitido un caráct er 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 compl ementar io 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-bloc k ABOR T: no se utiliza. 
—  S-bloc k VPP state error: no se utiliza. 
—  La longitud total de encadenamiento de un campo de datos no sobrepasará 255 bytes (de ello se 
asegurará el IFD). 
—  El IFD deberá indicar el dispositivo de tamaño del campo de información (IFSD) inmediatament e 
después de la respuesta ATR: el IFD deberá transmitir la petición de S-Block IFS después de la 
ATR y la tarjeta deberá enviar el S-Bloc k IFS. El valor recomendado para el IFSD es 254 bytes. 
—  La tarjeta no pedirá un reajust e del IFS. 26.5.2016 L 139/178 Diar io Oficial de la Unión Europea ES    
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 caracte res histór icos ATR. 
Ejemplo de biprotocolo básico ATR con arreglo a la norma ISO/CEI 7816-3 
Character Value Remarks 
TS ‘3Bh’ Indicates direct convention. 
T0 ‘85h’ TD1 present ; 5 histo rical bytes are presents. 
TD1 ‘80h’ TD2 present ; T=0 to be used 
TD2 ‘11h’ TA3 present ; T=1 to be used 
TA3 ‘XXh’ (at least ‘F0h’) Information Field Size Card ( IFSC) 
TH1 to TH5 ‘XXh’ Historical charact ers 
TCK ‘XXh’ Check Charact er (exclusive OR)  
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 direct orio actual. 
3.2.3  PTS 
TCS_19  El protocolo por defe cto es T=0. Para conf igurar el prot ocolo 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 oblig atori os para la tarjeta, la selección PTS 
básica de conmutación de protocolos es oblig atori a 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 defect o 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 apar te de la que se ajusta por defe cto (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 : 
Character Value Remarks 
PPSS ‘FFh’ The Initiat e Characte r. 
PPS0 ‘00h’ or ‘01h’ PPS1 to PPS3 are not present ; ‘00h’ to select T0, ‘01h’ to select 
T1. 
PK ‘XXh’ Check Characte r:  ‘XXh’ = ‘FFh’ if PPS0 = ‘00h’ , 
‘XXh’ = ‘FEh’ if PPS0 = ‘01h’ .  26.5.2016 L 139/179 Diar io Oficial de la Unión Europea ES    
3.3.  Nor mas de acceso 
TCS_22  Una norma de acceso especifi ca las condiciones de segur idad correspondientes para un modo de 
acceso, es decir , un comando. Si se cumplen estas condiciones de segur idad, se procesa el comando 
correspondiente. 
TCS_23  Se utilizan las condiciones de segur idad siguiente s para la tarjeta de tacógraf o: 
Abreviación Significado 
ALW La acción siempr e es posible y se puede ejecutar sin restr icciones. El co­
mando y la respuesta APDU se enví an en texto simple, es decir , sin mensaj e­
ría segura. 
NEV La acción nunca es posible. 
PLAIN-C El comando APDU se envía en texto simple, es decir , sin mensaj ería segura. 
PWD La acción solo puede ejecutarse si el PIN de la tarjeta de taller se verifica co­
rrectamente, es decir , si se ha configurad o el estado de segur idad intern a de 
la tarjeta ‘PIN_V erified’. El comando debe enviarse sin mensaj erí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-MA C-G1 El APDU (comando y respuesta) debe aplicarse con mensaj ería segura de ge­
neración 1 en modo exclusivament e de autenticación (véase la parte A del 
apéndice 11). 
SM-C-MA C-G1 El comando APDU debe aplicarse con mensajería segura de generación 1 en 
modo excl usivamente de autenticación (véase la parte A del apéndice 11). 
SM-R -ENC-G1 La respuesta APDU debe aplicarse con mensaj erí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 aute nticación de mensajes. 
SM-R -ENC-MA C-G1 La respuesta APDU debe aplicarse con mensaj ería segura de generación 1 en 
modo de cifrado y posteri ormente aute nticación (véase la parte A del apén ­
dice 11). 
SM-MA C-G2 El APDU (comando y respuesta) debe aplicarse con mensaj ería segura de ge­
neración 2 en modo excl usivamente de autenticación (véase la parte B del 
apéndice 11). 
SM-C-MA C-G2 El comando APDU debe aplicarse con mensajería segura de generación 2 en 
modo excl usivamente de autenticación (véase la parte B del apéndice 11). 
SM-R -ENC-MA C-G2 La respuesta APDU debe aplicarse con mensaj ería segura de generación 2 en 
modo de cifrado y post eriormente aute nticación (véase la parte B del apén ­
dice 11).  
TCS_24  Estas condiciones de segur idad pueden enlazarse de los modos siguient es: 
AND: deben cumplirse todas las condiciones de segur idad; 
OR: debe cumplir se al menos una condición de segur idad. 
Las normas de acceso para el siste ma de archiv os, es decir , los comandos SELECT , READ BINAR Y y 
UPD ATE BINAR Y, se especifi can en el apar tado 4. Las normas de acceso para el resto de comandos 
se especifican en las tablas siguient es. 26.5.2016 L 139/180 Diar io Oficial de la Unión Europea ES    
TCS_25  En la aplicación DF tacógraf o G1, se utilizan las siguientes normas de acceso: 
Comando Tarjeta del 
conducto r Tarjeta de centro 
de ensa yo Tarjeta de control Tarjeta de la 
empresa 
Extern al Authenticat e     
—  Para aute nticación 
de generación 1 ALW ALW ALW ALW 
—  Para aute nticación 
de generación 2 ALW PWD ALW ALW 
Internal Authenticat e ALW PWD ALW ALW 
General Auth enticate 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 DSR C Mes ­
sage No aplicable No aplicable No aplicable No aplicable 
PSO: Com pute Digital 
Signature ALW OR 
SM-MA C-G2 ALW OR 
SM-MA C-G2 No aplicable No aplicable 
PSO: Hash No aplicable No aplicable ALW No aplicable 
PSO: Hash of File ALW OR 
SM-MA C-G2 ALW OR 
SM-MA C-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  
TCS_26  En la aplicación DF tacógraf o_G2, se utilizan las siguiente s normas de acceso: 
Comando Tarjeta del 
conducto r Tarjeta de centro 
de ensa yo Tarjeta de control Tarjeta de la 
empresa 
Extern al Authenticat e     
—  Para aute nticación 
de generación 1 No aplicable No aplicable No aplicable No aplicable 
—  Para aute nticación 
de generación 2 ALW PWD ALW ALW 
Internal Authenticat e No aplicable No aplicable No aplicable No aplicable 26.5.2016 L 139/181 Diar io Oficial de la Unión Europea ES    
Comando Tarjeta del 
conducto r Tarjeta de centro 
de ensa yo Tarjeta de control Tarjeta de la 
empresa 
General Auth enticate 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 DSR C Mes ­
sage No aplicable ALW ALW No aplicable 
PSO: Com pute Digital 
Signature ALW OR 
SM-MA C-G2 ALW OR 
SM-MA C-G2 No aplicable No aplicable 
PSO: Hash No aplicable No aplicable ALW No aplicable 
PSO: Hash of File ALW OR 
SM-MA C-G2 ALW OR 
SM-MA C-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  
TCS_27  En el MF, se utilizan las siguient es normas de acceso: 
Comando Tarjeta del 
conducto r Tarjeta de centro 
de ensa yo Tarjeta de control Tarjeta de la 
empresa 
Extern al Authenticat e     
—  Para aute nticación 
de generación 1 No aplicable No aplicable No aplicable No aplicable 
—  Para aute nticación 
de generación 2 ALW PWD ALW ALW 
Internal Authenticat e No aplicable No aplicable No aplicable No aplicable 
General Auth enticate 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 DSR C Mes ­
sage No aplicable No aplicable No aplicable No aplicable 26.5.2016 L 139/182 Diar io Oficial de la Unión Europea ES    
Comando Tarjeta del 
conducto r Tarjeta de centro 
de ensa yo Tarjeta de control Tarjeta de la 
empresa 
PSO: Com pute Digital 
Signature No aplicable No aplicable No aplicable No aplicable 
PSO: Hash No aplicable No aplicable No aplicable No aplicable 
PSO: Hash of File No aplicable No aplicable No aplicable No aplicable 
PSO: Verify Certificate ALW ALW ALW ALW 
Verify No aplicable ALW No aplicable No aplicable  
TCS_28  Una tarjeta de tacógraf o puede o no aceptar un comando con un nivel de segur idad super ior al 
especifi cado en las condiciones de segur idad. Es decir , si la condición de segur idad es ALW (o 
PLAIN-C), la tarjeta puede acept ar un comando con mensaj ería segura (modo de cifrado y/o autenti ­
cación). Si la condición de segur idad requiere mensajería segura con modo de autenti cación, la 
tarjeta del tacógraf o puede acept ar un comando con mensaj ería segura de la misma generación en 
modo de autenti cación y cifrado. 
Nota: Las descr ipciones de los comandos ofrecen más información acerca de la compatib ilidad de 
los comandos con distintos tipos de tarjetas de tacógraf o y diferent es DF. 
3.4.  Visión general de los comandos y los códigos de error 
Los comandos y la organización de arch ivos se deducen de la norma ISO/CEI 7816-4 y se ajustan a ella. 
En esta sección se descr iben los siguient es pares comando APDU-respuesta. Las variantes de comandos que 
admite una aplicación de generación 1 y 2 se especific an en las descr ipciones correspondientes de los 
comandos. 
Comando INS 
SELECT ‘A4h’ 
READ BINAR Y ‘B0h’, ‘B1h’ 
UPD ATE BINAR Y ‘D6h’, ‘D7h’ 
GET CHALLENGE ‘84h’ 
VERIFY ‘20h’ 
GET RESPONSE ‘C0h’ 
PERFORM SECURIT Y OPERA TION ‘2Ah’ 
—  VERIFY CER TIFIC ATE  
—  COMPUTE DIGIT AL SIGNA TURE  
—  VERIFY DIGIT AL SIGNA TURE  
—  HASH  
—  PERFORM HASH OF FILE  
—  PROCESS DSR C MESSA GE  26.5.2016 L 139/183 Diar io Oficial de la Unión Europea ES    
Comando INS 
INTERNAL AUTHENTICA TE ‘88h’ 
EXTERNAL AUTHENTICA TE ‘82h’ 
MANA GE SECURIT Y ENVIR ONMENT ‘22h’ 
—  SET DIGIT AL SIGNA TURE TEMPL ATE  
—  SET AUTHENTICA TION TEMPL ATE  
GENERAL AUTHENTICA TE ‘86h’  
TCS_29  Las palabras de estado SW1 SW2 aparecen en todos los mensaj es 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 devuelt os puede estar dañada 
63 00 Ha fallado la aute nticación (Advertencia) 
63 CX CHV (PIN) incor recto. ‘X’ indica el contador de intent os restant es 
64 00 Error de ejecución. No ha variado el estado de la memor ia permanent e. Error 
de integridad. 
65 00 Error de ejecución. Ha variado el estado de la memor ia permanent e 
65 81 Error de ejecución. Ha variado el estado de la memor ia permanente. Fallo de 
memor ia 
66 88 Error de segur idad: suma de control criptográfica incor recta (durante la men ­
sajería segura) o bien 
certificado incor recto (durante la verificación del certifi­
cado) o bien 
criptograma incor recto (durante la autentificación ex­
tern a) o bien 
firma incor recta (durante la verificación de la firma) 
67 00 Longitud incor recta (Lc o Le incor recta) 
68 82 Mensajería segura no admitida 
68 83 Último comando de la cadena esperado 
69 00 Comando prohibido (no hay respuesta disponible en T=0) 
69 82 Estado de segur idad no satisf echo. 
69 83 Método de autentificación bloqueado. 
69 85 Condiciones de uso no satisf echas. 
69 86 Comando no autori zado (falta el EF actual). 26.5.2016 L 139/184 Diar io Oficial de la Unión Europea ES    
SW1 SW2 Significado 
69 87 Faltan objeto s de datos de mensaj ería segura que se esperaban. 
69 88 Objetos de datos de mensaj ería segura incor rectos. 
6A 80 Parámetros incor rectos en el campo de datos 
6A 82 Archiv o no encontrado. 
6A 86 Parámetros P1-P2 incor rectos. 
6A 88 Datos referenciados no encontrados. 
6B 00 Parámetros incor rectos (desviación fuera del EF). 
6C XX Longitud incor recta, SW2 indica la longitud exacta. No se devuelve un campo 
de datos. 
6D 00 Código de instr ucción no admitido o no válido. 
6E 00 Clase no admitida. 
6F 00 Otros errores de comprobación  
TCS_30  Si se cumplen más de una condición de error en un comando APDU, la tarjeta puede devol ver 
cualquiera de las palabras de estado adecuada. 
3.5.  Descr ipción de los comandos 
En el present e apar tado se descr iben los comandos obligat orios para las tarjetas de tacógraf o. 
En el apéndice 11 (Mecanismos de segur idad comunes) hallará otros pormenores relevante s relacionados con 
las operaciones criptográficas que es preciso realizar para tacógraf os de generación 1 y generación 2. 
Todos los comandos se descr iben con independencia del prot ocolo utilizado (T=0 o T=1). Los bytes APDU 
CLA, INS, P1, P2, Lc y Le siempr e se indican. Si el byte Lc o Le no es necesar io para el comando descr ito, 
entonces la longitud, el valor y la descr ipción asociados están vacíos. 
TCS_31  Si se solicitan los dos bytes de longitud (Lc y Le) y además el IFD está utilizando el prot ocolo T=0, 
es preciso dividir en dos partes el comando descr ito: el IFD envía el comando del modo descr ito 
con P3 = Lc + datos y seguidamente 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 tarjeta 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ógraf o podría admitir campos de longitud ampliada conf orme a ISO/CEI 7816-4 
como función opcional. Una tarjeta de tacógraf o que admita campos de longitud amplia da deberá: 
—  indicar la compati bilidad con los campos de longitud ampliada en la ATR; 
—  proporcionar los tamaños de memor ia temporal admitidos por medio de la información de 
longitud ampli ada en el EF ATR/INFO, véase TCS_146; 26.5.2016 L 139/185 Diar io Oficial de la Unión Europea ES    
—  indicar si admite campos de longitud ampli ada para T = 1 y/o T = 0 en la longitud ampli ada de 
EF, véase TCS_147; 
—  admitir campos de longitud amplia da para la aplicación de tacógraf o de generación 1 y 2. 
Notas: 
Las especificaciones de todos los comandos son para campos de longitud corta. El uso de APDU de 
longitud amplia da está claro en ISO/CEI 7816-4. 
Por lo general, se especifi can los comandos para el modo director , es decir , sin mensaj ería segura, ya 
que la capa de mensajería segura se especifica en el apéndice 11. Se deduce claramente de las 
normas de acceso de un comando si este debe admitir mensaj ería segura o no y si el comando debe 
admitir mensaj ería segura de generación 1 y/o generación 2. Algunas variantes de comandos se 
descr iben con mensajería segura para ilustrar el uso de la mensaj ería segura. 
TCS_34  La VU deberá ejecutar todo el prot ocolo de autenticación mutua de generación 2 VU-tar jeta durante 
una sesión, incluida la verificación de certificad os (en caso necesar io) ya sea en el DF tacógraf o, en 
el DF tacógraf o_G2 o en el MF. 
3.5.1  SELECT 
Este comando cumple con lo dispuest o en la norma ISO/CEI 7816-4, pero tiene un uso restr ingido en 
comparación con el comando que se define en dicha norma. 
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 archiv o enviado. 
3.5.1.1  Selección por nombre (AID) 
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 arch ivos (después de la 
respuesta ATR o en cualquier momento) . 
TCS_36  Al seleccionar una aplicación se reinicia el entorno de segur idad 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 comando se ejecutó sin mensaj ería segura, las claves de la sesión de 
mensaj ería segura anter ior dejan de estar disponibles. 
TCS_37  Mensaje de comando 
Byte Longitud Valor Descr ipció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ógraf o 
#6-#(5+NN) NN ‘XX..XXh’ AID: ‘FF 54 41 43 48 4F’ para la aplicación de tacógraf o de 
generación 1 
AID: ‘FF 53 4D 52 44 54’ para la aplicación de tacógraf o 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). 26.5.2016 L 139/186 Diar io Oficial de la Unión Europea ES    
TCS_38  Mensaje de respuest a (no se pide respuest a) 
Byte Longitud Valor Descr ipción 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
—  Si el comando se ejecuta correctamente , la tarjeta contes ta con el estado ‘9000’. 
—  Si no se encuentra la aplicación que corresponde al AID, se conte sta con el estado de procesado 
‘6A82’ . 
—  En T=1, si está present e 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’. 
—  Si se considera que la aplicación seleccionada está dañada (se detecta un error de integridad 
dentro de los atribut os del archiv o), se contes ta con el estado de procesado ‘6400’ o ‘6581’. 
3.5.1.2  Selección de un archivo elemental utilizando su identificador de arch ivo 
TCS_39  Mensaje de comando 
TCS_40  Una tarjeta de tacógraf o deberá admitir mensaj ería segura de generación 2 tal como se especifi ca en 
la parte B del apéndice 11 para esta variante de comando. 
Byte Longitud Valor Descr ipció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’ Identif icador de archiv o  
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 respuest a (no se pide respuest a) 
Byte Longitud Valor Descr ipción 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
—  Si el comando se ejecuta correctamente , la tarjeta contes ta con el estado ‘9000’. 
—  Si no se encuentra el archiv o que corresponde al identif icador , se cont esta con el estado de 
procesado ‘6A82’ . 
—  En T=1, si está present e 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’. 
—  Si se considera que el archiv o seleccionado está dañado (se detec ta un error de integridad dentro 
de los atribut os del archiv o), se conte sta con el estado de procesado ‘6400’ o ‘6581’. 
3.5.2  READ BINARY 
Este comando cumple con lo dispuest o en la norma ISO/CEI 7816-4, pero tiene un uso restr ingido en 
comparación con el comando que se define en dicha norma. 26.5.2016 L 139/187 Diar io Oficial de la Unión Europea ES    
El comando READ BINAR Y sirve para leer datos de un archiv o transparent e. 
La respuesta de la tarjeta consiste en devol ver los datos leídos, opcionalment e encapsulados en una 
estructura de mensaj ería segura. 
3.5.2.1  Comando con desviación en P1-P2 
Este comando permite al IFD leer datos del EF actualmente seleccionado, sin mensaj ería segura. 
Nota: Este comando sin mensaj ería segura solo puede utilizarse para leer un arch ivo que admita la condición 
de segur idad ALW para el modo de acceso de lectura. 
TCS_42  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘00h’  
INS 1 ‘B0h’ Read Binar y 
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 archiv o: byte menos significa ­
tivo 
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 respuest a 
Byte Longitud Valor Descr ipció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 contes ta 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 segur idad del archiv o seleccionado, se interr umpe el 
comando con ‘6982’. 
—  Si la desviación no es compatible con el tamaño del EF (desviación > tamaño del EF), se conte sta 
con el estado de procesado ‘6B00’. 
—  Si el tamaño de los datos que se han de leer no es compati ble con el tamaño del EF (desviación 
+ Le > tamaño del EF), se conte sta con el estado de procesado ‘6700’ o ‘6Cxx’ donde ‘xx’ indica 
la longitud exacta. 
—  Si se detecta un error de integridad dentro de los atribut os del archiv o, la tarjeta considerará el 
arch ivo dañado e irrecuperable, se contes ta con el estado de procesado ‘6400’ o ‘6581’. 
—  Si se detecta un error de integr idad dentro de los datos almacenados, la tarjeta devuelve los 
datos solicitados y conte sta con el estado de procesado ‘6281’. 
3.5.2.1.1  Comando con mensa jería segura (ejem plos) 
Este comando permite al IFD leer datos del EF actualmente seleccionado, con mensaj ería segura, a fin de 
verificar la integr idad de los datos recibidos y prot eger la confidencialidad de los datos si se aplica la 
condición de segur idad SM-R -ENC-MA C-G1 (generación 1) o SM-R -ENC-MA C-G2 (generación 2). 26.5.2016 L 139/188 Diar io Oficial de la Unión Europea ES    
TCS_44  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘0Ch’ Se pide mensaj ería segura 
INS 1 ‘B0h’ Read Binar y 
P1 1 ‘XXh’ P1 (desviación en bytes desde el comienzo del arch ivo): byte 
más signif icativ o 
P2 1 ‘XXh’ P2 (desviación en bytes desde el comienzo del arch ivo): byte 
menos significativo 
Lc 1 ‘XXh’ Longitud de los datos de entrada para mensaj ería segura 
#6 1 ‘97h’ TLE: Etiqueta para especifi cación de la longitud esperada. 
#7 1 ‘01h’ LLE: Longitud de la longitud esperada 
#8 1 ‘NNh’ Especifi cación de la longitud esperada (Le original): Número 
de bytes que se han de leer 
#9 1 ‘8Eh’ TCC: Etiqueta para suma de control criptográfica 
#10 1 ‘XXh’ LCC: 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 mensaj ería segura de generación 2 (véase la parte B 
del apéndice 11) 
#11-#(10+L) L ‘XX..XXh’ Cryptographi c chec ksum (suma de control criptográfi ca ), 
Le 1 ‘00h’ Según se especifica en la norma ISO/CEI 7816-4  
TCS_45  Mensaje de respuest a si no se requiere SM-R-ENC-MA C-G1 (generación 1) / SM-R-ENC- 
MA C-G2 (generación 2) y si el format o de entrada de mensajería segura es correcto: 
Byte Longitud Valor Descr ipción 
#1 1 ‘99h’ Etiqueta para el estado de procesado (SW1- 
SW2) — opcional para mensaj ería segura de 
generación 1 
#2 1 ‘02h’ Longitud del estado de procesado 
#3 — #4 2 ‘XX XXh’ Estado de procesado de la respuesta APDU sin 
prot eger 
#5 1 ‘81h’ TPV: Etiqueta para datos del valor plano 
#6 L ‘NNh’ o 
‘81 NNh’ LPV: longitud de los datos devuelt os (=Le origi­
nal). 
L es 2 bytes si LPV > 127 bytes 26.5.2016 L 139/189 Diar io Oficial de la Unión Europea ES    
Byte Longitud Valor Descr ipción 
#(6+L)-#(5+L+NN) NN ‘XX..XXh’ Valor de datos planos 
#(6+L+NN) 1 ‘8Eh’ TCC: Etiqueta para suma de control criptográfica 
#(7+L+NN) 1 ‘XXh’ LCC: Longitud de la siguient e 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 mensaj ería segura de gene­
ración 2 (véase la parte B del apéndice 11) 
#(8+L+NN)-#(7+M+L+NN) M ‘XX..XXh’ Suma de control criptográfi ca 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
TCS_46  Mensaje de respuest a si se requiere SM-R-ENC-MA C-G1 (generación 1) / SM-R-ENC-MA C-G2 
(generación 2) y si el format o de entrada de mensajería segura es correcto: 
Byte Longitud Valor Descr ipción 
#1 1 ‘87h’ TPI CG: Etiqueta para datos cifrados (cripto­
grama) 
#2 L ‘MMh’ o 
‘81 MMh’ LPI CG: longitud de los datos cifrados que se 
devuelven (distinta de la Le original del co­
mando, 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 mensaj ería segura 
de generación 1 
#(3+L+MM) 1 ‘02h’ Longitud del estado de procesado 
#(4+L+MM) — #(5+L+MM) 2 ‘XX XXh’ Estado de procesado de la respuesta APDU 
sin prot eger 
#(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áfi ca 
‘04h’ para mensaj ería segura de generación 
1 (véase la parte A del apéndice 11) 
‘08h’ , ‘0Ch’ o ‘10h’ dependiendo de la lon­
gitud de la clave AES para mensaj ería se­
gura 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)  26.5.2016 L 139/190 Diar io Oficial de la Unión Europea ES    
El comando READ BINAR Y puede devol ver estados de procesado normales enumerados en TCS_43 
bajo la etiqueta ‘99h’ tal como se descr ibe en TCS_59 utilizando la estructura de respuesta de 
mensaj ería segura. 
Asimismo, es posible que se produzcan algunos errores específicamente relacionados con la 
mensaj erí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_47  Mensaje de respuest a si el format o de entrada de mensajería segura es incor recto 
Byte Longitud Valor Descr ipció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 ocur re si la clave de la sesión no se ha generado toda vía o si ha expirado la validez de 
dicha clave (en tal caso, el IFD debe ejecutar de nuevo un proceso de autenti ficación mutua para 
establecer una nueva clave de sesión). 
—  Si en el formato de mensaj ería segura faltan algunos de los objeto s de datos que se esperaban 
(anteriormente especificados), se devuelve el estado de procesado ‘6987’: este error se produce si 
falta una etiqueta esperada o si el cuer po del comando no está bien constr uido. 
—  Si algunos de los objetos de datos son incor rectos, se cont esta con el estado de procesado 
‘6988’: este error se produce si están present es todas las etiquetas necesar ias pero algunas 
longitudes no coinciden con las esperadas. 
—  Si falla la verificación de la suma de control criptográfica, se cont esta con el estado de 
procesado ‘6688’. 
3.5.2.2  Comando con identificador EF (arc hivo elemental) cor to 
Esta variante de comando permite al IFD seleccionar un EF por medio de un identif icador EF corto y leer los 
datos de este EF. 
TCS_48  Una tarjeta de tacógraf o deberá admitir esta variante de comando para todos los archiv os 
elementales que lleven especificado un identif icador EF corto. Estos identificadores EF cortos se 
especifi can en el apar tado 4. 
TCS_49  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘00h’  
INS 1 ‘B0h’ Read Binar y 
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 identif icador 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 aplicación de tacógraf o de generación 2 se 
especifi can en el apar tado 4. 
Si P1 codifica un identif icador EF corte y el comando es correcto, el EF identif icado pasa a ser el EF 
seleccionado actualmente (EF actual). 
TCS_50  Mensaje de respuest a 
Byte Longitud Valor Descr ipción 
#1-#L L ‘XX..XXh’ Datos leídos 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  26.5.2016 L 139/191 Diar io Oficial de la Unión Europea ES    
—  Si el comando se ejecuta correctamente , la tarjeta contes ta con el estado ‘9000’. 
—  Si no se encuentra el archivo que corresponde al identif icador EF corto, se conte sta con el 
estado de procesado ‘6A82’ . 
—  Si no se satisf acen las condiciones de segur idad del archiv o seleccionado, se interr umpe el 
comando con ‘6982’. 
—  Si la desviación no es compatible con el tamaño del EF (desviación > tamaño del EF), se conte sta 
con el estado de procesado ‘6B00’. 
—  Si el tamaño de los datos que se han de leer no es compati ble con el tamaño del EF (desviación 
+ Le > tamaño del EF), se conte sta con el estado de procesado ‘6700’ o ‘6Cxx’ donde ‘xx’ indica 
la longitud exacta. 
—  Si se detecta un error de integridad dentro de los atribut os del archiv o, la tarjeta considerará el 
arch ivo dañado e irrecuperable, se contes ta con el estado de procesado ‘6400’ o ‘6581’. 
—  Si se detecta un error de integr idad dentro de los datos almacenados, la tarjeta devuelve los 
datos solicitados y conte sta con el estado de procesado ‘6281’. 
3.5.2.3  Comando con byte de instr ucción impar 
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ógraf o que admita EF de 32 768 bytes o más deberá admitir esta variante de 
comando para estos EF. Una tarjeta de tacógraf o puede o no admitir esta variante de comando para 
otros EF a excepci ón del EF Sensor_Installation_Data; véase TCS_156 y TCS_160. 
TCS_52  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘00h’  
INS 1 ‘B1h’ Read Binar y 
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 
Le 1 ‘XXh’ Número de bytes que se han de leer.  
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 
comprendida entre ‘256’ y ‘65 535’ bytes. 
TCS_53  Mensaje de respuest a 
Byte Longitud Valor Descr ipción 
#1-#L L ‘XX..XXh’ Datos leídos encapsulados en un objeto de datos discrecional con 
etiqueta ‘53h’ . 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  26.5.2016 L 139/192 Diar io Oficial de la Unión Europea ES    
—  Si el comando se ejecuta correctamente , la tarjeta contes ta con el estado ‘9000’. 
—  Si no se selecciona un EF, se contesta con el estado de procesado ‘6986’. 
—  Si no se satisf acen las condiciones de segur idad del archiv o seleccionado, se interr umpe el 
comando con ‘6982’. 
—  Si la desviación no es compatible con el tamaño del EF (desviación > tamaño del EF), se conte sta 
con el estado de procesado ‘6B00’. 
—  Si el tamaño de los datos que se han de leer no es compati ble con el tamaño del EF (desviación 
+ Le > tamaño del EF), se conte sta con el estado de procesado ‘6700’ o ‘6Cxx’ donde ‘xx’ indica 
la longitud exacta. 
—  Si se detecta un error de integridad dentro de los atribut os del archiv o, la tarjeta considerará el 
arch ivo dañado e irrecuperable, se contes ta con el estado de procesado ‘6400’ o ‘6581’. 
—  Si se detecta un error de integr idad dentro de los datos almacenados, la tarjeta devuelve los 
datos solicitados y conte sta con el estado de procesado ‘6281’. 
3.5.2.3.1  Comando con mensa jería segura (ejem plo) 
El siguient e ejemplo ilustra el uso de la mensaj ería segura si se aplica la condición de segur idad SM-MA C-G2. 
TCS_54  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘0Ch’ Se pide mensaj ería segura 
INS 1 ‘B1h’ Read Binar y 
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 1 ‘NNh’ LPV: longitud de los datos transmitidos 
#(8)-#(7+NN) NN ‘XX..XXh’ Datos planos codificados en BER -TLV, es decir , el 
objeto de datos de desviación con etiqueta ‘54’ 
#(8+NN) 1 ‘97h’ TLE: Etiqueta para especificación de la longitud es­
perada. 
#(9+NN) 1 ‘01h’ LLE: Longitud de la longitud esperada 
#(10+NN) 1 ‘XXh’ Especificación de la longitud esperada (Le origi­
nal): Número de bytes que se han de leer 
#(11+NN) 1 ‘8Eh’ TCC: Etiqueta para suma de control criptográfica 
#(12+NN) 1 ‘XXh’ LCC: Longitud de la siguient e suma de control 
criptográfica 
‘08h’ , ‘0Ch’ o ‘10h’ dependiendo de la longitud de 
la clave AES para mensaj erí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áfi ca 
Le 1 ‘00h’ Según se especifi ca en la norma ISO/CEI 7816-4  26.5.2016 L 139/193 Diar io Oficial de la Unión Europea ES    
TCS_55  Mensaje de respuesta si el comando es correcto 
Byte Longitud Valor Descr ipción 
#1 1 ‘B3h’ Datos planos codificados en BER -TLV 
#2 L ‘NNh’ o 
‘81 NNh’ LPV: longitud de los datos devuelt os (=Le origi­
nal). 
L es 2 bytes si LPV > 127 bytes 
#(2+L)-#(1+L+NN) NN ‘XX..XXh’ Valor de datos planos codificado s en BER -TLV, 
es decir , 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 
prot eger 
#(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 
prot eger 
#(6+L+NN) 1 ‘8Eh’ TCC: Etiqueta para suma de control criptográfica 
#(7+L+NN) 1 ‘XXh’ LCC: Longitud de la siguient e suma de control 
criptográfica 
‘08h’ , ‘0Ch’ o ‘10h’ dependiendo de la longitud 
de la clave AES para mensaj ería segura de gene­
ración 2 (véase la parte B del apéndice 11) 
#(8+L+NN)-#(7+M+L+NN) M ‘XX..XXh’ Suma de control criptográfi ca 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
3.5.3  UPD ATE BINARY 
Este comando cumple con lo dispuest o en la norma ISO/CEI 7816-4, pero tiene un uso restr ingido en 
comparación con el comando que se define en dicha norma. 
El mensaj e de comando UPD ATE BINAR Y inicia la actualización (bor rar + escr ibir) de los bits ya present es en 
un EF binar io, para sustituirlos por los bits dados en el comando APDU. 
3.5.3.1  Comando con desviación en P1-P2 
Este comando permite al IFD escr ibir datos en el EF actualmente seleccionado, sin que la tarjeta verifique la 
integridad de los datos recibidos. 
Nota: Este comando sin mensaj ería segura solo puede utilizarse para leer un arch ivo que admita la condición 
de segur idad ALW para el modo de acceso de actualización. 
TCS_56  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘00h’  
INS 1 ‘D6h’ Update Binar y 26.5.2016 L 139/194 Diar io Oficial de la Unión Europea ES    
Byte Longitud Valor Descr ipción 
P1 1 ‘XXh’ Desviación en bytes desde el comienzo del archivo: byte más 
signif icativ o 
P2 1 ‘XXh’ Desviación en bytes desde el comienzo del arch ivo: byte me­
nos signif icativ o 
Lc 1 ‘NNh’ Lc Longitud de los datos que se han de actualizar . Número de 
bytes que se han de escr ibir. 
#6-#(5+NN) NN ‘XX..XXh’ Datos que se han de escr ibir  
Nota: el bit 8 de P1 debe ponerse a 0.  
TCS_57  Mensaje de respuest a 
Byte Longitud Valor Descr ipción 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
—  Si el comando se ejecuta correctamente , la tarjeta contes ta con el estado ‘9000’. 
—  Si no se selecciona un EF, se contesta con el estado de procesado ‘6986’. 
—  Si no se satisf acen las condiciones de segur idad del archiv o seleccionado, se interr umpe el 
comando con ‘6982’. 
—  Si la desviación no es compatible con el tamaño del EF (desviación > tamaño del EF), se conte sta 
con el estado de procesado ‘6B00’. 
—  Si el tamaño de los datos que se han de escr ibir no es compat ible 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 atribut os del archiv o, la tarjeta considerará el 
arch ivo dañado e irrecuperable, se contes ta con el estado de procesado ‘6400’ o ‘6500’. 
—  Si falla la escr itura, se cont esta con el estado de procesado ‘6581’. 
3.5.3.1.1  Comando con mensa jería segura (ejem plos) 
Este comando permite al IFD escr ibir datos en el EF actualmente seleccionado, de modo que la tarjeta verifica 
la integridad de los datos recibidos. Dado que no se precisa conf idencialidad, los datos no están cifrados. 
TCS_58  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘0Ch’ Se pide mensajería segura 
INS 1 ‘D6h’ Updat e Binar y 
P1 1 ‘XXh’ Desviación en bytes desde el comienzo del ar­
chivo: 
byte más signif icativ o 
P2 1 ‘XXh’ Desviación en bytes desde el comienzo del ar­
chivo: 
byte menos signif icativ o 
Lc 1 ‘XXh’ Longitud del campo de datos seguro 26.5.2016 L 139/195 Diar io Oficial de la Unión Europea ES    
Byte Longitud Valor Descr ipción 
#6 1 ‘81h’ TPV: Etiqueta para datos del valor plano 
#7 L ‘NNh’ o 
‘81 NNh’ LPV: longitud de los datos transmitidos. 
L es 2 bytes si LPV > 127 bytes. 
#(7+L)-#(6+L+NN) NN ‘XX..XXh’ Valor de datos planos (datos que se han de es­
cribir) 
#(7+L+NN) 1 ‘8Eh’ TCC: Etiqueta para suma de control criptográfica 
#(8+L+NN) 1 ‘XXh’ LCC: Longitud de la siguient e suma de control 
criptográfica ‘04h’ para mensaj erí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 mensaj ería segura de gene­
ració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áfi ca 
Le 1 ‘00h’ Según se especifica en la norma ISO/CEI 7816- 
4  
TCS_59  Mensaje de respuest a si el format o de entrada de mensajería segura es correcto 
Byte Longitud Valor Descr ipción 
#1 1 ‘99h’ TSW: Etiqueta para palabras de estado (con la prot ección de CC) 
#2 1 ‘02h’ LSW: longitud de las palabras de estado devueltas 
#3-#4 2 ‘XXXXh’ Estado de procesado de la respuesta APDU sin proteg er 
#5 1 ‘8Eh’ TCC: Etiqueta para suma de control criptográfica 
#6 1 ‘XXh’ LCC: Longitud de la siguient e suma de control criptográfica 
‘04h’ para mensaj erí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 mensa jerí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áfi ca 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
Los estados de procesado «nor males», descr itos para el comando UPD ATE BINAR Y sin mensaj ería 
segura (véase §3.5.3.1), se pueden devolver utilizando las estructuras de mensaj e de respuesta 
descr itas anter iormente. 
Asimismo, es posible que se produzcan algunos errores específicamente relacionados con la 
mensaj erí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 respuest a si se produce un error de mensajería segura 
Byte Longitud Valor Descr ipción 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  26.5.2016 L 139/196 Diar io Oficial de la Unión Europea ES    
—  Si no hay una clave disponible para la sesión actual, se devuelve el estado de procesado ‘6A88’. 
—  Si en el formato de mensaj ería segura faltan algunos de los objeto s de datos que se esperaban 
(anteriormente especificados), se devuelve el estado de procesado ‘6987’: este error se produce si 
falta una etiqueta esperada o si el cuer po del comando no está bien constr uido. 
—  Si algunos de los objetos de datos son incor rectos, se cont esta con el estado de procesado 
‘6988’: este error se produce si están present es todas las etiquetas necesar ias pero algunas 
longitudes no coinciden con las esperadas. 
—  Si falla la verificación de la suma de control criptográfica, se cont esta con el estado de 
procesado ‘6688’. 
3.5.3.2  Comando con identificador EF cor to 
Esta variante de comando permite al IFD seleccionar un EF por medio de un identificad or EF corto y escr ibir 
los datos de este EF. 
TCS_61  Una tarjeta de tacógraf o deberá admitir esta variante de comando para todos los archiv os 
elementales que lleven especificado un identif icador EF corto. Estos identificadores EF cortos se 
especifi can en el apar tado 4. 
TCS_62  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘00h’  
INS 1 ‘D6h’ Update Binar y 
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 identificad or EF corto del EF co­
rrespondiente 
P2 1 ‘XXh’ Codif ica una desviación desde 0 hasta 255 bytes en el EF refe­
renciado por P1 
Lc 1 ‘NNh’ Lc Longitud de los datos que se han de actualizar . Número de 
bytes que se han de escr ibir. 
#6-#(5+NN) NN ‘XX..XXh’ Datos que se han de escr ibir  
TCS_63  Mensaje de respuest a 
Byte Longitud Valor Descr ipción 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
Nota: Los identificadores EF cortos utilizados para la aplicación de tacógraf o de generación 2 se 
especifi can en el apar tado 4. 
Si P1 codifica un identif icador EF corte y el comando es correcto, el EF identif icado pasa a ser el EF 
seleccionado actualmente (EF actual). 
—  Si el comando se ejecuta correctamente , la tarjeta contes ta con el estado ‘9000’. 
—  Si no se encuentra el archivo que corresponde al identif icador EF corto, se conte sta con el 
estado de procesado ‘6A82’ . 
—  Si no se satisf acen las condiciones de segur idad del archiv o seleccionado, se interr umpe el 
comando con ‘6982’. 26.5.2016 L 139/197 Diar io Oficial de la Unión Europea ES    
—  Si la desviación no es compatible con el tamaño del EF (desviación > tamaño del EF), se conte sta 
con el estado de procesado ‘6B00’. 
—  Si el tamaño de los datos que se han de escr ibir no es compat ible 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 atribut os del archiv o, la tarjeta considerará el 
arch ivo dañado e irrecuperable, se contes ta con el estado de procesado ‘6400’ o ‘6581’. 
—  Si falla la escr itura, se cont esta con el estado de procesado ‘6581’. 
3.5.3.3  Comando con byte de instr ucción impar 
Esta variante de comando permite al IFD escr ibir datos de un EF de 32 768 bytes o más. 
TCS_64  Una tarjeta de tacógraf o que admita EF de 32 768 bytes o más deberá admitir esta variante de 
comando para estos EF. Una tarjeta de tacógraf o puede o no admitir esta variante de comando para 
otros EF. 
TCS_65  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘00h’  
INS 1 ‘D7h’ Update Binar y 
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’ || Objeto de 
datos discrecional con etiqueta ‘53h’ que encapsula los datos 
que han de escr ibirse  
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 octet os, es decir , utilizando el byte de longitud ‘01h’ 
el IFD deberá codificar una desviación/longitud compr endida entre 0 y 255 y, mediante el byte de 
longitud ‘02h’ , una desviación/longitud compr endida entre ‘256’ y ‘65 535’ bytes. 
TCS_66  Mensaje de respuest a 
Byte Longitud Valor Descr ipción 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
—  Si el comando se ejecuta correctamente , la tarjeta contes ta con el estado ‘9000’. 
—  Si no se selecciona un EF, se contesta con el estado de procesado ‘6986’. 
—  Si no se satisf acen las condiciones de segur idad del archiv o seleccionado, se interr umpe el 
comando con ‘6982’. 
—  Si la desviación no es compatible con el tamaño del EF (desviación > tamaño del EF), se conte sta 
con el estado de procesado ‘6B00’. 
—  Si el tamaño de los datos que se han de escr ibir no es compat ible con el tamaño del EF 
(desviación + Lc > tamaño del EF), se contesta con el estado de procesado ‘6700’. 26.5.2016 L 139/198 Diar io Oficial de la Unión Europea ES    
—  Si se detecta un error de integridad dentro de los atribut os del archiv o, la tarjeta considerará el 
arch ivo dañado e irrecuperable, se contes ta con el estado de procesado ‘6400’ o ‘6500’. 
—  Si falla la escr itura, se cont esta con el estado de procesado ‘6581’. 
3.5.3.3.1  Comando con mensa jería segura (ejem plo) 
El siguient e ejemplo ilustra el uso de la mensaj ería segura si se aplica la condición de segur idad SM-MA C-G2. 
TCS_67  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘0Ch’ Se pide mensajería segura 
INS 1 ‘D7h’ Updat e Binar y 
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’ LPV: longitud de los datos transmitidos. 
L es 2 bytes si LPV > 127 bytes. 
#(7+L)-#(6+L+NN) NN ‘XX..XXh’ Datos planos codificados en BER -TLV, es decir , 
el objeto de datos de desviación con etiqueta 
‘54h’ || Objeto de datos discrecional con eti­
queta ‘53h’ que encapsula los datos que han de 
escr ibirse 
#(7+L+NN) 1 ‘8Eh’ TCC: Etiqueta para suma de control criptográfica 
#(8+L+NN) 1 ‘XXh’ LCC: Longitud de la siguient e suma de control 
criptográfica 
‘08h’ , ‘0Ch’ o ‘10h’ dependiendo de la longitud 
de la clave AES para mensaj ería segura de gene­
ració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áfi ca 
Le 1 ‘00h’ Según se especifica en la norma ISO/CEI 7816- 
4  
TCS_68  Mensaje de respuesta si el comando es correcto 
Byte Longitud Valor Descr ipción 
#1 1 ‘99h’ TSW: Etiqueta para palabras de estado (con la prot ección de CC) 
#2 1 ‘02h’ LSW: longitud de las palabras de estado devueltas 
#3-#4 2 ‘XXXXh’ Estado de procesado de la respuesta APDU sin proteg er 
#5 1 ‘8Eh’ TCC: Etiqueta para suma de control criptográfica 26.5.2016 L 139/199 Diar io Oficial de la Unión Europea ES    
Byte Longitud Valor Descr ipción 
#6 1 ‘XXh’ LCC: Longitud de la siguient e suma de control criptográfica 
‘08h’ , ‘0Ch’ o ‘10h’ dependiendo de la longitud de la clave AES 
para mensa jerí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áfi ca 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
3.5.4  GET CHALLENGE 
Este comando cumple con lo dispuest o en la norma ISO/CEI 7816-4, pero tiene un uso restr ingido en 
comparación con el comando que se define en dicha norma. 
El comando GET CHALLENGE pide a la tarjeta que envíe una interro gación para usarla en un procedimiento 
relacionado con la segur idad que incluya el envío de un criptograma o de unos datos cifrados a la tarjeta. 
TCS_69  La interro gación que envía la tarjeta tan solo es válida para el siguiente comando que utilice una 
interr ogación y se envíe a la tarjeta. 
TCS_70  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘00h’  
INS 1 ‘84h’ INS 
P1 1 ‘00h’ P1 
P2 1 ‘00h’ P2 
Le 1 ‘08h’ Le (Longitud de la interr ogación esperada)  
TCS_71  Mensaje de respuest a 
Byte Longitud Valor Descr ipción 
#1-#8 8 ‘XX..XXh’ Interr ogaci ón 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
—  Si el comando se ejecuta correctamente , la tarjeta contes ta con el estado ‘9000’. 
—  Si Le es distinto de ‘08h’ , el estado de procesado es ‘6700’. 
—  Si los parámetros P1-P2 son incor rectos, el estado de procesado es ‘6A86’. 
3.5.5  VERIFY 
Este comando cumple con lo dispuest o en la norma ISO/CEI 7816-4, pero tiene un uso restr ingido 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ógraf o pueden o no incor porar este comando, 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ógraf o que no sean tarjetas de taller , el 
compo rtamient o, es decir , el código de error devuelto, está fuera del alcance de esta especificación si se envía 
este comando. 26.5.2016 L 139/200 Diar io Oficial de la Unión Europea ES    
El comando VERIFY inicia una comparación en la tarjeta, confrontando los datos CHV (PIN) enviados desde 
el comando con la información CHV de referen cia almacenada en la tarjeta. 
TCS_72  El IFD debe añadir bytes ‘FFh’ para rellenar por la derecha el PIN que introduzca el usuar io y debe 
codif icarse en ASCI, hasta llegar a una longitud de 8 bytes; véase también el tipo de datos 
WorkshopCardPIN en el apéndice 1. 
TCS_73  Las aplicaciones de tacógraf o de generación 1 y 2 deberán utilizar la misma información CHV de 
referencia. 
TCS_74  La tarjeta de tacógraf o deberá comproba r si el comando está codificado correctamente. Si el 
comando no está codif icado correctamente, la tarjeta no comparará los valores CHV, no disminuirá 
el contador de intent os CHV restant es y no reiniciará el estado de segur idad «PIN_V erified», pero 
interr umpirá el comando. Un comando está codificado correctamente si los bytes CLA, INS, P1, P2, 
Lc tienen los valores especifi cados, Le está ausente y el campo de datos del comando tiene la 
longitud correcta. 
TCS_75  Si el comando es correcto, el contador de intent os CHV restant es se reinicializa. El valor inicial del 
contador de intent os CHV restantes es 5. Si el comando es correcto, la tarjeta establecerá el estado 
de segur idad interna «PIN_V erified». La tarjeta restablecerá este estado de segur idad si se restablece 
la tarjeta o si el código CHV transmitido en el comando no coincide con la información CHV de 
referencia almacenada. 
Nota: utilizar la misma información CHV de referen cia y un estado de segur idad global evita que un 
empleado del taller tenga que volver a introducir el PIN tras seleccionar otro DF de la aplicación de 
tacógraf o.  
TCS_76  En la tarjeta queda registrada cada comparación incor recta, es decir , el contador de intent os CHV 
restantes disminuye en uno, a fin de limitar el número de intent os que quedan para utilizar la 
información CHV de referencia. 
TCS_77  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘00h’  
INS 1 ‘20h’ INS 
P1 1 ‘00h’ P1 
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 respuest a 
Byte Longitud Valor Descr ipción 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
—  Si el comando se ejecuta correctamente , la tarjeta contes ta con el estado ‘9000’. 
—  Si no se encuentra la referen cia CHV , se conte sta con el estado de procesado ‘6A88’. 
—  Si la información CHV está bloqueada (el contador de intent os restant es de la CHV es cero), se 
conte sta con el estado de procesado ‘6983’. Una vez en ese estado, ya no se puede volver a 
presentar la información CHV . 
—  Si la compar ación no tiene éxito, se resta una unidad a la lectura del contador de intentos 
restant es y se devuelve el estado ‘63CX’ (X > 0 y X es igual al contador de intent os CHV 
restant es. 
—  Si se considera que la información CHV de referen cia está dañada, se conte sta con el estado de 
procesado ‘6400’ o ‘6581’. 
—  Si Lc es distint o de ‘08h’, el estado de procesado es ‘6700’. 26.5.2016 L 139/201 Diar io Oficial de la Unión Europea ES    
3.5.6  GET RESPONSE 
Este comando cumple con lo dispuesto en la norma ISO/CEI 7816-4. 
Este comando (exclusivament e necesar io 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 contrar io, los datos se pierden. Una vez ejecutado el comando GET RESPONSE (salv o si se produce el 
error ‘61xx’ o ‘6Cxx’, véase más abaj o), los datos preparados previamente dejan de estar disponibles. 
TCS_79  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘00h’  
INS 1 ‘C0h’  
P1 1 ‘00h’  
P2 1 ‘00h’  
Le 1 ‘XXh’ Número de bytes esperados  
TCS_80  Mensaje de respuest a 
Byte Longitud Valor Descr ipción 
#1-#X X ‘XX..XXh’ Datos 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
—  Si el comando se ejecuta correctamente , la tarjeta contes ta con el estado ‘9000’. 
—  Si la tarjeta no ha preparado ningún dato, se conte sta con el estado de procesado ‘6900’ o 
‘6F00’. 
—  Si la longitud Le sobrepasa el número de bytes disponibles 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 RESPONSE poste rior. 
—  Si la longitud Le es distinta de cero y menor que el número de bytes disponibles, la tarjeta 
normalment e envía los datos necesar ios y se cont esta con el estado de procesado ‘61xx’, donde 
‘xx’ indica el número de bytes extra toda vía disponibles para un comando GET RESPONSE 
posterior . 
—  Si el comando no se admite (protocolo T=1), la tarjeta contes ta con el estado ‘6D00’. 
3.5.7  PSO: VERIFY CER TIFICA TE 
Este comando cumple con lo dispuest o en la norma ISO/CEI 7816-8, pero tiene un uso restr ingido en 
comparación con el comando que se define en dicha norma. 
El comando VERIFY CERTI FICATE lo utiliza la tarjeta para obtener una clave pública del exterior y para 
comprobar su validez. 
3.5.7.1  Comando de generación 1 — Par de respuestas 
TCS_81  Esta variante de comando es compatible únicamente con una aplicación de tacógraf o de 
generación 1. 26.5.2016 L 139/202 Diar io Oficial de la Unión Europea ES    
TCS_82  Cuando un comando VERIFY CER TIFICA TE se ejecuta correctamente, la clave pública queda 
almacenada para su uso posterio r en el entorno de segur idad. Esta clave debe crearla de forma 
explícita el comando MSE utilizando su identificador de clave (véase § 3.5.11) para uso en 
comandos relacionados con la segur idad (INTERNAL AUTHENTICA TE, EXTERNAL 
AUTHENTICA TE o VERIFY CER TIFICA TE). 
TCS_83  En cualquier caso, el comando VERIFY CERTI FICATE 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 Descr ipción 
CLA 1 ‘00h’  
INS 1 ‘2Ah’ Realizar operación de segur idad 
P1 1 ‘00h’ P1 
P2 1 ‘AEh’ P2: datos sin codificación BER -TLV (concate nación de elementos 
de datos) 
Lc 1 ‘C2h’ Lc: Longitud del certificad o, 206 Bytes 
#6-#199 194 ‘XX..XXh’ Certificado : concate nación de elementos de datos (como se des­
cribe en el apéndice 11)  
TCS_85  Mensaje de respuest a 
Byte Longitud Valor Descr ipción 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
—  Si el comando se ejecuta correctamente , la tarjeta contes ta con el estado ‘9000’. 
—  Si la verificación del certificado falla, se cont esta con el estado de procesado ‘6688’. El proceso 
de verificación y aper tura del certificado se descr ibe en el apéndice 11 para G1 y G2. 
—  Si no hay una clave pública present e en el entorno de segur idad, se devuelve ‘6A88’ . 
—  Si se considera que la clave pública seleccionada (utilizada para desen volver el certificad o) está 
dañada, se contes ta con el estado de procesado ‘6400’ o ‘6581’. 
—  Generación 1 únicamente: Si la clave pública seleccionada (utilizada para desenv olver el 
certificado) tiene un CHA.LSB (
 ) 
diferente de ‘00’ (es decir , no es el de un Estado miembro o el de Europa), se cont esta con el 
estado de procesado ‘6985’. 
3.5.7.2  Comando de generación 2 — Par de respuestas 
Dependiendo del tamaño de la curva, los certificados ECC pueden ser tan largos que no es posible transmi ­
tirlos en un solo APDU. En este caso, debe aplicarse el encadenamient o de comandos según ISO/CEI 7816-4 
y el certificado debe transmitirse en dos PSO consecutivo s: APDU de Verify Certificate. 
La estructura del certificado y los parámetros de dominio se definen en el apéndice 11. 
TCS_86  El comando puede ejecutarse en el MF, DF tacógraf o y DF tacógraf o_G2; véase también TCS_33. 26.5.2016 L 139/203 Diar io Oficial de la Unión Europea ES    
TCS_87  Mensaje de comando 
Byte Longitud Valor Descr ipció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 segur idad 
P1 1 ‘00h’  
P2 1 ‘BEh’ Verificar certificado autode scriptiv o 
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 cuer po del 
certificado ECC como primer objeto de datos concatenado con el 
objeto de datos de la firma del certificado ECC como segundo 
objeto de datos o para de esta concate nación. La etiqueta ‘7F21’ 
y la correspondiente longitud no deberán transmitirse. 
El orden de estos objeto s de datos es fijo.  
TCS_88  Para APDU de longitud corta, se aplican las siguient es disposiciones: El IFD deberá utilizar el 
número mínimo de APDU necesar io para transmitir los datos útiles del comando y transmitir el 
máximo número de bytes en el primer comando APDU de acuerdo con el valor del tamaño del 
campo de información para la tarjeta; véase TCS_14TCS_14. Si el IFD se compo rta de forma 
diferent e, el compor tamiento de la tarjeta está fuera del alcance. 
TCS_89  Para APDU de longitud ampli ada, se aplican las siguientes disposiciones: si el certificado no encaja 
en un solo APDU, la tarjeta deberá admitir el encadenamient o de comandos. El IFD deberá utilizar 
el número mínimo de APDU necesar io para transmitir los datos útiles del comando y transmitir el 
máximo número de bytes en el primer comando APDU. Si el IFD se compo rta de forma diferent e, 
el compo rtamient o de la tarjeta está fuera del alcance. 
Nota: Según el apéndice 11, la tarjeta almacena el certificado o el contenido relevante del certificado 
y actualiza su currentA uthenticatedTime. 
La estructura del mensaje de respuesta y las palabras de estado son las que se definen en 
TCS_85TCS_85. 
TCS_90  Además de los códigos de error enumerados en TCS_85TCS_85, la tarjeta puede devolver los 
siguiente s códigos de error: 
—  Si la clave pública seleccionada (utilizada para desen volver el certificado) tiene un CHA.LSB 
(Cer tificateHolderAuthorisatio n.equipmentT ype) que no es apropiado para la verificación de 
certificados según el apéndice 11, se cont esta con el estado de procesado ‘6985’. 
—  Si el currentA uthenticatedTi me de la tarjeta es posterio r a la fecha de caducidad del certificado, 
se contes ta con el estado de procesado ‘6985’. 
—  Si se espera el último comando de la cadena, la tarjeta conte sta con el estado ‘6883’. 
—  Si se envían parámetros incor rectos en el campo de datos del comando, la tarjeta cont esta con 
el estado ‘6A80’ (utilizado también en caso de que los objeto s de datos no se enví en en el orden 
especificado). 
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ógraf o deberán admitir este comando en el DF tacógraf o de generación 1. El 
comando puede o no estar accesible en el MF y/o el DF tacógraf o_G2. Si es así, el comando deberá 
term inar con un código de error apropiado ya que la clave privada de la tarjeta (Card.SK) para el 
protocolo de autenticación de generación 1 solo es accesible en el DF_tacógraf o de generación 1. 26.5.2016 L 139/204 Diar io Oficial de la Unión Europea ES    
Por medio del comando INTERNAL AUTHENTICA TE, el IFD puede autenti ficar la tarjeta. El proceso de 
autenti cación se descr ibe en el apéndice 11. Incluye las declaraciones siguient es: 
TCS_92 El comando INTERNAL AUTHENTICA TE utiliza la clave privada de la tarjeta (seleccionada implíci ­
tamente) para firmar datos de autentificación, incluidos K1 (el primer elemento para acordar la 
clave de la sesión) y RND1, y utiliza la clave pública actualmente seleccionada (a través del último 
comando MSE) para cifrar la firma y formar el testigo de autenti ficación (hallará información más 
detallada al respecto en el apéndice 11). 
TCS_93  Mensaje de comando 
Byte Longitud Valor Descr ipció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 emplea da para autenti ficar la tarjeta 
#14 -#21 8 ‘XX..XXh’ VU.CH R (véase el apéndice 11) 
Le 1 ‘80h’ Longitud de los datos que se esperan de la tarjeta  
TCS_94  Mensaje de respuest a 
Byte Longitud Valor Descr ipció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 contes ta con el estado ‘9000’. 
—  Si no hay una clave pública presente en el entorno de segur idad, se cont esta con el estado de 
procesado ‘6A88’ . 
—  Si no hay una clave privada present e en el entorno de segur idad, se contesta con el estado de 
procesado ‘6A88’ . 
—  Si VU.CHR no coincide con el identif icador actual de clave pública, se cont esta con el estado de 
procesado ‘6A88’ . 
—  Si se considera que la clave privada seleccionada está dañada, se contes ta con el estado de 
procesado ‘6400’ o ‘6581’. 
TCS_95  Si el comando INTERNAL AUTHENTICA TE se ejecuta correctamente, la clave de la sesión actual, si 
la hay, se borra y deja de estar disponible. Para disponer de una nueva clave de sesión, es preciso 
que se ejecute correctamente el comando EXTERNAL AUTHENTICA TE para el mecanismo de 
autenticación de generación 1. 
3.5.9  EXTERNAL AUTHENTIC ATE 
Este comando cumple con lo dispuesto en la norma ISO/CEI 7816-4. 
Por medio del comando EXTERNAL AUTHENTICA TE, la tarjeta puede autenti ficar el IFD. En el apéndice 11 
se descr ibe el proceso de aute nticación del tacógraf o G1 y G2 (auten ticación de la VU). 26.5.2016 L 139/205 Diar io Oficial de la Unión Europea ES    
TCS_96  La variante del comando para el mecanismo de autenticación mutua de generación 1 es compati ble 
únicamente con una aplicación de tacógraf o de generación 1. 
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ógraf o y DF tacógraf o_G2; véase también TCS_34TCS_34. 
TCS_98  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘00h’ CLA 
INS 1 ‘82h’ INS 
P1 1 ‘00h’ Claves y algor itmos conocidos implícitament e 
P2 1 ‘00h’  
Lc 1 ‘XXh’ Lc (Longitud de los datos enviados a la tarjeta) 
#6-#(5+L) L ‘XX..XXh’ Auten ticación de generación 1: Criptograma (véase la parte A 
del apéndice 11) 
Auten ticación de generación 2: Firma generada por el IFD 
(véase la parte B del apéndice 11)  
TCS_99  Mensaje de respuest a 
Byte Longitud Valor Descr ipción 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
—  Si el comando se ejecuta correctamente , la tarjeta contes ta con el estado ‘9000’. 
—  Si el CHA de la clave pública actualmente configurada no es la concate nación del AID de la 
aplicación de tacógraf o y de un tipo de equipo VU, se cont esta con el estado de procesado 
‘6F00’. 
—  Si el comando no va precedido inmediatament e de un comando GET CHALLENGE, se contes ta 
con el estado de procesado ‘6985’. 
La aplicación de tacógraf o de generación 1 puede devolver los siguient es códigos de error 
adicionales: 
—  Si no hay una clave pública present e en el entorno de segur idad, se devuelve ‘6A88’ . 
—  Si no hay una clave privada present e en el entorno de segur idad, se contesta con el estado de 
procesado ‘6A88’ . 
—  Si la verificación del criptograma es incor recta, se contesta con el estado de procesado ‘6688’. 
—  Si se considera que la clave privada seleccionada está dañada, se contes ta con el estado de 
procesado ‘6400’ o ‘6581’. 
La variante del comando para la autenticación de generación 2 puede devolver el siguient e código 
de error adicional: 
—  Si falla la verificación de la firma, la tarjeta cont esta con el estado ‘6300’. 
3.5.10  GENERAL AUTHENTIC ATE 
Este comando sirve para el protocolo de autenti cació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ógraf o y DF tacógraf o_G2; véase también 
TCS_34TCS_34. 26.5.2016 L 139/206 Diar io Oficial de la Unión Europea ES    
TCS_101  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘00h’  
INS 1 ‘86h’  
P1 1 ‘00h’ Claves y protocolo conocidos im­
plícitamente 
P2 1 ‘00h’  
Lc 1 ‘NNh’ Lc: longitud del campo de datos 
subsiguient e 
#6-#(5+L) L ‘7Ch’ + L7C + ‘80h’ + L80 + ‘XX..XXh’ Valor de clave pública efímera codi ­
ficada con DER -TLV (véase el apén ­
dice 11) 
La VU deberá enviar los objeto s de 
datos en este orden.  
TCS_102  Mensaje de respuest a 
Byte Longitud Valor Descr ipción 
#1-#L L ‘7Ch’ + L7C + ‘81h’ + ‘08h’ 
+ ‘XX..XXh’ + ‘82h’ + L82 + 
‘XX..XXh’ Datos de autenticación dinámica codificados 
con DER -TLV: Testigo de autentificación especí ­
fico (véase el apéndice 11) 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
—  Si el comando se ejecuta correctamente, la tarjeta contesta con el estado ‘9000’. 
—  La tarjeta contesta con el estado ‘6A80’ para indicar parámetros incor rectos en el campo de 
datos. 
—  La tarjeta contesta con el estado ‘6982’ si el comando de autenticación extern a no se ha 
ejecutado correctamente. 
El objeto de datos de autenti cació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 inter valo ‘6400’ — ‘6FFF’ , 
y 
—  puede estar ausente en caso de que se produzca una adver tencia, es decir , si las palabras de 
estado se encuentran en el inter valo ‘6200’ — ‘63FF’. 
3.5.11  MANA GE SECURIT Y ENVIRONMENT 
Este comando se utiliza para deter minar una clave pública con fines de aute ntifi cación. 
3.5.11.1  Comando de generación 1 — Par de respuestas 
Este comando cumple con lo dispuest o en la norma ISO/CEI 7816-4. Este comando tiene un uso restr ingido 
en relación con dicha norma. 
TCS_103  Este comando es compati ble únicamente con una aplicación de tacógraf o 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 segur idad no 
exper imenta cambio alguno. 26.5.2016 L 139/207 Diar io Oficial de la Unión Europea ES    
TCS_106  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘00h’ CLA 
INS 1 ‘22h’ INS 
P1 1 ‘C1h’ P1: clave a que se hace referen cia, válida para todas las operacio ­
nes criptográficas 
P2 1 ‘B6h’ P2 (datos a que se hace referen cia, relativos a la firma digital) 
Lc 1 ‘0Ah’ Lc: longitud del campo de datos subsiguiente 
#6 1 ‘83h’ Etiqueta para hacer referen cia a una clave pública en casos asimé ­
tricos 
#7 1 ‘08h’ Longitud de la referencia de la clave (identificador de clave) 
#8-#15 8 ‘XX..XXh’ Identif icador de clave según se especifi ca en el apéndice 11  
TCS_107  Mensaje de respuest a 
Byte Longitud Valor Descr ipción 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
—  Si el comando se ejecuta correctamente, la tarjeta contesta con el estado ‘9000’. 
—  Si la clave a que se hace referencia no está present e en la tarjeta, se conte sta con el estado de 
procesado ‘6A88’ . 
—  Si en el format o de mensaj ería segura falta n algunos de los objeto s de datos que se esperaban, 
se devuelve el estado de procesado ‘6987’. Esto puede ocur rir si falta la etiqueta ‘83h’ . 
—  Si algunos objeto s de datos son incor rectos, se contesta con el estado de procesado ‘6988’. 
Esto puede ocur rir si la longitud del identif icador de clave no es ‘08h’ . 
—  Si se considera que la clave seleccionada está dañada, se cont esta con el estado de procesado 
‘6400’ o ‘6581’. 
3.5.11.2  Comando de generación 2 — Pares de respuestas 
En cuant o a la aute nticación de generación 2, la tarjeta de tacógraf o admite los siguient es MSE: Versiones de 
comando establecidas que cumplen la norma ISO/CEI 7816-4. Estas versiones de comando no son 
compati bles con la autenti cación de generación 1. 
3.5.11.2.1  MSE:SET AT para la autenticació n del chip 
El siguiente comando MSE:SET AT sirve para seleccionar los parámetros de autenti cación del chip que se 
realiza mediante un comando de autenticación general subsiguient e. 
TCS_108  El comando puede ejecutarse en el MF, DF tacógraf o y DF tacógraf o_G2; véase también 
TCS_34TCS_34. 
TCS_109  Mensaje del comando MSE:SET AT para la autenticación del chip 
Byte Longitud Valor Descr ipción 
CLA 1 ‘00h’  
INS 1 ‘22h’  26.5.2016 L 139/208 Diar io Oficial de la Unión Europea ES    
Byte Longitud Valor Descr ipción 
P1 1 ‘41h’ Establecido para autenticación interna 
P2 1 ‘A4h’ Autenticación 
Lc 1 ‘NNh’ Lc: longitud del campo de datos subsiguient e 
#6-#(5+L) L ‘80h’ + ‘0Ah’ + ‘XX..XXh’ Referencia del mecanismo criptográfico codifi ­
cado con DER -TLV: Identif icador de objeto s de 
autenti cación del chip (solo el valor , se omit e 
la etiqueta ‘06h’). 
Véase el apéndice 1 para conocer los valores 
de los identificadores de objeto s; se utilizará la 
notación en bytes. Véase el apéndice 11 para 
conocer las orientaciones sobre cómo seleccio ­
nar uno de estos identif icadores de objeto s.  
3.5.11.2.2  MSE:SET AT para la autenticació n de la VU 
El siguiente comando MSE:SET AT sirve para seleccionar los parámetros y las claves de autenti cación de la 
VU que se realiza mediante un comando de autenti cación externa subsiguient e. 
TCS_110  El comando puede ejecutarse en el MF, DF tacógraf o y DF tacógraf o_G2; véase también 
TCS_34TCS_34. 
TCS_111  Mensaje del comando MSE:SET AT para la autenticación de la VU 
Byte Longitud Valor Descr ipción 
CLA 1 ‘00h’  
INS 1 ‘22h’  
P1 1 ‘81h’ Establecido para autenticación exte rna 
P2 1 ‘A4h’ Autenticación 
Lc 1 ‘NNh’ Lc: longitud del campo de datos subsiguient e 
#6-#(5+L) L ‘80h’ + ‘0Ah’ + ‘XX..XXh’ Referencia del mecanismo criptográfico codifi ­
cado con DER -TLV: Identif icador de objeto s de 
autenti cación de la VU (solo el valor , se omit e 
la etiqueta ‘06h’). 
Véase el apéndice 1 para conocer los valores 
de los identificadores de objeto s; se utilizará la 
notación en bytes. Véase el apéndice 11 para 
conocer las orientaciones sobre cómo seleccio ­
nar uno de estos identif icadores de objeto s. 
‘83h’ + ‘08h’ + ‘XX..XXh’ Referencia codif icada con DER -TLV de la clave 
pública de la VU por medio de la referencia al 
titular del certificado citado en el present e cer­
tificado. 
‘91h’ + L91 + ‘XX..XXh’ Representación comprim ida 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  MSE:SET DST 
El siguient e 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 subsiguient e: el comando Verify Digital 
Signature, ya sea 26.5.2016 L 139/209 Diar io Oficial de la Unión Europea ES    
—  para la verificación de la firma de un certificado suministrado en un PSO subsiguient e: el comando Verify 
Certificate 
TCS_112  El comando puede ejecutarse en el MF, DF tacógraf o y DF tacógraf o_G2; véase también TCS_33. 
TCS_113  Mensaje del comando MSE:SET DST 
Byte Longitud Valor Descr ipción 
CLA 1 ‘00h’  
INS 1 ‘22h’  
P1 1 ‘81h’ Establecido para verificación 
P2 1 ‘B6h’ Firma digital 
Lc 1 ‘NNh’ Lc: longitud del campo de datos subsiguient e 
#6-#(5+L) L ‘83h’ + ‘08h’ + ‘XX...XXh’ Referencia codif icada 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 mensaj e de respuesta y las palabras de estado vienen 
dadas por: 
TCS_114  Mensaje de respuest a 
Byte Longitud Valor Descr ipción 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
—  Si el comando se ejecuta correctamente, la tarjeta contes ta con el estado ‘9000’. Se ha 
seleccionado e inicializado el protocolo . 
—  ‘6A80’ indica parámetros incor rectos 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. 
3.5.12  PSO: HASH 
Este comando sirve para transferi r a la tarjeta el resultado de un cálculo de comprobación aleat oria con unos 
datos deter minados. Este comando se utiliza para la verificació n de firmas digitales. El valor de 
comprobació n aleat oria se almacena temporalmente para el PSO del comando subsiguient e: Verify Digital 
Signature 
Este comando cumple con lo dispuest o en la norma ISO/CEI 7816-8. Este comando tiene un uso restr ingido 
en relación con dicha norma. 
Solo la tarjeta de control debe admitir este comando en el DF tacógraf o y el DF tacógraf o_G2. 
Otros tipos de tarjetas de tacógraf o pueden o no incor porar este comando. 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 aleat oria temporal deberá borrarse si se calcula un nuevo valor de 
comprobación aleat oria por medio del comando PSO: HASH si se selecciona un DF y si se reinicia 
la tarjeta del tacógraf o. 26.5.2016 L 139/210 Diar io Oficial de la Unión Europea ES    
TCS_116  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘00h’ CLA 
INS 1 ‘2Ah’ Realizar operación de segur idad 
P1 1 ‘90h’ Devolv er Hash code 
P2 1 ‘A0h’ Etiqueta: campo de datos contiene DO relevantes para com ­
probación aleatori a 
Lc 1 ‘XXh’ Longitud Lc del camp o de datos subsiguient e 
#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én ­
dice 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 respuest a 
Byte Longitud Valor Descr ipción 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
—  Si el comando se ejecuta correctamente, la tarjeta contesta con el estado ‘9000’. 
—  Si faltan algunos de los objeto s de datos que se esperaban (anter iormente especificados), se 
devuelve el estado de procesado ‘6987’. Esto puede ocur rir si falta una etiqueta ‘90h’ . 
—  Si algunos objeto s de datos son incor rectos, se contesta con el estado de procesado ‘6988’. 
Este error sucede si la etiqueta requer ida está present e, pero tiene una longitud 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 SECURIT Y OPERA TION/HASH. 
Solo la tarjeta del conduct or y la tarjeta de taller deben admitir este comando en el DF tacógraf o y el DF 
tacógraf o_G2. 
Otros tipos de tarjetas de tacógraf o pueden o no incor porar este comando. Si una tarjeta de empr esa o de 
control incor pora este comando, el comando deberá aplicarse del modo especifi cado en el present e apar tado. 
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 comprobació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 aleatori a en la zona 
de datos del EF transparent e actualmente seleccionado. 
TCS_119  Una tarjeta de tacógraf o deberá admitir este comando solo para los EF que se relacionan en el 
apar tado 44 dentro del apar tado del DF_tacógraf o y del DF_tacógraf o_G2 con la siguient e 
excepción. Una tarjeta de tacógraf o no deberá admitir el comando para el EF Sensor_Installa ­
tion_Data del DF tacógraf o_G2. 26.5.2016 L 139/211 Diar io Oficial de la Unión Europea ES    
TCS_120  El resultado de la operación de comprobación aleatori a se almacena temporalmente en la tarjeta. 
Posterior mente , puede utilizarse para obtener una firma digital del archiv o por medio del PSO: el 
comando COMPUTE DIGIT AL SIGNA TURE. 
TCS_121  El valor de compr obación aleat oria del arch ivo temporalment e almacenado deberá borrarse si se 
calcula un nuevo valor de comproba ción aleat oria del archiv o por medio del PSO: El comando 
«Hash of File», si se selecciona un DF y si se reinicia la tarjeta del tacógraf o. 
TCS_122  La aplicación del tacógraf o de generación 1 deberá admitir SHA-1. 
TCS_123  La aplicación del tacógraf o de generación 2 deberá admitir SHA-1 y SHA-2 (256, 384 y 512 bits). 
TCS_124  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘80h’ CLA 
INS 1 ‘2Ah’ Realizar operación de segur idad 
P1 1 ‘90h’ Etiqueta: Hash 
P2 1 ‘XXh’ P2: Indica el algor itmo que debe utilizarse para la compr obación aleato ­
ria de los datos del arch ivo transparente seleccionado actualmente: 
‘00h’ para SHA-1 
‘01h’ para SHA-256 
‘02h’ para SHA-384 
‘03h’ para SHA-512  
TCS_125  Mensaje de respuest a 
Byte Longitud Valor Descr ipción 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
—  Si el comando se ejecuta correctamente, la tarjeta contesta con el estado ‘9000’. 
—  Si el EF actual no admite este comando (EF Sensor_Installation_Data en DF tacógraf o_G2), se 
contes ta con el estado de procesado ‘6985’. 
—  Si se considera que el EF seleccionado está dañado (errores de integr idad en los atribut os del 
archiv o o los datos almacenados), se contes ta con el estado de procesado ‘6400’ o ‘6581’. 
—  Si el archiv o seleccionado no es un arch ivo o si no existen ningún EF actual, se conte sta con el 
estado de procesado ‘6986’. 
3.5.14  PSO: COMPUTE DIGIT AL SIGNATURE 
Este comando sirve para calcular la firma digital de un código de comprobación aleatori a calculado 
previamente (véase PERFORM HASH of FILE, §3.5.133.5.13). 
Solo la tarjeta del conduct or y la tarjeta de taller deben admitir este comando en el DF tacógraf o y el DF 
tacógraf o_G2. 
Otros tipos de tarjetas de tacógraf o pueden o no incor porar este comando, pero no tendrán una clave de 
firma. 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. En caso afirmativo, el comando deberá term inar con un 
código de error adecuado. 26.5.2016 L 139/212 Diar io Oficial de la Unión Europea ES    
Este comando cumple con lo dispuest o en la norma ISO/CEI 7816-8. Este comando tiene un uso restr ingido 
en relación con dicha norma. 
TCS_126  Este comando no deberá calcular una firma digital del código de comprobació n aleatori a calculado 
anter iormente con el comando PSO: HASH. 
TCS_127  La tarjeta conoce implícitament e su clave privada, que se utiliza para calcular la firma digital. 
TCS_128  La aplicación del tacógraf o de generación 1 realiza una firma digital utilizando un métod o de 
relleno conf orme a la norma PKCS1 (véanse los detalles en el apéndice 11). 
TCS_129  La aplicación del tacógraf o de generación 2 calcula una firma digital basada en una curva elípt ica 
(véanse los detalles en el apéndice 11). 
TCS_130  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘00h’ CLA 
INS 1 ‘2Ah’ Realizar operación de segur idad 
P1 1 ‘9Eh’ Firma digital que se ha de devol ver 
P2 1 ‘9Ah’ Etiqueta: el campo de datos contiene los datos que se han de firmar . 
Como se incluy e ningún campo de datos, se supone que los datos ya es­
tán present es en la tarjeta (com probación aleatoria del archiv o) 
Le 1 ‘NNh’ Longitud de la firma esperada  
TCS_131  Mensaje de respuest a 
Byte Longitud Valor Descr ipción 
#1-#L L ‘XX..XXh’ Firma de la comprobació n aleatori a calculada previamente 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
—  Si el comando se ejecuta correctamente, la tarjeta contesta con el estado ‘9000’. 
—  Si se considera que la clave privada seleccionada implícitamente está dañada, se contesta con el 
estado de procesado ‘6400’ o ‘6581’. 
—  Si el valor de compr obación aleatori a 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 DIGIT AL SIGNATURE 
Este comando sirve para verificar la firma digital, suministrada como entrada, cuya comprobació n aleatori a 
conoce la tarjeta. La tarjeta conoce implícitament e el algor itmo de la firma. 
Este comando cumple con lo dispuest o en la norma ISO/CEI 7816-8. Este comando tiene un uso restr ingido 
en relación con dicha norma. 
Solo la tarjeta de control debe admitir este comando en el DF tacógraf o y el DF tacógraf o_G2. 
Otros tipos de tarjetas de tacógraf o pueden o no incor porar este comando. El comando puede o no estar 
accesible en el MF. 
TCS_132  El comando VERIFY DIGIT AL SIGNA TURE siempr e utiliza la clave pública seleccionada por el 
Manage Secur ity Environment (MSE) anterior: el comando Set DST y el código de comprobació n 
aleatori a anterior introducido por un comando PSO: HASH. 26.5.2016 L 139/213 Diar io Oficial de la Unión Europea ES    
TCS_133  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘00h’ CLA 
INS 1 ‘2Ah’ Realizar operación de segur idad 
P1 1 ‘00h’  
P2 1 ‘A8h’ Etiqueta: el campo de datos contiene DO relevantes para verifi­
cación 
Lc 1 ‘83h’ Longitud Lc del camp o de datos subsiguient e 
6 1 ‘9Eh’ Etiqueta para firma digital 
#7-#8 2 ‘81 XXh’ Longitud de la firma digital: 
128 bytes codif icados conf orme a la parte A del apéndice 11 
para una aplicación de tacógraf o de generación 1 
Dependiendo de la curva seleccionada para la aplicación de ta­
cógraf o de generación 2 (véase la parte B del apéndice 11) 
#9-#(8+L) L ‘XX..XXh’ Conteni do de la firma digital  
TCS_134  Mensaje de respuest a 
Byte Longitud Valor Descr ipción 
SW 2 ‘XXXXh’ Palabras de estado (SW1,SW2)  
—  Si el comando se ejecuta correctamente, la tarjeta contesta con el estado ‘9000’. 
—  Si la verificación de la firma falla, se cont esta con el estado de procesado ‘6688’. El proceso de 
verificación se descr ibe en el apéndice 11. 
—  Si no se selecciona una clave pública, se cont esta con el estado de procesado ‘6A88’. 
—  Si faltan algunos de los objeto s de datos que se esperaban (anter iormente especificados), se 
devuelve el estado de procesado ‘6987’. Esto puede ocur rir si falta una de las etiquetas 
necesar ias. 
—  Si no hay disponible un código de compr obación aleatori a para procesar el comando (como 
resultado de un comando anterior PSO: comando HASH), se conte sta con el estado de 
procesado ‘6985’. 
—  Si algunos objeto s de datos son incor rectos, se contesta con el estado de procesado ‘6988’. 
Esto puede ocur rir si la longitud de uno de los objetos de datos necesar ios es incor recta. 
—  Si se considera que la clave pública seleccionada está dañada, se conte sta con el estado de 
procesado ‘6400’ o ‘6581’. 
3.5.16  PROCE SS DSRC MESSA GE 
Este comando sirve para verificar la integrid ad y aute nticidad del mensaj e DSR C y para descifrar los datos 
transmitidos desde una VU a una autor idad de control o a un centro de ensa yo a través del enlace DSR C. La 
tarjeta obtiene la clave de cifrado y la clave MAC utilizada para asegurar el mensaj e DSR C del modo descr ito 
en el apar tado 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ógraf o_G2. 
Otros tipos de tarjetas de tacógraf o pueden o no incor porar este comando, pero no tendrán una clave 
maestra DSR C. Por tanto , estas tarjetas no pueden ejecutar el comando correctamente, pero term inan con un 
código de error adecuado. 26.5.2016 L 139/214 Diar io Oficial de la Unión Europea ES    
El comando puede o no estar accesible en el MF y/o el DF tacógraf o. En caso afirmativo, el comando deberá 
term inar con un código de error adecuado. 
TCS_135  La clave maestra DSR C es accesible únicamente en el DT tacógraf o_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ógraf o_G2. 
TCS_136  El comando deberá descifrar solamente los datos DSR C y verificar la suma de control criptográfi ca, 
pero sin interpr etar los datos de entrada. 
TCS_137  El orden de los objeto s de datos en el campo de datos del comando queda fijado por la present e 
especifi cación. 
TCS_138  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 ‘80h’ CLA propio 
INS 1 ‘2Ah’ Realizar operación de segur idad 
P1 1 ‘80h’ Datos de respuesta: valor plano 
P2 1 ‘B0h’ Datos del comando: valor plano codif icado en 
BER -TLV e incluy e SM DO 
Lc 1 ‘NNh’ Longitud Lc del campo de datos subsiguient e 
#6-#(5+L) L ‘87h’ + L87 + ‘XX..XXh’ Byte indicador del conte nido de relleno codifi ­
cado con DET -TLV seguido de los datos útiles ci­
frados del tacógraf o. Se utilizará el valor ‘00h’ 
(‘ninguna otra indicación’ según la tabla 52 de la 
norma ISO/CIE 7816-4:2013) para el byte indi ­
cador del contenido de relleno. Véase el apar tado 
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 L87 son 
múltiplos de la longitud del bloque AES más 1 
para el byte indicador del contenido de relleno, 
es decir , desde 17 bytes hasta 193 bytes inclu ­
sive. 
Nota: Véase la tabla 49 de la norma ISO/CIE 
7816-4:2013 para más información sobre el ob­
jeto de datos SM con etiqueta ‘87h’. 
‘81h’ + ‘10h’ Plantilla de la referencia de control para confi ­
dencialidad codificada con DER -TLV que anida la 
concatenación de los elementos de datos siguien ­
tes (véase el apéndice 1 DSR CSecur ityData y el 
apar tado 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 DSR C de 1 byte 
Nota: Véase la tabla 49 de la norma ISO/CIE 
7816-4:2013 para más información sobre el ob­
jeto de datos SM con etiqueta ‘81h’. 
‘8Eh’ + L8E + ‘XX..XXh’ MAC codificad a con DER -TLV a través del men ­
saje DSR C. Véase el apar tado 13 de la parte B del 
apéndice 11 para obtener más información sobre 
el algor itmo 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 ob­
jeto de datos SM con etiqueta ‘8Eh’.  26.5.2016 L 139/215 Diar io Oficial de la Unión Europea ES    
TCS_139  Mensaje de respuest a 
Byte Longitud Valor Descr ipción 
#1-#L L ‘XX..XXh’ Aus ente (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 contesta con el estado ‘9000’. 
—  ‘6A80’ indica parámetros incor rectos en el campo de datos del comando (también se utiliza en 
caso de que los objeto s de datos no se envíen en el orden especificado). 
—  ‘6A88’ indica que los datos a que se hace referencia, es decir , la clave maestra DSR C 
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. 
4.  ESTR UCTURA DE LAS TARJET AS DE TACÓGRAFO 
El present e apar tado especifica las estructuras de archiv os de las tarjetas de tacógraf o para el almacenamiento 
de datos accesibles. 
No se especifican las estructuras intern as que dependen del fabr icante de la tarjeta, como por ejemplo 
las cabeceras de archivos, ni el almacenamiento y la manipulación de elementos de datos necesar ios 
para uso interno excl usivamente , como
 ,
 ,
o
 . 
TCS_140  Una tarjeta de tacógraf o de generación 2 deberá incor porar el archiv o maestro MF y una 
aplicación de tacógraf o de generación 1 y de generación 2 del mismo tipo (por ejemplo, 
aplicaciones de tarjeta del conductor). 
TCS_141  Una tarjeta de tacógraf o deberá admitir al menos el número mínimo de registros especificados 
para las aplicaciones correspondientes y no admitirá más registros que el número máximo de 
registros especificados para las aplicaciones correspondientes. 
Los números máximo y mínimo de registros se especifican en este apar tado para las distintas 
aplicaciones. 
En cuanto a las condiciones de segur idad utilizadas en las normas de acceso a lo largo de este 
apar tado, véase el apar tado 3.33.3. En general, el modo de acceso de «lectura» denota el comando 
READ BINAR Y con byte INS par y, si se admite, impar a excepci ón del EF Sensor_Installation_Data 
en la tarjeta de taller; véase TCS_156TCS_156 y TCS_160TCS_160. El modo de acceso de «actuali ­
zación» denota el comando Update Binar y con byte INS par y, si se admit e, impar y el modo de 
acceso de «selección», el comando SELECT . 
4.1.  Archiv o maestro MF 
TCS_142  Una vez personalizado el arch ivo maestro MF, tendrá la siguient e estructura permanente de 
archiv o y las normas de acceso al arch ivo: 
Nota: .El identif icador EF corto SFID se da como número decimal, por ejemplo, el valor 30 se 
corresponde con 11110 en binar io. 
26.5.2016 L 139/216 Diar io Oficial de la Unión Europea ES    
En esta tabla se utiliza la siguient e abreviación para la condición de segur idad: 
SC1  ALW OR SM-MA C-G2 
TCS_143  La estructura de todos los EF deberá ser transparent e. 
TCS_144  El archiv o principal (MF) deberá tener la siguient e estructura de datos: 
TCS_145  El archiv o elemental EF DIR deberá contener los siguiente s objeto s 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 arch ivo elemental EF ATR/INFO deberá estar presente si la tarjeta de tacógraf o indica en su ATR 
que admite campos de longitud amp liada. En este caso, el EF ATR/INFO llevará el objeto de datos 
con información de longitud ampliada (DO‘7F66’) tal como se especifi ca en la cláusula 12.7.1 de 
la norma ISO/CIE 7816-4:2013. 
TCS_147  El archiv o elemental EF Exte nded_Length deberá estar present e si la tarjeta de tacógraf o indica en 
su ATR que admite campos de longitud ampliada. En este caso, el EF contendrá el siguient e objeto 
de datos: ‘02 01 xx’, donde el valor ‘xx’ indica si se admiten campos de longitud exte ndida para el 
protocolo T = 1 y/o T = 0. 
El valor ‘01’ indica compatib ilidad con el camp o de longitud extendida para el prot ocolo T = 1. 
El valor ‘10’ indica compatib ilidad con el camp o de longitud extendida para el prot ocolo T = 0. 
El valor ‘11’ indica compati bilidad con el campo de longitud extendida para el prot ocolo 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 gener ación 1 
TCS_148  Una vez personalizada, la aplicación de la tarjeta de conductor de generación 1 tendrá la siguiente 
estructura permanent e de archiv os y las normas de acceso a los archiv os: 26.5.2016 L 139/217 Diar io Oficial de la Unión Europea ES    
En esta tabla se utilizan las siguiente s abreviaciones para las condiciones de segur idad: 
SC1  ALW OR SM-MA C-G2 
SC2  ALW OR SM-MA C-G1 OR SM-MA C-G2 
SC3  SM-MA C-G1 OR SM-MA C-G2 
TCS_149  La estructura de todos los EF deberá ser transparent e. 
TCS_150  La aplicación de generación 1 de la tarjeta de conductor deberá tener la siguient e estructura de 
datos:   26.5.2016 L 139/218 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/219 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/220 Diar io Oficial de la Unión Europea ES    
TCS_151  Los valores siguientes, empleado s 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 conduct or debe utilizar para una 
aplicación de generación 1: 
4.2.2  Aplicación de la tarjeta de conductor de gener ación 2 
TCS_152  Una vez personalizada, la aplicación de la tarjeta de conductor de generación 2 tendrá la siguiente 
estructura permanent e de archiv os y las normas de acceso a los archiv os. 
Nota: .El identif icador EF corto SFID se da como número decimal, por ejemplo, el valor 30 se 
corresponde con 11110 en binar io. 
En esta tabla se utiliza la siguient e abreviación para la condición de segur idad: 
SC1  ALW OR SM-MA C-G2 
TCS_153  La estructura de todos los EF deberá ser transparent e. 
TCS_154  La aplicación de generación 2 de la tarjeta de conductor deberá tener la siguient e estructura de 
datos:   26.5.2016 L 139/221 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/222 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/223 Diar io Oficial de la Unión Europea ES    
TCS_155  Los valores siguientes, empleado s 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 conduct or 
debe utilizar para una aplicación de generación 2: 
4.3.  Aplicaciones de la tarjeta de taller 
4.3.1  Aplicación de la tarjeta del centr o de ensayo de gener ación 1 
TCS_156  Una vez personalizada, la aplicación de la tarjeta de taller de generación 1 tendrá la siguiente 
estructura permanent e de archiv os y las normas de acceso a los archiv os:  26.5.2016 L 139/224 Diar io Oficial de la Unión Europea ES    
En esta tabla se utilizan las siguiente s abreviaciones para las condiciones de segur idad: 
SC1  ALW OR SM-MA C-G2 
SC2  ALW OR SM-MA C-G1 OR SM-MA C-G2 
SC3  SM-MA C-G1 OR SM-MA C-G2 
SC4  Para el comando READ BINAR Y con byte INS par: 
(PLAIN-C AND SM-R -ENC-G1) O (SM-C-MA C-G1 Y SM-R -ENC-MA C-G1) O 
(SM-C-MA C-G2 Y SM-R -ENC-MA C-G2) 
Para el comando READ BINAR Y con byte INS impar (si se admite): NEV 
TCS_157  La estructura de todos los EF deberá ser transparent e. 
TCS_158  La aplicación de la tarjeta de taller de generación 1 deberá tener la siguiente estructura de datos:   26.5.2016 L 139/225 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/226 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/227 Diar io Oficial de la Unión Europea ES    
TCS_159  Los valores siguientes, empleado s 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 
TCS_160  Una vez personalizada, la aplicación de la tarjeta de taller de generación 2 tendrá la siguiente 
estructura permanent e de archiv os y las normas de acceso a los archiv os. 
Nota: .El identif icador EF corto SFID se da como número decimal, por ejemplo, el valor 30 se 
corresponde con 11110 en binar io.  26.5.2016 L 139/228 Diar io Oficial de la Unión Europea ES    
En esta tabla se utilizan las siguiente s abreviaciones para las condiciones de segur idad: 
SC1  ALW OR SM-MA C-G2 
SC5  Para el comando Read Binar y con byte INS par: SM-C-MA C-G2 Y SM-R -ENC-MA C-G2 
Para el comando Read Binar y con byte INS impar (si se admite ): NEV 
TCS_161  La estructura de todos los EF deberá ser transparent e. 
TCS_162  La aplicación de la tarjeta de taller de generación 2 deberá tener la siguiente estructura de datos:   26.5.2016 L 139/229 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/230 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/231 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/232 Diar io Oficial de la Unión Europea ES    
TCS_163  Los valores siguientes, empleado s 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: 
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 siguient e 
estructura permanent e de archiv os y las normas de acceso a los archiv os: 
En esta tabla se utilizan las siguiente s abreviaciones para las condiciones de segur idad: 
SC1  ALW OR SM-MA C-G2 
SC2  ALW OR SM-MA C-G1 OR SM-MA C-G2 
SC3  SM-MA C-G1 OR SM-MA C-G2 
SC6  EXT -AUT-G1 O SM-MA C-G1 O SM-MA C-G2 
TCS_165  La estructura de todos los EF deberá ser transparent e. 
TCS_166  La aplicación de la tarjeta de control de generación 1 deberá tener la siguiente estructura de datos:   26.5.2016 L 139/233 Diar io Oficial de la Unión Europea ES    
TCS_167  Los valores siguientes, empleado s 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 
TCS_168  Una vez personalizada, la aplicación de la tarjeta de control de generación 2 tendrá la siguient e 
estructura permanent e de archiv os y las normas de acceso a los archiv os: 
Nota: .El identif icador EF corto SFID se da como número decimal, por ejemplo, el valor 30 se 
corresponde con 11110 en binar io. 26.5.2016 L 139/234 Diar io Oficial de la Unión Europea ES    
En esta tabla se utiliza la siguient e abreviación para la condición de segur idad: 
SC1  ALW OR SM-MA C-G2 
TCS_169  La estructura de todos los EF deberá ser transparent e. 
TCS_170  La aplicación de la tarjeta de control de generación 2 deberá tener la siguiente estructura de datos:   26.5.2016 L 139/235 Diar io Oficial de la Unión Europea ES    
TCS_171  Los valores siguientes, empleado s 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: 
4.5.  Aplicaciones de la tarjeta de empresa 
4.5.1  Aplicación de la tarjeta de empres a de gener ación 1 
TCS_172  Una vez personalizada, la aplicación de la tarjeta de emp resa de generación 1 tendrá la siguiente 
estructura permanent e de archiv os y las normas de acceso a los archiv os: 26.5.2016 L 139/236 Diar io Oficial de la Unión Europea ES    
En esta tabla se utilizan las siguiente s abreviaciones para las condiciones de segur idad: 
SC1  ALW OR SM-MA C-G2 
SC2  ALW OR SM-MA C-G1 OR SM-MA C-G2 
SC3  SM-MA C-G1 OR SM-MA C-G2 
SC6  EXT -AUT-G1 O SM-MA C-G1 O SM-MA C-G2 
TCS_173  La estructura de todos los EF deberá ser transparent e. 
TCS_174  La aplicación de la tarjeta de empresa de generación 1 deberá tener la siguient e estructura de 
datos: 
26.5.2016 L 139/237 Diar io Oficial de la Unión Europea ES    
TCS_175  Los valores siguientes, empleado s 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 empres a de gener ación 2 
TCS_176  Una vez personalizada, la aplicación de la tarjeta de emp resa de generación 2 tendrá la siguiente 
estructura permanent e de archiv os y las normas de acceso a los archiv os. 
Nota: .El identif icador EF corto SFID se da como número decimal, por ejemplo, el valor 30 se 
corresponde con 11110 en binar io. 
En esta tabla se utiliza la siguient e abreviación para la condición de segur idad: 
SC1  ALW OR SM-MA C-G2 
TCS_177  La estructura de todos los EF deberá ser transparent e. 
TCS_178  La aplicación de la tarjeta de empresa de generación 2 deberá tener la siguient e estructura de 
datos:   26.5.2016 L 139/238 Diar io Oficial de la Unión Europea ES    
TCS_179  Los valores siguientes, empleado s 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: 
26.5.2016 L 139/239 Diar io Oficial de la Unión Europea ES    
Apéndice 3 
PICTOGRAMAS 
PIC_001  El tacógraf o podrá utilizar , de forma opcional, los siguientes pictogramas y combinaciones de pictogramas 
(o pictogramas y combinaciones lo suficientement e parecidas para identif icarse con estas de forma inequív oca):  
1. PICTOGRAMAS BÁSIC OS  
Personas Acciones Modos de funcionamient o 
Empresa  Modo de empr esa 
Controlador Control Modo de control 
Conductor Conducción Modo operativo 
Taller/centro de ensa yo Inspección/calibrado Modo de calibrado 
Fabr icante     
Actividades Duración 
Disponible Período de disponibilidad ac­
tual 
Conducción Tiempo de conducción conti ­
nua 
Descanso Período de descanso actual 
Otro traba jo Período de trabajo actual 
Pausa Tiempo de pausa acumulado 
Indeter minado    
Equipo Funciones 
Ranura del conductor  
Ranura del segundo conduc ­
tor  
Tarjeta  
Reloj  
Pantalla Visualización 
Almacenamiento extern o Transf erencia 
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    
Condiciones específ icas 
Fuera de ámbito 
Trayecto en transbordador/tren  26.5.2016 L 139/240 Diar io Oficial de la Unión Europea ES    
Varios   
Incidentes 
 Fallos 
Comienzo del período de traba jo dia­
rio 
Final del período de trabajo diar io 
Lugar   
Entrada manual de las actividades del 
conductor   
Segur idad   
Velocidad   
Hora   
Total/resumen     
Calif icadores 
24h Diar io 
Semanal 
Bisemanal 
Desde o hasta   
2. COMBINA CIONES DE PICTOGRAMAS  
Varios   
Lugar de control   
Lugar donde comienza el período de 
trabajo diar io 
Lugar donde termina el período de tra­
bajo diar io 
Hora de comienzo 
 Hora de conclusión 
Desde el vehículo   
Comienzo condición Fuera de ámbito 
 Final condición Fuera de ámbito   
Tarjetas 
Tarjeta de conduct or 
Tarjeta de empr esa 
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 diar ia de las actividades del conduct or almacenadas en la tarjeta 
Impresión diar ia de las actividades del conduct or almacenadas en la VU 
Impresión de incident es y fallos almacenados en la tarjeta 
Impresión de incident es y fallos almacenados en la VU 
Impresión de datos técnicos 
Impresión de excesos de velocidad  26.5.2016 L 139/241 Diar io Oficial de la Unión Europea ES    
Incidentes 
Inserción de una tarjeta no válida 
Conf licto 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 
Interr upción del suministro eléctr ico 
Error en datos de movimiento 
Conf licto de movimiento del vehículo 
Violación de la segur idad 
Ajuste de la hora (por el taller) 
Control del exceso de velocidad   
Fallos 
Fallo de tarjeta (ranura del conductor) 
Fallo de tarjeta (ranura del segundo conductor) 
Fallo de la pantalla 
Fallo de transfer encia 
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 diar io? 
¿Final del anterior período de trabajo? 
Confi rme o introduzca el lugar donde term ina el período de traba jo 
Introduzca la hora de comienzo 
Introduzca el lugar donde comienza el período de traba jo  
Nota: En el apéndice 4 se definen otras combinaciones de pictograma s que representan bloques de impresión o 
identificad ores de registro.   26.5.2016 L 139/242 Diar io Oficial de la Unión Europea ES    
Apéndice 4 
DOCUMENTOS IMPRESOS 
ÍNDICE 
1. GENERALID ADES ............................................................................................................................... 243 
2. ESPECIFIC ACIÓN DE LOS BLOQUES DE DATOS ........................................................................................ 243 
3. ESPECIFIC ACIONES DE LOS DOCUMENTOS IMPRESOS .............................................................................. 250 
3.1. Impresión diar ia de las actividades del conduct or almacenadas en la tarjeta ......................................... 250 
3.2. Impresión diar ia de las actividades del conduct or almacenadas en la VU ............................................. 251 
3.3. Impresión de incident es y fallos almacenados en la tarjeta ............................................................... 252 
3.4. Impresión de incident es y fallos almacenados en la VU ................................................................... 252 
3.5. Impresión de datos técn icos ...................................................................................................... 253 
3.6. Impresión de excesos de velocidad ............................................................................................. 253 
3.7. Histori al de tarjetas inser tadas ................................................................................................... 254  
1.  GENERALID ADES 
Cada documento impreso es una concat enación de varios bloques de datos, posiblemente identif icados con un 
identificador de bloque. 
Un bloque de datos contiene uno o más registros, posiblemente identificados con un identificador de registro. 
PRT_001 Cuando un identificador de bloque precede inmediatament e a un identif icador de registro, el identi ­
ficador de registro no se impr ime. 
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 conte nido de una línea entera es desconocido o no tiene que impr imirse, se omit e toda la línea. 
PRT_004  Los campos de datos numér icos 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. 
PRT_005  Los campos de datos en cadena se imprimen alineados a la izquierda. Cuando es preciso (en nombres y 
direcciones), se rellenan con espacios hasta alcanzar la longitud de la unidad de información, o bien se 
truncan para no sobrepasar dicha longitud. 
PRT_006  Cuando haya que dividir una línea cuyo texto sea largo, debe imprimirse un carácte r especial (un punto 
a media altura de la línea, «•») como primer carácter en la línea nueva. 
2.  ESPECIFICA CIÓN DE LOS BLOQUES DE DATOS 
En este capítulo se han utilizado las siguientes convencione s para la notación de formatos: 
—  los caracteres impresos en neg rita indican texto legible que hay que impr imir (en caracteres normales), 
—  los caracteres normales indican variables (pictogramas o datos) que hay que sustituir por sus valores antes de 
proceder a la imp resió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 especifi can con el formato «dd/mm/aaaa» (día, mes, año). También se puede utilizar el formato 
«dd.mm.aaaa», 
—  el térm ino «identif icación de la tarjeta» indica la compo sición de: el tipo de tarjeta (mediant e una combinación 
de pictograma s), el código del Estado miembro que ha expedido la tarjeta, un carácte r de barra oblicua y el 
número de tarjeta con el índice de sustitución y el índice de reno vación separados por espacios: 
P 
 x x x / x x x x x x x x x x x x x x  x  x Combinaciones 
de pictogramas 
de tarjeta 
Código del 
Estado miembro 
emisor  Primeros 14 caracter es del número de tarjeta 
(incluido posiblemente un índice consecutivo)  
Índice de 
sustitución  
Índice de 
renovación  26.5.2016 L 139/243 Diar io Oficial de la Unión Europea ES    
PRT_007 Los document os impresos deberán utilizar los siguiente s bloques de datos y/o registros de datos, con arreglo a 
los significados y formatos que se exponen a continuación: 
26.5.2016 L 139/244 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/245 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/246 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/247 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/248 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/249 Diar io Oficial de la Unión Europea ES    
3.  ESPECIFICA CIONES DE LOS DOCUMENTOS IMPRESOS 
En este capítulo se han empleado las siguiente s conven ciones 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 necesar io  
X/Y Imprimir bloques o registros X o Y según proceda, y repetidos tantas veces como sea 
necesar io.  
3.1.  Impresión diar ia de las actividades del conductor almacenadas en la tarjeta 
PRT_008 La imp resión diar ia de las actividades del conductor almacenadas en la tarjeta deberá efectuarse con 
arreglo al format o siguiente : 
1 Fecha y hora en la que se impr ime el documento 
2 Tipo de documento impreso 
3 Identif icación del controlador (si se inser ta una tarjeta de control en la VU) 
3 Identif icación del conductor (según la tarjeta cuyos datos se impr imen + GEN) 
4 Identif icación del vehículo (vehículo del que se obtiene el documento impreso) 
5 Identif icación de la VU (VU cuya impresión se obtiene + GEN) 
6 Último calibrado de la VU actual 
7 Último control pasado por el conduct or sometido a la inspección 
8 Delimitador de las actividades del conduct or 
8a Condición «Fuera de ámbito» al comienzo de este día 
8.1a / 8.1b / 8.1c / 8.2 / 
8.3 / 8.3a / 8.4 Actividades del conduct or por orden de ocur rencia 
11 Delimitador del resumen diar io 26.5.2016 L 139/250 Diar io Oficial de la Unión Europea ES    
11.4 Lugares introducidos en orden cronológico 
11.5 Datos GNSS 
11.6 Totalidad de actividades 
12.1 Delimitador de incident es o fallos almacenados en la tarjeta 
12.4 Registro de incident es/fallos (últimos 5 incident es o fallos almacenados en la tarjeta) 
13.1 Delimitador de incident es o fallos almacenados en la VU 
13.4 Registro de incidentes/f allos (últimos 5 incident es o fallos almacenados o en curso en 
la VU) 
22.1 Lugar de control 
22.2 Firma del controlador 
22.5 Firma del conductor  
3.2.  Impresión diar ia de las actividades del conductor almacenadas en la VU 
PRT_009 La impresión diar ia de las actividades del conductor almacenadas en la VU deberá efectuarse con 
arreglo al format o siguiente : 
1 Fecha y hora en la que se impr ime el documento 
2 Tipo de documento impreso 
3 Identif icación del titular de la tarjeta (para todas las tarjetas inser tadas en la VU + 
GEN) 
4 Identif icación del vehículo (vehículo del que se obtiene el documento impreso) 
5 Identif icación de la VU (VU cuya impresión se obtiene + GEN) 
6 Último calibrado de esta VU 
7 Último control realizado en este tacógraf o 
9 Delimitador de las actividades del conduct or 
10 Delimitador de la ranura del conductor (ranura 1) 
10a Condición «Fuera de ámbito» al comienzo de este día 
10.1 / 10.2 / 10.3 
/10.3a / 10.4 Actividades en orden cronológico (ranura del conduct or) 
10 Delimitador de la ranura del segundo conductor (ranura 2) 
10a Condición «Fuera de ámbito» al comienzo de este día 
10.1 / 10.2 / 10.3 
/10.3a / 10.4 Actividades en orden cronológico (ranura del segundo conduct or) 
11 Delimitador del resumen diar io 
11.1 Sínte sis de los inter valos sin tarjeta en la ranura del conductor 
11.4 Lugares introducidos en orden cronológico 
11.5 Datos GNSS 
11.6 Totalidad de actividades 
11.2 Resumen de los inter valos sin tarjeta en la ranura del segundo conductor 
11.4 Lugares introducidos en orden cronológico 
11.5 Datos GNSS 26.5.2016 L 139/251 Diar io Oficial de la Unión Europea ES    
11.7 Totalidad de actividades 
11.3 Resumen de actividades por el conductor , incluidas ambas ranuras  
11.4  Lugares introducidos por este conduct or en orden cronológico 
11.5 Datos GNSS 
11.8 Totalidad de actividades relativas al conduct or actual 
13.1 Delimitador de incident es/fallos 
12.4 Registro de incidentes/f allos (últimos 5 incident es o fallos almacenados o en curso en 
la VU) 
13.1 Lugar de control 
22.2 Firma del controlador 
22.3 Hora de co­
mienzo (espacio reser vado a un conduct or sin una tarjeta para indicar qué 
períodos le atañen o corresponden) 
22.4 Hora de finali ­
zación 
22.5 Firma del conductor  
3.3.  Impresión de incidentes y fallos almacenados en la tarjeta 
PRT_010 La impresión de incident es y fallos almacenados en la tarjeta deberá efectuarse con arreglo al formato 
siguiente: 
1 Fecha y hora en la que se impr ime el documento 
2 Tipo de documento impreso 
3 Identif icación del controlador (si se inser ta una tarjeta de control en la VU + GEN) 
3 Identif icación del conductor (según la tarjeta cuyos datos se impr imen) 
4 Identif icación del vehículo (vehículo del que se obtiene el documento impreso) 
12.2 Delimitador de incident es 
12.4 Registros de incident es (todos los incident es almacenados en la tarjeta) 
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 impr ime el documento 
2 Tipo de documento impreso 
3 Identif icación del titular de la tarjeta (para todas las tarjetas inser tadas en la VU + 
GEN) 
4 Identif icación del vehículo (vehículo del que se obtiene el documento impreso) 26.5.2016 L 139/252 Diar io Oficial de la Unión Europea ES    
13.2 Delimitador de incident es 
13.4 Registros de incident es (todos los incident es 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  
3.5.  Impresión de datos técnicos 
PRT_012 La impresión de datos técnicos deberá efectuarse con arreglo al format o siguiente : 
1 Fecha y hora en la que se impr ime el documento 
2 Tipo de documento impreso 
3 Identif icación del titular de la tarjeta (para todas las tarjetas inser tadas en la VU + 
GEN) 
4 Identif icación del vehículo (vehículo del que se obtiene el documento impreso) 
14 Identif icación de la VU 
15 Identif icación del sensor 
15.1 Datos de emparej amiento del sensor (todos los datos existen tes en orden cronológico) 
16 Identif icación de GNSS 
16.1 Datos de acoplamiento del dispositivo GNSS externo (todos los datos existent es en or­
den cronológico) 
17 Delimitador de los datos de calibrado 
17.1 Registros de calibrado (todos los registros disponibles en orden cronológico) 
18 Delimitador del ajust e de hora 
18.1 Registros de ajuste de hora (todos los registros disponibles acerca del ajust e de hora y 
de los registros de los datos de calibrado) 
19 El incident e y el fallo más recientes registrados en la VU  
3.6.  Impresión de excesos de velocidad 
PRT_013 La impresión por exce so de velocidad deberá efectuarse con arreglo al formato siguiente: 
1 Fecha y hora en la que se impr ime el documento 
2 Tipo de documento impreso 
3 Identif icación del titular de la tarjeta (para todas las tarjetas inser tadas en la VU + 
GEN) 
4 Identif icación del vehículo (vehículo del que se obtiene el documento impreso) 
20 Información sobre el control del exceso de velocidad 
21.1 Identif icador de los datos sobre el exceso de velocidad 
21.4/21.5 Primer exce so de velocidad después del último calibrado 26.5.2016 L 139/253 Diar io Oficial de la Unión Europea ES    
21.2 Identif icador de los datos sobre el exceso de velocidad 
21.4/21.5 Los 5 incident es más grav es de exceso de velocidad ocur ridos en los últimos 365 días 
21.3 Identif icador 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 ocur rido incident es de este tipo 
22.1 Lugar de control 
22.2 Firma del controlador 
22.5 Firma del conductor  
3.7.  Histor ial de tarjetas inser tadas 
PRT_014 La impresión del histo rial de tarjetas inser tadas deberá efectuarse con arreglo al formato siguient e: 
1 Fecha y hora en la que se impr ime el documento 
2 Tipo de documento impreso 
3 Identif icaciones del titular de la tarjeta (para todas las tarjetas inser tadas en la VU) 
23 La tarjeta más reciente introducida en la VU 
23.1 Las tarjetas introducidas (hasta 88 registros) 
12.3 Delimitador de fallos   26.5.2016 L 139/254 Diar io Oficial de la Unión Europea ES    
Apéndice 5 
VISU ALIZA CIÓN 
En este apéndice se utilizan las siguient es conven ciones para la notación de formatos: 
—  los caracteres impresos en neg rita indican texto legible en la visualización (la visualización aparece en caracteres 
normales), 
—los caracte res normales indican variables (pictogramas o datos) que hay que sustituir por sus valores en la visuali ­
zación:  
— dd mm aaaa:  día, mes, año,  
— hh:  horas,  
— mm:  minutos,  
— D:  pictogram a de duración,  
— EF:  combinación de pictogramas de incident e o fallo,  
— O:  pictogram a de modo de funcionamient o. 
DIS_001  En la visualización, el aparat o de control deberá utilizar los formatos siguiente s: 
Datos Format o 
Visualización por defect o 
Hora local 
Modo de funcionamient o 
Información relativa al conduct or 
Información relativa al segundo conduct or 
Condición fuera de ámbito abier ta 
Visualización de aler ta 
Superación del tiempo de conducción continua 
Incident e o fallo 
Otras visualizaciones 
Fecha UTC 
Hora 
Tiem po de conducción continua y tiempo de descanso acumulado del conduc ­
tor 
Tiem po de conducción continua y tiempo de descanso acumulado del segundo 
conduct or 
Tiem po de conducción acumulado del conductor durante la semana anterior y 
la actual 
Tiem po de conducción acumulado del segundo conduct or durant e la semana 
anterior y la actual 
26.5.2016 L 139/255 Diar io Oficial de la Unión Europea ES    
Apéndice 6 
CONECTOR FRONT AL PARA EL CALIBRADO Y LA TRANSFERENCIA DE DATOS 
ÍNDICE 
1. EQUIPO INFORMÁ TICO ......................................................................................................................... 256 
1.1. Conector ................................................................................................................................ 256 
1.2. Asignación de contact os............................................................................................................ 257 
1.3. Diagrama de conjunt o............................................................................................................... 258 
2. INTERF AZ DE TRANSFERENCIA .............................................................................................................. 258 
3. INTERF AZ DE CALIBRADO .................................................................................................................... 259   
1.  EQUIPO INFORMÁ TICO 
1.1.  Conect or 
INT_001  El conector de transfer encia/calibrado deberá tener 6 patillas y ser accesible en el panel frontal sin 
necesidad de desconectar ninguno de los element os del tacógraf o, y sus dimensiones se ajus tarán al 
siguiente esquema (dimensiones en milímetros): 
26.5.2016 L 139/256 Diar io Oficial de la Unión Europea ES    
La siguiente ilustración muestra una clavija de acoplamiento típica de 6 patillas: 
1.2.  Asignación de cont actos 
INT_002  Los contactos se asignarán de acuerdo con la tabla siguiente: 
Patilla Descr ipción Obser vaciones 
1 Polo negativ o batería Conectado al polo negativ o de la bate ría del vehículo 
2 Comunicación de datos Línea K (ISO 14230-1) 26.5.2016 L 139/257 Diar io Oficial de la Unión Europea ES    
Patilla Descr ipción Obser vaciones 
3 Transf erencia RxD Entrada de datos en el tacógraf o 
4 Señal de entrada/salida Calibrado 
5 Salida permanente de potencia Se especifi ca que el inter valo de tensiones debe ser el de la 
pote ncia del vehículo menos 3 V para tener en cuenta la 
caída de tensión en los circuitos de prote cción. 
Salida 40 mA 
6 Transf erencia RxD Salida de datos del tacógraf o   
1.3.  Diag rama de conjunt o 
INT_003  El diagrama de conjunt o será el siguient e: 
2.  INTERF AZ DE TRANSFERENCIA 
INT_004  La interfaz de transfer encia deberá cumplir las especificaciones RS232. 
INT_005  La interfaz de transfer encia 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 dato s 
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 26.5.2016 L 139/258 Diar io Oficial de la Unión Europea ES    
Cuando se transmitan datos numér icos compues tos de más de un byte, el byte más signif icativ o se transmitirá el 
primero, y el byte menos significativo 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 velocidad más alta posible; la velocidad inicial en baudios al comenzar la 
comunicación se fija en 9 600 bps. 
3.  INTERF AZ DE CALI BRADO 
INT_007  La comunicación de datos deberá cumpli r lo dispuest o en la norma ISO 14230-1 Vehículos de carretera 
— Sistemas de diagnóstico — Protocol o Keyword 2000 — Parte 1: Nivel físico, Primera edición: 1999. 
INT_008  La señal de entrada/salida deberá cumplir las siguient es especificaciones eléctr icas: 
Parámetro Mínimo Típico Máximo Obser vaciones 
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 siguiente s diagramas de relaciones de tiempo: 
26.5.2016 L 139/259 Diar io Oficial de la Unión Europea ES    
Apéndice 7 
PROTOCOL OS DE TRANSFERENCIA DE DATOS 
ÍNDICE 
1. INTR ODUCCIÓN ............................................................................................................................ 261 
1.1. Ámbit o de aplicación .......................................................................................................... 261 
1.2. Acrónimos y notaciones ...................................................................................................... 261 
2. TRANSFERENCIA DE LOS DATOS DE LA VU ........................................................................................ 262 
2.1. Procedimient o de transfer encia .............................................................................................. 262 
2.2. Prot ocolo de transfer encia de datos ........................................................................................ 262 
2.2.1 Estructura del mensaj e......................................................................................................... 262 
2.2.2 Tipos de mensaj es.............................................................................................................. 264 
2.2.2.1 Star t Communication Request (petición de inicio de comunicación) (SId 81) ................................... 266 
2.2.2.2 Positive Response Star t Communication (respuesta positiva a la petición de inicio de comunicación) 
(SId C1) ........................................................................................................................... 266 
2.2.2.3 Star t Diagnostic Session Request (petición de inicio de la sesión de diagnóstico) (SId 10) .................... 266 
2.2.2.4 Positive Response Star t Diagnostic (respuesta positiva a la petición de inicio de diagnóstico) (SId 50) .... 266 
2.2.2.5 Link Control Service (servicio de control del enlace) (SId 87) ....................................................... 266 
2.2.2.6 Link Control Positive Response (respuesta positiva al control del enlace) (SId C7) ............................. 266 
2.2.2.7 Request Upload (envío de petición) (SId 35) ............................................................................. 266 
2.2.2.8 Positive Response Request Upload (respuesta positiva al envío de petición) (SId 75) .......................... 266 
2.2.2.9 Transf er Data Request (petición de transfer encia de datos) (SId 36) ................................................ 266 
2.2.2.10 Positive Response Transfer Data (respuesta positiva a la petición de transferencia de datos) (SId 76) ...... 267 
2.2.2.11 Request Transfer Exit (petición de salida de la transfer encia) (SId 37) .............................................. 267 
2.2.2.12 Positive Response Request Transf er Exit (respuesta positiva a la petición de salida de la transfe rencia) 
(SId 77) ............................................................................................................................ 267 
2.2.2.13 Stop Communication Request (petición de interrupción de la comunicación) (SId 82) ....................... 267 
2.2.2.14 Positive Response Stop Communication (respuesta positiva a la petición de interr upción de la comuni ­
cación) (SId C2) ................................................................................................................. 267 
2.2.2.15 Ackno wledge Sub Message (confi rmación de submensaje) (SId 83) ................................................ 267 
2.2.2.16 Neg ative Response (respuesta negativ a) (SId 7F)......................................................................... 268 
2.2.3 Flujo del mensaje ............................................................................................................... 268 
2.2.4 Sincronización ................................................................................................................... 269 
2.2.5 Gestión de errores .............................................................................................................. 270 
2.2.5.1 Fase de inicio de la comunicación .......................................................................................... 270 
2.2.5.2 Fase de comunicación ......................................................................................................... 270 
2.2.6 Conte nido del mensaj e de respuesta ....................................................................................... 272 
2.2.6.1 Respuesta positiva a la petición de transfe rencia de datos «resumen» .............................................. 273 
2.2.6.2 Respuesta positiva a la petición de transfe rencia de datos sobre actividades ..................................... 274 
2.2.6.3 Respuesta positiva a la petición de transfe rencia de datos sobre incident es y fallos ............................ 275 
2.2.6.4 Respuesta positiva a la petición de transfe rencia de datos pormenor izados sobre la velocidad .............. 276 
2.2.6.5 Respuesta positiva a la petición de transfe rencia de datos técn icos ................................................. 276 
2.3. Almacenamiento de un arch ivo en un ESM .............................................................................. 277 26.5.2016 L 139/260 Diar io Oficial de la Unión Europea ES    
3. PROTOCOL O DE TRANSFERENCIA DE LOS DATOS ALMA CENADOS EN TARJET AS DE TACÓGRAFO ............... 277 
3.1. Ámbit o de aplicación .......................................................................................................... 277 
3.2. Definiciones ...................................................................................................................... 277 
3.3. Transf erencia de los datos de la tarjeta .................................................................................... 277 
3.3.1 Secuencia de inicialización ................................................................................................... 278 
3.3.2 Secuencia para arch ivos de datos no firmados ........................................................................... 278 
3.3.3 Secuencia para arch ivos de datos firmados ............................................................................... 279 
3.3.4 Secuencia para reiniciar el contador del calibrado ...................................................................... 279 
3.4. Formato de almacenamient o de datos ..................................................................................... 280 
3.4.1 Introducción ..................................................................................................................... 280 
3.4.2 Formato de archivo ............................................................................................................ 280 
4. TRANSFERENCIA DE LOS DATOS DE UNA TARJET A DE TACÓGRAFO A TRA VÉS DE UNA UNID AD INST ALADA 
EN EL VEHÍCULO. ........................................................................................................................... 281  
1.  INTR ODUCCIÓN 
En el presente apéndice se especifi can los procedimiento s que se deben utilizar para llevar a cabo los 
diferentes tipos de transfer encia de datos a un medio de almacenamiento externo (ESM), así como los 
protocolo s que es preciso aplicar para garantizar la corrección de dichas transfer encias y la total compati ­
bilidad del formato de los datos transferidos, a fin de que un controlador cualquiera pueda inspeccionar 
dichos datos y compr obar su autenticidad e integridad antes de analizarlos. 
1.1.  Ámbito de aplicación 
Se pueden transferi r datos a un ESM: 
—  desde una unidad instalada en el vehículo (VU), mediante un equipo dedicado intelig ente (IDE) conectado 
a la VU; 
—  desde una tarjeta de tacógraf o, mediante un IDE que incor pore un dispositivo de interfaz de tarjeta (IFD); 
y 
—  desde una tarjeta de tacógraf o y a través de una unidad instalada en el vehículo, mediante un IDE 
conectado a la VU. 
Para poder verificar la aute nticidad y la integridad de los datos transfe ridos que se encuentran almacenados 
en un ESM, dichos datos se transf ieren con una firma añadida según lo dispuesto en el apéndice 11 
(Mecanismos de segur idad comunes). También se transfieren la identif icación del equipo de origen (VU o 
tarjeta) y sus certificados de segur idad (Estado miembro y equipamiento). La persona encarg ada de verificar 
los datos debe estar en posesión de una clave pública europea de confianza. 
DDP_001  Los datos transferidos durante una sesión de transferencia deben almacenarse en el ESM en un 
solo arch ivo. 
1.2.  Acrón imos y notaciones 
En el present e apéndice se utilizan los siguient es acrónimos: 
AID  Identif icador 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 almacenamient o externo 
FID  Identif icador de archiv o (ID de archiv o) 
FMT  Byte de formato (primer byte de la cabecera del mensaje) 
ICC  Tarjeta de circuit o integrado 
IDE  Equipo dedicado intelig ente: equipo empleado para realizar la transferencia de datos al ESM (por 
ejemplo un ordenador personal) 
IFD  Dispositivo de interfaz 26.5.2016 L 139/261 Diar io Oficial de la Unión Europea ES    
KWP  Protocol o Keyword 2000 
LEN  Byte de longitud (el último byte de la cabecera del mensaj e) 
PPS  Selección de los parámetros de prot ocolo 
PSO  Realizar operación de segur idad 
SID  Identif icador de servicio 
SRC  Byte de origen 
TGT  Byte de destino 
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 transfe rencia 
VU  Unidad instalada en el vehículo 
2.  TRANSFERENCIA DE LOS DATOS DE LA VU 
2.1.  Procedimiento de transfer encia 
A fin de realizar una transfe rencia de los datos de la VU, el operar io debe efectuar las siguient es operaciones: 
—  introducir su tarjeta de tacógraf o 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 transfe rir y envi ar la petición a la VU; y 
—  cerrar la sesión de transfe rencia. 
2.2.  Protoc olo de transferencia de datos 
El protocolo presenta una estructura maestro-esclav o, de modo que el IDE actúa como maestro y la VU 
como esclav o. 
La estructura, los tipos y el flujo de los mensaj es se basan principalmente en el protocolo Keyword 2000 
(KWP) (ISO 14230-2: Vehículos de carretera — Sistem as de diagnóstico — Protocolo Keyw ord 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 — Siste mas de diagnóstico — Parte 1: Servicios de diagnóstico, versión 6 de 22 de febrero de 
2001). 
2.2.1  Estructur a del mensaje 
DDP_002  El formato de todos los mensaj es que inter cambian 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 compues to por un byte identif icador 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 consistent e en un byte de suma de control (CS). 
Cabecera Campo de datos Suma de control 
FMT TGT SRC LEN SId DAT­
OS … … … CS 
4 bytes Máx. 255 bytes 1 byte  26.5.2016 L 139/262 Diar io Oficial de la Unión Europea ES    
(*)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. 
Los bytes TGT y SRC representan la dirección física del destinatar io y del emisor del mensaj e. 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. 
El byte de suma de control es la suma de todos los bytes del mensaj e tomad os de 8 bits en 8 bits, 
en módulo 256, excl uido 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 correspondiente al campo de datos, el mensaj e se enví a dividido en varios submensa jes. 
Cada submensaje incor pora una cabecera, los mismos SId y TREP y un contador de dos bytes que 
indica el número de submensa je dentro del mensaj e total. Al objeto de permitir la verificación de 
errores y la cancelación, el IDE conf irma cada uno de los submensa jes. El IDE puede aceptar el 
submensaje, solicitar su retransmisión, pedir a la VU que comience de nuevo o cancelar la 
transmisión. 
DDP_004  Si el último submensa je contiene exactament e 255 bytes en el campo de datos, habrá que añadir 
un submensaje final con un campo de datos vacío (exceptuando los identificad ores SId y TREP y 
el contador de submensaje) para indicar el final del mensaj e. 
Ejemplo: 
Cabecera SId TREP Mensaje CS 
4 bytes Más de 255 bytes   
Se transmitirá como: 
Cabecera SId TREP 00 01 Submensa je 1 CS 
4 bytes 255 bytes   
Cabecera SId TREP 00 02 Submensa je 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 Submensa je 1 CS 
4 bytes 255 bytes   
Cabecera SId TREP 00 02 Submensa je 2 CS 
4 bytes 255 bytes   26.5.2016 L 139/263 Diar io Oficial de la Unión Europea ES    
… 
Cabecera SId TREP xx yy Submensaje n CS 
4 bytes 255 bytes   
Cabecera SId TREP xx yy + 1 CS 
4 bytes 4 bytes   
2.2.2  Tipos de mensajes 
El prot ocolo de comunicación para la transfe rencia de datos entre la VU y el IDE exige el intercambio de 
ocho tipos de mensaj es diferentes. 
La siguient e tabla resume dichos mensaj es. 
Estructura del mensaje Máx. 4 bytes 
Cabecera Máx. 255 bytes 
Dato s 1 byte 
Suma de 
control 
IDE -> <- VU FMT TGT SRC LEN SId DS_/TRTP DATOS CS 
Petici ón de inicio de comunica ­
ció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 
diagnó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 bau­
dios (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 bau­
dios 80 F0 EE 02 C7  01 28 
Velocidad de baudios de transi ­
ción (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, 
FF,FF 99 
Respuesta positiva al envío de 
petición 80 F0 EE 03 75  00,FF D5 26.5.2016 L 139/264 Diar io Oficial de la Unión Europea ES    
Estructura del mensaje Máx. 4 bytes 
Cabecera Máx. 255 bytes 
Dato s 1 byte 
Suma de 
control 
IDE -> <- VU FMT TGT SRC LEN SId DS_/TRTP DATOS CS 
Petici ón de transferencia de dato s  
Visión general 80 EE F0 02 36 01  97 
Actividades 80 EE F0 06 36 02 Fecha CS 
Incident es y fallos 80 EE F0 02 36 03  99 
Datos pormenor izados sobre 
la velocidad 80 EE F0 02 36 04  9A 
Datos técnicos 80 EE F0 02 36 05  9B 
Transfer encia de los dato s de 
la tarjeta 80 EE F0 02 36 06 Ran ura CS 
Respuesta positiva a la petición 
de transfer encia de dato s 80 F0 EE Len 76 TREP Datos CS 
Petici ón de salida de la transfe ­
rencia 80 EE F0 01 37   96 
Respuesta positiva a la petición 
de salida de la transfer encia 80 F0 EE 01 77   D6 
Petici ón de interr upción de la co­
municación 80 EE F0 01 82   E1 
Respuesta positiva a la petición 
de interr upción de la comunica ­
ción 80 F0 EE 01 C2   21 
Confir mación de submensaj e 80 EE F0 Len 83  Datos CS 
Respuestas nega tivas  
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 inco ­
rrecta 80 F0 EE 03 7F Sid pet. 13 CS 
Condiciones incor rectas 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 acep tado 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érm ino envío (entendido desde el IDE) se utiliza para compatibilidad con la norma ISO 14229. 
Significa lo mismo que transferencia (entend ida desde la VU). 
—  Los posibles contadores de submensa je 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 
conduct or) o 2 (tarjeta de la ranura del copiloto) . 
—  En caso de que no se especifi que la ranura, la VU seleccionará la ranura 1 si la tarjeta se inser ta en esta 
ranura y solamente seleccionará 2 si así lo selecciona específi camente el usuar io. 26.5.2016 L 139/265 Diar io Oficial de la Unión Europea ES    
2.2.2.1  Star t Communication Request (petición de inicio de comunicación) (SId 81) 
DDP_005 El IDE enví a este mensaj e para establecer el enlace de comunicación con la VU. Las comunica ­
ciones 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  Positive Response Star t Communication (respuesta positiva a la petición de inicio de 
comunicación) (SId C1) 
DDP_006  La VU envía este mensaj e 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 admit e un protocolo con una 
cabecera que incluya información sobre el destino, el origen y la longitud del mensaj e. 
2.2.2.3  Star t Diagnostic Session Request (petición de inicio de la sesión de diagnóstico) (SId 10) 
DDP_007  El IDE envía el mensaj e de petición de inicio de la sesión de diagnóstico para solicitar una nueva 
sesión de diagnóstico con la VU. La subfunción «sesión por defect o» (default session) (81 Hex) 
indica que va a abrirse una sesión de diagnóstico estándar . 
2.2.2.4  Positive Response Star t Diagnostic (respuesta positiva a la petición de inicio de 
diagnóstico) (SId 50) 
DDP_008  La VU envía el mensaj e 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  Link Control Ser vice (ser vicio de control del enlace) (SId 87) 
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 velocidad. Al recibir un mensaj e positiv o de la VU, el 
IDE envía a la VU una conf irmació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 conf irmación la VU, 
cambia a la nueva velocidad en baudios. 
2.2.2.6  Link Control Positive Response (respuesta positiva al control del enlace) (SId C7) 
DDP_053  La VU envía la respuesta positiva al control del enlace para contes tar positivamente a la petición 
de servicio del control del enlace (etapa 1). Téngase en cuenta que no se da respuesta a la solicitud 
de conf irmación (etapa 2). 
2.2.2.7  Request Upload (envío de petición) (SId 35) 
DDP_009  El IDE emite el mensaj e de envío de petición para especificar a la VU que se solicita una operación 
de transfer encia. Para cumplir los requisit os de la norma ISO 14229, se incluyen 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 transfer encia, la dirección de la memor ia se conf igura a 0, el format o está descifrado y descom ­
primido y el tamaño de la memor ia se fija en el máximo. 
2.2.2.8  Positive Response Request Upload (respuesta positiva al envío de petición) (SId 75) 
DDP_010  La VU envía el mensaj e de respuesta positiva al envío de petición para indicar al IDE que la VU 
está preparada para transferir datos. Para cumplir los requisit os de la norma ISO 14229, en este 
mensaj e de respuesta positiva se incluyen datos, indicando al IDE que los ulteriores mensajes de 
respuesta positiva a la transferencia de datos incluirán un máximo de 00FF hex bytes. 
2.2.2.9  Transfer Data Request (petición de transfe rencia de dat os) (SId 36) 
DDP_011  El IDE envía la petición de transfe rencia de datos para especificar a la VU el tipo de datos que se 
van a transferi r. Un parámetro de petición de transferencia (TRTP) de un byte indica el tipo de 
transfer encia. 
Exist en seis tipos de transferencias de datos : 
—  resumen (TRTP 01); 
—  actividades de una fecha específica (TRTP 02); 
—  incident es y fallos (TRTP 03); 26.5.2016 L 139/266 Diar io Oficial de la Unión Europea ES    
—  datos pormenor izados sobre la velocidad (TRTP 04); 
—  datos técn icos (TRTP 05); y 
—  transfe rencia de datos de la tarjeta (TRTP 06). 
DDP_054  Es oblig atori o que el IDE solicite la transfer encia de datos resumen (TRTP 01) durant e una sesión 
de transfe rencia, ya que solo así se asegura que los certificad os de la VU se registran en el archiv o 
transferido (y se permite la verificación de la firma digital). 
En el segundo caso (TRTP 02), el mensa je de petición de transfer encia de datos incluye la 
indicación del día natural (en format o 
 ) cuyos datos se van a transferi r. 
2.2.2.10  Positive Response Transfer Data (respuesta positiva a la petición de transferenci a de dat os) 
(SId 76) 
DDP_012  La VU envía la respuesta positiva a la petición de transferencia de datos como conte stación a la 
petición de transferencia de datos. Este mensaj e contiene los datos solicitados, junto con un 
parámetro de respuesta a la solicitud de transferencia (TREP) correspondiente al TRTP de la 
petición. 
DDP055  En el primer caso (TREP 01), la VU envía datos que ayudan al operar io del IDE a seleccionar los 
datos que quiere transferi r. La información conte nida en este mensaj e es la siguient e: 
—  certificados de segur idad; 
—  identificación del vehículo; 
—  fecha y hora actuales de la VU; 
—  fecha máxima y mínima transfe rible (datos de la VU); 
—  indicación de presencia de tarjetas en la VU; 
—  transfe rencia previa a una empr esa; 
—  bloqueos introducidos por empr esas; e 
—  inspecciones anteriores. 
2.2.2.11  Request Transfer Exit (petición de salida de la transfe rencia) (SId 37) 
DDP_013  El IDE envía el mensaj e de petición de salida de la transferencia para informar a la VU de que la 
sesión de transferencia ha terminado. 
2.2.2.12  Positive Response Request Transfer Exit (respuesta positiva a la petición de salida de la 
transfe rencia) (SId 77) 
DDP_014  La VU envía el mensaj e de respuesta positiva a la petición de salida de la transfer encia para 
conf irmar la petición de salida de la transfer encia. 
2.2.2.13  Stop Communication Request (petición de inter rupción de la comunicación) (SId 82) 
DDP_015  El IDE envía el mensa je de petición de interr upción de la comunicación para desconectar el enlace 
de comunicación con la VU. 
2.2.2.14  Positive Response Stop Communication (respuesta positiva a la petición de interrupción 
de la comunicación) (SId C2) 
DDP_016  La VU envía el mensaj e de respuesta positiva a la petición de interrupción de la comunicación 
para conf irmar la petición de interr upción de la comunicación. 
2.2.2.15  Ackno wledg e Sub Message (confir mación de submensaj e) (SId 83) 
DDP_017  El IDE envía el mensaje de conf irmación de submensa je para conf irmar la recepción de cada una 
de las partes de un mensaj e 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 
siguient e: 
—  MsgC +1 conf irma 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 submensaje número MsgC. 
El IDE solicita a la VU que vuelva a enviar el submensa je. 26.5.2016 L 139/267 Diar io Oficial de la Unión Europea ES    
—  FFFF solicita la terminación del mensaje. 
El IDE puede utilizar este código para term inar la transmisión del mensaje de la VU por el 
motiv o que fuera. 
El último submensaje de un mensaj e (byte LEN < 255) se puede conf irmar con cualquiera de estos 
códigos, o bien puede dejarse sin conf irmar . 
Respuestas de la VU que se compo nen de varios submensajes: 
—  Positive Response Transf er Data (respuesta positiva a la petición de transfer encia de datos) 
(SId 76) 
2.2.2.16  Neg ative Response (respuesta negativa) (SId 7F) 
DDP_018  La VU envía el mensaje de respuesta negativa como cont estación a los mensaj es de petición 
anteriores cuando no puede satisf acer la petición de que se trate. Los camp os de datos del mensaj e 
incluye n 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. 
—  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 submensa jes que 
transmitir . 
—  13: longitud del mensaj e incor recta 
La longitud del mensaj e es incor recta. 
—  22: condiciones incor rectas o error en la secuencia de la petición 
El servicio requer ido no está activo o la secuencia de mensaj es de petición es incor recta. 
—  31: solicitud no admisible 
El registro del parámetro de la solicitud (campo de datos) no es válido. 
—  50: envío no aceptad o 
No se puede llevar a cabo la petición (la VU se encuentra 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 acept ar 
otra petición. 
—  FA: datos no disponibles 
El objeto de datos de una petición de transferencia de datos no está disponible en la VU (por 
ejem plo, no se ha introducido una tarjeta, etc.). 
2.2.3  Flujo del mensaje 
A continuación se descr ibe el flujo normal de un mensaje durante un procedimiento normal de transfer encia 
de datos: 
IDE  VU 
Petición de inicio de comunicación 
Respuesta positiva 
Petición de inicio del servicio de diagnóstico 
Respuesta positiva 
Envío de petición 
Respuesta positiva 26.5.2016 L 139/268 Diar io Oficial de la Unión Europea ES    
IDE  VU 
Resumen de peticiones de transfe rencia de 
datos 
Respuesta positiva 
Petición de transfer encia de datos no 2 
Respuesta positiva no 1 
Confi rmación de submensa je no 1 
Respuesta positiva no 2 
Confi rmación de submensa je no 2 
Respuesta positiva no m 
Confi rmación de submensaje no m 
Respuesta positiva (Cam po de datos < 255 
bytes) 
Confi rmación de submensa je (opcional) 
… 
Petición de transfer encia de datos no n 
Respuesta positiva 
Petición de salida de la transferencia 
Respuesta positiva 
Petición de interr upción de la comunicación 
Respuesta positiva  
2.2.4  Sincro nización 
DDP_019  Los parámetros de sincronización que aparecen en el gráfi co siguiente son impor tantes durante el 
funcionamient o normal: 
Gráfico 1 
Flujo del mensaje, sincronización 
26.5.2016 L 139/269 Diar io Oficial de la Unión Europea ES    
Donde: 
P1  =tiempo entre dos bytes en la respuesta de la VU. 
P2  =tiempo transcur rido desde el final de la petición del IDE hasta el comienzo de la respuesta 
de la VU, o desde el final de la conf irmación del IDE hasta el comienzo de la siguient e 
respuesta de la VU. 
P3  =tiempo transcur rido 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 
conf irmació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. 
La siguient e 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 direccionamiento físico 
para lograr una comunicación más rápida). 
Sincronización Parámetro Límit e infer ior 
Valor (ms) Límite super ior 
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 negativ a con un código que signifi que «petición recibida correctamente, pen­
diente 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 mensa jes, el esquema de flujo del mensaj e se modifica en 
función de qué equipo haya detectado el error y de qué mensaje haya generado el error. 
Los gráfic os 2 y 3 muestran los procedimiento s de gestión de errores de la VU y del IDE, respectivament e. 
2.2.5.1  Fase de inicio de la comunicación 
DDP_020 Si el IDE detecta un error durante la fase de inicio de la comunicación, ya sea debido a la sincroni ­
zación o a la corriente de bits, esperará durant e 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 mensa je de petición de inicio de comunicación. 
2.2.5.2  Fase de comunicación 
Se pueden definir dos zonas distintas de gestión de errores:  
1. La VU detect a 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 incor recto, byte de la suma de control incor recto). 
DDP_023  Si la VU detec ta uno de los errores anterior es, no envía respuesta ni hace caso del mensaj e 
recibido. 26.5.2016 L 139/270 Diar io Oficial de la Unión Europea ES    
DDP_024  La VU puede detectar otros errores en el formato o en el conte nido del mensaj e recibido (por 
ejemplo, tipo de mensaj e inadmisible), aunque el mensaj e cumpla los requisitos en cuanto a 
longitud y suma de control. En tal caso, la VU deberá contestar al IDE con un mensaj e de 
respuesta nega tiva que especifi que la naturaleza del error. (NOT A: el siguiente orga nigrama no 
debe traducirse, ni tampoco los que figuran en las próximas páginas). 
Gráfico 2 
Gestión de errores de la VU 
26.5.2016 L 139/271 Diar io Oficial de la Unión Europea ES    
2. EL IDE DETECT A UN ERR OR EN LA TRANSMISIÓN DE LA VU 
DDP_025  Para cada mensaje que reciba, el IDE buscará errores de sincronización, errores de format o de 
byte (por ejemplo, violaciones de los bits de inicio y de paro) y errores de trama (número de 
bytes recibidos incor recto, byte de la suma de control incor recto). 
DDP_026  El IDE deberá detectar errores de secuencia; es decir , errores en los increment os del contador 
de submensajes en mensaj es sucesiv os. 
DDP_027  Si el IDE detecta un error o transcur re el período P2máx. sin que se haya recibido conte stación 
de la VU, el mensaj e de petición se envía de nuevo hasta un máximo de tres transmisiones en 
total. A efect os de esta detección de errores, una confir mación de submensaje se considerará 
como petición a la VU. 
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 ocur rencia del último bit 
de paro calculado después de haberse detectado el error. 
Gráfico 3 
Gestión de errores del IDE 
2.2.6  Contenido del mensaje de respuesta 
En este apar tado se especifica el conteni do de los campos de datos incluidos en los diferentes mensa jes de 
respuesta positiva. 
Los elementos de datos se definen en el apéndice 1 (Diccionar io de datos). 
Obser vaciones: En el caso de las transfer encias de segunda generación, cada elemento de datos de primer 
nivel está representado por un conjunt o de registros, incluso si solo contiene un registro. Los conjuntos de 
registros emp iezan 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 conjunt os de registros como «… 
RecordAr ray» (con cabecera). 26.5.2016 L 139/272 Diar io Oficial de la Unión Europea ES    
2.2.6.1  Respuesta positiva a la petición de transf erencia de datos «resumen» 
DDP_029  El campo de datos del mensaj e Positive Response Transf er Data Over view (respuesta positiva a la 
petición de transfer encia de datos resumen) contiene los datos siguient es en este orden, con el SId 
76 Hex, el TREP 01 Hex y el método adecuado de división y recuento de submensajes: 
Estr uctura de datos de primera generación 
Elemento de dato  Obser vaciones 
Certificados de segur idad de la VU 
Identif icación del vehículo 
Fecha y hora actuales de la VU 
Período transferible 
Tipo de tarjetas inser tadas en la VU 
Última transferencia de la VU 
Todos los bloqueos introducidos por empresas almace ­
nados. Si esta sección está vacía, únicamente se enví a 
el mensaj e «noOfLocks=0». 
Todos los registros de control almacenados en la VU. 
Si esta sección está vacía, únicamente se envía el men ­
saje «noOfControls=0». 
Firma RSA de todos los datos (except o los certificado s) 
desde VehicleIdentificationNumb er hasta el último 
byte del último VuControlA ctivityData.  
Estr uctura de datos de segunda generación 
Elemento de dato  Obser vaciones 
Certificado del Estado miembro 
Certificado de la VU 
Identif icación del vehículo 
Matrícula del vehículo 
Fecha y hora actuales de la VU 
Período transferible 
Tipo de tarjetas inser tadas en la VU 
Última transferencia de la VU 
Todos los bloqueos introducidos por empresas almace ­
nados. Si esta sección está vacía, se envía una cabecera 
de conjunto con el mensaje ‘noOfRecords=0’. 
Todos los registros de control almacenados en la VU. 
Si esta sección está vacía, se envía una cabecera de 
conjunt o con el mensaje ‘noOfRecords=0’ . 
La firma ECC de todos los datos anteriores, excep to 
los certificados.  26.5.2016 L 139/273 Diar io Oficial de la Unión Europea ES    
2.2.6.2  Respuesta positiva a la petición de transf erencia de datos sobre actividades 
DDP_030  El campo de datos del mensaj e Positive Response Transf er Data Activities (respuesta positiva a la 
petición de transfer encia de datos sobre actividades) contiene los datos siguient es en este orden, 
con el SId 76 Hex, el TREP 02 Hex y el método adecuado de división y recuento de submensa jes: 
Estr uctura de datos de primera generación 
Elemento de dato  Obser vaciones 
Fecha del día transferido 
Odómetro al final del día transmitido 
Datos de los ciclos de inserción y extracción de las tarjetas. 
—  Si esta sección no contiene datos disponibles, únicamente 
se enví a el mensaj e ‘noOfV uCardIWRecords=0’ . 
—Cuando un VuCardIWRecord se encuentra en 00:00 (inser ­
ción de la tarjeta el día anterior) o en 24:00 (extracción de 
la tarjeta al día siguiente ) figurará por compl eto en ambos 
días. 
Estado de las ranuras a las 00:00 y cambios de actividad regis ­
trados en el día transferi do. 
Datos relacionados con lugar es registrados en el día transfe ­
rido. Si esta sección está vacía, únicamente se envía el mensaje 
‘noOfPlaceRecords=0’ . 
Datos sobre condiciones específic as registrados en el día trans ­
ferido. Si esta sección está vacía, únicamente se envía el men ­
saje ‘noOfSpecifi cConditionRecords=0’. 
Firma RSA de todos los datos desde TimeReal hasta el último 
byte del último registro de condiciones específi cas.  
Estr uctura de datos de segunda generación 
Elemento de dato  Obser vaciones 
Fecha del día transferido 
Odómetro al final del día transmitido 
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 conjunt o con el mensaj e ‘noOfRecords=0’ . 
—Cuando un VuCardIWRecord se encuentra en 00:00 (inser ­
ción de la tarjeta el día anterior) o en 24:00 (extracción de 
la tarjeta al día siguiente ) figurará por compl eto en ambos 
días. 
Estado de las ranuras a las 00:00 y cambios de actividad regis ­
trados en el día transferi do. 
Datos relacionados con lugar es registrados en el día transfe ­
rido. Si esta sección está vacía, se envía una cabecera de con­
junto con el mensaj e ‘noOfRecords=0’ . 
Posiciones GNSS del vehículo si el número de horas de con­
ducción ininte rrumpi da del conduct or alcanza un múltiplo de 
tres. Si esta sección está vacía, se envía una cabecera de con­
junto con el mensaj e ‘noOfRecords=0’ . 
Datos sobre condiciones específic as registrados en el día trans ­
ferido. Si esta sección está vacía, se envía una cabecera de con­
junto con el mensaj e ‘noOfRecords=0’ . 
La firma ECC de todos los datos anteriores.  26.5.2016 L 139/274 Diar io Oficial de la Unión Europea ES    
2.2.6.3  Respuesta positiva a la petición de transf erencia de datos sobre incidente s y fallos 
DDP_031  El campo de datos del mensaj e Positive Response Transfer Data Events and Faults (respuesta 
positiva a la petición de transfer encia de datos sobre incident es y fallos) contiene los datos 
siguient es en este orden, con el SId 76 Hex, el TREP 03 Hex y el métod o adecuado de división y 
recuento de submensa jes: 
Estr uctura de datos de primera generación 
Elemento de dato  Obser vaciones 
Todos los fallos almacenados o en curso en la VU. 
Si esta sección está vacía, únicamente se envía el men ­
saje ‘noOfV uFaul ts=0’. 
Todos los incidentes almacenados o en curso en la VU 
(except o excesos de velocidad). 
Si esta sección está vacía, únicamente se envía el men ­
saje ‘noOfV uEvents=0’ . 
Datos relacionados con el último control de exceso de 
velocidad (valor por defecto si no se dispone de datos) 
Todos los registros de exceso de velocidad almacena ­
dos en la VU. 
Si esta sección está vacía, únicamente se envía el men ­
saje ‘noOfV uOverSpeedingEvents=0’. 
Todos los incident es de sincronización 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 ‘noOfV uTimeAdjRecor ds=0’. 
Firma RSA de todos los datos desde noOfV uFaults 
hasta el último byte del último registro de ajustes tem­
porales.  
Estr uctura de datos de segunda generación 
Elemento de dato  Obser vaciones 
Todos los fallos almacenados o en curso en la VU. 
Si esta sección está vacía, se envía una cabecera de 
conjunt o con el mensaje ‘noOfRecords=0’ . 
Todos los incidentes almacenados o en curso en la VU 
(except o excesos de velocidad). 
Si esta sección está vacía, se envía una cabecera de 
conjunt o con el mensaje ‘noOfRecords=0’ . 
Datos relacionados con el último control de exceso de 
velocidad (valor por defecto si no se dispone de datos) 
Todos los registros de exceso de velocidad almacena ­
dos en la VU. 
Si esta sección está vacía, se envía una cabecera de 
conjunt o con el mensaje ‘noOfRecords=0’ . 
Todos los incident es de sincronización almacenados 
en la VU (fuera del marco de un calibrado total) . 
Si esta sección está vacía, se envía una cabecera de 
conjunt o con el mensaje ‘noOfRecords=0’ . 
La firma ECC de todos los datos anter iores.  26.5.2016 L 139/275 Diar io Oficial de la Unión Europea ES    
2.2.6.4  Respuesta positiva a la petición de transf erencia de dat os por menor izados sobre la 
velocidad 
DDP_032  El camp o de datos del mensaj e Positive Response Transf er Data Detailed Speed (respuesta positiva 
a la petición de transfer encia de datos detallados sobre la velocidad) contiene los datos siguient es 
en este orden, con el SId 76 Hex, el TREP 04 Hex y el método adecuado de división y recuento de 
submensajes : 
Estr uctura de datos de primera generación 
Elemento de dato  Obser vaciones 
Todos los datos de velocidad detallados almacenados 
en la VU (un bloque de velocidad por minuto de mo­
vimient o del vehículo). 
60 valores de velocidad por minuto (uno por se­
gundo). 
Firma RSA de todos los datos desde noOfSpeedBlocks 
hasta el último byte del último bloque de velocidad.  
Estr uctura de datos de segunda generación 
Elemento de dato  Obser vaciones 
Todos los datos de velocidad detallados almacenados 
en la VU (un bloque de velocidad por minuto de mo­
vimient o del vehículo). 
60 valores de velocidad por minuto (uno por se­
gundo). 
La firma ECC de todos los datos anter iores.  
2.2.6.5  Respuesta positiva a la petición de transf erencia de datos técnicos 
DDP_033  El campo de datos del mensaj e Positive Response Transf er Data Techn ical Data (respuesta positiva 
a la petición de transfer encia de datos técn icos) contiene los datos siguient es en este orden, con el 
SId 76 Hex, el TREP 05 Hex y el método adecuado de división y recuento de submensa jes: 
Estr uctura de datos de primera generación 
Elemento de dato  Obser vaciones 
Todos los registros de calibrado almacenados en la 
VU. 
Firma RSA de todos los datos desde vuManufacturer ­
Name hasta el último byte del último VuCalibration ­
Record.  26.5.2016 L 139/276 Diar io Oficial de la Unión Europea ES    
Estr uctura de datos de segunda generación 
Elemento de dato  Obser vaciones 
Todos los emparejamientos de los Estados miembros 
almacenados en la VU. 
Todos los emparejamientos de la dispositivo GNSS ex­
terno almacenados en la VU. 
Todos los registros de calibrado almacenados en la 
VU. 
Todos los datos de inserción de tarjeta almacenados 
en la VU. 
La firma ECC de todos los datos anter iores.  
2.3.  Almacenamient o de un archiv o en un ESM 
DDP_034  Si una sesión de transfe rencia ha incluido una transferencia de datos de la VU, el IDE deberá 
almacenar en un único archiv o físico todos los datos recibidos de la VU durante dicha sesión de 
transfer encia dentro de los mensajes de respuesta positiva a la solicitud de transferencia. Los datos 
almacenados excl uyen las cabeceras de mensaj es, los contadores de submensajes, los submensajes 
vacíos y las sumas de control, pero incluyen el SId y el TREP (del primer submensaje excl usi­
vament e si es que hay varios submensajes). 
3.  PROTOCOL O DE TRANSFERENCIA DE LOS DATOS ALMA CENADOS EN TARJET AS DE TACÓGRAFO 
3.1.  Ámbito de aplicación 
El present e apar tado descr ibe cómo se transf ieren directament e a un IDE los datos almacenados en una 
tarjeta de tacógraf o. El IDE no forma parte del entorno seguro, por tanto no se lleva a cabo una autenti cación 
entre la tarjeta y el IDE. 
3.2.  Def iniciones 
Sesión de transferencia:  Cada vez que se transf ieren los datos de la ICC. Esta sesión comprende el 
procedimiento compl eto 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). 
Archiv o de datos firmado:  Un archivo de la ICC. El archiv o se transf iere al IFD en forma de texto. En la 
ICC, el archiv o se somet e a una comprobación aleat oria y se firma, y la firma 
se transfiere al IFD. 
3.3.  Transf erencia de los datos de la tarjeta 
DDP_035  La transfer encia de los datos de una tarjeta de tacógraf o consta de los pasos siguient es: 
—  Transf erencia de la información común de la tarjeta almacenada en los archiv os EF 
 e 
 . 
Esta información es opcional y no se proteg e con una firma digital. 
—  Transf erencia de los arch ivos EF 
 (o 
 ) y 
. Esta información no se prote ge con una firma digital. 
Es oblig ator io transferir estos archiv os para cada sesión de transferencia. 
—  Transf erencia del resto de archiv os EF con datos de aplicación (dentro del archiv o 
y 
 , si existe) excep to el EF 
 . Esta 
información se proteg e con una firma digital. 
—  Es oblig atori o transferi r al menos los archiv os EF 
 e 
para cada sesión de transferencia. 26.5.2016 L 139/277 Diar io Oficial de la Unión Europea ES    
—  Cuando se transfieran los datos de una tarjeta del conduct or, también es oblig atori o transfe rir 
los siguientes archiv os EF: 
—  Cuando se transfieran los datos de una tarjeta del conduct or, se actualizará la fecha 
en el archiv o EF 
 . 
—  Cuando se transfieran los datos de una tarjeta de taller , habrá que reiniciar el contador de 
calibrado en el arch ivo EF 
 . 
—  Al transferir una tarjeta de taller , no debe transferirse 
 . 
3.3.1  Secuencia de inicialización 
DDP_036  El IDE deberá iniciar la secuencia de la manera siguiente : 
Tarjeta Direc ­
ción IDE/IFD Significa do/Obser vaciones  
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. 
3.3.2  Secuencia para archivos de datos no firmados 
DDP_037  A continuación se muestra la secuencia para transfe rir los archivos EF ICC, IC, Card_Cer tificate (o 
CardSignCer tificate) y CA_Cer tificate: 
Tarjeta Direc ­
ción IDE/IFD Significa do/Obser vaciones  
Select File (seleccionar ar­
chiv o) Selección de archivo utili ­
zando su identificad or. 
OK 
Read Binar y (leer archiv o 
binar io) Si el arch ivo contiene más 
datos de los que caben en la 
memor ia temporal del lector 
o de la tarjeta, habrá que re­
petir el comando hasta que 
se haya leído el archiv o com ­
pleto. 
File Data (dato s del ar­
chiv o) 
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 archiv o EF Card_Cer tificate (o CardSignCer tificate), es preciso 
seleccionar la aplicación de tacógraf o (selección por AID). 
Nota 2: también es posible seleccionar y leer un archiv o en un solo paso al utilizar un comando 
Read Binar y con un identif icador EF corto. 26.5.2016 L 139/278 Diar io Oficial de la Unión Europea ES    
3.3.3  Secuencia para archivos de datos firmados 
DDP_038  La siguient e secuencia debe utilizarse para cada uno de los archiv os siguientes que debe 
transferirse junto con su firma: 
Tarjeta Dir IDE/IFD Significa do/Obser vaciones  
Select File (seleccionar ar­
chiv o)  
OK 
Perfor m Hash of File (rea ­
lizar comprobación alea ­
toria de archiv o) Calcula el valor de compro ­
bación aleatoria con los datos 
contenidos en el arch ivo se­
leccionado, utilizando el al­
goritmo de comprobación 
aleatori a especificado en el 
apéndice 11. Este no es un 
comando ISO. 
Realizar una comproba ­
ción aleatori a del ar­
chiv o y almacenar tem­
poralmente el valor ob­
tenido    
OK 
Read Binar y (leer archiv o 
binar io) Si el arch ivo contiene más 
datos de los que caben en la 
memor ia temporal del lector 
o de la tarjeta, habrá que re­
petir el comando hasta que 
se haya leído el archiv o com ­
pleto 
File Data (dato s del ar­
chiv o) 
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 Sig­
nature (calcular firma di­
gital )  
Realizar la operación de 
segur idad «calcular 
firma digital» utilizando 
el valor de comproba ­
ción aleatoria almace ­
nado temporalmente    
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  
Nota: también es posible seleccionar y leer un archivo en un solo paso al utilizar un comando 
Read Binar y con un identif icador EF corto. En este caso, se podrá seleccionar y leer el EF antes de 
ejecutar el comando Perform Hash of File (realizar compr obación aleatori a de archivo). 
3.3.4  Secuencia para reiniciar el contador del calibr ado 
DDP_039  A continuación se muestra la secuencia para reiniciar el contador 
en el archiv o EF 
 incluido en una tarjeta 
del taller: 
Tarjeta Dir IDE/IFD Significa do/Obser vaciones  
Select File (seleccionar ar­
chiv o) EF Card_Do wnload Selección de archivo utili ­
zando su identificador 
OK 
26.5.2016 L 139/279 Diar io Oficial de la Unión Europea ES    
Tarjeta Dir IDE/IFD Significa do/Obser vaciones  
Update Binar y (actualizar 
archiv o binar io) 
NoOfCalibrationsSince ­
Download=00 00  
Reinicia el número de 
transferencia de la tar­
jeta    
OK 
Nota: también es posible seleccionar y actualizar un arch ivo en un solo paso al utilizar un 
comando Updat e Binar y con un identif icador EF corto.  
3.4.  Formato de almacenamient o de datos 
3.4.1  Intro ducción 
DDP_040  Los datos transferi dos deben almacenarse de acuerdo con las siguientes condiciones: 
—  Los datos almacenados deben ser transparent es. Es decir , durante el almacenamient o es preciso 
respetar el orden de los bytes que se transf ieren de la tarjeta, así como el orden de los bits 
cont enidos en cada byte. 
—  Todos los archivos de la tarjeta cuyos datos se transf ieren 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 concat enación de varios objeto s 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 archiv o 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 reser va para uso futuro. 
DDP_045  Si un archiv o no se transf iere, no deberá almacenarse ninguna información relacionada con dicho 
arch ivo (ni la etiqueta ni la longitud cero). 
DDP_046  Inmediatamente después del objeto TLV que contiene los datos del archiv o, habrá que almacenar 
una firma como el siguient e objeto TLV. 
Defini ción Signif icado Longitud 
FID (2 bytes) || 00 Etiqueta para EF (FID) 3 bytes 
FID (2 bytes) || 01 Etiqueta para firma de EF 
(FID) 3 bytes 
xx xx Longitud del campo de valor 2 bytes  
Ejemplo de datos en un archivo transferi do y almacenado en un ESM: 
Etiqueta Longitud Valor 
Datos del archivo EF ICC 
Datos del archivo EF Card_Cer tificate   
… 
Datos del archivo EF 
Firma del archivo 
26.5.2016 L 139/280 Diar io Oficial de la Unión Europea ES    
4.  TRANSFERENCIA DE LOS DATOS DE UNA TARJET A DE TACÓGRAFO A TRA VÉS DE UNA UNID AD INST ALADA EN EL 
VEHÍCULO. 
DDP_047  La VU debe permitir la transferencia del contenido de una tarjeta de conduct or inser tada en un 
IDE conectado. 
DDP_048  El IDE deberá enviar a la VU el mensa je Transf er Data Request Card Download (petición de 
transfer encia de datos de la tarjeta) para iniciar este modo (véase el apar tado 2.2.2.9). 
DDP_049  A continuación, la VU deberá transfe rir todos los datos de la tarjeta, arch ivo por archiv o, de 
acuerdo con el protocolo de transferencia descr ito en el apar tado 3, para luego enviar al IDE 
todos los datos recibidos de la tarjeta. Estos datos se enviarán con el format o adecuado de archiv o 
TLV (véase el apar tado 3.4.2) y encapsulados en un mensaj e Positive Response Transfer Data 
(respuesta positiva a la petición de transfe rencia de datos). 
DDP_050  El IDE deberá recuperar los datos conte nidos en el mensaj e Positive Response Transf er Data 
(respuesta positiva a la petición de transfer encia de datos ) (separando todas las cabeceras, SId, 
TREP , contadores de submensa jes y sumas de control) y almacenarlos en un único archiv o físico, 
tal y como se especifi ca en el apar tado 2.3. 
DDP_051  A continuación, según proceda, la VU actualizará el archiv o 
 o el 
arch ivo 
 de la tarjeta del conduct or.  26.5.2016 L 139/281 Diar io Oficial de la Unión Europea ES    
Apéndice 8 
PROTOCOL O DE CALIBRADO 
ÍNDICE 
1. INTR ODUCCIÓN ................................................................................................................................ 283 
2. TÉRMINOS, DEFINICIONES Y REFERENCIAS ............................................................................................. 283 
3. VISIÓN GENERAL DE LOS SER VICIOS ..................................................................................................... 284 
3.1. Servicios disponibles ............................................................................................................... 284 
3.2. Códigos de respuesta ............................................................................................................... 285 
4. SER VICIOS DE COMUNICA CIÓN ........................................................................................................... 285 
4.1. Servicio Star tCommunication .................................................................................................... 285 
4.2. Servicio StopCo mmunication .................................................................................................... 287 
4.2.1 Descr ipción del mensaje .......................................................................................................... 287 
4.2.2 Format o del mensaj e............................................................................................................... 288 
4.2.3 Definición del parámetro ......................................................................................................... 289 
4.3. Servicio TesterPresent (presencia de verificador) ............................................................................. 289 
4.3.1 Descr ipción del mensaje .......................................................................................................... 289 
4.3.2 Format o del mensaj e............................................................................................................... 289 
5. SER VICIOS DE ADMINISTRA CIÓN ......................................................................................................... 291 
5.1. Servicio Star tDiagnosticSession ................................................................................................. 291 
5.1.1 Descr ipción del mensaje .......................................................................................................... 291 
5.1.2 Format o del mensaj e............................................................................................................... 292 
5.1.3 Definición del parámetro ......................................................................................................... 293 
5.2. Servicio Secur ityA ccess ............................................................................................................ 294 
5.2.1 Descr ipción del mensaje .......................................................................................................... 294 
5.2.2 Format o del mensaj e — Secur ityA ccess — requestSeed ................................................................... 295 
5.2.3 Format o del mensaj e — Secur ityA ccess — sendKey ....................................................................... 296 
6. SER VICIOS DE TRANSMISIÓN DE DATOS ................................................................................................ 297 
6.1. Servicio ReadDataByIdentifi er................................................................................................... 298 
6.1.1 Descr ipción del mensaje .......................................................................................................... 298 
6.1.2 Format o del mensaj e............................................................................................................... 298 
6.1.3 Definición del parámetro ......................................................................................................... 299 
6.2. Servicio WriteDataByIdentifier ................................................................................................... 300 
6.2.1 Descr ipción del mensaje .......................................................................................................... 300 
6.2.2 Format o del mensaj e............................................................................................................... 300 
6.2.3 Definición del parámetro ......................................................................................................... 302 26.5.2016 L 139/282 Diar io Oficial de la Unión Europea ES    
7. CONTR OL DE LOS IMPULSOS DE PRUEB A — UNID AD FUNCIONAL PARA CONTR OL DE ENTRAD A/SALID A......... 302 
7.1. Servicio InputOutputCont rolByIdentif ier...................................................................................... 302 
7.1.1 Descr ipción del mensaje .......................................................................................................... 302 
7.1.2 Format o del mensaj e............................................................................................................... 303 
7.1.3 Definición del parámetro ......................................................................................................... 304 
8. FORMA TOS DATARECO RDS ................................................................................................................. 305 
8.1. Inter valos de los parámetros transmitidos .................................................................................... 305 
8.2. Format os dataRecords ............................................................................................................. 306  
1.  INTR ODUCCIÓN 
El presente apéndice define el modo en que se interca mbian 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 descr ita en el apéndice 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 descr ibe en el apar tado 4 (Ser vicios 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 
diferent es condiciones. La sesión por defe cto es la «StandardDiagnosticSession», en la que todos los datos se 
pueden leer desde una unidad instalada en el vehículo pero no es posible escr ibir ningún dato en ella. 
La selección de la sesión de diagnóstico se explica en el apar tado 5 (Ser vicios de administración). 
El presente apéndice debe considerarse aplicable tanto para la generación de VU como de tarjetas de taller , según 
lo previsto en los requisitos de interoperabilidad recogidos en el present e 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 funcionamient o 
CALIBRADO. 
La transferencia de datos a través de la línea K se descr ibe en el apar tado 6 (Ser vicios de transmisión de 
datos). Los formatos de los datos transferidos se detallan en el apar tado 8 (For matos dataRecords). 
CPR_002  La «ECU AdjustmentSession» 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 
descr ibe en el apar tado 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 direcciones preferen tes para los verificad ores, la VU deberá responder correctamente a 
cualquier dirección de verificador . La dirección física de la VU es 0xEE. 
2.  TÉRMINOS, DEFINICIONES Y REFERENCIAS 
Todos los protocolos, mensaj es y códigos de error se rigen principalment e por el proyect o de la norma ISO 
14229-1 (Vehículos de carretera — Siste mas 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 identificad ores de servicios, las peticiones 
y respuestas de servicio y los parámetros normalizados. 
El térm ino «ver ificador» se refiere al equipo empleado para introducir datos de programación/calibrado en la VU. 
Los térm inos «client e» y «servidor» se refieren al verificador y a la VU, respectivament e. 
El térm ino UCE signif ica «unidad de control electrónico» y se refiere a la VU. 26.5.2016 L 139/283 Diar io Oficial de la Unión Europea ES    
Referencias: 
ISO 14230-2: Vehículos de carretera — Siste mas de diagnóstico — Protocolo Keyw ord 2000 — Parte 2: Nivel de 
enlace de datos. 
Primera edición: 1999. 
Vehículos — Diagnóstico. 
3.  VISIÓN GENERAL DE LOS SER VICIOS 
3.1.  Servicios disponibles 
La siguiente tabla ofrece una visión general de los servicios que estarán disponibles en el tacógraf o 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 apar tado del present e apéndice donde se ofrece más 
información sobre el servicio que corresponda. 
—  La tercera columna asigna los valores de identificad or de servicio (SId) para los mensaj es de 
petición. 
—  La cuar ta columna especifica los servicios de la «StandardDiagnosticSession» (SD) que deben 
aplicarse en cada VU. 
—  La quinta columna especific a los servicios de la «ECU AdjustmentSession» (ECU AS) que deben 
aplicarse 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 sext a columna especifica los servicios de la «ECUProg rammingSession» (ECUPS) que deben 
aplicarse para poder programar los parámetros en la VU. 
Tabla 1 
Cuadro resumen con los valores de los identif icadores de servicios  
Sesiones de diagnóstico 
Nombre del servicio de diagnós ­
tico Sección no Valor SId de la 
petición SD ECU AS ECUPS 
Star tCommunication 4.1 81             
StopCommunicatio n 4.2 82       
Testerpresent 4.3 3E             
Star tDiagnosticSession 5.1 10             
Secur ityA ccess 5.2 27             
ReadDataByIdentifi er 6.1 22             
WriteDataByIdentifier 6.2 2E       
InputOutputCont rolByIdentif ier 7.1 2F         
   Este símbolo indica que el servicio es oblig atorio 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.  26.5.2016 L 139/284 Diar io Oficial de la Unión Europea ES    
3.2.  Códigos de respuest a 
Se definen los códigos de respuesta para cada servicio. 
4.  SER VICIOS DE COMUNICA CIÓN 
Se requieren ciertos servicios para establecer y manten er la comunicación, y no aparecen en el nivel de aplicación. 
Los servicios disponibles se descr iben con detalle en la siguiente tabla: 
Tabla 2 
Servicios de comunicación 
Nombre del servicio Descr ipción 
Star tCommunication El cliente solicita el comienzo de una sesión de comunicación con uno o varios 
servidores. 
StopCommunicatio n El cliente solicita el térm ino de la sesión de comunicación actual. 
Testerpresent El cliente indica al servidor que todavía está presente.  
CPR_005  El servicio Star tCommunication sirve para comenzar una comunicación. A fin de utilizar un servicio, 
es preciso inicializar la comunicación y que los parámetros de comunicación sean los adecuados para 
el modo deseado. 
4.1.  Servicio Star tCommunication 
CPR_006  Nada más recibir una indicación primitiva Star tCommunication, la VU deberá compr obar si el enlace 
de comunicación solicitado se puede inicializar en las condiciones que haya en ese momento. Las 
condiciones válidas para la inicialización de un enlace de comunicación se descr iben en la norma ISO 
14230-2. 
CPR_007  A continuación, la VU deberá hacer todo lo necesar io para inicializar el enlace de comunicación y 
enviar una primitiva de respuesta Star tCommunication 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 Star tCommunication Request (por ejemplo, debido a la recuperación de un error en el 
verificad or), 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 mensaj e Star tCommunication Request. 
CPR_011  La inicialización de la VU para los servicios se efectúa a través de un métod o de «inicialización rápida». 
—  Antes de cualquier actividad hay un tiempo de inactividad del bus. 
—  A continuación, el verificado r envía una pauta de inicialización. 
—  La respuesta de la VU incluye toda la información necesar ia 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 verificado r; 26.5.2016 L 139/285 Diar io Oficial de la Unión Europea ES    
—  la VU se encuentra en el modo de diagnóstico por defect o, es decir , StandardDiagnosticSession; y 
—  la línea de señal I/O de calibrado se encuentra en el estado por defect o, es decir , desactivada. 
CPR_014  La velocidad de datos en la línea K será de 10 400 baudios. 
CPR_016  El verificad or comienza la inicialización rápida transmitiendo 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 
verificad or transmite el primer bit del servicio Star tCommunication después de un tiempo Twup que 
sigue al primer flanco descendente. 
CPR_017  Los valores de sincronización para la inicialización rápida y las comunicaciones en general se descr iben 
con todo detalle en las tablas siguient es. 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 term inado un servicio StopCo mmunication, Trep=P3 mín.; y 
—  después de haberse interr umpido la comunicación por exce so 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 Descr ipción del parámetro Valores límite 
infer iores (ms) Valores límite 
super iores (ms) 
mín. máx. 
P1 Tiem po entre dos bytes para respuesta de la VU 0 20 
P2 Tiem po transcur rido entre la petición del verifica ­
dor y la respuesta de la VU o entre dos respuestas 
de la VU 25 250 
P3 Tiem po transcur rido desde el final de las respues ­
tas de la VU hasta el comienzo de la nueva peti­
ción del verificador 55 5 000 
P4 Tiem po entre dos bytes para petición del verifica ­
dor 5 20  26.5.2016 L 139/286 Diar io Oficial de la Unión Europea ES    
CPR_018  En las siguient es tablas se descr ibe con detalle el formato de mensaj e para inicialización rápida. (NOT A: 
hex signif ica hexadecimal) 
Tabla 5 
Mensaje Star tCommunication Request (petición de inicio de la comunicación) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 81 FMT 
No 2 Byte de dirección de destino EE TGT 
No 3 Byte de dirección de origen tt SRC 
No 4 Star tCommunication Request Service Id (SId 
de petición de inicio de la comunicación) 81 SCR 
No 5 Suma de control 00-FF CS  
Tabla 6 
mensaje Star tCommunication Positiv e Response (respuest a positiva a la petición de inicio de 
lacomunicación) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino tt TGT 
No 3 Byte de dirección de origen EE SRC 
No 4 Byte de longitud adicional 03 LEN 
No 5 Star tCommunication Positiv e Response Ser­
vice Id (SId de respuest a positiva a la petición 
de inicio de la comunicación) C1 SCRPR 
No 6 Byte clave 1 EA KB1 
No 7 Byte clave 2 8F KB2 
No 8 Suma de control 00-FF CS  
CPR_019  No hay respuesta negat iva al mensaj e Star tCommunication Request. Si no hay un mensaj e de respuesta 
positiva que transmitir , la VU no se inicializa, no transmite ninguna información y continúa en el 
modo normal de funcionamient o. 
4.2.  Servicio StopCommunication 
4.2.1  Descr ipció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 StopCo mmunication, la VU deberá compr obar si las 
condiciones que haya en ese momento permiten poner térm ino a la comunicación. En caso afirmativ o, 
la VU hará todo lo necesar io para terminar la comunicación. 26.5.2016 L 139/287 Diar io Oficial de la Unión Europea ES    
CPR_021  Si es posible poner fin a la comunicación, antes de que esta term ine la VU deberá emitir una primitiva 
de respuesta StopCo mmunication con los parámetros de respuesta positiva seleccionados. 
CPR_022  Si por algún motivo no es posible poner fin a la comunicación, la VU deberá emitir una primitiva de 
respuesta StopCo mmunication con el parámetro de respuesta negativ a 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. 
4.2.2  Formato del mensaje 
CPR_024 En las siguientes tablas se descr iben con detalle los formatos de mensaje para las primitivas StopCom ­
munication. 
Tabla 7 
Mensaje StopCommunication Request (petición de inter rupción de la comunicación) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino EE TGT 
No 3 Byte de dirección de origen tt SRC 
No 4 Byte de longitud adicional 01 LEN 
No 5 StopCommunication Request Service Id (SId 
de petición de inter rupción de la comunica ­
ción) 82 SPR 
No 6 Suma de control 00-FF CS  
Tabla 8 
Mensaje StopCommunication Positiv e Response (respues ta positiva a la petición de 
inter rupción de la comunicación) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino tt TGT 
No 3 Byte de dirección de origen EE SRC 
No 4 Byte de longitud adicional 01 LEN 
No 5 StopCommunication Positiv e Response Ser­
vice Id (SId de respuest a positiva a la petición 
de inter rupción de la comunicación) C2 SPRPR 
No 6 Suma de control 00-FF CS  26.5.2016 L 139/288 Diar io Oficial de la Unión Europea ES    
Tabla 9 
Mensaje StopCommunication Negativ e Response (respues ta negativa a la petición de 
inter rupción de la comunicación) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino tt TGT 
No 3 Byte de dirección de origen EE SRC 
No 4 Byte de longitud adicional 03 LEN 
No 5 negativ e Response Service Id (SId de respuest a 
negativa) 7F NR 
No 6 StopCommunication Request Service Identif ication 
(SId de petición de interr upción de la comunica ­
ción) 82 SPR 
No 7 responseCode = generalReject 10 RC_GR 
No 8 Suma de control 00-FF CS  
4.2.3  Definición del parámetr o 
Este servicio no precisa definició n de parámetros. 
4.3.  Servicio TesterPresent (presencia de verificador) 
4.3.1  Descr ipción del mensaje 
El servicio TesterPresent lo utiliza el verificad or para indicar al servidor que sigue present e, con el fin de evitar que 
retor ne autom áticamente al funcionamiento normal, lo que podría interrumpi r la comunicació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 siguiente s tablas se descr iben con detalle los formatos de mensaje para las primitivas Tester­
Present. 
Tabla 10 
Mensaje Tester Present Request (petición de presencia de verificador) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino EE TGT 
No 3 Byte de dirección de origen tt SRC 
No 4 Byte de longitud adicional 02 LEN 
No 5 Tester Present Request Service Id (SId de peti ­
ción de presencia de verificador) 3E TP 26.5.2016 L 139/289 Diar io Oficial de la Unión Europea ES    
No de byte Nombre del parámetro Valor hex Mnemónico 
No 6 Sub Function = responseRequired = [sí 01 RESPREQ_Y 
no] 02 RESPREQ_NO 
No 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 siguient e. Si se configura en «no», el servidor no enviará respuesta. 
Tabla 11 
Mensaje TesterPresent Positiv e Response (respuest a positiva a la petición de presencia de 
verificador) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino tt TGT 
No 3 Byte de dirección de origen EE SRC 
No 4 Byte de longitud adicional 01 LEN 
No 5 Tester Present Positiv e Response Service Id 
(SId de respuest a positiva a la petición de pre­
sencia de verificador) 7E TPPR 
No 6 Suma de control 00-FF CS  
CPR_081  El servicio admitirá los siguient es códigos de respuesta negativa: 
Tabla 12 
Mensaje TesterPresent Negativ e Response (respuest a negativa a la petición de presencia de 
verificador) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino tt TGT 
No 3 Byte de dirección de origen EE SRC 
No 4 Byte de longitud adicional 03 LEN 
No 5 negativ e Response Service Id (SId de respuest a 
negativa) 7F NR 
No 6 TesterPresent Request Service Identif ication (SId de 
petición de presencia de verificador) 3E TP 26.5.2016 L 139/290 Diar io Oficial de la Unión Europea ES    
No de byte Nombre del parámetro Valor hex Mnemónico 
No 7 responseCode = [ SubFunctionNotSuppor ted-In ­
validFor mat 12 RC_SFNS_IF 
incor rectMessageL ength ] 13 RC_IML 
No 8 Suma de control 00-FF CS  
5.  SER VICIOS DE ADMINISTRA CIÓN 
Los servicios disponibles se descr iben con detalle en la siguiente tabla: 
Tabla 13 
Servicios de administración 
Nombre del servicio Descr ipción 
Star tDiagnosticSession El cliente solicita el comienzo de una sesión de diagnóstico con una VU. 
Secur ityA ccess El cliente solicita acceso a las funciones restr ingidas a usuar ios autori zados.  
5.1.  Servicio Star tDiagnosticSession 
5.1.1  Descr ipción del mensaje 
CPR_025  El servicio Star tDiagnosticSession sirve para activar diferentes 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 
present e document o. Las reglas de aplicación deberán cumplir los siguiente s requisitos: 
—  habrá siempre exactamente una sesión de diagnóstico activa en la VU; 
—  la VU iniciará siempr e la StandardDiagnosticSession al encendido. Si no se inicia ninguna otra 
sesión de diagnóstico, se estará ejecutando la StandardDiagnosticSession 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 respuesta positiva; y 
—  cuando el verificador solicite una nueva sesión de diagnóstico, la VU enviará primero un mensaj e 
de respuesta positiva Star tDiagnosticSession 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 mensaj e de 
respuesta negativa Star tDiagnosticSession y proseguirá la sesión ya activa. 
CPR_026  Solo se iniciará una sesión de diagnóstico si se ha establecido 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óstico (Star tDiagnosticSession). El parámetro diagnosticSession estará conf igurado a 
«StandardDiagnosticSession» (sesión normal) en el mensaj e de petición si previamente estaba activada 
otra sesión de diagnóstico. 26.5.2016 L 139/291 Diar io Oficial de la Unión Europea ES    
5.1.2  Formato del mensaje 
CPR_028 En las siguient es tablas se descr iben con detalle los formatos de mensaje para las primitivas Star tDiag ­
nosticSession. 
Tabla 14 
Mensaje Star tDiagnos ticSession Request (petición de inicio de la sesión de diagnóst ico) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino EE TGT 
No 3 Byte de dirección de origen tt SRC 
No 4 Byte de longitud adicional 02 LEN 
No 5 Star tDiagnos ticSession Request Service Id 
(SId de petición de inicio de la sesión de diag ­
nóstico) 10 STDS 
No 6 diagnosticSession = [uno de los valores de la Tabla 
17] xx DS_… 
No 7 Suma de control 00-FF CS  
Tabla 15 
Mensaje Star tDiagnos ticSession Positiv e Response (respuest a positiva a la petición de inicio de 
la sesión dediagnóstico) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino tt TGT 
No 3 Byte de dirección de origen EE SRC 
No 4 Byte de longitud adicional 02 LEN 
No 5 Star tDiagnos ticSession Positiv e Response Ser­
vice Id (SId de respuest a positiva a la petición 
de inicio de la sesión de diagnóstico) 50 STDSPR 
No 6 diagnosticSession = [el mismo valor que en el byte 
no6 de la Tabla 14] xx DS_… 
No 7 Suma de control 00-FF CS  
Tabla 16 
Mensaje Star tDiagnos ticSession Negativ e Response (respuest a negativa a la petición de inicio 
de la sesiónde diagnóstico) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino tt TGT 26.5.2016 L 139/292 Diar io Oficial de la Unión Europea ES    
No de byte Nombre del parámetro Valor hex Mnemónico 
No 3 Byte de dirección de origen EE SRC 
No 4 Byte de longitud adicional 03 LEN 
No 5 Negativ e Response Service Id (SId de res­
puest a negativa) 7F NR 
No 6 Star tDiagnosticSession Request Service Id (SId de 
petición de inicio de la sesión de diagnóstico) 10 STDS 
No 7 ResponseCode = [subFunctionNotSuppor ted(a) 12 RC_SFNS 
incor rectMessageL ength (b) 13 RC_IML 
conditionsNotCor rect (c) 22 RC_CNC 
No 8 Suma de control 00-FF CS 
(a)  : no se admite el valor introducido en el byte no 6 del mensaje de petición, puest o que no figura en la Tabla 17. 
(b)  : la longitud del mensaje es incor recta. 
(c)  : no se cumplen los requisitos para la petición Star tDiagnosticSession.  
5.1.3  Definición del parámetr o 
CPR_029  El servicio Star tDiagnosticSession utiliza el parámetro diagnosticSession (DS_) para seleccionar el 
compo rtamient o específico del servidor o servidores. En el presente documento se especifican las 
siguient es sesiones de diagnóstico: 
Tabla 17 
Def inición de valores de la sesión de diagnóst ico 
Hex Descr ipción Mnemónico 
81 StandardDiagnos ticSession (sesión de diagnóstico nor mal) 
Esta sesión de diagnóstico activa todos los servicios especificados en la Ta­
bla 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 fi­
nalizado con éxito la inicialización entre el cliente (verificador) y el servi­
dor (VU). Es posible que otras sesiones de diagnóstico especificadas en 
este apar tado sobrescr iban esta sesión de diagnóstico. SD 
85 ECUProg rammingSession (sesión de prog ramación ECUPS) 
Esta sesión de diagnóstico activa todos los servicios especificados en la Ta­
bla 1, columna 6 (ECUPS). Dichos servicios admiten la programación de 
memor ia de un servidor (VU). Es posible que otras sesiones de diagnóstico 
especificadas en este apar tado sobrescr iban esta sesión de diagnóstico. ECUPS 
87 ECU Adjust mentSession (sesión de ajuste ECU A) 
Esta sesión de diagnóstico activa todos los servicios especificados en la Ta­
bla 1, columna 5 (ECU AS). Dichos servicios admite n el control de en­
trada/salida de un servidor (VU). Es posible que otras sesiones de diagnós ­
tico especificadas en este apar tado sobrescr iban esta sesión de diagnós ­
tico. ECU AS  26.5.2016 L 139/293 Diar io Oficial de la Unión Europea ES    
5.2.  Servicio Secur ityAccess 
No es posible escr ibir datos de calibrado a menos que la VU se encuentre en el modo CALIBRADO. Para poder 
acceder al modo CALIBRADO es preciso inser tar una tarjeta de taller válida y además introducir 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 CONTR OL. 
El servicio Secur ityA ccess sirve como medio para introducir el PIN y para indicar al verificad or si la VU se 
encuentra o no en el modo CALIBRADO. 
El PIN también se puede introducir por otros métodos alternati vos. 
5.2.1  Descr ipción del mensaje 
El servicio Secur ityA ccess se compo ne de un mensaj e Secur ityA ccess «requestSeed», seguido en su caso de un 
mensaj e Secur ityA ccess «sendKe y». El servicio Secur ityA ccess debe utilizarse después del servicio Star tDiagnostic ­
Session. 
CPR_033  El verificador deberá utilizar el mensa je Secur ityA ccess «requestSeed» para comprobar si la unidad 
instalada en el vehículo está preparada para acepta r un PIN. 
CPR_034  Si la unidad instalada en el vehículo ya se encuentra en el modo CALIBRADO, deberá cont estar a la 
petición enviando una «simient e» (seed) de 0x0000, utilizando para ello el servicio Secur ityA ccess 
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 «simient e» (seed) mayor que 
0x0000, utilizando para ello el servicio Secur ityA ccess Positive Response. 
CPR_036  Si la unidad instalada en el vehículo no está preparada para aceptar un PIN del verificado r, ya sea 
porque la tarjeta de taller que se ha inser tado no es válida, o porque no se ha inser tado ninguna 
tarjeta, o porque la unidad espera el PIN de otro método, deberá cont estar a la petición con una 
respuesta negativa, con un código de respuesta conf igurado a conditionsNotCor rectOrRequestSequen ­
ceEr ror. 
CPR_037  A continuación, el verificador utilizará en su caso el mensa je Secur ityA ccess «sendKe y» para enviar un 
PIN a la unidad instalada en el vehículo. A fin de conceder tiempo suficient e para el proceso de aute nti­
cación de la tarjeta, la VU utilizará el código de respuesta negativ a requestCor rectlyReceived-Response ­
Pending para ampli ar el tiempo de respuesta. Sin embargo, el tiempo de respuesta máximo no excederá 
de cinco minutos. En cuanto finalice el servicio solicitado, la VU enviará un mensaj e de respuesta 
positiva o un mensaj e de respuesta negativ a con un código de respuesta distinto de este. La VU podrá 
repetir el código de respuesta negativ a requestCor rectlyReceived-ResponseP ending hasta que finalice el 
servicio solicitado y se envíe el mensaj e de respuesta final. 
CPR_038  La unidad instalada en el vehículo solamente deberá contestar a esta petición utilizando el servicio 
Secur ityA ccess Positive Response cuando se encuentre en el modo CALIBRADO. 
CPR_039  En los casos siguiente s, la unidad instalada en el vehículo deberá cont estar a esta petición con una 
respuesta negat iva con un código de respuesta configurado a: 
—  subFunctionNotSuppor ted: formato del parámetro de subfunción no válido (accessT ype); 
—  conditionsNotCor rectOrRequestSequenceEr ror: la unidad instalada en el vehículo no está lista para 
aceptar una entrada PIN; 
—  invalidKe y: el PIN no es válido y no se ha sobrepasado el número de intentos de verificación del 
PIN; 
—  exceedNumberOfA ttempts: 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 autenticación mutua con la tarjeta de taller . 26.5.2016 L 139/294 Diar io Oficial de la Unión Europea ES    
5.2.2  Formato del mensaje — Secur ityA ccess — requestSeed 
CPR_040 En las siguient es tablas se descr iben con detalle los format os de mensaj e para las primitivas Secur it­
yAccess «requestSeed» (petición de simient e). 
Tabla 18 
Mensaje Secur ityAcc ess Request- requestSeed (petición de simiente) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino EE TGT 
No 3 Byte de dirección de origen tt SRC 
No 4 Byte de longitud adicional 02 LEN 
No 5 Secur ityA ccess Request Service Id (SId de pe­
tición de servicio Secur ityA ccess) 27 SA 
No 6 accessT ype — requestSeed 7D AT_RSD 
No 7 Suma de control 00-FF CS  
Tabla 19 
Mensaje Secur ityAccess — reques tSeed Positiv e Response (respuest a positiva a la petición de 
simiente) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino tt TGT 
No 3 Byte de dirección de origen EE SRC 
No 4 Byte de longitud adicional 04 LEN 
No 5 Secur ityA ccess Positiv e Response Service Id 
(SId de respuest a positiva a la petición de ser­
vicio Secur ityAc cess) 67 SAPR 
No 6 accessT ype — requestSeed 7D AT_RSD 
No 7 Seed High 00-FF SEEDH 
No 8 Seed Low 00-FF SEEDL 
No 9 Suma de control 00-FF CS  
Tabla 20 
Mensaje Secur ityAccess –requestS eed Negativ e Response (respues ta negativa a la petición de 
simiente) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino tt TGT 
No 3 Byte de dirección de origen EE SRC 26.5.2016 L 139/295 Diar io Oficial de la Unión Europea ES    
No de byte Nombre del parámetro Valor hex Mnemónico 
No 4 Byte de longitud adicional 03 LEN 
No 5 Negativ eResponse Service Id (SId de respuest a 
negativa) 7F NR 
No 6 Secur ityA ccess Request Service Id (SId de petición 
de servicio Secur ityA ccess) 27 SA 
No 7 responseCode = [conditionsNotCor rectOrRe ­
questSequenceEr ror 22 RC_CNC 
incor rectMessageL ength] 13 RC_IML 
No 8 Suma de control 00-FF CS  
5.2.3  Formato del mensaje — Secur ityA ccess — sendKe y 
CPR_041 En las siguient es tablas se descr iben con detalle los format os de mensaj e para las primitivas Secur it­
yAccess «sendKey» (envío de clave). 
Tabla 21 
Mensaje Secur ityAccess Request — sendKe y (envío de clave) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino EE TGT 
No 3 Byte de dirección de origen tt SRC 
No 4 Byte de longitud adicional m+2 LEN 
No 5 Secur ityA ccess Request Service Id (SId de pe­
tición de servicio Secur ityA ccess) 27 SA 
No 6 accessT ype — sendKey 7E AT_SK 
Nos 7 a m 
+6 Clave no 1 (alto) xx CLAVE 
… …  
Clave no m (bajo, m debe ser como mínimo 4 y 
como máximo 8) xx  
No m+7 Suma de control 00-FF CS  
Tabla 22 
Mensaje Secur ityA ccess — sendKe y Positiv e Response (respues ta positiva a la petición de 
envío de clave) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino tt TGT 
No 3 Byte de dirección de origen EE SRC 26.5.2016 L 139/296 Diar io Oficial de la Unión Europea ES    
No de byte Nombre del parámetro Valor hex Mnemónico 
No 4 Byte de longitud adicional 02 LEN 
No 5 Secur ityA ccess Positiv e Response Service Id 
(SId de respuest a positiva a la petición de ser­
vicio Secur ityAc cess) 67 SAPR 
No 6 accessT ype — sendKey 7E AT_SK 
No 7 Suma de control 00-FF CS  
Tabla 23 
Mensaje Secur ityAc cess Negativ e Response (respues ta negativa) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino tt TGT 
No 3 Byte de dirección de origen EE SRC 
No 4 Byte de longitud adicional 03 LEN 
No 5 Negativ eResponse Service Id (SId de respuest a 
negativa) 7F NR 
No 6 Secur ityA ccess Request Service Id (SId de petición 
de servicio Secur ityA ccess) 27 SA 
No 7 ResponseCode = [generalReject 10 RC_GR 
subFunctionNotSuppor ted 12 RC_SFNS 
incor rectMessageL ength 13 RC_IML 
conditionsNotCor rectOrRe ­
questSequenceEr ror 22 RC_CNC 
invalidKey 35 RC_IK 
excee dedNumberOfAtt emp ts 36 RC_ENA 
requestCor rectlyReceived-Res ­
ponseP ending] 78 RC_R CR_RP 
No 8 Suma de control 00-FF CS  
6.  SER VICIOS DE TRANSMISIÓN DE DATOS 
Los servicios disponibles se descr iben con detalle en la siguiente tabla: 
Tabla 24 
Servicios de transmisión de datos 
Nombre del servicio Descr ipción 
ReadDataByIdentifi er El cliente solicita la transmisión del valor actual de un registro con acceso me­
diante recordDataIdentif ier. 
WriteDataByIdentifier El cliente solicita la escr itura de un registro al que se acceda mediante record ­
DataIdentif ier.  26.5.2016 L 139/297 Diar io Oficial de la Unión Europea ES    
6.1.  Servicio ReadDataByIdentif ier 
6.1.1  Descr ipción del mensaje 
CPR_050  El cliente utiliza el servicio ReadDataByIdentifi er para leer valores de registros de datos de un servidor . 
Los datos se identifican con un recordDataIdentifie r (identifi cador 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. 
6.1.2  Formato del mensaje 
CPR_051 En las siguientes tablas se descr ibe con detalle los formatos de mensaj e para las primitivas ReadDataByI ­
dentifier . 
Tabla 25 
Mensaje ReadDat aByIdentif ier Request (petición de servicio ReadDat aByIdentif ier) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino EE TGT 
No 3 Byte de dirección de origen tt SRC 
No 4 Byte de longitud adicional 03 LEN 
No 5 ReadDataByIdentif ier Request Service Id (SId 
de petición de servicio ReadDataBy Identif ier) 22 RDBI 
Nos 6 a 7 recordDataIdentifier = [un valor de la Tabla 28] xxxx RDI_… 
No 8 Suma de control 00-FF CS  
Tabla 26 
Mensaje ReadDat aByIdentif ier Positiv e Response (respuest a positiva a la petición de servicio 
ReadDat aByIdentif ier) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino tt TGT 
No 3 Byte de dirección de origen EE SRC 
No 4 Byte de longitud adicional m+3 LEN 
No 5 ReadDataByIdentif ier Positiv e Response Ser­
vice Id (SId de respuest a positiva a la petición 
de servicio ReadDataByIdenti fier) 62 RDBIPR 
Nos 6 y 7 recordDataIdentifier = [mismo valor que los bytes 
nos 6 y 7 de la Tabla 25] xxxx RDI_… 
Nos 8 a m 
+7 dataRecord[] = [data#1 xx DREC_D ATA1 
: : : 
data#m] xx DREC_D ATAm 
No m+8 Suma de control 00-FF CS  26.5.2016 L 139/298 Diar io Oficial de la Unión Europea ES    
Tabla 27 
Mensaje ReadDataByIdentif ier Negativ e Response (respuest a negativa a la petición de servicio ­
ReadDat aByIdentif ier) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino tt TGT 
No 3 Byte de dirección de origen EE SRC 
No 4 Byte de longitud adicional 03 LEN 
No 5 Negativ eResponse Service Id (SId de respuest a 
negativa) 7F NR 
No 6 ReadDataByIdentifier Request Service Id (SId de 
petición de servicio ReadDataByIdentif ier) 22 RDBI 
No 7 ResponseCode= [requestOutOfRange 31 RC_R OOR 
incor rectMessageL ength 13 RC_IML 
conditionsNotCor rect] 22 RC_CNC 
No 8 Suma de control 00-FF CS  
6.1.3  Definición del parámetr o 
CPR_052  El parámetro recor dDataIdentifier (RDI_) incluido en el mensaj e ReadDataByIdentif ier Request 
identifica un registro de datos. 
CPR_053  La siguient e tabla muestra los valores recordDataIdentif ier definidos en el present e documento. 
La tabla recordDataIdentif ier tiene cuatro columnas y múltiples filas. 
—  La primera columna (Hex) incluye el valor hexadecimal asignado al recordDataIdentifier 
especifi cado en la tercera columna. 
—  La segunda columna (Element o de datos) especifica el element o de datos del apéndice 1 en el 
que se basa el recordDataIdentifier (a veces es necesar io transcodific ar). 
—  La tercera columna (Descr ipción) especifica el nombre recordDataIdentifie r correspondiente. 
—La cuar ta columna (Tér mino nemónico) especifica el térm ino nemónico de este recordDataIden ­
tifier. 
Tabla 28 
Def inición de los valores recordDataIdentif ier 
Hex Elemento de dato Nombre recordDataIdentifier 
(véase formato en el apar tado 8.2) Mnemónico 
F90B 
 TimeDat e RDI_TD 
F912 
 HighResolution TotalV ehicleDistance RDI_HRT VD 
F918 
 Kfact or RDI_KF 26.5.2016 L 139/299 Diar io Oficial de la Unión Europea ES    
Hex Elemento de dato Nombre recordDataIdentifier 
(véase formato en el apar tado 8.2) Mnemónico 
F91C 
 LfactorT yreCircumfe rence RDI_LF 
F91D 
 WvehicleCharacter isticF actor RDI_WV CF 
F921 
 TyreSize RDI_TS 
F922 
 NextCalibrationDat e RDI_NCD 
F92C 
 SpeedAuthor ised RDI_S A 
F97D 
 Regist eringMemberState RDI_RMS 
F97E 
 VehicleRegistrationNumber RDI_VRN 
F190 
 VIN RDI_VIN  
CPR_054  El mensaj e ReadDataByIdentifier Positive Response utiliza el parámetro dataRecor d (DREC_) para 
facilitar al cliente (verificador) el valor del registro de datos identif icado por el recordDataIdentifie r. Los 
format os de datos se especifican en el apar tado 8. Pueden aplicarse dataRecords de usuar io adicionales 
opcionales, que incluyan datos específico s de la VU, tanto intern os como de entrada y salida, pero no 
se definen en el present e documento. 
6.2.  Servicio WriteDat aByIdentif ier 
6.2.1  Descr ipción del mensaje 
CPR_056  El cliente utiliza el servicio WriteDataByIdentifi er para escr ibir valores de registros de datos en un 
servidor . Los datos se identif ican con un recordDataIdentifie r (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 siguiente s tablas se descr iben con detalle los format os de mensaj e para las primitivas WriteDa­
taByIdentifier . 
Tabla 29 
Mensaje WriteDat aByIdentif ier Request (petición de servicio WriteDat aByIdentif ier) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino EE TGT 
No 3 Byte de dirección de origen tt SRC 
No 4 Byte de longitud adicional m+3 LEN 
No 5 WriteDat aByIdentif ier Request Service Id (SId 
de petición de servicio WriteDataByIdentif ier) 2E WDBI 
Nos 6 a 7 recordDataIdentifier = [un valor de la Tabla 28] xxxx RDI_… 26.5.2016 L 139/300 Diar io Oficial de la Unión Europea ES    
No de byte Nombre del parámetro Valor hex Mnemónico 
No 8 a no 
m+7 dataRecord[] = [data#1 xx DREC_D ATA1 
: : : 
data#m] xx DREC_D ATAm 
No m+8 Suma de control 00-FF CS  
Tabla 30 
Mensaje WriteDataByIdentif ier Positiv e Response (respuest a positiva a la petición de servicio 
WriteDataByIdentif ier) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino tt TGT 
No 3 Byte de dirección de origen EE SRC 
No 4 Byte de longitud adicional 03 LEN 
No 5 WriteDat aByIdentif ier Positiv e Response Ser­
vice Id (SId de respuest a positiva a la petición 
de servicio WriteDataByIdentif ier) 6E WDBIPR 
Nos 6 a 7 recordDataIdentifier = [mismo valor que los bytes 
nos 6 y 7 de la Tabla 29] xxxx RDI_… 
No 8 Suma de control 00-FF CS  
Tabla 31 
Mensaje WriteDat aByIdentif ier Negativ e Response (respues ta negativa a la petición de servicio 
WriteDataByIdentif ier) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino tt TGT 
No 3 Byte de dirección de origen EE SRC 
No 4 Byte de longitud adicional 03 LEN 
No 5 Negativ eResponse Service Id (SId de respuest a 
negativa) 7F NR 
No 6 WriteDataByIdentif ier Request Service Id (SId de 
petición de servicio WriteDataByIdentif ier) 2E WDBI 26.5.2016 L 139/301 Diar io Oficial de la Unión Europea ES    
No de byte Nombre del parámetro Valor hex Mnemónico 
No 7 ResponseCode = [requestOutOfRange 31 RC_R OOR 
incor rectMessageL ength 13 RC_IML 
conditionsNotCor rect] 22 RC_CNC 
No 8 Suma de control 00-FF CS  
6.2.3  Definición del parámetr o 
El parámetro recor dDataIdentifier (RDI_) se define en la Tabla 28. 
El parámetro dataRecor d (DREC_) lo utiliza el mensaj e de petición WriteDataByIdentif ier para facilitar al 
servidor (VU) los valores de registros de datos identif icados por el recordDataIdentif ier. Los formatos de datos se 
especifi can en el 8. 
7.  CONTR OL DE LOS IMPULSOS DE PRUEBA — UNID AD FUNCIONAL PARA CON TROL DE ENTRAD A/SALID A 
Los servicios disponibles se descr iben con detalle en la siguiente tabla: 
Tabla 32 
Unidad funcional para control de entrada/salida 
Nombre del servicio Descr ipción 
InputOutputCont rolByIdentif ier El cliente solicita el control de una entrada/salida específica del servidor .  
7.1.  Servicio InputOutputControlByIdentif ier 
7.1.1  Descr ipción del mensaje 
Existe una conexión, a través del conect or frontal, que permite controlar 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 conf igurar con el comando de la línea K emplea ndo el 
servicio InputOutputControlByIdentifier para seleccionar la función de entrada 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 movimient o. Esta 
función no está disponible en el modo CONTR OL; 
—  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 
—  RTC Output, 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 CONTR OL. 
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 CONTR OL. 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 CONTR OL, 
solo pueden seleccionarse dos estados de la línea (desactivado y realTimeSpeedSignalOutputSensor). Al 
salir de la sesión de ajust e o del modo CALIBRA DO o CONTR OL, la unidad instalada en el vehículo 
debe cerciorarse de que la línea de señal I/O vuelve al estado «desactivado» (por defect o). 26.5.2016 L 139/302 Diar io Oficial de la Unión Europea ES    
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á conf igurada para transmitir entradas, entonces 
dicha línea de señal I/O deberá configurarse para transmitir salidas o deberá volver al estado de desacti ­
vación. 
CPR_061  Se seguirá el orden siguient e: 
—  establecer comunicación mediante el servicio Star tCommunication; 
—  entrar en una sesión de ajust e mediante el servicio Star tDiagnosticSession y estar en el modo 
CALIBRADO o CONTR OL (el orden de estas dos operaciones no es importante); y 
—  cambiar el estado de la salida mediante el servicio InputOutputCon trolBylIdentif ier. 
7.1.2  Formato del mensaje 
CPR_062 En las siguientes tablas se descr iben con detalle los formatos de mensaje para las primitivas InputOut ­
putControlByIdentifier . 
Tabla 33 
Mensaje InputOutputControlByIdentif ier Request (petición de control de entrada/salida) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino EE TGT 
No 3 Byte de dirección de origen tt SRC 
No 4 Byte de longitud adicional xx LEN 
No 5 InputOutputControlByIdentif ier Request SId 
(SId de petición de control de entrada/salida) 2F IOCBI 
Nos 6 y 7 Input OutputIdentif ier = [CalibrationInputOutput] F960 IOI_CIO 
No 8 o 
nos 8 a 9 ControlOp tionRecord = [  COR_… 
inputOut putControlParamet er — un valor de la 
Tabla 36 xx IOCP_… 
controlStat e — un valor de la Tabla 37 (véase la 
nota a continuación)] xx CS_… 
No 9 o 10 Suma de control 00-FF CS  
Nota: el parámetro controlState solo está present e en algunos casos (véase el apar tado 7.1.3). 
Tabla 34 
Mensaje InputOutputControlByIdentif ier Positiv e Response (respuest a positiva a la petición de 
control deentrada/salida) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino tt TGT 26.5.2016 L 139/303 Diar io Oficial de la Unión Europea ES    
No de byte Nombre del parámetro Valor hex Mnemónico 
No 3 Byte de dirección de origen EE SRC 
No 4 Byte de longitud adicional xx LEN 
No 5 inputOutputControlByIdentif ier Positiv e Res ­
ponse SId (SId de respuest a positiva a la peti ­
ción de control de entrada/salida) 6F IOCBIPR 
Nos 6 y 7 inputOut putIdentif ier = [CalibrationInputOutput] F960 IOI_CIO 
No 8 o 
nos 8 a 9 controlStatusRecord = [  CSR_ 
inputOut putControlParamet er (el mismo valor que 
en el byte no8 de la Tabla 33) xx IOCP_… 
controlStat e (mismo valor que byte no 9 de la Ta­
bla 33)] (en su caso) xx CS_… 
No 9 o 10 Suma de control 00-FF CS  
Tabla 35 
Mensaje InputOutputControlByIdentif ier Negativ e Response (respuest a negativa a la petición 
de control deentrada/salida) 
No de byte Nombre del parámetro Valor hex Mnemónico 
No 1 Byte de format o — asignación de dirección física 80 FMT 
No 2 Byte de dirección de destino tt TGT 
No 3 Byte de dirección de origen EE SRC 
No 4 Byte de longitud adicional 03 LEN 
No 5 Negativ eResponse Service Id (SId de respuest a 
negativa) 7F NR 
No 6 inputOut putControlByIdentif ier Request SId (SId 
de petición de control de entrada/salida) 2F IOCBI 
No 7 responseCode=[   
incor rectMessageL ength 13 RC_IML 
conditionsNotCor rect 22 RC_CNC 
requestOutOfRange 31 RC_R OOR 
deviceControlLimitsEx ceeded] 7A RC_DCLE 
No 8 Suma de control 00-FF CS  
7.1.3  Definición del parámetr o 
CPR_064  El parámetro inputOutputControl Parameter (IOCP_) se define en la siguient e tabla. 26.5.2016 L 139/304 Diar io Oficial de la Unión Europea ES    
Tabla 36 
Def inición de los valores inputOutputControlParameter 
Hex Descr ipción Mnemónico 
00 Retur nControlT oECU 
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 ResetT oDefault 
Este valor deberá indicar al servidor (VU) su oblig ación de reiniciar la se­
ñal de I/O de calibrado al estado que le corresponde por defecto. RTD 
03 Shor tTermAdjustment 
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 controlS ­
tate. STA  
CPR_065  El parámetro control State, definido en la siguient e tabla, solo está present e cuando el parámetro 
inputOut putControlParamet er se ha conf igurado a Shor tTermAdjustment. 
Tabla 37 
Def inición de valores controlState 
Modo Valor hex Descr ipción 
Desactivado 00 Línea I/O desactivada (estado por defecto) 
Activado 01 Línea I/O de calibrado activada como speedSignalInput 
Activado 02 Línea I/O de calibrado activada como realTimeSpeedSignalOut ­
putSensor 
Activado 03 Línea I/O de calibrado activada como RTC Output  
8.  FORMA TOS DATARECO RDS 
En el present e apar tado se detallan: 
—  las reglas general es que se aplicarán a los intervalos de los parámetros transmitidos por la unidad instalada en 
el vehículo al verificador; y 
—  los format os que se utilizarán en los datos transferidos a través de los servicios de transmisión de datos 
descr itos en el apar tado 6. 
CPR_067  La VU admitirá todos los parámetros identificad os. 
CPR_068  Los datos transmitidos por la VU al verificador en respuesta a un mensaj e de petición serán del tipo 
medido (es decir , el valor actual del parámetro solicitado medido u obser vado por el VU). 
8.1.  Inter valos 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. 26.5.2016 L 139/305 Diar io Oficial de la Unión Europea ES    
CPR_070  Los valores del intervalo «indicador de error» sirven para que la unidad instalada en el vehículo indique 
inmediatament e que no dispone en ese moment o de datos paramétr icos válidos por causa de algún 
tipo de error en el tacógraf o. 
CPR_071  Los valores del intervalo «no disponible» sirven para que la unidad instalada en el vehículo transmita 
un mensaj e que contiene un parámetro que no está disponible o no está admitido en ese módulo. Los 
valores del inter valo «no solicitado» constituyen un medio para que un dispositivo transmita un 
mensaj e de comando e identif ique para qué parámetros no se espera respuesta del dispositivo recep tor. 
CPR_072  Si el fallo de un component e impide la transmisión de datos válidos para un parámetro, deberá 
utilizarse en lugar de dichos datos el indicador de error descr ito en la Tabla 38. Sin embargo, si los 
datos medidos o calculados adquieren un valor que es válido, pero que excede del inter valo definido 
para el parámetro, no se utilizará el indicador de error. Se transmitirán los datos utilizando el valor 
mínimo o máximo del parámetro según proceda. 
Tabla 38 
Inter valos dataRecords 
Nombre del inter valo 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áme ­
tro FB FB00 a FBFF FB000000 a FBFFFFFF ninguno 
Reser vado para futuros bits de 
indicador 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 codificado s en ASCII, el caráct er ASCII «*» está reser vado como delimitador . 
8.2.  Format os 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 WriteDataByIdentif ier. 
CPR_074  En la Tabla 39 se ofrece la longitud, resolución e inter valo operativo de cada parámetro, identif icado 
por su recordDataIdentifier : 
Tabla 39 
Format o de dataRecords 
Nombre del parámetro Longitud de 
dato (bytes) Resolución Inter valo operativo 
TimeDat e 8 Véanse los detalles en la Tabla 40 
HighResolution TotalV ehicleDistance 4 avance 5 m/bit, inicio 0 m 0 a + 21 055 406 km 
Kfact or 2 avance 0,001 pulsos/m/bit, inicio 0 0 a 64,255 pulsos/m 
LfactorT yreCircumfe rence 2 avance 0,125 10– 3 m /bit, inicio 0 0 a 8,031 m 
WvehicleCharacter isticF actor 2 avance 0,001 pulsos/m/bit, inicio 0 0 a 64,255 pulsos/m 
TyreSize 15 ASCII ASCII 26.5.2016 L 139/306 Diar io Oficial de la Unión Europea ES    
Nombre del parámetro Longitud de 
dato (bytes) Resolución Inter valo operativo 
NextCalibrationDat e 3 Véanse los detalles en la Tabla 41 
SpeedAuthor ised 2 avance 1/256 km/h/bit, inicio 0 0 a 250,996 km/h 
Regist eringMemberState 3 ASCII ASCII 
VehicleRegistrationNumber 14 Véanse los detalles en la Tabla 42 
VIN 17 ASCII ASCII  
CPR_075  En la Tabla 40 se detallan los formatos de los distintos bytes del parámetro TimeDate: 
Tabla 40 
Format o detallado de TimeDate (valor recordDataIdentif ier # F90B) 
Byte Definición del parámetro Resolución Inter valo operativo 
1 Segundos avance 0,25 s/bit, inicio 0 s 0 a 59,75 s 
2 Minutos avance 1 min/bit, inicio 0 min 0 a 59 min 
3 Horas avance 1 h/bit, inicio 0 h 0 a 23 h 
4 Mes avance 1 mes/bit, 0 mes 1 a 12 meses 
5 Día avance 0,25 día/bit, 0 día 
(véase la nota de la Tabla 41) 0,25 a 31,75 días 
6 Año avance 1 año/bit, año + 1985 
(véase la nota de la Tabla 41) año 1985 a 2235 
7 Local Minute Offset avance 1 min/bit, inicio – 125 min – 59 a + 59 min 
8 Local Hour Offset avance 1 h/bit, inicio – 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 deta llado de NextCalibrationDate (valor recordData Identif ier # F922) 
Byte Definición del parámetro Resolución Inter valo operativo 
1 Mes avance 1 mes/bit, 0 mes 1 a 12 meses 
2 Día avance 0,25 día/bit, 0 día 
(véase la nota a continuación) 0,25 a 31,75 días 
3 Año avance 1 año/bit, año + 1985 
(véase la nota a continuación) año 1985 a 2235  26.5.2016 L 139/307 Diar io Oficial de la Unión Europea ES    
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 modifi ca. 
Nota relativa al uso del parámetro «Año»: 
el valor 0 para el año identifica el año 1985; el valor 1, el año 1986; etc. 
CPR_078  En la Tabla 42 se detallan los formatos de los distintos bytes del parámetro VehicleRegistrationNumber: 
Tabla 42 
Format o detallado de VehicleRegistrationNumber (valor recordDataIdentif ier # F97E) 
Byte Definición del parámetro Resolución Inter valo opera ­
tivo 
1 Página de código (según se define en el apéndice 
1) ASCII 01 a 0A 
2 — 14 Número de registro del vehículo (según se define 
en el apéndice 1) ASCII ASCII   26.5.2016 L 139/308 Diar io Oficial de la Unión Europea ES    
Apéndice 9. 
HOMOL OGA CIÓN LIST A DE PRUEBAS MÍNIMAS REQUERID AS 
ÍNDICE 
1. INTR ODUCCIÓN ..................................................................................................................................... 309 
2. PRUEBA S FUNCIONALES DE LA UNID AD INST ALADA EN EL VEHÍCULO ............................................................. 311 
3. PRUEBA S FUNCIONALES DEL SENSOR DE MOVIMIENTO ................................................................................ 315 
4. PRUEBA S FUNCIONALES DE LAS TARJET AS DE TACÓGRAFO .......................................................................... 318 
5. PRUEBA S DEL DISPOSITIV O GNSS EXTERNO ................................................................................................ 328 
6. PRUEBA S DE LA INST ALACIÓN DE COMUNICA CIÓN REMOT A......................................................................... 331 
7. PRUEBA S FUNCIONALES DEL PAPEL ........................................................................................................... 333 
8. PRUEBA S DE INTER OPERABILID AD ............................................................................................................. 335  
1.  INTR ODUCCIÓN 
1.1.  Homologación 
La homolog ación CE de un aparat o de control (o compo nente) o de una tarjeta de tacógraf o se basa en: 
—  una certificación de segur idad basada en criterios comunes especific ados para acreditar el cumplimient o de 
un objetivo de segur idad conf orme al apéndice 10 del presente anex o (a compl etar/modificar); 
—  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 present e anex o en cuant o a las funciones que 
desempeña, la exactitud de medición y las caract erísticas medioambientales; y 
—  una certificación de interoperabilidad, realizada por un organismo compe tent e, para garant izar que el 
aparato de control (o la tarjeta de tacógraf o) puede interoperar sin restr icciones con los modelos necesar ios de 
tarjeta de tacógraf o (o aparat o de control) (véase el apar tado 8 del present e anex o). 
En el present e apéndice se especifican las pruebas mínimas que debe realizar la autor idad del Estado miembro 
durant e los ensa yos funcionales, así como las pruebas mínimas que debe realizar el organismo compet ente durant e 
los ensa yos de inter operabilidad. No se determina el tipo de pruebas ni los procedimiento s a seguir durante las 
mismas. 
El presente apéndice no se ocupa de los aspectos relativos a la certificación de segur idad. Si durante la evaluación 
de segur idad y el proceso de certificación se llevan a cabo algunas de las pruebas exigidas para la homolog ación, 
no habrá que repetirlas posterior mente . En ese caso, tan solo se compr obarán los resultados de dichas pruebas de 
segur idad. A título informativo, en el present e apéndice hemos marcado con un aster isco («*») las condiciones que 
es preciso verificar (y también las condiciones estrechament e asociadas con pruebas que deban realizarse) durante la 
certificación de segur idad. 
Los requisitos numerados se refieren al cont enido de este anex o, 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 (pictog ramas)). 
El present e apéndice trata por separado la homologación del sensor de movimient o, de la unidad instalada en el 
vehículo y del dispositivo GNSS externo como compo nentes del aparato de control. Cada uno de los component es 
recibirá un certificado de homologación propio, en el que se indicarán el resto de compo nentes compatib les. La 
prueba de funcionalidad del sensor de movilidad (o del dispositivo GNSS externo) se realiza junto con la unidad 
instalada en el vehículo, y al contrar io. 
No se requiere inter operabilidad entre el sensor de movimient o (o el dispositivo GNSS externo) y cada modelo de la 
unidad instalada en el vehículo. En este caso, únicamente puede concederse la homolog ación de un sensor de 
movimient o (o de un dispositivo GNSS exte rno) en combinación con el tipo de aprobación de la unidad instalada 
en el vehículo pertinente, y al contrar io. 26.5.2016 L 139/309 Diar io Oficial de la Unión Europea ES    
1.2.  Referencias 
En el presente apéndice aparecen las siguient es 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, aleatori o 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 prote cción (código IP) — Protecci ón del equipo eléctr ico frente a 
objeto s extraños, al agua y al acceso. 
ISO 10605:2008 + Corrigendum técn ico 2010 + AMD1: 2014 Vehículos de carretera — Métodos de prueba para 
perturbaciones eléctr icas por descarga electrostática. 
ISO 7637-1:2002 + AMD1: 2008 Vehículos de carretera — Perturbaciones eléctr icas por conducción y 
acoplamient o — Parte 1: Defi niciones y consideraciones generales. 
ISO 7637-2 Vehículos de carretera — Perturbaciones eléctr icas por conducción y acoplamient o — Parte 2: 
Conducción eléctr ica transito ria por líneas de alimentación excl usivamente . 
ISO 7637-3 Vehículos de carretera — Perturbaciones eléctr icas por conducción y acoplamient o — Parte 3: 
Transmisión eléctr ica transito ria mediante acoplamient o capacitiv o e inductiv o por líneas que no sean de 
alimentación. 
ISO/IEC 7816-1 Tarjetas de identificación — Tarjetas de circuito(s) integrado(s) con contact os — Parte 1: Caracte ­
rísticas físicas. 
ISO/IEC 7816-2 Tecnología de la información — Tarjetas de identif icación — Tarjetas de circuito(s) integrad o(s) 
con contactos — Parte 2: Dimensiones y ubicación de los contact os. 
ISO/IEC 7816-3 Tecnología de la información — Tarjetas de identif icación — Tarjetas de circuito(s) integrad o(s) 
con contactos –Par te 3: Señales electrónicas y protocolo de transmisión. 
ISO/IEC 10373-1:2006 + AMD1:2012 Tarjetas de identificación — Métod os de prueba — Parte 1: Caracter ísticas 
generales 
ISO/IEC 10373-3:2010 + Corrigendum técnico 2013 Tarjetas de identif icación — Métodos de prueba — Parte 3: 
Tarjetas de circuitos integrados con contact os y dispositivos de interfaz relacionados 
ISO 16844-3:2004, Cor 1:2006 Vehículos de carretera — Sistema s de tacógraf o — Parte 3: Interfaz del sensor de 
movimient o (con las unidades intra vehiculares). 
ISO 16844-4 Vehículos de carretera — Sistemas de tacógraf o — Parte 4: Interfa z CAN 
ISO 16844-6 Vehículos de carretera — Sistemas de tacógraf o — Parte 6: Diagnóstico 26.5.2016 L 139/310 Diar io Oficial de la Unión Europea ES    
ISO 16844-7 Vehículos de carretera — Sistemas de tacógraf o — Parte 7: Parámetros 
ISO 534 Papel y cartón — Fijaci ón del grosor , la densidad y el volume n específico 
Reglamento CEPE no 10 sobre homologación de vehículos respecto a la compati bilidad electromagnética (Comisión 
Económica para Europa de las Naciones Unidas) 
2.  PRUEBAS FUNCIONALES DE LA UNID AD INST ALADA EN EL VEHÍCULO 
No Prueba Descr ipción Condiciones correspon ­
dient es 
1 Exa men administ rativ o 
1.1 Documentación Corrección de la documentación.  
1.2 Resultados de las 
pruebas del fabri­
cante Resultados de la prueba realizada por el fabricante durante 
la integraci ón. 
Demostraciones sobre papel. 88, 89, 91 
2 Inspección visual 
2.1 Cum plimiento de lo dispuest o en la documentación  
2.2 Identif icación/inscr ipciones 224 a 226 
2.3 Materiales 219 a 223 
2.4 Precintos 398, 401 a 405 
2.5 Interfa ces externas  
3 Pruebas funcionales 
3.1 Funciones disponibles 03, 04, 05, 07, 382 
3.2 Modos de funcionamient o 09 a 11*, 132, 133 
3.3 Funciones y derechos de acceso a los datos 12*, 13*, 382, 383, 
386 a 389 
3.4 Inserción y extracción de las tarjetas de super visión 15, 16, 17, 18, 19*, 
20*, 132 
3.5 Medición de la velocidad y la distancia 21 a 31 
3.6 Medición de la hora (ensa yo realizado a 20 °C) 38 a 43 
3.7 Super visión de las actividades del conduct or 44 a 53, 132 
3.8 Super visión del régimen de conducción 54, 55, 132 26.5.2016 L 139/311 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es 
3.9 Entradas manuales 56 a 62 
3.10 Gestión de los bloqueos introducidos por las empr esas 63 a 68 
3.11 Super visión de las actividades de control 69, 70 
3.12 Detección de incidentes o fallos 71 a 88 132 
3.13 Datos de identif icación del aparat o 93*, 94*, 97, 100 
3.14 Datos de inserción y extracción de la tarjeta del conduct or 102* a 104* 
3.15 Datos sobre la actividad del conductor 105* a 107* 
3.16 Datos sobre lugar es y posiciones 108* a 112* 
3.17 Datos del cuentakilómetros 113* a 115* 
3.18 Datos pormenor izados sobre la velocidad 116* 
3.19 Datos sobre incident es 117* 
3.20 Datos sobre fallos 118* 
3.21 Datos de calibrado 119* a 121* 
3.22 Datos de ajust e de la hora 124*, 125* 
3.23 Datos sobre actividades de control 126*, 127* 
3.24 Datos sobre los bloqueos introducidos por las empr esas 128* 
3.25 Datos sobre actividades de transfer encia 129* 
3.26 Datos sobre condiciones específi cas 130*, 131* 
3.27 Registro y almacenamiento de datos en tarjetas de tacógraf o 134, 135, 136*, 137*, 
139*, 140, 141 
142, 143, 144*, 145*, 
146*, 147, 148 
3.28 Visualización 90, 132, 
149 a 166 
PIC_001, DIS_001 
3.29 Imp resión 90, 132, 167 a 179, 
PIC_001, PRT_001 a 
PRT_014 
3.30 Advertencias 132, 180 a 189, 
PIC_001 26.5.2016 L 139/312 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es 
3.31 Transferencia de datos a medios externos 90, 132, 190 a 194 
3.32 Comunicación remota para pruebas en carretera específicas 195 a 197 
3.33 Envío de datos a dispositivo s extern os adicionales 198, 199 
3.34 Calibrado 202 a 206*, 383, 384, 
386 a 391 
3.35 Verificación del calibrado en carretera 207 a 209 
3.36 Ajuste de la hora 210 a 212* 
3.37 No interfe rencia con funciones adicionales 06, 425 
3.38 Interfa z del sensor de movimiento 02, 122 
3.39 Dispositivo GNSS exte rno 03, 123 
3.40 Comp robar si la VU detecta, registra y almacena el o los incident es o fallos des­
critos por el fabricante de la VU cuando un sensor de movimient o acoplado 
reaccione a los campos magnéticos perturbando la detec ción de movimiento 
del vehículo. 217 
3.41 Serie de cifrado y parámetros de dominio estandar izados CSM_48, CSM_50 
4 Pruebas ambienta les 
4.1 Temp eratura Verificar la funcionalidad mediante: 
Prueba en virtud de la ISO 16750-4, apar tado 5.1.1.2: 
prueba de funcionamient o 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, apar tado 5.1.2.2: 
prueba de funcionamiento a temperatura alta (72 h a 70 ° 
C). 
Esta prueba se refie re a la IEC 60068-2-2: Procedimient os 
básicos de verificación medioambiental; Parte 2: pruebas; 
Prueba B: Calor seco. 
Prueba en virtud de la ISO 16750-4, apar tado 5.3.2: cam ­
bio 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 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 du­
rante los ciclos de temperatura. 213 26.5.2016 L 139/313 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es 
4.2 Humedad Verificar que la unidad instalada en el vehículo puede so­
portar 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 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 sopor tar vibraciones sinusoidales de las siguientes ca­
racte rísticas: 
desplazamient o constante entre 5 y 11 Hz: pico de 
10 mm; y 
aceleración constante entre 11 y 300 Hz: 5 g. 
Esta exige ncia se verifica mediante la norma IEC 60068- 
2-6, prueba Fc, con una duración mínima de 3x12 ho­
ras (12 horas por cada eje). 
La ISO 16750-3 no requiere una prueba de vibración si­
nusoidal para dispositivos situados en el puesto de con­
ducción del vehículo desacoplado. 
2.  Vibraciones aleatori as: 
Prueba en virtud de la ISO 16750-3, apar tado 4.1.2.8: 
prueba VIII: vehículo comercial, puest o de conducción 
del vehículo desacoplado. 
Prueba de vibraciones aleat orias, 10-2 000 Hz, RMS 
vertical 21,3 m/s2, RMS longitudinal 11,8 m/s2, RMS la­
teral 13,1 m/s2, 3 ejes, 32 horas por eje, incluido un ci­
clo 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, aleat orio de banda ancha y orientación. 
3.  Choques: 
choque mecánico con semionda sinusoidal de 3 g de 
conf ormidad con la ISO 16750. 
Las pruebas arriba descr itas se llevan a cabo con muestras 
diferentes del tipo de equipo que se someta a prueba. 219 
4.4 Protecci ón frente 
a la penetración 
de agua y cuer ­
pos extraños Prueba en virtud de la ISO 20653: Vehículos de carretera 
— Niveles de prot ección (código IP) — Prot ección del 
equipo eléctr ico frente a objetos extraños, al agua y al ac­
ceso (sin cambio en los parámetros); valor mínimo IP 40. 220, 221 
4.5 Protecci ón frente 
a sobreten siones Verificar que la unidad instalada en el vehículo es capaz de 
sopor tar un suministro eléctr ico de: 216 
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)  
4.6 Protecci ón frente 
a la inversión de 
la polar idad Verificar que la unidad instalada en el vehículo es capaz de 
sopor tar una inversión de su fuente de alimentación. 
(ISO 16750-2) 216 26.5.2016 L 139/314 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es 
4.7 Protecci ón frente 
a cortocircuitos 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) 216 
5 Pruebas de compatibilidad electromagnética 
5.1 Emisiones radia ­
das y susceptibili ­
dad Cum plimiento del Reglamento no 10 de la CEPE. 218 
5.2 Descarg a electro ­
stática Cum plimiento de la norma ISO 10605: 2008 + Corrigen ­
dum Técnico 2010 + AMD1: 2014: +/– 4 kV para contacto 
+/– 8 kV para descarga de aire. 218 
5.3 Suscept ibilidad 
transito ria condu ­
cida en la fuent e 
de alimentación Para versiones 24 V: cumplim iento de la ISO 7637-2 + Re­
glamento no 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: cumplim iento de la ISO 7637-1 + Re­
glamento no 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 excl usivamente en las unida ­
des intraveh iculares concebidas para ser instaladas en ve­
hículos que no dispongan de prot ección común exte rna 
contra volcado de la carga. 
Para las propuestas de volcado de la carg a, remítase a la 
ISO 16750-2, 4a edición, apar tado 4.6.4. 218  
3.  PRUEBAS FUNCIONALES DEL SENSOR DE MOVIMIENTO 
No Prueba Descr ipción Condiciones correspon ­
dient es 
1. Exa men administ rativ o 
1.1 Documentación Corrección de la documentación.  26.5.2016 L 139/315 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es 
2. Inspección visual 
2.1. Cum plimiento de lo dispuest o en la documentación  
2.2. Identif icación/inscr ipciones 225, 226 
2.3 Materiales 219 a 223 
2.4. Precintos 398, 401 a 405 
3. Pruebas funcionales 
3.1 Datos de identif icación del sensor 95 a 97* 
3.2 Empar ejamiento del sensor de movimiento y la unidad instalada en el vehículo 122*, 204 
3.3 Detección de movimient o 
Precisión de la medición del movimient o. 30 a 35 
3.4 Interfa z de la unidad instalada en el vehículo 02 
3.5 Comp robar si el sensor de movimiento es invulnerab le a los campos magnéti ­
cos constant es. De forma alternativa, comprobar si el sensor de movimiento 
reacciona a los campos magnéticos constantes perturbando la detección de mo­
vimient o del vehículo a fin de que la VU conectada pueda detectar , registrar y 
almacenar los fallos del sensor . 217 
4. Pruebas ambienta les 
4.1 Temp eratura de 
funcionamient o Verificar la funcionalidad (tal y como se define en la prueba 
no 3.3) en el inter valo de temperaturas [– 40 °C; + 135 °C] 
mediante: 
IEC 60068-2-1: prueba Ad, con una duración de 96 horas 
a la temperatura más baja Tomín. 
IEC 60068-2-2: prueba Bd, con una duración de 96 horas 
a la temperatura más alta Tomáx. 
Prueba en virtud de la ISO 16750-4, sección 5.1.1.2: 
prueba de funcionamient o a temperatura baja (24 h a 
– 40 °C). 
Esta prueba se refiere a la IEC 60068-2-1: Verificación me­
dioambiental — Parte 2-1: Pruebas — Prueba A: Frío. IEC 
68-2-2: prueba Bd, con una duración de 96 horas a la tem ­
peratura más baja de – 40 °C. 
Prueba en virtud de la ISO 16750-4, apar tado 5.1.2.2: 
prueba de funcionamiento a temperatura alta (96 h a 135 ° 
C). 
Esta prueba se refie re a la IEC 60068-2-2: Procedimient os 
básicos de verificación medioambiental; Parte 2: pruebas; 
Prueba B: Calor seco. 213 26.5.2016 L 139/316 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es 
4.2 Ciclos de tempe­
ratura Prueba en virtud de la ISO 16750-4, apar tado 5.3.2: cam ­
bio rápido de temperatura con una duración de transición 
específica (– 40 °C/135 °C, 20 ciclos, tiempo: 30 minutos 
en cada temperatura). 
IEC 60068-2-14: Verificación medioambiental — Parte 2- 
14: Pruebas — Prueba N: Variaciones de la temperatura. 213 
4.3 Ciclos de hume ­
dad Verificar la funcionalidad (tal y como se define en la prueba 
no 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 
4.4 Vibración ISO 16750-3: apar tado 4.1.2.6: prueba VI: vehículo comer ­
cial, 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/s2, <= 0,5 oct/min; y 
b)  una prueba de vibración aleatori a, 10-2 000 Hz, RMS 
177 m/s2 
94 horas por eje, incluido un ciclo de temperatura 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: Vibra ­
ción — Modo combinado 219 
4.5 Choque mecá ­
nico ISO 16750-3: apar tado 4.2.3: prueba VI: prueba para los 
dispositivo s situados en el interior o en la superf icie de la 
caja de cambios. 
Choque semisinusoidal, aceleración acordada de entre 
3 000 y 15 000 m/s2, duración del impulso acordada, sin 
embargo (< 1 ms), número de choques acordados. 
Esta prueba se refiere a la IEC 60068-2-27: Verificación 
medioambiental — Parte 2: Pruebas. Prueba Ea y orien­
tación: Choque. 219 
4.6 Protecci ón frente 
a la penetración 
de agua y cuer ­
pos extraños Prueba en virtud de la ISO 20653: Vehículos de carretera 
— Niveles de prot ección (código IP) — Prot ección del 
equipo eléctr ico frente a objetos extraños, al agua y al ac­
ceso 
(valor objetivo IP 64). 220, 221 
4.7 Protecci ón frente 
a la inversión de 
la polar idad Verificar que el sensor de movimiento es capaz de sopor tar 
una inve rsión de su fuente de alimentación. 216 
4.8 Protecci ón frente 
a cortocircuitos 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. 216 26.5.2016 L 139/317 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es 
5. Compatibilidad electromagnética 
5.1 Emisiones radia ­
das y susceptibili ­
dad Verificar el cumpli miento del Reglamento no 10 de la CEPE. 218 
5.2 Descarg a electro ­
stática Cum plimiento de la norma ISO 10605: 2008 + Corrigen ­
dum Técnico 2010 + AMD1: 2014: +/–  4 kV para con­
tacto +/–  8 kV para descarg a de aire. 218 
5.3 Suscept ibilidad 
transito ria condu ­
cida en las líneas 
de datos Para versiones 24 V: cumplim iento de la ISO 7637-2 + Re­
glamento no 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: cumplim iento de la ISO 7637-1 + Re­
glamento no 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 excl usivamente en las unida ­
des intraveh iculares concebidas para ser instaladas en ve­
hículos que no dispongan de prot ección común exte rna 
contra volcado de la carga. 
Para las propuestas de volcado de la carg a, remítase a la 
ISO 16750-2, 4a edición, apar tado 4.6.4. 218  
4.  PRUEBAS FUNCIONALES DE LAS TARJET AS DE TACÓGRAF O 
Las pruebas previstas en el apar tado 4, 
no 5 «Pruebas de protocolo », 
no 6 «Estr uctura de la tarjeta» y 
no 7 «Pruebas funcionales» 
puede llevarlas a cabo el evaluador o el certificador durante el proceso de certificación de la segur idad 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 cuer po de la tarjeta con 
el módulo del chip. Deben realizarse estas pruebas cuando se modifi que uno de estos compo nent es (cuer po de la 
tarjeta o módulo del chip). 26.5.2016 L 139/318 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es 
1. Exa men administ rativ o 
1.1 Documentación Corrección de la documentación.  
2 Cuer po de la tarjeta 
2.1 Diseño impreso Cerciorarse de que todas las características de prote cción y 
todos los datos visibles están bien impresos en la tarjeta y 
se ajustan a la normativa. 
[Designador] 
Anex o 1C, apar tado 4.1 (datos visibles), 227 
El anverso de la tarjeta conte ndrá: 
la mención «Tarjeta del conduct or», «Tarjeta de control», 
«Tarjeta de taller» o «Tarjeta de empr esa», en mayúsculas 
y en el o los idiomas oficiales del Estado miembro que 
expida la tarjeta, según el tipo de tarjeta. 
[Nombre del Estado miembro] 
Anex o 1C, apar tado 4.1 (datos visibles), 228 
El anverso de la tarjeta conte ndrá: 
el nombre del Estado miembro que expida la tarjeta (op­
cional). 
[Firma] 
Anex o 1C, apar tado 4.1 (datos visibles), 229 
El anverso de la tarjeta conte ndrá: 
el distintivo del Estado miembro que expida la tarjeta, 
impreso en negat ivo en un rectángulo azul rodeado de 
doce estrellas amar illas. 
[Numeración] 
Anex o 1C, apar tado 4.1 (datos visibles), 232 
El reverso de la tarjeta conte ndrá: 
una explicación de las rúbr icas numeradas que aparecen 
en la primera página de la tarjeta. 
[Color] 
Anex o 1C, apar tado 4.1 (datos visibles), 234 
Las tarjetas de tacógraf o deberán impr imirse con los si­
guientes colores de fondo predominante s: 
—  tarjeta del conductor: blanco, 
—  tarjeta de taller: rojo, 
—  tarjeta de control: azul, 
—  tarjeta de empr esa: amar illo.  227 a 229, 232, 234 a 
236 26.5.2016 L 139/319 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es  
[Segur idad] 
Anex o 1C, apar tado 4.1 (datos visibles), 235 
Las tarjetas de tacógraf o deberán reunir al menos las si­
guientes caract erísticas de protección contra intent os de 
falsif icación y manipulación: 
—  un fondo con diseño de segur idad, fondo labrado e 
impresión en arco iris, 
—  al menos una línea de microim presión bicolor . 
[Marcas] 
Anex o 1C, apar tado 4.1 (datos visibles), 236 
Los Estados miembros podrán añadir colores o marcas, 
como por ejemplo símbolos nacionales o caract erísticas 
de segur idad. 
[Marca de homologación] 
Las tarjetas de tacógraf o deberán incluir una marca de 
homolog ación. 
La marca de homologació n estará compuesta por: 
—un rectángulo en el que se inscr iba la letra «e» minús ­
cula seguida de un número distintiv o o de una letra 
distintiva del país que haya expedido una homologa ­
ción; y 
—un número de homologa ción correspondiente al nú­
mero de la ficha de homologació n de la tarjeta del ta­
cógraf o, colocado en cualquier posición cerca del rec­
tángulo.      
2.2 Ensa yos 
mecánicos  240, 243 
ISO/IEC 7810   [Tamaño de la tarjeta] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7810: Tarjetas de identif icación — Caracter ísti­
cas 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ógraf o deben ser conf ormes a la norma 
ISO/IEC 7810: Tarjetas de identif icación — Caracter ísti­
cas físicas: 
[5] Dimensiones de la tarjeta 
[5.1] Tamaño de la tarjeta 
[5.1.2] Bordes de la tarjeta  26.5.2016 L 139/320 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es    
[Fabricación de la tarjeta] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7810: Tarjetas de identif icación — Caracter ísti­
cas físicas: 
[6] Fabri cación de la tarjeta 
[Materiales de la tarjeta] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7810: Tarjetas de identif icación — Caracter ísti­
cas físicas: 
[7] Materi ales de la tarjeta 
[Resisten cia a la flexión] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7810: Tarjetas de identif icación — Caracter ísti­
cas físicas: 
[8] Caracter ísticas de la tarjeta 
[8.1] Resistencia a la flexión 
[Toxicidad] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7810: Tarjetas de identif icación — Caracter ísti­
cas físicas: 
[8] Caracter ísticas de la tarjeta 
[8.3] Toxicidad 
[Resisten cia a los agentes químicos] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7810: Tarjetas de identif icación — Caracter ísti­
cas físicas: 
[8] Caracter ísticas de la tarjeta 
[8.4] Resistencia a los agentes químicos 
[Estabilidad de la tarjeta] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7810: Tarjetas de identif icación — Caracter ísti­
cas físicas: 
[8] Caracter ísticas de la tarjeta 
[8.5] Estabilidad dimensional de la tarjeta y alabeado con 
la temperatura y la humedad  26.5.2016 L 139/321 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es    
[Lige ra] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7810: Tarjetas de identif icación — Caracter ísti­
cas físicas: 
[8] Caracter ísticas de la tarjeta 
[8.6] Lige ra 
[Durabilidad] 
Anex o 1C, apar tado 4.4 (especifi caciones ambientales y 
eléctr icas), 241 
Las tarjetas de tacógraf o deberán poder funcionar correc­
tament e durante cinco años si se utilizan con arreglo a 
las especifi caciones ambientales y eléctr icas. 
[Resisten cia de la superf icie] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7810: Tarjetas de identif icación — Caracter ísti­
cas físicas: 
[8] Caracter ísticas de la tarjeta 
[8.8] Resistencia de la superf icie 
[Adherencia o bloqueo] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7810: Tarjetas de identif icación — Caracter ísti­
cas físicas: 
[8] Caracter ísticas de la tarjeta 
[8.9] Adherencia o bloqueo 
[Alabeado] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7810: Tarjetas de identif icación — Caracter ísti­
cas físicas: 
[8] Caracter ísticas de la tarjeta 
[8.11] Alabeado general de la tarjeta 
[Resisten cia al calor] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7810: Tarjetas de identif icación — Caracter ísti­
cas físicas: 
[8] Caracter ísticas de la tarjeta 
[8.12] Resistencia al calor  26.5.2016 L 139/322 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es    
[Distor siones de la superf icie] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7810: Tarjetas de identif icación — Caracter ísti­
cas físicas: 
[8] Caracter ísticas de la tarjeta 
[8.13] Distorsiones de la superf icie 
[Contaminación] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7810: Tarjetas de identif icación — Caracter ísti­
cas físicas: 
[8] Caracter ísticas de la tarjeta 
[8.14] Contaminación e interacción entre los componen ­
tes de la tarjeta   
2.3 Pruebas 
mecánicas con el 
módulo de chip 
integrad o [Flexión] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7810:2003/Amd. 1:2009, Tarjetas de identif ica­
ción — Características físicas, enmienda 1: criterios para 
las tarjetas que contienen circuitos integrados: 
[9.2] Tensión por flexión dinámica 
No total de ciclos de flexión: 4 000. 
[Torsión] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7810:2003/Amd. 1:2009, Tarjetas de identif ica­
ción — Características físicas, enmienda 1: criterios para 
las tarjetas que contienen circuitos integrados: 
[9.3] Tensión por torsión dinámica 
No 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 superf icie] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7816-1:2011: Tarjetas de identif icación — Tar­
jetas con circuitos integrados con contact os — Parte 1: 
Tarjetas con contactos — Caracter ísticas físicas: 
[4.2] Perfil de la superf icie de los contact os  ISO/IEC 7816 26.5.2016 L 139/323 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es  
[Resisten cia mecánica] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7816-1:2011: Tarjetas de identif icación — Tar­
jetas con circuitos integrados con contact os — Parte 1: 
Tarjetas con contactos — Caracter ísticas físicas: 
[4.3] Resistencia mecánica (de una tarjeta y de los con­
tactos) 
[Resisten cia eléctr ica] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7816-1:2011: Tarjetas de identif icación — Tar­
jetas con circuitos integrados con contact os — Parte 1: 
Tarjetas con contactos — Caracter ísticas físicas: 
[4.4] Resistencia eléctr ica (de los contact os) 
[Dimensiones] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7816-2:2007: Tarjetas de identif icación — Tar­
jetas con circuitos integrados con contact os — Parte 2: 
Tarjetas con contact os — Dimensiones y localización de 
los contact os: 
[3] Dimensiones de los contactos 
[Localización] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7816-2:2007: Tarjetas de identif icación — Tar­
jetas con circuitos integrados con contact os — Parte 2: 
Tarjetas con contact os — Dimensiones y localización de 
los contact os: 
[4] Número y localización de los contactos 
En caso de los módulos con seis contact os, los contact os 
C4 y C8 no están sujetos a este requisito.      
4 Chip 
4.1 Chip  241 a 244 
Reglamento no 10 de la 
CEPE 
ISO/IEC 7810 
ISO/IEC 10373   [Temperatura de funcionamient o] 
El chip de la tarjeta de tacógraf o funcionará a una tempe­
ratura ambiente de entre –25 °C y +85 °C.  26.5.2016 L 139/324 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es    
[Temperatura y humedad] 
Anex o 1C, apar tado 4.4 (especifi caciones ambientales y 
eléctr icas), 241 
Las tarjetas de tacógraf o deberán estar en condiciones de 
funcionar correctamente bajo cualquier condición climá ­
tica habitual en el territori o de la Comunidad y al menos 
en el inter valo de temperaturas comprendido entre – 
25 °C y + 70 °C, con picos ocasionales de hasta + 85 °C 
(«ocasional» signif ica 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ógraf o se exponen en fases consecuti ­
vas a las siguiente s temperaturas y humedades durante 
un tiempo fijado. Se verifica la funcionalidad eléctr ica de 
las tarjetas de tacógraf o después de cada una de las fases. 
1.  Temperatura de – 20 °C durante 2 horas. 
2.  Temperatura de +/– 0 °C durant e 2 horas. 
3.  Temperatura de + 20 °C y humedad relativa del 50 % 
durant e 2 horas. 
4.  Temperatura de + 50 °C y humedad relativa del 50 % 
durant e 2 horas. 
5.  Temperatura de + 70 °C y humedad relativa del 50 % 
durant e 2 horas. 
La temperatura se aumenta intermitent emente hasta + 
85 °C, con una humedad relativa del 50 %, durant e 
60 min. 
6.  Temperatura de + 70 °C y humedad relativa del 85 %, 
durant e 2 horas. 
La temperatura se aumenta intermitent emente hasta + 
85 °C, con una humedad relativa del 85 %, durant e 
30 min. 
[Humedad] 
Anex o 1C, apar tado 4.4 (especifi caciones ambientales y 
eléctr icas), 242 
Las tarjetas de tacógraf o deberán poder funcionar correc­
tament e en el inter valo higrométr ico compr endido entre 
el 10 % y el 90 %. 
[Com patibilidad electromagnética (CEM)] 
Anex o 1C, apar tado 4.4 (especifi caciones ambientales y 
eléctr icas), 244 
Cuando se encuentren en funcionamient o, las tarjetas de 
tacógraf o deberán cumpli r el Reglamento no 10 de la 
CEPE en lo relativ o a la compati bilidad electromagnética.   26.5.2016 L 139/325 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es  
[Electr icidad estática] 
Anex o 1C, apar tado 4.4 (especifi caciones ambientales y 
eléctr icas), 244 
Cuando se encuentren en funcionamient o, las tarjetas de 
tacógraf o deberán estar protegi das contra descarg as elec­
troestáticas. 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7810:2003/Amd. 1:2009: Tarjetas de identif ica­
ción — Características físicas, enmienda 1: criterios para 
las tarjetas que contienen circuitos integrados: 
[9.4] Electr icidad estática 
[9.4.1] Tarjetas de contacto IC 
Tensión de volta je: 4 000 V 
[Rayos X] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7810:2003/Amd. 1:2009, Tarjetas de identif ica­
ció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 identif icación — Mé­
todos de prueba — Parte 1: Caracte rísticas generales 
[5.11] Luz ultra violeta 
[3 ruedas] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 10373-1:2006/Amd. 1:2012, Tarjetas de identi ­
ficación — Métodos de prueba — Parte 1: Caract erísticas 
generales, Enmienda 1: 
[5.22] ICC — Resistencia mecánica: prueba de las tres 
ruedas para ICC con contactos 
[Env oltura] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
Mast erCard CQM V2.03:2013 
[11.1.3] R-L3-14-8: Prueba de la firmeza del envoltorio 
[13.2.1.32] TM-422: Fiabilidad mecánica: Prueba del en­
voltor io  26.5.2016 L 139/326 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es 
4.2 Pruebas 
mecánicas del 
módulo del chip 
inser tado en el 
cuer po de la 
tarjeta –> ídem 
2.3 [Flexión] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7810:2003/Amd. 1:2009, Tarjetas de identif ica­
ción — Características físicas, enmienda 1: criterios para 
las tarjetas que contienen circuitos integrados: 
[9.2] Tensión por flexión dinámica 
No total de ciclos de flexión: 4 000. 
[Torsión] 
Las tarjetas de tacógraf o deben ser conf ormes a la norma 
ISO/IEC 7810:2003/Amd. 1:2009, Tarjetas de identif ica­
ción — Características físicas, enmienda 1: criterios para 
las tarjetas que contienen circuitos integrados: 
[9.3] Tensión por torsión dinámica 
No total de ciclos de torsión: 4 000.  ISO/IEC 7810 
5 Pruebas de prot ocolos 
5.1 ATR Comp robar si el ATR es conf orme. ISO/IEC 7816-3 
TCS_14, TCS_17, 
TCS_18 
5.2 T=0 Comp robar si el protocolo T=0 es conf orme. ISO/IEC 7816-3 
TCS_11, TCS_12, 
TCS_13, TCS_15 
5.3 PTS Comp robar si el comando PTS es conf orme. Para ello, 
ajus tar T=1 partiendo de T=0. ISO/IEC 7816-3 
TCS_12, TCS_19, 
TCS_20, TCS_21 
5.4 T=1 Comp robar si el protocolo T=1 es conf orme. ISO/IEC 7816-3 
TCS_11, TCS_13, 
TCS_16 
6 Estr uctura de la tarjeta 
6.1  Comp robar si la estructura de arch ivos de la tarjeta es 
conf orme. Para ello, verificar la presencia de los archiv os 
oblig ator ios 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 autori zado de 
cada comando (por ejemplo, verificar el comando UPD ATE 
BINAR Y con CLA=00, CLA=0C y con diferentes 
parámetros P1, P2 y Lc). 
Comp robar que las operaciones se han llevado a cabo en la 
tarjeta (por ejemplo, leyendo el archiv o donde se ha 
ejecutado el comando). TCS_29 a TCS_139 26.5.2016 L 139/327 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es 
7.2 Mensaj es de error Comp robar al menos una vez cada uno de los mensaj es de 
error (especifi cados en el apéndice 2) para cada comando. 
Comp robar al menos una vez cada uno de los errores 
genéricos (excep to los errores de integridad ‘6400’ 
verificados durant e la certificación de segur idad).  
7.3 Serie de cifrado y parámetros de dominio estandar izados CSM_48, CSM_50 
8 Personalización 
8.1 Personalización 
óptica Anex o 1C, apar tado 4.1 (datos visibles), 230 
El anverso de la tarjeta conte ndrá: 
información específi ca de la tarjeta expedida. 
Anex o 1C, apar tado 4.1 (datos visibles), 231 
El anverso de la tarjeta conte ndrá: 
las fechas en formato «dd/mm/aaaa» o «dd.mm.aaaa» (día, 
mes, año). 
Anex o 1C, apar tado 4.1 (datos visibles), 235 
Las tarjetas de tacógraf o deberán reunir al menos las si­
guientes caract erísticas de protección contra intent os de 
falsif icación y manipulación: 
—en la zona de la fotografía, el fondo con diseño de se­
guridad y la fotografía deberán solaparse.  230, 231, 235  
5.  PRUEBAS DEL DISPOSITIV O GNSS EXTERNO 
No Prueba Descr ipción Condiciones correspon ­
dient es 
1. Exa men administ rativ o 
1.1 Documentación Corrección de la documentación.  
2. Inspección visual del dispositiv o GNSS exter no 
2.1. Cum plimiento de lo dispuest o en la documentación  
2.2. Identif icación/inscr ipciones 224 a 226 
2.3 Materiales 219 a 223 
3. Pruebas funcionales 
3.1 Datos de identif icación del sensor 98, 99 
3.2 Acoplamiento entre el módulo GNSS externo y la unidad instalada en el vehícu ­
lo 123, 205 26.5.2016 L 139/328 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es 
3.3 Posición GNSS 36, 37 
3.4 Interfa z de la unidad instalada en el vehículo cuando el recept or GNSS es ex­
terno a la unidad 03 
3.5 Serie de cifrado y parámetros de dominio estandar izados CSM_48, CSM_50 
4. Pruebas ambienta les 
4.1 Temp eratura Verificar la funcionalidad mediante: 
Prueba en virtud de la ISO 16750-4, apar tado 5.1.1.2: 
prueba de funcionamient o 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, apar tado 5.1.2.2: 
prueba de funcionamiento a temperatura alta (72 h a 70 ° 
C). 
Esta prueba se refie re a la IEC 60068-2-2: Procedimient os 
básicos de verificación medioambiental; Parte 2: pruebas; 
Prueba B: Calor seco. 
Prueba en virtud de la ISO 16750-4, apar tado 5.3.2: cam ­
bio rápido de temperatura con una duración de transició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 du­
rante los ciclos de temperatura. 213 
4.2 Humedad Verificar que la unidad instalada en el vehículo puede so­
portar 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 sopor tar vibraciones sinusoidales de las siguientes ca­
racte rísticas: 
desplazamient o constante entre 5 y 11 Hz: pico de 
10 mm; y 
aceleración constante entre 11 y 300 Hz: 5 g. 
Esta exige ncia se verifica mediante la norma IEC 60068- 
2-6, prueba Fc, con una duración mínima de 3 × 12 ho­
ras (12 horas por cada eje). 
La ISO 16750-3 no requiere una prueba de vibración si­
nusoidal para dispositivos situados en el puesto de con­
ducción del vehículo desacoplado.  219 26.5.2016 L 139/329 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es 
2.  Vibraciones aleatori as: 
Prueba en virtud de la ISO 16750-3, apar tado 4.1.2.8: 
prueba VIII: vehículo comercial, puest o de conducción 
del vehículo desacoplado. 
Prueba de vibraciones aleat orias, 10-2 000 Hz, RMS 
vertical 21,3 m/s2, RMS longitudinal 11,8 m/s2, RMS la­
teral 13,1 m/s2, 3 ejes, 32 horas por eje, incluido un ci­
clo 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, aleat orio de banda ancha y orientación. 
3.  Choques: 
choque mecánico con semionda sinusoidal de 3 g de 
conf ormidad con la ISO 16750. 
Las pruebas arriba descr itas 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 cuer ­
pos extraños Prueba en virtud de la ISO 20653: Vehículos de carretera 
— Niveles de prot ección (código IP) — Prot ección del 
equipo eléctr ico frente a objetos extraños, al agua y al ac­
ceso (sin cambio en los parámetros). 220, 221 
4.5 Protecci ón frente 
a sobreten siones Verificar que la unidad instalada en el vehículo es capaz de 
sopor tar un suministro eléctr ico 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, apar tado 4.3) 
4.6 Protecci ón frente 
a la inversión de 
la polar idad Verificar que la unidad instalada en el vehículo es capaz de 
sopor tar una inversión de su fuente de alimentación. 
(ISO 16750-2, apar tado 4.7) 216 
4.7 Protecci ón frente 
a cortocircuitos 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, apar tado 4.10) 216 
5 Pruebas de compatibilidad electromagnética 
5.1 Emisiones radia ­
das y susceptibili ­
dad Cum plimiento del Reglamento no 10 de la CEPE. 218 26.5.2016 L 139/330 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es 
5.2 Descarg a electro ­
stática Cum plimiento de la norma ISO 10605: 2008 + Corrigen ­
dum Técnico 2010 + AMD1: 2014: +/– 4 kV para contacto 
+/– 8 kV para descarga de aire. 218 
5.3 Suscept ibilidad 
transito ria condu ­
cida en la fuent e 
de alimentación Para versiones 24 V: cumplim iento de la ISO 7637-2 + Re­
glamento no 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: cumplim iento de la ISO 7637-1 + Re­
glamento no 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 excl usivamente en las unida ­
des intraveh iculares concebidas para ser instaladas en ve­
hículos que no dispongan de prot ección común exte rna 
contra volcado de la carga. 
Para las propuestas de volcado de la carg a, remítase a la 
ISO 16750-2, 4a edición, apar tado 4.6.4. 218  
6.  PRUEBAS DE LA INST ALACIÓN DE COMUNIC ACIÓN REMOT A 
No Prueba Descr ipción Condiciones correspon ­
dient es 
1. Exa men administ rativ o 
1.1 Documentación Corrección de la documentación.  
2. Inspección visual 
2.1. Cum plimiento de lo dispuest o en la documentación  
2.2. Identif icación/inscr ipciones 225, 226 
2.3 Materiales 219 a 223 26.5.2016 L 139/331 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es 
4. Pruebas ambienta les 
4.1 Temp eratura Verificar la funcionalidad mediante: 
Prueba en virtud de la ISO 16750-4, apar tado 5.1.1.2: 
prueba de funcionamient o 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, apar tado 5.1.2.2: 
prueba de funcionamiento a temperatura alta (72 h a 70 ° 
C). 
Esta prueba se refie re a la IEC 60068-2-2: Procedimient os 
básicos de verificación medioambiental; Parte 2: pruebas; 
Prueba B: Calor seco. 
Prueba en virtud de la ISO 16750-4, apar tado 5.3.2: cam ­
bio rápido de temperatura con una duración de transició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 du­
rante los ciclos de temperatura. 213 
4.4 Protecci ón frente 
a la penetración 
de agua y cuer ­
pos extraños Prueba en virtud de la ISO 20653: Vehículos de carretera 
— Niveles de prot ección (código IP) — Prot ección del 
equipo eléctr ico frente a objetos extraños, al agua y al ac­
ceso (valor objetivo IP40) 220, 221 
5 Pruebas de compatibilidad electromagnética 
5.1 Emisiones radia ­
das y susceptibili ­
dad Cum plimiento del Reglamento no 10 de la CEPE. 218 
5.2 Descarg a electro ­
stática Cum plimiento de la norma ISO 10605: 2008 + Corrigen ­
dum Técnico 2010 + AMD1: 2014: +/–  4 kV para con­
tacto +/–  8 kV para descarg a de aire. 218 
5.3 Suscept ibilidad 
transito ria condu ­
cida en la fuent e 
de alimentación Para versiones 24 V: cumplim iento de la ISO 7637-2 + Re­
glamento no 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.  218 26.5.2016 L 139/332 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es 
Para versiones 12 V: cumplim iento de la ISO 7637-1 + Re­
glamento no 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 excl usivamente en las unida ­
des intraveh iculares concebidas para ser instaladas en ve­
hículos que no dispongan de prot ección común exte rna 
contra volcado de la carga. 
Para las propuestas de volcado de la carg a, remítase a la 
ISO 16750-2, 4a edición, apar tado 4.6.4.  
7.  PRUEBAS FUNCIONALES DEL PAPEL 
No Prueba Descr ipción Condiciones correspon ­
dient es 
1. Exa men administ rativ o 
1.1 Documentación Corrección de la documentación.  
2 Pruebas generales 
2.1 Número de carac ­
teres por línea Inspección visual de los documentos de impresión. 172 
2.2 Tamaño mínimo 
de los caracte res Inspección visual de los documentos de impresión e inspec ­
ción de los caracte res. 173 
2.3 Conjuntos de ca­
racte res admiti ­
dos La impresora admitirá el uso de los caracteres especificados 
en el apéndice 1, apar tado 4 (Conjuntos de caracte res). 174 
2.4 Defi nición de los 
documentos de 
imp resión Verificación de la homologa ción del tacógraf o e inspección 
visual de los documentos de impresión. 174 
2.5 Legibilidad e 
identif icación de 
los documentos 
de impresión Inspección de los documentos de impresión. 
Demostración mediante los informes de prueba y los proto ­
colos de verificación del fabricante. 
Todos los números de homolog ación de los tacógraf os con 
los que se pueda emplear la impresora están impresos en el 
papel. 175, 177, 178 
2.6 Inclusión de no­
tas escr itas a 
mano Inspección visual: Exist encia de un espacio para la firma del 
conductor . 
Existencia de espacios para la inclusión de otros textos es­
critos a mano. 180 26.5.2016 L 139/333 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es 
2.7 Detalles adiciona ­
les en el papel Tanto el anver so como el reverso del papel pueden incluir 
detalles o información adicionales. 
Estos últimos no podrán alterar la legibilidad de los docu ­
mentos de impresión. 
Inspección visual. 177, 178 
3 Pruebas de almacenamient o 
3.1 Calor seco Preacondicionamiento: 16 horas a +23 °C ±2 °C/humedad 
relativa del 55 % ±3 % 
Prueba ambiental: 72 horas a +70 °C ±2 °C 
Recuperación: 16 horas a +23 °C ±2 °C/humedad relativa 
del 55 % ±3 % 176, 178 
IEC 60068-2-2-Bb 
2.2 Calor húmedo Preacondicionamiento: 16 horas a +23 °C ±2 °C/humedad 
relativa del 55 % ±3 % 
Prueba ambiental: 144 horas a +55 °C ±2 °C/humedad rela­
tiva del 93 % ±3 % 
Recuperación: 16 horas a +23 °C ±2 °C/humedad relativa 
del 55 % ±3 % 176, 178 
IEC 60068-2-78-Cab 
4 Pruebas del papel durante el servicio 
4.1 Resistencia a la 
humedad del 
fondo (papel no 
imp reso) Preacondicionamiento: 16 horas a +23 °C ±2 °C/humedad 
relativa del 55 % ±3 % 
Prueba ambiental: 144 horas a +55 °C ±2 °C/humedad rela­
tiva del 93 % ±3 % 
Recuperación: 16 horas a +23 °C ±2 °C/humedad relativa 
del 55 % ±3 % 176, 178 
IEC 60068-2-78-Cab 
4.2 Imp rimabilidad Preacondicionamiento: 24 horas a +40 °C ±2 °C/humedad 
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 relativa 
del 55 % ±3 % 176, 178 
4.3 Resistencia al ca­
lor Preacondicionamiento: 16 horas a +23 °C ±2 °C/humedad 
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 relativa 
del 55 % ±3 % 176, 178 
IEC 60068-2-2-Bb 
4.4 Resistencia a 
temperaturas ba­
jas Preacondicionamiento: 16 horas a +23 °C ± 2 °C/humedad 
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 relativa 
del 55 % ±3 % 176, 178 
ISO 60068-2-1-Ab 26.5.2016 L 139/334 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción Condiciones correspon ­
dient es 
4.5 Resistencia a la 
luz Preacondicionamiento: 16 horas a +23 °C ±2 °C/humedad 
relativa del 55 % ±3 % 
Prueba ambiental: 100 horas con una iluminación infer ior 
a 5 000 lux a +23 °C ±2 °C/humedad relativa del 55 % 
±3 % 
Recuperación: 16 horas a +23 °C ±2 °C/humedad relativa 
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 siguient es 
límite s: 
Caracte res impresos: mín. 1,0 
Fondo (papel no impreso): máx. 0,2 
Las densidades ópticas de los documentos de imp resión resultantes deben medirse en función de la norma DIN EN 
ISO 534. 
Los documentos de impresión no deberán sufr ir cambios dimensionales y deberán manten er una legibilidad clara. 
8.  PRUEBAS DE INTER OPERABILID AD 
No Prueba Descr ipción 
9.1 Pruebas de interoperabilidad entre las unidades intravehiculares y las tarjetas de tacógraf o 
1 Autenticación 
mutua Comp robar que la autenti cación mutua entre la unidad instalada en el vehículo y la 
tarjeta de tacógraf o funciona normalmente. 
2 Pruebas de lec­
tura/escr itura Ejecutar un escenar io de actividad típico en la unidad instalada en el vehículo. Dicho 
escenar io deberá adap tarse al tipo de tarjeta que se esté verificando y deberá incluir 
pruebas de escr itura en tanto s EF como sea posible en la tarjeta. 
Verificar mediante una transfer encia de la unidad instalada en el vehículo que todos 
los registros correspondientes se han realizado correctamente. 
Verificar mediante una transfer encia de la tarjeta que todos los registros correspon ­
dient es se han realizado correctamente . 
Verificar mediante una impresión diar ia que todos los registros correspondiente s se 
pueden leer correctamente. 
9.2 Pruebas de inter operabilidad entre las unidades intra vehiculares y los sensores de movimiento 
1 Empar ejamiento Comp robar que el emparej amiento entre las unidades intra vehiculares y los sensores 
de movimient o funciona normalmente. 
2 Pruebas de activi ­
dad Ejecutar un escenar io de actividad típico en el sensor de movimient o. El escenar io in­
cluirá una actividad normal y creará el mayor número de incidentes o fallos posible. 
Verificar mediante una transfer encia de la unidad instalada en el vehículo que todos 
los registros correspondientes se han realizado correctamente. 
Verificar mediante una transfer encia de la tarjeta que todos los registros correspon ­
dient es se han realizado correctamente . 
Verificar mediante una impresión diar ia que todos los registros correspondiente s se 
pueden leer correctamente. 26.5.2016 L 139/335 Diar io Oficial de la Unión Europea ES    
No Prueba Descr ipción 
9.3 Pruebas de interoperabilidad entre las unidades intravehiculares y las instalaciones GNSS externas (si procede) 
1 Autenticación 
mutua Comp robar que la autenticación mutua (acoplamient o) entre la unidad instalada en el 
vehículo y el módulo GNSS externo funciona normalmente . 
2 Pruebas de activi ­
dad Ejecutar un escenar io de actividad típico en el módulo GNSS extern o. El escenar io in­
cluirá una actividad normal y creará el mayor número de incidentes o fallos posible. 
Verificar mediante una transfer encia de la unidad instalada en el vehículo que todos 
los registros correspondientes se han realizado correctamente. 
Verificar mediante una transfer encia de la tarjeta que todos los registros correspon ­
dient es se han realizado correctamente . 
Verificar mediante una impresión diar ia que todos los registros correspondiente s se 
pueden leer correctamente.   26.5.2016 L 139/336 Diar io Oficial de la Unión Europea ES    
Apéndice 10 
REQUISITOS DE SEGURID AD 
En el presente apéndice se especifi can los requisitos en mater ia de segur idad informática para los compo nentes del 
sistema de tacógraf o inteli gent e (tacógraf o de segunda generación). 
SEC_001 Los compo nentes del sistem a de tacógraf o inteli gent e que se recogen a continuación deberán tener una certifi­
cación de segur idad conf orme con el sistem a de criterios comunes: 
—  unidad instalada en el vehículo, 
—  tarjeta de tacógraf o, 
—  sensor de movimient o, 
—  Dispositivo GNSS extern o 
SEC_002  Los requisitos mínimos de segur idad informática que debe cumpli r cada component e con certificación de 
segur idad se deter minarán en un Perfil de Protecci ón de los compo nente s 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 certifi­
cación de la segur idad informática nacionales, en el marco del Grupo de Trabajo de interpr etación conjunta, 
que es el grupo de trabajo que apoya el reconocimiento mutuo de certificados en el conte xto del acuerdo 
europeo SOGIS-MRA (Acuerdo sobre el reconocimiento mutuo de los certificados de evaluación de la 
segur idad de la tecnología de la información), cuatro perf iles de prot ección conf ormes con el present e anex o: 
—  Perfil de Prote cción para la unidad instalada en el vehículo, 
—  Perfil de Prote cción para la tarjeta de tacógraf o, 
—  Perfil de Prote cción para el sensor de movimiento, 
—  Perfil de prot ección para el dispositivo GNSS externo. 
El perf il 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 extern o o sin él. En el primer caso los requisitos de segur idad del dispositivo GNSS 
externo son los recogidos en el Perf il de Protección específico . 
SEC_004  Los fabr icante s deberán perfeccionar y compl etar, en la medida de lo necesar io, el Perfil de Prot ección de los 
compo nentes sin borrar o modificar especifi caciones en mater ia de amenazas, objetivos, procedimientos y 
funciones de aplicación de las normas de segur idad con el fin de establecer un objetivo de segur idad 
conf orme al cual se exigirá la certificació n de segur idad del compo nente. 
SEC_005  En el proceso de evaluación se comprobará de forma estricta la conf ormidad del objetivo de segur idad 
específico con el correspondiente Perf il de Protecci ón. 
SEC_006  El nivel de garantía de cada Perf il de Protecci ón será EAL4 incrementado por los compo nente s de garan tía 
ATE_DPT .2 y AVA_V AN.5.  26.5.2016 L 139/337 Diar io Oficial de la Unión Europea ES    
Apéndice 11 
MEC ANISMOS COMUNES DE SEGURID AD 
ÍNDICE 
PREÁMBULO .................................................................................................................................. 340 
PARTE A SISTEMA DE TACÓGRAFO DE PRIMERA GENERA CIÓN ......................................................................... 341 
1. INTR ODUCCIÓN ........................................................................................................................... 341 
1.1. Referencias ...................................................................................................................... 341 
1.2. Notaciones y términos abreviados ......................................................................................... 341 
2. SISTEMAS Y ALGORITMOS CRIPTOGRÁFIC OS .................................................................................... 343 
2.1. Sistemas criptográfi cos ....................................................................................................... 343 
2.2. Algor itmos criptográfi cos .................................................................................................... 343 
2.2.1 Algor itmo RSA ................................................................................................................. 343 
2.2.2 Algor itmo de comprobación aleatoria .................................................................................... 343 
2.2.3 Algor itmo de cifrado de datos .............................................................................................. 343 
3. CLAVES Y CER TIFIC ADOS ............................................................................................................... 343 
3.1. Generación y distr ibución de claves ....................................................................................... 343 
3.1.1 Generación y distr ibución de claves RSA ................................................................................ 343 
3.1.2 Claves de prueba RSA ........................................................................................................ 345 
3.1.3 Claves del sensor de movimient o.......................................................................................... 345 
3.1.4 Generación y distr ibución de claves de sesión T-DES ................................................................. 345 
3.2. Claves ............................................................................................................................. 345 
3.3. Certificad os...................................................................................................................... 345 
3.3.1 Contenid o de los certificado s............................................................................................... 346 
3.3.2 Certificad os expedidos ........................................................................................................ 348 
3.3.3 Verificación y aper tura del certificado .................................................................................... 349 
4. MECAN ISMO DE AUTENTICA CIÓN MUTU A........................................................................................ 349 
5. MECAN ISMOS DE CONFIDENCIALID AD, INTEGRID AD Y AUTENTICA CIÓN EN LAS TRANSFERENCIAS DE DA­
TOS ENTRE LA VU Y LAS TARJET AS ................................................................................................. 352 
5.1. Mensajerí a segura .............................................................................................................. 352 
5.2. Tratamiento de los errores de mensaj ería segura ....................................................................... 354 
5.3. Algor itmo para calcular sumas de control criptográficas ............................................................ 354 
5.4. Algor itmo para calcular criptogramas con los que manten er la conf idencialidad de los DO ................ 355 
6. MECAN ISMOS DE FIRMA DIGIT AL PARA LA TRANSFERENCIA DE DATOS ................................................ 355 
6.1. Generación de firmas ......................................................................................................... 355 
6.2. Verificación de firmas ......................................................................................................... 356 26.5.2016 L 139/338 Diar io Oficial de la Unión Europea ES    
PARTE B SISTEMA DE TACÓGRAFO DE SEGUND A GENERA CIÓN ........................................................................ 357 
7. INTR ODUCCIÓN ........................................................................................................................... 357 
7.1. Referencias ...................................................................................................................... 357 
7.2. Notaciones y abreviaturas .................................................................................................... 357 
7.3. Defi niciones ..................................................................................................................... 359 
8. SISTEMAS Y ALGORITMOS CRIPTOGRÁFIC OS .................................................................................... 359 
8.1. Sistemas criptográfi cos ....................................................................................................... 359 
8.2. Algor itmos criptográfi cos .................................................................................................... 360 
8.2.1 Algor itmos simétr icos ........................................................................................................ 360 
8.2.2 Algor itmos asimétr icos y parámetros de dominio normalizados .................................................. 360 
8.2.3 Algor itmos de comprobación aleatoria ................................................................................... 361 
8.2.4 Conjuntos de cifrado .......................................................................................................... 361 
9. CLAVES Y CER TIFIC ADOS ............................................................................................................... 361 
9.1. Pares asimétr icos de claves y certificados de clave pública ........................................................... 361 
9.1.1 Generalidades ................................................................................................................... 361 
9.1.2 Nivel europeo ................................................................................................................... 362 
9.1.3 Nivel del Estado miembro ................................................................................................... 362 
9.1.4 Nivel de equipo: Unidades instaladas en los vehículos ................................................................ 363 
9.1.5 Nivel de equipo: Tarjetas de tacógraf o.................................................................................... 365 
9.1.6 Nivel de equipo: Dispositivos GNSS exte rnos ........................................................................... 366 
9.1.7 Síntes is: Sustitución del certificado ........................................................................................ 367 
9.2. Claves simétr icas ............................................................................................................... 368 
9.2.1 Claves de aseguramiento de la comunicación entre la VU y el sensor de movimiento ........................ 368 
9.2.2 Claves de aseguramiento de comunicaciones dedicadas de corto alcance (DSR C).............................. 372 
9.3. Certificad os...................................................................................................................... 375 
9.3.1 Generalidades ................................................................................................................... 375 
9.3.2 Contenid o de los certificado s............................................................................................... 375 
9.3.3 Solicitud de certificados ...................................................................................................... 377 
10. AUTENTICA CIÓN MUTU A DE LA TARJET A VU_CARD Y MENSAJ ERÍA SEGURA .......................................... 378 
10.1. Generalidades ................................................................................................................... 378 
10.2. Verificación mutua de la cadena de certificado s........................................................................ 379 
10.2.1 Verificación por la VU de la cadena de certificados de una tarjeta ................................................. 379 
10.2.2 Verificación por la tarjeta de la cadena de certificados de una VU ................................................. 381 
10.3. Autenticación de VU .......................................................................................................... 384 
10.4. Autenticación de chip y acuerdo de claves de sesión .................................................................. 385 26.5.2016 L 139/339 Diar io Oficial de la Unión Europea ES    
10.5. Mensajerí a segura .............................................................................................................. 387 
10.5.1 Generalidades ................................................................................................................... 387 
10.5.2 Estr uctura de mensaje segura ............................................................................................... 388 
10.5.3 Abor to de sesión de mensaj ería segura ................................................................................... 391 
11. ACOPL AMIENTO, AUTENTICA CIÓN MUTU A Y MENSAJERÍA SEGURA ENTRE LA VU Y EL DISPOSITIV O GNSS 
EXTERNO .................................................................................................................................... 392 
11.1. Generalidades ................................................................................................................... 392 
11.2. Acoplamiento entre la VU y el dispositivo GNSS exte rno ........................................................... 393 
11.3. Verificación mutua de la cadena de certificado s........................................................................ 393 
11.3.1 Generalidades ................................................................................................................... 393 
11.3.2 Durante el acoplamient o entre la VU y la EGF ......................................................................... 393 
11.3.3 Durante el funcionamient o normal ........................................................................................ 394 
11.4. Autenticación de la VU, autenticación del chip y acuerdo de claves de sesión .................................. 395 
11.5. Mensajerí a segura .............................................................................................................. 395 
12. EMP AREJAMIENTO Y COMUNICA CIÓN ENTRE UNA VU Y UN SENSOR DE MOVIMIENTO ............................. 396 
12.1. Generalidades ................................................................................................................... 396 
12.2. Emparejamient o de la VU con el sensor de movimient o mediante claves de diferent es generaciones ..... 396 
12.3. Emparejamient o y comunicación entre una VU y un sensor de movimient o mediante el algor itmo AES 397 
12.4. Emparejamient o del sensor de movimient o para equipos de diferentes generaciones ......................... 399 
13. SEGURID AD PARA LA COMUNICA CIÓN REMOT A MEDIANTE DSR C........................................................ 399 
13.1. Generalidades ................................................................................................................... 399 
13.2. Cifrado de la carg a útil del tacógraf o y generación del código MAC.............................................. 400 
13.3. Verificación y descifrado de la carg a útil del tacógraf o............................................................... 401 
14. FIRMA DE DESCAR GAS DE DATOS Y VERIFICA CIÓN DE FIRMAS ............................................................ 401 
14.1. Generalidades ................................................................................................................... 401 
14.2. Generación de firmas ......................................................................................................... 402 
14.3. Verificación de firmas ......................................................................................................... 402  
PREÁMBULO 
El present e apéndice especifi ca los mecanismos de segur idad que garantizan 
—  la autenticación mutua entre los diferentes compo nente s del sistema de tacógraf o digital; 
—  la confidencialidad, integridad, autenticidad y/o no rechazo de los datos transferi dos entre equipos diferentes o 
descarg ados a medios de almacenamiento exte rnos. 
El present e apéndice consta de dos partes. La Parte A define los mecanismos de segur idad del sistem a de tacógraf o de 
primera generación (tacógraf o digital). La Parte A define los mecanismos de segur idad del sistema de tacógraf o de 
segunda generación (tacógraf o intelig ente). 
Los mecanismos especificados en la Parte A del presente apéndice serán de aplicación si al menos uno de los 
compo nentes del sistema de tacógraf o implicados en una autenti cación mutua y/o proceso de transfe rencia de datos es 
de primera generación. 26.5.2016 L 139/340 Diar io Oficial de la Unión Europea ES    
Los mecanismos especifi cados en la Parte B del presente apéndice serán de aplicación si los dos compo nentes del sistema 
de tacógraf o implicados en la aute nticación mutua y/o el proceso de transfer encia de datos son de segunda generación. 
El apéndice 15 contiene más información sobre el uso de compo nente s de primera generación en combinación con 
compo nentes de segunda generación. 
PARTE A 
SISTEMA DE TACÓGRAFO DE PRIMERA GENERA CIÓN 
1.  INTR ODUCCIÓN 
1.1.  Referencia s 
En el present e apéndice aparecen las siguiente s referen cias: 
SHA-1  National Institute of Standards and Technology (NIST). Publicación FIPS 180-1: Nor ma sobre 
códigos de comproba ción seguros. Abr il de 1995. 
PKCS1  RSA Laborator ies. PKCS # 1: Nor ma de cifrado RSA. Versión 2.0. Octubre de 1998. 
TDES  National Institute of Standards and Technology (NIST). Publicación FIPS 46-3: Nor ma de 
cifrado de datos. Proyecto de 1999. 
TDES-OP  ANSI X9.52, Modos de funcionamient o del algor itmo triple de cifrado de datos. 1998. 
ISO/IEC 7816-4  Tecnologías de la Información — Tarjetas de identif icación — Tarjetas de circuit o(s) 
integrado(s) con contact os — Parte 4: Comandos interindustr iales para inter cambio. Primera 
edición: 1995 + Modif icación 1: 1997. 
ISO/IEC 7816-6  Tecnologías de la Información — Tarjetas de identif icación — Tarjetas de circuit o(s) 
integrado(s) con contactos — Parte 6: Elementos de datos interindustr iales. Primera edición: 
1996 + Cor 1: 1998. 
ISO/IEC 7816-8  Tecnologías de la Información — Tarjetas de identif icación — Tarjetas de circuit o(s) 
integrado(s) con contact os — Parte 8: Comandos interindustr iales relacionados con la 
segur idad. Primera edición 1999. 
ISO/IEC 9796-2  Tecnología de la información — Técnicas de segur idad — Esquemas de firma digital con 
recuperación de mensaj e — Parte 2: Mecanismos que emple an una función de 
comprobación aleatoria. Primera edición: 1997. 
ISO/IEC 9798-3  Tecnología de la información — Técnicas de segur idad — Mecanismos de autenti cación de 
entidades — Parte 3: aute nticación de entidades mediante un algor itmo de clave pública. 
Segunda edición 1998. 
ISO 16844-3  Vehículos de carretera — Sistema s de tacógraf o — Parte 3: Interfaz del sensor de 
movimient o. 
1.2.  Notacio nes y términos abreviados 
En el present e apéndice se emp lean las siguiente s notaciones y térm inos abreviados: 
(Ka, Kb, Kc)  Un conjunt o de claves que utiliza el algor itmo triple de cifrado de datos. 
CA  Certification author ity (/autori dad de certificación), 
CAR  Certification author ity referen ce (/refe rencia a la autori dad de certificación), 
CC  Cryptographic chec ksum (/suma de control criptográfi ca), 
CG  Criptograma, 
CH  Command header (/cabecera de comando), 
CHA  Certificate holder author isation (/autori zación del titular del certificado), 
CHR  Certificate holder referen ce (/referen cia al titular del certificad o), 
D()  Descifrado con DES, 26.5.2016 L 139/341 Diar io Oficial de la Unión Europea ES    
DE  Data element (/elemento de datos), 
DO  Data object (/objeto de datos), 
d  Clave privada RSA , exponent e privado, 
e  Clave pública RSA , exponent e público, 
E()  Cifrado con DES, 
EQT  EQT Equipment (/equipo), 
Hash()  Valor de compr obación aleatori a, una salida de Hash, 
Hash  Función de compr obación aleatori a, 
KID  Key identifier (/identif icador de clave), 
Km  Clave TDES. Clave maestra definida en ISO 16844-3, 
KmVU  Clave TDES inser tada en las unidades de vehículos, 
KmWC  Clave TDES inser tada en las tarjetas de los centros de ensa yo, 
m  Representante de mensaj e, 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 confiden ­
cialidad 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 (/mensaj ería segura), 
TCBC  Modo de funcionamient o por cifrado progresivo TDEA, 
TDEA  Algor itmo 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 usuar io X, expedido por una autori dad de certificación, 
X.CA  Una autori dad de certificación del usuar io 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 autori dad. El resultado es la clave 
pública del usuar io X cuyo certificado es el operando derecho, 
X.PK  Clave pública RDS de un usuar io X, 
X.PK[I]  Cifrado RSA de cierta información I, utilizando la clave pública del usuar io X, 
X.SK  Clave privada RDS de un usuar io X, 
X.SK[I]  Cifrado RSA de cierta información I, utilizando la clave privada del usuar io X, 
‘xx’  Un valor hexadecimal, 
||  Operador de concat enación. 26.5.2016 L 139/342 Diar io Oficial de la Unión Europea ES    
2.  SISTEMAS Y ALGORITMOS CRIPTOGRÁFICOS 
2.1.  Sistemas criptog ráficos 
CSM_001  Las unidades instaladas en los vehículos y las tarjetas de tacógraf o deberán emplear un sistema 
criptográfic o RSA clásico de clave pública para ofrecer los siguiente s mecanismos de segur idad: 
—  aute nticación entre unidades instaladas en los vehículos y tarjetas, 
—  transpor te de claves de sesión triple DES entre las unidades instaladas en los vehículos y las 
tarjetas de tacógraf o, 
—  firma digital de los datos transferidos desde unidades instaladas en los vehículos o tarjetas de 
tacógraf o a medios externo s. 
CSM_002  Las unidades instaladas en los vehículos y las tarjetas de tacógraf o deberán emplear un sistema 
criptográfic o simétr ico triple DES para ofrecer un mecanismo que garantice la integr idad de los 
datos durante los inter cambios de datos de usuar io entre las unidades instaladas en los vehículos y 
las tarjetas de tacógraf o, y para ofrecer , cuando proceda, la conf idencialidad en los intercambios de 
datos entre las unidades instaladas en los vehículos y las tarjetas de tacógraf o. 
2.2.  Algor itmos cripto gráficos 
2.2.1  Algor itmo RSA 
CSM_003  El algor itmo RSA se define íntegram ente con las relaciones siguiente s: 
X.SK[m] = s = md mod n 
X.PK[s] = m = se mod n  
En el documento de referencia PKCS1 figur a una descr ipció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  Algor itmo de comprobación aleator ia 
CSM_004  Los mecanismos de firma digital deberán emplear el algor itmo SHA-1 de compr obación aleatori a, 
que se define en el documento de referencia SHA-1. 
2.2.3  Algor itmo de cifrado de datos 
CSM_005  En el modo de funcionamiento por cifrado progresiv o deberán emp learse algor itmos con base DES. 
3.  CLAVES Y CERTIFICADOS 
3.1.  Generación y distribución de claves 
3.1.1  Gener ación y distr ibució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 26.5.2016 L 139/343 Diar io Oficial de la Unión Europea ES    
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 
conser varán registros de toda s las claves certificadas. Todas estas tareas se realizarán bajo la gestión 
de una autor idad de certificación europea, y bajo la autoridad 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 claves 
públicas que vayan a introducirse en el equipo (unidad instalada en el vehículo o tarjeta de 
tacógraf o). Se conser varán registros de todas las claves públicas certificadas, junto con la identif i­
cación del equipo al que están destinadas. Estas tareas serán efectuadas por una autori dad de certifi­
cació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 autori dad de certificación del Estado miembro 
que corresponda. Estas tareas podrán ser efectuadas por los fabr icantes de los equipos, los persona ­
lizadores de los equipos o las autori dades de los Estados miembros. Este par de claves se emplea 
para los servicios de aute nticación, firma digital y cifrado. 
CSM_010  Se deberá manten er la conf idencialidad de las claves privadas durante su generación, transpor te (en 
su caso) y almacenamient o. 
El gráfico siguiente resume el flujo de datos en este proceso: 
26.5.2016 L 139/344 Diar io Oficial de la Unión Europea ES    
3.1.2  Claves de prueba RSA 
CSM_011  Con el fin de verificar los equipos (incluidas las pruebas de interoperabilidad), la autori dad de 
certificación europea deberá 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 fabricant es deberán introducir , en el equipo que se someta a las 
pruebas de homolog ació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 conf idencialidad de las tres claves TDES descr itas a continuación se manten drá adecuadamente durant e la 
generación, el transpor te (si lo hay) y el almacenamiento. 
A fin de admitir compo nentes de tacógraf o conf ormes con la norma ISO 16844, la autor idad de certificación 
europea y las autori dades de certificaci ón de los Estados miembros garantizarán, además, lo siguiente : 
CSM_036 La autori dad de certificació n europea generará KmVU y KmW C, dos claves Triple DES indepen ­
dient es y únicas, y generará Km como:  Km = KmVU XOR KmWC  . La autori dad de certificaci ón 
europea remitirá estas claves, con arreglo a procedimiento s de segur idad adecuados, a las 
autori dades de certificació n de los Estados miembros a petición de éstas. 
CSM_037  Las autori dades de certificació n europeas: 
—  utilizarán Km para cifrar los datos del sensor de movimient o solicitados por los fabricantes del 
sensor de movimient o (los datos que deben cifrarse con Km se definen en ISO 16844-3), 
—remitirán KmVU a los fabricantes de la unidad instalada en el vehículo, con arreglo a procedi ­
mient os de segur idad adecuados, para su inserción en las unidades del vehículo, 
—  se encarg arán de que KmWC se inser te en todas las tarjetas de centros de ensa yo 
(
 en el arch ivo elemental 
 ) 
durant e la personalización de la tarjeta. 
3.1.4  Gener ación y distr ibución de claves de sesión T-DES 
CSM_012  Las unidades instaladas en los vehículos y las tarjetas de tacógraf o deberán, como parte del proceso 
de autenticación mutua, generar e inter cambiar los datos necesar ios para elaborar una clave común 
de sesión triple DES. La confidencialidad de este intercambio de datos deberá estar protegida por 
un mecanismo criptográfi co RSA. 
CSM_013  Esta clave deberá emplearse en todas las operaciones criptográfi cas subsiguient es que utilicen 
mensaj ería segura. Su validez expirará al térm ino 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 mensaj ería 
segura, y la respuesta asociada). 
3.2.  Clav es 
CSM_014  Las claves RSA (con independencia de su nivel) deberán tener las longitudes siguient es: módulo n 
1 024 bits, exponent e público e 64 bits máximo, exponent e privado d 1 024 bits. 
CSM_015  Las claves triple DES deberán tener la forma (Ka, Kb, Ka), donde Ka y Kb son claves independientes 
con una longitud de 64 bits. No se configurarán bits para la detec ción de errores de paridad. 
3.3.  Cer tificados 
CSM_016  Los certificados de clave pública RSA deberán ser «no autodescr iptivos» y «ver ificables con tarjeta» 
(ref.: ISO/IEC 7816-8). 26.5.2016 L 139/345 Diar io Oficial de la Unión Europea ES    
3.3.1  Contenido de los certificados 
CSM_017  Los certificados de clave pública RSA incluye n los datos siguient es en este orden: 
Dato Formato Bytes Obs 
CPI No ENTER O  1 Identificad or de perf il del certificado (‘01’ para esta versión) 
CAR CADENA DE OC­
TETOS  8 Referencia a la autor idad de certificación 
CHA CADENA DE OC­
TETOS  7 Autorización del titular del certificado 
EOV Fecha  4 Fin de la validez del certificado. Este dato es opcional y se rellena 
con las letras ‘FF’ si no se utiliza. 
CHR CADENA DE OC­
TETOS  8 Referencia al titular del certificado 
n CADENA DE OC­
TETOS  128 Clave pública (módulo) 
e CADENA DE OC­
TETOS  8 Clave pública (exponent e público)   
164   
Notas: 
1.  El «Identif icador de perf il del certificado» (CPI) define la estructura exacta de un certificado de autenticación. 
Se puede utilizar como un identificad or interno del equipo en una lista de cabeceras que descr iba la 
concat enació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’ Etiqueta de lista de cabeceras ampliada 
Longitud de la lista de cabeceras 
Etiqueta CPI 
Longitud CPI 
Etiqueta CAR 
Longitud CAR 
Etiqueta CHA 
Longitud CHA 
Etiqueta EOV 
Longitud EOV 
Etiqueta CHR 
Longitud CHR 
Etiqueta de clave pública (construida) 
Longitud de los DO subsiguientes 
Etiqueta del módulo 
Longitud del módulo 
Etiqueta del exponente público 
Longitud del exponente público    
2.  La «referencia a la autoridad de certificación» (CAR) sirve para identificar 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 autor idad, para señalar la clave pública de la autori dad de certificación (la codif icación se explica más 
adelante , cuando se habla del identificad or de clave). 26.5.2016 L 139/346 Diar io Oficial de la Unión Europea ES    
3.  La «autori zación del titular del certificado» (CHA) sirve para identif icar los derechos que posee el titular del 
certificado. Consta del identificad or de la aplicación de tacógraf o y del tipo de equipo a que se refiere el 
certificado (con arreglo al element o de datos 
 , «00» para un Estado miembro). 
4.  La «referencia al titular del certificado» (CHR) sirve para identif icar de forma inequívoca al titular del 
certificado, de manera que el elemento de datos se puede utilizar simultáneamente como un identif icador 
de clave de sujeto para señalar la clave pública del titular del certificado. 
5.  Los identificadores de clave permiten identif icar de forma inequívoca al titular del certificado y a las 
autoridades de certificación. Los identif icadores de clave se codifican de la manera siguiente :  
5.1. Equipo (VU o tarjeta): 
Dato No de serie del 
equipo Fecha Tipo Fabric ante 
Longitud 4 bytes 2 bytes 1 byte 1 byte 
Valor Número entero Codificaci ón BCD 
mm aa Específi co del fabri­
cante Código del fabri­
cant e  
En el caso de una VU, el fabricante, cuando solicita un certificado, puede o no conocer la identifi ­
cación del equipo en el que se introducirán las claves. 
En el primer caso, el fabricante envi ará la identificación del equipo, junto con la clave pública, a la 
autor idad de certificación de su Estado miembro. El certificado que ésta expida conte ndrá la identifi ­
cación del equipo. El fabricante debe cerciorarse de que las claves y el certificad o se introducen en el 
equipo que corresponde. El identificad or de clave tiene la forma arriba descr ita. 
En caso contrar io, el fabricante debe identif icar de forma inequívoca cada solicitud de certificado y 
enviar dicha identif icación, junto con la clave pública, a la autoridad de certificació n de su Estado 
miembro. El certificado que ésta expida contendrá la identif icación de la solicitud. Una vez se haya 
instalado la clave en el equipo, el fabricante, por su parte, debe comunicar a la autori dad de su Estado 
miembro la asignación de la clave al equipo (es decir , la identif icación de la solicitud del certificado, la 
identif icación del equipo). El identif icador de clave posee la forma siguiente : 
Dato No de serie de soli­
citud de certificad o Fecha Tipo Fabric ante 
Longitud 4 bytes 2 bytes 1 byte 1 byte 
Valor Número entero Codificaci ón BCD 
mm aa ‘FF’ Código del fabri­
cant e   
5.2. Autoridad de certificación: 
Dato Identif icación de la 
autor idad No de serie de la 
clave Información adicio ­
nal Identificad or 
Longitud 4 bytes 1 byte 2 bytes 1 byte 26.5.2016 L 139/347 Diar io Oficial de la Unión Europea ES    
Valor 1 byte código nu­
mér ico del país 
3 bytes código alfa­
numér ico del país Número entero Codif icación adicio ­
nal 
(específi ca de la 
CA) 
‘FF FF’ si no se uti­
liza ‘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 Identificador de Objeto que lo especifique). 
3.3.2  Certificados expedidos 
CSM_018  El certificado expedido es una firma digital con recuperación parcial del cont enido del certificado, 
según la norma ISO/IEC 9796-2 (except o su anex o A4), y se le añade una «referencia a la autori dad 
de certificación». 
X.C = X.CA .SK[‘6A ’ || Cr || Hash(Cc) || ‘BC’] || Cn || X.CAR  
Con el cont enido del certificado = Cc = Cr || Cn  
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 autori dad de certificación para verificar el certificado. 
3.  El responsable de verificar el certificado deberá conocer de forma implícita el algor itmo empleado por la 
autoridad de certificación para firmar el certificado. 
4.  A continuación se muestra la lista de cabeceras asociada a este certificad o expedido: 
‘7F 21’ ‘09’ ‘5F 37’ ‘81 80’ ‘5F 38’ ‘3A’ ‘42’ ‘08’ Etiqueta del certificado CV (Construida) 
Longitud de los DO subsiguientes 
Etiqueta de firma 
Longitud de la firma 
Etiqueta de resto 
Longitud de resto 
Etiqueta CAR 
Longitud CAR   26.5.2016 L 139/348 Diar io Oficial de la Unión Europea ES    
3.3.3  Verificación y aper tura del certificado 
La verificación y aper tura del certificado consiste en verificar la firma con arreglo a la norma ISO/IEC 9796-2, 
recuperar el conte nido 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 cont enido: 
—  conocido el X.C, recuperar la firma, 
Cn' y CAR': X.C = Firma || Cn' || CAR'   
128 bytes  58 bytes  8 bytes  
—  conocida la referen cia CAR', seleccionar la clave pública de la autori dad 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], 
—  compr obar que Sr' comienza con ‘6A’ y term ina con ‘BC’ 
—  calcular Cr' y H' a partir de: Sr' = ‘6 A’ || Cr' || H' || ‘BC’    
106 bytes  20 bytes    
—  Recuperar el cont enido C' del certificado = Cr' || Cn', 
—  compr obar que Hash(C') = H' 
Si estas comprobacio nes arrojan un resultado positiv o, el certificado es genuino y su cont enido es 
C'. 
Una vez conocido el conte nido 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 almacenamient o de la clave pública, el identi ­
ficador de clave, la autorización del titular del certificado y el fin de la validez del certificado: 
—  X.PK = n || e 
—  X.KID = CHR 
—  X.CHA = CHA 
—  X.EO V = EOV 
4.  MECANISMO DE AUTENTICA CIÓN MUTU A 
La autenti cación mutua entre tarjetas y VU se basa en el siguient e 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 
certificada por la autori dad de certificación europea. 
La demostración se lleva a cabo firmando con la clave privada un número aleatori o enviado por la otra parte, 
quien debe recuperar dicho número cuando verifique esta firma. 
El mecanismo lo activa la VU al inser tar la tarjeta. Comienza con el intercambio de certificados y la aper tura 
de claves públicas, y term ina con la creación de una clave de sesión. 26.5.2016 L 139/349 Diar io Oficial de la Unión Europea ES    
CSM_020  Deberá utilizarse el protocolo siguiente (las flecha s indican los comandos y datos que se 
inter cambian [véase el apéndice 2)]: 
26.5.2016 L 139/350 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/351 Diar io Oficial de la Unión Europea ES    
5.  MECANISMOS DE CON FIDENCIALID AD, INTEGRID AD Y AUTENTICA CIÓN EN LAS TRANSFERENCIAS DE DATOS 
ENTRE LA VU Y LAS TARJET AS 
5.1.  Mensajería segura 
CSM_021  La integridad de las transfer encias de datos entre la VU y las tarjetas estará prot egida por un 
sistema de mensajería segura, de conf ormidad con los documentos de referencia [ISO/IEC 7816-4] 
e [ISO/IEC 7816-8]. 
CSM_022  Cuando haya que prote ger los datos durante la transferencia, se añadirá un objeto de datos 
consistent e en una suma de control criptográfica a los objeto s de datos que se envíen en el 
comando o la respuesta. El recept or 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 ((=>CL A = ‘0C’, y todos los objeto s 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 prote gidos por 
una suma de control criptográfica cuando dicha respuesta no conteng a un campo de datos. 
CSM_025  Las sumas de control criptográficas deberán tener una longitud de 4 bytes. 
Así pues, la estructura de comandos y respuestas cuando se utiliza un sistema de mensajería segura 
es así: 
Los DO emp leados son un conjunto parcial de los DO de mensaj ería segura que se descr iben en la 
norma ISO/IEC 7816-4: 
Etiqueta Mnemónico Significado 
‘81’ TPV Dato de valor plano no codificado en BER -TLV (con la protección de la 
suma CC) 
‘97’ TLE Valor de Le en el comando no seguro (con la prot ección de la suma 
CC) 
‘99’ TSW Información de estado (con la protección de la suma CC) 
‘8E’ TCC Suma de control criptográfi ca 
‘87’ TPI CG Byte indicador de relleno || Criptograma (Valor plano no codif icado en 
BER -TLV)  
Dado un par de respuestas para un comando no seguro: 
Cabecera de comando Cuer po del comando 
CLA INS P1 P2 [campo Lc] [cam po de datos] [cam po Le] 
cuatro bytes L bytes, denotados por B1 a BL  
Cuer po de la respuesta Cola de la respuesta 
[campo de datos] SW1 SW2 
Lr bytes de datos dos bytes  26.5.2016 L 139/352 Diar io Oficial de la Unión Europea ES    
El correspondiente par de respuestas para el comando seguro es: 
Comando seguro: 
Cabecera del comando 
(CH) Cuer po del comando 
CLA INS P1 P2 [Nuevo campo 
Lc] [Nuevo campo de datos ] [Nuev o 
campo 
Le] 
‘OC’ Longitud del 
nuevo campo 
de datos TPV LPV PV TLE LLE Le TCC LCC CC ‘00’ 
‘81’ Lc Cam po 
de da­
tos ‘97’ ‘01’ Le ‘8E’ ‘04’ CC  
Datos que habrá que integrar en la suma de control = CH || PB || TPV || LPV || PV || TLE || LLE || Le || 
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 correspondiente s 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 necesar io proteg erlo para 
garantizar la confidencialidad: 
Cuer po de la respuesta Cola de la respuesta 
[Nuev o campo de datos] nuev o SW1 SW2 
TPV LPV PV TCC LCC CC  
‘81’ Lr Campo de datos ‘8E’ ‘04’ CC  
Datos que habrá que integrar en la suma de control = TPV || LPV || PV || PB  
2. Caso en que el camp o de datos de la respuesta no está vacío y debe ser protegido para 
garantizar la confidencialidad: 
Cuer po de la respuesta Cola de la respuesta 
[Nuev o campo de datos] nuev o SW1 SW2 
TPI CG LPI CG PI CG TCC LCC 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 = TPI CG || LPI CG || PI CG || PB 26.5.2016 L 139/353 Diar io Oficial de la Unión Europea ES    
3. Caso en que el campo de datos de la respuesta está vacío: 
Cuer po de la respuesta Cola de la respuesta 
[Nuev o campo de datos] nuev o SW1 SW2 
TSW LSW SW TCC LCC CC  
‘99’ ‘02’ Nuevo SW1 SW2 ‘8E’ ‘04’ CC  
Datos que habrá que integrar en la suma de control = TSW || LSW || SW || PB 
5.2.  Tratamiento de los errores de mensajería segura 
CSM_026  Si la tarjeta de tacógraf o detecta un error SM mientras está interpr etando 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 
siguient es 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 incor rectos. 
CSM_027  Si la tarjeta de tacógraf o devuelve bytes de estado sin DO SM o con un DO SM erróneo, la VU 
tendrá que interr umpir la sesión. 
5.3.  Algor itmo para calcular sumas de control cripto gráficas 
CSM_028  Las sumas de control criptográficas se constr uyen 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 calculan utilizando Ka; 
—  etapa final: la suma de control criptográfica se calcula a partir del último bloque de control yn 
de la manera siguient e: E(Ka, D(Kb, yn)). 
donde E() significa cifrado con DES, y D() signif ica descifrado con DES. 
Se transf ieren los cuatro bytes más signif icativ os de la suma de control criptográfica. 
CSM_029  El contador de la secuencia de envío (SSC) deberá iniciarse durant e el procedimiento de acuerdo de 
la clave: 
SSC inicial: Rnd3 (los 4 bytes menos signif icativ os) || 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). 26.5.2016 L 139/354 Diar io Oficial de la Unión Europea ES    
El gráfico siguiente muestra el método de cálculo del MAC: 
5.4.  Algor itmo para calcular cripto gramas con los que mantener la conf idencialidad de los DO 
CSM_031  Los criptogramas se calculan utilizando el algor itmo TDEA en el modo de funcionamient o TCBC, 
de acuerdo con los documentos de referencia TDES y TDES-OP y con el vect or nulo como bloque 
de valor inicial. 
El gráfico siguiente muestra la aplicación de claves en TDES: 
6.  MECANISMOS DE FIRMA DIGIT AL PARA LA TRANSFERENCIA DE DATOS 
CSM_032  El equipo dedicado intelig ente (IDE) almacena en un archivo físico los datos recibidos de un equipo 
(VU o tarjeta) durant e una sesión de descarg a. Dicho archiv o debe contener los certificados MSi.C y 
EQT .C. El archiv o contiene además firmas digitales de bloques de datos, tal y como se especifi ca en 
el apéndice 7, apar tado Protocol os de transferencia de datos. 
CSM_033  Las firmas digitales de los datos transferi dos deberán utilizar un esquema de firma digital con 
apéndice, de manera que los datos transferi dos 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 comprobació n 
aleatoria SHA-1: 
Firma = EQT .SK[‘00’ || ‘01’ || PS || ‘00’ || DER(SHA-1(dat os))] 26.5.2016 L 139/355 Diar io Oficial de la Unión Europea ES    
PS = Cadena de octetos de relleno con un valor ‘FF’ tal que la longitud sea 128. 
DER(SHA-1(M)) es la codif icación de la identif icación del algor itmo para la función de 
comprobació n aleatori a y el valor de comprobació n aleatori a, con el fin de obtener un valor ASN.1 
del tipo DigestInf o (reglas de codif icación distinguidas): 
‘30’||‘21’||‘30’||‘09’||‘06’||‘05’||‘2B’||‘0E’||‘03’||‘02’||‘1A ’||‘05’||‘00’||‘04’||‘14’||V alor de comprobación 
aleatoria. 
6.2.  Verificación de firmas 
CSM_035  La verificación de la firma en los datos transferi dos deberá seguir el esquema de firma con apéndice 
que se define en el documento de referencia [PKCS1] con la función de comproba ción aleatori a 
SHA-1: 
El responsable de verificación debe conocer independient emente (y confiar en) la clave pública 
europea EUR.PK. 
La tabla siguiente muestra el protocolo que una IDE que incor pore una tarjeta de control puede 
seguir para verificar la integridad de los datos transferidos y almacenados en el ESM (medio de 
almacenamient o exte rno). La tarjeta de control sirve para descifrar las firmas digitales. En este caso, 
puede que esta función no esté imple mentada en la IDE. 
El equipo que ha transferido y firmado los datos que han de analizarse se denota por EQT . 
26.5.2016 L 139/356 Diar io Oficial de la Unión Europea ES    
PARTE B 
SISTEMA DE TACÓGRAFO DE SEGUND A GENERA CIÓN 
7.  INTR ODUCCIÓN 
7.1.  Referencia s 
En esta parte del present e apéndice aparecen las siguiente s referen cias: 
AES  National Institute of Standards and Techn ology (NIST), FIPS PUB 197: Advanced Encr yption 
Standard (AES), 26 de noviembre de 2001 
DSS  National Institute of Standards and Techn ology (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: Org anization, 
secur ity and commands for inter chang e. Tercera edición 2013-04-15 
ISO 7816-8  ISO/IEC 7816-8, Identif ication cards — Integrat ed circuit cards — Part 8: Commands for 
secur ity operations. Segunda edición 2004-06-01 
ISO 8825-1  ISO/IEC 8825-1, Information technology — ASN.1 encoding rules: Specification of Basic 
Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules 
(DER). Cuar ta edición, 2008-12-15 
ISO 9797-1  ISO/IEC 9797-1, Information technology — Secur ity techniques — Message Auth entication 
Codes (MA Cs) — Part 1: Mechanism s using a bloc k cipher . Segunda edición, 2011-03-01 
ISO 10116  ISO/IEC 10116, Information technology — Secur ity techniques — Modes of operation of an n- 
bit bloc k cipher . Tercera edición, 2006-02-01 
ISO 16844-3  ISO/IEC 16844-3, Road vehicles — Tachog raph 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  Ellipti c Curve Cryptograph y Subject Public Key Information, marzo de 2009 
RFC 5639  Ellipti c Curve Cryptograph y (ECC) — Brain pool Standard Curves and Curve Generation, 2010 
RFC 5869  HMA C-based Extract-and-Expand Key Derivation Function (HKDF), mayo de 2010 
SHS  National Institute of Standards and Techn ology (NIST), FIPS PUB 180-4: Secure Hash Standard, 
marzo de 2012 
SP 800-38B  National Institute of Standards and Techn ology (NIST), Special Publication 800-38B: 
Recommendation for Bloc k Cipher Modes of Operation: The CMA C Mode for Authentication, 
2005 
TR-03111  BSI Technical Guideline TR-03111, Ellipti c Curve Cryptograph y, versión 2.00, 2012-06-28 
7.2.  Notacio nes y abreviaturas 
En el present e apéndice se emp lean las siguiente s notaciones y térm inos abreviados: 
AES  Advanced Encr yption Standard (/nor ma de cifrado avanzado ) 
CA  Certification author ity (/autori dad de certificación), 
CAR  Certificate Authority Reference (/referencia a la autor idad de certificación) 
CBC  Cipher Block Chaining (mode of operation) [/cifrado progresiv o (modo de funcionamient o)] 26.5.2016 L 139/357 Diar io Oficial de la Unión Europea ES    
CH  Command Header (/cabecera de comando), 
CHA  Certificate Holder Author isation (/autori zación del titular del certificad o) 
CHR  Certificate Holder Reference (/refe rencia al titular del certificado ) 
CV  Constant Vector (/vecto r constant e) 
DER  Distinguished Encoding Rules (/reg las de codificación distinguidas) 
DO  Data object (/objeto de datos) 
DSR C  Dedicat ed Shor t Range Communication (/comunicaciones especializadas de corto alcance) 
ECC  Ellipt ic Curve Cryptography (/criptografía de curva elíptica) 
ECDSA  Ellipt ic Curve Digital Signature Algor ithm (/algor itmo de firma digital de curva elípt ica) 
ECDH  Ellipt ic Curve Diffi e-Hellman (key agreement algor ithm) [/cur va elíptica Diffi e-Hellman 
(algor itmo de acuerdo de la clave) 
EGF  Exte rnal GNSS Faci lity (/dispositivo GNSS externo) 
EQT  Equipment (/equipo) 
IDE  Intelligent Dedicat ed Equipment (/equipo especializado inteligent e) 
KM  Clave maestra del sensor de movimiento que permite aparear una unidad instalada en el vehículo 
con un sensor de movimient o 
KM-V U  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 
KM-W C  Clave introducida en tarjetas de centro de ensa yo que permite a una VU derivar la clave maestra 
del sensor de movimient o si se introduce una tarjeta de taller en la VU 
MAC  Message Auth entication Code (/código de autenti cación de mensajes) 
MoS  Motion Sensor (/sensor de movimiento) 
MSB  Most Signif icant Bit (/bit más signif icativ o) 
PKI  Public Key Infrastr ucture (/infraestr uctura de clave pública) 
RCF  Remot e Communication Facility (/instalación de comunicación remota) 
SSC  Send sequence counte r (/contador de la secuencia de envío) 
SM  Secure Messaging (/mensaj eria segura) 
TDES  Triple Data Encr yption Standard (/nor ma 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 usuar io X 
X.CA  La autoridad de certificación que haya expedido el certificado del usuar io X 
X.CAR  La referencia de la autor idad de certificación mencionada en el certificado del usuar io X 
X.CHR  La referencia al titular del certificado mencionada en el certificado del usuar io X 
X.PK  Clave pública de un usuar io X 
X.SK  Clave privada de un usuar io X 
X.PKeph  Clave pública efímera de un usuar io X 
X.SKeph  Clave privada efímera de un usuar io X 
‘xx’  Un valor hexadecimal 
||  Operador de concate nación. 26.5.2016 L 139/358 Diar io Oficial de la Unión Europea ES    
7.3.  Def iniciones 
Las definiciones de los térm inos utilizados en el presente apéndice figuran en la sección I del anex o 1C. 
8.  SISTEMAS Y ALGORITMOS CRIPTOGRÁFICOS 
8.1.  Sistemas criptog ráficos 
CSM_38  Las unidades instaladas en los vehículos y las tarjetas de tacógraf o deberán emplear un sistema 
criptográfico de curva elíptica de clave pública para ofrecer los siguient es servicios de segur idad: 
—  autenticación mutua entre una unidad instalada en el vehículo y una tarjeta; 
—  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 recha zo de los datos descarg ados desde unidades 
instaladas en los vehículos o tarjetas de tacógraf o a medios externos. 
CSM_39  Las unidades instaladas en los vehículos y los dispositivos GNSS extern os deberán emplear un 
sistem a criptográfico de curva elíptica de clave pública para ofrecer los siguient es servicios de 
segur idad: 
—  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 extern o. 
CSM_40  Las unidades instaladas en los vehículos y las tarjetas de tacógraf o deberán emplear un sistema 
criptográfico AES para ofrecer los siguiente s servicios de segur idad: 
—  garantía de la autenticidad e integridad de los datos inter cambiados entre una unidad instalada en 
el vehículo y una tarjeta de tacógraf o; 
—  cuando corresponda, garantía de la conf idencialidad de los datos intercambiados entre una 
unidad instalada en el vehículo y una tarjeta de tacógraf o. 
CSM_41  Las unidades instaladas en los vehículos y los dispositivos GNSS extern os deberán emplear un 
sistem a criptográfi co AES para ofrecer los siguientes servicios de segur idad: 
—  garantía de la autenticidad e integridad de los datos inter cambiados entre una unidad instalada en 
el vehículo y un dispositivo GNSS extern o. 
CSM_42  Las unidades instaladas en los vehículos y los sensores de movimient o deberán emplear un sistema 
criptográfico AES para ofrecer los siguiente s servicios de segur idad: 
—  emparejamient o de una unidad instalada en el vehículo y un sensor de movimient o; 
—  autenticación mutua entre una unidad instalada en el vehículo y un sensor de movimient o; 
—  garantía de la conf idencialidad de los datos intercambiados entre una unidad instalada en el 
vehículo y un sensor de movimient o. 
CSM_43 Las unidades instaladas en los vehículos y las tarjetas de control deberán emplea r un sistema cripto­
gráfico AES para ofrecer los siguient es servicios de segur idad en la interfa z de comunicación remota. 
—  garantía de la autenticidad e integr idad de los datos transmitidos desde una unidad instalada en 
el vehículo a una tarjeta de control. 26.5.2016 L 139/359 Diar io Oficial de la Unión Europea ES    
Notas: 
—  Hablando con propiedad, los datos se transmiten desde una unidad instalada en el vehículo a un 
interr ogad or remot o 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 interro gador remoto envía los datos recibidos a una tarjeta de control para 
descifrado y validación de autenticidad. Desde el punt o de vista de la segur idad, la instalación de 
comunicación remota y el interrogador remoto son plenamente transparent es. 
—  Una tarjeta de taller ofrece los mismos servicios de segur idad para la interfaz DSR C que una 
tarjeta de control. Esto permite a un taller validar el funcionamient o correcto de la interfaz de 
comunicación remota de una VU, incluida la segur idad. Remítase a la sección para 9.2.2 mayor 
información. 
8.2.  Algor itmos cripto gráficos 
8.2.1  Algor itmos simétr icos 
CSM_44  Las unidades instaladas en los vehículos, las tarjetas de tacógraf o, los sensores de movimiento y los 
dispositivo s GNSS externos admitirán el algor itmo AES según se define en [AES], con longitudes de 
clave de 128, 192 y 256 bits. 
8.2.2  Algor itmos asimétr icos y parámetr os de dominio normalizados 
CSM_45  Las unidades instaladas en los vehículos, las tarjetas de tacógraf o y los dispositivo s GNSS exte rnos 
admitirán criptografí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ógraf o y los dispositivo s GNSS exte rnos 
admitirán el algor itmo de firma ECDSA, según se especifi ca en [DSS]. 
CSM_47  Las unidades instaladas en los vehículos, las tarjetas de tacógraf o y los dispositivo s GNSS exte rnos 
admitirán el algor itmo de acuerdo de la clave ECK A-EG, según se especifi ca en la directr iz técnica 
[TR 03111]. 
CSM_48  Las unidades instaladas en los vehículos, las tarjetas de tacógraf o y los dispositivo s GNSS exte rnos 
admitirán todos 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 nor malizados 
Nombre Tamaño (bits) Referencia Identificador de objeto 
NIST P-256 256 [DSS], [RFC 5480] 
Brain poolP256r1 256 [RFC 5639] 
NIST P-384 384 [DSS], [RFC 5480] 
Brain poolP384r1 384 [RFC 5639] 
Brain poolP512r1 512 [RFC 5639] 
NIST P-521 521 [DSS], [RFC 5480] 
Nota: los identif icadores de objeto mencionados en la última columna de la Table 1 vienen especi ­
ficados en [RFC 5639] para las curvas Brainpool y en [RFC 5480] para las curvas NIST . 
26.5.2016 L 139/360 Diar io Oficial de la Unión Europea ES    
8.2.3  Algor itmos de compr obación aleator ia 
CSM_49  Las unidades instaladas en los vehículos y las tarjetas de tacógraf o admitirán los algor itmos HA-256, 
SHA-384 y SHA-512 especifi cados en [SHS]. 
8.2.4  Conjuntos de cifrado 
CSM_50  Si se utilizan simultáneamente un algor itmo simétr ico, un algor itmo asimétr ico y/o un algor itmo de 
compr obación aleatoria para formar un prot ocolo de segur idad, sus longitudes de clave y tamaños 
de algor itmo de autenticación respectivos serán de fortaleza apro ximadamente equivalente. La Table 
2 indica los descr iptores permitidos: 
Tabla 2 
Conjunt os de cifrado permitidos 
Id del conjunto de 
cifrado Tamaño de clave 
ECC (bits) Longitud de clave 
AES (bits) Algor itmo de 
comprobació n alea ­
toria 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 equivalent e a 
todos los efectos en el present e apéndice. 
9.  CLAVES Y CERTIFICADOS 
9.1.  Pares asimétr icos de claves y certificados de clave pública 
9.1.1  Gener alidades 
Nota: las claves descr itas en esta sección se utilizan para la autenti cación mutua y la mensaj ería segura entre 
unidades instaladas en los vehículos y tarjetas de tacógraf o, así como entre unidades instaladas en los 
vehículos y dispositivo s GNSS exte rnos. Estos procesos se descr iben en detalle en los capítulos 10 y 11 de este 
apéndice. 
CSM_51 En el sistem a europeo de tacógraf o inteli gent e, los pares de claves ECC y los certificados correspon ­
dient es se generarán y gestionarán mediante tres niveles jerárquicos funcionales: 
—  Nivel europeo 
—  Nivel de Estado miembro 
—  Nivel de equipo. 26.5.2016 L 139/361 Diar io Oficial de la Unión Europea ES    
CSM_52  En la totali dad del sistema de Tacógraf o Intelig ente Europeo, 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 compuest o de una 
clave privada (EUR:SK) y de una clave pública (EUR.PK). Este par de claves formará el par de claves 
raíz de la totali dad del Tacógraf o Intelig ente 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 (auto firmado) de la clave 
pública europea y comunicará este certificado raíz europeo a todos los Estados 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 autofir mado 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 movimient o y una nueva clave maestra DSR C, véanse las 
secciones 9.2.1.2 y 9.2.2.2. 
CSM_57  Ante s de generar un nuevo par de claves raíz europeo, la ERCA efectuará un análisis de la fortaleza 
criptográfica necesar ia para el nuevo par de claves, habida cuenta de la necesidad de garantizar su 
segur idad durante los 34 años siguientes. En caso necesar io, la ERCA cambiará a un conjunt o de 
cifrado más fuer te que el actual, tal como se especifi ca en CSM_50. 
CSM_58  Siempr e 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. Lo anterior se indica asimismo en la Figure 1 de la 
sección 9.1.7. 
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 nuev o certificad o raíz de clave. 
CSM_60  La ERCA dispondrá en cualquier momento de las siguient es claves criptográficas y certificad os: 
—  El par de claves EUR actual y el certificado correspondiente . 
—  Todos los certificados EUR anteriores que deberán utilizarse para la verificació n de certificados 
MSCA que son toda vía válidos. 
—  Los certificados de enlace para todas las generaciones de certificado s EUR excep to 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ógraf o generarán uno o varios pares de claves ECC únicos designados 
MSCA_Card. Todos los Estados miembros 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 
únicos designados MSCA _VU-EGF . 26.5.2016 L 139/362 Diar io Oficial de la Unión Europea ES    
CSM_62 La tarea de generar pares de claves del Estado miembro será gestionada por una Autoridad de Certifi­
cació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 correspondiente 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 correspondiente del Estado 
miembro. 
CSM_64  Un par de claves MSCA_VU-EGF , si está present e, estará compuest o 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 
excl usivamente para firmar los certificad os de clave pública de las unidades instaladas en los 
vehículos y los dispositivo s GNSS externos. 
CSM_65  Un par de claves MSCA_ Card estará compuest o por la clave privada MSCA_ Card.SK y la clave 
pública MSCA_ Card.PK. Una MSCA utilizará la clave privada MSCA _Card.SK excl usivamente para 
firmar los certificado s de clave pública y las tarjetas de tacógraf o. 
CSM_66  Una MSCA llevará un registro de todos los certificado s VU, los certificad os de dispositivo GNSS 
exte rno y los certificados de tarjeta firmados, junto con la identificación del equipo al que esté 
destinado cada certificad o. 
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 período de uso de la clave de dos 
años. 
CSM_69  Una MSCA no utilizará la clave privada de un par de claves MSCA _VU-EGF para ningún fin a partir 
del momento 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 siguientes claves criptográfi cas y certificados: 
—  El par de claves MSCA_Card actual y el certificado correspondiente. 
—  Todos los certificad os MSCA_ Card anteriores que deberán utilizarse para la verificación de los 
certificados de tarjetas de tacógraf o que son todavía válidos. 
—  El certificad o EUR actual necesar io para la verificación del certificado MSCA actual. 
—  Todos los certificad os EUR anteriores necesar ios 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 
dispositivo s GNSS externos, la MSCA dispondrá además de las siguient es claves y certificados: 
—  El par de claves MSCA_VU-EGF actual y el certificad o correspondiente . 
—  Todas las claves públicas MSCA_VU-EGF anteriores que deberán utilizarse para la verificación de 
los certificado s de VU o de dispositivo s GNSS extern os que son todavía válidos. 
9.1.4  Nivel de equipo: Unidades instaladas en los vehíc ulos 
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 del país en el 
que resida 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. 26.5.2016 L 139/363 Diar io Oficial de la Unión Europea ES    
CSM_73  Los certificados VU_MA y VU_Sign de una unidad concreta instalada en el vehículo tendrán la 
misma fecha de validez. 
CSM_74  Un fabr icante 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, compuest o por la clave 
privada VU_MA.SK y la clave pública VU_MA. PK, exclusivament e para efectuar la autenticación de la 
VU en tarjetas de tacógraf o y dispositivo s GNSS externos, tal como se especifica en las secciones 
10.3 y 11.4 del present e apéndice. 
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 excl usivament e para establecer la clave de sesión con una tarjeta de 
tacógraf o o dispositivo GNSS externo, tal como se especifi ca en las secciones 10.4 y 11.4 del 
present e apéndice. 
CSM_77  Una unidad instalada en el vehículo utilizará la clave privada VU_Sign.SK de su par de claves 
VU_Sign excl usivamente para firmar archiv os de datos descarg ados, tal como se especifica en el 
capítulo 14 del presente apéndice. La clave pública VU_Sign.PK correspondiente se utilizará excl usi­
vament e 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 ampli ado de un certificado VU_Sign permite a una unidad instalada en el 
vehículo crear firmas válidas en datos descarg ados durante los tres primeros meses posterio res a 
su caducidad, de conf ormidad con lo dispuesto en el Reglamento (UE) no 581/2010. 
—El período de validez ampli ado de un certificado VU_MA es necesar io para permitir la autenti ­
cación de la VU con una tarjeta de control o una tarjeta de empr esa durante los tres primeros 
meses posterio res a su caducidad, de tal modo que sea posible efectuar una descarg a 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 certificad o correspondiente. 
CSM_80  Los pares de claves VU (except o 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 funcionamient o 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 aute nticación del chip y un acuerdo de claves 
de sesión, véase la sección 10.4. Obsér vese que los pares de claves efímeros carecen de 
certificados correspondiente s. 
—  Este requisito no prohíbe la posibilidad de sustituir pares de claves VU estáticos durante una 
reno vación o reparación en un entorno seguro controlado por el fabricante de la VU. 
CSM_81  Una vez puestas en funcionamient o, las unidades instaladas en los vehículos conte ndrán las 
siguient es claves criptográficas y certificad os: 
—  La clave privada VU_MA y el certificado correspondiente . 
—  La clave privada VU_Sign y el certificado correspondiente. 
—  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 certificad o VU_Sign. 
—  El certificado EUR que contiene la clave pública EUR.PK que deberá utilizarse para la verificación 
del certificado MSCA_VU-EGF . 26.5.2016 L 139/364 Diar io Oficial de la Unión Europea ES    
—  El certificado EUR cuyo período de validez es directament e anter ior al período de validez del 
certificado EUR que deberá utilizarse para verificar el certificado MSCA_ VU-EGF , si existe. 
—  El certificad o de enlace que asocia estos dos certificados EUR, si existe. 
CSM_82  Además de las claves criptográfi cas y los certificad os enumerados en CSM_81, las unidades 
instaladas en los vehículos deberán contener asimismo las claves y certificados especifi cados en la 
parte A del present e apéndice de forma que una unidad instalada en el vehículo pueda inter actuar 
con las tarjetas de tacógraf o de primera generación. 
9.1.5  Nivel de equipo: Tarjetas de tacóg rafo 
CSM_83  Para cada tarjeta de tacógraf o se generará un par de claves ECC único, designado Card_MA. Además, 
para cada tarjeta de conduct or y cada tarjeta de taller se generará un segundo par de claves ECC 
único, designado Card_Sign. Esta tarea puede ser efectuada por los fabr icantes de tarjetas o los 
personalizadores de tarjetas. Siempr e que se genere un nuevo par de claves de tarjeta, la parte que 
genere la clave enviará la clave pública a la MSCA del país en el que resida 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ógraf o. 
CSM_84  Los certificados Card_MA y Card_Sign de una tarjeta de conduct or 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 correspon ­
dient e de la tarjeta. 
CSM_86  Una tarjeta de tacógraf o utilizará su par de claves Card_MA, compuest o por la clave privada 
Card_MA.SK y la clave pública Card_MA. PK, excl usivamente para efectuar la aute nticación mutua y 
establecer la clave de sesión con las unidades instaladas en los vehículos, tal como se especifi ca en 
las secciones 10.3 y 10.4 del presente apéndice. 
CSM_87  Una tarjeta de conductor o tarjeta de taller utilizará la clave privada Card_Sign.SK de su par de 
claves Card_Sign excl usivament e para firmar arch ivos 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 utilizará 
excl usivamente para verificar las firmas creadas por la tarjeta. 
CSM_88  El período de validez de un certificado Card_MA será el siguiente : 
—  Para las tarjetas de conduct or: 5 años 
—  Para las tarjetas de empr esa: 2 años 
—  Para las tarjetas de control: 2 años 
—  Para las tarjetas de taller: 1 año  
CSM_89  El período de validez de un certificado Card_Sign será el siguient e: 
—  Para las tarjetas de conduct or: 5 años y 1 mes 
—  Para las tarjetas de taller: 1 año y 1 mes  
Nota: El período de validez ampli ado de un certificad o Card_Sign permite a una tarjeta de conduct or 
crear firmas válidas en datos descargados durante el primer mes posterior a su caducidad. Esto es 
necesar io de conf ormidad con el Reglamento (UE) no 581/2010 que exige que sea posible efectuar 
una descarga de datos de una tarjeta de conductor hasta transcur ridos 28 días desde el último 
registro de datos. 
CSM_90  Los pares de claves y los certificados correspondiente s de una tarjeta de tacógraf o concreta no se 
sustituirán ni reno varán una vez expedida la tarjeta. 26.5.2016 L 139/365 Diar io Oficial de la Unión Europea ES    
CSM_91  Una vez expedidas, las tarjetas de tacógraf o contendrán las siguient es 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 conduct or 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 certificad o 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 directament e anter ior al período de validez del 
certificado EUR que deberá utilizarse para verificar el certificado MSCA_ Card, si existe. 
—  El certificad o de enlace que asocia estos dos certificados EUR, si existe. 
CSM_92  Además de las claves criptográfi cas y los certificados enumerados en CSM_91, las tarjetas de 
tacógraf o deberán contener asimismo las claves y certificados especificados en la parte A del 
present e apéndice de forma que estas tarjetas puedan interactuar con las unidades instaladas en los 
vehículos de primera generación. 
9.1.6  Nivel de equipo: Dispositivo s GNSS exter nos 
CSM_93  Para cada dispositivo GNSS externo se generará un par de claves ECC único designado EGF_MA. Esta 
tarea es efectuada por los fabricantes de dispositivo s GNSS externo s. Siempre que se genere un 
nuevo par de claves EGF_MA, la clave pública se enviará a a la MSCA del país en el que resida a fin 
de obtener el certificado EGF_MA correspondiente firmado por la MSCA . La clave privada será 
utilizada solamente por el dispositivo GNSS extern o. 
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. 
CSM_95  Una dispositivo GNSS externo utilizará su par de claves EGF_MA, compuest o por la clave privada 
EGF_MA. SK y la clave pública EGF_MA. PK, excl usivamente para efectuar la autenticación mutua y 
establecer la clave de sesión con las unidades instaladas en los vehículos, tal como se especifi ca en 
las secciones 11.4 y 11.4 del presente apéndice. 
CSM_96  El período de validez del certificado EGF_MA será de 15 años. 
CSM_97  Un dispositivo GNSS extern o 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 certificado correspondiente. 
Nota: tal como se indica en la sección 11.3.3, una EGF puede potencialment e utilizar su clave 
privada para la autenticació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 certificad o correspondiente de un dispositivo GNSS externo concreto 
no se sustituirán ni reno varán en el campo una vez puesta en funcionamient o la EGF . 
Nota: Este requisito no prohíbe la posibilidad de sustituir pares de claves EGF durante una 
reno vación o reparación en un entorno seguro controlado por el fabricante de la EGF . 
CSM_99  Una vez puesta en funcionamient o, un dispositivo GNSS exte rno conte ndrá las siguient es claves 
criptográficas y certificad os: 
—  La clave privada EGF_MA y el certificado correspondiente . 26.5.2016 L 139/366 Diar io Oficial de la Unión Europea ES    
—  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 . 
—  El certificado EUR cuyo período de validez es directament e anter ior al período de validez del 
certificado EUR que deberá utilizarse para verificar el certificado MSCA_ VU-EGF , si existe. 
—  El certificad o de enlace que asocia estos dos certificados EUR, si existe. 
9.1.7  Síntesis: Sustitución del certificado 
La Figure 1 siguient e ilustra cronológicament e la forma en que se expiden y utilizan los certificado s raíz 
ERCA, los certificad os de enlace ERCA, los certificados MSCA y los certificados de equipos (VU y tarjeta): 
Figura 1 
Expedición y uso de las diferentes generaciones de certificados raíz ERCA, certificados de enlace ERCA, 
certificados MSC A y certificados de equipos 
26.5.2016 L 139/367 Diar io Oficial de la Unión Europea ES    
Notas de la Figure 1: 
1.  Las diferentes generaciones del certificado raíz se indican mediante un número entre paréntesis. Por 
ejemp lo, ERCA (1) es la primera generació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éntesis, el primero de los cuales indica la 
generación del certificado raíz correspondiente, y el segundo la generación del propio certificado. Por 
ejemp lo, 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 expedidos casi en la misma fecha, pero no 
exactament e. 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 certificado s VU y Card son expedidos en el marco de un certificado MSCA, y no 
directament e en el marco del certificado ERCA. El certificado MSCA (2-1) será expedido directament e 
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 toda ví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 conduct or (5 años). 
6.  Por limitaciones de espacio, solamente se indica la diferencia entre los períodos de validez de los 
certificados Card_MA y Card_Sign y entre los certificado s VU_MA y VU_Sign de la primera generación. 
9.2.  Clav es simétr icas 
9.2.1  Claves de asegur amiento de la comunicación entre la VU y el sensor de movimiento 
9.2.1.1  Gener alidades 
Nota: se da por supuest o que los lectores de la present e sección están familiar izados con el conteni do de la 
norma [ISO 16844-3] que descr ibe la interfaz entre una unidad instalada en el vehículo y un sensor de 
movimiento. El proceso de emparej amiento entre una VU y un sensor de movimient o se descr ibe 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 necesar ias varias 
claves simétr icas a efectos de la aute nticación mutua entre las unidades instaladas 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 movimient o, 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 longitud del par de claves raíz (previst o), tal como se 
descr ibe en CSM_50. 
Tabla 3 
Clav es de aseguramiento de la comunicación entre la unidad inst alada en el vehículo y el sensor de movimiento 
Clave Símbolo Generada por Méto do de generación Almacenada por 
Clave maestra del sensor 
de movimiento — parte 
VU KM-V U ERCA Aleat orio ERCA, MSCA implicadas 
en la expedición de certi­
ficados de VU, fabrican ­
tes de VU, unidades insta ­
ladas en los vehículos 26.5.2016 L 139/368 Diar io Oficial de la Unión Europea ES    
Clave Símbolo Generada por Méto do de generación Almacenada por 
Clave maestra del sensor 
de movimiento — parte 
taller KM-W C ERCA Aleat orio ERCA, MSCA, fabr icante s 
de tarjetas, tarjetas de ta­
ller 
Clave maestra del sensor 
de movimiento KM No generada indepen ­
dientement e Calculada como KM = 
KM-V U XOR KM-W C ERCA, MSCA implicadas 
en la expedición de claves 
de sensores de movi­
mient o (opcionalmente) 
(*) 
Clave de identificación KID No generada indepen ­
dientement e Calculada como KID = KM 
XOR CV, donde CV se 
especifica en CSM_106 ERCA, MSCA implicadas 
en la expedición de claves 
de sensores de movi­
mient o (opcionalmente) 
(*) 
Clave de emparejamiento KP Fabri cant e del sensor de 
movimient o Aleat orio Un sensor de movi­
mient o 
Clave de sesión KS VU (durante el empare ­
jamiento de la VU y el 
sensor de movimient o) Aleat orio Una VU y un sensor de 
movimiento 
(*)  El almacenamiento de KM y KID es optativ o, ya que estas claves pueden derivarse de KM-V U, KM-WC y CV.  
CSM_101  La Autor idad del Certificado Raíz Europeo generará KM-V U yd KM-W C, dos claves AES aleatorias y 
únicas a partir de las cuales la clave maestra del sensor de movimient o KM se puede calcular como 
KM-V U XOR KM-W C. La ERCA comunicará previa solicitud las claves KM, KM-VU y KM-W C a las 
autori dades de certificació n de los Estados miembros. 
CSM_102  La ERCA asignará a cada clave maestra de sensor de movimient o KM un número de versión único, 
que será asimismo aplicable para las claves constitutivas KM-V U y KM-W C y para la clave de identif i­
cación asociada KID. La ERCA comunicará a las MSCA el número de versión al enviarles las claves 
KM-V U y KM-W C. 
Nota: El número de versión se usa para distinguir generaciones 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 KM-V U, 
junto con su número de versión, a los fabricantes de unidades instaladas en los vehículos. Los 
fabricantes de VU inser tarán la clave KM-V U 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 KM-W C, junto con 
su número de versión, sea inser tada en cada tarjeta de taller expedida bajo su responsabilidad. 
Notas: 
—  Véase la descr ipción del tipo de dato 
 en el apéndice 2. 
—  Como se indica en la sección 9.2.1.2, de hecho puede ser necesar io inser tar múltiples 
generaciones de la clave KM-W C 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 KmWC en 
TDES especifi cada en el requisito CSM_037 de la parte A del present e apéndice sea también 
inser tada en cada tarjeta de taller expedida bajo su responsabilidad. 26.5.2016 L 139/369 Diar io Oficial de la Unión Europea ES    
Notas: 
—  Esto permite utilizar una tarjeta de taller de segunda generación para emparejar una VU de 
primera generación. 
—  Una tarjeta de taller de segunda generación conte ndrá dos aplicaciones diferentes, una 
conf orme con la parte B del present e apéndice y otra conf orme con la parte A. Esta última 
cont endrá la clave KmWC en TDES. 
CSM_106 Las MSCA implicadas en la expedición de sensores de movimiento derivarán la clave de identifi ­
cación a partir de la clave maestra del sensor de movimient o aplicándole el operador XOR con un 
vect or constant e CV. El valor de CV será el siguiente: 
—  Para las claves maestras de sensor de movimient o de 128 bits: CV = ‘B6 44 2C 45 0E F8 D3 62 
0B 7A 8A 97 91 E4 5E 83’ 
—  Para las claves maestras de sensor de movimient o 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 vect ores constante s se han generado de la siguient e manera: 
Pi_10 = primeros 10 bytes de la porción decimal de la constante mate má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  Los fabricantes de sensores de movimient o generarán una clave de emparej amiento KP aleatori a y 
única para cada sensor de movimiento y enviarán cada clave de emparej amiento a la autori dad de 
certificación del Estado miembro. La MSCA cifrará cada clave de emparejamient o separadament e 
con la clave maestra KM del sensor de movimient o y devol verá la clave cifrada al fabricante del 
sensor de movimient o. Para cada clave cifrada, la MSCA notifi cará al fabricante del sensor de 
movimiento el número de versión de la KM asociada. 
Nota: como se indica en la sección 9.2.1.2, de hecho puede ser necesar io que un fabricante de 
sensores de movimient o tenga que generar claves de emparejamiento únicas múltiples para el 
mismo sensor de movimient o. 
CSM_108  Los fabr icante s de sensores de movimient o generarán un número de serie único para cada sensor 
de movimiento y enviarán todos los números de serie a la autoridad de certificación del Estado 
miembro. La MSCA cifrará cada número de serie separadament e con la clave de identificación 
maestra KID y devol verá el número de serie cifrado al fabricante del sensor de movimiento. Para 
cada número de serie cifrado, la MSCA notificará al fabr icante del sensor de movimient o el número 
de versión de la KID asociada. 
CSM_109  Para los requisitos CSM_107 y CSM_108, la MSCA utilizará el algor itmo AES in el modo de 
funcionamient o de cifrado progresivo por bloques, tal como se define en la norma [ISO 10116], 
con un parámetro interpolar m = 1 y un vect or de inicialización SV = ‘00’ {16}, es decir , dieciséis 
bytes con valor binar io 0. Cuando sea necesar io, la MSCA utilizará el método de relleno 2 definido 
en la norma [ISO 9797-1]. 
CSM_110  El fabr icante del sensor de movimiento almacenará la clave de emparejamient o cifrada y el número 
de serie cifrado en el sensor de movimient o de que se trate, junto con los valores de texto sencillo 
correspondientes y el número de versión de las claves KM y KID utilizadas para el cifrado. 
Nota: como se indica en la sección 9.2.1.2, de hecho puede ser necesar io que un fabricante de 
sensores de movimient o teng a que inser tar múltiples claves de emparej amiento cifradas y múltiples 
números de serie cifrados en el mismo sensor de movimient o. 26.5.2016 L 139/370 Diar io Oficial de la Unión Europea ES    
CSM_111  Además del mater ial criptográfico basado en la norma AES especificado en CSM_110, puede ser 
necesar io que un fabricante de sensores de movimiento teng a que almacenar asimismo en cada 
sensor de movimient o el mat erial criptográfic o en TDES especific ado en el requisito CSM_037 de la 
parte A del present e apéndice. 
Nota: esto permitirá que un sensor de movimient o de segunda generación pueda ser acoplado a 
una VU de primera generación. 
CSM_112  La longitud de la clave de sesión KS generada por una VU durante el emparejamient o con un sensor 
de movimient o estará relacionada con la longitud de su KM-V U, tal como se descr ibe en CSM_50. 
9.2.1.2  Sustitución de la clave maestr a del sensor de movim iento 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 movimient o comenzará un año antes de que adquiera 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. 
Figura 2 
Expedición y uso de diferentes generaciones de la clave maes tra del sensor de movimiento en las unidades 
inst aladas en los vehículos, sensores de movimiento y tarjetas de taller 
CSM_114  Al menos un año antes de generar un nuev o par de claves raíz europeo, tal como se descr ibe en el 
punt o CSM_56, la ERCA generará una nueva clave maestra del sensor de movimiento KM 
generando las nuevas claves KM-V U y KM-WC La longitud de la clave maestra del sensor de movimiento 
estará relacionada con la longitud prevista del nuev o par de claves raíz europeo, de conf ormidad 
con el punt o CSM_50. La ERCA comunicará, previa solicitud, las nuevas claves KM, KM-V U yd KM-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 KM-W C sean almacenadas en 
cada tarjeta de taller expedida bajo su autori dad, junto con su número de versión, tal como se 
indica en la Figure 2. 26.5.2016 L 139/371 Diar io Oficial de la Unión Europea ES    
Nota: esto imp lica 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-W C, tal como se 
indica en la Figure 2. 
CSM_116  En relación con el proceso descr ito anteriormente en CSM_107 y CSM_108: Las MSCA cifrarán 
cada clave de empa rejamiento KP que reciban de un fabr icante de sensores de movimiento separa ­
damente con cada generación válida de la clave maestra del sensor de movimiento KM. Las MSCA 
cifrarán asimismo cada número de serie que reciban de un fabricante de sensores de movimiento 
separadament e con cada generación válida de la clave de identificación KID. Los fabricantes de 
sensores de movimient o almacenarán todos los cifrados de la clave de empa rejamiento 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 correspondientes y el número o los números de versión de las claves KM y KID 
utilizadas para el cifrado. 
Nota: Esto implica que durant e el último año del período de validez de un certificado ERCA, los 
sensores de movimient o serán expedidos con datos cifrados basados en tres generaciones diferent es 
de la clave KM, tal como se indica en la Figure 2. 
CSM_117  En relación con el proceso descr ito anteriormente en CSM_107: Puesto que la longitud de la clave 
de emparejamient o KP estará relacionada con la longitud de la clave KM (véase CSM_100), es posible 
que un fabricante de sensores de movimient o tenga que generar hasta tres claves de empareja ­
miento diferentes (de diferent es longitudes) para un sensor de movimient o, para el caso en que 
generaciones post eriores de la clave KM tengan longitudes diferentes. En tal caso, el fabricante 
enviará cada clave de empa rejamiento a la MSCA . La MSCA garant izará que cada clave de emparej a­
miento 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 fabr icante de sensores de movimient o opte por generar en TDES una 
clave de emparej amiento para un sensor de movimiento de segunda generación (véase CSM_111), 
el fabricante indicará a la MSCA que para cifrar esta clave de emparejamient o debe emplearse la 
clave maestra en TDES del sensor de movimient o. 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 inser tarán solamente una generación de la 
clave KM-V U en cada unidad instalada en el vehículo, junto con su número de versión. Esta 
generación de clave KM-VU estará relacionada 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 certificado ERCA de generación X solamente 
deberá conte ner la clave KM-V U de generación X aun en el caso de que sea expedida después del 
inicio del período de validez del certificado ERCA de generación X+1. Esto viene ilustrado en la 
Figure 2. 
—  Una VU de generación X no puede emparej arse con un sensor de movimiento de generación X- 
1. 
—  Puest o 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 conte ndrán la nueva clave KM-W C en el 
momento en que sea expedida la primera VU que cont enga la nueva clave KM-V U. Por 
consiguiente, esa VU siempr e podrá calcular la nueva clave KM.. Además, para entonces la 
mayoría de los sensores de movimient o nuevos conte ndrán datos cifrados también basados en 
la nueva clave KM.. 
9.2.2  Claves de asegur amiento de comunicaciones dedicadas de corto alcance (DSRC) 
9.2.2.1  Gener alidades 
CSM_119  La autenti cidad y conf idencialidad de los datos comunicados desde una unidad instalada en el 
vehículo a una autori dad de control a través de un canal de comunicación remota DSR C se 
asegurará mediante una serie de claves AES específi cas de la VU derivadas de una única clave 
maestra de DSR C, KMDSR C. 
CSM_120  La clave maestra de DSR C KMDSR C será una clave AES generada, almacenada y distr ibuida 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 descr ibe en CSM_50. 26.5.2016 L 139/372 Diar io Oficial de la Unión Europea ES    
CSM_121  La ERCA comunicará previa solicitud la clave maestra DSR C a las autor idades de certificación de 
los Estados miembros de forma segura a fin de permitirles derivar claves DSR C específicas de las 
VU y asegurar que la clave maestra DSR C sea inser tada en todas las tarjetas de control y tarjetas de 
taller expedidas bajo su responsabilidad. 
CSM_122  La ERCA asignará a cada clave maestra DSR C un número de versión único. La ERCA comunicará a 
las MSCA el número de versión al enviarles la clave maestra DSR C. 
Nota: El número de versión se usa para distinguir generaciones diferentes de la clave maestra DSR C, 
como se explica en detalle en la sección 9.2.2.2. 
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 UV único y lo enviará a la autori dad de certificación de su Estado 
miembro en una solicitud de obtención de un conjunt o de dos claves DSR C específi cas de la VU. El 
número de serie de la VU tendrá el tipo de dato 
 , y para el cifrado se utilizarán 
las reglas de codificación distinguida (DER) según la norma [ISO 8825-1]. 
CSM_124  Cuando reciba una solicitud de claves DSR C específi cas de una VU, la MSCA derivará dos claves 
AES para la unidad instalada en el vehículo, denominadas K_VUDSR C_ENC y K_VUDSR C_MA C. Estas 
claves específicas de la VU tendrán la misma longitud que la clave maestra DSR C. La MSCA 
utilizará la función de derivación de claves definida en el document o [RFC 5869]. La función 
resumen (o función hash) necesar ia para instanciar la función HMA C-Hash estará relacionada con 
la longitud de la clave maestra DSR C, tal como se descr ibe en CSM_50. La función de derivación 
de la clave que figura en el documento [RFC 5869] se utilizará del siguient e modo: 
Paso 1 (Extraer): 
—  PRK = HMA C-Hash (salt, IKM) donde salt es una cadena vacía ‘’ e IKM es KMDSR C. 
Paso 2 (Expandir): 
—  OKM = T(1), donde 
T(1) = HMA C-Hash (PRK, T(0) || info || ‘01’) con 
—  T(0) = una cadena vacía (‘’) 
—  info = número de serie de la VU tal como se especifica en CSM_123 
—  K_VUDSR C_ENC = primeros octet os L de OKM y 
K_VUDSR C_MA C = últimos octet os L de OKM 
donde L es la longitud requer ida de K_VUDSR C_ENC y K_VUDSR C_MA C en octetos. 
CSM_125  La MSCA distr ibuirá las claves K_VUDSR C_ENC y K_VUDSR C_MA C al fabr icante 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 llevará almacenadas las claves 
K_VUDSR C_ENC y K_VUDSR C_MA C en su memor ia prot egida a fin de poder garantizar la integr idad, 
autenti cidad y conf idencialidad de los datos enviados por el canal de comunicación remota. Una 
unidad instalada en el vehículo también llevará almacenado el número de versión de la clave 
maestra DSR C utilizada para derivar estas claves específi cas de la VU. 
CSM_127  Una vez expedidas, las tarjetas de control y las tarjetas de taller llevarán almacenada la clave KMDSR C 
en su memor ia protegi da a fin de poder verificar la integr idad y autenticidad de los datos envi ados 
por una VU por un canal de comunicació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 DSR C. 
Nota: Como se indica en la sección 9.2.2.2, de hech o puede ser necesar io inser tar múltiples 
generaciones de la clave KMDSR C en la misma tarjeta de taller o tarjeta de control. 26.5.2016 L 139/373 Diar io Oficial de la Unión Europea ES    
CSM_128  La MSCA llevará un registro de todas las claves DSR C específicas de VU que haya generado, su 
número de versión y la identificación de las VU a las que se haya destinado cada conjunt o de 
claves. 
9.2.2.2  Sustitución de la clave maestr a DSRC 
CSM_129  Cada clave maestra DSR C está asociada a una generación concreta del par de claves raíz de la 
ERCA. Por consiguiente, la ERCA sustituirá la clave maestra DSR C dada 17 años. El período de 
validez de cada generación de clave maestra DSR C comenzará dos años antes de que adquiera 
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 se ilustra en la Figure 3. 
Figura 3 
Expedición y uso de diferentes generaciones de la clave maes tra DSR C en las unidades inst aladas en los 
vehículos, tarjetas de taller y tarjetas de control 
CSM_130  Al menos un año antes de generar un nuev o par de claves raíz europeo, tal como se descr ibe en el 
punt o CSM_56, la ERCA generará una nueva clave maestra DSR C. La longitud de la clave maestra 
DSR C estará relacionada con la longitud prevista del nuevo par de claves raíz europeo, de 
conf ormidad con el punto CSM_50. La ERCA comunicará, previa solicitud, la nueva clave DSR C, 
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 KMDSR C sean almacenadas en 
cada tarjeta de control expedida bajo su autori dad, 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 diferent es de la clave KMDSR C, tal como 
se indica en la Figure 2. 26.5.2016 L 139/374 Diar io Oficial de la Unión Europea ES    
CSM_132  Las MSCA garantizarán que todas las generaciones de la clave KMDSR C que hayan sido válidas 
durante al menos un año sean almacenadas en cada tarjeta de control expedida bajo su autor idad, 
junto con sus números de versión, tal como se indica en la Figure 2. 
Nota: esto imp lica 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 diferent es de la clave KMDSR C, tal como se 
indica en la Figure 2. 
CSM_133  Los fabricantes de unidades instaladas en los vehículos inser tarán solamente un conjunt o de claves 
DSR C 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 KMDSR C 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 solamente deberá cont ener las claves K_VUDSR C_ENC KM-V U y K_VUDSR C_MA C 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 generación X+1., tal como se indica en la Figure 3. 
—  Puest o 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 toda s las tarjetas de taller y tarjetas 
de control contendrán la nueva clave maestra DSR C en el momento en que sea expedida la 
primera VU que conteng a claves específicas de la VU basadas en esa clave maestra. 
9.3.  Cer tificados 
9.3.1  Gener alidades 
CSM_134 Todos los certificados del sistema europeo de tacógraf o intelig ente serán certificado s autod es­
criptiv os y verificables con tarjeta (CV) de acuerdo con las normas [ISO 7816-4] y [ISO 7816-8]. 
CSM_135  A fin de codificar tanto las estructuras de datos ASN.1 como los objeto s de datos (específi cos de 
las aplicaciones) en los certificados, se utilizarán las reglas de codif icación distinguida (DER) de 
acuerdo con la norma [ISO 8825-1]. 
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 entero no firmado en uno, dos, o tres 
octetos, que resultan en una longitud máxima de 65 535 octet os. 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 certificado s tendrá la estructura indicada en el perf il de certificado de la Table 4. 
Tabla 4 
Perf il de certificado versión 1 
Cam po ID del cam po Etiqueta Longitud 
(bytes) Tipo de dato ASN.1 
(véase el apéndice 1) 
Certificado ECC C ‘7F 21’ var  
Org anismo de certificación ECC B ‘7F 4E’ var  26.5.2016 L 139/375 Diar io Oficial de la Unión Europea ES    
Cam po ID del cam po Etiqueta Longitud 
(bytes) Tipo de dato ASN.1 
(véase el apéndice 1) 
Identificad or del perf il de certificado CPI ‘5F 29’ ‘01’ 
Referencia de la autori dad de certificación CAR ‘42’ ‘08’ 
Autor ización del titular del certificado CHA ‘5F 4C’ ‘07’ 
Clave pública PK ‘7F 49’ var  
Parámetros de dominio DP ‘06’ var 
Punt o 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 individuales de un certificado, por ejemplo, X.CAR es la referencia de la autoridad 
de certificación mencionada en el certificado del usuar io X. 
9.3.2.1  Identif icador del perf il de certificado 
CSM_137  Los certificados utilizarán un identificador del perf il de certificado para indicar el perf il de 
certificado utilizado. La versión 1, tal como se especifi ca en la Table 4, se identif icará con el valor 
‘00’. 
9.3.2.2  Referencia de la autori dad de certificación 
CSM_138  La referencia de la autor idad de certificación se utilizará para identif icar la clave pública que se 
deberá utilizar para verificar la firma del certificado. La referencia de la autoridad de certificación 
será por tanto igual a la referen cia del titular del certificad o en el certificado de la autori dad de 
certificación correspondiente . 
CSM_139  Un certificado raíz de la ERCA estará autofir mado, es decir , la referencia en el certificado de la 
autori dad de certificación y del titular del certificado serán iguales. 
CSM_140  Para un certificad o de enlace ERCA, la referencia del titular del certificado será igual a la CHR del 
nuevo certificado raíz de la ERCA. La referen cia de la autor idad de certificación para un certificado 
de enlace será igual a la CHR del certificado raíz ERCA anter ior. 
9.3.2.3  Autorización del titular del certificado (CHA) 
CSM_141  La autori zación del titular del certificado servirá para identif icar el tipo de certificado. Se compo ne 
de los seis bytes más signif icativ os del identif icador de la aplicación del tacógraf o, concat enados 
con el tipo de equipo al que está destinado el certificado. 26.5.2016 L 139/376 Diar io Oficial de la Unión Europea ES    
9.3.2.4  Clave pública 
La clave pública anida dos elementos de datos: los parámetros de dominio normalizados que deberán 
utilizarse con la clave pública en el certificado y el valor del punt o público. 
CSM_142 El element o de datos Domain Parameters contendrá uno de los identificadores de objeto especi ­
ficados en la Table 1 para referen ciar un conjunt o de parámetros de dominio normalizados. 
CSM_143  El elemento de datos Public Point contendrá el punto público. Los punt os públicos de curva elíptica 
se conver tirán en cadenas de octetos tal como se especifi ca en la directr iz técnica [TR-03111]. Se 
utilizará el formato de codificación descom primido. Al recuperar un punt o de curva elíptica de su 
formato codificado , siempre se efectuarán las validaciones descr itas en la directr iz técn ica [TR- 
03111]. 
9.3.2.5  Referencia del titular del certificado (CHR) 
CSM_144  La referen cia del titular del certificado es un identif icador de la clave pública indicado en el 
certificado. Se utilizará para referenciar esta clave pública en otros certificados. 
CSM_145  Para los certificados de tarjeta y los certificados de dispositivo GNSS externo, la referencia del 
titular del certificado tendrá el tipo de dato 
 especificado 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 
especificado en el apéndice 1. 
CSM_147  En relación con los certificados ERCA y MSCA , la referencia del titular del certificado tendrá el tipo 
de dato 
 especific ado en el apéndice 1. 
9.3.2.6  Fecha efectiva del certificado 
CSM_148  La fecha efectiva del certificado indicará la fecha y hora de inicio del período de validez del 
certificado. La fecha efectiva del certificado será la fecha de generación del certificado. 
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 cont enido codificado del certificado, incluidas la 
etiqueta y la longitud del conte nido del certificado. El algor itmo de firma será ECDSA, tal como se 
especifica en la norma [DSS], utilizando el algor itmo hash relacionado con el tamaño de la clave de 
la autori dad firmante, tal como se especifica en CSM_50. El format o de la firma será de texto 
plano, tal como se especifica en la directr iz técnica [TR-03111]. 
9.3.3  Solicitud de certifica dos 
CSM_151  Al solicitar un certificad o, el solicitant e enviará los siguient es datos a su autor idad de certificación: 
—  el identif icador del perf il de certificado del certificado solicitado 
—  la referencia de la autori dad de certificación prevista para la firma del certificado 
—  la clave pública que deba firmarse 26.5.2016 L 139/377 Diar io Oficial de la Unión Europea ES    
CSM_152  Además de los datos indicados en CSM_151, en una solicitud de certificado las MSCA enviarán los 
siguient es datos a la ERCA a fin de permitirle crear la referencia del titular del certificado de nuevo 
certificado MSCA: 
—  el código numér ico del país de la autori dad de certificación (tipo de dato 
definido en el apéndice 1) 
—  el código alfanumér ico del país de la autori dad de certificación (tipo de dato 
definido en el apéndice 1) 
—  el número de serie de 1 byte para distinguir las diferentes claves de la autori dad de certificació n 
en caso de que se cambien las claves 
—  el camp o de dos bytes que contiene la información adicional específi ca de la autori dad de 
certificación 
CSM_153  Además de los datos indicados en CSM_151, en una solicitud de certificado los fabricantes de 
equipos enviarán los siguiente s datos a la MSCA a fin de permitirle crear la referencia del titular del 
certificado del nuevo certificado de equipo: 
—  un identif icador específi co del fabricante del tipo 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 contrar io, un identificador único de la solicitud 
de certificado. 
—  El mes y año de fabr icación del equipo o de solicitud del certificado. 
El fabricante garantizará que estos datos sean correctos y que el certificado devuelt o por la MSCA 
sea inser tado en el equipo previsto. 
CSM_154  En el caso de una VU, 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. Si lo conoce, el fabr icante de VU enviará el número de serie a la MSCA . Si 
no lo conoce, el fabr icante identif icará de forma unív oca cada solicitud de certificado y enviará este 
número de serie de solicitud de certificado a la MSCA . El certificado resultante conte ndrá el 
número de serie de la solicitud de certificado . Una vez inser tado 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 identif icación de la VU a la MSCA . 
10.  AUTENTICA CIÓN MUTU A DE LA TARJET A VU_CARD Y MENSA JERÍA SEGURA 
10.1.  Generalidades 
CSM_155  A un nivel elevado, la comunicación segura entre una unidad instalada en el vehículo y una tarjeta 
de tacógraf o se basará en los siguient es pasos: 
—  En primer lugar , cada parte demostrará a la otra que detenta un certificado de clave pública 
válido y firmado por una autori dad de certificación de un Estado miembro. A su vez, el 
certificado de clave pública MSCA debe estar firmado por la Autor idad 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 luga r, 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 certificado presentado 
firmando un número aleat orio enviado por la tarjeta. La tarjeta verifica la firma a través del 
número aleatori o. Si la verificación se efectúa correctamente, se autentica la VU. Este paso se 
denomina autenti cación de la VU y se especifica en detalle en la sección 10.3 26.5.2016 L 139/378 Diar io Oficial de la Unión Europea ES    
—  En tercer lugar , ambas partes calculan por separado dos claves de sesión AES utilizando un 
algor itmo de cifrado asimétr ico. Usando una de estas claves de sesión, la tarjeta crea un código 
de autenticación de mensaj e (MA C) a través de datos envi ados por la VU. La VU verifica el 
MAC. Si la verificación se efectúa correctamente, se aute ntica la tarjeta. Este paso se denomina 
aute nticación de la tarjeta y se especifi ca en detalle en la sección 10.4 
—  En cuar to lugar , la VU y la tarjeta usarán las claves de sesión acordadas para asegurar la 
confidencialidad, integr idad y autenti cidad de todos los mensaj es intercambiados. Esto se 
denomina mensaj ería segura y se especifica en detalle en la sección 10.5 
CSM_156  El mecanismo descr ito en CSM_155 será desencadenado por la unidad del vehículo siempr e que se 
inser te 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  Las unidades instaladas en el vehículo utilizarán el protocolo ilustrado en la Figure 4 para verificar 
la cadena de certificados de una tarjeta de tacógraf o. 
Notas de la Figure 4: 
—  Los certificados de tarjeta y las claves públicas mencionados en la figura son los empleados 
para la aute nticación mutua. La sección 9.1.5 los denota Card_MA. 
—  Los certificados Card.C A y las claves públicas mencionados en la figura son los emple ados 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á 
present e. Tal como se especific a en la sección 9.1.2, este es el certificad o de enlace para un 
nuev o par de claves raíz europeo creado por la ERCA y firmado por la clave privada europea 
anterior. 
—  El certificado Card.Link.E UR es el certificado raíz europeo indicado en la referencia CAR del 
certificado Card.Link. 
CSM_158  Tal como ilustra la Figure 4, la verificación de la cadena de certificad os de la tarjeta se iniciará al 
inser tar 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 verificad o correctamente la cadena de certificados de la tarjeta en el pasado 
y la ha almacenado para futuras referen cias. Si la conoce y el certificad o de la tarjeta es toda vía 
válido, el proceso continúa con la verificació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 certificado de la tarjeta, el certificado Card.C A.EUR necesar io para verificar el certificado 
MSCA_ Card y, posiblemente, el certificad o de enlace, hasta que encuentre un certificado que 
conozca o pueda verificar . Si encuentra dicho certificado, la VU lo utilizará para verificar los 
certificados de tarjeta suby acentes que ha leído en la tarjeta. Si la verificació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 certificad o Card.C A.EUR es el mismo certificad o que el propio certificado EUR de la VU; 26.5.2016 L 139/379 Diar io Oficial de la Unión Europea ES    
—  el certificado Card.CA .EUR precede al propio certificado EUR de la VU, y la VU ya cont enía 
este certificado en el moment o 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ógraf o, la verificó y la almacenó 
para referencias futuras. 
CSM_159  Como se indica en la Figure 4, una vez que la VU ha verificado la autenti cidad y validez de un 
certificado previamente desconocido, puede almacenar este certificado para referen cias futuras, de 
modo que no teng a que volver a verificar la autenticidad del certificado si se vuelve a presentar a la 
VU. En lugar de almacenar la totalidad del certificado, una VU puede optar por almacenar 
solamente el contenido del certificad o, tal como se especifica en la sección 9.3.2. 
CSM_160  La VU verificará la validez temporal de todos los certificados leídos en la tarjeta o almacenados en 
su memor ia, y rech azará los certificados caducados. Para verificar la validez temporal de un 
certificado presentado por la tarjeta, la VU utilizará su reloj intern o.  26.5.2016 L 139/380 Diar io Oficial de la Unión Europea ES    
Figura 4 
Prot ocolo 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  Las tarjetas de tacógraf o utilizarán el protocolo ilustrado en la Figure 5 para verificar la cadena de 
certificados de una VU. 26.5.2016 L 139/381 Diar io Oficial de la Unión Europea ES    
Figura 5 
Protocolo para la verificación por una tarjeta de la cadena de certificados de una VU 
26.5.2016 L 139/382 Diar io Oficial de la Unión Europea ES    
Notas de la Figure 5: 
—Los certificados de VU y las claves públicas mencionados en la figura son los empleado s para la autenti ­
cación mutua. La sección 9.1.4 los denota VU_MA. 
—  Los certificados VU.CA y las claves públicas mencionados en la figura son los emplea dos 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.C A. 
—  El certificado VU.Link mencionado en la figura es el certificado de enlace de la VU, si está present e. 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 anter ior. 
—  El certificado VU.Link.E UR es el certificad o 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 intent e establecer su propia clave pública para su uso en la tarjeta 
de tacógraf o. Si esto se efectúa correctamente, signif ica que la tarjeta ha verificado con éxito 
anteriormente la cadena de certificado s de la VU y ha almacenado el certificado VU para 
referen cias futuras. En este caso, el certificado VU está listo para usar y el proceso continúa con la 
autenti cación de la VU. Si la tarjeta no conoce el certificado de la VU, la VU presentará sucesi ­
vament e el certificado MSCA_VU necesar io para verificar el certificado de la VU, el certificado VU. 
CA.EUR necesar io para verificar el certificado MSCA_ VU y, posiblemente, el certificado de enlace, 
hasta encontrar un certificado conocido o verificable por la tarjeta. Si encuentra dicho certificado, 
la tarjeta lo utilizará para verificar los certificados VU subyacent es que le sean presentados. Si la 
verificación se efectúa correctamente, la VU establecerá finalment e su clave pública para uso en la 
tarjeta de tacógraf o. Si no puede efectuarse la verificación, la VU ignorará la tarjeta. 
Nota: La tarjeta puede conocer el certificado VU.CA .EUR de tres maner as: 
—  el certificad o VU.C A.EUR es el mismo certificad o 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 
cont enía este certificado 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. 
CSM_163  La VU utilizará el comando MSE (Message Secur ity Environment): Set AT para establecer su clave 
pública para uso en la tarjeta de tacógraf o. 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 algor itmo ECDSA, en combinación con el 
algor itmo hash relacionado 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 
tarjeta. El par de claves efímero se denota por (VU.SKeph, VU.PKeph, Card.DP). La VU considerará la 
coordenada x del punto público efímero ECDH como la identif icación de la clave; esto se 
denomina la representación compr imida de la clave pública y se denota por Com p(VU.PKeph). 
CSM_165  Si el comando MSE: Set AT se ejecuta correctamente, la tarjeta establecerá la VU.PK indicada para 
su uso poste rior durante la aute nticación del vehículo, y almacenará temporalmente Comp(VU. 
PKeph). En el caso de que se enví en dos o más comandos MSE: Set AT ejecutados correctamente 
antes de efectuar el acuerdo de claves de sesión, la tarjeta almacenará únicamente la última Comp 
(VU.PKeph) recibida. 26.5.2016 L 139/383 Diar io Oficial de la Unión Europea ES    
CSM_166 La tarjeta verificará la validez temporal de todos los certificados presentados por la VU o referen ­
ciados por la VU mientras están almacenados en la memor ia de la tarjeta, y rechazará los 
certificados caducados. 
CSM_167  Para verificar la validez temporal de un certificado presentado por la VU, cada tarjeta de tacógraf o 
almacenará internament e datos que represent en la hora actual. Estos datos no serán directament e 
actualizables por una VU. En el momento de su expedición, la hora actual de una tarjeta que se 
conf igurará será la misma que la fecha efectiva del certificado 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 
conf igurará su hora actual a la fecha efectiva de ese certificad o. La tarjeta solamente acepta rá los 
certificados siguient es como fuent e 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. 
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 
referen cia 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 previamente desconocido, puede almacenar este certificado para referen cias futuras, de 
modo que no teng a 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 
solamente el contenido del certificad o, 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 protocolo 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ógraf o 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  Junto a la comprobación de la tarjeta, la VU incluirá en la firma la referencia del titular de la tarjeta 
extraída del certificado de la tarjeta. 
Nota: De esta forma se garantiza que la tarjeta ante la cual se aute ntica 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 identif icador de la clave pública efímera Comp(VU.PKeph) 
que la VU utilizará para establecer la mensajería segura durant e 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 durant e la sesión de 
mensaj ería segura es la misma VU que fue autenti cada por la tarjeta.  26.5.2016 L 139/384 Diar io Oficial de la Unión Europea ES    
Figura 6 
Protocolo de autenticación de VU 
CSM_172  Si durante la aute nticación de VU la VU envía múltiples comandos GET CHALLENGE, la tarjeta 
devol verá una nueva compr obación aleatori a de 8 bytes cada vez, pero solamente almacenará la 
última comprobació n. 
CSM_173  El algor itmo de firma utilizado por la VU para la autenticación de VU será el algor itmo ECDS A, tal 
como se especifica en la norma [DSS], utilizando el algor itmo hash relacionado 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 directr iz técnica [TR-03111]. La VU envi ará la 
firma resultante a la tarjeta. 
CSM_174  Al recibir la firma de la VU en un comando EXTERNAL AUTHENTICA TE, la tarjeta: 
—  calculará el token de autenti cación concatenando Card.CH R, la compr obación de tarjeta rcard y 
el identif icador de la clave pública efímera de la VU Com p(VU.PKeph); 
—  calculará el algor itmo hash a través del token de autenticación mediante el algor itmo hash 
relacionado con el tamaño de clave del par de claves VU_MA de la VU, tal como se especifica 
en CSM_50; 
—  verificar á la firma de la VU mediante el algor itmo ECDSA en combinación con la clave VU.PK y 
el algor itmo hash calculado. 
10.4.  Autenticación de chip y acuerdo de clav es de sesión 
CSM_175  Las unidades instaladas en los vehículos utilizarán el prot ocolo Autenticación de chip ilustrado en 
la Figure 7 para autenti car 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énti ca. 26.5.2016 L 139/385 Diar io Oficial de la Unión Europea ES    
Figure 7 
Autenticación de chip y acuerdo de claves de sesión 
CSM_176  La VU y la tarjeta efectuarán los siguiente s 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 algor itmo 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 especifi ca 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.  
2. La VU envía el punto público VU.PKeph de su par de claves efímero a la tarjeta. 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.PKeph) a 
la tarjeta, y la tarjeta lo almacenó.  
3. La tarjeta computa Comp(VU.PKeph) a partir de la clave VU.PKeph y compara el resultado con el 
valor almacenado de Comp(VU.PKeph).  
4. Mediant e el algor itmo 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 aleat orio de 8 bytes NPICC mediante el cual deriva dos claves de 
sesión AES KMAC y KENC a partir de K. Véase CSM_179.  
6. Mediant e la clave KMAC, la tarjeta computa un token de autenticación a través del identificador 
de la clave pública efímera de la VU: TPICC = CMA C(KMAC, VU.PKeph). La tarjeta envía NPICC y TPICC 
a la unidad instalada en el vehículo.  
7. Mediant e el algor itmo 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 secreta que comput ó la tarjeta en el 
paso 4. 26.5.2016 L 139/386 Diar io Oficial de la Unión Europea ES    
8. La VU deriva la claves de sesión KMAC y KENC a partir de K y NPICC; véase CSM_179.  
9. La VU verifica el token de autenticación TPICC. 
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 algor itmo 
ECKA -EG tal como se define en la directr iz técnica [TR-03111]. 
CSM_179  En los pasos 5 y 8 anter iores, 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 directr iz técnica [TR-03111], con las 
siguient es precisiones y cambios: 
—  El valor del contador será ‘00 00 00 01’ para KENC y ‘00 00 00 02’ para KMAC. 
—  Se usará el nonce opcional r igual a NPICC. 
—  Para derivar claves AES de 128 bits, se deberá utilizar el algor itmo hash SHA-256. 
—  Para derivar claves AES de 192 bits, se deberá utilizar el algor itmo hash SHA-384. 
—  Para derivar claves AES de 256 bits, se deberá utilizar el algor itmo 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. 
CSM_180  En los pasos 6 y 9 anteriores, la tarjeta y la unidad instalada en el vehículo utilizarán el algor itmo 
en modo CMA C, tal como se especifica en define en la publicación especial del NIST [SP 800-38B]. 
La longitud de TPICC estará relacionada 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  Gener alidades 
CSM_181  Todos los comandos y respuestas inter cambiados entre una unidad instalada en el vehículo y una 
tarjeta de tacógraf o tras la autenticación correcta del chip y hasta el final de la sesión estarán 
prote gidos por mensaj ería segura. 
CSM_182  Salv o durante la lectura en un archiv o con la condición de acceso SM-R -ENC-MA C-G2 (véase el 
apéndice 2, sección 4), la mensaj ería segura se utilizará en modo solo autenticación. En este modo, 
una suma de comprobación criptográfi ca, también llamada código de autenti cación de mensaj es 
(MA C), se añade a todos los comandos y respuestas para garantizar la autenti cidad e integridad de 
los mensaj es. 
CSM_183  Al leer los datos de un arch ivo con la condición de acceso SM-R -ENC-MA C-G2, la mensaj ería 
segura se utilizará en el modo cifrar y después autenticar , es decir , primero se cifran los datos de 
respuesta para asegurar la confidencialidad del mensaj e, y después se calcula un MAC con los datos 
cifrados format eados para asegurar la autenticidad e integridad. 
CSM_184  La mensaj ería segura utilizará la norma AES tal como se define en [AES] con las claves de sesión 
KMAC y KENC 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 format o 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 mensaj ería 
segura. El SSC se incrementará cada vez antes de generar un comando o respuesta 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. 26.5.2016 L 139/387 Diar io Oficial de la Unión Europea ES    
CSM_186 Para el cifrado de mensaj es se utilizará la clave KENC con AES en el modo de operación de encadena ­
miento de bloques de cifrado (CBC), tal como se define en la norma [ISO 10116], con un 
parámetro interpolar m = 1 y un vect or de inicialización SV = E(KENC, SSC), es decir , el valor actual 
del contador de envío de secuencia cifrado con la clave KENC. 
CSM_187  Para la autenti cación de mensaj es, se utilizará la clave KMAC con AES en el modo CMA C, tal como 
se especifi ca 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 especific a 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 autenti car. 
10.5.2  Estructur a de mensaje segur a 
CSM_188  La mensaj ería segura utilizará solamente los objeto s de datos de mensaj ería segura (véase la norma 
[ISO 7816-4]) enumerados en la Table 5. En cualquier mensaj e, estos objeto s de datos se utilizarán 
en el orden especificado en esta tabla. 
Tabla 5 
Objet os de datos de mensajería segura 
Nombre de objeto de datos Etiqueta Presencia oblig ator ia (M), condicional 
(C) o prohibida (F) en 
Comandos Respuestas 
Valor plano no codif icado en BERL- TLV ‘81’ C C 
Valor plano codificado en BERL- TLV, pero excl ui­
dos los DO de SM ‘B3’ C C 
Indicador de contenido de relleno seguido de 
criptograma, valor plano no codificad o en BER - 
TLV ‘87’ C C 
Le prote gida ‘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ógraf o pueden sopor tar el comando 
READ BINAR Y y UPD ATE BINAR Y con un byte INS impar (‘B1’ resp. ‘D7’). Estas variante s de 
comando son necesar ias 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 objeto s de datos de SM (mensaj ería segura) se codificarán en DER TLV, tal como se 
especifica en la norma [ISO 8825-1]. 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 entero no firmado en uno, dos, o tres 
octetos, que resultan en una longitud máxima de 65 535 octet os. Se utilizará el número 
de octetos mínimo. 
Valor:  El valor está codificado en cero o más octetos. 26.5.2016 L 139/388 Diar io Oficial de la Unión Europea ES    
CSM_190  Las unidades de datos de prot ocolo de aplicación (APDU) prote gidas mediante mensaj ería segura se 
crearán de la siguiente 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’. 
—  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 BINAR Y y UPD ATE BINAR Y. 
—  El valor real de Lc se modifi cará a Lc' tras la aplicación de la mensajería segura. 
—  El campo Datos estará compuest o de objeto s de datos SM. 
—  En el comando prote gido APDU, el nuevo byte Le se conf igurará a ‘00’. En caso necesar io, el 
objeto de datos ‘97’ se incluirá en el campo Datos a fin de comunicar el valor original de Le. 
CSM_191  Los objetos de datos que deban cifrarse se rellenarán de acuerdo con la norma [ISO 7816-4] 
mediante el indicador de conte nido de relleno ‘01’. Para el cálculo del MAC, cada objeto de datos 
de la APDU se rellenará también separadamente conf orme a la norma [ISO 7816-4]. 
Nota: El relleno para la mensajería segura siempr e es efectuado por la capa de mensajería segura, no 
por los algor itmos CMA C o CBC. 
Resumen y ejemplos 
Un comando APDU con mensaj ería segura aplicada tendrá la siguient e estructura, dependiendo del caso del 
comando no secur izado correspondiente (DO signif ica 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 mensaj ería segura aplicada tendrá la siguiente estructura, dependiendo del caso del 
comando no secur izado correspondiente: 
Caso 1 o 3: DO ‘99’ || DO ‘8E’ || SW1SW2 
Caso 2 o 4 (byte INS par) con cifrado: DO ‘81’ || DO ‘99’ || DO ‘8E’ || SW1SW2 
Caso 2 o 4 (byte INS par) sin cifrado: DO ‘87’ || DO ‘99’ || DO ‘8E’ || SW1SW2 
Caso 2 o 4 (byte INS impa r) 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. 26.5.2016 L 139/389 Diar io Oficial de la Unión Europea ES    
A continuación figuran tres ejemplos de transf ormaciones APDU para comandos con código INS par. La 
Figure 8 muestra un comando APDU de caso 4 aute nticado, la Figure 9 muestra una respuesta APDU de caso 
2/caso 4 aute nticada, y la Figure 10 muestra una respuesta APDU de caso 2/caso 4 cifrada y autenti cada. 
Figura 8 
Transf ormación de un comando APDU de caso 4 autenticado 
Figura 9 
Transforma ción de una respuest a APDU de caso 1/caso 3 autenticada 
26.5.2016 L 139/390 Diar io Oficial de la Unión Europea ES    
Figura 10 
Transforma ción de una respuest a APDU de caso 2/caso 4 cifrada y autenticada 
10.5.3  Abor to de sesión de mensajería segur a 
CSM_192  Una unidad instalada en el vehículo abor tará una sesión de mensaj ería segura en curso solamente si 
si se da una de las condiciones siguient es: 
—  recibe una respuesta APDU plana; 
—  detecta un error de mensaj ería segura en una respuesta APDU: 
—  falta un objeto de datos de mensaj ería segura esperado, el orden de los objeto s de datos es 
incor recto, o hay incluido un objeto de datos desconocido; 
—  un objeto de datos de mensajería segura es incor recto, por ejemplo, el valor MAC es 
incor recto, la estructura TLC es incor recta, 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 detectado un error SM (véase CSM_194); 
—  se ha alcanzado el límite de número de comandos y respuestas asociadas en la sesión actual. 
Este límite lo definirá para cada VU concreta su fabricante, teniendo en cuenta los requisitos de 
segur idad del sopor te físico utilizado, con un valor máximo de 240 comandos y respuestas 
asociadas de SM por sesión. 
CSM_193  Una tarjeta de tacógraf o abor tará una sesión de mensajería segura en curso solamente si se da una 
de las condiciones siguient es: 
—  recibe un comando APDU plano; 26.5.2016 L 139/391 Diar io Oficial de la Unión Europea ES    
—  detecta un error de mensaj ería segura en un comando APDU: 
—  falta un objeto de datos de mensaj ería segura esperado, el orden de los objeto s de datos es 
incor recto, o hay incluido un objeto de datos desconocido; 
—  un objeto de datos de mensajería segura es incor recto, por ejemplo, el valor MAC es 
incor recto o la estructura TLC es incor recta; 
—  no recibe alimentación eléctr ica o ha sido restaurada; 
—  la VU selecciona una aplicación de la tarjeta; 
—  la VU inicia el proceso de autenticación de la VU; 
—  se ha alcanzado el límite de número de comandos y respuestas asociadas en la sesión actual. 
Este límite lo definirá para cada tarjeta concreta su fabricante, teniendo en cuenta los requisitos 
de segur idad del sopor te físico utilizado, con un valor máximo de 240 comandos y respuestas 
asociadas de SM por sesión. 
CSM_194  En relación con la gestión de errores SM por la tarjeta de tacógraf o: 
—  Si en un comando APDU faltan objeto s de datos de mensajería segura esperados, el orden de 
los objeto s de datos es incor recto, o hay incluidos objeto s de datos incor rectos o desconocidos, 
la tarjeta de tacógraf o responderá con los bytes de estado ‘69 87’. 
—  Si un objeto de datos de mensaj ería segura en un comando APDU es incor recto, la tarjeta de 
tacógraf o responderá con los bytes de estado ‘69 88’. 
En tal caso, los bytes de estado se devolverán sin usar la mensaj ería segura. 
CSM_195  Si una sesión de mensajería segura entre una VU y una tarjeta de tacógraf o se abor ta, la VU y la 
tarjeta de tacógraf o: 
—  destr uirá de forma segura las claves de sesión almacenadas; 
—  establecerá inmediatament e una nueva sesión de mensaj ería segura, como se descr ibe en las 
secciones 10.2 — 10.5. 
CSM_196  Si, por cualquier razón, la VU decide reiniciar la autenti cación mutua frente a una tarjeta inser tada, 
el proceso se reiniciará con la verificación de la cadena de certificados de la tarjeta, tal como se 
descr ibe en la sección 10.2, y continuará en la forma descr ita en las secciones 10.2 — 10.5. 
11.  ACOPL AMIENTO, AUTENTICA CIÓN MUTU A Y MENSAJERÍA SEGURA ENTRE LA VU Y EL DISPOSITIV O GNSS 
EXTERNO 
11.1.  Generalidades 
CSM_197  El dispositivo GNSS utilizado por una VU para determinar su posición puede ser intern a (es decir , 
montada dentro de la caja de la VU y no separable), o puede ser un módulo externo. En el primer 
caso, no hay necesidad de normalizar la comunicación interna entre el dispositivo GNSS y la VU, y 
los requisitos del present e capítulo no son de aplicación. En el último caso, la comunicación entre 
la VU y el dispositivo GNSS extern o estará normalizada y prot egida tal como se descr ibe en este 
capítulo. 
CSM_198  La comunicación segura entre una unidad instalada en el vehículo y un dispositivo GNSS exte rno 
tendrá lugar de la misma forma que una comunicación segura entre una unidad instalada en el 
vehículo y una tarjeta de tacógraf o, donde el dispositivo GNSS externo (EGF) tiene la función de 
tarjeta. Las EGF cumpli rá todos los requisitos mencionados en el capítulo 10 para las tarjetas de 
tacógraf o teniendo en cuenta las desviaciones, clarificaciones y añadidos mencionados en el 
present e capítulo. En particular , la verificación mutua de la cadena de certificad os, la aute nticación 
de la VU y la autenticación del chip se efectuará tal como se descr ibe en las secciones 11.3 y 11.4. 26.5.2016 L 139/392 Diar io Oficial de la Unión Europea ES    
CSM_199  La comunicación entre una unidad instalada en el vehículo y una EGF difiere de la comunicación 
entre una unidad instalada 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 inter cambiar 
datos basados en el GNSS durante el funcionamient o normal. El proceso de acoplamient o se 
descr ibe 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 present e anex o. 
11.2.  Aco plamiento entre la VU y el dispositiv o GNSS exter no 
CSM_201 Una unidad instalada en el vehículo y una EGF de un vehículo se acoplarán en un taller . En funcio ­
namiento 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 vehículo está en modo calibración. El acoplamiento será iniciado 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 destr uirá de forma segura el certificado 
EGF_MA existent e en su memor ia 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. Durant e el reacoplamient o, la EGF destr uirá de forma segura el certificado VU_MA 
existen te en su memor ia y almacenará el certificad o VU_MA de la VU a la que esté siendo 
acoplada. 
11.3.  Verificación mutua de la cadena de certificados 
11.3.1  Gener alidades 
CSM_205  La verificación mutua de la cadena de certificado s entra una VU y una EGF se efectuará solamente 
durante el acoplamient o de la VU y la EGF por un taller . Durant e el funcionamient o normal de una 
VU y una EGF acopladas, no se verificará ningún certificado. En lugar de eso, la VU y la EGF 
conf iarán en los certificados que hayan almacenado durante el acoplamiento, una vez comproba da 
la validez temporal de los mismos. La VU y la EGF no conf iarán en ningún otro certificado para 
prote ger la comunicación entre la VU y la EGF durante el funcionamient o normal. 
11.3.2  Durante el acoplamiento entre la VU y la EGF 
CSM_206  Durant e el acoplamient o a una EGF , la unidad instalada en el vehículo utilizará el prot ocolo 
ilustrado en la Figure 4 (sección 10.2.1) para verificar la cadena de certificados del dispositivo 
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 inteligent e y, por consiguiente , la VU probablement e no mandará un 
comando Restaurar (Reset) para iniciar la comunicación y no recibirá una respuesta ATR. 
—  Los certificado s de tarjeta y las claves públicas mencionadas en la figura se interpretarán como 
los certificados de la EGF y las claves públicas para aute nticació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 certificad os de la MSCA y las claves públicas para firmar certificados 
EGF . La sección 9.1.3 los denota MSCA_ VU-EGF . 26.5.2016 L 139/393 Diar io Oficial de la Unión Europea ES    
—  El certificado Card.C A.EUR mencionado en la figura se interpretará como el certificado raíz 
europeo indicado en la referen cia CAR del certificado MSCA _VU-EGF . 
—  El certificado Card.Link mencionado en la figura se interpretar á como el certificado de enlace 
de la EGF , si está present e. Tal como se especifica en la sección 9.1.2, este es el certificado de 
enlace para un nuev o par de claves raíz europeo creado por la ERCA y firmado por la clave 
privada europea anterior. 
—  El certificado Card.Link.E UR es el certificado raíz europeo indicado en la referencia CAR del 
certificado Card.Link. 
—  En luga r del 
 , la VU leerá el 
 del 
arch ivo EF ICC. 
—  En lugar de seleccionar el AID del tacógraf o, la VU seleccionará el AID de la EGF . 
—  ‘Ignore Card’ se interpretará como ‘Ignore EGF’. 
CSM_207  Una vez verificado el certificado EGF_MA, la unidad instalada en el vehículo almacenará el 
certificado para utilizarlo durant e el funcionamiento normal. Véase la sección 11.3.3. 
CSM_208  Durant e el acoplamiento a una VU, una unidad GNSS exte rna utilizará el protocolo ilustrado en la 
Figure 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 utilizando los parámetros de dominio del 
certificado EGF . 
—  Los certificad os de VU y las claves públicas mencionados en la figura son los empleados para la 
aute nticación mutua. La sección 9.1.4 los denota VU_MA. 
—  Los certificados VU.C A y las claves públicas mencionados en la figura son los empleados para 
firmar los certificados de VU y de dispositivo GNSS exte rno. La sección 9.1.3 los denota 
MSCA_VU-EGF . 
—  El certificado VU.CA .EUR mencionado en la figur a 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á 
present e. Tal como se especific a en la sección 9.1.2, este es el certificad o de enlace para un 
nuev o par de claves raíz europeo creado por la ERCA y firmado por la clave privada europea 
anterior. 
—  El certificado VU.Link.E UR 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. 
CSM_210  Una vez verificado el certificado VU_MA, la unidad GNSS extern a almacenará el certificado para 
utilizarlo durante el funcionamiento normal. Véase la sección 11.3.3. 
11.3.3  Durante el funcionamiento normal 
CSM_211  Durant e el funcionamient o normal, una unidad instalada en el vehículo y una EGF utilizarán el 
protocolo ilustrado en la Figure 11 para verificar la validez temporal de los certificad os EGF_MA y 
VU_MA almacenados y para configurar la clave pública VU_MA para la poste rior autenticación de 
la VU. Durante el funcionamient o normal no se efectuará ninguna nueva verificación mutua de las 
cadenas de certificados. 26.5.2016 L 139/394 Diar io Oficial de la Unión Europea ES    
Obsér vese que la Figure 11 consiste en esencia de los primeros paso mostrados en la Figure 4 y en 
la Figure 5. Asimismo, obsér vese que puest o que una EGF no es una tarjeta intelig ente, la VU 
probablement e 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. 
Figura 11 
Verificación mutua de la validez temporal del certificado durante el funcionamient o nor mal 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 subsiguient e a través de la mensajería segura procederán normalmente . 
11.4.  Autenticación de la VU, autenticación del chip y acuerdo de clav es de sesión 
CSM_213  La autenti cació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 durant e el acoplamiento y siempre que se restablezca una sesión de 
mensaj ería segura durante el funcionamient o normal. La VU y la EGF efectuarán los procesos 
descr itos 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 extern o tras la autenticación correcta del chip y hasta el final de la sesión estarán 
prote gidos 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 mensaj ería segura entra una VU y una EGF se abor ta, la VU establecerá inmedia ­
tamente una nueva sesión de mensaj ería segura, tal como se descr ibe en las secciones 11.3.3 y 
11.4. 26.5.2016 L 139/395 Diar io Oficial de la Unión Europea ES    
12.  EMP AREJAMIENTO Y COMUNICA CIÓ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 movimient o se comunicarán mediante el 
protocolo de interfaz especifi cado en la norma [ISO 16844-3] durante el emparej amiento y el 
funcionamient o normal, con los cambios descr itos en el present e capítulo y en la sección 9.2.1. 
Nota: se supone que los lectores del presente capítulo están famili arizados con el contenido de la 
norma [ISO 16844-3]. 
12.2.  Emparejamient o de la VU con el sensor de movimiento mediante clav es de diferentes generaciones 
Como se explica en la sección 9.2.1, la clave maestra del sensor de movimient o y todas las claves asociadas 
son sustituidas regular mente. Esta circunstancia da lugar a la presencia de hasta tres claves AES KM-W C (de 
generaciones de claves consecutivas) relacionadas con los sensores de movimient o en las tarjetas de taller . 
Análoga mente, en los sensores de movimient o puede haber hasta tres cifrados de datos diferentes basados en 
algor itmos AES resultantes de generaciones consecutivas de la clave maestra KM del sensor de movimient o. 
Una unidad instalada en el vehículo contiene solamente una clave KM-VU relacionada con el sensor de 
movimiento. 
CSM_217  Una VU de segunda generación y un sensor de movimient o de segunda generación se emparejarán 
de la siguient e manera (compá rese la tabla 6 de la norma [ISO 16844-3]):  
1. Una tarjeta de taller de segunda generación se inser ta en la VU, y la VU se conecta al sensor de 
movimiento.  
2. La VU lee todas las claves KM-W C 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 
KM-V U de la VU. Si la clave KM-W C correspondiente no está presente en la tarjeta de taller , la VU 
abor ta el proceso de emparej amiento y muestra un mensaj e de error apropiado al titular de la 
tarjeta de taller .  
3. La VU calcula la clave maestra KM del sensor de movimient o a partir de KM-VU y KM-WC y la clave 
de identif icación KID a partir de KM, tal como se especifi ca en la sección 9.2.1.  
4. La VU envía la instr ucción para iniciar el proceso de emparejamiento al sensor de movimient o, 
tal como se descr ibe en la norma [ISO 16844-3], y cifra el número de serie que recibe del 
sensor de movimient o con la clave de identificación KID. La VU envía el número de serie cifrado 
al sensor de movimiento.  
5. El sensor de movimient o compar a el número de serie cifrado consecutivamente con cada 
cifrado del número de serie que contiene intername nte. Si encuentra una correspondencia, se 
autenti ca la VU. El sensor de movimient o anota la clave de generación KID utilizada por la VU y 
devuelve la versión cifrada correspondiente de su clave de emparejamient o; es decir , el cifrado 
creado mediante la misma generación de KM.  
6. La VU descifra la clave de emparejamient o mediante la clave KM, genera una clave de sesión KS, 
la cifra con la clave de emparejamiento y enví a el resultado al sensor de movimiento. El sensor 
de movimiento descifra la clave KS.  
7. La VU ensambla la información de emparejamient o tal como se define en la norma [ISO 
16844-3], cifra la información con la clave de emparejamiento, y envía el resultado al sensor de 
movimiento. El sensor de movimient o descifra la información de empa rejamiento.  
8. El sensor de movimient o cifra la información de emparejamiento recibida con la clave KS 
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 de movimiento en el paso anterior. Si lo es, esto 
prueba que el sensor de movimient o utilizó la misma clave KS que la VU y, por consiguiente, en 
el paso 5 envió su clave de emparejamient o cifrada con la clave KM de la generación correcta. 
Por tanto , el sensor de movimiento es autenticado. 
Obsér vese que los pasos 2 y 5 son diferent es del proceso normal definido en la norma ISO 16844- 
3]; los demás pasos son normales. 26.5.2016 L 139/396 Diar io Oficial de la Unión Europea ES    
Ejemplo: Supónga se que un emparej amiento se efectúa durant e 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óngas e que el sensor de movimiento fue expedido durante el último año de validez del 
certificado ERCA (1). Por consiguiente cont endrá las siguient es claves y datos: 
—  Ns[1]: su número de serie cifrado con la generación 1 de la clave KID 
—  Ns[2]: su número de serie cifrado con la generación 2 de la clave KID 
—  Ns[3]: su número de serie cifrado con la generación 3 de la clave KID 
—  KP[1]: su clave de emparejamiento de generación 1 (1), cifrada con la generación 1 de la 
clave KM 
—  KP[2]: su clave de emparejamient o de generación 2, cifrada con la generación 2 de la clave 
KM 
—  KP[3]: su clave de emparejamient o de generación 3, cifrada con la generación 3 de la clave 
KM 
—  Supóngas e que la tarjeta de taller fue expedida durant e 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 KM-W C. 
—  Supóngas e que la VU es una VU de generación 2 que contiene la generación 2 de la clave KM-V U. 
En este caso, en los pasos 2 a 5 ocur rirá lo siguient e: 
—  Paso 2: La VU lee la generación 2 y la generación 3 de la clave KM-W C en la tarjeta de taller e 
inspecciona sus números de versión. 
—  Paso 3: La VU combina la clave KM-W C de generación 2 con su clave KM-V U para computar las 
claves KM y KID. 
—  Paso 4: La VU cifra el número de serie que recibe del sensor de movimiento con la clave KID. 
—  Paso 5: El sensor de movimiento compara los datos recibidos con Ns[1] y no encuentra una 
correspondencia. Seguidamente, compara los datos con Ns[2] y encuentra una correspondencia. 
Concluy e que la VU es de generación 2, y por tanto devuelve la clave KP[2]. 
12.3.  Emparejamient o y comunicación entre una VU y un sensor de movimiento mediante el algor itmo AES 
CSM_218 Tal como se especifica en la Table 3 de la sección 9.2.1, todas las claves involucradas en el empa re­
jamiento de una unidad instalada en el vehículo (de segunda generación) y un sensor de 
movimiento y en la comunicación subsiguient e serán claves AES, en lugar de las claves TDES de 
doble longitud especificadas en la norma [ISO 16844-3]. Estas claves 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. Además. algunos de estos mensaj es se utilizarán para transpor tar claves AES cuya 
longitud puede ser de 128, 192 o 256 bits. Por consiguiente , el número de bytes de datos por 
instr ucción de la tabla 5 de la norma [ISO 16844-3] se modifi cará tal como ilustra la Table 6: 
Tabla 6 
Número de bytes de dato s de text o plano y cifrados por inst rucción definido en la nor ma in [ISO 16844-3] 
Instr uc­
ción Solicitud/ 
respuesta Descr ipción de los 
datos # de bytes de texto 
plano según la 
norma [ISO 
16844-3] # de bytes de datos 
de texto plano 
mediante claves 
AES # de bytes de datos cifrados 
mediante claves AES de longitud 
en bits de 
128 192 256 
10 solicitud Datos de autentica ­
ción + número de 
arch ivo 8 8 16 16 16 26.5.2016 L 139/397 Diar io Oficial de la Unión Europea ES    
(1)Obsér vese que las claves de emparejamient o 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 diferent es, tal como se explica en CSM_117. 
Instr uc­
ción Solicitud/ 
respuesta Descr ipción de los 
datos # de bytes de texto 
plano según la 
norma [ISO 
16844-3] # de bytes de datos 
de texto plano 
mediante claves 
AES # de bytes de datos cifrados 
mediante claves AES de longitud 
en bits de 
128 192 256 
11 respuesta Datos de autentica ­
ción + cont enido de 
arch ivo 16 o 32, según el 
arch ivo 16 o 32, según el 
arch ivo 16 / 32 16 / 32 16 / 32 
41 solicitud No de serie del sen­
sor 8 8 16 16 16 
41 respuesta Clave de empareja ­
mient o 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 em­
parejamiento 24 24 32 32 32 
50 respuesta Información de em­
parejamiento 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 
autenti cación 8 8 16 16 16  
CSM_219  La información de emparej amiento enviada en las instr ucciones 43 (solicitud de la VU) y 50 
(respuesta del sensor de movimient o) se ensamblará tal como se especifica en la sección 7.6.10 de 
la norma [ISO 16844-3], salvo que se usará el algor itmo AES en lugar del algor itmo TDES en el 
esquema criptográfico basado en el emparej amiento de datos, lo que resulta en dos cifrados AES, y 
se adopt ará el relleno especifi cado 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 emparej amiento KP sea de 16 bytes de longitud: K'p = KP XOR (Ns|| 
Ns) 
—  En el caso de que la clave de emparej amiento KP sea de 24 bytes de longitud: K'p = KP XOR (Ns|| 
Ns||Ns) 
—  En el caso de que la clave de emparej amiento KP sea de 32 bytes de longitud: K'p = KP XOR (Ns|| 
Ns||Ns||Ns) 
donde Ns 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 siempr e un 
múltiplo de 8, de tal modo que no se necesita relleno si se usa el algor itmo TDES. Esta parte del 
present e apéndice no modifi ca la definición de datos y mensaj es en la norma [ISO 16844-3], y por 
tanto exige la aplicación de relleno. 
CSM_221  Para la instr ucció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 vect or de inicialización que se deberá utilizar será 
el siguient e: 
—  Para la instr ucción 11: El bloque de aute nticació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 definido en la norma 
[ISO 9797-1]; véanse asimismo las secciones 7.6.5 y 7.6.6 de la norma [ISO 16844-3]. 26.5.2016 L 139/398 Diar io Oficial de la Unión Europea ES    
—  Para todas las demás instr ucciones en las que se transfieran más de 16 bytes, tal como se 
especifica en la Table 6: ‘00’{16}, es decir , dieciséis bytes de valor binar io 0. 
Nota: Tal como muestran las secciones 7.6.5 y 7.6.6 de la norma [ISO 16844-3]., cuando el sensor 
de movimient o cifra archiv os de datos para su inclusión en la instr ucción 11, el bloque de autenti ­
cación 
—  se usa como vector de inicialización para el cifrado en modo de encadenamient o de bloques de 
cifrado de los archivos de datos, y 
—  se cifra e incluy e como el primer bloque en los datos enviados a la VU. 
12.4.  Emparejamient o del sensor de movimiento para equipos de diferentes generaciones 
CSM_222  Como se explica en la sección 9.2.1, un sensor de movimient o de segunda generación puede 
conte ner el cifrado basado en el algor itmo TDES de los datos de emparejamiento (tal como se 
define en la parte A del present e apéndice), lo que permite emparejar el sensor de movimient o 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 descr ita en la parte A del present e 
apéndice y en la norma [ISO 16844-3]. Para el proceso de empa rejamiento 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 movimient o de 
primera generación. 
—  No es posible usar una tarjeta de taller de primera generación para emparej ar una VU de 
segunda generación con un sensor de movimient o. 
13.  SEGURID AD PARA LA COMUNICA CIÓN REMOT A MEDIANTE DSR C 
13.1.  Generalidades 
Tal como se especifica en el apéndice 14, una VU genera regular mente datos de monitor ización remota de 
tacógraf os (RTM) y los envía a la instalación (interna o externa) de comunicación remota (RCF). La instalación 
de comunicación remota es responsable de envi ar estos datos por la interfaz descr ita en el apéndice 14 al 
interrogador remot o. El apéndice 1 especifi ca que los datos RTM son la concat enación de: 
Carga útil cifrada del tacóg rafoel cifrado de la carg a útil de texto plano del tacógraf o 
Dat os de segur idad DSR Cdescr itos a continuación 
El formato de los datos de carg a útil de texto plano del tacógraf o se especifica en el apéndice 1 y se descr ibe 
en mayor profundidad en el apéndice 14. Esta sección descr ibe la estructura de los datos de segur idad DSR C; 
la especificación formal está en el apéndice 1. 
CSM_223  Los datos 
 de texto plano comunicados por una VU a una instalación de 
comunicación remota (si la ICF es externa) o de la VU a un interrogador remot o a través de la 
interfa z DSR C (si la RCF es interna) se proteg erán en modo cifrar y después aute nticar , es decir , 
primero se cifran los datos de carg a útil del tacógrafro para asegurar la confidencialidad del 
mensaj e, y después se calcula un código MAC para asegurar la autenti cidad e integridad de los 
datos. 
CSM_224  Los datos de segur idad DSR C estarán compuest os de la concatenació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 
) 
Conta dor  un contador de 3 bytes, véase CSM_225 26.5.2016 L 139/399 Diar io Oficial de la Unión Europea ES    
No de serie de la VU  el número de serie de la VU (tipo de dato 
) 
No de versión de la clave maestra DSR C  el número de versión de 1 byte de la clave maestra 
DSR C de la que se derivaron las claves DSR C 
específic as de la VU; véase la sección 9.2.2. 
MA C  el MAC calculado a través de todos los bytes 
anteriores en los datos RTM. 
CSM_225  El contador de 3 bytes en los datos de segur idad DSR C estará en el formato MSB-pr imero. La 
primera vez que una VU calcule un conjunto de datos RTM tras su puesta en funcionamient o, 
conf igurará el valor del contador en 0. Antes de calcular el siguiente conjunt o de datos RTM, la VU 
incrementará cada vez el valor de los datos del contador en 1. 
13.2.  Cifrado de la carga útil del tacóg rafo y generación del código MA C 
CSM_226  Dado un elemento de datos de texto plano con el tipo de dato 
 descr ito en 
el apéndice 14, una VU cifrará estos datos tal como muestra la Figure 12: la clave DSR C de la VU 
para el cifrado K_VUDSR C_ENC (véase la sección 9.2.2) se usará con el algor itmo AES en el modo de 
operación de encadenamient o de bloques de cifrado (CBC), tal como se define en la norma [ISO 
10116], con un parámetro interpolar m = 1. El vect or 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 especifi can 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 segur idad DSR C como se indica en la Figure 12: 
el MAC se calculará a través de todos los bytes anterior es en los datos RTM, hasta el número de 
versión de la clave maestra DSR C, este incluido, e incluyendo las etiquetas y longitudes de los 
objeto s de datos. La VU usará su clave DSR C para comprobar la autenticidad de K_VUDSR C_MA C 
(véase la sección 9.2.2) con el algor itmo AES en modo CMA C, tal como se especifica en la 
publicación especial [SP 800-38B]. La longitud del código MAC estará relacionada con la longitud 
de las claves DSR C específicas de la VU, tal como se especifica en CSM_50. 
Figura 12 
Cifrado de la carga útil del tacóg rafo y generación del código MA C 
26.5.2016 L 139/400 Diar io Oficial de la Unión Europea ES    
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 totali dad de los datos 
RTM a una tarjeta de control en el campo datos de un comando PROCESS DSR C MESS AGE, tal 
como se descr ibe en el apéndice 2. Seguidamente :  
1. La tarjeta de control inspeccionará el número de versión de la clave maestra DSR C en los datos 
de segur idad DSR C. Si la tarjeta de control no conoce la clave maestra DSR C indicada, devol verá 
un error especificado en el apéndice 2 y abor tará el proceso.  
2. La tarjeta de control usará la clave maestra DSR C indicada en combinación con el número de 
serie de la VU en los datos de segur idad DSR C para derivar las claves DSR C K_VUDSR C_ENC y 
K_VUDSR C_MA C específi cas de la VU, tal como se especific a en CSM_124.  
3. La tarjeta de control usará la clave K_VUDSR C_MA C para verificar el código MAC en los datos de 
segur idad DSR C, tal como se especifica en CSM_227. Si el código MAC es incor recto, la tarjeta 
de control devol verá un error especificado en el apéndice 2 y abor tará el proceso.  
4. La tarjeta de control usará la clave K_VUDSR C_ENC para descifrar la carg a útil cifrada del 
tacógraf o, tal como se especifi ca en CSM_226. La tarjeta de control eliminará el relleno y 
devol verá los datos de la carg a útil descifrada al interr ogad or remoto. 
CSM_229  A fin de impedir los ataques por repetición, el interrogador remoto verificará la actualidad de los 
datos RTM comprobando que la current date time de los datos de segur idad DSR C no se desvíe 
demasiado de la hora actual del interro gador remot o. 
Notas: 
—  Esto exige que el interrogador remoto tenga una fuente exacta y fiable de la hora. 
—  Puest o 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 interr ogador remot o. 
CSM_230  Cuando un taller verifique el funcionamiento correcto de la funcionalidad DSR C de una VU, 
enviará la totali dad de los datos RTM recibidos de la VU a una tarjeta de taller en el camp o datos 
de un comando PROCESS DSR C MESS AGE, tal como se descr ibe en el apéndice 2. La tarjeta de 
taller efectuará todas las comprobaciones y acciones especificadas en CSM_228. 
14.  FIRMA DE DESCAR GAS DE DATOS Y VERIFICA CIÓN DE FIRMAS 
14.1.  Generalidades 
CSM_231  El equipo dedicado intelig ente (IDE) almacenará en un archiv o físico los datos recibidos de una VU 
o de una tarjeta durant e una sesión de descarga. Los datos se pueden almacenar en un ESM (medio 
de almacenamiento externo) . El archiv o contiene firmas digitales de bloques de datos, tal y como se 
especifica en el apéndice 7, apar tado Protocol os de transferencia de datos. Este archiv o cont endrá 
además los certificados siguientes (remítase a la sección 9.1). 
—  En el caso de una descarg a 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. 26.5.2016 L 139/401 Diar io Oficial de la Unión Europea ES    
—  En el caso de una descarg a 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 directament e 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 certificados no se especifica en el present e 
apéndice. 
14.2.  Generación de firmas 
CSM_233  El algor itmo de firma para crear firmas digitales en datos descarg ados será el algor itmo ECDSA, tal 
como se especifica en la norma [DSS], utilizando el algor itmo 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 directr iz técnica [TR-03111]. 
14.3.  Verificación de firmas 
CSM_234  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. 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 archiv o de datos y verificará asimismo la firma en los 
datos de acuerdo con el esquema de firma definido en la norma [DSS]. 
Notas de la Figure 13: 
—  El equipo que firmó los datos que han de analizarse se denota EQT . 
—  Los certificado s EQT y las claves públicas mencionados en la figura son los emp leados para la 
firma, es decir , VU_Sign o Card_Sign. 
—  Los certificad os EQT .CA y las claves públicas mencionados en la figura son los empleado s para 
firmar los certificado s 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á 
present e. Tal como se especific a en la sección 9.1.2, este es el certificad o de enlace para un 
nuev o par de claves raíz europeo creado por la ERCA y firmado con la clave privada europea 
anterior. 
—  El certificado EQT .Link .EUR es el certificado raíz europeo 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 algor itmo 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 especifi ca 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 present e documento no especifica ninguna acción que se deba empr ender si la firma en un 
archiv o de datos descarg ado no se puede verificar o si la verificación no se efectúa correctamente. 26.5.2016 L 139/402 Diar io Oficial de la Unión Europea ES    
Figura 13 
Proto colo para la verificación de la firma en un archiv o de datos descargado. 
26.5.2016 L 139/403 Diar io Oficial de la Unión Europea ES    
Apéndice 12 
POSICIONAMIENTO BASADO EN EL SISTEMA MUNDIAL DE NAVEGA CIÓN POR SATÉLITE (GNSS) 
ÍNDICE 
1. INTR ODUCCIÓN ................................................................................................................................ 405 
1.1. Ámbito de aplicación .............................................................................................................. 405 
1.2. Acrónimos y notaciones .......................................................................................................... 405 
2. REQUISITOS DEL RECEPTOR GNSS ........................................................................................................ 406 
3. SECUENCIAS DE LA NMEA .................................................................................................................. 406 
4. UNID AD INST ALADA EN EL VEHÍCUL O CON DISPOSITIV O GNSS EXTERNO ................................................... 408 
4.1. Confi guración ....................................................................................................................... 408 
4.1.1 Principales component es e interfaces .......................................................................................... 408 
4.1.2 Estado del dispositivo GNSS exte rno al final de la producción .......................................................... 408 
4.2. Comunicación entre el dispositivo GNSS extern o y la unidad instalada en el vehículo ............................ 409 
4.2.1 Protocolo de comunicación ...................................................................................................... 409 
4.2.2 Transf erencia segura de datos GNSS ........................................................................................... 411 
4.2.3 Estr uctura del comando de lectura del registro .............................................................................. 412 
4.3. Acoplamiento, aute nticación mutua y acuerdo de la clave de la sesión entre el dispositivo GNSS exte rno y 
la unidad instalada en el vehículo ............................................................................................... 413 
4.4. Gestión de errores .................................................................................................................. 413 
4.4.1 Error de comunicación con el dispositivo GNSS exte rno................................................................. 413 
4.4.2 Manipulación de la integrid ad física del dispositivo GNSS externo ..................................................... 413 
4.4.3 Ausencia de información de posición del recep tor GNSS ................................................................. 413 
4.4.4 Certificado del dispositivo GNSS externo expirado ......................................................................... 414 
5. UNID AD INST ALADA EN EL VEHÍCUL O SIN DISPOSITIV O GNSS EXTERNO .................................................... 414 
5.1. Confi guración ....................................................................................................................... 414 
5.2. Gestión de errores .................................................................................................................. 414 
5.2.1 Ausencia de información de posición del recep tor GNSS ................................................................. 414 
6. ERR OR DE SINCR ONIZA CIÓN DEL GNSS ................................................................................................ 414 
7. CONFLICTO DE MOVIMIENTO DEL VEHÍCULO ......................................................................................... 415  26.5.2016 L 139/404 Diar io Oficial de la Unión Europea ES    
1.  INTR ODUCCIÓN 
El presente apéndice recoge los requisitos técn icos para los datos del GNSS emplea dos por la unidad instalada en 
el vehículo, incluidos los protocolo s que deben aplicarse para garantizar una transfe rencia de datos segura y 
correcta de la información sobre el posicionamient o. 
Los principales artículos del Reglamento (UE) no 165/2014 que regulan estos requisitos son: el artículo 8 
(Registro de la posición del vehículo en determinados puntos durante el período de trabajo diar io), el artículo 10 
(Interfaz con sistemas de transpor te inteli gent es) y el artículo 11 (Disposiciones específi cas sobre los tacógraf os 
intelig entes). 
1.1.  Ámbito de aplicación 
GNS_1  La unidad instalada en el vehículo recabará datos de posición de al menos un GNSS para respaldar la 
aplicación del artículo 8. 
La unidad instalada en el vehículo podrá incluir o no un dispositivo GNSS exte rno, tal y como se indica en el 
Gráfi co 1: 
Gráfico 1 
Diferentes conf iguraciones del recept or GNSS. 
1.2.  Acrónimo s y notaciones 
En el present e apéndice se utilizan los siguient es acrónimos: 
DOP  dilución de precisión 
EGF  archiv o elemental del dispositivo GNSS 26.5.2016 L 139/405 Diar io Oficial de la Unión Europea ES    
EGNOS  Sistema Europeo de Naveg ación por Com plemento Geoestacionar io 
GNSS  sistema mundial de naveg ación por satélit e 
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 Mar ine Electronics Association 
PDOP  dilución de precisión de la posición 
RMC  específi co mínimo recomendado 
SIS  señal en el espacio 
VDOP  dilución de precisión vertical 
VU  unidad instalada en el vehículo 
2.  REQUISITOS DEL RECEPTOR GNSS 
Independientement e de la conf iguración del tacógraf o intelig ente, que puede incluir o no un dispositivo GNSS 
externo , la facilitación de información de posición precisa y fiable es un element o esencial para el funcionamient o 
efectivo del tacógraf o inteligent e. Por consiguiente , conviene exigir su compati bilidad con los servicios prestados 
por los programas Galileo y Sistema Europeo de Naveg ación por Complement o Geoestacionar io (EGNOS), con 
arreglo a lo establecido en el Reglamento (UE) no 1285/2013 del Parlamento Europeo y del Consejo (1). El sistema 
establecido en el marco del programa Galileo es un sistem a mundial independiente de radionaveg ación por 
satélit e, y el establecido en el marco del programa EGNOS es un sistem a regional de navegación por satélit e que 
mejora la calidad de la señal del Sistema de Posicionamiento Global (GPS). 
GNS_2  Los fabricantes se asegurarán de que los recep tores GNSS integra dos en los tacógraf os inteligent es sean 
compati bles con los servicios de localización prestados por los sistemas Galileo y EGNOS. Además, los 
fabricant es podrán optar por la compatibilidad con otros sistemas de navegación por satélite. 
GNS_3  El recep tor GNSS deberá poder admitir la autenticación en la interfaz abier ta de Galileo cuando el sistema 
Galileo facilite dicha interfaz , y cuando la admitan los fabricantes del recep tor GNSS. 
3.  SECUENCIAS DE LA NMEA 
En la present e sección se descr iben las secuencias NMEA utilizadas para el funcionamient o del tacógraf o 
intelig ente. Esta sección es aplicable tanto a la configuración de tacógraf o intelig ente con dispositivo GNSS 
externo como sin él. 
GNS_4  Los datos de localización se basan en los datos específicos mínimos recomendados (RMC) del GNSS 
recogidos en la secuencia NMEA, que incluyen la información sobre la posición (latitud y longitud), el 
tiempo en format o UTC (hhmmss.ss) y la velocidad sobre el fondo en nudos, además de valores 
adicionales. 
El formato de la secuencia RMC es el siguient e (según la norma NMEA V4.1): 26.5.2016 L 139/406 Diar io Oficial de la Unión Europea ES    
(1)Reglamento (UE) no 1285/2013 del Parlament o Europeo y del Consejo, de 11 de diciembre de 2013, relativo al establecimient o y la 
explotación de los sistemas europeos de radionaveg ación por satélit e y por el que se derogan el Reglamento (CE) no 876/2002 del 
Consejo y el Reglament o (CE) no 683/2008 del Parlamento Europeo y del Consejo (DO L 347 de 20.12.2013, p. 1). 
Gráfico 2 
Estr uctura de la secuencia RMC 
El estado indica si se dispone de señal GNSS. Los datos recibidos (por ejemplo, tiempo o latitud/longitud) 
únicamente podrán utilizarse para registrar la posición del vehículo de la unidad instalada en el vehículo cuando 
el estado tenga «A» como valor . 
La resolución de la posición se basa en el format o de la secuencia RMC anter iormente descr ita. La primera parte 
de los campos 3 y 5 (los dos primeros números) 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_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 descr ibe 
en el apéndice 1 para las geocoordenadas. 
La VU puede utilizar el comando DOP del GPS y satélit es activos (GSA) para definir y registrar la disponi ­
bilidad y la precisión de la señal. En concreto, la HDOP se emplea para facilitar una indicación del nivel 
de precisión de los datos de localización registrados (véase el apar tado 4.2.2). La VU almacenará el valor 
de la HDOP calculado como el mínimo de los valores HDOP recogidos en los sistemas GNSS disponibles. 
El identif icador de sistema GNSS indica si se trata de GPS, Glonass, Galileo, Beidou o sistema de 
aumentación basado en satélites (SBAS). 
Gráfico 3 
Estructura de la secuencia GSA 
26.5.2016 L 139/407 Diar io Oficial de la Unión Europea ES    
El modo (2) indica si no se dispone de posición (modo=1), si se dispone de una posición 2D (modo=2) o si se 
dispone de una posición 3D (modo=3). 
GNS_6  La secuencia GSA se almacenará con el número de registro «06». 
GNS_7  El tamaño máximo de las secuencias NMEA (por ejem plo, RMC, GSA u otras) empleadas para medir el 
comando de lectura del registro será de 85 bytes (véase la Tabla 1). 
4.  UNID AD INST ALADA EN EL VEHÍCULO CON DISPOSITIV O GNSS EXTERNO 
4.1.  Conf iguración 
4.1.1  Principales componentes e interf aces 
En esta conf iguración, el recep tor GNSS forma parte de un dispositivo GNSS exte rno. 
GNS_8  Dicho dispositivo debe disponer de una interfa z vehicular específica. 
GNS_9  El dispositivo GNSS externo estará formado por los siguientes component es (véase el Gráfico 4): 
a)  Un recept or GNSS comercial que facilit e los datos de posición a través de la interf az de datos GNSS. 
Por ejemplo, la interfaz de datos GNSS puede corresponder a la norma NMEA V4.10, de modo que 
el recep tor GNSS actúe como emisor y transmita secuencias NMEA al transcept or seguro GNSS con 
una frecuencia de 1 Hz para el conjunto predef inido de secuencias NMEA, que debe incluir al menos 
las secuencias RMC y GSA. Serán los fabricante s del dispositivo GNSS externo quienes decidan 
aplicar la interfa z de datos GNSS. 
b)  Una unidad transmisora recep tora (transcept or seguro GNSS) con capacidad para respetar la norma 
ISO/IEC 7816-4:2013 (véase el apar tado 4.2.1), comunicarse con la unidad instalada en el vehículo y 
admitir la interf az de transferencia de datos GNSS al recep tor GNSS. La unidad dispone de una 
memor ia para almacenar los datos identificativos del recep tor GNSS y del dispositivo GNSS externo. 
c)  Un sistem a de cierre con un detect or de manipulaciones que incluya tanto el recept or GNSS como el 
transcept or seguro GNSS. El detector de manipulaciones deberá aplicar las medidas de prote cción de 
la segur idad solicitadas en el perf il de protección del tacógraf o intelig ente. 
d)  Una antena GNSS instalada en el vehículo y conectada al recept or GNSS mediante el sistema de 
cierre. 
GNS_10  El dispositivo GNSS externo tiene al menos las siguient es interfaces extern as: 
a)  la interfaz de la antena GNSS instalada en el malete ro del vehículo, en caso de que se utilice una 
antena externa; y 
b)  la interfaz de la unidad instalada en el vehículo. 
GNS_11  En la unidad instalada en el vehículo, el transcept or seguro de la VU es el otro fin de la comunicación 
segura con el transcept or seguro del GNSS, y debe respetar la norma ISO/IEC 7816-4:2013 para la 
conexión con el dispositivo GNSS exte rno. 
GNS_12  Para el nivel físico de la comunicación con el dispositivo GNSS extern o, la unidad instalada en el 
vehículo respetará la norma ISO/IEC 7816-12:2005 y otras normas que respeten la ISO/IEC 7816- 
4:2013. (véase el apar tado 4.2.1). 
4.1.2  Estado del dispositivo GNSS exter no al final de la producc ión 
GNS_13  El dispositivo GNSS externo deberá almacenar los siguiente s valores en la memor ia permanent e del 
transcept or seguro del GNSS cuando salga de la fábr ica: 
—  la pareja de claves EGF_MA y el certificado correspondiente; 
—  el certificado MSCA _VU-EGF que conteng a la clave pública MSCA_ VU-EGF .PK que se utilizará para 
verificar el certificad o EGF_MA; 26.5.2016 L 139/408 Diar io Oficial de la Unión Europea ES    
—  el certificado EUR que conteng a la clave pública EUR.PK que se utilizará para verificar el certificado 
MSCA_ VU-EGF; 
—  el certificado EUR cuyo período de validez finalice exactament e antes del período de validez del 
certificado EUR empleado para verificar el certificado 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 extern o; 
—  el identificador del sistema operativo del dispositivo GNSS; 
—  el número de homologación del dispositivo GNSS externo; y 
—  el identificador del component e de segur idad del módulo GNSS extern o. 
4.2.  Comunicación entre el dispositiv o GNSS exter no y la unidad inst alada en el vehículo 
4.2.1  Protocolo de comunicación 
GNS_14  El protocolo de comunicación entre el dispositivo GNSS exte rno y la unidad instalada en el vehículo 
deberá admitir tres funciones:  
1. recogida y distr ibución de datos GNSS (por ejemplo, posición, tiempo, velocidad);  
2. recogida de los datos de conf iguración del dispositivo GNSS exte rno; y  
3. protocolo de administración para admitir el acoplamient o, la autenticación mutua y el acuerdo de la 
clave de la sesión entre el dispositivo GNSS extern o y la VU. 
GNS_15  El prot ocolo de comunicación se basará en la norma ISO/IEC 7816-4:2013, de modo que el transcept or 
seguro de la VU actuará como maestro y el transcep tor seguro GNSS como esclav o. 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 respete n la norma ISO/IEC 7816-4:2013. 
GNS_16  En el protocolo de comunicación no se admitirán campos de longitud ampliada. 
GNS_17  El prot ocolo de comunicación de la norma ISO 7816 (tant o *-4:2013 como *-12:2005) entre el 
dispositivo GNSS extern o y la VU se conf igurará en T=1. 
GNS_18  Para las funciones 1 (recogida y distr ibución de datos GNSS), 2 (recogida de los datos de configuración 
del dispositivo GNSS exte rno) y 3 (protocol o de administración), el transcep tor seguro GNSS simulará 
una tarjeta intelig ente con una arquit ectura de arch ivos del sistem a formada por: un archivo principal 
(MF); un archivo de directori o (DF) con el identif icador de aplicación especificado en el apéndice 1, 
apar tado 6.2 («FF 44 54 45 47 4D») y con tres EF que conteng an certificados; y un archivo elemental 
único (EF.EGF) con el identif icador igual a «2F2F», tal y como se descr ibe en Tabla 1. 
GNS_19  El transcept or seguro GNSS almacenará los datos procedent es del recep tor GNSS y la configuración en 
el EF.EGF . Se trata de un arch ivo de registro lineal y de longitud variable cuyo identificador es «2F2F» en 
formato hexadecimal. 
GNS_20  El transcep tor seguro GNSS utilizará una memor ia para almacenar los datos que pueda realizar al 
menos 20 millones de ciclos de escr itura/lectura. A excepci ón de este elemento, el diseño interno y la 
aplicación del transcept or seguro GNSS queda en manos de los fabricantes. 
El mapeado de los números de registro y de los datos se detalla en la Tabla 1. Cabe señalarse que hay 
cuatro secuencias GSA para los cuatro sistemas satélit e y el sistem a de aumentación basado en satélit es 
(SBAS). 
GNS_21  La Tabla 1 recoge la estructura de los archiv os. Para las condiciones de acceso (ALW, NEV , SM-MA C), 
véase el apéndice 2, apar tado 3.5. 26.5.2016 L 139/409 Diar io Oficial de la Unión Europea ES    
Tabla 1 
Estr uctura de los archiv os   
Condiciones de acceso 
Archi vo Identificador 
del archiv o Lectura Actualización Cifrado 
MF 3F00    
EF.ICC 0002 ALW NEV 
(por parte de 
la VU) No 
DF GNSS Facili ty 0501 ALW NEV No 
EF EGF_MA Certificate C100 ALW NEV No 
EF CA_Cer tificate C108 ALW NEV No 
EF Link_Cer tificate C109 ALW NEV No 
EF.EGF 2F2F SM-MA C NEV 
(por parte de 
la VU) No  
Archiv o/element o de dato No de registro Tamaño (bytes) Valores por 
defect o   
Mín. Máx.  
MF  552 1 031  
EF.ICC     
sensorGNSSSer ialNumber  8 8       
DF GNSS Faci lity  612 1 023  
EF EGF_MA Certificate  204 341  
EGFCer tificate  204 341 {00..00} 
EF CA_Cer tificate  204 341  
MemberStateCer tificate  204 341 {00..00} 
EF Link_Cer tificate  204 341  
LinkCer tificate  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  26.5.2016 L 139/410 Diar io Oficial de la Unión Europea ES    
Archiv o/element o de dato No de registro Tamaño (bytes) Valores por 
defect o   
Mín. Máx.  
Tercera secuencia GSA NMEA 04 85 85  
Cuar ta secuencia GSA NMEA 05 85 85  
Quinta secuencia GSA NMEA 06 85 85  
Número de serie ampliado del dispositivo 
GNSS externo definido en el apéndice 1 
como sensorSer ialNumber . 07 8 8  
Identif icador del sistema operativo del 
transcept or seguro GNSS definido en el 
apéndice 1 como SensorOSIdentifier . 08 2 2  
Número de homolog ación del dispositivo 
GNSS externo definido en el apéndice 1 
como SensorExter nalGNSS Appro valNum ­
ber. 09 16 16  
Identif icador del compo nente de segur idad 
del dispositivo GNSS externo definido en el 
apéndice 1 como SensorExte rnalGNSSSCI ­
dentifi er. 10 8 8  
RFU: reser vado para uso futuro. De 11 a FD     
4.2.2  Transferencia segur a de datos GNSS 
GNS_22  Únicament e se permitirá la transfer encia segura de datos de posición GNSS en las siguient es 
condiciones:  
1. si se ha llevado a cabo el proceso de acoplamiento tal y como se descr ibe en el apéndice 11 
(Mecanismos de segur idad comunes); y  
2. si se han realizado con la frecuencia prevista la autenticación mutua periódica y el acuerdo de la 
clave de la sesión entre la VU y el dispositivo GNSS externo también descr itos en el apéndice 11 
(Mecanismos de segur idad comunes). 
GNS_23  Cada T segundos (siendo T un valor igual o inferior a 10, a menos que se esté realizando el 
acoplamiento, la autenti cación mutua o el acuerdo de la clave de la sesión), la VU solicita al dispositivo 
GNSS externo información de posición mediante el siguiente proceso:  
1. La VU solicita al dispositivo GNSS externo datos de localización y datos sobre la dilución de 
precisión (de la secuencia GSA NMEA). El transcept or seguro de la VU utilizará el comando de 
selección y lectura de registros de la ISO/IEC 7816-4:2013 en el modo de solo autenticación de 
mensaj ería segura, según lo previsto en el apéndice 11, apar tado 11.5, con el identificador de 
archiv o «2F2F» y el número de registro «01» para la secuencia RMC NMEA y «02», 
«03» ,«04»,«05»,«06» para la secuencia GSA NMEA.  
2. Los últimos datos de localización recibidos se almacenan en el EF con el identif icador «2F2F», y los 
registros descr itos en la Tabla 1 en el transcep tor seguro GNSS, puesto que el transcep tor seguro 
GNSS recibe del recept or GNSS datos NMEA con una frecuencia de al menos 1 Hz a través de la 
interfaz de datos GNSS.  
3. El transcept or seguro GNSS enví a la respuesta al transcep tor seguro de la VU utilizando un mensaj e 
de respuesta APDU en el modo de solo aute nticación de mensaj ería segura, según lo previsto en el 
apéndice 11, apar tado 11.5. 26.5.2016 L 139/411 Diar io Oficial de la Unión Europea ES    
4. El transcept or seguro de la VU compr ueba la autenti cidad y la integridad de la respuesta recibida. En 
caso de que el resultado sea positiv o, se transfieren los datos de localización al procesador de la VU a 
través de la interfaz de datos GNSS.  
5. El procesador de la VU verifica los datos recibidos (por ejemplo, latitud, longitud o tiempo) al extraer 
la información de la secuencia RMC NMEA. La secuencia RMC NMEA incluy e la información si la 
posición es válida. Si la posición no es válida, aún no dispone de datos de localización y no pueden 
emplearse para registrar la posición del vehículo. Si la posición es válida, el procesador de la VU 
también extrae los valores de HDOP de las secuencias GSA NMEA y calcula el valor medio en los 
sistemas de satélite disponibles (es decir , cuando se disponga de una posición).  
6. El procesador de la VU almacena en la VU la información recibida y procesada, como la latitud, la 
longitud, el tiempo y la velocidad, en el formato definido en el diccionar io de datos del apéndice 1 
como «geoco ordenadas», junto con el valor de HDOP calculado como el mínimo de los valores 
HDOP recogidos en los siste mas GNSS disponibles. 
4.2.3  Estructur a del comando de lectur a del registro 
En la present e sección se detalla la estructura del comando de lectura del registro (Read Record). Se incluye la 
mensaj ería segura (modo de solo autenticación) descr ita en el apéndice 11 (Mecanismos de segur idad comunes). 
GNS_24  El comando admitirá el modo de solo aute nticación de mensaj ería segura, véase el apéndice 11. 
GNS_25  Mensaje de comando 
Byte Longitud Valor Descr ipción 
CLA 1 0Ch Se pide mensa jerí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 referen cia P1 se convier te en el registro actual. 
Byte Longitud Valor Descr ipción 
No 1- no X X XX..XXh Datos leídos 
SW 2 XXXXh Palabras de estado (SW1,SW2)  
—  Si el comando se ejecuta correctamente, el transcep tor seguro GNSS contesta con el estado «9000». 
—  Si el arch ivo actual no está destinado al registro, el transcept or seguro GNSS contes ta con el estado 
«6981». 
—  Si se utiliza el comando con P1=00 pero no se dispone de EF, el transcep tor seguro GNSS conte sta 
con el estado «6986» (comando no permitido). 
—  Si no se localiza el registro, el transcep tor seguro GNSS contes ta con el estado «6A 83». 
—  Si el dispositivo GNSS exte rno detecta manipulación, conte stará con el estado «66 90». 26.5.2016 L 139/412 Diar io Oficial de la Unión Europea ES    
GNS_27  El transcept or seguro GNSS admitirá los siguientes comandos de tacógraf o de segunda generación 
especifi cados en el apéndice 2: 
Comando Referencia 
Select (seleccionar) Apéndice 2, apar tado 3.5.1 
Read Binar y (leer archivo binar io) Apéndice 2, apar tado 3.5.2 
Get Challenge (obt ener interr ogación) Apéndice 2, apar tado 3.5.4 
PSO: Verify Certificate (realizar operación de segu ­
ridad: verificar certificado) Apéndice 2, apar tado 3.5.7 
Extern al Authenticate (auten ticación externa) Apéndice 2, apar tado 3.5.9 
General Authenticat e (auten ticación general ) Apéndice 2, apar tado 3.5.10 
MSE:SET Apéndice 2, apar tado 3.5.11  
4.3.  Acoplamien to, autenticación mutua y acuerdo de la clav e de la sesión entre el dispositiv o GNSS exter no 
y la unidad inst alada en el vehículo 
El acoplamiento, la aute nticación mutua y el acuerdo de la clave de la sesión entre el dispositivo GNSS exte rno y 
la unidad instalada en el vehículo se descr iben en el apéndice 11 (Mecanismos de segur idad comunes), apar tado 
11. 
4.4.  Gest ión de errores 
En la present e 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 exter no 
GNS_28  Si la VU no consigue comunicarse con el dispositivo GNSS externo acoplado durant e más de 
20 minut os seguidos, la VU generará y registrará en la VU un incident e de tipo EventFaultT ype con el 
valor de la enumeración «53H Exte rnal GNSS communication fault» (error de comunicación con el 
dispositivo GNSS extern o) y con la hora en que se produzca como marca de tiempo. El incidente se 
generará excl usivamente si se cumplen las siguient es dos condiciones: a) el tacógraf o intelig ente no está 
en modo calibración y b) el vehículo está en movimient o. En este cont exto, se genera un error de 
comunicación cuando el transcept or seguro de la VU no recibe ningún mensaj e de respuesta tras un 
mensaje de petición envi ado según se descr ibe en el apar tado 4.2. 
4.4.2  Manipulación de la integ ridad física del dispositiv o GNSS exter no 
GNS_29  Si se ha manipulado el dispositivo GNSS extern o, el transcept or seguro GNSS borrará toda su memor ia, 
incluido el mate rial criptográfico. Tal y como se descr ibe en GNS_25 y en GNS_26, la VU detectará la 
manipulación si se ha enviado un mensaj e de respuesta con el estado «6690». A continuación, la VU 
generará un incidente de tipo EventFaultT ype con la enumeración «55H Tampe r detection of GNSS» 
(detección de manipulación del GNSS). 
4.4.3  Ausencia de información de posición del receptor GNSS 
GNS_30  Si el transcept or seguro GNSS no recibe datos del recep tor GNSS durant e más de tres horas seguidas, el 
transcept or seguro GNSS generará un mensa je de respuesta con el comando READ REC ORD (leer 
registro) con el número de registro «01» y con un campo de datos de 12 bytes, todos ellos fijados en 
0xFF . Una vez recibido el mensaj e de respuesta con este valor del campo de datos, la VU solamente 
generará y registrará un incidente de tipo EventFa ultT ype con la enumeración «52H exte rnal GNSS 
receiver fault» (fallo del recept or GNSS exte rno) y con la hora en que se produzca como marca de 
tiempo si se cumplen las siguientes dos condiciones: a) el tacógraf o intelig ente no está en modo 
calibración y b) el vehículo está en movimient o. 26.5.2016 L 139/413 Diar io Oficial de la Unión Europea ES    
4.4.4  Certificado del dispositivo GNSS exter no expir ado 
GNS_31  Si la VU detecta que el certificado EGF empleado para las autenti caciones mutuas ya no es válido, 
generará y registrará un fallo del aparat o de control de tipo EventF aultT ype con la enumeración «56H 
Extern al GNSS facility certificate expired» (certificado del dispositivo GNSS externo expirado) con la 
hora en que se produzca como marca de tiempo. La VU seguirá utilizando los datos GNSS de posición 
recibidos. 
Gráfico 4 
Esquema del dispositiv o GNSS exter no 
5.  UNID AD INST ALADA EN EL VEHÍCULO SIN DISPOSITIV O GNSS EXTERNO 
5.1.  Conf iguración 
En esta configuración, el recept or GNSS se encuentra dentro de la unidad instalada en el vehículo, tal y como se 
refleja en el Gráfi co 1. 
GNS_32  El recep tor GNSS actuará como emisor y transmitirá secuencias NMEA al procesador de la VU, que 
actuará como recep tor con una frecuencia de 1/10 Hz o super ior para el conjunt o predet erminado de 
secuencias NMEA, que incluirá como mínimo las secuencias RMC y GSA. 
GNS_33  Se conectará a la VU una antena GNSS externa instalada en el vehículo o una antena GNSS interna. 
5.2.  Gest ión de errores 
5.2.1  Ausencia de información de posición del receptor GNSS 
GNS_34  Si la VU no recibe datos del recep tor GNSS durante más de tres horas seguidas, solamente generará y 
registrará un incident e de tipo EventF aultT ype con la enumeración «51H Internal GNSS receiver fault» 
(fallo del recep tor GNSS intern o) y con la hora en que se produzca como marca de tiempo si se 
cumplen las siguient es dos condiciones: a) el tacógraf o intelig ente no está en modo calibración y b) el 
vehículo está en movimiento. 
6.  ERR OR DE SINCR ONIZA CIÓN DEL GNSS 
Si la VU detecta una discrepancia de más de un minuto entre el tiempo de la función de medición del tiempo de 
la unidad instalada en el vehículo y el tiempo procedente del recep tor GNSS, generará y registrará un incident e de 
tipo EventFaultT ype con la enumeración «0BH Time conf lict (GNSS versus VU intern al clock)» (discrepancia 
temporal entre el GNSS y el reloj interno de la VU). Se registra el incidente junto con el valor del reloj interno de 
la unidad instalada en el vehículo y se realiza un ajust e autom ático de la hora. Cuando se produzca una 
discrepancia temporal, la VU no comprobar á el desajust e hasta pasadas doce horas. Este incident e no se producirá 
en casos en los que el recep tor GNSS no haya detectado una señal GNSS válida en los últimos treinta días. No 
obstante, cuando se vuelva a disponer de información de posición del recept or GNSS, se realizará el ajuste 
automático de la hora. 26.5.2016 L 139/414 Diar io Oficial de la Unión Europea ES    
7.  CONFLICTO DE MOVIMIENTO DEL VEHÍCULO 
GNS_35  La VU producirá y registrará un conf licto de movimient o del vehículo (véase el requisito 84 del anex o), 
con la hora en que se produzca como marca de tiempo, cuando la información de movimiento 
calculada por el sensor de movimient o no sea acorde a la información de movimiento calculada por el 
recept or interno de GNSS o por el dispositivo GNSS externo. Para detectar estas contradicciones se 
utilizará el valor mediano de las diferencias de velocidad entre estas fuentes, como se indica a 
continuación: 
—  cada diez segundos como máximo, se calculará el valor absoluto de la diferencia entre la velocidad 
del vehículo estimada por el GNSS y la estimada por el sensor de movimient o; 
—  para calcular el valor mediano se utilizarán todos los valores computad os en un inter valo de tiempo 
que incluya los últimos cinco minutos de movimiento; y 
—  el valor mediano será la media del 80 % de los valores restant es, después de haberse eliminado los 
valores absolut os más elevados. 
El incident e de conf licto de movimient o del vehículo se producirá si el valor mediano es super ior a 
10 km/hora durante cinco minutos seguidos en los que el vehículo esté en movimient o. De manera 
opcional, podrán emplearse otras fuent es independient es de detección de movimient o del vehículo para 
facilitar una detección más fiable de manipulaciones del tacógraf o. (Nota: con el empleo de la mediana 
de los últimos cinco minutos se pretende mitig ar el riesgo de obtener mediciones discrepantes y valores 
transitor ios). Este incident e no se producirá en los siguientes casos: a) durante trayectos en ferri o en 
tren, b) cuando no se disponga de información de posición del recept or GNSS y c) en modo de 
calibrado.  26.5.2016 L 139/415 Diar io Oficial de la Unión Europea ES    
Apéndice 13 
INTERF AZ ITS 
ÍNDICE 
1. INTR ODUCCIÓN ................................................................................................................................ 416 
2. ÁMBITO DE APLICA CIÓN .................................................................................................................... 416 
2.1. Siglas, definicione s y notaciones ................................................................................................ 417 
3. REGL AMENTOS Y NORMAS DE REFERENCIA ........................................................................................... 418 
4. PRINCIPIOS DE FUNCIONAMIENTO DE LA INTERF AZ ................................................................................ 418 
4.1. Condiciones previas para la transferencia de datos a través de la interfaz ITS ....................................... 418 
4.1.1 Datos facilitados a través de la interfaz ITS ................................................................................... 418 
4.1.2 Contenido de los datos............................................................................................................ 418 
4.1.3 Aplicaciones ITS .................................................................................................................... 418 
4.2. Tecnología de la comunicación .................................................................................................. 419 
4.3. Autorización mediante PIN ....................................................................................................... 419 
4.4. Format o de los mensajes .......................................................................................................... 421 
4.5. Consentimiento del conductor ................................................................................................... 425 
4.6. Recuperación de datos estándar ................................................................................................. 426 
4.7. Recuperación de datos personales .............................................................................................. 426 
4.8. Recuperación de datos de incident es y fallos ................................................................................. 426  
1.  INTR ODUCCIÓN 
El presente apéndice especifica el diseño y los procedimiento s a seguir para implementar la inferfaz con los 
sistemas de transpor te inteligent es (ITS) de conf ormidad con lo dispuesto en el artículo 19 del Reglamento (UE) no 
165/2014 (el Reglamento). 
El Reglamento especifica que los tacógraf os de los vehículos podrán ir equipados de interfaces normalizadas que 
permitan que los datos registrados o producidos por el tacógraf o se utilicen en modo operativo gracias a un 
dispositivo externo, siempr e que se cumplan las siguientes condiciones: 
a)  la interfaz no afect e a la autenticidad ni a la integridad de los datos del tacógraf o; 
b)  la interfaz cumpla las disposiciones específic as del artículo 11; 
c)  el dispositivo exte rno conectado con la interfaz tenga acceso a los datos personales, incluso a los datos de 
geoposicionamiento, únicamente tras el consentimient o verificable del conduct or al que se refie ran los datos. 
2.  ÁMBITO DE APLICA CIÓN 
El ámbito del present e apéndice es especificar la forma en que las aplicaciones alojadas en dispositivo s externos 
pueden obtener datos (los datos) de un tacógraf o a través de una conexión Bluetooth ®. 
Los datos disponibles a través de esta interfaz están descr itos en el anex o 1 del presente documento. Esta interfaz 
no prohíbe la implementación de otras inferfaces (por ejemplo, a través del bus CAN) para transmitir los datos de 
la VU a otras unidades de procesamiento del vehículo. 26.5.2016 L 139/416 Diar io Oficial de la Unión Europea ES    
Este apéndice expecifi ca: 
—  Los datos disponibles a través de la interfaz ITS. 
—  El perfil Bluetooth® utilizado para transferi r los datos . 
—  Los procedimiento s de interrogación y descarga y la secuencia de operaciones. 
—  Los mecanismos de emparejamiento entre el tacógraf o y el dispositivo externo. 
—  El mecanismo de consentimient o disponible para el conductor . 
A efect os de aclaración, el present e anex o no especifica: 
—  La operación y gestión de la recogida de los datos en la VU (que se especificarán en otro punt o del Reglamento, 
o que de otra manera serán función del diseño del product o). 
—  La forma de presentación de los datos recogidos a la aplicación alojada en el dispositivo externo. 
—  Las disposiciones sobre segur idad de los datos más allá de la proporcionada por Bluetooth® (como el cifrado) 
en lo que se refie re al contenido de los datos [que se especificarán en otro punt o del Reglamento (apéndice 10, 
Mecanismos comunes de segur idad)]. 
—  Los procolos Bluetooth® usados por la interfaz ITS. 
2.1.  Siglas, definiciones y notaciones 
En este apéndice se utilizan las siguient es siglas y definiciones específicas: 
La comunicación  inter cambio de información/dato s entre una unidad maestra (es decir , los tacógraf os) y una 
unidad externa a través de la interf az ITS a través de Bluetooth®. 
Los datos  Los conjuntos de datos tal como se especifican en el anex o 1. 
El Reglamen to  Reglamento (UE) no 165/2014 del Parlament o Europeo y del Consejo, de 4 de febrero de 
2014, relativ o a los tacógraf os en el transpor te por carretera, por el que se deroga el 
Reglamento (CEE) no 3821/85 del Consejo relativ o al aparat o de control en el sector de los 
transpor tes por carretera y se modifi ca el Reglamento (CE) no 561/2006 del Parlamento 
Europeo y del Consejo relativ o a la armonización de determi nadas disposiciones en mater ia 
social en el sector de los transpor tes por carretera. 
BR  Basic Rate (Velocidad básica) 
EDR  Enhanced Data Rate (Velocidad de datos mejorada) 
GNSS  Global Nav igation Sate llite System (Sist ema mundial de naveg ación por satélite) 
IRK  Identity Resolution Key (Cla ve de resolución de identidad) 
ITS  Sistema de transpor te inteli gent e 
LE  Low Energy (Baja energía) 
PIN  Personal Identif ication Number (Número de identif icación personal) 
PUC  Personal Unblocking Code (Código de desloqueo personal) 
SID  Service Identif ier (Identifi cador del servicio) 
SPP  Serial Port Profi le (Perf il de puer to serie) 
SSP  Secure Sim ple Pairing (Empar ejamiento sencillo seguro) 
TRTP  Transfer Request Paramet er (Parámetro de la petición de transfe rencia) 
TREP  Transfer Response Parame ter (Parámetro de la respuesta a la petición de transferencia) 
VU  Vehicle Unit (Unidad instalada en el vehículo) 26.5.2016 L 139/417 Diar io Oficial de la Unión Europea ES    
3.  REGL AMENTOS Y NORMAS DE REFERENCIA 
La especific ación definida en el present e apéndice se refiere total o parcialmente a los siguient es Reglamentos y 
normas, de los que depende. En las cláusulas de este apéndice se especifican las normas pertinente s, o las 
cláusulas pertinentes de las mismas. En el caso de que surgiera cualquier contradicción, prevalecerán las cláusulas 
del presente apéndice. 
Los Reglamentos y normas a los que se remite el presente apéndice son: 
—  Reglamento (UE) no 165/2014 del Parlamento Europeo y del Consejo, de 4 de febrero de 2014, relativ o a los 
tacógraf os en el transpor te por carretera, por el que se deroga el Reglamento (CEE) no 3821/85 del Consejo 
relativ o al aparat o de control en el sector de los transpor tes por carretera y se modifica el Reglamento (CE) 
no 561/2006 del Parlament o Europeo y del Consejo relativ o a la armonización de determinadas disposiciones 
en mat eria social en el sector de los transpor tes por carretera. 
—  Reglamento (CE) no 561/2006 del Parlament o Europeo y del Consejo, de 15 de marzo de 2006, relativo a la 
armonización de deter minadas disposiciones en mater ia social en el sector de los transpor tes por carretera y 
por el que se modifi can los Reglamentos (CEE) no 3821/85 y (CE) no 2135/98 del Consejo y se deroga el 
Reglamento (CEE) no 3820/85 del Consejo. 
—  ISO 16844 — 4: Vehículos de carretera — Siste mas de tacógraf o — Parte 4: Interfaz CAN 
—  ISO 16844 — 7: Vehículos de carretera — Siste mas de tacógraf o — Parte 7: Parámetros 
—  Bluet ooth® — Perfil de puer to serie — V1.2 
—  Bluet ooth® — Versión Core 4.2 
—  Prot ocolo NMEA 0183 V4.1 
4.  PRINCIPIOS DE FUNCIONAMIENTO DE LA INTERF AZ 
4.1.  Condiciones previas para la transferencia de datos a trav és de la interf az ITS 
La VU será responsable de actualizar y mantener los datos que se deban almacenar en la VU sin ninguna partici­
pación de la interfaz ITS. El medio para ello está situado en el interior de la VU, se especifi ca en otros puntos del 
Reglamento y no se especifica en el presente apéndice. 
4.1.1  Datos facilitados a través de la interfaz ITS 
La VU será responsable de actualizar los datos que estarán disponibles a través de la interfaz ITS con una 
frecuencia determinada en los procedimiento s de la VU, sin ninguna participación de su interfaz ITS. Los datos de 
la VU servirán de base para poblar y actualizar los datos, el medio para ello se especifica en otros punt os del 
Reglamento o, si no existe tal especificación, es una función del diseño del product o y no se especifi ca en el 
present e apéndice. 
4.1.2  Contenido de los datos 
El cont enido de los datos será el especificado en el anex o 1 del present e apéndice. 
4.1.3  Aplicaciones ITS 
Las aplicaciones ITS utilizarán los datos puestos a disposición a través de la interfaz ITS, por ejem plo para 
optimizar la gestión de las actividades del conductor dentro del respet o del Reglamento, para detectar posibles 
fallos del tacógraf o o para usar los datos del GNSS. La especificación de las aplicaciones no está en el ámbito del 
present e apéndice. 26.5.2016 L 139/418 Diar io Oficial de la Unión Europea ES    
4.2.  Tecnología de la comunicación 
El inter cambio de datos mediante la interfaz ITS se efectuará a través de una interfaz Bluetooth ® compati ble de 
versión 4.2 o posterior . Bluetooth ® opera en la banda industr ial, científi ca y médica (ISM) sin licencia a entre 
2,4 y 2,485 GHz. Bluetooth® 4.2 ofrece mecanismos de privacidad y segur idad mejoradas y aumenta la velocidad 
y fiabilidad de las transfer encias de datos. A efectos de esta especificación, se utiliza Bluetooth® de 
clase 2 con un alcance de la señal de hasta 10 metros. Para mayor información sobre Bluetooth® 4.2, consúlt ese 
www .bluet ooth.com (https://www .bluetooth.org/en-us/specification/adopt ed-specif ications?_ga=1.21 5147412. 
2083380574.1435305676). 
La comunicación se establecerá con el equipo de comunicaciones después de efectuado un proceso de emp areja ­
mient o por parte de un dispositivo autorizado. Puesto que Bluetooth® utiliza un modelo maestro/esclav o para 
controlar el momento y el lugar en que los dispositivos pueden enviar datos, el tacógraf o tendrá la función de 
maestro, mientras que el dispositivo extern o tendrá la de esclav o. 
Cuando un dispositivo externo entra dentro del radio de alcance de la VU por primera vez, puede iniciarse el 
proceso de emparej amiento de Bluetooth® (véase también el anex o 2). Los dispositivos compar ten sus 
direcciones, nombres y perf iles y clave secreta común, que les permite conectarse cada vez que entren en contacto 
en el futuro. Una vez finalizado este paso, el dispositivo externo es de conf ianza y está en situación de iniciar 
solicitudes de descarg a de datos del tacógraf o. No está previsto añadir mecanismos de cifrado más allá de los 
facilitados por Bluetooth ®. No obstante, si se necesitan mecanismos de segur idad adicionales se proedrá de 
conf ormidad con el lo establecido en el apéndice 10 Mecanismos comunes de segur idad. 
La figur a siguiente muestra el principio general de la comunicación. 
El perf il SPP (perf il de puer to serie) de Bluetooth® servirá para transferi r datos de ña VU al dispositivo exte rno. 
4.3.  Autori zación mediante PIN 
Por razones de segur idad, la VU aplicará un sistem a de autor ización mediante código PIN separado del empareja ­
mient o Bluetooth. Cada VU será capaz de generar códigos PIN con fines de autenticación compuest os de al menos 
4 cifras. Cada vez que un dispositivo extern o se empareje con la VU deberá introducir el código PIN correcto 
antes de recibir datos. 26.5.2016 L 139/419 Diar io Oficial de la Unión Europea ES    
Si introduce el PIN correcto, el dispositivo pasa a la lista blanca que almacenará al menos 64 dispositivo s 
empa rejados con una VU específi ca. 
Un dispositivo que no consiga introducir el código PIN correcto tres veces seguidas pasará temporalment e a la 
lista negra. Mientras el dispositivo siga en la lista negra, toda nueva tentativa de emparejamiento será rechazada. 
Cada nuevo intento fallido tres veces seguidas de introducción del código PIN correcto tendrá como consecuencia 
una prohibición de cada vez mayor duración (véase la tabla 1). La introducción del código PIN correcto reajustará 
la duración de la prohibición y el número de intent os. La figura 1 del anex o 2 representa el diagrama de secuencia 
de un intent o de validación de un código PIN. 
Tabla 1 
Duración de la prohibición según el número de intentos fallidos consecutiv os de introducción del código 
Número de fallos consecutiv os Duración de la prohibición 
3 30 segundos 
6 5 minutos 
9 1 hora 
12 24 horas 
15 Permanent e  
Una unidad ITS que no consiga introducir el código PIN correcto quince veces (5 × 3) seguidas pasará permanen ­
temente a la lista negra. La prohibición permanente solamente podrá anularse introduciendo el código PUC 
correcto. 
El código PUC estará compuest o de 8 cifras y será facilitado por el fabricante junto con la VU. Una unidad ITS 
que no consiga introducir el código PUC correcto diez veces seguidas pasará irrevocableme nte a la lista negra. 
Si bien el fabricante puede ofrecer la opción de cambiar el código PIN directament e a través de la VU, el código 
PUC no será modif icable. La modifi cación del código PIN, si es posible, exigirá la introducción del código PIN 
actual directament e en la VU. 
Además, los dispositivos almacenados en la lista blanca se manten drán hasta que el usuar io los elimine 
manualment e (por ejemplo, a través de la interfaz hombre-máquina de la VU u otro medio). De este modo 
pueden eliminarse de la lista blanca las unidades ITS perdidas o robadas. Por otra parte, las unidades ITS que 
salgan fuera del radio de alcance de la conexión Bluetooth durante más de 24 horas serán automáticament e 
eliminadas de la lista blanca de la VU y deberán presentar de nuevo el código PIN correcto al restablecer la 
conexión. 
El format o de los mensaj es entre la interf az de la VU y la VU no se facilita, sino que se deja a la discreción del 
fabricante. No obstante , el fabricante deberá asegurar que se respete el formato de los mensajes entre la unidad 
ITS y la interfaz de la VU (véase las especificaciones de la norma ASN.1). 
Antes que una solicitud de datos reciba cualquier tipo de tratamient o, se verificarán las credenciales del remitent e. 
La figura 2 del anex o 2 representa el diagrama de secuencia de este procedimiento. Los dispositivo s que estén en 
la lista negra recibirán un rech azo automático , mientras que los dispositivos que no estén ni en la lista negra ni en 
la lista blanca recibirán una solicitud de PIN a la que deberán responder antes de volver a enviar su solicitud de 
datos. 26.5.2016 L 139/420 Diar io Oficial de la Unión Europea ES    
4.4.  Formato de los mensajes 
Todos los mensaj es que intercambien la unidad ITS y la interfa z de la VU presentarán una estructura con un 
formato compues to de tres partes: Una cabecera compuesta de un byte objetivo (TGT), un byte fuent e (SRC) y un 
byte de longitud (LEN). 
El campo de datos se compo ne de un byte identif icador de servicio (SID) y una cantidad variable de bytes de datos 
(máximo 255). 
El byte de suma de control es la suma de de todos los bytes del mensaj e tomados de 1 byte en 1 byte, en módulo 
256, excl uido el propio CS. 
El mensaj e será Big Endian. 
Tabla 2 
Format o general del mensaje 
Cabecera Cam pos de datos Suma de 
control 
TGT SRC LEN SID TRTP CC CM DATOS CS 
3 bytes Máx. 255 bytes 1 byte  
Cabecer a 
TGT y SRC: el ID de los dispositivo s objetivo (TGT) y fuente (SRC) del mensaj e. La interfaz de la VU tendrá el ID 
por defe cto «EE». Este ID no se puede cambiar . La unidad ITS utilizará el ID por defect o «A0» para su primer 
mensaj e de la sesión de comunicación. Seguidamente , la interfaz de la VU asignará un ID único a la unidad ITS, a 
la que informará del mencionado ID para futuros mensaj es durante la sesión. 
El byte LEN solamente tendrá en cuenta la parte «DATOS» del campo de datos (véase la tabla 2), los 4 primeros 
bytes son implícitos. 
La interfa z VU conf irmará la autenticidad del remit ente del mensaje cruzando su propia lista ID con los datos 
Bluetooth comprobando que la unidad ITS enumerada en el ID facilitado está actualmente dentro del radio de 
alcance de la conexión Bluetooth. 
Campo de datos 
Además del SID, el campo de datos cont endrá asimismo otros parámetros: un parámetro de petición de transpa ­
rencia (TRTP) y bytes de contador . 
Si los datos que hay que transpor tar son más largos que el espacio disponible en un mensaj e, se dividirán entre 
varios submensa jes. Cada submensaje tendrá la misma cabecera y SID, pero cont endrá un contador de 2 bytes, 
Counter Current (CC) y Counter Max (CM), para indicar el número de submensa jes. Al objeto de permitir la 
verificación de errores y la cancelación, el dispositivo recep tor confir ma cada uno de los submensa jes. El 
dispositivo de recepción puede aceptar el submensaje, solicitar su retransmisión, pedir al dispositivo de envío que 
comience de nuevo o abor tar la transmisión. 
Si no se utilizan, el CC y el CM recibirán el valor 0xFF . 
Por ejemplo, el mensaj e siguient e 
HEADER SID TRTP CC CM DATOS CS 
3 bytes Más largo de 255 bytes 1 byte  26.5.2016 L 139/421 Diar io Oficial de la Unión Europea ES    
Se transmitirá de este modo: 
HEADER SID TRTP 01 n DATA CS 
3 bytes 255 bytes 1 byte  
HEADER SID TRTP 02 n DATA CS 
3 bytes 255 bytes 1 byte  
… 
HEADER SID TRTP N N DATA CS 
3 bytes Máx. 255 bytes 1 byte  
La tabla 3 contiene los mensaj es que la VU y la unidad ITS podrán inter cambiar . El contenido de cada parámetro 
se da en hexadecimal. En aras de la claridad, el CC y el CM no están representados en la tabla, véase la tabla 
anterior para el formato compl eto. 
Tabla 3 
Contenido deta llado del mensaje 
Mensaje Cabecera DATOS Suma de 
control 
TGT SRC LEN SID TRTP DATOS  
RequestPIN ITSID EE 00 01 FF   
SendITSID ITSID EE 01 02 FF ITSID  
SendPIN EE ITSID 04 03 FF 4*INTEGER (0..9)  
PairingR esult ITSID EE 01 04 FF BOOLEAN (T/F)  
SendPUC EE ITSID 08 05 FF 8*INTEGER (0..9)  
BanLif tingResu lt ITSID EE 01 06 FF BOOLEAN (T/F)  
RequestRejected ITSID EE 08 07 FF Tiem po  
RequestData  
standardT achData EE ITSID 01 08 01   
personalT achData EE ITSID 01 08 02   
gnssData EE ITSID 01 08 03   
standardEventData EE ITSID 01 08 04   
personalEventData EE ITSID 01 08 05   
standardFaultD ata EE ITSID 01 08 06   
manufa cturerData EE ITSID 01 08 07   26.5.2016 L 139/422 Diar io Oficial de la Unión Europea ES    
Mensaje Cabecera DATOS Suma de 
control 
TGT SRC LEN SID TRTP DATOS  
ResquestAccepted ITSID EE Len 09 TREP Datos  
DataUnavail able  
Datos no disponibles ITSID EE 02 0A TREP 10  
Datos personales no 
compar tidos ITSID EE 02 0A TREP 11  
NegativeAnsw er  
Enví o no acep tado ITSID EE 02 0 B SID pet. 10  
Servicio no admitido ITSID EE 02 0 B SID pet. 11  
Subfunción no admi ­
tida ITSID EE 02 0 B SID pet. 12  
Longitud del mensaje 
incor recta ITSID EE 02 0 B SID pet. 13  
Condiciones incor rectas 
o error en la secuencia 
de la petición ITSID EE 02 0 B SID pet. 22  
Petición no admisible ITSID EE 02 0 B SID pet. 31  
Datos no disponibles ITSID EE 02 0 B SID pet. 78  
Discordancia ITSID ITSID EE 02 0 B SID pet. FC  
ITSID No encontrado ITSID EE 02 0 B SID pet. FB   
RequestPIN (SID 01) 
La interfaz de la VU envía este mensaje si una unidad ITS que no está en la lista negra, pero tampoco en la blanca, 
envía una petición de datos. 
SendITSID (SID 02) 
La interfaz de la VU envía este mensaj e siempre que un nuevo dispositivo enví e una petición. Este dispositivo 
usará el ID por defe cto «A0» antes de recibir un ID único para la sesión de comunicación. 
SendPIN (SID 03) 
La unidad ITS envía este mensaj e para que la interf az de la VU lo incluya en su lista blanca. El conte nido de este 
mensaj e es un código de 4 ENTER OS entre 0 y 9. 
PairingR esult (SID 04) 
La interfa z de la VU enví a este mensaj e para informar a la unidad ITS de si el código PIN enviado era el correcto. 
El contenido de este mensaj e será un BOOLEANO con el valor «verdadero» si el código PIN era correcto, y «falso» 
de lo contrar io. 
SendPUC (SID 05) 
La unidad ITS envía este mensaje para levantar una sanción de inclusión en la lista negra de la interfa z de la VU. 
El cont enido de este mensaj e es un código de 8 ENTER OS entre 0 y 9. 26.5.2016 L 139/423 Diar io Oficial de la Unión Europea ES    
BanLif tingResu lt (SID 06) 
La interfaz de la VU envía este mensaj e para informar a la unidad ITS de si el código PUC enviado era el correcto. 
El cont enido de este mensaje será un BOOLEANO con el valor «verdadero» si el código PUC era correcto, y «falso» 
de lo contrar io. 
RequestRejected (SID 07) 
La interfaz de la VU envía este mensaj e en respuesta a cualquier mensaje de una unidad ITS incluida en la lista 
negra, salvo «SendPUC». El mensaje cont endrá el tiempo restant e que la unidad ITS esté incluida en la lista negra 
de acuerdo con el formato de la secuencia «Hora» definida en el anex o 3. 
RequestData (SID 08) 
La unidad ITS envía este mensaj e para acceder a datos. Un parámetro de petición de transferencia (TRTP) de un 
byte indica el tipo de datos solicitados. Exist en varios tipos de datos: 
—  standardT achDa ta (TRTP 01): Datos disponibles del tacógraf o clasif icados como no personales. 
—  personalT achD ata (TRTP 02): Datos disponibles del tacógraf o clasif icados como personales. 
—  gnssData (TRTP 03): Datos del GNSS, siempre personales. 
—  standardEventData (TRTP 04): Datos de suceso registrados clasif icados como no personales 
—  personalEventData (TRTP 05): Datos de suceso registrados clasif icados como personales 
—  standardFa ultData (TRTP 06): Fallos registrados clasif icados como no personales 
—  manuf acturerData (TRTP 07): datos puestos a disposición por el fabricante. 
Véase el anex o 3 del present e apéndice para más información sobre el cont enido de cada tipo de dato. 
Véase el apéndice 12 para más información sobre el formato y el contenido de los datos del GNSS. 
Véanse los anex os IB y IC para más información sobre código de datos de suceso y fallos. 
ResquestAccepted (SID 09) 
La interf az de la VU envía este mensaj e si se ha aceptad o un mensaj e «RequestData» de la unidad ITS. Este mensaj e 
contiene un TREP de 1 byte, que es el byte TRTP del mensaj e «RequestData» asociado, y todos los datos del tipo 
solicitado. 
DataUnavail able (SID 0A) 
La interfaz de la VU envía este mensaj e si, por una razón deter minada, los datos solicitados no están disponibles 
para ser enviados a una unidad ITS incluida en la lista blanca. El mensaj e contiene un TREP de 1 byte que es el 
TRTP de los datos solicitados y un código de error de 1 byte especifi cado en la tabla 3. Están disponibles los 
códigos siguientes: 
—  No hay datos disponibles (10): La interfaz de la VU no puede acceder a los datos de la VU por razones no 
especificadas. 
—  Datos personales no compar tidos (11): La unidad ITS intenta recuperar datos personales cuando no son 
compar tidos. 26.5.2016 L 139/424 Diar io Oficial de la Unión Europea ES    
NegativeAnsw er (SID 0B) 
La interfaz de la VU envía estos mensa jes si no puede efetuarse una petición por cualquier otra razón que la 
indisponibilidad de los datos. Nor malmente estos mensaj es son el resultado de un formato de petición incor recto 
(Longitud, SID, ITSID...), pero no siempr e. El TRTP en el campo de datos contiene el identif icador de segur idad 
SID de la petición. El campo da datos contiene un código que identif ica la razón de la respuesta negativa. Están 
disponibles los códigos siguientes: 
—  Rech azo general (código: 10) 
—  Esta acción no puede efectuarse por una razón no citada a continuación ni en la sección (DataUnavailable). 
—  Servicio no admitido (código: 11) 
—  SID de la petición no comprendido. 
—  Subfunción no admitida (código: 12) 
—  TRTP de la petición no comprendido. A causa, por ejemplo, de ausencia de valores aceptados. 
—  Longitud del mensaj e incor recta (código: 13) 
—  La longitud del mensaj e recibido es incor recta (discordancia entre el byte LEN y la longitud real del mensa je). 
—  Condiciones incor rectas o error en la secuencia de la petición (código: 22) 
—  El servicio requer ido no está activo o la secuencia de mensaj es de petición es incor recta. 
—  Petición no admisible (código: 33) 
—  El registro del parámetro de la solicitud (campo de datos) no es válido. 
—  Respuesta pendiente (código: 78) 
—  La acción solicitada no se puede efectuar a tiempo y la VU no está preparada para aceptar otra petición. 
—  Discordancia del ITSID (código: FB) 
—  El SRC ITSID no concuerda con el dispositivo asociado tras la compar ación con la información Bluet ooth. 
—  ITSID no encontrado (código: FC) 
—  El SRC ITSID no está asociado a ningún dispositivo . 
Las líneas 1 a 72 (For matMessageModule) del código ASN.1 del anex o 3 especifican el formato de los mensaj es 
tal como se descr ibe en la tabla 3. A continuación figuran más detalles sobre el contenido de los mensaj es. 
4.5.  Consentimiento del conductor 
Todos los datos disponibles están clasificado s como estándar o personales. Los datos personales solo serán 
accesibles si el conduct or dio su consentimiento en aceptar que sus datos de tacógraf o personales puedan salir de 
la red del vehículo para aplicaciones de terceros. 
El conductor da su consentimiento cuando, al introducir por primera vez una tarjeta de conduct or o de taller 
actualmente desconocida para la unidad instalada en el vehículo, se invita al titular de la tarjeta a expresar su 
consentimient o para la salida de datos personales relacionados con el tacógraf o a través de la interfaz opcional 
ITS. (véase también el anex o I C, apar tado 3.6.2). 
El estado de consentimient o (activado/desactivado) se registra en la memor ia del tacógraf o. 
En el caso de múltiples conduct ores, solamente se compar tirán con la interfaz ITS los datos personales de los 
conduct ores que hayan dado su consentimient o. Por ejemplo, si en el vehículo hay dos conduct ores y solamente el 
primero ha aceptad o compar tir sus datos personales, los relativ os al segundo conduct or no serán compar tidos. 26.5.2016 L 139/425 Diar io Oficial de la Unión Europea ES    
4.6.  Recuperación de datos estándar 
La figura 3 del anex o 2 representa los diagramas de secuencia de una petición válida enviada por la unidad ITS 
para acceder a datos estándar . La unidad ITS figura en la lista blanca y no pide datos personales, no es necesar ia 
ninguna verificación adicional. Los diagramas consideran que ya se ha seguido el procedimiento adecuado 
ilustrado en la figura 2 del anex o 2. Pueden equipararse a la casilla gris REQUES T TREATMENT de la figura 2. 
Entre los datos disponibles, se considerarán estándar : 
—  standardT achDa ta (TRTP 01) 
—  StandardEventData (TRTP 04) 
—  standardFa ultData (TRTP 06) 
4.7.  Recuperación de datos personales 
La figura 4 del anex o 2 representa el diagrama de secuencia para el procesamiento de peticiones de datos 
personales. Como se ha dicho anter iormente, la interfaz VU solamente enviará datos personales si el conductor ha 
dado su consentimiento explícito (véase también 4.5). De otro modo, la petición deberá ser automáticament e 
rech azada. 
Entre los datos disponibles, se considerarán personales: 
—  personalT achD ata (TRTP 02) 
—  gnssData (TRTP 03) 
—  personalEventData (TRTP 05) 
—  manuf acturerData (TRTP 07) 
4.8.  Recuperación de datos de incidentes y fallos 
Las unidades ITS deberán poder solicitar datos de incident es que conteng an la lista de todos los incident es 
inesperados. Estos datos se considerarán estándar o personales, véase el anex o 3. El contenido de cada incident e 
deberá ser conf orme a la documentación presentada en el anex o 1 de este apéndice.  26.5.2016 L 139/426 Diar io Oficial de la Unión Europea ES    
ANEX O 1 
LIST A DE DATOS DISPONIBLES A TRA VÉS DE LA INTERF AZ ITS 
Datos Fuente Clasificación recomendada 
VehicleIdentif icationNumber Unidad Vehículo no personal 
CalibrationDat e Unidad Vehículo no personal 
Tachog raphV ehicleSpeed speed instant t Unidad Vehículo personal 
Driver1W orkingStat e Select or driver Unidad Vehículo personal 
Driver2W orkingStat e Unidad Vehículo personal 
DriveRecognize Speed Threshold detected Unidad Vehículo no personal 
Driver1TimeRelatedStat es Weekly day time Tarjeta conduct or personal 
Driver2TimeRelatedStat es Tarjeta conduct or personal 
DriverCardDr iver1 Unidad Vehículo no personal 
DriverCardDr iver2 Unidad Vehículo no personal 
OverSpeed Unidad Vehículo personal 
TimeDate Unidad Vehículo no personal 
HighResolution TotalV ehicleDistance Unidad Vehículo no personal 
ServiceComponentIdentification Unidad Vehículo no personal 
ServiceDela yCalendarTimeBased Unidad Vehículo no personal 
Driver1Identif ication Tarjeta conduct or personal 
Driver2Identif ication Tarjeta conduct or personal 
NextCalibrationDat e Unidad Vehículo no personal 
Driver1ContinuousDr ivingTime Tarjeta conduct or personal 
Driver2ContinuousDr ivingTime Tarjeta conduct or personal 
Driver1CumulativeBreakTime Tarjeta conduct or personal 
Driver2CumulativeBreakTime Tarjeta conduct or personal 
Driver1Cur rentDurationOfSelectedA ctivity Tarjeta conduct or personal 
Driver2Cur rentDurationOfSelectedA ctivity Tarjeta conduct or personal 26.5.2016 L 139/427 Diar io Oficial de la Unión Europea ES    
Datos Fuente Clasificación recomendada 
SpeedA uthor ised Unidad Vehículo no personal 
Tachog raphCardSlot1 Tarjeta conduct or no personal 
Tachog raphCardSlot2 Tarjeta conduct or no personal 
Driver1Name Tarjeta conduct or personal 
Driver2Name Tarjeta conduct or personal 
OutOfScopeCondition Unidad Vehículo no personal 
ModeOfOperation Unidad Vehículo no personal 
Driver1CumulatedDr ivingTimePreviousAndCur rentW eek Tarjeta conduct or personal 
Driver2CumulatedDr ivingTimePreviousAndCur rentW eek Tarjeta conduct or personal 
EngineSpeed Unidad Vehículo personal 
Regist eringMemberState Unidad Vehículo no personal 
VehicleRegistrationNumber Unidad Vehículo no personal 
Driver1EndOfLastDailyRestPer iod Tarjeta conduct or personal 
Driver2EndOfLastDailyRestPer iod Tarjeta conduct or personal 
Driver1EndOfLastW eeklyRestP eriod Tarjeta conduct or personal 
Driver2EndOfLastW eeklyRestP eriod Tarjeta conduct or personal 
Driver1EndOfSecondLastW eeklyRestPer iod Tarjeta conduct or personal 
Driver2EndOfSecondLastW eeklyRestPer iod Tarjeta conduct or personal 
Driver1Cur rentDailyDr ivingTime Tarjeta conduct or personal 
Driver2Cur rentDailyDr ivingTime Tarjeta conduct or personal 
Driver1Cur rentW eeklyDr ivingTime Tarjeta conduct or personal 
Driver2Cur rentW eeklyDr ivingTime Tarjeta conduct or personal 
Driver1TimeLef tUntilN ewDailyRestPer iod Tarjeta conduct or personal 
Driver2TimeLef tUntilN ewDailyRestPer iod Tarjeta conduct or personal 
Driver1CardExpir yDate Tarjeta conduct or personal 26.5.2016 L 139/428 Diar io Oficial de la Unión Europea ES    
Datos Fuente Clasificación recomendada 
Driver2CardExpir yDate Tarjeta conduct or personal 
Driver1CardNextMandatory DownloadDat e Tarjeta conduct or personal 
Driver2CardNextMandatory DownloadDat e Tarjeta conduct or personal 
Tachog raphNextMandatory DownloadDat e Unidad Vehículo no personal 
Driver1TimeLef tUntilN ewW eeklyRestP eriod Tarjeta conduct or personal 
Driver2TimeLef tUntilN ewW eeklyRestP eriod Tarjeta conduct or personal 
Driver1NumberOfTimes9hDailyDr ivingTimesExceeded Tarjeta conduct or personal 
Driver2NumberOfTimes9hDailyDr ivingTimesExceeced Tarjeta conduct or personal 
Driver1CumulativeUnint erruptedRestTime Tarjeta conduct or personal 
Driver2CumulativeUnint erruptedRestTime Tarjeta conduct or personal 
Driver1MinimumDailyRest Tarjeta conduct or personal 
Driver2MinimumDailyRest Tarjeta conduct or personal 
Driver1MinimumW eeklyRest Tarjeta conduct or personal 
Driver2MinimumW eeklyRest Tarjeta conduct or personal 
Driver1MaximumDailyPer iod Tarjeta conduct or personal 
Driver2MaximumDailyPer iod Tarjeta conduct or personal 
Driver1MaximumDailyDr ivingTime Tarjeta conduct or personal 
Driver2MaximumDailyDr ivingTime Tarjeta conduct or personal 
Driver1NumberOfUsedReducedDailyRestPer iods Tarjeta conduct or personal 
Driver2NumberOfUsedReducedDailyRestPer iods Tarjeta conduct or personal 
Driver1RemainingCur rentDr ivingTime Tarjeta conduct or personal 
Driver2RemainingCur rentDr ivingTime Tarjeta conduct or personal 
GNSS position Unidad Vehículo personal  
2)DATOS CONTINUOS DEL GNSS DISPONIBLES PREVIO CONSENTIMIENTO DEL CONDUCTOR 
Véase el apéndice 12 — GNSS 26.5.2016 L 139/429 Diar io Oficial de la Unión Europea ES    
3)CÓDIGOS DE INCIDENCIA DISPONIBLES SIN EL CONSENTIMIENTO DEL CON DUCTOR 
Incidente Reglas de almacenamiento Datos que hay que registrar en cada incidente 
Inserción de una tarjeta 
no válida —  los 10 incidentes más recientes —  fecha y hora del incidente 
—tipo, número y Estado miembro emisor de la tar­
jeta y generación de la tarjeta que crea el inci­
dente 
—  número de incidentes similares ocur ridos ese día 
Conf licto de tarjetas —  los 10 incidentes más recientes —  fecha y hora en que comenzó el incident e 
—  fecha y hora en que term inó el incidente 
—tipo, número y Estado miembro emisor de la tar­
jeta y generación de las dos tarjetas que crean el 
conf licto 
Error al cerrar la última 
sesión de la tarjeta —  los 10 incidentes más recientes —  fecha y hora de inserción de la tarjeta 
—tipo, número, Estado miembro emisor , y genera ­
ció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 
—VRN, Estado miembro de matrícula y genera ­
ción de la VU 
Interr upción del suminis ­
tro eléctr ico (2) —el incidente de más duración ocu­
rrido en cada uno de los 10 últi­
mos días en que se hayan produ ­
cido incidentes de ese tipo 
—los 5 incident es de mayor dura ­
ción ocur ridos en los últimos 365 
días —  fecha y hora en que comenzó el incident e 
—  fecha y hora en que term inó el incidente 
—tipo, número y Estado miembro emisor de la tar­
jeta, y generación de cualquier tarjeta que se 
haya inser tado al comenzar o al term inar el inci­
dente 
—  número de incidentes similares ocur ridos ese día 
Error de comunicación 
con la instalación de co­
municación remota —el incidente de más duración ocu­
rrido en cada uno de los 10 últi­
mos días en que se hayan produ ­
cido incidentes de ese tipo 
—los 5 incident es de mayor dura ­
ción ocur ridos en los últimos 365 
días —  fecha y hora en que comenzó el incident e 
—  fecha y hora en que term inó el incidente 
—tipo, número y Estado miembro emisor de la tar­
jeta, y generación de cualquier tarjeta que se 
haya inser tado al comenzar o al term inar el inci­
dente 
—  número de incidentes similares ocur ridos ese día 
Ausencia de información 
de posición del recep tor 
del GNSS —el incidente de más duración ocu­
rrido en cada uno de los 10 últi­
mos días en que se hayan produ ­
cido incidentes de ese tipo 
—los 5 incident es de mayor dura ­
ción ocur ridos en los últimos 365 
días —  fecha y hora en que comenzó el incident e 
—  fecha y hora en que term inó el incidente 
—tipo, número y Estado miembro emisor de la tar­
jeta, y generación de cualquier tarjeta que se 
haya inser tado al comenzar o al term inar el inci­
dente 
—  número de incidentes similares ocur ridos ese día 
Error en datos de movi­
mient o —el incidente de más duración ocu­
rrido en cada uno de los 10 últi­
mos días en que se hayan produ ­
cido incidentes de ese tipo 
—los 5 incident es de mayor dura ­
ción ocur ridos en los últimos 365 
días —  fecha y hora en que comenzó el incident e 
—  fecha y hora en que term inó el incidente 
—tipo, número y Estado miembro emisor de la tar­
jeta, y generación de cualquier tarjeta que se 
haya inser tado al comenzar o al term inar el inci­
dente 
—  número de incidentes similares ocur ridos ese día 26.5.2016 L 139/430 Diar io Oficial de la Unión Europea ES    
Incidente Reglas de almacenamiento Datos que hay que registrar en cada incidente 
Conf licto de movimient o 
del vehículo —el incidente de más duración ocu­
rrido en cada uno de los 10 últi­
mos días en que se hayan produ ­
cido incidentes de ese tipo 
—los 5 incident es de mayor dura ­
ción ocur ridos en los últimos 365 
días —  fecha y hora en que comenzó el incident e 
—  fecha y hora en que term inó el incidente 
—tipo, número y Estado miembro emisor de la tar­
jeta, y generación de cualquier tarjeta que se 
haya inser tado al comenzar o al term inar el inci­
dente 
—  número de incidentes similares ocur ridos ese día 
Intent o de violación de la 
segur idad los 10 incident es más reciente s de 
cada tipo —  fecha y hora en que comenzó el incident e 
—  fecha y hora en que terminó el incident e (si es 
pertinente), 
—tipo, número y Estado miembro emisor de la tar­
jeta, y generación de cualquier tarjeta que se 
haya inser tado al comenzar o al term inar el inci­
dente 
—  tipo de incident e. 
Conf licto de tiempo —el incidente de más duración ocu­
rrido en cada uno de los 10 últi­
mos días en que se hayan produ ­
cido incidentes de ese tipo 
—los 5 incident es de mayor dura ­
ción ocur ridos en los últimos 365 
días —  fecha y hora del equipo de registro 
—  fecha y hora del GNSS 
—tipo, número y Estado miembro emisor de la tar­
jeta, y generación de cualquier tarjeta que se 
haya inser tado al comenzar o al term inar el inci­
dente 
—  número de incidentes similares ocur ridos ese día  
4)CÓDIGOS DE INCIDENCIA DISPONIBLES CON CONSENTIMIENTO DEL CON DUCTOR 
Incidente Reglas de almacenamiento Datos que hay que registrar en cada incidente 
Conducción sin tarjeta 
adecuada —el incidente de más duración ocu­
rrido en cada uno de los 10 últi­
mos días en que se hayan produ ­
cido incidentes de ese tipo 
—los 5 incident es de mayor dura ­
ción ocur ridos en los últimos 365 
días —  fecha y hora en que comenzó el incident e 
—  fecha y hora en que term inó el incidente 
—tipo, número y Estado miembro emisor de la tar­
jeta, y generación de cualquier tarjeta que se 
haya inser tado al comenzar o al term inar el inci­
dente 
—  número de incidentes similares ocur ridos ese día 
Inserción de tarjeta du­
rante la conducción —  el último incident e ocur rido en 
cada uno de los 10 últimos días 
en que se hayan producido inci­
dentes de ese tipo —  fecha y hora del incidente 
—tipo, número, Estado miembro emisor , y genera ­
ción de la tarjeta 
—  número de incidentes similares ocur ridos ese día 
Exceso de velocidad (1) —  el incidente más grav e en cada 
uno de los 10 últimos días en que 
se hayan producido incident es de 
este tipo (es decir , el que haya 
ocur rido con la velocidad media 
más alta) 
—los 5 incident es más graves ocu­
rridos en los últimos 365 días 
—el primer incident e que haya ocu­
rrido después del último cali­
brado —  fecha y hora en que comenzó el incident e 
—  fecha y hora en que term inó el incidente 
—  velocidad máxima medida durante el incident e 
—  media aritmética de la velocidad medida durant e 
el incident e 
—tipo, número y Estado miembro emisor de la tar­
jeta y generación de la tarjeta del conductor (si 
corresponde) 
—  número de incidentes similares ocur ridos ese día  26.5.2016 L 139/431 Diar io Oficial de la Unión Europea ES    
5)CÓDIGOS DE DATOS DE FALLO DISPONIBLES SIN EL CONSENTIMIENTO DEL CONDUCTOR 
Fallo Reglas de almacenamiento Datos que hay que registrar en cada fallo 
Fallo de la tarjeta —  los 10 fallos más recientes de la 
tarjeta del conduct or —  fecha y hora en que comenzó el fallo, 
—  fecha y hora en que term inó el fallo 
—tipo, número, Estado miembro emisor , y genera ­
ción de la tarjeta 
Fallos del aparato de con­
trol —  los 10 fallos más recientes de 
cada tipo 
—  el primer fallo ocur rido después 
del último calibrado —  fecha y hora en que comenzó el fallo 
—  fecha y hora en que term inó el fallo 
—  tipo de fallo 
—tipo, número y Estado miembro emisor de la tar­
jeta, y generación de cualquier tarjeta que se 
haya inser tado al comenzar o al term inar el inci­
dente  
Este fallo será provocado por cualquiera de los fallos siguiente s, fuera del modo de calibrado: 
—  Fallo interno de la VU 
—  Fallo de la impresora 
—  Fallo de la pantalla 
—  Fallo de transfer encia 
—  Fallo del sensor 
—  Fallo del recept or del GNSS o de la instalación externa del GNSS 
—  Fallo de la instalación de comunicación remota 
6)INCIDENTES Y FALLO S ESPECÍFICOS DEL FABRICAN TE SIN CONSENTIMIENTO DEL CONDUCT OR 
Incident e o fallo Reglas de almacenamiento Datos que hay que registrar en cada incidente 
A definir por el fabri­
cant e A definir por el fabricante A definir por el fabricante   26.5.2016 L 139/432 Diar io Oficial de la Unión Europea ES    
ANEX O 2 
DIA GRAMAS DE SECUENCIA DE INTER CAMBIOS DE MENSAJES CON LA UNID AD ITS 
Figura 1 
Diag rama de secuencia para intento de validación con PIN 
26.5.2016 L 139/433 Diar io Oficial de la Unión Europea ES    
Figura 2 
Diag rama de secuencia para verificación de la autor ización de la unidad ITS 
26.5.2016 L 139/434 Diar io Oficial de la Unión Europea ES    
Figura 3 
Diag rama de secuencia para procesar una petición de datos clasif icados como no personales (previo acceso con 
PIN correcto ) 
Figura 4 
Diag rama de secuencia para procesar una petición de dato s clasif icados como personales (previo acceso con 
PIN correcto ) 
26.5.2016 L 139/435 Diar io Oficial de la Unión Europea ES    
Figura 5 
Diag rama de secuencia para intento de validación con PUC 
26.5.2016 L 139/436 Diar io Oficial de la Unión Europea ES    
ANEX O 3 
ESPECIFIC ACIONES ASN .1 
26.5.2016 L 139/437 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/438 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/439 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/440 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/441 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/442 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/443 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/444 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/445 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/446 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/447 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/448 Diar io Oficial de la Unión Europea ES    
Apéndice 14 
FUNCIÓN DE COMUNICA CIÓN A DIST ANCIA 
ÍNDICE 
1 INTR ODUCCIÓN ................................................................................................................................ 450 
2 ALCANCE ......................................................................................................................................... 451 
3 ACRÓNIMOS, DEFINICIONES Y ANOT ACIONES ........................................................................................ 452 
4 ESCENARIOS OPERA TIVOS .................................................................................................................. 454 
4.1 Resumen .............................................................................................................................. 454 
4.1.1 Condiciones previas a la transfer encia de datos mediante una interfaz DSR C de 5,8 GHz ........................ 454 
4.1.2 Perf il 1a: mediante un lector de comunicaciones de teledetección temprana apuntado manualment e o insta ­
lado provisionalmente junto a la carretera y apuntado .................................................................... 455 
4.1.3 Perf il 1b: mediante un lector de comunicaciones de teled etección temprana (REDCR) instalado en un ve­
hículo y dirigido .................................................................................................................... 456 
4.2 Segur idad/Int egridad ............................................................................................................... 456 
5 DISEÑO Y PROTOC OLOS DE COMUNIC ACIÓN A DIST ANCIA ..................................................................... 456 
5.1 Diseño ................................................................................................................................. 456 
5.2 Flujo de traba jo...................................................................................................................... 459 
5.2.1 Operaciones .......................................................................................................................... 459 
5.2.2 Interp retación de los datos recibidos a través de la comunicación DSR C............................................. 461 
5.3 Parámetros de la interf az física de DSR C para comunicación a distancia .............................................. 461 
5.3.1 Limitaciones de posición .......................................................................................................... 461 
5.3.2 Parámetros de los enlaces ascendent e y descendente ....................................................................... 461 
5.3.3 Diseño de la antena ................................................................................................................ 466 
5.4 Requisitos del prot ocolo DSR C para RTM.................................................................................... 466 
5.4.1 Resumen .............................................................................................................................. 466 
5.4.2 Comandos ............................................................................................................................ 469 
5.4.3 Secuencia de comandos de interr ogaci ón..................................................................................... 469 
5.4.4 Estr ucturas de los datos ........................................................................................................... 470 
5.4.5 Elementos de RtmData, acciones realizadas y definiciones ............................................................... 472 
5.4.6 Mecanismo de transfer encia de datos.......................................................................................... 476 
5.4.7 Descr ipción detallada de la transacción DSR C............................................................................... 476 
5.4.8 Descr ipción de la transacción de pruebas de la DSR C..................................................................... 486 
5.5 Cumplimient o de la Directiva 2015/719/CE ................................................................................. 490 
5.5.1 Resumen .............................................................................................................................. 490 26.5.2016 L 139/449 Diar io Oficial de la Unión Europea ES    
5.5.2 Comandos ............................................................................................................................ 490 
5.5.3 Secuencia de comandos de interr ogaci ón..................................................................................... 490 
5.5.4 Estr ucturas de los datos ........................................................................................................... 490 
5.5.5 Módulo ASN.1 para la transacción OWS DSR C............................................................................. 491 
5.5.6 Elementos de OwsData, acciones realizadas y definicione s............................................................... 492 
5.5.7 Mecanismos de transfe rencia de datos......................................................................................... 492 
5.6 Transf erencia de datos entre la DSR C-VU y la VU .......................................................................... 492 
5.6.1 Conexión física e interfaces ....................................................................................................... 492 
5.6.2 Protocolo de aplicaciones ......................................................................................................... 493 
5.7 Gestión de errores .................................................................................................................. 494 
5.7.1 Registro y comunicación de los datos en la DSR C-VU ..................................................................... 494 
5.7.2 Errores de comunicación inalámbr ica ......................................................................................... 494 
6 PRUEBAS PARA LA PUEST A EN SER VICIO Y LAS INSPECCIONES PERIÓDICAS DE LA FUNCIÓN DE COMUNICA ­
CIÓN A DIST ANCIA ........................................................................................................................... 496 
6.1 Generalidades ........................................................................................................................ 496 
6.2 ECHO .................................................................................................................................. 496 
6.3 Pruebas para validar el cont enido de datos seguros ........................................................................ 496  
1  INTR ODUCCIÓN 
En este apéndice se especifican el diseño y los procedimiento s que deben seguirse para llevar a cabo la función 
de comunicación a distancia (la Comunicación) con arreglo a los dispuest o en el artículo 9 del Reglamento (UE) 
no 165/2014 (el Reglamento) . 
DSC_1  El Reglamento (UE) no 165/2014 establece que el tacógraf o incor porará una funcionalidad de 
comunicación a distancia que permita que los agentes de las autori dades de control compet entes 
puedan leer la información del tacógraf o de vehículos en circulación mediante un equipo de interr o­
gació n a distancia (el lector de teled etección temprana, REDCR), específicamente, un equipo de interr o­
gació n que se conecta de manera inalámbr ica a través de interf aces de las comunicaciones especia ­
lizadas de corto alcance (DSR C) de 5,8 GHz del CEN. 
Es impor tante entender que esta funcionalidad tiene por objeto servir excl usivamente como filtro 
previo de selección de vehículos para controlarlos más detenidament e y no sustituye al proceso de 
control formal que se establece en el Reglamento (UE) no 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ógraf o y las autor idades de control, con fines de control en carretera, facilita una mayor selectividad 
de este tipo de controles. 
DSC_2  Los Datos se inter cambiarán mediante la Comunicación que consistirá en un enlace inalámbr ico a través 
de comunicaciones inalámbr icas DSR C de 5,8 GHz de conf ormidad con el presente apéndice y 
evaluado con los parámetros pertinente s que se establecen en EN 300 674-1 {Electromagnetic 
compati bility and Radio spectr um Matte rs (ERM); Road Transpor t and Traffic Telematics (RTTT); 
Dedicat ed Shor t Range Communication (DSR C) transmission equipment (500 kbit/s / 250 kbit/s) 
operating in the 5,8 GHz Industr ial, Scientific and Medical (ISM) band; Part 1 General charact eristics 
and test methods for Road Side Units (RSU) and On -Board Units (OBU)}. 
DSC_3  La Comunicación se establecerá con el equipo de comunicaciones solo cuando lo solicite el equipo de la 
autori dad de control compet ente por medios de radiocomunicación compati bles (el lector de 
comunicación de teledetección tempr ana, REDCR). 
DSC_4  Los Datos se prot egerán para garantizar su integrid ad. 26.5.2016 L 139/450 Diar io Oficial de la Unión Europea ES    
DSC_5  El acceso a los Datos comunicados se restr ingirá a las autori dades de control compet entes autori zadas 
para verificar las infracciones del Reglamento (CE) no 561/2006 y del Reglamento (UE) no 165/2014 y 
a los talleres en la medida en que sea necesar io para verificar la funcionamiento correcto del 
tacógraf o. 
DSC_6  El inter cambio de los Datos durante la Comunicación se limitará a aquellos necesar ios para hacer más 
selectiv os los controles de carretera de los vehículos cuyo tacógraf o haya podido ser manipulado o 
utilizado indebidament e. 
DSC_7  La integr idad y la segur idad de los datos se obtendr á protegiendo 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 
segur idad (véase el apar tado 5.4.4) por medio de la telecomunicació n inalámbr ica DSR C de 5,8 GHz, 
lo que implica que solo las personas autor izadas de las autor idades de control compet entes cuentan 
con los medios para interpr etar los datos transmitidos a través de la Comunicación y para verificar su 
autenti cidad. Véase el Apéndice 11, «Mecanismos de segur idad comunes». 
DSC_8  Los Datos incor porarán una indicación temporal con la fecha y hora de su última actualización. 
DSC_9  El conte nido de los datos de segur idad solo se dará a conocer a y quedará bajo el control exclusiv o de 
las autoridades de control compet entes y aquellos terceros con los que compar tan esta información y 
queda fuera de las disposiciones de la Comunicación que es objeto del present e apéndice, a menos que 
la Comunicación prevea la transfe rencia de un paquete de datos de segur idad con cada paquete de datos 
útiles. 
DSC_10  La misma arquite ctura y equipo podrán emplearse para obtener otros tipos de datos (como el peso a 
bordo) mediante la arquit ectura aquí especificada. 
DSC_11  A efectos de aclaración, de conf ormidad con las disposiciones del Reglamento (UE) no 165/2014 
(artículo 7), los datos relativ os a la identidad del conduct or no se transmitirán en la Comunicación. 
2  ALCAN CE 
El propósito del present e apéndice es especifi car el modo en que los agentes de las autoridades de control 
compet entes utilizan una comunicación inalámbr ica DSR C de 5,8 GHz específica para obtener datos a distancia 
de un vehículo seleccionado (los Datos) que indiquen que dicho vehículo ha podido infringir el Reglamento (UE) 
no 165/2014 y deba ser detenido para posterio res investig aciones. 
El Reglamento (UE) no 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) no 165/2014. 
En estas circunstancias, el tiempo de que se dispone para la comunicación es limitado porque la Comunicación es 
específica y tiene un diseño de corto alcance. Además, las autoridades de control compet entes pueden 
apro vechar el mismo medio de comunicación utilizado en la super visión a distancia de tacógraf os (RTM) para 
otras aplicaciones (como los pesos máximos y las dimensiones de vehículos pesados que se establecen en la 
Directiva (UE) 2015/719) y estas operaciones pueden realizarse por separado o de manera consecutiva según el 
criterio de las autor idades de control compet entes. 
El present e apéndice especifi ca: 
—  el equipo, los procedimiento s y los prot ocolos de comunicaciones que han de utilizarse para la 
Comunicación; 
—  las normas y los reglamentos que debe cumplir el equipo radioeléctr ico; 
—  la presentación de los Datos al equipo de la Comunicación; 
—  los procedimiento s de consulta y transfer encia y la secuencia de las operaciones; 
—  los Datos que deben transferi rse; 
—  la posible interpretaci ón de los Datos transfe ridos a través de la Comunicación; 
—  las disposiciones de los datos de segur idad relativas a la Comunicación; 26.5.2016 L 139/451 Diar io Oficial de la Unión Europea ES    
—  la disponibilidad de los Datos para las autoridades de control compet entes; 
—  el modo en que el lector de comunicación de teledetección tempr ana puede solicitar distintos tipos de datos sobre 
la carg a y la flota. 
A efectos de aclaración, este apéndice no especifi ca: 
—  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 especifi que de otro modo en el Reglamento (UE) no 165/2014); 
—  la forma de presentar los datos recabados al agent e de las autoridades de control compe tent es, ni los 
criterios que aplicarán las autori dades de control compet entes para decidir qué vehículos deben detenerse (lo 
que dependerá del diseño del product o a menos que se especifique de otro modo en el Reglamento (UE) no 
165/2014 o en una decisión política de las autori dades de control compet entes); a efectos de aclaración: la 
Comunicación se limita a poner los Datos a disposición de las autor idades de control compet entes para que 
estas puedan tomar decisiones bien fundadas; 
—  las disposiciones sobre segur idad de los datos (como el cifrado) relativas a los Datos (que se especifi carán en 
el apéndice 11, «Mecanismos de segur idad comunes»); 
—  detalles de cualquier tipo de datos distintos de RTM que puedan obte nerse con la misma arquit ectura y 
equipo; 
—  detalles del compo rtamient o y la gestión entre la VU y la DSR C-VU, o el compo rtamient o dentro de la 
DSR C-VU (al margen del suministro de los Datos cuando los solicite un REDCR). 
3  ACRÓNIMOS, DEFINICIONES Y ANOT ACIONES 
Los siguiente s acrónimos y definiciones son específi cos del present e apéndice y se utilizan como se indica a 
continuación: 
Antena  Un dispositivo eléctr ico que convier te la energía eléctr ica en ondas de radio 
y viceversa que se utiliza con un radiotransmisor o un radior recep tor. 
Cuando está en funcionamient o, un radiotransmisor suministra una 
corriente eléctr ica que oscila a una determi nada radiofrecuencia hasta los 
term inales de la antena y la antena irradia la energía de la corriente en forma 
de ondas electromagnéticas (ondas de radio). Durant e 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 term inales que se aplica a un recep tor para 
ampli ficarlo. 
Comunicación  El intercambio de información o datos entre un DSR C-REDCR y una DSR C- 
VU conf orme a lo dispuest o en la sección 5 estableciéndose una relación 
maestro-esclav o para obtener los datos. 
Datos  Los datos prote gidos en un formato definido (véase el apar tado 5.4.4) 
solicitados por el DSRC-REDCR y facilitados al DSRC-REDCR por la DSRC- 
VU a través de un enlace DSR C de 5,8 GHz definido en la sección 5. 
Regl amento (CE) no 165/2014  El Reglamento (UE) no 165/2014 del Parlamento Europeo y del Consejo, de 
4 de febrero de 2014, relativ o a los tacógraf os en el transpor te por carretera, 
por el que se derog a el Reglamento (CEE) no 3821/85 relativ o al aparat o de 
control en el sector de los transpor tes por carretera y se modifi ca el 
Reglamento (CE) no 561/2006 del Parlament o Europeo y del Consejo 
relativ o a la armonización de deter minadas disposiciones en mater ia social 
en el sector de los transpor tes por carretera. 
AID  Identif icador de aplicación 
BLE  Bluetooth de baja energía 
BST  Tabla de servicios de la baliza 26.5.2016 L 139/452 Diar io Oficial de la Unión Europea ES    
CIWD  Inserción de tarjeta durante la conducción 
CRC  verificación por redundancia cíclica 
DSC (n)  identif icador de un requisit o para un apéndice DSR C específi co 
DSR C  Dedicat ed Shor t Range Communication 
DSR C-REDCR  DSR C — lector de comunicación de teledet ección temprana. 
DSR C-VU DSR C — Unidad instalada en el vehículo. Se trata del «dispositiv o de telede ­
tecci ón temprana» definido en el anex o 1C. 
DWV C  Conducción sin tarjeta válida 
EID  Identif icador 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  Lect or de comunicaciones de teled etección temprana. Se trata del «lect or de 
comunicación de teled etección temprana» definido en el anex o 1C. 
RTM  Super visión a distancia de tacógraf os 
SM-REDCR  Módulo de segur idad-lector de comunicaciones de teled etección temprana 
TARV  Aplicaciones telemáticas para vehículos regulados (serie de normas ISO 
15638) 
VU  Unidad instalada en el vehículo 
VUPM  Memor ia útil de la unidad instalada en el vehículo 
VUSM  Módulo de segur idad de la unidad instalada en el vehículo 
VST  Tabla de servicios del vehículo 
WIM  Pesaje en movimiento 
WOB  Pesaje a bordo 
La especifi cación definida en este apéndice se refie re y depende de la totali dad o de distintas partes de los 
reglamentos y normas siguient es. En las cláusulas del present e 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 
present e apéndice. En el caso de que exista alguna contradicción sin aclarar por alguna especificación en el 
present e 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 prefe rencia 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) no 165/2014 del Parlamento Europeo y del Consejo, de 4 de febrero de 2014, relativ o a 
los tacógraf os en el transpor te por carretera, por el que se derog a el Reglamento (CEE) no 3821/85 relativo 
al aparat o de control en el sector de los transpor tes por carretera y se modifi ca el Reglamento (CE) no 
561/2006 del Parlamento Europeo y del Consejo relativ o a la armonización de determinadas disposiciones 
en mater ia social en el sector de los transpor tes por carretera. 26.5.2016 L 139/453 Diar io Oficial de la Unión Europea ES    
[2] Reglamento (UE) no 561/2006 del Parlamento Europeo y del Consejo, de 15 de marzo de 2006, relativ o a 
la armonización de determinadas disposiciones en mater ia social en el sector de los transpor tes por 
carretera y por el que se modif ican los Reglamentos (CEE) no 3821/85 y (CE) no 2135/98 del Consejo y se 
deroga el Reglamento (CEE) no 3820/85 del Consejo (Texto pertinente a efectos del EEE).  
[3] ERC 70-03 CEPT : ECC Recommendation 70-03: Relating to the Use of Shor t Range Devices (SRD)  
[4] ISO 15638 Intellig ent transpor t systems — Framew ork for cooperative telematics applications for 
regulated commercial freight vehicles (TARV).  
[5] EN 300 674-1 Compa tibilidad electromagnética y temas del espectro de radio (ERM); Telemática para el 
tráfico y el transpor te por carretera (RTTT); Equipos de transmission (500 kbit/s / 250 kbit/s) operando en 
la banda industr ial, científica y médica (ISM) de 5,8 GHz en comunicaciones dedicadas de corto alcance 
(DSR C); Parte 1: Caract erísticas general es y métodos de ensa yo 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 transpor te por carretera (RTTT). Comunicaciones dedicadas de 
corto alcance (DSR C). Capa física utilizando microondas a 5,8 GHz.  
[7] EN 12795 Telemática aplicada al tráfico y al transpor te por carretera. Comunicaciones dedicadas de corto 
alcance (DSR C). Capa de enlace de datos DSR C: Control de acceso al medio y control lógico de enlace.  
[8] EN 12834 Telemática para el tráfico y el transpor te por carretera (RTTT). Comunicaciones dedicadas de 
corto alcance (DSR C) — Capa de aplicación.  
[9] EN 13372 Telemática para el tráfico y el transpor te por carretera (RTTT). Comunicaciones dedicadas de 
corto alcance (DSR C). Perfiles para aplicaciones RTTT .  
[10] ISO 14906 Sistem a de telepago. Definición de la interfaz de la capa de aplicación para comunicaciones 
dedicadas de corto alcance. 
4  ESCENARIOS OPERA TIVOS 
4.1  Resumen 
El Reglamento (UE) no 165/2014 contem pla escenar ios específicos y controlados en los que debe utilizarse la 
Comunicación. 
Los escenar ios cont emplados son: 
«Perfil de comunicación 1: Control en carreter a utilizando un lector de teledetección tempr ana mediante comunicación 
inalámbr ica de corto alcance para proceder a un contro l físico en carreter a (maestro-:-es clavo) 
Perfil de lector 1a: a través de un lector de comunicaciones de teledetección tempr ana apuntado manualmente o instalado 
provisio nalmente junto a la carreter a y apuntado 
Perfil de lector 1b: a través de un lector de comunicaciones de teledetección tempr ana instalado en un vehíc ulo y dirigido». 
4.1.1  Condiciones previas a la transferencia de datos mediante una inter faz DSRC de 5,8 GHz 
NOT A: a fin de entender el conte xto 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 DSR C. El medio para realizar esta operación se 
encuentra en el interior de la VU, especifi cado en el Reglamento (UE) no 165/2014, anex o 1C, sección 
3.19, «Comunicación a distancia para controles de carreter a selectiv os», y no se especifica en el present e 
apéndice. 26.5.2016 L 139/454 Diar io Oficial de la Unión Europea ES    
4.1.1.2  Datos suministrados al equipo DSR C-VU 
DSC_13  La VU se ocupará de actualizar los datos del tacógraf o DSR C (los Datos) siempre que los datos 
almacenados en la VU se actualicen en el intervalo especifi cado en el apar tado 4.1.1.1 (DSC_12), sin 
la inter vención de la función de comunicación DSR C. 
DSC_14  Los datos de la VU servirán de base para compl etar y actualizar los Datos. El medio para realizar esta 
operación se especifi ca en el anex o 1C, sección 3.19, «Comunicación a distancia para contro les de carretera 
selectiv os», y, de no existir dicha especificación, dependerá del diseño del product o y no se especifi ca en 
este apéndice. En cuanto al diseño de la conexión entre el equipo DSR C-VU y la VU, consúlt ese la 
sección 5.6. 
4.1.1.3  Conte nido de los datos 
DSC_15  El contenido y el format o de los Datos deberán permitir que, una vez descifrados, se estructuren y se 
pongan a disposición del modo y con el format o especifi cados en el apar tado 5.4.4 del present e 
apéndice (Estr ucturas de los datos). 
4.1.1.4  Presentación de los datos 
DSC_16  Los Datos, habiéndose actualizado frecuentem ente conf orme a los procedimiento s establecidos en el 
apar tado 4.1.1.1, se proteg erán antes de su presentación a la DSRC-VU y se presentarán como un 
valor concep tual de datos seguros, para su almacenamiento temporal en la DSRC-VU como versión 
actual de los Datos. Estos datos se transf ieren del VUSM a la función VUPM de DSR C. El VUSM y la 
VUPM son funciones y no necesar iament e entidades físicas. La forma de instanciación física para 
realizar estas funciones dependerá del diseño del product o, a menos que se especifique de otro modo 
en el Reglamento (UE) no 165/2014. 
4.1.1.5  Datos de segur idad 
DSC_17  Los datos de segur idad (secur ityData), 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 segur idad comunes», y se presentarán como un valor concep tual de datos, para su 
almacenamient o temporal en la DSRC-VU como versión actual de secur ityData, de la forma establecida 
en el apar tado 5.4.4 del present e apéndice. 
4.1.1.6  Datos de la VUPM disponibles para su transferencia a través de la interf az DSR C 
DSC_18  El concept o de datos que deberá estar siempre disponible en la función VUPM de DSR C para su 
transfer encia inmediata tras ser solicitados por el REDCR se define en el apar tado 5.4.4 para todas las 
especificaciones del módulo ASN.1. 
Descr ipción general del perf il de comunicación 1 
Este perf il contem pla el ejemplo de uso en el que un agente de las autoridades de control compet entes utiliza 
un lector de comunicaciones de teledet ección temprana (interfaces DSR C 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 descr ibe en el apar tado 5) (el 
REDCR) para identif icar a distancia un vehículo que pueda haber infringido el Reglamento (UE) no 165/2014. 
Una vez identificado, el agente de las autori dades de control compet entes 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 tempr ana apuntado manualmente o instalado provisio ­
nalmente junto a la carreter a y apuntado 
En este ejemplo de uso, el agente de las autori dades de control compe tent es 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 parabr isas del vehículo seleccionado. La interr ogación se realiza mediante interfaces DSR C 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 descr ito en el apar tado 5. Véase la figura 14.1 (Ejem plo de uso 1). 26.5.2016 L 139/455 Diar io Oficial de la Unión Europea ES    
Figura 14.1 
Inter rogación en carretera mediante DSR C de 5,8 GHz 
4.1.3  Perfil 1b: mediante un lector de comunicaciones de teledetección tempr ana (REDCR) instalado en un vehículo y dirigido 
En este ejemplo de uso, el agente de las autori dades de control compet entes se encuentra en un vehículo en 
movimient o y, o bien apunta un REDCR manual portátil desde el vehículo hacia el centro del parabr isas del 
vehículo seleccionado, o bien el REDCR va montado en el interi or o sobre el vehículo para apuntar hacia el 
centro del parabr isas del vehículo seleccionado cuando el vehículo del lector de comunicaciones de teledet ección 
temprana se encuentra en una posición deter minada con relación al vehículo seleccionado (por ejemplo, 
directament e delante en un flujo de tráfico). La interr ogaci ón se realiza mediante interfaces DSR C 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 descr ito 
en la sección 5. Véase la figura 14.2. (Ejem plo de uso 2). 
Figura 14.2 
Inter rogación basada en vehículo mediante DSR C de 5,8 GHz (idem) 
4.2  Segur idad/Integ ridad 
Para poder verificar la autenticidad y la integridad de los datos transferi dos 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, «Mecanismos de 
segur idad comunes». 
5  DISEÑO Y PROTOCOL OS DE COMUNICA CIÓN A DIST ANCIA 
5.1  Diseño 
El diseño de la función de comunicación a distancia del tacógraf o inteli gent e es el descr ito en la figura 14.3. 26.5.2016 L 139/456 Diar io Oficial de la Unión Europea ES    
Figura 14.3 
Diseño de la función de comunicación a distancia 
DSC_19  Las funciones siguiente s van incor poradas a la VU: 
—  Módulo de segur idad (VUSM). Esta función incor porada a la VU se ocupa de proteg er los Datos 
que se van a transmitir desde la DSRC-VU hasta el agent e de las autori dades compet entes 
mediante comunicación a distancia. 
—  Los datos protegidos se almacenan en la memor ia VUSM. A los inter valos establecidos en el 
apar tado 4.1.1.1 (DSC_12), la VU cifra y repone el concep to RTMdata (que comprende valores 
concep tuales de datos útiles y datos de segur idad especificados más adelante en este apéndice) 
alojado en la memor ia de la DSR C-VU. El funcionamient o del módulo de segur idad se define en el 
apéndice 11, «Mecanismos de segur idad comunes», y queda fuera del ámbito del present e apéndice, 
su bien será necesar io para realizar las actualizaciones del equipo de comunicación de la VU cada 
vez que cambien los datos del VUSM. 
—  La comunicación entre la VU y la DSR C-VU puede ser una comunicación por cable o una 
comunicación por Bluetooth de baja energía (BLE) y físicamente la DSR C-VU puede ir integrad a 
con la antena en el parabr isas del vehículo, estar dentro de la VU o colocada en algún lugar 
intermedio. 
—  La DSR C-VU dispondrá de una fuent e 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 memor ia de la DSR C-VU no será volátil, con el fin de manten er los datos en la DSR C-VU 
incluso con el vehículo apaga do. 
—  Si la comunicación entre la VU y la DSR C-VU se realiza mediante BLE y la fuente de alimentación 
es una bate ría no recargable , se sustituirá la fuente de alimentación de la DSR C-VU en cada 
inspección periódica y el fabricante del equipo DSR C-VU será responsable de garantizar que la 
alimentación sea suficiente para que dure de una inspección periódica a la siguiente , manten iendo 
el acceso normal a los datos mediante un REDCR durante todo el periodo sin fallos ni interr up­
ciones. 26.5.2016 L 139/457 Diar io Oficial de la Unión Europea ES    
—  Equipo de «memor ia útil» de VU RTM (VUPM). Esta función integrada en la VU se encarga de 
suministrar y actualizar los Datos. El conteni do de los Datos («TachographP ayload») se define más 
abaj o en 5.4.4/5.4.5 y se actualiza según el inter valo establecido en el apar tado 4.1.1.1 (DSC_12). 
—  DSR C-VU. Esta es la función, dentro de la antena o conectada a ella y en comunicación con la VU 
a través de una conexión por cable o inalámbr ica (BLE), que aloja los datos actuales (datos VUPM) 
y gestiona la respuesta a una interr ogaci ón por medio de DSR C de 5,8 GHz. La desconexión del 
equipo DSR C o la interf erencia con el funcionamiento del equipo DSR C durante la utilización 
normal del vehículo se considerarán una infracción del Reglamento (UE) no 165/2014. 
—  El módulo de segur idad (REDCR) (SM-REDCR) constituye la función que se utiliza para descifrar y 
compr obar 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 segur idad comunes», y no se define en este apéndice. 
—  La función del equipo DSR C (REDCR) (DSRC-REDCR) compre nde un transcept or de 5,8 GHz y el 
correspondiente firmware y software para gestionar la Comunicación con la DSRC-VU de 
conf ormidad con el present e 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 DSR C y procesa y almacena los 
datos recibidos en su SM-REDCR. 
—  La antena de la DSRC-VU se colocará en una posición en la que optimice la comunicación DSR C 
entre el vehículo y la antena del lado de la carretera (en general, en el centro o cerca del centro del 
parabr isas del vehículo). En vehículos ligeros, puede instalarse perfectamente en la parte super ior 
del parabr isas. 
—  No habrá objeto s metálicos (por ejem plo, insignias, pegatinas, bandas antir reflectantes 
(tintadas), parasoles, limpiaparabr isas en reposo) delante o cerca de la antena que puedan 
interfer ir en la comunicación. 
—  La antena se instalará de manera que su alineación óptica quede apro ximadamente paralela a la 
superf icie de la carretera. 
DSC_20  La Ante na 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 descr ito en la sección 5. La Antena y la Comunicación 
pueden incor porar técn icas para atenuar el riesgo de interfe rencias inalámbr icas según se descr ibe en 
el informe ECC 228 mediante el uso, por ejemplo, de filtros en la comunicación CEN DSR C 5,8 GHz. 
DSC_21  La antena DSR C se conectará al equipo DSR C-VU de forma directa dentro del módulo instalado en el 
parabr isas o cerca de este o mediante un cable específi co fabricado de modo que dificulte su 
desconexión ilegal. La desconexión o interferencia con el funcionamient o de la Antena constituirá una 
infracción del Reglamento (UE) no 165/2014. El enmascaramiento intencionado o perjudicial para el 
funcionamient o de la Antena constituirá una infracción del Reglamento (UE) no 165/2014. 
DSC_22  El factor de forma de la antena no se define y constituirá una decisión comercial, siempr e que la 
DSR C-VU instalada cumpla los requisitos de conf ormidad establecidos en la sección 5. La antena se 
colocará del modo establecido en DSC_19 e indicado en la figura 14.4 (línea ovalada) y responderá de 
manera eficaz a los ejem plos de uso descr itos en los apar tados 4.1.2 y 4.1.3. 26.5.2016 L 139/458 Diar io Oficial de la Unión Europea ES    
Figura 14.4 
Ejemplo de colocación de la antena DSR C de 5,8 GHz en el parabr isas 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 compet entes. 
Se utiliza una función de visualización o notifi cación para mostrar los resultados de la función de 
comunicación a distancia al agente de las autoridades de control compet entes. El modo de visualización puede 
ser una pantalla, una impresión en papel, una señal acústica o una combinación de las mismas. Esta forma de 
visualización o notifi cación depende de las necesidades de los agentes de las autori dades de control compet entes 
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 rendimient o que se definen en este apéndice (apar tado 5.3.2), por lo 
que el mercado dispone de la máxima flexibilidad para diseñar y suministrar equipos que abarquen los 
supuest os específic os de interr ogaci ón de cualquier autori dad de control compet ente. 
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 especifi caciones de diseño y rendimient o definidas 
en este apéndice (apar tado 5.3.2) y en la presente sección (5.1). 
DSC_25  No obstante , la DSRC-VU será razonablement e capaz de acept ar valores concept uales de datos de 
otros equipos intelig entes de vehículos a través de una conexión y unos protocolo s abier tos y 
normalizados del sector (por ejemplo, de equipos de pesaje de a bordo), siempre que estos concept os 
de datos sean identificados mediante identif icadores de aplicación o nombres de arch ivo únicos y 
conocidos y se facilit en a la Comisión Europea las instr ucciones para manejar estos protocolo s y estén 
disponibles sin coste para los fabr icante s de los equipos pertinentes. 
5.2  Flujo de trabajo 
5.2.1  Oper aciones 
En la figura 14.5 se representa el flujo de traba jo de las operaciones. 26.5.2016 L 139/459 Diar io Oficial de la Unión Europea ES    
Figura 14.5 
Flujo de trabajo de la función de comunicación a dist ancia 
Los pasos se descr iben a continuación: 
a.  Siempre que el vehículo esté en march a (el encendido conectado), el tacógraf o 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 memor ia de la DSRC-VU (tal y como se define en los apar tados 4.1.1.1 — 4.1.1.2). Los Datos 
obtenid os se formatean del modo establecido en los apar tados 5.4.4 — 5.4.5. 26.5.2016 L 139/460 Diar io Oficial de la Unión Europea ES    
b.  Cada vez que se actualizan los Datos, se actualiza la indicación temporal definid a en el concept o de datos de 
segur idad. 
c.  La función VUSM proteg e los datos conf orme a los procedimiento s establecidos en el apéndice 11. 
d.  Cada vez que se actualizan los Datos (véanse los apar tados 4.1.1.1 — 4.1.1.2), los Datos se transf ieren a la 
DSRC-VU, donde sustituy en a los datos anteriores de modo que siempr e haya datos actualizados (los Datos) 
que suministrar en caso de que se produzca una interrogación por parte de un REDCR. Cuando la VU 
suministre los Datos al DSR C-VU, los datos podrán identificarse por el nombre del archiv o RTMData o por 
los identificad ores de aplicación y de atribut os. 
e.  Si un agente de las autoridades de control compe tent es decide seleccionar un vehículo y recabar los Datos de 
ese vehículo específi co, el agente de las autoridades de control compet entes introducirá primero su tarjeta 
inteli gent e en el REDCR para habilitar la Comunicación y para que el SM-REDCR pueda verificar su 
autenti cidad y descifrar los datos. 
f.  A continuación, el agente de las autori dades de control compet entes selecciona un vehículo y solicita los 
datos mediante comunicación a distancia. El REDCR abre una sesión de interf az de DSR C 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 comunicación inalámbr ica como atributo DSR C empleando el servicio de aplicaciones GET 
definido en la sección 5.4. El Atribut o contiene los valores de los datos útiles cifrados y los datos de 
segur idad de DSR C. 
g.  Los datos son analizados por el equipo REDCR y suministrados al agent e de la autoridad de control 
compet ente. 
h.  El agent e de la autori dad de control compet ente utiliza los datos para decidir si detiene o no el vehículo con 
el fin de realizar una inspección minuciosa o solicita a otro agent e de la autori dad de control compet ente 
que detenga el vehículo. 
5.2.2  Inter pretación de los datos recibidos a través de la comunicación DSRC 
DSC_26  Los datos recibidos a través de la interf az de 5,8 GHz llevarán el significado y la importancia definidos 
en los apar tados 5.4.4 y 5.4.5, y solo esos, y se entenderán únicamente en el marco de los objetivos 
aquí definidos. De conf ormidad con las disposiciones del Reglamento (UE) no 165/2014, los Datos se 
utilizarán excl usivamente para facilitar información pertinente a una autor idad de control compet ente 
para poder deter minar qué vehículo debe detener para realizar una inspección física y, posterior mente, 
se destr uirán conf orme a lo dispuesto en el artículo 9 del Reglamento (UE) no 65/2014. 
5.3  Parámetros de la interf az física de DSR C para comunicación a distancia 
5.3.1  Limitaciones de posición 
DSC_27  La interrogación a distancia de vehículos mediante una interf az DSR C de 5,8 GHz no debe utilizarse a 
menos de 200 metros de un pórtico DSR C de 5,8 GHz en funcionamient o. 
5.3.2  Parámetr os de los enlaces ascendente y descendente 
DSC_28  El equipo emplea do para la super visión a distancia de tacógraf os se ajustará y funcionará con arreglo a 
ERC 70-03 y a los parámetros establecidos en los cuadros 14.1 y 14.2. 26.5.2016 L 139/461 Diar io Oficial de la Unión Europea ES    
DSC_29  Asimismo, con el fin de garan tizar la compati bilidad con los parámetros operativos de otros sistemas 
normalizados DSR C de 5,8 GHz, el equipo emple ado para la super visión a distancia de tacógraf os se 
ajustará a los parámetros que establecen EN 12253 y EN 13372. 
A saber : 
Cuadr o 14.1 
Parámetros de enlace descendente 
No de 
element o Parámetro Valor(es) Obser vación 
D1 Frecuencias portadoras 
del enlace descendente Exist en cuatro altern ativas 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 seleccionar las 
frecuencias portadoras del sistema de 
carretera y no tienen por qué conocerse 
en la DSR C-VU 
(Conf orme a EN 12253, EN 13372) 
D1a (*) Tolerancia de las fre­
cuencias portadoras Dentro de ± 5 ppm (Conf orme 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 requisito especí ­
fico dentro de este anex o Parámetro utilizado para controlar las 
interfe rencias entre los interro gadores 
en proximidad (como se define en EN 
12253 y EN 13372) 
D3 Rango mínimo de fre­
cuencias de la OBU 
(DSR C-VU) 5,795 — 5,815 GHz (Conf orme a EN 12253) 
D4 (*) E.I.R.P . máxima Dentro de ERC 70-03 (sin licencia) 
dentro de la normativa regional 
Máximo +33 dBm (Conf orme a EN 12253) 
D4a Máscara de E.I.R.P . an­
gular Según la especificación declarada y pu­
blicada por el diseñador del interroga ­
dor (Conf orme a EN 12253) 
D5 Polar ización Circular a izquierdas (Conf orme a EN 12253) 
D5a Polar ización cruzada XPD: 
En la dirección de máxima radiación: 
(REDCR) RSU t ≥ 15 dB 
(DSR C-VU) OBU r ≥ 10 dB 
En un área a -3 dB: (REDCR) RSU t ≥ 
10 dB 
(DSR C-VU) OBU r ≥ 6 dB (Conf orme a EN 12253) 
D6 (*) Modulación Modulación en amplit ud de dos nive ­
les. (Conf orme a EN 12253) 
D6a (*) Índice de modulación 0,5 … 0,9 (Conf orme a EN 12253) 26.5.2016 L 139/462 Diar io Oficial de la Unión Europea ES    
No de 
element o Parámetro Valor(es) Obser vación 
D6b Patrón ocular ≥ 90 % (tiempo) / ≥ 85 % (ampli tud)  
D7 (*) Codif icación de datos FM0 
El bit «1» tiene transiciones solo al co­
mienzo y al final del inter valo de bits. 
El bit «0» tiene una transición adicional 
en mitad del inter valo de bits en com ­
paración con el bit «1». (Conf orme a EN 12253) 
D8 (*) Velocidad binar ia 500 kbit/s (Conf orme a EN 12253) 
D8a Tolerancia del reloj de 
bit super ior a ± 100 ppm (Conf orme a EN 12253) 
D9 (*) Tasa de error de bit (B. 
E.R.) para comunicación ≤ 10 -6 cuando la potencia incidente en 
la OBU (DSR C-VU) está en el rango 
dado por [D11a a D11b] (Conf orme a EN 12253) 
D10 Proceso de desper tar a 
la OBU (DSR C-VU) La OBU (DSR C-VU) desper tará al reci­
bir una trama con 11 o más octetos 
(incluido el preámbulo) No se precisa ningún patrón de activa ­
ción especial 
La DSR C-VU puede despar tarse al reci­
bir una trama con menos de 11 octetos 
(Conf orme a EN 12253) 
D10a Tiempo de comienzo 
máximo ≤ 5 ms (Conf orme 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 (Conf orme a EN 12253) 
D11a (*) Límit e super ior de po­
tencia en la zona de co­
municación – 24 dBm (Conf orme a EN 12253) 
D11b (*) Límit e infer ior de poten ­
cia en la zona de comu ­
nicación Potencia incident e: 
– 43 dBm (dirección de máxima radia ­
ción) 
– 41 dBm (dentro de – 45° ± 45° res­
pect o del plano paralelo a la superf icie 
de la carretera cuando la DSR C-VU se 
instala posterio rmente en el vehículo 
(acimut)) (Conf orme a EN 12253) 
Requisito amplia ndo para ángulos hori­
zontales hasta ± 45°, debido a los casos 
de uso definidos en este anex o. 
D12 (*) Nivel de poten cia de 
corte de la OBU (DSR C- 
VU) – 60 dBm (Conf orme a EN 12253) 
D13 Preámbulo Preámbulo oblig atori o (Conf orme a EN 12253) 
D13a Longitud y patrón del 
preámbulo 16 bits ± 1 bit de bits «1» FM0 codifi ­
cados (Conf orme a EN 12253) 26.5.2016 L 139/463 Diar io Oficial de la Unión Europea ES    
No de 
element o Parámetro Valor(es) Obser vación 
D13b Forma de onda del 
preámbulo Una secuencia altern ativa de niveles 
bajos y altos con una duración de 
pulso de 2 µs 
La tolerancia viene dada por D8a (Conf orme a EN 12253) 
D13c Bits de cola A la RSU (REDCR) se le permite trans ­
mitir un máximo de 8 bits después del 
indicador de final. Para la OBU (DSR C- 
VU) no es necesar io tener en cuenta es­
tos bits adicionales. (Conf orme a EN 12253) 
(*)Los parámetros de enlace descendente están sujetos a las pruebas de conf ormidad de acuerdo con la prueba de parámetros perti­
nente de EN 300 674-1  
Cuadr o 14.2 
Parámetros de enlace ascendente 
No de 
element o Parámetro Valor(es) Obser vación 
U1 (*) Frecuencias de la sub­
portadora La OBU (DSR C-VU) debe sopor tar 
1,5 MHz y 2,0 MHz 
La RSU (REDCR) debe sopor tar 
1,5 MHz o 2,0 MHz o ambos. U1-0: 
1,5 MHz U1-1: 2,0 MHz Selección de frecuencia subpor tadora 
(1,5 MHz o 2,0 MHz) dependiendo del 
perf il EN 13372 elegido. 
U1a (*) Tolerancia de las fre­
cuencias de la supor ­
tadora dentro de ± 0,1 % (Conf orme a EN 12253) 
U1b Uso de bandas later ales Los mismos datos en ambas bandas (Conf orme a EN 12253) 
U2 (*) Máscara de espectro de 
la OBU transmisora 
(DSR C-VU) Conf orme a EN12253 
1)  Potencia fuera de la banda: 
véase ETSI EN 300674-1 
2)  Potencia en la banda: 
[U4a] dBm en 500 kHz 
3)  Emisiones en cualquier otro canal 
de enlace ascendente: 
U2(3)-1 = – 35 dBm en 500 kHz (Conf orme a EN 12253) 
U4a (*) E.I.R.P . máxima de 
banda later al única (ali­
neación óptica) Dos opciones: 
U4a-0: – 14 dBm 
U4a-1: – 21 dBm Según la especific ación declarada y pu­
blicada por el diseñador del equipo 
U4b (*) E.I.R.P . máxima de 
banda later al única (35°) Dos opciones: 
—  No aplicable 
—  – 17 dBm Según la especific ación declarada y pu­
blicada por el diseñador del equipo 
U5 Polar ización Circular a izquierdas (Conf orme a EN 12253) 26.5.2016 L 139/464 Diar io Oficial de la Unión Europea ES    
No de 
element o Parámetro Valor(es) Obser vación 
U5a Polar ización cruzada XPD: 
En la dirección de máxima radiación: 
(REDCR) RSU r ≥ 15 dB 
(DSR C-VU) OBU t ≥ 10 dB 
A -3 dB: (REDCR) RSU r ≥ 10 dB 
(DSR C-VU) OBU t ≥ 6 dB (Conf orme a EN 12253) 
U6 Modulación de la sub­
portadora 2-PSK 
Datos codificados sincronizados con la 
subpor tadora: las transiciones de los 
datos codificado s coinciden con las 
transiciones de la subpor tadora (Conf orme a EN 12253) 
U6b Ciclo de trabajo Ciclo de traba jo: 
50 % ± α, α ≤ 5 % (Conf orme a EN 12253) 
U6c Modulación de la porta­
dora Multiplicación de la subpor tadora mo­
dulada con la portadora. (Conf orme a EN 12253) 
U7 (*) Codif icació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) (Conf orme a EN 12253) 
U8 (*) Velocidad de bit 250 kbit/s (Conf orme a EN 12253) 
U8a Tolerancia del reloj de 
bit Dentro de los ± 1 000 ppm (Conf orme a EN 12253) 
U9 Tasa de error de bit (B. 
E.R.) por comunicacio ­
nes ≤ 10– 6 (Conf orme a EN 12253) 
U11 Zona de comunicacio ­
nes La región espacial en la que se sitúa la 
DSR C-VU de tal forma que sus trans ­
misiones sean recibidas por el REDCR 
con una B.E.R. inferior a la dada por 
U9a. (Conf orme a EN 12253) 
U12a (*) Ganancia de conver sión 
(límiter inferior ) 1 dB por cada banda lateral Rango del 
ángulo: circular mente simétr ico alrede ­
dor de la dirección de máxima radia ­
ción y ± 35° 
y  
dentro de – 45° — + 45° respecto del 
plano paralelo a la superf icie de la ca­
rretera cuando la DSR C-VU se instala 
poste riormente en el vehículo (acimut)) Super ior al rango de valores especifi ­
cado para los ángulos horizontales hasta 
± 45°, debido a los casos de uso defini ­
dos en este anex o. 
U12b (*) Ganancia de conver sión 
(límite super ior) 10 dB por cada banda lateral Inferior al rango de valores especificado 
para cada banda lateral dentro de un 
cono circular alrededor de la dirección 
de máxima radiación del ± ángulo de 
aper tura de 45° 
U13 Preámbulo Preámbulo oblig atori o (Conf orme a EN 12253) 26.5.2016 L 139/465 Diar io Oficial de la Unión Europea ES    
No de 
element o Parámetro Valor(es) Obser vación 
U13a Preámbulo 
Longitud y patrón de 32 a 36 µs modulado solamente 
con la subpor tadora, luego 8 bits de 
«0» codificados NRZI (Conf orme a EN 12253) 
U13b Bits de cola La DSR C-VU puede transmitir un má­
ximo de 8 bits tras el indicador de fi­
nal. La RSU (REDCR) no necesita tener 
en cuenta estos bits adicionales. (Conf orme a EN 12253) 
(*)– Los parámetros de enlace ascendent e están sujeto s a las pruebas de conf ormidad de acuerdo con la prueba de parámetros perti­
nente de EN 300 674-1  
5.3.3  Diseño de la antena 
5.3.3.1  Ante na REDCR 
DSC_30  El diseño de la antena REDCR dependerá del diseño comercial, ajustándose a los límites establecidos 
en el apar tado 5.3.2, que se ha adap tado para optimizar el rendimiento de lectura del DSRC-REDCR 
para el fin específi co y las circunstancias de lectura en las que está previsto que funcione el REDCR. 
5.3.3.2  Ante na VU 
DSC_31  El diseño de la antena DSRC-VU dependerá del diseño comercial, ajustándose a los límite s establecidos 
en el apar tado 5.3.2, que se ha adap tado para optimizar el rendimiento de lectura del DSRC-REDCR 
para el fin específi co y las circunstancias de lectura en las que el REDCR está previsto que funcione. 
DSC_32  La antena VU se instalará en el parabr isas delanter o o cerca del parabr isas delanter o del vehículo del 
modo especifi cado 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 DSR C-VU, instalada 
conf orme a la sección 5.1, se conectará correctamente mediante una comunicación de ensa yo estándar 
y permitirá realizar satisfact oriament e una transacción RTM del modo definido en este apéndice, a una 
distancia de entre 2 y 10 metros, durant e un tiempo super ior al 99 % y con un promedio super ior a 
1 000 interr ogaciones de lectura. 
5.4  Requisit os del prot ocolo DSR C para RTM 
5.4.1  Resumen 
DSC_34  El protocolo de transacciones para descarg ar los Datos a través del enlace de interfaz DSR C de 
5,8 GHz se ajus tará a los pasos indicados a continuación. Este apar tado descr ibe un flujo de transac ­
ciones en condiciones ideales sin retransmisiones ni interr upciones de la comunicación. 
NOT A La finalidad de la fase de inicialización (paso 1) es conf igurar la comunicación entre el REDCR 
y las DSR C-VU que hayan entrado en la zona de transacción (maestro-esclav o) DSR C 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 1Inicialización. El REDCR envía una trama que contiene una «tabla de servicios de la baliza» 
(BST) que incluye los identif icadores de aplicación (AID) en la lista de servicios que admit e. En la 
aplicación RTM, consistirá simplemente en el servicio con el valor AID = 2 (carg a y flota). La 
DSRC-VU evalúa la BST recibida y responde (véase a continuación) con la lista de las aplicaciones 
compati bles dentro del dominio de carga y flota o no responde en caso de que ninguna sea 
compati ble. Si el REDCR no ofrece AID = 2, la DSR C-VU no responderá al REDCR. 26.5.2016 L 139/466 Diar io Oficial de la Unión Europea ES    
— Paso 2La DSRC-VU enví a una trama que contiene la solicitud de asignación de ventana privada.  
— Paso 3El REDCR envía una trama que contiene una asignación de ventana privada.  
— Paso 4La DSRC-VU utiliza la ventana privada asignada para enviar una trama con la tabla de 
servicios del vehículo (VST). Esta VST incluy e una lista de toda s las instanciaciones diferent es de la 
aplicación que admite esta DSRC-VU en el marco de AID = 2. Las diferent es instanciaciones 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 
compati bles.  
— Paso 5A continuación, el REDCR analiza la VST que se le ofrece 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 admite la transacción RTM), o bien, si recibe una VST adecuada, inicia 
una instanciación de la aplicación.  
— Paso 6Para llevar esto a cabo, el REDCR envi ará una trama que contiene el comando de 
recuperar los datos RTM e identif ica la instanciación de la aplicación RTM al especificar el identi ­
ficador correspondiente a la instanciación de la aplicación RTM (tal como haya sido especificado 
por la DSR C-VU en la VST) y asignará una ventana privada.  
— Paso 7La DSRC-VU utiliza la ventana privada recién asignada para envi ar una trama que 
contiene el identificador direccionado correspondiente a la instanciación de la aplicación RTM tal 
como se suministró en la VST, seguido del atribut o RtmData (elemento de datos útiles + elemento 
de segur idad).  
— Paso 8Si existen varios servicios solicitados, el valor «n» cambia al siguient e número de referencia 
de servicio y se repit e el proceso.  
— Paso 9El REDCR conf irma 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 figur a 14.6 una descr ipción gráfi ca del protocolo de transacción.  26.5.2016 L 139/467 Diar io Oficial de la Unión Europea ES    
Figur a 14.6 
Flujo de procesos de RTM a trav és de una DSR C de 5,8 GHz 
26.5.2016 L 139/468 Diar io Oficial de la Unión Europea ES    
5.4.2  Comandos 
DSC_35  Los siguiente s comandos constituyen las únicas funciones utilizadas en una fase de transacción RTM.  
— INITIALIS ATION .reques t:comando, enviado desde el REDCR en forma de difusión, con la 
definición de las aplicaciones que admite el REDCR.  
— INITIALIS ATION .response: respuesta desde la DSR C-VU que conf irma la conexión y contiene 
una lista de las instancias de aplicación admitidas con las caract erísticas y la información de cómo 
direccionarlas (EID).  
— GET .reques t: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 atribut os seleccionados junto con los Datos. El 
objetivo del comando GET es que el REDCR obte nga los Datos de la DSRC-VU.  
— GET .response: respuesta de la DSR C-VU que contiene los Datos solicitados.  
— ACTION .reques t 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 
homolog ación que comprueben que el enlace DSR C funciona sin necesidad de acceder a las 
credenciales de segur idad.  
— ACTION.response ECH O:respuesta desde la DSR C VU al comando ECHO.  
— EVENT_REPORT .reques t RELEASE: comando que indica 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 interr ogación durante la conexión 
actual. Adviér tase que, según EN 12834, una DSR C-VU no se conectará dos veces con el mismo 
interrogador a no ser que haya estado fuera de la zona de comunicación durant e 255 segundos o 
se cambie el ID de la baliza del interr ogador. 
5.4.3  Secuencia de comandos de inter rogación 
DSC_36  Desde el punt o de vista de la secuencia de comandos y respuestas, la transacción se descr ibe del modo 
siguient e: 
Secuencia Emisor  Recep tor Descr ipción Acción 
1 REDCR > DSR C-VU Inicialización del enlace de co­
municación — Solicitud El REDCR difunde la BST 
2 DSRC-VU > REDCR Inicialización del enlace de comu ­
nicación — Respuesta Si la BST admite AID=2, entonces 
la DSRC-VU solicita una venta na 
privada 
3 REDCR > DSR C-VU Concede una ventana privada 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 compr ende 
una VST 
5 REDCR > DSR C-VU Envía GET .request de datos en 
el Atribut o para el EID especí ­
fico  
6 DSRC-VU > REDCR Envía GET .response con el Atri­
buto solicitado para el EID especí ­
fico Envía el atributo (DatosR TM, Da­
tosOW S…) con datos para el EID 
específic o 26.5.2016 L 139/469 Diar io Oficial de la Unión Europea ES    
Secuencia Emisor  Recep tor Descr ipción Acción 
7 REDCR > DSR C-VU Envía GET .request para datos 
de otro Atribut o (si procede)  
8 DSRC-VU > REDCR Envía GET .response con el Atri­
buto solicitado Envía el Atributo con los datos 
para el EID específico 
9 REDCR > DSR C-VU Confir ma la recepción correcta 
de los datos Envía el comando RELEASE, que 
cierra la transacció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 cont enido de las 
tramas intercambiadas. 
5.4.4  Estructur as de los datos 
DSC_37  La estructura semántica de los Datos cuando pasan por la interfaz DSR C de 5,8 GHz se ajustará a lo 
descr ito en el presente apéndice. El modo en que se estructuran estos datos se especifica en el present e 
apar tado. 
DSC_38  Los datos útiles (datos RTM) consisten en la concate nación de  
1. datos Encr yptedTachographP ayload, que constituye el cifrado de TachographP ayload definido en el 
apar tado 5.4.5 de ASN.1. El método de cifrado se descr ibe en el apéndice 11;  
2. DSR CSecur ityData, especificado en el apéndice 11. 
DSC_39  Los datos RTM se están direccionando como Atributo RTM = 1 y se transf ieren en el cont enedor RTM 
= 10. 
DSC_40  La marca conte xtual de RTM identif icará la parte estándar compatible en la serie de normas TARV 
(RTM se corresponde con la parte 9). 
La definición del módulo ASN.1 para los datos DSR C dentro de la aplicación RTM se establece del 
modo siguiente:  26.5.2016 L 139/470 Diar io Oficial de la Unión Europea ES    
26.5.2016 L 139/471 Diar io Oficial de la Unión Europea ES    
5.4.5  Elementos de RtmData, acciones realizadas y defin iciones 
DSC_41  Los valores de datos que debe calcular la VU y utilizar para actualizar los datos prote gidos en la 
DSR C-VU se calcularán de acuerdo con las reglas definidas en el cuadro 14.3: 
Cuadr o 14.3 
Element os de RtmDat a, acciones realizadas y definiciones 
(1) Elementos 
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 fijará el valor del elemento de datos RTM1 tp15638V e­
hicleRe gistr ationPlate a partir del valor registrado del tipo de da­
tos VehicleRegistr ationIdentif ication tal como se define en el 
apéndice 1, VehicleR egistr ationIdentifi cation Matrícula del ve­
hículo expresada 
como una cadena 
de caracte res 
26.5.2016 L 139/472 Diar io Oficial de la Unión Europea ES    
(1) Elementos 
de datos RTM (2) Acción realizada por la VU  (3) Definición de ASN.1 de los 
datos 
RTM2 
Incidente de 
exceso de ve­
locidad La VU generará un valor booleano para el element o de datos 
RTM2 tp15638SpeedingEvent. 
El valor tp15638SpeedingEvent deberá ser calculado por la VU 
a partir del número de incident es de exceso de velocidad regis ­
trados en la VU en los diez últimos días en que se hayan pro­
ducido incident es de este tipo, como se define en el anex o 1C. 
Si existe al menos un tp15638SpeedingEvent en los diez últi­
mos días en que se hayan producido incident es de este tipo, el 
valor tp15638SpeedingEvent deberá fijarse en VERD ADER O. 
DE LO CONTRARIO, si no existen incident es en los diez últi­
mos días en que se hayan producido incident es de este tipo, el 
valor tp15638SpeedingEvent deberá fijarse en FALSO. 1 (VERD ADER O) 
— Indica irregu ­
laridades de velo ­
cidad en los diez 
últimos días en 
que se hayan pro­
ducido incident es 
de este tipo 
RTM3 
Conducir sin 
una tarjeta vá­
lida La VU generará un valor booleano para el element o de datos 
RTM3 tp15638Dr ivingWithoutV alidCard. 
La VU deberá asignar un valor de Verdadero a la variable 
tp15638Dr ivingWithoutV alidCard si los datos de la VU regis ­
tran al menos un incident e en los diez últimos días en que se 
hayan producido incidentes del tipo «Conducir sin una tarjeta 
válida» tal como se define en el anex o 1C. 
DE LO CONTRARIO, si no existen incident es en los diez últi­
mos días en que se hayan producido incident es de este tipo, la 
variable tp15638Dr ivingWithoutV alidCard se fijará en FALSO. 1 (VERD ADER O) 
= Indica un uso 
de tarjeta no vá­
lido 
RTM4 
Tarjeta de 
conducto r vá­
lida La VU generará un valor booleano para el element o de datos 
RTM4 
tp15638Dr iverCard basándose en los datos almacenados en la 
VU y tal como se define en el apéndice 1. 
Si no hay ninguna tarjeta de conduct or válida, la VU deberá fi­
jar la variable en VERD ADER O. 
DE LO CONTRARIO, si hay una tarjeta de conduct or válida, la 
VU deberá fijar la variable en FALSO. 0 (FALSO) = In­
dica una tarjeta 
de conduct or vá­
lida 
RTM5 
Inserción de 
tarjeta du­
rante la con ­
ducción La VU generará un valor booleano para el element o de datos 
RTM5. 
La VU deberá asignar un valor de VERD ADER O a la variable 
tp15638CardInser tion si los datos de la VU registran en los 
diez últimos días en que se hayan producido incident es al me­
nos un incident e del tipo «Inserción de tarjeta durante la con­
ducción» tal y como se define en el anex o 1C. 
DE LO CONTRA RIO, si no se producen incident es en los diez 
últimos días en que se hayan producido incidentes, la variable 
tp15638CardInser tion deberá fijarse en FALSO. 1 (VERD ADER O) 
= Indica la inser ­
ción de tarjeta 
durant e la con­
ducción en los 
diez últimos días 
en que se hayan 
producido inci­
dente s 
RTM6 
Error de datos 
de movi­
mient o La VU generará un valor booleano para el element o de datos 
RTM6. 
La VU deberá asignar un valor de VERD ADER O a la variable 
tp15638MotionDataEr ror si los datos de la VU registran en los 
diez últimos días en que se hayan producido incident es al me­
nos un incident e del tipo «Error de datos de movimiento» tal y 
como se define en el anex o 1C. 
DE LO CONTRARIO, si no se ha producido ningún incident e 
de este tipo en los diez últimos días en que se hayan producido 
incident es, la variable tp15638MotionDataEr ror deberá fijarse 
en FALSO. 1 (VERD ADER O) 
= Indica error de 
datos de movi­
mient o en los 
diez últimos días 
en que se hayan 
producido inci­
dente s 
26.5.2016 L 139/473 Diar io Oficial de la Unión Europea ES    
(1) Elementos 
de datos RTM (2) Acción realizada por la VU  (3) Definición de ASN.1 de los 
datos 
RTM7 
Conf licto de 
movimiento 
del vehículo La VU generará un valor booleano para el element o de datos 
RTM7. 
La VU deberá asignar un valor de VERD ADER O a la variable 
tp15638vehicleMotionConf lict si los datos de la VU registran 
en los diez últimos días en que se hayan producido incident es 
al menos un incidente del tipo «Conf licto de movimient o del 
vehículo» (valor ‘0A’H ). 
DE LO CONTRARIO, si no existen incident es en los diez últi­
mos días en que se hayan producido incident es de este tipo, la 
variable tp15638vehicleMotionConf lict se fijará en FALSO. 1 (VERD ADER O) 
= Indica conf licto 
de movimiento 
en los diez últi­
mos días en que 
se hayan produ ­
cido incident es 
RTM8 
Tarjeta del se­
gundo con ­
duct or La VU generará un valor booleano para el element o de datos 
RTM8 basándose en el anex o 1C («Datos de actividad del con­
ductor» EQUIPO y SEGUNDO CONDUCTOR). 
Si hay una segunda tarjeta de conduct or válida, la VU deberá 
fijar la variable en VERD ADER O. 
DE LO CONTRARIO, si no ha una segunda tarjeta de conduc ­
tor válida, la VU deberá fijar la variable en FALSO. 1 (VERD ADER O) 
= Indica una se­
gunda tarjeta de 
conduct or inser ­
tada 
RTM9 
Actividad ac­
tual La VU generará un valor booleano para el element o de datos 
RTM9. 
Si la actividad actual se registra en la VU como cualquier acti­
vidad distinta de «CONDUCCIÓN» tal y como se define en el 
anex o 1C, la VU deberá fijar la variable en VERD ADER O. 
DE LO CONTRARIO, si la actividad actual se registra en la VU 
como «CONDUCCIÓN», la VU deberá fijar la variable en 
FALSO. 1 (VERD ADER O) 
= seleccionada 
otra actividad; 
0 (FALSO) = se 
ha seleccionado 
la conducción 
RTM10 
Última sesión 
cerrada La VU generará un valor booleano para el element o de datos 
RTM10. 
Si no se cerró correctamente la última sesión de la tarjeta tal y 
como se define en el anex o 1C, la VU deberá fijar la variable 
en VERD ADER O. 
DE LO CONTRARIO, si se cerró correctamente la última se­
sión de la tarjeta, la VU deberá fijar la variable en FALSO. 1 (VERD ADER O) 
= cerrada inco ­
rrectamente 
0 (FALSO) = ce­
rrada correcta ­
mente 
RTM11 
Inter rupción 
del suminis tro 
eléctr ico La VU generará un valor entero para el elemento de datos 
RTM11. 
La VU deberá asignar un valor para la variable tp15638P ower­
SupplyInterr uption igual a la interr upción del suministro eléc­
trico de mayor duración conf orme al artículo 9 del Reg (UE) 
no 165/2014 del tipo «Inte rrupción de la fuent e de alimen ­
tación», tal y como se define en el anex o 1C. 
DE LO CONTRARIO, si en los diez últimos días en que se ha­
yan producido incidentes no se ha producido ningún incident e 
de interr upción de la alimentación, el valor del entero se fijará 
en 0. —  Número de 
interr upcio ­
nes de la ali­
mentación en 
los diez últi­
mos días en 
que se hayan 
producido in­
cidentes 
26.5.2016 L 139/474 Diar io Oficial de la Unión Europea ES    
(1) Elementos 
de datos RTM (2) Acción realizada por la VU  (3) Definición de ASN.1 de los 
datos 
RTM12 
Fallo de sen­
sor La VU generará un valor entero para el elemento de datos 
RTM12. 
La VU deberá asignar a la variable Sensorfault un valor de: 
—  1 si se ha registrado un incidente de tipo ‘35’H Fallo de 
sensor en los últimos diez días 
—  2 si se ha registrado un incident e de tipo Fallo del recept or 
GNSS (intern o o externo con valores de enumeración ‘51’H 
o ‘52’H) en los últimos diez días 
—  3 si se ha registrado un incident e del tipo ‘53’H Fallo de 
comunicación del GNSS externo en los diez últimos días 
en que se hayan producido incidentes 
—4 si se han registrado fallos tanto del sensor como del re­
cept or GNSS en los diez últimos días en que se hayan pro­
ducido incident es 
—  5 si se han registrado fallos tanto del sensor como de las 
comunicaciones del GNSS externo en los diez últimos días 
en que se hayan producido incidentes 
—  6 si se han registrado fallos tanto del recep tor GNSS como 
de las comunicaciones del GNSS externo en los diez últi­
mos días en que se hayan producido incidentes 
—  7 si se han registrado fallos en los tres sensores en los diez 
últimos días en que se hayan producido incident es. 
DE LO CONTRARIO, deberá asignarse un valor de 0 si no se 
han registrado incident es en los diez últimos días en quese ha­
yan producido incidentes. —fallo del sen­
sor un octeto 
según el dic­
cionar io de 
datos 
RTM13 
Ajuste de la 
hora La VU deberá general un valor entero (timeReal del apéndice 
1) para el elemento de datos RTM13 basándose en la presencia 
de datos de Ajuste de hora tal y como se define en el anex o 
1C. 
La VU deberá asignar el valor de la hora en que se haya produ ­
cido el último incident e de datos de ajuste de hora. 
DE LO CONTRARIO, si no existe ningún incident e de«Ajuste 
de la hora», tal y como se define en el anex o 1C, en los datos 
de la VU, se fijará en un valor de 0. Hora del último 
ajuste de la hora 
RTM14 
Intent o de 
violación de 
la segur idad La VU generará un valor entero (timeReal del apéndice 1) para 
el elemento de datos RTM14 basándose en la presencia de un 
incident e de intento de violación de la segur idad tal y como se 
define en el anex o 1C. 
La VU deberá fijar el valor de la hora del último incident e de 
intent o de violación de la segur idad registrado por la VU. 
DE LO CONTRARIO, si en los datos de la VU no existe ningún 
incident e de «inte nto de violación de la segur idad» tal como se 
define en el anex o 1C, deberá fijarse un valor de 0x00FF . Hora del último 
intento de viola ­
ción 
—Valor prede ­
term inado 
=0x00FF 
RTM15 
Último cali­
brado La VU deberá generar un valor entero (timeReal del apéndice 
1) para el elemento de datos RTM15 basándose en la presencia 
de datos del último calibrado tal y como se define en el anex o 
1C. 
La VU deberá fijar el valor de la hora de los dos últimos cali­
brados (RTM15 y RTM16), que se fijan en VuCalibrationData 
definido en el apéndice 1. 
La VU deberá fijar el valor para RTM15 al timeReal del registro 
de calibrado más reciente. Hora de los datos 
del último cali­
brado 
26.5.2016 L 139/475 Diar io Oficial de la Unión Europea ES    
(1) Elementos 
de datos RTM (2) Acción realizada por la VU  (3) Definición de ASN.1 de los 
datos 
RTM16 
Calibrado an­
terior La VU deberá generar un valor entero (timeReal del apéndice 
1) para el element o de datos RTM16 del registro de calibrado 
anterior al del último calibrado. 
DE LO CONTRA RIO, si no ha habido ningún calibrado ante ­
rior, la VU deberá fijar el valor de RTM6 en 0. Hora de los datos 
del calibrado an­
terior 
RTM17 
Fecha de co­
nexión del ta­
cóg rafo Para el element o de datos RTM17, la VU deberá generar un va­
lor entero (timeReal del apéndice 1). 
La VU deberá fijar el valor de la hora de la instalación inicial 
de la VU. 
La VU deberá extraer estos datos de VuCalibrationData (apén ­
dice 1) a partir de vuCalibrationRecords con CalibrationPur ­
pose igual a: ‘03’H. Fecha de cone ­
xión del tacó ­
grafo 
RTM18 
Velocidad ac­
tual La VU generará un valor de número entero para el elemento 
de datos RTM18. 
La VU deberá fijar el valor para RTM 18 en la última velocidad 
actual registrada en el momento de la última actualización de 
los RtmData. Última velocidad 
actual registrada 
RTM19 
Indicación 
temporal Para el element o de datos RTM19, la VU deberá generar un va­
lor entero (timeReal del apéndice 1). 
La VU deberá fijar el valor para RTM19 en la hora de la última 
actualización de los RtmData. Indicación tem­
poral del registro 
TachographPa y­
load actual 
5.4.6  Mecanismo de transfer encia de datos 
DSC_42  Los datos útiles definidos anter iormente 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. 
DSC_43  En todos los intercambios DSR C, los datos se codificarán utilizando PER (Reg las de Codif icación por 
Paquetes). 
5.4.7  Descr ipción detallada de la transacción DSRC 
DSC_44  La inicialización se lleva a cabo conf orme a DSC_44 — DSC_48 y las cuadros 14.4 — 14.9. En la 
fase de inicializació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 
especifican a continuación en el cuadro 14.4. 26.5.2016 L 139/476 Diar io Oficial de la Unión Europea ES    
Cuadr o 14.4 
Inicialización: valores de trama BST 
Cam po Configuración 
Link Identifier Dirección de difusión 
BeaconId Según EN 12834 
Time Según EN 12834 
Profile Sin exte nsión, deberá usarse 0 o 1 
MandApplications Sin extensión, EID no present e, Parámetro no presente, AID=2 Carga y 
flota 
NoMandApplications No presente 
ProfileL ist Sin exte nsión, número de perf iles en la lista = 0 
Fragmentation header Sin fragmentación 
Layer 2 settings PDU de comandos, comando UI  
En el siguient e cuadro 14.5 se recoge un ejemplo práctico de los valores especificados en el cuadro 
14.4, con una indicación de las codificacio nes de bits. 
Cuadr o 14.5 
Inicialización: ejemplo del contenido de la trama BST No octeto Atributo/Campo Bits en octeto Descr ipció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 26.5.2016 L 139/477 Diar io Oficial de la Unión Europea ES    
No octeto Atributo/Campo Bits en octeto Descr ipción 
6 BST 
 Solicitud de inicialización 
SEQUENCE {   
OPTION indicator 
BeaconID SEQUENCE { 
ManufacturerId INTEGER 
(0..65535)  
Aplicaciones no oblig atori as no pre­
sentes    
Identif icador del fabricante 
7  
8  
IndividualID INTEGER 
(0..134217727)  
} 
ID de 27 bits disponible para el fabr i­
cante 
9 
10 
11 
12 Time INTEGER (0..4294967295)  
 Hora real UNIX de 32 bits 
13 
14 
15 
16 Profil eINTEGER (0..127,...)  
 Sin exte nsión. Perfil de ejemplo 0 
17 MandApplications SEQUENCE 
(SIZE 
(0..127,...)) OF 
{  
Sin exte nsión, número de MandAppli ­
cations = 1 
18 SEQUENCE {   
OPTION indicator 
 EID no presente 
OPTION indicator 
 Paráme tro no present e 
AID DSR CApplicationEntityID 
} }  
Sin exte nsión. AID = 2 Carga y flota 26.5.2016 L 139/478 Diar io Oficial de la Unión Europea ES    
No octeto Atributo/Campo Bits en octeto Descr ipción 
19 Profil eList SEQUENCE (0..127,...) 
OF Profile }  
Sin exte nsión, número de perf iles 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ífico s. El cuadro 14.6 ofrece un ejemplo de 
codificación de bits. 
Cuadr o 14.6 
Inicialización: contenido de la trama que solicita la asignación de una ventana privada No octeto Atributo/Campo Bits en octeto Descr ipción 
1 FLAG 
 Indicador de comienzo 
2 Private LID 
 Dirección de enlace de la DSR C-VU es­
pecífica 
3 
4 
5 
6 MAC Control field 
 Solicitud de ventana privada 
7 FCS 
 Secuencia de control de trama 
8 
9 Flag 
 Indicador de final  
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. 26.5.2016 L 139/479 Diar io Oficial de la Unión Europea ES    
Cuadr o 14.7 
Inicialización: contenido de la trama de asignación de una venta na privada No octeto Atributo/Campo Bits en octeto Descr ipción 
1 FLAG 
 Indicador de comienzo 
2 Private LID 
 Dirección de enlace de la DSR C-VU es­
pecí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. 
Cuadr o 14.8 
Inicialización: valores de trama VST 
Cam po Configuración 
Private LID Según EN 12834 
VST parameters Relleno=0, luego para cada aplicación compati ble: EID presente, pará ­
metro present e, AID=2, EID tal como sea generado por la OBU 
Parameter Sin exte nsión, contiene la marca de cont exto de RTM 
ObeConfiguration El campo opcional ObeStatus puede estar present e, pero no será utili ­
zado por el REDCR 
Fragmentation header Sin fragmentación 
Layer 2 settings PDU de comandos, comando UI  26.5.2016 L 139/480 Diar io Oficial de la Unión Europea ES    
DSC_48 La DSRC-VU deberá ser compati ble con la aplicación «Carga y flota», identif icada mediante el identi ­
ficador de aplicación ‘2’. Puede que se admitan otros identif icadores 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 referen cia a la norma correspondiente , formada por una marca context ual Rtm, que se 
compo ne de un IDENTIFICADOR DE OBJETOS que representa la norma relacionada, su parte (9 para 
RTM ) y posiblemente su versión, más un EID que genera la DSR C-VU y va asociado a esa instancia de 
aplicación. 
En el cuadro 14.9 se recoge un ejemplo práctico de los valores especificados en el cuadro 14.8, con 
una indicación de las codificaciones de bits. 
Cuadr o 14.9 
Inicialización: ejemplo del contenido de la trama VST No octeto Atributo/Campo Bits en octeto Descr ipción 
1 FLAG 
 Indicador de comienzo 
2 Private LID 
 Dirección de enlace de la DSR C-VU es­
pecífica 
3 
4 
5 
6 MAC Control field 
 PDU de comandos 
7 LLC Control field 
 Comando UI 
8 Fragmentation header 
 Sin fragmentación 
9 VST 
SEQUENCE { 
Respuesta de inicialización 
Fill BIT STRING (SIZE(4)) 
 No usado y fijado en 0 
10 Profil eINTEGER (0..127,...) 
Applications SEQUENCE OF { 
Sin exte nsión. Perfil de ejemplo 0 
11 
 Sin exte nsión, 1 aplicación 
12 SEQUENCE {   
OPTION indicator 
 EID present e 
OPTION indicator 
 Paráme tro present e 
AID DSR CApplicationEntityID 
 Sin exte nsión. AID = 2 Carga y flota 
13 EID Dsrc-EID 
 Defi nido dentro de la OBU e identifica 
la instancia de la aplicación. 26.5.2016 L 139/481 Diar io Oficial de la Unión Europea ES    
No octeto Atributo/Campo Bits en octeto Descr ipción 
14 Parameter Container { 
 Sin exte nsión, Opción de conte nedor 
= 02, Cadena de octetos 
15  
 Sin exte nsión, longitud de la marca de 
context o de Rtm = 8 
16 Rtm-Cont extMark::= SEQUENCE 
{ 
StandardIdentifier 
standardIdentifier  
Identif icador de objeto de la norma ad­
mitida, parte y versión. Ejemplo : ISO 
(1) Standard (0) TARV (15638) part9 
(9) Version1 (1). 
El primer octeto es 06H, que es el 
identif icador del objeto, el segundo oc­
teto es 06H, que es su longitud. Los 
seis octetos siguientes codif ican el 
identif icador de objeto de ejemplo. 
Adviértase que solo hay presente un 
único element o de la secuencia (se 
omite el elemento opcional RtmCom ­
Profi le) 17 
18 
19 
20 
21 
22 
23 
24 ObeConfiguration Sequence {   
OPTION indicator 
 ObeStatus no present e 
EquipmentClass INTEGER 
(0..32767) 
25 
26 Manufactur erId INTEGER 
(0..65535) 
Identif icador del fabricante para la 
DSR C-VU tal como se descr ibe en el 
registro ISO 14816 27 
28 FCS 
 Secuencia de control de trama 
29 
30 Flag 
 Indicador de final  
DCS_49  A continuación el REDCR lee los datos y envía un comando GET , conf orme 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 
Cam po Configuración 
Invoker Identif ier (IID) No presente 
Link Identifier (LID) Dirección de enlace de la DSR C-VU específica 
Chaining No 26.5.2016 L 139/482 Diar io Oficial de la Unión Europea ES    
Cam po Configuración 
Element Identif ier (EID) Según se especifica en la VST. Sin extensión 
Access Credentials No 
AttributeIdList Sin exte nsión, 1 atribut o, 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 No octeto Atributo/Campo Bits en octeto Descr ipción 
1 FLAG 
 Indicador de comienzo 
2 Private LID 
 Dirección de enlace de la DSR C-VU es­
pecí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 present es 
OPTION indicator 
 IID no present e 
OPTION indicator 
 Attr ibut eIdList 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 especific a en la VST. 
Sin exte nsión 
11 AttributeIdList SEQUENCE OF { 
AttributeId }} 
Sin exte nsión, número de atribut os = 1 
12 
 Attr ibut eId=1, RtmData. Sin extensión 26.5.2016 L 139/483 Diar io Oficial de la Unión Europea ES    
No octeto Atributo/Campo Bits en octeto Descr ipción 
13 FCS 
 Secuencia de control de trama 
14 
15 Flag 
 Indicador de final  
DSC_50  La DSRC-VU, tras recibir la petición GET , envía una respuesta GET con los datos solicitados conf orme 
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 respuest a GET 
Cam po Configuración 
Invoker Identif ier (IID) No presente 
Link Identifier (LID) Según EN 12834 
Chaining No 
Element Identif ier (EID) Según se especifica en la VST. 
Access Credentials No 
Fragmentation No 
Layer2 settings PDU de respuesta, Respuesta disponible y comando aceptad o, co­
mando ACn  
El cuadro 14.13 muestra un ejemplo de lectura de los datos RTM. 
Cuadro 14.13 
Present ación: ejemplo del contenido de una trama de respuest a No octeto Atributo/Campo Bits en octeto Descr ipción 
1 FLAG 
 Indicador de comienzo 
2 Private LID 
 Dirección de enlace de la DSR C-VU es­
pecífica 
3 
4 
5 
26.5.2016 L 139/484 Diar io Oficial de la Unión Europea ES    
No octeto Atributo/Campo Bits en octeto Descr ipción 
6 MAC Control field 
 PDU de respuesta 
7 LLC Control field 
 Respuesta disponible, bit n del co­
mando ACn 
8 LLC Status field 
 Respuesta disponible y comando acep ­
tado 
9 Fragmentation header 
 Sin fragmentación 
10 Get.response 
SEQUENCE { 
Obtener respuesta 
OPTION indicator 
 IID no present e 
OPTION indicator 
 Lista de atributos present e 
OPTION indicator 
 Estado de retor no no present e 
Fill BIT STRING(SIZE(1)) 
 No se utiliza 
11 EID INTEGER(0..127,…) 
 Respondiendo de la Instancia de aplica ­
ción RTM. 
Sin exte nsión 
12 AttributeList SEQUENCE OF { 
 Sin exte nsión, número de atribut os = 1 
13 Attr ibut es SEQUENCE { 
Attribut eId 
Sin exte nsión, AttibuteId=1 (Da­
tosRtm) 
14 Attribut eValue CONT AINER { 
 Sin exte nsión, Opción de conte nedor 
= 1010. 
15 
 RtmData 
16 
17 
… … 
n }}}} 
n+1 FCS 
 Secuencia de control de trama 
n+2 
n+3 Flag 
 Indicador de final  26.5.2016 L 139/485 Diar io Oficial de la Unión Europea ES    
DSC_51  A continuación, el REDCR cierra la conexión enviando un comando EVENT_REPOR T, RELEASE 
conf orme a EN 13372, 6.2, 6.3, 6.4 y EN 12834,7.3.8, sin valores RTM específico s. El cuadro 14.14 
muestra un ejemp lo de codificación de bits del comando RELEASE. 
Cuadro 14.14 
Finalización. Contenido de la trama EVENT_REPORT Release No octeto Atributo/Campo Bits en octeto Descr ipción 
1 FLAG 
 Indicador de comienzo 
2 Private LID 
 Dirección de enlace de la DSR C-VU es­
pecífica 
3 
4 
5 
6 MAC Control field 
 La trama contiene una LPDU de co­
mandos 
7 LLC Control field 
 Comando UI 
8 Fragmentation header 
 Sin fragmentación 
9 EVENT_REPOR T.request 
SEQUENCE { 
EVENT_REPOR T (Release) 
OPTION indicator 
 Credenciales de acceso no present es 
OPTION indicator 
 Paráme tro de event o no presente 
OPTION indicator 
 IID no present e 
Mode BOOLEAN 
 No se espera respuesta 
10 EID INTEGER (0..127,…) 
 Sin exte nsión, EID = 0 (Sist ema) 
11 EventT ype INTEGER (0..127,…) } 
 Tipo de event o 0 = Release 
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  Descr ipción de la transacción de pruebas de la DSRC 
DSC_53  Deben realizarse pruebas completas que comprendan la prote cción de los datos tal y como se define 
en el apéndice 11, «Mecanismos de segur idad comunes», por personas autorizadas que tengan acceso a 
los procedimiento s de segur idad mediante el comando GET normal definido anteriormente. 26.5.2016 L 139/486 Diar io Oficial de la Unión Europea ES    
DSC_54  Las pruebas para la puesta en servicio y para las inspecciones periódicas que requieran el descifrado y 
la compre nsión del cont enido de los datos descifrados se llevarán a cabo según los especificado en el 
apéndice 11, «Mecanismos de segur idad comunes», y el apéndice 9, «Homologaci ón y lista de pruebas 
mínimas requer idas». 
No obstante, la comunicación DSR C básica puede comprobarse mediante el comando ECH O. 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 compet ente o el Reglamento (UE) no 165/2014 (véase 
la sección 6). 
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 satisf actoria mente una fase de inicialización. Por tanto, la 
secuencia de intera cciones es similar a la de una interr ogación:  
— Paso 1El REDCR envía una «tabla de servicios de la baliza» (BST) que incluy e los identificad ores 
de aplicación (AID) en la lista de servicios que admite. En las aplicaciones RTM, consistirá 
simplemente en el servicio con el valor AID = 2. 
La DSRC-VU evalúa la BST recibida y, cuando identif ica que la BST está solicitando carg a 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 2La DSRC-VU envía una solicitud de una asignación de ventana privada.  
— Paso 3El REDCR envía una asignación de ventana privada.  
— Paso 4La DSRC-VU utiliza la ventana privada asignada para envi ar su tabla de servicio del 
vehículo (VST). Esta VST incluy e una lista de todas las instanciaciones diferentes de la aplicación 
que admit e esta DSRC-VU en el marco de AID = 2. Las diferent es instanciaciones se identificarán 
mediante EID únicas, cada una de ellas asociada a un valor de parámetro que indica la instancia de 
la aplicación que es compatib le.  
— Paso 5A continuación el REDCR analiza la VST ofrecida y, o bien finaliza la conexión (RELEASE) 
porque no le inter esa 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 6El REDCR emitirá un comando (ECHO) a la DSRC-VU específi ca y asignará una ventana 
privada.  
— Paso 7La DSRC-VU utiliza la ventana privada recién asignada para enviar una trama de respuesta 
ECHO. 
Los cuadros siguient es ofrecen un ejem plo práctico de una sesión de inter cambio ECH O. 
DSC_56  La inicialización se lleva a cabo conf orme 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, ECH O conf orme a ISO 14906, que contiene 
100 octetos de datos sin valores específico s para RTM. El cuadro 14.15 muestra el cont enido de la 
trama que envía el REDCR. 
Cuadro 14.15 
ejemplo de trama de petición ACTION ,ECHO No octeto Atributo/Campo Bits en octeto Descr ipción 
1 FLAG 
 Indicador de comienzo 
2 Private LID 
 Dirección de enlace de la DSR C-VU es­
pecífica 
3 
26.5.2016 L 139/487 Diar io Oficial de la Unión Europea ES    
No octeto Atributo/Campo Bits en octeto Descr ipción 
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 present es 
OPTION indicator 
 Paráme tro de acción present e 
OPTION indicator 
 IID no present e 
Mode BOOLEAN 
 Respuesta esperada 
10 EID INTEGER (0..127,…) 
 Sin exte nsión, EID = 0 (Sist ema) 
11 Action Type INTEGER (0..127,…) 
 Sin exte nsión, solicitud de ECHO de 
tipo de acción 
12 ActionParamet er CONT AINER { 
 Sin exte nsión, opción de contened or 
= 2 
13 
 Sin exte nsión, longitud de cadena 
= 100 octetos 
14  
 Datos de que se debe hacer eco 
… … 
113 }} 
114 FCS 
 Secuencia de control de trama 
115 
116 Flag 
 Indicador de final  
DSC_58  La DSRC-VU, al recibir la petición ECH O, envía una respuesta ECHO de 100 octetos de datos 
reflejando el comando recibido, según ISO 14906, sin valores específi cos para RTM. El cuadro 14.16 
muestra un ejemp lo de codificación a nivel de bits. 26.5.2016 L 139/488 Diar io Oficial de la Unión Europea ES    
Cuadro 14.16 
ejemplo de trama de respuest a ACTION ,ECHO No octeto Atributo/Campo Bits en octeto Descr ipció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 (ECH O) 
OPTION indicator 
 IID no present e 
OPTION indicator 
 Paráme tro de respuesta presente 
OPTION indicator 
 Estado de retor no no present e 
Fill BIT STRING (SIZE (1)) 
 No se utiliza 
11 EID INTEGER (0..127,…) 
 Sin exte nsión, EID = 0 (Sist ema) 
12 ResponseP arameter CONT AINER { 
 Sin exte nsión, opción de contened or 
= 2 
13 
 Sin exte nsión, longitud de cadena 
= 100 octetos 
14  
 Datos de eco 
… … 
113 }} 
114 FCS 
 Secuencia de control de trama 
115 
116 Flag 
 Indicador de final  26.5.2016 L 139/489 Diar io Oficial de la Unión Europea ES    
5.5  Cumplimiento de la Directiva (UE) 2015/719 
5.5.1  Resumen 
DSC_59  Con el fin de cumpli r la Directiva (UE) 2015/719 relativa las dimensiones y los pesos máximos de 
vehículos pesados, el protocolo de transacciones para descarg ar los datos OWS a través de un enlace 
de interfaz DSR C de 5,8 GHz será el mismo que el utilizado para los datos RTM (véase el apar tado 
5.4.1), con la salvedad de que el identif icador de objeto s que se refiere a la norma TARV se ajustará a 
la parte 20 de la norma ISO 15638 (TARV) relativa a WOB/O WS. 
5.5.2  Comandos 
DSC_60  Los comandos emplea dos para una transacción OWS serán los mismos que los utilizados en una 
transacción RTM. 
5.5.3  Secuencia de comandos de inter rogación 
DSC_61  La secuencia de comandos de interr ogación para datos OWS será la misma que para los datos RTM. 
5.5.4  Estructur as de los datos 
DSC_62  Los datos útiles (datos OWS) consiste n en la concatenación de  
1. datos Encr yptedOwsP ayload, que constituyen el cifrado de OwsPa yload definido en ASN.1, 
apar tado 5.5.5. El método de cifrado será el mismo que el adopt ado para los RtmData, que se 
especifica en el apéndice 11.  
2. DSR CSecur ityData, calculados con los mismos algor itmos adop tados para los RtmData, que se 
especifican en el apéndice 11.  26.5.2016 L 139/490 Diar io Oficial de la Unión Europea ES    
5.5.5  Módulo ASN.1 para la transacción OW S DSRC 
DSC_63.  La definición del módulo ASN.1 para los datos DSR C dentro de la aplicación RTM se establece del 
modo siguiente : 
26.5.2016 L 139/491 Diar io Oficial de la Unión Europea ES    
5.5.6  Elementos de OwsData, acciones realizadas y defin iciones 
Se definen los elementos de OwsData para cumpli r la Directiva (UE) 2015/719 relativa las dimensiones y los 
pesos máximos de vehículos pesados. Su signif icado es: 
—  recordedW eight representa el peso total medido del vehículo pesado con una resolución de 10 kg según se 
define en EN ISO 14906. Por ejem plo, un valor de 2 500 representa un peso de 25 toneladas. 
—  axlesConf iguration representa la configuración del vehículo pesado como número de ejes. La configuración 
se define con la máscara de 20 bits (ampli ado a partir de EN ISO 14906). 
Una máscara de 2 bits representa la configuración de un eje con el format o siguiente: 
—  el valor 00B signif ica que el valor «no está disponible» porque el vehículo no dispone de ningún equipo 
para obtener el peso sobre el eje; 
—  el valor 01B significa que el eje no está presente; 
—  el valor 10B signif ica que el eje está present e, que se ha calculado y obtenid o el peso y aparece en el 
campo axlesRecordedW eight ; 
—  el valor 11B se reser va para usos futuros. 
Los 4 últimos bits se reser van para usos futuros. 
Número de ejes  
Número de ejes en el tract or Número de ejes en el remolque 
00/01/ 
10/11 00/01/ 
10/11 00/01/ 
10/11 00/01/ 
10/11 00/01/ 
10/11 00/01/ 
10/11 00/01/ 
10/11 00/01/ 
10/11 00/01/ 
10/11 00/01/ 
10/11 RFU 
(4 bits)  
—  axlesRecordedW eight representa el peso específi co registrado para cada eje con una resolución de 10 kg. Se 
utilizan dos octetos para cada eje. Por ejemplo, un valor de 150 representa un peso de 1 500 kg. 
Los demás tipos de datos se definen en el apar tado 5.4.5. 
5.5.7  Mecanismos de transfer encia de datos 
DSC_64  El mecanismo de transfe rencia de datos para datos OWS entre el interr ogador y el equipo DSR C del 
vehículo será el mismo que para los datos RTM (véase el apar tado 5.4.6). 
DSC_65  La transferencia de datos entre la plataf orma que obtiene los datos de pesos máximos y el equipo 
DSR C del vehículo se basará en la conexión física, las interfaces y el protocolo definido s en la sección 
5.6. 
5.6  Transferencia de dato s entre la DSR C-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ámbr ica de corto alcance basada en Bluetooth v4.0 BLE. 
DSC_67  Independiente mente de la conexión física y la interfaz elegidas, deberán cumpli rse los siguient es 
requisitos: 
DSC_68  a)con el fin de poder contratar a varios proveedores el suministro de la VU y la DSR C-VU, e incluso 
diferentes lotes de DSR C-VU, la conexión entre la VU y la DSR C-VU será una conexión de norma 
abier ta. La VU se conectará con la DSR C-VU: 
i)  mediante cable fijo de al menos 2 metros, utilizando un conector macho homologado Straight 
DIN 41612 H11 de 11 patillas de la DSR C-VU para conectarlo a un conect or hembra 
homologado DIN/ISO del dispositivo VU; 26.5.2016 L 139/492 Diar io Oficial de la Unión Europea ES    
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 DSR C-VU debe admitir los comandos 
del protocolo de aplicaciones definidos en el apar tado 5.6.2. y 
DSC_70  c)la VU y la DSR C-VU deben ser compati bles con el funcionamiento de la transfe rencia de datos a 
través de la conexión en cuant o al rendimient o y al suministro eléctr ico. 
5.6.2  Protocolo de aplicaciones 
DSC_71  El protocolo de aplicaciones entre el dispositivo de comunicación a distancia VU y la DSR C-VU tiene 
por objeto la transferencia periódica de datos de comunicación a distancia desde la VU al DSR C. 
DSC_72  Se han identif icado los siguient es 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.  
4. Confir mació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 anter iores pueden definirse del modo siguiente : 
26.5.2016 L 139/493 Diar io Oficial de la Unión Europea ES    
DSC_74  La descr ipción de los comandos y parámetros es la siguient e: 
—  
 se utiliza para inicializar el 
enlace de comunicación. El comando lo envía la VU a la DSR C-VU. El LinkIdentif ier lo establece la 
VU y lo comunica a la DSR C-VU para rastrear un enlace de comunicación específico. 
(Nota: esto sirve para admitir enlaces futuros y otras aplicaciones o módulos como el de pesaje a 
bordo.)  
—  
 lo utiliza la DSR C-VU para 
responder a la petición de iniciar el enlace de comunicación. El comando lo envía la DSR C-VU a la 
VU. El comando da el resultado de la inicialización como respuesta = 1 (cor recto) o = 0 
(incor recto). 
DSC_75  La inicialización del enlace de comunicación se realizará solo tras la instalación, calibrado y arranque 
del motor/VU. 
—  
 lo utiliza la VU para enviar los RCDTData firmados (es decir , los Datos de 
comunicación a distancia) a la DSR C-VU. Los datos se enviarán cada 60 segundos. El parámetro 
DataT ransactionId identifica la transmisión específica de datos. El LinkIdentif ier también se usa 
para asegurarse de que el enlace correspondiente es el correcto. 
—  
 lo envía la DSR C-VU para suministrar información a la VU 
acerca de la recepción de los datos de un comando RCDT–Send Data identif icado mediante el 
parámetro DataT ransactionId. El parámetro de respuesta es 1 (cor recto) o = 0 (incor recto). Si una 
VU recibe más de tres respuestas iguales a 0 o si 
 la VU no recibe una 
confir mación de datos RCDT de un comando específi co RCDT -Send Data enviado anterior mente 
con un DataT ransactionId específic o, la VU generará y registrará un incident e. 
—  
 lo envía la VU a la DSR C-VU para 
finalizar un enlace de un LinkIdentif ier específico. 
DSC_76  Al reiniciar la DSR C-VU o una VU, todos los enlaces de comunicación existent es deben eliminarse, ya 
que podría haber enlaces «pendientes » debido a la desconexión repentina de una VU. 
—  
 lo envía la DSR C-VU a la VU para 
confir mar la petición de finalización del enlace por parte de la VU para el LinkIdentif ier específico. 
5.7  Gestión de errores 
5.7.1  Registro y comunicación de los datos en la DSRC-VU 
DSC_77  Los Datos deberán ser suministrados, ya prot egidos, por la función VUSM a la DSRC-VU. La VUSM 
verificará que los datos registrados en la DSRC-VU se han grabado correctamente . El registro y la 
notificación de errores en la transferencia de datos de la VU a la memor ia de la DSRC-VU se llevarán 
a cabo con el tipo EventFa ultT ype y el valor de enumeración fijado en ‘62’ H fallo de comunicación 
del dispositivo de comunicación a distancia junto con la indicación temporal. 
DSC_78  La VU mantendrá un fichero identif icado mediante un nombre único que result e fácil de identif icar 
para los inspect ores con la finalidad de registrar «fall os de comunicación interna de la VU». 
DSC_79  Si la VUPM intenta obtener datos de la VU desde el módulo de segur idad (para pasarlos a la DSR C- 
VU), pero no lo consigue, registrará el fallo con el tipo EventF aultT ype y el valor de enumeración 
fijado en ‘62’ H fallo de comunicación del dispositiv o de comunicación a distancia junto con la indicación 
temporal. El fallo de comunicación se detecta cuando no se recibe un mensaj e 
para el correspondiente 
 (es decir , con el mismo 
DataT ransactionId en los mensajes 
 )durant e más de tres veces 
consecutivas. 
5.7.2  Errores de comunicación inalámbr ica 
DSC_80  La gestión de errores de comunicación deberá ajustarse a las correspondiente s normas DSR C, es decir , 
EN 300 674-1, EN 12253, EN 12795, EN 12834 y los parámetros pertinentes de EN 13372. 26.5.2016 L 139/494 Diar io Oficial de la Unión Europea ES    
5.7.2.1  Errores de cifrado y firma 
DSC_81  Los errores de cifrado y firma se gestionarán del modo definido en el apéndice 11, «Mecanismos de 
segur idad comunes», y no aparecen en ninguno de los mensajes de error asociados a transfer encias de 
datos DSR C. 
5.7.2.2  Registro de errores 
El medio DSR C consiste en una comunicación inalámbr ica dinámica en un entorno de condiciones atmosfé ricas 
e interfe rencias inestables, especialmente en las combinaciones de «REDCR portátil» y «vehículo en movimient o» 
que inter vienen en esta aplicación. Por tanto , es preciso establecer la diferencia entre un «fall o de lectura» y una 
condición de «error». En una transacción a través de una interfaz inalámbr ica, los fallos de lectura son 
habituales y la consecuencia suele ser un reintent o, 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 satisfact oria y la transfer encia 
de datos, a menos que el vehículo seleccionado se salga del alcance durante el tiempo necesar io para 
retransmitir . (Es posible que una instancia «satisfact oria» de una «lectura» haya necesitado varios intent os y 
reint entos.) 
El fallo de lectura puede deberse a que las antenas no estaban correctamente 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éctr icas, especialmente de comunicaciones WIFI de alrededor de 
5,8 GHz u otras comunicaciones inalámbr icas de acceso público, o puede deberse a interferencias de radares o 
a condiciones atmosf éricas problemáticas (por ejemp lo, durant e una tormenta eléctr ica); o sencillamente a 
haberse salido del alcance de la comunicación DSR C. Las instancias individuales de los fallos de lectura, por su 
naturaleza, no pueden registrarse simplement e porque la comunicación no tuvo lugar . 
No obstante, si el agente de la autori dad de control compet ente selecciona un vehículo e intenta interr ogar 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 autori dad de control compet ente 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 inspección física. Pero, al no haber existido ninguna comunicación, la 
DSR C-VU no puede suministrar datos relacionados con el fallo. Por tanto , estos informes dependerán del diseño 
del equipo REDCR. 
Técnicamente , un «fall o de lectura» es distinto a un «error». En este cont exto, un «error» es la obte nción de un 
valor erróneo. 
Los datos que se transf ieren 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). 
Posteri ormente, se comprueban los datos transferidos a través de la interf az 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 retransmit en los datos. Estadísticamente , es tan improbable que los datos puedan pasar con 
éxito una CRC de forma incor recta que esta posibilidad puede descar tarse. 
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 «fall o» significativos que pueden registrarse son los del número de iniciaciones de transac ­
ciones satisf actor ias que se producen y que no se traducen en una transfe rencia 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 DSR C, pero se interrumpi ó la 
transacción antes de que los Datos fueran recuperados correctamente por el REDCR. Estos datos 
quedarán a disposición del agent e de la autori dad de control compe tent e y se almacenarán en la 
memor ia del equipo REDCR. El medio empleado para esta operación dependerá del diseño del 
product o o de la especific ación de una autoridad de control compe tent e. 
Los únicos datos de «error» signif icativ os que pueden registrarse son el número de veces que el 
REDCR no logra descifrar 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écn icamente y, sin embargo, 
no tener sentido semántico. 26.5.2016 L 139/495 Diar io Oficial de la Unión Europea ES    
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 interf az DSR C. 
6  PRUEBAS PARA LA PUEST A EN SER VICIO Y LAS INSPECCIONES PERIÓDICAS DE LA FUNCIÓN DE COMUNICA CIÓN A 
DIST ANCIA 
6.1  Generalidades 
DSC_84  Se prevén dos tipos de pruebas para la función de comunicación a distancia:  
1) Una prueba ECHO para validar el canal de comunicación inalámbr ica DSRC-REDCR >>-:-<DSRC- 
VU.  
2) Una prueba de segur idad de extremo a extremo para garantizar 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ámbr ica. 
6.2  ECHO 
Esta sección contiene disposiciones elaboradas específicamente para comproba r únicament e que el enlace 
DSRC-REDCR >>-:-<DSRC-VU está operativo. 
El objetivo del comando ECHO es permitir a los talleres o a los centros de ensa yos de homologación que 
prueben que el enlace DSR C funciona sin necesidad de acceder a las credenciales de segur idad. Por tanto, el 
equipo del evaluador solo precisa poder inicializar una comunicación DSR C (enviando una BST con AID = 2) y, 
seguidamente , enviar un comando ECH O y, suponiendo que funcione el DSR C, recibirá una respuesta ECHO. 
Véanse los detalles en el apar tado 5.4.8. Suponiendo que se recibe esta respuesta correctamente, es posible 
validar el funcionamient o correcto del enlace DSR C (DSRC-REDCR >>-:-<DSRC-VU). 
6.3  Pruebas para validar el contenido de datos seguros 
DSC_85  Esta prueba se realiza para validar de extremo a extremo el flujo de datos de segur idad. Se precisa un 
lector de pruebas DSR C para esta prueba. El lector de pruebas DSR C desempeña la misma función y 
se instala con las mismas especific aciones que el lector que utilizan los agent es de segur idad, con la 
salvedad de que se utiliza una tarjeta de taller en lugar de una tarjeta de control para aute nticar al 
usuar io del lector de pruebas DSR C. La prueba puede realizarse tras la activación inicial de un 
tacógraf o inteligent e o al final del proceso de calibrado. Tras la activación, el equipo del vehículo 
generará y comunicará a la DSR C-VU los datos protegidos de detección temprana. 
DSC_86  El personal del taller debe colocar el lector de pruebas DSR C delante del vehículo a una distancia de 
entre 2 y 10 metros. 
DSC_87  A continuación, dicho personal inser tará una tarjeta de taller en el lector de pruebas DSR C para 
solicitar la interr ogaci ón de los datos de detección temprana a la VU. Tras una interro gació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.  26.5.2016 L 139/496 Diar io Oficial de la Unión Europea ES    
Apéndice 15 
MIGRA CIÓN: GESTIÓN DE LA COEXISTENCIA DE LAS GENERA CIONES DE EQUIPOS 
ÍNDICE 
1. DEFINICIONES ................................................................................................................................... 497 
2. DISPOSICIONES GENERALES ................................................................................................................ 497 
2.1. Visión general de la transición ................................................................................................... 497 
2.2. Interoperabilidad entre la unidad instalada en el vehículo y las tarjetas ............................................... 498 
2.3. Interoperabilidad entre la unidad instalada en el vehículo y los sensores de movimient o......................... 498 
2.4. Interoperabilidad entre las unidades instaladas en el vehículo, las tarjetas de tacógraf o y los equipos para la 
transferencia de datos .............................................................................................................. 498 
2.4.1 Transf erencia de datos directamente de la tarjeta por IDE ................................................................ 498 
2.4.2 Transf erencia de datos de la tarjeta a través de una unidad instalada en el vehículo ............................... 499 
2.4.3 Transf erencia de datos de la unidad instalada en el vehículo ............................................................. 499 
2.5. Interoperabilidad entre las unidades instaladas en el vehículo y el equipo de calibrado ........................... 499 
3. ETAPAS PRINCIP ALES DURANTE EL PERÍODO PREVIO A LA FECHA DE INTR ODUCCIÓN .................................. 499 
4. DISPOSICIONES PARA EL PERÍODO POSTERIOR A LA FECHA DE INTR ODUCCIÓN .......................................... 499  
1.  DEFINICIONES 
A efectos del present e apéndice, se aplicarán las siguientes definiciones: 
Sistema de tacó grafo inteligente: tal como se define en el present e anex o (capítulo 1: definición bbb); 
Sistema de tacóg rafo de primera generación: tal como se define en el presente Reglamento (artículo 2: 
definición 1); 
Sistema de tacóg rafo de segunda generación: tal como se define en el present e Reglamento (artículo 2: 
definición 7); 
Fecha de introducción: tal como se define en el presente anex o (capítulo 1: definición ccc); 
Equipo dedicado inteligente (IDE): equipo empleado para realizar la transfe rencia de datos, tal como se define 
en el apéndice 7 del present e anex o. 
2.  DISPOSICIONES GENERALES 
2.1.  Visión general de la transición 
El preámbulo del presente anex o ofrece una visión general de la transición entre los sistem as de tacógraf o de la 
primera y de la segunda generación. 
Además de las disposiciones del presente preámbulo: 
—  los sensores de movimient o de primera generación no serán interoperables con las unidades instaladas en el 
vehículo de segunda generación, 
—  los sensores de movimient o de segunda generación empe zarán a instalarse en los vehículos al mismo tiempo 
que las unidades instaladas en el vehículo de segunda generación, 
—  la transferencia de datos y los equipos de calibrado tendrán que evolucionar con el fin de permitir el uso de 
las dos generaciones de aparat os de control y tarjetas de tacógraf o. 26.5.2016 L 139/497 Diar io Oficial de la Unión Europea ES    
2.2.  Interoperabilidad entre la unidad inst alada en el vehículo y las tarjetas 
Se entiende que los tarjetas de tacógraf o de primera generación son inter operables con las unidades instaladas en 
el vehículo de primera generación (de conf ormidad con el anex o 1B del present e Reglamento) , mientras que las 
tarjetas de tacógraf o de segunda generación son interoperables con las unidades instaladas en el vehículo de 
segunda generación (de conf ormidad con el anex o 1C del present e Reglamento) . Asimismo, serán de aplicación 
los siguiente s requisitos: 
MIG_001  Excep to en el caso indicado en los requisit os MIG_004 y MIG_005, las tarjetas de tacógraf o de primera 
generación podrán seguir utilizándose en las unidades 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ógraf o de segunda generación tan pronto como estén disponibles. 
MIG_002  Las unidades instaladas en vehículos de segunda generación podrán utilizar cualquier tarjeta valida de 
primera generación inser tada, ya sea de conductor , de control o de empr esa. 
MIG_003  Esta capacidad puede ser eliminada por el taller de forma definit iva en dichas unidades instaladas en el 
vehículo, de forma que las tarjetas de tacógraf o 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 march a un 
procedimiento destinado a exigir a los talleres dicha actuación, por ejemp lo durant e cada control 
periódico del tacógraf o. 
MIG_004  Las unidades instaladas en el vehículo de segunda generación solo podrán utilizar las tarjetas de taller 
de segunda generación. 
MIG_005  Para determinar el modo de funcionamiento, las unidades instaladas en el vehículo de segunda 
generación solo podrán considerar el tipo de la tarjeta válida inser tada, independientement e de su 
generación. 
MIG_006  Cualquier tarjeta de tacógraf o válida de segunda generación deberá poder ser utilizada en unidades 
instaladas en el vehículo de primera generación, exactamente como una tarjeta de tacógraf o de primera 
generación del mismo tipo. 
2.3.  Interoperabilidad entre la unidad inst alada en el vehículo y los sensores de movimiento 
Se entiende que los sensores de movimiento de primera generación son inter operables con las unidades instaladas 
en el vehículo de primera generación, mientras que los sensores de movimiento de segunda generación son intero­
perables con las unidades instaladas en el vehículo de segunda generación. Asimismo, serán de aplicación los 
siguiente s requisitos: 
MIG_007  Las unidades instaladas en el vehículo de segunda generación no podrán emparejarse y utilizarse con 
sensores de movimient o de primera generación. 
MIG_008  Los sensores de movimient o de segunda generación podrán emparej arse y utilizarse solo con unidades 
instaladas en el vehículo de segunda generación, o con unidades instaladas en el vehículo de las dos 
generaciones. 
2.4.  Interoperabilidad entre las unidades inst aladas en el vehículo, las tarjetas de tacóg rafo y los equipos para 
la transfer encia de datos 
MIG_009  Los equipos para la transfer encia de datos podrán utilizarse con unidades instaladas en el vehículo y 
tarjetas de tacógraf o de una sola generación, o de las dos. 
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ógraf o de una generación 
inser tadas en sus lectore s de tarjetas, utilizando los mecanismos de segur idad y el protocolo de transfe ­
rencia de datos de esa generación, y los datos transferi dos deberán tener el formato definido para dicha 
generación. 
MIG_011  Para permitir el control de los conductores por parte de autor idades de control no perteneciente s a la 
UE, también será posible la trasf erencia de datos de las tarjetas de conduct or (y de taller) de segunda 
generación exactament e de la misma manera que las tarjetas de conduct or (y de taller) de primera 
generación. Dicha transfe rencia incluirá: 
—  EF (arch ivos elementales) 
 e 
 no firmados, 
—  EF (1a generación) 
 y 
 no firmados, 26.5.2016 L 139/498 Diar io Oficial de la Unión Europea ES    
—  el resto de EF con datos de aplicación (dentro del DF 
 ) requer idos por el prot ocolo de 
transfer encia de datos de la tarjeta de primera generación. Esta información debe estar protegi da 
con una firma digital, conf orme a los mecanismos de segur idad de la primera generación. 
Dicha trasfe rencia de datos no incluirá EF con datos de aplicación solo present es en las tarjetas de 
conductor (y de taller) de segunda generación (EF con datos de aplicación dentro del DF 
 ). 
2.4.2  Transferencia de datos de la tarjeta a través de una unidad instalada en el vehíc ulo 
MIG_012  Los datos se trasf erirán desde una tarjeta de segunda generación inser tada en una unidad instalada en 
el vehículo de primera generación utilizando el protocolo de transfer encia 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 primera generación. 
MIG_013  Los datos se transferirán desde una tarjeta de primera generación inser tada en una unidad instalada en 
el vehículo de segunda generación utilizando el prot ocolo de transfer encia de datos definido en el 
apéndice 7 del presente anex o. La unidad instalada en el vehículo deberá envi ar comandos a la tarjeta 
exactamente de la misma manera que una unidad instalada en el vehículo de primera generación, y los 
datos transfe ridos deberán respetar el format o definido para las tarjetas de primera generación. 
2.4.3  Transferencia de datos de la unidad instalada en el vehíc ulo 
MIG_014  Los datos serán transferidos desde las unidades instaladas en el vehículo de segunda generación 
utilizando los mecanismos de segur idad de segunda generación, y el prot ocolo de transfer encia de 
datos especificado en el apéndice 7 del present e anex o. 
MIG_015  Para permitir el control de los conductores por parte de autor idades de control no perteneciente s a la 
UE y la trasf erencia de los datos de la unidad instalada en el vehículo por parte de talleres no pertene­
cientes a la UE, también podría ser posible la opción de realizar la trasferencia de datos desde unidades 
instaladas en el vehículo de segunda generación utilizando los mecanismos de segur idad de la primera 
generación, y el protocolo de transferencia de datos de la primera generación. Los datos transferidos 
deberán tener el formato de los datos transferi dos desde una unidad instalada en el vehículo de 
primera generación. Esta capacidad podrá seleccionarse mediante los comandos del menú. 
2.5.  Interoperabilidad entre las unidades inst aladas en el vehículo y el equipo de calibrado 
MIG_016  El equipo de calibrado podrá efectuar el calibrado de una determinada generación de tacógraf os 
utilizando el protocolo de calibrado de dicha generación. El equipo de calibrado se puede utilizar con 
tacógraf os de una sola generación, o de las dos. 
3.  ETAPAS PRINCIP ALES DURANTE EL PERÍODO PREVIO A LA FECHA DE INTR ODUCCIÓN 
MIG_017  Las claves y los certificado s de los ensa yos estarán a disposición de los fabricantes a más tardar treinta 
meses antes de la fecha de introducción. 
MIG_018  Los ensa yos de interoperabilidad deberán ponerse en marc ha a petición de los fabricantes a más tardar 
quince meses antes de la fecha de introducción. 
MIG_019  Las claves y certificado s oficiales estarán a disposición de los fabr icantes a más tardar doce meses 
antes de la fecha de introducción. 
MIG_020  Los Estados miembros deberán poder expedir las tarjetas de taller de segunda generación a más tardar 
tres meses antes de la fecha de introducción. 
MIG_021  Los Estados miembros deberán poder expedir todos los tipos de tarjetas de tacógraf o de segunda 
generación a más tardar un mes antes de la fecha de introducción. 
4.  DISPOSICIONES PARA EL PERÍODO POSTERIOR A LA FEC HA DE INTR ODUCCIÓN 
MIG_022  Tras la fecha de introducción, los Estados miembros solamente expedirán tarjetas de tacógraf o de 
segunda generación. 26.5.2016 L 139/499 Diar io Oficial de la Unión Europea ES    
MIG_023  Los fabr icantes de unidades instaladas en el vehículo y/o de sensores de movimiento estarán 
autori zados a producir unidades instaladas en el vehículo y sensores de movimiento de primera 
generación en tanto se utilicen sobre el terren o, para que los compo nentes que funcionen mal puedan 
sustituirse. 
MIG_024  Los fabr icantes de unidades instaladas en el vehículo y/o de sensores de movimiento estarán 
autori zados a solicitar y obtener el manten imiento de la homologació n de las unidades instaladas en el 
vehículo y sensores de movimient o de la primera generación ya homolog ados.  26.5.2016 L 139/500 Diar io Oficial de la Unión Europea ES    
Apéndice 16 
ADAPT ADOR PARA VEHÍCULOS DE LAS CATEGORÍAS M 1 Y N1 
ÍNDICE 
1. ABREVIA TURAS Y DOCUMENTOS DE REFERENCIA ..................................................................................... 501 
1.1. Abreviaturas ........................................................................................................................... 501 
1.2. Nor mas de referen cia ................................................................................................................ 501 
2. CARA CTERÍSTICAS GENERALES Y FUNCIONES DEL ADAPT ADOR .................................................................. 502 
2.1. Descr ipción general del adapta dor ................................................................................................ 502 
2.2. Funciones ............................................................................................................................... 502 
2.3. Segur idad ............................................................................................................................... 502 
3. REQUISITOS REL ATIVOS AL APARA TO DE CONTR OL EQUIP ADO CON UN ADAPT ADOR ................................... 502 
4. CONDICIONES DE FABRICA CIÓN Y FUNCIONAMIENTO DEL ADAPT ADOR ...................................................... 503 
4.1. Interconexi ón y adapta ción de los impulsos de velocidad de entrada .................................................... 503 
4.2. Inducción de los impulsos de entrada al sensor de movimient o integra do............................................. 503 
4.3. Sensor de movimient o integrado .................................................................................................. 503 
4.4. Requisito s de segur idad ............................................................................................................. 503 
4.5. Caracter ísticas de funcionamient o................................................................................................ 504 
4.6. Materi ales ............................................................................................................................... 504 
4.7. Inscr ipciones ........................................................................................................................... 504 
5. INST ALACIÓN DEL APARA TO DE CONTR OL EQUIP ADO CON UN ADAPT ADOR ............................................... 504 
5.1. Instalación .............................................................................................................................. 504 
5.2. Precintos ................................................................................................................................ 505 
6. VERIFICA CIONES, CONTR OLES Y REPARA CIONES ....................................................................................... 505 
6.1. Controles periódicos ................................................................................................................. 505 
7. HOMOLOGA CIÓN DEL APARA TO DE CONTR OL EQUIP ADO CON UN ADAPT ADOR ......................................... 505 
7.1. Aspectos generales .................................................................................................................... 505 
7.2. Certificado funcional ................................................................................................................. 506  
1.  ABREVIA TURAS Y DOCUMENTOS DE REFERENCIA 
1.1.  Abreviaturas 
VU  Unidad instalada en el vehículo (Vehicle Unit) 
1.2.  Nor mas de referencia 
ISO16844-3 Vehículos de carretera — Siste mas de tacógraf o — Parte 3: Interfaz del sensor de movimient o 26.5.2016 L 139/501 Diar io Oficial de la Unión Europea ES    
2.  CARA CTERÍSTICAS GENERALES Y FUNCIONES DEL ADAPT ADOR 
2.1.  Descr ipción general del adaptad or 
ADA_001  El adap tador proporcionará a la VU conectada unos datos de movimiento seguros representativos en 
todo momento de la velocidad del vehículo o de la distancia recor rida. 
El adap tador está destinado únicamente a los vehículos que deben estar provistos de un aparato de 
control de conf ormidad con el present e Reglamento. 
Se instalará y utilizará solo en los tipos de vehículos definidos en la letra yy) «adaptador » del anex o IC 
cuando no result e posible mecánicament e instalar ningún otro tipo de sensor de movimiento existe nte 
que por su parte cumpla las disposiciones del present e anex o y sus apéndices 1 a 16. 
El adapt ador 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 interfaces altern ativas. 
ADA_002 En la caja del adaptador se colocará un sensor de movimiento homologado (con arreglo a las disposi ­
ciones del present e anex o IC, sección 8, Homologación de aparat os de control y tarjetas de tacógraf o) 
junto con un procesador de impulsos que inducirá los impulsos de entrada al sensor de movimiento 
integrado. El propio sensor de movimient o integrad o estará conectado a la VU, de tal modo que la 
interfaz entre la VU y el adapta dor cumpli rá los requisitos de la norma ISO16844-3. 
2.2.  Funciones 
ADA_003  El adap tador 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 movimient o integrad o, 
—  todas las funciones del sensor de movimient o integra do, proporcionando datos de movimient o 
seguros a la VU. 
2.3.  Segur idad 
ADA_004  El adaptador no obtendrá la certificación de segur idad de acuerdo con el objetivo genér ico de 
segur idad del sensor de movimient o definido en el apéndice 10 del present e anex o. En su lugar serán 
de aplicación los requisitos de segur idad establecidos en la sección 4.4 del present e apéndice. 
3.  REQUISITOS REL ATIVOS AL APARA TO DE CONTR OL EQUIP ADO CON UN ADAPT ADOR 
Los requisitos que figuran en los siguient es capítulos explican cómo deben entenderse los requisitos del present e 
anex o cuando se utiliza un adapt ador . Los números de requisito correspondientes del anex o IC se indican entre 
paréntes is. 
ADA_005  El aparato de control de todo vehículo que esté equipado con un adapta dor debe cumpli r toda s las 
disposiciones del present e anex o, a menos que se especifique otra cosa en el presente apéndice. 
ADA_006  Cuando se instala un adap tador , el aparato de control incluye los cables, el adap tador (incluido un 
sensor de movimient o) y una VU (01). 
ADA_007  La función de detección de incident es o fallos del aparat o de control se modific a como sigue: 
—  El incident e «Interrupción del suministro eléctr ico» es activado por la VU cuando el suministro 
eléctr ico del sensor de movimient o integrad o se interrumpe durant e más de 200 milisegundos, 
fuera del modo de calibrado (79). 
—  El incident e «Error de datos de movimiento» es activado por la VU en caso de interr upción del 
flujo normal de datos entre el sensor de movimient o integrado y la VU, o en caso de producirse 
un error de integridad o de aute nticación de datos durant e el intercambio de datos entre el sensor 
de movimient o integrad o y la VU (83). 26.5.2016 L 139/502 Diar io Oficial de la Unión Europea ES    
—  El incident e «Intento de violación de la segur idad» es activado por la VU ante cualquier otro 
incidente que afecte a la segur idad 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 
incor porado, fuera del modo de calibrado (88). 
ADA_008  Los fallos del adapt ador que podrá detectar el aparato de control serán los relativ os al sensor de 
movimient o integrado (88). 
ADA_009  La función de calibrado de la VU permitirá el emparej amiento automático del sensor de movimiento 
integrado con la VU (202, 204). 
4.  CONDICIONES DE FABRICA CIÓN Y FUNCIONAMIENTO DEL ADAPT ADOR 
4.1.  Interconexión y adaptac ión de los impulsos de velocidad de entrada 
ADA_011  La interfaz de entrada del adapta dor acep tará impulsos de frecuencia que representarán la velocidad 
del vehículo y la distancia recor rida. Las caracte rísticas eléctr icas de los impulsos de entrada serán: a 
discr eción del fabricante. Los ajustes accesibles solamente al fabricant e del adapta dor y al taller 
autorizado que efectúa la instalación del adapt ador permitirán, en su caso, la interconexión correcta 
de la entrada del adap tador al vehículo. 
ADA_012  La interfaz de la entrada del adapt ador 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 adap tar la señal a la 
gama de valores del factor k definida en el present e anex o (4 000 a 25 000 impulsos/km). Sólo el 
fabricante del adap tador y el taller autor izado que efectúa la instalación del adap tador podrán 
programar este factor fijo. 
4.2.  Inducción de los impulsos de entrada al sensor de movimiento integ rado 
ADA_013  Los imp ulsos de entrada, adaptados posiblemente con arreglo a lo expuest o anterior mente, serán 
inducidos al sensor de movimiento integra do, de modo que cada impulso de entrada será detectado 
por el sensor . 
4.3.  Sensor de movimiento integ rado 
ADA_014  El sensor de movimient o integrado será estimulado por los impulsos inducidos, lo que le permitirá 
generar datos de movimiento 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 identif icación del sensor de movimiento integrado para identificar el 
adap tador (95). 
ADA_016  Se considerará que los datos de instalación almacenados en el sensor de movimient o integrado 
representan los datos de instalación del adaptador (122). 
4.4.  Requisitos de segur idad 
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 detec tarse con facilid ad (por ejemplo, mediante inspección visual, véase 
ADA_035). Los precint os deberán cumpli r los mismos requisitos que los precint os del sensor de 
movimient o (398 a 406). 
ADA_018  Será imposible retirar el sensor de movimient o integrad o del adaptador sin romper el precint o o 
precint os de la caja del adapta dor o el precint o entre el sensor y la caja del adap tador (véase 
ADA_034). 
ADA_019  El adap tador garant izará que los datos de movimient o solo se puedan procesar y extraer de la entrada 
del adapt ador . 26.5.2016 L 139/503 Diar io Oficial de la Unión Europea ES    
4.5.  Caracterís ticas de funcionamiento 
ADA_020  El adap tador funcionará perfectamente en el inter valo de temperaturas deter minado por el fabricante. 
ADA_021  El adap tador funcionará perfectamente en el inter valo higrométr ico del 10 % al 90 % (214). 
ADA_022  El adap tador estará protegido frente a sobreten siones, inversiones de polar idad de la fuente de 
alimentación y cortocircuitos (216). 
ADA_023  Los adap tadores: 
—  reaccionarán a todo campo magnético que perturbe la detección de movimiento del vehículo; en 
estas circunstancias, la unidad instalada en el vehículo registrará y almacenará un fallo del sensor 
(88), o bien 
—  estarán dotados de un sensor protegido de los campos magnéticos o invulnerable a estos (217). 
ADA_024  El adapt ador se ajustará a la regulación internacional en el Reglamento n.o 10 de la CEPE de las 
Naciones Unidas, relativa a la compatibilidad electromagnética, y deberá estar prot egido contra 
descarg as electromagnéticas y fluctuaciones de la tensión (218). 
4.6.  Mater iales 
ADA_025  El adap tador tendrá la clase de prot ección (a discr eción del fabricante, dependiendo de la posición de 
instalación) (220, 221). 
ADA_026  La caja del adaptador será de color amar illo. 
4.7.  Inscr ipciones 
ADA_027  El adap tador llevará una placa descr iptiva con la información siguient e: 
—  nombre y domicilio del fabr icante del adap tador , 
—  número de pieza del fabricante y año de fabricación del adap tador , 
—  marca de homologació n del modelo de adapta dor o del aparato de control que incluy e el 
adaptador , 
—  fecha de instalación del adaptador , 
—  VIN del vehículo en el que se ha instalado. 
ADA_028  Además, la placa descr iptiv a deberá contener la información siguient e (si no es legible directament e 
desde fuera del sensor de movimient o integra do): 
—  nombre del fabricante del sensor de movimient o integrado, 
—  número de pieza del fabricante y año de fabricación del sensor de movimient o integra do, 
—  marca de homolog ación del sensor de movimiento integrado. 
5.  INST ALACIÓN DEL APARA TO DE CONTR OL EQUIP ADO CON UN ADAPT ADOR 
5.1.  Inst alación 
ADA_029  Los adap tadores destinados a los vehículos solo podrán ser instalados por los fabricantes de vehículos, 
o por talleres autori zados para instalar , activar y calibrar tacógraf os digitales y tacógraf os intelig entes. 
ADA_030  El taller autor izado que instale el adap tador ajustará la interfaz de entrada y seleccionará el factor de 
división de la señal de entrada (si procede). 26.5.2016 L 139/504 Diar io Oficial de la Unión Europea ES    
ADA_031  El taller autorizado que instale el adap tador precintará su caja. 
ADA_032  El adap tador 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 (carg a positiva) y negros (tier ra). 
5.2.  Precintos 
ADA_034  Serán de aplicación los siguiente s requisitos de precintado: 
—  se precintará la caja del adaptador (véase ADA_017), 
—  se colocará un precint o entre la caja del sensor integrado y la caja del adap tador , a menos que sea 
imposible retirar el sensor integrado sin rompe r el precinto o los precint os de la caja del adapta dor 
(véase ADA_018), 
—  se colocará un precint o entre la caja del adap tador y el vehículo, 
—  la conexión entre el adap tador y el equipo que proporciona sus impulsos de entrada se precintará 
en ambos extremos (en la medida de lo razonablemente posible). 
6.  VERIFICA CIONES, CONTR OLES Y REPARA CIONES 
6.1.  Controles periódicos 
ADA_035  Cuando se utilice un adap tador , en cada control periódico (controles periódicos son aquellos que se 
ajustan a los requisitos (409) a (413) del anex o IC) del aparato de control, se verificará lo siguiente: 
—  si el adapta dor lleva las inscr ipciones de homologación adecuadas, 
—  si están intactos los precintos del adap tador y sus conexiones, 
—  si el adapta dor está instalado de acuerdo con las indicaciones de la placa de instalación, 
—  si el adaptador está instalado con arreglo a las especificaciones del fabr icante del adap tador o del 
vehículo, 
—  si está autorizado el montaje de un adap tador 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.  HOMOLOGA CIÓN DEL APARA TO DE CONTR OL EQUIP ADO CON UN ADAPT ADOR 
7.1.  Aspect os generales 
ADA_037  El aparat o de control se presentará compl eto a la homologació n, provisto del adaptador (425). 
ADA_038  Todo adaptador podrá presentarse a su propia homologació n o a la homologació n como component e 
de un aparat o de control. 
ADA_039  La homolog ación incluirá los ensa yos funcionales del adaptador . El resultado positiv o de cada uno de 
estos ensa yos se consignará en un certificado (426). 26.5.2016 L 139/505 Diar io Oficial de la Unión Europea ES    
7.2.  Cer tificado funcional 
ADA_040  Se entregar á al fabr icante del adaptador un certificado funcional del adap tador o del aparat o de 
control provisto de un adap tador una vez superados los siguiente s ensa yos funcionales mínimos. 
N.o Ensa yo Descr ipción Requisitos correspondientes 
1. Exa men administ rativ o 
1.1 Documentación Corrección de la documentación del adap tador  
2. Inspección visual 
2.1. Conf ormidad del adap tador con la documentación  
2.2. Identif icación/inscr ipciones del adaptador ADA_027, ADA_028 
2.3 Materi ales del adaptador (219) a (223) 
ADA_026 
2.4. Precintos ADA_017, ADA_018, 
ADA_034 
3. Ensay os funcionales 
3.1 Inducción de los impulsos de velocidad al sensor de movimient o integrad o ADA_013 
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 movimient o (30) a (35), (217) 
4. Ensay os ambientales 
4.1 Resultados de ensa yo del fabri­
cante Resultados de los ensa yos ambientales del fabri­
cant e. ADA_020, ADA_021, 
ADA_022, ADA_024 
5. EMC 
5.1 Emisiones radiadas y suscep ti­
bilidad Verificar cumpli miento de la Directiva 
2006/28/CE ADA_024 
5.2 Resultados de ensa yo del fabri­
cante Resultados de los ensa yos ambientales del fabri­
cant e. ADA_024   26.5.2016 L 139/506 Diar io Oficial de la Unión Europea ES