Anúnciate en Noticias Jurídicas Newsletter Colabora con nosotros

TIENDA LA LEY

LA LEY. Librería Jurídica Online Profesional

TIENDA LIBROS FORMACIÓN BASES DE DATOS REVISTAS SOFTWARE DE GESTIÓN OBRAS ACTUALIZABLES

Base de Datos de Legislaci髇

Reglamento de Ejecuci髇 (UE) 2018/502 de la Comisi髇, de 28 de febrero de 2018, por el que se modifica el Reglamento de Ejecuci髇 (UE) 2016/799 que establece los requisitos para la construcci髇, ensayo, instalaci髇, funcionamiento y reparaci髇 de los tac骻rafos y de sus componentes

Ficha:
  • 觬gano COMISION EUROPEA
  • Publicado en DOUEL n鷐. 85 de
  • Vigencia desde 17 de Abril de 2018
Versiones/revisiones:

Sumario

LA COMISI覰 EUROPEA,

Visto el Tratado de Funcionamiento de la Uni髇 Europea,

Visto el Reglamento (UE) n. 165/2014 del Parlamento Europeo y del Consejo, de 4 de febrero de 2014, relativo a los tac骻rafos en el transporte por carretera (1) , y en particular su art韈ulo 11 y su art韈ulo 12, apartado 7,

Considerando lo siguiente:

  • (1) El Reglamento (UE) n. 165/2014 introdujo los tac骻rafos inteligentes -tac骻rafos digitales de segunda generaci髇-, que incluyen una conexi髇 con el dispositivo GNSS (sistema mundial de radionavegaci髇 por sat閘ite), un dispositivo de comunicaci髇 a efectos de teledetecci髇 temprana y una interfaz opcional con sistemas de transporte inteligentes.
  • (2) Los requisitos t閏nicos para la construcci髇, ensayo, instalaci髇, funcionamiento y reparaci髇 de los tac骻rafos y de sus componentes se establecen en el Reglamento de Ejecuci髇 (UE) 2016/799 de la Comisi髇 (2) .
  • (3) De conformidad con los art韈ulos 8, 9 y 10 del Reglamento (UE) n. 165/2014, a partir del 15 de junio de 2019 los tac骻rafos instalados en veh韈ulos matriculados por primera vez deben ser tac骻rafos inteligentes. Debe, por tanto, modificarse el Reglamento de Ejecuci髇 (UE) 2016/799 de modo que las provisiones t閏nicas establecidas en 閘 se apliquen a partir de esa fecha.
  • (4) A fin de cumplir lo dispuesto en el art韈ulo 8 del Reglamento (UE) n. 165/2014, que establece que la posici髇 del veh韈ulo debe registrarse cada tres horas de tiempo de conducci髇 acumulado, el Reglamento de Ejecuci髇 (UE) 2016/799 debe modificarse de modo que posibilite que la informaci髇 sobre la posici髇 del veh韈ulo se almacene con una frecuencia de tres horas, utilizando un sistema de medici髇 que no pueda reinicializarse, y que se evite as una confusi髇 con la noci髇 de 玹iempo de conducci髇 continua, que es un par醡etro con una funci髇 diferente.
  • (5) La unidad instalada en el veh韈ulo puede consistir en una sola unidad o en varias unidades repartidas por el veh韈ulo. Los dispositivos GNSS y DSRC (comunicaciones especializadas de corto alcance) pueden, por tanto, ser tanto internos como externos con respecto al cuerpo principal de la unidad instalada en el veh韈ulo. Si son externos, debe ser posible que ambos dispositivos y el cuerpo principal de la unidad instalada en el veh韈ulo sean homologados como componentes, con el fin de adaptar el proceso de homologaci髇 de los tac骻rafos inteligentes a las necesidades del mercado.
  • (6) Las normas sobre el almacenamiento de incidentes de conflicto temporal y ajustes de la hora deben modificarse, a fin de distinguir entre los ajustes de hora autom醫icos, que se producen a ra韟 de un posible intento de manipulaci髇 o de un fallo en el funcionamiento del tac骻rafo, y los ajustes debidos a otras razones, como su mantenimiento.
  • (7) Los identificadores de datos deben poder distinguir entre los datos transferidos desde un tac骻rafo inteligente y los transferidos desde un tac骻rafo de una generaci髇 anterior.
  • (8) El per韔do de validez de la tarjeta de empresa debe ampliarse de dos a cinco a駉s, para igualarlo con el per韔do de validez de la tarjeta de conductor.
  • (9) Debe definirse mejor la descripci髇 de determinados fallos e incidentes, la validaci髇 de la introducci髇 de los lugares donde comienzan o terminan los per韔dos de trabajo diarios y la utilizaci髇 del consentimiento del conductor en la interfaz con sistemas de transporte inteligentes (ITS), por lo que respecta a los datos transmitidos por la unidad instalada en el veh韈ulo a trav閟 de la red del veh韈ulo, as como otros aspectos t閏nicos.
  • (10) Para garantizar que la certificaci髇 de los precintos del tac骻rafo est actualizada, estos han de adaptarse a la nueva norma sobre la seguridad de los precintos mec醤icos utilizados en los tac骻rafos.
  • (11) El presente Reglamento afecta a la construcci髇, ensayo, instalaci髇 y funcionamiento de sistemas que constan tambi閚 de equipos radioel閏tricos, regulados por la Directiva 2014/53/UE del Parlamento Europeo y del Consejo (3) . Dicha Directiva regula la comercializaci髇 y puesta en servicio de equipos el閏tricos y electr髇icos que utilizan ondas radioel閏tricas a fines de radiocomunicaci髇 o radiodeterminaci髇 a nivel horizontal, por lo que se refiere, en particular, a la seguridad el閏trica, la compatibilidad con otros sistemas, el acceso al espectro radioel閏trico, el acceso a servicios de emergencia o cualquier otra disposici髇 delegada. A fin de garantizar el uso eficiente del espectro radioel閏trico, evitar interferencias radioel閏tricas perjudiciales, garantizar la seguridad y la compatibilidad electromagn閠ica de los equipos radioel閏tricos y respetar cualquier otro requisito delegado, el presente Reglamento se entender sin perjuicio de las disposiciones de esa Directiva.
  • (12) Procede, por tanto, modificar el Reglamento de Ejecuci髇 (UE) 2016/799 en consecuencia.
  • (13) Las medidas previstas en el presente Reglamento se ajustan al dictamen del Comit a que se refiere el art韈ulo 42, apartado 3, del Reglamento (UE) n. 165/2014.

HA ADOPTADO EL PRESENTE REGLAMENTO:

Art韈ulo 1

El Reglamento de Ejecuci髇 (UE) 2016/799 queda modificado como se indica a continuaci髇:

  • 1) El art韈ulo 1 se modifica como sigue:
    • a) los apartados 2 y 3 se sustituyen por el texto siguiente:

      2. La construcci髇, ensayo, instalaci髇, inspecci髇, funcionamiento y reparaci髇 de los tac骻rafos inteligentes y sus componentes deber醤 cumplir los requisitos t閏nicos establecidos en el anexo IC del presente Reglamento.

      3. Los tac骻rafos distintos de los tac骻rafos inteligentes seguir醤 teniendo que cumplir, en lo que se refiere a las condiciones de construcci髇, ensayo, instalaci髇, inspecci髇, funcionamiento y reparaci髇, los requisitos establecidos en el anexo I del Reglamento (UE) n. 165/2014 o en el anexo IB del Reglamento (CEE) n. 3821/85 del Consejo (4) , seg鷑 proceda.

      Ir a Norma afectada
    • b) se a馻de el apartado 5 siguiente:

      5. El presente Reglamento se entender sin perjuicio de la Directiva 2014/53/UE del Parlamento Europeo y del Consejo (5) .

      Ir a Norma afectada
  • 2) El art韈ulo 2 se modifica como sigue:
    • a) la definici髇 3 se sustituye por el texto siguiente:
      • 3) “expediente del fabricante”: la documentaci髇 completa, en formato electr髇ico o en papel, que contiene toda la informaci髇 facilitada por el fabricante o su agente a la autoridad de homologaci髇 a efectos de la homologaci髇 de un tac骻rafo o de uno de sus componentes, incluidos los certificados a que se refiere el art韈ulo 12, apartado 3, del Reglamento (UE) n. 165/2014, los resultados de los ensayos definidos en el anexo IC del presente Reglamento, as como dibujos, fotograf韆s y dem醩 documentos pertinentes;
      Ir a Norma afectada
    • b) la definici髇 7 se sustituye por el texto siguiente:
      Ir a Norma afectada
    • c) la definici髇 8 se sustituye por el texto siguiente:
      • 8) “componente del tac骻rafo”: cualquiera de los elementos siguientes: la unidad instalada en el veh韈ulo, el sensor de movimiento, la tarjeta de tac骻rafo, la hoja de registro, el dispositivo GNSS externo y el dispositivo externo de teledetecci髇 temprana;
      Ir a Norma afectada
    • d) se a馻de la definici髇 10 siguiente:
      • 10) “unidad instalada en el veh韈ulo”: el tac骻rafo, excepto el sensor de movimiento y los cables que conectan dicho sensor.

        Puede consistir en una sola unidad o en varias unidades repartidas por el veh韈ulo, e incluye una unidad de procesamiento, una memoria de datos, una funci髇 de medici髇 de la hora, dos dispositivos de interfaz de tarjeta inteligente para el conductor y el segundo conductor, una impresora, una pantalla, conectores y dispositivos para que el usuario introduzca datos, un receptor GNSS y un dispositivo de comunicaci髇 a distancia.

        La unidad instalada en el veh韈ulo puede estar compuesta de los siguientes componentes sujetos a homologaci髇:
        • - la unidad instalada en el veh韈ulo, como componente 鷑ico (con un receptor GNSS y un dispositivo de comunicaci髇 a distancia incluidos),
        • - el cuerpo principal de la unidad instalada en el veh韈ulo (con un dispositivo de comunicaci髇 a distancia incluido) y un dispositivo GNSS externo,
        • - el cuerpo principal de la unidad instalada en el veh韈ulo (con un receptor GNSS incluido) y un dispositivo de comunicaci髇 a distancia externo,
        • - el cuerpo principal de la unidad instalada en el veh韈ulo, un dispositivo GNSS externo y un dispositivo de comunicaci髇 a distancia externo.


        Si la unidad instalada en el veh韈ulo se compone de varias unidades repartidas por el veh韈ulo, el cuerpo principal es la unidad que contenga la unidad de procesamiento, la memoria de datos y la funci髇 de medici髇 de la hora.

        “unidad instalada en el veh韈ulo (VU)” se utiliza tanto para “unidad instalada en el veh韈ulo” como para “cuerpo principal de la unidad instalada en el veh韈ulo”.
      Ir a Norma afectada
  • 3) En el art韈ulo 6, el p醨rafo tercero se sustituye por el texto siguiente:

    Sin embargo, el anexo IC ser aplicable a partir del 15 de junio de 2019, a excepci髇 del ap閚dice 16, que ser aplicable a partir del 2 de marzo de 2016.

    Ir a Norma afectada
  • 4) El anexo IC se modifica de conformidad con el anexo I del presente Reglamento.
  • 5) El anexo II se modifica de conformidad con el anexo II del presente Reglamento.

Art韈ulo 2 Entrada en vigor

El presente Reglamento entrar en vigor a los veinte d韆s de su publicaci髇 en el Diario Oficial de la Uni髇 Europea.

El presente Reglamento ser obligatorio en todos sus elementos y directamente aplicable en cada Estado miembro.

Hecho en Bruselas, el 28 de febrero de 2018.

 Por la Comisi髇

 El Presidente

 Jean-Claude JUNCKER

ANEXO I

El anexo IC del Reglamento (UE) 2016/799 se modifica como sigue:

  • 1) El 韓dice queda modificado como sigue:
    • a) el apartado 3.12.5 se sustituye por el texto siguiente:

      3.12.5. Lugares y posiciones donde comienzan o terminan los per韔dos de trabajo diarios y/o donde se alcanzan las tres horas de tiempo de conducci髇 acumulado

    • b) el apartado 4.5.3.2.16 se sustituye por el texto siguiente:

      4.5.3.2.16. Datos sobre lugares en tres horas de conducci髇 acumuladas

    • c) el apartado 4.5.4.2.14 se sustituye por el texto siguiente:

      4.5.4.2.14. Datos sobre lugares en tres horas de conducci髇 acumuladas

    • d) el apartado 6.2 se sustituye por el texto siguiente:

      6.2. Verificaci髇 de componentes nuevos o reparados

  • 2) El apartado 1 se modifica como sigue:
    • a) la definici髇 ll) se sustituye por el texto siguiente:
      • ll) Dispositivo de comunicaci髇 a distancia o dispositivo de teledetecci髇 temprana:

        Equipo de la unidad instalada en el veh韈ulo que se utiliza para realizar controles de carretera selectivos.
      Ir a Norma afectada
    • b) la definici髇 tt) se sustituye por el texto siguiente:
      • tt) ajuste de la hora:

        Ajuste de la hora actual; este ajuste puede realizarse de manera autom醫ica a intervalos regulares, utilizando como referencia la hora que proporciona el receptor GNSS, o efectuarse durante el calibrado.
      Ir a Norma afectada
    • c) el primer guion de la definici髇 yy) se sustituye por el texto siguiente:
      • - se instala y utiliza exclusivamente en veh韈ulos de las categor韆s M1 y N1 (seg鷑 se definen en el anexo II de la Directiva 2007/46/CE del Parlamento Europeo y del Consejo (*), en su versi髇 modificada m醩 reciente);
      Ir a Norma afectada
    • d) se a馻de una nueva definici髇 fff):
      • fff) tiempo de conducci髇 acumulado:

        Valor que representa el n鷐ero total de minutos de conducci髇 acumulados de un veh韈ulo determinado.

        El valor del tiempo de conducci髇 acumulado es un recuento sin sincronizar de todos los minutos considerados como actividad de CONDUCCI覰 por la funci髇 de supervisi髇 de las actividades de conducci髇 del aparato de control, y solo se utiliza para poner en marcha el registro de la posici髇 del veh韈ulo, cada vez que se alcanza un m鷏tiplo de tres horas de conducci髇 acumuladas. La acumulaci髇 se inicia cuando se activa el aparato de control. No se ve afectada por ninguna otra condici髇, como “Fuera de 醡bito” o “Trayecto en transbordador/tren”.

        El tiempo de conducci髇 acumulado es un valor que no est destinado a mostrarse en pantalla, imprimirse ni transferirse.
      Ir a Norma afectada
  • 3) En el apartado 2.3, el 鷏timo guion del punto 13 se sustituye por el texto siguiente:
    • - el per韔do de validez operativa normal de las unidades instaladas en veh韈ulos es de quince a駉s a partir de la fecha efectiva de los certificados de dichas unidades, pero podr醤 utilizarse durante tres meses adicionales solo para la transferencia de datos..
    Ir a Norma afectada
  • 4) En el apartado 2.4, el p醨rafo primero se sustituye por el texto siguiente:

    La seguridad del sistema tiene por objeto proteger la memoria de datos, de manera que se evite el acceso a la misma de terceros no autorizados, se excluya la manipulaci髇 de informaci髇 y se detecte cualquier tentativa en ese sentido; as se protege la integridad y autenticidad de los datos intercambiados entre el sensor de movimiento y la unidad instalada en el veh韈ulo, de los datos intercambiados entre el aparato de control y las tarjetas de tac骻rafo y de los datos intercambiados entre la unidad instalada en el veh韈ulo y el dispositivo GNSS externo, de existir este, se protege la confidencialidad, integridad y autenticidad de los datos intercambiados a trav閟 de la comunicaci髇 de teledetecci髇 temprana con fines de control y se verifica la integridad y autenticidad de los datos transferidos.

    Ir a Norma afectada
  • 5) En el apartado 3.2, el segundo guion del punto 27 se sustituye por el texto siguiente:
    • - las posiciones en que el tiempo de conducci髇 acumulado llega a un m鷏tiplo de tres horas;
    Ir a Norma afectada
  • 6) En el apartado 3.4, el punto 49 se sustituye por el texto siguiente:
    • 49) Si el primer cambio de actividad a PAUSA/DESCANSO o DISPONIBILIDAD tiene lugar antes de que hayan transcurrido 120 segundos tras haber cambiado autom醫icamente a TRABAJO por haberse detenido el veh韈ulo, se entender que ha tenido lugar a la hora en que se detuvo el veh韈ulo (por consiguiente, podr韆 cancelar el cambio a TRABAJO).
    Ir a Norma afectada
  • 7) En el apartado 3.6.1, el punto 59 se sustituye por el texto siguiente:
    • 59) El conductor deber introducir entonces el lugar en que se encuentra actualmente el veh韈ulo, que se considerar una entrada temporal.

      Si se cumplen las siguientes condiciones, se valida la entrada temporal efectuada en la 鷏tima extracci髇 de la tarjeta (es decir, ya no se sobrescribir):
      • - introducci髇 de un lugar donde comienza el per韔do de trabajo diario actual durante la introducci髇 manual de conformidad con el requisito 61;
      • - la siguiente introducci髇 de un lugar donde comienza el per韔do de trabajo diario actual, si el titular de la tarjeta no introduce el lugar donde comienza o finaliz el per韔do de trabajo durante la introducci髇 manual de conformidad con el requisito 61.


      Si se cumplen las siguientes condiciones, se sobrescribe la entrada temporal efectuada en la 鷏tima extracci髇 de la tarjeta y se valida el nuevo valor:
      • - la siguiente introducci髇 de un lugar donde finaliza el per韔do de trabajo diario actual, si el titular de la tarjeta no introduce el lugar donde comienza o finaliz el per韔do de trabajo durante la introducci髇 manual de conformidad con el requisito 61.
    Ir a Norma afectada
  • 8) En el apartado 3.6.2, los guiones sexto y s閜timo se sustituyen por el texto siguiente:
    • - un lugar en que haya terminado un per韔do de trabajo diario precedente, asociado a la hora pertinente (sobrescribiendo y validando as la entrada realizada con motivo de la 鷏tima extracci髇 de la tarjeta), o
    • - un lugar en que comienza el per韔do de trabajo diario actual, asociado a la hora pertinente (validando as una entrada temporal realizada con motivo de la 鷏tima extracci髇 de la tarjeta)..
    Ir a Norma afectada
  • 9) El apartado 3.9.15 se sustituye por el texto siguiente:

    3.9.15. Incidente “Conflicto temporal”

    • 86) Este incidente se produce cuando, fuera del modo de calibrado, la VU detecta una discrepancia de m醩 de un minuto entre la hora de la funci髇 de medici髇 de la hora de la unidad instalada en el veh韈ulo y la hora procedente del receptor GNSS. Este incidente se registra junto con el valor del reloj interno de la unidad instalada en el veh韈ulo y va acompa馻do de un ajuste de la hora autom醫ico. Despu閟 de haberse producido un incidente de conflicto temporal, la VU no generar m醩 incidentes del mismo tipo durante las doce horas siguientes. Este incidente no se producir cuando no hubiera una se馻l GNSS v醠ida detectable por el receptor GNSS en los 鷏timos treinta d韆s o m醩.
    Ir a Norma afectada
  • 10) En el apartado 3.9.17 se a馻de el siguiente guion:
    • - fallo de la interfaz ITS (si procede).
    Ir a Norma afectada
  • 11) El apartado 3.10 se modifica como sigue:
    • i) el texto que precede al cuadro del punto 89 se sustituye por el siguiente:

      (no afecta a la versi髇 espa駉la)

    • ii) en el cuadro, se a馻de la fila siguiente:

      Interfaz ITS (opcional) Funcionamiento correcto

    Ir a Norma afectada
  • 12) En el apartado 3.12, el segundo guion se sustituye por el texto siguiente:
    • - El n鷐ero medio de posiciones por d韆 se define como al menos 6 posiciones en las que comienza el per韔do de trabajo diario, 6 posiciones en las que el tiempo de conducci髇 acumulado del conductor llega a un m鷏tiplo de tres horas, y 6 posiciones en las que termina el per韔do de trabajo diario, por lo que “365 d韆s” incluyen al menos 6570 posiciones.
    Ir a Norma afectada
  • 13) El apartado 3.12.5 se modifica como sigue:
    • a) el t韙ulo y el apartado 108 se sustituyen por el texto siguiente:

      3.12.5. Lugares y posiciones donde comienzan o terminan los per韔dos de trabajo diarios y/o donde se alcanzan las tres horas de tiempo de conducci髇 acumulado

      • 108) El aparato de control deber registrar y almacenar en su memoria de datos:
        • - los lugares y las posiciones en que el conductor y/o el segundo conductor comienzan su per韔do de trabajo diario;
        • - las posiciones en que el tiempo de conducci髇 acumulado llega a un m鷏tiplo de tres horas;
        • - los lugares y las posiciones en que el conductor y/o el segundo conductor finalizan su per韔do de trabajo diario.
      Ir a Norma afectada
    • b) el cuarto guion del punto 110 se sustituye por el texto siguiente:
      • - el tipo de entrada (comienzo, final o tres horas de tiempo de conducci髇 acumulado),
      Ir a Norma afectada
    • c) el punto 111 se sustituye por el texto siguiente:
      • 111) La memoria de datos deber ser capaz de mantener almacenados durante al menos 365 d韆s los lugares y posiciones en que comienzan o finalizan los per韔dos de trabajo diarios y/o se alcanzan las tres horas de tiempo de conducci髇 acumulado.
      Ir a Norma afectada
  • 14) En el apartado 3.12.7, el punto 116 se sustituye por el texto siguiente:

    (no afecta a la versi髇 espa駉la)

  • 15) En el apartado 3.12.8, el cuadro queda modificado como sigue:
    • a) se inserta el siguiente elemento entre los elementos 獳usencia de informaci髇 sobre la posici髇 procedente del receptor GNSS y 獷rror en datos de movimiento:
      Error de comunicaci髇 con el dispositivo GNSS externo

      - el incidente de mayor duraci髇 ocurrido cada uno de los 鷏timos diez d韆s,

      - los cinco incidentes de mayor duraci髇 ocurridos en los 鷏timos 365 d韆s

      .

      		 -fecha y hora de comienzo del incidente,
      - fecha y hora de finalizaci髇 del incidente,
      - tipo de tarjeta(s), n鷐ero, Estado miembro emisor y generaci髇 de cualquier tarjeta insertada al comenzar o al terminar el incidente,
      - n鷐ero de incidentes similares ocurridos ese d韆.
    • b) el elemento 獵onflicto temporal se sustituye por el texto siguiente:
      Conflicto temporal

      -el incidente m醩 grave ocurrido cada uno de los 鷏timos diez d韆s (es decir, los que presentan mayor diferencia entre la fecha y hora del aparato de control y la fecha y hora del GNSS),

      - los cinco incidentes m醩 graves ocurridos en los 鷏timos 365 d韆s,

      		 - fecha y hora del aparato de control,
      - fecha y hora del GNSS,
      - tipo de tarjeta(s), n鷐ero, Estado miembro emisor y generaci髇 de cualquier tarjeta insertada al comenzar o al terminar el incidente,
      - n鷐ero de incidentes similares ocurridos ese d韆.
    Ir a Norma afectada
  • 16) En el apartado 3.20, el punto 200 se sustituye por el texto siguiente:
    • 200) El aparato de control podr ir tambi閚 equipado de interfaces normalizadas que permitan que un aparato externo utilice en modo operativo o de calibrado los datos registrados o producidos por el tac骻rafo.

      En el ap閚dice 13 se especifica y normaliza una interfaz ITS opcional. Podr醤 coexistir otras interfaces de la unidad instalada en el veh韈ulo, siempre que se cumplan plenamente los requisitos del ap閚dice 13 en t閞minos de lista m韓ima de datos, seguridad y consentimiento del conductor.

      El consentimiento del conductor no se aplica a los datos transmitidos por el aparato de control a la red del veh韈ulo. En caso de que los datos personales inyectados en la red del veh韈ulo sean luego procesados fuera de dicha red, es responsabilidad del fabricante del veh韈ulo que el tratamiento de datos personales sea conforme con el Reglamento (UE) 2016/679 (“Reglamento general de protecci髇 de datos”).

      El consentimiento del conductor tampoco se aplica a los datos del tac骻rafo transferidos a una empresa a distancia (requisito 193), dado que este caso est sujeto al derecho de acceso de las tarjetas de empresa.

      Se aplicar醤 los siguientes requisitos a los datos de ITS facilitados a trav閟 de esa interfaz:
      • - estos datos constituir醤 una selecci髇 de los datos existentes a partir del diccionario de datos del tac骻rafo (ap閚dice 1),
      • - un subconjunto de esta selecci髇 de datos se identificar como “datos personales”,
      • - el subconjunto de “datos personales” solo estar disponible si est habilitado el consentimiento verificable del conductor, aceptando que sus datos personales puedan abandonar la red del veh韈ulo,
      • - en cualquier momento, podr habilitarse o inhabilitarse el consentimiento del conductor a trav閟 de comandos del men, siempre que est insertada la tarjeta de conductor,
      • - la selecci髇 y el subconjunto de datos se emitir醤 a trav閟 del protocolo inal醡brico Bluetooth en el radio de la cabina del veh韈ulo, con una frecuencia de refresco de un minuto,
      • - el emparejamiento del dispositivo exterior con la interfaz ITS estar protegido por un PIN aleatorio y dedicado de al menos cuatro d韌itos, registrado y disponible a trav閟 de la pantalla de cada unidad instalada en el veh韈ulo,
      • - en ninguna circunstancia podr la presencia de la interfaz ITS perturbar ni alterar el correcto funcionamiento y la seguridad de la unidad instalada en el veh韈ulo.


      Tambi閚 se podr醤 enviar otros datos, adem醩 de la selecci髇 de datos existentes, que se considera la lista m韓ima, siempre que no se puedan considerar datos personales.

      El aparato de control deber ser capaz de comunicar el estado del consentimiento del conductor a otras plataformas de la red del veh韈ulo.

      Cuando el encendido del veh韈ulo est activado (ON), estos datos se enviar醤 de manera permanente..
    Ir a Norma afectada
  • 17) En el apartado 3.23, el punto 211 se sustituye por el texto siguiente:
    • 211) La hora del reloj interno de la VU se reajustar autom醫icamente cada doce horas. Cuando este reajuste no sea posible porque no se disponga de se馻l GNSS, se fijar la hora tan pronto como la VU pueda acceder a una hora v醠ida facilitada por el receptor GNSS, seg鷑 las condiciones de encendido del veh韈ulo. La referencia temporal para la fijaci髇 autom醫ica de la hora del reloj interno de la VU se derivar del receptor GNSS..
    Ir a Norma afectada
  • 18) En el apartado 3.26, los puntos 225 y 226 se sustituyen por el texto siguiente:
    • 225) Cada uno de los componentes del aparato de control deber llevar una placa descriptiva con la informaci髇 siguiente:
      • - nombre y direcci髇 del fabricante,
      • - n鷐ero de pieza del fabricante y a駉 de fabricaci髇,
      • - n鷐ero de serie,
      • - marca de homologaci髇.
    • 226) Cuando el espacio f韘ico disponible no baste para mostrar todas las informaciones mencionadas, en la placa descriptiva deber figurar al menos el nombre o el logotipo del fabricante y el n鷐ero de pieza..
    Ir a Norma afectada
  • 19) En el apartado 4.1, el dibujo correspondiente al anverso y el reverso de la tarjeta de conductor se sustituye por el siguiente:

    Ir a Norma afectada
  • 20) En el apartado 4.5.3.1.8, el primer guion del punto 263 se sustituye por el texto siguiente:
    • - fallo de la tarjeta (cuando esa tarjeta sea el tema del fallo),.
    Ir a Norma afectada
  • 21) En el apartado 4.5.3.2.8, el primer guion del punto 288 se sustituye por el texto siguiente:
    • - fallo de la tarjeta (cuando esa tarjeta sea el tema del fallo),
    Ir a Norma afectada
  • 22) El apartado 4.5.3.2.16 se sustituye por el texto siguiente:

    4.5.3.2.16. Datos sobre lugares en tres horas de conducci髇 acumuladas

    • 305) La tarjeta de conductor deber ser capaz de almacenar los siguientes datos relativos a la posici髇 del veh韈ulo cuando el tiempo de conducci髇 acumulado alcance un m鷏tiplo de tres horas:
      • - fecha y hora en las que el tiempo de conducci髇 acumulado llega a un m鷏tiplo de tres horas,
      • - posici髇 del veh韈ulo,
      • - la exactitud del GNSS, fecha y hora en que se haya determinado la posici髇,
      • - la lectura del cuentakil髆etros del veh韈ulo.
    • 306) La tarjeta de conductor deber ser capaz de almacenar al menos 252 de estos registros..
    Ir a Norma afectada
  • 23) El apartado 4.5.4.2.14 se sustituye por el texto siguiente:

    4.5.4.2.14. Datos sobre lugares en tres horas de conducci髇 acumuladas

    • 353) La tarjeta de taller deber ser capaz de almacenar los siguientes datos relativos a la posici髇 del veh韈ulo cuando el tiempo de conducci髇 acumulado alcance un m鷏tiplo de tres horas:
      • - fecha y hora en las que el tiempo de conducci髇 acumulado llega a un m鷏tiplo de tres horas,
      • - posici髇 del veh韈ulo,
      • - la exactitud del GNSS, fecha y hora en que se haya determinado la posici髇,
      • - la lectura del cuentakil髆etros del veh韈ulo.
    • 354) La tarjeta de taller deber ser capaz de almacenar al menos dieciocho de estos registros.
    Ir a Norma afectada
  • 24) En el apartado 5.2, el punto 396 se sustituye por el texto siguiente:
    • 396) En la placa deber醤 figurar, como m韓imo, los datos siguientes:
      • - nombre y domicilio o nombre comercial del instalador o taller autorizado,
      • - coeficiente caracter韘tico del veh韈ulo, en la forma “w = … imp/km”,
      • - constante del aparato de control, en la forma “k = … imp/km”,
      • - circunferencia efectiva de los neum醫icos de las ruedas, en la forma “l = … mm”,
      • - tama駉 de los neum醫icos,
      • - fecha del informe del coeficiente caracter韘tico del veh韈ulo y de la medida de la circunferencia efectiva de los neum醫icos de las ruedas,
      • - n鷐ero de identificaci髇 del veh韈ulo (VIN),
      • - presencia (o no) de un dispositivo GNSS externo,
      • - n鷐ero de serie del dispositivo GNSS externo, en su caso,
      • - n鷐ero de serie del dispositivo de comunicaci髇 a distancia, de existir este,
      • - n鷐ero de serie de todos los precintos existentes,
      • - parte del veh韈ulo en la que, en su caso, est instalado el adaptador,
      • - parte del veh韈ulo en la que est instalado el sensor de movimiento, si no est conectado a la caja de cambios o si no se utiliza un adaptador,
      • - descripci髇 del color del cable entre el adaptador y la parte del veh韈ulo que proporciona sus impulsos de entrada,
      • - n鷐ero de serie del sensor de movimiento integrado del adaptador.
    Ir a Norma afectada
  • 25) El apartado 5.3 se modifica como sigue:
    • a) se inserta un nuevo punto 398 bis tras el punto 398:
      • 398 bis) Los precintos antes mencionados deber醤 certificarse de conformidad con la norma EN 16882:2016.
      Ir a Norma afectada
    • b) en el punto 401, el p醨rafo segundo se sustituye por el texto siguiente:

      Este n鷐ero de identificaci髇 鷑ico se define del siguiente modo: MMNNNNNNNN mediante marcado que no se pueda retirar, siendo MM un identificador 鷑ico del fabricante (registro en base de datos gestionada por la CE) y NNNNNNNN un identificador alfanum閞ico del precinto, 鷑ico en el dominio del fabricante.

      Ir a Norma afectada
    • c) el punto 403 se sustituye por el texto siguiente:
      • 403) Los fabricantes de los precintos quedar醤 registrados en una base de datos espec韋ica cuando obtengan un modelo de precinto certificado de conformidad con la norma EN 16882:2016 y har醤 p鷅licos sus identificadores de precintos a trav閟 de un procedimiento que establecer la Comisi髇 Europea.
      Ir a Norma afectada
    • d) el punto 404 se sustituye por el texto siguiente:
      • 404) Los talleres autorizados y los fabricantes de veh韈ulos utilizar醤 鷑icamente, en el marco del Reglamento (UE) n. 165/2014, precintos certificados de conformidad con la norma EN 16882:2016 procedentes de los fabricantes de precintos recogidos en la base de datos mencionada anteriormente.
      Ir a Norma afectada
  • 26) El apartado 6.2 se sustituye por el texto siguiente:

    6.2. Verificaci髇 de componentes nuevos o reparados

    • 407) Cada dispositivo, tanto nuevo como reparado, deber verificarse individualmente en lo que se refiere a su correcto funcionamiento y a la exactitud de sus indicaciones y registros, dentro de los l韒ites establecidos en los apartados 3.2.1, 3.2.2, 3.2.3 y 3.3.
    Ir a Norma afectada
  • 27) En el apartado 6.3, el punto 408 se sustituye por el texto siguiente:
    • 408) En el momento de su instalaci髇 en un veh韈ulo, la instalaci髇 en su conjunto (incluido el aparato de control) deber ajustarse a las disposiciones sobre tolerancias m醲imas establecidas en los cap韙ulos 3.2.1, 3.2.2, 3.2.3 y 3.3. El conjunto de la instalaci髇 deber precintarse de conformidad con el cap韙ulo 5.3 e incluir un calibrado.
    Ir a Norma afectada
  • 28) El apartado 8.1 queda modificado como sigue:
    • a) el texto anterior al punto 425 se sustituye por el texto siguiente:

      A efectos del presente cap韙ulo, por “aparato de control” se entender el “aparato de control o sus componentes”. No ser preciso homologar el cable o cables que conectan el sensor de movimiento a la VU, el dispositivo GNSS externo a la VU o el dispositivo de comunicaci髇 a distancia externo a la VU. El papel que utilice el aparato de control se considerar un componente de dicho aparato.

      Todo fabricante podr solicitar la homologaci髇 de los componentes de su aparato de control con cualquier otro tipo de componentes de aparato de control, siempre que cada componente cumpla los requisitos del presente anexo. De manera alternativa, los fabricantes podr醤 tambi閚 solicitar la homologaci髇 del aparato de control.

      Tal como se describe en la definici髇 10 del art韈ulo 2 del presente Reglamento, existen diferentes variedades de unidades de veh韈ulo seg鷑 el montaje de sus componentes. Sea cual sea el montaje de los componentes de la unidad instalada en el veh韈ulo, la antena exterior y, en su caso, el separador de antena conectado al receptor GNSS o al dispositivo de comunicaci髇 a distancia no forman parte de la homologaci髇 de la unidad instalada en el veh韈ulo.

      No obstante, los fabricantes que hayan obtenido la homologaci髇 del aparato de control mantendr醤 una lista p鷅lica de las antenas y los separadores compatibles con cada unidad instalada en el veh韈ulo, dispositivo GNSS externo y dispositivo de comunicaci髇 a distancia externo homologados.

      Ir a Norma afectada
    • b) el punto 427 se sustituye por el texto siguiente:
      • 427) Las autoridades de homologaci髇 de los Estados miembros no conceder醤 el certificado de homologaci髇 mientras no est閚 en posesi髇 de:
        • - un certificado de seguridad (si se solicita en el presente anexo),
        • - un certificado funcional, y
        • - un certificado de interoperabilidad (si se solicita en el presente anexo)

          para el aparato de control o la tarjeta de tac骻rafo cuya homologaci髇 se solicite.
      Ir a Norma afectada
  • 29) El ap閚dice 1 se modifica como sigue:
    • a) el 韓dice queda modificado como sigue:
      • i) el apartado 2.63 se sustituye por el texto siguiente:

        2.63. Reservado para usos futuros

      • ii) el apartado 2.78 se sustituye por el texto siguiente:

        2.78. GNSSAccumulatedDriving

      • iii) el apartado 2.79 se sustituye por el texto siguiente:

        2.79. GNSSAccumulatedDrivingRecord

      • iv) el apartado 2.111 se sustituye por el texto siguiente:

        2.111. NoOfGNSSADRecords

      • v) el apartado 2.160 se sustituye por el texto siguiente:

        2.160. Reservado para usos futuros

      • vi) el apartado 2.203 se sustituye por el texto siguiente:

        2.203. VuGNSSADRecord

      • vii) el apartado 2.204 se sustituye por el texto siguiente:

        2.204. VuGNSSADRecordArray

      • viii) el apartado 2.230 se sustituye por el texto siguiente:

        2.230. Reservado para usos futuros

      • ix) el apartado 2.231 se sustituye por el texto siguiente:

        2.231. Reservado para usos futuros

    • b) en el apartado 2 se a馻dir el texto siguiente antes del apartado 2.1:

      En el caso de los tipos de datos de la tarjeta utilizados para las aplicaciones de la generaci髇 1 y la generaci髇 2, el tama駉 especificado en el presente ap閚dice es el correspondiente a la aplicaci髇 de generaci髇 2. Se da por supuesto que el lector conoce el tama駉 de la aplicaci髇 de generaci髇 1. Los n鷐eros de requisito del anexo IC correspondientes a estos tipos de datos incluyen tanto las aplicaciones de generaci髇 1 como las de generaci髇 2.

      Ir a Norma afectada
    • c) el apartado 2.19 se sustituye por el texto siguiente:

      2.19. CardEventData

      Generaci髇 1:

      Informaci髇 almacenada en una tarjeta de conductor o de taller relativa a los incidentes asociados al titular de la tarjeta (anexo IC, requisitos 260 y 318).

      CardEventData es una secuencia de cardEventRecords ordenada por valor ascendente del c骴igo EventFaultType (excepto los registros relacionados con intentos de violaci髇 de la seguridad, que se incluyen en el 鷏timo conjunto de la secuencia).

      cardEventRecords es un conjunto de registros de incidentes de un tipo en particular (o de una categor韆 en particular, en el caso de los intentos de violaci髇 de la seguridad).

      Generaci髇 2:

      Informaci髇 almacenada en una tarjeta de conductor o de taller relativa a los incidentes asociados al titular de la tarjeta (anexo IC, requisitos 285 y 341).

      CardEventData es una secuencia de cardEventRecords ordenada por valor ascendente del c骴igo EventFaultType (excepto los registros relacionados con intentos de violaci髇 de la seguridad, que se incluyen en el 鷏timo conjunto de la secuencia).

      cardEventRecords es un conjunto de registros de incidentes de un tipo en particular (o de una categor韆 en particular, en el caso de los intentos de violaci髇 de la seguridad).

      Ir a Norma afectada
    • d) el apartado 2.30 se sustituye por el texto siguiente:

      2.30. CardRenewalIndex

      El 韓dice de renovaci髇 de una tarjeta [definici髇 i)].

      Asignaci髇 de valor: (v閍se el cap韙ulo 7 del presente anexo).

      “0” Primera expedici髇.

      Orden de incremento: “0, …, 9, A, …, Z”

      Ir a Norma afectada
    • e) en el apartado 2.61, el texto que aparece despu閟 del encabezamiento 獹eneraci髇 2 se sustituye por el texto siguiente:

      Adem醩 de los de la generaci髇 1, se utilizan los siguientes elementos de datos:

      noOfGNSSCDRecords es el n鷐ero de registros GNSS de conducci髇 acumulada que puede almacenar la tarjeta.

      noOfSpecificConditionRecords es el n鷐ero de registros de condiciones espec韋icas que puede almacenar la tarjeta.

      noOfCardVehicleUnitRecords es el n鷐ero de registros sobre unidades instaladas en veh韈ulos que puede almacenar la tarjeta.

      Ir a Norma afectada
    • f) el apartado 2.63 se sustituye por el texto siguiente:

      2.63. Reservado para usos futuros

      Ir a Norma afectada
    • g) en el apartado 2.67, el texto que aparece despu閟 del encabezamiento 獹eneraci髇 2 se sustituye por el texto siguiente:

      se utilizan los mismos valores que en la generaci髇 1, con los siguientes a馻didos:

      Nota 1: Pueden utilizarse en SealRecord, si procede, los valores de generaci髇 2 de la placa, el adaptador y la conexi髇 del GNSS externo, as como los valores de generaci髇 1 de la unidad instalada en el veh韈ulo y el sensor de movimiento.

      Nota 2: En el campo CardHolderAuthorisation (CHA) de un certificado de generaci髇 2, los valores 1, 2 y 6 deben interpretarse en el sentido de que indican un certificado para la autenticaci髇 mutua del tipo de equipo respectivo. Para indicar el certificado respectivo para crear una firma digital, deben utilizarse los valores 17, 18 o 19.

      Ir a Norma afectada
    • h) en el apartado 2.70, el texto que aparece despu閟 del encabezamiento 獹eneraci髇 2 se sustituye por el texto siguiente:

      Generaci髇 2:

      Ir a Norma afectada
    • i) el apartado 2.71 se sustituye por el texto siguiente:

      2.71. ExtendedSealIdentifier

      Generaci髇 2:

      El identificador de precinto ampliado identifica de manera 鷑ica un precinto (anexo IC, requisito 401).

      manufacturerCode es un c骴igo del fabricante del precinto.

      sealIdentifier es un identificador del precinto que es exclusivo para el fabricante.

      Ir a Norma afectada
    • j) los apartados 2.78 y 2.79 se sustituyen por el texto siguiente:

      2.78. GNSSAccumulatedDriving

      Generaci髇 2:

      Informaci髇 almacenada en una tarjeta de conductor o de taller y relativa a la posici髇 GNSS del veh韈ulo si el tiempo de conducci髇 acumulado alcanza un m鷏tiplo de tres horas (anexo IC, requisitos 306 y 354).

      gnssADPointerNewestRecord es el 韓dice del 鷏timo registro actualizado de conducci髇 acumulado del GNSS.

      Asignaci髇 de valor es el n鷐ero correspondiente al numerador del registro de conducci髇 acumulado del GNSS. Al primer registro de la estructura se le asigna el n鷐ero ‘0’.

      gnssAccumulatedDrivingRecords es el conjunto de registros que contienen la fecha y hora en que la conducci髇 acumulada alcanza un m鷏tiplo de tres horas e informaci髇 sobre la posici髇 del veh韈ulo.

      2.79. GNSSAccumulatedDrivingRecord

      Generaci髇 2:

      Informaci髇 almacenada en una tarjeta de conductor o de taller y relativa a la posici髇 GNSS del veh韈ulo si el tiempo de conducci髇 acumulado alcanza un m鷏tiplo de tres horas (anexo IC, requisitos 305 y 353).

      timeStamp es la fecha y la hora en las que el tiempo de conducci髇 acumulado llega a un m鷏tiplo de tres horas.

      gnssPlaceRecord contiene informaci髇 relacionada con la posici髇 del veh韈ulo.

      vehicleOdometerValue es la lectura del cuentakil髆etros en el momento en que el tiempo de conducci髇 acumulado llega a un m鷏tiplo de tres horas.

      Ir a Norma afectada
    • k) el apartado 2.86 se sustituye por el texto siguiente:

      2.86. KeyIdentifier

      Un identificador exclusivo de una clave p鷅lica, empleado para hacer referencia a dicha clave y seleccionarla. Tambi閚 identifica al titular de la clave.

      La primera opci髇 sirve para hacer referencia a la clave p鷅lica de una unidad instalada en el veh韈ulo, de una tarjeta de tac骻rafo o de un dispositivo GNSS externo.

      La segunda opci髇 sirve para hacer referencia a la clave p鷅lica de una VU (en los casos en que el n鷐ero de serie de dicha VU no pueda conocerse en el momento de generarse el certificado).

      La tercera opci髇 sirve para hacer referencia a la clave p鷅lica de un Estado miembro.

      Ir a Norma afectada
    • l) el apartado 2.92 se sustituye por el texto siguiente:

      2.92. MAC

      Generaci髇 2:

      Una suma de control criptogr醘ica de 8, 12 o 16 bytes de longitud correspondiente a los conjuntos de cifrado que se especifican en el ap閚dice 11.

      Ir a Norma afectada
    • m) el apartado 2.111 se sustituye por el texto siguiente:

      2.111. NoOfGNSSADRecords

      Generaci髇 2:

      N鷐ero de registros GNSS de conducci髇 acumulada que puede almacenar una tarjeta.

      Asignaci髇 de valor: v閍se el ap閚dice 2.

      Ir a Norma afectada
    • n) en el apartado 2.120, la asignaci髇 de valor ‘16H’ se sustituye por lo siguiente:

      Ir a Norma afectada
    • o) el apartado 2.160 se sustituye por el texto siguiente:

      2.160. Reservado para usos futuros

      Ir a Norma afectada
    • p) el apartado 2.162 se sustituye por el texto siguiente:

      2.162. TimeReal

      C骴igo para un campo combinado de fecha y hora, donde ambos par醡etros se expresan como los segundos transcurridos desde las 00h.00m.00s. del 1 de enero de 1970, UTC.

      Asignaci髇 de valor - Alineaci髇 de octeto: n鷐ero de segundos transcurridos a partir de la medianoche del d韆 1 de enero de 1970, UTC.

      La fecha/hora m醲ima posible es en el a駉 2106.

      Ir a Norma afectada
    • q) el apartado 2.179 se sustituye por el texto siguiente:

      2.179. VuCardRecord

      Generaci髇 2:

      Informaci髇 almacenada en una unidad instalada en el veh韈ulo y relativa a una tarjeta de tac骻rafo utilizada (anexo IC, requisito 132).

      cardNumberAndGenerationInformation es el n鷐ero de tarjeta completo y la generaci髇 de la tarjeta utilizada (tipo de datos 2.74).

      cardExtendedSerialNumber seg鷑 se lee del archivo EF_ICC del MF de la tarjeta.

      cardStructureVersion seg鷑 se lee del archivo EF_Application_Identification del DF_Tachograph_G2.

      cardNumber seg鷑 se lee del archivo EF_Identification del DF_Tachograph_G2.

      Ir a Norma afectada
    • r) los apartados 2.203 y 2.204 se sustituyen por el texto siguiente:

      2.203. VuGNSSADRecord

      Generaci髇 2:

      Informaci髇 almacenada en una unidad instalada en el veh韈ulo y relativa a la posici髇 GNSS del veh韈ulo si el tiempo de conducci髇 acumulado alcanza un m鷏tiplo de tres horas (anexo IC, requisitos 108 y 110).

      timeStamp es la fecha y la hora en las que el tiempo de conducci髇 acumulado llega a un m鷏tiplo de tres horas.

      cardNumberAndGenDriverSlot identifica la tarjeta, incluida su generaci髇, que est insertada en la ranura del conductor.

      cardNumberAndGenCodriverSlot identifica la tarjeta, incluida su generaci髇, que est insertada en la ranura del segundo conductor.

      gnssPlaceRecord contiene informaci髇 relacionada con la posici髇 del veh韈ulo.

      vehicleOdometerValue es la lectura del cuentakil髆etros en el momento en que el tiempo de conducci髇 acumulado llega a un m鷏tiplo de tres horas.

      2.204. VuGNSSADRecordArray

      Generaci髇 2:

      Informaci髇 almacenada en una unidad instalada en el veh韈ulo y relativa a la posici髇 GNSS del veh韈ulo si el tiempo de conducci髇 acumulado alcanza un m鷏tiplo de tres horas (anexo IC, requisitos 108 y 110).

      recordType denota el tipo de registro (VuGNSSADRecord).

      Asignaci髇 de valor: v閍se RecordType

      recordSize es el tama駉 de VuGNSSADRecord en bytes.

      noOfRecords es el n鷐ero de registros que hay en el conjunto.

      records es un conjunto de registros GNSS sobre conducci髇 acumulada.换

      Ir a Norma afectada
    • s) los apartados 2.230 y 2.231 se sustituyen por el texto siguiente:

      2.230. Reservado para usos futuros

      2.231. Reservado para usos futuros

      Ir a Norma afectada
    • t) en el apartado 2.234, el texto que aparece despu閟 del encabezamiento 獹eneraci髇 2 se sustituye por el texto siguiente:

      Adem醩 de los de la generaci髇 1, se utilizan los siguientes elementos de datos:

      noOfGNSSADRecords es el n鷐ero de registros GNSS de conducci髇 acumulada que puede almacenar la tarjeta.

      noOfSpecificConditionRecords es el n鷐ero de registros de condiciones espec韋icas que puede almacenar la tarjeta.

      noOfCardVehicleUnitRecords es el n鷐ero de registros sobre unidades instaladas en veh韈ulos que puede almacenar la tarjeta.

      Ir a Norma afectada
  • 30) El ap閚dice 2 se modifica como sigue:
    • a) en el apartado 1.1 se a馻den las siguientes abreviaciones:
      CHA Autorizaci髇 del titular del certificado
      DO Objeto de datos;
      Ir a Norma afectada
    • b) el apartado 3.3 se modifica como sigue:
      • i) el punto TCS_24 se sustituye por el texto siguiente:

        TCS_24 Estas condiciones de seguridad pueden enlazarse de los modos siguientes:

        AND: deben cumplirse todas las condiciones de seguridad;

        OR: debe cumplirse al menos una condici髇 de seguridad.

        Las normas de acceso para el sistema de archivos, es decir, los comandos SELECT, READ BINARY y UPDATE BINARY, se especifican en el apartado 4. Las normas de acceso para el resto de los comandos se especifican en las tablas siguientes. El t閞mino ‘no aplicable’ se utiliza si no existe ning鷑 requisito para admitir el comando. En este caso, el comando puede ser o no ser admitido, pero la condici髇 de acceso es “fuera de 醡bito”.

      • ii) en el punto TCS_25, el cuadro se sustituye por el siguiente:
        Comando Tarjeta de conductor Tarjeta de taller Tarjeta de control Tarjeta de empresa
        External Authenticate
        —-Para autenticaci髇 de generaci髇 1 ALW ALW ALW ALW
        —-Para autenticaci髇 de generaci髇 2 ALW PWD ALW ALW
        Internal Authenticate ALW PWD ALW ALW
        General Authenticate ALW ALW ALW ALW
        Get Challenge ALW ALW ALW ALW
        MSE:SET AT ALW ALW ALW ALW
        MSE:SET DST ALW ALW ALW ALW
        Process DSRC Message No aplicable No aplicable No aplicable No aplicable
        PSO: Compute Digital Signature

        ALW OR

        SM-MAC-G2

        ALW OR

        SM-MAC-G2

        		 No aplicable No aplicable
        PSO: Hash No aplicable No aplicable ALW No aplicable
        PERFORM HASH of FILE

        ALW OR

        SM-MAC-G2

        ALW OR

        SM-MAC-G2

        		 No aplicable No aplicable
        PSO: Verify Certificate ALW ALW ALW ALW
        PSO: Verify Digital Signature No aplicable No aplicable ALW No aplicable
        Verify No aplicable ALW No aplicable No aplicable
      • iii) en el apartado TCS_26, el cuadro se sustituye por el siguiente:
        Comando Tarjeta de conductor Tarjeta de taller Tarjeta de control Tarjeta de empresa
        External Authenticate
        —-Para autenticaci髇 de generaci髇 1 No aplicable No aplicable No aplicable No aplicable
        —-Para autenticaci髇 de generaci髇 2 ALW PWD ALW ALW
        Internal Authenticate No aplicable No aplicable No aplicable No aplicable
        General Authenticate ALW ALW ALW ALW
        Get Challenge ALW ALW ALW ALW
        MSE:SET AT ALW ALW ALW ALW
        MSE:SET DST ALW ALW ALW ALW
        Process DSRC Message No aplicable ALW ALW No aplicable
        PSO: Compute Digital Signature

        ALW OR

        SM-MAC-G2

        ALW OR

        SM-MAC-G2

        		 No aplicable No aplicable
        PSO: Hash No aplicable No aplicable ALW No aplicable
        PERFORM HASH of FILE

        ALW OR

        SM-MAC-G2

        ALW OR

        SM-MAC-G2

        		 No aplicable No aplicable
        PSO: Verify Certificate ALW ALW ALW ALW
        PSO: Verify Digital Signature No aplicable No aplicable ALW No aplicable
        Verify No aplicable ALW No aplicable No aplicable
      • iv) en el apartado TCS_27, el cuadro se sustituye por el siguiente:
        Comando Tarjeta de conductor Tarjeta de taller Tarjeta de control Tarjeta de empresa
        External Authenticate
        —-Para la autenticaci髇 de generaci髇 1 No aplicable No aplicable No aplicable No aplicable
        —-Para la autenticaci髇 de generaci髇 2 ALW PWD ALW ALW
        Internal Authenticate No aplicable No aplicable No aplicable No aplicable
        General Authenticate ALW ALW ALW ALW
        Get Challenge ALW ALW ALW ALW
        MSE:SET AT ALW ALW ALW ALW
        MSE:SET DST ALW ALW ALW ALW
        Process DSRC Message No aplicable No aplicable No aplicable No aplicable
        PSO: Compute Digital Signature No aplicable No aplicable No aplicable No aplicable
        PSO: Hash No aplicable No aplicable No aplicable No aplicable
        PERFORM HASH of FILE No aplicable No aplicable No aplicable No aplicable
        PSO: Verify Certificate ALW ALW ALW ALW
        PSO: Verify Digital Signature No aplicable No aplicable No aplicable No aplicable
        Verify No aplicable ALW No aplicable No aplicable
      Ir a Norma afectada
    • c) en el apartado 3.4, el punto TCS_29 se sustituye por el texto siguiente:

      TCS_29 Las palabras de estado SW1 SW2 aparecen en todos los mensajes de respuesta e indican el estado de procesado del comando.

      SW1 SW2 Significado
      90 00 Procesamiento normal.
      61 XX Procesamiento normal. XX = n鷐ero de bytes de respuesta disponibles.
      62 81 Procedimiento de aviso. Una parte de los datos devueltos puede estar da馻da.
      63 00 Ha fallado la autenticaci髇 (Advertencia).
      63 CX CHV (PIN) incorrecto. “X” indica el contador de intentos restantes.
      64 00 Error de ejecuci髇. No ha variado el estado de la memoria permanente. Error de integridad.
      65 00 Error de ejecuci髇. Ha variado el estado de la memoria permanente.
      65 81 Error de ejecuci髇. Ha variado el estado de la memoria permanente. Fallo de memoria.
      66 88

      Error de seguridad-:-suma de control criptogr醘ica incorrecta (durante la mensajer韆 segura), o bien

      certificado incorrecto (durante la verificaci髇 del certificado), o bien

      criptograma incorrecto (durante la autenticaci髇 externa), o bien

      firma incorrecta (durante la verificaci髇 de la firma).
      67 00 Longitud incorrecta (Lc o Le incorrecta).
      68 83 趌timo comando de la cadena esperado.
      69 00 Comando prohibido (no hay respuesta disponible en T=0).
      69 82 Estado de seguridad no satisfecho.
      69 83 M閠odo de autenticaci髇 bloqueado.
      69 85 Condiciones de uso no satisfechas.
      69 86 Comando no autorizado (falta el EF actual).
      69 87 Faltan objetos de datos de mensajer韆 segura que se esperaban.
      69 88 Objetos de datos de mensajer韆 segura incorrectos.
      6A 80 Par醡etros incorrectos en el campo de datos.
      6A 82 Archivo no encontrado.
      6A 86 Par醡etros P1-P2 incorrectos.
      6A 88 Datos referenciados no encontrados.
      6B 00 Par醡etros incorrectos (desviaci髇 fuera del EF).
      6C XX Longitud incorrecta, SW2 indica la longitud exacta. No se devuelve un campo de datos.
      6D 00 C骴igo de instrucci髇 no admitido o no v醠ido.
      6E 00 Clase no admitida.
      6F 00 —-Otros errores de comprobaci髇

      Pueden devolverse otras palabras de estado como las definidas en la norma ISO/CEI 7816-4, si su comportamiento no se menciona expl韈itamente en el presente ap閚dice.

      Por ejemplo, existe la opci髇 de devolver las siguientes palabras de estado:

      6881: Canal l骻ico no admitido

      6882: Mensajer韆 segura no admitida.

      Ir a Norma afectada
    • d) en el apartado 3.5.1.1, el 鷏timo guion del punto TCS_38 se sustituye por el texto siguiente:
      • - Si se considera que la aplicaci髇 seleccionada est da馻da (se detecta un error de integridad dentro de los atributos del archivo), se contesta con el estado de procesado “6400” o “6500”.
      Ir a Norma afectada
    • e) en el apartado 3.5.1.2, el 鷏timo guion del punto TCS_41 se sustituye por el texto siguiente:
      • - Si se considera que el archivo seleccionado est da馻do (se detecta un error de integridad dentro de los atributos del archivo), se contesta con el estado de procesado “6400” o “6500”.
      Ir a Norma afectada
    • f) en el apartado 3.5.2.1, el sexto guion del punto TCS_43 se sustituye por el texto siguiente:
      • - Si se detecta un error de integridad dentro de los atributos del archivo, la tarjeta considerar el archivo da馻do e irrecuperable, se contesta con el estado de procesado “6400” o “6500”.
      Ir a Norma afectada
    • g) el apartado 3.5.2.1.1 se modifica como sigue:
      • i) en el punto TCS_45, el cuadro se sustituye por el siguiente:
        Byte Longitud Valor Descripci髇
        #1 1 “81h” TPV: Etiqueta para datos del valor plano
        #2 L

        “NNh” o

        “81 NNh”

        LPV: longitud de los datos devueltos (=Le original).

        L es 2 bytes si LPV > 127 bytes
        #(2+L) - #(1+L+NN) NN “XX..XXh” Valor de datos planos
        #(2+L+NN) 1 “99h” Etiqueta para el estado de procesado (SW1-SW2) – opcional para mensajer韆 segura de generaci髇 1
        #(3+L+NN) 1 “02h” Longitud del estado de procesado – opcional para mensajer韆 segura de generaci髇 1
        #(4+L+NN) - #(5+L+NN) 2 “XX XXh” Estado de procesado de la respuesta APDU sin proteger – opcional para mensajer韆 segura de generaci髇 1
        #(6+L+NN) 1 “8Eh” TCC: Etiqueta para suma de control criptogr醘ica
        #(7+L+NN) 1 “XXh”

        LCC: Longitud de la siguiente suma de control criptogr醘ica

        -“04h” para mensajer韆 segura de generaci髇 1 (v閍se la parte A del ap閚dice 11)

        -“08h”, “0Ch” o “10h” dependiendo de la longitud de la clave AES para mensajer韆 segura de generaci髇 2 (v閍se la parte B del ap閚dice 11)
        #(8+L+NN)-#(7+M+L+NN) M “XX..XXh” Suma de control criptogr醘ica
        SW 2 “XXXXh” Palabras de estado (SW1,SW2)
      • ii) en el punto TCS_46, el cuadro se sustituye por el siguiente:
        Byte Longitud Valor Descripci髇
        #1 1 “87h” TPI CG: Etiqueta para datos cifrados (criptograma)
        #2 L

        “MMh” o

        “81 MMh”

        LPI CG: Longitud de los datos cifrados que se devuelven (distinta de la Le original del comando, debido al relleno).

        L es 2 bytes si LPI CG > 127 bytes
        #(2+L)-#(1+L+MM) MM “01XX..XXh” Datos cifrados: Indicador de relleno y criptograma
        #(2+L+MM) 1 “99h” Etiqueta para el estado de procesado (SW1-SW2) – opcional para mensajer韆 segura de generaci髇 1
        #(3+L+MM) 1 “02h” Longitud del estado de procesado – opcional para mensajer韆 segura de generaci髇 1
        #(4+L+MM) - #(5+L+MM) 2 “XX XXh” Estado de procesado de la respuesta APDU sin proteger – opcional para mensajer韆 segura de generaci髇 1
        #(6+L+MM) 1 “8Eh” TCC: Etiqueta para suma de control criptogr醘ica
        #(7+L+MM) 1 “XXh”

        LCC: Longitud de la siguiente suma de control criptogr醘ica

        -“04h” para mensajer韆 segura de generaci髇 1 (v閍se la parte A del ap閚dice 11)

        -“08h”, “0Ch” o “10h” dependiendo de la longitud de la clave AES para mensajer韆 segura de generaci髇 2 (v閍se la parte B del ap閚dice 11)
        #(8+L+MM)-#(7+N+L+MM) N “XX..XXh” Suma de control criptogr醘ica
        SW 2 “XXXXh” Palabras de estado (SW1,SW2)
      Ir a Norma afectada
    • h) en el apartado 3.5.2.2, el sexto guion del punto TCS_50 se sustituye por el texto siguiente:
      • - Si se detecta un error de integridad dentro de los atributos del archivo, la tarjeta considerar el archivo da馻do e irrecuperable, se contesta con el estado de procesado “6400” o “6500”.
      Ir a Norma afectada
    • i) en el apartado 3.5.2.3, el punto TCS_52 queda modificado como sigue:
      • i) la 鷏tima fila del cuadro se sustituye por el texto siguiente:
        Le 1 “XXh” Seg鷑 se especifica en la norma ISO/CEI 7816-4
      • ii) se a馻de la siguiente frase:

        En T= 0, la tarjeta asume el valor Le = “00h” si no se aplica mensajer韆 segura.

        En T= 1, se contesta con el estado de procesado “6700” si Le = “01h”.

      Ir a Norma afectada
    • j) en el apartado 3.5.2.3, el sexto guion del punto TCS_53 se sustituye por el texto siguiente:
      • - Si se detecta un error de integridad dentro de los atributos del archivo, la tarjeta considerar el archivo da馻do e irrecuperable, se contesta con el estado de procesado “6400” o “6500”.
      Ir a Norma afectada
    • k) en el apartado 3.5.3.2, el sexto guion del punto TCS_63 se sustituye por el texto siguiente:
      • - Si se detecta un error de integridad dentro de los atributos del archivo, la tarjeta considerar el archivo da馻do e irrecuperable, se contesta con el estado de procesado “6400” o “6500”.
      Ir a Norma afectada
    • l) en el apartado 3.5.5, el punto TCS_72 se sustituye por el texto siguiente:

      TCS_72 El IFD debe a馻dir bytes “FFh” para rellenar por la derecha el PIN que introduzca el usuario y debe codificarse en ASCII, hasta llegar a una longitud de 8 bytes; v閍se tambi閚 el tipo de datos WorkshopCardPIN en el ap閚dice 1.

      Ir a Norma afectada
    • m) en el apartado 3.5.8, el punto TCS_95 se sustituye por el texto siguiente:

      TCS_95 Si el comando INTERNAL AUTHENTICATE se ejecuta correctamente, la clave de la sesi髇 actual de generaci髇 1, si la hay, se borra y deja de estar disponible. Para disponer de una nueva clave de sesi髇 de generaci髇 1, es preciso que se ejecute correctamente el comando EXTERNAL AUTHENTICATE para el mecanismo de autenticaci髇 de generaci髇 1.

      Nota: Para las claves de sesi髇 de generaci髇 2, v閍se el ap閚dice 11, CSM_193 y CSM_195. Si se establecen claves de sesi髇 de generaci髇 2 y la tarjeta de tac骻rafo recibe el comando APDU plano INTERNAL AUTHENTICATE, aborta la sesi髇 de mensajer韆 segura de generaci髇 2 y destruye las claves de sesi髇 de generaci髇 2.

      Ir a Norma afectada
    • n) en el apartado 3.5.9, el punto TCS_97 se sustituye por el texto siguiente:

      TCS_97 La variante del comando para la autenticaci髇 mutua de la tarjeta de la VU de segunda generaci髇 puede ejecutarse en el MF, DF tac骻rafo y DF tac骻rafo_G2; v閍se tambi閚 TCS_34. Si el comando EXTERNAL AUTHENTICATE de generaci髇 2 se ejecuta correctamente, la clave de la sesi髇 actual de generaci髇 1, si la hay, se borra y deja de estar disponible.

      Nota: Para las claves de sesi髇 de generaci髇 2, v閍se el ap閚dice 11, CSM_193 y CSM_195. Si se establecen claves de sesi髇 de generaci髇 2 y la tarjeta de tac骻rafo recibe el comando APDU plano EXTERNAL AUTHENTICATE, aborta la sesi髇 de mensajer韆 segura de generaci髇 2 y destruye las claves de sesi髇 de generaci髇 2.

      Ir a Norma afectada
    • o) en el apartado 3.5.10, se a馻de la siguiente fila al cuadro del punto TCS_101:
      5 + L + 1 1 “00h” Seg鷑 se especifica en la norma ISO/CEI 7816-4
      Ir a Norma afectada
    • p) en el apartado 3.5.11.2.3, se a馻den los siguientes p醨rafos en el punto TCS_114:
      • - Si el currentAuthenticatedTime de la tarjeta es posterior a la fecha de caducidad de la clave p鷅lica seleccionada, se contesta con el estado de procesado “6A88”.

      Nota: En el caso del comando MSE: SET AT para la autenticaci髇 de la VU, la clave referenciada es una clave p鷅lica VU_MA. La tarjeta establecer la clave p鷅lica VU_MA para su uso, si dispone de ella en su memoria, que coincida con la referencia al titular del certificado (CHR) que figura en el campo de datos del comando (la tarjeta puede identificar las claves p鷅licas VU_MA mediante el campo CHA del certificado). La tarjeta devolver el estado 6A 88 a este comando solo en el caso de que no est disponible en la unidad instalada en el veh韈ulo la clave p鷅lica VU_Sign o ninguna otra clave p鷅lica. V閍se la definici髇 del campo CHA en el ap閚dice 11, y la del tipo de dato equipmentType en el ap閚dice 1.

      Igualmente, en caso de que se env韊 a una tarjeta de control un comando MSE: SET DST que haga referencia a un EQT (por ejemplo, una VU o una tarjeta), de conformidad con CSM_234 la clave referenciada es siempre una clave EQT_Sign que debe utilizarse para la verificaci髇 de una firma digital. Con arreglo a la figura 13 del ap閚dice 11, la tarjeta de control siempre habr almacenado la clave p鷅lica EQT_Sign pertinente. En algunos casos, la tarjeta de control podr haber almacenado la correspondiente clave p鷅lica EQT_MA. La tarjeta de control establecer siempre la clave p鷅lica EQT_Sign para su uso cuando reciba un comando MSE: SET DST.

      Ir a Norma afectada
    • q) el apartado 3.5.13 se modifica como sigue:
      • i) el punto TCS_121 se sustituye por el texto siguiente:

        TCS_121 El valor de comprobaci髇 aleatoria del archivo temporalmente almacenado deber borrarse si se calcula un nuevo valor de comprobaci髇 aleatoria del archivo por medio del comando PERFORM HASH of FILE, si se selecciona un DF y si se reinicia la tarjeta del tac骻rafo.

      • ii) el punto TCS_123 se sustituye por el texto siguiente:

        TCS_123 La aplicaci髇 de tac骻rafo de generaci髇 2 deber admitir el algoritmo SHA-2 (SHA-256, SHA-384 o SHA-512), especificado en la serie de cifrado del ap閚dice 11, parte B, para la clave de firma de tarjeta Card_Sign.

      • iii) el cuadro del punto TCS_124 se sustituye por el siguiente:
        Byte Longitud Valor Descripci髇
        CLA 1 “80h” CLA
        INS 1 “2Ah” Realizar operaci髇 de seguridad
        P1 1 “90h” Etiqueta: Hash
        P2 1 “00h”

        Algoritmo conocido impl韈itamente

        Para la aplicaci髇 de tac骻rafo de generaci髇 1: SHA-1

        Para la aplicaci髇 de tac骻rafo de generaci髇 2: algoritmo SHA-2 (SHA-256, SHA-384 o SHA-512), definido en la serie de cifrado del ap閚dice 11, parte B, para la clave de firma de tarjeta Card_Sign
      Ir a Norma afectada
    • r) el apartado 3.5.14 se modifica como sigue:

      el texto que aparece despu閟 del encabezamiento y hasta el punto TCS_126 se sustituye por el siguiente:

      Este comando sirve para calcular la firma digital de un c骴igo de comprobaci髇 aleatoria calculado previamente (v閍se PERFORM HASH of FILE, 3.5.13).

      Solo la tarjeta de conductor y la tarjeta de taller deben admitir este comando en el DF tac骻rafo y el DF tac骻rafo_G2.

      Otros tipos de tarjetas de tac骻rafo pueden o no incorporar este comando. En el caso de la aplicaci髇 de tac骻rafo de generaci髇 2, solo la tarjeta de conductor y la tarjeta de taller tienen una clave de firma de generaci髇 2, otras tarjetas no pueden ejecutar el comando correctamente y terminan con un c骴igo de error adecuado.

      El comando puede o no estar accesible en el MF. Si el comando no est accesible en el MF, deber terminar con un c骴igo de error apropiado.

      Este comando cumple con lo dispuesto en la norma ISO/CEI 7816-8. Este comando tiene un uso restringido en relaci髇 con dicha norma.

      Ir a Norma afectada
    • s) el apartado 3.5.15 se modifica como sigue:
      • i) el cuadro del punto TCS_133 se sustituye por el siguiente:
        Byte Longitud Valor Descripci髇
        CLA 1 “00h” CLA
        INS 1 “2Ah” Realizar operaci髇 de seguridad
        P1 1 “00h”
        P2 1 “A8h” Etiqueta: el campo de datos contiene DO relevantes para verificaci髇
        Lc 1 “XXh” Longitud Lc del campo de datos subsiguiente
        #6 1 “9Eh” Etiqueta para firma digital

        #7 o

        #7-#8

        		 L

        “NNh” o

        “81 NNh”

        Longitud de la firma digital (L es 2 bytes si la firma digital es m醩 larga que 127 bytes):

        -128 bytes codificados conforme a la parte A del ap閚dice 11 para una aplicaci髇 de tac骻rafo de generaci髇 1.

        -Dependiendo de la curva seleccionada para la aplicaci髇 de tac骻rafo de generaci髇 2 (v閍se la parte B del ap閚dice 11)
        #(7+L)-#(6+L+NN) NN “XX..XXh” Contenido de la firma digital
      • ii) se a馻de el siguiente guion al punto TCS_134:
        • - Si la clave p鷅lica seleccionada (utilizada para verificar la firma digital) tiene un CHA.LSB (CertificateHolderAuthorisation.equipmentType) que no es apropiado para la verificaci髇 de firmas digitales seg鷑 el ap閚dice 11, se contesta con el estado de procesado “6985”.
      Ir a Norma afectada
    • t) el apartado 3.5.16 se modifica como sigue:
      • i) en el cuadro del punto TCS_138 se a馻de la fila siguiente:
        5 + L + 1 1 “00h” Seg鷑 se especifica en la norma ISO/CEI 7816-4
      • ii) se a馻de el siguiente guion al punto TCS_139:
        • - “6985” indica que el sello de tiempo de 4 bytes que aparece en el campo de datos del comando es anterior a cardValidityBegin o posterior a cardExpiryDate.
      Ir a Norma afectada
    • u) el apartado 4.2.2 se modifica como sigue:
      • i) en la estructura de datos del punto TCS_154, las l韓eas desde DF Tachograph G2 hasta EF CardMA_Certificate y desde EF GNSS_Places hasta el final de este punto se sustituyen por el texto siguiente:

      • ii) en el punto TCS_155, en el cuadro, el elemento se sustituye por el siguiente:

        		252 336
    • v) en el apartado 4.3.1, el texto correspondiente a la abreviaci髇 SC4 en el punto TCS_156 se sustituye por el texto siguiente:

      SC4 Para el comando READ BINARY con byte INS par:

      (SM-C-MAC-G1 Y SM-R-ENC-MAC-G1) O

      (SM-C-MAC-G2 Y SM-R-ENC-MAC-G2)

      Para el comando READ BINARY con byte INS impar (si se admite): NEV

      Ir a Norma afectada
    • w) el apartado 4.3.2 se modifica como sigue:
      • i) en la estructura de datos del punto TCS_162, las l韓eas desde DF Tachograph G2 hasta EF CardMA_Certificate, desde EF Calibration hasta extendedSealIdentifier y desde EF GNSS_Places hasta vehicleOdometerValue se sustituyen por el texto siguiente:

      • ii) el elemento NoOfGNSSCDRecords del cuadro del punto TCS_163 se sustituye por lo siguiente:
  • 31) En el ap閚dice 3, el apartado 2 queda modificado como sigue:
    • a) se inserta la l韓ea siguiente despu閟 de la l韓ea con los pictogramas 獿ugar donde comienza el per韔do de trabajo diario y 獿ugar donde termina el per韔do de trabajo diario:

    • b) la combinaci髇 de pictogramas 玜juste de la hora (por el taller) se sustituye por la siguiente:

    • c) las siguientes combinaciones de pictogramas se a馻den a la lista de incidentes:

  • 32) El ap閚dice 4 se modifica como sigue:
    • a) el apartado 2 se modifica como sigue:
      • i) el bloque n鷐ero 11.4 se sustituye por lo siguiente:

      • ii) el bloque n鷐ero 11.5 se sustituye por lo siguiente:

    • b) en el apartado 3.1, la posici髇 11.5 del formato de impresi髇 diaria se sustituye por lo siguiente:

      11.5. Posiciones tras un tiempo de conducci髇 acumulado de tres horas, en orden cronol骻ico

      Ir a Norma afectada
    • c) en el apartado 3.2, el formato de impresi髇 diaria se sustituye por lo siguiente:
      1 Fecha y hora en la que se imprime el documento
      2 Tipo de documento impreso
      3 Identificaci髇 del titular de la tarjeta (para todas las tarjetas insertadas en la VU + GEN)
      4 Identificaci髇 del veh韈ulo (veh韈ulo del que se obtiene el documento impreso)
      5 Identificaci髇 de la VU (VU cuya impresi髇 se obtiene + GEN)
      6 趌timo calibrado de la VU actual
      7 趌timo control realizado en este tac骻rafo
      9 Delimitador de las actividades del conductor
      10 Delimitador de la ranura del conductor (ranura 1)
      10a Condici髇 獸uera de 醡bito al comienzo de este d韆
      10.1 / 10.2 / 10.3 / 10.3a / 10.4 Actividades en orden cronol骻ico (ranura del conductor)
      10 Delimitador de la ranura del segundo conductor (ranura 2)
      10a Condici髇 獸uera de 醡bito al comienzo de este d韆
      10.1 / 10.2 / 10.3 / 10.3a / 10.4 Actividades en orden cronol骻ico (ranura del segundo conductor)
      11 Delimitador del resumen diario
      11.1 S韓tesis de los intervalos sin tarjeta en la ranura del conductor
      11.4 Lugares introducidos en orden cronol骻ico
      11.5 Posiciones tras un tiempo de conducci髇 acumulado de tres horas, en orden cronol骻ico
      11.7 Totalidad de actividades
      11.2 Resumen de los intervalos sin tarjeta en la ranura del segundo conductor
      11.4 Lugares introducidos en orden cronol骻ico
      11.5 Posiciones tras un tiempo de conducci髇 acumulado de tres horas, en orden cronol骻ico
      11.8 Totalidad de actividades
      11.3 Resumen de actividades por el conductor, incluidas ambas ranuras
      11.4 Lugares introducidos por este conductor en orden cronol骻ico
      11.5 Posiciones tras un tiempo de conducci髇 acumulado de tres horas, en orden cronol骻ico
      11.9 Totalidad de actividades relativas al conductor actual
      13.1 Delimitador de incidentes/fallos
      13.4 Registro de incidentes/fallos (鷏timos cinco incidentes o fallos almacenados o en curso en la VU)
      22.1 Lugar de control
      22.2 Firma del controlador
      22.3 Hora de comienzo (espacio reservado a un conductor sin una tarjeta para indicar
      22.4 Hora de finalizaci髇 qu per韔dos le ata馿n o corresponden)
      22.5 Firma del conductor
      Ir a Norma afectada
    • d) en el apartado 3.7, el punto PRT_014 se sustituye por el texto siguiente:

      (no afecta a la versi髇 espa駉la)

  • 33) El ap閚dice 7 se modifica como sigue:
    • a) el apartado 1.1 se sustituye por el texto siguiente:

      1.1. 羗bito de aplicaci髇

      Se pueden transferir datos a un ESM:

      • - desde una unidad instalada en el veh韈ulo (VU), mediante un equipo dedicado inteligente (IDE) conectado a la VU;
      • - desde una tarjeta de tac骻rafo, mediante un IDE que incorpore un dispositivo de interfaz de tarjeta (IFD); y
      • - desde una tarjeta de tac骻rafo y a trav閟 de una unidad instalada en el veh韈ulo, mediante un IDE conectado a la VU.

      Para poder verificar la autenticidad y la integridad de los datos transferidos que se encuentran almacenados en un ESM, dichos datos se transfieren con una firma a馻dida seg鷑 lo dispuesto en el ap閚dice 11 (Mecanismos de seguridad comunes). Tambi閚 se transfieren la identificaci髇 del equipo de origen (VU o tarjeta) y sus certificados de seguridad (Estado miembro y equipamiento). La persona encargada de verificar los datos debe estar en posesi髇 de una clave p鷅lica europea de confianza.

      Los datos transferidos desde una VU se firman utilizando los mecanismos de seguridad comunes del ap閚dice 11, parte B (Sistema de tac骻rafo de segunda generaci髇), excepto cuando la supervisi髇 del conductor la realiza una autoridad de control de un pa韘 no perteneciente a la UE utilizando una tarjeta de control de primera generaci髇, en cuyo caso los datos se firman mediante los mecanismos de seguridad comunes del ap閚dice 11, parte A (Sistema de tac骻rafo de primera generaci髇), tal y como se establece en el requisito MIG_015 del ap閚dice 15 (Migraci髇).

      En el presente ap閚dice se especifican, por lo tanto, dos tipos de transferencias de datos desde la VU:

      • - Transferencia de datos desde la VU de generaci髇 2, con la estructura de datos de segunda generaci髇, firmada utilizando los mecanismos de seguridad comunes del ap閚dice 11, parte B,
      • - Transferencia de datos desde la VU de generaci髇 1, con la estructura de datos de primera generaci髇, firmada utilizando los mecanismos de seguridad comunes del ap閚dice 11, parte A.

      Igualmente, existen dos tipos de transferencias de datos desde tarjetas de conductor de segunda generaci髇 insertadas en una VU, como se especifica en los apartados 3 y 4 del presente ap閚dice.

      Ir a Norma afectada
    • b) el apartado 2.2.2 se modifica como sigue:
      • i) el cuadro se sustituye por el siguiente:
        Estructura del mensaje M醲. 4 bytes Cabecera M醲. 255 bytes Datos 1 byte Suma de control

        IDE ->

        <- VU

        		 FMT TGT SRC LEN SID DS_ / TRTP DATA CS
        Petici髇 de inicio de comunicaci髇 81 EE F0 81 E0
        Respuesta positiva a la petici髇 de inicio de comunicaci髇 80 F0 EE 03 C1 EA, 8F 9B
        Petici髇 de inicio de la sesi髇 de diagn髎tico 80 EE F0 02 10 81 F1
        Respuesta positiva a la petici髇 de inicio de diagn髎tico 80 F0 EE 02 50 81 31
        Servicio de control del enlace
        Verificar la velocidad en baudios (fase 1)
        9 600 Bd 80 EE F0 04 87 01,01,01 EC
        19 200 Bd 80 EE F0 04 87 01,01,02 ED
        38 400 Bd 80 EE F0 04 87 01,01,03 EE
        57 600 Bd 80 EE F0 04 87 01,01,04 EF
        115 200 Bd 80 EE F0 04 87 01,01,05 F0
        Respuesta positiva a la petici髇 de verificar la velocidad en baudios 80 F0 EE 02 C7 01 28
        Velocidad de baudios de transici髇 (fase 2) 80 EE F0 03 87 02,03 ED
        Env韔 de petici髇 80 EE F0 0A 35

        00,00,00,00,00,FF,FF,

        FF,FF

        		 99
        Respuesta positiva al env韔 de petici髇 80 F0 EE 03 75 00,FF D5
        Petici髇 de transferencia de datos
        Visi髇 general 80 EE F0 02 36 01 o 21 97
        Actividades 80 EE F0 06 36 02 o 22 Fecha CS
        Incidentes y fallos 80 EE F0 02 36 03 o 23 Fecha 99
        Datos pormenorizados sobre la velocidad 80 EE F0 02 36 04 o 24 Fecha 9A
        Datos t閏nicos 80 EE F0 02 36 05 o 25 Fecha 9B
        Transferencia de los datos de la tarjeta 80 EE F0 02 36 06 Ranura CS
        Respuesta positiva a la petici髇 de transferencia de datos 80 F0 EE Len 76 TREP Datos CS
        Petici髇 de salida de la transferencia 80 EE F0 01 37 96
        Respuesta positiva a la petici髇 de salida de la transferencia 80 F0 EE 01 77 D6
        Petici髇 de interrupci髇 de la comunicaci髇 80 EE F0 01 82 E1
        Respuesta positiva a la petici髇 de interrupci髇 de la comunicaci髇 80 F0 EE 01 C2 21
        Confirmaci髇 de submensaje 80 EE F0 Len 83 Datos CS
        Respuestas negativas
        Denegaci髇 general 80 F0 EE 03 7F SId pet. 10 CS
        Servicio no admitido 80 F0 EE 03 7F SId pet. 11 CS
        Subfunci髇 no admitida 80 F0 EE 03 7F SId pet. 12 CS
        Longitud del mensaje incorrecta 80 F0 EE 03 7F SId pet. 13 CS
        Condiciones incorrectas o error en la secuencia de la petici髇 80 F0 EE 03 7F SId pet. 22 CS
        Petici髇 no admisible 80 F0 EE 03 7F SId pet. 31 CS
        Env韔 no aceptado 80 F0 EE 03 7F SId pet. 50 CS
        Falta respuesta 80 F0 EE 03 7F SId pet. 78 CS
        Datos no disponibles 80 F0 EE 03 7F SId pet. FA CS
      • ii) se a馻den los siguientes guiones a las notas que aparecen despu閟 del cuadro:
        • - Para las peticiones de transferencia de datos desde VU de segunda generaci髇, se utilizan los TRTP 21 a 25; para las peticiones de transferencia de datos desde VU de primera generaci髇, se utilizan los TRTP 01 a 05, que la VU aceptar solo en el marco de la supervisi髇 del conductor realizada por una autoridad de control de un pa韘 no perteneciente a la UE, utilizando una tarjeta de control de primera generaci髇.
        • - Los TRTP 11 a 19 y 31 a 39 se reservan para peticiones de transferencia espec韋icas de los fabricantes.
      Ir a Norma afectada
    • c) el apartado 2.2.2.9 se modifica como sigue:
      • i) el punto DDP_011 se sustituye por el texto siguiente:

        DDP_011 El IDE env韆 la petici髇 de transferencia de datos para especificar a la VU el tipo de datos que se van a transferir. Un par醡etro de petici髇 de transferencia (TRTP) de un byte indica el tipo de transferencia.

        Existen seis tipos de transferencias de datos: Para la transferencia de datos desde la VU se pueden utilizar dos valores de TRTP distintos para cada tipo de transferencia:

        Tipo de transferencia de datos Valor del TRTP para la transferencia de datos desde la VU de primera generaci髇 Valor del TRTP para la transferencia de datos desde la VU de segunda generaci髇
        Visi髇 general 01 21
        Actividades de una fecha espec韋ica 02 22
        Incidentes y fallos 03 23
        Datos pormenorizados sobre la velocidad 04 24
        Datos t閏nicos 05 25
        Tipo de transferencia de datos Valor del TRTP
        Transferencia de los datos de la tarjeta 06
      • ii) el punto DDP_054 se sustituye por el texto siguiente:

        獶DP_054 Es obligatorio que el IDE solicite la transferencia de datos resumen (TRTP 01 o 21) durante una sesi髇 de transferencia, ya que solo as se asegura que los certificados de la VU se registran en el archivo transferido (y se permite la verificaci髇 de la firma digital).

        En el segundo caso (TRTP 02 o 22), el mensaje de petici髇 de transferencia de datos incluye la indicaci髇 del d韆 natural (en formato cuyos datos se van a transferir.

      Ir a Norma afectada
    • d) en el apartado 2.2.2.10, el punto DDP_055 se sustituye por el texto siguiente:

      DDP_055 En el primer caso (TREP 01 o 21), la VU env韆 datos que ayudan al operario del IDE a seleccionar los datos que quiere transferir. La informaci髇 contenida en este mensaje es la siguiente:

      • - certificados de seguridad;
      • - identificaci髇 del veh韈ulo;
      • - fecha y hora actuales de la VU;
      • - fecha m醲ima y m韓ima transferible (datos de la VU);
      • - indicaci髇 de presencia de tarjetas en la VU;
      • - transferencia previa a una empresa;
      • - bloqueos introducidos por empresas; e
      • - inspecciones anteriores.
      Ir a Norma afectada
    • e) en el apartado 2.2.2.16, el 鷏timo guion del punto DDP_018 se sustituye por el texto siguiente:
      • - FA: datos no disponibles

        El objeto de datos de una petici髇 de transferencia de datos no est disponible en la VU (por ejemplo, no se ha introducido una tarjeta, o se solicita una transferencia de datos desde una VU de primera generaci髇 fuera del marco de la supervisi髇 del conductor realizada por una autoridad de control de un pa韘 no perteneciente a la UE).
      Ir a Norma afectada
    • f) el apartado 2.2.6.1 se modifica como sigue:
      • i) El primer p醨rafo del punto DDP_029 se sustituye por el texto siguiente:

        El campo de datos del mensaje Positive Response Transfer Data Overview (respuesta positiva a la petici髇 de transferencia de datos resumen) contiene los datos siguientes en este orden, con el SId 76 Hex, el TREP 01 o 21 Hex y el m閠odo adecuado de divisi髇 y recuento de submensajes:

      • ii) el encabezamiento 獷structura de datos de primera generaci髇 se sustituye por el texto siguiente:

        Estructura de datos de primera generaci髇 (TREP 01 Hex)

      • iii) el encabezamiento 獷structura de datos de segunda generaci髇 se sustituye por el texto siguiente:

        Estructura de datos de segunda generaci髇 (TREP 21 Hex)

      Ir a Norma afectada
    • g) el apartado 2.2.6.2 se modifica como sigue:
      • i) El primer p醨rafo del punto DDP_030 se sustituye por el texto siguiente:

        El campo de datos del mensaje Positive Response Transfer Data Activities (respuesta positiva a la petici髇 de transferencia de datos sobre actividades) contiene los datos siguientes en este orden, con el SId 76 Hex, el TREP 02 o 22 Hex y el m閠odo adecuado de divisi髇 y recuento de submensajes:

      • ii) el encabezamiento 獷structura de datos de primera generaci髇 se sustituye por el texto siguiente:

        Estructura de datos de primera generaci髇 (TREP 02 Hex)

      • iii) el encabezamiento 獷structura de datos de segunda generaci髇 se sustituye por el texto siguiente:

        獷structura de datos de segunda generaci髇 (TREP 22 Hex)

      • iv) el elemento VuGNSSCDRecordArray que aparece bajo el encabezamiento 獷structura de datos de segunda generaci髇 (TREP 22 Hex) se sustituye por el texto siguiente:

      Ir a Norma afectada
    • h) el apartado 2.2.6.3 se modifica como sigue:
      • i) el primer p醨rafo del punto DDP_031 se sustituye por el texto siguiente:

        El campo de datos del mensaje Positive Response Transfer Data Events and Faults (respuesta positiva a la petici髇 de transferencia de datos sobre incidentes y fallos) contiene los datos siguientes en este orden, con el SId 76 Hex, el TREP 03 o 23 Hex y el m閠odo adecuado de divisi髇 y recuento de submensajes:

      • ii) el encabezamiento 獷structura de datos de primera generaci髇 se sustituye por el texto siguiente:

        Estructura de datos de primera generaci髇 (TREP 03 Hex)

      • iii) el encabezamiento 獷structura de datos de segunda generaci髇 se sustituye por el texto siguiente:

        Estructura de datos de segunda generaci髇 (TREP 23 Hex)

      • iv) se suprime el elemento VuTimeAdjustmentGNSSRecordArray que aparece bajo el encabezamiento 獷structura de datos de segunda generaci髇 (TREP 23 Hex);
      Ir a Norma afectada
    • i) el apartado 2.2.6.4 se modifica como sigue:
      • i) el primer p醨rafo del punto DDP_032 se sustituye por el texto siguiente:

        El campo de datos del mensaje Positive Response Transfer Data Detailed Speed (respuesta positiva a la petici髇 de transferencia de datos detallados sobre la velocidad) contiene los datos siguientes en este orden, con el SId 76 Hex, el TREP 04 o 24 Hex y el m閠odo adecuado de divisi髇 y recuento de submensajes:

      • ii) el encabezamiento 獷structura de datos de primera generaci髇 se sustituye por el texto siguiente:

        Estructura de datos de primera generaci髇 (TREP 04)

      • iii) el encabezamiento 獷structura de datos de segunda generaci髇 se sustituye por el texto siguiente:

        Estructura de datos de segunda generaci髇 (TREP 24)

      Ir a Norma afectada
    • j) el apartado 2.2.6.5 se modifica como sigue:
      • i) el primer p醨rafo del punto DDP_033 se sustituye por el texto siguiente:

        El campo de datos del mensaje Positive Response Transfer Data Technical Data (respuesta positiva a la petici髇 de transferencia de datos t閏nicos) contiene los datos siguientes en este orden, con el SId 76 Hex, el TREP 05 o 25 Hex y el m閠odo adecuado de divisi髇 y recuento de submensajes:

      • ii) el encabezamiento 獷structura de datos de primera generaci髇 se sustituye por el texto siguiente:

        Estructura de datos de primera generaci髇 (TREP 05)

      • iii) el encabezamiento 獷structura de datos de segunda generaci髇 se sustituye por el texto siguiente:

        Estructura de datos de segunda generaci髇 (TREP 25)

      Ir a Norma afectada
    • k) en el apartado 3.3, el punto DDP_035 se sustituye por el texto siguiente:

      DDP_035 La transferencia de los datos de una tarjeta de tac骻rafo consta de los pasos siguientes:

      • - Transferencia de la informaci髇 com鷑 de la tarjeta almacenada en los archivos EF

        Esta informaci髇 es opcional y no se protege con una firma digital.
      • - (para las tarjetas de tac骻rafo de primera y segunda generaci髇) Transferencia de los archivos EF dentro del archivo DOU
      • - Transferencia de los archivos EF Esta informaci髇 no se protege con una firma digital.

        Es obligatorio transferir estos archivos para cada sesi髇 de transferencia.
      • - Transferencia del resto de los archivos EF con datos de aplicaci髇 (dentro del archivo excepto el EF

        Esta informaci髇 se protege con una firma digital, utilizando los mecanismos de seguridad comunes del ap閚dice 11, parte A.
      • - Es obligatorio transferir al menos los archivos EF e para cada sesi髇 de transferencia.
      • - Cuando se transfieran los datos de una tarjeta de conductor, tambi閚 es obligatorio transferir los siguientes archivos EF:

      • - (solo para las tarjetas de tac骻rafo de segunda generaci髇) Excepto cuando la transferencia de una tarjeta de conductor insertada en una VU se realiza durante una supervisi髇 del conductor por parte de una autoridad de control de un pa韘 no perteneciente a la UE, utilizando una tarjeta de control de primera generaci髇, transferir los archivos EF dentro del archivo
      • - Transferir los archivos EF CardSignCertificate, CA_Certificate y Link_Certificate, si existen. Esta informaci髇 no se protege con una firma digital.

        Es obligatorio transferir estos archivos para cada sesi髇 de transferencia.
      • - Transferencia del resto de archivos EF con datos de aplicaci髇 (dentro del archivo excepto el EF

        Esta informaci髇 se protege con una firma digital, utilizando los mecanismos de seguridad comunes del ap閚dice 11, parte B.
      • - Es obligatorio transferir al menos los archivos EF e para cada sesi髇 de transferencia.
      • - Cuando se transfieran los datos de una tarjeta de conductor, tambi閚 es obligatorio transferir los siguientes archivos EF:

      • - Cuando se transfieran los datos de una tarjeta de conductor, se actualizar la fecha de en el archivo EF en los DF y, si procede, D
      • - Cuando se transfieran los datos de una tarjeta de taller, habr que reiniciar el contador de calibrado en el archivo EF en los DF y, si procede,
      • - Cuando se transfieran los datos de una tarjeta de taller, no se transferir el
      Ir a Norma afectada
    • l) en el apartado 3.3.2, el primer p醨rafo del punto DDP_037 se sustituye por el texto siguiente:

      A continuaci髇 se muestra la secuencia para transferir los archivos EF ICC, IC, Card_Certificate (o CardSignCertificate para DF tac骻rafo_G2), CA_Certificate y Link_Certificate (solo para DF tac骻rafo_G2):

    • m) en el apartado 3.3.3, se sustituye el cuadro por el siguiente:
      Tarjeta Dir IDE/IFD Significado/Observaciones

      		Select File (seleccionar archivo)
      OK

      		Perform Hash of File (realizar comprobaci髇 aleatoria de archivo) —-Calcula el valor de comprobaci髇 aleatoria con los datos contenidos en el archivo seleccionado, utilizando el algoritmo de comprobaci髇 aleatoria especificado en el ap閚dice 11, parte A o B. Este no es un comando ISO.
      Realizar una comprobaci髇 aleatoria del archivo y almacenar temporalmente el valor obtenido
      OK

      		Read Binary (leer archivo binario) Si el archivo contiene m醩 datos de los que caben en la memoria temporal del lector o de la tarjeta, habr que repetir el comando hasta que se haya le韉o el archivo completo.

      File Data (datos del archivo)

      OK

      		Almacenar los datos recibidos en un ESM seg鷑 lo previsto en el apartado 3.4 Data storage format

      		PSO: Compute Digital Signature (calcular firma digital)
      Realizar la operaci髇 de seguridad “calcular firma digital” utilizando el valor de comprobaci髇 aleatoria almacenado temporalmente

      Signature (firma)

      OK

      		A馻dir datos a los datos previamente almacenados en el ESM seg鷑 lo previsto en el apartado 3.4 Data storage format
      Ir a Norma afectada
    • n) en el apartado 3.4.2, el punto DDP_046 se sustituye por el texto siguiente:

      DDP_046 Inmediatamente despu閟 del objeto TLV que contiene los datos del archivo, habr que almacenar una firma como el siguiente objeto TLV.

      Definici髇 Significado Longitud
      FID (2 bytes) || 00 Etiqueta para EF (FID) en el DF Tachograph o para la informaci髇 com鷑 de la tarjeta 3 bytes
      FID (2 bytes) || 01 Etiqueta para firma de EF (FID) en el DF Tachograph 3 bytes
      FID (2 bytes) || 02 Etiqueta para firma de EF (FID) en el DF Tachograph_G2 3 bytes
      FID (2 bytes) || 03 Etiqueta para firma de EF (FID) en el DF Tachograph_G2 3 bytes
      xx xx Longitud del campo de valor 2 bytes

      Ejemplo de datos en un archivo transferido y almacenado en un ESM:

      Etiqueta Longitud Valor
      00 02 00 00 11 Datos del archivo EF ICC
      C1 00 00 00 C2 Datos del archivo EF Card_Certificate
      …
      05 05 00 0A 2E Datos del archivo EF Vehicles_Used (en el DF Tachograph)
      05 05 01 00 80 Firma del archivo EF Vehicles_Used (en el DF Tachograph)
      05 05 02 0A 2E Datos del archivo EF Vehicles_Used (en el DF Tachograph_G2)
      05 05 03 XX XX Firma del archivo EF Vehicles_Used (en el DF Tachograph_G2)
      Ir a Norma afectada
    • o) en el apartado 4, el punto DDP_049 se sustituye por el texto siguiente:

      獶DP_049 Tarjetas de conductor de primera generaci髇: Los datos se transferir醤 utilizando el protocolo de transferencia de datos de primera generaci髇, y los datos transferidos deber醤 tener el mismo formato que los datos transferidos desde una unidad instalada en el veh韈ulo de primera generaci髇.

      Tarjetas de conductor de segunda generaci髇: la VU deber transferir todos los datos de la tarjeta, archivo por archivo, de acuerdo con el protocolo de transferencia descrito en el apartado 3, para luego enviar al IDE todos los datos recibidos de la tarjeta. Estos datos se enviar醤 con el formato adecuado de archivo TLV (v閍se el apartado 3.4.2) y encapsulados en un mensaje Positive Response Transfer Data (respuesta positiva a la petici髇 de transferencia de datos).

      Ir a Norma afectada
  • 34) En el apartado 2 del ap閚dice 8, el texto que aparece despu閟 del encabezamiento 玆eferencias se sustituye por el texto siguiente:

    ISO 14230-2: Veh韈ulos de carretera - Sistemas de diagn髎tico - Protocolo Keyword 2000 - Parte 2: Nivel de enlace de datos.

    Primera edici髇: 1999.

    Ir a Norma afectada
  • 35) El ap閚dice 9 se modifica como sigue:
    • a) en el 韓dice, el apartado 6 se sustituye por lo siguiente:

      6. PRUEBAS DEL DISPOSITIVO DE COMUNICACI覰 A DISTANCIA EXTERNO

    • b) en el apartado 1.1, el primer guion se sustituye por el texto siguiente:
      • - una certificaci髇 de seguridad basada en criterios comunes especificados para acreditar el cumplimiento de un objetivo de seguridad conforme al ap閚dice 10 del presente anexo;
    • c) en el apartado 2, el cuadro de las pruebas funcionales de la unidad instalada en el veh韈ulo se sustituye por el siguiente:
      N.o Prueba Descripci髇 Condiciones correspondientes
      1 Examen administrativo
      1.1 Documentaci髇 Correcci髇 de la documentaci髇
      1.2 Resultados de las pruebas del fabricante

      Resultados de la prueba realizada por el fabricante durante la integraci髇.

      Demostraciones sobre papel.

      		 88, 89, 91
      2 Inspecci髇 visual
      2.1 Cumplimiento de lo dispuesto en la documentaci髇
      2.2 Identificaci髇/inscripciones 224 a 226
      2.3 Materiales 219 a 223
      2.4 Precintos 398, 401 a 405
      2.5 Interfaces externas
      3 Pruebas funcionales
      3.1 Funciones disponibles 02, 03, 04, 05, 07, 382
      3.2 Modos de funcionamiento 09 a 11*, 134, 135
      3.3 Funciones y derechos de acceso a los datos 12*, 13*, 382, 383, 386 a 389
      3.4 Inserci髇 y extracci髇 de las tarjetas de supervisi髇 15, 16, 17, 18, 19*, 20*, 134
      3.5 Medici髇 de la velocidad y la distancia 21 a 31
      3.6 Medici髇 de la hora (ensayo realizado a 20 癈) 38 a 43
      3.7 Supervisi髇 de las actividades del conductor 44 a 53, 134
      3.8 Supervisi髇 del r間imen de conducci髇 54, 55, 134
      3.9 Entradas manuales 56 a 62
      3.10 Gesti髇 de los bloqueos introducidos por las empresas 63 a 68
      3.11 Supervisi髇 de las actividades de control 69, 70
      3.12 Detecci髇 de incidentes o fallos 71 a 88, 134
      3.13 Datos de identificaci髇 del aparato 93*, 94*, 97, 100
      3.14 Datos de inserci髇 y extracci髇 de la tarjeta del conductor 102* a 104*
      3.15 Datos sobre la actividad del conductor 105* a 107*
      3.16 Datos sobre lugares y posiciones 108* a 112*
      3.17 Datos del cuentakil髆etros 113* a 115*
      3.18 Datos pormenorizados sobre la velocidad 116*
      3.19 Datos sobre incidentes 117*
      3.20 Datos sobre fallos 118*
      3.21 Datos de calibrado 119* a 121*
      3.22 Datos de ajuste de la hora 124*, 125*
      3.23 Datos sobre actividades de control 126*, 127*
      3.24 Datos sobre los bloqueos introducidos por las empresas 128*
      3.25 Datos sobre actividades de transferencia 129*
      3.26 Datos sobre condiciones espec韋icas 130*, 131*
      3.27 Registro y almacenamiento de datos en tarjetas de tac骻rafo

      136, 137, 138*, 139*, 141*, 142, 143

      144, 145, 146*, 147*, 148*, 149, 150
      3.28 Visualizaci髇

      90, 134,

      151 a 168,

      PIC_001, DIS_001
      3.29 Impresi髇

      90, 134

      169 a 181, PIC_001, PRT_001 a PRT_014
      3.30 Advertencias

      134, 182 a 191,

      PIC_001
      3.31 Transferencia de datos a medios externos 90, 134, 192 a 196
      3.32 Comunicaci髇 remota para pruebas en carretera espec韋icas 197 a 199
      3.33 Env韔 de datos a dispositivos externos adicionales 200, 201
      3.34 Calibrado 202 a 206*, 383, 384, 386 a 391
      3.35 Verificaci髇 del calibrado en carretera 207 a 209
      3.36 Ajuste de la hora 210 a 212*
      3.37 No interferencia con funciones adicionales 06, 425
      3.38 Interfaz del sensor de movimiento 02, 122
      3.39 Dispositivo GNSS externo 03, 123
      3.40 Comprobar si la VU detecta, registra y almacena el o los incidentes o fallos descritos por el fabricante de la VU cuando un sensor de movimiento acoplado reaccione a los campos magn閠icos perturbando la detecci髇 de movimiento del veh韈ulo. 217
      3.41 Serie de cifrado y par醡etros de dominio estandarizados CSM_48, CSM_50
      4. Pruebas ambientales
      4.1 Temperatura

      Verificar la funcionalidad mediante:

      -Prueba en virtud de la ISO 16750-4, apartado 5.1.1.2: prueba de funcionamiento a temperatura baja (72 h a – 20 癈).

      -Esta prueba se refiere a la IEC 60068-2-1: Verificaci髇 medioambiental – Parte 2-1: Pruebas – Prueba A: Fr韔

      -Prueba en virtud de la ISO 16750-4: apartado 5.1.2.2: prueba de funcionamiento a temperatura alta (72 h a 70 癈).

      -Esta prueba se refiere a la IEC 60068-2-2: Procedimientos b醩icos de verificaci髇 medioambiental; Parte 2: pruebas; Prueba B: Calor seco.

      -Prueba en virtud de la ISO 16750-4, apartado 5.3.2: cambio r醦ido de temperatura con una duraci髇 de transici髇 espec韋ica (– 20 癈/70 癈, 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髇 3 de esta tabla) a la temperatura m醩 baja, a la temperatura m醩 alta y durante los ciclos de temperatura.

      		 213
      4.2 Humedad Verificar que la unidad instalada en el veh韈ulo puede soportar una humedad c韈lica (prueba de calor) mediante la norma IEC 60068-2-30, prueba Db, seis ciclos de 24 horas, con una variaci髇 de temperatura de + 25 癈 a + 55 癈 en cada caso y una humedad relativa del 97 % a + 25 癈 y del 93 % a + 55 癈. 214
      4.3 Mec醤ica

      1.-Vibraciones sinusoidales:

      verificar que la unidad instalada en el veh韈ulo es capaz de soportar vibraciones sinusoidales de las siguientes caracter韘ticas:

      -desplazamiento constante entre 5 y 11 Hz: pico de 10 mm; y

      -aceleraci髇 constante entre 11 y 300 Hz: 5 g.

      -Esta exigencia se verifica mediante la norma IEC 60068-2-6, prueba Fc, con una duraci髇 m韓ima de 3 12 horas (12 horas por cada eje).

      -La ISO 16750-3 no requiere una prueba de vibraci髇 sinusoidal para dispositivos situados en el puesto de conducci髇 del veh韈ulo desacoplado.

      2.-Vibraciones aleatorias:

      Prueba en virtud de la ISO 16750-3, apartado 4.1.2.8: prueba VIII: veh韈ulo comercial, puesto de conducci髇 del veh韈ulo desacoplado.

      Prueba de vibraciones aleatorias, 10-2 000 Hz, RMS vertical 21,3 m/s2, RMS longitudinal 11,8 m/s2, RMS lateral 13,1 m/s2, 3 ejes, 32 horas por eje, incluido un ciclo de temperatura – 20 - + 70 癈.

      Esta prueba se refiere a la IEC 60068-2-64: Verificaci髇 medioambiental – Parte 2-64: Pruebas – Prueba Fh: Vibraci髇, aleatorio de banda ancha y orientaci髇.

      3.-Choques:

      choque mec醤ico con semionda sinusoidal de 3 g de conformidad con la ISO 16750.

      Las pruebas arriba descritas se llevan a cabo con muestras diferentes del tipo de equipo que se someta a prueba.

      		 219
      4.4 Protecci髇 frente a la penetraci髇 de agua y cuerpos extra駉s Prueba en virtud de la ISO 20653: Veh韈ulos de carretera – Niveles de protecci髇 (c骴igo IP) – Protecci髇 del equipo el閏trico frente a objetos extra駉s, al agua y al acceso (sin cambio en los par醡etros); valor m韓imo IP 40. 220, 221
      4.5 Protecci髇 frente a sobretensiones

      Verificar que la unidad instalada en el veh韈ulo es capaz de soportar un suministro el閏trico de:

      versiones de 24 V-:-34 V a + 40 癈 1 hora; y

      versiones de 12 V-:-17 V a + 40 癈 1 hora.

      (ISO 16750-2)

      		 216
      4.6 Protecci髇 frente a la inversi髇 de la polaridad

      Verificar que la unidad instalada en el veh韈ulo es capaz de soportar una inversi髇 de su fuente de alimentaci髇.

      (ISO 16750-2)

      		 216
      4.7 Protecci髇 frente a cortocircuitos

      Verificar que las se馻les de entrada y de salida est醤 protegidas frente a cortocircuitos a la fuente de alimentaci髇 y a masa.

      (ISO 16750-2)

      		 216
      5 Pruebas de compatibilidad electromagn閠ica
      5.1 Emisiones radiadas y susceptibilidad Cumplimiento del Reglamento n. 10 de la CEPE. 218
      5.2 Descarga electrost醫ica

      Cumplimiento de la norma ISO 10605:2008 +

      Corrigendum T閏nico 2010 +

      AMD1:2014: +/– 4 kV para contacto +/– 8 kV para descarga de aire.

      		 218
      5.3 Susceptibilidad transitoria conducida en la fuente de alimentaci髇

      Para versiones 24 V: cumplimiento de la ISO 7637-2 + Reglamento n. 10 de la CEPE, Rev. 3:

      -impulso 1a: Vs = – 450 V, Ri = 50 ohmios

      -impulso 2a: Vs = + 37 V, Ri = 2 ohmios

      -impulso 2b: Vs = + 20 V, Ri = 0,05 ohmios

      -impulso 3a: Vs = – 150 V, Ri = 50 ohmios

      -impulso 3b: Vs = + 150 V, Ri = 50 ohmios

      -impulso 4: Vs = – 16 V, Va = – 12 V, t6 =100 ms

      -impulso 5: Vs = + 120 V, Ri = 2,2 ohmios, td = 250 ms.

      Para versiones 12 V: cumplimiento de la ISO 7637-1 + Reglamento n. 10 de la CEPE, Rev. 3:

      -impulso 1: Vs = – 75 V, Ri = 10 ohmios

      -impulso 2a: Vs = + 37 V, Ri = 2 ohmios

      -impulso 2b: Vs = + 10 V, Ri = 0,05 ohmios

      -impulso 3a: Vs = – 112 V, Ri = 50 ohmios

      -impulso 3b: Vs = + 75 V, Ri = 50 ohmios

      -impulso 4: Vs = – 6 V, Va = – 5 V, t6 = 15 ms

      -impulso 5: Vs = + 65 V, Ri = 3 ohmios, td = 100 ms.

      -El impulso 5 deber verificarse exclusivamente en las unidades intravehiculares concebidas para ser instaladas en veh韈ulos que no dispongan de protecci髇 com鷑 externa contra volcado de la carga.

      Para las propuestas de volcado de la carga, rem韙ase a la ISO 16750-2, 4.a edici髇, apartado 4.6.4.

      		 218
      Ir a Norma afectada
    • d) el apartado 6 se sustituye por el texto siguiente:

      6. PRUEBAS DEL DISPOSITIVO DE COMUNICACI覰 A DISTANCIA EXTERNO

      N. Prueba Descripci髇 Condiciones correspondientes
      1. Examen administrativo
      1.1. Documentaci髇 Correcci髇 de la documentaci髇
      2. Inspecci髇 visual
      2.1. Cumplimiento de lo dispuesto en la documentaci髇
      2.2. Identificaci髇/inscripciones 225, 226
      2.3. Materiales 219 a 223
      3. Pruebas funcionales
      3.1. Comunicaci髇 remota para pruebas en carretera espec韋icas 4, 197 a 199
      3.2. Registro y almacenamiento de datos en la memoria 91
      3.3. Comunicaci髇 con la unidad instalada en el veh韈ulo Ap閚dice 14, DSC_66 a DSC_70, DSC_71 a DSC_76
      4. Pruebas ambientales
      4.1. Temperatura

      Verificar la funcionalidad mediante:

      -Prueba en virtud de la ISO 16750-4, apartado 5.1.1.2: prueba de funcionamiento a temperatura baja (72 h a – 20 癈).

      Esta prueba se refiere a la IEC 60068-2-1: Verificaci髇 medioambiental – Parte 2-1: Pruebas – Prueba A: Fr韔

      -Prueba en virtud de la ISO 16750-4: apartado 5.1.2.2: prueba de funcionamiento a temperatura alta (72 h a 70 癈).

      Esta prueba se refiere a la IEC 60068-2-2: Procedimientos b醩icos de verificaci髇 medioambiental; Parte 2: pruebas; Prueba B: Calor seco.

      -Prueba en virtud de la ISO 16750-4, apartado 5.3.2: cambio r醦ido de temperatura con una duraci髇 de transici髇 espec韋ica (– 20 癈 / 70 癈, 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髇 3 de esta tabla) a la temperatura m醩 baja, a la temperatura m醩 alta y durante los ciclos de temperatura.

      		 213
      4.2. Protecci髇 frente a la penetraci髇 de agua y cuerpos extra駉s Prueba en virtud de la ISO 20653: Veh韈ulos de carretera – Niveles de protecci髇 (c骴igo IP) – Protecci髇 del equipo el閏trico frente a objetos extra駉s, al agua y al acceso (valor objetivo IP40) 220, 221
      5. Pruebas de compatibilidad electromagn閠ica
      5.1. Emisiones radiadas y susceptibilidad Cumplimiento del Reglamento n. 10 de la CEPE. 218
      5.2. Descarga electrost醫ica Cumplimiento de la norma ISO 10605:2008 + Corrigendum T閏nico 2010 + AMD1:2014:+/– 4 kV para contacto +/– 8 kV para descarga de aire. 218
      5.3. Susceptibilidad transitoria conducida en la fuente de alimentaci髇

      Para versiones 24 V: cumplimiento de la ISO 7637-2 + Reglamento n. 10 de la CEPE, Rev. 3:

      -impulso 1a: Vs = – 450 V, Ri = 50 ohmios

      -impulso 2a: Vs = + 37 V, Ri = 2 ohmios

      -impulso 2b: Vs = + 20 V, Ri = 0,05 ohmios

      -impulso 3a: Vs = – 150 V, Ri = 50 ohmios

      -impulso 3b: Vs = + 150 V, Ri = 50 ohmios

      -impulso 4: Vs = – 16 V, Va = – 12 V, t6 = 100 ms

      -impulso 5: Vs = + 120 V, Ri = 2,2 ohmios, td = 250 ms.

      Para versiones 12 V: cumplimiento de la ISO 7637-1 + Reglamento n. 10 de la CEPE, Rev. 3:

      -impulso 1: Vs = – 75 V, Ri = 10 ohmios

      -impulso 2a: Vs = + 37 V, Ri = 2 ohmios

      -impulso 2b: Vs = + 10 V, Ri = 0,05 ohmios

      -impulso 3a: Vs = – 112 V, Ri = 50 ohmios

      -impulso 3b: Vs = + 75 V, Ri = 50 ohmios

      -impulso 4: Vs = – 6 V, Va = – 5 V, t6 = 15 ms

      -impulso 5: Vs = + 65 V, Ri = 3 ohmios, td = 100 ms.

      -El impulso 5 deber verificarse exclusivamente en las unidades intravehiculares concebidas para ser instaladas en veh韈ulos que no dispongan de protecci髇 com鷑 externa contra volcado de la carga.

      Para las propuestas de volcado de la carga, rem韙ase a la ISO 16750-2, 4.a edici髇, apartado 4.6.4.

      		 218
      Ir a Norma afectada
    • e) en el apartado 8, el cuadro sobre las pruebas de interoperabilidad se sustituye por el siguiente:
      N. Prueba Descripci髇

      8.1

      Pruebas de interoperabilidad entre las unidades intravehiculares y las tarjetas de tac骻rafo
      1 Autenticaci髇 mutua Comprobar que la autenticaci髇 mutua entre la unidad instalada en el veh韈ulo y la tarjeta de tac骻rafo funciona normalmente.
      2 Pruebas de lectura/escritura

      Ejecutar un escenario de actividad t韕ico en la unidad instalada en el veh韈ulo. Dicho escenario deber adaptarse al tipo de tarjeta que se est verificando y deber incluir pruebas de escritura en tantos EF como sea posible en la tarjeta.

      Verificar mediante una transferencia de la unidad instalada en el veh韈ulo que todos los registros correspondientes se han realizado correctamente.

      Verificar mediante una transferencia de la tarjeta que todos los registros correspondientes se han realizado correctamente.

      Verificar mediante una impresi髇 diaria que todos los registros correspondientes se pueden leer correctamente.

      8.2

      Pruebas de interoperabilidad entre las unidades intravehiculares y los sensores de movimiento
      1 Emparejamiento Comprobar que el emparejamiento entre las unidades intravehiculares y los sensores de movimiento funciona normalmente.
      2 Pruebas de actividad

      Ejecutar un escenario de actividad t韕ico en el sensor de movimiento. El escenario incluir una actividad normal y crear el mayor n鷐ero de incidentes o fallos posible.

      Verificar mediante una transferencia de la unidad instalada en el veh韈ulo que todos los registros correspondientes se han realizado correctamente.

      Verificar mediante una transferencia de la tarjeta que todos los registros correspondientes se han realizado correctamente.

      Verificar mediante una impresi髇 diaria que todos los registros correspondientes se pueden leer correctamente.

      8.3

      Pruebas de interoperabilidad entre las unidades intravehiculares y las instalaciones GNSS externas (si procede)
      1 Autenticaci髇 mutua Comprobar que la autenticaci髇 mutua (acoplamiento) entre la unidad instalada en el veh韈ulo y el m骴ulo GNSS externo funciona normalmente.
      2 Pruebas de actividad

      Ejecutar un escenario de actividad t韕ico en el m骴ulo GNSS externo. El escenario incluir una actividad normal y crear el mayor n鷐ero de incidentes o fallos posible.

      Verificar mediante una transferencia de la unidad instalada en el veh韈ulo que todos los registros correspondientes se han realizado correctamente.

      Verificar mediante una transferencia de la tarjeta que todos los registros correspondientes se han realizado correctamente.

      Verificar mediante una impresi髇 diaria que todos los registros correspondientes se pueden leer correctamente.
      Ir a Norma afectada
  • 36) El ap閚dice 11 se modifica como sigue:
    • a) en el apartado 8.2.3, el punto CSM_49 se sustituye por el texto siguiente:

      獵SM_49 Las unidades instaladas en los veh韈ulos, las tarjetas de tac骻rafo y los dispositivos GNSS externos admitir醤 los algoritmos SHA-256, SHA-384 y SHA-512 especificados en [SHS].

      Ir a Norma afectada
    • b) en el apartado 9.1.2, el primer p醨rafo del punto CSM_58 se sustituye por el texto siguiente:

      CSM_58 Siempre que genere un nuevo par de claves ra韟 europeo, la ERCA crear un certificado de enlace para la nueva clave p鷅lica europea y la firmar con la clave privada europea anterior. El per韔do de validez del certificado de enlace ser de 17 a駉s y 3 meses. Lo anterior se indica asimismo en la figura 1 de la secci髇 9.1.7.

      Ir a Norma afectada
    • c) en el apartado 9.1.4, el punto CSM_72 se sustituye por el texto siguiente:

      CSM_72 Para cada unidad instalada en el veh韈ulo se generar醤 dos pares de claves ECC 鷑icos, 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鷅lica a la MSCA, a fin de obtener el certificado VU correspondiente firmado por la MSCA. La clave privada ser utilizada solamente por la unidad instalada en el veh韈ulo.

      Ir a Norma afectada
    • d) el apartado 9.1.5 se modifica como sigue:
      • i) el punto CSM_83 se sustituye por el texto siguiente:

        CSM_83 Para cada tarjeta de tac骻rafo se generar un par de claves ECC 鷑ico, designado Card_MA. Adem醩, para cada tarjeta de conductor y cada tarjeta de taller se generar un segundo par de claves ECC 鷑ico, designado Card_Sign. Esta tarea puede ser efectuada por los fabricantes de tarjetas o los personalizadores de tarjetas. Siempre que se genere un nuevo par de claves de tarjeta, la parte que genere la clave enviar la clave p鷅lica a la MSCA, a fin de obtener el certificado de la tarjeta correspondiente firmado por la MSCA. La clave privada ser utilizada solamente por la tarjeta de tac骻rafo.

      • ii) el punto CSM_88 se sustituye por el texto siguiente:

        CSM_88 El per韔do de validez de un certificado Card_MA ser el siguiente:

        • - Para las tarjetas de conductor: 5 a駉s
        • - Para las tarjetas de empresa: 5 a駉s
        • - Para las tarjetas de control: 2 a駉s
        • - Para las tarjetas de taller: 1 a駉
      • iii) se a馻de el guion siguiente al punto CSM_91:
        • - Adem醩, para las tarjetas de control, las tarjetas de empresa y las tarjetas de taller, y solo si estas tarjetas se expiden durante los tres primeros meses del per韔do de validez del nuevo certificado EUR: el certificado EUR que sea dos generaciones m醩 antiguo, de existir este.

        Nota al 鷏timo guion: por ejemplo, en los tres primeros meses del certificado ERCA (3) (v閍se la figura 1), las mencionadas tarjetas contendr醤 el certificado ERCA (1). Esto es necesario para garantizar que estas tarjetas pueden utilizarse para realizar transferencias de datos desde VU con certificado ERCA (1) cuyo per韔do de vida normal de quince a駉s m醩 el per韔do de tres meses para transferir los datos expira durante estos meses; v閍se el 鷏timo guion del requisito 13 del anexo IC.

      Ir a Norma afectada
    • e) el apartado 9.1.6 se modifica como sigue:
      • i) el punto CSM_93 se sustituye por el texto siguiente:

        CSM_93 Para cada dispositivo GNSS externo se generar un par de claves ECC 鷑ico designado EGF_MA. Esta tarea es efectuada por los fabricantes de dispositivos GNSS externos. Siempre que se genere un nuevo par de claves EGF_MA, la parte que genere la clave enviar la clave p鷅lica a la MSCA, a fin de obtener el certificado EGF_MA correspondiente firmado por la MSCA. La clave privada ser utilizada solamente por el dispositivo GNSS externo.

      • ii) el punto CSM_95 se sustituye por el texto siguiente:

        CSM_95 Una dispositivo GNSS externo utilizar su par de claves EGF_MA, compuesto por la clave privada EGF_MA.SK y la clave p鷅lica EGF_MA.PK, exclusivamente para efectuar la autenticaci髇 mutua y establecer la clave de sesi髇 con las unidades instaladas en los veh韈ulos, tal como se especifica en el apartado 11.4 del presente ap閚dice.

      Ir a Norma afectada
    • f) el apartado 9.1.7 se modifica como sigue:
      • i) la figura 1 se sustituye por lo siguiente:

        Figura 1

        Expedici髇 y uso de las diferentes generaciones de certificados ra韟 ERCA, certificados de enlace ERCA, certificados MSCA y certificados de equipos

      • ii) la nota 6 de la figura 1 se sustituye por la siguiente:

        6. Por limitaciones de espacio, solamente se indica la diferencia entre los per韔dos de validez de los certificados Card_MA y Card_Sign de la primera generaci髇.

      Ir a Norma afectada
    • g) el apartado 9.2.1.1 se modifica como sigue:
      • i) en el punto CSM_106, el primer guion se sustituye por el texto siguiente:
        • - Para las claves maestras de sensor de movimiento de 128 bits: CV = “B6 44 2C 45 0E F8 D3 62 0B 7A 8A 97 91 E4 5D 83”
      • ii) en el punto CSM_107, el p醨rafo primero se sustituye por el texto siguiente:

        Cada fabricante de sensores de movimiento generar una clave de emparejamiento KP aleatoria y 鷑ica para cada sensor de movimiento y enviar cada clave de emparejamiento a la autoridad de certificaci髇 de su Estado miembro. La MSCA cifrar cada clave de emparejamiento separadamente con la clave maestra KM del sensor de movimiento y devolver la clave cifrada al fabricante del sensor de movimiento. Para cada clave cifrada, la MSCA notificar al fabricante del sensor de movimiento el n鷐ero de versi髇 de la KM asociada.

      • iii) el punto CSM_108 se sustituye por el texto siguiente:

        CSM_108 Cada fabricante de sensores de movimiento generar un n鷐ero de serie 鷑ico para cada sensor de movimiento y enviar todos los n鷐eros de serie a la autoridad de certificaci髇 de su Estado miembro. La MSCA cifrar cada n鷐ero de serie separadamente con la clave de identificaci髇 maestra KID y devolver el n鷐ero de serie cifrado al fabricante del sensor de movimiento. Para cada n鷐ero de serie cifrado, la MSCA notificar al fabricante del sensor de movimiento el n鷐ero de versi髇 de la KID asociada.

      Ir a Norma afectada
    • h) el apartado 9.2.2.1 se modifica como sigue:
      • i) el punto CSM_123 se sustituye por el texto siguiente:

        CSM_123 Para cada unidad instalada en el veh韈ulo, el fabricante de la unidad instalada en el veh韈ulo crear un n鷐ero de serie de la VU 鷑ico y lo enviar a la autoridad de certificaci髇 de su Estado miembro en una solicitud de obtenci髇 de un conjunto de dos claves DSRC espec韋icas de la VU. El n鷐ero de serie de la VU tendr el tipo de dato

        Nota:

        • - Este n鷐ero de serie de la VU ser id閚tico al elemento vuSerialNumber de VuIdentification, v閍se el ap閚dice 1 y la referencia del titular del certificado en los certificados de la VU.
        • - El n鷐ero de serie de la VU puede no conocerse en el momento en que el fabricante de la unidad instalada en el veh韈ulo solicita las claves DSRC espec韋icas de la VU. En este caso, el fabricante de la VU enviar el identificador 鷑ico de la solicitud de certificado que utiliz al solicitar los certificados de la VU; v閍se CSM_153. Dicho identificador de la solicitud de certificado ser, por tanto, igual a la referencia del titular del certificado de los certificados de la VU.
      • ii) en el punto CSM_124, el requisito de informaci髇 del paso 2 se sustituye por el texto siguiente:

        玦nfo = n鷐ero de serie o identificador de la solicitud de certificado de la VU tal como se especifica en CSM_123

      • iii) el punto CSM_128 se sustituye por el texto siguiente:

        CSM_128 La MSCA llevar un registro de todas las claves DSRC espec韋icas de VU que haya generado, su n鷐ero de versi髇 y el n鷐ero de serie o el identificador de la solicitud de certificado de la VU utilizados para derivarlas.

      Ir a Norma afectada
    • i) en el apartado 9.3.1, el primer p醨rafo del punto CSM_135 se sustituye por el texto siguiente:

      A fin de codificar los objetos de datos en los certificados, se utilizar醤 las reglas de codificaci髇 distinguida (DER) de acuerdo con la norma [ISO 8825-1]. La tabla 4 muestra la codificaci髇 completa del certificado, incluidas todas las etiquetas y los bytes de longitud.

      Ir a Norma afectada
    • j) en el apartado 9.3.2.3, el punto CSM_141 se sustituye por el texto siguiente:

      CSM_141 La autorizaci髇 del titular del certificado servir para identificar el tipo de certificado. Se compone de los seis bytes m醩 significativos del identificador de la aplicaci髇 del tac骻rafo, concatenados con el tipo de equipo, que indica el tipo de equipo al que est destinado el certificado. En el caso de un certificado de la VU, un certificado de la tarjeta de conductor o un certificado de la tarjeta de taller, el tipo de equipo tambi閚 se utiliza para diferenciar entre un certificado para la autenticaci髇 mutua y un certificado para la creaci髇 de firmas digitales (v閍nse el apartado 9.1 y el ap閚dice 1, tipo de datos EquipmentType).

      Ir a Norma afectada
    • k) en el apartado 9.3.2.5, se a馻de el siguiente p醨rafo en el punto CSM_146:

      Nota: En el caso de un certificado de la tarjeta, el valor de la CHR ser igual al valor del cardExtendedSerialNumber del archivo EF_ICC; v閍se el ap閚dice 2. En el caso de un certificado EGF, el valor de la CHR ser igual al valor del sensorGNSSSerialNumber del archivo EF_ICC; v閍se el ap閚dice 14. En el caso de un certificado de VU, el valor de la CHR ser igual al valor del elemento vuSerialNumber de VuIdentification, v閍se el ap閚dice 1, a menos que el fabricante no conozca el n鷐ero de serie espec韋ico del fabricante en el momento de solicitar el certificado.

      Ir a Norma afectada
    • l) en el apartado 9.3.2.6, el punto CSM_148 se sustituye por el texto siguiente:

      CSM_148 La fecha efectiva del certificado indicar la fecha y hora de inicio del per韔do de validez del certificado.

      Ir a Norma afectada
    • m) el apartado 9.3.3 se modifica como sigue:
      • i) en el punto CSM_151, el p醨rafo primero se sustituye por el texto siguiente:

        Al solicitar un certificado, la MSCA enviar los siguientes datos a su ERCA:

      • ii) el punto CSM_153 se sustituye por el texto siguiente:

        CSM_153 En una solicitud de certificado, un fabricante de equipos enviar los siguientes datos a la MSCA a fin de permitirle crear la referencia del titular del certificado del nuevo certificado de equipo:

        • - si se conoce (v閍se CSM_154), un n鷐ero de serie para el equipo, 鷑ico para el fabricante, el tipo de equipo, y el mes de fabricaci髇. En caso contrario, un identificador 鷑ico de la solicitud de certificado.
        • - El mes y a駉 de fabricaci髇 del equipo o de solicitud del certificado.

        El fabricante garantizar que estos datos sean correctos y que el certificado devuelto por la MSCA sea insertado en el equipo previsto.

      Ir a Norma afectada
    • n) el apartado 10.2.1 se modifica como sigue:
      • i) en el punto CSM_157, el texto que precede a las notas de la figura 4 se sustituye por el texto siguiente:

        Las unidades instaladas en el veh韈ulo utilizar醤 el protocolo ilustrado en la figura 4 para verificar la cadena de certificados de una tarjeta de tac骻rafo. Para cada certificado que lea en la tarjeta, la VU verificar que el campo “Autorizaci髇 del titular del certificado” (CHA) sea correcto:

        • - El campo CHA del certificado Card indicar un certificado de tarjeta para la autenticaci髇 mutua (v閍se ap閚dice 1, tipo de datos EquipmentType).
        • - El campo CHA del certificado Card.CA indicar una MSCA.
        • - El campo CHA del certificado Card.Link indicar una ERCA.
      • ii) en el punto CSM_159 se a馻de la frase siguiente:

        Mientras que el almacenamiento de todos los dem醩 tipos de certificados es facultativo, es obligatorio que la VU almacene todo nuevo certificado de enlace presentado por una tarjeta.

      Ir a Norma afectada
    • o) el apartado 10.2.2 se modifica como sigue:
      • i) en el punto CSM_161, el texto que precede a la figura 5 se sustituye por el texto siguiente:

        Las tarjetas de tac骻rafo utilizar醤 el protocolo ilustrado en la figura 5 para verificar la cadena de certificados de una VU. Para cada certificado presentado por la VU, la tarjeta verificar que el campo “Autorizaci髇 del titular del certificado” (CHA) sea correcto:

        • - El campo CHA del certificado VU.Link indicar una ERCA.
        • - El campo CHA del certificado VU.CA indicar una MSCA.
        • - El campo CHA del certificado VU indicar un certificado de VU para la autenticaci髇 mutua (v閍se ap閚dice 1, tipo de datos EquipmentType).
      • ii) el punto CSM_165 se sustituye por el texto siguiente:

        CSM_165 Si el comando MSE: Set AT se ejecuta correctamente, la tarjeta establecer la VU.PK indicada para su uso posterior durante la autenticaci髇 del veh韈ulo, y almacenar temporalmente Comp(VU.PKeph). En el caso de que se env韊n dos o m醩 comandos MSE: Set AT ejecutados correctamente antes de efectuar el acuerdo de claves de sesi髇, la tarjeta almacenar 鷑icamente la 鷏tima Comp(VU.PKeph) recibida. La tarjeta reiniciar Comp(VU.PKeph) despu閟 de un comando GENERAL AUTHENTICATE ejecutado correctamente.

      Ir a Norma afectada
    • p) el apartado 10.3 se modifica como sigue:
      • i) el primer p醨rafo del punto CSM_170 se sustituye por el texto siguiente:

        Junto a la comprobaci髇 de la tarjeta, la VU incluir en la firma la referencia del titular del certificado extra韉a del certificado de la tarjeta.

      • ii) en el punto CSM_171, la figura 6 se sustituye por la siguiente:

        Figura 6

        Protocolo de autenticaci髇 de VU

      • iii) el punto CSM_174 se sustituye por el texto siguiente:

        CSM_174 Al recibir la firma de la VU en un comando EXTERNAL AUTHENTICATE, la tarjeta:

        • - calcular el token de autenticaci髇 concatenando Card.CHR, la comprobaci髇 de tarjeta rcard y el identificador de la clave p鷅lica ef韒era de la VU Comp(VU.PKeph);
        • - verificar la firma de la VU mediante el algoritmo ECDSA, en combinaci髇 con el algoritmo hash relacionado con el tama駉 de clave del par de claves VU_MA de la VU, tal como se especifica en CSM_50, y en combinaci髇 con la clave VU.PK y el token de autenticaci髇 calculado.
      Ir a Norma afectada
    • q) en el apartado 10.4, el punto CSM_176 queda modificado como sigue:
      • i) el punto 2 se sustituye por el texto siguiente:

        2. La VU env韆 el punto p鷅lico VU.PKeph de su par de claves ef韒ero a la tarjeta. El punto p鷅lico se convertir en una cadena de octetos tal como se especifica en la directriz t閏nica [TR-03111]. Se utilizar el formato de codificaci髇 descomprimido. Como se indica en CSM_164, la VU gener este par de claves ef韒ero antes de la verificaci髇 de la cadena de certificados de la VU. La VU envi el identificador de la clave p鷅lica ef韒era Comp(VU.PKeph) a la tarjeta, y la tarjeta lo almacen.

      • ii) el punto 6 se sustituye por el texto siguiente:

        6. Mediante la clave KMAC, la tarjeta computa un token de autenticaci髇 a trav閟 del identificador del punto p鷅lico ef韒ero de la VU: TPICC = CMAC(KMAC, VU.PKeph). El punto p鷅lico deber estar en el formato utilizado por la VU (v閍se el punto 2). La tarjeta env韆 NPICC y TPICC a la unidad instalada en el veh韈ulo.

      Ir a Norma afectada
    • r) en el apartado 10.5.2, el punto CSM_191 se sustituye por el texto siguiente:

      CSM_191 Los objetos de datos que deban cifrarse se rellenar醤 de acuerdo con la norma [ISO 7816-4] mediante el indicador de contenido de relleno ‘01’. Para el c醠culo del MAC, los objetos de datos de la APDU se rellenar醤 conforme a la norma [ISO 7816-4].

      Nota: El relleno para la mensajer韆 segura siempre es efectuado por la capa de mensajer韆 segura, no por los algoritmos CMAC o CBC.

      Resumen y ejemplos

      Un comando APDU con mensajer韆 segura aplicada tendr la siguiente estructura, dependiendo del caso del comando no securizado correspondiente (DO significa objeto de datos):

      Caso 1 : CLA INS P1 P2 || Lc' || DO ‘8E’ || Le
      Caso 2 : CLA INS P1 P2 || Lc' || DO ‘97’ || DO ‘8E’ || Le
      Caso 3 (byte INS par) : CLA INS P1 P2 || Lc' || DO ‘81’ || DO ‘8E’ || Le
      Caso 3 : (byte INS impar): CLA INS P1 P2 || Lc' || DO ‘B3’ || DO ‘8E’ || Le
      Caso 4 (byte INS par) : CLA INS P1 P2 || Lc' || DO ‘81’ || DO ‘97’ || DO ‘8E’ || Le
      Caso 4 (byte INS impar) : CLA INS P1 P2 || Lc' || DO ‘B3’ || DO ‘97’ || DO ‘8E’ || Le

      donde Le = ‘00’ o ‘00 00’, dependiendo de si se usan campos de corta longitud o de longitud extendida; v閍se la norma [ISO 7816-4].

      Una respuesta APDU con mensajer韆 segura aplicada tendr la siguiente estructura, dependiendo del caso del comando no securizado correspondiente:

      Caso 1o 3 : DO ‘99’ || DO ‘8E’ || SW1SW2
      Caso 2 o 4 (byte INS par) sin cifrado : DO ‘81’ || DO ‘99’ || DO ‘8E’ || SW1SW2
      Caso 2 o 4 (byte INS par) con cifrado : DO ‘87’ || DO ‘99’ || DO ‘8E’ || SW1SW2
      Caso 2 o 4 (byte INS impar) sin cifrado : DO ‘B3’ || DO ‘99’ || DO ‘8E’ || SW1SW2

      Nota: El caso 2 o 4 (byte INS impar) con cifrado no se usa nunca en la comunicaci髇 entre una VU y una tarjeta.

      A continuaci髇 figuran tres ejemplos de transformaciones APDU para comandos con c骴igo INS par. La figura 8 muestra un comando APDU de caso 4 autenticado, la figura 9 muestra una respuesta APDU de caso 1/caso 3 autenticada, y la figura 10 muestra una respuesta APDU de caso 2/caso 4 cifrada y autenticada.

      Figura 8

      Transformaci髇 de un comando APDU de caso 4 autenticado

      Figura 9

      Transformaci髇 de una respuesta APDU de caso 1 / caso 3 autenticada

      Figura 10

      Transformaci髇 de una respuesta APDU de caso 2 / caso

      Ir a Norma afectada
    • s) en el apartado 10.5.3, el punto CSM_193 se sustituye por el texto siguiente:

      CSM_193 Una tarjeta de tac骻rafo abortar una sesi髇 de mensajer韆 segura en curso solamente si se da una de las condiciones siguientes:

      • - recibe un comando APDU plano;
      • - detecta un error de mensajer韆 segura en un comando APDU:
        • - falta un objeto de datos de mensajer韆 segura esperado, el orden de los objetos de datos es incorrecto, o hay incluido un objeto de datos desconocido;
        • - un objeto de datos de mensajer韆 segura es incorrecto, por ejemplo, el valor MAC es incorrecto o la estructura TLC es incorrecta;
        • - no recibe alimentaci髇 el閏trica o ha sido restaurada;
        • - la VU inicia el proceso de autenticaci髇 de la VU;
        • - se ha alcanzado el l韒ite de n鷐ero de comandos y respuestas asociadas en la sesi髇 actual. Este l韒ite lo definir para cada tarjeta concreta su fabricante, teniendo en cuenta los requisitos de seguridad del soporte f韘ico utilizado, con un valor m醲imo de 240 comandos y respuestas asociadas de SM por sesi髇.
      Ir a Norma afectada
    • t) el apartado 11.3.2 se modifica como sigue:
      • i) el primer p醨rafo del punto CSM_208 se sustituye por el texto siguiente:

        Durante el acoplamiento a una VU, un dispositivo GNSS externo utilizar el protocolo ilustrado en la figura 5 (secci髇 10.2.2) para verificar la cadena de certificados de la VU.

      • ii) el punto CSM_210 se sustituye por el texto siguiente:

        CSM_210 Una vez verificado el certificado VU_MA, el dispositivo GNSS externo almacenar el certificado para utilizarlo durante el funcionamiento normal. V閍se el apartado 11.3.3.

      Ir a Norma afectada
    • u) en el apartado 11.3.3, el primer p醨rafo del punto CSM_211 se sustituye por el texto siguiente:

      Durante el funcionamiento normal, una unidad instalada en el veh韈ulo y una EGF utilizar醤 el protocolo ilustrado en la figura 11 para verificar la validez temporal del certificado EGF_MA almacenado y para configurar la clave p鷅lica VU_MA para la posterior autenticaci髇 de la VU. Durante el funcionamiento normal no se efectuar ninguna nueva verificaci髇 mutua de las cadenas de certificados.

      Ir a Norma afectada
    • v) en el apartado 12.3, la tabla 6 se sustituye por la siguiente:
      Tabla 6N鷐ero de bytes de datos de texto plano y cifrados por instrucci髇 definido en la norma [ISO 16844-3]
      Instrucci髇 Solicitud/respuesta Descripci髇 de los datos # de bytes de datos de texto plano mediante claves AES # de bytes de datos cifrados mediante claves AES de longitud en bits de # de bytes de texto plano seg鷑
      128 192 256
      10 solicitud Datos de autenticaci髇 + n鷐ero de archivo 8 8 16 16 16
      11 respuesta Datos de autenticaci髇 + contenido de archivo 16 o 32, seg鷑 el archivo 16 o 32, seg鷑 el archivo 32 / 48 32 / 48 32 / 48
      41 solicitud N. de serie del sensor 8 8 16 16 16
      41 respuesta Clave de emparejamiento 16 16 / 24 / 32 16 32 32
      42 solicitud Clave de sesi髇 16 16 / 24 / 32 16 32 32
      43 solicitud Informaci髇 de emparejamiento 24 24 32 32 32
      50 respuesta Informaci髇 de emparejamiento 24 24 32 32 32
      70 solicitud Datos de autenticaci髇 8 8 16 16 16
      80 respuesta Valor de contador del sensor + datos de autenticaci髇 8 8 16 16 16
      Ir a Norma afectada
    • w) en el apartado 13.1, el requisito relativo al n鷐ero de serie de la VU que aparece en el punto CSM_224 se sustituye por el texto siguiente:

      玁. de serie de la VU el n鷐ero de serie de la VU o el identificador de la solicitud de certificado (tipo de dato VuSerialNumber o CertificateRequestID), v閍se CSM_123

      Ir a Norma afectada
    • x) en el apartado 13.3, el apartado 2 del punto CSM_228 se sustituye por el texto siguiente:

      2. La tarjeta de control usar la clave maestra DSRC indicada en combinaci髇 con el n鷐ero de serie de la VU o el identificador de la solicitud de certificado en los datos de seguridad DSRC para derivar las claves DSRC K_VUDSRC_ENC y K_VUDSRC_MAC espec韋icas de la VU, tal como se especifica en CSM_124.

      Ir a Norma afectada
    • y) el apartado 14.3 se modifica como sigue:
      • i) en el punto CSM_234, el texto que precede a las notas de la figura 13 se sustituye por el texto siguiente:

        Un IDE puede efectuar por s mismo la verificaci髇 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髇 de la firma se efectuar tal como muestra la Figure 13. Para verificar la validez temporal de un certificado presentado por el IDE, la tarjeta de control utilizar su reloj interno, tal como se especifica en el punto CSM_167. La tarjeta de control actualizar su hora actual si la fecha efectiva de un certificado aut閚tico de ‘fuente v醠ida de hora’ es m醩 reciente que la hora actual de la tarjeta. La tarjeta solamente aceptar los certificados siguientes como fuente v醠ida de hora:

        • - Certificados de enlace ERCA de segunda generaci髇
        • - Certificados de enlace MSCA de segunda generaci髇
        • - Certificados VU_Sign o Card_Sign de segunda generaci髇 expedidos por el mismo pa韘 que el propio certificado de tarjeta de la tarjeta de control.

        En el caso de que efect鷈 la verificaci髇 de la firma por s mismo, el IDE verificar la autenticidad y validez de todos los certificados de la cadena de certificados en el archivo de datos y verificar asimismo la firma en los datos de acuerdo con el esquema de firma definido en la norma [DSS]. En ambos casos, para cada certificado que lea del archivo de datos, es necesario verificar que el campo “Autorizaci髇 del titular de la tarjeta” (CHA) sea correcto:

        • - El campo CHA del certificado EQT indicar un certificado de VU o de tarjeta (seg鷑 proceda) para la firma (v閍se ap閚dice 1, tipo de datos EquipmentType).
        • - El campo CHA del certificado EQT.CA indicar una MSCA.
        • - El campo CHA del certificado EQT.Link indicar una ERCA.
      • ii) la figura 13 se sustituye por lo siguiente:

        Figura 13

        Protocolo para la verificaci髇 de la firma en un archivo de datos descargado

      Ir a Norma afectada
  • 37) El ap閚dice 12 se modifica como sigue:
    • a) el apartado 3 se modifica como sigue:
      • i) en el punto GNS_4, el p醨rafo segundo despu閟 del gr醘ico 2 se sustituye por el texto siguiente:

        La resoluci髇 de la posici髇 se basa en el formato de la secuencia RMC anteriormente descrita. La primera parte de los campos 3 y 5 sirve para representar los grados. El resto se emplea para representar los minutos con tres decimales. Por consiguiente, la resoluci髇 es de 1/1 000 de minuto o 1/60 000 de grado (puesto que un minuto es 1/60 de un grado).

      • ii) el punto GNS_5 se sustituye por el texto siguiente:

        GNS_5 La unidad instalada en el veh韈ulo almacenar en su base de datos la informaci髇 de posici髇 relativa a la latitud y a la longitud con una resoluci髇 de 1/10 de minuto o 1/600 de grado, tal y como se describe en el ap閚dice 1 para las geocoordenadas.

        La VU puede utilizar el comando DOP del GPS y sat閘ites activos (GSA) para definir y registrar la disponibilidad y la precisi髇 de la se馻l. En concreto, la HDOP se emplea para facilitar una indicaci髇 del nivel de precisi髇 de los datos de localizaci髇 registrados (v閍se el apartado 4.2.2). La VU almacenar el valor de la HDOP calculado como el m韓imo de los valores HDOP recogidos en los sistemas GNSS disponibles.

        El identificador del sistema GNSS indica el identificador NMEA correspondiente a cada sistema sat閘ite y el sistema de aumentaci髇 basado en sat閘ites (SBAS).

        Gr醘ico 3

        Estructura de la secuencia GSA

      • iii) el punto GNS_6 se sustituye por el texto siguiente:

        GNS_6 La secuencia GSA se almacenar con el n鷐ero de registro “02” a “06”.

      Ir a Norma afectada
    • b) el apartado 4.2.1 se modifica como sigue:
      • i) el punto GNS_16 se sustituye por el texto siguiente:

        (no afecta a la versi髇 espa駉la)

      • ii) el punto GNS_18 se sustituye por el texto siguiente:

        GNS_18 Para las funciones 1 (recogida y distribuci髇 de datos GNSS), 2 (recogida de los datos de configuraci髇 del dispositivo GNSS externo) y 3 (protocolo de administraci髇), el transceptor seguro GNSS simular una tarjeta inteligente con una arquitectura de archivos del sistema formada por: un archivo principal (MF); un archivo dedicado (DF) con el identificador de aplicaci髇 especificado en el ap閚dice 1, apartado 6.2 (“FF 44 54 45 47 4D”) y con tres EF que contengan certificados; y un archivo elemental 鷑ico (EF.EGF) con el identificador igual a “2F2F”, tal y como se describe en la tabla 1.

      • iii) el punto GNS_20 se sustituye por el texto siguiente:

        GNS_20 El transceptor seguro GNSS utilizar una memoria para almacenar los datos y podr realizar al menos veinte millones de ciclos de escritura/lectura. A excepci髇 de este elemento, el dise駉 interno y la aplicaci髇 del transceptor seguro GNSS queda en manos de los fabricantes.

        El mapeado de los n鷐eros de registro y de los datos se detalla en la tabla 1. Cabe se馻larse que hay cinco secuencias GSA para los sistemas sat閘ite y el sistema de aumentaci髇 basado en sat閘ites (SBAS).

      Ir a Norma afectada
    • c) en el apartado 4.2.2, el apartado 5 del punto GNS_23 se sustituye por el texto siguiente:

      5. El procesador de la VU verifica los datos recibidos (por ejemplo, latitud, longitud o tiempo) al extraer la informaci髇 de la secuencia RMC NMEA. La secuencia RMC NMEA incluye la informaci髇 si la posici髇 es v醠ida. Si la posici髇 no es v醠ida, a鷑 no dispone de datos de localizaci髇 y no pueden emplearse para registrar la posici髇 del veh韈ulo. Si la posici髇 es v醠ida, el procesador de la VU tambi閚 extrae los valores de HDOP de las secuencias GSA NMEA y calcula el valor m韓imo en los sistemas de sat閘ite disponibles (es decir, cuando se disponga de una posici髇).

      Ir a Norma afectada
    • d) en el apartado 4.4.1, el punto GNS_28 se sustituye por el texto siguiente:

      GNS_28 Si la VU no consigue comunicarse con el dispositivo GNSS externo acoplado durante m醩 de veinte minutos seguidos, la VU generar y registrar en la VU un incidente de tipo EventFaultType con el valor de la enumeraci髇 “0EH”“ Communication error with the external GNSS facility” (error de comunicaci髇 con el dispositivo GNSS externo) y con la hora en que se produzca como marca de tiempo. El incidente se generar exclusivamente si se cumplen las siguientes dos condiciones: a) el tac骻rafo inteligente no est en modo calibraci髇 y b) el veh韈ulo est en movimiento. En este contexto, se genera un error de comunicaci髇 cuando el transceptor seguro de la VU no recibe ning鷑 mensaje de respuesta tras un mensaje de petici髇 enviado seg鷑 se describe en el apartado 4.2.

      Ir a Norma afectada
    • e) en el apartado 4.4.2, el punto GNS_29 se sustituye por el texto siguiente:

      GNS_29 Si se ha manipulado el dispositivo GNSS externo, el transceptor seguro GNSS borrar toda su memoria, incluido el material criptogr醘ico. Tal y como se describe en GNS_25 y en GNS_26, la VU detectar la manipulaci髇 si se ha enviado un mensaje de respuesta con el estado “6690”. A continuaci髇, la VU generar un incidente de tipo EventFaultType con la enumeraci髇 “19H Tamper detection of GNSS” (detecci髇 de manipulaci髇 del GNSS). De manera alternativa, el dispositivo GNSS externo podr韆 no responder a ninguna otra solicitud externa m醩.

      Ir a Norma afectada
    • f) en el apartado 4.4.3, el punto GNS_30 se sustituye por el texto siguiente:

      GNS_30 Si el transceptor seguro GNSS no recibe datos del receptor GNSS durante m醩 de tres horas seguidas, el transceptor seguro GNSS generar un mensaje de respuesta con el comando READ RECORD (leer registro) con el n鷐ero de registro “01” y con un campo de datos de 12 bytes, todos ellos fijados en 0xFF. Una vez recibido el mensaje de respuesta con este valor del campo de datos, la VU solamente generar y registrar un incidente de tipo EventFaultType con la enumeraci髇 “0DH Absence of position information from GNSS receiver” (ausencia de informaci髇 de posici髇 del receptor GNSS) y con la hora en que se produzca como marca de tiempo si se cumplen las siguientes dos condiciones: a) el tac骻rafo inteligente no est en modo calibraci髇 y b) el veh韈ulo est en movimiento.

      Ir a Norma afectada
    • g) en el apartado 4.4.4, el texto del punto GNS_31 hasta el gr醘ico 4 se sustituye por el texto siguiente:

      Si la VU detecta que el certificado EGF empleado para las autenticaciones mutuas ya no es v醠ido, generar y registrar un fallo del aparato de control de tipo EventFaultType con la enumeraci髇 “1BH External 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髇 recibidos.

      Ir a Norma afectada
    • h) en el apartado 5.2.1, el punto GNS_34 se sustituye por el texto siguiente:

      GNS_34 Si la VU no recibe datos del receptor GNSS durante m醩 de tres horas seguidas, solamente generar y registrar un incidente de tipo EventFaultType con la enumeraci髇 “0DH Absence of position information from GNSS receiver” (ausencia de informaci髇 de posici髇 del receptor GNSS) y con la hora en que se produzca como marca de tiempo si se cumplen las siguientes dos condiciones: a) el tac骻rafo inteligente no est en modo calibraci髇 y b) el veh韈ulo est en movimiento.

      Ir a Norma afectada
    • i) el apartado 6 se sustituye por el texto siguiente:

      6. ERROR DE SINCRONIZACI覰 DEL GNSS

      Si la VU detecta una discrepancia de m醩 de un minuto entre el tiempo de la funci髇 de medici髇 del tiempo de la unidad instalada en el veh韈ulo y el tiempo procedente del receptor GNSS, generar y registrar un incidente de tipo EventFaultType con la enumeraci髇 “0BH Time conflict (GNSS versus VU internal clock)” (discrepancia temporal entre el GNSS y el reloj interno de la VU). Cuando se produzca una discrepancia temporal, la VU no comprobar el desajuste hasta pasadas doce horas. Este incidente no se producir cuando no hubiera una se馻l GNSS v醠ida detectable por el receptor GNSS en los 鷏timos treinta d韆s..

      Ir a Norma afectada
  • 38) El ap閚dice 13 se modifica como sigue:
    • a) en el apartado 2, el p醨rafo cuarto se sustituye por el texto siguiente:

      A efectos de aclaraci髇, el presente ap閚dice no especifica:

      • - La operaci髇 y gesti髇 de la recogida de los datos en la VU (que se especificar醤 en otro punto del Reglamento, o que de otra manera ser醤 una funci髇 del dise駉 del producto).
      • - La forma de presentaci髇 de los datos recogidos a la aplicaci髇 alojada en el dispositivo externo.
      • - Las disposiciones sobre seguridad de los datos m醩 all de la proporcionada por Bluetooth (como el cifrado) en lo que se refiere al contenido de los datos [que se especificar醤 en otro punto del Reglamento (ap閚dice 11, Mecanismos de seguridad comunes)].
      • - Los protocolos Bluetooth usados por la interfaz ITS.
      Ir a Norma afectada
    • b) en el apartado 4.2, el p醨rafo tercero se sustituye por el texto siguiente:

      Cuando un dispositivo externo entra dentro del radio de alcance de la VU por primera vez, puede iniciarse el proceso de emparejamiento de Bluetooth (v閍se tambi閚 el anexo 2). Los dispositivos comparten sus direcciones, nombres y perfiles y clave secreta com鷑, que les permite conectarse cada vez que entren en contacto en el futuro. Una vez finalizado este paso, el dispositivo externo es de confianza y est en situaci髇 de iniciar solicitudes de descarga de datos del tac骻rafo. No est previsto a馻dir mecanismos de cifrado m醩 all de los facilitados por Bluetooth. No obstante, si se necesitan mecanismos de seguridad adicionales se proceder de conformidad con lo establecido en el ap閚dice 11, Mecanismos de seguridad comunes.

      Ir a Norma afectada
    • c) el apartado 4.3 se modifica como sigue:
      • i) el p醨rafo primero se sustituye por el texto siguiente:

        Por razones de seguridad, la VU requerir un sistema de autorizaci髇 mediante c骴igo PIN separado del emparejamiento Bluetooth. Cada VU ser capaz de generar c骴igos PIN con fines de autenticaci髇 compuestos de al menos cuatro cifras. Cada vez que un dispositivo externo se empareje con la VU deber introducir el c骴igo PIN correcto antes de recibir datos.

      • ii) el p醨rafo tercero despu閟 de la tabla 1 se sustituye por el texto siguiente:

        (no afecta a la versi髇 espa駉la)

    • d) en el apartado 4.4, el segundo p醨rafo que aparece despu閟 del encabezamiento 獵ampo de datos se sustituye por el texto siguiente:

      Si los datos que hay que gestionar son mayores que el espacio disponible en un mensaje, se dividir醤 entre varios submensajes. Cada submensaje tendr la misma cabecera y SID, pero contendr un contador de 2 bytes, Counter Current (CC) y Counter Max (CM), para indicar el n鷐ero de submensajes. Al objeto de permitir la verificaci髇 de errores y la cancelaci髇, el dispositivo receptor confirma cada uno de los submensajes. El dispositivo de recepci髇 puede aceptar el submensaje, solicitar su retransmisi髇, pedir al dispositivo de env韔 que comience de nuevo o abortar la transmisi髇.

      Ir a Norma afectada
    • e) el anexo 1 se modifica como sigue:
      • i) el t韙ulo se sustituye por el texto siguiente:
        • 1) LISTA DE DATOS DISPONIBLES A TRAV蒘 DE LA INTERFAZ ITS
        Ir a Norma afectada
      • ii) se inserta el siguiente elemento en el cuadro del punto 3, despu閟 del elemento 獳usencia de informaci髇 de posici髇 del receptor del GNSS:

        Error de comunicaci髇 con el

        dispositivo GNSS externo

        - el incidente de mayor duraci髇

        ocurrido cada uno de los 鷏timos

        10 d韆s,

        - los 5 incidentes de mayor duraci髇

        ocurridos en los 鷏timos

        365 d韆s.

        - fecha y hora de comienzo del

        incidente,

        - fecha y hora de finalizaci髇 del

        incidente,

        - tipo de tarjeta(s), n鷐ero, Estado

        miembro emisor y generaci髇

        de cualquier tarjeta insertada

        al comenzar o al terminar

        el incidente,

        - n鷐ero de incidentes similares

        ocurridos ese d韆.
        Ir a Norma afectada
      • iii) en el punto 5, se a馻de el guion siguiente:
        • - fallo de la interfaz ITS (si procede)
        Ir a Norma afectada
    • f) las especificaciones ASN.1 del anexo 3 se modifican como sigue:
      • i) se insertan las siguientes filas 206a a 206e tras la fila 206:

      • ii) las filas 262 a 264 se sustituyen por lo siguiente:

      • iii) la fila 275 se sustituye por lo siguiente:

      • iv) las filas 288 a 310 se sustituyen por lo siguiente:

      • v) las filas 362 y 363 se sustituyen por lo siguiente:

      • vi) se insertan las siguientes filas 410a y 410b tras la fila 410:

      • vii) se insertan las siguientes filas 539a a 539j tras la fila 539:

  • 39) El ap閚dice 14 se modifica como sigue:
    • a) el apartado 5.5 del 韓dice se sustituye por el siguiente:

      5.5. Cumplimiento de la Directiva (UE) 2015/719… p. 490

    • b) en el apartado 2, el p醨rafo tercero se sustituye por el texto siguiente:

      En estas circunstancias, el tiempo de que se dispone para la comunicaci髇 es limitado porque la Comunicaci髇 es espec韋ica y tiene un dise駉 de corto alcance. Adem醩, las autoridades de control competentes pueden aprovechar el mismo medio de comunicaci髇 utilizado en la supervisi髇 a distancia de tac骻rafos (RTM) para otras aplicaciones [como los pesos m醲imos y las dimensiones de veh韈ulos pesados que se establecen en la Directiva (UE) 2015/719] y estas operaciones pueden realizarse por separado o de manera consecutiva seg鷑 el criterio de las autoridades de control competentes.

      Ir a Norma afectada
    • c) el apartado 5.1 se modifica como sigue:
      • i) en el punto DSC_19, el duod閏imo guion se sustituye por el texto siguiente:
        • - La antena de la DSRC-VU se colocar en una posici髇 en la que optimice la comunicaci髇 DSRC entre el veh韈ulo y la antena del lector del lado de la carretera, cuando el lector est instalado a quince metros de distancia por delante del veh韈ulo y a dos metros de altura, apuntando al centro vertical y horizontal del parabrisas. En veh韈ulos ligeros, puede instalarse perfectamente en la parte superior del parabrisas. En el caso de los dem醩 veh韈ulos, la antena de la DSRC se instalar, bien cerca la parte inferior del parabrisas, o bien cerca de su parte superior.
      • ii) en el punto DSC_22, el p醨rafo primero se sustituye por el texto siguiente:

        El factor de forma de la antena no se define y constituir una decisi髇 comercial, siempre que la DSRC-VU instalada cumpla los requisitos de conformidad establecidos en la secci髇 5. La antena se colocar del modo establecido en DSC_19 y responder de manera eficaz a los ejemplos de uso descritos en los apartados 4.1.2 y 4.1.3.

      Ir a Norma afectada
    • d) en el apartado 5.4.3, la secuencia 7 se sustituye por el texto siguiente:

      (no afecta a la versi髇 espa駉la)

    • e) en el apartado 5.4.4, la definici髇 del m骴ulo ASN.1 del punto DCS_40 se modifica como sigue:
      • i) la primera l韓ea de la secuencia para

        se sustituye por el texto siguiente:

      • ii) se a馻de la siguiente nota 1:

        1. si una LPN contiene un AlphabetIndicator LatinAlphabetNo2 o latinCyrillicAlphabet, los caracteres especiales se remapean en la unidad del interrogador de carretera aplicando normas especiales de acuerdo con el anexo E de la norma ISO/DIS 14 906,2.

      • iii) se elimina el super韓dice 2 de la l韓ea 玊imestamp of current record;
      • iv) la definici髇 de

        del m骴ulo ASN.1 se sustituye por la siguiente:

    • f) en el apartado 5.4.5, el elemento RTM12 del cuadro 14.3 se sustituye por lo siguiente:

      RTM12

      Fallo de sensor

      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 鷏timos diez d韆s

      —-2 si se ha registrado un incidente de tipo Fallo del receptor GNSS (interno o externo con valores de enumeraci髇 ‘36’H o ‘37’H) en los diez 鷏timos d韆s

      —-3 si se ha registrado un incidente del tipo ‘0E’H Error de comunicaci髇 con el dispositivo GNSS externo en los diez 鷏timos d韆s

      —-4 si se han registrado fallos tanto del sensor como del receptor GNSS en los diez 鷏timos d韆s

      —-5 si se han registrado incidentes tanto de tipo Fallo del sensor como de tipo Error de comunicaci髇 con el dispositivo GNSS externo en los diez 鷏timos d韆s

      —-6 si se han registrado incidentes tanto de tipo Fallo del receptor GNSS como de tipo Error de comunicaci髇 con el dispositivo GNSS externo en los diez 鷏timos d韆s

      —-7 si se han registrado fallos en los tres sensores en los diez 鷏timos d韆s DE LO CONTRARIO, deber asignarse un valor de 0 si no se han registrado incidentes en los diez 鷏timos d韆s

      		 –fallo del sensor un octeto seg鷑 el diccionario de datos

      Ir a Norma afectada
    • g) en el apartado 5.4.6, el punto DSC_43 se sustituye por el texto siguiente:

      Ir a Norma afectada
    • h) en el apartado 5.4.7, en la cuarta columna del cuadro 14.9, el texto en la celda que describe se sustituye por el texto siguiente:

      Identificador de objeto de la norma admitida, parte y versi髇. Ejemplo: ISO (1) Standard (0) TARV (15638) part9 (9) Version1 (1).

      El primer octeto es 06H, que es el identificador del objeto. El segundo octeto es 06H, que es su longitud. Los seis octetos siguientes codifican el identificador de objeto de ejemplo.

    • i) los apartados 5.5 y 5.5.1 se sustituyen por el texto siguiente:

      5.5. Cumplimiento de la Directiva (UE) 2015/719

      5.5.1. Resumen

      DSC_59 Con el fin de cumplir la Directiva (UE) 2015/719, relativa a las dimensiones y los pesos m醲imos de veh韈ulos pesados, el protocolo de transacciones para descargar los datos OWS a trav閟 de un enlace de interfaz DSRC de 5,8 GHz ser el mismo que el utilizado para los datos RTM (v閍se el apartado 5.4.1), con la salvedad de que el identificador de objetos que se refiere a la norma TARV se ajustar a la parte 20 de la norma ISO 15638 (TARV) relativa a WOB/OWS.

      Ir a Norma afectada
    • j) en el apartado 5.6.1, la letra a) del punto DSC_68 se sustituye por el texto siguiente:
      • a) con el fin de poder contratar a varios proveedores el suministro de la VU y la DSRC-VU, e incluso diferentes lotes de DSRC-VU, la conexi髇 entre la VU y la DSRC-VU no interna ser una conexi髇 de norma abierta. La VU se conectar con la DSRC-VU:
      Ir a Norma afectada
    • k) en el apartado 5.7.1, el punto DSC_77 se sustituye por el texto siguiente:

      DSC_77 Los Datos deber醤 ser suministrados, ya protegidos, por la funci髇 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髇 de errores en la transferencia de datos de la VU a la memoria de la DSRC-VU se llevar醤 a cabo con el tipo EventFaultType y el valor de enumeraci髇 fijado en ‘0C’H Error de comunicaci髇 con el dispositivo de comunicaci髇 a distancia, junto con la indicaci髇 temporal..

      Ir a Norma afectada
  • 40) El ap閚dice 15 se modifica como sigue:
    • a) el primer p醨rafo del apartado 2.2 se sustituye por el texto siguiente:

      Se entiende que las tarjetas de tac骻rafo de primera generaci髇 son interoperables con las unidades instaladas en el veh韈ulo de primera generaci髇 [de conformidad con el anexo IB del Reglamento (CEE) n. 3821/85], mientras que las tarjetas de tac骻rafo de segunda generaci髇 son interoperables con las unidades instaladas en el veh韈ulo de segunda generaci髇, de conformidad con el anexo IC del presente Reglamento. Asimismo, ser醤 de aplicaci髇 los siguientes requisitos:

      Ir a Norma afectada
    • b) en el apartado 2.4.1, el punto MIG_11 queda modificado como sigue:
      • i) el primer guion se sustituye por el texto siguiente:
        • - EF (archivos elementales) IC e ICC no firmados (opcional),
      • ii) el tercer guion se sustituye por el texto siguiente:
        • - el resto de EF con datos de aplicaci髇 (dentro del DF tac骻rafo) requeridos por el protocolo de transferencia de datos de la tarjeta de primera generaci髇. Esta informaci髇 debe estar protegida con una firma digital, conforme a los mecanismos de seguridad de la primera generaci髇.

        Dicha trasferencia de datos no incluir EF con datos de aplicaci髇 solo presentes en las tarjetas de conductor (y de taller) de segunda generaci髇 (EF con datos de aplicaci髇 dentro del DF tac骻rafo_G2).

      Ir a Norma afectada
    • c) en el apartado 2.4.3, los puntos MIG_014 y MIG_015 se sustituyen por el texto siguiente:

      MIG_014 Fuera del marco de la supervisi髇 del conductor realizada por las autoridades de control de pa韘es no pertenecientes a la UE, los datos ser醤 transferidos desde las unidades instaladas en el veh韈ulo de segunda generaci髇 utilizando los mecanismos de seguridad de segunda generaci髇, y el protocolo de transferencia de datos especificado en el ap閚dice 7 del presente anexo.

      MIG_015 Para permitir el control de los conductores por parte de autoridades de control no pertenecientes a la UE, tambi閚 podr韆 ser posible la opci髇 de realizar la trasferencia de datos desde unidades instaladas en el veh韈ulo de segunda generaci髇 utilizando los mecanismos de seguridad de la primera generaci髇. Los datos transferidos deber醤 tener entonces el formato de los datos transferidos desde una unidad instalada en el veh韈ulo de primera generaci髇. Esta capacidad podr seleccionarse mediante los comandos del men.

      Ir a Norma afectada

ANEXO II

El anexo II del Reglamento (UE) 2016/799 se modifica como sigue:

  • 1) En el cap韙ulo I, apartado 1, la letra b) se sustituye por el texto siguiente:
    • b) un n鷐ero de homologaci髇 correspondiente al n鷐ero del certificado de homologaci髇 que se haya asignado al prototipo del aparato de control o de la hoja de registro o de la tarjeta de tac骻rafo, colocado en cualquier posici髇 cerca del rect醤gulo.
    Ir a Norma afectada
  • 2) En el cap韙ulo III, el punto 5 se sustituye por el texto siguiente:
    • 5. Presentado para su homologaci髇 el …
    Ir a Norma afectada
  • 3) En el cap韙ulo IV, el punto 5 se sustituye por el texto siguiente:
    • 5. Presentado para su homologaci髇 el …
    Ir a Norma afectada
(1)

DO L 60 de 28.2.2014, p. 1.

Ver Texto
(2)

Reglamento de Ejecuci髇 (UE) 2016/799 de la Comisi髇, de 18 de marzo de 2016, por el que se ejecuta el Reglamento (UE) n. 165/2014 del Parlamento Europeo y del Consejo, que establece los requisitos para la construcci髇, ensayo, instalaci髇, funcionamiento y reparaci髇 de los tac骻rafos y de sus componentes (DO L 139 de 26.5.2016, p. 1).

Ver Texto
(3)

Directiva 2014/53/UE del Parlamento Europeo y del Consejo, de 16 de abril de 2014, relativa a la armonizaci髇 de las legislaciones de los Estados miembros sobre la comercializaci髇 de equipos radioel閏tricos, y por la que se deroga la Directiva 1999/5/CE (DO L 153 de 22.5.2014, p. 62).

Ver Texto
(4)

Reglamento (CEE) n. 3821/85 del Consejo, de 20 de diciembre de 1985, relativo al aparato de control en el sector de los transportes por carretera (DO L 370 de 31.12.1985, p. 8).

Ver Texto
(5)

Directiva 2014/53/UE del Parlamento Europeo y del Consejo, de 16 de abril de 2014, relativa a la armonizaci髇 de las legislaciones de los Estados miembros sobre la comercializaci髇 de equipos radioel閏tricos, y por la que se deroga la Directiva 1999/5/CE (DO L 153 de 22.5.2014, p. 62).

Ver Texto