¿Los vehículos ahora se definen por software? Arquitectura basada en dominios y transformación SDV

Tecnologías de Automóviles Eléctricos
Autor: Deniz Erkan
Creación: 14 Octubre 2026

La arquitectura que reduce más de un centenar de unidades de control a unos pocos controladores zonales hace que la identidad del coche ya no se fabrique con acero, sino con código.

Comparte esta página

Sí: el comportamiento, las características y el carácter de rendimiento del automóvil moderno ahora se definen prioritariamente mediante software. Esta transformación, denominada vehículo definido por software (SDV), traslada la arquitectura electrónica del vehículo desde pilas de ECU hasta controladores de dominio y zonales, separando el hardware del software y reconfigurando todo, desde el peso del cableado hasta las actualizaciones OTA.

Aspectos destacados

Los vehículos actuales 100 o más pueden contener unidades de control; las nuevas arquitecturas apuntan a reducir esta cifra hasta un 20% .
La arquitectura de dominio se organiza por función, la arquitectura zonal por ubicación física.
En la topología zonal se utilizan CAN XL (hasta 20 Mbps) y columnas vertebrales de gran ancho de banda como Ethernet gigabit.
La actualización OTA es una capacidad fundamental del SDV, posible gracias a la separación hardware-software.
La transición es gradual: la primera área es el dominio de carrocería (body); ADAS, tren motriz y chasis pueden permanecer más tiempo en la estructura actual.

¿Qué es Exactamente un Vehículo Definido por Software?

La definición es clara: un vehículo definido por software es aquel cuya funcionalidad y comportamiento se determinan prioritariamente mediante software en lugar de hardware. En el automóvil tradicional, una característica se definía mediante una pieza de hardware fabricada específicamente para esa función; en un SDV, el mismo hardware puede asumir diferentes funciones según el software que se ejecute sobre él. Incluso después de vender el vehículo, se pueden añadir nuevas características, calibrar el comportamiento y corregir errores de forma remota.

Las arquitecturas E/E actuales se componen de 100 o más unidades de control; las estructuras de nueva generación logran ahorros de hasta el 20% en el número de unidades de control y de hasta el 10% en materiales y hardware.
Bosch Mobility, evaluación de la arquitectura E/E

Las cifras que transmite esta frase resumen la escala de la transformación. El problema no es solo el número de unidades de control: cada ECU trae su propio cableado, su propia pila de software y su propia carga de validación. La visión del SDV es transformar esta estructura dispersa en un sistema en el que el software pueda gestionarla como una única capa coherente. Y para ello es necesario reconfigurar la arquitectura electrónica desde cero.

De las ECU a la Arquitectura de Dominio: Agrupación por Función

La época en la que cada pequeña función de un automóvil tenía su propia unidad de control electrónico (ECU) convirtió los mazos de cables en algo inmanejable. La arquitectura de dominio fue la primera respuesta sistemática a esto: organiza la electrónica del vehículo según grandes áreas funcionales como ADAS, infotainment, tren motriz (powertrain), electrónica de carrocería, chasis y seguridad. Cada dominio generalmente tiene su propio procesador, pila de software, interfaz de comunicación, sensores y actuadores, y es gestionado por un controlador de dominio.

Esta estructura proporcionó una simplificación considerable respecto al caos de las ECU. Sin embargo, a medida que creció el objetivo del SDV, se revelaron los límites de la arquitectura de dominio. En particular, los datos de sensores generados por las funciones autónomas llevaron el ancho de banda de las redes CAN clásicas a sus límites. Además, el hecho de que cada dominio llevara su propio recurso de procesamiento dejó el mazo de cables complejo y dificultó el escalado del software en todo el vehículo.

Arquitectura Zonal: La Organización Pasa de la Función a la Ubicación

La arquitectura zonal invierte la lógica: agrupa la electrónica no según la función, sino según su ubicación física en el vehículo. El vehículo se divide en zonas como delantera izquierda, delantera derecha, trasera izquierda, trasera derecha y cabina; en cada zona hay un controlador zonal que recoge los sensores, actuadores y la distribución de energía de esa zona y los comunica con plataformas de procesamiento centralizadas de alto rendimiento.

Característica	Arquitectura de dominio	Arquitectura zonal
Principio de organización	Por función (tren motriz, ADAS, carrocería...)	Por ubicación física (delantera izquierda, trasera derecha...)
Recursos de procesamiento	Procesamiento específico por dominio	Procesamiento centralizado/distribuido combinado
Cableado	Mazo de cables complejo y largo	Cableado y peso reducidos
Número de ECU	Gran cantidad de ECU	Pocos controladores zonales + computadora central
Flexibilidad de software	Difícil de escalar para los SDV	Alta flexibilidad de software

La ganancia es tangible y medible: el peso del mazo de cables disminuye, las conexiones punto a punto se reducen y el esfuerzo de validación de la arquitectura del vehículo y de los sistemas se simplifica. Más importante aún, los diseños de sensores y actuadores se independizan del nodo de procesamiento central; así, los ciclos de actualización de hardware y software se separan y un diseño de sensor puede utilizarse a lo largo de varias generaciones de vehículos.

¿Qué Hace un Controlador Zonal? Distribución de Tareas y Relación con el Hardware

Zonal mimaride kablolar kısaldıkça araç hafifler, sigortalar yerini yarı iletken anahtarlara bırakır ve güç artık bölge bölge yönetilir.

La clave de la arquitectura zonal es el controlador zonal, responsable de conectar numerosos actuadores y sensores con la ECU de procesamiento central. Este controlador no es solo una caja de recolección de datos; puede ejecutar bucles de control en tiempo real en su propio procesador, gestionar los dispositivos de su zona y envía al backbone tráfico filtrado y priorizado. Según una evaluación de ingeniería de fuente de Ti, el MCU del módulo zonal debe ofrecer alto rendimiento en tiempo real, amplia memoria, soporte de virtualización para diferentes niveles ASIL, comunicación de alta velocidad con el backbone y numerosas interfaces de bajo costo como CAN FD y LIN.

¿Cómo se descentraliza la distribución de energía?

En la arquitectura de dominio, la energía se distribuye desde cajas centrales de distribución de energía que contienen fusibles y relés. En la estructura zonal, la distribución se descentraliza: un único mazo de energía se tira de la batería a la zona, y el módulo zonal reparte la energía entre los módulos de esa región. Los cables de energía cortos significan directamente ahorro de peso y costo. Además, los fusibles son reemplazados por fusibles inteligentes basados en semiconductores; los interruptores del lado alto con característica I²t proporcionan menor variabilidad de fusibles y secciones de cable más optimizadas. La caja inteligente de distribución de energía, compuesta por el MCU, los interruptores del lado alto y los transceptores, se convierte en una unidad cuya configuración se realiza por software: la misma caja puede utilizarse en cada zona, adaptándose según la carga.

Desacoplamiento de las E/S físicas y lógicas

El módulo zonal reduce la complejidad del cableado al combinar en un solo punto las funciones lógicas de entrada/salida de múltiples ECU; las ubicaciones físicas de los sensores y actuadores se mantienen. Un paso más allá, los dispositivos periféricos se vuelven "inteligentes": el circuito local conserva la información de estado y ejecuta el diagnóstico de fallos. Protocolos simplificados como CAN FD Light pueden incluso eliminar la necesidad de una MCU separada en algunos nodos periféricos. Esta desacoplación, en la que el hardware permanece fijo y la tarea se define mediante software, es la columna vertebral de ingeniería del SDV.

Bus de datos en el vehículo zonal: ancho de banda, temporización y ciberseguridad

La fusión de sensores y las cargas de trabajo de AI obligan a construir la topología zonal sobre columnas vertebrales de alto ancho de banda: PCIe, hasta 20 Mbps CAN XL, que alcanza velocidades de datos de hasta 20 Mbps y mantiene la compatibilidad con CAN existente, y Ethernet gigabit. El verdadero desafío va más allá del ancho de banda: la temporización; los mensajes de control breves, los datos de sensores ADAS y el tráfico de infotainment tienen requisitos de latencia, jitter y sincronización muy diferentes entre sí. En términos aproximados: se aplican objetivos de latencia de nivel de milisegundos para el audio y de nivel de microsegundos para la transmisión de potencia y el control del chasis.

Para transportar estas distintas clases de tráfico en una única red, las soluciones destacadas son las basadas en Ethernet con Time-Sensitive Networking (TSN). Estándares como la sincronización de tiempo (IEEE 802.1AS), el conformado de tráfico sensible al tiempo (802.1Qbv), el tráfico express (802.3br), la preempción de tramas (802.1Qbu) y la redundancia (802.1CB) garantizan latencia determinística para los datos críticos. En cuanto a la seguridad funcional, el soporte de ISO 26262, las rutas de comunicación redundantes, la partición de seguridad y la detección de fallos; en cuanto a la ciberseguridad, la norma ISO/SAE 21434, las regulaciones UNECE y mecanismos de cifrado y autenticación de bajo nivel como MACsec son determinantes. Dado que la arquitectura zonal centraliza las redes, los métodos de ataque basados en Ethernet también se vuelven aplicables; el colapso del concepto de desacoplación de E-procesamiento ante una brecha de seguridad es un riesgo que debe evaluarse individualmente.

¿Cómo hace posible la desacoplación hardware-software la actualización OTA?

La actualización OTA es lo primero que viene a la mente en la mayoría de las discusiones sobre el SDV, pero no es una capacidad por sí sola; es un resultado arquitectónico. No se puede lograr una actualización ininterrumpida sin que el software se desacople de chips específicos mediante la capa de abstracción de hardware (HAL) y sin que las funciones del vehículo se dividan en servicios independientes, reutilizables y débilmente acoplados (arquitectura orientada a servicios, SOA). La desacoplación también abarca el aislamiento entre sí de los software con diferentes niveles de seguridad.

Su significado concreto es que la arquitectura zonal, con las actualizaciones OTA/FOTA y la conexión constante a la nube, transfiere el control del mantenimiento de software de alto nivel al fabricante, al tiempo que puede desplazar los bucles de control en tiempo real a los módulos zonales. En los vehículos eléctricos, ajustes finos como el refuerzo de alimentación de los módulos no utilizados también se facilitan con esta estructura. En última instancia, el software del vehículo eléctrico, más allá de ser un canal de actualización, es la capa de definición que determina las características del vehículo, sus sistemas de seguridad y su carácter de rendimiento. El vehículo empieza a parecerse a un centro de datos distribuido sobre ruedas; la cadena de valor se apoya en el software, la potencia de procesamiento y la arquitectura de sistemas.

¿Qué tan rápido será la transición y bastará solo con la arquitectura zonal?

La transición será gradual. El dominio de carrocería (body), por contener numerosas ECU distribuidas de actuadores y sensores, será el primer ámbito en pasar a la arquitectura zonal; la transición del ADAS, del tren motriz y del control del chasis, por su naturaleza crítica para la seguridad, puede llevar más tiempo. La evolución vivida desde 2017 en las capas MCAL, BSW y de aplicación demuestra que esto no es un proyecto técnico, sino un cambio de mentalidad a escala de toda la industria.

También hay que leerlo con equilibrio. La arquitectura zonal reorganiza físicamente el vehículo; el lado lógico y de software (SOA, HAL, ciberseguridad) debe resolverse por separado: con solo reorganizar los cables no se hace que un vehículo esté definido por software. Las previsiones del tamaño del mercado también cambian considerablemente según las definiciones de alcance; las distintas cifras sobre el mercado de la arquitectura E/E provienen de que el mercado se mide de forma distinta según lo que se cuenta (si solo las plataformas de procesamiento o toda la electrónica distribuida). Además, no debe olvidarse que los fabricantes de semiconductores y los proveedores de soluciones, como partes interesadas de la transición, tienen naturalmente un interés en esta transformación.

La conclusión es un claro equilibrio de ingeniería: la definición del vehículo por software solo es posible con la existencia simultánea de una nueva organización de hardware basada en controladores de dominio y zonales, capas de software desacopladas y una columna vertebral de datos determinista y segura. La actualización OTA es el fruto más visible de esta estructura integrada; la verdadera revolución está en que el hardware del vehículo transfiera su razón de ser al software.