La SOVD y el derecho a la reparación de la UE: creación de una arquitectura de acceso al diagnóstico escalable y compatible para los SDV

La mayoría de los OEM que operan en los mercados de la UE ya conocen el cumplimiento del derecho a reparar. El Reglamento de exención por categorías para vehículos de motor (MVBER) exige a los talleres de reparación independientes un acceso no discriminatorio al diagnóstico desde 1995. No se trata de una nueva normativa que afecte al sector, sino de una base de referencia establecida que ha determinado el funcionamiento de los mercados automotrices europeos durante tres décadas.

Lo que ha cambiado es el vehículo. Los vehículos definidos por software (con HPC centralizados, aplicaciones en contenedores, actualizaciones OTA remotas y flujos de trabajo de servicios conectados a la nube) están haciendo que las arquitecturas de diagnóstico tradicionales sean cada vez más frágiles. Los enfoques que satisfacían técnicamente los requisitos del MVBER en la era de las ECU independientes y el acceso a los talleres físicos tienen dificultades para adaptarse a la era de la SDV.

La verdadera pregunta para los OEM hoy en día no es si deben proporcionar acceso al diagnóstico, ya están obligados a hacerlo. La cuestión es si su arquitectura de diagnóstico puede realmente ofrecer ese acceso de una manera que sea administrable, segura y valiosa desde el punto de vista operativo, a medida que aumenta la complejidad del software de los vehículos. La solución SOVD es la solución arquitectónica, y sus beneficios van mucho más allá del cumplimiento de las normativas y permiten a los fabricantes de equipos originales hacer que sus redes de concesionarios y de servicio independientes funcionen en vehículos cada vez más basados en software.

La base de cumplimiento: lo que realmente requiere MVBER

El MVBER otorga a los fabricantes de equipos originales una exención de ciertos requisitos de la legislación de competencia de la UE, incluido el derecho a operar redes de concesionarios franquiciados, a cambio de una obligación clara: los talleres de reparación independientes deben recibir un acceso no discriminatorio a los datos técnicos, las herramientas de diagnóstico y la información de reparación en condiciones comerciales justas.

Esto significa que los OEM no pueden usar arquitecturas de diagnóstico patentadas para crear barreras de acceso de hecho que favorezcan a las redes de concesionarios autorizados en lugar de a las de los talleres de reparación independientes. El acceso debe ser técnicamente factible, no solo teóricamente permitido. Y a medida que los vehículos se definen cada vez más por el software, la expresión «técnicamente factible» se convierte en un requisito cada vez más exigente.

Un ejemplo concreto: un importante OEM ha estado explorando la SOVD específicamente porque su solución de diagnóstico patentada no se puede implementar en la UE en su forma actual. El problema no es la intención legal, sino la realidad arquitectónica. Los sistemas patentados diseñados para las redes de distribuidores crean patrones de acceso que no se corresponden claramente con el acceso no discriminatorio que requiere MVBER, especialmente a medida que el diagnóstico pasa al software y a los dominios remotos.

MVBER de un vistazo

Activo desde 1995, extendido hasta 2028. Exige a los fabricantes de equipos originales que proporcionen a los talleres de reparación independientes acceso a la información técnica y de reparación de los vehículos en condiciones no discriminatorias, comparables a las que reciben las redes de concesionarios autorizados. Se aplica a todos los OEM que venden vehículos en los mercados de la UE, independientemente de dónde tenga su sede el OEM.

Por qué los SDV dificultan el problema de la arquitectura

Los diagnósticos tradicionales se diseñaron en torno a una arquitectura de ECU distribuida y estable. Cada ECU tenía identificadores fijos, archivos de descripción estáticos y una implementación de UDS conocida. El cumplimiento implicaba publicar esas interfaces, algo complejo e imperfecto, pero realizable.

Los vehículos definidos por software rompen este modelo de varias maneras:

• Configuraciones de software dinámicas: Los SDV modernos ejecutan aplicaciones en contenedores en los HPC. El software cambia con cada actualización de OTA. El vehículo que se envió no es el vehículo que estaba en el campo seis meses después. Los archivos de descripción estáticos y los mapas fijos de la ECU no pueden seguir el ritmo.
  
• Flujos de trabajo de servicios remotos y basados en la nube: Los diagnósticos se realizan cada vez más antes de que el vehículo llegue al taller: clasificación previa remota, monitoreo del estado de la flota y alertas de servicio activadas por la OTA. Los modelos tradicionales de diagnóstico de acceso físico no se diseñaron para esto, y los túneles remotos patentados conectados a los sistemas antiguos crean fragmentación.
  
• Requisitos de acceso de múltiples partes interesadas: MVBER requiere acceso para reparadores independientes. Los operadores de flotas también necesitan su propio acceso. El soporte central de los OEM necesita visibilidad remota. Los técnicos de los concesionarios necesitan herramientas en el taller. Los equipos de ingeniería necesitan un acceso profundo a la depuración. La gestión de todo esto mediante integraciones punto-a-punto patentadas no es escalable.
  
• Evidencia de auditoría y cumplimiento: Las normativas como la ONU R156 exigen pruebas estructuradas sobre cómo se gestionan las actualizaciones de software. La creación de paquetes de cumplimiento a partir de registros dispersos en sistemas propietarios es cada vez más insostenible a medida que crece la escala de la flota.

El resultado es que los OEM que crearon arquitecturas de diagnóstico adecuadas para la generación anterior de vehículos se enfrentan a una deuda técnica cada vez mayor precisamente cuando sus obligaciones de servicio y cumplimiento se amplían.

SOVD: la base arquitectónica para un acceso escalable

El SOVD (diagnóstico de vehículos orientado al servicio) es un estándar de ASAM (que pasa a través de la ISO como ISO 17978) que define una API basada en HTTP/REST para el diagnóstico de vehículos. Mientras que el diagnóstico tradicional requería que todas las herramientas implementaran una lógica de comunicación personalizada para cada programa del vehículo, el SOVD proporciona un contrato de API común. El contenido de diagnóstico (códigos de error, mediciones, parámetros de configuración y estado de actualización del software) se expone a través de terminales REST estandarizados que utilizan JSON, y las capacidades se autodescriben a través de las especificaciones de OpenAPI.

Para los OEM que se enfrentan simultáneamente a las obligaciones de cumplimiento de la UE y a la complejidad de los servicios de SDV, SOVD aborda ambas cuestiones mediante la misma inversión arquitectónica.

Una interfaz en todos los escenarios de acceso

SOVD define una API unificada que funciona en escenarios remotos (basados en la nube), de proximidad (en la tienda) y en el vehículo. Un taller de reparación independiente que se conecta al taller, un operador de flota que monitorea de forma remota y un ingeniero de soporte OEM que realiza una evaluación previa antes de una visita de servicio interactúan a través de la misma interfaz lógica: el acceso se rige por los permisos basados en los roles, no por el conjunto de herramientas propias del que disponen.

Para el cumplimiento de MVBER, esto es importante porque la arquitectura admite de forma inherente el acceso no discriminatorio. El OEM define los niveles de autorización (quién ve qué), pero la interfaz en sí está estandarizada y está disponible para cualquier herramienta autorizada, no está limitada a una cadena de herramientas o VCI específica del OEM.

Acceso controlado y auditable: los OEM mantienen el control

Un punto crítico que vale la pena enfatizar: el SOVD no abre el diagnóstico del vehículo a nadie. Los OEM mantienen el control total sobre la autorización mediante OAuth 2.0 y OpenID Connect, los mismos estándares de seguridad que se utilizan en el software empresarial. El control de acceso basado en funciones determina exactamente lo que puede hacer cada tipo de cliente. Un reparador independiente tiene acceso a los códigos de avería y a las rutinas de diagnóstico definidas. Un ingeniero OEM obtiene un acceso más profundo a las funciones de calibración y depuración. El operador de una flota ve los datos de estado y estado.

Lo que cambia no es quién controla el acceso (los OEM todavía lo hacen) sino cómo se administra ese acceso. Una API estandarizada, registrada y auditable reemplaza un conjunto fragmentado de integraciones patentadas que son difíciles de gestionar a escala.

Uniendo las ECU heredadas y las arquitecturas basadas en HPC

El SOVD no requiere reemplazar la infraestructura de ECU existente. Un adaptador de diagnóstico clásico gestiona la traducción entre las solicitudes del SOVD y los comandos del UDS para las ECU tradicionales; los sistemas antiguos siguen funcionando. Las nuevas aplicaciones basadas en HPC pueden mostrar los diagnósticos de forma nativa a través del SOVD. La herramienta del reparador independiente se comunica con una interfaz; el vehículo gestiona las rutas internamente. Esto hace que la adopción gradual sea realista sin un programa de quitar y reemplazar.

La evidencia de cumplimiento como subproducto

Un R156 exige a los OEM que mantengan los sistemas de gestión de actualizaciones de software con pruebas estructuradas de cómo se planifican, ejecutan y validan las actualizaciones. Las interacciones de API registradas y estandarizadas de SOVD generan esta evidencia de forma natural. El inventario del software, las comprobaciones de disponibilidad, la validación posterior a la actualización y los registros de auditoría son los resultados de las operaciones normales del SOVD, y no un ejercicio forense independiente realizado en el momento de revisar el cumplimiento.

La ventaja de la red de concesionarios y servicios

Más allá del cumplimiento, el valor más profundo de SOVD es lo que permite a las redes de servicio independientes y de concesionarios que prestan servicio a los SDV. Aquí es donde el ROI operativo se concreta.

Clasificación previa remota antes de la visita al taller

El soporte central de los OEM puede acceder a los vehículos a través del SOVD antes de que lleguen para ser reparados, recuperando registros, identificando patrones de fallas, configurando la captura de datos de alta resolución y, en muchos casos, resolviendo problemas sin una visita física. Cuando es necesaria una visita al taller, el técnico llega con un contexto, no con una pizarra en blanco. Las tarifas fijas por primera vez mejoran. Los reemplazos innecesarios de piezas disminuyen. Los costos de garantía disminuyen.

Herramientas para concesionarios que siguen el ritmo de las actualizaciones de software

En el vehículo definido por software, el perfil de diagnóstico del automóvil puede cambiar con cada actualización de la OTA. La arquitectura autodescriptiva del SOVD permite que las herramientas del concesionario descubran las capacidades actuales del vehículo en tiempo de ejecución, en lugar de basarse en bases de datos de descripciones estáticas que pueden estar ya desactualizadas. Los concesionarios trabajan en el vehículo que existe hoy en día, no en una instantánea del software de hace seis meses.

Habilitación de reparadores independientes sin exposición a la propiedad intelectual

Una de las principales tensiones en el derecho a la reparación siempre ha sido: ¿cómo se puede proporcionar un acceso significativo al diagnóstico sin exponer el software de calibración, el código de la ECU y los algoritmos de alto valor patentados? El SOVD soluciona este problema mediante la encapsulación de los servicios. La API revela lo que un taller de reparación necesita para diagnosticar y reparar el vehículo (códigos de avería, valores de medición, rutinas de prueba definidas) sin exponer la implementación del software subyacente. Los OEM definen el límite del servicio de diagnóstico; el SOVD lo hace cumplir.

Acceso escalable para operadores de flotas

Los operadores de flotas representan algunos de los escenarios de servicio más exigentes: altos recuentos de vehículos, operaciones críticas desde el punto de vista del tiempo de actividad y flotas distribuidas geográficamente. La tecnología SOVD permite monitorizar el estado de las flotas a través de la misma API que se utiliza para el diagnóstico individual de los vehículos, lo que permite recopilar los patrones de averías, rastrear las versiones de software de toda la flota y detectar las necesidades de servicio proactivas antes de que se conviertan en averías.

Sibros SOVD: de la evaluación a la producción
‍Sibros ha construido un completo Oferta de SOVD - que abarca tanto las capacidades de los servidores integrados en el vehículo como las herramientas en la nube y administrativas, diseñado para los OEM que pasan de la evaluación arquitectónica a la implementación en producción. Nuestra oferta incluye:

• Cliente SOVD y plataforma de administración: control de acceso basado en funciones, flujos de trabajo de diagnóstico remoto y de proximidad y registro de auditoría estructurado a lo largo del ciclo de vida del vehículo.
• Integración de fabricación y posventa: la misma infraestructura SOVD admite la configuración de final de línea, las herramientas de servicio del concesionario y la supervisión remota de la flota sin implementaciones independientes.
• Ecosistema OTA y de registro: Diagnóstico de SOVD y administración de actualizaciones de software trabaje desde una infraestructura unificada junto con Sibros Registrador profundo y capacidades OTA.
• Servicios de consultoría SOVD: para los OEM que evalúan las decisiones de arquitectura, determinan los requisitos de los proveedores o planifican la adopción gradual de la SOVD en todos los programas de vehículos. ‍

‍El derecho de la UE a reparar el cumplimiento ha sido la base durante treinta años. Lo que está cambiando es el vehículo y, con él, las exigencias arquitectónicas para ofrecer ese cumplimiento a escala en todas las flotas definidas por software. Los OEM que crean una infraestructura de diagnóstico en torno al SOVD ahora no solo están resolviendo un problema de cumplimiento. Están sentando las bases de las operaciones de servicio para la era del SDV.