EXPOSICIÓN DE MOTIVOS
1.Contexto de la política
El volumen creciente del transporte por carretera en la Unión Europea plantea varios problemas. El transporte por carretera es responsable de la mayoría de las emisiones de gases de efecto invernadero y contaminantes atmosféricos procedentes del sector del transporte en su conjunto. Si bien la seguridad vial en la Unión ha mejorado en las últimas décadas, recientemente esta tendencia se ha visto ralentizada, por lo que es poco probable que se alcance el objetivo de reducir en un 50 % el número de muertes entre 2010 y 2020. Además, las carreteras congestionadas suponen unos costes enormes para la economía de la Unión. Para combatir estos problemas e impedir que causen un daño grave a los ciudadanos, la economía, el medio ambiente y el clima europeos, es necesario actuar de manera coordinada en varios frentes.
Las nuevas tecnologías destinadas a mejorar la eficiencia, la seguridad y el comportamiento medioambiental del transporte por carretera están desempeñando un papel significativo en el logro de los objetivos de la Comisión en este ámbito. Uno de los campos emergentes es el de los sistemas de transporte inteligentes cooperativos (STI-C), que permiten a los vehículos interactuar directamente entre sí y con la infraestructura viaria que los rodea. En el transporte por carretera, los STI-C normalmente engloban la comunicación de vehículo a vehículo (V2V), la comunicación de vehículo a infraestructura (V2I) y la comunicación de infraestructura a infraestructura (I2I), así como la comunicación entre vehículos y peatones o ciclistas («de vehículo a todo» [V2X]), lo que permite contar con una amplia gama de servicios de información y cooperación.
Los STI-C constituyen una categoría de servicios STI, basados en una red abierta que permite la relación de muchos a muchos o de par a par entre estaciones STI-C. Esto significa que todas las estaciones STI-C, según se definen en el presente Reglamento, pueden intercambiar mensajes entre sí de manera segura y no se limitan a intercambiar mensajes con una o varias estaciones preestablecidas. Los servicios STI que facilitan información similar, por ejemplo mediante difusión digital, redes de telefonía móvil o radio FM, pero que no presentan las características de una red abierta que permite la relación de muchos a muchos o de par a par entre estaciones STI-C no entran en el ámbito de aplicación del presente Reglamento.
Los beneficios de los STI-C alcanzan a diversos ámbitos e incluyen la mejora de la seguridad vial, la descongestión del tráfico, el aumento de la eficiencia del transporte, la fiabilidad de la movilidad y los servicios, el uso reducido de la energía, la disminución del impacto medioambiental negativo y la contribución al desarrollo económico. Al mismo tiempo, hay que tener cuidado para evitar los posibles efectos negativos; por ejemplo, las necesidades que se derivan del aumento del tráfico como consecuencia de estas mejoras, la sobrecarga de información para los conductores o el aumento de los riesgos en materia de ciberseguridad o privacidad al que puede dar lugar el hecho de compartir datos adicionales.
En los últimos diez años, se han producido nuevos avances extraordinarios en las tecnologías que facilitan los STIC. Sin embargo, pese a los beneficios potenciales, todavía no se ha logrado una implantación a gran escala. En 2011, los fabricantes de vehículos de la Unión unidos en el Consorcio de Comunicación CAR 2 CAR publicaron un memorando de entendimiento conjunto en el que declaraban su intención de iniciar la implantación a gran escala en 2015, año en que los sistemas estarían preparados tecnológicamente. Sin embargo, quedó claro que esto solo sería posible si las principales partes interesadas seguían un planteamiento común tanto en los aspectos técnicos como en los no técnicos.
En 2014, la Comisión respondió creando una plataforma para la implantación de los sistemas de transporte inteligentes cooperativos en la Unión (plataforma STI-C), un grupo de expertos en el que las autoridades nacionales, las partes interesadas en los STI-C y la Comisión pudieran trabajar de manera conjunta en una visión común y unas soluciones de ejecución concretas para la implantación interoperable de los STI-C en la Unión. Los resultados de la exhaustiva labor de la plataforma y sus grupos de trabajo se resumieron en los informes finales correspondientes a la fase I (2014-2016) y la fase II (2016-2017).
A través de la plataforma C-Roads, una iniciativa conjunta de los Estados miembros y los explotadores de carreteras europeos para ensayar e implementar los servicios STI-C con vistas a la armonización y la interoperabilidad transfronterizas, y por medio de fuertes inversiones a nivel nacional y de la Unión (199 millones EUR, de los cuales 107 fueron cofinanciados a través del Mecanismo «Conectar Europa»), dieciséis Estados miembros han trabajado conjuntamente con la industria para armonizar los servicios STI-C V2I y hacerlos interoperables, de manera que, por ejemplo, los mensajes relativos a obras en la carretera puedan entenderse por igual en diferentes entornos geográficos y entre diferentes fabricantes de vehículos. Esto ha sido el resultado de la cooperación entre la plataforma C-Roads y el Consorcio de Comunicación CAR 2 CAR, que ha mejorado la uniformidad de los mensajes y sistemas V2V y V2I.
En 2016, varias compañías de los sectores de la automoción y las telecomunicaciones se unieron para formar la Asociación Automotriz 5G sobre tecnología para la movilidad conectada y automatizada, que incluye los servicios STI-C. Esto ha dado lugar a una situación en la que existen dos tecnologías para la comunicación de corto alcance, con diferentes niveles de madurez y comercialización, que no son interoperables a nivel de acceso radioeléctrico.
El trabajo de la plataforma STI-C ha sido una fuente de alimentación esencial en el contexto de la estrategia europea sobre los STI-C, cuyo objetivo era facilitar la convergencia entre las inversiones y los marcos normativos en toda la Unión, de manera que la implantación pudiera empezar lo antes posible y, en concreto, pudieran implantarse unos servicios STI-C relacionados con la seguridad maduros a partir de 2019. La estrategia determinó la necesidad de adoptar un marco jurídico adecuado a nivel de la Unión en 2018 a más tardar, posiblemente a través de actos delegados en el marco de la Directiva 2010/40/UE (Directiva sobre los sistemas de transporte inteligentes [STI]) o de otros instrumentos jurídicos.
El objetivo del presente Reglamento Delegado, que complementa la Directiva 2010/40/UE del Parlamento Europeo y del Consejo, es establecer los requisitos legales mínimos para la interoperabilidad de los STI-C y posibilitar la implantación a gran escala de los sistemas y servicios STI-C a partir de 2019. La Directiva 2010/40/UE (Directiva STI) constituye un marco estratégico y jurídico destinado a acelerar la implantación de soluciones innovadoras de transporte en toda Europa. Dicha Directiva se centra en los sistemas de transporte inteligentes por carretera y en su interfaz con otros modos de transporte, y habilita a la Comisión para adoptar actos delegados en cuatro ámbitos prioritarios. El establecimiento de especificaciones para los STI-C forma parte del ámbito prioritario IV de la Directiva.
El presente Reglamento Delegado se centra en los servicios «Día 1», es decir, los servicios STI-C que se van a implantar a corto plazo y que van a contribuir de manera particular a la seguridad vial y a la eficiencia del tráfico. Fruto de la cooperación entre un amplio grupo de partes interesadas de la industria y autoridades de los Estados miembros, ya existen especificaciones y normas relativas a los servicios «Día 1» prioritarios interoperables y una solución común en materia de seguridad.
2.BASE JURÍDICA, SUBSIDIARIEDAD Y PROPORCIONALIDAD
2.1.Base jurídica
El presente acto delegado complementa la Directiva 2010/40/UE de conformidad con su artículo 7. El instrumento jurídico más adecuado es un reglamento, ya que no requiere medidas de transposición nacional, por lo que garantiza un mayor nivel de armonización, una carga administrativa menor para los Estados miembros, un mayor grado de seguridad jurídica para las partes interesadas públicas y privadas y una rápida entrada en vigor.
2.2.Subsidiariedad y proporcionalidad
Según el principio de subsidiariedad (artículo 5, apartado 3, del Tratado de la Unión Europea), solo debe actuarse a nivel de la Unión cuando los objetivos perseguidos no puedan ser alcanzados de manera satisfactoria por los Estados miembros en solitario y, por consiguiente, debido a la dimensión o los efectos de la acción pretendida, pueda alcanzarlos mejor la Unión.
Si bien los servicios STI-C ya están siendo implantados en toda la Unión por medio de proyectos, y varios Estados miembros y numerosos fabricantes de vehículos han indicado que tienen la intención de pasar a la implantación a gran escala, muchos de ellos han sostenido que es necesario un marco jurídico a nivel de la Unión. La normalización liderada por la industria a través de las organizaciones europeas de normalización (OEN) contribuye a la interoperabilidad, pero tiene carácter voluntario y puede dar lugar a formas divergentes, no interoperables, de ejecución. La existencia de numerosas partes interesadas diferentes y los fuertes efectos de red hacen que las partes interesadas no puedan introducir soluciones interoperables por sí solas. De la misma forma, la adopción de normas a nivel nacional probablemente obstaculizaría la prestación de servicios STI-C continuos en el espacio único europeo de transporte.
Para disfrutar de todos los beneficios de los STI-C, será necesario garantizar la compatibilidad entre soluciones de infraestructuras y vehiculares. Además, para garantizar unas sinergias eficaces con la implantación de nuevas tecnologías de seguridad, así como el desarrollo de una movilidad cooperativa conectada y automatizada en toda la Unión, es necesario un enfoque más armonizado a escala europea. Sin un marco inclusivo y preparado para el futuro a nivel de la Unión, probablemente la implantación seguiría estando fragmentada y descoordinada y no podría garantizar la continuidad geográfica de los servicios STI-C en toda la Unión y en sus fronteras exteriores.
El cumplimiento del presente Reglamento Delegado solo sería obligatorio allí donde se implantaran servicios o estaciones STI-C. Si bien las especificaciones vinculantes de la Unión exigen que las estaciones STI-C existentes y las nuevas soluciones tecnológicas se adapten a ellas, dichas especificaciones son esenciales para garantizar la interoperabilidad de los servicios STI-C en toda la Unión; además, la revisión prevista permite flexibilidad en el desarrollo de soluciones tecnológicas. Si bien un reglamento es más estricto que una directriz o una recomendación, los beneficios directos e indirectos esperados también son mayores proporcionalmente. En este sentido, el presente acto delegado respeta el principio de proporcionalidad.
Otro efecto importante del presente Reglamento Delegado es garantizar la autenticidad y la integridad de los mensajes intercambiados entre estaciones STI-C, lo que debería permitir evaluar la fiabilidad de esta información. Al mismo tiempo, debería minimizarse el impacto en la privacidad de los usuarios de la vía pública. Para ello, la plataforma STI-C ha desarrollado una arquitectura de seguridad apoyada en una infraestructura de clave pública (PKI) que utiliza certificados con seudónimo que cambian frecuentemente. La política de certificación y seguridad común resultante ha sido objeto de amplia consulta y ha contado con el acuerdo de todas las partes interesadas afectadas.
2.3.Derechos fundamentales
El derecho a la protección de los datos personales está garantizado por el artículo 8 de la Carta de los Derechos Fundamentales de la Unión Europea. Cuando las medidas establecidas en el presente Reglamento conlleven el tratamiento de datos personales, dicho tratamiento debe efectuarse de conformidad con el Derecho de la Unión relativo a la protección de los datos personales, en particular el Reglamento general de protección de datos y la Directiva sobre la privacidad y las comunicaciones electrónicas.
El 10 de julio de 2017, en el marco de su trabajo preparatorio, los servicios de la Comisión consultaron al subgrupo de tecnología del grupo de trabajo del artículo 29 establecido en virtud de la Directiva sobre la protección de datos. En el dictamen del subgrupo (octubre de 2017) se indicaban varias acciones necesarias para contribuir al tratamiento lícito de los datos personales en el ámbito de los STI-C. Se aclaraba además que, dado que el presente Reglamento solo regula el intercambio de mensajes entre estaciones STI-C, dicho Reglamento no puede constituir en sí mismo una base jurídica para el tratamiento lícito de los datos. Por consiguiente, siguen siendo plenamente aplicables las obligaciones de los responsables y los encargados del tratamiento de los datos. No obstante, en el presente Reglamento se aclara que, sin una base lícita específica adecuada, los datos personales recogidos no deben (re)utilizarse con fines comerciales ni como nuevo recurso para garantizar la aplicación de la ley. Por otro lado, la información relativa a una persona física identificada o identificable debe tratarse cumpliendo estrictamente el principio de minimización de los datos y únicamente para los fines citados en el presente Reglamento, y no debe almacenarse más tiempo del necesario. Por último, debe informarse de manera clara y exhaustiva a los usuarios finales sobre la recogida de los datos y sobre las disposiciones relativas a los períodos durante los cuales se van a conservar.
3.Resultados de las evaluaciones ex post y de las evaluaciones de impacto
•
Evaluaciones ex post / controles de calidad de la legislación existente
Dado que en este ámbito no existe legislación, no ha sido necesario llevar a cabo una evaluación ex post.
•
Obtención y uso de asesoramiento especializado
La Comisión recurrió a los informes finales de las fases I y II de la plataforma STI-C. Además, buscó asesoramiento externo por medio de un contrato para la realización de un estudio de apoyo de la evaluación de impacto con RICARDO Energy & Environment, asistido por TRT y TEPR, que se inició en septiembre de 2017 y concluyó en diciembre de 2018.
•
Evaluación de impacto
La iniciativa se fundamenta en una evaluación de impacto que recibió un dictamen positivo con reservas del Comité de Control Reglamentario (CCR) tras el examen efectuado el 10 de octubre de 2018. Las reservas del CCR se referían a dos aspectos principales:
·Según el CCR, el informe no dejaba lo suficientemente clara la necesidad de recurrir a un enfoque escalonado para alcanzar los objetivos de la iniciativa. Por tanto, la elección de la opción preferida no surgió claramente del análisis y la presentación del informe.
·El CCR también consideraba que el informe no explicaba el motivo por el cual no se abordaban (aún) en él las preocupaciones de las partes interesadas acerca de la seguridad de los usuarios vulnerables de la vía pública y los impactos medioambientales.
A fin de dar respuesta a estas reservas, se añadió lo siguiente a la evaluación de impacto final:
·A lo largo de toda la evaluación de impacto, en particular en los epígrafes 5.3, 7 y 8, se analiza y aclara la distinción entre las diferentes opciones de actuación, así como las consideraciones subyacentes. Se debate expresamente la necesidad de realizar una evaluación de impacto separada sobre posibles medidas legislativas de seguimiento, incluido un mandato V2V.
·El impacto de los STI-C en los usuarios vulnerables de la vía pública se aclara en mayor medida en los epígrafes 6.1 y 6.5. Se pone de relieve que los servicios STI-C específicos para los usuarios vulnerables de la vía pública todavía no están lo suficientemente maduros como para ser incluidos en las especificaciones y, por tanto, en las opciones de actuación consideradas en esta evaluación de impacto. Las preocupaciones de las partes interesadas se describen de manera más detallada en el anexo 2.
·Por lo que respecta a las repercusiones, el análisis de sensibilidad del epígrafe 6.5 se ha extendido a todas las opciones de actuación, y se han hecho ajustes a lo largo de todo el informe para diferenciar mejor dichas opciones. Se ha actualizado el epígrafe 2 del anexo 4 para reflejar que los servicios «Día 1» hacen especial hincapié en la seguridad y para aclarar en mayor medida los límites del análisis.
·Se ha añadido el epígrafe 6.4 para debatir las repercusiones en la protección de datos de las diferentes opciones de actuación. También se ha actualizado el anexo 6 en este sentido.
En la evaluación de impacto se examinaron tres opciones de actuación generales:
OA1:
Intervención ligera basada en medidas no legislativas, que incluyen orientaciones no vinculantes sobre la interoperabilidad de los servicios «Día 1», las comunicaciones seguras, la protección de datos y la evaluación de la conformidad.
OA2:
Intervención moderada basada en especificaciones en el marco de la Directiva STI. Incluiría elementos similares a los de la OA1, pero serían vinculantes jurídicamente al adoptarse por medio de un Reglamento Delegado. No obstante, los Estados miembros y la industria seguirían teniendo libertad para decidir si implantan o no los STI-C.
OA3: Fuerte intervención basada en un mandato V2V (vehículo a vehículo) y en la creación de organismos de gobernanza. Esta opción se basa en mayor medida en las especificaciones vinculantes jurídicamente y adopta un enfoque gradual, garantizando que todos los vehículos nuevos vayan equipados con estaciones STI-C, aumentando drásticamente la tasa de utilización y alcanzado así mucho más rápidamente el umbral de prestaciones efectivas de servicios (debido al efecto de red). La OA3 incluye medidas adicionales que contribuyen a la implantación de los STI-C y no pueden introducirse por medio de un acto delegado únicamente:
·una medida legislativa puede proporcionar una base jurídica para el tratamiento lícito de datos personales relacionados con los STI-C, lo que incrementaría la seguridad jurídica y probablemente daría lugar a la prestación de más servicios STI-C; y
·la asignación de funciones de gobernanza a entidades jurídicas garantizaría en mayor medida la coordinación y la supervisión de la implantación de los STI-C, permitiendo así la reducción al mínimo de las barreras para su adopción.
La OA3 constituye el enfoque preferido (un enfoque gradual, como se establece en la Directiva STI): en él, tras la adopción de especificaciones, se planteará una iniciativa separada para la implantación y se analizarán en mayor medida la eficiencia y la proporcionalidad de un mandato basado en el desarrollo continuado del sector de los STI-C. Esta opción de actuación se considera la más coherente y eficaz, ya que consigue la mayor reducción en cuanto a accidentes, congestión y emisiones de CO2.
Las repercusiones esperadas son las siguientes:
·Los principales beneficios son una reducción del número de accidentes y de los gastos de combustible y una disminución del tiempo de desplazamiento. Además, una ligera reducción de los costes externos de emisiones de CO2 y contaminantes atmosféricos. El total de los beneficios calculados ascendería a 78 900 millones EUR durante el período 2020-2035. Esta cifra aumentaría hasta los 128 900 millones EUR con la introducción de un mandato V2V.
·Los principales costes se refieren al equipamiento de los vehículos y la infraestructura viaria con STI-C. Se han evaluado otros costes de conformidad y administrativos, pero se han considerado menores con respecto a los costes globales. El total de los costes calculados ascendería a 19 100 millones EUR durante el período 2020-2035 o a 32 300 millones EUR con la introducción de un mandato V2V. Por tanto, los beneficios esperados superan con creces los costes previstos.
·Si bien el 90 % de los costes se refiere al equipamiento de las flotas de vehículos, los costes de equipamiento de la infraestructura recaerán en gran medida en el sector público. No obstante, los Estados miembros siguen teniendo libertad para decidir si llevan a cabo o no la implantación.
4.RESULTADOS DE LAS CONSULTAS
4.1.Reuniones con expertos nombrados por los Estados miembros
El desarrollo de normas y requisitos a nivel de la Unión para impulsar la implantación de sistemas y servicios STI-C y, en particular, la interoperabilidad y la continuidad de los servicios V2V y V2I en toda la Unión hizo necesaria una estrecha cooperación entre las partes interesadas (fabricantes, prestadores de servicios y autoridades competentes). Se pidió a los Estados miembros de la Unión y a los países de la AELC que designaran a expertos para asistir a trece reuniones en Bruselas con los servicios de la Comisión entre el 23 de mayo de 2017 y el 3 de octubre de 2018 con el fin de ayudar a elaborar el proyecto de Reglamento. También se invitó a expertos del Parlamento Europeo a participar en las reuniones; la Comisión, por su parte, celebró varias reuniones bilaterales con Estados miembros.
4.2.Consultas con las partes interesadas
Del 10 de octubre de 2017 al 12 de enero de 2018 (trece semanas) estuvo abierta una consulta pública en el sitio web de la Comisión, y se recibieron ciento treinta y nueve respuestas. La consulta pública se basó en un cuestionario destinado a recabar la opinión de las partes interesadas sobre los componentes clave de la evaluación de impacto: el principal problema, sus causas, las posibles medidas estratégicas y sus repercusiones probables, así como la pertinencia de la actuación a nivel de la Unión.
En el marco de un estudio de apoyo, se realizaron varios estudios de casos:
·nueve sobre proyectos de implantación de STI-C en la Unión; y
·tres sobre la implantación de STI-C en otros países (Estados Unidos, Australia y Japón); los estudios incluyeron entrevistas con altos representantes realizadas entre octubre de 2017 y febrero de 2018.
Todos los estudios de casos se centraron en los siguientes aspectos de la implantación de STI-C: objetivos, avances, barreras, recogida de datos y costes en el ámbito afectado. En los estudios de casos de la Unión, también se pidió a los encuestados que dieran su opinión sobre la definición del problema, las medidas y opciones de actuación, así como la supervisión y evaluación de esta iniciativa estratégica.
El 9 de febrero de 2018, tuvo lugar un taller con las partes interesadas para reunir información/datos específicos, así como sus opiniones y sugerencias y las de los expertos. El taller contó con la asistencia de más de ciento cuarenta participantes.
El 6 de septiembre de 2018 y el 29 de enero de 2019, la Comisión presentó el objetivo y el ámbito de aplicación del Reglamento a los miembros del Comité de Transporte y Turismo.
Del 11 de enero al 8 de febrero de 2019, el proyecto de Reglamento se sometió a consulta pública a través del portal «Legislar mejor», y se recibieron cien respuestas.
4.3.Tecnologías de comunicación STI-C
Una cuestión particularmente importante en relación con los STI-C son las tecnologías de comunicación que pueden utilizarse para intercambiar mensajes entre estaciones STI-C. Esto está vinculado directamente con la necesidad de garantizar que todo el mundo pueda hablar con todo el mundo (interoperabilidad) y que todo el mundo siga pudiendo hablar con todo el mundo (compatibilidad).
La maximización de beneficios implica el aprovechamiento de las distintas ventajas que ofrecen diferentes tecnologías complementarias. El enfoque de «comunicación híbrida» combina dos tipos de tecnologías:
·las tecnologías de comunicación de corto alcance, que operan en una banda de frecuencia específica de 5,9 GHz y son las más utilizadas para servicios en los que el tiempo es decisivo (los STI-G5 se desarrollaron específicamente con este fin y ya han alcanzado su madurez, han sido sometidos a ensayo y ya se han implantado); y
·las tecnologías de comunicación de mayor alcance, que aprovechan la cobertura de redes existentes y conectan zonas amplias, pero se utilizan para servicios V2I en los que el tiempo es menos decisivo (las tecnologías 3G y 4G de la telefonía móvil son tecnologías maduras que ya proporcionan buena cobertura en grandes zonas de la Unión).
La ejecución del enfoque de comunicación híbrida, combinada con la necesidad de garantizar la interoperabilidad y la continuidad de los servicios, impone determinadas opciones tecnológicas. Estas se reflejan en un conjunto mínimo de requisitos funcionales y técnicos para el intercambio interoperable de mensajes entre estaciones STI-C. Dado que esto no debería poner freno a la innovación, el presente Reglamento garantiza que las futuras tecnologías puedan integrarse en la combinación «comunicación híbrida».
Una cláusula de revisión facilitará la integración de varios candidatos existentes, como la LTE-V2X (una tecnología de comunicaciones de corto alcance basada en telefonía móvil) y la 5G (el conjunto de tecnologías para la próxima generación de redes de telefonía móvil). La Comisión debatirá posibles modificaciones del presente Reglamento Delegado con un grupo de expertos de manera abierta y transparente, y mantendrá informado periódicamente a dicho grupo de los avances y las posibles etapas siguientes. Las partes interesadas que ya han puesto en servicio estaciones STI-C deberían cooperar de buena fe en este proceso, en consonancia con la legislación tanto europea como nacional en materia de competencia, a fin de garantizar la igualdad de condiciones entre las diferentes tecnologías y sin obstaculizar el desarrollo de otras nuevas. A fin de permitir futuros avances en este ámbito, las partes interesadas también deberían preparar sus productos para la integración de futuras tecnologías.
5.REPERCUSIONES PRESUPUESTARIAS
El presente Reglamento tiene algunas repercusiones en el presupuesto de la Unión.
A fin de garantizar el buen funcionamiento de la red STI-C, es necesario que las entidades centrales lleven a cabo determinadas tareas antes de poder establecer plenamente el marco de gobernanza. A la espera de la creación de dichas entidades, la Comisión llevará a cabo algunas de esas tareas, principalmente las que estén relacionadas con el sistema de la UE para la gestión de credenciales de seguridad de los STI-C, el marco STI-C de la Unión para el suministro de comunicaciones seguras y de confianza sobre la base de una PKI.
Es importante garantizar que las estaciones STI-C puedan inscribirse en el sistema para la gestión de credenciales de seguridad antes de entrar en servicio y empezar a funcionar. Para ello, la Comisión asumirá, como tarea compartida entre el Centro Común de Investigación (JRC) y la Dirección General de Movilidad y Transportes (DG MOVE), las tareas del punto de contacto central, del gestor de la lista de confianza y de la autoridad de la política de certificación de los STI-C.
Esto no tendrá repercusiones en términos de recursos humanos, ya que tanto el JRC como la DG MOVE utilizarán o reasignarán a su personal según proceda. Además, el JRC se beneficia de la acción de apoyo «Arquitectura de seguridad para infraestructura y vehículos conectados en Europa», en el contexto de la Decisión de Ejecución C(2016) 1966 de la Comisión, por la que se asignan 4 millones EUR para la ejecución de la fase I del sistema para la gestión de credenciales de seguridad (2018-2021). En caso de que sean necesarias más acciones de apoyo, podrían financiarse a través del mecanismo «Conectar Europa».
REGLAMENTO DELEGADO (UE) …/... DE LA COMISIÓN
de 13.3.2019
que complementa la Directiva 2010/40/UE del Parlamento Europeo y del Consejo por lo que respecta a la implantación y el uso operativo de los sistemas de transporte inteligentes cooperativos
(Texto pertinente a efectos del EEE)
LA COMISIÓN EUROPEA,
Visto el Tratado de Funcionamiento de la Unión Europea,
Vista la Directiva 2010/40/UE del Parlamento Europeo y del Consejo, de 7 de julio de 2010, por la que se establece el marco para la implantación de los sistemas de transporte inteligentes en el sector del transporte por carretera y para las interfaces con otros modos de transporte, y en particular su artículo 6, apartado 3, en relación con su artículo 7,
Considerando lo siguiente:
(1)En el artículo 2, apartado 1, de la Directiva 2010/40/UE se establece, como ámbito prioritario IV para la elaboración y utilización de especificaciones y normas, la conexión del vehículo a la infraestructura de transporte. Esto supone, entre otras cosas, el desarrollo y la implementación de unos sistemas cooperativos (vehículo a vehículo, vehículo a infraestructura –en los que los mensajes pueden partir tanto del vehículo como de la infraestructura– e infraestructura a infraestructura) basados en: la facilitación del intercambio de datos o información entre vehículos, entre infraestructuras y entre vehículos e infraestructura; la utilización de un formato de mensaje normalizado para el intercambio de datos o información entre vehículos e infraestructura; y la definición de una infraestructura de comunicación para el intercambio de datos o información entre vehículos, entre infraestructuras y entre vehículos e infraestructura.
(2)Los sistemas de transporte inteligentes cooperativos (STI-C) utilizan tecnologías que permiten que los vehículos de carretera se comuniquen entre sí y con la infraestructura viaria, incluidas las señales de tráfico. Los servicios STI-C constituyen una categoría de servicios STI, basados en una red abierta que permite la relación de muchos a muchos o de par a par entre estaciones STI-C. Esto significa que todas las estaciones STI-C, según se definen en el presente Reglamento, pueden intercambiar mensajes entre sí de manera segura y no se limitan a intercambiar mensajes con una o varias estaciones preestablecidas. Las estaciones STI-C no necesitan requisitos adicionales, como: utilizar el mismo software o tener una cuenta o relación contractual con la misma entidad (por ejemplo, el mismo fabricante de vehículos, la misma autoridad viaria o el mismo prestador de servicios).
(3)La estrategia europea STI-C detectó un riesgo de fragmentación del mercado interior en el ámbito de los STI-C y una necesidad de establecer requisitos mínimos para los servicios STI-C, a fin de garantizar su implantación coordinada y coherente. En este contexto, la Comisión anunció su intención de hacer uso, cuando procediera, de su mandato en el marco de la Directiva 2010/40/UE para adoptar uno o varios actos delegados hacia 2018, a fin de garantizar la compatibilidad, la interoperabilidad y la continuidad de los servicios STI-C en la implantación y el uso operativo en toda la Unión de unos servicios STI-C basados en comunicaciones seguras y de confianza.
(4)A fin de impulsar y maximizar todos los beneficios en materia de seguridad vial y eficiencia del tráfico que ofrecen los servicios STI-C, las especificaciones establecidas en el presente Reglamento deben aplicarse a la totalidad de la red de transporte por carretera. Esto incluye sus interconexiones con otros modos de transporte que son pertinentes para la seguridad vial y la eficiencia del tráfico, como los pasos a nivel, las zonas portuarias, etc.
(5)Las especificaciones establecidas en el presente Reglamento deben aplicarse a todos los servicios STI-C, sin perjuicio de las especificaciones particulares adoptadas en otros actos en el marco de la Directiva 2010/40/UE, en particular los Reglamentos Delegados (UE) n.º 886/2013 y (UE) 2015/962 de la Comisión.
(6)La Directiva (UE) 2016/1148 del Parlamento Europeo y del Consejo, de 6 de julio de 2016, relativa a las medidas destinadas a garantizar un elevado nivel común de seguridad de las redes y sistemas de información en la Unión (Directiva sobre las redes y sistemas de información), establece requisitos relativos a las capacidades nacionales en el ámbito de la ciberseguridad y mecanismos para mejorar la cooperación estratégica y operativa entre Estados miembros e introduce obligaciones relativas a las medidas de seguridad y a las notificaciones de incidentes entre sectores. Dado que en la Directiva sobre las redes y sistemas de información figuran los operadores de los sistemas de transporte inteligentes definidos en el artículo 4, punto 1, de la Directiva 2010/40/UE como posibles operadores de servicios esenciales, en determinados casos la aplicación de la Directiva sobre las redes y sistemas de información y de los requisitos que impone el presente Reglamento puede ser complementaria.
(7)La Decisión 2008/671/CE de la Comisión armoniza las condiciones para que las aplicaciones relacionadas con la seguridad de los STI puedan disponer de la banda de frecuencias 5 875-5 905 MHz y hacer un uso eficiente de ella en la Unión.
(8)En respuesta al mandato de normalización M/453, las organizaciones europeas de normalización (OEN) –el Instituto Europeo de Normas de Telecomunicaciones (ETSI) y el Comité Europeo de Normalización (CEN)– han elaborado normas comunes para la implantación de los servicios STI-C, a las que hace referencia el presente Reglamento. Dichas normas proporcionan una base para la prestación eficaz de servicios prioritarios STI-C, al permitir a los gestores del tráfico por carretera que tomen medidas adecuadas y preparen el camino para una automatización más segura en las carreteras de la Unión. El trabajo de normalización seguirá adelante, entre otras cosas para integrar otras tecnologías y seguir consolidando los STI-C. Por tanto, los organismos de normalización pertinentes y todas las partes interesadas deben seguir trabajando en el marco del mandato de normalización M/453 y elaborar conjuntamente soluciones que contribuyan a la interoperabilidad y permitan que todas las tecnologías desempeñen su función.
(9)A fin de garantizar la interoperabilidad, cada estación STI-C requiere una configuración de normas específica («perfil de sistema») que determina la implementación de varias normas opcionales. El perfil de sistema describe las interfaces externas necesarias para la comunicación entre estaciones STI-C. Todas las estaciones STI-C deben cumplir lo dispuesto en la Directiva 2014/53/UE del Parlamento Europeo y del Consejo. La cooperación entre la industria y las autoridades de los Estados miembros ha dado lugar al desarrollo de perfiles de sistema armonizados para estaciones STI-C vehiculares y estaciones STI-C viarias que se comunican en la banda de frecuencias 5 855-5 925 MHz. Para que todos los servicios STI-C se reciban sin problemas en toda la Unión, es necesario un enfoque de «comunicación híbrida», es decir, que combine tecnologías de comunicación complementarias. Habida cuenta del ritmo del progreso tecnológico, se anima a la industria y a los Estados miembros a desarrollar (y armonizar en toda la Unión) perfiles de sistema complementarios y compatibles adicionales para otros tipos de estaciones y tecnologías STI-C. Antes de utilizar estos nuevos perfiles o tecnologías, deben informar a la Comisión, de manera que pueda plantearse sin demora la actualización del presente Reglamento. Las actualizaciones deben prepararse en estrecha cooperación con los Estados miembros.
(10)La naturaleza cooperativa de los STI-C hace necesario que todas las estaciones STI-C aporten información a la red STI-C. Las estaciones STI-C no deben interferir en la prestación de servicios prioritarios STI-C, los servicios europeos de telepeaje o los tacógrafos inteligentes, ni en el funcionamiento de otras estaciones STI-C.
(11)Es importante que la industria y los Estados miembros implementen soluciones técnicas comunes para la prestación de servicios STI-C. Dichas soluciones deben desarrollarse, en particular, a través de las OEN, con el fin de facilitar la introducción de los servicios STI-C, garantizar la interoperabilidad y la continuidad de dichos servicios en toda la Unión y reducir los costes de implementación. A fin de garantizar la compatibilidad, la interoperabilidad y la continuidad de los servicios STI-C en toda la Unión, las normas y perfiles de sistema contemplados en el presente Reglamento deben utilizarse, cuando proceda, como referencia para el desarrollo de futuras tecnologías y servicios STI-C.
(12)Por lo que respecta a la implantación, debe darse prioridad a los servicios STI-C que contribuyen a la seguridad vial y a la eficiencia del tráfico. Los servicios de información mínima universal sobre el tráfico en relación con la seguridad vial definidos en el Reglamento Delegado (UE) n.º 886/2013 deben prestarse, en la medida de lo posible, como servicios universales y gratuitos para el usuario final en el punto de utilización, de conformidad con dicho Reglamento.
(13)A fin de garantizar la interoperabilidad, cada servicio STI-C requiere una configuración de normas específica, llamada perfil de servicio, que determina la implementación de varias opciones de normas. Los servicios STI-C no deben interferir en la prestación de los servicios prioritarios STI-C. Los perfiles de servicio de vehículo a vehículo han sido desarrollados fundamentalmente para turismos. Para permitir la implantación de estos servicios o de servicios similares para otras categorías de vehículos, puede ser necesario el desarrollo de perfiles de servicio adicionales o una actualización de los perfiles de servicio que figuran en el presente Reglamento.
(14)La Decisión n.º 768/2008/CE del Parlamento Europeo y del Consejo establece principios comunes y disposiciones de referencia destinados a aplicarse a toda la legislación sectorial. Dicha Decisión constituye, pues, un marco horizontal general para cualquier nueva legislación de armonización de las condiciones de comercialización de los productos. Sus disposiciones de referencia proporcionan definiciones y obligaciones generales para los operadores económicos y una serie de procedimientos de evaluación de la conformidad entre los que puede elegir el legislador, según el caso. A fin de garantizar la seguridad del mercado, establece también normas para el marcado CE y disposiciones de referencia sobre los procedimientos relativos a los productos que entrañan un riesgo. Dado que el presente Reglamento regula la introducción en el mercado de las estaciones STI-C, conviene utilizar las disposiciones de referencia del anexo I de dicha Decisión, con arreglo a las cuales el fabricante es responsable de garantizar, entre otras cosas, el cumplimiento de la legislación aplicable; de elaborar la declaración CE de conformidad; de colocar el marcado de conformidad y de elaborar la documentación técnica requerida. Asimismo, deben regularse las funciones y las responsabilidades de otras entidades, como el representante autorizado, el importador y el distribuidor.
(15)En el presente Reglamento, las estaciones STI-C instaladas en vehículos, portátiles o situadas en la infraestructura viaria se consideran productos que pueden introducirse en el mercado como módulos independientes o como partes de módulos de mayor tamaño. El grado en que las estaciones STI-C destinadas a ser instaladas en vehículos cumplen los requisitos aplicables puede verificarse antes o después de la instalación. En el caso de las estaciones STI-C viarias, puede verificarse antes de la instalación, de manera que puedan introducirse en el mercado como productos independientes. En el caso de las estaciones STI-C centrales, la situación puede ser diferente, ya que a menudo se integrarán en centros de control del tráfico que no estén normalizados. Dado que estos centros de control del tráfico se construyen paulatinamente, según van desarrollándose las zonas de tráfico que gestionan, puede ocurrir que su conformidad no pueda verificarse del todo antes de su introducción en el mercado. En cualquier caso, el nivel de seguridad y confianza debe ser el mismo para todas las estaciones STI-C, incluidas las centrales.
(16)Antes de la puesta en servicio y la entrada en funcionamiento de cualquier estación STI-C, es necesario determinar la entidad que comprobará que va acompañada de una declaración UE de conformidad y, en su caso, que lleva colocado el marcado de conformidad. Dicha entidad debe registrar la estación en el sistema de la UE para la gestión de credenciales de seguridad de los STI-C y garantizar que siga cumpliendo los requisitos técnicos durante todo el período de utilización. La entidad ejercerá de operador de la estación STI-C y estará a cargo de las relaciones con el usuario.
(17)En relación con numerosos servicios STI-C, es esencial garantizar la autenticidad y la integridad de los mensajes STI-C que contengan información, como la posición, la velocidad y el rumbo. Por tanto, debe establecerse un modelo europeo común STI-C de confianza para todas las estaciones STI-C (para todas las estaciones STI-C móviles –los mismos requisitos para las estaciones personales y vehiculares– y para todas las estaciones STI-C fijas –los mismos requisitos para las centrales y las viarias–), independientemente de las tecnologías de comunicación utilizadas. Las normas y requisitos de este modelo de confianza se establecen en la política de certificación y seguridad. El nivel más elevado de la PKI es la lista de confianza de certificación europea, que contiene entradas de todas las autoridades de certificación raíz de confianza en Europa.
(18)En el pasado se han realizado algunos esfuerzos por lograr el reconocimiento mutuo de los certificados de seguridad de los productos en Europa. El ejemplo más importante a este respecto es el Acuerdo sobre el reconocimiento mutuo (ARM) del Grupo de Altos Funcionarios sobre Seguridad de los Sistemas de Información (SOG-IS). Este grupo, si bien representa el modelo más importante en cuanto a cooperación y reconocimiento mutuo en el ámbito de la certificación de la seguridad, incluye únicamente a parte de los Estados miembros de la Unión. Dado que la certificación de la seguridad de las estaciones STI-C es un elemento importante de la política de certificación y seguridad de los STI-C, en ausencia de otros programas europeos de certificación de la ciberseguridad equivalentes en el marco europeo de la ciberseguridad pertinente se aplica el ARM del SOG-IS.
(19)Es posible que algunas estaciones STI-C introducidas en el mercado antes de la fecha de aplicación del presente Reglamento no cumplan plenamente los requisitos relacionados con la seguridad de este, ya que puede que se hayan tomado decisiones de implantación técnica en una etapa anterior. Para que dichas estaciones STI-C formen parte de la red STI-C después de la fecha de aplicación del presente Reglamento, debe establecerse un procedimiento destinado a permitir su inscripción en el modelo de confianza STI-C.
(20)Con arreglo al artículo 6, apartado 6, de la Directiva 2010/40/UE, la Comisión debe adoptar especificaciones que cumplan una serie de principios, entre ellos la utilización de infraestructuras basadas en satélites o cualquier otra tecnología que proporcione un nivel equivalente de precisión, a efectos del uso de aplicaciones y servicios de STI que requieren servicios horarios y de posicionamiento en todo el mundo, continuados, fiables y garantizados. Por tanto, conviene garantizar la compatibilidad de las estaciones STI-C con los servicios de valor añadido que proporcionan los programas Galileo y EGNOS (el sistema europeo de navegación por complemento geoestacionario), establecidos mediante el Reglamento (UE) n.º 1285/2013 del Parlamento Europeo y del Consejo, para mejorar la fiabilidad de las estaciones STI-C.
(21)La plataforma para la implantación de los STI-C en la Unión (plataforma STI-C), que se creó en noviembre de 2014 y está presidida por servicios de la Comisión, elaboró una política de certificación y seguridad común, respaldada por todas las partes interesadas. Dado que esta ha de ser actualizada en consonancia con los avances técnicos y el desarrollo del marco de gobernanza, la Comisión debe revisar permanentemente el presente Reglamento para mantener la coherencia y la uniformidad.
(22)A fin de garantizar el buen funcionamiento de la red STI-C, es necesario que las entidades centrales lleven a cabo determinadas tareas antes de poder establecer plenamente el marco de gobernanza. A la espera del establecimiento de las entidades centrales, la Comisión debe encargarse de estas tareas, incluidas las que corresponden a la autoridad de la política de certificación de los STI-C, al gestor de la lista de confianza y al punto de contacto STI-C.
(23)Cuando las medidas establecidas en el presente Reglamento conlleven el tratamiento de datos personales, deben llevarse a cabo de conformidad con el Derecho de la Unión relativo a la protección de los datos personales y la privacidad, en particular el Reglamento (UE) 2016/679 y, cuando sea de aplicación, la Directiva 2002/58/CE. Dicho tratamiento debe tener una base jurídica adecuada, como se indica en el artículo 6 del Reglamento (UE) 2016/679, que no proporciona el presente Reglamento Delegado.
(24)Sin una base jurídica adecuada, los datos personales recogidos no deben ser reutilizados con ningún otro fin, ni comercial ni como nuevo recurso para garantizar la aplicación de la ley, salvo sobre la base de una ley.
(25)La información relativa a una persona física identificada o identificable debe tratarse cumpliendo estrictamente el principio de minimización de los datos y únicamente para los fines especificados en el presente Reglamento, y no debe almacenarse más tiempo del necesario. Los requisitos de seguridad sobre seudonimización que se establecen en el presente Reglamento contribuyen a reducir el riesgo de uso indebido de los datos.
(26)Los usuarios finales deben ser informados clara y exhaustivamente sobre todos los puntos pertinentes del tratamiento de sus datos personales de conformidad con el Reglamento (UE) 2016/679.
(27)Como se establece en la política de certificación y seguridad común, elaborada en el contexto de la plataforma STI-C, para la gobernanza son necesarios organismos que adopten la forma de comités directores comunes de las partes interesadas, a saber, la Comisión, los Estados miembros, los operadores de infraestructuras viarias y los fabricantes y operadores de estaciones STI-C. A la espera de la creación de dichos organismos, la Comisión, asistida por un grupo de expertos en el que estén representadas todas las partes interesadas, debe encargarse de las tareas pertinentes, incluidas las relacionadas con la gobernanza, la supervisión y la autoridad de la política de certificación de los STI-C. Este grupo de expertos debe incluir, en particular, a representantes de los fabricantes y operadores de estaciones STI-C en la red STI-C, así como a otras partes interesadas afectadas y autoridades pertinentes de los Estados miembros.
(28)El amplio e inclusivo proceso de consulta que dio lugar al desarrollo del marco de gobernanza y política de seguridad y a la política de certificación (con el apoyo de todas las partes interesadas públicas y privadas pertinentes) debe aplicarse también a la actualización del presente Reglamento en consonancia con el progreso técnico y, en su caso, con el desarrollo del marco de gobernanza.
(29)Los Estados miembros y las autoridades de certificación raíz deben suministrar con regularidad esta información a la Comisión para que pueda supervisar la ejecución del presente Reglamento.
(30)A fin de tener en cuenta la rápida evolución de los nuevos mercados, tecnologías y servicios, como ya se anunció en el programa de trabajo actualizado de la Directiva STI, está previsto actualizar el presente Reglamento antes de su ejecución, que debería tener lugar tres años después de su entrada en vigor.
El principal candidato para esta modificación es la inclusión de las redes 3G y 4G existentes para la prestación de servicios prioritarios STI-C. Además, en el 3GPP (Proyecto Asociación de Tercera Generación) ya están listas las especificaciones para las tecnologías LTE-V2X y se están validando las implementaciones del prototipo. Estas tecnologías están siendo integradas en normas y especificaciones técnicas europeas, tanto para servicios prioritarios STI-C como para nuevos servicios emergentes. Por último, hay nuevas tecnologías que están evolucionando rápidamente, como la 5G, y que también podrían servir de base a los servicios STI-C.
Algunos de estos cambios podrían dar lugar a una o varias modificaciones del presente Reglamento, una vez que se transmita a la Comisión un expediente con especificaciones avanzadas desde un punto de vista técnico. Estas modificaciones deberían garantizar un enfoque abierto y preparado para el futuro en las normas y en la legislación. La Comisión debe consultar con un grupo de expertos las posibles modificaciones del presente Reglamento de manera abierta y transparente, e informar periódicamente a dicho grupo de los avances y posibles etapas siguientes. Para mantener la continuidad de los servicios prioritarios STI-C, estos también deberían garantizar la compatibilidad y la interoperabilidad con las estaciones STI-C existentes, puestas ya en servicio de conformidad con el presente Reglamento, o especificar un itinerario de migración adecuado teniendo en cuenta también la evolución del mercado y de la tecnología.
La Comisión debe analizar el expediente y debatirlo en el grupo de expertos sin excesiva demora, con vistas a una posible modificación del presente Reglamento, examinando si es necesario cambiar los requisitos vigentes. Las partes interesadas que ya han puesto en servicio estaciones STI-C deberían cooperar de buena fe en este proceso, en consonancia con la legislación tanto europea como nacional en materia de competencia, a fin de garantizar la igualdad de condiciones entre las diferentes tecnologías y sin obstaculizar el desarrollo de otras nuevas. A fin de permitir futuros avances en este ámbito, las partes interesadas también deberían preparar sus productos para la integración de futuras tecnologías.
(31)De conformidad con el artículo 28, apartado 2, del Reglamento (CE) n.º 45/2001 del Parlamento Europeo y del Consejo, se consultó al Supervisor Europeo de Protección de Datos, quien emitió un dictamen el [...].
HA ADOPTADO EL PRESENTE REGLAMENTO:
Capítulo I
Disposiciones generales
Artículo 1
Objeto y ámbito de aplicación
1.El presente Reglamento establece especificaciones necesarias para garantizar la compatibilidad, la interoperabilidad y la continuidad en la implantación y el uso operativo en toda la Unión de unos servicios STI-C basados en comunicaciones seguras y de confianza.
Establece el modo en que han de llevarse a cabo las comunicaciones de vehículo a vehículo, de vehículo a infraestructura y de infraestructura a infraestructura a través de las estaciones STI-C y cómo deben introducirse en el mercado y ponerse en servicio estas estaciones para permitir la prestación de servicios STI-C a los usuarios de STI.
2.El presente Reglamento se aplica a todas las estaciones STI-C en el ámbito del transporte por carretera y a sus interfaces con otros modos de transporte.
3.La implantación de estaciones STI-C se lleva a cabo de conformidad con el artículo 5 de la Directiva 2010/40/UE. Los Estados miembros designarán la parte de su infraestructura de redes de transporte que estará equipada con estaciones STI-C.
Artículo 2
Definiciones
A los efectos del presente Reglamento, se entenderá por:
1)«sistemas de transporte inteligentes cooperativos» o «STI-C»: sistemas de transporte inteligentes que permiten a los usuarios de STI cooperar mediante el intercambio de mensajes seguros y de confianza utilizando el sistema de la UE para la gestión de credenciales de seguridad de los STI-C;
2)«servicio STI-C»: servicio STI prestado a través de STI-C;
3)«estación STI-C»: conjunto de componentes hardware y software necesarios para reunir, almacenar, tratar, recibir y transmitir mensajes seguros y de confianza con el fin de permitir la prestación de un servicio STI-C. Se incluyen aquí las estaciones STI personales, centrales, vehiculares y viarias definidas en la norma EN 302665 v 1.1.1;
4)«estación STI-C móvil»: estación STI-C instalada en un vehículo o en forma de dispositivo portátil personal;
5)«estación STI-C fija»: estación STI-C instalada en un sistema central o en infraestructura viaria;
6)«estación STI-C central»: servidor central con capacidades de estación STI-C integradas, como puede ser un centro de gestión de tráfico.
7)«comercialización»: suministro de una estación STI-C para su distribución o utilización en el mercado de la Unión en el contexto de una actividad comercial, ya sea previo pago o a título gratuito;
8)«introducción en el mercado»: primera comercialización de una estación STI-C en el mercado de la Unión;
9)«puesta en servicio»: primera utilización de una estación STI-C en la Unión con los fines para los que está destinada;
10)«comunicación de corto alcance»: comunicación en la banda de frecuencia 5 855-5 925 MHz;
11)«servicio prioritario STI-C»: servicio STI-C que contribuye a la seguridad vial o a la eficiencia del tráfico y que figura en el anexo I;
12)«perfil de sistema»: conjunto mínimo de requisitos funcionales y técnicos para el intercambio interoperable de mensajes entre estaciones STI-C;
13)«perfil de servicio»: conjunto de especificaciones funcionales para los mensajes interoperables, a fin de permitir la prestación de un servicio STI-C;
14)«sistema mundial de navegación por satélite (“GNSS”)»: infraestructura compuesta por una constelación de satélites y una red de estaciones terrestres, que proporciona información exacta sobre la hora y la localización geográfica a los usuarios que disponen de un receptor adecuado;
15)«fabricante»: toda persona física o jurídica que diseña y fabrica una estación STI-C, o que manda diseñar o fabricar una estación STI-C, y la comercializa con su nombre o su marca registrada;
16)«operador de estación STI-C»: toda persona física o jurídica que es responsable de la puesta en servicio y el funcionamiento de las estaciones STI-C de conformidad con el presente Reglamento;
17)«representante autorizado»: toda persona física o jurídica establecida en la Unión que ha recibido un mandato por escrito de un fabricante para actuar en su nombre en relación con tareas específicas;
18)«importador»: toda persona física o jurídica establecida en la Unión que introduce en el mercado de esta una estación STI-C procedente de un tercer país;
19)«distribuidor»: toda persona física o jurídica de la cadena de suministro, distinta del fabricante o el importador, que comercializa una estación STI-C;
20)«operador económico»: fabricante, representante autorizado, importador o distribuidor;
21)«recuperación»: toda medida destinada a obtener la devolución de una estación STI-C que ya ha sido puesta a disposición del usuario final;
22)«retirada»: toda medida destinada a impedir la comercialización de una estación STI-C presente en la cadena de suministro;
23)«marcado CE»: marcado mediante el cual el fabricante indica que el producto es conforme con los requisitos aplicables establecidos en la legislación de la Unión que contempla su colocación;
24)«usuario final»: persona física o jurídica que utiliza en último lugar o que está previsto que utilice en último lugar una estación STI-C;
25)«autoridad de vigilancia del mercado»: autoridad de un Estado miembro responsable de vigilar el mercado en su territorio;
26)«autoridad nacional competente»: toda autoridad facultada para verificar la conformidad de una estación STI-C con la legislación aplicable;
27)«sistema de la UE para la gestión de credenciales de seguridad de los STI-C»: marco STI-C de la Unión Europea para el suministro de comunicaciones seguras y de confianza por medio de una infraestructura de clave pública (PKI);
28)«autoridad de inscripción»: entidad jurídica u operativa encargada de autenticar las estaciones STI-C y de permitirles el acceso a los STI-C;
29)«red STI-C»: todas las estaciones STI-C operativas de la Unión.
Artículo 3
Comercialización y puesta en servicio
Las estaciones STI-C solo se comercializarán y pondrán en servicio si, además de estar mantenidas adecuadamente y ser utilizadas para el fin previsto, cumplen el presente Reglamento.
Artículo 4
Libre circulación
Los Estados miembros no prohibirán, restringirán ni impedirán, por los motivos contemplados en el presente Reglamento, la comercialización ni la puesta en servicio en su territorio de las estaciones STI-C que cumplan lo dispuesto en dicho Reglamento.
Capítulo II
Requisitos técnicos
Artículo 5
Requisitos que han de cumplir las estaciones STI-C
1.Las estaciones STI-C vehiculares diseñadas para la comunicación de corto alcance cumplirán los requisitos establecidos en el perfil de sistema del epígrafe 2 del anexo II.
2.Las estaciones STI-C viarias diseñadas para la comunicación de corto alcance cumplirán los requisitos establecidos en el perfil de sistema del epígrafe 3 del anexo II.
3.Las estaciones STI-C enviarán mensajes que permitan la prestación de al menos uno de los servicios prioritarios STI-C enumerados en el anexo I.
4.Las estaciones STI-C serán compatibles con las estaciones STI-C que envíen mensajes relacionados con los servicios prioritarios STI-C enumerados en el anexo I.
5.Las estaciones STI-C no interferirán en el funcionamiento del Servicio Europeo de Telepeaje contemplado en la Directiva 2004/52/CE del Parlamento Europeo y del Consejo y la Decisión 2009/750/CE de la Comisión ni en el funcionamiento del tacógrafo inteligente contemplado en el Reglamento (UE) n.º 165/2014 del Parlamento Europeo y del Consejo.
6.Las estaciones STI-C deberán ser compatibles con las estaciones STI-C que sean conformes con los perfiles de sistema que figuran en el anexo II.
7.Cuando las estaciones STI-C operen a través del GNSS deberán ser compatibles con los servicios de posicionamiento y temporización prestados por los sistemas Galileo y EGNOS. Además, las estaciones STI-C podrán ser compatibles con otros sistemas de navegación por satélite.
Artículo 6
Requisitos que han de cumplir los servicios STI-C
1.Los servicios prioritarios STI-C enumerados en el anexo I cumplirán los requisitos del perfil de servicio STI-C correspondiente.
2.Los servicios STI-C funcionarán sin ser modificados con todos los perfiles de servicio que figuran en el anexo I.
Capítulo III
Introducción en el mercado de las estaciones STI-C
Artículo 7
Obligaciones de los fabricantes de estaciones STI-C
1.Los fabricantes, cuando introduzcan sus estaciones STI-C en el mercado, se asegurarán de que han sido diseñadas y fabricadas de conformidad con los requisitos establecidos en el artículo 5.
2.Los fabricantes elaborarán la documentación técnica contemplada en la parte A del anexo V y llevarán a cabo el procedimiento de evaluación de la conformidad contemplado en esa misma parte o velarán por que se lleve a cabo.
3.Cuando se haya demostrado, mediante el procedimiento de evaluación de la conformidad contemplado en la parte A del anexo V, que una estación STI-C es conforme con los requisitos aplicables, los fabricantes elaborarán una declaración UE de conformidad y colocarán el marcado CE.
4.Los fabricantes conservarán la documentación técnica contemplada en la parte A del anexo V y la declaración UE de conformidad durante diez años a partir de la introducción en el mercado de la estación STI-C.
5.Los fabricantes se asegurarán de que existen procedimientos para que la producción en serie mantenga su conformidad con el presente Reglamento.
6.A fin de proteger la salud y la seguridad de los consumidores, cuando se considere oportuno con respecto a los riesgos que presentan las estaciones STI-C, los fabricantes:
a)someterán a ensayo muestras de las estaciones STI-C comercializadas;
b)investigarán y, en su caso, llevarán un registro de reclamaciones de las estaciones STI-C no conformes y de las recuperaciones de estaciones STI-C;
c)mantendrán a los distribuidores informados de estas medidas de control.
7.Los fabricantes se asegurarán de que las estaciones STI-C que han introducido en el mercado llevan un número de tipo, lote o serie, o cualquier otro elemento que permita su identificación.
8.Los fabricantes indicarán, en la estación STI-C o, cuando no sea posible, en su embalaje o en un documento que la acompañe lo siguiente:
a)su nombre;
b)su nombre comercial registrado o la marca registrada;
c)su dirección postal, junto con un punto único en el que se les pueda contactar.
Los datos de contacto figurarán en una lengua fácilmente comprensible para los usuarios finales y las autoridades de vigilancia del mercado.
9.Los fabricantes garantizarán que la estación STI-C vaya acompañada de las instrucciones y de la información relativa a la seguridad en una lengua fácilmente comprensible para los usuarios finales, según lo que determine el Estado miembro de que se trate. Las instrucciones y la información relativa a la seguridad, así como cualquier etiquetado, serán claros, comprensibles e inteligibles.
10.Los fabricantes que consideren que una estación STI-C que han introducido en el mercado no es conforme con el presente Reglamento adoptarán inmediatamente las medidas correctoras necesarias para lograr su conformidad, retirarla o recuperarla, según proceda. Cuando la estación STI-C presente un riesgo, los fabricantes informarán de ello inmediatamente a las autoridades de vigilancia del mercado de los Estados miembros en los que la hayan comercializado y darán detalles, en particular, sobre la no conformidad y sobre toda medida correctora que hayan adoptado.
11.Previa solicitud motivada de una autoridad nacional competente, los fabricantes facilitarán, en papel o en formato electrónico, toda la información y la documentación necesarias para demostrar la conformidad de la estación STI-C en una lengua fácilmente comprensible para dicha autoridad. Los fabricantes cooperarán con dicha autoridad, a petición de esta, en cualquier acción destinada a eliminar los riesgos que planteen las estaciones STI-C que hayan introducido en el mercado.
Artículo 8
Representantes autorizados
1.El fabricante podrá designar a un representante autorizado mediante mandato escrito.
2.Los representantes autorizados realizarán las tareas especificadas en el mandato otorgado por el fabricante. El mandato deberá permitir al representante autorizado realizar, como mínimo, las tareas siguientes:
a)conservar la declaración UE de conformidad y la documentación técnica a disposición de las autoridades nacionales de vigilancia del mercado durante diez años a partir de la introducción en el mercado de la estación STI-C;
b)previa petición motivada de la autoridad nacional competente, facilitar a esta toda la información y la documentación necesarias para demostrar la conformidad de la estación STI-C;
c)cooperar con las autoridades nacionales competentes, a petición de estas, en cualquier acción destinada a eliminar los riesgos que planteen las estaciones STI-C objeto de su mandato.
Las obligaciones establecidas en el artículo 7, apartado 1, y la elaboración de la documentación técnica contemplada en el artículo 7, apartado 2, no formarán parte del mandato del representante autorizado.
Artículo 9
Obligaciones de los importadores
1.Los importadores solo introducirán en el mercado de la Unión estaciones STI-C conformes.
2.Antes de introducir en el mercado una estación STI-C, los importadores se asegurarán de que:
a)el fabricante ha llevado a cabo el procedimiento de evaluación de la conformidad contemplado en el artículo 7, apartado 2;
b)el fabricante ha redactado la documentación técnica;
c)la estación STI-C lleva el marcado CE obligatorio;
d)el fabricante ha cumplido los requisitos establecidos en el artículo 7, apartado 7, y en el artículo 8.
3.Cuando un importador considere que una estación STI-C no es conforme con los requisitos establecidos en el artículo 5, no lo introducirá en el mercado hasta que no sea conforme. Cuando la estación STI-C presente un riesgo, el importador informará de ello al fabricante y a las autoridades de vigilancia del mercado.
4.Los importadores indicarán, en la estación STI-C o, cuando no sea posible, en su embalaje o en un documento que la acompañe lo siguiente:
a)su nombre;
b)su nombre comercial registrado o la marca registrada;
c)la dirección en la que pueden ser contactados.
Los datos de contacto figurarán en una lengua fácilmente comprensible para los usuarios finales y las autoridades nacionales competentes.
5.Los importadores garantizarán que la estación STI-C vaya acompañada de las instrucciones y de la información relativa a la seguridad en una lengua fácilmente comprensible para los usuarios finales, según lo que determine el Estado miembro de que se trate.
6.Mientras sean responsables de una estación STI-C, los importadores se asegurarán de que las condiciones de almacenamiento o transporte no comprometan el cumplimiento de los requisitos establecidos en el artículo 5.
7.A fin de proteger la salud y la seguridad de los consumidores, cuando se considere oportuno con respecto a los riesgos que presente una estación STI-C, los importadores:
a)someterán a ensayo muestras de la estación STI-C comercializada;
b)investigarán y, en su caso, llevarán un registro de reclamaciones de las estaciones STI-C no conformes y de las recuperaciones de estaciones STI-C;
c)mantendrán a los distribuidores informados de estas medidas de control.
8.Los importadores que consideren que una estación STI-C que han introducido en el mercado no es conforme con el presente Reglamento adoptarán inmediatamente las medidas correctoras necesarias para lograr su conformidad, retirarla o recuperarla, según proceda. Cuando la estación STI-C presente un riesgo, los importadores informarán de ello inmediatamente a las autoridades nacionales competentes de los Estados miembros en los que la hayan comercializado y darán detalles, en particular, sobre la falta de conformidad y sobre toda medida correctora que hayan adoptado.
9.Durante un período de diez años a partir de la introducción en el mercado de la estación STI-C, los importadores conservarán una copia de la declaración UE de conformidad a disposición de las autoridades de vigilancia del mercado y se asegurarán de que, previa solicitud, dichas autoridades puedan disponer de la documentación técnica.
10.Previa solicitud motivada de una autoridad nacional competente, los importadores facilitarán, en papel o en formato electrónico, toda la información y la documentación necesarias para demostrar la conformidad de la estación STI-C en una lengua fácilmente comprensible para dicha autoridad. Los importadores cooperarán con dicha autoridad, a petición de esta, en cualquier acción destinada a eliminar los riesgos que planteen las estaciones STI-C que hayan introducido en el mercado.
Artículo 10
Obligaciones de los distribuidores
1.Al comercializar una estación STI-C, los distribuidores actuarán con la debida diligencia en relación con los requisitos del presente Reglamento.
2.Antes de comercializar una estación STI-C, los distribuidores comprobarán lo siguiente:
a)que lleva el marcado CE;
b)que va acompañada de las instrucciones y de la información relativa a la seguridad contemplada en el artículo 7, apartado 9, en una lengua fácilmente comprensible para los usuarios finales en el Estado miembro en el que se va a comercializar;
c)que el fabricante y el importador han cumplido los requisitos establecidos en el artículo 7, apartados 7 y 8, y el artículo 9, apartado 4.
3.Cuando un distribuidor considere que una estación STI-C no es conforme con el artículo 5, no la comercializará hasta que no sea conforme. Cuando la estación STI-C presente un riesgo, el distribuidor informará de ello al fabricante o al importador y a las autoridades de vigilancia del mercado.
4.Mientras sean responsables de una estación STI-C, los distribuidores se asegurarán de que las condiciones de almacenamiento o transporte no comprometan el cumplimiento de los requisitos del artículo 5.
5.Los distribuidores que consideren que una estación STI-C que han comercializado no es conforme con el presente Reglamento o con cualquier otra legislación aplicable de la Unión se asegurarán de que se adoptan las medidas correctoras necesarias para lograr su conformidad, retirarla o recuperarla, según proceda. Cuando la estación STI-C presente un riesgo, los distribuidores informarán de ello inmediatamente a las autoridades de vigilancia del mercado de los Estados miembros en los que la hayan comercializado y darán detalles, en particular, sobre la falta de conformidad y sobre toda medida correctora que hayan adoptado.
6.Previa petición motivada de la autoridad nacional competente, los distribuidores facilitarán a esta toda la información y la documentación necesarias para demostrar la conformidad de una estación STI-C. Los distribuidores cooperarán con dicha autoridad, a petición de esta, en cualquier acción destinada a eliminar los riesgos que planteen las estaciones STI-C que hayan comercializado.
Artículo 11
Casos en los que las obligaciones de los fabricantes se aplican a los importadores y los distribuidores
Cuando un importador o un distribuidor introduzca en el mercado una estación STI-C bajo su nombre o marca registrada, o modifique una estación STI-C ya introducida en el mercado de manera que pueda verse afectada la conformidad con el presente Reglamento, dicho importador o distribuidor será considerado fabricante a efectos del presente Reglamento y deberá cumplir las obligaciones que incumben al fabricante con arreglo al artículo 7.
Artículo 12
Identificación de los operadores económicos
Previa solicitud, los operadores económicos identificarán ante las autoridades de vigilancia del mercado:
a)a cualquier operador económico que les haya suministrado una estación STI-C;
b)a cualquier operador económico al que hayan suministrado una estación STI-C.
Los operadores económicos deberán poder presentar la información a la que se refiere el párrafo primero durante un período de quince años desde que se les suministró la estación STI-C y durante un período de quince años desde que suministraron la estación STI-C.
Artículo 13
Declaración UE de conformidad
1.En la declaración UE de conformidad deberá constar que se ha demostrado la conformidad con los requisitos especificados en el artículo 5.
2.La declaración UE de conformidad deberá estar estructurada según el modelo que figura en la parte B del anexo V, contener los elementos que se especifican en la parte A de ese mismo anexo y mantenerse actualizada. Se traducirá a la lengua o lenguas requeridas por el Estado miembro en el que se comercialice la estación STIC.
3.Al elaborar la declaración UE de conformidad, el fabricante asumirá la responsabilidad de la conformidad de la estación STI-C con los requisitos establecidos en el presente Reglamento.
4.Cuando una estación STI-C esté sujeta a más de un acto de la Unión que exija una declaración UE de conformidad, se elaborará una declaración única con respecto a todos esos actos. En dicha declaración figurarán los actos en cuestión, incluidas sus referencias de publicación.
Artículo 14
Principios generales del marcado CE
El marcado CE estará sujeto a los principios generales establecidos en el artículo 30 del Reglamento (CE) n.º 765/2008 del Parlamento Europeo y del Consejo.
Artículo 15
Reglas y condiciones para la colocación del marcado CE
1.El marcado CE se colocará en la estación STI-C o en su placa de datos de manera visible, legible e indeleble.
2.El marcado CE se colocará antes de la introducción en el mercado de la estación STI-C. Podrá ir seguido de un pictograma o de otra marca que indique un riesgo o un uso especiales.
Artículo 16
Vigilancia del mercado de la Unión y control de las estaciones STI-C que entran en él
Se aplicarán a las estaciones STI-C el artículo 15, apartado 3, y los artículos 16 a 29 del Reglamento (CE) n.º 765/2008.
Artículo 17
Procedimiento para hacer frente a estaciones STI-C que presentan un riesgo a nivel nacional
1.Cuando las autoridades de vigilancia del mercado de un Estado miembro hayan adoptado medidas con arreglo al artículo 20 del Reglamento (CE) n.º 765/2008 o tengan motivos para creer que una estación STI-C presenta un riesgo para la salud o la seguridad de las personas, para la seguridad vial o para la eficiencia del tráfico, llevarán a cabo una evaluación de la estación STI-C en cuestión con respecto a todos los requisitos aplicables del presente Reglamento. Los operadores económicos pertinentes cooperarán con dichas autoridades según proceda.
Si, en el transcurso de la evaluación, las autoridades de vigilancia del mercado constatan que la estación STI-C no cumple los requisitos del presente Reglamento, pedirán sin demora al operador económico pertinente que adopte todas las medidas correctoras adecuadas para que la estación sea conforme con dichos requisitos o bien la retire del mercado o la recupere en un plazo razonable, proporcional a la naturaleza del riesgo.
El artículo 21 del Reglamento (CE) n.º 765/2008 será de aplicación a las medidas contempladas en el párrafo segundo del presente apartado.
2.Cuando las autoridades de vigilancia del mercado consideren que el incumplimiento no se limita al territorio nacional, informarán sin demora a la Comisión y a los demás Estados miembros de los resultados de la evaluación y de las medidas que han pedido al operador económico que adopte.
3.El operador económico se asegurará de que en toda la Unión se adoptan todas las medidas correctoras adecuadas con respecto a todas las estaciones STI-C afectadas que han sido comercializadas en el mercado de la Unión.
4.Cuando el operador económico no adopte las medidas correctoras adecuadas en el plazo indicado en el apartado 1, párrafo segundo, las autoridades de vigilancia del mercado adoptarán todas la medidas provisionales oportunas para prohibir o restringir la comercialización de la estación STI-C en su mercado nacional, retirarla de ese mercado o recuperarla.
5.Las autoridades de vigilancia del mercado informarán sin demora a la Comisión y a los demás Estados miembros de las medidas provisionales contempladas en el apartado 4. Esta información incluirá todos los pormenores disponibles, en particular:
a)los datos necesarios para identificar la estación STI-C no conforme;
b)el origen de la estación STI-C;
c)el riesgo en cuestión y la naturaleza del supuesto incumplimiento de la estación STI-C con los requisitos establecidos en el presente Reglamento;
d)la naturaleza y la duración de las medidas provisionales adoptadas;
e)los argumentos presentados por el operador económico.
6.Los Estados miembros distintos del que inició el procedimiento informarán sin demora a la Comisión y a los demás Estados miembros de:
a)toda medida que hayan adoptado;
b)toda información adicional de que dispongan relativa al incumplimiento de la estación STI-C en cuestión;
c)cualquier objeción que tengan con respecto a las medidas provisionales adoptadas por el Estado miembro que inició el procedimiento.
7.Cuando, transcurridos tres meses desde la recepción de la información contemplada en el apartado 5, los demás Estados miembros o la Comisión no hayan presentado ninguna objeción con respecto a las medidas provisionales adoptadas por un Estado miembro, tales medidas se considerarán justificadas. Cuando una medida provisional se considere justificada, los Estados miembros se asegurarán de que se adoptan sin demora las medidas restrictivas oportunas con respecto a la estación STI-C en cuestión, como su retirada del mercado.
Artículo 18
Procedimiento de salvaguardia de la Unión
1.Cuando, una vez concluido el procedimiento establecido en el artículo 17, apartados 3 y 4, se presenten objeciones con respecto a una medida provisional adoptada por un Estado miembro, o cuando la Comisión considere que una medida provisional es contraria a la legislación de la Unión, la Comisión consultará sin demora a los Estados miembros y al operador u operadores económicos pertinentes y procederá a la evaluación de la medida en cuestión. En función de los resultados de esta evaluación, la Comisión decidirá si la medida adoptada a nivel nacional está o no justificada.
La Comisión dirigirá su decisión a todos los Estados miembros y la comunicará inmediatamente a los operadores económicos pertinentes.
2.Si, en una decisión de la Comisión, se considera justificada la medida provisional, todos los Estados miembros adoptarán las medidas necesarias para garantizar la retirada de su mercado de la estación STI-C no conforme e informarán de ello a la Comisión. Si la medida provisional se considera injustificada, el Estado miembro en cuestión la retirará.
Artículo 19
Estaciones STI-C conformes que presentan un riesgo para la salud y la seguridad a nivel nacional
1.Cuando, tras una evaluación con arreglo al artículo 17, apartado 1, las autoridades de vigilancia del mercado de un Estado miembro constaten que una estación STI-C, pese a cumplir lo dispuesto en el presente Reglamento, presenta un riesgo para la salud o la seguridad de las personas o con respecto a otros aspectos relacionados con la protección del interés público, dichas autoridades deberán ordenar al operador económico pertinente que adopte una o varias de las siguientes medidas correctoras, de manera proporcionada a la naturaleza del riesgo:
a)medidas oportunas para garantizar que la estación STI-C, cuando se comercialice, ya no presente ese riesgo;
b)la retirada del mercado de la estación STI-C;
c)la recuperación de la estación STI-C.
Las autoridades de vigilancia del mercado fijarán un plazo razonable, proporcionado a la naturaleza del riesgo, para que el operador económico adopte las medidas contempladas en el párrafo primero.
2.El operador económico se asegurará de que en toda la Unión se adoptan las medidas correctoras con respecto a todas las estaciones STI-C afectadas que han sido comercializadas en el mercado de la Unión.
3.Las autoridades de vigilancia del mercado informarán inmediatamente a la Comisión y a los demás Estados miembros de las medidas correctoras que han ordenado con arreglo al párrafo primero y de todos los pormenores disponibles, en particular:
a)los datos necesarios para la identificación de la estación STI-C afectada;
b)el origen y la cadena de suministro de la estación STI-C;
c)la naturaleza del riesgo;
d)la naturaleza y la duración de las medidas correctoras.
4.La Comisión consultará sin demora a los Estados miembros y a los operadores económicos pertinentes, y procederá a evaluar las medidas correctoras ordenadas por las autoridades de vigilancia del mercado. Sobre la base de los resultados de la evaluación, decidirá si la medida está o no justificada y, en su caso, propondrá medidas adecuadas.
5.La Comisión dirigirá su decisión a todos los Estados miembros y la comunicará inmediatamente al operador u operadores económicos pertinentes.
Artículo 20
Incumplimiento formal
1.Sin perjuicio de lo dispuesto en el artículo 17, los Estados miembros exigirán al operador económico pertinente que acabe con la falta de conformidad cuando lleguen a una de las conclusiones siguientes:
a)se ha colocado el marcado CE incumpliendo el artículo 14 o el artículo 15;
b)no se ha colocado el marcado CE;
c)no se ha elaborado la declaración UE de conformidad;
d)no se ha elaborado correctamente la declaración UE de conformidad;
e)no está disponible la documentación técnica, o está incompleta;
f)falta, es falsa o está incompleta la información contemplada en el artículo 5, apartado 6, o en el artículo 7, apartado 3;
g)no se cumple cualquier otro requisito administrativo establecido en el artículo 5 o en el artículo 7.
2.Si persiste la falta de conformidad a la que se refiere el apartado 1, el Estado miembro en cuestión adoptará todas las medidas adecuadas para restringir o prohibir la comercialización de la estación STI-C o asegurarse de que sea recuperada o retirada del mercado.
Capítulo IV
Puesta en servicio y funcionamiento de las estaciones STI-C
Artículo 21
Puesta en servicio de las estaciones STI-C centrales
1.Antes de poner en servicio una estación STI-C central, su operador se asegurará de que ha sido diseñada y fabricada de conformidad con los requisitos establecidos en el artículo 5. Para ello, llevará a cabo una de las acciones siguientes:
a)comprará una estación STI-C central introducida en el mercado de conformidad con el capítulo III; en este caso, no serán de aplicación los apartados 2 y 3 del presente artículo;
b)integrará las capacidades de la estación STI-C en un centro de control del tráfico o servidor central; en este caso, se aplicarán a la estación STI-C central los apartados 2 y 3 del presente artículo y no se aplicarán los artículos 7 a 20.
2.Los operadores de la estación STI-C elaborarán la documentación técnica obligatoria contemplada en la parte C del anexo V y llevarán a cabo el procedimiento de evaluación de la conformidad que figura en esa misma parte. Cuando se haya demostrado, mediante dicho procedimiento, que una estación STI-C central cumple los requisitos establecidos en el artículo 5, los operadores de la estación STI-C elaborarán una declaración UE de conformidad con arreglo a la parte D del anexo V.
3.Los operadores de la estación STI-C conservarán la documentación técnica y la declaración UE de conformidad todo el tiempo que esté en funcionamiento la estación STI-C central.
Artículo 22
Obligaciones de los operadores de estaciones STI-C
1.Los operadores de estaciones STI-C se asegurarán de que todas sus estaciones se pongan en servicio y sean operadas de conformidad con el presente Reglamento.
2.Antes de la puesta en servicio de una estación STI-C, el operador verificará lo siguiente:
a)que lleva el marcado CE;
b)que está disponible la documentación técnica contemplada en el artículo 7;
c)que la estación STI-C está certificada de conformidad con los requisitos del epígrafe 1.6.2 del anexo IV.
Las obligaciones que figuran en las letras a) y b) del párrafo primero del presente apartado no se aplicarán a las estaciones STI-C centrales que hayan sido puestas en servicio de conformidad con la letra b) del artículo 21, apartado 1.
Por otro lado, antes de la puesta en servicio de una estación STI-C, su operador la inscribirá en el sistema de la UE para la gestión de credenciales de seguridad de los STI-C de conformidad con el artículo 23, apartado 3.
3.Antes de la puesta en servicio de una estación STI-C, su operador llegará a un acuerdo con el propietario en cuanto a los derechos y obligaciones en relación con el funcionamiento, el mantenimiento y la actualización de la estación STI-C, así como sobre el modo de informar al usuario final.
4.Cuando una estación STI-C se inscriba en el sistema de la UE para la gestión de credenciales de seguridad de los STI-C, se incluirá en un registro de estaciones STI-C de la autoridad de inscripción correspondiente junto con la identificación de su operador. El punto de contacto STI-C mantendrá una lista de registros de estaciones STI-C.
5.El operador de una estación STI-C se asegurará de que, mientras una estación STI-C esté operativa, siga cumpliendo los requisitos del artículo 5 aplicables en el momento de su puesta en servicio.
6.Cuando una estación STI-C deba ser actualizada, bien a iniciativa de su operador, bien como consecuencia de una modificación del presente Reglamento, el operador se asegurará de que la estación en cuestión cumple la última versión de las especificaciones pertinentes que figuran en el artículo 5.
7.Cuando una estación STI-C deba ser actualizada a iniciativa de su fabricante o de su representante autorizado, el fabricante o el representante autorizado y los operadores de la estación STI-C cooperarán para garantizar que la estación cumpla la última versión de las especificaciones pertinentes que figuran en el artículo 5.
Capítulo V
Seguridad
Artículo 23
Inscripción de las estaciones STI-C en el sistema de la UE para la gestión de credenciales de seguridad de los STI-C
1.El sistema de la UE para la gestión de credenciales de seguridad de los STI-C se ha creado para el suministro de comunicaciones seguras y de confianza entre estaciones STI-C.
2.El funcionamiento del sistema de la UE para la gestión de credenciales de seguridad de los STI-C deberá cumplir los requisitos que figuran:
a)en el anexo III (política de certificación), que establece los requisitos para la gestión de certificados de clave pública para servicios STI-C por parte de entidades emisoras, así como su utilización por parte de entidades finales;
b)en el anexo IV (política de seguridad), que establece los requisitos para la gestión de la seguridad de la información en los STI-C.
3.Todas las estaciones STI-C se inscribirán en el sistema de la UE para la gestión de credenciales de seguridad de los STI-C y cumplirán las reglas de dicho sistema, de conformidad con las especificaciones de los anexos III y IV.
Artículo 24
Autoridad de la política de certificación STI-C
1.La autoridad de la política de certificación STI-C será responsable de gestionar la política de certificación y la autorización de las PKI de conformidad con la política de certificación establecida en el anexo III.
2.La Comisión ejercerá de autoridad de la política de certificación de los STI-C hasta que se establezca una entidad ad hoc.
Artículo 25
Gestor de la lista de confianza
1.El gestor de la lista de confianza se encargará de generar y actualizar la lista de confianza de certificación europea (ECTL) de conformidad con la política de certificación establecida en el anexo III y de enviar informes de actividad periódicos a la autoridad de la política de certificación STI-C por lo que respecta al funcionamiento seguro general del modelo de confianza STI-C.
2.La Comisión ejercerá de gestora de la lista de confianza hasta que se establezca una entidad ad hoc.
Artículo 26
Punto de contacto STI-C
1.El punto de contacto STI-C se encargará de manejar toda la comunicación con los gestores de la autoridad de certificación raíz y de publicar el certificado de clave pública del gestor de la lista de confianza y la ECTL de conformidad con la política de certificación establecida en el anexo III.
2.La Comisión ejercerá de punto de contacto STI-C hasta que se establezca una entidad ad hoc.
Artículo 27
Sistema de gestión de la seguridad de la información
Cada operador de una estación STI-C se encargará del funcionamiento de un sistema de gestión de la seguridad de la información de conformidad con la norma ISO/IEC 27001 y los requisitos adicionales que figuran en el epígrafe 1.3.1 del anexo IV.
Artículo 28
Conformidad con la política de seguridad
Los operadores de estaciones STI-C solicitarán y obtendrán periódicamente certificaciones de conformidad con los requisitos del epígrafe 1.7 del anexo IV.
Capítulo VI
Implementación
Artículo 29
Implementación de la red STI-C
1.La Comisión tendrá las siguientes tareas en la implementación de la red STI-C:
a)tareas de gobernanza:
1)preparación de las actualizaciones del marco de gobernanza STI-C;
2)contribución a la elaboración de principios comunes para el tratamiento lícito de datos personales por parte de los responsables y los encargados del tratamiento de datos en la red STI-C;
3)punto de contacto en relación con la implementación de la red STI-C para los operadores y fabricantes de estaciones STI-C, los grupos de usuarios de STI y las partes interesadas de terceros países;
4)revisión de los siguientes elementos:
a)los criterios de evaluación STI-C que han de utilizar los laboratorios de ensayo y otros organismos de evaluación durante el proceso de evaluación de la conformidad;
b)las especificaciones de referencia STI-C, incluidas las normas básicas y de ensayo que han de utilizarse durante las diversas etapas del proceso de evaluación;
b)tareas de supervisión: supervisión de la gestión de incidentes de seguridad a gran escala y de gravedad que repercuten en toda la red STI-C (incluidas las situaciones de recuperación de catástrofes cuando el algoritmo criptográfico esté en riesgo);
c)tareas de la autoridad de la política de certificación STI-C:
1)gestión de la política de certificación;
2)gestión de la autorización de las PKI.
2.A la hora de llevar a cabo las tareas contempladas en el apartado 1, la Comisión estará asistida por un grupo de expertos con representantes de partes interesadas públicas y privadas, en particular fabricantes y operadores de estaciones STI-C de la red STI-C.
Capítulo VII
Disposiciones finales
Artículo 30
Medidas provisionales
En caso de que tenga lugar una situación que ponga en peligro el funcionamiento adecuado de la red STI-C y que incida de manera directa y grave en la seguridad vial, la ciberseguridad o la disponibilidad y la integridad de los servicios STI-C, la Comisión podrá adoptar una decisión para introducir medidas provisionales destinadas a poner remedio a la situación. Dicha decisión se limitará estrictamente a abordar las causas y consecuencias de la situación en cuestión. Será de aplicación hasta que se modifique el presente Reglamento para poner remedio a la situación.
Artículo 31
Elaboración de informes
1.Los Estados miembros supervisarán la ejecución del presente Reglamento en su territorio e informarán sobre los avances logrados al respecto en los informes periódicos contemplados en el artículo 17, apartado 3, de la Directiva 2010/40/UE. En particular, los informes incluirán:
a)una descripción de las iniciativas público-privadas pertinentes para la implantación de los STI-C, incluidos su objetivo, los plazos, los hitos, los recursos, las principales partes interesadas y la situación;
b)la cobertura de la red de carreteras por tipo de carretera para cada servicio prioritario STI-C de vehículo a infraestructura enumerado en el anexo I;
c)el número de estaciones STI-C viarias y centrales implantadas en su territorio.
Los Estados miembros informarán por primera vez el 27 de agosto de 2020 a más tardar.
2.Las autoridades de certificación raíz enumeradas en la lista de confianza de certificación europea que figura en el anexo III notificarán a la Comisión el 31 de diciembre de 2020 a más tardar y, en lo sucesivo, el 31 de diciembre de cada año a más tardar el número de estaciones STI-C móviles y fijas inscritas y operativas que estén bajo su autoridad.
Artículo 32
Estaciones STI-C introducidas en el mercado antes del 31 de diciembre de 2019
1.Las estaciones STI-C introducidas en el mercado el 31 de diciembre de 2019 a más tardar que no cumplan plenamente los requisitos relacionados con la seguridad STI-C del presente Reglamento y las estaciones STI-C del mismo tipo/modelo introducidas en el mercado el 30 de junio de 2021 a más tardar podrán ser inscritas, caso por caso, en el modelo de confianza STI-C por la autoridad de la política de certificación STI-C, siempre y cuando se cumplan las condiciones establecidas en el apartado 2. Las estaciones STI-C del mismo tipo/modelo utilizadas para sustituir a las estaciones STI-C defectuosas o estropeadas que se contemplan en la primera frase también podrán ser inscritas en las mismas condiciones.
2.La autoridad de la política de certificación STI-C podrá inscribir en el modelo de confianza STI-C las estaciones STI-C que se contemplan en el apartado 1 en las condiciones siguientes:
a)si se determina que presentan el nivel de seguridad y confianza exigido en el presente Reglamento;
b)si se demuestra que las estaciones STI-C correspondientes y el procedimiento de inscripción previsto no plantean riesgos adicionales para la red STI-C.
3.La autoridad de la política de certificación STI-C tomará esta decisión basándose en el informe de un auditor PKI acreditado y en una evaluación de la vulnerabilidad en materia de seguridad realizado por un organismo de evaluación de la conformidad.
Artículo 33
Reexamen
1.A más tardar el [OP: insertar fecha: tres años después de la entrada en vigor del presente Reglamento], la Comisión reexaminará la ejecución del presente Reglamento y, en su caso, adoptará nuevas especificaciones comunes dentro de su ámbito de aplicación.
2.Cuando las partes interesadas tengan la intención de implantar en la red STI-C un método o servicio de comunicaciones nuevo o actualizado, u otras soluciones innovadoras, incluidas tecnologías cuyos prototipos estén siendo objeto de ensayo, deberán presentar primero a la Comisión un expediente que contenga las especificaciones técnicas, así como información sobre el grado de madurez y de compatibilidad de la solución innovadora con el presente Reglamento. Las especificaciones técnicas se elaborarán en consonancia con los principios de apertura, consenso y transparencia que se definen en el anexo II del Reglamento (UE) n.º 1025/2012.
A continuación, la Comisión analizará el expediente sin excesiva demora y empezará a debatirlo con el grupo de expertos contemplado en el artículo 29, apartado 2, en un plazo de dos meses, con vistas a una posible modificación del presente Reglamento. El grupo de expertos valorará si son necesarias especificaciones comunes de integración de las nuevas soluciones en la red STI-C y, a más tardar seis meses después de recibir el expediente, emitirá un dictamen. Cuando proceda, el Centro Común de Investigación de la Comisión fundamentará los debates pertinentes en una evaluación técnica independiente.
La presentación de soluciones innovadoras a la Comisión y, en su caso, la posterior modificación del presente Reglamento podrán tener lugar en cualquier momento a partir de la entrada en vigor de este.
3.Para mantener la continuidad de los servicios prioritarios STI-C enumerados en el anexo I, toda futura modificación deberá garantizar la compatibilidad y la interoperabilidad con las estaciones STI-C existentes puestas en servicio de conformidad con el presente Reglamento o especificar un itinerario de migración adecuado.
Artículo 34
Entrada en vigor
El presente Reglamento entrará en vigor a los veinte días de su publicación en el Diario Oficial de la Unión Europea.
Será aplicable a partir del 31 de diciembre de 2019.
El presente Reglamento será obligatorio en todos sus elementos y directamente aplicable en cada Estado miembro.
Hecho en Bruselas, el 13.3.2019
Por la Comisión
El Presidente
Jean-Claude JUNCKER
ANEXO I
1.Introducción
El presente anexo contiene los perfiles de servicio para los servicios STI-C prioritarios. Un perfil de servicio es una configuración específica de normas, que define la ejecución de diversas opciones de normas.
1.1.Referencias
En el presente anexo se utilizan las siguientes referencias:
TS 102 894-2
ETSI TS 102 894-2, Intelligent Transport Systems (ITS); Users and applications requirements; Part 2: Applications and facilities layer common data dictionary (Sistemas de transporte inteligentes [STI]. Requisitos aplicables a usuarios y aplicaciones. Parte 2: Diccionario de datos comunes de las capas de aplicaciones y recursos), V1.3.1 (2018-08)
EN 302 637-2
ETSI EN 302 637-2, Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic Service (Sistemas de transporte inteligentes [STI]. Comunicaciones vehiculares. Conjunto básico de aplicaciones. Parte 2: Especificación del servicio básico de concienciación cooperativa), V1.4.0 (2018-08); esta referencia se entenderá hecha a la versión 1.4.1 desde la fecha de publicación de esta.
EN 302 637-3
ETSI EN 302 637-3, Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 3: Specifications of Decentralized Environmental Notification Basic Service (Sistemas de transporte inteligentes [STI]. Comunicaciones vehiculares. Conjunto básico de aplicaciones. Parte 3: Especificaciones del servicio básico de notificación ambiental descentralizada), v1.3.0 (2018-08); esta referencia se entenderá hecha a la versión 1.3.1 desde la fecha de publicación de esta.
CEPE 13
Reglamento n.º 13 de la Comisión Económica para Europa (CEPE) de las Naciones Unidas. Disposiciones uniformes sobre la homologación de vehículos de las categorías M, N y O con relación al frenado [2016/194]
CEPE 13H
Reglamento n.º 13-H de la Comisión Económica para Europa (CEPE) de las Naciones Unidas. Disposiciones uniformes sobre la homologación de los vehículos de turismo en lo relativo al frenado [2015/2364]
CEPE 48
Reglamento n.º 48 de la Comisión Económica para Europa (CEPE) de las Naciones Unidas. Disposiciones uniformes relativas a la homologación de vehículos por lo que se refiere a la instalación de dispositivos de alumbrado y señalización luminosa [2016/1723]
CEPE 121
Reglamento n.º 121 de la Comisión Económica para Europa (CEPE) de las Naciones Unidas. Disposiciones uniformes relativas a la homologación de vehículos por lo que se refiere al emplazamiento e identificación de los mandos manuales, testigos e indicadores [2016/18]
ISO/TS 19321
ISO/TS 19321, Intelligent transport systems — Cooperative ITS — Dictionary of in-vehicle information (IVI) data structures (Sistemas de transporte inteligentes. STI cooperativos. Diccionario de estructuras de datos de información en los vehículos, (15 de abril de 2015)
ISO 639-1
Codes for the representation of names of languages — Part 1: Alpha-2 code (Códigos para la representación de los nombres de las lenguas. Parte 1: Código alfa-2)
ISO/TS 14823
ISO/TS 14823:2017. Intelligent transport systems – Graphic data dictionary (Sistemas de transporte inteligentes. Diccionario de datos gráficos)
1.2.Notaciones y abreviaciones
En el presente anexo se emplean las notaciones y los términos abreviados siguientes:
ABS
Sistema de frenado antibloqueo (Anti-lock Braking System)
ASR
Regulación antideslizamiento (Anti-Slip Regulation)
AT
Tique de autorización (Authorization Ticket)
CAM
Mensaje de concienciación cooperativa (Cooperative Awareness Message)
DCC
Control de congestión descentralizado (Decentralized Congestion Control)
DEN
Notificación ambiental descentralizada (Decentralized Environmental Notification)
DENM
Mensaje de notificación ambiental descentralizada (Decentralized Environmental Notification Message)
GNSS
Sistema mundial de navegación por satélite (Global Navigation Satellite System)
I2V
De infraestructura a vehículo (infrastructure-to-vehicle)
IRC
Contenedor de reducción del impacto (Impact Reduction Container)
IVI
Información de infraestructura a vehículo (Infrastructure to Vehicle Information)
MAP
Información topográfica para la intersección (Topology information for the intersection)
SPAT
Fase y temporización de señales (Signal Phase and Timing)
SREM
Mensaje extendido de petición de señales (Signal Request Extended Message)
SSEM
Mensaje extendido de situación de la petición de señales (Signal Request Status Extended Message)
STI-C
Sistemas de transporte inteligentes cooperativos (Cooperative Intelligent Transport Systems)
TC
Clase de tráfico (Traffic Class)
TMS
Sistema de gestión del tráfico (Traffic Management system)
TOC
Centro de operaciones de tráfico (traffic operations centre)
TRCO
Condición de activación (Triggering condition)
TTC
Tiempo hasta colisión (Time to Collision)
V2V
De vehículo a vehículo (vehicle-to-vehicle)
1.3.Definiciones
En el presente anexo se utilizan las siguientes definiciones:
a)«vehículo parado»: vehículo con una velocidad absoluta < = 8 cm por segundo; este estado será determinado por sensores internos del vehículo;
b)«vehículo de emergencia»: vehículo designado y autorizado para responder a una emergencia; a menudo, los vehículos de emergencia están legalmente autorizados a infringir las normas convencionales de tráfico para llegar a su destino lo antes posible, como (entre otras cosas) a atravesar una intersección con el semáforo en rojo o a superar el límite de velocidad.
2.Lista de servicios prioritarios
|
Categoría de servicio
|
Servicio
|
Perfil de servicio
|
|
Servicios de vehículo a vehículo
|
|
Atasco
|
Final de fila peligroso
|
Epígrafe 3
|
|
Atasco
|
Atasco más adelante
|
Epígrafe 4
|
|
Advertencia de vehículo parado
|
Vehículo detenido
|
Epígrafe 5
|
|
Advertencia de vehículo parado
|
Vehículo averiado
|
Epígrafe 6
|
|
Advertencia de vehículo parado
|
Poscolisión
|
Epígrafe 7
|
|
Advertencia de vehículo especial
|
Vehículo de emergencia en marcha
|
Epígrafe 8
|
|
Advertencia de vehículo especial
|
Vehículo de emergencia protector parado
|
Epígrafe 9
|
|
Advertencia de vehículo especial
|
Advertencia de servicio de rescate parado
|
Epígrafe 10
|
|
Intercambio de IRC
|
IRC de petición
|
Epígrafe 11
|
|
Intercambio de IRC
|
IRC de respuesta
|
Epígrafe 12
|
|
Situación peligrosa
|
Luz de frenado de emergencia electrónica
|
Epígrafe 13
|
|
Situación peligrosa
|
Intervención automática de los frenos
|
Epígrafe 14
|
|
Situación peligrosa
|
Intervención del sistema de retención de los ocupantes reversible
|
Epígrafe 15
|
|
Condiciones meteorológicas adversas
|
Niebla
|
Epígrafe 16
|
|
Condiciones meteorológicas adversas
|
Precipitación
|
Epígrafe 17
|
|
Condiciones meteorológicas adversas
|
Pérdida de tracción
|
Epígrafe 18
|
|
Servicios de infraestructura a vehículo
|
|
Señalización en el vehículo
|
Información sobre el límite de velocidad dinámico
|
Epígrafe 19
|
|
Señalización en el vehículo
|
«Texto libre» VMS intercalado
|
Epígrafe 20
|
|
Señalización en el vehículo
|
Otra información de señalización
|
Epígrafe 21
|
|
Notificación de ubicaciones peligrosas
|
Zona de accidente
|
Epígrafe 22
|
|
Notificación de ubicaciones peligrosas
|
Atasco más adelante
|
Epígrafe 23
|
|
Notificación de ubicaciones peligrosas
|
Vehículo parado
|
Epígrafe 24
|
|
Notificación de ubicaciones peligrosas
|
Advertencia de condiciones meteorológicas
|
Epígrafe 25
|
|
Notificación de ubicaciones peligrosas
|
Calzada temporalmente deslizante
|
Epígrafe 26
|
|
Notificación de ubicaciones peligrosas
|
Animal o persona en la calzada
|
Epígrafe 27
|
|
Notificación de ubicaciones peligrosas
|
Obstáculo en la calzada
|
Epígrafe 28
|
|
Advertencia de obras en la calzada
|
Cierre de carril (y otras restricciones)
|
Epígrafe 29
|
|
Advertencia de obras en la calzada
|
Cierre de la carretera
|
Epígrafe 30
|
|
Advertencia de obras en la calzada
|
Obras en la calzada móviles
|
Epígrafe 31
|
|
Intersecciones señalizadas
|
Recomendación de velocidad óptima para semáforo en verde
|
Epígrafe 32
|
|
Intersecciones señalizadas
|
Priorización del transporte público
|
Epígrafe 33
|
3.Atasco. Final de fila peligroso
3.1.Descripción del servicio de sistemas de transporte inteligentes cooperativos (STI-C)
Este servicio STI-C transmite información de vehículo a vehículo (V2V) relativa a una situación en la que el vehículo ego detecta el extremo final de un atasco («final de fila peligroso»). Esta situación se da cuando el carril de circulación del vehículo ego está bloqueado y el vehículo no puede avanzar por él. En este servicio no se tiene en cuenta el entorno urbano.
Los siguientes servicios STI-C guardan relación con este servicio, pues comparten condiciones de activación similares:
·«situaciones peligrosas: luz de frenado de emergencia electrónica».
3.2.Condiciones de activación
3.2.1.Condiciones previas
1)Antes de que se active este servicio STI-C, deberán satisfacerse siempre las condiciones previas siguientes:
a)el vehículo ego se encuentra en un entorno no urbano, según se determina por lo menos de una de las siguientes maneras:
·la velocidad es superior a 80 km/h durante un período mínimo de 30 s en los 60 s previos a cada detección y el valor absoluto del ángulo del volante es inferior a 90° durante un período mínimo de 30 s en los 60 s previos a cada detección (en entornos no de autopista no debería detectarse el «final de fila peligroso»);
·un sensor de cámara de a bordo indica un entorno no urbano;
·un mapa digital de a bordo indica un entorno no urbano.
2)La velocidad y la desaceleración del vehículo serán determinadas por la señal de buses de este, no por un sistema mundial de navegación por satélite (GNSS). Se utilizará la velocidad filtrada del vehículo (con respecto al ruido del sensor). Este requisito se aplicará a todos los análisis subsiguientes de la velocidad y la desaceleración del vehículo.
3)Los valores de velocidad y ángulo se medirán continuamente. Las condiciones deberán cumplirse durante toda la medición. El proceso volverá a comenzar si no se cumplen las condiciones mientras dura la medición.
3.2.2.Condiciones específicas del servicio
4)Si se satisfacen las condiciones previas del punto 1 y al menos una de las condiciones siguientes, se cumplen las condiciones de activación de este servicio STI-C, por lo que deberá activarse la generación de un mensaje de notificación ambiental descentralizada (DENM):
·TRCO_0 Y (TRCO _2, TRCO _3, TRCO _4, TRCO _5 O TRCO _6)
·TRCO_1 Y TRCO_2.
Cuadro 1: Condiciones específicas del servicio «atasco: final de fila peligroso»
|
Cuenta
|
Condición de activación (TRCO)
|
Situación
|
|
TRCO_0
|
El vehículo ego está circulando a una velocidad inicial superior a 80 km/h y la desaceleración inicial es igual o inferior a 0,1 m/s². El conductor reacciona ante el final de fila peligroso reduciendo la velocidad para pasar de la velocidad inicial a la velocidad buscada de 30 km/h o menos. Deberá pasarse de la velocidad inicial a la velocidad buscada en 10 s o menos. Se detecta una desaceleración instantánea entre la velocidad inicial y la velocidad buscada que es superior a 3,5 m/s².
|
reacción del conductor
|
|
TRCO_1
|
Los pasajeros del vehículo ego reaccionan ante el atasco encendiendo las luces de emergencia durante al menos 3 s.
|
reacción del conductor
|
|
TRCO_2
|
Por lo menos otros tres vehículos con una velocidad de al menos 7 km/h han encendido las luces de emergencia durante al menos 3 s, según indican:
·un sensor de cámara de a bordo; o
·CAM.
|
entorno o sensores de a bordo
|
|
TRCO_3
|
Se ha recibido al menos un DENM correspondiente al servicio STI-C «Atasco. Final de fila peligroso».
|
entorno
|
|
TRCO_4
|
Se han recibido, de vehículos que circulan por delante, al menos cinco DENM diferentes (es decir, con diferentes actionIDs) correspondientes al servicio STI-C «Atasco. Atasco más adelante».
|
entorno
|
|
TRCO_5
|
Se ha recibido al menos un DENM correspondiente al servicio STI-C «Advertencia de vehículo especial. Vehículo de emergencia protector parado», con una linkedCause igual a Condición del tráfico o Final de fila peligroso.
|
entorno
|
|
TRCO_6
|
Los sensores de a bordo del vehículo ego reconocen que el vehículo tiene por delante un final de fila peligroso.
|
sensores de a bordo
|
5)No se pedirá un nuevo DENM durante el tiempo de bloqueo de la detección. El tiempo de bloqueo de la detección se pone en marcha una vez que se ha detectado el evento y se ha pedido un DENM al efecto. De este modo, un único evento no es capaz de inundar el canal de transmisión. El tiempo de bloqueo de la detección será de 60 s, independientemente de cómo se detecte el evento. El período de detección entre dos eventos detectados será como mínimo igual al tiempo de bloqueo de la detección. El algoritmo de detección podrá funcionar durante el tiempo de bloqueo de la detección.
Nota: No se presenta ningún período para las maniobras de frenado, ya que la velocidad inicial del vehículo ego no tiene ninguna restricción superior.
6)Una condición será válida mientras esté activa y durante un período adicional de 5 s (el período aumenta el determinismo del algoritmo de detección). La validez disminuirá desde el momento en que ya no se cumpla la condición, lo que facilitará la combinación de condiciones de activación.
7)Los CAM y DENM de vehículos alejados que se utilicen para evaluar las condiciones específicas del servicio como se ha descrito anteriormente deberán ser pertinentes para el vehículo ego. La pertinencia se determinará de una de las siguientes maneras:
a)un mapa digital indica que el evento y el vehículo ego están separados por una distancia inferior a 500 m y comparten el mismo sentido de circulación;
b)un historial de trayecto indica que el evento y el vehículo ego están separados por una distancia inferior a 500 m y comparten el mismo sentido de circulación;
c)la distancia euclidiana entre el evento y el vehículo ego es inferior a 500 m y el valor absoluto de la diferencia de rumbo es inferior a 10°; las posiciones de referencia del atasco según los DENM se sitúan en un área que se extiende de los - 45° a los + 45° a partir del eje longitudinal del vehículo ego.
Nota: Al contabilizar vehículos o eventos, conviene considerar el cambio del tique de autorización (AT) de manera que ningún vehículo ni ningún evento se contabilicen varias veces.
3.2.3.Calidad de la información
8)El valor del elemento de datos informationQuality en el DENM depende de cómo se detecte la situación. Las TRCO (véase el punto 4) se dividen en grupos: reacción del conductor, dinámica del vehículo, entorno y sensores de a bordo. El valor informationQuality se fijará de acuerdo con el cuadro que figura a continuación. Se utilizará el valor más elevado posible.
Cuadro 2: Calidad de la información del servicio «atasco: final de fila peligroso»
|
Detección del evento
|
Valor informationQuality
|
|
Ninguna aplicación conforme con TRCO
|
unknown(0)
|
|
Se cumple al menos una TRCO del grupo de reacción del conductor Y del grupo de entorno.
|
1
|
|
Se cumple al menos una TRCO del grupo de reacción del conductor Y del grupo de sensores de a bordo.
|
2
|
|
Se cumple al menos una TRCO del grupo de reacción del conductor, ASÍ COMO del grupo de entorno Y del grupo de sensores de a bordo.
|
3
|
3.3.Condiciones de terminación
9)No se planteará una terminación del servicio STI-C.
3.3.1.Cancelación
10)Para este servicio STI-C no se utilizará un DENM de cancelación.
3.3.2.Negación
11)Para este servicio STI-C no se utilizará un DENM de negación.
3.4.Actualización
12)Para este servicio STI-C no se utilizará un DENM de actualización.
3.5.Duración de la repetición e intervalo entre repeticiones
13)Se repetirán DENM nuevos durante un valor repetitionDuration de 20 s con un valor repetitionInterval de 0,5 s. Así pues, los parámetros de interfaz duración de la repetición e intervalo entre repeticiones entre la aplicación y el servicio básico de DEN se ajustarán de acuerdo con los valores anteriores.
Nota: Cuando dos DENM con el mismo causeCode procedan de la misma estación STI-C, el caso será gestionado por la estación STI-C receptora.
3.6.Clase de tráfico
14)Los DENM nuevos se ajustarán en la clase de tráfico 1.
3.7.Parámetros del mensaje
3.7.1.DENM
15)El siguiente cuadro especifica los elementos de datos del DENM que se establecerán.
Cuadro 3: Elementos de datos del DENM en el servicio «atasco: final de fila peligroso»
|
Campo de datos
|
Valor
|
|
Management container
|
|
actionID
|
Identificador de un DENM. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
detectionTime
|
TimestampIts: sello de tiempo en el que el evento es detectado por la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
referenceTime
|
TimestampIts: sello de tiempo en el que se genera un DENM nuevo. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
termination
|
No se establecerá, pues en este servicio STI-C no se utilizarán ni negación ni cancelación.
|
|
eventPosition
|
ReferencePosition. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
relevanceDistance
|
lessThan1000 m(4)
|
|
relevanceTrafficDirection
|
upstreamTraffic(1)
|
|
validityDuration
|
20 s (se espera que los vehículos se encuentren con una situación de tráfico diferente 20 s después de la detección)
|
|
stationType
|
El tipo de estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
Situation container
|
|
informationQuality
|
Véase el punto 8.
|
|
causeCode
|
dangerousEndOfQueue(27)
|
|
subCauseCode
|
unavailable(0)
|
|
Location container
|
|
eventSpeed
|
Velocidad de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
eventPositionHeading
|
Rumbo de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
traces
|
PathHistory de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
roadType
|
RoadType de la carretera en la que está situada la estación STI-C detectora.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2] en combinación con las siguientes reglas:
|
|
|
Urbana / No urbana
|
Separación estructural
|
Elemento de datos
|
|
|
Urbana
|
No
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
Urbana
|
Sí
|
urban-WithStructuralSeparation ToOppositeLanes(1)
|
|
|
Urbana
|
Desconocido
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
No urbana
|
No
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
No urbana
|
Sí
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
|
|
|
No urbana
|
Desconocido
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
Si no puede determinarse la información sobre la situación urbana o no urbana, se omitirá el elemento de datos.
|
|
Alacarte container
|
|
lanePosition
|
Si el valor lanePosition es suministrado por un sensor de a bordo (por ejemplo, un radar o una cámara), se fijará de acuerdo con la norma [TS 102 894-2]. Con esta versión de la condición de activación, no es lícito utilizar un GNSS y un mapa digital para calcular el número de carril.
|
|
|
Si se desconoce el valor lanePosition, se omitirá el elemento de datos.
|
3.7.2.Mensaje de concienciación cooperativa (CAM)
16)No se utilizará la adaptación de CAM para este servicio STI-C.
3.8.Capa de red y de transporte
17)El parámetro de interfaz DENM destination area entre el servicio básico de DEN y la capa de red y de transporte será igual a una forma circular con un radio equivalente al valor relevanceDistance.
3.9.Capa de seguridad
18)Si se cumplen las condiciones de activación según se describen en el punto 4, se bloqueará un cambio de AT para DENM nuevos mientras no haya expirado el valor validityDuration. Los DENM nuevos correspondientes se enviarán con el mismo AT.
4.Atasco. Atasco más adelante
4.1.Descripción del servicio STI-C
Este servicio STI-C transmite información V2V relativa a una situación en la que el vehículo ego detecta un atasco. Esta situación se da si el vehículo ego está rodeado de tráfico parado o de un gran volumen de tráfico. Este servicio no se aplica a entornos urbanos.
Los siguientes servicios STI-C guardan relación con este servicio, pues comparten condiciones de activación similares:
•
«advertencia de vehículo parado: vehículo detenido»;
•
«advertencia de vehículo parado: vehículo averiado»;
•
«advertencia de vehículo parado: poscolisión»;
•
«advertencia de vehículo especial: advertencia de servicio de rescate parado».
4.2.Condiciones de activación
4.2.1.Condiciones previas
19)Antes de que se inicie este servicio STI-C, deberán satisfacerse las condiciones previas siguientes:
a)no se detecta ningún servicio de «advertencia de vehículo parado» (véanse los epígrafes 4 a 6);
b)no se detecta ningún servicio de «advertencia de vehículo especial» (véanse los epígrafes 7 a 9);
c)el vehículo ego está situado en un entorno no urbano; la ubicación se determinará al menos de una de estas maneras:
a)la velocidad es superior a 80 km/h durante un período mínimo de 30 s en los 180 s previos a cada detección y el valor absoluto del ángulo del volante es inferior a 90° durante un período mínimo de 30 s en los 60 s previos a cada detección (no deberían detectarse atascos en autopistas);
b)un sensor de cámara de a bordo indica un entorno no urbano;
c)un mapa digital de a bordo indica un entorno no urbano.
20)La velocidad del vehículo será determinada por la señal de buses de este, no por GNSS. Se utilizará la velocidad filtrada del vehículo (con respecto al ruido del sensor). Este requisito se aplicará a todos los análisis subsiguientes de la velocidad del vehículo.
21)Los valores de velocidad y ángulo se medirán continuamente. Las condiciones deberán cumplirse durante toda la medición. El proceso volverá a comenzar si no se cumplen las condiciones mientras dura la medición.
4.2.2.Condiciones específicas del servicio
22)Si se satisfacen las condiciones previas del punto 19 y al menos una de las condiciones siguientes, se cumplen las condiciones de activación de este servicio STI-C, por lo que deberá activarse la generación de un DENM:
·TRCO_0
·TRCO _1 Y (TRCO _2, TRCO _3, TRCO _4 O TRCO _5)
Cuadro 4: Condiciones específicas del servicio «atasco: atasco más adelante»
|
Cuenta
|
Condición de activación (Triggering condition)
|
Situación
|
|
TRCO_0
|
El vehículo ego se desplaza a una velocidad media de 30 km/h o inferior y a más de 0 km/h (este umbral se introduce para evitar solapamientos y para distinguir TRCO_0 y TRCO_1). La velocidad media se calculará durante un período de 120 s (la condición de duración excluye de la activación las situaciones del tráfico que cambian con frecuencia).
Nota: Esta TRCO abarca la situación en la que el vehículo ego está rodeado de tráfico de parada y arranque constantes.
|
dinámica del vehículo
|
|
TRCO_1
|
La velocidad del vehículo ego es igual a 0 km/h durante un mínimo de 30 s.
Nota: Esta TRCO abarca una situación en la que el vehículo ego está parado y rodeado de otros usuarios de la vía.
|
dinámica del vehículo
|
|
TRCO_2
|
Se ha recibido al menos un DENM correspondiente al servicio STI-C «Atasco. Atasco más adelante» en el mismo sentido de circulación.
|
entorno
|
|
TRCO_3
|
Se ha recibido al menos una notificación de atasco en el mismo sentido de circulación por medio de radio móvil.
|
entorno
|
|
TRCO_4
|
Los CAM indican una velocidad de 30 km/h o menos de al menos otros cinco vehículos en un radio de 100 m y en el mismo sentido de circulación.
|
entorno
|
|
TRCO_5
|
Los sensores de a bordo indican una velocidad de 30 km/h o menos de al menos otros cinco vehículos en un radio de 100 m y en el mismo sentido de circulación.
|
sensor de a bordo
|
23)No se pedirá un nuevo DENM durante el tiempo de bloqueo de la detección. El tiempo de bloqueo de la detección se pone en marcha una vez que se ha detectado el evento y se ha pedido un DENM al efecto. De este modo, un único evento no es capaz de inundar el canal de transmisión. El tiempo de bloqueo de la detección será de 180 s, independientemente de cómo se detecte el evento. El período de detección entre dos eventos detectados será como mínimo igual al tiempo de bloqueo de la detección. El algoritmo de detección podrá funcionar durante el tiempo de bloqueo de la detección.
24)Una condición será válida mientras esté activa y durante un período adicional de 5 s (el período aumenta el determinismo del algoritmo de detección). La validez disminuye desde el momento en que ya no se cumple la condición, lo que facilita la combinación de condiciones de activación.
25)Los CAM y DENM de vehículos alejados que se utilicen para evaluar las condiciones específicas del servicio como se ha descrito anteriormente deberán ser pertinentes para el vehículo ego. La pertinencia se determinará de una de las siguientes maneras:
a)un mapa digital indica que el evento y el vehículo ego están separados por una distancia inferior a 500 m y comparten el mismo sentido de circulación;
b)un historial de trayecto indica que el evento y el vehículo ego están separados por una distancia inferior a 500 m y comparten el mismo sentido de circulación;
c)la distancia euclidiana entre el evento y el vehículo ego es inferior a 500 m y el valor absoluto de la diferencia de rumbo es inferior a 10°; las posiciones de referencia del atasco según los DENM se sitúan en un área que se extiende de los - 45° a los + 45° a partir del eje longitudinal del vehículo ego.
Nota: Al contabilizar vehículos o eventos, conviene considerar el cambio del AT de manera que ningún vehículo ni ningún evento se contabilicen varias veces.
4.2.3.Calidad de la información
26)El valor del elemento de datos informationQuality en el DENM depende de cómo se detecte la situación. Las TRCO (véase el punto 22) se dividen en grupos: reacción del conductor, dinámica del vehículo, entorno y sensores de a bordo. El valor informationQuality se fijará de acuerdo con el cuadro que figura a continuación. Se utilizará el valor más elevado posible.
Cuadro 5: Calidad de la información del servicio «atasco: atasco más adelante»
|
Detección del evento
|
Valor informationQuality
|
|
Ninguna aplicación conforme con TRCO
|
unknown(0)
|
|
Se cumple al menos una condición del grupo de dinámica del vehículo, es decir, se cumple la condición TRCO_0.
|
1
|
|
Se cumple al menos una condición del grupo de dinámica del vehículo Y del grupo de entorno.
|
2
|
|
Se cumple al menos una condición del grupo de dinámica del vehículo Y del grupo de sensores de a bordo.
|
3
|
|
Se cumple al menos una condición del grupo de dinámica del vehículo, ASÍ COMO del grupo de entorno Y del grupo de sensores de a bordo.
|
4
|
4.3.Condiciones de terminación
27)No se planteará una terminación del servicio STI-C.
4.3.1.Cancelación
28)Para este servicio STI-C no se utilizará un DENM de cancelación.
4.3.2.Negación
29)Para este servicio STI-C no se utilizará un DENM de negación.
4.4.Actualización
30)Para este servicio STI-C no se utilizará un DENM de actualización.
4.5.Duración de la repetición e intervalo entre repeticiones
31)Se repetirán DENM nuevos durante un valor repetitionDuration de 60 s con un valor repetitionInterval de 1 s. Así pues, los parámetros de interfaz duración de la repetición e intervalo entre repeticiones entre la aplicación y el servicio básico de DEN se ajustarán de acuerdo con los valores anteriores.
Nota: Cuando dos DENM con el mismo causeCode procedan de la misma estación STI-C, el caso será gestionado por la estación STI-C receptora.
4.6.Clase de tráfico
32)Los DENM nuevos se ajustarán en la clase de tráfico 1.
4.7.Parámetros del mensaje
4.7.1.DENM
33)El siguiente cuadro especifica los elementos de datos del DENM que se establecerán.
Cuadro 6: Elementos de datos del DENM en el servicio «atasco: atasco más adelante»
|
Campo de datos
|
Valor
|
|
Management container
|
|
actionID
|
Identificador de un DENM. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
detectionTime
|
TimestampIts: sello de tiempo en el que el evento es detectado por la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
referenceTime
|
TimestampIts: sello de tiempo en el que se genera un DENM nuevo. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
termination
|
No se establecerá, pues en este servicio STI-C no se utilizarán ni negación ni cancelación.
|
|
eventPosition
|
ReferencePosition. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
relevanceDistance
|
lessThan1000m(4)
|
|
relevanceTrafficDirection
|
upstreamTraffic(1)
|
|
validityDuration
|
60 s (cabe esperar que una situación de atasco dure al menos 60 s)
|
|
stationType
|
El tipo de estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
Situation container
|
|
informationQuality
|
Véase el punto 26.
|
|
causeCode
|
trafficCondition(1)
|
|
subCauseCode
|
unavailable(0)
|
|
Location container
|
|
eventSpeed
|
Velocidad de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
eventPositionHeading
|
Rumbo de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
traces
|
PathHistory de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
roadType
|
RoadType de la carretera en la que está situada la estación STI-C detectora.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2] en combinación con las siguientes reglas:
|
|
|
Urbana / No urbana
|
Separación estructural
|
Elemento de datos
|
|
|
Urbana
|
No
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
Urbana
|
Sí
|
urban-WithStructuralSeparation ToOppositeLanes(1)
|
|
|
Urbana
|
Desconocido
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
No urbana
|
No
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
No urbana
|
Sí
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
|
|
|
No urbana
|
Desconocido
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
Si no puede determinarse la información sobre la situación urbana o no urbana, se omitirá el elemento de datos.
|
|
Alacarte container
|
|
lanePosition
|
Si el valor lanePosition es suministrado por un sensor de a bordo (por ejemplo, un radar o una cámara), se fijará de acuerdo con la norma [TS 102 894-2]. Con esta versión de la condición de activación, no es lícito utilizar un GNSS y un mapa digital para calcular el número de carril.
|
|
|
Si se desconoce el valor lanePosition, se omitirá el elemento de datos.
|
4.7.2.CAM
34)No se utilizará la adaptación de CAM para este servicio STI-C.
4.8.Capa de red y de transporte
35)El parámetro de interfaz DENM destination area entre el servicio básico de DEN y la capa de red y de transporte será igual a una forma circular con un radio equivalente al valor relevanceDistance.
4.9.Capa de seguridad
36)Si se cumplen las condiciones de activación según se describen en el punto 22, se bloqueará un cambio de AT para DENM nuevos mientras no haya expirado el valor validityDuration. Los DENM nuevos correspondientes se enviarán con el mismo AT.
5.Advertencia de vehículo parado: vehículo detenido
5.1.Descripción del servicio STI-C
Este servicio STI-C transmite información V2V relativa a una situación en la que un vehículo se ha detenido, sin información particular sobre el motivo.
Los siguientes servicios STI-C guardan relación con este servicio, pues comparten condiciones de activación similares:
·«advertencia de vehículo especial: advertencia de servicio de rescate parado»;
·«advertencia de vehículo parado: vehículo averiado»;
·«advertencia de vehículo parado: poscolisión».
37)Solo se enviará una señal DENM a la memoria temporal si se evalúa que se cumplen las condiciones de activación descritas en el presente epígrafe. Esa señal hace que la memoria temporal genere un DENM nuevo o un DENM de actualización o cancelación. Si no se cumplen las condiciones de activación, no se generará una señal DENM.
5.2.Condiciones de activación
5.2.1.Condiciones previas
38)Antes de que se active este servicio STI-C, deberán satisfacerse las condiciones previas siguientes:
a)en el cuadro de mandos no hay ningún mensaje de advertencia de avería que impida al conductor seguir conduciendo (por ejemplo, símbolos rojos de advertencia, de conformidad con el Reglamento [CEPE n.º 121]).
Nota: No se requiere que este servicio compruebe el estado del terminal de encendido 15 para activarse (puede estar encendido o apagado). El funcionamiento del servicio es opcional cuando el terminal de encendido 15 está apagado.
39)Se evitará la activación paralela con los demás servicios STI-C relacionados. Cuando los servicios STI-C «vehículo averiado» o «poscolisión» se activen al mismo tiempo, la prioridad será como sigue:
a)«poscolisión» (prioridad máxima);
b)«vehículo averiado»;
c)«vehículo detenido» (prioridad mínima).
5.2.2.Condiciones específicas del servicio
40)Si se satisface la condición previa del punto 38 y todas las condiciones siguientes, se cumplen las condiciones de activación de este servicio STI-C, por lo que deberá activarse la generación de un DENM:
a)el vehículo ego ha encendido las luces de emergencia;
b)el vehículo está parado;
c)el temporizador de activación ha expirado.
41)La velocidad del vehículo será determinada por la señal de buses de este, no por GNSS. Se utilizará la velocidad filtrada del vehículo (con respecto al ruido del sensor). Este requisito se aplicará a todos los análisis subsiguientes de la velocidad del vehículo.
42)Si el vehículo ha encendido las luces de emergencia y está parado, el temporizador de activación se ajustará en 30 s y se iniciará. El temporizador de activación se reducirá si se producen las siguientes situaciones:
a)se reducirá 10 s si la transmisión automática (AUT) se coloca en «aparcamiento» durante un mínimo de 3 s;
b)se reducirá 10 s si la caja de cambios se pone en punto muerto durante un mínimo de 3 s;
c)se reducirá 10 s si el freno de estacionamiento se activa durante un mínimo de 3 s;
d)se reducirá 10 s si un número arbitrario de hebillas de los cinturones de seguridad pasan de estar «conectadas» a estar «desconectadas» durante un mínimo de 3 s;
e)se ajustará en 0 si un número arbitrario de puertas permanecen abiertas durante un mínimo de 3 s;
f)se ajustará en 0 si el terminal de encendido pasa de estar en funcionamiento a estar apagado durante un mínimo de 3 s;
g)se ajustará en 0 si el maletero permanece abierto durante un mínimo de 3 s;
h)se ajustará en 0 si el capó permanece abierto durante un mínimo de 3 s.
43)Todos los procedimientos enumerados anteriormente para la reducción del temporizador se aplicarán una sola vez durante la detección inicial. Si el temporizador de activación se ha ajustado en 0, no es necesaria ninguna otra reducción en el ciclo de detección actual.
44)Mientras dure el temporizador de activación, las luces de emergencia estarán encendidas y el vehículo permanecerá parado. De lo contrario, se cancelará la detección.
5.2.3.Calidad de la información
45)El valor del elemento de datos informationQuality en el DENM depende de cómo se detecte el evento (véase el punto 42). El valor informationQuality se fijará de acuerdo con el cuadro que figura a continuación (se utilizará el valor más elevado posible).
Cuadro 7: Calidad de la información del servicio «vehículo parado: vehículo detenido»
|
Detección del evento
|
Valor informationQuality
|
|
Ninguna aplicación conforme con TRCO
|
unknown(0)
|
|
No se cumple ninguna de las condiciones a) a h).
|
1
|
|
Se cumple al menos una de las condiciones a) a d).
|
2
|
|
Se cumple al menos una de las condiciones e) a h).
|
3
|
46)Si las condiciones de activación cambian entre dos actualizaciones, el valor informationQuality no cambiará hasta la próxima actualización. Si, mientras se actualiza el DENM, se siguen cumpliendo las condiciones modificadas, se actualizará el valor informationQuality. En la fase de actualización, solo se evaluarán las condiciones que darían lugar a una reducción del temporizador, pero no el propio temporizador.
5.3.Condiciones de terminación
47)Se pone fin a este servicio STI-C mediante una cancelación de la estación STI-C de origen. Al término del servicio STI-C se pondrá fin a la petición de un DENM de actualización.
5.3.1.Cancelación
48)Si se cumple al menos una de las condiciones siguientes antes de que haya expirado el período establecido en el elemento de datos validityDuration, deberá activarse la generación de un DENM de cancelación:
a)el vehículo deja de estar parado durante 5 s;
b)las luces de emergencia están apagadas;
c)la posición del vehículo ha cambiado más de 500 m (por ejemplo, por haber sido remolcado).
Nota: La condición de cancelación no implica que la estación STI-C tenga que estar permanentemente en funcionamiento o ampliar su funcionamiento durante dicha condición de cancelación.
5.3.2.Negación
49)Para este servicio STI-C no se utilizará un DENM de negación.
5.4.Actualización
50)Si no se ha cancelado el DENM activado previamente en relación con la detección de un vehículo detenido, la generación de un DENM de actualización se activará cada 15 s.
51)En la fase de actualización solo se comprobarán las condiciones de activación (no se evaluarán más los temporizadores).
52)Se asignarán nuevos valores a los campos o elementos de datos del DENM de acuerdo con el evento modificado (por ejemplo, detectionTime o informationQuality).
Nota: La condición de actualización no implica que la estación STI-C tenga que estar permanentemente en funcionamiento o ampliar su funcionamiento durante dicha condición de actualización.
5.5.Duración de la repetición e intervalo entre repeticiones
53)Los DENM que sean nuevos o hayan sido actualizados o cancelados se repetirán durante un valor repetitionDuration de 15 s con un valor repetitionInterval de 1 s. Así pues, los parámetros de interfaz duración de la repetición e intervalo entre repeticiones entre la aplicación y el servicio básico de DEN se ajustarán de acuerdo con los valores anteriores.
Nota: El valor validityDuration se ajusta en 30 s. Por lo tanto, puede evitarse una laguna de DENM si el valor repetitionDuration del DENM original ha expirado y la actualización aún no se ha recibido.
Nota: Cuando dos DENM con el mismo causeCode procedan de la misma estación STI-C, el caso será gestionado por la estación STI-C receptora.
5.6.Clase de tráfico
54)Los DENM nuevos, de actualización y de cancelación se ajustarán en la clase de tráfico 1.
5.7.Parámetros del mensaje
5.7.1.DENM
55)El siguiente cuadro especifica los elementos de datos del DENM que se establecerán.
Cuadro 8: Elementos de datos del DENM en el servicio «advertencia de vehículo parado: vehículo detenido»
|
Campo de datos
|
Valor
|
|
Management container
|
|
actionID
|
Identificador de un DENM. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
detectionTime
|
TimestampIts: sello de tiempo en el que el evento es detectado por la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
referenceTime
|
TimestampIts: sello de tiempo en el que se genera un DENM nuevo, de actualización o de cancelación. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
termination
|
No se fijará en el caso de DENM nuevo o de actualización. Se fijará en el valor isCancellation(0) en el caso de un DENM de cancelación.
|
|
eventPosition
|
ReferencePosition. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
relevanceDistance
|
lessThan1000m(4)
|
|
relevanceTrafficDirection
|
Si se conoce el valor roadType, el valor se fijará como sigue:
|
|
|
RoadType
|
Dirección
|
|
|
|
0
|
allTrafficDirections(0)
|
|
|
|
1
|
upstreamTraffic(1)
|
|
|
|
2
|
allTrafficDirections(0)
|
|
|
|
3
|
upstreamTraffic(1)
|
|
|
|
De lo contrario, el valor se fijará en allTrafficDirections(0).
|
|
validityDuration
|
30 s
|
|
stationType
|
El tipo de estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
Situation container
|
|
informationQuality
|
Véase el punto 45. Se actualizará para cada DENM de actualización.
|
|
causeCode
|
stationaryVehicle(94)
|
|
subCauseCode
|
unavailable(0)
|
|
Location container
|
|
eventSpeed
|
Velocidad de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
eventPositionHeading
|
Rumbo de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
traces
|
PathHistory de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
|
|
roadType
|
RoadType de la carretera en la que está situada la estación STI-C detectora.
|
|
|
Se actualizará para un DENM de actualización.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2] en combinación con las siguientes reglas:
|
|
|
Urbana / No urbana
|
Separación estructural
|
Elemento de datos
|
|
|
Urbana
|
No
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
Urbana
|
Sí
|
urban-WithStructuralSeparation ToOppositeLanes(1)
|
|
|
Urbana
|
Desconocido
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
No urbana
|
No
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
No urbana
|
Sí
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
|
|
|
No urbana
|
Desconocido
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
Si no puede determinarse la información sobre la situación urbana o no urbana, se omitirá el elemento de datos.
|
|
Alacarte container
|
|
lanePosition
|
Si el valor lanePosition es suministrado por un sensor de a bordo (por ejemplo, un radar o una cámara), se fijará de acuerdo con la norma [TS 102 894-2]. Con esta versión de la condición de activación, no es lícito utilizar un GNSS y un mapa digital para calcular el número de carril.
|
|
|
Si se desconoce el valor lanePosition, se omitirá el elemento de datos.
|
|
|
Se actualizará para un DENM de actualización.
|
|
Alacarte container: StationaryVehicleContainer
|
|
stationarySince
|
Se fijará de acuerdo con el tiempo, en minutos, que la estación STI-C detectora permanezca parada. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
5.7.2.CAM
56)No se utilizará la adaptación de CAM para este servicio STI-C.
5.8.Capa de red y de transporte
57)El parámetro de interfaz DENM destination area entre el servicio básico de DEN y la capa de red y de transporte será igual a una forma circular con un radio equivalente al valor relevanceDistance.
5.9.Capa de seguridad
58)Si se cumplen las condiciones de activación según se describen en el punto 40, se bloqueará un cambio de AT para DENM nuevos, de actualización y de cancelación mientras no haya expirado el valor validityDuration. Los DENM nuevos, de actualización y de cancelación correspondientes se enviarán con el mismo AT.
6.Advertencia de vehículo parado: vehículo averiado
6.1.Descripción del servicio STI-C
Este servicio STI-C transmite información V2V relativa a un vehículo averiado. Aunque un vehículo puede estar averiado por diversas razones, como son el reventón de un neumático, la falta de combustible o un fallo del motor, este epígrafe se centra en las razones indicadas por los mensajes de advertencia de avería del cuadro de mandos.
Los siguientes servicios STI-C guardan relación con este servicio, pues comparten condiciones de activación similares:
·«advertencia de vehículo especial: advertencia de servicio de rescate parado»;
·«advertencia de vehículo parado: vehículo detenido»;
·«advertencia de vehículo parado: poscolisión».
59)Solo se enviará una señal DENM a la memoria temporal si se evalúa que las condiciones de activación descritas en el presente epígrafe son válidas. Esa señal hace que la memoria temporal genere un DENM nuevo o un DENM de actualización o cancelación. Si no se cumplen las condiciones de activación, no se generará una señal DENM.
6.2.Condiciones de activación
6.2.1.Condiciones previas
60)Antes de que se active este servicio STI-C, deberá satisfacerse la condición previa siguiente:
a)en el cuadro de mandos hay un mensaje de advertencia de avería que impide al conductor seguir conduciendo (por ejemplo, símbolos rojos de advertencia, de conformidad con el Reglamento [CEPE n.º 121]).
Nota: No se requiere que este servicio compruebe el estado del terminal de encendido 15 para activarse (puede estar encendido o apagado). El funcionamiento del servicio es opcional cuando el terminal de encendido 15 está apagado.
61)Se evitará la activación paralela con los demás servicios STI-C relacionados. Cuando los servicios STI-C «vehículo detenido» o «poscolisión» se activen al mismo tiempo, la prioridad será como sigue:
a)«poscolisión» (prioridad máxima);
b)«vehículo averiado»;
c)«vehículo detenido» (prioridad mínima).
6.2.2.Condiciones específicas del servicio
62)Si se satisface la condición previa del punto 60 y todas las condiciones siguientes, se cumplen las condiciones de activación de este servicio STI-C, por lo que deberá activarse la generación de un DENM:
a)el vehículo ego ha encendido las luces de emergencia;
b)el vehículo está parado;
c)el temporizador de activación ha expirado.
63)La velocidad del vehículo será determinada por la señal de buses de este, no por GNSS. Se utilizará la velocidad filtrada del vehículo (con respecto al ruido del sensor). Este requisito se aplicará a todos los análisis subsiguientes de la velocidad del vehículo.
64)Si el vehículo ha encendido las luces de emergencia y está parado, el temporizador de activación se ajustará en 30 s y se iniciará. El temporizador de activación se reducirá si se producen las siguientes situaciones:
a)se reducirá 10 s si la transmisión automática (AUT) se coloca en «aparcamiento» durante un mínimo de 3 s;
b)se reducirá 10 s si la caja de cambios se pone en punto muerto durante un mínimo de 3 s;
c)se reducirá 10 s si el freno de estacionamiento se activa durante un mínimo de 3 s;
d)se reducirá 10 s si un número arbitrario de hebillas de los cinturones de seguridad pasan de estar «conectadas» a estar «desconectadas» durante un mínimo de 3 s;
e)se ajustará en 0 si un número arbitrario de puertas permanecen abiertas durante un mínimo de 3 s;
f)se ajustará en 0 si el terminal de encendido pasa de estar en funcionamiento a estar apagado durante un mínimo de 3 s;
g)se ajustará en 0 si el maletero permanece abierto durante un mínimo de 3 s;
h)se ajustará en 0 si el capó permanece abierto durante un mínimo de 3 s.
65)Todos los procedimientos enumerados anteriormente para la reducción del temporizador se aplicarán una sola vez durante la detección inicial. Si el temporizador de activación se ha ajustado en 0, no es necesaria ninguna otra reducción en el ciclo de detección actual.
66)Mientras dure el temporizador de activación, las luces de emergencia estarán encendidas y el vehículo permanecerá todo el tiempo parado. De lo contrario, se cancelará la detección.
6.2.3.Calidad de la información
67)El valor del elemento de datos informationQuality en el DENM depende de cómo se detecte el evento (véase el punto 64). El valor informationQuality se fijará de acuerdo con el cuadro que figura a continuación (se utilizará el valor más elevado posible).
Cuadro 9: Calidad de la información del servicio «vehículo parado: vehículo averiado»
|
Detección del evento
|
Valor informationQuality
|
|
Ninguna aplicación conforme con TRCO
|
unknown(0)
|
|
No se cumple ninguna de las condiciones a) a h).
|
1
|
|
Se cumple al menos una de las condiciones a) a d).
|
2
|
|
Se cumple al menos una de las condiciones e) a h).
|
3
|
68)Si las condiciones de activación cambian entre dos actualizaciones, el valor informationQuality no cambiará hasta la próxima actualización. Si, mientras se actualiza el DENM, se siguen cumpliendo las condiciones modificadas, se actualizará el valor informationQuality. En la fase de actualización, solo se evaluarán las condiciones que darían lugar a una reducción del temporizador, pero no el propio temporizador.
6.3.Condiciones de terminación
69)Se pone fin a este servicio STI-C mediante una cancelación de la estación STI-C de origen. Al término del servicio STI-C se pondrá fin a la petición de un DENM de actualización.
6.3.1.Cancelación
70)Si se cumple al menos una de las condiciones siguientes antes de que haya expirado el período establecido en el elemento de datos validityDuration, deberá activarse la generación de un DENM de cancelación:
a)el vehículo deja de estar parado durante 5 s;
b)las luces de emergencia están apagadas;
c)la posición del vehículo ha cambiado más de 500 m (por ejemplo, por haber sido remolcado).
Nota: La condición de cancelación no implica que la estación STI-C tenga que estar permanentemente en funcionamiento o ampliar su funcionamiento durante dicha condición de cancelación.
6.3.2.Negación
71)Para este servicio STI-C no se utilizará un DENM de negación.
6.4.Actualización
72)Si no se ha cancelado el DENM activado previamente en relación con la detección de un vehículo averiado, la generación de un DENM de actualización se activará cada 15 s.
73)En la fase de actualización solo se comprobarán las condiciones de activación (no se evaluarán más los temporizadores).
74)Si el terminal de encendido 15 pasa de estar en funcionamiento a estar apagado se activará inmediatamente un DENM de actualización.
75)Se asignarán nuevos valores a los campos o elementos de datos del DENM de acuerdo con el evento modificado (por ejemplo, detectionTime o informationQuality).
Nota: La condición de actualización no implica que la estación STI-C tenga que estar permanentemente en funcionamiento o ampliar su funcionamiento durante dicha condición de actualización.
6.5.Duración de la repetición e intervalo entre repeticiones
76)Los DENM que sean nuevos o hayan sido actualizados o cancelados se repetirán durante un valor repetitionDuration de 15 s con un valor repetitionInterval de 1 s. Así pues, los parámetros de interfaz duración de la repetición e intervalo entre repeticiones entre la aplicación y el servicio básico de DEN se ajustarán de acuerdo con los valores anteriores.
77)En el caso de un terminal de encendido 15 activado, el valor validityDuration será de 30 s. Por lo tanto, puede evitarse una laguna de DENM si el valor repetitionDuration del DENM original ha expirado y la actualización aún no se ha recibido.
Nota: El valor validityDuration se fija en un valor más elevado en el caso de un terminal de encendido 15 desactivado que en el caso de un terminal de encendido 15 activado. Esto es debido a que ya no puede activarse ni enviarse un DENM de actualización. Así pues, el último DENM se mantendrá activo por más tiempo.
Nota: Cuando dos DENM con el mismo causeCode procedan de la misma estación STI-C, el caso será gestionado por la estación STI-C receptora.
6.6.Clase de tráfico
78)Los DENM nuevos, de actualización y de cancelación se ajustarán en la clase de tráfico 1.
6.7.Parámetros del mensaje
6.7.1.DENM
79)El siguiente cuadro especifica los elementos de datos del DENM que se establecerán.
Cuadro 10: Elementos de datos del DENM en el servicio «advertencia de vehículo parado: vehículo averiado»
|
Campo de datos
|
Valor
|
|
Management container
|
|
actionID
|
Identificador de un DENM. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
detectionTime
|
TimestampIts: sello de tiempo en el que el evento es detectado por la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
referenceTime
|
TimestampIts: sello de tiempo en el que se genera un DENM nuevo, de actualización o de cancelación. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
termination
|
No se fijará en el caso de un DENM nuevo o de actualización. Se fijará en el valor isCancellation(0) en el caso de un DENM de cancelación.
|
|
eventPosition
|
ReferencePosition. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
relevanceDistance
|
lessThan1000m(4)
|
|
relevanceTrafficDirection
|
Si se conoce el valor roadType, el valor se fijará como sigue:
|
|
|
RoadType
|
Dirección
|
|
|
|
0
|
allTrafficDirections(0)
|
|
|
|
1
|
upstreamTraffic(1)
|
|
|
|
2
|
allTrafficDirections(0)
|
|
|
|
3
|
upstreamTraffic(1)
|
|
|
|
De lo contrario, el valor se fijará en allTrafficDirections(0).
|
|
validityDuration
|
·Terminal de encendido 15 activado: 30 s
·Terminal de encendido 15 desactivado: 900 s
|
|
stationType
|
El tipo de estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
Situation container
|
|
informationQuality
|
Véase el punto 67. Se actualizará para cada DENM de actualización.
|
|
causeCode
|
stationaryVehicle(94)
|
|
subCauseCode
|
vehicleBreakdown(2)
|
|
Location container
|
|
eventSpeed
|
Velocidad de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
eventPositionHeading
|
Rumbo de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
traces
|
PathHistory de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
|
|
roadType
|
RoadType de la carretera en la que está situada la estación STI-C detectora.
|
|
|
Se actualizará para un DENM de actualización.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2] en combinación con las siguientes reglas:
|
|
|
Urbana / No urbana
|
Separación estructural
|
Elemento de datos
|
|
|
Urbana
|
No
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
Urbana
|
Sí
|
urban-WithStructuralSeparation ToOppositeLanes(1)
|
|
|
Urbana
|
Desconocido
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
No urbana
|
No
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
No urbana
|
Sí
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
|
|
|
No urbana
|
Desconocido
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
Si no puede determinarse la información sobre la situación urbana o no urbana, se omitirá el elemento de datos.
|
|
Alacarte container
|
|
lanePosition
|
Si el valor lanePosition es suministrado por un sensor de a bordo (por ejemplo, un radar o una cámara), se fijará de acuerdo con la norma [TS 102 894-2]. Con esta versión de la condición de activación, no es lícito utilizar un GNSS y un mapa digital para calcular el número de carril.
|
|
|
Si se desconoce el valor lanePosition, se omitirá el elemento de datos.
|
|
|
Se actualizará para un DENM de actualización.
|
|
Alacarte container: StationaryVehicleContainer
|
|
stationarySince
|
Se fijará de acuerdo con el tiempo, en minutos, que la estación STI-C detectora permanezca parada. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
6.7.2.CAM
80)No se utilizará la adaptación de CAM para este servicio STI-C.
6.8.Capa de red y de transporte
81)El parámetro de interfaz DENM destination area entre el servicio básico de DEN y la capa de red y de transporte será igual a una forma circular con un radio equivalente al valor relevanceDistance.
6.9.Capa de seguridad
82)Si se cumplen las condiciones de activación según se describen en el punto 62, se bloqueará un cambio de AT para DENM nuevos, de actualización y de cancelación mientras no haya expirado el valor validityDuration. Los DENM nuevos, de actualización y de cancelación correspondientes se enviarán con el mismo AT.
7.Advertencia de vehículo parado: poscolisión
7.1.Descripción del servicio STI-C
Este servicio STI-C transmite información V2V relativa a un vehículo que está parado como consecuencia de un accidente de tráfico.
Los siguientes servicios STI-C guardan relación con este servicio, pues comparten condiciones de activación similares:
•
«advertencia de vehículo parado: vehículo detenido»;
•
«advertencia de vehículo parado: vehículo averiado».
83)Solo se enviará una señal DENM a la memoria temporal si se evalúa que las condiciones de activación descritas en el presente epígrafe son válidas. Esa señal hace que la memoria temporal genere un DENM nuevo o un DENM de actualización o cancelación. Si no se cumplen las condiciones de activación, no se generará una señal DENM.
7.2.Condiciones de activación
7.2.1.Condiciones previas
84)Para este servicio STI-C no se aplican condiciones previas específicas.
85)Se evitará la activación paralela con los demás servicios STI-C relacionados. Cuando los servicios STI-C «vehículo detenido» o «vehículo averiado» se activen al mismo tiempo, la prioridad será como sigue:
a)«poscolisión» (prioridad máxima);
b)«vehículo averiado»;
c)«vehículo detenido» (prioridad mínima).
7.2.2.Condiciones específicas del servicio
86)Si se satisfacen las condiciones previas del punto 84 y al menos una de las condiciones siguientes, se cumplen las condiciones de activación de este servicio STI-C, por lo que deberá activarse la generación de un DENM:
a)el ocupante del vehículo ha activado manualmente una eCall pulsando el botón eCall, y el vehículo queda parado en 15 s; si el vehículo ya está parado, la condición se cumple de inmediato;
b)se detecta una colisión de poca gravedad sin que se active un sistema de retención de los ocupantes irreversible (por ejemplo, desconexión de la batería de alta tensión o desbloqueo de puertas) y el vehículo queda parado en 15 s; si el vehículo ya está parado, la condición se cumple de inmediato;
c)se detecta la colisión con un peatón, con la activación de al menos un sistema de protección de peatones irreversible (por ejemplo, levantamiento del capó o airbag exterior), y el vehículo queda parado en 15 s; si el vehículo ya está parado, la condición se cumple de inmediato;
d)se detecta una colisión de mucha gravedad, con la activación de al menos un sistema de retención de los ocupantes irreversible (por ejemplo, pretensor pirotécnico del cinturón de seguridad o airbag).
87)La velocidad del vehículo será determinada por la señal de buses de este, no por GNSS. Se utilizará la velocidad filtrada del vehículo (con respecto al ruido del sensor). Este requisito se aplicará a todos los análisis subsiguientes de la velocidad del vehículo.
Nota: Las condiciones solo deben comprobarse si se dispone del suministro de energía necesario. Esto significa que no se requiere una ejecución del sistema segura contra colisiones.
7.2.3.Calidad de la información
88)El valor del elemento de datos informationQuality en el DENM depende de cómo se detecte el evento (véase el punto 86). El valor informationQuality se fijará de acuerdo con el cuadro que figura a continuación (se utilizará el valor más elevado posible).
Cuadro 11: Calidad de la información del servicio «vehículo parado: poscolisión»
|
Detección del evento
|
Valor informationQuality
|
|
Ninguna aplicación conforme con TRCO
|
unknown(0)
|
|
Se cumple la condición a).
|
1
|
|
Se cumple la condición b) o c).
|
2
|
|
Se cumple la condición d).
|
3
|
89)Si las condiciones de activación cambian entre dos actualizaciones, el valor informationQuality no cambiará hasta la próxima actualización. Si, mientras se actualiza el DENM, se siguen cumpliendo las condiciones modificadas, se actualizará el valor informationQuality.
7.3.Condiciones de terminación
90)Se pone fin a este servicio STI-C mediante una cancelación de la estación STI-C de origen. Al término del servicio STI-C se pondrá fin a la petición de un DENM de actualización.
7.3.1.Cancelación
91)Una vez que se cumpla al menos una de las condiciones siguientes antes de que haya expirado el período establecido en el elemento de datos validityDuration, deberá activarse la generación de un DENM de cancelación:
a)el vehículo ego no está parado durante 15 s;
b)la posición del vehículo ha cambiado más de 500 m (por ejemplo, por haber sido remolcado).
Nota: La condición de cancelación no implica que la estación STI-C tenga que estar permanentemente en funcionamiento o ampliar su funcionamiento durante dicha condición de cancelación.
7.3.2.Negación
92)Para este servicio STI-C no se utilizará un DENM de negación.
7.4.Actualización
93)Si el servicio STI-C no se ha cancelado, se activará un DENM de actualización cada 60 s.
94)Si el terminal de encendido 15 pasa de estar en funcionamiento a estar apagado se activará inmediatamente un DENM de actualización.
95)Se asignarán nuevos valores a los campos o elementos de datos del DENM de acuerdo con el evento modificado (por ejemplo, detectionTime o informationQuality).
Nota: La condición de actualización no implica que la estación STI-C tenga que estar permanentemente en funcionamiento o ampliar su funcionamiento durante dicha condición de actualización.
7.5.Duración de la repetición e intervalo entre repeticiones
96)Los DENM que sean nuevos o hayan sido actualizados o cancelados se repetirán durante un valor repetitionDuration de 60 s con un valor repetitionInterval de 1 s. Así pues, los parámetros de interfaz duración de la repetición e intervalo entre repeticiones entre la aplicación y el servicio básico de DEN se ajustarán de acuerdo con los valores anteriores.
97)En el caso de un terminal de encendido 15 activado, el valor validityDuration será de 180 s. Por lo tanto, puede evitarse una laguna de DENM si el valor repetitionDuration del DENM original ha expirado y la actualización aún no se ha recibido.
Nota: El valor validityDuration se fija en un valor más elevado en el caso de un terminal de encendido 15 desactivado que en el caso de un terminal de encendido 15 activado. Esto se debe al hecho de que ya no puede activarse ni enviarse un DENM de actualización. Así pues, el último DENM se mantendrá activo por más tiempo.
Nota: Cuando dos DENM con el mismo causeCode procedan de la misma estación STI-C, el caso será gestionado por la estación STI-C receptora.
7.6.Clase de tráfico
98)Los DENM nuevos, de actualización y de cancelación se ajustarán en la clase de tráfico 1.
7.7.Parámetros del mensaje
7.7.1.DENM
99)El siguiente cuadro especifica los elementos de datos del DENM que se establecerán.
Cuadro 12: Elementos de datos del DENM en el servicio «advertencia de vehículo parado: poscolisión»
|
Campo de datos
|
Valor
|
|
Management container
|
|
actionID
|
Identificador de un DENM. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
detectionTime
|
TimestampIts: sello de tiempo en el que el evento es detectado por la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
referenceTime
|
TimestampIts: sello de tiempo en el que se genera un DENM nuevo, de actualización o de cancelación. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
termination
|
No se fijará en el caso de DENM nuevo o de actualización. Se fijará en el valor isCancellation(0) en el caso de un DENM de cancelación.
|
|
eventPosition
|
ReferencePosition. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
relevanceDistance
|
lessThan5km(5)
|
|
relevanceTrafficDirection
|
Si se conoce el valor roadType, el valor se fijará como sigue:
|
|
|
RoadType
|
Dirección
|
|
|
|
0
|
allTrafficDirections(0)
|
|
|
|
1
|
upstreamTraffic(1)
|
|
|
|
2
|
allTrafficDirections(0)
|
|
|
|
3
|
upstreamTraffic(1)
|
|
|
|
De lo contrario, el valor se fijará en allTrafficDirections(0).
|
|
validityDuration
|
·Terminal de encendido 15 activado: 180 s
·Terminal de encendido 15 desactivado: 1 800 s
|
|
stationType
|
El tipo de estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
Situation container
|
|
informationQuality
|
Véase el punto 88. Se actualizará para cada DENM de actualización.
|
|
causeCode
|
stationaryVehicle(94)
|
|
subCauseCode
|
postCrash(3)
|
|
Location container
|
|
eventSpeed
|
Velocidad de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
eventPositionHeading
|
Rumbo de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
traces
|
PathHistory de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
|
|
roadType
|
RoadType de la carretera en la que está situada la estación STI-C detectora.
|
|
|
Se actualizará para un DENM de actualización.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2] en combinación con las siguientes reglas:
|
|
|
Urbana / No urbana
|
Separación estructural
|
Elemento de datos
|
|
|
Urbana
|
No
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
Urbana
|
Sí
|
urban-WithStructuralSeparation ToOppositeLanes(1)
|
|
|
Urbana
|
Desconocido
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
No urbana
|
No
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
No urbana
|
Sí
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
|
|
|
No urbana
|
Desconocido
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
Si no puede determinarse la información sobre la situación urbana o no urbana, se omitirá el elemento de datos.
|
|
Alacarte container
|
|
lanePosition
|
Si el valor lanePosition es suministrado por un sensor de a bordo (por ejemplo, un radar o una cámara), se fijará de acuerdo con la norma [TS 102 894-2]. Con esta versión de la condición de activación, no es lícito utilizar un GNSS y un mapa digital para calcular el número de carril.
|
|
|
Si se desconoce el valor lanePosition, se omitirá el elemento de datos.
|
|
|
Se actualizará para un DENM de actualización.
|
|
Alacarte container: StationaryVehicleContainer
|
|
stationarySince
|
Se fijará de acuerdo con el tiempo, en minutos, que la estación STI-C detectora permanezca parada. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
7.7.2.CAM
100)No se utilizará la adaptación de CAM para este servicio STI-C.
7.8.Capa de red y de transporte
101)El parámetro de interfaz DENM destination area entre el servicio básico de DEN y la capa de red y de transporte será igual a una forma circular con un radio equivalente al valor relevanceDistance.
7.9.Capa de seguridad
102)Si se cumplen las condiciones de activación según se describen en el punto 86, se bloqueará un cambio de AT para DENM nuevos, de actualización y de cancelación mientras no haya expirado el valor validityDuration. Los DENM nuevos, de actualización y de cancelación correspondientes se enviarán con el mismo AT.
8.Advertencia de vehículo especial: vehículo de emergencia en marcha
8.1.Descripción del servicio STI-C
Este servicio STI-C transmite información V2V relativa a un vehículo de emergencia que se desplaza hacia un lugar de actuación, lo que se señala con el encendido del dispositivo luminoso de emergencia.
103)Tan pronto como se active el servicio STI-C, la estación STI-C del vehículo de emergencia transmitirá un DENM, y partes de los campos de datos del CAM se ajustarán de conformidad con el epígrafe 8.7.2.
Los siguientes servicios STI-C guardan relación con este servicio, pues comparten condiciones de activación similares:
·«advertencia de vehículo especial: vehículo de emergencia protector parado»;
·«advertencia de vehículo especial: advertencia de servicio de rescate parado».
104)El servicio STI-C por defecto para la estación STI-C de un vehículo de emergencia es «vehículo de emergencia en marcha». Se activará un cambio en el servicio STI-C «vehículo de emergencia protector parado» únicamente en las condiciones expuestas en el epígrafe 9.
8.2.Condiciones de activación
8.2.1.Condiciones previas
105)Antes de que se active este servicio STI-C, deberán satisfacerse las condiciones previas siguientes:
a)se confirma que el valor stationType es de vehículo especial [el valor stationType del CAM se ajusta en specialVehicles(10)]; el servicio STI-C se limita a los vehículos de emergencia;
b)no se cumplirán las condiciones de activación relativas a «vehículo de emergencia protector parado» (véase el epígrafe 9.2).
8.2.2.Condiciones específicas del servicio
106)Si se cumplen las condiciones previas del punto 105 y la condición siguiente, deberá activarse la generación de un DENM:
a)el dispositivo luminoso de emergencia está encendido.
107)El nivel de calidad de la información puede mejorarse con las siguientes condiciones:
b)la sirena está en funcionamiento;
c)el vehículo no está parado.
108)La velocidad del vehículo será determinada por la señal de buses de este, no por GNSS. Se utilizará la velocidad filtrada del vehículo (con respecto al ruido del sensor).
8.2.3.Calidad de la información
109)El valor del elemento de datos informationQuality en el DENM depende de cómo se detecte el evento (véanse los puntos 106 y 107). El valor informationQuality se fijará de acuerdo con el cuadro que figura a continuación (se utilizará el valor más elevado posible).
Cuadro 13: Calidad de la información del servicio «vehículo de emergencia en marcha»
|
Detección del evento
|
Valor informationQuality
|
|
Ninguna aplicación conforme con TRCO
|
unknown(0)
|
|
Se cumple la condición a).
|
1
|
|
Se cumplen las condiciones a) y b).
|
2
|
|
Se cumplen las condiciones a) y c).
|
3
|
|
Se cumplen las condiciones a), b) y c).
|
4
|
110)Si las condiciones de activación cambian entre dos actualizaciones, el valor informationQuality no cambiará hasta la próxima actualización. Si, mientras se actualiza el DENM, se siguen cumpliendo las condiciones modificadas, se actualizará el valor informationQuality.
8.3.Condiciones de terminación
111)El servicio STI-C se terminará cuando ya no esté encendido el dispositivo luminoso de emergencia. Al término del servicio STI-C se terminará la actualización de DENM. El valor vehicleRole se ajustará en default(0) si el dispositivo luminoso de emergencia ya no está encendido.
8.3.1.Cancelación
112)Para este servicio STI-C no se utilizará un DENM de cancelación.
8.3.2.Negación
113)Para este servicio STI-C no se utilizará un DENM de negación.
8.4.Actualización
114)El DENM generado se actualizará cada 250 ms si se siguen cumpliendo las condiciones de activación. Los campos de datos a los que se asignan valores nuevos se definen en el cuadro 14.
8.5.Duración de la repetición e intervalo entre repeticiones
115)No se repetirá el DENM para este servicio STI-C.
8.6.Clase de tráfico
116)Los DENM nuevos, de actualización y de cancelación se ajustarán en la clase de tráfico 1.
8.7.Parámetros del mensaje
8.7.1.DENM
117)El siguiente cuadro especifica los elementos de datos del DENM que se establecerán.
Cuadro 14: Elementos de datos del DENM en el servicio «vehículo de emergencia en marcha»
|
Campo de datos
|
Valor
|
|
Management container
|
|
actionID
|
Identificador de un DENM. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
detectionTime
|
TimestampIts: sello de tiempo en el que el evento es detectado por la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
referenceTime
|
TimestampIts: sello de tiempo en el que se genera un DENM nuevo o de actualización. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
termination
|
No se establecerá, pues en este servicio STI-C no se utilizarán ni negación ni cancelación.
|
|
eventPosition
|
ReferencePosition. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
relevanceDistance
|
lessThan1000m(4)
|
|
relevanceTrafficDirection
|
Si se conoce el valor roadType, el valor se fijará como sigue:
|
|
|
RoadType
|
Dirección
|
|
|
|
0
|
allTrafficDirections(0)
|
|
|
|
1
|
upstreamTraffic(1)
|
|
|
|
2
|
allTrafficDirections(0)
|
|
|
|
3
|
upstreamTraffic(1)
|
|
|
|
De lo contrario, el valor se fijará en allTrafficDirections(0).
|
|
validityDuration
|
2 s
|
|
stationType
|
specialVehicles(10)
|
|
Situation container
|
|
informationQuality
|
Véase el punto 109. Se actualizará para cada DENM de actualización.
|
|
causeCode
|
emergencyVehicleApproaching(95)
|
|
subCauseCode
|
emergencyVehicleApproaching(1)
|
|
Location container
|
|
eventSpeed
|
Velocidad de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
eventPositionHeading
|
Rumbo de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
traces
|
PathHistory de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
roadType
|
RoadType de la carretera en la que está situada la estación STI-C detectora.
|
|
|
Se actualizará para un DENM de actualización.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2] en combinación con las siguientes reglas:
|
|
|
Urbana / No urbana
|
Separación estructural
|
Elemento de datos
|
|
|
Urbana
|
No
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
Urbana
|
Sí
|
urban-WithStructuralSeparation ToOppositeLanes(1)
|
|
|
Urbana
|
Desconocido
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
No urbana
|
No
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
No urbana
|
Sí
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
|
|
|
No urbana
|
Desconocido
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
Si no puede determinarse la información sobre la situación urbana o no urbana, se omitirá el elemento de datos.
|
|
Alacarte container
|
|
lanePosition
|
Si el valor lanePosition es suministrado por un sensor de a bordo (por ejemplo, un radar o una cámara), se fijará de acuerdo con la norma [TS 102 894-2]. Con esta versión de la condición de activación, no es lícito utilizar un GNSS y un mapa digital para calcular el número de carril.
|
|
|
Si se desconoce el valor lanePosition, se omitirá el elemento de datos.
|
|
|
Se actualizará para un DENM de actualización.
|
|
Alacarte container: StationaryVehicleContainer
|
|
stationarySince
|
Se fijará de acuerdo con el tiempo, en minutos, que la estación STI-C detectora permanezca parada. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
8.7.2.CAM
118)El valor vehicleRole se inicializará en un ajuste «por defecto» [vehicleRole del CAM ajustado en default(0)]. Si se cumple al menos una de las condiciones de activación del punto 106, el valor vehicleRole se ajustará en emergency(6).
119)El siguiente cuadro especifica los elementos de datos del CAM que se establecerán si se activa el servicio STI-C .
Cuadro 15: Elementos de datos del CAM en el servicio «vehículo de emergencia en marcha»
|
Campo de datos
|
Valor
|
|
CoopAwareness
|
|
generationDeltaTime
|
Hora correspondiente a la de la posición de referencia en el CAM, considerada como hora de generación del CAM.
|
|
|
Se fijará de acuerdo con la norma [EN 302 637-2].
|
|
BasicContainer
|
|
stationType
|
specialVehicles(10)
|
|
referencePosition
|
Posición y exactitud de la posición medidas en el punto de referencia de la estación STI-C de origen.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
El valor HighFrequencyContainer se ajustará en BasicVehicleContainerHighFrequency
|
|
heading
|
Dirección del rumbo de la estación STI-C de origen en relación con el norte geográfico.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
speed
|
Velocidad de circulación de la estación STI-C de origen.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
driveDirection
|
Dirección de circulación del vehículo (hacia delante o hacia atrás) de la estación STI-C de origen.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
vehicleLength
|
Longitud del vehículo.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
vehicleWidth
|
Anchura del vehículo.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
longitudinalAcceleration
|
Aceleración longitudinal del vehículo de la estación STI-C de origen.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
curvature
|
Curvatura de la trayectoria del vehículo y la exactitud.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
curvatureCalcMode
|
Describe si se utiliza la velocidad de guiñada para calcular la curvatura de un valor de curvatura comunicado.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
yawRate
|
Velocidad de guiñada del vehículo en un momento dado.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
El valor LowFrequencyContainer se ajustará en BasicVehicleContainerLowFrequency
|
|
vehicleRole
|
emergency(6)
|
|
exteriorLights
|
Describe el estado de los interruptores de las luces exteriores de un vehículo.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
pathHistory
|
Representa el movimiento de un vehículo a lo largo de un período o una distancia recientes.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
El valor SpecialVehicleContainer se ajustará en EmergencyContainer
|
|
lightBarSirenInUse
|
El bit lightBarActivated se ajustará en 1(onChange) si se detecta el funcionamiento del dispositivo luminoso de emergencia; de lo contrario, se fijará en 0.
|
|
|
El bit sirenActivated se ajustará en 1 si se detecta el funcionamiento de la sirena; de lo contrario, se fijará en 0.
|
|
emergencyPriority
|
No se requiere.
|
|
causeCode
|
Según lo especificado en el punto 117.
|
|
subCauseCode
|
Según lo especificado en el punto 117.
|
8.8.Capa de red y de transporte
120)El parámetro de interfaz DENM destination area entre el servicio básico de DEN y la capa de red y de transporte será igual a una forma circular con un radio equivalente al valor relevanceDistance.
8.9.Capa de seguridad
121)Si se cumplen las condiciones de activación según se describen en el punto 106, se bloqueará un cambio de AT para DENM nuevos y de actualización mientras no haya expirado el valor validityDuration. Los DENM nuevos y de actualización correspondientes se enviarán con el mismo AT.
9.Advertencia de vehículo especial: vehículo de emergencia protector parado
9.1.Descripción del servicio STI-C
Este servicio STI-C transmite información V2V relativa a un vehículo de emergencia parado que está protegiendo una zona de peligro.
122)Tan pronto como se active el servicio STI-C, la estación STI-C del vehículo de emergencia transmitirá un DENM, y partes de los campos de datos del CAM se ajustarán de conformidad con el epígrafe 9.7.2.
Los siguientes servicios STI-C guardan relación con este servicio, pues comparten condiciones de activación similares:
·«advertencia de vehículo especial: vehículo de emergencia en marcha»;
·«advertencia de vehículo especial: advertencia de servicio de rescate parado».
9.2.Condiciones de activación
9.2.1.Condiciones previas
123)Antes de que se active este servicio STI-C, deberán satisfacerse las condiciones previas siguientes:
·se confirma que el valor stationType es de vehículo de emergencia [el valor stationType del CAM se ajusta en specialVehicles(10)]; el servicio STI-C se limita a los vehículos de emergencia;
·el temporizador de espera se inicializará con cero.
124)El servicio STI-C por defecto para la estación STI-C de un vehículo de emergencia es «vehículo de emergencia en marcha». Se activará un cambio en el servicio STI-C «vehículo de emergencia protector parado» únicamente en las condiciones expuestas en el epígrafe 9.2.2.
9.2.2.Condiciones específicas del servicio
125)Si el vehículo está parado y el dispositivo luminoso de emergencia está en funcionamiento, se inicializará con cero y se pondrá en marcha un temporizador de espera. Si el dispositivo luminoso de emergencia ya no está en funcionamiento o el vehículo deja de estar parado, el temporizador de espera se detendrá y se volverá a poner a cero.
126)Si se satisfacen las condiciones previas del punto 123 y al menos una de las condiciones siguientes, se cumplen las condiciones de activación de este servicio STI-C, por lo que deberá activarse la generación de un DENM:
a)el dispositivo luminoso de emergencia está en funcionamiento y el relé del motor está activado;
b)el dispositivo luminoso de emergencia está en funcionamiento, las luces de emergencia están encendidas y el freno de estacionamiento está activado o (en caso de transmisión automática) la palanca está en la posición «aparcamiento»;
c)el dispositivo luminoso de emergencia está en funcionamiento, las luces de emergencia están encendidas y el temporizador de espera está en 60 s o más.
127)El nivel de calidad de la información puede mejorarse con las siguientes condiciones:
d)el estado de al menos una puerta, o del maletero, es «abierto»;
e)se detecta que el asiento del conductor está en estado «no ocupado», mediante una de las técnicas siguientes:
1)cámara en el habitáculo;
2)la técnica más avanzada respecto a la ocupación del asiento que se utiliza en el recordatorio del cinturón de seguridad.
128)La velocidad del vehículo será determinada por la señal de buses de este, no por GNSS. Se utilizará la velocidad filtrada del vehículo (con respecto al ruido del sensor). Este requisito se aplicará a todos los análisis subsiguientes de la velocidad del vehículo.
129)Si el servicio STI-C se activa por el cumplimiento de las condiciones a) o b) del punto 126, el temporizador de espera se detendrá y se ajustará en 60 s. En la fase de actualización solo se comprobarán las condiciones, pero no se iniciará ningún temporizador.
9.2.3.Calidad de la información
130)El valor del elemento de datos informationQuality en el DENM depende de cómo se detecte el evento (véanse los puntos 126 y 127). El valor informationQuality se fijará de acuerdo con el cuadro que figura a continuación (se utilizará el valor más elevado posible).
Cuadro 16: Calidad de la información del servicio «vehículo de emergencia protector parado»
|
Detección del evento
|
Valor informationQuality
|
|
Ninguna aplicación conforme con TRCO
|
unknown(0)
|
|
Se cumple la condición c).
|
1
|
|
Se cumple la condición b).
|
2
|
|
Se cumplen al menos una de las condiciones b) o c) y la condición d).
|
3
|
|
Se cumplen al menos una de las condiciones b) o c) y la condición e).
|
4
|
|
Se cumple la condición a).
|
5
|
131)Si las condiciones de activación cambian entre dos actualizaciones, el valor informationQuality no cambiará hasta la próxima actualización. Si, mientras se actualiza el DENM, se siguen cumpliendo las condiciones modificadas, se actualizará el valor informationQuality.
9.3.Condiciones de terminación
132)Se pone fin a este servicio STI-C mediante una cancelación de la estación STI-C de origen. Al término del servicio STI-C se pondrá fin a la petición de un DENM de actualización.
9.3.1.Cancelación
133)Si se cumple la condición siguiente antes de que haya expirado el período establecido en el elemento de datos validityDuration, deberá activarse la generación de un DENM de cancelación:
a)ya no se cumple ninguna de las condiciones a) a c) específicas del servicio STI-C indicadas en el epígrafe 9.2.2.
El valor vehicleRole se ajustará en default(0) si el dispositivo luminoso de emergencia ya no está encendido.
9.3.2.Negación
134)Para este servicio STI-C no se utilizará un DENM de negación.
9.4.Actualización
135)El DENM generado se actualizará cada 60 s si se siguen cumpliendo las condiciones de activación. Todos los campos de datos a los que se asignan valores nuevos se definen en el cuadro 17.
9.5.Duración de la repetición e intervalo entre repeticiones
136)Los DENM que sean nuevos o hayan sido actualizados o cancelados se repetirán durante un valor repetitionDuration de 60 s con un valor repetitionInterval de 1 s. Así pues, los parámetros de interfaz duración de la repetición e intervalo entre repeticiones entre la aplicación y el servicio básico de DEN se ajustarán de acuerdo con los valores anteriores.
Nota: El valor validityDuration se ajusta en 180 s. Por lo tanto, puede evitarse una laguna de DENM si el valor repetitionDuration del DENM original ha expirado y la actualización aún no se ha recibido.
Nota: Cuando dos DENM con el mismo causeCode procedan de la misma estación STI-C, el caso será gestionado por la estación STI-C receptora.
9.6.Clase de tráfico
137)Los DENM nuevos, de actualización y de cancelación se ajustarán en la clase de tráfico 1.
9.7.Parámetros del mensaje
9.7.1.DENM
138)El siguiente cuadro especifica los elementos de datos del DENM que se establecerán.
Cuadro 17: Elementos de datos del DENM en el servicio «vehículo de emergencia protector parado»
|
Campo de datos
|
Valor
|
|
Management container
|
|
actionID
|
Identificador de un DENM. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
detectionTime
|
TimestampIts: sello de tiempo en el que el evento es detectado por la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
referenceTime
|
TimestampIts: sello de tiempo en el que se genera un DENM nuevo, de actualización o de cancelación. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
termination
|
No se fijará en el caso de DENM nuevo o de actualización. Se fijará en el valor isCancellation(0) en caso de que se cumplan las condiciones de cancelación; véase el punto 133.
|
|
eventPosition
|
ReferencePosition. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
relevanceDistance
|
lessThan5km(5)
|
|
relevanceTrafficDirection
|
Si se conoce el valor roadType, el valor se fijará como sigue:
|
|
|
RoadType
|
Dirección
|
|
|
|
0
|
allTrafficDirections(0)
|
|
|
|
1
|
upstreamTraffic(1)
|
|
|
|
2
|
allTrafficDirections(0)
|
|
|
|
3
|
upstreamTraffic(1)
|
|
|
|
De lo contrario, el valor se fijará en allTrafficDirections(0).
|
|
validityDuration
|
180 s
|
|
stationType
|
specialVehicles(10)
|
|
Situation container
|
|
informationQuality
|
Véase el punto 130. Se actualizará para cada DENM de actualización.
|
|
causeCode
|
rescueAndRecoveryWorkInProgress(15)
|
|
subCauseCode
|
emergencyVehicles(1)
|
|
Location container
|
|
eventSpeed
|
Velocidad de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
eventPositionHeading
|
Rumbo de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
traces
|
PathHistory de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
|
|
|
roadType
|
RoadType de la carretera en la que está situada la estación STI-C detectora.
|
|
|
Se actualizará para un DENM de actualización.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2] en combinación con las siguientes reglas:
|
|
|
Urbana / No urbana
|
Separación estructural
|
Elemento de datos
|
|
|
Urbana
|
No
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
Urbana
|
Sí
|
urban-WithStructuralSeparation ToOppositeLanes(1)
|
|
|
Urbana
|
Desconocido
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
No urbana
|
No
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
No urbana
|
Sí
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
|
|
|
No urbana
|
Desconocido
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
Si no puede determinarse la información sobre la situación urbana o no urbana, se omitirá el elemento de datos.
|
|
Alacarte container
|
|
lanePosition
|
Si el valor lanePosition es suministrado por un sensor de a bordo (por ejemplo, un radar o una cámara), se fijará de acuerdo con la norma [TS 102 894-2]. Con esta versión de la condición de activación, no es lícito utilizar un GNSS y un mapa digital para calcular el número de carril.
|
|
|
Si se desconoce el valor lanePosition, se omitirá el elemento de datos.
|
|
|
Se actualizará para un DENM de actualización.
|
|
Alacarte container: StationaryVehicleContainer
|
|
stationarySince
|
Se fijará de acuerdo con el tiempo, en minutos, que la estación STI-C detectora permanezca parada. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
9.7.2.CAM
139)El valor vehicleRole se inicializará en un ajuste «por defecto» [vehicleRole del CAM ajustado en default(0)]. Si se cumple al menos una de las condiciones de activación definidas en el punto 126, el valor vehicleRole se ajustará en emergency(6).
140)El siguiente cuadro especifica los elementos de datos del CAM que se establecerán si se activa el servicio STI-C .
Cuadro 18: Elementos de datos del CAM en el servicio «vehículo de emergencia protector parado»
|
Campo de datos
|
Valor
|
|
CoopAwareness
|
|
generationDeltaTime
|
Hora correspondiente a la de la posición de referencia en el CAM, considerada como hora de generación del CAM.
|
|
|
Se fijará de acuerdo con la norma [EN 302 637-2].
|
|
BasicContainer
|
|
stationType
|
specialVehicles(10)
|
|
referencePosition
|
Posición y exactitud de la posición medidas en el punto de referencia de la estación STI-C de origen.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
El valor HighFrequencyContainer se ajustará en BasicVehicleContainerHighFrequency
|
|
heading
|
Dirección del rumbo de la estación STI-C de origen en relación con el norte geográfico.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
speed
|
Velocidad de circulación de la estación STI-C de origen.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
driveDirection
|
Dirección de circulación del vehículo (hacia delante o hacia atrás) de la estación STI-C de origen.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
vehicleLength
|
Longitud del vehículo.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
vehicleWidth
|
Anchura del vehículo.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
longitudinalAcceleration
|
Aceleración longitudinal del vehículo de la estación STI-C de origen.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
curvature
|
Curvatura de la trayectoria del vehículo y la exactitud.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
curvatureCalcMode
|
Describe si se utiliza la velocidad de guiñada para calcular la curvatura de un valor de curvatura comunicado.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
yawRate
|
Velocidad de guiñada del vehículo en un momento dado.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
El valor LowFrequencyContainer se ajustará en BasicVehicleContainerLowFrequency
|
|
vehicleRole
|
emergency(6)
|
|
exteriorLights
|
Describe el estado de los interruptores de las luces exteriores de un vehículo.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
pathHistory
|
Representa el movimiento de un vehículo a lo largo de un período o una distancia recientes.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
El valor SpecialVehicleContainer se ajustará en EmergencyContainer
|
|
lightBarSirenInUse
|
El bit lightBarActivated se ajustará en 1(onChange) si se detecta el funcionamiento del dispositivo luminoso de emergencia, de lo contrario, se ajustará en 0.
|
|
|
El bit sirenActivated se ajustará en 1 si se detecta el funcionamiento de la sirena, de lo contrario, se ajustará en 0.
|
|
emergencyPriority
|
No se requiere.
|
|
causeCode
|
Según lo especificado en el punto 138.
|
|
subCauseCode
|
Según lo especificado en el punto 138.
|
9.8.Capa de red y de transporte
141)El parámetro de interfaz DENM destination area entre el servicio básico de DEN y la capa de red y de transporte será igual a una forma circular con un radio equivalente al valor relevanceDistance.
9.9.Capa de seguridad
142)Si se cumplen las condiciones de activación según se describen en el punto 126, se bloqueará un cambio de AT para DENM nuevos, de actualización y de cancelación mientras no haya expirado el valor validityDuration. Los DENM nuevos, de actualización y de cancelación correspondientes se enviarán con el mismo AT.
10.Advertencia de vehículo especial: advertencia de servicio de rescate parado
10.1.Descripción del servicio STI-C
Este servicio STI-C transmite información V2V relativa a un vehículo de servicio de rescate que asiste a un vehículo averiado. El servicio STI-C del servicio de rescate en movimiento, por ejemplo portando un vehículo averiado, está cubierto por el CAM común.
Los siguientes servicios STI-C guardan relación con este servicio, pues comparten condiciones de activación similares:
·«advertencia de vehículo especial: vehículo de emergencia en marcha»;
·«advertencia de vehículo especial: vehículo de emergencia protector parado».
10.2.Condiciones de activación
10.2.1.Condiciones previas
143)Antes de que se active este servicio STI-C, deberán satisfacerse las condiciones previas siguientes:
·se confirma que el valor stationType es de vehículo de emergencia [el valor stationType del CAM se ajusta en specialVehicles(10)]; el servicio STI-C se limita a los vehículos de servicio de rescate;
·el temporizador de espera se inicializará con cero.
10.2.2.Condiciones específicas del servicio
144)Si el vehículo está parado y el dispositivo luminoso de emergencia está en funcionamiento, se inicializará con cero y se pondrá en marcha un temporizador de espera. Si el dispositivo luminoso de emergencia ya no está en funcionamiento o el vehículo deja de estar parado, el temporizador de espera se detendrá y se volverá a poner a cero.
145)Si se satisfacen las condiciones previas del punto 143 y al menos una de las condiciones siguientes, se cumplen las condiciones de activación de este servicio STI-C, por lo que deberá activarse la generación de un DENM:
a)el dispositivo luminoso de emergencia está en funcionamiento, las luces de emergencia están encendidas y el freno de estacionamiento está activado o (en caso de transmisión automática) la palanca está en la posición «aparcamiento»;
b)el dispositivo luminoso de emergencia está en funcionamiento, las luces de emergencia están encendidas y el temporizador de espera está en 60 s o más.
146)El nivel de calidad de la información puede mejorarse con las siguientes condiciones:
c)el estado de la puerta del conductor es «abierto»;
d)se detecta que el asiento del conductor está en estado «no ocupado», mediante una de las técnicas siguientes:
1)cámara en el habitáculo;
2)la técnica más avanzada respecto a la ocupación del asiento que se utiliza en el recordatorio del cinturón de seguridad.
147)La velocidad del vehículo será determinada por la señal de buses de este, no por GNSS. Se utilizará la velocidad filtrada del vehículo (con respecto al ruido del sensor). Este requisito se aplicará a todos los análisis subsiguientes de la velocidad del vehículo.
148)Si el servicio STI-C se activa por el cumplimiento de la condición a) del punto 145, el temporizador de espera se detendrá y se ajustará en 60 s. En la fase de actualización solo se comprobarán las condiciones, pero no se iniciará ningún temporizador.
10.2.3.Calidad de la información
149)El valor del elemento de datos informationQuality en el DENM depende de cómo se detecte el evento (véanse los puntos 145 y 146). El valor informationQuality se fijará de acuerdo con el cuadro que figura a continuación (se utilizará el valor más elevado posible).
Cuadro 19: Calidad de la información del servicio «advertencia de servicio de rescate parado»
|
Detección del evento
|
Valor informationQuality
|
|
Ninguna aplicación conforme con TRCO
|
unknown(0)
|
|
Se cumple la condición b).
|
1
|
|
Se cumple la condición a).
|
2
|
|
Se cumplen al menos una de las condiciones a) o b) y la condición c).
|
3
|
|
Se cumplen al menos una de las condiciones a) o b) y la condición d).
|
4
|
150)Si las condiciones de activación cambian entre dos actualizaciones, el valor informationQuality no cambiará hasta la próxima actualización. Si, mientras se actualiza el DENM, se siguen cumpliendo las condiciones modificadas, se actualizará el valor informationQuality.
10.3.Condiciones de terminación
151)Se pone fin a este servicio STI-C mediante una cancelación de la estación STI-C de origen. Al término del servicio STI-C se pondrá fin a la petición de un DENM de actualización.
10.3.1.Cancelación
152)Si se cumple la condición siguiente antes de que haya expirado el período establecido en el elemento de datos validityDuration, deberá activarse la generación de un DENM de cancelación y el valor vehicleRole se ajustará en default(0):
a)no se cumplen las condiciones a) y b) específicas del servicio STI-C indicadas en el punto 145.
10.3.2.Negación
153)Para este servicio STI-C no se utilizará un DENM de negación.
10.4.Actualización
154)El DENM generado se actualizará cada 60 s si se siguen cumpliendo las condiciones de activación. Todos los campos de datos a los que se asignan valores nuevos se definen en el cuadro 20.
10.5.Duración de la repetición e intervalo entre repeticiones
155)Los DENM que sean nuevos o hayan sido actualizados o cancelados se repetirán durante un valor repetitionDuration de 60 s con un valor repetitionInterval de 1 s. Así pues, los parámetros de interfaz duración de la repetición e intervalo entre repeticiones entre la aplicación y el servicio básico de DEN se ajustarán de acuerdo con los valores anteriores.
Nota: El valor validityDuration se ajusta en 180 s. Por lo tanto, puede evitarse una laguna de DENM si el valor repetitionDuration del DENM original ha expirado y la actualización aún no se ha recibido.
Nota: Cuando dos DENM con el mismo causeCode procedan de la misma estación STI-C, el caso será gestionado por la estación STI-C receptora.
10.6.Clase de tráfico
156)Los DENM nuevos, de actualización y de cancelación se ajustarán en la clase de tráfico 1.
10.7.Parámetros del mensaje
10.7.1.DENM
157)El siguiente cuadro especifica los elementos de datos del DENM que se establecerán.
Cuadro 20: Elementos de datos del DENM en el servicio «advertencia de servicio de rescate parado»
|
Campo de datos
|
Valor
|
|
Management container
|
|
actionID
|
Identificador de un DENM. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
detectionTime
|
TimestampIts: sello de tiempo en el que el evento es detectado por la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
referenceTime
|
TimestampIts: sello de tiempo en el que se genera un DENM nuevo, de actualización o de cancelación. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
termination
|
No se fijará en el caso de DENM nuevo o de actualización. Se fijará en el valor isCancellation(0) en caso de que se cumplan las condiciones de cancelación; véase el punto 152.
|
|
eventPosition
|
ReferencePosition. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
relevanceDistance
|
lessThan5km(5)
|
|
relevanceTrafficDirection
|
Si se conoce el valor roadType, el valor se fijará como sigue:
|
|
|
RoadType
|
Dirección
|
|
|
|
0
|
allTrafficDirections(0)
|
|
|
|
1
|
upstreamTraffic(1)
|
|
|
|
2
|
allTrafficDirections(0)
|
|
|
|
3
|
upstreamTraffic(1)
|
|
|
|
De lo contrario, el valor se fijará en allTrafficDirections(0).
|
|
validityDuration
|
180 s
|
|
stationType
|
specialVehicles(10)
|
|
Situation container
|
|
informationQuality
|
Véase el punto 149. Se actualizará para cada DENM de actualización.
|
|
causeCode
|
rescueAndRecoveryWorkInProgress(15)
|
|
subCauseCode
|
unavailable(0)
|
|
Location container
|
|
eventSpeed
|
Velocidad de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
eventPositionHeading
|
Rumbo de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
traces
|
PathHistory de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
|
|
|
|
|
|
roadType
|
RoadType de la carretera en la que está situada la estación STI-C detectora.
|
|
|
Se actualizará para un DENM de actualización.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2] en combinación con las siguientes reglas:
|
|
|
Urbana / No urbana
|
Separación estructural
|
Elemento de datos
|
|
|
Urbana
|
No
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
Urbana
|
Sí
|
urban-WithStructuralSeparation ToOppositeLanes(1)
|
|
|
Urbana
|
Desconocido
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
No urbana
|
No
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
No urbana
|
Sí
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
|
|
|
No urbana
|
Desconocido
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
Si no puede determinarse la información sobre la situación urbana o no urbana, se omitirá el elemento de datos.
|
|
Alacarte container
|
|
lanePosition
|
Si el valor lanePosition es suministrado por un sensor de a bordo (por ejemplo, un radar o una cámara), se fijará de acuerdo con la norma [TS 102 894-2]. Con esta versión de la condición de activación, no es lícito utilizar un GNSS y un mapa digital para calcular el número de carril.
|
|
|
Si se desconoce el valor lanePosition, se omitirá el elemento de datos.
|
|
|
Se actualizará para un DENM de actualización.
|
|
Alacarte Container: StationaryVehicleContainer
|
|
stationarySince
|
Se fijará de acuerdo con el tiempo, en minutos, que la estación STI-C detectora permanezca parada. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
10.7.2.CAM
158)El valor vehicleRole se inicializará en un ajuste «por defecto» [vehicleRole del CAM ajustado en default(0)]. Si se cumple al menos una de las condiciones de activación definidas en el punto 145, el valor vehicleRole se ajustará en rescue(5).
159)El siguiente cuadro especifica los elementos de datos del CAM que se establecerán si se activa el servicio STI-C .
Cuadro 21: Elementos de datos del CAM en el servicio «advertencia de servicio de rescate parado»
|
Campo de datos
|
Valor
|
|
CoopAwareness
|
|
generationDeltaTime
|
Hora correspondiente a la hora de la posición de referencia en el CAM, considerada como hora de generación del CAM.
|
|
|
Se fijará de acuerdo con la norma [EN 302 637-2].
|
|
BasicContainer
|
|
stationType
|
specialVehicles(10)
|
|
referencePosition
|
Posición y exactitud de la posición medidas en el punto de referencia de la estación STI-C de origen.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
El valor HighFrequencyContainer se ajustará en BasicVehicleContainerHighFrequency
|
|
heading
|
Dirección del rumbo de la estación STI-C de origen en relación con el norte geográfico.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
speed
|
Velocidad de circulación de la estación STI-C de origen.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
driveDirection
|
Dirección de circulación del vehículo (hacia delante o hacia atrás) de la estación STI-C de origen.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
vehicleLength
|
Longitud del vehículo.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
vehicleWidth
|
Anchura del vehículo.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
longitudinalAcceleration
|
Aceleración longitudinal del vehículo de la estación STI-C de origen.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
curvature
|
Curvatura de la trayectoria del vehículo y la exactitud.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
curvatureCalcMode
|
Describe si se utiliza la velocidad de guiñada para calcular la curvatura de un valor de curvatura comunicado.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
yawRate
|
Velocidad de guiñada del vehículo en un momento dado.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
El valor LowFrequencyContainer se ajustará en BasicVehicleContainerLowFrequency
|
|
vehicleRole
|
rescue(5)
|
|
exteriorLights
|
Describe el estado de los interruptores de las luces exteriores de un vehículo.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
pathHistory
|
Representa el movimiento de un vehículo a lo largo de un período o una distancia recientes.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
El valor SpecialVehicleContainer se ajustará en SafetyCarContainer
|
|
lightBarSirenInUse
|
El bit lightBarActivated se ajustará en 1(onChange) si se detecta el funcionamiento del dispositivo luminoso de emergencia; de lo contrario, se fijará en 0.
|
|
|
El bit sirenActivated se ajustará en 1 si se detecta el funcionamiento de la sirena; de lo contrario, se fijará en 0.
|
|
causeCode
|
Según lo especificado en el punto 157.
|
|
subCauseCode
|
Según lo especificado en el punto 157.
|
10.8.Capa de red y de transporte
160)El parámetro de interfaz DENM destination area entre el servicio básico de DEN y la capa de red y de transporte será igual a una forma circular con un radio equivalente al valor relevanceDistance.
10.9.Capa de seguridad
161)Si se cumplen las condiciones de activación según se describen en el punto 145, se bloqueará un cambio de AT para DENM nuevos, de actualización y de cancelación mientras no haya expirado el valor validityDuration. Los DENM nuevos, de actualización y de cancelación correspondientes se enviarán con el mismo AT.
11.Intercambio de IRC: IRC de petición
11.1.Descripción del servicio STI-C
Este servicio STI-C transmite información V2V relativa a una situación crítica de circulación en la que es muy probable o inevitable que se produzca una colisión entre dos vehículos. El vehículo ego reconoce una posible colisión y envía su propio IRC para obtener el IRC del vehículo con el que puede colisionar.
Los siguientes servicios STI-C guardan relación con este servicio, pues comparten condiciones de activación similares:
·«intercambio de IRC: IRC de respuesta».
162)Solo se enviará una señal DENM a la memoria temporal si se evalúa que las condiciones de activación descritas en el presente epígrafe son válidas. Esa señal hace que la memoria temporal genere un DENM nuevo. Si no se cumplen las condiciones de activación, no se generará una señal DENM.
11.2.Condiciones de activación
11.2.1.Condiciones previas
163)Para este servicio STI-C no se aplican condiciones previas específicas.
11.2.2.Condiciones específicas del servicio
164)Si se satisfacen las dos condiciones siguientes, se cumplen las condiciones de activación de este servicio STI-C, por lo que deberá activarse la generación de un DENM:
a)el «tiempo hasta colisión» (TTC) calculado por el algoritmo de un dispositivo de medición de a bordo es < 1,5 s; la tolerancia aceptable para el valor TTC calculado es del 10 %;
b)la velocidad relativa entre dos vehículos en posible colisión supera los 20 km/h.
Nota: El cálculo del TTC basado únicamente en la posición GNSS, tal como la ofrecen los receptores GNSS más modernos, no es lo bastante fiable para este servicio.
11.2.3.Calidad de la información
165)El valor del elemento de datos informationQuality en el DENM depende de cómo se detecte el evento. El valor informationQuality se fijará de acuerdo con el cuadro que figura a continuación (se utilizará el valor más elevado posible).
Cuadro 22: Calidad de la información del servicio «intercambio de IRC: IRC de petición»
|
Detección del evento
|
Valor informationQuality
|
|
Ninguna aplicación conforme con TRCO
|
unknown(0)
|
|
En los demás casos
|
1
|
11.3.Condiciones de terminación
166)No se planteará una terminación del servicio STI-C.
11.3.1.Cancelación
167)Para este servicio STI-C no se utilizará un DENM de cancelación.
11.3.2.Negación
168)Para este servicio STI-C no se utilizará un DENM de negación.
11.4.Actualización
169)Para este servicio STI-C no se utilizará un DENM de actualización.
11.5.Duración de la repetición e intervalo entre repeticiones
170)Se repetirán DENM nuevos durante un valor repetitionDuration de 300 ms (100 ms tres veces seguidas) con un valor repetitionInterval de 100 ms. Así pues, los parámetros de interfaz duración de la repetición e intervalo entre repeticiones entre la aplicación y el servicio básico de DEN se ajustarán de acuerdo con los valores anteriores.
Nota: Como no está garantizado que un IRC enviado llegue al receptor (por ejemplo, debido a la carga del canal, a la salida temporal del radio de acción, etc.), el emisor envía el IRC tres veces seguidas. Esto equivale a un valor repetitionDuration de 300 ms.
Nota: La duración estimada para transmitir (de aplicación a aplicación) un IRC (sin incluir la repetición) a través de una WLAN de automoción es de 200300 ms. Si la recepción se consigue solo al tercer intento (caso más desfavorable), en ambos casos (petición y respuesta), la información estará disponible para los dos vehículos después de 1 s (2 * [300 ms + 100 ms (@10 Hz) + 100 ms (@10 Hz)]). Por lo tanto, el parámetro de activación TTC < 1,5 s es suficiente. El envío de los IRC tres veces seguidas se considera un buen compromiso entre cargar el canal y garantizar una transmisión eficaz.
Nota: Solo el primer DENM se enviará sin limitaciones del control de congestión descentralizado (DCC). El segundo y el tercer DENM pueden verse afectados por el DCC (en función de la actual carga del canal).
Nota: Cuando dos DENM con el mismo causeCode procedan de la misma estación STI-C, el caso será gestionado por la estación STI-C receptora.
11.6.Clase de tráfico
171)Los DENM nuevos se ajustarán en la clase de tráfico 0.
11.7.Parámetros del mensaje
11.7.1.DENM
172)El siguiente cuadro especifica los elementos de datos del DENM que se establecerán.
Cuadro 23: Elementos de datos del DENM en el servicio «intercambio de IRC: IRC de petición»
|
Campo de datos
|
Valor
|
|
Management container
|
|
actionID
|
Identificador de un DENM. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
detectionTime
|
TimestampIts: sello de tiempo en el que el evento es detectado por la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
referenceTime
|
TimestampIts: sello de tiempo en el que se genera un DENM nuevo. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
termination
|
No se establecerá, pues en este servicio STI-C no se utilizarán ni negación ni cancelación.
|
|
eventPosition
|
ReferencePosition. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
relevanceDistance
|
lessThan100m(1)
Nota: Esto cubrirá también el caso más desfavorable de conducción a casi 250 km/h hacia un final de fila peligroso (s = v * t = 69,4 m/s * 1,5 s = 104,2 m).
|
|
relevanceTrafficDirection
|
allTrafficDirections(0)
|
|
validityDuration
|
2 s
Nota: Será superior al TTC.
|
|
stationType
|
El tipo de estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
Situation container
|
|
informationQuality
|
Véase el punto 165.
|
|
causeCode
|
collisionRisk(97)
|
|
subCauseCode
|
unavailable(0)
|
|
Location container
|
|
eventSpeed
|
Velocidad de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
eventPositionHeading
|
Rumbo de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
traces
|
PathHistory de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
roadType
|
Se fijará de acuerdo con la norma [TS 102 894-2]. Si no puede determinarse la información sobre la situación urbana o no urbana, se omitirá el elemento de datos.
|
|
Alacarte container: ImpactReductionContainer
|
|
heightLonCarrLeft
|
Altura del soporte longitudinal izquierdo del vehículo, desde la base hasta la parte superior. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
heightLonCarrRight
|
Altura del soporte longitudinal derecho del vehículo, desde la base hasta la parte superior. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
posLonCarrLeft
|
Distancia longitudinal desde el centro del parachoques delantero hasta la parte delantera del soporte longitudinal izquierdo del vehículo. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
posLonCarrRight
|
Distancia longitudinal desde el centro del parachoques delantero hasta la parte delantera del soporte longitudinal derecho del vehículo. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
positionOfPillars
|
Los montantes del vehículo son los soportes verticales o cuasiverticales de un vehículo, denominados, respectivamente, A, B, C o D. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
posCentMass
|
Distancia perpendicular desde el centro de la masa de un vehículo sin carga hasta la línea delantera de la caja envolvente del vehículo. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
wheelBaseVehicle
|
Distancia perpendicular entre el eje delantero y el eje trasero de la batalla del vehículo. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
turningRadius
|
Viraje circular más pequeño (es decir, viraje en U) que el vehículo puede realizar. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
posFrontAx
|
Distancia perpendicular entre la línea delantera del vehículo de la caja envolvente y el eje de ruedas delantero. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
positionOfOccupants
|
Cadena de bits que indica si un asiento de pasajero está ocupado o si el estado de ocupación es detectable. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
vehicleMass
|
Masa de un vehículo sin carga. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
requestResponseIndication
|
request(0)
|
11.7.2.CAM
173)No se utilizará la adaptación de CAM para este servicio STI-C.
11.8.Capa de red y de transporte
174)El parámetro de interfaz DENM destination area entre el servicio básico de DEN y la capa de red y de transporte será igual a una forma circular con un radio equivalente al valor relevanceDistance.
11.9.Capa de seguridad
175)Si se cumplen las condiciones de activación según se describen en el punto 164, se bloqueará un cambio de AT mientras no haya expirado el valor validityDuration.
12.Intercambio de IRC: IRC de respuesta
12.1.Descripción del servicio STI-C
Este servicio STI-C transmite información V2V relativa a una situación crítica de circulación en la que es muy probable o inevitable que se produzca una colisión entre dos vehículos. El vehículo ego ha recibido un IRC de otro vehículo y envía en respuesta su propio IRC.
Los siguientes servicios STI-C guardan relación con este servicio, pues comparten condiciones de activación similares:
·«intercambio de IRC: IRC de petición».
176)Solo se enviará una señal DENM a la memoria temporal si se evalúa que las condiciones de activación descritas en el presente epígrafe son válidas. Esa señal hace que la memoria temporal genere un DENM nuevo. Si no se cumplen las condiciones de activación, no se generará una señal DENM.
12.2.Condiciones de activación
12.2.1.Condiciones previas
177)Se ha recibido un IRC según se describe en el cuadro 23.
12.2.2.Condiciones específicas del servicio
178)Si se satisface la condición previa del punto 177 y las dos condiciones siguientes, se cumplen las condiciones de activación de este servicio STI-C, por lo que deberá activarse la generación de un DENM:
a)El valor requestResponseIndication en el IRC recibido se ajustará en request(0);
b)la distancia perpendicular entre el vehículo peticionario (posición del evento en el IRC) y el vehículo ego (posición de referencia tal como se define en el CAM) es inferior a 100 m.
Nota: Cuando se recibe un IRC, el receptor debe comprobar que se le pidió realmente, antes de responder con su propio IRC. Esto puede hacerse basándose en el valor requestResponseIndication. Para evitar una carga innecesaria en el canal de transmisión debido a múltiples IRC transmitidos, solo responden a la petición los vehículos que se encuentren en las inmediaciones (en un radio de 100 m).
12.2.3.Calidad de la información
179)El valor del elemento de datos informationQuality en el DENM depende de cómo se detecte el evento. El valor informationQuality se fijará de acuerdo con el cuadro que figura a continuación (se utilizará el valor más elevado posible).
Cuadro 24: Calidad de la información del servicio «intercambio de IRC: IRC de respuesta»
|
Detección del evento
|
Valor informationQuality
|
|
Ninguna aplicación conforme con TRCO
|
unknown(0)
|
|
En los demás casos
|
1
|
12.3.Condiciones de terminación
180)No se planteará una terminación del servicio STI-C.
12.3.1.Cancelación
181)Para este servicio STI-C no se utilizará un DENM de cancelación.
12.3.2.Negación
182)Para este servicio STI-C no se utilizará un DENM de negación.
12.4.Actualización
183)Para este servicio STI-C no se utilizará un DENM de actualización.
12.5.Duración de la repetición e intervalo entre repeticiones
184)Se repetirán DENM nuevos durante un valor repetitionDuration de 300 ms (100 ms tres veces seguidas) con un valor repetitionInterval de 100 ms. Así pues, los parámetros de interfaz duración de la repetición e intervalo entre repeticiones entre la aplicación y el servicio básico de DEN se ajustarán de acuerdo con los valores anteriores.
Nota: Como no está garantizado que un IRC enviado llegue al receptor (por ejemplo, debido a la carga del canal, a la salida temporal del radio de acción, etc.), el emisor envía el IRC tres veces seguidas. Esto equivale a un valor repetitionDuration de 300 ms.
Nota: La duración estimada para transmitir (de aplicación a aplicación) un IRC (sin incluir la repetición) a través de una WLAN de automoción es de 200300 ms. Si la recepción se consigue solo al tercer intento (caso más desfavorable), en ambos casos (petición y respuesta), la información estará disponible para los dos vehículos después de 1 s (2 * [300 ms + 100 ms (@10 Hz) + 100 ms (@10 Hz)]). Por lo tanto, el parámetro de activación TTC < 1,5 s es suficiente. El envío de los IRC tres veces seguidas se considera un buen compromiso entre cargar el canal y garantizar una transmisión eficaz.
Nota: Solo el primer DENM se enviará sin limitaciones del DCC. El segundo y el tercer DENM pueden verse afectados por el DCC (en función de la actual carga del canal).
Nota: Cuando dos DENM con el mismo causeCode procedan de la misma estación STI-C, el caso será gestionado por la estación STI-C receptora.
12.6.Clase de tráfico
185)Los DENM nuevos se ajustarán en la clase de tráfico 0.
12.7.Parámetros del mensaje
12.7.1.DENM
186)El siguiente cuadro especifica los elementos de datos del DENM que se establecerán.
Cuadro 25: Elementos de datos del DENM en el servicio «intercambio de IRC: IRC de respuesta»
|
Campo de datos
|
Valor
|
|
Management container
|
|
actionID
|
Identificador de un DENM. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
detectionTime
|
TimestampIts: sello de tiempo en el que el evento es detectado por la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
referenceTime
|
TimestampIts: sello de tiempo en el que se genera un DENM nuevo. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
termination
|
No se establecerá, pues en este servicio STI-C no se utilizarán ni negación ni cancelación.
|
|
eventPosition
|
ReferencePosition. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
relevanceDistance
|
lessThan100m(1)
|
|
relevanceTrafficDirection
|
allTrafficDirections(0)
|
|
validityDuration
|
2 s
|
|
stationType
|
El tipo de estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
Situation container
|
|
informationQuality
|
Véase el punto 179.
|
|
causeCode
|
collisionRisk(97)
|
|
subCauseCode
|
unavailable(0)
|
|
Location container
|
|
eventSpeed
|
Velocidad de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
eventPositionHeading
|
Rumbo de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
traces
|
PathHistory de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
roadType
|
Se fijará de acuerdo con la norma [TS 102 894-2]. Si no puede determinarse la información sobre la situación urbana o no urbana, se omitirá el elemento de datos.
|
|
Alacarte container: ImpactReductionContainer
|
|
heightLonCarrLeft
|
Altura del soporte longitudinal izquierdo del vehículo, desde la base hasta la parte superior. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
heightLonCarrRight
|
Altura del soporte longitudinal derecho del vehículo, desde la base hasta la parte superior. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
posLonCarrLeft
|
Distancia longitudinal desde el centro del parachoques delantero hasta la parte delantera del soporte longitudinal izquierdo del vehículo. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
posLonCarrRight
|
Distancia longitudinal desde el centro del parachoques delantero hasta la parte delantera del soporte longitudinal derecho del vehículo. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
positionOfPillars
|
Los montantes del vehículo son los soportes verticales o cuasiverticales de un vehículo, denominados, respectivamente, A, B, C o D. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
posCentMass
|
Distancia perpendicular desde el centro de la masa de un vehículo sin carga hasta la línea delantera de la caja envolvente del vehículo. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
wheelBaseVehicle
|
Distancia perpendicular entre el eje delantero y el eje trasero de la batalla del vehículo. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
turningRadius
|
Viraje circular más pequeño (es decir, viraje en U) que el vehículo puede realizar. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
posFrontAx
|
Distancia perpendicular entre la línea delantera del vehículo de la caja envolvente y el eje de ruedas delantero. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
positionOfOccupants
|
Cadena de bits que indica si un asiento de pasajero está ocupado o si el estado de ocupación es detectable. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
vehicleMass
|
Masa de un vehículo sin carga. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
requestResponseIndication
|
response(1)
|
12.7.2.CAM
187)No se utilizará la adaptación de CAM para este servicio STI-C.
12.8.Capa de red y de transporte
188)El parámetro de interfaz DENM destination area entre el servicio básico de DEN y la capa de red y de transporte será igual a una forma circular con un radio equivalente al valor relevanceDistance.
12.9.Capa de seguridad
189)Si se cumplen las condiciones de activación según se describen en el punto 178, se bloqueará un cambio de AT mientras no haya expirado el valor validityDuration. Los DENM nuevos correspondientes se enviarán con el mismo AT.
13.Situación peligrosa: luz de frenado de emergencia electrónica
13.1.Descripción del servicio STI-C
Este servicio STI-C transmite información V2V relativa a un frenado de emergencia realizado por el conductor al reaccionar, por ejemplo, ante un vehículo parado o más lento que circula por delante. El propio vehículo ego se convierte en una posible zona de peligro local.
Los siguientes servicios STI-C guardan relación con este servicio, pues comparten condiciones de activación similares:
·«situaciones peligrosas: intervención automática de los frenos»;
·«situaciones peligrosas: intervención del sistema de retención de los ocupantes reversible».
13.2.Condiciones de activación
13.2.1.Condiciones previas
190)Para este servicio STI-C no se aplican condiciones previas específicas.
191)Se evitará la activación paralela con los demás servicios STI-C relacionados. Cuando los servicios STI-C «intervención automática de los frenos» o «intervención del sistema de retención de los ocupantes reversible» se activen al mismo tiempo, la prioridad será como sigue:
a)«luz de frenado de emergencia electrónica» (prioridad máxima);
b)«intervención automática de los frenos»;
c)«intervención del sistema de retención de los ocupantes reversible» (prioridad mínima).
192)Si se activa un servicio STI-C de mayor prioridad, deberá abortarse toda transmisión relacionada de un servicio STI-C de menor prioridad que ya se haya activado y siga activa con respecto a la actualización. Además, se pedirá la generación de un DENM nuevo para el servicio STI-C de mayor prioridad.
13.2.2.Condiciones específicas del servicio
193)Si se satisface la condición siguiente, se cumplen las condiciones de activación de este servicio STI-C, por lo que deberá activarse la generación de un DENM:
a)se detecta una señal que representa la petición de luz de frenado de emergencia electrónica. Las condiciones para tal petición se establecen en los reglamentos [CEPE 48], [CEPE 13] y [CEPE 13H].
Los vehículos también podrán utilizar la siguiente condición de activación alternativa:
b)la velocidad actual del vehículo es superior a 20 km/h y la aceleración actual es inferior a - 7 m/s² durante un mínimo de 500 ms.
194)La aceleración del vehículo será determinada por la señal de buses de este, no por GNSS. Se utilizará la aceleración filtrada con respecto al ruido del sensor.
13.2.3.Calidad de la información
195)El valor del elemento de datos informationQuality en el DENM depende de cómo se detecte el evento (véase el punto 193). El valor informationQuality se fijará de acuerdo con el cuadro que figura a continuación (se utilizará el valor más elevado posible).
Cuadro 26: Calidad de la información del servicio «luz de frenado de emergencia electrónica»
|
Detección del evento
|
Valor informationQuality
|
|
Ninguna aplicación conforme con TRCO
|
0
|
|
Se cumple la condición a).
|
1
|
|
Se cumple la condición a) y la aceleración longitudinal filtrada actual del vehículo es < - 4 m/s2
|
2
|
|
Se cumple la condición b).
|
3
|
196)Si las condiciones de activación cambian entre dos actualizaciones, el valor informationQuality no cambiará hasta la próxima actualización. Si, mientras se actualiza el DENM, se siguen cumpliendo las condiciones modificadas, se actualizará el valor informationQuality.
13.3.Condiciones de terminación
197)El servicio STI-C terminará cuando dejen de ser válidas las condiciones a) o b). Al término del servicio STI-C se pondrá fin a la petición de un DENM de actualización.
13.3.1.Cancelación
198)Para este servicio STI-C no se utilizará un DENM de cancelación.
13.3.2.Negación
199)Para este servicio STI-C no se utilizará un DENM de negación.
13.4.Actualización
200)El DENM generado se actualizará cada 100 ms si se siguen cumpliendo las condiciones de activación. Todos los campos de datos a los que se asignan valores nuevos se definen en el cuadro 27.
13.5.Duración de la repetición e intervalo entre repeticiones
201)No se repetirá el DENM para este servicio STI-C.
13.6.Clase de tráfico
202)Los DENM nuevos y de actualización se ajustarán en la clase de tráfico 0.
13.7.Parámetros del mensaje
13.7.1.DENM
203)El siguiente cuadro especifica los elementos de datos del DENM que se establecerán.
Cuadro 27: Elementos de datos del DENM en el servicio «luz de frenado de emergencia electrónica»
|
Campo de datos
|
Valor
|
|
Management container
|
|
actionID
|
Identificador de un DENM. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
detectionTime
|
TimestampIts: sello de tiempo en el que el evento es detectado por la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para un DENM de actualización.
|
|
referenceTime
|
TimestampIts: sello de tiempo en el que se genera un DENM nuevo o de actualización. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
termination
|
No se establecerá, pues en este servicio STI-C no se utilizarán ni negación ni cancelación.
|
|
eventPosition
|
ReferencePosition. Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para cada DENM de actualización.
|
|
relevanceDistance
|
lessThan500m(3)
|
|
relevanceTrafficDirection
|
Si se conoce el valor roadType, el valor se fijará como sigue:
|
|
|
RoadType
|
Dirección
|
|
|
0
|
allTrafficDirections(0)
|
|
|
1
|
upstreamTraffic(1)
|
|
|
2
|
allTrafficDirections(0)
|
|
|
3
|
upstreamTraffic(1)
|
|
|
De lo contrario, el valor se fijará en allTrafficDirections(0).
|
|
validityDuration
|
2 s
|
|
stationType
|
El tipo de estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
Situation container
|
|
informationQuality
|
Véase el punto 195.
|
|
causeCode
|
dangerousSituation(99)
|
|
subCauseCode
|
emergencyElectronicBrakeEngaged(1)
|
|
Location container
|
|
eventSpeed
|
Velocidad de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para un DENM de actualización.
|
|
eventPositionHeading
|
Rumbo de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para un DENM de actualización.
|
|
traces
|
PathHistory de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para un DENM de actualización.
|
|
roadType
|
RoadType de la carretera en la que está situada la estación STI-C detectora.
Se actualizará para un DENM de actualización.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2] en combinación con las siguientes reglas:
|
|
|
Urbana / No urbana
|
Separación estructural
|
Elemento de datos
|
|
|
Urbana
|
No
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
Urbana
|
Sí
|
urban-WithStructuralSeparation ToOppositeLanes(1)
|
|
|
Urbana
|
Desconocido
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
No urbana
|
No
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
No urbana
|
Sí
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
|
|
|
No urbana
|
Desconocido
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
Si no puede determinarse la información sobre la situación urbana o no urbana, se omitirá el elemento de datos.
|
|
Alacarte container
|
|
lanePosition
|
Si el valor lanePosition es suministrado por un sensor de a bordo (por ejemplo, un radar o una cámara), se fijará de acuerdo con la norma [TS 102 894-2]. Con esta versión de la condición de activación, no es lícito utilizar un GNSS y un mapa digital para calcular el número de carril.
Si se desconoce el valor lanePosition, se omitirá el elemento de datos.
Se actualizará para un DENM de actualización.
|
13.7.2.CAM
204)No se utilizará la adaptación de CAM para este servicio STI-C.
13.8.Capa de red y de transporte
205)El parámetro de interfaz DENM destination area entre el servicio básico de DEN y la capa de red y de transporte será igual a una forma circular con un radio equivalente al valor relevanceDistance.
13.9.Capa de seguridad
206)Si se cumplen las condiciones de activación según se describen en el punto 193, se bloqueará un cambio de AT para DENM nuevos y de actualización mientras no haya expirado el valor validityDuration. Los DENM nuevos y de actualización correspondientes se enviarán con el mismo AT.
14.Situación peligrosa: intervención automática de los frenos
14.1.Descripción del servicio STI-C
Este servicio STI-C transmite información V2V relativa a una intervención autónoma del frenado de emergencia realizada por el vehículo. El propio vehículo ego se convierte en una posible zona de peligro local.
Los siguientes servicios STI-C guardan relación con este servicio, pues comparten condiciones de activación similares:
·«situaciones peligrosas: luz de frenado de emergencia electrónica»;
·«situaciones peligrosas: intervención del sistema de retención de los ocupantes reversible».
14.2.Condiciones de activación
14.2.1.Condiciones previas
207)Para este servicio STI-C no se aplican condiciones previas específicas.
208)Se evitará la activación paralela con los demás servicios STI-C relacionados. Cuando los servicios STI-C «luz de frenado de emergencia electrónica» o «intervención del sistema de retención de los ocupantes reversible» se activen al mismo tiempo, la prioridad será como sigue:
a)«luz de frenado de emergencia electrónica» (prioridad máxima);
b)«intervención automática de los frenos»;
c)«intervención del sistema de retención de los ocupantes reversible» (prioridad mínima).
209)Si se activa un servicio STI-C de mayor prioridad, deberá abortarse toda transmisión relacionada de un servicio STI-C de menor prioridad que ya se haya activado y siga activa con respecto a la actualización. Además, se pedirá la generación de un DENM nuevo para el servicio STI-C de mayor prioridad.
14.2.2.Condiciones específicas del servicio
210)Si se satisface la condición siguiente, se cumplen las condiciones de activación de este servicio STI-C, por lo que deberá activarse la generación de un DENM:
a)se detecta una señal que representa la petición de intervención del sistema de frenado de emergencia autónomo.
211)La aceleración del vehículo será determinada por la señal de buses de este, no por GNSS. Se utilizará la aceleración filtrada con respecto al ruido del sensor.
14.2.3.Calidad de la información
212)El valor del elemento de datos informationQuality en el DENM depende de cómo se detecte el evento (véase el punto 210). El valor informationQuality se fijará de acuerdo con el cuadro que figura a continuación (se utilizará el valor más elevado posible).
Cuadro 28: Calidad de la información del servicio «intervención automática de los frenos»
|
Detección del evento
|
Valor informationQuality
|
|
Ninguna aplicación conforme con TRCO
|
0
|
|
Se cumple la condición a).
|
1
|
|
Se cumple la condición a) y la aceleración longitudinal filtrada actual del vehículo es < - 4 m/s2
|
2
|
213)Si las condiciones de activación cambian entre dos actualizaciones, el valor informationQuality no cambiará hasta la próxima actualización. Si, mientras se actualiza el DENM, se siguen cumpliendo las condiciones modificadas, se actualizará el valor informationQuality.
14.3.Condiciones de terminación
214)El servicio STI-C terminará cuando deje de ser válida la condición a). Al término del servicio STI-C se pondrá fin a la petición de un DENM de actualización.
14.3.1.Cancelación
215)Para este servicio STI-C no se utilizará un DENM de cancelación.
14.3.2.Negación
216)Para este servicio STI-C no se utilizará un DENM de negación.
14.4.Actualización
217)El DENM generado se actualizará cada 100 ms si se siguen cumpliendo las condiciones de activación. Los campos de datos a los que se asignan valores nuevos se definen en el cuadro 29.
14.5.Duración de la repetición e intervalo entre repeticiones
218)No se repetirá el DENM para este servicio STI-C.
14.6.Clase de tráfico
219)Los DENM nuevos y de actualización se ajustarán en la clase de tráfico 0.
14.7.Parámetros del mensaje
14.7.1.DENM
220)El siguiente cuadro especifica los elementos de datos del DENM que se establecerán.
Cuadro 29: Elementos de datos del DENM en el servicio «intervención automática de los frenos»
|
Campo de datos
|
Valor
|
|
Management container
|
|
actionID
|
Identificador de un DENM. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
detectionTime
|
TimestampIts: sello de tiempo en el que el evento es detectado por la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para un DENM de actualización.
|
|
referenceTime
|
TimestampIts: sello de tiempo en el que se genera un DENM nuevo o de actualización. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
termination
|
No se establecerá, pues en este servicio STI-C no se utilizarán ni negación ni cancelación.
|
|
eventPosition
|
ReferencePosition. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para cada DENM de actualización.
|
|
relevanceDistance
|
lessThan500m(3)
|
|
relevanceTrafficDirection
|
Si se conoce el valor roadType, el valor se fijará como sigue:
|
|
|
RoadType
|
Dirección
|
|
|
0
|
allTrafficDirections(0)
|
|
|
1
|
upstreamTraffic(1)
|
|
|
2
|
allTrafficDirections(0)
|
|
|
3
|
upstreamTraffic(1)
|
|
|
De lo contrario, el valor se fijará en allTrafficDirections(0).
|
|
validityDuration
|
2 s
|
|
stationType
|
El tipo de estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
Situation container
|
|
informationQuality
|
Véase el punto 212.
|
|
causeCode
|
dangerousSituation(99)
|
|
subCauseCode
|
aebEngaged(5)
|
|
Location container
|
|
eventSpeed
|
Velocidad de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para un DENM de actualización.
|
|
eventPositionHeading
|
Rumbo de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para un DENM de actualización.
|
|
traces
|
PathHistory de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para un DENM de actualización.
|
|
roadType
|
RoadType de la carretera en la que está situada la estación STI-C detectora.
Se actualizará para un DENM de actualización.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2] en combinación con las siguientes reglas:
|
|
|
Urbana / No urbana
|
Separación estructural
|
Elemento de datos
|
|
|
Urbana
|
No
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
Urbana
|
Sí
|
urban-WithStructuralSeparation ToOppositeLanes(1)
|
|
|
Urbana
|
Desconocido
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
No urbana
|
No
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
No urbana
|
Sí
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
|
|
|
No urbana
|
Desconocido
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
Si no puede determinarse la información sobre la situación urbana o no urbana, se omitirá el elemento de datos.
|
|
Alacarte container
|
|
lanePosition
|
Si el valor lanePosition es suministrado por un sensor de a bordo (por ejemplo, un radar o una cámara), se fijará de acuerdo con la norma [TS 102 894-2]. Con esta versión de la condición de activación, no es lícito utilizar un GNSS y un mapa digital para calcular el número de carril.
Si se desconoce el valor lanePosition, se omitirá el elemento de datos.
Se actualizará para un DENM de actualización.
|
14.7.2.CAM
221)No se utilizará la adaptación de CAM para este servicio STI-C.
14.8.Capa de red y de transporte
222)El parámetro de interfaz DENM destination area entre el servicio básico de DEN y la capa de red y de transporte será igual a una forma circular con un radio equivalente al valor relevanceDistance.
14.9.Capa de seguridad
223)Si se cumplen las condiciones de activación según se describen en el punto 210, se bloqueará un cambio de AT para DENM nuevos y de actualización mientras no haya expirado el valor validityDuration. Los DENM nuevos y de actualización correspondientes se enviarán con el mismo AT.
15.Situación peligrosa: intervención del sistema de retención de los ocupantes reversible
15.1.Descripción del servicio STI-C
Este servicio STI-C transmite información V2V relativa a la intervención activa de un sistema de retención de los ocupantes reversible (por ejemplo, pretensor del cinturón de seguridad reversible) en el vehículo ego, debido a una situación de circulación crítica.
Los siguientes servicios STI-C guardan relación con este servicio, pues comparten condiciones de activación similares:
·«situaciones peligrosas: luz de frenado de emergencia electrónica»;
·«situaciones peligrosas: intervención automática de los frenos».
15.2.Condición de activación
15.2.1.Condiciones previas
224)Para este servicio STI-C no se aplican condiciones previas específicas.
225)Se evitará la activación paralela con los demás servicios STI-C relacionados. Cuando los servicios STI-C «luz de frenado de emergencia electrónica» o «intervención automática de los frenos» se activen al mismo tiempo, la prioridad será como sigue:
a)«luz de frenado de emergencia electrónica» (prioridad máxima);
b)«intervención automática de los frenos»;
c)«intervención del sistema de retención de los ocupantes reversible» (prioridad mínima).
226)Si se activa un servicio STI-C de mayor prioridad, deberá abortarse toda transmisión relacionada de un servicio STI-C de menor prioridad que ya se haya activado y siga activa con respecto a la actualización. Además, se pedirá la generación de un DENM nuevo para el servicio STI-C de mayor prioridad.
15.2.2.Condiciones específicas del servicio
227)Si se cumple la condición siguiente, deberá activarse la generación de un DENM:
a)se detecta una señal que representa la petición de una intervención activa de un sistema de retención de los ocupantes reversible (por ejemplo, pretensor del cinturón de seguridad reversible) debido a una situación de circulación crítica.
15.2.3.Calidad de la información
228)El valor del elemento de datos informationQuality en el DENM depende de cómo se detecte el evento (véase el punto 227). El valor informationQuality se fijará de acuerdo con el cuadro que figura a continuación (se utilizará el valor más elevado posible).
Cuadro 30: Calidad de la información del servicio «intervención del sistema de retención de los ocupantes reversible»
|
Detección del evento
|
Valor informationQuality
|
|
Ninguna aplicación conforme con TRCO
|
0
|
|
Se cumple la condición a).
|
1
|
|
Se cumple la condición a) y la aceleración longitudinal filtrada actual del vehículo es < - 4 m/s2
|
2
|
229)Si las condiciones de activación cambian entre dos actualizaciones, el valor informationQuality no cambiará hasta la próxima actualización. Si, mientras se actualiza el DENM, se siguen cumpliendo las condiciones modificadas, se actualizará el valor informationQuality.
15.3.Condiciones de terminación
230)El servicio STI-C terminará cuando deje de ser válida la condición a). Al término del servicio STI-C se pondrá fin a la petición de un DENM de actualización.
15.3.1.Cancelación
231)Para este servicio STI-C no se utilizará un DENM de cancelación.
15.3.2.Negación
232)Para este servicio STI-C no se utilizará un DENM de negación.
15.4.Actualización
233)El DENM generado se actualizará cada 100 ms si se siguen cumpliendo las condiciones de activación. Todos los campos de datos a los que se asignan valores nuevos se definen en el cuadro 31.
15.5.Duración de la repetición e intervalo entre repeticiones
234)No se repetirá el DENM para este servicio STI-C.
15.6.Clase de tráfico
235)Los DENM nuevos y de actualización se ajustarán en la clase de tráfico 0.
15.7.Parámetros del mensaje
15.7.1.DENM
236)El siguiente cuadro especifica los elementos de datos del DENM que se establecerán.
Cuadro 31: Elementos de datos del DENM en el servicio «intervención del sistema de retención de los ocupantes reversible»
|
Campo de datos
|
Valor
|
|
Management container
|
|
actionID
|
Identificador de un DENM. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
detectionTime
|
TimestampIts: sello de tiempo en el que el evento es detectado por la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para un DENM de actualización.
|
|
referenceTime
|
TimestampIts: sello de tiempo en el que se genera un DENM nuevo o de actualización. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
termination
|
No se establecerá, pues en este servicio STI-C no se utilizarán ni negación ni cancelación.
|
|
eventPosition
|
ReferencePosition. Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para cada DENM de actualización.
|
|
relevanceDistance
|
lessThan500m(3)
|
|
relevanceTrafficDirection
|
Si se conoce el valor roadType, el valor se fijará como sigue:
|
|
|
RoadType
|
Dirección
|
|
|
0
|
allTrafficDirections(0)
|
|
|
1
|
upstreamTraffic(1)
|
|
|
2
|
allTrafficDirections(0)
|
|
|
3
|
upstreamTraffic(1)
|
|
|
De lo contrario, el valor se fijará en allTrafficDirections(0).
|
|
validityDuration
|
2 s
|
|
stationType
|
El tipo de estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
Situation container
|
|
informationQuality
|
Véase el punto 228.
|
|
causeCode
|
dangerousSituation(99)
|
|
subCauseCode
|
preCrashSystemEngaged(2)
|
|
Location container
|
|
eventSpeed
|
Velocidad de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para un DENM de actualización.
|
|
eventPositionHeading
|
Rumbo de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para un DENM de actualización.
|
|
traces
|
PathHistory de la estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para un DENM de actualización.
|
|
roadType
|
RoadType de la carretera en la que está situada la estación STI-C detectora.
Se actualizará para un DENM de actualización.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2] en combinación con las siguientes reglas:
|
|
|
Urbana / No urbana
|
Separación estructural
|
Elemento de datos
|
|
|
Urbana
|
No
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
Urbana
|
Sí
|
urban-WithStructuralSeparation ToOppositeLanes(1)
|
|
|
Urbana
|
Desconocido
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
No urbana
|
No
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
No urbana
|
Sí
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
|
|
|
No urbana
|
Desconocido
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
Si no puede determinarse la información sobre la situación urbana o no urbana, se omitirá el elemento de datos.
|
|
Alacarte container
|
|
lanePosition
|
Si el valor lanePosition es suministrado por un sensor de a bordo (por ejemplo, un radar o una cámara), se fijará de acuerdo con la norma [TS 102 894-2]. Con esta versión de la condición de activación, no es lícito utilizar un GNSS y un mapa digital para calcular el número de carril.
Si se desconoce el valor lanePosition, se omitirá el elemento de datos.
Se actualizará para un DENM de actualización.
|
15.7.2.CAM
237)No se utilizará la adaptación de CAM para este servicio STI-C.
15.8.Capa de red y de transporte
238)El parámetro de interfaz DENM destination area entre el servicio básico de DEN y la capa de red y de transporte será igual a una forma circular con un radio equivalente al valor relevanceDistance.
15.9.Capa de seguridad
239)Si se cumplen las condiciones de activación según se describen en el punto 227, se bloqueará un cambio de AT para DENM nuevos y de actualización mientras no haya expirado el valor validityDuration. Los DENM nuevos y de actualización correspondientes se enviarán con el mismo AT.
16.Condiciones meteorológicas adversas: niebla
16.1.Descripción del servicio STI-C
Este servicio STI-C transmite información V2V relativa a la niebla que puede restar visibilidad al conductor.
Los siguientes servicios STI-C guardan relación con este servicio, pues comparten condiciones de activación similares:
·«condiciones meteorológicas adversas: precipitación».
240)Solo se enviará una señal DENM a la memoria temporal si se evalúa que las condiciones de activación descritas en el presente epígrafe son válidas. Esa señal hace que la memoria temporal genere un DENM nuevo o de actualización Si no se cumplen las condiciones de activación, no se generará una señal DENM.
16.2.Condiciones de activación
16.2.1.Condiciones previas
241)Antes de que se active este servicio STI-C, deberán satisfacerse las condiciones previas siguientes:
a)la velocidad del vehículo es superior a 7 km/h;
b)la velocidad del vehículo es inferior a 80 km/h.
242)La velocidad del vehículo será determinada por la señal de buses de este, no por GNSS. Se utilizará la velocidad filtrada del vehículo (con respecto al ruido del sensor).
16.2.2.Condiciones específicas del servicio
243)Si se satisfacen las condiciones previas del punto 241 y al menos una de las condiciones siguientes, se cumplen las condiciones de activación de este servicio STI-C, por lo que deberá activarse la generación de un DENM:
1)reacción del conductor y estado de las luces:
a)el conductor enciende la luz antiniebla trasera y la luz de cruce está encendida; estas condiciones deben ser válidas durante más de 20 s (para minimizar el riesgo de uso indebido por el conductor, las condiciones han de ser válidas durante un período más largo);
b)el conductor enciende la luz antiniebla trasera, la luz de cruce está encendida y la velocidad del vehículo es inferior a 60 km/h; estas condiciones deben ser válidas durante más de 20 s;
2)dispositivo medidor de la visibilidad:
a)la visibilidad, debido a la niebla, es de menos de 80 m, con una tolerancia de ± 40 m, durante más de 5 s (la visión oscurecida debe detectarse durante un período razonable; el período es más corto que el de las condiciones a) y b), merced a una información más fiable);
b)la visibilidad, debido a la niebla, es de menos de 80 m, con una tolerancia de ± 40 m, y la velocidad del vehículo es inferior a 60 km/h (si el vehículo se encuentra en una zona no urbana, esta velocidad podría ser indicio de una visibilidad reducida) durante más de 5 s.
244)No se generará un DENM nuevo o de actualización durante el tiempo de bloqueo de la detección. El tiempo de bloqueo de la detección se pone en marcha una vez que se ha detectado el evento y se ha activado un DENM al efecto. De este modo, un único evento no es capaz de activar una serie de DENM. En el caso del dispositivo medidor de la visibilidad [condiciones c) y d)], el tiempo de bloqueo de la detección será de 15 s. Con respecto a las demás condiciones, no habrá tiempo de bloqueo de la detección.
245)A fin de garantizar un comportamiento funcional coherente para las diferentes condiciones de activación y el tiempo de bloqueo de la detección, el intervalo mínimo de detección entre dos eventos detectados será de 20 s.
16.2.3.Calidad de la información
246)El valor del elemento de datos informationQuality en el DENM depende de cómo se detecte el evento (véase el punto 243). El valor informationQuality se fijará de acuerdo con el cuadro que figura a continuación (se utilizará el valor más elevado posible).
Cuadro 32: Calidad de la información del servicio «condición meteorológica adversa: niebla»
|
Detección del evento
|
Valor informationQuality
|
|
Ninguna aplicación conforme con TRCO
|
unknown(0)
|
|
Se cumple la condición a).
|
1
|
|
Se cumple la condición b).
|
2
|
|
Se cumple la condición c).
|
3
|
|
Se cumple la condición d).
|
4
|
247)Si las condiciones de activación cambian entre dos actualizaciones, el valor informationQuality no cambiará hasta la próxima actualización. Si, mientras se actualiza el DENM, se siguen cumpliendo las condiciones modificadas, se actualizará el valor informationQuality.
16.3.Condiciones de terminación
248)No se planteará una terminación del servicio STI-C.
16.3.1.Cancelación
249)Para este servicio STI-C no se utilizará un DENM de cancelación.
16.3.2.Negación
250)Para este servicio STI-C no se utilizará un DENM de negación.
16.4.Actualización
251)El procedimiento adecuado de actualización del DENM se determinará en función de las siguientes condiciones:
a)después del intervalo mínimo de detección especificado en el epígrafe 16.2.2 se cumple al menos una de las condiciones del punto 243;
b)el valor validityDuration del DENM anterior no ha expirado;
c)ni el valor del elemento de datos DeltaLatitude ni el del elemento de datos DeltaLongitude, que representan la distancia entre el evento detectado actual y el evento detectado anterior, superan el umbral que pueden cubrir los elementos de datos DeltaLatitude y DeltaLongitude.
252)Si se cumplen las condiciones a), b) y c) especificadas en el punto 251, deberá generarse un DENM de actualización. La información de los elementos de datos del DENM anterior (eventPosition, eventDeltaTime, informationQuality) deberá almacenarse en el eventHistory como eventPoint adicional.
Los puntos de evento se ordenarán en orden ascendente con respecto a su vida útil, con el eventPoint más reciente en primera posición. Los puntos de evento del eventHistory con vidas útiles que excedan del valor validityDuration se borrarán del eventHistory con respecto al DENM de actualización. Si la distancia recorrida por el eventHistory supera el umbral permitido por la seguridad, se borrarán del eventHistory los puntos de evento más antiguos.
La información del evento detectado actual se asignará a los campos de datos del DENM actualizado.
Nota: Después de haberse generado el DENM de actualización, corresponde al receptor ocuparse de los puntos de evento con vidas útiles que superan el valor validityDuration.
253)Si se cumplen las condiciones a) y b), pero no la condición c), no deberá generarse un DENM de actualización. En su lugar, deberá generarse un DENM nuevo adicional. La información del evento detectado actual se asignará a los campos de datos del DENM nuevo adicional. El DENM anterior seguirá transmitiéndose mientras no expire el valor repetitionDuration del DENM anterior.
254)Si se cumple la condición a), pero no la condición b), no deberá generarse un DENM de actualización, sino un DENM nuevo de acuerdo con el evento detectado en ese momento.
Nota: En este caso, la transmisión del DENM anterior ya ha terminado, puesto que el valor repetitionDuration del DENM anterior ha expirado.
255)Si no se cumple la condición a), no es necesaria la generación de un DENM de actualización.
16.5.Duración de la repetición e intervalo entre repeticiones
256)Los DENM que sean nuevos o hayan sido actualizados se repetirán durante un valor repetitionDuration de 180 s con un valor repetitionInterval de 4 s. Así pues, los parámetros de interfaz duración de la repetición e intervalo entre repeticiones entre la aplicación y el servicio básico de DEN se ajustarán de acuerdo con los valores anteriores.
Nota: El valor validityDuration se ajusta en 300 s. Por lo tanto, puede evitarse una laguna de DENM si el valor repetitionDuration del DENM original ha expirado y la actualización aún no se ha recibido.
Nota: Cuando dos DENM con el mismo causeCode procedan de la misma estación STI-C, el caso será gestionado por la estación STI-C receptora.
16.6.Clase de tráfico
257)Los DENM nuevos y de actualización se ajustarán en la clase de tráfico 1.
16.7.Parámetros del mensaje
16.7.1.DENM
258)El siguiente cuadro especifica los elementos de datos del DENM que se establecerán.
Cuadro 33: Elementos de datos del DENM en el servicio «condición meteorológica adversa: niebla»
|
Campo de datos
|
Valor
|
|
Management container
|
|
actionID
|
Identificador de un DENM. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
detectionTime
|
TimestampIts: sello de tiempo en el que el evento es detectado por la estación STI-C de origen. El sello de tiempo refleja el inicio de la detección del evento actual. Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para un DENM de actualización y se ajustará en la hora de detección del evento actual.
|
|
referenceTime
|
TimestampIts: sello de tiempo en el que se genera un DENM nuevo o de actualización. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
termination
|
No se establecerá, pues en este servicio STI-C no se utilizarán ni negación ni cancelación.
|
|
eventPosition
|
ReferencePosition. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización.
|
|
relevanceDistance
|
·DENM nuevo: lessThan1000m(4)
·DENM de actualización: lessThan5km(5) (al utilizar actualizaciones, la distancia recorrida por el eventHistory se hace más larga; a fin de cubrir todas las estaciones STI pertinentes, el valor relevanceDistance es mayor en este caso).
|
|
relevanceTrafficDirection
|
allTrafficDirections(0)
|
|
validityDuration
|
300 s
|
|
stationType
|
El tipo de estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
Situation container
|
|
informationQuality
|
Véase el punto 246. Se actualizará para cada DENM de actualización y se ajustará en el valor informationQuality del evento actual.
|
|
causeCode
|
adverseWeatherCondition-Visibility(18)
|
|
subCauseCode
|
unavailable(0) o fog(1)
|
|
eventHistory
|
Este elemento se utilizará únicamente para DENM de actualización (véase el epígrafe 16.4).
|
|
Location container
|
|
traces
|
PathHistory de la estación STI-C de origen, con referencia al punto de evento actual.
Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para un DENM de actualización.
|
|
roadType
|
RoadType de la carretera en la que está situada la estación STI-C detectora.
|
|
|
Se actualizará para un DENM de actualización.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2] en combinación con las siguientes reglas:
|
|
|
Urbana / No urbana
|
Separación estructural
|
Elemento de datos
|
|
|
Urbana
|
No
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
Urbana
|
Sí
|
urban-WithStructuralSeparation ToOppositeLanes(1)
|
|
|
Urbana
|
Desconocido
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
No urbana
|
No
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
No urbana
|
Sí
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
|
|
|
No urbana
|
Desconocido
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
Si no puede determinarse la información sobre la situación urbana o no urbana, se omitirá el elemento de datos.
|
16.7.2.CAM
259)No se utilizará la adaptación de CAM para este servicio STI-C.
16.8.Capa de red y de transporte
260)El parámetro de interfaz DENM destination area entre el servicio básico de DEN y la capa de red y de transporte será igual a una forma circular con un radio equivalente al valor relevanceDistance.
16.9.Capa de seguridad
261)Si se cumplen las condiciones de activación según se describen en el punto 243, se bloqueará un cambio de AT para DENM nuevos y de actualización durante quince minutos (contados desde el momento en que se genera el DENM nuevo). Los DENM nuevos y de actualización correspondientes se enviarán con el mismo AT.
262)Si el AT cambia y hay una transmisión activa de DENM (DENM nuevo o de actualización), deberá detenerse la transmisión. Además, se borrarán el EventHistory y el PathHistory. Luego continuará el proceso normal de generación de DENM.
17.Condiciones meteorológicas adversas: precipitación
17.1.Descripción del servicio STI-C
Este servicio STI-C transmite información V2V relativa a una precipitación que puede restar visibilidad al conductor.
Los siguientes servicios STI-C guardan relación con este servicio, pues comparten condiciones de activación similares:
·«condiciones meteorológicas adversas: niebla».
263)Solo se enviará una señal DENM a la memoria temporal si se evalúa que las condiciones de activación descritas en el presente epígrafe son válidas. Esa señal hace que la memoria temporal genere un DENM nuevo o de actualización Si no se cumplen las condiciones de activación, no se generará una señal DENM.
17.2.Condiciones de activación
17.2.1.Condiciones previas
264)Antes de que se active este servicio STI-C, deberán satisfacerse las condiciones previas siguientes:
a)la velocidad del vehículo es superior a 7 km/h;
b)la velocidad del vehículo es inferior a 80 km/h;
c)la función lavaparabrisas no está activada.
265)La velocidad del vehículo será determinada por la señal de buses de este, no por GNSS. Se utilizará la velocidad filtrada del vehículo (con respecto al ruido del sensor).
17.2.2.Condiciones específicas del servicio
266)Si se satisfacen las condiciones previas del punto 264 y al menos una de las condiciones siguientes, se cumplen las condiciones de activación de este servicio STI-C, por lo que deberá activarse la generación de un DENM.
1)velocidad de los limpiaparabrisas y estado de las luces:
a)los limpiaparabrisas funcionan a su máxima velocidad; la luz de cruce está encendida; estas condiciones deben ser válidas durante más de 20 s;
b)los limpiaparabrisas funcionan a su máxima velocidad y la velocidad del vehículo es inferior a 60 km/h; la luz de cruce está encendida; estas condiciones deben ser válidas durante más de 20 s;
2)dispositivo medidor de lluvia, velocidad de los limpiaparabrisas y estado de las luces:
a)la cantidad de lluvia equivale al menos al 90 % de la capacidad máxima del dispositivo medidor y los limpiaparabrisas funcionan a su máxima velocidad; la luz de cruce está encendida; estas condiciones deben ser válidas durante más de 20 s;
b)la cantidad de lluvia equivale al menos al 90 % de la capacidad máxima del dispositivo medidor y los limpiaparabrisas funcionan a su máxima velocidad; la luz de cruce está encendida y la velocidad del vehículo es inferior a 60 km/h; estas condiciones deben ser válidas durante más de 20 s.
267)El intervalo mínimo de detección entre dos eventos detectados deberá ser de 20 s.
17.2.3.Calidad de la información
268)El valor del elemento de datos informationQuality en el DENM depende de cómo se detecte el evento (véase el punto 266). El valor informationQuality se fijará de acuerdo con el cuadro que figura a continuación (se utilizará el valor más elevado posible).
Cuadro 34: Calidad de la información del servicio «condición meteorológica adversa: precipitación»
|
Detección del evento
|
Valor informationQuality
|
|
Ninguna aplicación conforme con TRCO
|
unknown(0)
|
|
Se cumple la condición a).
|
1
|
|
Se cumple la condición b).
|
2
|
|
Se cumple la condición c).
|
3
|
|
Se cumple la condición d).
|
4
|
269)Si las condiciones de activación cambian entre dos actualizaciones, el valor informationQuality no cambiará hasta la próxima actualización. Si, mientras se actualiza el DENM, se siguen cumpliendo las condiciones modificadas, se actualizará el valor informationQuality.
17.3.Condiciones de terminación
270)No se planteará una terminación del servicio STI-C.
17.3.1.Cancelación
271)Para este servicio STI-C no se utilizará un DENM de cancelación.
17.3.2.Negación
272)Para este servicio STI-C no se utilizará un DENM de negación.
17.4.Actualización
273)El procedimiento adecuado de actualización del DENM se determinará en función de las siguientes condiciones:
a)después del intervalo mínimo de detección especificado en el epígrafe 17.2.2 se cumple al menos una de las condiciones del punto 266;
b)el valor validityDuration del DENM anterior no ha expirado;
c)ni el valor del elemento de datos DeltaLatitude ni el del elemento de datos DeltaLongitude, que representan la distancia entre el evento detectado actual y el evento detectado anterior, superan el umbral que pueden cubrir los elementos de datos DeltaLatitude y DeltaLongitude.
274)Si se cumplen las condiciones a), b) y c) especificadas en el punto 273, deberá generarse un DENM de actualización. La información de los elementos de datos del DENM anterior (eventPosition, eventDeltaTime, informationQuality) debe almacenarse en el eventHistory como eventPoint adicional.
Los puntos de evento se ordenarán en orden ascendente con respecto a su vida útil, con el eventPoint más reciente en primera posición. Los puntos de evento del eventHistory con vidas útiles que excedan del valor validityDuration se borrarán del eventHistory con respecto al DENM de actualización. Si la distancia recorrida por el eventHistory supera el umbral permitido por la seguridad, se borrarán del eventHistory los puntos de evento más antiguos.
La información del evento detectado actual debe asignarse a los campos de datos del DENM actualizado.
Nota: Después de haberse generado el DENM de actualización, corresponde al receptor ocuparse de los puntos de evento con vidas útiles que superan el valor validityDuration.
275)Si se cumplen las condiciones a) y b), pero no la condición c), no deberá generarse un DENM de actualización. En su lugar, deberá generarse un DENM nuevo adicional. La información del evento detectado actual debe asignarse a los campos de datos del DENM nuevo adicional. El DENM anterior seguirá transmitiéndose mientras no expire el valor repetitionDuration del DENM anterior.
276)Si se cumple la condición a), pero no la condición b), no deberá generarse un DENM de actualización, sino un DENM nuevo de acuerdo con el evento detectado en ese momento.
Nota: En este caso, la transmisión del DENM anterior ya ha terminado, puesto que el valor repetitionDuration del DENM anterior ha expirado.
277)Si no se cumple la condición a), no es necesaria la generación de un DENM de actualización.
17.5.Duración de la repetición e intervalo entre repeticiones
278)Los DENM que sean nuevos o hayan sido actualizados se repetirán durante un valor repetitionDuration de 180 s con un valor repetitionInterval de 4 s. Así pues, los parámetros de interfaz duración de la repetición e intervalo entre repeticiones entre la aplicación y el servicio básico de DEN se ajustarán de acuerdo con los valores anteriores.
Nota: El valor validityDuration se ajusta en 300 s. Por lo tanto, puede evitarse una laguna de DENM si el valor repetitionDuration del DENM original ha expirado y la actualización aún no se ha recibido.
Nota: Cuando dos DENM con el mismo causeCode procedan de la misma estación STI-C, el caso será gestionado por la estación STI-C receptora.
17.6.Clase de tráfico
279)Los DENM nuevos y de actualización se ajustarán en la clase de tráfico 1.
17.7.Parámetros del mensaje
17.7.1.DENM
280)El siguiente cuadro especifica los elementos de datos del DENM que se establecerán.
Cuadro 35: Elementos de datos del DENM en el servicio «condición meteorológica adversa: precipitación»
|
Campo de datos
|
Valor
|
|
Management container
|
|
actionID
|
Identificador de un DENM. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
detectionTime
|
TimestampIts: sello de tiempo en el que el evento es detectado por la estación STI-C de origen. El sello de tiempo refleja el inicio de la detección del punto de evento actual. Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para un DENM de actualización y se ajustará en la hora de detección del punto de evento actual.
|
|
referenceTime
|
TimestampIts: sello de tiempo en el que se genera un DENM nuevo o de actualización. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
termination
|
No se establecerá, pues en este servicio STI-C no se utilizarán ni negación ni cancelación.
|
|
eventPosition
|
ReferencePosition. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
|
Se actualizará para un DENM de actualización y se ajustará en la posición del punto de evento actual.
|
|
relevanceDistance
|
·DENM nuevo: lessThan1000m(4)
·DENM de actualización: lessThan5km(5) (al utilizar actualizaciones, la distancia recorrida por el eventHistory se hace más larga; a fin de cubrir todas las estaciones STI pertinentes, el valor relevanceDistance es mayor en este caso).
|
|
relevanceTrafficDirection
|
allTrafficDirections(0)
|
|
validityDuration
|
300 s
|
|
stationType
|
El tipo de estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
Situation container
|
|
informationQuality
|
Véase el punto 268. Se actualizará para cada DENM de actualización y se ajustará en el valor informationQuality del evento actual.
|
|
causeCode
|
adverseWeatherCondition-Precipitation(19)
|
|
subCauseCode
|
unavailable(0), heavyRain(1) o heavySnowfall(2)
|
|
eventHistory
|
Este elemento se utilizará únicamente para DENM de actualización (véase el epígrafe 17.4).
|
|
Location container
|
|
traces
|
PathHistory de la estación STI-C de origen, con referencia al punto de evento actual.
Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para un DENM de actualización.
|
|
roadType
|
RoadType de la carretera en la que está situada la estación STI-C detectora.
|
|
|
Se actualizará para un DENM de actualización y se ajustará en el valor roadType del punto de evento actual.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2] en combinación con las siguientes reglas:
|
|
|
Urbana / No urbana
|
Separación estructural
|
Elemento de datos
|
|
|
Urbana
|
No
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
Urbana
|
Sí
|
urban-WithStructuralSeparation ToOppositeLanes(1)
|
|
|
Urbana
|
Desconocido
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
No urbana
|
No
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
No urbana
|
Sí
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
|
|
|
No urbana
|
Desconocido
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
Si no puede determinarse la información sobre la situación urbana o no urbana, se omitirá el elemento de datos.
|
17.7.2.CAM
281)No se utilizará la adaptación de CAM para este servicio STI-C.
17.8.Capa de red y de transporte
282)El parámetro de interfaz DENM destination area entre el servicio básico de DEN y la capa de red y de transporte será igual a una forma circular con un radio equivalente al valor relevanceDistance.
17.9.Capa de seguridad
283)Si se cumplen las condiciones de activación según se describen en el punto 266, se bloqueará un cambio de AT para DENM nuevos y de actualización durante quince minutos (contados desde el momento en que se genera el DENM nuevo). Los DENM nuevos y de actualización correspondientes se enviarán con el mismo AT.
284)Si el AT cambia y hay una transmisión activa de DENM nuevo o de actualización, deberá detenerse la transmisión. Además, se borrarán el EventHistory y el PathHistory. Luego continuará el proceso normal de generación de DENM.
18.Condiciones meteorológicas adversas: pérdida de tracción
18.1.Descripción del servicio STI-C
Este servicio STI-C transmite información V2V relativa a la presencia de pavimento deslizante, que puede afectar a la conducción.
285)Solo se enviará una señal DENM a la memoria temporal si se evalúa que las condiciones de activación descritas en el presente epígrafe son válidas. Esa señal hace que la memoria temporal genere un DENM nuevo o de actualización Si no se cumplen las condiciones de activación, no se generará una señal DENM.
18.2.Condiciones de activación
18.2.1.Condiciones previas
286)Antes de que se active este servicio STI-C, deberán satisfacerse las condiciones previas siguientes:
a)no está metida la marcha atrás;
b)no se indica ningún error del motor, del tren de transmisión ni del sistema de frenado.
18.2.2.Condiciones específicas del servicio
287)Si se satisface la condición previa del punto 286 y al menos una de las condiciones siguientes, se cumplen las condiciones de activación de este servicio STI-C, por lo que deberá activarse la generación de un DENM.
1)sobre la base de la aceleración positiva:
a)en función de la regulación antideslizamiento (ASR), el pedal acelerador, la aceleración del vehículo y la velocidad del vehículo; la petición de ASR debe estar activa durante al menos 200 ms (como en el caso de otras funciones de seguridad dependientes de la ASR); el pedal acelerador está pisado, en promedio, más del 30 % mientras está activa la intervención de la ASR; la aceleración del vehículo (aceleración según la señal de buses del vehículo filtrada) es inferior al 40 % de su aceleración sobre una superficie de alto coeficiente de rozamiento (por ejemplo, asfalto seco [donde habitualmente µ = 0,85]) a la misma velocidad de arranque y con la misma maniobra de conducción; (con el fin de cubrir diferentes configuraciones de tracción, por ejemplo, tracción a dos ruedas y tracción a cuatro ruedas, no se indican aquí valores detallados);
b)en función de la ASR, el pedal acelerador, la aceleración del vehículo y la velocidad del vehículo; la petición de ASR debe estar activa durante al menos 200 ms; el pedal acelerador está pisado, en promedio, más del 30 % mientras está activa la intervención de la ASR; la aceleración del vehículo (aceleración según la señal de buses del vehículo filtrada) es inferior al 20 % de su aceleración sobre una superficie de alto coeficiente de rozamiento (por ejemplo, asfalto seco [donde habitualmente µ = 0,85]) a la misma velocidad de arranque y con la misma maniobra de conducción;
c)en función de la ASR, el pedal acelerador, la aceleración del vehículo y la velocidad del vehículo; la petición de ASR debe estar activa durante al menos 200 ms; el pedal acelerador está pisado, en promedio, más del 30 % mientras está activa la intervención de la ASR; la aceleración del vehículo (aceleración según la señal de buses del vehículo filtrada) es inferior al 10 % de su aceleración sobre una superficie de alto coeficiente de rozamiento (por ejemplo, asfalto seco [donde habitualmente µ = 0,85]) a la misma velocidad de arranque y con la misma maniobra de conducción;
d)en función de la ASR y el pedal acelerador; la petición de ASR debe estar activa durante al menos 200 ms; el pedal acelerador está pisado, en promedio, menos del 30 % (para no causar la intervención de la ASR sobre un suelo con alto valor de rozamiento) mientras está activa la intervención de la ASR;
2)sobre la base de la aceleración negativa (desaceleración):
a)en función del sistema de frenado antibloqueo (ABS), la presión de frenado y la desaceleración; la intervención del ABS está activa durante más de 200 ms (conforme a otras funciones de seguridad dependientes del ABS); la presión de frenado es superior al 20 % de la presión de frenado máxima alcanzable; la desaceleración del vehículo (desaceleración según la señal de buses del vehículo filtrada) es inferior al 50 % de su desaceleración sobre una superficie de alto coeficiente de rozamiento (por ejemplo, asfalto seco [donde habitualmente µ = 0,85]) a la misma velocidad de arranque y con la misma maniobra de conducción;
b)en función del ABS, la presión de frenado y la desaceleración; la intervención del ABS está activa durante más de 200 ms; la presión de frenado es superior al 20 % de la presión de frenado máxima alcanzable; la desaceleración del vehículo (desaceleración según la señal de buses del vehículo filtrada) es inferior al 25 % de su desaceleración sobre una superficie de alto coeficiente de rozamiento (por ejemplo, asfalto seco [donde habitualmente µ = 0,85]) a la misma velocidad de arranque y con la misma maniobra de conducción;
c)en función del ABS, la presión de frenado y la desaceleración; la intervención del ABS está activa durante más de 200 ms; la presión de frenado es superior al 20 % (para no causar la intervención del ABS sobre un suelo con alto valor de rozamiento) de la presión de frenado máxima alcanzable; la desaceleración del vehículo (desaceleración según la señal de buses del vehículo filtrada) es inferior al 10 % de su desaceleración sobre una superficie de alto coeficiente de rozamiento (por ejemplo, asfalto seco [donde habitualmente µ = 0,85]) a la misma velocidad de arranque y con la misma maniobra de conducción;
d)en función del ABS y la presión de frenado; la intervención del ABS está activa durante más de 200 ms; la presión de frenado es inferior al 20 % de la presión de frenado máxima alcanzable;
3)sobre la base de la estimación del coeficiente de rozamiento:
a)el coeficiente de rozamiento es inferior a 0,3 durante al menos 5 s (el coeficiente de rozamiento del hielo es < 0,2; el de la nieve y la gravilla es aproximadamente de 0,4; el coeficiente de rozamiento ha de detectarse durante un determinado período);
b)el coeficiente de rozamiento es inferior a 0,2 durante al menos 5 s.
288)Si las condiciones del punto 1, letras a) a c), o del punto 2, letras a) a c), se evalúan como válidas, la aceleración o la desaceleración del vehículo vendrán determinadas por la señal de buses de este, no por análisis GNSS.
289)No se generará un DENM nuevo o de actualización durante el tiempo de bloqueo de la detección. El tiempo de bloqueo de la detección se pone en marcha una vez que se ha detectado el evento y se ha activado un DENM al efecto. De este modo, un único evento no es capaz de activar una serie de DENM. Para la estimación del coeficiente de rozamiento [condiciones del punto 3, letras a) y b)], el tiempo de bloqueo de la detección será de 15 s. Para las demás condiciones, el tiempo de bloqueo de la detección será de 20 s.
290)A fin de garantizar un comportamiento funcional coherente para las condiciones de activación a) a d) y el tiempo de bloqueo de la detección, el intervalo mínimo de detección entre dos eventos detectados será de 20 s.
18.2.3.Calidad de la información
291)El valor del elemento de datos informationQuality en el DENM depende de cómo se detecte el evento (véase el punto 287). El valor informationQuality se fijará de acuerdo con el cuadro que figura a continuación (se utilizará el valor más elevado posible).
Cuadro 36: Calidad de la información del servicio «condición meteorológica adversa: pérdida de tracción»
|
Detección del evento
|
Valor informationQuality
|
|
Ninguna aplicación conforme con TRCO
|
unknown(0)
|
|
Se cumple la condición del punto 1, letra a), o del punto 2, letra a).
|
1
|
|
Se cumple la condición del punto 1, letra b).
|
2
|
|
Se cumple la condición del punto 1, letra c), o del punto 2, letra b).
|
3
|
|
Se cumple la condición del punto 2, letra c).
|
4
|
|
Se cumple la condición del punto 1, letra d), o del punto 2, letra d).
|
5
|
|
Se cumple la condición del punto 3, letra a).
|
6
|
|
Se cumple la condición del punto 3, letra b).
|
7
|
292)Si las condiciones de activación cambian entre dos actualizaciones, el valor informationQuality no cambiará hasta la próxima actualización. Si, mientras se actualiza el DENM, se siguen cumpliendo las condiciones modificadas, se actualizará el valor informationQuality.
18.3.Condiciones de terminación
293)No se planteará una terminación del servicio STI-C.
18.3.1.Cancelación
294)Para este servicio STI-C no se utilizará un DENM de cancelación.
18.3.2.Negación
295)Para este servicio STI-C no se utilizará un DENM de negación.
18.4.Actualización
296)El procedimiento adecuado de actualización del DENM se determinará en función de las siguientes condiciones:
a)después del intervalo mínimo de detección especificado en el epígrafe 18.2.2 se cumple al menos una de las condiciones del punto 287;
b)el valor validityDuration del DENM anterior no ha expirado;
c)ni el valor del elemento de datos DeltaLatitude ni el del elemento de datos DeltaLongitude, que representan la distancia entre el evento detectado actual y el evento detectado anterior, superan el umbral que pueden cubrir los elementos de datos DeltaLatitude y DeltaLongitude.
297)Si se cumplen las condiciones a), b) y c) especificadas en el punto 296, deberá generarse un DENM de actualización. La información de los elementos de datos del DENM anterior (eventPosition, eventDeltaTime, informationQuality) debe almacenarse en el eventHistory como eventPoint adicional.
Los puntos de evento se ordenarán en orden ascendente con respecto a su vida útil, con el eventPoint más reciente en primera posición. Los puntos de evento del eventHistory con vidas útiles que excedan del valor validityDuration (véase el punto 303) se borrarán del eventHistory con respecto al DENM de actualización. Si la distancia recorrida por el eventHistory supera el umbral permitido por la seguridad, se borrarán del eventHistory los puntos de evento más antiguos.
La información del evento detectado actual debe asignarse a los campos de datos del DENM actualizado.
Nota: Después de haberse generado el DENM de actualización, corresponde al receptor ocuparse de los puntos de evento con vidas útiles que superan el valor validityDuration.
298)Si se cumplen las condiciones a) y b), pero no la condición c), no deberá generarse un DENM de actualización. En su lugar, deberá generarse un DENM nuevo adicional. La información del evento detectado actual se asignará a los campos de datos del DENM nuevo adicional. El DENM anterior seguirá transmitiéndose mientras no expire el valor repetitionDuration del DENM anterior.
299)Si se cumple la condición a), pero no la condición b), no deberá generarse un DENM de actualización, sino un DENM nuevo de acuerdo con el evento detectado en ese momento.
Nota: En este caso, la transmisión del DENM anterior ya ha terminado, puesto que el valor repetitionDuration del DENM anterior ha expirado.
300)Si no se cumple la condición a), no es necesaria la generación de un DENM de actualización.
18.5.Duración de la repetición e intervalo entre repeticiones
301)Por defecto, los DENM que sean nuevos o hayan sido actualizados se repetirán durante un valor repetitionDuration de 300 s con un valor repetitionInterval de 1 s.
No obstante, si el DENM se activa en una zona urbana, según se determine mediante un mapa digital o el algoritmo de un sensor de a bordo, deberá repetirse durante un valor repetitionDurationde 180 s con un valor repetitionInterval de 4 s.
Así pues, los parámetros de interfaz duración de la repetición e intervalo entre repeticiones entre la aplicación y el servicio básico de DEN se ajustarán de acuerdo con los valores anteriores.
Nota: El valor validityDuration se ajusta en 600 s o 300 s, respectivamente. Por lo tanto, puede evitarse una laguna de DENM si el valor repetitionDuration del DENM original ha expirado y la actualización aún no se ha recibido.
Nota: Cuando dos DENM con el mismo causeCode procedan de la misma estación STI-C, el caso será gestionado por la estación STI-C receptora.
18.6.Clase de tráfico
302)Los DENM nuevos y de actualización se ajustarán en la clase de tráfico 1.
18.7.Parámetros del mensaje
18.7.1.DENM
303)El siguiente cuadro especifica los elementos de datos del DENM que se establecerán.
Cuadro 37: Elementos de datos del DENM en el servicio «condición meteorológica adversa: pérdida de tracción»
|
Campo de datos
|
Valor
|
|
Management container
|
|
actionID
|
Identificador de un DENM. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
detectionTime
|
TimestampIts: sello de tiempo en el que el evento es detectado por la estación STI-C de origen. El sello de tiempo refleja el inicio de la detección del punto de evento actual. Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para un DENM de actualización y se ajustará en la hora de detección del punto de evento actual.
|
|
referenceTime
|
TimestampIts: sello de tiempo en el que se genera un DENM nuevo o de actualización. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
termination
|
No se establecerá, pues en este servicio STI-C no se utilizarán ni negación ni cancelación.
|
|
eventPosition
|
ReferencePosition. Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para un DENM de actualización y se ajustará en la posición del punto de evento actual.
|
|
relevanceDistance
|
·DENM nuevo: lessThan1000m(4)
·DENM de actualización: lessThan5km(5) (al utilizar actualizaciones, la distancia recorrida por el eventHistory se hace más larga; a fin de cubrir todas las estaciones STI pertinentes, el valor relevanceDistance es mayor en este caso).
|
|
relevanceTrafficDirection
|
allTrafficDirections(0)
|
|
validityDuration
|
Por defecto: 600 s
En zonas urbanas, según se determine mediante un mapa digital o el algoritmo de un sensor de a bordo: 300 s (si el vehículo no dispone de información sobre la situación urbana o no urbana, se utilizará el valor por defecto).
|
|
stationType
|
El tipo de estación STI-C de origen. Se fijará de acuerdo con la norma [TS 102 894-2].
|
|
Situation container
|
|
informationQuality
|
Véase el punto 291. Se actualizará para cada DENM de actualización y se ajustará en el valor informationQuality del evento actual.
|
|
causeCode
|
adverseWeatherCondition-Adhesion(6)
|
|
subCauseCode
|
unavailable(0)
|
|
eventHistory
|
Este elemento se utilizará únicamente para DENM de actualización (véase el epígrafe 18.4).
|
|
Location container
|
|
traces
|
PathHistory de la estación STI-C de origen, con referencia al punto de evento actual.
Se fijará de acuerdo con la norma [TS 102 894-2].
Se actualizará para un DENM de actualización.
|
|
roadType
|
RoadType de la carretera en la que está situada la estación STI-C detectora.
Se actualizará para un DENM de actualización y se ajustará en el valor roadType del punto de evento actual.
|
|
|
Se fijará de acuerdo con la norma [TS 102 894-2] en combinación con las siguientes reglas:
|
|
|
Urbana / No urbana
|
Separación estructural
|
Elemento de datos
|
|
|
Urbana
|
No
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
Urbana
|
Sí
|
urban-WithStructuralSeparation ToOppositeLanes(1)
|
|
|
Urbana
|
Desconocido
|
urban-NoStructuralSeparation ToOppositeLanes(0)
|
|
|
No urbana
|
No
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
No urbana
|
Sí
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
|
|
|
No urbana
|
Desconocido
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
|
|
|
Si no puede determinarse la información sobre la situación urbana o no urbana, se omitirá el elemento de datos.
|
18.7.2.CAM
304)No se utilizará la adaptación de CAM para este servicio STI-C.
18.8.Capa de red y de transporte
305)El parámetro de interfaz DENM destination area entre el servicio básico de DEN y la capa de red y de transporte será igual a una forma circular con un radio equivalente al valor relevanceDistance.
18.9.Capa de seguridad
306)Si se cumplen las condiciones de activación según se describen en el punto 287, se bloqueará un cambio de AT para DENM nuevos y de actualización durante quince minutos (contados desde el momento en que se genera el DENM nuevo). Los DENM nuevos y de actualización correspondientes se enviarán con el mismo AT.
307)Si el AT cambia y hay una transmisión activa de DENM nuevo o de actualización, deberá detenerse la transmisión. Además, se borrarán el EventHistory y el PathHistory. Luego continuará el proceso normal de generación de DENM.
19.Señalización en el vehículo: información sobre el límite de velocidad dinámico
Este servicio STI-C transmite información I2V (utilizando IVI) relativa al límite de velocidad válido en el momento, por segmento, carril o categoría de vehículo, de forma continua, según lo establece y distribuye el explotador de la carretera.
308)La información deberá ser coherente con las señales de tráfico dinámicas válidas en el momento.
309)[ISO/TS 14823] El campo de datos se establecerá con los tipos de datos serviceCategoryCode = regulatory, nature = 5, serialNumber = 57, attributes/spe/spm = el valor del límite de velocidad en km/h, y unit = 0 (es decir, kmperh), o el equivalente en otros países (por ejemplo, 1 para milesperh).
310)Con respecto al fin del límite de velocidad, se podrá utilizar lo siguiente: [ISO/TS 14823] Campo de datos con los tipos de datos serviceCategoryCode = regulatory (12), nature = 6, serialNumber = 14 (aviso de fin del límite de velocidad) o serviceCategoryCode = informative (13), nature = 6, serial number = 63 (aviso de fin de todas las restricciones mediante señales electrónicas), si esta señal figura en la carretera. Los mensajes de terminación podrían ser redundantes, pues el punto final de la zona de pertinencia del mensaje IVI inicial ya pone término al límite de velocidad.
20.Señalización en el vehículo: «texto libre» VMS intercalado
Este servicio STI-C transmite información I2V (utilizando IVI) en «texto libre», según la establece y distribuye el explotador de la carretera. La prioridad de los mensajes IVS enviados es definida por el explotador de la carretera.
311)La información deberá ser coherente con las señales de tráfico dinámicas válidas en el momento.
21.Señalización en el vehículo: otra información de señalización
Este servicio STI-C transmite información de señalización I2V (utilizando IVI) distinta del límite de velocidad dinámico y de la información de texto libre, como, por ejemplo, prohibiciones de adelantamiento o asesoramiento sobre el carril, según la establece y distribuye el explotador de la carretera.
312)La información deberá ser coherente con las señales de tráfico dinámicas válidas en el momento.
313)[ISO/TS 14 823] El campo de datos se establece con los tipos de datos serviceCategoryCode = informative; nature = 6; serialNumber = 59 (carril cerrado), 60 (carril libre), 61 (liberar carril izquierdo) o 62 (liberar carril derecho).
314)Con respecto al «fin de la restricción»: podrán utilizarse serviceCategoryCode = informative (13), nature = 6, serialNumber = 63 correspondiente a «fin de todas las restricciones por señales electrónicas», si se muestra esta señal electrónica. Los mensajes de terminación podrían ser redundantes, pues el punto final de la zona de pertinencia del mensaje IVI inicial ya pone término a la información de señalización.
22.Notificación de ubicaciones peligrosas: zona de accidente
Este servicio STI-C transmite información I2V (mediante DEN) relativa a una zona de accidente utilizando un único identificador de mensaje de advertencia, según lo establece y distribuye el explotador de la carretera.
315)El CauseCode se ajustará en 2 (accidente) y el subCauseCode en 0 y 7 (excepto 6).
23.Notificación de ubicaciones peligrosas: atasco más adelante
Este servicio STI-C transmite información I2V (mediante DEN) sobre la existencia de un atasco más adelante, por segmento o por carril, utilizando un único identificador de mensaje de advertencia, según lo establece y distribuye el explotador de la carretera (mencionando las posiciones, la longitud del atasco y los tramos/carriles afectados, si está disponible esta información).
316)El CauseCode se ajustará en 27 (final de fila peligroso) y el subCauseCode en 0 (no disponible) para señalar la existencia de un final de fila peligroso. Para transmitir información sobre la longitud total de la fila, el causeCode se ajustará en 1 (congestión del tráfico) y el subCauseCode en 0.
24.Notificación de ubicaciones peligrosas: vehículo parado
Este servicio STI-C transmite información I2V (mediante DEN) relativa a un vehículo parado utilizando un único identificador de mensaje de advertencia, según lo establece y distribuye el explotador de la carretera.
317)El CauseCode se ajustará en 94 (vehículo parado) y el subCauseCode en 0 (no disponible) o en 2 (vehículo averiado).
25.Notificación de ubicaciones peligrosas: advertencia de condiciones meteorológicas
Este servicio STI-C transmite información I2V (mediante DEN) relativa a una precipitación o unas condiciones meteorológicas extremas (situación 1) o a una baja visibilidad (situación 3), actuales o previstas, utilizando un único identificador de mensaje de advertencia, según lo establece y distribuye el explotador de la carretera.
318)El CauseCode se ajustará en 17 (condiciones meteorológicas extremas) o en 19 (precipitación).
26.Notificación de ubicaciones peligrosas: calzada temporalmente deslizante
Este servicio STI-C transmite información I2V (mediante DEN) relativa a tramos deslizantes de la carretera, utilizando un único identificador de mensaje de advertencia, según lo establece y distribuye el explotador de la carretera.
319)El CauseCode se ajustará en 6 (adherencia) y el subCauseCode entre 0 y 9.
27.Notificación de ubicaciones peligrosas: animal o persona en la calzada
Este servicio STI-C transmite información I2V (mediante DEN) relativa a la presencia de animales o personas en la calzada, utilizando un único identificador de mensaje de advertencia, según lo establece y distribuye el explotador de la carretera.
320)El CauseCode se ajustará en 11 (animal en la calzada) o en 12 (presencia de personas en la calzada).
28.Notificación de ubicaciones peligrosas: obstáculo en la calzada
Este servicio STI-C transmite información I2V (mediante DEN) relativa a la presencia de uno o más obstáculos en uno o más carriles. Sin embargo, el tráfico no se detiene (no hay un bloqueo). Utiliza un único identificador de mensaje de advertencia, según lo establece y distribuye el explotador de la carretera.
321)El CauseCode se ajustará en 10 (obstáculo en la calzada) y el subCauseCode entre 0 y 5 (6 y 7 no se utilizan).
29.Advertencia de obras en la calzada: cierre de carril (y otras restricciones)
Este servicio STI-C transmite información I2V (mediante DEN) relativa al cierre de parte de un carril, un carril entero o varios carriles (incluido el arcén), pero sin que se cierre totalmente la carretera. Utiliza un único identificador de mensaje de advertencia, según lo establece y distribuye el explotador de la carretera
Puede facilitarse de alguna de las maneras siguientes:
·obras estáticas previstas en la calzada (activación por el centro de operaciones de tráfico [TOC]): el explotador de la carretera programa en su sistema de gestión del tráfico (TMS) obras estáticas y planificadas (o ad hoc);
·modo autónomo: se utiliza un remolque para realizar obras en la calzada a corto o largo plazo, pero sin conexión con el TOC (ninguna conexión disponible);
·modo aumentado (modo autónomo seguido de activación por el TOC): el mensaje se envía primero desde un remolque y puede actualizarse después, incluso con detalles adicionales del TOC.
322)El CauseCode se ajustará en 3 (obras en la calzada) y el subCauseCode en 0 o 4.
30.Advertencia de obras en la calzada: cierre de la carretera
Este servicio STI-C transmite información I2V (mediante DEN) relativa al cierre de la carretera debido a un conjunto de obras estáticas en la calzada. El cierre es temporal. Utiliza un único identificador de mensaje de advertencia, según lo establece y distribuye el explotador de la carretera
323)El CauseCode se ajustará en 3 (obras en la calzada) y el subCauseCode en 1.
31.Advertencia de obras en la calzada: obras en la calzada (móviles)
Este servicio STI-C transmite información I2V (mediante DEN) relativa a una zona de la carretera en la que, en algún punto, se estrecha o cierra un carril (pero sin que se cierre la carretera), debido a que está prevista una obra móvil. Utiliza un único identificador de mensaje de advertencia, según lo establece y distribuye el explotador de la carretera.
Este servicio STI-C puede facilitarse de alguna de las maneras siguientes:
·activación por el TOC: el explotador de la carretera programa en su TMS obras en la calzada móviles y planificadas (o ad hoc); la información contiene todos los elementos que pueden utilizarse para identificar la zona de obras (posición inicial/final y duración); los operarios no utilizarán toda la zona, sino que marcarán en ella el lugar concreto de las obras; puede añadirse más información, como es el límite de velocidad en cada porción estrechada;
·modo autónomo: se utiliza un remolque para realizar obras en la calzada a corto o largo plazo, pero sin conexión con el TOC (ninguna conexión disponible).
324)Tanto el CauseCode como el subCauseCode se ajustarán en 3 (obras en la calzada).
32.Intersecciones señalizadas: recomendación de velocidad óptima para semáforo en verde
Este servicio STI-C transmite información I2V —utilizando la fase y la temporización de señales (SPAT) y la información topográfica para la intersección (MAP)— relativa a la recomendación de velocidad para los usuarios de la vía que se aproximan a intersecciones controladas por semáforos y las atraviesan, basándose en el estado de la fase actual y en la temporización prevista de los semáforos, así como en la topografía de la carretera de cara a las intersecciones situadas más adelante.
Puede facilitarse de alguna de las maneras siguientes:
·el vehículo calcula la recomendación de velocidad: la intersección señalizada transmite periódicamente y en tiempo real el estado de la fase actual de los semáforos y la temporización de los próximos cambios de fase; el vehículo que se aproxima, que conoce su ubicación y velocidad propias, recibe los mensajes y calcula la velocidad óptima para aproximarse a la intersección;
·la infraestructura calcula la recomendación de velocidad: la intersección señalizada calcula y transmite periódicamente y en tiempo real información sobre la velocidad recomendada para múltiples segmentos de la calzada en la aproximación a la intersección; el vehículo que se aproxima, que conoce su ubicación y velocidad propias, recibe los mensajes y extrae la velocidad óptima para aproximarse a la intersección;
·recomendación de velocidad para onda verde: una secuencia de intersecciones sincronizadas controladas por semáforos transmite la recomendación de velocidad predefinida o planificada para la onda verde; el vehículo que se aproxima, que conoce su ubicación y velocidad propias, recibe los mensajes y extrae la velocidad de onda verde para atravesar las intersecciones.
325)La información sobre el estado de la fase actual y la temporización de los próximos cambios de fase procedente de la intersección señalizada deberán ser lo suficientemente exactos y fiables para garantizar una recomendación de velocidad de gran calidad.
326)La información deberá ser coherente con las cabezas de semáforo físicas de la intersección.
327)Las condiciones del tráfico, tales como filas o atascos, afectan a la validez de la recomendación de velocidad y, por lo tanto, deberán ser tenidas en cuenta.
328)Las velocidades recomendadas no deberán nunca superar el límite de velocidad legal.
33.Intersecciones señalizadas: priorización del transporte público
Este servicio STI-C da prioridad a los vehículos de transporte público sobre los vehículos privados en las intersecciones señalizadas, utilizando mensajes extendidos de petición de señales (SREM) y mensajes extendidos de situación de la petición de señales (SSEM). El vehículo de transporte público transmite una petición de priorización mediante V2I. El sistema de priorización del transporte público procesa la petición, la acepta o la rechaza, y envía la respuesta al vehículo de transporte público mediante I2V. Si se acepta la petición, por ejemplo, acortando las «fases en rojo» y extendiendo las «fases en verde», el vehículo de transporte público obtiene el semáforo en verde con un retraso mínimo en la línea de parada. Una vez que ha atravesado la intersección, el regulador semafórico vuelve al funcionamiento normal.
329)El valor stationID del vehículo no cambiará durante el procesamiento de la petición de priorización.
330)Deberá garantizarse la autenticación y la autorización de los vehículos de transporte público.
331)La petición de prioridad deberá efectuarse con tiempo para que el sistema de priorización del transporte público pueda reaccionar.
ANEXO II
1.Introducción
1.1.Referencias
En el presente anexo se utilizan las siguientes referencias:
EN 302 636-4-1
ETSI EN 302 636-4-1, Intelligent Transport Systems (ITS); Vehicular Communication; Geonetworking; Part 4: Geographical addressing and forwarding for point-to-point and point-to-multipoint communications; Sub-part 1: Media-Independent Functionality (Sistemas de transporte inteligentes [STI]. Comunicaciones vehiculares. GeoNetworking. Parte 4: Direccionamiento geográfico y reenvío de comunicaciones punto a punto y punto a multipunto. Subparte 1: Funcionalidad independiente de los medios) V1.3.1 (2017-08)
TS 102 894-2
ETSI TS 102 894-2, Intelligent Transport Systems (ITS); Users and applications requirements; Part 2: Applications and facilities layer common data dictionary (Sistemas de transporte inteligentes [STI]. Requisitos aplicables a usuarios y aplicaciones. Parte 2: Diccionario de datos comunes de las capas de aplicaciones y recursos), V1.3.1 (2018-08)
ISO/TS 19091
ISO/TS 19091, Intelligent transport systems – Cooperative ITS – Using V2I and I2V communications for applications related to signalized intersections (Sistemas de transporte inteligentes. STI cooperativos. Utilización de comunicaciones V2I e I2V para aplicaciones relacionadas con intersecciones señalizadas), (2017-03)
EN 302 663
ETSI EN 302 663, Intelligent Transport Systems (ITS); Access layer specification for Intelligent Transport Systems operating in the 5 GHz frequency band (Sistemas de transporte inteligentes [STI]. Especificación de la capa de acceso para los sistemas de transporte inteligentes que funcionan en la banda de frecuencia de 5 GHz), V1.2.1 (2013-07)
TS 102 687
ETSI EN 102 687, Intelligent Transport Systems (ITS); Decentralized Congestion Control Mechanisms for Intelligent Transport Systems operating in the 5 GHz range; Access layer part (Sistemas de transporte inteligentes [STI]. Mecanismos del control de congestión descentralizado para los sistemas de transporte inteligentes que funcionan en la banda de frecuencia de 5 GHz. Parte de la capa de acceso), V1.2.1 (2018-04)
TS 102 792
ETSI TS 102 792, Intelligent Transport Systems (ITS); Mitigation techniques to avoid interference between European CEN Dedicated Short Range Communication (CEN DSRC) equipment and Intelligent Transport Systems (ITS) operating in the 5 GHz frequency range (Sistemas de transporte inteligentes [STI]. Técnicas de atenuación para evitar interferencias entre los equipos europeos CEN de comunicaciones de corto alcance dedicadas [CEN DSRC] y los sistemas de transporte inteligentes que funcionan en la banda de frecuencia de 5 GHz), V1.2.1 (2015-06)
TS 302 637-2
ETSI EN 302 637-2, Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic Service (Sistemas de transporte inteligentes [STI]. Comunicaciones vehiculares. Conjunto básico de aplicaciones. Parte 2: Especificación del servicio básico de concienciación cooperativa), V1.4.0 (2018-08); esta referencia se entenderá hecha a la versión 1.4.1 desde la fecha de publicación de esta.
TS 102 724
ETSI TS 102 724, Intelligent Transport Systems (ITS); Harmonized Channel Specifications for Intelligent Transport Systems operating in the 5 GHz frequency band (Sistemas de transporte inteligentes [STI]. Especificaciones de canal armonizado para los sistemas de transporte inteligentes que funcionan en la banda de frecuencia de 5 GHz) V1.1.1 (2012-10)
EN 302 636-5-1
ETSI EN 302 636-5-1, Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 5: Transport Protocols; Sub-part 1: Basic Transport Protocol (Sistemas de transporte inteligentes [STI]. Comunicaciones Vehiculares. GeoNetworking. Parte 5: Protocolos de transporte. Subparte 1: Protocolo de transporte básico), V2.1.1 (2017-08)
TS 103 248
ETSI TS 103 248, Intelligent Transport Systems (ITS); GeoNetworking; Port Numbers for the Basic Transport Protocol (BTP) (Sistemas de transporte inteligentes [STI]. GeoNetworking. Números de puerto para el protocolo de transporte básico [BTP]), V1.2.1 (2018-08)
EN 302 931
ETSI EN 302 931, Vehicular Communications; Geographical Area Definition (Comunicaciones vehiculares. Definición del área geográfica), V1.1.1 (2011-7)
TS 302 637-3
ETSI EN 302 637-3, Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 3: Specifications of Decentralized Environmental Notification Basic Service (Sistemas de transporte inteligentes [STI]. Comunicaciones vehiculares. Conjunto básico de aplicaciones. Parte 3: Especificaciones del servicio básico de notificación ambiental descentralizada), V1.3.0 (2018-08); esta referencia se entenderá hecha a la versión 1.3.1 desde la fecha de publicación de esta.
TS 102 636-4-2
ETSI TS 102 636-4-2, Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 4: Geographical addressing and forwarding for point-to-point and point-to-multipoint communications; Sub-part 2: Media-dependent functionalities for ITS-G5 (Sistemas de transporte inteligentes [STI]. Comunicaciones vehiculares. GeoNetworking. Parte 4: Direccionamiento geográfico y reenvío de comunicaciones punto a punto y punto a multipunto. Subparte 2: Funcionalidades dependientes de los medios para ITS-G5), V1.1.1 (2013-10)
SAE J2945/1
SAE J2945/1, On-board System Requirements for V2V Safety Communications (Requisitos de los sistemas de a bordo para las comunicaciones de seguridad V2V), (2016-03)
TS 103 097
ETSI TS 103 097, Intelligent Transport Systems (ITS); Security; Security Header and Certificate Formats (Sistemas de transporte inteligentes [STI]. Seguridad. Formatos de cabecera de seguridad y certificado), V1.3.1 (2017-10)
ISO 8855
ISO 8855, Road vehicles — Vehicle dynamics and road-holding ability — Vocabulary (Vehículos de carretera. Dinámica y estabilidad del vehículo. Vocabulario), (2011-12)
TS 103 301
ETSI TS 103 301, Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Facilities layer protocols and communication requirements for infrastructure services (Sistemas de transporte inteligentes [STI]. Comunicaciones vehiculares. Conjunto básico de aplicaciones. Protocolos de la capa de recursos y requisitos de comunicación para los servicios de infraestructura), V1.2.1 (2018-08)
TS 103 175
ETSI TS 103 175, Intelligent Transport Systems (ITS); Cross Layer DCC Management Entity for operation in the ITS G5A and ITS G5B medium (Sistemas de transporte inteligentes [STI]. Entidad multicapa de gestión DCC para el funcionamiento en el medio ITS G5A e ITS G5B), V1.1.1 (2015-06)
ISO/TS 19321
ISO/TS 19321, Intelligent transport systems — Cooperative ITS — Dictionary of in-vehicle information (IVI) data structures (Sistemas de transporte inteligentes. STI cooperativos. Diccionario de estructuras de datos de información en los vehículos), (2015-04-15)
ISO 3166-1
ISO 3166-1:2013, Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes (Códigos para la representación de los nombres de los países y sus subdivisiones. Parte 1: Códigos de los países)
ISO 14816
ISO 14816:2005, Road transport and traffic telematics; Automatic vehicle and equipment identification; Numbering and data structure (Telemática aplicada al tráfico y al transporte por carretera. Identificación automática de vehículos y equipos. Estructuras de numeración y de datos)
ISO/TS 14823
ISO/TS 14823:2017, Intelligent transport systems – Graphic data dictionary (Sistemas inteligentes de transporte. Diccionario de datos gráficos)
IEEE 802.11
IEEE 802.11-2016, IEEE Standard for Information technology — Telecommunications and information exchange between systems, local and metropolitan area networks — Specific requirements, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications (Norma IEEE para la tecnología de la información. Telecomunicaciones e intercambio de información entre sistemas. Redes de área local y metropolitana. Requisitos específicos. Parte 11: Especificaciones del control de acceso del medio (MAC) de la LAN inalámbrica y de la capa física (PHY)), (2016-12-14)
1.2.Notaciones y abreviaciones
En el presente anexo se emplean las notaciones y los términos abreviados siguientes:
AT
Tique de autorización (Authorization Ticket)
BTP
Protocolo de transporte básico (Basic Transport Protocol)
CA
Concienciación cooperativa (Cooperative Awareness)
CAM
Mensaje de concienciación cooperativa (Cooperative Awareness Message)
CBR
Razón de canal ocupado (Channel Busy Ratio)
CCH
Canal de control (Control Channel)
CDD
Diccionario de datos comunes (Common Data Dictionary)
CEN-DSRC
Comité Europeo de Normalización (CEN) - Comunicación de corto alcance dedicada
DCC
Control de congestión descentralizado (Decentralized Congestion Control)
DEN
Notificación ambiental descentralizada (Decentralized Environmental Notification)
DENM
Mensaje de notificación ambiental descentralizada (Decentralized Environmental Notification Message)
DP
Perfil del control de congestión descentralizado (Decentralized Congestion Control Profile)
ETSI
Instituto Europeo de Normas de Telecomunicaciones
GBC
GeoBroadcast
GN
GeoNetworking
GNSS
Sistema mundial de navegación por satélite (Global Navigation Satellite System)
IEEE
Instituto de Ingenieros Eléctricos y Electrónicos (Institute of Electrical and Electronics Engineers)
IVI
Información de infraestructura a vehículo (Infrastructure to Vehicle Information)
IVIM
Mensaje de información de infraestructura a vehículo (Infrastructure to Vehicle Information Message)
MAP
Información topográfica para la intersección (Topology information for the intersection)
MAPEM
Mensaje extendido de MAP (MAP Extended Message)
NH
Próxima cabecera (Next Header)
NTP
Protocolo de sincronización de la red (Network Time Protocol)
PAI
Indicador de exactitud de la posición (Position Accuracy Indicator)
PoTi
Posición y hora (Position and Time)
QPSK
Modulación por desplazamiento de fase cuaternaria (Quadrature Phase-Shift Keying)
RLT
Topografía de carriles de la calzada (Road Lane Topology)
RSU
Unidad viaria (Road-side Unit)
SCF
Custodia-transporte-reenvío (Store Carry Forward)
SHB
Difusión a un salto (Single Hop Broadcast)
SPATEM
Mensaje extendido de fase y temporización de señales (Signal Phase and Timing Extended Message)
SREM
Mensaje extendido de petición de señales (Signal Request Extended Message)
SSEM
Mensaje extendido de situación de la petición de señales (Signal Request Status Extended Message)
STI-C
Sistemas de transporte inteligentes cooperativos (Cooperative Intelligent Transport Systems)
TAI
Hora atómica internacional (International Atomic Time)
TAL
Nivel de garantía de confianza (Trust Assurance Level)
TLM
Maniobra semafórica (Traffic Light Manoeuvre)
TC
Clase de tráfico (Traffic Class)
UTC
Hora universal coordinada (Coordinated Universal Time)
WGS84
Sistema Geodésico Mundial 1984 (World Geodetic System 84)
1.3.Definiciones
En el presente anexo se utilizan las siguientes definiciones:
a)«Hora STI-C» o «base horaria»: número de milisegundos de la hora atómica internacional (TAI) transcurridos desde la hora universal coordinada (UTC)+0 2004-01-01 00:00:00.000, según se define en la norma [ETSI EN 302 636-4-1]; los sellos de tiempo conforme a la norma [ETSI TS 102 894-2] siguen este formato de hora.
Nota: Los «milisegundos TAI» representan el número real de milisegundos contados y no alterados por segundos intercalares después del 1 de enero de 2004.
b)«Reloj de estación»: reloj que representa la hora de los sistemas de transporte inteligentes cooperativos (STI-C) en una estación STI-C.
2.Requisitos aplicables a las estaciones STI-C vehiculares diseñadas para la comunicación de corto alcance
Este perfil de sistema especifica un conjunto mínimo de normas y colma las lagunas pertinentes para la realización de una estación STI-C vehicular interoperable en el lado de la transmisión. El perfil incluye únicamente los requisitos de interoperabilidad, dejando abierta la posibilidad de añadir requisitos adicionales. No describe, por tanto, la funcionalidad completa de la estación STI-C vehicular.
Este perfil de sistema permite la implantación de los servicios prioritarios (en particular, V2V). Puede servir de apoyo a otros servicios, pero estos pueden requerir especificaciones de sistema adicionales.
El perfil proporciona descripciones, definiciones y reglas para las capas (aplicaciones, recursos, redes, transporte y acceso) de la arquitectura de referencia de la estación STI ETSI o el servidor de la estación STI.
2.1.Definiciones
En la presente parte de este anexo se utilizan las siguientes definiciones:
a)«estados del vehículo»: posición, rumbo y velocidad absolutos en un momento determinado;
b)que la información se facilite con un «nivel de confianza» del 95 % significa que el valor real está dentro del intervalo especificado por el valor estimado más/menos el intervalo de confianza en el 95 % de los puntos de datos de una base estadística determinada;
c)«obstrucción del cielo»: fracción de los valores de la semiesfera que están obstruidos para los satélites de Galileo u otros sistemas mundiales de navegación por satélite (GNSS) debido a las montañas, los edificios, los árboles, etc.;
d)«CEN-DSRC» (Comité Europeo de Normalización- Comunicación de corto alcance dedicada): tecnología de microondas utilizada en los sistemas de telepeaje electrónicos para financiar los costes de la infraestructura viaria o para recaudar las tasas de utilización de las carreteras; a los efectos del presente anexo, el término «CEN-DSRC» abarca todas las tecnologías de microondas de 5,8 GHz contempladas en la Directiva 2004/52/CE del Parlamento Europeo y del Consejo y en la Decisión 2009/750/CE de la Comisión.
2.2.Ajustes de los parámetros
En la presente parte de este anexo se utilizan los ajustes de los parámetros del cuadro 1.
Cuadro 1: Ajustes de los parámetros
|
Parámetro
|
Valor
|
Unidad
|
Descripción
|
|
pAlDataRateCch
|
6
|
Mbit/s
|
Velocidad de datos por defecto para el canal de control (CCH)
|
|
pAlDataRateCchHigh
|
12
|
Mbit/s
|
Velocidad de datos opcional para el CCH superior a la velocidad por defecto
|
|
pAlDataRateCchLow
|
3
|
Mbit/s
|
Velocidad de datos opcional para el CCH inferior a la velocidad por defecto
|
|
pBtpCamPort
|
2001
|
n/d
|
Puerto de destino notorio para los CAM
|
|
pBtpDenmPort
|
2002
|
n/d
|
Puerto de destino notorio para los DENM
|
|
pBtpDestPortInfo
|
0
|
n/d
|
Valor de la información del puerto de destino
|
|
pCamGenNumber
|
3
|
n/d
|
Número de CAM generados consecutivamente sin restricciones temporales
|
|
pCamTraceMaxLength
|
500
|
m
|
Longitud máxima de un rastro en CAM
|
|
pCamTraceMinLength
|
200
|
m
|
Longitud mínima de un rastro en CAM
|
|
pCamTrafficClass
|
2
|
n/d
|
Valor de la clase de tráfico (TC) con la que se envían CAM
|
|
pDccCcaThresh
|
- 85
|
dBm
|
Sensibilidad mínima del canal
|
|
pDccMeasuringInterval
|
100
|
ms
|
Valor del intervalo en el que se suministra la carga del canal
|
|
pDccMinSensitivity
|
- 88
|
dBm
|
Valor de la sensibilidad mínima del receptor
|
|
pDccProbingDuration
|
8
|
µs
|
Valor de la duración del muestreo
|
|
pDccPToll
|
10
|
dBm
|
Valor de la potencia de transmisión dentro de zonas protegidas
|
|
pDCCSensitivityMargin
|
3
|
dB
|
Valor del margen del parámetro pDccMinSensitivity
|
|
pDenmTraceMaxLength
|
1 000
|
m
|
Longitud máxima de un rastro en DENM
|
|
pDenmTraceMinLength
|
600
|
m
|
Longitud mínima de un rastro en DENM
|
|
pGnAddrConfMode
|
ANONYMOUS (2)
|
n/d
|
Método de configuración para la dirección GeoNetworking (GN)
|
|
pGnBtpNh
|
2
|
n/d
|
Valor del campo «próxima cabecera» (NH) de la cabecera común GN
|
|
pGnChannelOffLoad
|
0
|
n/d
|
Valor del campo de descarga del canal
|
|
pGnEtherType
|
0x8947
|
--
|
Valor del EtherType que ha de utilizarse
|
|
pGnGbcHtField
|
4
|
n/d
|
Valor del campo HeaderType en casos de GeoBroadcast (GBC)
|
|
pGnGbcScf
|
1
|
n/d
|
Valor del campo «custodia-transporte-reenvío» en casos de GBC
|
|
pGnInterfaceType
|
ITS-G5 (1)
|
n/d
|
Tipo de interfaz que ha de utilizar GN
|
|
pGnIsMobile
|
1
|
n/d
|
Define si la estación STI-C es móvil o no
|
|
pGnMaxAreaSize
|
80
|
km²
|
Área que debe cubrirse
|
|
pGnSecurity
|
ENABLED (1)
|
n/d
|
Define la utilización de cabeceras de seguridad GN
|
|
pGnShbHstField
|
0
|
n/d
|
Valor del campo HeaderSubType en casos de difusión a un salto (SHB)
|
|
pGnShbHtField
|
5
|
n/d
|
Valor del campo HeaderType en casos de SHB
|
|
pGnShbLifeTimeBase
|
1
|
n/d
|
Valor del campo LifeTimeBase en casos de SHB
|
|
pGnShbLifeTimeMultiplier
|
1
|
n/d
|
Valor del campo LifeTimeMultiplier en casos de SHB
|
|
pPotiMaxTimeDiff
|
20
|
ms
|
Diferencia horaria máxima entre el reloj de la estación y la base horaria
|
|
pPotiWindowTime
|
120
|
s
|
Tamaño de la ventana deslizante de posición y hora (PoTi) en segundos
|
|
pPotiUpdateRate
|
10
|
Hz
|
Velocidad de actualización de la información sobre posición y hora
|
|
pSecCamToleranceTime
|
2
|
s
|
Desviación horaria máxima entre la hora de la cabecera de seguridad del mensaje de concienciación cooperativa (CAM) y el reloj de la estación para aceptar el CAM
|
|
pSecGnScc
|
0
|
n/d
|
Valor del campo SCC (código de país de la estación) de la dirección GN
|
|
pSecGnSourceAddressType
|
0
|
n/d
|
Valor del campo M de la dirección GN (tipo de configuración de la dirección)
|
|
pSecMaxAcceptDistance
|
6
|
km
|
Distancia máxima entre el emisor y el receptor para aceptar mensajes
|
|
pSecMessageToleranceTime
|
10
|
min
|
Desviación horaria máxima entre la hora de la cabecera de seguridad del mensaje (distinto de CAM) y el reloj de la estación para aceptar el mensaje
|
|
pSecRestartDelay
|
1
|
min
|
Período de gracia para el cambio de AT después de activar el terminal de encendido
|
|
pTraceAllowableError
|
0,47
|
m
|
Parámetro para el cálculo del historial de trayecto; para más detalles, véase el apéndice A.5 de la norma [SAE J2945/1]
|
|
pTraceDeltaPhi
|
1
|
°
|
Parámetro para el cálculo del historial de trayecto; para más detalles, véase el apéndice A.5 de la norma [SAE J2945/1]
|
|
pTraceEarthMeridian
|
6 378,137
|
km
|
Radio medio de la Tierra (según la Unión Internacional de Geodesia y Geofísica [IUGG]) Utilizado para el cálculo de rastros; para más detalles, véase el apéndice A.5 de la norma [SAE J2945/1]
|
|
pTraceMaxDeltaDistance
|
22,5
|
m
|
Parámetro para el cálculo de rastros; para más detalles, véase el apéndice A.5 de la norma [SAE J2945/1]
|
2.3.Seguridad
1)Toda estación STI-C vehicular deberá estar vinculada de forma segura a un vehículo concreto. Cuando la estación STI-C vehicular esté energizada, deberá verificar que está funcionando en el vehículo con el que se ha vinculado de forma segura. Si no puede verificarse esta condición correcta de funcionamiento, la estación STI-C deberá desactivarse para impedir que envíe mensajes (es decir, se desactivará por lo menos su nivel de radiotransmisión).
2)La estación STI-C vehicular deberá comprobar el sello de tiempo de la cabecera de seguridad con respecto a la hora de recepción, y aceptar únicamente CAM en la última hora de pSecCamToleranceTime y otros mensajes en la última hora de pSecMessageToleranceTime.
3)La estación STI-C vehicular deberá comprobar la distancia desde la posición del emisor —en la cabecera de seguridad, si está disponible— y reenviar únicamente mensajes con una distancia desde el emisor de pSecMaxAcceptDistance o inferior.
4)La verificación de un mensaje incluirá, como mínimo, la verificación criptográfica de la firma del mensaje.
5)La estación STI-C vehicular reenviará únicamente mensajes verificados.
6)La estación STI-C vehicular utilizará solamente una cabecera de seguridad y una firma de extremo a extremo por mensaje, de conformidad con las normas [TS 103 097] y [EN 302 636-4-1].
7)La firma se generará utilizando una clave privada correspondiente a un AT válido de conformidad con el apartado 7.2.1 de la norma [TS 103 097].
8)Todas las direcciones e identificadores transmitidos a través de la comunicación de corto alcance deberán cambiar cuando cambie el AT.
2.4.Posición y hora
9)Los estados del vehículo deberán ser uniformes. Por consiguiente, el rumbo y la velocidad deberán referirse a la misma hora que la posición absoluta (por ejemplo, GenerationDeltaTime en los CAM).
Nota: Conviene que las inexactitudes que pudieran derivarse de efectos relacionados con la hora se tengan en cuenta en las exactitudes de las variables de estado.
10)La estación STI-C vehicular utilizará el Sistema Geodésico Mundial 1984 (WGS84) como sistema de coordenadas de referencia, tal como se especifica en la norma [TS 102 894-2].
Nota: En vista de la deriva del Sistema de Referencia Terrestre Europeo (ETRS89), que está fijado en la placa continental de Europa, de 2,5 cm/año en el WGS84, hay que señalar que las estaciones STI-C vehiculares han de saber qué sistema de referenciación se utiliza. Cuando se utiliza un sistema de referenciación mejorado, como el de cinemática en tiempo real, para la referenciación de ubicaciones de alta precisión, puede ser necesario compensar esta desviación.
11)La información sobre la altitud se interpretará como altura por encima del elipsoide WGS84.
Nota: No se utilizarán interpretaciones de altitud alternativas con definiciones geoides (por ejemplo, respecto del nivel medio del mar).
12)Para la posición horizontal se utiliza un área de confianza, en lugar de un único intervalo de confianza. El área de confianza se describe como una elipse especificada a través de un eje mayor, un eje menor y la orientación del eje mayor con respecto a la dirección norte, según se define en el punto 10.
13)La estación STI-C vehicular interpretará el «rumbo» como la dirección del componente horizontal del vector de velocidad. El punto de inicio del vector de velocidad será el punto de referencia de la estación STI-C vehicular, según se define en el punto B.19 «referencePosition» de la norma [EN 302 637-2].
Nota: No se utilizarán interpretaciones del rumbo alternativas relacionadas con la orientación de la carrocería del vehículo.
Nota: Esta definición implica que la conducción marcha atrás en línea recta genera una diferencia de 180° entre el rumbo y la orientación de la carrocería del vehículo.
14)La hora STI-C será la base de todos los sellos de tiempo de todos los mensajes transmitidos por la estación STI-C vehicular en todos los Estados miembros de la UE.
15)Cuando estén activas, las estaciones STI-C actualizarán los estados del vehículo con una frecuencia mínima igual a la pPotiUpdateRate.
16)Los sellos de tiempo de los mensajes se basarán en el reloj de la estación.
17)Deberá estimarse la diferencia entre el reloj de la estación y la hora STI-C. Si la diferencia absoluta |hora del reloj de la estación - hora STI-C | >= pPotiMaxTimeDiff, la estación STI-C vehicular no deberá estar activa.
Nota: La existencia de un sello de tiempo preciso no solo es necesaria para la sincronización temporal, sino que implica asimismo que los estados del sistema son válidos en ese preciso momento, es decir, que los estados del vehículo se mantienen uniformes.
18)Cuando se detenga, el sistema deberá comunicar el último valor conocido del rumbo (dirección de movimiento del vehículo). Al volver a ponerse en movimiento, el valor deberá desbloquearse.
2.5.Comportamiento del sistema
19)La estación STI-C vehicular deberá funcionar con el servicio básico de concienciación cooperativa cuando se encuentre en la vía pública y en una dinámica de conducción normal.
Nota: El funcionamiento del servicio básico de concienciación cooperativa incluye la transmisión de CAM si se cumplen todas las condiciones para la generación de estos mensajes.
20)Solo se generarán datos de rastros e historial de trayecto cuando se disponga de información sobre confianza de la posición y el reloj de la estación se ajuste a lo dispuesto en los puntos 90 y 91.
21)El ocupante del vehículo deberá poder desactivar fácilmente la estación STI-C vehicular en cualquier momento.
22)La estación STI-C vehicular deberá tratar las transmisiones de CAM de manera que no se transmitan mensajes obsoletos ni siquiera si se aplica el control de congestión.
2.6.Capa de acceso
23)La estación STI-C vehicular utilizará el canal de control G5-CCH, según se especifica en el cuadro 3 de la norma [EN 302 663], para enviar mensajes en apoyo del servicio básico de concienciación cooperativa y los servicios STI-C prioritarios especificados en el anexo I del presente Reglamento.
24)La capa de acceso de la estación STI-C vehicular deberá ser conforme con la norma [EN 302 663], con excepción de los límites de emisión y de los apartados 4.2.1, 4.5 y 6.
25)La estación STI-C vehicular utilizará una velocidad de transferencia por defecto de pAlDataRateCch en el canal de control.
26)La estación STI-C vehicular será también compatible con velocidades de transferencia pAlDataRateCchLow y pAlDataRateCchHigh en el canal de control.
27)La capa de acceso de la estación STI-C vehicular deberá ser conforme con la norma [TS 102 724].
28)La estación STI-C vehicular deberá ser compatible con los siguientes perfiles del control de congestión descentralizado (DP) definidos en la norma [TS 102 724]: DP0, DP1, DP2 y DP3.
Estos perfiles DCC utilizarán los siguientes valores de identificación del perfil DCC:
DP0, utilizado solo para DENM con TC = 0;
DP1, utilizado para DENM con TC = 1;
DP2, utilizado para CAM con TC = pCamTrafficClass;
DP3, utilizado para DENM reenviados y otros mensajes de baja prioridad.
29)El mecanismo DCC de la estación STI-C vehicular deberá ser conforme con la norma [TS 102 687].
30)Deberán utilizarse los ajustes del cuadro A.2 de la norma [TS 102 687] si se aplica el algoritmo DCC reactivo descrito en el apartado 5.3 de dicha norma.
Nota: El cuadro A.2 de la norma [TS 102 687] se basa en la difusión de CAM y mensajes de notificación ambiental descentralizada (DENM) para los servicios STI-C prioritarios con un valor Ton medio de 500 μs.
31)La siguiente función de suavizado de los valores de razón de canal ocupado (CBR) se realizará si la estación STI-C vehicular utiliza el algoritmo DCC reactivo descrito en el apartado 5.3 de la norma [TS 102 687]: CBR_now = (CBR(n)+CBR(n-1))/2 (
Nota: Donde «n» y «n-1» son los períodos de muestreo CBR actual y anterior, respectivamente).
32)La estación STI-C vehicular deberá ser capaz, como mínimo, de generar y transmitir el número de mensajes determinado por el valor de la velocidad de generación de CAM más elevada (es decir, 10 Hz), que, si se utilizan algoritmos de detección, se incrementará con la velocidad de generación de DENM mínima exigida que se derive de esas condiciones de activación.
33)La estación STI-C vehicular deberá ajustarse a las siguientes cadencias máximas de mensajes si utiliza el algoritmo DCC reactivo descrito en el apartado 5.3 de la norma [TS 102 687]:
en el estado relajado: la suma de todos los mensajes enviados en DP1, DP2 y DP3 no deberá sobrepasar Rmax_relaxed = 16,7 mensajes por segundo; se permiten ráfagas de mensajes para DP0 con RBurst = 20 mensajes por segundo, con una duración máxima de TBurst = 1 segundo, y únicamente cada TBurstPeriod = 10 segundos; así, sumando los mensajes DP0, la cadencia máxima de mensajes es de Rmax_relaxed = 36,7 mensajes por segundo;
en los estados activos: la cadencia máxima de mensajes en cada estado se indica en el cuadro A.2 de la norma [TS 102 687];
en el estado restrictivo: la cadencia máxima de mensajes por estación STI-C vehicular se fija en 2,2 mensajes por segundo, es decir, la inversa de TTX_MAX = 460 ms.
34)La estación STI-C vehicular deberá ser compatible con el control de la potencia de transmisión por paquetes.
Nota: PTx puede depender del estado DCC actual (es decir, relajado, activo o restrictivo) y del perfil DCC (es decir, DP0, DP1, etc.).
35)La estación STI-C vehicular reducirá su potencia de transmisión a PToll = pDccPToll tan pronto como entre en la zona protegida y sin cambiar ningún otro parámetro de transmisión DCC conforme al cuadro A.2 de la norma [TS 102 687]. Los mensajes DP0 se excluyen de esta restricción.
36)Si la estación STI-C vehicular no está equipada con un radiodetector CEN-DSRC según se describe en el apartado 5.2.5 de la norma [TS 102 792], deberá mantener una lista de posiciones de zona protegida según lo descrito en el apartado 5.5.1 de dicha norma. Esta lista estará compuesta por:
un conjunto de zonas de protección según figuren en la «última versión» (disponible cuando se desarrolle el vehículo) de la base de datos de zonas protegidas; la estación STI-C vehicular puede incluir mecanismos de actualización de la base de datos;
un conjunto de zonas protegidas según se identifiquen mediante la recepción de CAM de atenuación CEN-DSRC, conforme a lo descrito en los apartados 5.2.5 y 5.2.2.3 de la norma [TS 102 792];
una zona protegida temporalmente según se identifique mediante la recepción de CAM de atenuación CEN-DSRC, conforme a lo descrito en el apartado 5.2.2.2 de la norma [TS 102 792].
37)Si la estación STI-C vehicular está equipada con un radiodetector CEN-DSRC, se aplicará la atenuación conforme a lo descrito en el apartado 5.2.5 de la norma [TS 102 792], y la estación STI-C generará CAM conforme al apartado 5.5.1 de dicha norma.
38)Si la estación STI-C vehicular no está equipada con un radiodetector CEN-DSRC, se aplicará la atenuación conforme a la norma [TS 102 792] sobre la base de la lista definida en el punto 36 y de los CAM recibidos de otros usuarios de la vía que hayan implementado el punto 37.
Nota: Aclaración del apartado 5.2.5 de la norma [TS 102 792]: Las estaciones STI móviles deben efectuar una atenuación cada vez con respecto a la posición central de la estación de peaje más próxima. Si se dan varias posiciones en la misma zona, conviene que la estación STI móvil responda a cada posición central, posiblemente de forma secuencial. Las zonas protegidas con idéntico identificador protectedZone pueden considerarse una sola estación. Cuando la base de datos de zonas protegidas y los CAM de atenuación CEN-DSRC contengan una zona protegida válida con idéntico identificador protectedZone, la atenuación se basará únicamente en el contenido del CAM de atenuación CEN-DSRC.
2.7.Capa de red y de transporte
39)La parte de GeoNetworking (GN) independiente de los medios de la estación STI-C vehicular deberá ser conforme con la norma [EN 302 636-4-1].
40)Todas las constantes y parámetros por defecto del perfil de la estación STI-C vehicular no definidos o sustituidos en el presente Reglamento se ajustarán conforme a lo especificado en el anexo H de la norma [EN 302 636-4-1].
41)El GN se utilizará con la constante itsGnSecurity ajustada en pGnSecurity.
42)El GN se utilizará con la constante itsGnLocalAddrConfMethod ajustada en pGnAddrConfMode.
43)El parámetro GN itsGnMaxGeoAreaSize se ajustará en pGnMaxAreaSize.
44)El GN no efectuará repetición de paquetes en las estaciones STI-C vehiculares, y tampoco se ejecutarán las correspondientes etapas de repetición en los procedimientos de tratamiento de paquetes descritos en el apartado 10.3 de la norma [EN 302 636-4-1].
El parámetro «tiempo máximo de repetición» de la primitiva de servicio GNDATA.request y la constante de protocolo GN itsGnMinPacketRepetitionInterval no se aplican a las estaciones STI-C vehiculares.
45)El GN se utilizará con la constante itsGnIfType ajustada en pGnInterfaceType.
46)La estación STI-C vehicular utilizará cabeceras de difusión a un salto (SHB), tal como se definen en la norma [EN 302 636-4-1], en todos los paquetes CAM que envíe.
Por consiguiente, la cabecera común GN utilizará un valor de pGnShbHtField para el campo HT y un valor de pGnShbHstField para el campo HST cuando transmita paquetes SHB.
La estación STI-C vehicular utilizará cabeceras GBC, tal como se definen en la norma [EN 302 63641], en todos los paquetes DENM que envíe.
Por consiguiente, la cabecera común GN utilizará un valor de pGnGbcHtField para el campo HT cuando transmita paquetes DENM.
Para el campo HST se utilizará uno de los valores siguientes:
0 para las zonas circulares;
1 para las zonas rectangulares;
2 para las zonas elipsoidales.
Nota: Este perfil se refiere al tratamiento de paquetes SHB y GBC. Puesto que no abarca el tratamiento de otros tipos de paquetes GN definidos en la norma [EN 302 636-4-1], tampoco impide su aplicación.
47)La estación STI-C vehicular ajustará el campo LifeTime de todos los paquetes SHB de la siguiente manera:
el multiplicador de subcampo se ajustará en pGnShbLifeTimeMultiplier y la base de subcampo en pGnShbLifeTimeBase.
48)La estación STI-C vehicular ajustará el campo LifeTime de todos los paquetes GBC en el valor mínimo de ValidityDuration y RepetitionInterval, que se definen en el perfil de servicio pertinente. El valor del campo LifeTime no excederá del parámetro itsGnMaxPacketLifetime, según se especifica en el anexo H de la norma [EN 302 636-4-1].
49)La estación STI-C vehicular almacenará temporalmente los paquetes GBC cuando no haya vecinos disponibles (custodia-transporte-reenvío). En consecuencia, el bit custodia-transporte-reenvío (SCF) del campo TC de los paquetes GBC se ajustará en PGnGbcScScf.
50)No se requiere que la estación STI-C vehicular descargue paquetes en otro canal. Por lo tanto, conviene que el bit de descarga de canal del campo TC se ajuste en pGnChannelOffLoad.
51)La estación STI-C vehicular utilizará los perfiles DCC especificados en el punto 28. Por consiguiente, los bits de identificación del perfil DCC del campo TC utilizarán los valores de identificación del perfil DCC definidos en el punto 28.
52)La estación STI-C vehicular ajustará el bit itsGnIsMobile del campo Flags en pGnIsMobile.
53)La estación STI-C vehicular deberá ser compatible con el modo de funcionamiento multisalto. Deberá ejecutar el algoritmo de reenvío especificado en los anexos D, E.3 y F.3 de la norma [EN 302 63641].
54)Cuando reenvíe paquetes, la estación STI-C vehicular utilizará el valor DP3 del perfil DCC definido en la norma [TS 102 724] y mencionado en el punto 28.
55)La estación STI-C vehicular utilizará la detección de paquetes duplicados en la capa de red y de transporte. En consecuencia, para la detección de paquetes duplicados se utilizará el algoritmo especificado en el anexo A.2 de la norma [EN 302 636-4-1].
56)Todas las secuencias GN enviadas por la estación STI-C vehicular deberán utilizar para el EtherType el valor pGnEtherType según figura en la lista de la autoridad de registro del IEEE, en la dirección http://standards.ieee.org/develop/regauth/ethertype/eth.txt.
57)El protocolo de transporte básico (BTP) de la estación STI-C vehicular deberá ser conforme con la norma [EN 302 636-5-1].
58)La estación STI-C vehicular deberá utilizar cabeceras BTP-B. Por consiguiente, la cabecera común GN deberá utilizar un valor de pGnBtpNh para el campo NH.
59)La estación STI-C vehicular deberá ajustar el campo de información del puerto de destino en el valor pBtpDestPortInfo.
60)En la cabecera BTP-B, la estación STI-C vehicular ajustará el puerto de destino en el valor pBtpCamPort para los CAM.
61)En la cabecera BTP-B, la estación STI-C vehicular ajustará el puerto de destino en el valor pBtpDenmPort para los DENM.
62)La estación STI-C vehicular deberá ser compatible con zonas circulares, rectangulares y elipsoidales, según se definen en la norma [EN 302 931]. Cada caso de uso definido en el perfil de servicio pertinente debe especificar uno de esos tipos de área geográfica, indicado a través de la cabecera GN, como se especifica en la norma [EN 302 636-4-1].
63)Si la estación STI-C vehicular calcula la distancia entre dos posiciones utilizando las coordenadas de Galileo u otro GNSS (por ejemplo, para los PathDeltaPoints o en los casos de zona de relevancia circular), deberá utilizar el método de círculo máximo u otro que dé resultados más exactos.
2.8.Capa de recursos
64)El servicio básico de concienciación cooperativa (CA) de la estación STI-C vehicular deberá ser conforme con la norma [EN 302 637-2].
65)El campo de historial de trayecto del contenedor CAM de baja frecuencia deberá generarse de acuerdo con el método especificado en el punto 86 y contener un elemento de datos PathHistory que cubra una distancia mínima de pCamTraceMinLength (parámetro K_PHDISTANCE_M, según se define en el apéndice A.5 de la norma [SAE J2945/1]).
Solo se hará una excepción con respecto a la distancia mínima cubierta por el elemento PathHistory si:
el vehículo todavía no ha cubierto físicamente la distancia con su actual AT (por ejemplo, después del arranque o inmediatamente después del cambio de AT durante la conducción); o
aunque se utilice el número máximo de PathPoints, la longitud total cubierta por el elemento PathHistory no alcanza el valor pCamTraceMinLength.
Nota: Esto puede ocurrir si la topografía de la carretera contiene curvas cerradas y se reduce la distancia entre PathPoints consecutivos.
Solo en los casos mencionados puede el vehículo enviar información del PathHistory que cubra una distancia inferior a pCamTraceMinLength.
66)El PathHistory de los CAM cubrirá como máximo la longitud pCamTraceMaxLength.
67)El PathHistory de los CAM deberá incluir valores PathDeltaTime en cada PathPoint. Deberá contener una lista de las ubicaciones geográficas realmente recorridas que hayan llevado a la posición actual del vehículo, ordenadas por el momento en que este las alcanzó, y el primer punto será el más próximo temporalmente al momento actual.
68)Cuando la estación STI-C vehicular no esté en movimiento, es decir, cuando la información sobre la posición del PathPoint no varíe, el valor PathDeltaTime del primer PathPoint deberá seguir actualizándose con cada CAM.
69)Cuando la estación STI-C vehicular no esté en movimiento, es decir, cuando la información sobre la posición del PathPoint no varíe, durante un tiempo superior al valor máximo de PathDeltaTime (especificado en la norma [TS 102 894-2]), el valor PathDeltaTime del primer PathPoint del CAM deberá fijarse en el valor máximo.
70)El servicio básico CA deberá estar activo mientras el vehículo se encuentre en la vía pública y en una dinámica de conducción normal. Mientras el servicio básico CA esté activo, se generarán CAM de conformidad con las reglas de generación de la norma [EN 302 637-2].
71)Las estaciones STI-C vehiculares transmitirán CAM cuando se disponga de información sobre confianza de la posición y el reloj de la estación se ajuste a lo dispuesto en el punto 91.
72)El valor TC de los CAM se ajustará en pCamTrafficClass.
73)El parámetro T_GenCam_Dcc (véase la norma [EN 302 637-2]) se ajustará en el valor del tiempo mínimo entre dos transmisiones, Toff, según el cuadro A.2 (mecanismos DCC) de la norma [TS 102 687].
74)El parámetro ajustable N_GenCam (véase la norma [EN 302 637-2]) especificado en la gestión de la frecuencia de generación de CAM se ajustará en pCamGenNumber para la estación STI-C vehicular.
75)El servicio básico de notificación ambiental descentralizada (DEN) de la estación STI-C vehicular deberá ser conforme con la norma [EN 302 637-3].
76)La repetición de DENM será realizada por el servicio básico DEN, como se especifica en la norma [EN 302 637-3].
77)El campo de historial de trayecto de los mensajes DEN deberá generarse de acuerdo con el método especificado en el punto 86 y contener un elementos de datos de rastros que cubran una distancia mínima de pDenmTraceMinLength (parámetro K_PHDISTANCE_M, según se define en el apéndice A.5 de la norma [SAE J2945/1]).
Solo se hará una excepción con respecto a la distancia mínima cubierta por el elemento de rastros si:
el vehículo todavía no ha cubierto físicamente la distancia con su actual AT (por ejemplo, después del arranque o inmediatamente después del cambio de AT durante la conducción); o
aunque se utiliza el número máximo de PathPoints, la longitud total cubierta por el elemento PathHistory no alcanza el valor pDenmTraceMinLength.
Nota: Esto puede ocurrir si la topografía de la carretera contiene curvas cerradas y se reduce la distancia entre PathPoints consecutivos.
Solo en los dos casos mencionados puede el vehículo enviar información de rastros que cubra una distancia inferior a pDenmTraceMinLength.
78)Los rastros de los DENM cubrirán como máximo la longitud pDenmTraceMaxLength.
79)Las estaciones STI-C vehiculares utilizarán los rastros de los DENM como sigue:
el primer elemento de rastros describirá una lista cronológica de las ubicaciones geográficas realmente recorridas que han llevado a la posición del evento, según se especifica en el punto 67.
80)Los elementos de datos PathDeltaTime de los PathPoints del primer elemento de rastros DENM solo se actualizarán si se actualiza el DENM.
81)Cuando el vehículo que detecte el evento no esté en movimiento, es decir, cuando la información sobre la posición del PathPoint no varíe, el valor PathDeltaTime del primer PathPoint del primer elemento de rastros DENM deberá seguir actualizándose con cada DEN_Update.
Nota: Este caso solo se da con eventos estacionarios en los que el vehículo detector es idéntico al evento, por ejemplo una advertencia de vehículo parado. Esto no ocurre en el caso de eventos dinámicos, por ejemplo situaciones peligrosas o eventos que no son idénticos al vehículo (advertencias de condición meteorológica adversa, etc.).
82)Cuando la estación STI-C vehicular no esté en movimiento, es decir, cuando la información sobre la posición del PathPoint no varíe, durante un tiempo superior al valor máximo de PathDeltaTime (especificado en la norma [TS 102 894-2]), el valor PathDeltaTime del primer PathPoint del primer elemento de rastros DENM deberá fijarse en el valor máximo.
83)En los rastros DENM puede haber elementos de PathHistory adicionales. No obstante, a diferencia del primer elemento, estos describirán rutas alternativas al lugar del evento. Estas rutas pueden estar o no disponibles en el momento de detectarse el evento. En las rutas alternativas, los PathPoints se ordenarán por posición (es decir, rutas del trayecto más corto) y no incluirán el PathDeltaTime.
84)Para los servicios prioritarios, la estación STI-C vehicular solo generará DENM como se describa en el perfil de servicio pertinente.
85)Los elementos de datos que constituyen el contenido de los CAM y los DENM deberán ser conformes con la norma [TS 102 894-2] y utilizar el sistema de coordenadas especificado en los puntos 87, 10 y 11.
86)Los rastros y los historiales de trayecto utilizados por la estación STI-C vehicular deberán generarse utilizando el método de diseño uno, según se especifica en el apéndice A.5 de la norma [SAE J2945/1]. La estación STI-C vehicular utilizará este método de generación con los siguientes ajustes:
K_PHALLOWABLEERROR_M = pTraceAllowableError, donde PH_ActualError < K_PHALLOWABLEERROR_M;
distancia máxima entre puntos de trayecto concisos, K_PH_CHORDLENGTHTHRESHOLD = pTraceMaxDeltaDistance;
K_PH_MAXESTIMATEDRADIUS = REarthMeridian;
K_PHSMALLDELTAPHI_R = pTraceDeltaPhi;
REarthMeridian = pTraceEarthMeridian (según la IUGG), utilizado para el cálculo de la distancia de círculo máximo u ortodrómica;
PH_ActualChordLength =
REarthMeridian*cos-1[cos(lat1)cos(lat2)cos(long1-long2)+sin(lat1)sin(lat2)]
87)La estación STI-C vehicular deberá utilizar un sistema de coordenadas conforme con la sección 2.13 de la norma [ISO 8855].
Nota: Esto significa que los ejes X e Y son paralelos al plano del suelo; el eje Z está alineado verticalmente hacia arriba, el eje Y apunta a la izquierda de la dirección de avance del vehículo y el eje X apunta en la dirección de circulación hacia delante del vehículo.
2.9.Requisitos relacionados con el hardware
88)El valor de confianza del 95 % [véanse el punto 2.1, letra b), y el punto 12] será válido en cada situación enumerada en el punto 92. Esto implica que, en un ensayo de evaluación del valor de confianza (que puede ser fuera de línea), no es adecuado un promediado estadístico de todos los estados y situaciones.
En su lugar, deberá utilizarse como base estadística una ventana deslizante que contenga los estados del vehículo [véase el punto 2.1, letra a)] de los últimos segundos pPotiWindowTime.
Nota: El mecanismo propuesto de validación de la confianza por medio de la ventana deslizante suele realizarse fuera de línea, como posprocesamiento de los datos recogidos en los ensayos. No es necesario que la estación STI-C vehicular realice una validación de la confianza en línea, es decir, mientras se encuentra en la vía pública y en una dinámica de conducción normal.
Nota: El enfoque de ventana deslizante tiene las siguientes ventajas sobre el de estadísticas por separado para cada situación:
se incluyen las transiciones entre situaciones;
la confianza es válida «ahora» en lugar de «a lo largo de la vida útil»; no están permitidas las «ráfagas de errores» (muchos valores de confianza no válidos en un breve espacio de tiempo), lo que:
mejora la utilidad del valor de confianza para las aplicaciones;
exige una detección rápida de la degradación de la exactitud dentro de PoTi;
la definición precisa de los datos de ensayo no afecta a los parámetros de validación de la confianza; sin embargo, los datos de ensayo deberán incluir todas las situaciones enumeradas en el punto 92;
no se requieren cálculos estadísticos adicionales; las situaciones cubren todos los estados pertinentes;
la longitud del intervalo es similar a las longitudes de las situaciones (por ejemplo, túnel urbano, detención ante un semáforo o maniobras de conducción) típicas (entorno y condición de circulación);
el 5 % del intervalo es similar a los efectos típicos breves (por ejemplo, conducción bajo un puente).
89)Se considera que un vehículo se encuentra en una dinámica de conducción normal cuando:
ha superado su fase inicial de arranque;
se está utilizando según lo previsto por el fabricante;
es posible tenerlo normalmente controlado (por ejemplo, no está directamente involucrado en un accidente, o la superficie de la calzada permite la adherencia normal de los neumáticos);
todas las condiciones (valores) siguientes se aplican a los turismos:
la aceleración lateral del vehículo es < 1,9 m/s2;
la aceleración longitudinal del vehículo es > - 2,4 m/s2 (desaceleración);
la aceleración longitudinal del vehículo es < 2,5 m/s2;
la velocidad del vehículo es < = mínima de (130 km/h, Vmax).
90)En condiciones GNSS óptimas y con una dinámica de conducción normal, según se define en el punto 89, los valores de confianza deberán ser iguales o inferiores a los siguientes valores en al menos el 95 % de los puntos de datos de posición en 3D de un conjunto de datos:
confianza de la posición horizontal de 5 m;
confianza de la posición vertical de 20 m.
En otras situaciones se aplican las degradaciones requeridas del punto 92. Este requisito garantiza la utilidad de la información enviada en todos los mensajes STI-C.
91)El reloj de la estación deberá estar dentro de pPotiMaxTimeDiff respecto a la hora STI-C, es decir, Delta t = |hora del reloj de la estación - hora STI-C| < pPotiMaxTimeDiff.
92)Las estaciones STI-C vehiculares deberán ser capaces de proporcionar estimaciones útiles de los estados del vehículo, incluso en situaciones difíciles. Para tener en cuenta las degradaciones inevitables, en el cuadro 2 se recogen los valores de confianza requeridos para distintas situaciones.
«C» es el máximo de semiMajorConfidence y semiMinorConfidence. La condición para «C» deberá cumplirse en el 95 % de los puntos de datos del conjunto de datos de la situación dada.
Nota: Los criterios deberán cumplirse con la siguiente dinámica de pendiente respecto de la fracción de rastro analizada: pendiente media < = 4 % y pendiente máxima < = 15 %.
Nota: Como condición previa, cada situación se iniciará con un minuto de conducción a cielo abierto y con una dinámica de conducción normal.
Nota: La ausencia de valores C indica que la situación se ensayará para garantizar que el intervalo de confianza comunicado es válido, pero sin dar límites.
Cuadro 2: Situaciones
|
ID
|
Situación
|
Definición
|
Aceptación
|
|
Entorno con una dinámica de conducción normal
|
|
S1
|
Cielo abierto
|
La obstrucción del cielo es inferior al 20 %, y el vehículo se desplaza con una dinámica de conducción normal y en condiciones normales de la carretera.
|
C <= 5 m
|
|
S2
|
Túnel
|
Ningún satélite GNSS visible en por lo menos 30 s y 250 m (vmin = 30 km/h); reflexión de la señal GNSS a la entrada y al final del túnel.
|
C < 15 m
|
|
S3
|
Estructura de aparcamiento
|
Ningún satélite GNSS visible directamente, pero conexión por reflexión, T > 60 s, vmax < 20 km/h, como mínimo dos curvas de 90° y s > 100 m, dos rampas en las zonas de entrada y salida.
|
Se permite cualquier valor.
|
|
S4
|
Cielo semiabierto
|
La obstrucción del cielo es del 30 al 50 % (obstrucción concentrada en un lado del coche) durante más de 30 s; condiciones de conducción como en S1.
|
C < 7 m
|
|
S5
|
Bosque
|
La obstrucción del cielo es del 30 al 50 % debido a la presencia de objetos, en particular árboles más altos que la antena, durante más de 30 s.
|
C < 10 m
|
|
S6
|
Montañas (valle)
|
La obstrucción del cielo es del 40 al 60 % debido a la presencia de altas montañas; condiciones de conducción como en S1.
|
C < 10 m
|
|
S7
|
Ciudad
|
Durante una conducción de 300 s, la obstrucción del cielo fue del 30 al 50 % (se permiten cortos períodos de obstrucciones de menos del 30 al 50 %), con frecuentes reflexiones de la señal GNSS causadas por edificios, incluidas breves pérdidas de la señal GNSS (es decir, menos de cuatro satélites); condiciones de conducción como en S1.
|
C < 14 m
|
|
S8
|
Urbana moderada
|
Obstrucción del cielo del 20 al 40 %, t > 60 s, s > 400 m; condiciones de conducción como en S1, con paradas, árboles o edificios, así como avenidas.
|
C < 10 m
|
|
Condiciones de conducción a cielo abierto
|
|
S9
|
Conducción dinámica
|
Recorrido de ensayo con aceleraciones longitudinales de más de - 6 m/s² y aceleraciones laterales > (±) 5 m/s².
|
C < 7 m
|
|
S10
|
Estática
|
Vehículo quieto durante 30 min.
|
C < 5 m
|
|
S11
|
Calzada difícil
|
Recorrido de ensayo sobre una calzada sucia con baches, v = 20-50 km/h
|
C < 10 m
|
|
S12
|
Calzada helada
|
Recorrido de ensayo con aceleraciones longitudinales de más de - 0,5 m/s² y aceleraciones laterales > (±) 0,5 m/s², µ < 0,15.
|
C < 7 m
|
|
S13
|
Velocidad alta
|
V = mínimo de (130 km/h, Vmax) sobre una calzada seca durante 30 s
|
C < 5 m
|
93)En condiciones GNSS óptimas y con una dinámica de conducción normal, según se define en el punto 89, los valores de confianza de la velocidad deberán ser iguales o inferiores a los siguientes valores en al menos el 95 % de los puntos de datos de un conjunto de datos:
0,6 m/s para velocidades de entre 1,4 y 12,5 m/s;
0,3 m/s para velocidades superiores a 12,5 m/s.
94)En condiciones GNSS óptimas y con una dinámica de conducción normal, según se define en el punto 89, los valores de confianza del rumbo deberán ser iguales o inferiores a los siguientes valores en al menos el 95 % de los puntos de datos de un conjunto de datos:
3° para velocidades de entre 1,4 y 12,5 m/s;
2° para velocidades superiores a 12,5 m/s.
3.Requisitos aplicables a las estaciones STI-C viarias diseñadas para la comunicación de corto alcance
Este perfil de sistema especifica un conjunto mínimo de normas y colma las lagunas pertinentes para la realización de una estación STI-C viaria interoperable en el lado de la transmisión. El perfil incluye únicamente los requisitos de interoperabilidad, dejando abierta la posibilidad de añadir requisitos adicionales. No describe, por tanto, la funcionalidad completa de la estación STI-C viaria.
Este perfil de sistema permite la implantación de los servicios prioritarios (en particular, I2V). Puede servir de apoyo a otros servicios, pero estos pueden requerir especificaciones de sistema adicionales.
El perfil proporciona descripciones, definiciones y reglas para las capas (aplicaciones, recursos, redes, transporte y acceso) y la gestión de la arquitectura de referencia de la estación STI ETSI o el servidor de la estación STI.
3.1.Posición y hora
95)La hora STI-C de una estación STI-C viaria estática constituirá la base de todos los sellos de tiempo en todos los mensajes transmitidos y las balizas GN.
Nota: Esto significa que los sellos de tiempo de la cabecera GN deben utilizar el mismo reloj y la misma base horaria que los sellos de tiempo de las cargas útiles CAM/DENM/IVIM. En el caso de SPATEM y MAPEM, conviene que el sello de tiempo utilizado se ajuste a lo especificado en la norma [ISO TS 19091].
96)La posición de las estaciones STI-C viarias estáticas deberá medirse con exactitud y fijarse de manera permanente.
Los valores de confianza deberán ser iguales o inferiores a los valores siguientes en al menos el 95 % de los conjuntos de datos:
confianza de la posición horizontal (latitud y longitud) de 5 m;
confianza de la posición vertical de 20 m.
Nota: Se evita así la inestabilidad del GNSS en cuanto a exactitud de la posición y se aumenta la confianza a cerca del 100 %.
97)Deberá estimarse la diferencia entre el reloj de la estación y la base horaria. La diferencia absoluta |hora del reloj de la estación - base horaria| no debería exceder de 20 ms, y en todo caso debe ser inferior a 200 ms. La estación STI-C viaria no deberá transmitir mensajes si la hora de su reloj difiere en más de 200 ms.
Nota: La existencia de un sello de tiempo preciso no solo es necesaria para la sincronización temporal, sino que implica asimismo que los estados del sistema son válidos en ese preciso momento, es decir, que los estados del sistema se mantienen uniformes.
Nota: La información para la sincronización temporal puede obtenerse de un receptor de Galileo u otro receptor GNSS, o de un servicio de protocolo de sincronización de la red (NTP).
3.2.Comportamiento del sistema
98)Todas las estaciones STI-C viarias deberán ser capaces de transmitir los mensajes de infraestructura (por ejemplo, DENM, CAM, mensajes de información de infraestructura a vehículo [IVIM], mensajes extendidos de fase y temporización de señales [SPATEM], mensajes extendidos de MAP [MAPEM] y mensajes extendidos de situación de la petición de señales [SSEM]).
99)Las estaciones STI-C viarias deberán ser capaces de recibir DENM, CAM y mensajes extendidos de petición de señales (SREM), de acuerdo con el punto 3.6.
3.3.Capa de acceso
La capa de acceso comprende las dos capas más bajas de la memoria temporal de protocolo, es decir, las capas física (PHY) y de enlace de datos, y esta última se subdivide a su vez en control de acceso del medio (MAC) y control de enlace lógico (LLC).
100)Las estaciones STI-C viarias deberán utilizar los requisitos opcionales de rendimiento mejorado del receptor que se definen en los cuadros 17 a 19 de la norma IEEE 802.11.
101)Las estaciones STI-C viarias deberán utilizar el canal de control G5-CCH, según se especifica en el cuadro 3 de la norma [EN 302 663], para enviar mensajes en apoyo de los servicios STI-C prioritarios especificados en el anexo 3, utilizando una velocidad de transferencia por defecto de 6 Mbit/s (QPSK 1/2).
102)La capa de acceso de las estaciones STI-C viarias deberá ser conforme con la norma [EN 302 663], con excepción de los límites de emisión y de los apartados 4.2.1, 4.5 y 6.
103)Las estaciones STI-C viarias deberán ser conformes con la norma [TS 102 687].
104)Las estaciones STI-C viarias deberían gestionar los escasos recursos de hardware y software de que disponen, y pueden realizar una configuración del tráfico o un reenvío selectivo en consonancia con el principio del «mejor esfuerzo».
Nota: La configuración del tráfico es especialmente pertinente para los mensajes DENM retransmitidos, pues se prevé que, en algunas situaciones (como una grave congestión del tráfico u otras situaciones extremas de la red vehicular), la carga de DENM pueda aumentar de manera abrupta. En tales casos, se permite explícitamente que las estaciones STI-C viarias no reenvíen mensajes DENM ajenos.
105)Las estaciones STI-C viarias deberán ser capaces, como mínimo, de generar y transmitir el número de mensajes determinado por el valor de la velocidad de generación de CAM más elevada (es decir, 10 Hz) y, si se utilizan algoritmos de detección, incrementada con la velocidad mínima exigida de generación de DENM que se derive de esas condiciones de activación.
106)Las estaciones STI-C viarias deberán ser compatibles con el modo de difusión definido en la norma [EN 302 663].
107)La zona protegida se definirá como sigue:
cuando una ubicación de peaje esté compuesta por una sola unidad viaria (RSU) CEN-DSRC, deberá definirse una zona protegida con un radio por defecto de 55 m, con la ubicación de la RSU CEN-DSRC como posición central;
en caso de que haya varias RSU CN-DSRC próximas, conviene evitar en lo posible los solapamientos de zonas protegidas por medio de una zona protegida combinada. La zona protegida combinada utilizará como posición central el centro geográfico (circuncentro) de todas las RSU DSRC afectadas; el radio vendrá dado por el circunradio + 55 m. En cualquier caso, no se superará un radio máximo de 255 m.
Nota: Debido al radio máximo de 255 m, no siempre son evitables los solapamientos.
108)Cuando una estación STI-C viaria esté situada cerca de un equipo de peaje basado en CEN-DSRC (al menos dentro de la zona protegida), deberá aplicar técnicas de mitigación según se definen en la norma [TS 102 792].
109)Las estaciones STI-C viarias móviles deberán aplicar métodos de mitigación basados en mensajes de anuncio de zona de peaje.
110)Cuando la estación STI-C viaria se utilice para indicar la presencia de una estación de peaje, deberá transmitir CAM que incluyan las zonas protegidas de acuerdo con la técnica definida en la norma [TS 102 792] y con el formato de mensaje CA que se especifica en la norma [EN 302 637-2]. Deberá transmitir esos CAM en el canal de control, antes de que una estación STI-C vehicular entre en la zona protegida.
111)La capa de acceso de las estaciones STI-C viarias deberá ser conforme con la norma [TS 102 724].
112)Las estaciones STI-C viarias deberán aplicar técnicas DCC de conformidad con la norma [TS 102 687].
3.4.Capa de red y de transporte
113)Las estaciones STI-C viarias deberán aplicar el GN como protocolo de red de acuerdo con la norma [EN 302 636-4-1].
114)Todas las constantes y parámetros por defecto del perfil viario de la infraestructura no especificados en el presente anexo se ajustarán conforme a lo especificado en el anexo H de la norma [EN 302 636-4-1].
115)El GN no efectuará repetición de paquetes, y tampoco se ejecutarán las correspondientes etapas en los procedimientos de tratamiento de paquetes definidos en el apartado 10.3 de la norma [EN 302 63641]. El parámetro «tiempo máximo de repetición» de la primitiva de servicio GNDATA.request y la constante de protocolo GN itsGnMinPacketRepetitionInterval no se aplican.
116)Las estaciones STI-C viarias pueden escoger la constante «dirección anónima» para la configuración de la dirección GN [itsGnLocalAddrConfMethod ajustada en ANONYMOUS(2)].
117)Las estaciones STI-C viarias deberán utilizar el GN con itsGnIfType ajustado en ITS-G5(1).
118)Cuando está desactivada la repetición de paquetes, la constante itsGnMinPacketRepetitionInterval no es aplicable.
119)El campo LifeTime de todos los paquetes SHB se ajustará en un segundo.
120)El campo LifeTime de todos los paquetes GBC se ajustará en los valores mínimos de ValidityDuration y RepetitionInterval, pero no excederá del parámetro itsGnMaxPacketLifetime, especificado en el anexo H de la norma [EN 302 636-4-1].
121)Cuando esté activado el campo «custodia-transporte-reenvío», el bit SCF del campo TC se ajustará en uno.
Nota: En consecuencia, los paquetes pueden almacenarse temporalmente si no hay vecinos disponibles.
122)No se requiere que las estaciones STI-C viarias descarguen paquetes en otro canal. Por consiguiente, conviene que el bit de descarga de canal del campo TC se ajuste en 0 para todos los tipos de mensaje.
123)Las estaciones STI-C viarias estacionarias ajustarán el bit itsGnIsMobile del campo Flags en 0. Las estaciones STI-C viarias móviles ajustarán el bit itsGnIsMobile del campo Flags en 1.
124)Las estaciones STI-C viarias deberán ser compatibles con el modo de funcionamiento multisalto, utilizando los algoritmos especificados en los anexos E.3 y F.3 de la norma [EN 302 636-4-1], basados en los principios de selección indicados en su anexo D.
125)Las estaciones STI-C viarias utilizarán la detección de paquetes duplicados en la capa de red y de transporte. Para la detección de paquetes duplicados se utilizará el algoritmo especificado en el anexo A.2 de la norma [EN 302 636-4-1].
126)Las estaciones STI-C viarias solo pueden enviar balizas GN con el indicador de exactitud de la posición (PAI) ajustado en 1.
127)Todas las secuencias GN enviadas por la estación STI-C viaria deberán utilizar el valor EtherType 0x8947 según figura en la lista de la autoridad de registro del IEEE, en la dirección http://standards.ieee.org/develop/regauth/ethertype/eth.txt.
128)Las estaciones STI-C viarias deberán ejecutar el BTP de conformidad con la norma [EN 302 636-5-1].
129)Las estaciones STI-C viarias deberán utilizar cabeceras BTP-B. Por consiguiente, la cabecera común GN deberá utilizar un valor de 2 para el campo NH.
130)Las estaciones STI-C viarias deberán ajustar el campo de información del puerto de destino en el valor 0.
131)Las estaciones STI-C viarias deberán fijar el puerto de destino en función del mensaje ajustado según se especifica en la norma [TS 103 248].
132)Las áreas geográficas se aplicarán de acuerdo con la norma [EN 302 931].
133)Las estaciones STI-C viarias deberán ser compatibles por lo menos con zonas circulares, rectangulares y elipsoidales, según se definen en la norma [EN 302 931]. Cada servicio STI-C deberá especificar uno de esos tipos de área geográfica, indicado a través de la cabecera GN, según se especifica en la norma [EN 302 636-4-1].
134)Si la estación STI-C viaria calcula la distancia entre dos posiciones utilizando las coordenadas de Galileo u otro GNSS (por ejemplo, para los PathDeltaPoints o en los casos de zona de relevancia circular), se recomienda utilizar el método de círculo máximo u otro que dé resultados más exactos. Deberá procurarse evitar grandes errores de redondeo en los sistemas de coma flotante poco precisos (por ejemplo, utilizando la fórmula del semiverseno).
Cuando la zona de relevancia es una elipse o un rectángulo, deben calcularse las coordenadas cartesianas del centro de la zona y de la posición actual para determinar si se hace saltar el paquete como se especifica en la norma [TS 102 894-2]. A estos efectos se recomienda el método del «plano tangente local», u otro que ofrezca la misma exactitud.
3.5.Capa de recursos
135)El servicio básico DEN de las estaciones STI-C viarias deberá ser conforme con la norma [EN 302 637-3].
136)Las estaciones STI-C viarias deberán ejecutar la repetición de DENM como se especifica en la norma [EN 302 637-3].
137)Los casos en que se activan las actualizaciones de DENM se especifican en el perfil de servicio pertinente del anexo I.
138)Cuando una estación STI-C viaria envíe un DENM, los rastros se describirán en forma de lista de las ubicaciones geográficas que conducen de vuelta desde la posición del evento hasta el primer punto de trayecto.
139)Cuando una estación STI-C viaria móvil se pare, el PathDeltaTime del primer PathPoint del primer elemento de rastros DENM se fijará en el valor máximo especificado en la norma [EN 302 637-3]. Por lo tanto, los PathPoints no «quedan excluidos» del primer elemento de rastros DENM. Esto se aplica únicamente a los servicios STI-C basados en remolques.
140)En los rastros DENM puede haber elementos de PathHistory adicionales. No obstante, a diferencia del primer elemento, estos describirán rutas alternativas al lugar del evento. Estas rutas pueden estar o no disponibles en el momento de detectarse el evento.
141)En el caso de las estaciones STI-C viarias, el valor TC de un mensaje es específico del servicio de base del formato de mensaje o del propio servicio STI-C y, por tanto, se especifica en el perfil de servicio pertinente del anexo I. El valor TC seleccionado deberá ser conforme con las clasificaciones de mensajes especificadas en las normas [TS 102 636-4-2] y [TS 103 301], con la salvedad de que los mensajes de información de infraestructura a vehículo (IVI) relacionados con los límites de velocidad variables equivalen a DENM de baja prioridad y, por tanto, pueden tener el mismo valor TC.
142)El sistema viario deberá utilizar un sistema de coordenadas conforme con el apartado 2.13 de la norma [ISO 8855].
Nota: Esto significa que los ejes X e Y son paralelos al plano del suelo; el eje Z está alineado verticalmente hacia arriba, el eje Y apunta a la izquierda de la dirección de avance del vehículo y el eje X apunta en la dirección de circulación hacia delante del vehículo.
143)Para la transmisión de mensajes por los sistemas viarios, el protocolo de la capa de recursos y el ajuste del perfil de comunicación CPS_001 deberán utilizarse de conformidad con la norma [TS 103 301].
144)Los datos de zona protegida facilitados en un CAM enviado por una estación STI-C viaria no deberán entrar en conflicto con la información de zona protegida facilitada en la base de datos de zonas protegidas o una base de datos equivalente. Si la misma zona está definida en la base de datos de zonas protegidas, deberá utilizarse el mismo identificador como protectedZoneID. De lo contrario, deberá emplearse un identificador superior a 67108863 que no se utilice en la base de datos.
145)Las estaciones STI-C viarias destinadas a la difusión de datos de zona protegida deberán transmitir con regularidad CAM que contengan datos de zona protegida utilizando el formato de mensaje especificado por la norma [EN 302 637-2]. No se utiliza la terminación de CAM.
Nota: Los elementos de datos específicos para el servicio STI-C de coexistencia se localizan en el highFrequencyContainer y en la secuencia de datos rsuContainerHighFrequency.
Nota: Los CAM pueden contener otros elementos de datos no relacionados con el servicio STI-C de coexistencia.
146)La antena de una estación STI-C viaria destinada a difundir datos de zona protegida deberá colocarse de forma que los CAM de zona de protección puedan recibirse a tiempo antes de la entrada en la zona protegida.
Nota: Las medidas para cumplir este requisito deben tener en cuenta el tiempo que el equipo del usuario de la vía necesita para procesar la información recibida. Como referencia conviene utilizar un lapso de 300 ms.
147)Las estaciones STI-C viarias destinadas a difundir datos de zona protegida deberán transmitir CAM que contengan datos de zona protegida con una frecuencia de transmisión que garantice que las estaciones STI-C móviles puedan detectar a tiempo la presencia de zonas protegidas.
148)Las estaciones STI-C viarias destinadas a difundir datos de zona protegida deberán instalarse fuera de las zonas protegidas o configurarse conforme a la norma [TS 102 792].
149)Los CAM no deberán contener más de una zona protegida temporal (es decir, ProtectedCommunicationZone con ProtectedZoneType=1).
Nota: Esto es específico de los puestos de peaje temporales y de los vehículos policiales. Las estaciones STI-C móviles han de almacenar una sola zona protegida temporal de conformidad con el apartado 5.2.2.2 de la norma [TS 102 792], a fin de evitar ambigüedades.
150)Si se utiliza el servicio de capa de recursos de coexistencia (ITS-G5 y CEN-DSRC), deberá aplicarse de conformidad con la norma [EN 302 637-2] y según lo especificado en la norma [TS 102 792].
151)La norma [ISO/TS 19321] se refiere a una versión anterior (1.2.1) de la norma [TS 102 894-2], relativa al diccionario de datos comunes (CDD) para los datos de carga útil. Por lo tanto, todos los servicios STI-C IVI basados en la norma [ISO/TS 19321] deberán basarse en la versión actualizada (1.3.1), hasta que esta norma se actualice en consecuencia.
152)El servicio básico CA deberá estar activo mientras la estación STI-C viaria móvil esté participando en la vía pública con una dinámica de conducción normal. Mientras el servicio básico CA esté activo, deberán generarse CAM de conformidad con las reglas de generación de la norma [EN 302 637-2].
153)Las estaciones STI-C viarias deberán transmitir CAM cuando se disponga de información sobre confianza de la posición y el reloj de la estación se ajuste a lo dispuesto en el punto 97.
154)El parámetro T_GenCam_Dcc se ajustará en el valor del tiempo mínimo transcurrido entre dos transmisiones, Toff, según lo facilite el mecanismo DCC especificado en el punto 103.
155)El parámetro N_GenCam ajustable especificado en la gestión de la frecuencia de generación de CAM se ajustará en 0 para la estación STI-C viaria, a menos que esta esté destinada a difundir datos de zona protegida conforme al punto 145.
3.6.Gestión
No es preciso implementar todos los servicios de seguridad especificados. Además, en el caso de algunos servicios, el operador de la estación STI-C define internamente la implementación.
156)Las estaciones STI-C viarias que ejecuten funciones ITS-G5 deberán ejecutar una capa de gestión que incluya una entidad DCC_CROSS conforme a lo especificado en la norma [TS 103 175].
3.7.Elementos del servicio
3.7.1.Servicio básico DEN
El servicio básico DEN utiliza los servicios proporcionados por las entidades protocolarias de la capa de red y de transporte STI para difundir DENM.
Un DENM contiene información sobre un evento que puede tener un impacto en la seguridad vial o en las condiciones del tráfico. Un evento se caracteriza por su tipo, su posición, la hora de detección y la duración. Estos atributos pueden cambiar en el espacio y en el tiempo. En algunas situaciones, la transmisión de DENM puede ser independiente de la estación STI-C de origen.
El servicio básico DEN genera cuatro tipos de DENM:
•
DENM nuevos;
•
DENM de actualización:
•
DENM de cancelación;
•
DENM de negación.
157)La cabecera DENM deberá ser como se especifica en el diccionario de datos de la norma [TS 102 894-2].
158)Los elementos de datos DENM, las secuencias de datos y los parámetros de servicio se ajustarán de conformidad con el cuadro 3. Además, en el caso de servicios STI-C sobre advertencias de obras, las secuencias de datos DENM y los parámetros de servicio deberán ajustarse de conformidad con el cuadro 4.
Cuadro 3: Elementos DENM en general
|
Nombre
|
Utilización
|
Modo de empleo
|
|
Management container
|
Obligatoria
|
|
|
actionID
|
Obligatoria
|
Contenido:
El actionID es el identificador único de un DENM y se compone de los elementos de datos originatingStationID y sequenceNumber. El elemento originatingStationID es el identificador único de la estación STI-C cuya capa de recursos ha creado el mensaje, que puede ser tanto la estación STI-C central como la estación STI-C viaria. Si no los establece la estación STI-C central, los mensajes cuyo contenido se genere centralmente, pero que sean difundidos desde diversas estaciones STI-C viarias, tendrán diferentes elementos originatingStationID, y por consiguiente diferentes actionID.
Si los elementos originatingStationID y sequenceNumber vienen dados por la estación STI-C central y el contenido generado centralmente es (potencialmente) enviado a través de múltiples estaciones STI-C viarias, el sistema proporciona el mismo actionID para todos los mensajes relacionados con el mismo evento, sea cual sea la estación STI-C viaria que esté enviando el mensaje. Una vez establecido el actionID, no cambiará para los mensajes relacionados con el mismo evento, aunque se actualicen con frecuencia.
Valor:
no predefinido, establecido por el sistema
|
|
detectionTime
|
Obligatoria
|
Inicialmente, este elemento de datos se ajustará en la hora a la que se detectó el evento. La hora deberá proceder de una fuente de hora local en la estación STI-C viaria, en situaciones de casos de utilización autónomas. En situaciones de casos de utilización con conexión a la estación STI-C central, el elemento detectionTime se ajustará inicialmente en la hora a la que la aplicación que crea el DENM recibe la información pertinente, es decir, el momento en que comienzan o se detectan a nivel funcional una obra en la calzada o una ubicación peligrosa.
Valor:
el elemento detectionTime se ajusta inicialmente en la hora de inicio del evento (DENM nuevo), y luego se reinicia con cada actualización del DENM. Respecto a la terminación del DENM, este elemento de datos será la hora a la que se detecte la terminación del evento.
|
|
referenceTime
|
Obligatoria
|
Contenido:
El elemento referenceTime se ajustará en la hora a la que se genere o actualice el DENM.
Valor:
Ajuste automático
|
|
termination
|
Opcional
|
Específica del servicio STI-C
|
|
eventPosition
|
Obligatoria
|
En la situación de casos de utilización I2V, la secuencia de datos eventPosition se utiliza para localizar bloqueos de carril o calzada o ubicaciones peligrosas. Representa la posición donde comienzan el bloqueo físico del carril (incluido el arcén) o la calzada o la ubicación peligrosa. La exactitud debería ser a nivel de carril, pero como mínimo deber ser a nivel de calzada.
Pueden utilizarse elementos de datos de altitud y confianza, o pueden ajustarse en los valores correspondientes a «no disponible».
|
|
relevanceDistance
|
Opcional
|
Opcional
|
|
relevanceTrafficDirection
|
Obligatoria
|
Contenido:
Valor fijo. Para las autopistas, este valor se ajusta en 1 (tráfico por detrás).
Esta secuencia de datos indica para qué sentido del tráfico es pertinente el mensaje (desde la perspectiva de la eventPosition).
|
|
validityDuration
|
Obligatoria
|
Los eventos están representados con mensajes DEN. La duración de un solo DENM se basa en el valor (configurable) de validityDuration. Mientras un evento sea válido para el explotador de la carretera, se enviará (mediante repetición de DENM) y actualizará (mediante actualización de DENM y renovación de validityDuration, detectionTime y referenceTime en el proceso) continuamente. La actualización de un mensaje se activará si el valor validityDuration cae por debajo de un determinado umbral (también configurable). Si el evento ya no es válido, o bien expira o bien se cancela activamente (cancelación de DENM).
Contenido:
El elemento de datos validityDuration se ajusta en un valor fijo.
Valor:
Específico del servicio STI-C.
|
|
TransmissionInterval
|
No se utiliza
|
No se utiliza
|
|
stationType
|
Obligatoria
|
Contenido:
Valor fijo, ajustado en 15 (roadSideUnit). Esto es así en el caso de las estaciones STI-C viarias fijas y móviles. El valor puede ser 9 (remolque) o 10 (specialVehicles) en el caso de los vehículos del explotador de la carretera.
Valor:
Ajustado en 9, 10 o 15.
|
|
Situation container
|
Obligatoria
|
|
|
informationQuality
|
Obligatoria
|
La calidad de la información es la probabilidad de aparición, en un intervalo de 0 a 7.
Valores: riesgo (2), probable (4), cierto (6).
Si se recibe (0), debe rechazarse; si se recibe (7), debe considerarse cierto.
|
|
eventType
|
Obligatoria
|
Combinación de los elementos de datos causeCode y subCauseCode. Específico del servicio STI-C.
|
|
linkedCause
|
Opcional
|
Posibilidad de vincular el mensaje actual a un conjunto causeCode/subCauseCode (similar a eventType) para facilitar información adicional.
|
|
eventHistory
|
Opcional
|
Contenido:
Este perfil utiliza opcionalmente este elemento de datos cuando puede determinarse el punto final del bloqueo físico. Si es así, describe el bloqueo desde el inicio hasta el final, o hasta el inicio de un bloqueo nuevo (otro DENM). En este contexto, los valores eventPoint se facilitan sin el correspondiente eventDeltaTime, pues los puntos describen una extensión geoespacial, y no una trayectoria.
El elemento de datos informationQuality en el eventHistory se ajustará en el mismo valor informationQuality especificado anteriormente para todo el DENM.
Cuando se utilicen proyecciones cartográficas, estas deberán referirse a puntos situados en el centro del carril o la calzada.
La desviación máxima entre la realidad y las proyecciones cartográficas no deberá exceder de una cuarta parte de la anchura de la calzada.
|
|
Location container
|
Opcional
|
|
|
eventSpeed
|
Opcional
|
Esta secuencia de datos solo se facilitará en el caso de un evento en movimiento, si está disponible. No se facilitará si el evento es estático.
|
|
eventPositionHeading
|
Opcional
|
La información sobre el rumbo solo se facilitará para eventos en movimiento, por medio del elemento eventPositionHeading. Los eventos estáticos basados en DENM no utilizarán esta secuencia de datos.
|
|
traces
|
Obligatoria
|
El primer punto de rastro del mensaje es el punto más cercano a la posición del evento. Este punto se encuentra en el medio del carril o la calzada por detrás de la posición del evento, teniendo en cuenta la curvatura de la carretera. Se codifica como un desplazamiento o posición delta con respecto a la posición del evento. Los puntos de rastro adicionales se definen como desplazamientos o posiciones delta con respecto a sus puntos de rastro anteriores. Los puntos de rastro se ordenarán en orden ascendente, definiendo así el rumbo del evento.
Puede haber hasta siete rastros.
Cuando se utilicen proyecciones cartográficas, estas deberán referirse a puntos situados en el centro del carril o la calzada.
La desviación máxima entre la realidad y las proyecciones cartográficas no deberá exceder de una cuarta parte de la anchura de la calzada.
|
|
roadType
|
Opcional
|
Opcional
|
|
Alacarte container
|
Opcional
|
|
|
lanePosition
|
Opcional
|
Específico del servicio STI-C
|
|
impactReduction
|
No se utiliza
|
No se utiliza
|
|
externalTemperature
|
No se utiliza
|
No se utiliza
|
|
lightBarSirenInUse
|
No se utiliza
|
No se utiliza
|
Cuadro 4: Elementos DENM específicos de las advertencias de obras en la calzada
|
Nombre
|
Utilización
|
Modo de empleo
|
|
Alacarte container
|
Opcional
|
|
|
lanePosition
|
Opcional
|
opcional
|
|
closedLanes
|
Opcional
|
Los carriles se cuentan desde el borde interior de la carretera, excluido el arcén.
Esta secuencia de datos se compone de los elementos drivingLaneStatus y hardShoulderStatus.
|
|
speedLimit
|
Opcional
|
opcional
|
|
recommendedPath
|
Opcional
|
opcional
|
|
startingPointSpeedLimit
|
Opcional
|
opcional
|
|
trafficFlowRule
|
Opcional
|
opcional
Los elementos passToRight(2) o passToLeft(3) suelen ser compatibles en todas las situaciones de servicio STI-C.
|
|
referenceDenms
|
Opcional
|
Los DENM de advertencia de obras en la calzada pertenecientes a la misma situación de obras en la calzada se vincularán en la estación STI-C central enumerando todos los actionID relacionados entre sí en el elemento de datos referenceDenms de cada mensaje.
|
3.7.2.Servicio IVI
El servicio IVI utiliza los servicios proporcionados por las entidades protocolarias de la capa de red y de transporte STI para difundir IVIM.
Los IVIM apoyan la señalización vial de obligación y recomendación, como son las velocidades contextuales y las advertencias de obras en la calzada. Los IVIM facilitan información sobre las señales de circulación físicas como son las señales fijas o variables, las señales virtuales o las señales de obras en la calzada.
El servicio IVI representado en una estación STI-C proporcionará el servicio o bien de transmisión o bien de recepción.
El servicio IVI genera cuatro tipos de IVIM:
IVIM nuevos;
IVIM de actualización;
IVIM de cancelación;
IVIM de negación.
159)La cabecera IVIM deberá ser como se especifica en la norma [TS 102 894-2].
160)Los elementos de datos de la carga útil del mensaje IVIM se definen en la norma [ISO/TS 19321].
161)Los elementos de datos IVIM, las secuencias de datos IVIM y los parámetros de servicio se ajustarán de conformidad con el cuadro 5.
Cuadro 5
|
Nombre
|
Utilización
|
Modo de empleo
|
|
IVI management container
|
Obligatoria
|
|
|
serviceProviderId
|
Obligatoria
|
El elemento serviceProviderID se compone de los elementos de datos countryCode y providerIdentifier.
El elemento countryCode es una cadena de bits conforme a la norma [ISO 3166-1]. Por ejemplo, en el caso de Austria, la cadena de bits corresponde a «AT» (código de la cadena de bits: A (11000) y T (00001) 1100000001 conforme a la norma [ISO 14 816]).
Junto con el elemento iviIdentificationNumber, es el identificador único de los mensajes para la estación STI-C vehicular receptora.
|
|
iviIdentificationNumber
|
Obligatoria
|
Este elemento de datos es el identificador de la estructura IVI, asignado por el prestador del servicio. Este componente sirve como identificador del mensaje por serviceProvider y puede ser utilizado como referencia por otros mensajes relacionados.
|
|
timestamp
|
Obligatoria
|
Este elemento de datos es el sello de tiempo que representa la hora a la que se genera el mensaje IVI o a la que se modificó por última vez el contenido de los mensajes.
|
|
validFrom
|
Obligatoria
|
Este componente puede contener la hora de inicio del período de validez del mensaje. Si la hora de inicio no es relevante para el sistema o este la desconoce, el elemento validFrom no está presente o es igual a timestamp.
|
|
validTo
|
Obligatoria
|
Este elemento de datos se utilizará siempre para determinar la validez. Antes de que expire el mensaje, se enviará una actualización.
Valor: fijado por la aplicación.
El período de validez por defecto es fijado por el explotador de la carretera.
|
|
connectedIviStructures (1..8)
|
No se utiliza
|
No se utiliza
|
|
iviStatus
|
Obligatoria
|
Este componente contiene la situación de la estructura IVI. Puede ajustarse en new(0), update(1), cancellation(2) o negation(3). Se utiliza para el tratamiento de los mensajes.
|
|
Geographical location container (GLC)
|
Obligatoria
|
|
|
referencePosition
|
Obligatoria
|
Este elemento de datos se utiliza como punto de referencia para todas las zonas del GLC.
El punto de referencia para la IVI es el centro de la calzada, en un pórtico, y es el primer punto de las definiciones de zona para las zonas de relevancia y las zonas de detección.
La altitud puede ajustarse en no disponible o desconocida. Si se facilita la altitud, es la altitud de la calzada.
Valor: fijado por la aplicación.
|
|
referencePositionTime
|
No se utiliza
|
No se utiliza
|
|
referencePositionHeading
|
No se utiliza
|
No se utiliza
|
|
referencePositionSpeed
|
No se utiliza
|
No se utiliza
|
|
GlcPart
|
Obligatoria
|
Partes (1..16). En cada GLC pueden definirse hasta dieciséis partes. El GLC contiene al menos dos zonas: una para la relevancia y otra para la detección.
Valor: fijado por la aplicación.
|
|
zoneId
|
Obligatoria
|
Para cada mensaje se facilitarán al menos una zona de detección y una zona de relevancia.
|
|
laneNumber
|
Opcional
|
Obligatoria si se describen carriles individuales en este contenedor de ubicación. Ausente por defecto (sin información de carril).
|
|
zoneExtension
|
No se utiliza
|
No se utiliza
|
|
zoneHeading
|
Obligatoria
|
Obligatoria
|
|
zone
|
Obligatoria
|
Definición de una zona utilizando la secuencia de datos zone compuesta por una secuencia de datos segment, una secuencia de datos polygonalLine o una secuencia de datos computedSegment escogidas.
La opción segment se utilizará con poligonalLine como línea (construida con deltaPosition, como para los rastros DENM) y, opcionalmente, con laneWidth (solo cuando se referencia un único carril dentro de la zona).
|
|
IVI application container
|
Obligatoria
|
|
|
detectionZoneIds
|
Obligatoria
|
Lista de identificadores de las definiciones de las zonas de detección, utilizando el elemento de datos Zid (1.. 8).
|
|
its-Rrid
|
No se utiliza
|
No se utiliza
|
|
relevanceZoneIds
|
Obligatoria
|
Lista de identificadores de las definiciones de las zonas de relevancia a las que se aplica el contenedor IVI, utilizando el elemento de datos Zid (1..8).
|
|
direction
|
Obligatoria
|
Sentido pertinente en relación con el sentido definido (implícitamente) por la zona utilizando el elemento de datos direction. Siempre ajustado en sameDirection(0).
|
|
driverAwarnessZoneIds
|
No se utiliza
|
No se utiliza
|
|
minimumAwarenessTime
|
No se utiliza
|
No se utiliza
|
|
applicableLanes (1..8)
|
Opcional
|
Lista de identificadores de los carriles a los que se aplica el contenedor IVS, utilizando el elemento de datos LanePosition (1..8).
|
|
iviType
|
Obligatoria
|
Proporciona el tipo de IVI (por ejemplo, mensaje de peligro inminente, mensaje regulador, mensaje de información de tráfico) para permitir la clasificación y priorización de IVI en la estación STI-C receptora.
|
|
iviPurpose
|
No se utiliza
|
No se utiliza
|
|
laneStatus
|
Opcional
|
Indica la situación del carril (por ejemplo, abierto, cerrado, mergeL o mergeR) de los applicableLanes.
|
|
completeVehicleCharacteristics
|
Opcional
|
El elemento completeVehicleCharacteristics contendrá la definición de las características de los vehículos a los que sea aplicable un contenedor de aplicación. El componente train (si está presente) contendrá las características aplicables a todo el tren de vehículos.
|
|
driverVehicleCharacteristics
|
No se utiliza
|
No se utiliza
|
|
layoutId
|
No se utiliza
|
No se utiliza
|
|
preStoredLayoutId
|
No se utiliza
|
No se utiliza
|
|
roadSignCodes
|
Obligatoria
|
Contendrá la definición del código de señales de circulación. Permite diferentes opciones que remiten a diferentes catálogos de pictogramas.
Este componente especifica qué señales de circulación son aplicables a una zona de relevancia. Los códigos de señales de circulación dependen del sistema de clasificación referenciado.
Pueden añadirse atributos adicionales al código de señales de circulación según permitan las opciones.
Lista de 1..4 de RSCode
|
|
RSCode
|
Obligatoria
|
Contiene el elemento layoutComponentId y un código.
|
|
layoutComponentId
|
No se utiliza
|
Esta secuencia de datos puede utilizarse para asociar el RSCode al componente de configuración de la configuración referenciada.
|
|
code
|
Obligatoria
|
Para la codificación de señales se utilizará la norma [ISO/TS 14 823].
|
|
ISO 14823Code
|
Obligatoria
|
Para la codificación de señales se utilizará la norma [ISO/TS 14 823].
Esta secuencia de datos incluye varias secuencias de datos y varios elementos de datos.
Incluye el elemento pictogramCode (countryCode, serviceCategorycode y pictogramCategoryCode).
Los atributos SET (sección) y NOL (número de carril) no son compatibles, pues duplican información que ya se encuentra en el contenedor de aplicación.
|
|
extraText ((1..4),...)
|
Opcional
|
Lista de líneas de texto asociadas a la lista ordenada de códigos de señales de circulación. Cada pieza contiene un código de lengua, más texto adicional de tamaño limitado en la lengua seleccionada, utilizando la secuencia de datos de texto.
Nota: Esta secuencia de datos puede sobrecargarse con seguridad para incluir más líneas de texto.
|
3.7.3.Servicio de topografía de carriles de la calzada (RLT)
El servicio RLT utiliza los servicios proporcionados por las entidades protocolarias de la capa de red y de transporte STI para difundir RLT.
Incluye la topografía de carriles para vehículos, bicicletas, aparcamiento, transporte público y pasos de peatones, por ejemplo, y las maniobras admisibles dentro de una zona de intersección o de un tramo de carretera. En futuras mejoras, el mapa digital incluirá descripciones topográficas adicionales, como las glorietas.
162)Las cabeceras MAPEM deberán ser como se especifica en la norma [ETSI TS 102 894-2].
163)Los elementos de datos MAPEM, las secuencias de datos MAPEM y los parámetros de servicio se ajustarán de conformidad con el cuadro 6.
Cuadro 6: Elementos de datos MAPEM
|
Nivel
|
Nombre
|
Tipo
|
Utilización
|
Modo de empleo
|
|
*
|
mapData
|
Secuencia de datos
|
Obligatoria
|
|
|
**
|
timeStamp
|
Elemento de datos
|
No se utiliza
|
No se utiliza
|
|
**
|
msgIssue Revision
|
Elemento de datos
|
Obligatoria
|
Obligatoria y ajustada en 0. Según se define en la norma [ISO TS 19091].
|
|
**
|
layerType
|
Elemento de datos
|
No se utiliza
|
No se utiliza
|
|
**
|
layerID
|
Elemento de datos
|
Opcional
|
Opcional. Según se define en la norma [ISO TS 19091].
|
|
**
|
intersections
(1..32)
|
Secuencia de datos
|
Obligatoria
|
IntersectionGeometryList::= SEQUENCE (SIZE(1..32)) OF IntersectionGeometry (véase el cuadro 6.1)
Obligatoria para servicios STI-C de maniobra semafórica (TLM) o RLT.
|
|
**
|
roadSegments
(1..32)
|
Secuencia de datos
|
No se utiliza
|
No se utiliza Los elementos de datos no se perfilan más.
|
|
**
|
dataParameters
|
Secuencia de datos
|
Opcional
|
Opcional
|
|
***
|
processMethod
|
Elemento de datos
|
No se utiliza
|
No se utiliza
|
|
***
|
processAgency
|
Elemento de datos
|
Opcional
|
Opcional
|
|
***
|
lastCheckedDate
|
Elemento de datos
|
Opcional
|
Opcional, como yyyy-mm-dd
|
|
***
|
geoidUsed
|
Elemento de datos
|
No se utiliza
|
No se utiliza
|
|
**
|
restriction List
(1..32)
|
Secuencia de datos
|
Opcional
|
RestrictionClassList::= SEQUENCE (SIZE(1..254)) OF RestrictionClassAssignment (véase el cuadro 6.3).
Opcional
|
|
**
|
regional
|
Elemento de datos
|
No se utiliza
|
REGION.Reg-MapData
No se utiliza
|
Cuadro 6.1: IntersectionGeometryList -> Intersection Geometry
|
Nivel
|
Nombre
|
Tipo
|
Utilización
|
Modo de empleo
|
|
*
|
intersectionGeometry
|
Secuencia de datos
|
Obligatoria
|
Obligatoria si se utiliza intersections.
|
|
**
|
name
|
Elemento de datos
|
Opcional
|
Opcional. Típicamente legible para el ojo humano y reconocible por la autoridad vial.
|
|
**
|
id
|
Secuencia de datos
|
Obligatoria
|
(IntersectionReferenceID)
Obligatoria. Debe ser la misma que en el SPATEM. La combinación de region e id debe ser única dentro de un mismo país.
|
|
***
|
region
|
Elemento de datos
|
Opcional
|
Opcional
|
|
***
|
id
|
Elemento de datos
|
Obligatoria
|
Obligatoria
|
|
**
|
revision
|
Elemento de datos
|
Obligatoria
|
Obligatoria. El número de revisión deberá aumentar de uno en uno cada vez que cambie el MapData de esta intersección. Los números de revisión de SPATEM y MAPEM deben ser los mismos, para indicar que se utiliza la revisión de MAPEM correcta. Según se define en la norma [ISO TS 19091].
|
|
**
|
refPoint
|
Secuencia de datos
|
Obligatoria
|
Obligatoria
|
|
***
|
lat
|
Elemento de datos
|
Obligatoria
|
Obligatoria
|
|
***
|
long
|
Elemento de datos
|
Obligatoria
|
Obligatoria
|
|
***
|
elevation
|
Elemento de datos
|
No se utiliza
|
No se utiliza Sustituido por RegPosition3D regional.
|
|
***
|
regional
|
Secuencia de datos
|
Opcional
|
REGION.Reg-Position3D.
Opcional. Cuando se indica, proporciona la altitud.
|
|
****
|
altitude
|
Secuencia de datos
|
Obligatoria
|
Obligatoria. Se compone de altitudeValue y altitudeConfidence.
|
|
*****
|
altitudeValue
|
Elemento de datos
|
Obligatoria
|
Obligatoria
|
|
*****
|
altitudeConfidence
|
Elemento de datos
|
Opcional
|
Obligatoria; si no está disponible se ajusta en (15) = no disponible.
|
|
**
|
laneWidth
|
Elemento de datos
|
Opcional
|
Opcional
|
|
**
|
speedLimits
(1..9)
|
Secuencia de datos
|
Opcional
|
SpeedLimitList::= SEQUENCE (SIZE(1..9)) OF RegulatorySpeedLimit (véase el cuadro 6.2).
Opcional
|
|
**
|
laneSet
(1..255)
|
Secuencia de datos
|
Obligatoria
|
LaneList::= SEQUENCE (SIZE(1..255)) OF GenericLane (véase el cuadro 6.4).
Obligatoria
|
|
**
|
preemptPriorityData
(1..32)
|
Secuencia de datos
|
No se utiliza
|
No se utiliza Los elementos de datos no se perfilan más.
|
|
**
|
Regional
|
Secuencia de datos
|
No se utiliza
|
REGION.Reg- IntersectionGeometry). No se utiliza
|
Cuadro 6.2: SpeedLimitList -> RegulatorySpeedLimit
|
Nivel
|
Nombre
|
Tipo
|
Utilización
|
Modo de empleo
|
|
*
|
regulatory SpeedLimit
|
Secuencia de datos
|
Obligatoria
|
Obligatoria si se utiliza speedLimits.
|
|
**
|
type
|
Elemento de datos
|
Obligatoria
|
Obligatoria
|
|
**
|
speed
|
Elemento de datos
|
Obligatoria
|
Obligatoria
|
Cuadro 6.3: RestrictionClassList -> RestrictionClassAssignment
|
Nivel
|
Nombre
|
Tipo
|
Utilización
|
Modo de empleo
|
|
*
|
restriction ClassAssignment
|
Secuencia de datos
|
Obligatoria
|
Obligatoria si se utiliza restrictionList.
|
|
**
|
id
|
Elemento de datos
|
Obligatoria
|
Obligatoria
|
|
**
|
users
|
Secuencia de datos
|
Obligatoria
|
RestrictionUserTypeList::= SEQUENCE (SIZE(1..16)) OF RestrictionUserType
Obligatoria
|
|
***
|
restrictionUserType
|
Secuencia de datos
|
Obligatoria
|
|
|
****
|
basicType
|
Elemento de datos
|
Opcional
|
Se utiliza
|
|
****
|
regional
(1..4)
|
Secuencia de datos
|
Opcional
|
REGION.Reg-RestrictionUserType-addGrpC. Opcional para proporcionar restricciones de emisiones.
|
|
*****
|
emission
|
Elemento de datos
|
Opcional
|
Opcional
|
Cuadro 6.4: LaneList -> GenericLane
|
Nivel
|
Nombre
|
Tipo
|
Utilización
|
Modo de empleo
|
|
*
|
genericLane
|
Secuencia de datos
|
Obligatoria
|
Obligatoria si se utiliza laneSet.
|
|
**
|
laneID
|
Elemento de datos
|
Obligatoria
|
Obligatoria
|
|
**
|
name
|
Elemento de datos
|
Opcional
|
Opcional
|
|
**
|
ingressApproach
|
Elemento de datos
|
Opcional
|
Opcional. Si se utiliza, las aproximaciones de entrada y de salida del mismo ramal tienen el mismo ApproachID.
|
|
**
|
egressApproach
|
Elemento de datos
|
Opcional
|
Opcional. Si se utiliza, las aproximaciones de entrada y de salida del mismo ramal tienen el mismo ApproachID.
|
|
**
|
laneAttributes
|
Secuencia de datos
|
Obligatoria
|
Obligatoria
|
|
***
|
directional Use
|
Elemento de datos
|
Obligatoria
|
Obligatoria
|
|
***
|
sharedWith
|
Elemento de datos
|
Obligatoria
|
Obligatoria
Con los bits definidos: overlappingLaneDescriptionProvided(0) multipleLanesTreatedAsOneLane(1)
— no se permite en el perfil, ya que han de describirse todos los carriles
otherNonMotorizedTrafficTypes(2)
— por ejemplo, tiro de caballos
individualMotorizedVehicleTraffic(3)
— turismos
busVehicleTraffic(4)
taxiVehicleTraffic(5)
pedestriansTraffic(6)
cyclistVehicleTraffic(7)
trackedVehicleTraffic(8) pedestrianTraffic(9)
— utilizar 6 en su lugar (error)
|
|
***
|
laneType
|
Secuencia de datos
|
Obligatoria
|
Obligatoria. Se utiliza en este perfil:
vehicle
crosswalk
bikeLane
trackedVehicle
— véanse ejemplos de pasos de peatones en la norma [ISO TS 19091]
|
|
****
|
Vehicle
|
Elemento de datos
|
Opcional
|
Opcional (elección).
|
|
****
|
crosswalk
|
Elemento de datos
|
Opcional
|
Opcional (elección)
|
|
****
|
bikeLane
|
Elemento de datos
|
Opcional
|
Opcional (elección)
|
|
****
|
sidewalk
|
Elemento de datos
|
No se utiliza
|
No se utiliza
|
|
****
|
median
|
Elemento de datos
|
No se utiliza
|
No se utiliza
|
|
****
|
striping
|
Elemento de datos
|
No se utiliza
|
No se utiliza
|
|
****
|
trackedVehicle
|
Elemento de datos
|
Opcional
|
Opcional (elección)
|
|
****
|
parking
|
Elemento de datos
|
No se utiliza
|
No se utiliza
|
|
***
|
regional
|
Secuencia de datos
|
No se utiliza
|
Reg-laneAttributes. No se utiliza
|
|
**
|
maneuvers
|
Elemento de datos
|
No se utiliza
|
No se utiliza
|
|
**
|
nodeList
|
Secuencia de datos
|
Obligatoria
|
Obligatoria
|
|
***
|
nodes
(2..63)
|
Secuencia de datos
|
Obligatoria
|
NodeSetXY::= SEQUENCE (SIZE(2..63)) OF NodeXY (véase el cuadro 6.5)
Obligatoria si se utiliza nodeList.
El uso recomendado para carriles curvados es añadir un nodo adicional cuando la línea central del GenericLane se desvía más de 0,5 m de la línea central real.
|
|
***
|
computed
|
Secuencia de datos
|
No se utiliza
|
No se utiliza
|
|
**
|
connectsTo
(1..16)
|
Secuencia de datos
|
Opcional
|
ConnectsToList::= SEQUENCE (SIZE(1..16)) OF Connection (véase el cuadro 6.6).
Opcional. Por ejemplo, en el caso de carriles de salida sin gestión semafórica.
|
|
**
|
overlays
|
Secuencia de datos
|
No se utiliza
|
No se utiliza
|
|
**
|
regional
|
Secuencia de datos
|
No se utiliza
|
REGION-Reg-GenericLane. No se utiliza (hasta la próxima publicación de la norma [ISO TS 19091]). Para proporcionar ConnectionTrajectory-addGrpC. Pertinente para la situación de casos de utilización «maniobra segura en intersección».
|
Cuadro 6.5: NodeSetXY -> NodeXY
|
Nivel
|
Nombre
|
Tipo
|
Utilización
|
Modo de empleo
|
|
*
|
nodeXY
|
Secuencia de datos
|
Obligatoria
|
Obligatoria si se utiliza nodes.
|
|
**
|
delta
|
Secuencia de datos
|
Obligatoria
|
Obligatoria
|
|
***
|
node-XY1
|
Secuencia de datos
|
Opcional
|
Opcional (elección)
Secuencia de datos compuesta por X e Y, ambos obligatorios.
|
|
***
|
node-XY2
|
Secuencia de datos
|
Opcional
|
Opcional (elección)
Secuencia de datos compuesta por X e Y, ambos obligatorios.
|
|
***
|
node-XY3
|
Secuencia de datos
|
Opcional
|
Opcional (elección)
Secuencia de datos compuesta por X e Y, ambos obligatorios.
|
|
***
|
node-XY4
|
Secuencia de datos
|
Opcional
|
Opcional (elección)
Secuencia de datos compuesta por X e Y, ambos obligatorios.
|
|
***
|
node-XY5
|
Secuencia de datos
|
Opcional
|
Opcional (elección)
Secuencia de datos compuesta por X e Y, ambos obligatorios.
|
|
***
|
node-XY6
|
Secuencia de datos
|
Opcional
|
Opcional (elección)
Secuencia de datos compuesta por X e Y, ambos obligatorios.
|
|
***
|
node-LatLon
|
Secuencia de datos
|
No se utiliza
|
No se utiliza en intersecciones. Utilización aceptable en autopistas, por ejemplo.
|
|
***
|
regional
|
Secuencia de datos
|
No se utiliza
|
REGION.Reg-NodeOffsetPointXY
No se utiliza
|
|
**
|
attributes
|
Secuencia de datos
|
Opcional
|
Este elemento de datos proporciona los atributos opcionales que son necesarios. Esto incluye cambios en la anchura y elevación del carril actual. Todos los atributos se facilitan en el orden de los nodos (en contraposición al sentido de circulación). También las indicaciones izquierda/derecha mediante atributos deben interpretarse según el orden de los nodos.
|
|
***
|
localNode
(1..8)
|
Secuencia de datos
|
Opcional
|
NodeAttributeXYList::=
SEQUENCE (SIZE(1..8)) OF
NodeAttributeXY
Opcional. Según el caso. La línea de detención es obligatoria si está presente en el campo.
|
|
****
|
nodeAttributeXY
|
Elemento de datos
|
Obligatoria
|
Obligatoria si se utiliza localNode.
|
|
***
|
disabled
(1..8)
|
Secuencia de datos
|
Opcional
|
SegmentAttributeXYList::=
SEQUENCE (SIZE(1..8)) OF
SegmentAttributeXY
Opcional. Según el caso.
|
|
****
|
segmentAttributeXY
|
Elemento de datos
|
Obligatoria
|
Obligatoria si se utiliza disabled.
|
|
***
|
enabled
(1..8)
|
Secuencia de datos
|
Opcional
|
SegmentAttributeXYList::=
SEQUENCE (SIZE(1..8)) OF
SegmentAttributeXY
Opcional. Según el caso.
|
|
****
|
segmentAttributeXY
|
Elemento de datos
|
Obligatoria
|
Obligatoria si se utiliza enabled.
|
|
***
|
data
|
Secuencia de datos
|
Opcional
|
Opcional
|
|
****
|
pathEndPointAngle
|
Elemento de datos
|
No se utiliza
|
No se utiliza
|
|
****
|
pathEndPointAngle
|
Elemento de datos
|
No se utiliza
|
No se utiliza
|
|
****
|
laneCrownPointCenter
|
Elemento de datos
|
No se utiliza
|
No se utiliza
|
|
****
|
laneCrownPointLeft
|
Elemento de datos
|
No se utiliza
|
No se utiliza
|
|
****
|
laneCrownPointRight
|
Elemento de datos
|
No se utiliza
|
No se utiliza
|
|
****
|
laneAngle
|
Elemento de datos
|
No se utiliza
|
No se utiliza
|
|
****
|
speedLimits (1..9)
|
Elemento de datos
|
Opcional
|
SpeedLimitList::= SEQUENCE
(SIZE(1..9)) OF
RegulatorySpeedLimit
(véase el cuadro 6.2)
Opcional (elección)
|
|
****
|
regional
|
Secuencia de datos
|
No se utiliza
|
REGION.Reg-
LaneDataAttribute.
No se utiliza
|
|
***
|
dWidth
|
Elemento de datos
|
Opcional
|
Opcional
|
|
***
|
dElevation
|
Elemento de datos
|
Opcional
|
Opcional
|
|
***
|
regional
|
Secuencia de datos
|
No se utiliza
|
REGION.Reg-NodeAttributeSetXY.
No se utiliza
|
Cuadro 6.6: ConnectsToList -> Connection
|
Nivel
|
Nombre
|
Tipo
|
Utilización
|
Modo de empleo
|
|
*
|
connection
|
Secuencia de datos
|
Opcional
|
Obligatoria si se utiliza connectsTo
|
|
**
|
connectingLane
|
Secuencia de datos
|
Obligatoria
|
Obligatoria
|
|
***
|
lane
|
Elemento de datos
|
Obligatoria
|
Obligatoria
|
|
***
|
maneuver
|
Elemento de datos
|
Opcional
|
Opcional
|
|
**
|
remoteIntersection
|
Secuencia de datos
|
Opcional
|
Opcional. Solo se utiliza si la intersección referenciada forma parte del mismo MAPEM.
|
|
***
|
Region
|
Elemento de datos
|
Opcional
|
Opcional
|
|
***
|
Id
|
Elemento de datos
|
Obligatoria
|
Obligatoria
|
|
**
|
signalGroup
|
Elemento de datos
|
Opcional
|
Opcional, pues no todas las conexiones pueden tener grupos de señales relacionados. Sin embargo, en el caso de las conexiones controladas por un semáforo, debe establecerse el grupo de señales.
|
|
**
|
userClass
|
Elemento de datos
|
Opcional
|
Opcional
|
|
**
|
connectionID
|
Elemento de datos
|
Obligatoria
|
Obligatoria
|
3.7.4.Servicio TLM
El servicio TLM utiliza los servicios proporcionados por las entidades protocolarias de la capa de red y de transporte STI para difundir TLM.
Incluye información sobre seguridad para ayudar a los participantes en el tráfico (vehículos, peatones, etc.) a realizar maniobras seguras en una zona de intersección. El objetivo es entrar y salir de manera controlada del «área de conflicto» que constituye una intersección. El servicio TLM proporciona información en tiempo real sobre los estados operativos del regulador de semáforos, el estado actual de las señales, el tiempo restante del estado antes de cambiar al estado siguiente y las maniobras permitidas, y ayuda a cruzar.
164)Las cabeceras SPATEM deberán ser como se especifica en la norma [TS 102 894-2].
165)Los elementos de datos SPATEM, las secuencias de datos y los parámetros de servicio se ajustarán de conformidad con el cuadro 7.
Cuadro 7: Elementos de datos SPATEM
|
Nivel
|
Nombre
|
Tipo
|
Utilización
|
Modo de empleo
|
|
*
|
Spat
|
Secuencia de datos
|
Obligatoria
|
|
|
**
|
timeStamp
|
Elemento de datos
|
Opcional
|
No se utiliza, pero se mantiene opcional.
|
|
**
|
name
|
Elemento de datos
|
Opcional
|
No se utiliza, pero se mantiene opcional.
|
|
**
|
Intersections
(1..32)
|
Secuencia de datos
|
Obligatoria
|
IntersectionStateList::= SEQUENCE (SIZE(1..32)) OF IntersectionState (véase el cuadro 7.1).
Obligatoria
|
|
**
|
regional (1..4)
|
Secuencia de datos
|
No se utiliza
|
REGION.Reg-SPAT
No se utiliza
|
Cuadro 7.1: IntersectionStateList -> IntersectionState
|
Nivel
|
Nombre
|
Tipo
|
Utilización
|
Modo de empleo
|
|
*
|
intersectionState
|
Secuencia de datos
|
Obligatoria
|
|
|
**
|
name
|
Elemento de datos
|
Opcional
|
Se utiliza, pero se mantiene opcional.
Basado en un sistema de numeración utilizado por la autoridad viaria.
|
|
**
|
id
|
Secuencia de datos
|
Obligatoria
|
(IntersectionReferenceID)
Obligatoria. Debe ser la misma que en el MAPEM. La combinación de region e ID debe ser única dentro de un mismo país.
|
|
***
|
region
|
Elemento de datos
|
Opcional
|
Opcional
|
|
***
|
id
|
Elemento de datos
|
Obligatoria
|
Obligatoria
|
|
**
|
revision
|
Elemento de datos
|
Obligatoria
|
Obligatoria. El número de revisión deberá aumentar de uno en uno cada vez que cambie el MapData de esta intersección. Los números de revisión de SPATEM y MAPEM deben ser los mismos, para indicar que se utiliza la revisión de MAPEM correcta. Según se define en la norma [ISO TS 19091].
|
|
**
|
status
|
Elemento de datos
|
Obligatoria
|
Obligatoria. Sobre la base de la norma EN 12675, suelen utilizarse:
•manualControlIsEnabled(0);
•fixedTimeOperation(5);
•trafficDependentOperation(6);
•standbyOperation(7);
•failureMode(8).
|
|
**
|
moy
|
Elemento de datos
|
Obligatoria
|
Obligatoria. También se utiliza para validar la hora de referencia de las TimeMarks.
|
|
**
|
timeStamp
|
Elemento de datos
|
Obligatoria
|
Obligatoria
|
|
**
|
enabledLanes
|
Secuencia de datos
|
Opcional
|
Obligatorio si se utiliza el bit revocableLane en cualquiera de las descripciones de los carriles; de lo contrario, no se utiliza.
|
|
**
|
states
(1..16)
|
Secuencia de datos
|
Obligatoria
|
MovementList::= SEQUENCE (SIZE(1..255)) OF MovementState (véase el cuadro 7.2).
Obligatoria
|
|
**
|
maneuverAs sistList
(1..16)
|
Secuencia de datos
|
No se utiliza
|
ManeuverAssistList::= SEQUENCE (SIZE(1..16)) OF ConnectionManeuverAssist (véase el cuadro 7.5).
No se utiliza, por lo que no se perfila más en este nivel.
|
|
**
|
Regional (1..4)
|
Secuencia de datos
|
Opcional
|
REGION.Reg-IntersectionState.
Opcional, para garantizar la interoperabilidad con los sistemas existentes de priorización del transporte público.
|
Cuadro 7.2: MovementList -> MovementState
|
Nivel
|
Nombre
|
Tipo
|
Utilización
|
Modo de empleo
|
|
*
|
movementState
|
Secuencia de datos
|
Obligatoria
|
Obligatoria si se utiliza states.
|
|
**
|
movementName
|
Elemento de datos
|
Opcional
|
Opcional
|
|
**
|
signalGroup
|
Elemento de datos
|
Obligatoria
|
Obligatoria
|
|
**
|
state-time- speed
|
Secuencia de datos
|
Obligatoria
|
MovementEventList::= SEQUENCE (SIZE(1..16)) OF MovementEvent
Obligatoria (1-16)
(véase el cuadro 7.3)
|
|
**
|
maneuverAssistList
(1..16)
|
Secuencia de datos
|
Opcional
|
ManeuverAssistList::= SEQUENCE (SIZE(1..16)) OF ConnectionManeuverAssist (véase el cuadro 7.5)
Opcional
|
|
**
|
regional
(1..4)
|
Secuencia de datos
|
No se utiliza
|
REGION.Reg-MovementState
No se utiliza
|
Cuadro 7.3: MovementEventList -> MovementEvent
|
Nivel
|
Nombre
|
Tipo
|
Utilización
|
Modo de empleo
|
|
*
|
movementEvent
|
Secuencia de datos
|
Obligatoria
|
Obligatoria si se utiliza state-time-speed
|
|
**
|
eventState
|
Elemento de datos
|
Obligatoria
|
Obligatoria y definida como sigue:
(0)unavailable (desconocido o error);
(1)dark (no se utiliza en la UE);
(2)stop-then-Proceed (por ejemplo, luz roja combinada con una señal de flecha verde indicadora de giro);
(3)stop-and-remain (por ejemplo, luz roja);
(4)pre-Movement (por ejemplo, luz roja/ámbar, como se utiliza en algunos países de la UE antes de la luz verde);
(5)permissive-Movement-Allowed (por ejemplo, luz verde sin símbolos, con posibilidad de tráfico en conflicto, especialmente al girar);
(6)protected-Movement-Allowed (por ejemplo, luz con flecha verde, sin tráfico ni peatones en conflicto durante el cruce del área de conflicto);
(7)permissive clearance (por ejemplo, luz ámbar sin símbolos, prepararse para parar; se utiliza después de un intervalo «verde»);
(8)protected clearance (por ejemplo, luz con flecha ámbar, prepararse para parar en una dirección; se utiliza después de un intervalo de «flecha verde»);
(9)caution-Conflicting-Traffic (por ejemplo, luz ámbar intermitente; proseguir con precaución, puede haber tráfico en conflicto en el área de conflicto de la intersección).
|
|
**
|
timing
|
Secuencia de datos
|
Opcional
|
Opcional. Por ejemplo, es posible que no se disponga de datos timing cuando el valor status sea 0, 1 o 9.
Todas las TimeMarks se definen como un desplazamiento con respecto a la hora completa UTC (véase la norma [ISO TS 19091]) y no a efectos de seguridad funcional, sino de información en relación con la sincronización de señales. El elemento likelyTime con el elemento confidence, o el elemento minEndTime con el elemento maxEndTime, son medidas de probabilidad y pueden utilizarse de forma intercambiable según la disponibilidad.
|
|
***
|
startTime
|
Elemento de datos
|
No se utiliza
|
No se utiliza
|
|
***
|
minEndTime
|
Elemento de datos
|
Obligatoria
|
Obligatoria. Valor preconfigurado o calculado con alta probabilidad, pero a veces no disponible (36001). En casos de control temporal fijo, por ejemplo, idéntico a maxEndTime, que indica una alta probabilidad.
|
|
***
|
maxEndTime
|
Elemento de datos
|
Obligatoria
|
Obligatoria. Valor preconfigurado o calculado con alta probabilidad, pero a veces no disponible (36001). En casos de control temporal fijo, por ejemplo, idéntico a minEndTime, que indica una alta probabilidad.
|
|
***
|
likelyTime
|
Elemento de datos
|
Opcional
|
Opcional
|
|
***
|
confidence
|
Elemento de datos
|
Opcional
|
Obligatoria si se facilita el elemento likelyTime.
La definición de «confianza» de la norma básica no es utilizable. En su lugar, la confianza viene definida por la desviación típica (sigma) del elemento likelyTime en segundos. El valor proporcionado por este elemento de datos, entre 0 y 15, representa 1 sigma (redondeado). 15 = desconocido. Por lo tanto, no se utiliza la tabla de conversión con probabilidades contenida en la norma SAE J2735.
Suponiendo una distribución normal y una desviación típica de 3,6 segundos, likelyTime está:
•entre 26 y 34 segundos (1 sigma), con una probabilidad del 68,27 %;
•entre 22 y 38 segundos (2 sigma), con una probabilidad del 95,44 %;
•entre 18 y 42 segundos (3 sigma), con una probabilidad del 99,73 %.
|
|
***
|
nextTime
|
Elemento de datos
|
Opcional
|
Opcional
|
|
**
|
speeds
(1..16)
|
Secuencia de datos
|
Opcional
|
AdvisorySpeedList::= SEQUENCE (SIZE(1..16)) OF AdvisorySpeed (véase el cuadro 7.4)
Opcional
|
|
**
|
regional
(1..4)
|
Secuencia de datos
|
Opcional
|
REGION.Reg-MovementEvent, Optional
|
Cuadro 7.4: AdvisorySpeedList -> AdvisorySpeed
|
Nivel
|
Nombre
|
Tipo
|
Utilización
|
Modo de empleo
|
|
*
|
advisorySpeed
|
Secuencia de datos
|
Obligatoria
|
Obligatoria si se utiliza speeds
|
|
**
|
type
|
Elemento de datos
|
Obligatoria
|
Obligatoria
greenwave(1) = velocidad para una secuencia de intersecciones coordinadas (repetida en cada intersección).
ecoDrive(2) = velocidad para la intersección actual
transit(3) = limitada a un tipo de vehículo específico
|
|
**
|
speed
|
Elemento de datos
|
Opcional
|
Opcional
|
|
**
|
confidence
|
Elemento de datos
|
No se utiliza
|
No se utiliza
|
|
**
|
distance
|
Elemento de datos
|
Opcional
|
Opcional
No se utiliza para greenwave(1). En los demás casos, la distancia se especifica hacia atrás desde la línea de detención a lo largo del carril de entrada.
|
|
**
|
class
|
Elemento de datos
|
Opcional
|
Opcional
|
|
**
|
regional
(1..4)
|
Secuencia de datos
|
No se utiliza
|
REGION.Reg-AdvisorySpeed
No se utiliza
|
Cuadro 7.5: ManeuverAssistList -> ConnectionManeuverAssist
|
Nivel
|
Nombre
|
Tipo
|
Utilización
|
Modo de empleo
|
|
*
|
connection ManeuverAssist
|
Secuencia de datos
|
Obligatoria
|
Obligatoria si se utiliza maneuverAssistList
|
|
**
|
connectionID
|
Elemento de datos
|
Obligatoria
|
Obligatoria
|
|
**
|
queueLength
|
Elemento de datos
|
Opcional
|
Opcional
|
|
**
|
availableStorageLength
|
Elemento de datos
|
No se utiliza
|
No se utiliza
|
|
**
|
waitOnStop
|
Elemento de datos
|
No se utiliza
|
No se utiliza
|
|
**
|
pedBicycleDetect
|
Elemento de datos
|
No se utiliza
|
No se utiliza
|
|
**
|
regional
(1..4)
|
Secuencia de datos
|
No se utiliza
|
REGION.Reg-ConnectionManeuverAssist
No se utiliza
|
ÍNDICE
1.Introducción9
1.1.Descripción y ámbito de aplicación de la presente política9
1.2.Definiciones y siglas11
1.3.Participantes de la PKI13
1.3.1.Introducción13
1.3.2.Autoridad de la política de certificación de los STI-C16
1.3.3.Gestor de la lista de confianza17
1.3.4.Auditor de la PKI autorizado17
1.3.5.Punto de contacto STI-C (CPOC)17
1.3.6.Roles operativos18
1.4.Utilización de los certificados18
1.4.1.Ámbitos de utilización aplicables18
1.4.2.Límites de responsabilidad19
1.5.Administración de la política de certificación19
1.5.1.Actualización de las CPS de las CA que figuran en la ECTL19
1.5.2.Procedimientos de aprobación de la CPS20
2.Responsabilidades de publicación y repositorio20
2.1.Métodos para la publicación de información sobre certificados20
2.2.Temporalidad o frecuencia de la publicación21
2.3.Repositorios21
2.4.Controles de acceso a los repositorios21
2.5.Publicación de la información sobre certificados22
2.5.1.Publicación de la información sobre certificados por el TLM22
2.5.2.Publicación de la información sobre certificados por las CA22
3.Identificación y autenticación23
3.1.Nomenclatura23
3.1.1.Tipos de nombre23
3.1.1.1.Nombres de TLM, CA raíz, EA y AA23
3.1.1.2.Nombres de las entidades finales23
3.1.1.3.Identificación de los certificados23
3.1.2.Necesidad de que los nombres sean significativos23
3.1.3.Anonimato y pseudonimia de las entidades finales23
3.1.4.Normas para interpretar varios formatos de nombres23
3.1.5.Unicidad de los nombres24
3.2.Validación inicial de la identidad24
3.2.1.Método para demostrar la posesión de la clave privada24
3.2.2.Autenticación de la identidad de una organización24
3.2.2.1.Autenticación de la identidad de la organización de CA raíz24
3.2.2.2.Autenticación de la identidad de la organización del TLM25
3.2.2.3.Autenticación de la identidad de la organización de CA subordinada25
3.2.2.4.Autenticación de la organización suscriptora de entidades finales26
3.2.3.Autenticación de una entidad individual26
3.2.3.1.Autenticación de una entidad individual de TLM/CA26
3.2.3.2.Autenticación de la identidad del suscriptor de las estaciones STI-C27
3.2.3.3.Autenticación de la identidad de las estaciones STI-C27
3.2.4.Información no verificada sobre el suscriptor27
3.2.5.Validación de la autoridad27
3.2.5.1.Validación del TLM y de las CA raíz , EA y AA27
3.2.5.2.Validación de los suscriptores de estaciones STI-C28
3.2.5.3.Validación de las estaciones STI-C28
3.2.6.Criterios de interoperabilidad28
3.3.Identificación y autenticación de las solicitudes de renovación de claves28
3.3.1.Identificación y autenticación de las solicitudes de renovación de claves de rutina28
3.3.1.1.Certificados de TLM28
3.3.1.2.Certificados de CA raíz28
3.3.1.3.Renovación de certificados o de las claves de certificados de EA/AA28
3.3.1.4.Credenciales de inscripción de las entidades finales29
3.3.1.5.Tiques de autorización de las entidades finales29
3.3.2.Identificación y autenticación de las solicitudes de renovación de claves tras una revocación29
3.3.2.1.Certificados de CA29
3.3.2.2.Credenciales de inscripción de las entidades finales29
3.3.2.3.Solicitudes de autorización de las entidades finales29
3.4.Identificación y autenticación de las solicitudes de revocación29
3.4.1.Certificados de CA raíz/EA/AA29
3.4.2.Credenciales de inscripción de estaciones STI-C30
3.4.3.Tiques de autorización de estaciones STI-C30
4.Requisitos operativos para el ciclo de vida de los certificados30
4.1.Solicitud de certificado30
4.1.1.Quién puede presentar una solicitud de certificado30
4.1.1.1.CA raíz30
4.1.1.2.TLM31
4.1.1.3.EA y AA31
4.1.1.4.Estación STI-C31
4.1.2.Proceso y responsabilidades de inscripción31
4.1.2.1.CA raíz31
4.1.2.2.TLM32
4.1.2.3.EA y AA32
4.1.2.4.Estación STI-C32
4.2.Tramitación de las solicitudes de certificado33
4.2.1.Realización de las funciones de identificación y autenticación33
4.2.1.1.Identificación y autenticación de las CA raíz33
4.2.1.2.Identificación y autenticación del TLM33
4.2.1.3.Identificación y autenticación de la EA y la AA33
4.2.1.4.Identificación y autenticación del suscriptor de EE34
4.2.1.5.Tiques de autorización34
4.2.2.Aprobación o denegación de las solicitudes de certificado34
4.2.2.1.Aprobación o denegación de certificados de CA raíz34
4.2.2.2.Aprobación o denegación del certificado de TLM34
4.2.2.3.Aprobación o denegación de certificados de EA y AA34
4.2.2.4.Aprobación o denegación de EC34
4.2.2.5.Aprobación o denegación de AT35
4.2.3.Plazo para procesar la solicitud de certificado35
4.2.3.1.Solicitud de certificado de CA raíz35
4.2.3.2.Solicitud de certificado de TLM35
4.2.3.3.Solicitud de certificado de EA y AA35
4.2.3.4.Solicitud de EC35
4.2.3.5.Solicitud de AT35
4.3.Emisión de certificados35
4.3.1.Acciones de la CA durante la emisión de certificados35
4.3.1.1.Emisión de certificados de CA raíz35
4.3.1.2.Emisión de certificados de TLM36
4.3.1.3.Emisión de certificados de EA y AA36
4.3.1.4.Emisión de EC36
4.3.1.5.Emisión de AT36
4.3.2.Notificación de la CA al suscriptor sobre la emisión de certificados36
4.4.Aceptación de certificados37
4.4.1.Forma en la que se acepta el certificado37
4.4.1.1.CA raíz37
4.4.1.2.TLM37
4.4.1.3.EA y AA37
4.4.1.4.Estación STI-C37
4.4.2.Publicación del certificado37
4.4.3.Notificación de la emisión del certificado37
4.5.Uso del par de claves y del certificado37
4.5.1.Uso de las claves privadas y de los certificados37
4.5.1.1.Uso de las claves privadas y de los certificados por el TLM37
4.5.1.2.Uso de las claves privadas y de los certificados por las CA raíz37
4.5.1.3.Uso de las claves privadas y de los certificados por las EA y AA37
4.5.1.4.Uso de las claves privadas y de los certificados por la entidad final38
4.5.2.Uso de las claves privadas y de los certificados por la parte confiante38
4.6.Renovación de certificados38
4.7.Renovación de claves de los certificados38
4.7.1.Circunstancias para la renovación de las claves de un certificado38
4.7.2.Quién puede solicitar una renovación de claves38
4.7.2.1.CA raíz38
4.7.2.2.TLM38
4.7.2.3.EA y AA38
4.7.2.4.Estación STI-C39
4.7.3.Proceso de renovación de claves39
4.7.3.1.Certificado de TLM39
4.7.3.2.Certificado de CA raíz39
4.7.3.3.Certificados de EA y AA39
4.7.3.4.Certificados de estación STI-C40
4.8.Modificación de certificados40
4.9.Revocación y suspensión de certificados40
4.10.Servicios de situación de certificados40
4.10.1.Características operativas40
4.10.2.Disponibilidad del servicio40
4.10.3.Características opcionales40
4.11.Fin de la suscripción40
4.12.Custodia y recuperación de claves40
4.12.1.Suscriptor40
4.12.1.1.Qué par de claves puede custodiarse40
4.12.1.2.Quién puede presentar una solicitud de recuperación40
4.12.1.3.Proceso y responsabilidades de recuperación40
4.12.1.4.Identificación y autenticación40
4.12.1.5.Aprobación o denegación de las solicitudes de recuperación40
4.12.1.6.Acciones KEA y KRA durante la recuperación del par de claves41
4.12.1.7.Disponibilidad de KEA y KRA41
4.12.2.Política y prácticas de encapsulación y recuperación de claves de sesión41
5.Controles operativos, de instalaciones y de gestión41
5.1.Controles físicos41
5.1.1.Ubicación física y construcción41
5.1.1.1.CA raíz, CPOC y TLM41
5.1.1.2.EA/AA42
5.1.2.Acceso físico42
5.1.2.1.CA raíz, CPOC y TLM42
5.1.2.2.EA/AA43
5.1.3.Alimentación eléctrica y aire acondicionado43
5.1.4.Exposición al agua43
5.1.5.Prevención y protección contra incendios44
5.1.6.Gestión de soportes44
5.1.7.Eliminación de residuos44
5.1.8.Copias de seguridad fuera de las instalaciones44
5.1.8.1.CA raíz, CPOC y TLM44
5.1.8.2.EA/AA45
5.2.Controles de procedimiento45
5.2.1.Roles de confianza45
5.2.2.Número de personas necesarias por tarea45
5.2.3.Identificación y autenticación para cada rol46
5.2.4.Roles que requieren separación de funciones46
5.3.Controles de personal47
5.3.1.Requisitos relativos a las cualificaciones, la experiencia y la autorización47
5.3.2.Procedimientos de comprobación de antecedentes47
5.3.3.Requerimientos de formación48
5.3.4.Requerimientos y frecuencia de actualización de la formación48
5.3.5.Frecuencia y secuencia de rotación de tareas48
5.3.6.Sanciones por actuaciones no autorizadas48
5.3.7.Requisitos para los contratistas independientes49
5.3.8.Documentación proporcionada al personal49
5.4.Procedimientos de registro de auditoría49
5.4.1.Tipos de eventos que cada CA debe registrar y notificar49
5.4.2.Frecuencia de tratamiento de los registros50
5.4.3.Período de conservación de los registros de auditoría50
5.4.4.Protección de los registros de auditoría51
5.4.5.Procedimientos de respaldo de los registros de auditoría51
5.4.6.Sistema de recogida de información de auditoría (interno o externo)51
5.4.7.Notificación al sujeto causa del evento51
5.4.8.Análisis de vulnerabilidades51
5.5.Archivo de registros52
5.5.1.Tipos de registros archivados52
5.5.2.Período de conservación del archivo53
5.5.3.Protección del archivo53
5.5.4.Archivo y almacenamiento del sistema53
5.5.5.Requisitos relativos al sellado de tiempo de los registros54
5.5.6.Sistema de compilación de archivos (interno o externo)54
5.5.7.Procedimientos para obtener y verificar la información de los archivos54
5.6.Cambio de claves de los elementos del modelo de confianza STI-C54
5.6.1.TLM54
5.6.2.CA raíz54
5.6.3.Certificado de EA/AA54
5.6.4.Auditor55
5.7.Recuperación en caso de comprometimiento y catástrofe55
5.7.1.Tratamiento de incidentes y comprometimientos55
5.7.2.Corrupción de recursos informáticos, software o datos56
5.7.3.Procedimientos en caso de comprometimiento de claves privadas de entidades56
5.7.4.Capacidad de continuidad de las actividades después de una catástrofe56
5.8.Cese y transferencia57
5.8.1.TLM57
5.8.2.CA raíz57
5.8.3.EA/AA58
6.Controles técnicos de seguridad58
6.1.Generación e instalación de pares de claves58
6.1.1.TLM, CA raíz, EA y AA58
6.1.2.EE: estación STI-C móvil58
6.1.3.EE: estación STI-C fija59
6.1.4.Requisitos criptográficos59
6.1.4.1.Longitud de los algoritmos y de las claves: algoritmos de firma59
6.1.4.2.Longitud de los algoritmos y de las claves: algoritmos de cifrado para la inscripción y la autorización60
6.1.4.3.Criptoagilidad61
6.1.5.Almacenamiento seguro de claves privadas61
6.1.5.1.Nivel de CA raíz, CA subordinada y TLM61
6.1.5.2.Entidad final62
6.1.6.Copia de seguridad de claves privadas63
6.1.7.Destrucción de claves privadas63
6.2.Datos de activación63
6.3.Controles de seguridad informática63
6.4.Controles técnicos del ciclo de vida63
6.5.Controles de seguridad de las redes63
7.Perfiles de los certificados, CRL y CTL63
7.1.Perfil de certificado63
7.2.Validez del certificado64
7.2.1.Certificados de pseudónimos65
7.2.2.Tiques de autorización para estaciones STI-C fijas65
7.3.Revocación de certificados65
7.3.1.Revocación de certificados de CA, EA y AA65
7.3.2.Revocación de las credenciales de inscripción66
7.3.3.Revocación de los tiques de autorización66
7.4.Lista de revocación de certificados66
7.5.Lista de confianza de certificación europea66
8.Auditoría de conformidad y otras evaluaciones66
8.1.Temas cubiertos por la auditoría y base de auditoría66
8.2.Frecuencia de las auditorías67
8.3.Identidad y cualificaciones del auditor67
8.4.Relación del auditor con la entidad auditada67
8.5.Medidas adoptadas como resultado de una deficiencia68
8.6.Comunicación de los resultados68
9.Otras disposiciones68
9.1.Tasas68
9.2.Responsabilidad financiera69
9.3.Confidencialidad de la información empresarial69
9.4.Plan de privacidad69
10.Referencias69
ANEXO III
1.Introducción
1.1.Descripción y ámbito de aplicación de la presente política
La presente política de certificación define el modelo europeo de confianza de los STI-C basado en la infraestructura de clave pública (PKI) dentro del ámbito del sistema de la UE para la gestión de credenciales de seguridad de los STI-C (EU CCMS). Asimismo, define los requisitos relativos a la gestión de los certificados de clave pública para las solicitudes de STI-C por parte de las entidades emisoras, así como el uso de dichos certificados por parte de las entidades finales en Europa. En su nivel más alto, la PKI está compuesta por un conjunto de autoridades de certificación (CA) raíz «habilitadas» a raíz de que el gestor de la lista de confianza (TLM) haya incorporado sus certificados en la lista de confianza de certificación europea (ECTL), emitida y publicada por la entidad TLM central (véanse los epígrafes 1.2 y 1.3).
La presente política es vinculante para todas las entidades que participen en el sistema de confianza STI-C en Europa, y contribuye a la evaluación del nivel de confianza que puede establecerse en la información recibida por cualquier receptor de un mensaje autenticado por un certificado de entidad final de la PKI. Para permitir la evaluación de la confianza en los certificados facilitados por el EU CCMS, la presente política establece un conjunto vinculante de requisitos para el funcionamiento de la entidad TLM central y la elaboración y gestión de la ECTL. Por consiguiente, el presente documento regula los aspectos relacionados con la ECTL que se exponen a continuación:
identificación y autenticación de los principales que obtengan roles en la PKI para el TLM, incluidas las declaraciones de los privilegios asignados a cada rol;
requisitos mínimos de las prácticas locales de seguridad para el TLM, incluidos los controles físicos, de personal y de procedimiento;
requisitos mínimos de las prácticas técnicas de seguridad para el TLM, en particular la seguridad informática, la seguridad de la red y los controles de ingeniería de los módulos criptográficos;
requisitos mínimos para las prácticas operativas del TLM, en particular el registro de nuevos certificados de CA raíz, las bajas temporales o permanentes de las CA raíz inscritas, y la publicación y distribución de actualizaciones de la ECTL;
perfil de la ECTL, en particular los campos de datos obligatorios y opcionales de la ECTL, los algoritmos criptográficos que deben utilizarse, el formato exacto de la ECTL y recomendaciones para el procesamiento de la ECTL;
gestión del ciclo de vida de los certificados ECTL, en particular la distribución, activación, expiración y revocación de los certificados ECTL;
gestión de la revocación de la confianza de las CA raíz, cuando proceda.
Dado que la fiabilidad de la ECTL no depende únicamente de la ECLT en sí, sino también en gran medida de las CA raíz que componen la PKI y sus CA subordinadas, esta política también establece requisitos mínimos obligatorios para todas las CA participantes (CA raíz y CA subordinadas). Los ámbitos de los requisitos son los siguientes:
identificación y autenticación de los principales que obtengan roles PKI (por ejemplo, responsable de la seguridad, responsable de la privacidad, administrador de la seguridad, administrador del directorio y usuario final), lo que incluye una exposición de las funciones, responsabilidades y privilegios asignados a cada rol;
gestión de claves, en particular algoritmos aceptables y obligatorios de firma de certificados y firma de datos, y períodos de validez de los certificados;
requisitos mínimos para prácticas de seguridad local, lo que incluye controles físicos, de personal y de procedimiento;
requisitos mínimos para prácticas de seguridad técnica como la seguridad informática, la seguridad de la red y los controles de ingeniería de los módulos criptográficos;
requisitos mínimos para las prácticas operativas de las CA, EA (autoridades de inscripción), AA (autoridades de autorización) y entidades finales, en particular los aspectos relacionados con el registro, las bajas (es decir, la eliminación de la lista), la revocación, el comprometimiento de claves, la destitución por causa justificada, la actualización de certificados, las prácticas de auditoría y la no divulgación de información relativa a la privacidad;
perfil de certificados y de lista de revocación de certificados (CRL), incluidos los formatos, los algoritmos aceptables, los campos de datos obligatorios y opcionales y sus rangos de valor válidos, y cómo se espera que los verificadores tramiten los certificados;
funciones de supervisión, presentación de informes, alerta y restablecimiento periódicos de las entidades del modelo de confianza STI-C a fin de establecer un funcionamiento seguro, incluso en caso de comportamiento indebido.
Además de estos requisitos mínimos, las entidades que gestionan las CA raíz y las CA subordinadas pueden decidir sus propios requisitos adicionales y establecerlos en las correspondientes declaraciones de prácticas de certificación (CPS), siempre y cuando no sean contrarias a los requisitos establecidos en la política de certificación. Véase el epígrafe 1.5 para obtener más información sobre el modo en que se auditan y publican las CPS.
La CP también indica los fines para los que pueden usarse las CA raíz, las CA subordinadas y los certificados emitidos por ellas. Establece las responsabilidades asumidas por:
el TLM;
cada una de las CA raíz cuyos certificados figuren en la ECTL;
las CA subordinadas (EA y AA) de las CA raíz;
cada miembro u organización que sea responsable de una de las entidades del modelo de confianza STI-C o la gestione.
La CP también define las obligaciones correspondientes a:
el TLM;
cada una de las CA raíz cuyos certificados figuren en la ECTL;
cada CA subordinada certificada por una CA raíz;
todas las entidades finales;
cada miembro u organización que sea responsable de una de las entidades del modelo de confianza STI-C o la gestione.
Para terminar, la CP establece los requisitos relativos a la documentación de limitaciones de las responsabilidades y obligaciones en la CPS de cada CA raíz cuyos certificados figuren en la ECTL.
La presente CP está en consonancia con el marco de la política y las prácticas de certificación adoptado por el Grupo Especial sobre Ingeniería de Internet (IETF) [3].
1.2.Definiciones y siglas
Serán aplicables las definiciones de los documentos de referencia [2], [3] y [4].
|
AA
|
autoridad de autorización
|
|
AT
|
tique de autorización
|
|
CA
|
autoridad de certificación
|
|
CP
|
política de certificación
|
|
CPA
|
autoridad de la política de certificación de los STI-C
|
|
CPOC
|
punto de contacto STI-C
|
|
CPS
|
declaración de prácticas de certificación
|
|
CRL
|
lista de revocación de certificados
|
|
EA
|
autoridad de inscripción
|
|
EC
|
credencial de inscripción
|
|
ECIES
|
esquema de cifrado integrado de curva elíptica
|
|
EE
|
entidad final (es decir, una estación STI-C)
|
|
ECTL
|
lista de confianza de certificación europea
|
|
EU CCMS
|
sistema de la UE para la gestión de credenciales de seguridad de los STI-C
|
|
RGPD
|
Reglamento General de Protección de Datos
|
|
HSM
|
módulo de seguridad hardware
|
|
PKI
|
infraestructura de clave pública
|
|
RA
|
autoridad de registro
|
|
CA subordinada
|
EA y AA
|
|
TLM
|
gestor de la lista de confianza
|
Glosario
|
solicitante
|
Persona física o jurídica que solicita un certificado (o su renovación). Una vez que se haya creado el certificado inicial (inicialización), el solicitante pasará a ser suscriptor.
En el caso de los certificados emitidos a entidades finales, el suscriptor (solicitante de certificado) es la entidad que controla o gestiona/mantiene la entidad final para la que se emite el certificado, aunque la que envíe la solicitud de certificado sea la entidad final.
|
|
autoridad de autorización
|
En el presente documento, «autoridad de autorización» (AA) se refiere no solo a la función específica de AA, sino también a la entidad jurídica u operativa que la gestiona.
|
|
autoridad de certificación
|
La autoridad de certificación (CA) se refiere al conjunto de la autoridad de certificación raíz, la autoridad de inscripción y la autoridad de autorización.
|
|
modelo de confianza STI-C
|
El modelo de confianza STI-C se encarga de establecer una relación de confianza entre las estaciones STI-C. Se implementa mediante el uso de una PKI compuesta por las CA raíz, el CPOC, el TLM, las EA, las AA y una red segura.
|
|
criptoagilidad
|
Capacidad de las entidades del modelo de confianza STI-C de adaptar la CP a los cambios en el entorno o a los nuevos requisitos futuros, por ejemplo, mediante cambios a lo largo del tiempo de los algoritmos criptográficos y de la longitud de la clave.
|
|
módulo criptográfico
|
Elemento basado en hardware seguro dentro del cual se generan o almacenan claves, se generan números aleatorios y se firman o cifran datos.
|
|
autoridad de inscripción
|
En el presente documento, «autoridad de inscripción» (EA) se refiere no solo a la función específica de EA, sino también a la entidad jurídica u operativa que la gestiona.
|
|
participantes de la PKI
|
Entidades del modelo de confianza STI-C, es decir, el TLM, las CA raíz, las EA, las AA y las estaciones STI-C.
|
|
renovación de claves
|
|
|
repositorio
|
El repositorio se usa para almacenar certificados e información sobre certificados facilitada por las entidades del modelo de confianza STI-C, tal y como se define en el epígrafe 2.3.
|
|
autoridad de certificación raíz
|
En el presente documento, «autoridad de certificación (CA) raíz» se refiere no solo a la función específica de CA, sino también a la entidad jurídica u operativa que la gestiona.
|
|
sujeto
|
La persona física, dispositivo, sistema, unidad o persona jurídica identificados en un certificado como el sujeto, es decir, el suscriptor o un dispositivo que este controla y maneja.
|
|
suscriptor
|
Persona física o jurídica a quien se emite un certificado y que está legalmente vinculada por un acuerdo de suscriptor o de condiciones de uso.
|
|
acuerdo de suscriptor
|
Acuerdo entre la CA y el solicitante/suscriptor que especifica los derechos y responsabilidades de las partes.
|
1.3.Participantes de la PKI
1.3.1.Introducción
Los participantes de la PKI tienen un rol en la PKI definido por la presente política. A menos que esté explícitamente prohibido, los participantes pueden asumir varios roles al mismo tiempo. Se les puede prohibir asumir roles específicos al mismo tiempo para evitar conflictos de interés o para garantizar la separación de funciones.
Los participantes también pueden delegar partes de su rol a otras entidades como parte de un contrato de servicios. Por ejemplo, cuando se proporciona información sobre la situación de revocación mediante la CRL, la CA también es la emisora de la CRL, pero puede delegar la responsabilidad de la emisión de CRL a una entidad diferente.
Los roles de la PKI son los siguientes:
roles de autoridad, es decir, cada rol es instanciado por una única entidad;
roles operativos, es decir, cada rol puede ser instanciado por una o más entidades.
Por ejemplo, el rol de CA raíz puede ser ejercido por una entidad comercial, un grupo de interés común, una organización internacional o una organización europea.
La figura 1 muestra la arquitectura del modelo de confianza STI-C basada en [2]. Aquí se describe brevemente la arquitectura, pero los elementos principales se describen con más detalle en los epígrafes 1.3.2 a 1.3.6.
La CPA nombra al TLM, que es por lo tanto una entidad de confianza para todos los participantes de la PKI. La CPA aprueba la operación de la CA raíz y confirma que el TLM puede confiar en las CA raíz. El TLM emite la ECTL que proporciona confianza en las CA raíz aprobadas a todos los participantes de la PKI. La CA raíz emite certificados a la EA y a la AA, proporcionando así confianza en su operación. La EA emite certificados de inscripción a las estaciones STI-C emisoras y retransmisoras (como entidades finales), proporcionando así confianza en su operación. La AA emite AT a las estaciones STI-C sobre la base de la confianza en la EA.
La estación STI-C receptora y retransmisora (como parte retransmisora) puede confiar en otras estaciones STI-C, ya que los AT son emitidos por una AA en la que confía una CA raíz, en la que confían a su vez el TLM y la CPA.
Nótese que la figura 1 solo describe el nivel de CA raíz del modelo de confianza STI-C. La información sobre las capas inferiores se facilita en los epígrafes siguientes de la presente CP o en la CPS de las CA raíz específicas.
La figura 2 proporciona una visión general de los flujos de información entre los participantes de la PKI. Los puntos verdes indican los flujos que requieren comunicaciones de máquina a máquina. Los flujos de información en rojo tienen requisitos definidos en materia de seguridad.
El modelo de confianza STI-C se basa en una arquitectura de CA raíz múltiple, en la que los certificados de la CA raíz se transmiten periódicamente (como se indica más abajo) al punto de contacto central (CPOC) mediante un protocolo de seguridad (por ejemplo, certificados de enlace) definidos por el CPOC.
Las CA raíz pueden ser gestionadas por una organización estatal o privada. La arquitectura del modelo de confianza STI-C contiene al menos una CA raíz (la CA raíz de la Unión con el mismo nivel que las demás CA raíz). Las entidades participantes en el modelo de confianza STI-C que no desean establecer su propia CA raíz delegan en la CA raíz de la Unión. El CPOC transmite los certificados de la CA raíz recibidos al TLM, que es el encargado de recopilar y firmar la lista de certificados de CA raíz y enviarlos de nuevo al CPOC, que los pone a disposición del público (véase más abajo).
Las relaciones de confianza entre las entidades del modelo de confianza STI-C se describen en las figuras, cuadros y secciones siguientes.
Figura 1: Arquitectura del modelo de confianza STI-C
Figura 2: Flujos de información del modelo de confianza STI-C
|
Identificador del flujo
|
Desde
|
A
|
Contenido
|
Referencia
|
|
1)
|
CPA
|
TLM
|
aprobación de la solicitud de la CA raíz
|
8
|
|
2)
|
CPA
|
TLM
|
información sobre la revocación de la CA raíz
|
8.5
|
|
3)
|
CPA
|
CA raíz
|
actualizaciones de la CP
|
1.5
|
|
4)
|
CPA
|
CA raíz
|
aprobación/denegación del formulario de solicitud de la CA raíz o de la solicitud de modificación de la CPS o del proceso de auditoría
|
8.5, 8.6
|
|
5)
|
TLM
|
CPA
|
notificación de modificación de la ECTL
|
4, 5.8.1
|
|
6)
|
TLM
|
CPOC
|
certificado de TLM
|
4.4.2
|
|
7)
|
TLM
|
CPOC
|
ECTL
|
4.4.2
|
|
8)
|
CPOC
|
TLM
|
información del certificado de CA raíz
|
4.3.1.1
|
|
9)
|
CPOC
|
TLM
|
revocación del certificado de CA raíz
|
7.3
|
|
10)
|
CPOC
|
todas las entidades finales
|
certificado de TLM
|
4.4.2
|
|
11)
|
CA raíz
|
CPOC
|
información del certificado de CA raíz
|
4.3.1.1
|
|
12)
|
CA raíz
|
CPOC
|
revocación del certificado de CA raíz
|
7.3
|
|
13)
|
CA raíz
|
auditor
|
encargo de auditoría
|
8
|
|
14)
|
CA raíz
|
CPA
|
formulario de solicitud de la CA raíz — solicitud inicial
|
4.1.2.1
|
|
15)
|
CA raíz
|
CPA
|
formulario de solicitud de la CA raíz — modificaciones de la CPS
|
1.5.1
|
|
16)
|
CA raíz
|
CPA
|
formulario de solicitud de la CA raíz — informe de auditoría
|
8.6
|
|
17)
|
CA raíz
|
CPA
|
informes de incidentes de la CA raíz, incluida la revocación de una CA subordinada (EA, AA)
|
Anexo III, 7.3.1
|
|
18)
|
CA raíz
|
EA
|
respuesta de certificado de EA
|
4.2.2.3
|
|
19)
|
CA raíz
|
AA
|
respuesta de certificado de AA
|
4.2.2.3
|
|
20)
|
CA raíz
|
Todos
|
certificado EA/AA, CRL
|
4.4.2
|
|
21)
|
EA
|
CA raíz
|
solicitud de certificado de EA
|
4.2.2.3
|
|
22)
|
EA
|
estación STI-C
|
respuesta de credencial de inscripción
|
4.3.1.4
|
|
23)
|
EA
|
AA
|
respuesta de autorización
|
4.2.2.5
|
|
24)
|
AA
|
CA raíz
|
solicitud de certificado de AA
|
4.2.2.3
|
|
25)
|
AA
|
EA
|
solicitud de autorización
|
4.2.2.5
|
|
26)
|
AA
|
estación STI-C
|
respuesta de tique de autorización
|
4.3.1.5
|
|
27)
|
EA
|
CA raíz
|
presentación de solicitud
|
4.1.2.3
|
|
28)
|
AA
|
CA raíz
|
presentación de solicitud
|
4.1.2.3
|
|
29)
|
CA raíz
|
EA
|
respuesta
|
4.12 y 4.2.1
|
|
30)
|
CA raíz
|
AA
|
respuesta
|
4.12 y 4.2.1
|
|
31)
|
estación STI-C
|
EA
|
solicitud de credencial de inscripción
|
4.2.2.4
|
|
32)
|
estación STI-C
|
AA
|
solicitud de tique de autorización
|
4.2.2.5
|
|
33)
|
fabricante / operador
|
EA
|
registro
|
4.2.1.4
|
|
34)
|
fabricante / operador
|
EA
|
desactivación
|
7.3
|
|
35)
|
EA
|
fabricante / operador
|
respuesta
|
4.2.1.4
|
|
36)
|
auditor
|
CA raíz
|
informe
|
8.1
|
|
37)
|
todos
|
CPA
|
solicitudes de modificación de la CP
|
1.5
|
|
38)
|
TLM
|
CPA
|
formulario de solicitud
|
4.1.2.2
|
|
39)
|
CPA
|
TLM
|
aprobación/denegación
|
4.1.2.2
|
|
40)
|
TLM
|
CPA
|
informe de auditoría
|
4.1.2.2
|
Cuadro 1:
Descripción detallada de los flujos de información en el modelo de confianza STI-C
1.3.2.Autoridad de la política de certificación de los STI-C
1)La autoridad de la política de certificación de los STI-C (CPA) está compuesta por representantes de partes interesadas públicas y privadas (por ejemplo, Estados miembros, fabricantes de vehículos, etc.) que participan en el modelo de confianza STI-C. Es responsable de dos subroles:
1)gestión de la política de certificación, lo que incluye:
aprobar la CP vigente y las futuras solicitudes de modificación de la CP;
decidir sobre el análisis de las solicitudes y recomendaciones de modificación de la CP presentadas por otros participantes o entidades de la PKI;
decidir sobre la publicación de nuevas versiones de la CP;
2)gestión de las autorizaciones PKI, en particular:
definir, decidir y publicar los procedimientos de aprobación de la CPS y de auditoría de la CA (denominados conjuntamente «procedimientos de aprobación de la CA»);
autorizar al CPOC a que opere y presente informes periódicamente;
autorizar al TLM a que opere y presente informes periódicamente;
aprobar la CPS de la CA raíz, si está en consonancia con la CP válida común;
examinar los informes de auditoría del auditor de la PKI acreditado para todas las CA raíz;
notificar al TLM la lista de las CA raíz aprobadas o no aprobadas y sus certificados sobre la base de los informes de aprobación de las CA raíz y los informes de operaciones regulares recibidos.
2)El representante autorizado de la CPA será el responsable de autenticar al representante autorizado del TLM y aprobar el formulario de solicitud del proceso de inscripción del TLM. La CPA es responsable de autorizar al TLM a que opere, como se menciona en la presente sección.
1.3.3.Gestor de la lista de confianza
3)El TLM es una entidad única designada por la CPA.
4)El TLM se encarga de:
gestionar la ECTL de conformidad con la CP válida común, y presentar periódicamente informes de actividad a la CPA para el funcionamiento global seguro del modelo de confianza STI-C;
recibir certificados de CA raíz procedentes del CPOC;
incluir certificados de CA raíz en la ECTL y excluirlos de ella tras la notificación de la CPA;
firmar la ECTL;
transmitir periódica y oportunamente la ECTL al CPOC.
1.3.4.Auditor de la PKI autorizado
5)El auditor de la PKI autorizado se encarga de:
efectuar u organizar auditorías de CA raíz, TLM y CA subordinadas;
distribuir el informe de auditoría (de una auditoría inicial o periódica) a la CPA, según los requisitos del epígrafe 8; el informe de auditoría debe incluir las recomendaciones del auditor de la PKI acreditado;
notificar a la entidad que gestiona la CA raíz la ejecución satisfactoria o fallida de una auditoría inicial o periódica de las CA subordinadas;
evaluar el cumplimiento de la presente CP por parte de las CPS.
1.3.5.Punto de contacto STI-C (CPOC)
6)El CPOC es una entidad única designada por la CPA. El representante autorizado de la CPA es el responsable de autenticar al representante autorizado del CPOC y aprobar el formulario de solicitud del proceso de inscripción del CPOC. La CPA es responsable de autorizar al CPOC a operar como se especifica en el presente epígrafe.
7)El CPOC se encarga de:
establecer y contribuir al intercambio seguro de información entre todas las entidades del modelo de confianza STI-C de manera eficiente y rápida;
examinar las solicitudes y recomendaciones de cambios de procedimiento presentadas por otros participantes del modelo de confianza (por ejemplo, las CA raíz);
transmitir certificados de la CA raíz al TLM;
publicar el ancla de confianza común (clave pública vigente y certificado de enlace del TLM);
publicar la ECTL.
En el epígrafe 7 figura información pormenorizada sobre la ECTL.
1.3.6.Roles operativos
8)Las siguientes entidades definidas en [2] cumplen un rol operativo, definido en el documento RFC 3647:
|
Elemento funcional
|
Rol PKI ([3] y [4])
|
Rol detallado ([2])
|
|
autoridad de certificación raíz
|
CA/RA (autoridad de registro)
|
Proporciona a la EA y a la AA la prueba de que pueden emitir EC o AT
|
|
autoridad de inscripción
|
suscriptor de una CA raíz / sujeto de un certificado de EA
CA/RA
|
Autentica una estación STI-C y le otorga acceso a las comunicaciones STI
|
|
autoridad de autorización
|
suscriptor de una CA raíz / sujeto de un certificado de AA
CA/RA
|
Proporciona a una estación STI-C una prueba de autoridad de que puede usar servicios STI específicos
|
|
estación STI-C emisora
|
sujeto de un certificado de entidad final (EE) (EC)
|
Adquiere derechos procedentes de la EA para acceder a las comunicaciones STI
Negocia derechos procedentes de la AA para invocar servicios de STI
Envía mensajes de salto único y mensajes de difusión retransmitidos
|
|
estación STI-C retransmisora
|
parte retransmisora/sujeto de un certificado de EE
|
Recibe el mensaje difundido por la estación STI-C emisora y lo reenvía a la estación STI-C receptora, de ser necesario
|
|
estación STI-C receptora
|
parte retransmisora
|
Recibe mensajes de difusión de la estación STI-C emisora o retransmisora
|
|
fabricante
|
suscriptor de la EA
|
Instala la información necesaria para la gestión de la seguridad en la estación STI-C en la producción
|
|
operador
|
suscriptor de la EA/AA
|
Instala y actualiza la información necesaria para la gestión de la seguridad en la estación STI-C durante el funcionamiento
|
Cuadro 2: Roles operativos
Nota: de conformidad con [4], se usan diferentes términos en la presente CP para el «suscriptor» que establece un contrato con la CA para la emisión de certificados y el «sujeto» al que se aplica el certificado. Los suscriptores son las entidades que tienen una relación contractual con una CA. Los sujetos son las entidades a las que se aplica el certificado. Las EA/AA son suscriptoras y sujetos de la CA raíz y pueden solicitar certificados de EA/AA. Las estaciones STI-C son sujetos y pueden solicitar certificados de entidad final.
9)Autoridades de registro:
La EA ejercerá la función de autoridad de registro para las entidades finales. Solamente un suscriptor autenticado y autorizado puede registrar nuevas entidades (estaciones STI-C) en una EA. Las CA raíz correspondientes ejercerán el rol de autoridad de registro para las EA y las AA.
1.4.Utilización de los certificados
1.4.1.Ámbitos de utilización aplicables
10)Los certificados emitidos en el marco de la presente CP están destinados a utilizarse para validar firmas digitales en el contexto de la comunicación STI-C, de conformidad con la arquitectura de referencia de [2].
11)Los perfiles de los certificados incluidos en [5] determinan los usos de los certificados para el TLM, las CA raíz, las EA, las AA y las entidades finales.
1.4.2.Límites de responsabilidad
12)Los certificados no están destinados ni autorizados a ser utilizados en:
circunstancias que infrinjan, incumplan o contravengan cualquier ley, reglamento (como el RGPD), decreto u orden gubernamental vigentes;
circunstancias que incumplan, contravengan o infrinjan los derechos de los demás;
incumplimiento de la presente CP o del acuerdo de suscriptor pertinente;
cualquier circunstancia en la que su uso pudiera provocar directamente la muerte, daños personales o daños medioambientales graves (por ejemplo, por fallo en el funcionamiento de instalaciones nucleares, en la comunicación o la navegación aeronáutica, o en los sistemas de control de armas);
circunstancias que contravengan los objetivos generales de una mayor seguridad vial y un transporte por carretera más eficiente en Europa.
1.5.Administración de la política de certificación
1.5.1.Actualización de las CPS de las CA que figuran en la ECTL
13)Cada CA raíz que figure en la ECTL publicará su propia CPS, que deberá ser conforme con la presente política. Una CA raíz puede añadir requisitos adicionales, pero se asegurará de que todos los requisitos de la presente CP se cumplan en todo momento.
14)Cada CA raíz que figure en la ECTL establecerá un proceso de modificación adecuado para su documento de CPS. Las características principales del proceso de modificación se documentarán en la parte pública de la CPS.
15)Los procesos de modificación garantizarán que todas las modificaciones de la presente CP se analicen detenidamente y, de ser necesario para cumplir con la CP modificada, que la CPS se actualice dentro del plazo establecido en la etapa de aplicación del proceso de modificación de la CP. En particular, el proceso de modificación integrará procedimientos de modificación de emergencia que aseguren la aplicación oportuna de las modificaciones de la CP importantes para la seguridad.
16)El proceso de modificación incluirá medidas adecuadas para verificar que todas las modificaciones de la CPS cumplen la CP. Cualquier modificación de las CPS se documentará claramente. Antes de la aplicación de una nueva versión de una CPS, un auditor de la PKI acreditado debe confirmar su conformidad con la CP.
17)La CA raíz notificará a la CPA, como mínimo, la información siguiente relativa a cualquier modificación que se introduzca en la CPS:
una descripción exacta de la modificación;
la razón de la modificación;
un informe del auditor de la PKI acreditado en el que se confirme la conformidad con la CP;
los datos de contacto de la persona responsable de la CPS;
calendario previsto de aplicación.
1.5.2.Procedimientos de aprobación de la CPS
18)Antes de iniciar sus operaciones, las futuras CA raíz presentarán sus CPS a un auditor de PKI acreditado como parte de un encargo de auditoría de conformidad (flujo 13) y a la CPA para su aprobación (flujo 15).
19)Las CA raíz presentarán las modificaciones de sus CPS a un auditor de PKI acreditado como parte de un encargo de auditoría de conformidad (flujo 13) y a la CPA para su aprobación (flujo 15) antes de que dichas modificaciones entren en vigor.
20)Las EA/AA presentarán sus CPS o modificaciones en sus CPS a la CA raíz, que podrá encargar un certificado de conformidad a un organismo nacional o una entidad privada responsable de la aprobación de las EA/AA, como se define en los epígrafes4.1.2 y 8.
21)El auditor de la PKI acreditado evaluará la CPS de conformidad con el epígrafe 8.
22)El auditor de la PKI acreditado comunicará los resultados de la evaluación de la CPS como parte del informe de auditoría, tal y como se establece en el epígrafe 8.1. La CPS será aceptada o rechazada como parte del informe de auditoría a que se refieren los epígrafes 8.5 y 8.6.
2.Responsabilidades de publicación y repositorio
2.1.Métodos para la publicación de información sobre certificados
23)La información sobre certificados puede publicarse con arreglo al epígrafe 2.5:
de manera periódica; o
en respuesta a la solicitud de una de las entidades participantes.
En cada caso, se aplican diferentes grados de urgencia para la publicación y, por lo tanto, diferentes calendarios, pero las entidades deben estar preparadas para ambas modalidades.
24)La publicación periódica de la información sobre certificados posibilita que se determine una fecha límite máxima de actualización de la información sobre certificados para todos los nodos de la red STI-C. La frecuencia de publicación de toda la información sobre certificados se establece en el epígrafe 2.2.
25)A petición de las entidades que participan en la red STI-C, cualquiera de los participantes puede empezar a publicar información sobre certificados en cualquier momento y, según su rango, solicitar un conjunto vigente de información sobre certificados a fin de convertirse en un nodo de plena confianza de la red STI-C. El objetivo de dicha publicación es, principalmente, poner al día a las entidades sobre el estado general actual de la información sobre certificados en la red y permitirles comunicar sobre una base de confianza hasta la próxima publicación periódica de la información.
26)Una CA raíz también puede iniciar la publicación de la información sobre certificados en cualquier momento, mediante el envío de un conjunto actualizado de certificados a todos los «miembros suscritos» de la red STI-C que sean receptores regulares de dicha información. Esto contribuye al funcionamiento de las CA y les permite dirigirse a los miembros entre las fechas regulares y programadas para la publicación de los certificados.
27)El epígrafe 2.5 establece el mecanismo y todos los procedimientos para publicar los certificados de CA raíz y la ECTL.
28)El CPOC publicará los certificados de CA raíz (tal como figuran en la ECTL y destinados al consumo público), el certificado de TLM y la ECTL que emita.
29)Las CA raíz publicarán sus certificados EA/AA y sus CRL, y podrán utilizar los tres mecanismos mencionados aquí para publicarlos para sus miembros suscritos y las partes confiantes, adoptando todas las medidas necesarias para garantizar la transmisión segura, tal como se indica en el epígrafe 4.
2.2.Temporalidad o frecuencia de la publicación
30)Los requisitos relativos al calendario de publicación de los certificados y las CRL deben determinarse a la luz de los diversos factores de limitación de los nodos de los STI-C, con el objetivo general de operar una «red de confianza» y publicar actualizaciones lo más rápidamente posible destinadas a todas las estaciones STI-C participantes.
Para la publicación periódica de información actualizada sobre certificados (por ejemplo, cambios en la composición de la ECTL o de la CRL), se requiere un período máximo de tres meses para el funcionamiento seguro de la red STI-C.
Las CA raíz publicarán sus certificados de CA y las CRL lo antes posible tras su emisión.
Para la publicación de la CRL, se usará el repositorio de la CA raíz.
Además, las CPS de cada CA especificarán el plazo dentro del cual se publicará un certificado después de que la CA lo emita.
En este epígrafe se especifica únicamente el momento o la frecuencia de la publicación periódica. Los medios de conectividad para actualizar las estaciones STI-C con la ECTL y las CRL en el plazo de una semana a partir de su publicación (en condiciones normales de funcionamiento, por ejemplo, con cobertura de telefonía móvil, vehículo en servicio real, etc.) se aplicarán de conformidad con los requisitos del presente documento.
2.3.Repositorios
31)Los requisitos sobre la estructura del repositorio para el almacenamiento de los certificados y sobre qué información es facilitada por las entidades de la red STI-C, en el caso de las entidades individuales, son los siguientes:
en general, cada CA raíz debería utilizar un repositorio de la información sobre sus propios certificados EA/AA y su CRL actualmente activos a fin de publicar certificados para los demás participantes de la PKI (por ejemplo, un servicio de directorio basado en el LDAP). El repositorio de cada CA raíz aceptará todos los controles de acceso (epígrafe 2.4) y temporalidades de transmisión (epígrafe 2.2) necesarios para cada método de distribución de la información relacionada con los STI-C;
el repositorio del TLM (que almacena la ECTL y los certificados de TLM publicados por el CPOC, por ejemplo) debería basarse en un mecanismo de publicación capaz de garantizar las temporalidades de transmisión establecidas en el epígrafe 2.2 para cada método de distribución.
Aunque no se definen los requisitos de las AA, deben aceptar los mismos niveles de seguridad que las otras entidades y estos deben declararse en sus CPS.
2.4.Controles de acceso a los repositorios
32)Los requisitos relativos al control de acceso a los repositorios de información sobre certificados deberán cumplir al menos las normas generales de tratamiento seguro de la información que se describen en la norma ISO/IEC 27001, así como los requisitos del epígrafe 4. Además, reflejarán las necesidades de seguridad del proceso que se han de establecer para las diferentes etapas del proceso en la publicación de la información sobre certificados.
Esto incluye la implementación del repositorio para los certificados de TLM y la ECTL en el TLM/CPOC. Cada CA u operador de repositorio aplicará controles de acceso en relación con todas las entidades STI-C y partes externas para al menos tres niveles diferentes (por ejemplo, niveles público, restringido a las entidades STI-C, y de CA raíz), a fin de impedir que entidades no autorizadas añadan, modifiquen o supriman entradas del repositorio.
Los mecanismos exactos del control de acceso de cada entidad deberían formar parte de las CPS respectivas.
Para cada CA raíz, los repositorios de la EA y de la AA cumplirán los mismos requisitos en materia de procedimientos de control de acceso, independientemente del lugar o de la relación contractual con el proveedor de servicios que gestione el repositorio.
Como punto de partida para los niveles de control de acceso, cada CA raíz u operador de repositorio debería proporcionar al menos tres niveles diferentes (por ejemplo, niveles público, restringido a las entidades de STI-C, y de CA).
2.5.Publicación de la información sobre certificados
2.5.1.Publicación de la información sobre certificados por el TLM
33)El TLM del ámbito de confianza STI-C común europeo publicará la siguiente información a través del CPOC:
todos los certificados de TLM válidos para el siguiente período de funcionamiento (certificado vigente y de enlace, si se dispone de él);
información sobre el punto de acceso para que el repositorio del CPOC facilite la lista firmada de CA raíz (ECTL);
punto de información general para la ECTL y la implantación de los STI-C.
2.5.2.Publicación de la información sobre certificados por las CA
34)Las CA raíz del ámbito de confianza STI-C común europeo publicarán la siguiente información:
certificados de CA raíz (actualmente válidos) emitidos (certificados vigentes y con la clave correctamente renovada, incluido un certificado de enlace), en el repositorio mencionado en el epígrafe 2.3;
todas las entidades EA y AA válidas, con su identificador de operador y su período de funcionamiento previsto;
certificados de CA emitidos en los repositorios a que se hace referencia en el epígrafe 2.3;
las CRL de todos los certificados de CA revocados que comprendan las EA y AA subordinadas;
información sobre el punto de acceso de la CA raíz a la información de la CRL y la CA.
Toda la información sobre certificados se clasificará según tres niveles de confidencialidad, y los documentos destinados al público en general deben estar a disposición del público sin restricciones.
3.Identificación y autenticación
3.1.Nomenclatura
3.1.1.Tipos de nombre
3.1.1.1.Nombres de TLM, CA raíz, EA y AA
35)El nombre del certificado de TLM consistirá en un atributo único subject_name con el valor reservado «EU_TLM».
36)El nombre de la CA raíz consistirá en un atributo único subject_name con un valor asignado por la CPA. La unicidad de los nombres es responsabilidad exclusiva de la CPA, y el TLM mantendrá el registro de nombres de CA raíz previa notificación de la CPA (aprobación, revocación/supresión de una CA raíz). Los nombres de los sujetos que figuran en los certificados están limitados a 32 bytes. Cada CA raíz propone su nombre a la CPA en el formulario de solicitud (flujo 14). La CPA se encarga de comprobar la unicidad del nombre. Si el nombre no es único, se rechaza el formulario de solicitud (flujo 4).
37)El nombre de cada certificado EA/AA puede consistir en un atributo único subject_name con un valor generado por el emisor del certificado. La CA raíz emisora tiene la responsabilidad exclusiva de la unicidad de los nombres.
38)Los certificados de EA y AA no usarán nombres que excedan los 32 bytes, ya que los subject_name de los certificados están limitados a 32 bytes.
39)Los AT no contendrán ningún nombre.
3.1.1.2.Nombres de las entidades finales
40)A cada estación STI-C se le asignarán dos tipos de identificador único:
un identificador canónico que se almacena en el registro inicial de la estación STI-C bajo la responsabilidad del fabricante; contendrá una subcadena que identifique al fabricante o al operador, de manera que este identificador pueda ser único;
un subject_name, que puede ser parte de la EC de la estación STI-C, bajo la responsabilidad de la EA.
3.1.1.3.Identificación de los certificados
41)Los certificados que se ajusten al formato de [5] se identificarán computando un valor HashedId8, tal como se define en [5] .
3.1.2.Necesidad de que los nombres sean significativos
No hay disposiciones.
3.1.3.Anonimato y pseudonimia de las entidades finales
42)La AA garantizará que se establezca la pseudonimia de una estación STI-C proporcionando a la estación STI-C unos AT que no contengan ningún nombre o información que pueda vincular el sujeto a su verdadera identidad.
3.1.4.Normas para interpretar varios formatos de nombres
No hay disposiciones.
3.1.5.Unicidad de los nombres
43)Los nombres del TLM, las CA raíz, las EA, las AA y los identificadores canónicos de las estaciones STI-C serán únicos.
44)El TLM garantizará, en el proceso de registro de una CA raíz determinada en la ECTL, que su identificador de certificado (HashedId8) sea único. La CA raíz garantizará, en el proceso de emisión, que el identificador de certificado (HashedId8) de cada CA subordinada sea único.
45)El HashedId8 de un EC será único dentro de la CA emisora, mientras que el HashedId8 de un AT no tiene por qué ser único.
3.2.Validación inicial de la identidad
3.2.1.Método para demostrar la posesión de la clave privada
46)La CA raíz demostrará que posee legítimamente la clave privada correspondiente a la clave pública en el certificado autofirmado. El CPOC comprobará esta prueba.
47)La EA/AA demostrará que posee legítimamente la clave privada correspondiente a la clave pública que debe incluirse en el certificado. La CA raíz comprobará esta prueba.
48)La posesión de una nueva clave privada (para renovación de claves) se demostrará mediante la firma de la solicitud con la nueva clave privada (firma interna) seguida de la generación de una firma externa sobre la solicitud firmada con la clave privada válida vigente (para garantizar la autenticidad de la petición). El solicitante enviará la solicitud de certificado firmada a la CA emisora a través de una comunicación segura. La CA emisora comprobará que la firma digital del solicitante que figura en el mensaje de solicitud fue creada usando la clave privada correspondiente a la clave pública adjunta a la solicitud de certificado. La CA raíz especificará qué solicitudes y respuestas de certificado acepta en su CPS.
3.2.2.Autenticación de la identidad de una organización
3.2.2.1.Autenticación de la identidad de la organización de CA raíz
49)En los formularios de solicitud a la CPA (flujo 14), la CA raíz proporcionará la identidad de la organización y la información de registro, compuesta de lo siguiente:
nombre de la organización;
dirección de correos;
dirección de correo electrónico;
nombre de la persona de contacto en la organización;
número de teléfono;
huella digital (valor hash SHA 256) del certificado de CA raíz en forma impresa;
información criptográfica (es decir, algoritmos criptográficos y longitud de las claves) en el certificado de CA raíz;
todos los permisos que se permite a la CA raíz usar y pasar a las CA subordinadas.
50)La CPA comprobará la identidad de la organización y otra información de registro facilitada por el solicitante del certificado para la inclusión de un certificado de CA raíz en la ECTL.
51)La CPA recopilará evidencias directas, o una atestación procedente de una fuente apropiada y autorizada, de la identidad (por ejemplo, el nombre) y, si procede, cualquier atributo específico de los sujetos para los que se emite un certificado. Las evidencias podrán presentarse en papel o en formato electrónico.
52)La identidad del sujeto será verificada en el momento del registro mediante los medios apropiados y de conformidad con la presente política de certificación.
53)En cada solicitud de certificado, se presentará la evidencia de:
el nombre completo de la entidad organizativa (organización privada, entidad estatal o entidad no comercial);
el registro reconocido a nivel nacional u otros atributos que puedan utilizarse, en la medida de lo posible, para distinguir la entidad organizativa de otras con el mismo nombre.
Las normas expuestas arriba se basan en el documento TS 102 042 [4]: La CA garantizará que la evidencia de la identificación del suscriptor y el sujeto, así como la exactitud de sus nombres y datos asociados, se sometan a un examen adecuado como parte del servicio definido o, cuando proceda, se determinen mediante examen de las atestaciones procedentes de fuentes adecuadas y autorizadas, y de que las solicitudes de certificados sean exactas, autorizadas y completas de conformidad con la atestación o las evidencias recabadas.
3.2.2.2.Autenticación de la identidad de la organización del TLM
54)La organización que gestione el TLM deberá aportar evidencias de la identificación y exactitud del nombre y los datos asociados a fin de permitir una verificación adecuada en la creación inicial y en la renovación de claves del certificado TLM.
55)La identidad del sujeto será verificada en el momento de la creación del certificado o de la renovación de claves mediante los medios apropiados y de conformidad con la presente CP.
56)La evidencia de la organización se facilitará como se especifica en el epígrafe 3.2.2.1.
3.2.2.3.Autenticación de la identidad de la organización de CA subordinada
57)La CA raíz comprobará la identidad de la organización y otra información de registro facilitada por los solicitantes de certificados de CA subordinada (EA/AA).
58)Como mínimo, la CA raíz:
determinará que la organización existe usando al menos un servicio o una base de datos de prueba de identidad de un tercero, o bien documentación organizativa emitida o archivada por el organismo estatal pertinente o la autoridad reconocida que confirme la existencia de la organización;
usará el correo postal o un procedimiento comparable para pedir al solicitante del certificado que confirme determinada información sobre la organización, que ha autorizado la solicitud de certificado y que la persona que presenta la solicitud en nombre del solicitante está autorizada a hacerlo. Cuando un certificado incluya el nombre de una persona como representante autorizado de la organización, también confirmará que esa persona es su empleada y que la ha autorizado a actuar en su nombre.
59)Los procedimientos de validación para emitir certificados de CA se documentarán en una CPS de la CA raíz.
3.2.2.4.Autenticación de la organización suscriptora de entidades finales
60)Antes de que el suscriptor de entidades finales (fabricante/operador) pueda registrarse en una EA de confianza para que sus entidades finales puedan enviar solicitudes de certificado EC, la EA:
comprobará la identidad de la organización suscriptora y otra información de registro proporcionada por el solicitante del certificado;
comprobará que el tipo de estación STI-C (es decir, el producto concreto basado en la marca, modelo y versión de la estación STI-C) cumple todos los criterios de evaluación de la conformidad.
61)Como mínimo, la EA:
determinará que la organización existe usando al menos un servicio o una base de datos de prueba de identidad de un tercero, o bien documentación organizativa emitida o archivada por el organismo estatal pertinente o la autoridad reconocida que confirme la existencia de la organización;
usará el correo postal o un procedimiento comparable para pedir al solicitante del certificado que confirme determinada información sobre la organización, que ha autorizado la solicitud de certificado y que la persona que presenta la solicitud en su nombre está autorizada a hacerlo. Cuando un certificado incluya el nombre de una persona como representante autorizado de la organización, también confirmará que esa persona es su empleada y que la ha autorizado a actuar en su nombre.
62)Los procedimientos de validación para el registro de una estación STI-C por su suscriptor se documentarán en una CPS de la EA.
3.2.3.Autenticación de una entidad individual
3.2.3.1.Autenticación de una entidad individual de TLM/CA
63)Para la autenticación de una entidad individual (persona física) identificada en asociación con una persona jurídica o entidad organizativa (por ejemplo, el suscriptor), se aportarán evidencias de lo siguiente:
nombre completo del sujeto (apellidos y nombre, en consonancia con la legislación aplicable y las prácticas nacionales de identificación);
fecha y lugar de nacimiento, referencia a un documento de identidad reconocido a nivel nacional u otros atributos del suscriptor que puedan usarse, en la medida de lo posible, para distinguir a la persona de otras con el mismo nombre;
nombre completo y condición jurídica de la persona jurídica u otras entidades organizativas asociadas (por ejemplo, el suscriptor);
cualquier información de registro pertinente (por ejemplo, registro de la empresa) de la persona jurídica u otra entidad organizativa asociada;
evidencia de que el sujeto está asociado con la persona jurídica u otra entidad organizativa.
Las evidencias podrán presentarse en papel o en formato electrónico.
64)Para verificar su identidad, el representante autorizado de una CA raíz, EA, AA o suscriptor facilitará documentación que demuestre que trabaja para la organización (certificado de autorización). Además, presentará un documento de identidad oficial.
65)Para el proceso inicial de inscripción (flujo 31/32), un representante de la EA/AA facilitará a la CA raíz correspondiente toda la información necesaria (véase el epígrafe 4.1.2).
66)El personal de la CA raíz verificará la identidad del representante del solicitante del certificado y todos los documentos asociados, aplicando los requisitos de «personal de confianza», según lo establecido en el epígrafe 5.2.1. (El proceso de validación de la información sobre la solicitud y la generación del certificado por la CA raíz los llevarán a cabo «personas de confianza» de la CA raíz, bajo una supervisión doble, como mínimo, ya que son operaciones sensibles en el sentido del epígrafe 5.2.2).
3.2.3.2.Autenticación de la identidad del suscriptor de las estaciones STI-C
67)Los suscriptores están representados por usuarios finales autorizados en la organización, que están registrados en las EA y AA emisoras. Estos usuarios finales designados por organizaciones (fabricantes u operadores) demostrarán su identidad y autenticidad antes de:
registrar la EE en su EA correspondiente, incluidos su clave pública canónica, su identificador canónico (identificador único) y los permisos de conformidad con la EE;
registrarse en la AA y aportar la prueba de un acuerdo de suscriptor que puede enviarse a la EA.
3.2.3.3.Autenticación de la identidad de las estaciones STI-C
68)Las EE que sean sujetos de EC se autenticarán a sí mismas cuando soliciten EC (flujo 31) usando su clave privada canónica para la autenticación inicial. La EA verificará la autenticación utilizando la clave pública canónica correspondiente a la EE. Las claves públicas canónicas de las EE se transmiten a la EA antes de que se ejecute la solicitud inicial, por un canal seguro entre el fabricante o el operador de la estación STI-C y la EA (flujo 33).
69)Las EE que sean sujetos de AT se autenticarán a sí mismas cuando soliciten AT (flujo 32) usando su clave privada de inscripción única. La AA transmitirá la firma a la EA (flujo 25) para su validación; la EA la validará y confirmará el resultado a la AA (flujo 23).
3.2.4.Información no verificada sobre el suscriptor
No hay disposiciones.
3.2.5.Validación de la autoridad
3.2.5.1.Validación del TLM y de las CA raíz , EA y AA
70)Cada organización identificará en la CPS al menos un representante (por ejemplo, un responsable de seguridad) encargado de solicitar nuevos certificados y renovaciones. Se aplicarán las normas de nomenclatura del epígrafe 3.2.3.
3.2.5.2.Validación de los suscriptores de estaciones STI-C
71)Al menos una persona física responsable de registrar las estaciones STI-C en una EA (por ejemplo, un responsable de la seguridad) deberá ser conocida y aprobada por la EA (véase el epígrafe 3.2.3).
3.2.5.3.Validación de las estaciones STI-C
72)Los suscriptores de estaciones STI-C podrán registrar estaciones STI-C en una EA específica (flujo 33) siempre y cuando estén autenticados en esa EA.
Cuando la estación STI-C esté registrada en una EA con un identificador canónico único y una clave pública canónica, puede solicitar una EC utilizando una solicitud firmada con la clave privada canónica relacionada con la clave pública canónica registrada previamente.
3.2.6.Criterios de interoperabilidad
73)Para la comunicación entre las estaciones STI-C y las EA (o AA), la estación STI-C será capaz de establecer una comunicación segura con las EA (o AA), es decir, de llevar a cabo funciones de autenticación, confidencialidad e integridad, tal como se especifica en [1]. Pueden utilizarse otros protocolos, siempre que se aplique [1]. La EA y la AA aceptarán esta comunicación segura.
74)La EA y la AA aceptarán las solicitudes y las respuestas de certificado que se ajusten a lo dispuesto en [1], que establece un protocolo seguro de solicitud/respuesta AT que permite el anonimato del solicitante con respecto a la AA y la separación de funciones entre la AA y la EA. Pueden utilizarse otros protocolos, siempre que se aplique [1]. Para evitar la divulgación de la identidad a largo plazo de las estaciones STI-C, la comunicación entre una estación STI-C móvil y una EA será confidencial (por ejemplo, los datos de comunicación estarán cifrados de extremo a extremo).
75)La AA enviará una solicitud de validación de la autorización (flujo 25) por cada solicitud de autorización que reciba de un sujeto de certificado EE. La EA validará esta solicitud respecto a:
la condición de la EE en la EA;
la validez de la firma;
los identificadores de aplicación STI (ITS-AID) y permisos solicitados;
la situación de la prestación de servicios de la AA al suscriptor.
3.3.Identificación y autenticación de las solicitudes de renovación de claves
3.3.1.Identificación y autenticación de las solicitudes de renovación de claves de rutina
3.3.1.1.Certificados de TLM
76)El TLM genera un par de claves y dos certificados: un certificado autofirmado y un certificado de enlace a los que se hace referencia en el epígrafe 7.
3.3.1.2.Certificados de CA raíz
No aplicable.
3.3.1.3.Renovación de certificados o de las claves de certificados de EA/AA
77)Antes de la expiración de un certificado de EA/AA, la EA/AA solicitará un nuevo certificado (flujo 21/24) para mantener la continuidad de uso del certificado. La EA/AA generará un nuevo par de claves para sustituir el par de claves que expira y firmará la solicitud de renovación de claves que contenga la nueva clave pública con la clave privada válida vigente («renovación de claves»). La EA o la AA genera un nuevo par de claves y firma la solicitud con la nueva clave privada (firma interna) para demostrar que posee la nueva clave privada. La solicitud completa se firma (por encima) con la clave privada válida vigente (firma externa) para garantizar la integridad y la autenticidad de la solicitud. Si se utiliza un par de claves de cifrado y descifrado, deberá demostrarse la posesión de las claves privadas de descifrado (para una descripción detallada de la renovación de claves, véase el epígrafe 4.7.3.3).
78)El método de identificación y autenticación para la renovación de claves de rutina es el mismo que para la emisión inicial de una validación inicial del certificado de CA raíz, como se indica en el epígrafe 3.2.2.
3.3.1.4.Credenciales de inscripción de las entidades finales
79)Antes de la expiración de un EC vigente, la EE solicitará un nuevo certificado (flujo 31) para mantener la continuidad de uso del certificado. La EE generará un nuevo par de claves para sustituir el par de claves que expira y solicitará un nuevo certificado que contenga la nueva clave pública; la solicitud se firmará con la clave privada válida vigente de la EC.
80)La EE puede firmar la solicitud con la clave privada que se acaba de crear (firma interna) para demostrar que posee la nueva clave privada. Después, la solicitud completa se firma (por encima) con la clave privada válida vigente (firma externa) y se cifra con destino a la EA receptora como se especifica en [1], para garantizar la confidencialidad, la integridad y la autenticidad de la solicitud. Pueden utilizarse otros protocolos, siempre que se aplique [1].
3.3.1.5.Tiques de autorización de las entidades finales
81)La renovación de claves de certificados para los AT se basa en el mismo proceso que la autorización inicial, como se define en [1]. Pueden utilizarse otros protocolos, siempre que se aplique [1].
3.3.2.Identificación y autenticación de las solicitudes de renovación de claves tras una revocación
3.3.2.1.Certificados de CA
82)La autenticación de una organización de CA para renovar las claves de certificados de CA raíz, EA y AA tras una revocación se tramita del mismo modo que la emisión inicial de un certificado de CA, tal como se establece en el epígrafe 3.2.2.
3.3.2.2.Credenciales de inscripción de las entidades finales
83)La autenticación de una EE para renovar las claves de un certificado de EC tras una revocación se tramita del mismo modo que la emisión inicial de un certificado de EE, tal como se establece en el epígrafe 3.2.2.
3.3.2.3.Solicitudes de autorización de las entidades finales
No se aplica, ya que los AT no se revocan.
3.4.Identificación y autenticación de las solicitudes de revocación
3.4.1.Certificados de CA raíz/EA/AA
84)Las solicitudes de supresión de un certificado de CA raíz de la ECTL serán autenticadas por la CA raíz al TLM (flujos 12 y 9). Las solicitudes de revocación de un certificado EA/AA serán autenticadas por la CA raíz correspondiente y la propia CA subordinada.
85)Entre los procedimientos aceptables para la autenticación de las solicitudes de revocación de un suscriptor figuran los siguientes:
un mensaje escrito y firmado en papel de correspondencia de empresa enviado por el suscriptor que solicita la revocación, con referencia al certificado que debe revocarse;
una comunicación con el suscriptor que ofrezca garantías razonables de que la persona u organización que solicita la revocación es de hecho el suscriptor. Dependiendo de las circunstancias, dicha comunicación podrá realizarse por uno o varios de los siguientes medios: correo electrónico, correo postal o servicio de mensajería.
3.4.2.Credenciales de inscripción de estaciones STI-C
86)El suscriptor de estaciones STI-C puede revocar la EC de una estación STI-C registrada anteriormente en una EA (flujo 34). El suscriptor solicitante creará una solicitud de revocación de una estación STI-C determinada o de una lista de estaciones STI-C. La EA autenticará la solicitud de revocación antes de su tramitación y confirmará la revocación de las estaciones STI-C y de sus EC.
87)La EA puede revocar la EC de una estación STI-C de conformidad con el epígrafe 7.3.
3.4.3.Tiques de autorización de estaciones STI-C
88)Debido a que los AT no se revocan, su validez estará limitada a un período específico. Los diferentes períodos de validez aceptables en la presente política de certificación se especifican en el epígrafe 7.
4.Requisitos operativos para el ciclo de vida de los certificados
4.1.Solicitud de certificado
89)El presente epígrafe establece los requisitos de las solicitudes iniciales de emisión de certificados.
90)El término «solicitud de certificado» se refiere a los siguientes procesos:
registro y establecimiento de una relación de confianza entre el TLM y la CPA;
registro y establecimiento de una relación de confianza entre la CA raíz y la CPA y el TLM, lo que incluye la inclusión del primer certificado de CA raíz en la ECTL;
registro y establecimiento de una relación de confianza entre la EA/AA y la CA raíz, lo que incluye la emisión de un nuevo certificado de EA/AA;
registro de la estación STI-C en la EA por parte del fabricante/operador;
solicitud de EC/AT por parte de la estación STI-C.
4.1.1.Quién puede presentar una solicitud de certificado
4.1.1.1.CA raíz
91)Las CA raíz generan sus propios pares de claves y emiten sus certificados raíz ellas mismas. Las CA raíz pueden presentar una solicitud de certificado mediante su representante designado (flujo 14).
4.1.1.2.TLM
92)El TLM genera su propio par de claves y emite su certificado él mismo. La creación inicial del certificado de TLM será tramitada por un representante de la organización del TLM bajo el control de la CPA.
4.1.1.3.EA y AA
93)Un representante autorizado de la EA o de la AA puede presentar la solicitud de certificado de CA subordinada (EA o AA) al representante autorizado de la CA raíz que corresponda (flujo 27/28).
4.1.1.4.Estación STI-C
94)Los suscriptores registrarán cada estación STI-C en la EA de conformidad con el epígrafe 3.2.5.3.
95)Cada estación STI-C registrada en la EA puede enviar solicitudes de EC (flujo 31).
96)Cada estación STI-C puede enviar solicitudes de AT (flujo 32) sin solicitar ninguna interacción del suscriptor. Antes de solicitar un AT, las estaciones STI-C deberán tener una EC.
4.1.2.Proceso y responsabilidades de inscripción
97)Solamente los Estados miembros en los que se encuentran las organizaciones pueden conceder permisos para las CA raíz y las CA subordinadas que emiten certificados para fines especiales (estatales), es decir, estaciones STI-C móviles y fijas especiales.
4.1.2.1.CA raíz
98)Tras ser auditadas (flujos 13 y 36, epígrafe 8), las CA raíz pueden solicitar a la CPA la inclusión de sus certificados en la ECTL (flujo 14). El proceso de inscripción se basa en un formulario de solicitud manual firmado que el representante autorizado de la CA raíz entregará físicamente a la CPA y que contiene, como mínimo, la información que figura en los epígrafes 3.2.2.1, 3.2.3 y 3.2.5.1.
99)El formulario de solicitud de la CA raíz estará firmado por su representante autorizado.
100)Además del formulario de solicitud, el representante autorizado de la CA raíz proporcionará a la CPA una copia de la CPS de la CA raíz (flujo 15) y su informe de auditoría para su aprobación (flujo 16). En caso de aprobación positiva, la CPA genera y envía un certificado de conformidad al CPOC/TLM y a la CA raíz correspondiente.
101)El representante autorizado de la CA raíz presentará entonces al CPOC/TLM su formulario de solicitud (que contiene la huella del certificado autofirmado), el identificador oficial y una prueba de la autorización. El certificado autofirmado será entregado por vía electrónica al CPOC/TLM. El CPOC/TLM verificará todos los documentos y el certificado autofirmado.
102)Si las verificaciones son positivas, el TLM añadirá el certificado de CA raíz a la ECTL basándose en la notificación procedente de la CPA (flujos 1 y 2). En la CPS del TLM se describe el procedimiento detallado.
103)Debería ser posible un procedimiento adicional para obtener la aprobación de la CPS y del informe de auditoría de una CA raíz en un organismo oficial de países específicos.
4.1.2.2.TLM
104)Tras ser auditado, el TLM puede inscribirse ante la CPA. El proceso de inscripción se basa en un formulario de solicitud manual firmado que el representante autorizado del TLM entregará físicamente a la CPA (flujo 38) y que contiene, como mínimo, la información que figura en epígrafes 3.2.2.2 y 3.2.3.
105)El formulario de solicitud del TLM será firmado por su representante autorizado.
106)En primer lugar, el TLM genera su certificado autofirmado y lo transmite de forma segura a la CPA. Después, el TLM entrega a la CPA su formulario de solicitud (que contiene la huella del certificado autofirmado), un ejemplar de su CPS, un identificador oficial, una prueba de autorización y su informe de auditoría (flujo 40). La CPA comprobará todos los documentos y el certificado autofirmado. Si la verificación de todos los documentos, del certificado autofirmado y de la huella es positiva, la CPA confirmará el proceso de inscripción enviando su aprobación al TLM y al CPOC (flujo 39). La CPA almacenará la información de la solicitud enviada por el TLM. El certificado de TLM se emite entonces a través del CPOC.
4.1.2.3.EA y AA
107)Durante el proceso de inscripción, la EA/AA presentará los documentos pertinentes (por ejemplo, la CPS y el informe de auditoría) a la CA raíz correspondiente para su aprobación (flujo 27/28). Si la comprobación de los documentos es positiva, la CA raíz envía un aprobación a las CA subordinadas correspondientes (flujo 29/30). La CA subordinada (EA o AA) transmitirá después por vía electrónica su solicitud firmada y entregará físicamente su formulario de solicitud (de conformidad con el epígrafe 3.2.2.1), la prueba de autorización y el documento de identificación a la CA raíz correspondiente. La CA raíz verifica la solicitud y los documentos recibidos (formulario de solicitud que contiene la huella, que es el valor hash SHA 256 de la solicitud de la CA subordinada, la prueba de autorización y el documento de identificación). Si todas las comprobaciones conducen a un resultado positivo, la CA raíz emite el correspondiente certificado de CA subordinada. La información detallada sobre cómo se realiza una solicitud inicial se describe en su CPS específica.
108)Además del formulario de solicitud de la CA subordinada, el representante autorizado de la CA subordinada adjuntará una copia de la CPS a la CA raíz.
109)La información se transmitirá a un auditor de la PKI acreditado para su auditoría de conformidad con el epígrafe 8.
110)Si la CA subordinada es propiedad de una entidad diferente de la entidad propietaria de la CA raíz, antes de emitir una solicitud de certificado de CA subordinada, la entidad de la CA subordinada firmará un contrato relativo al servicio de CA raíz.
4.1.2.4.Estación STI-C
111)El suscriptor responsable (fabricante/operador) realizará el registro inicial de los sujetos de entidad final (estaciones STI-C) ante la EA (flujos 33 y 35) tras la autenticación satisfactoria de la organización suscriptora y de uno de sus representantes, de conformidad con los epígrafes 3.2.2.4 y 3.2.5.2.
112)Las estaciones STI-C pueden generar un par de claves EC (véase el epígrafe 6.1) y crear una solicitud de EC firmada de conformidad con [1]. Pueden utilizarse otros protocolos, siempre que se aplique [1].
113)Durante el registro de una estación STI-C normal (a diferencia de una estación STI-C móvil o fija especial), la EA debe verificar que los permisos de la solicitud inicial no están destinados a un uso estatal. Los permisos para uso estatal están definidos por los Estados miembros correspondientes. El procedimiento detallado para el registro y la respuesta de la EA al fabricante/operador (flujos 33 y 35) se establecerá en la correspondiente CPS de la EA.
114)Las estaciones STI-C podrán inscribirse en una EA (epígrafe 3.2.5.3) enviando su solicitud inicial de EC de conformidad con [1].
115)Tras el registro inicial por parte de un representante del suscriptor autenticado, la EA aprueba qué AT puede obtener el sujeto de entidad final (es decir, la estación STI-C). Además, a cada entidad final se le asigna un nivel de garantía de confianza, que está relacionado con la certificación de la entidad final de conformidad con uno de los perfiles de protección enumerados en el epígrafe 6.1.5.2.
116)Los vehículos ordinarios solo tendrán una estación STI-C, registrada en una sola EA. Los vehículos especiales (como los coches de policía y otros vehículos especiales con derechos específicos) pueden estar registrados en una EA adicional o contar con una estación STI-C adicional para las autorizaciones correspondientes al ámbito de su finalidad especial. Los responsables de los Estados miembros determinarán a qué vehículos se aplican las exenciones, y serán los únicos que concederán los permisos para estaciones STI-C móviles y fijas especiales. La CPS de las CA raíz o de las CA subordinadas que emitan certificados para este tipo de vehículos en esos Estados miembros determinará cómo se aplica el proceso de certificación a dichos vehículos.
117)Cuando el suscriptor esté en proceso de migrar una estación STI-C de una EA a otra, la estación podrá estar registrada en dos EA (similares).
118)Las estaciones STI-C generan un par de claves AT (véase el epígrafe 6.1) y crean una solicitud de AT de conformidad con [1]. Pueden utilizarse otros protocolos, siempre que se aplique [1].
119)Las estaciones STI-C envían una solicitud de autorización a la URL de la AA (flujos 32 y 26) enviando al menos la información requerida mencionada en el epígrafe 3.2.3.3. La AA y la EA validan la autorización para cada solicitud, de conformidad con los epígrafes 3.2.6 y 4.2.2.5.
4.2.Tramitación de las solicitudes de certificado
4.2.1.Realización de las funciones de identificación y autenticación
4.2.1.1.Identificación y autenticación de las CA raíz
120)El representante autorizado de la CPA es el responsable de autenticar al representante autorizado de la CA raíz y aprobar su proceso de inscripción, de conformidad con el epígrafe 3.
4.2.1.2.Identificación y autenticación del TLM
121)El representante autorizado de la CPA es el responsable de autenticar al representante autorizado del TLM y aprobar su formulario de solicitud del proceso de inscripción, de conformidad con el epígrafe 3.
4.2.1.3.Identificación y autenticación de la EA y la AA
122)La CA raíz correspondiente es responsable de autenticar al representante autorizado de la EA/AA y aprobar su formulario de solicitud del proceso de inscripción, de conformidad con el epígrafe 3.
123)La CA raíz confirmará su validación positiva del formulario de solicitud a la EA/AA. La EA/AA puede entonces enviar una solicitud de certificado a la CA raíz (flujos 21 y 24), que emitirá los certificados a la EA/AA correspondiente (flujo 18/19).
4.2.1.4.Identificación y autenticación del suscriptor de EE
124)Antes de que una estación STI-C pueda solicitar un certificado de EC, el suscriptor de EE transmitirá de forma segura a la EA la información del identificador de la estación STI-C (flujo 33). La EA verificará la solicitud y, en caso de verificación positiva, registrará la información de la estación STI-C en su base de datos y la confirmará al suscriptor de EE (flujo 35). El fabricante u operador realiza esta operación solo una vez para cada estación STI-C. Una vez que la estación STI-C ha sido registrada por una EA, puede solicitar a la vez un único certificado de EC que necesite (flujo 31). La EA autentica y verifica que la información contenida en la solicitud de certificado de EC es válida para una estación STI-C.
4.2.1.5.Tiques de autorización
125)Durante las solicitudes de autorización (flujo 32), de conformidad con [1], la AA debe autenticar a la EA de la que la estación STI-C recibió su EC. Pueden utilizarse otros protocolos, siempre que se aplique [1]. Si la AA no es capaz de autenticar a la EA, la solicitud es rechazada (flujo 26). Como requisito, la AA poseerá el certificado de EA para autenticar a la EA y verificar su respuesta (flujos 25 y 23 y epígrafe 3.2.5.3).
126)La EA autentica la estación STI-C que solicita un AT verificando su EC (flujos 25 y 23).
4.2.2.Aprobación o denegación de las solicitudes de certificado
4.2.2.1.Aprobación o denegación de certificados de CA raíz
127)El TLM introduce y suprime los certificados de CA raíz en la ECTL de conformidad con la aprobación de la CPA (flujo 1/2).
128)El TLM debería verificar la firma, la información y la codificación de los certificados de CA raíz tras recibir una aprobación de la CPA (flujo 1). Tras la validación positiva y la aprobación de la CPA, el TLM pondrá el certificado raíz correspondiente en la ECTL y lo notificará a la CPA (flujo 5).
4.2.2.2.Aprobación o denegación del certificado de TLM
129)La CPA es responsable de aprobar o rechazar los certificados de TLM.
4.2.2.3.Aprobación o denegación de certificados de EA y AA
130)La CA raíz verifica las solicitudes de certificado de CA subordinada (flujo 21/ 24) y los informes pertinentes (emitidos por el auditor de la PKI acreditado) cuando los recibe (flujo 36, epígrafe 8) de la correspondiente CA subordinada de la CA raíz. Si la comprobación de la solicitud conduce a un resultado positivo, la CA raíz correspondiente emite un certificado a la EA/AA solicitante (flujo 18/19); en caso contrario, se rechaza la solicitud y no se emitirá ningún certificado a la AE/AA.
4.2.2.4.Aprobación o denegación de EC
131)La EA verificará y validará las solicitudes de EC de conformidad con los epígrafes 3.2.3.2 y 3.2.5.3.
132)Si la solicitud de certificado de conformidad con [1] es correcta y válida, la EA generará el certificado solicitado.
133)Cuando la solicitud de certificado no es válida, la EA lo rechaza y envía una respuesta que expone el motivo de la denegación, de conformidad con [1]. Si una estación STI-C desea aun así una EC, presentará una nueva solicitud de certificado. Pueden utilizarse otros protocolos, siempre que se aplique [1].
4.2.2.5.Aprobación o denegación de AT
134)La EA comprueba la solicitud de certificado. La AA establecerá una comunicación con la EA para validar la solicitud (flujo 25). La EA autenticará a la estación STI-C solicitante y validará si tiene derecho a recibir el AT solicitado según lo estipulado en la CP (por ejemplo, comprobando la situación de revocación, la validez temporal y regional, los permisos, el nivel de garantía, etc.). La EA devolverá una respuesta de validación (flujo 23) y, si la respuesta es positiva, la AA generará el certificado solicitado y lo transmitirá a la estación STI-C. Si la solicitud de AT no es correcta o la respuesta de validación de la EA es negativa, la AA rechaza la solicitud. Si una estación STI-C aun así requiere un AT, presentará una nueva solicitud de autorización.
4.2.3.Plazo para procesar la solicitud de certificado
4.2.3.1.Solicitud de certificado de CA raíz
135)La tramitación del proceso de identificación y autenticación de una solicitud de certificado se realiza durante los días laborables y estará sujeta a un plazo máximo establecido en la CPS de la CA raíz.
4.2.3.2.Solicitud de certificado de TLM
136)La tramitación de la solicitud de certificado de TLM estará sujeta a un plazo máximo establecido en la CPS del TLM.
4.2.3.3.Solicitud de certificado de EA y AA
137)La tramitación del proceso de identificación y autenticación de una solicitud de certificado se realiza durante los días laborables, de conformidad con el acuerdo y el contrato entre la CA raíz del Estado miembro u organización privada y la CA subordinada. El plazo para tramitar las solicitudes de certificado de CA subordinada estará sujeto a un límite máximo establecido en la CPS de la CA subordinada.
4.2.3.4.Solicitud de EC
138)La tramitación de las solicitudes de EC estará sujeta a un plazo máximo establecido en la CPS de la EA.
4.2.3.5.Solicitud de AT
139)La tramitación de las solicitudes de AT estará sujeta a un plazo máximo establecido en la CPS de la AA.
4.3.Emisión de certificados
4.3.1.Acciones de la CA durante la emisión de certificados
4.3.1.1.Emisión de certificados de CA raíz
140)Las CA raíz emiten sus propios certificados autofirmados de CA raíz, certificados de enlace, certificados de CA subordinada y CRL.
141)Tras la aprobación de la CPA (flujo 4), la CA raíz envía su certificado al TLM a través del CPOC para que se añada a la ECTL (flujos 11 y 8) (véase el epígrafe 4.1.2.1). El TLM comprueba si la CPA ha aprobado el certificado (flujo 1).
4.3.1.2.Emisión de certificados de TLM
142)El TLM emite su propio certificado de TLM y de enlace autofirmado y lo envía al CPOC (flujo 6).
4.3.1.3.Emisión de certificados de EA y AA
143)Las CA subordinadas generan una solicitud de certificado firmada y la transmiten a la CA raíz correspondiente (flujos 21 y 24). La CA raíz verifica la solicitud y emite un certificado a la CA subordinada solicitante de conformidad con [5] lo antes posible, como se estipula en la CPS para las prácticas operativas habituales, pero en un plazo máximo de cinco días laborables tras la recepción de la solicitud.
144)La CA raíz actualizará el repositorio que contenga los certificados de las CA subordinadas.
4.3.1.4.Emisión de EC
145)Las estaciones STI-C enviarán una solicitud de EC a la EA, de conformidad con [1]. La EA autenticará y verificará que la información contenida en la solicitud de certificado es válida para una estación STI-C. Pueden utilizarse otros protocolos, siempre que se aplique [1].
146)En caso de validación positiva, la EA emitirá un certificado, de conformidad con el registro de la estación STI-C (véase el epígrafe 4.2.1.4), y lo enviará a la estación STI-C usando un mensaje de respuesta de EC, de conformidad con [1]. Pueden utilizarse otros protocolos, siempre que se aplique [1].
147)Si no hay registro, la EA generará un código de error y lo enviará a la estación STI-C utilizando un mensaje de respuesta de EC, de conformidad con [1]. Pueden utilizarse otros protocolos, siempre que se aplique [1].
148)Las solicitudes y respuestas de EC se cifrarán para garantizar la confidencialidad y se firmarán para garantizar la autenticación y la integridad.
4.3.1.5.Emisión de AT
149)La estación STI-C enviará un mensaje de solicitud de AT a la AA, de conformidad con [1]. La AA enviará a la EA una solicitud de validación de AT, de conformidad con [1]. La EA enviará a la AA una respuesta de validación de AT. En caso de respuesta positiva, la AA generará un AT y lo enviará a la estación STI-C utilizando un mensaje de respuesta de AT, de conformidad con [1]. En caso de respuesta negativa, la AA generará un código de error y lo enviará a la estación STI-C utilizando un mensaje de respuesta de AT, de conformidad con [1]. Pueden utilizarse otros protocolos, siempre que se aplique [1].
150)Las solicitudes y respuestas de AT se cifrarán (solo es necesario en el caso de las estaciones STI-C móviles) para garantizar la confidencialidad y se firmarán para garantizar la autenticación y la integridad.
4.3.2.Notificación de la CA al suscriptor sobre la emisión de certificados
No aplicable.
4.4.Aceptación de certificados
4.4.1.Forma en la que se acepta el certificado
4.4.1.1.CA raíz
No aplicable.
4.4.1.2.TLM
No aplicable.
4.4.1.3.EA y AA
151)La EA/AA verificará el tipo de certificado, la firma y la información del certificado recibido. La EA/AA eliminará todos los certificados de EA/AA que no estén correctamente verificados y emitirá una nueva solicitud.
4.4.1.4.Estación STI-C
152)La estación STI-C contrastará la respuesta de EC/AT recibida de la EA/AA con su solicitud inicial, incluida la firma y la cadena de certificación. Eliminará todas las respuestas de EC/AT que no se hayan verificado correctamente. En tales casos, debería enviar una nueva solicitud de EC/AT.
4.4.2.Publicación del certificado
153)Los certificados de TLM y sus certificados de enlace se pondrán a disposición de todos los participantes a través del CPOC.
154)El CPOC publica los certificados de CA raíz mediante la ECTL, firmada por el TLM.
155)La CA raíz publica los certificados de las CA subordinadas (EA y AA).
156)Las EC y los AT no se publican.
4.4.3.Notificación de la emisión del certificado
No hay notificaciones de emisión.
4.5.Uso del par de claves y del certificado
4.5.1.Uso de las claves privadas y de los certificados
4.5.1.1.Uso de las claves privadas y de los certificados por el TLM
157)El TLM usará sus claves privadas para firmar sus propios certificados (TLM y enlace) y la ECTL.
158)Los participantes de la PKI usarán el certificado de TLM para verificar la ECTL y autenticar el TLM.
4.5.1.2.Uso de las claves privadas y de los certificados por las CA raíz
159)Las CA raíz usarán sus claves privadas para firmar sus propios certificados, la CRL, los certificados de enlace y los certificados de EA/AA.
160)Los participantes de la PKI usarán los certificados de CA raíz para verificar los certificados de AA y EA asociados, los certificados de enlace y las CRL.
4.5.1.3.Uso de las claves privadas y de los certificados por las EA y AA
161)Las EA usarán sus claves privadas para firmar EC y para el descifrado de la solicitud de inscripción.
162)Los certificados de EA se usarán para verificar la firma de las EC asociadas y para el cifrado de las solicitudes de EC y AT por las EE, tal como se define en [1].
163)Las AA usarán sus claves privadas para firmar AT y para descifrar las solicitudes de AT.
164)Las EE usarán los certificados de AA para verificar los AT asociados y para el cifrado de solicitudes de AT, tal y como se define en [1].
4.5.1.4.Uso de las claves privadas y de los certificados por la entidad final
165)Las EE usarán la clave privada correspondiente a una EC válida para firmar una nueva solicitud de inscripción, tal y como se define en [1]. La nueva clave privada se usará para construir la firma interna en la solicitud para demostrar la posesión de la clave privada correspondiente a la nueva clave pública de EC.
166)Las EE usarán la clave privada correspondiente a una EC válida para firmar una solicitud de autorización, tal y como se define en [1]. La clave privada correspondiente al nuevo AT se usará para construir la firma interna en la solicitud para demostrar la posesión de la clave privada correspondiente a la nueva clave pública de AT.
167)Las EE usarán la clave privada correspondiente a un AT adecuado para firmar los mensajes de STI-C, tal y como se define en [5].
4.5.2.Uso de las claves privadas y de los certificados por la parte confiante
168)Las partes confiantes usan la cadena de certificación de confianza y las claves públicas asociadas para los fines mencionados en los certificados y para autenticar la identidad común de confianza de las EC y los AT.
169)Las partes confiantes no usarán los certificados de CA raíz, EA y AA, las EC y los AT sin una comprobación preliminar.
4.6.Renovación de certificados
No autorizado.
4.7.Renovación de claves de los certificados
4.7.1.Circunstancias para la renovación de las claves de un certificado
170)La renovación de las claves de un certificado se tramitará cuando este llegue al final de su período de validez o una clave privada alcance el final de su uso operativo, pero la relación de confianza con la CA todavía exista. En todos los casos, se generará un nuevo par de claves y se emitirá el certificado correspondiente.
4.7.2.Quién puede solicitar una renovación de claves
4.7.2.1.CA raíz
171)La CA raíz no solicita renovaciones de claves. El proceso de renovación de claves es interno en el caso de la CA raíz, ya que su certificado es autofirmado. La CA raíz renovará las claves con certificados de enlace o con nuevas emisiones (véase el epígrafe 4.3.1.1).
4.7.2.2.TLM
172)El TLM no solicita renovaciones de claves. El proceso de renovación de claves es interno en el caso del TLM, ya que su certificado es autofirmado.
4.7.2.3.EA y AA
173)La solicitud de certificado de CA subordinada debe presentarse a su debido tiempo para asegurarse de que se dispone de un nuevo certificado de CA subordinada y un par de claves operativas de CA subordinada antes de la expiración de la clave privada vigente de CA subordinada. Con respecto a la fecha de presentación también debe tenerse en cuenta el tiempo necesario para la aprobación.
4.7.2.4.Estación STI-C
No aplicable.
4.7.3.Proceso de renovación de claves
4.7.3.1.Certificado de TLM
174)El TLM decide renovar las claves sobre la base de los requisitos de los epígrafes 6.1 y 7.2. El proceso detallado se establece en su CPS.
175)El TLM ejecutará el proceso de renovación de claves a su debido tiempo para permitir la distribución de los nuevos certificados de TLM y de enlace a todos los participantes antes de que expire el certificado de TLM en vigor.
176)El TLM usará los certificados de enlace para renovar las claves y para garantizar la relación de confianza del nuevo certificado autofirmado. El nuevo certificado de TLM y de enlace recién creado se transfiere al CPOC.
4.7.3.2.Certificado de CA raíz
177)La CA raíz decide renovar las claves sobre la base de los requisitos de los epígrafes 6.1.5 y 7.2. El proceso detallado debería establecerse en su CPS.
178)La CA raíz ejecutará el proceso de renovación de claves a su debido tiempo (antes de que expire el certificado de CA raíz) para permitir la inserción del nuevo certificado en la ECTL antes de que el certificado de CA raíz adquiera validez (véase el epígrafe 5.6.2). El proceso de cambio de claves se llevará a cabo mediante certificados de enlace o como una solicitud inicial.
4.7.3.3.Certificados de EA y AA
179)La EA o AA solicitará un nuevo certificado como sigue:
|
Etapa
|
Indicación
|
Solicitud de renovación de claves
|
|
1
|
Generación del par de claves
|
Las CA subordinadas (EA y AA) generarán nuevos pares de claves de conformidad con el epígrafe 6.1.
|
|
2
|
Generación de solicitudes de certificado y firmas internas
|
La CA subordinada genera una solicitud de certificado a partir de la clave pública recién generada, teniendo en cuenta el sistema de nomenclatura (subject_info) del epígrafe 3, el algoritmo de firma, los Service Specific Permissions (SSP) y el parámetro adicional optativo, y genera la firma interna con la correspondiente clave privada nueva. Si se requiere una clave de cifrado, la CA subordinada también debe demostrar que posee la clave privada de descifrado correspondiente.
|
|
3
|
Generar la firma externa
|
La solicitud completa deberá ser firmada con la clave privada válida vigente para garantizar la autenticidad de la solicitud firmada.
|
|
4
|
Enviar la solicitud a la CA raíz
|
La solicitud firmada se enviará a la CA raíz correspondiente.
|
|
5
|
Verificación de la solicitud
|
La CA raíz correspondiente verificará la integridad y autenticidad de la solicitud. En primer lugar, comprobará la firma externa. Si la verificación es positiva, comprobará la firma interna. Si existe prueba de la posesión de la clave privada de descifrado, también comprobará dicha prueba.
|
|
6
|
Aceptar o rechazar la solicitud
|
Si todas las comprobaciones conducen a un resultado positivo, la CA raíz acepta la solicitud; de lo contrario, la rechaza.
|
|
7
|
Generar y emitir el certificado
|
La CA raíz genera un nuevo certificado y lo distribuye a la CA subordinada solicitante.
|
|
8
|
Enviar respuesta
|
La CA subordinada enviará un mensaje de situación (sobre si se ha recibido o no el certificado) a la CA raíz.
|
Cuadro 3: Proceso de renovación de claves para las EA y AA
180)Durante la renovación automática de claves para las CA subordinadas, la CA raíz se asegurará de que el solicitante está efectivamente en posesión de su clave privada. Los protocolos adecuados para la prueba de la posesión de claves privadas de descifrado se aplicará, por ejemplo, como se define en los documentos RFC 4210 y 4211. Para las claves de firma privadas, debería usarse la firma interna.
4.7.3.4.Certificados de estación STI-C
No se aplica a los AT.
4.8.Modificación de certificados
No autorizado.
4.9.Revocación y suspensión de certificados
Véase el epígrafe 7.
4.10.Servicios de situación de certificados
4.10.1.Características operativas
No aplicable.
4.10.2.Disponibilidad del servicio
No aplicable.
4.10.3.Características opcionales
No aplicable.
4.11.Fin de la suscripción
No aplicable.
4.12.Custodia y recuperación de claves
4.12.1.Suscriptor
4.12.1.1.Qué par de claves puede custodiarse
No aplicable.
4.12.1.2.Quién puede presentar una solicitud de recuperación
No aplicable.
4.12.1.3.Proceso y responsabilidades de recuperación
No aplicable.
4.12.1.4.Identificación y autenticación
No aplicable.
4.12.1.5.Aprobación o denegación de las solicitudes de recuperación
No aplicable.
4.12.1.6.Acciones KEA y KRA durante la recuperación del par de claves
No aplicable.
4.12.1.7.Disponibilidad de KEA y KRA
No aplicable.
4.12.2.Política y prácticas de encapsulación y recuperación de claves de sesión
No aplicable.
5.Controles operativos, de instalaciones y de gestión
181)La PKI se compone de la CA raíz, la EA/AA, el CPOC y el TLM, incluidos su componentes TIC (por ejemplo, redes y servidores).
182)En el presente epígrafe, la entidad responsable de un elemento de la PKI se identifica por el propio elemento. En otras palabras, la frase «la CA es responsable de realizar la auditoría» es equivalente a «la entidad o personal que gestiona la CA es responsable de realizar...».
183)La expresión «elementos del modelo de confianza STI-C» incluye la CA raíz, el TLM, la EA/AA, el CPOC y la red de seguridad.
5.1.Controles físicos
184)Todas las operaciones del modelo de confianza STI-C se llevarán a cabo en un entorno protegido físicamente que evite y detecte el uso y divulgación no autorizados de información y sistemas sensibles, así como el acceso a ellos, y que disuada de tal uso y divulgación. Los elementos del modelo de confianza STI-C usarán controles físicos de seguridad en cumplimiento de las normas ISO 27001 e ISO 27005.
185)Las entidades que gestionen los elementos del modelo de confianza STI-C describirán los controles físicos, de procedimiento y de personal en sus CPS. En particular, las CPS contendrán información sobre la ubicación y construcción de los edificios y sus controles físicos de seguridad que garanticen un acceso controlado a todas las salas usadas en las instalaciones de las entidades del modelo de confianza STI-C.
5.1.1.Ubicación física y construcción
5.1.1.1.CA raíz, CPOC y TLM
186)La ubicación y la construcción de las instalaciones utilizadas para alojar el equipo y los datos (HSM, datos de activación, copia de seguridad del par de claves, ordenadores, registro, script de la ceremonia de claves, solicitud de certificados, etc.) de la CA raíz, el CPOC y el TLM serán acordes a las instalaciones utilizadas para alojar información sensible y de alto valor. Las operaciones de la CA raíz tendrán lugar en una zona física específica separada de las zonas físicas de otros componentes de la PKI.
187)La CA raíz, el CPOC y el TLM aplicarán políticas y procedimientos que garanticen el mantenimiento de un alto nivel de seguridad en el entorno físico en el que esté instalado el equipo de la CA raíz, a fin de garantizar que:
esté aislado de las redes ajenas al modelo de confianza;
esté dividido en una serie de (al menos dos) perímetros físicos con seguridad progresiva;
los datos sensibles (HSM, copia de seguridad de pares de claves, datos de activación, etc.) se almacenen en una caja fuerte específica ubicada en una zona física específica sujeta a un control de acceso múltiple.
188)Las técnicas de seguridad empleadas se diseñarán para resistir un gran número y una combinación de diferentes formas de ataques. Los mecanismos utilizados incluirán, como mínimo:
alarmas de perímetro, televisión en circuito cerrado, muros reforzados y detectores de movimiento;
autenticación de doble factor (por ejemplo, tarjeta inteligente y PIN) para cada persona, y acreditación para entrar y salir de las instalaciones de la CA raíz y de la zona física segura.
189)La CA raíz, el CPOC y el TLM utilizan personal autorizado para supervisar continuamente los equipos de alojamiento de las instalaciones las veinticuatro horas, todos los días del año. El entorno operativo (por ejemplo, las instalaciones físicas) nunca se dejará sin vigilancia. El personal del entorno operativo nunca tendrá acceso a las zonas seguras de las CA raíz y de las CA subordinadas a no ser que esté autorizado.
5.1.1.2.EA/AA
190)Se aplican las mismas disposiciones del epígrafe 5.1.1.1.
5.1.2.Acceso físico
5.1.2.1.CA raíz, CPOC y TLM
191)El equipo y los datos (HSM, datos de activación, copia de seguridad del par de claves, ordenadores, registro, script de la ceremonia de claves, solicitud de certificados, etc.) estarán siempre protegidos contra el acceso no autorizado. Los mecanismos físicos de seguridad para el equipo, como mínimo:
vigilarán, de forma manual o electrónica, la intrusión no autorizada en todo momento;
garantizarán que no se permita el acceso no autorizado al hardware y a los datos de activación;
garantizarán que todos los soportes extraíbles y papeles que contengan información sensible de texto sin cifrar se almacenen en un depósito seguro;
garantizarán que cualquier persona que entre en una zona segura que no esté autorizada de forma permanente no se quede sin supervisión de un empleado autorizado de las instalaciones de la CA raíz, el CPOC y el TLM;
garantizarán que se mantenga e inspeccione periódicamente un registro de acceso;
proporcionarán al menos dos capas progresivamente más seguras, por ejemplo, en el perímetro, el edificio y la sala operativa;
exigirán dos controles de acceso físico de rol de confianza para el HSM y los datos de activación criptográficos.
192)Se efectuará un control de seguridad de las instalaciones que alojen el equipo si este se deja sin vigilancia. Como mínimo, el control comprobará que:
el equipo se encuentra en un estado adecuado para el modo de funcionamiento actual;
se apaga todo el equipo de los componentes fuera de línea;
todos los contenedores de seguridad (sobres a prueba de manipulaciones, cajas fuertes, etc.) están correctamente protegidos;
los sistemas de seguridad físicos (por ejemplo, cerraduras de puertas, tapas de ventilación y electricidad) funcionan correctamente;
la zona está protegida contra el acceso no autorizado.
193)Los módulos criptográficos extraíbles se desactivarán antes de su almacenamiento. Cuando no se utilicen, estos módulos y los datos de activación utilizados para acceder a ellos o habilitarlos se pondrán en una caja fuerte. Los datos de activación se memorizarán o registrarán y se almacenarán de manera acorde con la seguridad garantizada al módulo criptográfico. No deberán almacenarse junto con el módulo criptográfico, a fin de evitar que solo una persona tenga acceso a la clave privada.
194)Una persona o un grupo de roles de confianza se hará explícitamente responsable de la realización de dichos controles. Cuando un grupo de personas sea responsable, se mantendrá un registro que identifique a la persona que lleve a cabo cada control. Si la instalación no tiene presencia humana continua, la última persona que salga deberá rubricar una hoja de salida que indique la fecha y hora, y que confirme que todos los mecanismos de protección física necesarios están instalados y activados.
5.1.2.2.EA/AA
195)Se aplican las mismas disposiciones del epígrafe 5.1.2.1.
5.1.3.Alimentación eléctrica y aire acondicionado
196)Las instalaciones seguras de los elementos del modelo de confianza STI-C (CA raíz, CPOC, TLM, EA y AA) estarán dotadas de un acceso fiable a la alimentación eléctrica para garantizar el funcionamiento sin fallos o con fallos menores. Se necesitan instalaciones primarias y auxiliares en caso de fallo de la alimentación externa, y un cierre correcto de los equipos del modelo de confianza STI-C en caso de falta de alimentación. Las instalaciones del modelo de confianza STI-C estarán equipadas con sistemas de calefacción/ventilación/aire acondicionado para mantener la temperatura y la humedad relativa de los equipos del modelo de confianza STI-C dentro de los límites operativos. La CPS del elemento del modelo de confianza STI-C describirá detalladamente el plan y los procesos para aplicar dichos requisitos.
5.1.4.Exposición al agua
197)Las instalaciones seguras de los elementos del modelo de confianza STI-C (CA raíz, CPOC, TLM, EA y AA) deberían protegerse de forma que se minimice el impacto de la exposición al agua. Por este motivo, se evitarán las cañerías y las tuberías de desagüe. La CPS del elemento del modelo de confianza STI-C describirá detalladamente el plan y los procesos para aplicar dichos requisitos.
5.1.5.Prevención y protección contra incendios
198)Para evitar daños producidos por las llamas o el humo, las instalaciones seguras de los elementos del modelo de confianza STI-C (CA raíz, CPOC, TLM, EA y AA) se construirán y equiparán en consecuencia, y se aplicarán procedimientos para hacer frente a los riesgos relacionados con el fuego. Los soportes de memoria deberían estar protegidos contra el fuego en contenedores apropiados.
199)Los elementos del modelo de confianza STI-C protegerán los soportes físicos que contengan copias de seguridad de los datos críticos del sistema o cualquier otra información sensible contra los riesgos medioambientales y contra la utilización, el acceso o la divulgación no autorizados. La CPS del elemento del modelo de confianza STI-C describirá detalladamente el plan y los procesos para aplicar dichos requisitos.
5.1.6.Gestión de soportes
200)Los soportes utilizados en los elementos del modelo de confianza STI-C (CA raíz, CPOC, TLM, EA y AA) son tratados de forma segura para protegerlos contra daños, contra el robo y contra el acceso no autorizado. Se aplican procedimientos de gestión de soportes para protegerlos contra la obsolescencia y el deterioro durante el período en el que deben conservarse los registros.
201)Los datos sensibles estarán protegidos contra el acceso derivado de la reutilización de los soportes de memoria (por ejemplo, ficheros suprimidos), que puede hacer que los datos sensibles sean accesibles a usuarios no autorizados.
202)Se mantendrá un inventario de todos los activos de información y se establecerán requisitos para la protección de dichos activos que sean coherentes con el análisis de riesgos. La CPS del elemento del modelo de confianza STI-C describirá detalladamente el plan y los procesos para aplicar dichos requisitos.
5.1.7.Eliminación de residuos
203)Los elementos del modelo de confianza STI-C (CA raíz, CPOC, TLM, EA y AA) aplicarán procedimientos para la eliminación segura e irreversible de residuos (como papeles o soportes) para evitar el uso o la divulgación no autorizados de residuos que contengan información confidencial o privada, o el acceso no autorizado a ellos. Todos los soportes utilizados para el almacenamiento de información sensible, como claves, datos de activación o ficheros, serán destruidos antes de ser eliminados como residuos. La CPS del elemento del modelo de confianza STI-C describirá detalladamente el plan y los procesos para aplicar dichos requisitos.
5.1.8.Copias de seguridad fuera de las instalaciones
5.1.8.1.CA raíz, CPOC y TLM
204)Después de la implantación de la CA raíz, el CPOC y el TLM, y después de cada nueva generación de par de claves, se realizan fuera de las instalaciones copias de seguridad completas de los componentes de la CA raíz, el CPOC y el TLM, que sean suficientes para una recuperación si se produce un fallo en el sistema. Periódicamente se realizan copias de seguridad de la información empresarial y el software esenciales (par de claves y CRL). Se proporcionan instalaciones adecuadas para copias de seguridad a fin de que se pueda recuperar toda la información empresarial y el software esenciales tras una catástrofe o un fallo de los soportes. Los mecanismos de copias de seguridad de los sistemas individuales se someten a pruebas periódicas para garantizar que cumplen los requisitos del plan de continuidad de las actividades. Al menos una copia de seguridad completa se almacena en un lugar fuera de las instalaciones (recuperación en caso de catástrofe). La copia de seguridad se almacena en un emplazamiento con controles físicos y de procedimiento acordes con el sistema operativo PKI.
205)Los datos de la copia de seguridad están sujetos a los mismos requisitos de acceso que los datos operativos, y se cifrarán y almacenarán fuera de las instalaciones. En caso de que se produzca una pérdida completa de datos, la información necesaria para poner de nuevo en funcionamiento la CA raíz, el CPOC y el TLM se recuperará completamente a partir de los datos de la copia de seguridad.
206)Las copias de seguridad del material de la clave privada de la CA raíz, el CPOC y el TLM no se realizarán utilizando mecanismos estándar de copias de seguridad, sino utilizando la función de copia de seguridad del módulo criptográfico.
5.1.8.2.EA/AA
207)Los procesos descritos en el epígrafe 5.1.8.1 se aplican a este epígrafe.
5.2.Controles de procedimiento
En este epígrafe se describen los requisitos relativos a los roles, las funciones y la identificación del personal.
5.2.1.Roles de confianza
208)Se considerará «personas de confianza» a los empleados, contratistas y consultores a los que se hayan asignado roles de confianza. Las personas que deseen convertirse en personas de confianza para obtener de una posición de confianza deberán cumplir los requisitos de control de la presente política de certificación.
209)Las personas de confianza controlan o tienen acceso a las operaciones de autenticación o cifrado que puedan afectar materialmente a:
la validación de la información en las solicitudes de certificados;
la aceptación, el rechazo u otra tramitación de solicitudes de certificados, de revocación o de renovación;
la emisión o revocación de certificados, incluido el personal que tenga acceso a las partes restringidas de su repositorio o al tratamiento de la información o solicitudes del suscriptor.
210)Entre los roles de confianza se encuentran:
servicio al cliente;
administración del sistema;
ingeniería designada;
directivos encargados de la gestión de la fiabilidad de las infraestructuras.
211)La CA proporcionará descripciones claras de todos los roles de confianza en su CPS.
5.2.2.Número de personas necesarias por tarea
212)Los elementos del modelo de confianza STI-C establecerán, mantendrán y harán cumplir procedimientos de control rigurosos para garantizar la separación de funciones según los roles de confianza y para garantizar que sean necesarias varias personas de confianza para llevar a cabo tareas sensibles. Los elementos del modelo de confianza STI-C (TLM, CPOC, CA raíz, EA y AA) deberían cumplir lo estipulado en [4], así como los requisitos de los apartados siguientes.
213)Existen procedimientos de política y de control para garantizar la separación de funciones según las responsabilidades en el puesto de trabajo. Las tareas más sensibles, como el acceso al hardware criptográfico de la CA (HSM) y a su material de claves asociado, así como su gestión, deben requerir la autorización de varias personas de confianza.
214)Estos procedimientos de control interno estarán diseñados de manera que se necesiten al menos dos personas de confianza para tener acceso físico o lógico al dispositivo. Las restricciones de acceso al hardware criptográfico de la CA deben ser aplicadas estrictamente por varias personas de confianza a lo largo de todo su ciclo de vida, desde la recepción y la inspección de entrada hasta la destrucción lógica o física final. Cuando se ha activado un módulo con claves operativas, se invocan más controles de acceso para mantener el control fraccionado sobre el acceso tanto físico como lógico al dispositivo.
5.2.3.Identificación y autenticación para cada rol
215)Todas las personas a las que se ha asignado un rol, tal como se describen en la presente CP, están identificadas y autenticadas a fin de garantizar que el rol les permita desempeñar sus funciones PKI.
216)Los elementos del modelo de confianza STI-C verificarán y confirmarán la identidad y la autorización de todo el personal que desee convertirse en persona de confianza, antes de que:
se expidan sus dispositivos de acceso y se les conceda acceso a las instalaciones necesarias;
hayan recibido las credenciales electrónicas para acceder a funciones específicas en los sistemas de la CA y ejercerlas.
217)La CPS describe los mecanismos utilizados para identificar y autenticar a las personas.
5.2.4.Roles que requieren separación de funciones
218)Entre los roles que requieren separación de funciones se encuentran:
la aceptación, el rechazo y la revocación de solicitudes, y otras tramitaciones de las solicitudes de certificados de CA;
la generación, emisión y destrucción de un certificado de CA.
219)La separación de funciones podrá ejecutarse utilizando equipos o procedimientos de PKI, o ambas cosas. No se asignará más de una identidad a ninguna persona, salvo que la CA raíz lo apruebe.
220)La parte de la CA raíz y de la CA relacionada con la gestión de la generación y la revocación de certificados será independiente de otras organizaciones para sus decisiones relativas al establecimiento, la dotación, el mantenimiento y la suspensión de los servicios, de conformidad con las políticas de certificación aplicables. En particular, sus altos cargos, el personal directivo y el personal que desempeñen roles de confianza estarán libres de toda presión comercial, financiera o de otro tipo que pueda influir negativamente en la confianza en los servicios que presta.
221)Las EA y las AA que presten servicio a las estaciones STI-C móviles serán entidades operativas aparte, con infraestructuras y equipos de gestión de TI independientes. De conformidad con el RGPG, la EA y la AA no intercambiarán datos personales, excepto en lo que se refiere a la autorización de las solicitudes de AT. Transferirán los datos relativos a la aprobación de las solicitudes de AT utilizando únicamente el protocolo de validación de la autorización que figura en [1] por medio de una interfaz segura específica. Pueden utilizarse otros protocolos, siempre que se aplique [1].
222)Los archivos de registro almacenados por la EA y la AA pueden utilizarse únicamente para la revocación de las EC indebidas basadas en AT de los CAM/DENM maliciosos interceptados. Tras la identificación de un CAM/DENM como malicioso, la AA examinará la clave de verificación del AT en sus registros de emisión y enviará una solicitud de revocación a la EA que contenga la firma cifrada bajo la clave privada de la EC que se utilizó durante la emisión del AT. Todos los archivos de registro deberán estar adecuadamente protegidos contra el acceso de partes no autorizadas y no podrán compartirse con otras entidades o autoridades.
Nota: En el momento de la redacción de la presente versión de la CP, no se ha definido el diseño de la función de comportamiento inadecuado. Se ha previsto la posibilidad de diseñar dicha función en futuras revisiones de la política.
5.3.Controles de personal
5.3.1.Requisitos relativos a las cualificaciones, la experiencia y la autorización
223)Los elementos del modelo de confianza STI-C emplean a un número suficiente de personal con los conocimientos especializados, la experiencia y las cualificaciones necesarias para desempeñar las funciones profesionales y los servicios que ofrecen. El personal de la PKI cumple estos requisitos mediante formación y titulaciones formales, experiencia real o una combinación de ambas. Los roles y las responsabilidades de confianza, como se describen en la CPS, están documentados en las descripciones de los puestos de trabajo y están claramente identificados. Los subcontratistas de personal PKI tienen descripciones de los puestos de trabajo definidas para garantizar la separación de funciones y privilegios, y la sensibilidad de la posición se determina sobre la base de las funciones y los niveles de acceso, el control de antecedentes personales y la formación y sensibilización de los empleados.
5.3.2.Procedimientos de comprobación de antecedentes
224)Los elementos del modelo de confianza STI-C llevarán a cabo comprobaciones de antecedentes de los miembros del personal que deseen convertirse en personas de confianza. Al menos cada cinco años, se repetirán las comprobaciones de antecedentes del personal que posea posiciones de confianza.
225)Los factores revelados en una comprobación de antecedentes que pueden considerarse motivos para rechazar a los candidatos a una posición de confianza o para tomar medidas contra una persona de confianza que ya ocupe el puesto son, entre otros, los siguientes:
declaraciones incorrectas realizadas por el candidato o la persona de confianza;
referencias profesionales muy desfavorables o poco fiables;
determinadas condenas penales;
indicios de falta de responsabilidad económica.
226)Los informes que contengan dicha información serán evaluados por el personal de recursos humanos, que tomará medidas razonables a la luz del tipo, la magnitud y la frecuencia de la conducta descubierta por la comprobación de antecedentes. Esta acción puede incluir medidas que pueden llegar a la supresión de las ofertas de empleo presentadas a los candidatos para puestos de confianza o a la rescisión del contrato de las personas de confianza que ya ocupen el puesto. El uso de la información revelada en una comprobación de antecedentes como base para tal acción estará sujeto a la legislación aplicable.
227)La investigación de antecedentes de las personas que desean convertirse en personas de confianza incluye, entre otras cosas:
confirmación de empleos anteriores;
una comprobación de las referencias profesionales relativas a su empleo durante un período mínimo de cinco años;
confirmación del título educativo más elevado o más pertinente obtenido;
una comprobación de antecedentes penales.
5.3.3.Requerimientos de formación
228)Los elementos del modelo de confianza STI-C proporcionarán a su personal la formación necesaria para cumplir sus responsabilidades en relación con las operaciones de la CA de manera competente y satisfactoria.
229)Los programas de formación se revisarán periódicamente y su formación abordará cuestiones que sean pertinentes para las funciones desempeñadas por su personal.
230)Los programas de formación abordarán cuestiones que sean pertinentes para el entorno particular de la persona en formación, en particular:
los principios y mecanismos de seguridad de los elementos del modelo de confianza STI-C;
las versiones de hardware y software en uso;
todas las funciones que se espera que realice la persona, así como los procesos y secuencias internos y externos de presentación de informes;
los procesos operativos y flujos de trabajo de la PKI;
la notificación y gestión de incidentes y comprometimientos;
los procedimientos de recuperación y de continuidad de las actividades en caso de catástrofe;
conocimientos suficientes en materia de TI.
5.3.4.Requerimientos y frecuencia de actualización de la formación
231)Las personas asignadas a roles de confianza tienen la obligación de actualizar de forma continua los conocimientos adquiridos en la formación utilizando un entorno de formación. La formación deberá repetirse siempre que se considere necesario y, como mínimo, cada dos años.
232)Los elementos del modelo de confianza STI-C proporcionarán a su personal formaciones complementarias y actualizaciones en la medida y con la frecuencia necesarias para garantizar que mantengan el nivel requerido de competencia para cumplir sus responsabilidades laborales de forma competente y satisfactoria.
233)Las personas que ocupen roles de confianza serán conscientes de los cambios en las operaciones PKI, según proceda. Todo cambio significativo de las operaciones deberá ir acompañado de un plan de formación (de sensibilización), cuya ejecución se documentará.
5.3.5.Frecuencia y secuencia de rotación de tareas
234)No estipulado, siempre que se garanticen las capacidades técnicas, la experiencia y los derechos de acceso. Los administradores de los elementos del modelo de confianza STI-C garantizarán que los cambios de personal no afecten a la seguridad del sistema.
5.3.6.Sanciones por actuaciones no autorizadas
235)Cada elemento del modelo de confianza STI-C debe elaborar un proceso disciplinario formal para garantizar que las acciones no autorizadas sean debidamente sancionadas. En los casos graves, deben retirarse las asignaciones del rol y los privilegios correspondientes.
5.3.7.Requisitos para los contratistas independientes
236)Los elementos del modelo de confianza STI-C pueden permitir que contratistas o consultores independientes se conviertan en personas de confianza solo en la medida necesaria para establecer relaciones de externalización claramente definidas, y a condición de que la entidad confíe en los contratistas o consultores en la misma medida que si fueran empleados y de que estos cumplan los requisitos aplicables a los empleados.
237)De no ser así, los contratistas y consultores independientes tendrán acceso a las instalaciones seguras de la PKI del C-ITS solo si están acompañados y directamente supervisados por personas de confianza.
5.3.8.Documentación proporcionada al personal
238)Los elementos del modelo de confianza STI-C proporcionarán a su personal la formación y el acceso a la documentación que necesitan para cumplir sus responsabilidades laborales de forma competente y satisfactoria.
5.4.Procedimientos de registro de auditoría
239)En el presente epígrafe se establecen los requisitos en relación con los tipos de eventos que deben registrarse y la gestión de los registros de auditoría.
5.4.1.Tipos de eventos que cada CA debe registrar y notificar
240)Un representante de la CA revisará periódicamente los registros, eventos y procedimientos de dicha CA.
241)Los elementos del modelo de confianza STI-C registrarán los siguientes tipos de eventos de auditoría (si procede):
acceso a las instalaciones físicas: se registrará el acceso de las personas físicas a las instalaciones mediante el almacenamiento de las solicitudes de acceso a través de tarjetas inteligentes; se creará un evento cada vez que se genere un registro;
gestión de los roles de confianza: se registrará cualquier cambio en la definición y el nivel de acceso de los diferentes roles, incluida la modificación de los atributos de los roles. se creará un evento cada vez que se genere un registro;
acceso lógico: se generará un evento cuando una entidad (por ejemplo, un programa) tenga acceso a zonas sensibles (es decir, redes y servidores);
gestión de las copias de seguridad: se crea un evento cada vez que se completa una copia de seguridad, tanto de forma satisfactoria como fallida;
gestión de los registros: se almacenarán los registros; se crea un evento cuando el tamaño del registro supera un tamaño determinado;
datos del proceso de autenticación para suscriptores y elementos del modelo de confianza STI-C: se generarán eventos para cada solicitud de autenticación por parte de los suscriptores y de los elementos del modelo de confianza STI-C;
aceptación y denegación de las solicitudes de certificado, incluida la creación y renovación de certificados: se generará periódicamente un evento con una lista de solicitudes de certificado aceptadas y denegadas en los últimos siete días;
registro de fabricantes: se creará un evento cuando se registre un fabricante;
registro de estaciones STI-C: se creará un evento cuando se registre una estación STI-C;
gestión de HSM: se creará un evento cuando se registre una violación de seguridad HSM;
gestión de la informática y de la red, en la medida en que estén relacionada con los sistemas PKI: se creará un evento cuando un servidor PKI se apague o se reinicie;
gestión de la seguridad (intentos de acceso al sistema PKI logrados y fallidos, acciones ejecutadas de PKI y del sistema de seguridad, cambios en los perfiles de seguridad, caídas del sistema, fallos y otras anomalías de hardware, actividades de cortafuegos y encaminador; y entradas y salidas de las instalaciones PKI);
los datos relacionados con los eventos se conservarán durante al menos cinco años, a menos que sean de aplicación normas nacionales adicionales.
242)De conformidad con el RGDP, los registros de auditoría no permitirán el acceso a los datos relacionados con la privacidad relativos a los vehículos privados de la estación STI-C.
243)En la medida de lo posible, los registros de auditoría de seguridad se compilarán de manera automática. Cuando esto no sea posible, se utilizará un cuaderno de registro, un formulario en papel u otro mecanismo físico. Se conservarán todos los registros de auditoría de seguridad, tanto electrónicos como no electrónicos, y se pondrán a disposición durante las auditorías de conformidad.
244)Cada evento relacionado con el ciclo de vida del certificado se registra de manera que pueda atribuirse a la persona que lo ha realizado. Todos los datos relativos a las identidades personales se cifran y protegen contra el acceso no autorizado.
245)Como mínimo, cada historial de auditoría incluye la siguiente información (registrada automática o manualmente para cada evento objeto de auditoría):
tipo de evento (según la lista anterior);
fecha y hora de confianza en que se produjo el evento;
resultado del evento: logrado o fallido, según corresponda;
identidad de la entidad u operador que causó el evento, si procede;
identidad de la entidad a la que se dirige el evento.
5.4.2.Frecuencia de tratamiento de los registros
246)Los registros de auditoría se analizarán en respuesta a las alertas basadas en irregularidades e incidentes dentro de los sistemas de la CA y, además, periódicamente cada año.
247)El tratamiento de los registros de auditoría consistirá en analizarlos y en documentar el motivo de todos los eventos significativos en un resumen del registro de auditoría. Los análisis del registro de auditoría incluirán una verificación de que el registro no ha sido manipulado, una inspección de todas las entradas del registro y una investigación de cualquier alerta o irregularidad en los registros. Se documentarán las medidas adoptadas sobre la base de los análisis de los registros de auditoría.
248)El registro de auditoría se archiva al menos una vez por semana. Un administrador lo almacenará manualmente si el espacio de disco libre para el registro de auditoría está por debajo de la cantidad prevista de datos del registro de auditoría producidos esa semana.
5.4.3.Período de conservación de los registros de auditoría
249)Los registros relativos a los ciclos de vida de los certificados se conservan durante al menos cinco años a partir de la fecha de expiración del certificado correspondiente.
5.4.4.Protección de los registros de auditoría
250)La integridad y la confidencialidad del registro de auditoría están garantizadas por un mecanismo de control del acceso basado en roles. Los registros internos de auditoría solo pueden ser consultados por los administradores; los usuarios que cuenten con la autorización adecuada también pueden acceder a los registros de auditoría relacionados con el ciclo de vida de los certificados, a través de una página web y con el identificador de usuario. El acceso debe concederse con autenticación multiusuario (al menos dos usuarios) y de al menos dos niveles. Debe garantizarse técnicamente que los usuarios no puedan acceder a sus propios ficheros de registro.
251)Cada anotación en el registro se firmará utilizando el material de claves procedente del HSM.
252)Los registros de eventos que contienen información que puede conducir a la identificación personal, como un vehículo privado, están cifrados de forma que solo las personas autorizadas pueden leerlos.
253)Los eventos están registrados de tal manera que no se pueden borrar o destruir fácilmente (salvo en caso de transferencia a soportes a largo plazo) dentro del período durante el cual los registros deben conservarse.
254)Los registros de eventos están protegidos de tal manera que siguen siendo legibles mientras dura su período de almacenamiento.
5.4.5.Procedimientos de respaldo de los registros de auditoría
255)Las copias de seguridad de los registros y de los resúmenes de auditoría se efectúan a través de mecanismos de copia de seguridad de empresa, bajo el control de roles de confianza autorizados, por separado del componente que los haya generado. Las copias de seguridad de los registros de auditoría están protegidas con el mismo nivel de confianza que se aplica a los registros originales.
5.4.6.Sistema de recogida de información de auditoría (interno o externo)
256)El equipo de los elementos del modelo de confianza STI-C activará los procesos de auditoría cuando se inicie el sistema y los desactivará únicamente cuando se apague el sistema. Si los procesos de auditoría no están disponibles, el elemento del modelo de confianza STI-C suspenderá su funcionamiento.
257)Al final de cada período de operación y en la renovación de claves de los certificados, la situación colectiva de los equipos debería comunicarse al gestor de operaciones y al órgano de gobierno de las operaciones del elemento respectivo de la PKI.
5.4.7.Notificación al sujeto causa del evento
258)Cuando el sistema de recogida de información de auditoría registra un evento, garantiza que este esté vinculado a un rol de confianza.
5.4.8.Análisis de vulnerabilidades
259)El rol encargado de realizar la auditoría y los roles encargados de la operación del sistema PKI en los elementos del modelo de confianza STI-C explican todos los eventos significativos en un resumen del registro de auditoría. En estos análisis se verifica que el registro no haya sido manipulado y que no exista discontinuidad u otra pérdida de datos de auditoría y, a continuación, se inspeccionan brevemente todas las entradas de los registros, con una investigación más exhaustiva de las eventuales alertas o irregularidades en los registros. Las medidas adoptadas como resultado de estos análisis se documentan.
260)Los elementos del modelo de confianza STI-C:
aplicarán controles organizativos o técnicos de detección y prevención bajo el control de los elementos del modelo de confianza STI-C, a fin de proteger los sistemas PKI contra virus y softwares maliciosos;
documentarán y seguirán un proceso de corrección de las vulnerabilidades que aborde la identificación, el análisis, la respuesta y la resolución de las vulnerabilidades;
llevarán a cabo un escaneo de vulnerabilidades o se someterán a él:
después de cualquier cambio en el sistema o en la red que los elementos del modelo de confianza STI-C consideren significativo para los componentes PKI; y
al menos una vez al mes, en las direcciones IP públicas y privadas identificadas por la CA y el CPOC como sistemas de la PKI;
se someterán a una prueba de penetración en los sistemas de la PKI, como mínimo una vez al año y después de las mejoras o modificaciones de la infraestructura o de la aplicación que los elementos del modelo de confianza STI-C consideren significativas para el componente de la PKI de la CA;
en el caso de los sistemas en línea, registrarán evidencias de que cada escaneo de vulnerabilidades y cada prueba de penetración han sido realizados por una persona o entidad (o un grupo colectivo de ellas) con las capacidades, las herramientas, la competencia, el código ético y la independencia necesarios para realizar escaneos de vulnerabilidades o pruebas de penetración fiables;
buscarán y solucionarán las vulnerabilidades, en consonancia con las políticas de ciberseguridad y la metodología de reducción del riesgo de la empresa.
5.5.Archivo de registros
5.5.1.Tipos de registros archivados
261)Los elementos del modelo de confianza STI-C conservarán registros lo suficientemente detallados como para establecer la validez de una firma y el funcionamiento adecuado de la PKI. Como mínimo, se archivarán los siguientes registros de eventos PKI (si procede):
registro de acceso a las instalaciones físicas de los elementos del modelo de confianza STI-C (un año como mínimo);
registro de la gestión de los roles de confianza de los elementos del modelo de confianza STI-C (diez años como mínimo);
registro de acceso TI de los elementos del modelo de confianza STI-C (cinco años como mínimo);
registro de creación, uso y destrucción de claves de CA (cinco años como mínimo) (no aplicable al TLM y el CPOC);
registro de creación, uso y destrucción de certificados (dos años como mínimo);
registro de solicitudes de CPA (dos años como mínimo);
registro de la gestión de los datos de activación de los elementos del modelo de confianza STI-C (cinco años como mínimo);
registro de TI y de red de los elementos del modelo de confianza STI-C (cinco años como mínimo);
documentación PKI de los elementos del modelo de confianza STI-C (cinco años como mínimo);
informe de los incidentes de seguridad e informe de auditoría de los elementos del modelo de confianza STI-C (diez años como mínimo);
equipo, software y configuración del sistema (cinco años como mínimo).
262)Los elementos del modelo de confianza STI-C conservarán la siguiente documentación relativa a las solicitudes de certificado y su verificación, y todos los certificados de TLM, CA raíz y CA, junto con su CRL, durante al menos siete años después de que todo certificado basado en dicha documentación deje de ser válido:
documentación de la auditoría de la PKI conservada por los elementos del modelo de confianza STI-C;
documentación de la CPS conservada por los elementos del modelo de confianza STI-C;
contrato entre la CPA y otras entidades conservado por los elementos del modelo de confianza STI-C;
certificados (u otra información sobre revocaciones) conservados por la CA y el TLM;
registros de solicitudes de certificados en el sistema de la CA raíz (no aplicable al TLM);
otros datos o aplicaciones que permitan verificar el contenido de los archivos;
todo el trabajo relacionado con los elementos del modelo de confianza STI-C y los auditores de conformidad, o procedente de ellos.
263)La entidad CA conservará toda la documentación relativa a las solicitudes de certificado y su verificación, y todos sus certificados y su revocación, durante al menos siete años después de que todo certificado basado en dicha documentación deje de ser válido.
5.5.2.Período de conservación del archivo
264)Sin perjuicio de los reglamentos que requieran un período de archivo más largo, los elementos del modelo de confianza STI-C conservarán todos los registros durante al menos cinco años tras la expiración del certificado correspondiente.
5.5.3.Protección del archivo
265)Los elementos del modelo de confianza STI-C almacenarán el archivo de los registros en una instalación de almacenamiento segura, protegida y separada de los equipos de la CA, con controles de seguridad físicos y de procedimiento equivalentes a los de la PKI o mejores.
266)El archivo se protegerá contra la consulta, modificación, supresión u otra manipulación no autorizada mediante el almacenamiento en un sistema fiable.
267)Los soportes que contengan los datos del archivo y las aplicaciones necesarias para su tratamiento se mantendrán de manera que pueda accederse a ellos durante el período establecido en la presente CP.
5.5.4.Archivo y almacenamiento del sistema
268)Los elementos del modelo de confianza STI-C realizarán copias de seguridad acumulativas de los archivos del sistema de esta información diariamente, y copias de seguridad completas semanalmente. Las copias de los registros en papel se conservarán en un lugar seguro fuera de las instalaciones.
5.5.5.Requisitos relativos al sellado de tiempo de los registros
269)Los elementos del modelo de confianza STI-C que gestionen una base de datos de revocaciones garantizarán que los registros contengan información sobre la fecha y la hora en que se crean los registros de revocación. La integridad de dicha información se conseguirá con soluciones criptográficas.
5.5.6.Sistema de compilación de archivos (interno o externo)
270)El sistema de compilación de archivos es interno.
5.5.7.Procedimientos para obtener y verificar la información de los archivos
271)Todos los elementos del modelo de confianza STI-C permitirán solamente a las personas de confianza autorizadas acceder al archivo. Las CA y las CA raíz describirán en la CPS los procedimientos para crear, verificar, empaquetar, transmitir y almacenar la información de los archivos.
272)Los equipos de la CA raíz y la CA verificarán la integridad de la información antes de que se restituya.
5.6.Cambio de claves de los elementos del modelo de confianza STI-C
273)Los siguientes elementos del modelo de confianza STI-C tienen requisitos específicos para su cambio de claves: certificados de TLM, CA raíz y EA/AA
5.6.1.TLM
274)El TLM suprimirá su clave privada al expirar el correspondiente certificado. Generará un nuevo par de claves y el correspondiente certificado de TLM antes de la desactivación de la clave privada válida vigente. Velará por que el nuevo certificado (de enlace) se incluya en la ECTL a tiempo para ser distribuido a todas las estaciones STI-C antes de que adquiera validez. El certificado de enlace y el nuevo certificado autofirmado se transfieren al CPOC.
5.6.2.CA raíz
275)La CA raíz desactivará y suprimirá la clave privada vigente (incluidas las claves de copia de seguridad), de modo que no emitirá certificados de EA/AA con una validez que se extienda más allá de la validez del certificado de CA raíz.
276)La CA raíz generará un nuevo par de claves y un certificado correspondiente de CA raíz y de enlace antes de la desactivación de la clave privada vigente (incluidas las claves de copia de seguridad) y los remitirá al TLM para su introducción en la ECTL. El período de validez del nuevo certificado de CA raíz comenzará a partir de la desactivación prevista de la clave privada vigente. La CA raíz velará por que el nuevo certificado se incluya en la ECTL a tiempo para ser distribuido a todas las estaciones STI-C antes de que adquiera validez.
277)La CA raíz activará la nueva clave privada cuando el correspondiente certificado de CA raíz adquiera validez.
5.6.3.Certificado de EA/AA
278)La EA/AA desactivará la clave privada vigente, de modo que no emita EC/AT con una validez que se extienda más allá de la validez del certificado de EA/AA.
279)La EA/AA generará un nuevo par de claves y solicitará el correspondiente certificado EA/AA antes de la desactivación de la clave privada vigente. El período de validez del nuevo certificado EA/AA comenzará a partir de la desactivación prevista de la clave privada vigente. La EA/AA velará por que el nuevo certificado pueda publicarse a tiempo para ser distribuido a todas las estaciones STI-C antes de que adquiera validez.
280)La EA/AA activará la nueva clave privada cuando el correspondiente certificado de EA/AA adquiera validez.
5.6.4.Auditor
Ninguna disposición.
5.7.Recuperación en caso de comprometimiento y catástrofe
5.7.1.Tratamiento de incidentes y comprometimientos
281)Los elementos del modelo de confianza STI-C supervisarán sus equipos de manera continua, a fin de detectar posibles intentos de piratería u otras formas de comprometimiento. Si estos se producen, investigarán para determinar la naturaleza y el grado del daño.
282)Si el personal responsable de la gestión de la CA raíz o el TLM detecta un posible intento de piratería u otra forma de comprometimiento, investigará para determinar la naturaleza y el grado del daño. Si se produce un comprometimiento de la clave privada, se revocará el certificado de CA raíz. Los expertos en seguridad de las TI de la CPA evaluarán el alcance de los posibles daños para determinar si la PKI debe ser reconstruida, si solo deben revocarse algunos certificados o si la PKI se ha visto comprometida. Además, la CPA determina qué servicios deben mantenerse (información de revocación y de situación de certificados) y cómo, de conformidad con el plan de continuidad de las actividades de la CPA.
283)Los incidentes, los comprometimientos y la continuidad de las actividades están recogidos en la CPS, que también pueden basarse en otros recursos y planes empresariales para su implementación.
284)Si el personal responsable de la gestión de la EA / la AA / el CPOC detecta un posible intento de piratería u otra forma de comprometimiento, investigará para determinar la naturaleza y el grado del daño. El personal responsable de la gestión de la entidad CA o CPOC evaluará el alcance de los posibles daños para determinar si el componente de la PKI debe ser reconstruido, si solo deben revocarse algunos certificados o si el componente de la PKI se ha visto comprometido. Además, la entidad CA subordinada determina qué servicios deben mantenerse y cómo, de acuerdo con el plan de continuidad de las actividades de la entidad CA subordinada. En caso de que se comprometa un componente de la PKI, la entidad CA alertará a su propia CA raíz y al TLM a través del CPOC.
285)Los incidentes, comprometimientos y continuidad de las actividades están recogidos en la CPS de la CA raíz o del TLM, o en otros documentos pertinentes en el caso de la CPOC, que también puede basarse en otros recursos y planes empresariales para su implementación.
286)La CA raíz y la CA alertarán, con información precisa sobre las consecuencias del incidente, a cada representante de los Estados miembros y cada CA raíz con los que tengan un acuerdo en el contexto de los STI-C, a fin de que puedan activar su propio plan de gestión de incidentes.
5.7.2.Corrupción de recursos informáticos, software o datos
287)Si se descubre una catástrofe que impida el correcto funcionamiento de un elemento del modelo de confianza STI-C, dicho elemento suspenderá su funcionamiento e investigará si la clave privada se ha visto comprometida (excepto el CPOC). El hardware defectuoso se sustituirá lo antes posible y se aplicarán los procedimientos descritos en los epígrafes 5.7.3 y 5.7.4.
288)La corrupción de recursos informáticos, software o datos se comunicará a la CA raíz en un plazo de veinticuatro horas cuando se trate de los niveles más elevados de riesgo. Todos los demás eventos deben incluirse en el informe periódico de la CA raíz, las EA y las AA.
5.7.3.Procedimientos en caso de comprometimiento de claves privadas de entidades
289)Si la clave privada de una CA raíz se ve comprometida, se pierde, se destruye o se sospecha que está comprometida, la CA raíz:
suspenderá su funcionamiento;
iniciará el plan de recuperación y de migración en caso de catástrofe;
revocará su certificado de CA raíz;
investigará el «problema clave» que generó el comprometimiento y lo notificará a la CPA, que revocará el certificado de CA raíz a través del TLM (véase el epígrafe7);
alertará a todos los suscriptores con los que tenga un acuerdo.
290)Si la clave de una EA/AA se ve comprometida, se pierde, se destruye o se sospecha que está comprometida, la EA/AA:
suspenderá su funcionamiento;
revocará su propio certificado;
investigará el «problema clave» e informará a la CA raíz;
alertará a los suscriptores con los que exista un acuerdo.
291)Si la clave EC o AT de una estación STI-C se ve comprometida, se pierde, se destruye o se sospecha que está comprometida, la EA/AA a la que está suscrita dicha estación:
revocará la EC del STI afectado;
investigará el «problema clave» e informará a la CA raíz;
alertará a los suscriptores con los que tenga un acuerdo.
292)En caso de que alguno de los algoritmos o parámetros asociados utilizados por la CA raíz o la CA o las estaciones STI-C resulte insuficiente para su uso restante previsto, la CPA (con una recomendación de expertos en criptografía) informará a la entidad CA raíz con la que tenga un acuerdo y modificará los algoritmos utilizados. (Para más detalles, véanse el epígrafe 6 y las CPS de la CA raíz y la CA subordinada).
5.7.4.Capacidad de continuidad de las actividades después de una catástrofe
293)Los elementos del modelo de confianza STI-C que utilicen instalaciones seguras para las operaciones de la CA deberán desarrollar, probar, mantener y aplicar un plan de recuperación en caso de catástrofe diseñado para mitigar los efectos de cualquier catástrofe natural o antropogénica. Dichos planes abordarán el restablecimiento de los servicios de los sistemas de información y las principales funciones empresariales.
294)Tras un incidente de cierto nivel de riesgo, la CA comprometida debe volver a ser auditada por un auditor de la PKI acreditado (véase el epígrafe 8).
295)Cuando la CA comprometida no pueda seguir funcionando (por ejemplo, a raíz de un incidente grave), debe elaborarse un plan de migración para la transferencia de sus funciones a otra CA raíz. Como mínimo la CA raíz de la UE estará disponible para apoyar el plan de migración. La CA comprometida cesará sus funciones.
296)Las CA raíz incluirán en la CPS el plan de recuperación en caso de catástrofe y el plan de migración.
5.8.Cese y transferencia
5.8.1.TLM
297)El TLM no cesará su actividad, pero una entidad que gestione el TLM podrá hacerse cargo de otra entidad.
298)En caso de cambio de la entidad gestora:
esta solicitará a la CPA la aprobación de un cambio en la gestión del TLM de la antigua entidad a la nueva entidad;
la CPA aprobará el cambio de gestión del TLM;
todos los registros de auditoría y registros archivados se transferirán de la antigua entidad de gestión a la nueva entidad.
5.8.2.CA raíz
299)La CA raíz no cesará ni comenzará su funcionamiento sin establecer un plan de migración (expuesto en la CPS correspondiente) que garantice el funcionamiento ininterrumpido para todos los suscriptores.
300)En caso de cese del servicio de la CA raíz, esta:
informará a la CPA;
informará al TLM para que pueda suprimir de la ECTL el certificado de CA raíz;
revocará la CA raíz correspondiente emitiendo una CRL en la que se incluya a sí misma;
avisará a las CA raíz con las que tenga un acuerdo para la renovación de los certificados de EA/AA;
destruirá la clave privada de CA raíz;
comunicará la última información sobre la situación de revocación (CRL firmada por la CA raíz) a la parte confiante, indicando claramente que es la última información sobre revocación;
archivará todos los registros de auditoría y otros registros antes del cese de la PKI;
transferirá los registros archivados a una autoridad apropiada.
301)El TLM suprimirá de la ECTL el certificado correspondiente de la CA raíz.
5.8.3.EA/AA
302)En caso de cese del servicio de EA/AA, la entidad EA/AA lo notifica antes del cese. Las EA y AA no cesarán ni comenzarán su funcionamiento sin establecer un plan de migración (expuesto en la CPS correspondiente) que garantice el funcionamiento ininterrumpido para todos los suscriptores. La EA/AA:
informará a la CA raíz mediante carta certificada;
destruirá la clave privada de CA;
transferirá su base de datos a la entidad designada por la CA raíz;
dejará de emitir certificados;
durante la transferencia de su base de datos y hasta que esta sea plenamente operativa en una nueva entidad, mantendrá la capacidad de autorizar solicitudes de la autoridad responsable de la privacidad;
en caso de que se haya comprometido una CA subordinada, la CA raíz revocará la CA subordinada y emitirá una nueva CRL con una lista de las CA subordinadas revocadas;
archivará los registros de auditoría y otros registros antes del cese de la PKI;
transferirá sus registros archivados a una entidad designada por la CA raíz.
303)En caso de cese de los servicios de la CA, esta será responsable de mantener todos los registros pertinentes relativos a las necesidades de los componentes de la CA y la PKI.
6.Controles técnicos de seguridad
6.1.Generación e instalación de pares de claves
6.1.1.TLM, CA raíz, EA y AA
304)El proceso de generación de pares de claves cumplirá los siguientes requisitos:
cada participante podrá generar sus propios pares de claves con arreglo a lo dispuesto en los epígrafes 6.1.4 y 6.1.5;
el proceso de derivar claves simétricas de cifrado y una clave MAC para las solicitudes de certificados (ECIES) se llevará a cabo según lo dispuesto en [1] y [5];
el proceso de generación de claves utilizará los algoritmos y longitudes de clave que se describen en los epígrafes 6.1.4.1 y 6.1.4.2;
el proceso de generación de claves estará sujeto a los requisitos de un «almacenamiento seguro de claves privadas» (véase el epígrafe 6.1.5);
las CA raíz y sus suscriptores (CA subordinadas) velarán por que la integridad y la autenticidad de sus claves públicas y los parámetros conexos se mantengan durante la distribución a las entidades CA subordinadas registradas.
6.1.2.EE: estación STI-C móvil
305)Cada estación STI-C móvil generará sus propios pares de claves con arreglo a lo dispuesto en los epígrafes 6.1.4 y 6.1.5.
306)El proceso de derivar claves simétricas de cifrado y una clave MAC para las solicitudes de certificados (ECIES) se llevará a cabo de conformidad con [1] y [5].
307)El proceso de generación de claves utilizará los algoritmos y longitudes de clave que se describen en los epígrafes 6.1.4.1 y 6.1.4.2.
308)El proceso de generación de claves estará sujeto a los requisitos de un «almacenamiento seguro de claves privadas» (véase el epígrafe 6.1.5);
6.1.3.EE: estación STI-C fija
309)Cada estación STI-C fija generará su propio par de claves con arreglo a lo dispuesto en los epígrafes 6.1.4 y 6.1.5.
310)El proceso de generación de claves utilizará los algoritmos y longitudes de clave que se describen en los epígrafes 6.1.4.1 y 6.1.4.2.
311)El proceso de generación de claves estará sujeto a los requisitos de un «almacenamiento seguro de claves privadas» (véase el epígrafe 6.1.5);
6.1.4.Requisitos criptográficos
312)Todos los participantes de la PKI deberán cumplir los requisitos criptográficos establecidos en los epígrafes siguientes por lo que se refiere al algoritmo de firma, la longitud de la clave, el generador de números aleatorios y los certificados de enlace.
6.1.4.1.Longitud de los algoritmos y de las claves: algoritmos de firma
313)Todos los participantes de la PKI (TLM, CA raíz, EA, AA y estaciones STI-C) serán capaces de generar pares de claves y utilizar la clave privada para firmar las operaciones con algoritmos seleccionados a más tardar dos años después de la entrada en vigor del presente Reglamento, de conformidad con el cuadro 4.
314)Todos los participantes de la PKI que deban comprobar la integridad de la ECTL, los certificados o los mensajes firmados de conformidad con su rol, como se define en el epígrafe 1.3.6, reconocerán los algoritmos correspondientes enumerados en el cuadro 5 para verificación. En particular, las estaciones STI-C podrán comprobar la integridad de la ECTL.
|
|
TLM
|
CA raíz
|
EA
|
AA
|
Estación STI-C
|
|
ECDSA_nistP256_with_SHA 256
|
-
|
X
|
X
|
X
|
X
|
|
ECDSA_brainpoolP256r1_with_SHA 256
|
-
|
X
|
X
|
X
|
X
|
|
ECDSA_brainpoolP384r1_with_SHA 384
|
X
|
X
|
X
|
-
|
-
|
|
X indica reconocimiento obligatorio
|
Cuadro 4: Generación de pares de claves y uso de la clave privada para operaciones de firma
|
|
TLM
|
CA raíz
|
EA
|
AA
|
Estación STI-C
|
|
ECDSA_nistP256_with_SHA 256
|
X
|
X
|
X
|
X
|
X
|
|
ECDSA_brainpoolP256r1_with_SHA 256
|
X
|
X
|
X
|
X
|
X
|
|
ECDSA_brainpoolP384r1_with_SHA 384
|
X
|
X
|
X
|
X
|
X
|
|
X indica reconocimiento obligatorio
|
Cuadro 5: Resumen de la verificación
315)Si la CPA así lo decide debido a la detección de nuevas deficiencias criptográficas, todas las estaciones STI-C podrán cambiar a uno de los dos algoritmos (ECDSA_nistP256_with_SCS 256 o ECDSA_brainpoolP256_wit_SHA 256) lo antes posible. Los algoritmos que se utilicen se especificarán en la CPS de la CA que emita el certificado de la clave pública correspondiente, de conformidad con la presente CP.
6.1.4.2.Longitud de los algoritmos y de las claves: algoritmos de cifrado para la inscripción y la autorización
316)Todos los participantes de la PKI (EA, AA y estaciones STI-C) podrán usar claves públicas para cifrar solicitudes y respuestas de inscripción y autorización con algoritmos seleccionados a más tardar dos años después de la entrada en vigor del presente Reglamento, de conformidad con el cuadro 6. Los algoritmos que se utilicen se especificarán en la CPS de la CA que emita el certificado de la clave pública correspondiente, de conformidad con la presente CP.
317)Los algoritmos mencionados en el cuadro 6 indican la longitud de la clave y del algoritmo hash, y se aplicarán de conformidad con [5].
|
|
TLM
|
CA raíz
|
EA
|
AA
|
Estación STI-C
|
|
ECIES_nistP256_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
|
ECIES_brainpoolP256r1_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
|
X indica reconocimiento obligatorio
|
Cuadro 6: Uso de claves públicas para el cifrado de solicitudes y respuestas de inscripción y autorización
318)Todos los participantes de la PKI (EA, AA y estaciones STI-C) podrán generar claves públicas y usar la clave privada para descifrar solicitudes y respuestas de inscripción y autorización con algoritmos seleccionados a más tardar dos años después de la entrada en vigor del presente Reglamento, de conformidad con el cuadro 7:
|
|
TLM
|
CA raíz
|
EA
|
AA
|
Estación STI-C
|
|
ECIES_nistP256_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
|
ECIES_brainpoolP256r1_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
|
X indica reconocimiento obligatorio
|
Cuadro 7: Generación de pares de claves y uso de la clave privada para descifrar solicitudes y respuestas de inscripción y autorización
6.1.4.3.Criptoagilidad
319)Los requisitos sobre longitudes de claves y algoritmos deben modificarse a lo largo del tiempo para mantener un nivel adecuado de seguridad. La CPA supervisará la necesidad de tales cambios a la luz de las vulnerabilidades reales y de la criptografía más avanzada. Elaborará, aprobará y publicará una actualización de la presente política de certificación si decide que los algoritmos criptográficos deberían actualizarse. En caso de que una nueva versión de la presente CP señale un cambio de la longitud del algoritmo o de la clave, la CPA adoptará una estrategia de migración que incluya períodos de transición durante los que deberán aceptarse las longitudes anteriores de los logaritmos y claves.
320)A fin de permitir y facilitar la transferencia a nuevas longitudes de algoritmos o de claves, se recomienda que todos los participantes de la PKI instalen hardware o software capaces de cambiar longitudes de claves y algoritmos.
321)Las modificaciones de los certificados raíz y de TLM se aceptarán y ejecutarán con la ayuda de los certificados de enlace (véase el epígrafe 4.6) que se utilizan para cubrir el período de transición entre los antiguos certificados raíz y los nuevos («migración del modelo de confianza»).
6.1.5.Almacenamiento seguro de claves privadas
En este epígrafe se describen los requisitos para el almacenamiento seguro y la generación de pares de claves y números aleatorios para las CA y las entidades finales. Estos requisitos se definen y describen para los módulos criptográficos en los subepígrafes siguientes.
6.1.5.1.Nivel de CA raíz, CA subordinada y TLM
322)Se utilizará un módulo criptográfico para:
generar, utilizar, administrar y almacenar claves privadas;
generar y usar números aleatorios (la evaluación de la función de generación de números aleatorios formará parte de la evaluación y certificación de la seguridad);
crear copias de seguridad de las claves privadas según lo dispuesto en el epígrafe 6.1.6;
suprimir claves privadas.
El módulo criptográfico se certificará con uno de los siguientes perfiles de protección (PP), con nivel de garantía EAL-4 o superior:
PP para HSM:
CEN EN 419 221-2: Protection profiles for TSP cryptographic modules – Part 2:Cryptographic module for CSP signing operations with backup («Perfiles de protección para módulos criptográficos TSP. Parte 2: Módulo criptográfico para las operaciones de firma del CSP con copia de seguridad»);
CEN EN 419 221-4: Protection profiles for TSP cryptographic modules – Part 4: Cryptographic module for CSP signing operations without backup («Perfiles de protección para módulos criptográficos TSP. Parte 4: Módulo criptográfico para las operaciones de firma del CSP sin copia de seguridad»);
CEN EN 419 221-5: Protection profiles for TSP cryptographic modules – Part 5: Cryptographic module for trust services («Perfiles de protección para módulos criptográficos TSP. Parte 5: Módulo criptográfico para servicios de confianza»);
PP para tarjetas inteligentes:
CEN EN 419 211-2: Protection profiles for secure signature creation device – Part 2: Device with key generation («Perfiles de protección para dispositivos seguros de creación de firma. Parte 2: Dispositivo con generación de claves»);
CEN EN 419 211-3: Protection profiles for secure signature creation device — Part 3: Device with key import («Perfiles de protección para dispositivos seguros de creación de firma. Parte 3: Dispositivo con importación de claves»);
El acceso manual al módulo criptográfico requerirá la autenticación de doble factor por parte del administrador. Además, esto requerirá la participación de dos personas autorizadas.
La aplicación de un módulo criptográfico garantizará que las claves no sean accesibles fuera de dicho módulo. El módulo criptográfico incluirá un mecanismo de control del acceso para evitar el uso no autorizado de claves privadas.
6.1.5.2.Entidad final
323)Se utilizará un módulo criptográfico para las EE a fin de:
generar, utilizar, administrar y almacenar claves privadas;
generar y usar números aleatorios (la evaluación de la función de generación de números aleatorios formará parte de la evaluación y certificación de la seguridad);
suprimir claves privadas de forma segura.
324)El módulo criptográfico se protegerá contra la retirada, sustitución y modificación no autorizadas. Todos los PP y documentos conexos aplicables a la certificación de seguridad del módulo criptográfico serán evaluados, validados y certificados conforme a la norma ISO 15408, aplicando el Acuerdo sobre el reconocimiento mutuo de certificados de evaluación de la seguridad de las tecnologías de la información del Grupo de Altos Funcionarios sobre Seguridad de los Sistemas de Información (SOG-IS), o un régimen europeo equivalente de certificación de la ciberseguridad en el marco europeo de ciberseguridad pertinente.
325)Dada la importancia de mantener el nivel de seguridad más elevado posible, los certificados de seguridad para el módulo criptográfico serán emitidos conforme al sistema de certificación de criterios comunes (ISO 15408) por un organismo de evaluación de la conformidad reconocido por el comité de gestión en el marco del Acuerdo SOG-IS, o bien serán emitidos por un organismo de evaluación de la conformidad acreditado por una autoridad nacional de certificación de la ciberseguridad de un Estado miembro. Dicho organismo de evaluación de la conformidad proporcionará, como mínimo, condiciones de evaluación de la seguridad equivalentes a las previstas en el Acuerdo sobre el reconocimiento mutuo SOG-IS.
Nota: se protegerá el vínculo entre el módulo criptográfico y la estación STI-C.
6.1.6.Copia de seguridad de claves privadas
326)La generación, el almacenamiento y la utilización de copias de seguridad de las claves privadas cumplirán, como mínimo, los requisitos del nivel de seguridad requerido para las claves originales.
327)Las copias de seguridad de las claves privadas serán realizadas por las CA raíz, las EA y las AA.
328)No se realizarán copias de seguridad de las claves privadas en el caso de las EC y los AT.
6.1.7.Destrucción de claves privadas
329)Las CA raíz, AE, AA, así como las estaciones STI-C móviles y fijas, destruirán su clave privada y las copias de seguridad correspondientes si se han generado e instalado correctamente un nuevo par de claves y el certificado correspondiente, y si el período de solapamiento (si existe, solo en el caso de la CA) ha pasado. La clave privada será destruida utilizando el mecanismo ofrecido por el módulo criptográfico utilizado para el almacenamiento de claves, o según lo descrito en el PP correspondiente, como se indica en el epígrafe 6.1.5.2.
6.2.Datos de activación
330)Los datos de activación se refieren a los factores de autenticación necesarios para utilizar módulos criptográficos a fin de evitar accesos no autorizados. El uso de los datos de activación de un dispositivo criptográfico de la CA requerirá la intervención de dos personas autorizadas.
6.3.Controles de seguridad informática
331)Los controles de seguridad informática de la CA se diseñarán de conformidad con el nivel de seguridad elevado cumpliendo los requisitos de la norma ISO/IEC 27002.
6.4.Controles técnicos del ciclo de vida
332)Los controles técnicos de la CA abarcarán todo su ciclo de vida, lo que incluye, en particular, los requisitos del epígrafe 6.1.4.3 («Criptoagilidad»).
6.5.Controles de seguridad de las redes
333)Las redes de las CA (CA raíz, EA y AA) se reforzarán contra los ataques en consonancia con los requisitos y las directrices de aplicación de las normas ISO/IEC 27001 e ISO/IEC 27002.
334)La disponibilidad de las redes de CA se diseñará teniendo en cuenta el tráfico previsto.
7.Perfiles de los certificados, CRL y CTL
7.1.Perfil de certificado
335)Los perfiles de certificación definidos en [5] se usarán para el TLM, los certificados raíz, los certificados EA, los certificados AA, los AT y las EC. Las EA estatales nacionales pueden utilizar otros perfiles de certificados para las EC.
336)Los certificados de CA raíz, EA y AA indicarán los permisos para los que estas CA (raíz, EA y AA) están autorizadas a emitir certificados.
337)Sobre la base de [5]:
cada CA raíz hará uso de su propia clave privada de firma para emitir las CRL;
el TLM hará uso de su propia clave privada de firma para emitir la ECTL.
7.2.Validez del certificado
338)Todos los perfiles de los certificados de los STI-C incluirán una fecha de emisión y expiración, que representa el período de validez del certificado. En cada nivel PKI, los certificados se generarán con antelación suficiente antes de la expiración.
339)El período de validez de los certificados de CA y EC incluirá un período de solapamiento. Los certificados del TLM y la CA raíz se emitirán e incluirán en la ECTL un máximo de tres meses y un mínimo de un mes antes de que empiece su validez, basándose en la fecha de inicio que figura en el certificado. Se requiere esta fase de precarga para distribuir los certificados de forma segura a todas las partes confiantes correspondientes, de conformidad con el epígrafe 2.2. Esto garantiza que, desde el inicio del período de solapamiento, todas las partes confiantes puedan ya verificar los mensajes emitidos con un nuevo certificado.
340)Al inicio del período de solapamiento, los sucesivos certificados de CA, EC y AT serán emitidos (si procede), distribuidos a las partes confiantes correspondientes e instalados por dichas partes. Durante el período de solapamiento, el certificado vigente se utilizará únicamente para verificación.
341)Dado que los períodos de validez enumerados en el cuadro 8 no deben superar el período de validez del certificado superior, se aplican las siguientes restricciones:
maximumvalidity(Root CA) = privatekeyusage(Root CA) + maximumvalidity(EA,AA);
maximumvalidity(EA) = privatekeyusage(EA) + maximumvalidity(EC);
maximumvalidity(AA) = privatekeyusage(AA) + preloadingperiod(AT).
342)La validez de los certificados de enlace (raíz y de TLM) comienza con el uso de la clave privada correspondiente y termina al acabar el período máximo de validez de la CA raíz o el TLM.
343)El cuadro 8 muestra el período máximo de validez de los certificados STI-C (para los períodos de validez de los AT, véase el epígrafe 7.2.1).
|
Entidad
|
Período máximo de utilización de la clave privada
|
Período máximo de validez
|
|
CA raíz
|
3 años
|
8 años
|
|
EA
|
2 años
|
5 años
|
|
AA
|
4 años
|
5 años
|
|
EC
|
3 años
|
3 años
|
|
TLM
|
3 años
|
4 años
|
Cuadro 8: Períodos de validez de los certificados en el modelo de confianza STI-C
7.2.1.Certificados de pseudónimos
344)En este contexto, los pseudónimos son aplicados por los AT. Por consiguiente, este epígrafe se refiere a los AT en lugar de a los pseudónimos.
345)Los requisitos establecidos en el presente epígrafe solo se aplican a los AT de las estaciones STI-C móviles que envíen CAM y DENM, cuando sea aplicable el riesgo de privacidad de la ubicación. No se aplican requisitos específicos sobre certificados de AT a los AT para estaciones STI-C fijas y móviles utilizadas para funciones especiales, en las que la privacidad de la ubicación no es aplicable (por ejemplo, vehículos marcados de servicios de emergencia y policiales).
346)Se entenderá por:
«período de validez de los AT»: período durante el cual un AT es válido, es decir, el período comprendido entre la fecha de inicio y la fecha de expiración;
«período de precarga de los AT»: la precarga es la posibilidad de que las estaciones STI-C obtengan AT antes del comienzo del período de validez. El período de precarga es el período máximo de tiempo permitido desde la solicitud de los AT hasta la última fecha de final de validez de los AT solicitados;
«período de uso de los AT»: período durante el cual un AT se utiliza efectivamente para firmar CAM/DENM;
«número máximo de AT paralelos»: el número de AT de entre los que una estación STI-C puede elegir en un momento dado al firmar un CAM/DENM, es decir, el número de distintos AT emitidos a una estación STI-C que son válidos al mismo tiempo.
347)Deberán cumplirse los siguientes requisitos:
el período de precarga de los AT no será superior a tres meses;
el período de validez de los AT no será superior a una semana;
el número máximo de AT paralelos no será superior a 100 por estación STI-C;
el período de uso de un AT depende de la estrategia de cambio de AT y del tiempo que un vehículo esté en funcionamiento, pero se ve limitado por el número máximo de AT paralelos y el período de validez. Más concretamente, el período medio de uso para una estación STI-C es, al menos, el tiempo de funcionamiento del vehículo durante un período de validez dividido por el número máximo de AT paralelos.
7.2.2.Tiques de autorización para estaciones STI-C fijas
348)Se aplican las definiciones del epígrafe 7.2.1 y los requisitos siguientes:
el período de precarga de los AT no será superior a tres meses;
el número máximo de AT paralelos no será superior a dos por estación STI-C.
7.3.Revocación de certificados
7.3.1.Revocación de certificados de CA, EA y AA
Los certificados de CA raíz, EA y AA serán revocables. Los certificados revocados de las CA raíz, EA y AA se publicarán en una CRL tan pronto como sea posible y sin demoras indebidas. Esta CRL será firmada por su CA raíz correspondiente y utilizará el perfil descrito en el epígrafe 7.4. Para la revocación de los certificados de CA raíz, la CA raíz correspondiente emite una CRL en la que se incluye a sí misma. Además, en caso de un comprometimiento de la seguridad, se aplica el epígrafe 5.7.3. Asimismo, el TLM suprimirá de la lista de confianza las CA raíz revocadas y emitirá una nueva lista de confianza. Los certificados caducados se retirarán de la CRL y de la lista de confianza correspondientes.
349)Los certificados se revocan cuando:
las CA raíz tienen motivos para creer o sospechar firmemente que la clave privada correspondiente se ha visto comprometida;
se notifica a las CA raíz que se ha puesto fin al contrato con el suscriptor;
la información (como el nombre y las asociaciones entre la CA y el sujeto) contenida en el certificado es incorrecta o ha cambiado;
se produce un incidente de seguridad que afecta al propietario del certificado;
una auditoría (véase el epígrafe 8) conduce a un resultado negativo.
350)El suscriptor deberá informar inmediatamente a la CA cuando se produzca o se sospeche que se ha producido un comprometimiento de su clave privada. Debe garantizarse que solo las solicitudes autenticadas den lugar a la revocación de los certificados.
7.3.2.Revocación de las credenciales de inscripción
351)La revocación de las credenciales de inscripción puede ser iniciada por el suscriptor de la estación STI-C (flujo 34) y se ejecutará mediante una lista negra interna en una base de datos de revocación con un sello de tiempo, que cada EA genera y mantiene. La lista negra nunca se publica y será confidencial y utilizada únicamente por la EA correspondiente para verificar la validez de las EC correspondientes en el contexto de las solicitudes de AT y de nuevas EC.
7.3.3.Revocación de los tiques de autorización
352)Dado que los AT no son revocados por las CA correspondientes, deberán tener una vida breve, y no pueden emitirse con demasiada antelación respecto del inicio de su validez. Los valores admisibles de los parámetros del ciclo de vida de los certificados se establecen en el epígrafe 7.2.
7.4.Lista de revocación de certificados
353)El formato y el contenido de la CRL emitida por la CA raíz serán los establecidos en [1].
7.5.Lista de confianza de certificación europea
354)El formato y el contenido de la ECTL emitida por el TLM serán los establecidos en [1].
8.Auditoría de conformidad y otras evaluaciones
8.1.Temas cubiertos por la auditoría y base de auditoría
355)La finalidad de una auditoría de conformidad es verificar que el TLM, las CA raíz, las EA y las AA operan de conformidad con la presente CP. El TLM, las CA raíz, las EA y las AA seleccionarán para auditar su CPS un auditor de la PKI acreditado que actúe de manera independiente. La auditoría se combinará con una evaluación ISO/IEC 27001 e ISO/IEC 27002.
356)Las auditorías de conformidad de las CA raíz son encargadas por la propia CA raíz (flujo 13), y las de las CA subordinadas son encargadas por su EA/AA subordinada.
357)Las auditorías de conformidad del TLM son encargadas por la CPA (flujo 38).
358)Cuando se solicite, un auditor de PKI acreditado realizará una auditoría de conformidad en uno de los siguientes niveles:
1)conformidad de la CPS del TLM, la CA raíz, la EA o la AA con la presente CP;
2)conformidad de las prácticas previstas del TLM, la CA raíz, la EA o la AA con su CPS antes de su funcionamiento;
3)conformidad de las prácticas y actividades operativas del TLM, la CA raíz, la EA o la AA con su CPS durante su funcionamiento.
359)La auditoría cubrirá todos los requisitos de la presente CP que deben cumplir el TLM, las CA raíz, las EA y las AA que deben auditarse. También cubrirá el funcionamiento de la CA en la PKI de los STI-C, incluidos todos los procesos mencionados en su CPS, los locales y las personas responsables.
360)El auditor acreditado de la PKI proporcionará un informe detallado de la auditoría a la CA raíz (flujo 36), EA, AA o CPA (flujos 16 y 40), según proceda.
8.2.Frecuencia de las auditorías
361)Las CA raíz, los TLM, las EA o las AA encargarán una auditoría de su conformidad realizada por un auditor de la PKI acreditado e independiente en los siguientes casos:
en su primera fase de establecimiento (conformidad de niveles 1 y 2);
en cada modificación de la CP. La CPA definirá el contenido y el calendario de implantación de la modificación de la CP y determinará en consecuencia las necesidades de auditoría (incluido el nivel de conformidad necesario);
en cada modificación de su CPS (conformidad de niveles 1, 2 y 3). Dado que las entidades gestoras de las CA raíz, el TLM y las EA/AA deciden qué cambios de implementación conlleva la actualización de sus CPS, encargarán una auditoría de conformidad antes de llevar a cabo las modificaciones. En caso de que solo se introduzcan ligeras modificaciones en las CPS (por ejemplo, de redacción), la entidad gestora puede enviar a la CPA una solicitud debidamente justificada de su aprobación para omitir las auditorías de conformidad de nivel 1, 2 o 3;
periódicamente, y como mínimo cada tres años durante su funcionamiento (conformidad de nivel 3).
8.3.Identidad y cualificaciones del auditor
362)La CA que se va a auditar seleccionará una empresa u organización acreditada («organismo auditor») o auditores acreditados de PKI que actúen de manera independiente para que la auditen de conformidad con la presente CP. El organismo auditor estará acreditado y certificado por un miembro de la Entidad Europea de Acreditación.
8.4.Relación del auditor con la entidad auditada
363)El auditor de la PKI acreditado será independiente de la entidad auditada.
8.5.Medidas adoptadas como resultado de una deficiencia
364)En caso de que un informe de auditoría considere que el TLM no es conforme, la CPA ordenará al TLM que adopte medidas preventivas o correctoras inmediatas.
365)Cuando una CA raíz con un informe de auditoría no conforme presente una nueva solicitud, la CPA rechazará la solicitud y enviará la denegación correspondiente a la CA raíz (flujo 4). En tal caso, se suspenderá la CA raíz. Debe adoptar medidas correctoras, volver a encargar la auditoría y hacer una nueva solicitud de aprobación de la CPA. Durante la suspensión, no se permitirá a la CA raíz emitir certificados.
366)En caso de auditoría periódica de la CA raíz o un cambio en la CPS de una CA raíz, y dependiendo de la naturaleza del incumplimiento descrito en el informe de auditoría, la CPA puede decidir revocar la CA raíz y comunicar esta decisión al TLM (flujo 2), provocando la supresión del certificado de CA raíz de la ECTL y la inclusión de la CA raíz en la CRL. La CPA enviará la denegación correspondiente a la CA raíz (flujo 4). La CA raíz debe adoptar medidas correctoras, volver a encargar una auditoría completa (niveles 1 a 3) y presentar una nueva solicitud de aprobación de la CPA. Otra posibilidad es que la CPA puede decidir no revocar la CA raíz, sino darle un período de gracia en el que la CA raíz tome medidas correctoras, encargue una nueva auditoría y vuelva a presentar el informe de auditoría a la CPA. En este caso, el funcionamiento de la CA raíz debe suspenderse y no se le permite emitir certificados ni CRL.
367)En caso de auditoría de una EA/AA, la CA raíz decidirá si acepta o no el informe. En función del resultado de la auditoría, la CA raíz decidirá si va a revocar el certificado EA/AA de conformidad con las normas que figuran en la CPS de la CA raíz. La CA raíz garantizará en todo momento el cumplimiento de la presente CP por parte de la EA/EA.
8.6.Comunicación de los resultados
368)La CA raíz y el TLM enviarán el informe de auditoría a la CPA (flujo 16). La CA raíz y el TLM almacenarán todos los informes de auditoría que hayan encargado. La CPA enviará la aprobación o denegación correspondiente (flujo 4) a la CA raíz y la TLM.
369)La CA raíz enviará un certificado de conformidad a la correspondiente EA/AA.
9.Otras disposiciones
9.1.Tasas
370)Uno de los principios del modelo de confianza STI-C de la Unión es que las CA raíz financian juntas en su totalidad los costes recurrentes periódicos del funcionamiento de la CPA y los elementos centrales (TLM y CPOC) relacionados con las actividades expuestas en la presente CP.
371)Las CA raíz (incluida la CA raíz de la Unión) están autorizadas a cobrar tasas a sus CA subordinadas.
372)Durante su período de funcionamiento, todos los participantes del modelo de confianza STI-C tendrán acceso al menos a una CA raíz, EA y AA, de manera no discriminatoria.
373)Cada CA raíz está autorizada a repercutir las tasas que paga por la CPA y los elementos centrales (TLM y CPOC) a los participantes registrados del modelo de confianza STI-C, incluidas las estaciones STI-C inscritas y autorizadas.
9.2.Responsabilidad financiera
374)El establecimiento inicial de una CA raíz abarcará un período de al menos tres años de funcionamiento, antes de convertirse en miembro del modelo de confianza STI-C de la Unión. La CPS de un operador de CA raíz también contendrá disposiciones detalladas sobre la revocación o el cierre de la CA raíz.
375)Cada CA raíz debe demostrar la viabilidad financiera de la entidad jurídica que la ejecuta durante al menos tres años. Este plan de viabilidad financiera forma parte del conjunto inicial de documentos de inscripción y debe actualizarse cada tres años y notificarse a la CPA.
376)Cada CA raíz debe comunicar cada año la estructura de las tarifas aplicadas a las AE/AA y las estaciones STI-C inscritas y autorizadas al gestor de operaciones y a la CPA para demostrar su sostenibilidad financiera.
377)Todas las entidades financieras y jurídicas responsables de las CA raíz, las EA, las AA y los elementos centrales del modelo de confianza STI-C (CPOC y TLM) deben cubrir sus funciones operativas con seguros adecuados para compensar los errores operativos y la recuperación financiera respecto de sus funciones si uno de los elementos técnicos falla.
9.3.Confidencialidad de la información empresarial
378)Se mantendrán confidenciales y privados:
los registros de solicitudes de las CA raíz, las EA y las AA, tanto si son aprobadas como denegadas;
los informes de auditoría de las CA raíz, las EA, las AA y el TLM;
los planes de recuperación en caso de catástrofe de las CA raíz, las EA, las AA, el CPOC y el TLM;
las claves privadas de los elementos del modelo de confianza STI-C (estaciones STI-C, TLM, EA, AA y CA raíz);
cualquier otra información considerada confidencial por la CPA, las CA raíz, las EA, las AA, el TLM y el CPOC.
9.4.Plan de privacidad
379)Las CPS de la CA raíz y las AE/AA establecerán el plan y los requisitos para el tratamiento de la información personal y la privacidad sobre la base del RGPD y de otros marcos legislativos (por ejemplo, nacionales) aplicables.
10.Referencias
En el presente anexo se utilizan las siguientes referencias:
|
[1]
|
ETSI TS 102 941 V1.2.1, Intelligent transport systems (ITS) – security, trust and privacy management («Sistemas de transporte inteligentes [STI]. Gestión de la seguridad, la confianza y la privacidad»).
|
|
[2]
|
ETSI TS 102 940 V1.3.1, Intelligent transport systems (ITS) – security, ITS communications security architecture and security management («Sistemas de transporte inteligentes [STI]. Seguridad, arquitectura de seguridad de las comunicaciones STI y gestión de la seguridad».
|
|
[3]
|
Certificate policy and certification practices framework («Política de certificados y marco de las prácticas de certificación») (RFC 3647, 1999).
|
|
[4]
|
ETSI TS 102 042 V2.4.1 Policy requirements for certification authorities issuing public key certificates («Requisitos de actuación aplicables a las autoridades de certificación que emiten certificados de clave pública»).
|
|
[5]
|
ETSI TS 103 097 V1.3.1, Intelligent transport systems (ITS) – security, security header and certificate formats («Sistemas de transporte inteligentes [STI]. Seguridad, cabecera de seguridad y formatos de certificado»).
|
|
[6]
|
Calder, A. (2006). Information security based on ISO 27001/ISO 1779: a management guide. Van Haren Publishing.
|
|
[7]
|
ISO, I., & Std, I. E. C. (2011). ISO 27005 (2011) – information technology, security techniques, information security risk management («Tecnología de la información, técnicas de seguridad y gestión del riesgo de seguridad de la información»). ISO.
|
|
|
|
