Technical Insight

GAR INSIGHT
Conectados, actualizados y regulados: la evolución de ONU R155 y R156

El vehículo moderno ya no se define únicamente por sus sistemas mecánicos. La conectividad, el software, las unidades de control electrónico, los servicios en la nube, las aplicaciones móviles y las actualizaciones inalámbricas determinan cada vez más cómo funciona durante toda su vida útil.

Esta transformación ha creado un nuevo desafío de homologación. Un vehículo puede cumplir técnicamente al salir de la línea de producción y, aun así, su exposición a riesgos de ciberseguridad puede cambiar cuando surgen nuevas vulnerabilidades, evolucionan los servicios conectados y se actualiza el software.

Los Reglamentos n.º 155 y n.º 156 de la ONU responden a este cambio fundamental. Juntos introducen marcos regulatorios de ciberseguridad del vehículo, gestión de la ciberseguridad y gobernanza de actualizaciones de software, extendiendo la conformidad desde el vehículo físico a los procesos organizativos del fabricante y al ciclo de vida digital continuo del vehículo.

La pregunta de homologación ha cambiado. Los reguladores ya no necesitan saber únicamente si el vehículo cumple hoy. Cada vez más necesitan garantías de que los riesgos de ciberseguridad y los cambios de software pueden seguir controlándose después de su entrada en servicio.
01
EL VEHÍCULO DIGITAL

La homologación ya no trata únicamente del hardware

La homologación tradicional se desarrolló en torno a sistemas físicos relativamente estables: frenos, dirección, alumbrado, estructuras, emisiones y protección de ocupantes.

Los vehículos modernos introducen un entorno de ingeniería muy diferente. El software controla cada vez más funciones críticas para la seguridad mientras los vehículos se comunican continuamente con sistemas externos.

VEHÍCULO TRADICIONAL Configuración relativamente estable

Las características del vehículo permanecen en gran medida fijas después de la producción, con la evaluación regulatoria centrada en la homologación del diseño y la conformidad de la producción.

VEHÍCULO CONECTADO Entorno digital en cambio continuo

El software, la conectividad, los servicios de backend y las amenazas cibernéticas emergentes pueden modificar el entorno operativo del vehículo durante toda su vida útil.

El vehículo tiene ahora una superficie de ataque digital. Cada interfaz de comunicación, componente de software, servicio conectado y dependencia externa puede influir potencialmente en la ciberseguridad del vehículo.
↑ Volver a la guía del artículo
02
REGLAMENTO N.º 155 DE LA ONU

La ciberseguridad forma parte de la homologación de tipo

El Reglamento n.º 155 de la ONU establece disposiciones uniformes sobre la homologación de vehículos en relación con la ciberseguridad y el sistema de gestión de la ciberseguridad —CSMS—.

El reglamento crea dos niveles de aseguramiento estrechamente relacionados.

NIVEL ORGANIZATIVO Sistema de gestión de la ciberseguridad

El fabricante debe demostrar procesos para identificar, evaluar, tratar y supervisar los riesgos de ciberseguridad durante las fases pertinentes del ciclo de vida del vehículo.

NIVEL DEL VEHÍCULO Homologación de tipo en materia de ciberseguridad

El fabricante debe demostrar que se han identificado y abordado adecuadamente los riesgos de ciberseguridad pertinentes para el tipo de vehículo.

R155 no pregunta simplemente si un vehículo puede resistir una prueba de penetración. Pregunta si el fabricante dispone de una capacidad sistemática para gestionar los riesgos de ciberseguridad durante el desarrollo, la producción y las actividades posteriores a la producción.
↑ Volver a la guía del artículo
03
CSMS

La ciberseguridad debe gestionarse como un proceso de ciclo de vida

El sistema de gestión de la ciberseguridad cambia el modelo de cumplimiento porque la homologación depende en parte de la capacidad organizativa, además de las características de un vehículo.

Identificación de riesgos

Los procesos deben identificar las amenazas de ciberseguridad, las vulnerabilidades y las posibles vías de ataque pertinentes.

Evaluación de riesgos

Los riesgos identificados deben evaluarse según sus posibles consecuencias y su probabilidad.

Tratamiento de riesgos

Se implementan medidas adecuadas de diseño, técnicas y organizativas para reducir el riesgo de ciberseguridad.

Verificación

Las medidas de ciberseguridad necesitan evidencias que demuestren que funcionan según lo previsto.

Seguimiento

Las nuevas amenazas y vulnerabilidades deben seguir considerándose después de que los vehículos entren en servicio.

Respuesta

Los fabricantes necesitan procesos para responder cuando se identifican cuestiones pertinentes de ciberseguridad.

El cambio regulatorio importante es la continuidad.

La gestión de la ciberseguridad no puede terminar cuando se concede la homologación de tipo, porque el propio entorno de amenazas sigue cambiando.

↑ Volver a la guía del artículo
04
AMENAZAS Y VULNERABILIDADES

La superficie de ataque se extiende mucho más allá del vehículo

Los vehículos conectados interactúan con múltiples sistemas internos y externos. Por ello, la evaluación de ciberseguridad debe considerar el ecosistema completo, además de los componentes electrónicos individuales.

Redes del vehículo

Las redes internas de comunicación y las unidades de control electrónico pueden convertirse en posibles vías de ataque.

Interfaces inalámbricas

Las interfaces de telefonía móvil, Wi-Fi, Bluetooth y otras comunicaciones aumentan la conectividad externa.

Interfaces de diagnóstico

El acceso de servicio y diagnóstico puede introducir riesgos de ciberseguridad si no se controla adecuadamente.

Infraestructura de backend

Los servidores del fabricante y los servicios conectados pueden influir en las funciones y los datos del vehículo.

Aplicaciones móviles

Las aplicaciones de control del vehículo y de usuario pueden formar parte del perímetro más amplio de ciberseguridad.

Cadena de suministro de software

El software, las bibliotecas, los componentes y los proveedores de terceros pueden introducir vulnerabilidades fuera del entorno de desarrollo directo del fabricante.

Un vehículo puede ser atacado sin tocarlo físicamente. Esto cambia fundamentalmente el significado de la seguridad del vehículo y extiende la homologación a sistemas que pueden existir mucho más allá de sus límites físicos.
↑ Volver a la guía del artículo
05
REGLAMENTO N.º 156 DE LA ONU

Las actualizaciones de software forman parte del control regulatorio

El Reglamento n.º 156 de la ONU establece disposiciones uniformes sobre actualizaciones de software y el sistema de gestión de actualizaciones de software —SUMS—.

Su importancia va mucho más allá de las actualizaciones inalámbricas. El reglamento crea un marco estructurado para controlar cambios de software que pueden afectar a las características homologadas del vehículo.

NIVEL ORGANIZATIVO Sistema de gestión de actualizaciones de software

El fabricante establece procesos para identificar, evaluar, controlar, documentar y desplegar actualizaciones de software del vehículo.

NIVEL DEL VEHÍCULO Cumplimiento de las actualizaciones de software

El vehículo y sus procesos de actualización deben cumplir los requisitos aplicables de identificación e integridad del software y ejecución segura de las actualizaciones.

ONU R156 no es simplemente un «reglamento OTA».

Su finalidad más amplia es garantizar que las actualizaciones de software se controlen sistemáticamente y que las características pertinentes para la homologación sigan siendo trazables cuando cambia el software.

↑ Volver a la guía del artículo
06
SUMS

Los cambios de software requieren gobernanza

El sistema de gestión de actualizaciones de software proporciona el marco organizativo mediante el cual los fabricantes controlan las actualizaciones que afectan a los vehículos.

Identificación del software

Las versiones y configuraciones pertinentes de software deben permanecer identificables y trazables.

Evaluación de la actualización

Los fabricantes necesitan procesos para determinar cómo afecta una actualización a las características homologadas del vehículo.

Impacto sobre la homologación

Los cambios deben evaluarse para determinar si se necesitan pruebas adicionales, una extensión de homologación u otra acción regulatoria.

Integridad de la actualización

Los paquetes de actualización y los procesos de despliegue requieren protección frente a manipulaciones no autorizadas.

Instalación segura

El vehículo debe gestionar adecuadamente el proceso de instalación y las condiciones pertinentes para ejecutar la actualización.

Documentación

Los cambios de software y su relación con la configuración homologada del vehículo requieren registros controlados.

La gobernanza del software forma parte de la gobernanza de la homologación. Cuando el software puede modificar una función pertinente para la homologación, su configuración pasa a formar parte de la identidad regulatoria del vehículo.
↑ Volver a la guía del artículo
07
IDENTIFICACIÓN DEL SOFTWARE

RxSWIN vincula el software con la homologación de tipo

Uno de los conceptos importantes introducidos por el marco ONU R156 es el número de identificación del software relativo al reglamento —RxSWIN—.

Cuando procede, RxSWIN proporciona un mecanismo regulatorio que vincula el software pertinente para un Reglamento concreto de la ONU con la configuración homologada del vehículo.

IDENTIFICACIÓN FÍSICA Tipo de vehículo y componentes

La homologación tradicional identifica configuraciones físicas, sistemas y componentes asociados a una homologación.

IDENTIFICACIÓN DIGITAL Software pertinente para la homologación

RxSWIN permite identificar la configuración de software aplicable dentro del marco regulatorio.

¿Por qué es importante?

Dos vehículos físicamente idénticos pueden comportarse de manera diferente porque contienen software distinto. Por ello, la trazabilidad regulatoria debe identificar cada vez más tanto el hardware como el software que gobierna las funciones homologadas.

↑ Volver a la guía del artículo
08
ACTUALIZACIONES INALÁMBRICAS

El vehículo puede cambiar después de salir de fábrica

Las actualizaciones inalámbricas permiten a los fabricantes modificar el software de los vehículos a distancia sin que todos tengan que acudir a un taller.

Las ventajas son importantes. Los fabricantes pueden corregir fallos, mejorar funciones, abordar vulnerabilidades de ciberseguridad y desplegar nuevas capacidades en flotas de vehículos.

Pero esa misma capacidad plantea una pregunta de homologación sin precedentes: ¿qué ocurre cuando un vehículo ya homologado cambia después de entrar en servicio?

Antes de la actualización

Determinar la configuración existente del vehículo y las homologaciones regulatorias aplicables.

Evaluación del impacto

Evaluar si la actualización propuesta modifica características pertinentes para la homologación.

Validación

Verificar que el software modificado se comporta según lo previsto y sigue cumpliendo los requisitos aplicables.

Despliegue

Entregar la actualización mediante mecanismos controlados y protegidos.

Instalación

Garantizar que el vehículo pueda completar de forma segura o gestionar adecuadamente el proceso de actualización.

Trazabilidad posterior a la actualización

Conservar evidencias de la configuración resultante de software y regulación.

La línea de producción ya no es el último punto en el que se configura el vehículo. La capacidad OTA extiende en la práctica parte del entorno de gestión de configuración del fabricante a la vida útil del vehículo.
↑ Volver a la guía del artículo
09
R155 + R156

La ciberseguridad y las actualizaciones no pueden gestionarse por separado

ONU R155 y ONU R156 abordan objetivos regulatorios distintos, pero están estrechamente conectados desde el punto de vista operativo.

ONU R155 Gestionar el riesgo de ciberseguridad

Identificar amenazas y vulnerabilidades, implementar medidas de mitigación adecuadas y mantener la supervisión de la ciberseguridad durante el ciclo de vida pertinente del vehículo.

ONU R156 Gestionar los cambios de software

Controlar, evaluar, documentar y desplegar actualizaciones de software manteniendo la conformidad regulatoria aplicable al vehículo.

La conexión se hace especialmente clara cuando se descubre una vulnerabilidad de ciberseguridad después de que los vehículos hayan entrado en servicio.

01 Se identifica la vulnerabilidad
02 Se evalúa el riesgo cibernético
03 Se desarrolla la corrección de software
04 Se evalúa el impacto sobre la homologación
05 Se valida la actualización
06 Se despliega la actualización
R155 identifica la necesidad de gestionar el riesgo cibernético. R156 ayuda a gobernar el cambio de software utilizado para abordarlo. Juntos forman una base regulatoria importante para mantener vehículos que evolucionan digitalmente después de la homologación de tipo.
↑ Volver a la guía del artículo
10
CONTROL DE LA CADENA DE SUMINISTRO

El fabricante no puede proteger el vehículo por sí solo

El software y las arquitecturas electrónicas de los vehículos modernos dependen de amplios ecosistemas de proveedores. Los fabricantes pueden integrar hardware, software embebido, sistemas operativos, módulos de conectividad, infraestructura en la nube y servicios de terceros procedentes de muchas organizaciones.

Requisitos de proveedores

Las expectativas de ciberseguridad y gestión del software deben incorporarse a las relaciones con los proveedores.

Intercambio de evidencias

Los fabricantes necesitan evidencias técnicas adecuadas de sus proveedores para respaldar la evaluación de ciberseguridad del vehículo.

Notificación de cambios

Los cambios de software y componentes de los proveedores necesitan comunicación controlada cuando pueden afectar a la conformidad del vehículo.

Respuesta a vulnerabilidades

Las vulnerabilidades recién identificadas pueden requerir investigación y mitigación coordinadas entre varias organizaciones.

La responsabilidad de ciberseguridad no puede simplemente externalizarse.

El fabricante depende de las evidencias y la cooperación de su cadena de suministro, manteniendo la responsabilidad de demostrar la conformidad del tipo de vehículo.

↑ Volver a la guía del artículo
11
EVOLUCIÓN REGULATORIA

ONU R155 y R156 siguen evolucionando

La regulación de ciberseguridad y software no puede permanecer estática, porque las tecnologías y los riesgos que regula también cambian.

El Grupo de Trabajo de la CEPE/ONU sobre Vehículos Automatizados/Autónomos y Conectados —GRVA— y sus actividades especializadas de ciberseguridad y actualizaciones de software siguen desarrollando el marco regulatorio.

R156 — Serie 01

ONU R156 ha avanzado hacia una nueva serie 01 de modificaciones, que refleja el desarrollo continuo del marco regulatorio de actualizaciones de software.

Orientaciones de interpretación

El documento de interpretación de R156 sigue desarrollándose para respaldar una aplicación coherente de los requisitos de actualizaciones de software y SUMS.

Desarrollo de R155

Otras propuestas sobre ONU R155 y su marco de gestión de ciberseguridad siguen bajo consideración activa de la CEPE/ONU.

Integración entre reglamentos

Las disposiciones de ciberseguridad y actualizaciones de software interactúan cada vez más con otros reglamentos que regulan funciones del vehículo controladas electrónicamente.

La dirección es hacia una integración más profunda. La gobernanza de la ciberseguridad y de las actualizaciones de software se convierte progresivamente en un conjunto de requisitos transversales que interactúan con el frenado, la dirección, los ADAS, la conducción automatizada y otros sistemas controlados por software.
↑ Volver a la guía del artículo
12
PREPARACIÓN DEL FABRICANTE

Crear una conformidad digital continua

R155 y R156 exigen que los fabricantes piensen más allá de las pruebas individuales de homologación y establezcan sistemas repetibles capaces de respaldar el cumplimiento durante todo el ciclo de vida del vehículo.

01 — Establecer el CSMS

Crear una gobernanza de ciberseguridad que abarque desarrollo, producción, seguimiento, respuesta a incidentes y actividades pertinentes de la cadena de suministro.

02 — Establecer el SUMS

Implementar procesos controlados para identificación del software, evaluación de actualizaciones, validación, despliegue y trazabilidad regulatoria.

03 — Identificar la arquitectura del vehículo

Comprender los sistemas electrónicos, las interfaces, los flujos de datos, las dependencias de software y las posibles superficies de ataque.

04 — Integrar proveedores

Establecer mecanismos de evidencias, comunicación y control de cambios en la cadena de suministro de software y componentes.

05 — Vincular el software con la homologación

Mantener la trazabilidad entre las configuraciones de software y los reglamentos afectados por esas configuraciones.

06 — Supervisar la flota

Mantener la capacidad de identificar problemas emergentes de ciberseguridad y responder adecuadamente después de la entrada en servicio.

El objetivo no es simplemente obtener un certificado CSMS o SUMS.

El verdadero objetivo es crear un sistema operativo de gobernanza capaz de respaldar vehículos seguros, controlados y con cumplimiento demostrable mientras evolucionan el software y los riesgos cibernéticos.

↑ Volver a la guía del artículo

De la homologación de tipo a la conformidad digital continua

ONU R155 y ONU R156 representan más que dos requisitos adicionales en la cartera de homologación de vehículos.

Reflejan un cambio estructural en la relación entre la ingeniería del vehículo y la conformidad regulatoria.

Las amenazas de ciberseguridad pueden surgir después de la producción. El software puede cambiar el comportamiento del vehículo después de la homologación. Las vulnerabilidades pueden originarse en el vehículo, la cadena de suministro o la infraestructura conectada. Por ello, la evidencia regulatoria debe extenderse más allá del momento tradicional de homologación de tipo.

HOMOLOGACIÓN TRADICIONAL Diseñar → Ensayar → Homologar → Producir

El cumplimiento se concentra en una configuración de vehículo relativamente estable.

HOMOLOGACIÓN DIGITAL Diseñar → Evaluar → Homologar → Supervisar → Actualizar → Reevaluar

La gobernanza de ciberseguridad y software extiende la conformidad a la vida operativa del vehículo.

El perímetro regulatorio del vehículo se amplía. El software, los procesos de ciberseguridad, las relaciones con proveedores, los sistemas de backend y las actualizaciones posteriores a la producción forman cada vez más parte de las evidencias necesarias para mantener la confianza en la conformidad.
El vehículo conectado no deja de evolucionar al salir de fábrica. Su marco de conformidad tampoco puede terminar allí.
Contexto regulatorio: Los requisitos de ciberseguridad y actualizaciones de software dependen de la categoría del vehículo, el mercado de destino, la serie aplicable del Reglamento de la ONU y los reglamentos afectados por configuraciones o actualizaciones individuales. Los Reglamentos n.º 155 y n.º 156 de la ONU y sus documentos de interpretación siguen evolucionando mediante las actividades de WP.29 y GRVA de la CEPE/ONU. Por ello, los fabricantes deben confirmar el texto regulatorio vigente, las series de modificaciones, las disposiciones de aplicación y los requisitos de homologación para el programa específico del vehículo antes de iniciar actividades de certificación u homologación.
GLOBAL ALLIANCE REGISTER

How Global Alliance Register Can Support You

Global Alliance Register supports organizations and project stakeholders with independent technical-assurance services relevant to la evolución de onu r155 y r156. Based on the article's emphasis on technical assurance, verification and risk management, GAR can coordinate competent specialists, laboratories, inspectors, auditors and accredited conformity-assessment resources as appropriate to the actual technical need. Within the context of this article, Global Alliance Register can support you in the following areas:

01

Define the technical, regulatory, quality and risk objectives for la evolución de onu r155 y r156 and determine which combination of testing, inspection, certification, audit or advisory services is appropriate.

02

Coordinate competent laboratories, inspectors, auditors, certification bodies and specialist technical resources for la evolución de onu r155 y r156 according to scope, geography and the required level of independence.

03

Integrate test results, inspection reports, audit evidence and certification outcomes relating to la evolución de onu r155 y r156 into a coherent assurance process with clear responsibilities and traceability.

04

Structure the assurance approach for la evolución de onu r155 y r156 so consultancy, testing, inspection, audit and certification roles maintain the appropriate independence and decision-making boundaries.

05

Assess the existing management-system arrangements relevant to la evolución de onu r155 y r156, identify gaps against applicable requirements and prioritise practical improvement actions.

Scroll to Top