A medida que los vehículos se definen cada vez más por software, muchos fabricantes de equipos originales optan por soluciones de código abierto para sus pilas de software integradas.
El código abierto promete flexibilidad, creación rápida de prototipos y rentabilidad. Pero en el contexto de plataformas de vehículos definidos por software (SDV) siempre activas y críticas para la seguridad, estos beneficios percibidos a menudo conllevan riesgos importantes.
Lidera el desarrollo del mercado de automoción en Tuxera.
Si bien los SDV son la verdadera tendencia, la transición aún está incompleta, especialmente para los OEM tradicionales que navegan por ciclos de desarrollo heredados, toma de decisiones jerárquica y una cultura que prioriza evitar errores antes que moverse rápidamente.
La era SDV requiere un desempeño regulatorio sólido en condiciones extremas, resistencia durante una vida útil de 10 a 15 años y resiliencia ante la pérdida de energía y la diversidad de hardware. Éstas son precisamente las áreas en las que el software de código abierto, especialmente en capas básicas como los sistemas de archivos, puede quedarse corto.
Por qué el código abierto no siempre es apto para producción
No se puede negar el poder del código abierto para la innovación y la velocidad. Es utilizado por ingenieros de todo el mundo para realizar pruebas de concepto e iniciar el desarrollo. Pero la transición del prototipo a la producción, especialmente en vehículos con margen cero de falla, plantea preocupaciones críticas.
La mayoría de los sistemas de archivos integrados de código abierto no están diseñados para restricciones deterministas/críticas para la seguridad.
Aunque muchos sistemas de archivos de código abierto brindan compatibilidad con fallas, generalmente no garantizan tiempos de recuperación limitados, comportamiento determinista después de repetidas pérdidas repentinas de energía o pruebas de validación asociadas con requisitos de seguridad funcional.
Estos sistemas pueden presentar retrasos y tiempos de recuperación no deterministas bajo cargas de escritura pesadas o interrupciones repetidas de energía.
Peor aún, a menudo carecen de la documentación, el soporte o las rutas de certificación que los OEM necesitan para cumplir con estándares de seguridad como marcos de ciberseguridad como ISO 26262 o ISO/SAE 21434.
Las comunidades de código abierto, aunque vibrantes, no están sujetas a hojas de ruta de productos ni acuerdos de nivel de servicio (SLA). Esto puede provocar inconsistencias en el soporte, actualizaciones inesperadas o errores que permanecen sin resolver durante largos períodos de tiempo.
En el contexto de un sistema crítico para la seguridad, los retrasos ilimitados o el comportamiento de recuperación impredecible pueden violar el presupuesto de tiempo real y afectar la confiabilidad general del sistema.
Los esfuerzos colaborativos de código abierto como Eclipse SDV o S-Core muestran un gran potencial, pero esperar a que estas pilas maduren por completo puede ralentizar el progreso. El software de calidad comercial que ya está disponible hoy permite a los OEM comenzar la transición ahora, dejando espacio para la optimización posterior a través del código abierto.
Los costos ocultos del código abierto
A menudo se supone que el código abierto es “gratuito”, pero los costos de ingeniería para adaptarlo, calificarlo y mantenerlo son considerables.
Esta tarea debe ser interna o subcontratada a proveedores de servicios especializados. En ambos casos, los equipos pasan meses validando casos extremos, manteniendo parches personalizados y garantizando un rendimiento constante en todas las variantes de hardware.
El resultado no es un costo cero, sino un cambio de las tarifas de licencia a costos continuos de ingeniería o consultoría, lo que a menudo crea una dependencia de integradores específicos en lugar de proveedores de productos. Los equipos deben pasar meses probando casos extremos, creando parches personalizados y garantizando el rendimiento en diferentes configuraciones de hardware.
Esto consume un valioso tiempo de los desarrolladores, especialmente en empresas que no se especializan en software integrado.
Peor aún, no existe un SLA formal ni una hoja de ruta del producto. Esto significa que los errores pueden quedar sin resolver y los cambios en la comunidad de código abierto pueden introducir incompatibilidades o regresiones.
Para los sistemas de misión crítica en SDV, esto puede provocar fallas inesperadas en los peores momentos posibles, como durante las actualizaciones OTA, durante eventos de apagado o cuando los registros son más necesarios.
Por ejemplo, las primeras unidades Tesla Model S experimentaron desgaste de eMMC en parte debido a un registro intenso y márgenes de tolerancia de flash insuficientes, un recordatorio de que la arquitectura de almacenamiento, la estrategia de registro y la gestión de flash deben considerarse juntas.
Los equipos de ingeniería a menudo subestiman la carga de pruebas necesaria para llevar los componentes de código abierto a la madurez de producción.
Sin una calificación rigurosa y pruebas de ciclo de vida, pueden pasar errores sutiles en la gestión de la memoria, la sincronización o las operaciones de E/S, apenas meses o años después de la vida útil del vehículo, cuando las correcciones son costosas y más dañinas para la reputación.
Los nuevos participantes en el mercado, particularmente en China, están adoptando un enfoque de “cultura del lobo” con equipos pequeños y con gran propiedad que toman decisiones rápidas y dirigidas por expertos. En comparación, muchos OEM tradicionales se ven frenados por aprobaciones estratificadas y estructuras de toma de decisiones centralizadas, lo que resulta en una “brecha de agilidad”.
La ciberseguridad añade otra capa de responsabilidad que a menudo se subestima cuando se depende del código abierto. Las comunidades de código abierto no están obligadas a monitorear vulnerabilidades, proporcionar soluciones oportunas ni respaldar productos en un ciclo de vida definido.
En los vehículos de producción, esta responsabilidad no desaparece sino que pasa enteramente al OEM o a sus proveedores. Los equipos deben realizar un seguimiento continuo de las vulnerabilidades, evaluar la exposición, remediar los backports y proporcionar evidencia de que los riesgos se gestionan de acuerdo con regulaciones como ISO/SAE 21434 y UN R155.
Ya sea que este trabajo se realice internamente o se subcontrate a un tercero, representa un costo operativo continuo y una carga organizacional que debe tenerse en cuenta cuando se utilizan componentes de código abierto en sistemas relevantes para la seguridad y la protección.
Importancia de la previsibilidad
En ámbitos críticos para la seguridad, la previsibilidad y la coherencia son tan importantes como el rendimiento. Se espera que el vehículo funcione de manera confiable durante más de una década en condiciones ambientales fluctuantes.
Cumplir estos requisitos con soluciones de código abierto normalmente requiere una calificación adicional considerable, personalización y un esfuerzo de propiedad a largo plazo.
Por ejemplo, los sistemas de archivos de código abierto como ext4 o F2FS se diseñaron originalmente para servidores, computadoras de escritorio y Android, no para el típico entorno determinista y restringido de los sistemas de vehículos.
Estos sistemas de archivos pueden experimentar tiempos de montaje impredecibles, corrupción de datos después de un cierre incorrecto o degradación rápida bajo cargas de escritura elevadas.
Incluso los sistemas de asistencia al conductor más avanzados pueden volverse ineficaces cuando los sistemas arrancan lentamente, los datos se dañan o los registros desaparecen durante fallas. Debido a que es posible que las fallas no aparezcan durante la verificación sino solo después de años de uso en el campo, los OEM enfrentan riesgos financieros y de reputación.
Los OEM deben proporcionar sólidas credenciales de seguridad y ciberseguridad en toda la pila de software. Los componentes sin propiedad clara, documentación o soporte a largo plazo hacen que este proceso de cumplimiento sea significativamente más difícil.
¿Por qué Flash supera a los sistemas de archivos?
Los sistemas de archivos integrados comerciales, especialmente aquellos que admiten Flash, están diseñados teniendo en cuenta estas realidades. Optimizan los patrones de escritura, reducen la amplificación de la escritura y garantizan que el rendimiento y los tiempos de montaje permanezcan constantes incluso después de miles de apagones repentinos.
Por ejemplo, las pruebas del mundo real de sistemas de archivos compatibles con flash en un entorno automotriz han demostrado una integridad de datos del 100 % después de más de 15 000 ciclos de apagado brusco, un nivel de validación que generalmente es difícil de lograr sin un esfuerzo de ingeniería dedicado cuando se utilizan sistemas de archivos de código abierto de propósito general.
Los sistemas de archivos compatibles con Flash también minimizan la fragmentación y el desgaste, lo que ayuda a durar tanto como las unidades de memoria flash integradas. Esto permite a los OEM utilizar tecnología de memoria más rentable sin sacrificar la confiabilidad.
Además, los sistemas de archivos de calidad comercial suelen venir con soporte de ingeniería, opciones de mantenimiento a largo plazo y una hoja de ruta de validación alineada con los estándares de la industria. Esto permite a los OEM centrarse en el rendimiento del vehículo confiando en especialistas en almacenamiento para gestionar la integridad fundamental de la capa de datos.
Ninguna estrategia de software puede tener éxito sin un conocimiento profundo del hardware subyacente. Ignorar el comportamiento del flash, los requisitos de arranque o las condiciones de corte de energía puede provocar una falla del sistema, independientemente de qué pila se elija.
Control sin compromiso
Los OEM no tienen que abandonar por completo el código abierto. Tiene un papel importante a la hora de permitir la innovación y la flexibilidad de la plataforma. Pero debe utilizarse con cuidado y ampliarse cuando sea necesario.
Esto es especialmente cierto en el nivel integrado, donde la integridad, la seguridad y la resiliencia de los datos no pueden verse comprometidas. Aquí, los OEM más exitosos combinan la flexibilidad del código abierto en la capa de aplicación con la previsibilidad y funcionalidad de la infraestructura de software de nivel comercial subyacente.
Al utilizar sistemas de archivos integrados comerciales, donde sea necesario, los OEM pueden reducir el costo total de propiedad, simplificar la validación y acelerar el tiempo de comercialización.
De hecho, muchos OEM líderes están adoptando enfoques híbridos utilizando pilas de código abierto para servicios de alto nivel, al tiempo que bloquean los sistemas de almacenamiento, registro y OTA con sistemas de archivos certificables y diseñados específicamente. Este equilibrio permite una innovación rápida sin poner en peligro la confiabilidad de misión crítica.
Ingeniería para el futuro
Se espera que los SDV duren más de una década, admitan plataformas de software en evolución y proporcionen un rendimiento constante en situaciones exigentes. Depender únicamente del código abierto en las capas base de estas plataformas es arriesgado.
Los OEM que comprendan el costo del ciclo de vida completo del software integrado estarán mejor equipados para ofrecer vehículos seguros y preparados para el futuro. También se trata de la capacidad del desarrollador.
Cuando los equipos internos se liberan de la depuración de problemas del sistema de archivos de bajo nivel o de la lógica de recuperación de ingeniería inversa, pueden centrarse en desarrollar las características que realmente diferencian el automóvil, como la conectividad, la UX, la autonomía y el rendimiento.
En la era SDV, la pila de software es el vehículo y cuando falla, el costo es mucho mayor que un reinicio.
Hemos presentado el mejor software para pequeñas empresas.
Este artículo fue producido en parte Perspectiva profesional de TechRadarNuestro canal para mostrar las mejores y más brillantes mentes de la industria tecnológica actual.
Las opiniones expresadas aquí son las del autor y no necesariamente las de TechRadarPro o Future plc. Si está interesado en contribuir, obtenga más información aquí:
