descripción general
Ya sea que se trate de software de entretenimiento en el vehículo, software de asistencia al conductor o software de conducción autónoma, el soporte del software ha brindado grandes beneficios y conveniencia a la industria automotriz y a los usuarios. Sin embargo, así como las piezas mecánicas requieren limpieza, lubricación y reemplazo, el software requiere mantenimiento.
Los fabricantes de equipos originales (OEM) y los proveedores de nivel 1 pueden ser muy buenos para seleccionar piezas de automóviles que faciliten el mantenimiento regular, como cambiar el aceite del motor o la cadena de distribución, pero cuando se trata de software automotriz, es posible que no sepan por dónde empezar. A medida que las funciones del software se vuelven cada vez más complejas, si la arquitectura de software seleccionada ahora no es adecuada, es posible que se requieran altas tarifas de mantenimiento de software en los próximos años. Por lo tanto, los OEM y los proveedores de nivel 1 deben prestar atención al sistema de software y la arquitectura del software del vehículo, y tener en cuenta el mantenimiento regular que requiere el software, como los parches de vulnerabilidad de seguridad del software o las actualizaciones de software.
Este artículo describe cómo garantizar que los vehículos definidos por software estén equipados con soluciones de seguridad y protección de última generación, al tiempo que explica la importancia de usar software de código abierto, no solo para permitir que los OEM se centren en desarrollar aplicaciones de próxima generación. y satisfacer las necesidades de los consumidores, sino también para controlar los costos.
introducción
El software define la pista en forma de U de la industria automotriz
En los últimos años, el campo de la electrificación de vehículos y la conducción autónoma ha progresado rápidamente, y el principal desafío que enfrenta la industria automotriz ha pasado de las piezas mecánicas a los sistemas electrónicos y el software a bordo.
Anteriormente, los problemas que surgían durante la fase de diseño del automóvil solían estar relacionados con piezas mecánicas. Para garantizar un suministro adecuado de piezas mecánicas, los OEM a menudo celebran acuerdos a largo plazo con proveedores de nivel 1 y nivel 2 para mantener las piezas de repuesto disponibles durante al menos diez años después de que un vehículo deja de fabricarse. Cuando un automóvil necesita mantenimiento, el consumidor final al final de la cadena de valor paga indirectamente a los proveedores de Nivel 1 y Nivel 2 por las piezas hasta el final de la vida útil del vehículo.
A medida que los "automóviles definidos por software" se convierten gradualmente en la principal tendencia de desarrollo de la industria automotriz, los problemas que deben resolverse en el proceso de diseño de automóviles están relacionados principalmente con el software y están más estrechamente relacionados con los consumidores finales. Todos los propietarios de automóviles quieren disfrutar de las funciones más recientes mientras mantienen su automóvil seguro, pero pocos propietarios de automóviles están dispuestos a pagar por actualizaciones frecuentes de las funciones de seguridad.
Los cambios constantes del mercado obligan a la industria automotriz a ponerse al día y mantenerse al día con la tendencia de desarrollo. Esto se puede ver en la asombrosa expansión departamental de los departamentos de ingeniería de software de empresas como Renault o Volkswagen.
“En 2011, Renault y Volkswagen ni siquiera pudieron encontrar un ingeniero de software interno.” Hoy en día, estas dos conocidas compañías automotrices tienen cada una un gran equipo de ingenieros de software.
Al mismo tiempo, los proveedores se esfuerzan por formar sus propios departamentos de ingeniería de software. Tomemos como ejemplo el grupo alemán Continental, que produjo el primer neumático ranurado para automóvil del mundo, la compañía invertirá 31 millones de euros en el software de desarrollo interno de la compañía solo en 2021. La unidad de negocios principal de Continental Automotive Technology (dividida en las unidades de negocios de Tecnología de redes de vehículos (VNI) y Tecnología de seguridad y conducción autónoma (AMS)) tiene alrededor de 89 000 empleados, mientras que la unidad de negocios de llantas ahora tiene solo alrededor de 57 000 empleados. Continental no es una excepción, el conocido proveedor de sistemas de limpiaparabrisas y sistemas de iluminación Valeo Group y el conocido proveedor de sistemas de escape Marelli han tomado medidas similares para ampliar sus ventajas profesionales en el campo de las soluciones electrónicas y el software.
Aunque varias empresas han creado sus propios departamentos de software uno tras otro, hay que admitir que existe una gran brecha entre las expectativas del mercado y los costos altísimos a medida que aumenta la dificultad técnica.
Con base en las consideraciones anteriores, el desafío para los OEM será cómo implementar sistemas cada vez más complejos y controlar los costos recurrentes anuales de mantenimiento de los sistemas.
etapa inicial
Redefiniendo la arquitectura automotriz en la era de los datos
Del estado actual de desarrollo en la industria automotriz, está claro que en el futuro, la cantidad de datos que los automóviles deberán procesar alcanzará los diez megabytes por día. Los sensores de largo y corto alcance (como LiDAR y cámaras) en el automóvil recopilarán todo tipo de datos y la cantidad de sensores aumentará.
Además de la conducción automática que requiere procesamiento de datos y cálculos, hay sistemas de entretenimiento a bordo y sistemas ampliados de diagnóstico de fallas del vehículo dentro del automóvil (mejorando aún más el diagnóstico de fallas realizado por el sistema de diagnóstico automático a bordo OBD-II). Estos tres sistemas integrados en vehículos requieren un procesamiento de datos estable.
Entonces, ¿se pueden cargar todos estos datos en el servidor de la nube? Las probabilidades de esto son escasas o nulas. La realidad es que el sistema del vehículo procesará algunos de los datos localmente antes de cargar los datos principales o agregados a la nube.
" Para garantizar la capacidad de procesamiento de datos de decenas de petabytes por día, se debe integrar un motor informático en el sistema automotriz".
Como resultado, la cantidad de datos que deben cargarse aumenta considerablemente. Anteriormente, la unidad de control electrónico (ECU) de un vehículo a menudo se ubicaba cerca de los sensores y actuadores a los que estaba conectada y, por lo tanto, se extendía por el interior del automóvil. Hoy en día, los fabricantes de equipos originales (OEM) están recurriendo a la "Arquitectura eléctrica y electrónica automotriz" (EEA), que permite la consolidación e integración de unidades de control electrónico y utiliza Ethernet para interconectar las diversas unidades de control electrónico. Esta nueva arquitectura también incluirá de 1 a 5 computadoras de alto rendimiento (HPC) integradas.
A continuación, describimos las muchas implicaciones de pasar de la arquitectura heredada a la nueva arquitectura EEE, particularmente en términos de mantenimiento de hardware y software.
Fuente: Alianza Renault-Nissan
Complejidad creciente
complejidad del hardware
En el sector de la automoción, el diseño del hardware electrónico no se basa en una unidad central de procesamiento (CPU) y tarjetas de expansión PCIe instaladas en una placa base como un ordenador, sino en un "sistema en un chip" (SoC). Un sistema en chip es un circuito integrado que incluye todos o la mayoría de los componentes informáticos. De hecho, el sistema en un chip de un automóvil generalmente incluye varias CPU para el rendimiento informático y la seguridad en la conducción. Estas CPU incluyen unidades de procesamiento de señales digitales (DSP), unidades de procesamiento de gráficos (GPU), aceleradores de video, unidades de procesamiento de imágenes (IPU) e interfaces de bus CAN. En otras palabras, un SoC es un sistema muy complejo.
Fuente: Sistema en chip TDA de Texas Instruments
"El hardware ya es tan complejo que los fabricantes de automóviles necesitan una mayor destreza de software para superar los desafíos que se avecinan, porque el software es más complejo que el hardware".
Al observar el desarrollo del hardware automotriz, no es difícil encontrar que la complejidad de los SoC sigue aumentando y aún no ha alcanzado el pico de desarrollo. De hecho, incluso si el rendimiento del hardware del vehículo aún no está en el rango de Teraflop, ya hay algunos conjuntos de chips en el mercado que contienen 16 núcleos de CPU. Es previsible que los automóviles pronto introduzcan CPU de 80 núcleos o incluso CPU de varios núcleos con un mejor rendimiento informático.
Complejidad del software y microservicios
La industria automotriz está cambiando gradualmente de "automóviles definidos mecánicamente" a "automóviles definidos por software". Impulsado por esta tendencia, el ciclo de desarrollo de vehículos se ha remodelado, y los métodos de trabajo y las habilidades requeridas para el desarrollo de vehículos también han marcado el comienzo de un punto de inflexión integral. Estos cambios han creado desafíos adicionales para la industria. Para hacer frente a los desafíos, los fabricantes de automóviles han ampliado sus equipos profesionales y no han reparado en gastos en la contratación y formación de profesionales. Por ahora, el costo del talento sigue en aumento. Mientras reclutan talentos profesionales a gran escala, las empresas enfrentan otro desafío: cómo atraer talentos capaces que puedan sentar una base sólida de estrategia de software para la empresa. Otro enfoque es capacitar al personal actual de los OEM y sus proveedores, enseñándoles las nuevas habilidades necesarias para aprovechar la ola del cambio. Sin embargo, aprender habilidades es muy simple, pero remodelar la forma de pensar inherente de los empleados es muy difícil, especialmente cuando el desarrollo de este campo es muy maduro.
Al mismo tiempo, la demanda de los consumidores finales de funciones cada vez más complejas está aumentando gradualmente. Según datos publicados por McKinsey, “durante la última década, la complejidad promedio de un solo proyecto de software en la industria automotriz ha crecido en un 300 por ciento”. Los aviones F-35 o los Boeing 787 Dreamliner tienen muchos más. Se estima que para 2025, la cantidad de líneas de código que se ejecutan en los automóviles alcanzará los 200 millones, y para los sistemas de conducción autónomos L5 (totalmente autónomos), la cantidad de líneas de código puede incluso llegar a 1 mil millones.
Los siguientes son los niveles de automatización de conducción definidos por la Sociedad de Ingenieros Automotrices (SAE)
Sociedad de Ingenieros Automotrices (SAE) Clasificación de niveles de automatización de conducción
Además de esto, los algoritmos de inteligencia artificial (IA) o aprendizaje automático (ML) también aumentan en gran medida la complejidad del software integrado.
Fuente: Mc Kinsey
amenaza de seguridad cibernética
Según los informes, en 1983, Kevin Poulsen, el primer "hacker" en el campo del software e Internet, pirateó el predecesor de Internet, Arpanet. En ese entonces, los ladrones de autos necesitaban romper las ventanas y conectar los cables debajo del volante para robar el auto con éxito. Hoy, con la proliferación de software en los vehículos, la industria automotriz es aún más vulnerable al ciberdelito.
En 1983, la empresa alemana BOSCH inventó el bus CAN, que nació antes que la World Wide Web e Internet. Dado que el bus CAN es intrínsecamente incapaz de resistir los ataques de piratas informáticos, cuando está integrado en un automóvil moderno, el bus CAN brinda una oportunidad a los piratas informáticos. Así como el incidente de piratería de Kevin Paulson expuso las lagunas de Internet, el "hacker que secuestró remotamente un jeep" expuso muchos riesgos de seguridad de los sistemas de navegación de automóviles.
Un informe sobre seguridad automotriz global publicado en 2021 indicó que "ya existen 110 vulnerabilidades y exposiciones de seguridad comunes (CVE) en la industria automotriz, con 33 solo en 2020, en comparación con 24 en 2019". incluido en el CVE. El informe mencionado anteriormente también señaló que en agosto de 2020, se encontraron más de 300 vulnerabilidades en el software de 40 ECU desarrollado por 10 compañías diferentes. Las autoridades están estudiando detenidamente el impacto económico de las infracciones de seguridad y han introducido normas para protegerse de las amenazas a la seguridad.
La norma ISO/SAE 21434 "especifica los requisitos de ingeniería para la gestión de riesgos de ciberseguridad en todas las etapas de concepto, desarrollo de productos, producción, operación, mantenimiento y desmantelamiento de sistemas eléctricos y electrónicos (E/E) de vehículos de carretera (incluidos sus componentes e interfaces) ". Además, Naciones Unidas ha adoptado el Reglamento No. 155, "Reglamento Unificado Relativo a la Aprobación de Ciberseguridad y Sistemas de Gestión de Ciberseguridad para Vehículos". El reglamento esboza "regulaciones unificadas sobre la homologación de sistemas de gestión de ciberseguridad y ciberseguridad de vehículos".
Como resultado del Reglamento 155 de la ONU, los OEM y sus proveedores deben colaborar en el desarrollo de parches o correcciones de seguridad de software para prevenir y limitar los delitos cibernéticos durante el uso del vehículo. Cada entrega de software, ya sea que su propósito sea introducir mejoras, corregir errores o abordar problemas de seguridad, debe pasar por una evaluación de seguridad cibernética y un proceso de aprobación formal antes de enviarse al vehículo.
Para cumplir con este mandato y las expectativas de los clientes, los OEM y los proveedores de nivel 1 deben comprender las complejidades del software en el vehículo. En el mundo del software, es muy raro que solo exista un método para implementar una función o servicio. Los arquitectos de software deben tomar decisiones informadas, porque reducir la complejidad de administrar el software es la única forma de reducir los costos de mantenimiento del software a largo plazo.
"El desafío no es solo entregar un sistema de software, sino cómo mantenerlo a largo plazo. ¿Están los fabricantes de automóviles completamente preparados para esto?"
Pero los riesgos de seguridad cibernética no se limitan al software y, a veces, el hardware también puede exponer vulnerabilidades de seguridad : las vulnerabilidades de seguridad "Meltdown" y "Spectre" que se encuentran en muchos productos son una prueba sólida. Claramente, tales vulnerabilidades de seguridad se suman a la complejidad del diseño del sistema, ya que los arquitectos de software deben anticipar las posibles vulnerabilidades del hardware al considerar los riesgos del software.
Consideraciones de Seguridad
La complejidad del sistema no es el único desafío que enfrenta la industria automotriz. Acabamos de hablar de ciberseguridad. De hecho, la seguridad cibernética de los vehículos y la garantía de seguridad son dos temas separados, porque la seguridad de los sistemas a bordo no garantiza la seguridad de los pasajeros. Un automóvil es un dispositivo móvil que a menudo pesa más de una tonelada métrica: el automóvil no solo necesita proteger la seguridad de sus ocupantes, sino también el entorno en el que se conduce.
Si los pasajeros no usan cinturones de seguridad, incluso el automóvil con el factor de seguridad más alto no puede garantizar completamente la seguridad de los pasajeros. Aunque los dos conceptos son bastante diferentes, su relación es inseparable.
El "hacker secuestrando un incidente de jeep de forma remota" mencionado anteriormente demuestra este punto. Después de que los piratas informáticos destruyen la seguridad de la red del automóvil, también representa una amenaza para la seguridad personal de los pasajeros. Esto es especialmente importante a tener en cuenta, ya que cada vez se instalan más sistemas de seguridad activa en los automóviles para evitar los accidentes previos. Debido a que los sistemas de seguridad activos dependen del software para funcionar correctamente, son vulnerables a los ataques de ciberseguridad. Con este fin, la industria automotriz ha introducido el concepto de Seguridad Funcional (FuSa), que tiene como objetivo proporcionar un marco para los OEM y sus proveedores, permitiendo que el concepto de seguridad penetre en varios procesos y se convierta en el núcleo de conceptos, producción, entrega, mantenimiento y otros procesos centro de gravedad.
ISO 26262 "Seguridad funcional de vehículos de carretera" es una norma de seguridad internacional que restringe y especifica la seguridad funcional de los sistemas eléctricos y/o electrónicos instalados en vehículos de carretera producidos en serie. La norma ISO 26262 define la "seguridad funcional (FuSa)" automotriz como "la ausencia de riesgos irrazonables debido a fallas en los sistemas eléctricos y electrónicos ".
La seguridad funcional no es un problema del sistema de hardware puro, ni un problema del sistema de software puro, es un problema sistémico que involucra la operación y el proceso específico tanto del sistema de hardware como del sistema de software.
seguridad de hardware
En cuanto al sistema de hardware, solo se puede instalar en el automóvil después del sistema en chip (SoC) y la unidad de control electrónico (ECU) que cumplen con estrictos requisitos de seguridad. La norma ISO 26262 define el Nivel de Integridad de la Seguridad Automotriz (ASIL), y ordena los requisitos y procesos aplicables a cada nivel según la importancia del sistema que se está desarrollando actualmente.
Por ejemplo, si se va a lograr el nivel ASIL-B, la tasa de cobertura de fallas en un solo punto del sistema automotriz debe alcanzar más del 90 % , mientras que el nivel ASIL-D requiere que la tasa de cobertura de fallas en un solo punto alcance más del 90 %. del 99%. Al mismo tiempo, la norma ISO 26262 también da la definición de "falla de un solo punto" y estipula el método de cálculo de la "tasa de falla prevista". El estándar también define los términos clave requeridos y proporciona los métodos de evaluación correspondientes para ayudar a los lectores a comprender completamente la seguridad del sistema de los automóviles.
Predicción de las tasas de fallas de hardware
El estándar ISO 26262 describe varias técnicas para evaluar la tasa de falla de los componentes semiconductores, que pueden evaluar la incidencia de estrés eléctrico, falla del transistor o falla del paquete. Estos tipos de fallas y sus respectivas tasas de ocurrencia dependen principalmente del tipo de circuito, la tecnología de implementación y factores ambientales como humedad, temperatura, presión, interferencia electromagnética, etc.
El estándar ISO 26262 también distingue entre las tasas de falla esperadas y la confiabilidad esperada de los componentes. Además, la norma establece que, en casos especiales, un solo punto de falla puede causar un riesgo de seguridad para varios componentes individuales. El estándar aclara además que estos escenarios de riesgo pueden abordarse a través de un análisis de falla relevante (DFA) y la identificación de puntos de inicio de falla (DFI) relevantes.
Detección de fallas en la transmisión de datos
Para cumplir con los requisitos de seguridad anteriores, las empresas de semiconductores han propuesto una gran cantidad de mecanismos y soluciones de detección de hardware. Los más comunes incluyen:
• Código de paridad: agregando un "bit de paridad" en el flujo de comunicación en el chip para lograr el propósito de detectar la transmisión de datos. El bit de paridad es el código de detección de errores más simple y el método de detección es sencillo: si el bit de paridad se establece en 0, el número de códigos de transmisión es par; si el bit de paridad se establece en 1, el número de códigos de transmisión es impar. individuo Si el extremo receptor recibe un número par de códigos y conoce la posición del bit de paridad, puede eliminarlo y encontrar el número transmitido. De esta manera, si el receptor obtiene un número impar de codificaciones, significa que se produjeron daños en los datos durante la transmisión. Si bien los códigos de paridad pueden detectar errores de transmisión, no pueden recuperar la información correcta, por lo que es necesario volver a enviar la información.
• La verificación por redundancia cíclica (CRC) es otra herramienta utilizada para detectar fallas en la transmisión de datos. La comprobación de redundancia cíclica utiliza el principio de división y resto para la detección de errores. Agrega un resto de un tamaño específico a los datos y luego verifica en el extremo receptor para ver si los datos han cambiado. Después de recibir el mensaje, el extremo receptor realiza una división polinomial en la parte que contiene el CRC: el CRC recibido con el mensaje debe ser consistente con el CRC calculado en el mensaje recibido, de lo contrario significa que hay un error de transmisión.
• Los códigos de corrección de errores (ECC) son una solución mejorada para la verificación de paridad porque incluyen una forma de recuperar la información original incluso si el hardware está dañado . Hay muchos tipos de códigos de corrección de errores, e incluso los estándares inalámbricos 5G incluyen nuevos mecanismos de códigos de corrección de errores.
Aunque el objetivo es detectar problemas de transmisión y recuperar la información original transmitida, estas técnicas de inspección requieren una codificación adicional para transmitir con la información. Esto tiene un impacto directo en el ancho de banda real de la red, que disminuye con el tiempo: si se usa 1 bit de cada byte para la detección de errores y 7 bits para los datos reales, el ancho de banda se reduce en 1/8, o 12,5 %.
Sin embargo, hay ocasiones en las que se producen interrupciones en la transmisión. Las transferencias interrumpidas pueden deberse a interrupciones físicas de la comunicación o, más a menudo, a que un proceso se ha detenido durante demasiado tiempo. Por lo tanto, utilizamos el "tiempo de espera de comunicación" para detectar la cantidad de pérdida de comunicación.
Detectar errores de tiempo de ejecución
Como se mencionó anteriormente, el estándar ISO 26262 cubre problemas que pueden ocurrir a nivel de transistor. Las empresas de semiconductores de hoy en día suelen utilizar herramientas de inspección de hardware para verificar el funcionamiento correcto. Pero las empresas de semiconductores también usan controladores de seguridad para recopilar información de fallas en todo el sistema, analizarla y pasar la información de fallas a la arquitectura de alto nivel del sistema de software.
Otro enfoque de bajo costo para aumentar el cumplimiento de la seguridad que ha surgido recientemente es la "autoevaluación integrada" (BIST). Este método nació porque los fabricantes de semiconductores necesitaban una forma de identificar los defectos de fabricación en los productos y mejorar el proceso de inspección de calidad. Al aprovechar al máximo estas funciones mejoradas de prueba en el sistema y usarlas mientras el procesador funciona normalmente, es posible identificar de manera efectiva las fallas en tiempo de ejecución.
Mecanismo de detección de redundancia
Para cumplir con los requisitos de seguridad, los fabricantes suelen adoptar el método de duplicar el sistema. Bajo los mismos requisitos de seguridad, si los dos sistemas se implementan por separado, la seguridad incluso aumentará.
La redundancia modular dual (DMR) y la redundancia modular triple (TMR) se refieren a duplicar o triplicar un sistema o un elemento de un sistema, proporcionar la misma señal de entrada a estos sistemas o módulos y comparar el método general de las señales de salida.
El principio de redundancia de módulo triple es el voto de la mayoría , y el resultado de salida de la mayoría es el resultado final: si dos de los tres sistemas tienen el mismo resultado de salida, este resultado es el resultado de salida correcto. En el caso de módulos duales, si los resultados de salida son inconsistentes, hay un error en el sistema.
La redundancia modular dual (DMR) y la redundancia modular triple (TMR) se utilizan en diferentes niveles de hardware, incluido el nivel de módulo, el nivel de chip y, en algunos casos, incluso el nivel de sistema.
Algunos SoC admiten la funcionalidad lockstep de doble núcleo . El mecanismo de hardware seguro se implementa a través de la redundancia de módulo dual (DMR), proporcionando software idéntico a dos núcleos de CPU idénticos y compartiendo el mismo ciclo de reloj. En cada ciclo de reloj, habrá un comparador lógico para verificar si los resultados de salida de los dos núcleos son consistentes y, si lo son, se informará un error.
Sin embargo, las CPU de alto rendimiento suelen tener una estructura más compleja y un determinismo más débil , por lo que el efecto real del método lockstep de doble núcleo puede no ser satisfactorio. Como resultado, han surgido algunas alternativas más complejas al bloqueo de doble núcleo, como el uso de "islas de seguridad" para realizar tareas de inspección en núcleos de CPU que mantienen una alta integridad de seguridad. Además, otro método de optimización del método lockstep de doble núcleo es "CPU core-lockstep" .
Así como las técnicas de detección de fallas antes mencionadas reducen el ancho de banda real de la comunicación, las técnicas de redundancia de CPU también consumen su propia potencia de procesamiento disponible. El método lockstep de doble núcleo o su método de extensión reducirá la potencia informática efectiva del sistema en el chip en un 50 % (la reducción de la potencia informática es ligeramente menor cuando se utiliza el método Split-Lock). Además, esta tecnología también conduce a mayores costos de desarrollo y costos de hardware porque se debe agregar redundancia.
seguridad del software
Las empresas de semiconductores a menudo requieren el uso de software especializado para garantizar el cumplimiento de la seguridad del hardware. En otras palabras, algunos sistemas basados en la nube requieren que el software implemente funciones específicas para aprovechar todo su potencial de seguridad, como la "autoprueba integrada (BIST)" mencionada en el capítulo de seguridad del hardware.
La plataforma de procesamiento automotriz S32 lanzada por NXP Semiconductors es una de las series de SoC automotriz más populares.
La compañía cree: "La arquitectura del software de seguridad S32 está involucrada en el trabajo durante la puesta en marcha, la operación y la recuperación de fallas".
Fuente: Arquitectura de software seguro NXP S32
No todo el software cumple con los requisitos de seguridad y no todo el software cumple con los requisitos de seguridad. Además, las tarifas de certificación de software también son caras. Por ello, con la integración paulatina de las unidades de control electrónico, se ha ido convirtiendo en una tendencia de la industria incluir diferentes niveles críticos de seguridad en un mismo SoC o unidad de control electrónico. Esta tendencia puede optimizar el control de costes y el rendimiento. Las unidades de control electrónico para sistemas de información y entretenimiento en vehículos son un ejemplo interesante.
Ahora es una práctica común en la industria combinar la consola central, el grupo de instrumentos, la pantalla de visualización frontal y las funciones de monitoreo de pasajeros en la misma unidad de control electrónico. Cuando se combinan, algunos elementos de visualización y elementos de sonido tienen mayores requisitos de seguridad que otros. La siguiente figura presenta el software principal que permite la integración de la ECU.
La principal diferencia entre las diferentes opciones es dónde se manejan las características de cumplimiento de seguridad.
• En la opción a, la separación del hardware es administrada por un hipervisor compatible con ASIL/seguridad.
• En la opción b, la separación de hardware se logra mediante el uso de 2 tipos de núcleos en el SoC. Por ejemplo, utilice uno o varios núcleos ARM Cortex-M para las necesidades de comunicación y seguridad del vehículo, y otro conjunto de núcleos de propósito general para funciones informáticas de alta gama.
• En la opción c, la separación de hardware no se realiza en el SoC, sino a nivel de hardware, utilizando dos SoC dedicados diferentes (uno para seguridad y otro para uso general) para lograr la separación de hardware.
Dicha arquitectura no solo aumenta la dificultad del desarrollo de software, sino que también presenta desafíos complejos de integración y depuración.
Se pueden utilizar métodos similares u otros métodos nuevos, como la introducción de la plataforma adaptativa AUTOSAR en el sistema. Estas son opciones de optimización que generalmente se basan en el SoC específico, y las capacidades específicas a menudo vienen con una complejidad adicional.
La complejidad del hardware seguirá creciendo para expandir el poder de cómputo de los SoC. Además de esto, los requisitos de seguridad aumentan la complejidad del sistema. La integración de la potencia informática y la seguridad en un solo sistema en chip será cada vez más compleja. Las empresas de semiconductores tendrán que aumentar el costo de los SoC para cumplir con los requisitos de seguridad correspondientes.
Asimismo, cuanto más complejo es el sistema, más difícil y costoso es autenticar. Es menos probable que la curva de crecimiento de los precios sea lineal y más probable que sea exponencial.
Pero garantizar el cumplimiento de la seguridad requiere inversiones adicionales en software. El estándar ISO 26262 requiere que el proceso de desarrollo del sistema siga un modelo de ciclo de vida en forma de V. Esto significa que los desarrolladores de software primero capturan las necesidades del cliente y luego definen la funcionalidad en función de esas necesidades. Los desarrolladores de software necesitan descomponer las funciones en sistemas de hardware y sistemas de software; los sistemas de software se subdividen en funciones. Además, es necesario definir, crear o volver a habilitar un proceso de prueba específico y luego realizar pruebas a nivel funcional, nivel de software, nivel de hardware y nivel de sistema en turno. Este enfoque de desarrollo de sistemas viene con un conjunto de procesos para ejecutar el software, incluida la revisión del código, la detección de desviaciones de los requisitos, la ejecución de pruebas, la medición de la cobertura de las pruebas y más.
"Las empresas de automóviles deben estar preparadas para incurrir en altos costos de mantenimiento de software".
Ahora, asumimos que los 100 millones de líneas de código existentes incrustadas en el automóvil actual cumplen todas las normas de seguridad (es posible que no sea el caso), de acuerdo con el modelo de ciclo de vida en forma de V definido por la norma ISO 26262, ¿cuánto tiempo durará ¿Nos llevará escribir 100 millones de líneas de código nuevas para llevar el total a 200 millones de líneas de código para 2025? ¿Cuántos ingenieros de software necesitamos para trabajar juntos?
Con 100 millones de líneas de código ahora implementadas, los OEM y los proveedores de nivel 1 deberían poder estimar aproximadamente el costo de agregar 100 millones de líneas de código bajo COCOMO o cualquier otro método. Pero esto es solo un costo estimado, cualquier cambio resultará en un cambio en el costo.
Entonces, para un automóvil con un sistema de conducción autónomo de nivel 5, ¿cuál es la carga de trabajo estimada de mil millones de líneas de código? Del mismo modo, ¿cuánto tiempo llevaría escribir especificaciones, implementar y probar software de esta magnitud si la mayor parte del contenido no pudiera reutilizarse?
El uso de código abierto es la única forma sostenible, detallada en la sección "Recomendaciones".
Aislar interferencia
Como se mencionó anteriormente, la integración de ECU de hardware es una tendencia importante. En la mayoría de los casos, esto significa combinar componentes críticos para la seguridad y componentes de procesamiento comunes en la misma unidad de control electrónico. Pero el sistema de seguridad debe tener la función "libre de distracciones". En otras palabras, si un sistema combina componentes críticos y no críticos para la seguridad (p. ej., dentro de la misma ECU), se debe demostrar que el entorno no crítico para la seguridad no puede interferir con las partes seguras del sistema, lo que causa problemas de seguridad. problemas.
Por ejemplo, asegúrese de que el programador no pueda dañarse, que un proceso no pueda terminar el sistema y que el montón de memoria sea resistente a los desbordamientos de búfer.
Después de revisar los incidentes de CVE, descubrimos que la mayoría de los incidentes de CVE se basan en puertas traseras, desbordamientos de memoria o comportamiento accidental/involuntario de los componentes de software (o hardware): por lo tanto, el enfoque de CVE es resaltar las amenazas de seguridad. Descubrimos nuevas vulnerabilidades CVE todos los días. Incluso si se diseña de acuerdo con ISO 26262 (estándar de "Seguridad funcional de vehículos de carretera") y sigue estrictamente el proceso Automotive Spice (Estándar de medición de capacidad y mejora de procesos de software), un sistema operativo en tiempo real (RTOS) con nivel ASIL D tendrá seguridad vulnerabilidades.
Pero en cualquier caso, la falta de protección significa falta de seguridad, este es un hecho en el que todos están de acuerdo.
La norma ISO 26262 no es suficiente para garantizar la seguridad de los automóviles. De acuerdo con los requisitos técnicos avanzados existentes, deberíamos incorporar la seguridad de las funciones esperadas (SOTIF) en el análisis del sistema de acuerdo con la norma ISO/PAS 21448 ("Seguridad de las funciones esperadas de los vehículos de carretera"). Este es otro problema difícil que necesita ser resuelto con urgencia.
"Cuanto más complejo es un sistema, más difícil es evaluar y demostrar su cumplimiento de seguridad".
sugerencia
Encuentre formas efectivas de resolver problemas difíciles y cuestiones de seguridad.
En esta etapa, podemos resolver los siguientes problemas:
• Procesar más datos del vehículo, más rápido
• Desafíos de la creciente complejidad del hardware
• Problema de expansión del software
• Desafíos adicionales que plantean las ciberamenazas
• Necesidades de mantenimiento a largo plazo del software
• Requisitos de seguridad separados o comunes para hardware y software
A continuación, exploraremos casos de mejores prácticas en aviónica, desarrollo de software de código abierto y otras industrias para enfrentar estos desafíos.
limitar la contaminación segura
Hemos demostrado que el uso de código abierto es la única forma sostenible de crecer. Pero eso no significa que debamos esperar modificar el software de código abierto para satisfacer las necesidades de nuestros automóviles. Por ejemplo, la contaminación de seguridad es cuando más y más partes del sistema comienzan a requerir protección de seguridad. Si nos enfocamos en reducir el tiempo de comercialización en lugar de mejorar la seguridad del usuario final, terminamos ignorando la investigación arquitectónica correspondiente. La contaminación de la seguridad limita en gran medida la usabilidad del software de código abierto,
Porque la gran mayoría del software de código abierto no cumple ni puede cumplir los requisitos de seguridad. Para los OEM, imponer altos requisitos de cumplimiento de seguridad en varias partes del sistema, como exigir que cada componente sea ASIL D, parece más fácil que actualizar un sistema ASIL B a ASIL D. Sin embargo, hacerlo da como resultado una mayor complejidad y costo, al mismo tiempo que reduce la funcionalidad. Por ejemplo, un sistema operativo compatible con la seguridad admite menos funciones que un sistema operativo de uso más general. Además, cada vez que se realiza un cambio (como un parche CVE), se requiere una evaluación de seguridad, por lo que tomar medidas de seguridad y cumplimiento de protección al mismo tiempo conducirá a otra escalada de complejidad.
Por lo tanto, una vez que se implementa un sistema de este tipo en un vehículo, los costos operativos pueden acumularse rápidamente. Y una vez configurada, la arquitectura del sistema puede ser difícil de cambiar. Para los OEM, la única forma de evitar explosiones de costos es controlar racionalmente los márgenes de seguridad del sistema.
Recientemente, con la integración de la conducción autónoma y las unidades de control electrónico, los requisitos de seguridad han afectado a muchos componentes del vehículo, como los sistemas de infoentretenimiento del vehículo.
Las empresas automotrices pueden aprender de la experiencia de otras industrias cuando se trata de evitar la contaminación de seguridad. Por ejemplo, la arquitectura del sistema de aviónica define claramente la distinción entre la seguridad del sistema y los componentes no relacionados con la seguridad. Por ejemplo, el sistema de información y entretenimiento a bordo no interferirá con los componentes de seguridad de la aeronave. Algunos componentes de seguridad también pueden controlar componentes que no son de seguridad, como el anuncio del capitán que puede controlar el sistema de infoentretenimiento a bordo.
Nuestra propuesta para futuras arquitecturas eléctricas y electrónicas es considerar admitir dos tipos de canales de comunicación (a nivel de hardware de la ECU): canales seguros y canales generales. Los componentes genéricos del sistema pueden interactuar con componentes compatibles con la seguridad (acceder a sensores o actuadores y leer su estado) y, cuando estén disponibles, responder mediante sistemas de mensajería de tipo nativo de la nube (componentes seguros): la seguridad es lo primero. Se debe prohibir que los componentes genéricos establezcan parámetros o controlen componentes seguros.
No se recomienda reconstruir los componentes de seguridad y no relacionados con la ECU. Se propone que dos tipos diferentes de System-on-Chip (SoC)/Unidad central de procesamiento (CPU) sean responsables de la seguridad y las características comunes en la misma ECU (como se muestra en la separación de hardware de la opción c antes mencionada). De esta forma, no es necesario conectar todos los SoC/CPU de computación de alto rendimiento o de computación perimetral a canales de comunicación seguros, lo que reduce la complejidad del diseño de hardware y software.
McKinsey espera que el hardware y el software se adquieran por separado, haciendo "la adquisición más competitiva, escalando más fácilmente y permitiendo plataformas estandarizadas para el software de aplicación mientras se mantiene la competencia en el lado del hardware".
Por esta razón, los próximos pasos para los OEM y los proveedores de nivel 1 son adquirir componentes de seguridad y uso general de hardware y software, respectivamente.
Los requisitos de seguridad del hardware crean barreras de entrada que impiden la competencia a mayor escala. Eliminar el requisito de seguridad para algunos módulos de hardware (como HPC) en la arquitectura del sistema conducirá a una repetición de la competencia y reducirá los costos de la lista de materiales (BOM).
Por ejemplo, las empresas de semiconductores podrían aprovechar esta oportunidad para ofrecer CPU con calificación AEC-Q100 a la industria automotriz sin certificación ASIL. Podemos esperar ver CPU más potentes con múltiples núcleos sin un gran aumento de precio en comparación con las PC/servidores.
Hoy en día, ¿cuántos prototipos creados en el sistema operativo Linux tienen que ser rediseñados, portados y adaptados para finalmente ejecutarse en un "sistema operativo seguro en tiempo real"? Imagínese si se desarrollara una prueba de concepto (POC) que pudiera ejecutarse inmediatamente en el hardware de destino, distinguir los componentes compatibles con la seguridad de los genéricos reduciría en gran medida la necesidad de soluciones de virtualización compatibles con la seguridad y aumentaría el uso de sistemas operativos personalizados ( ya sea basado en Linux o no) que cumplan con los estándares de seguridad. En ese momento, los OEM podrán utilizar el sistema operativo Linux y el software de código abierto. Al igual que con el uso de un sistema operativo seguro, obtener los requisitos de seguridad en un dominio limitado también mejorará el uso de los recursos: reducirá la cantidad de ingenieros expertos en seguridad necesarios. Habrá menos presión para reclutar.
Adoptar código abierto y sistema operativo Linux
¿Facebook/Meta, Airbnb, Netflix (y muchos otros) tienen éxito porque intentaron reemplazar Windows o Linux de Microsoft con su propio sistema operativo, o porque usaron código abierto y se enfocaron en el servicio al cliente? Sin duda, están muy familiarizados con su pila de software, pero no desperdicien energía reinventando lo que ya existe en la comunidad de código abierto. Si encuentran un error o desarrollan una versión mejorada de un módulo de código abierto, lo lanzan a la comunidad, lo que hace que la funcionalidad del módulo sea ascendente, beneficiando a más personas e involucrando a toda la comunidad en el proceso de mantenimiento. Así es como el código abierto mejora y evoluciona.
Recomendamos que los OEM y los proveedores de nivel 1 trabajen con los proveedores comerciales de Linux para brindar soporte a largo plazo y mantenimiento de seguridad del kernel de Linux y paquetes de software de código abierto extendidos. Esto les permite concentrarse en sus soluciones de software e impulsar la diferenciación a través del desarrollo de aplicaciones y servicios para el cliente.
Al mismo tiempo, dado que los vehículos están conectados a la nube, los OEM deben considerar trabajar con distribuidores de Linux para brindar soporte para servidores en la nube, escritorios de ingeniería y software Linux en el vehículo. Esto permite que los OEM reciban niveles más altos de soporte a un costo menor, al tiempo que reducen la carga de administrar múltiples proveedores, múltiples contratos y múltiples entornos de desarrollo.
Desarrollar aplicaciones automotrices de última generación
La expansión de las bases de código de software no es exclusiva de la industria automotriz. Para mantener un equilibrio entre la complejidad del software y una funcionalidad cada vez más diversa, la industria de TI en su conjunto se está alejando de los enfoques estáticos y monolíticos para adoptar microservicios y diseño de software de alta disponibilidad.
Caso de microservicio
La arquitectura de aplicaciones basada en microservicios permite el desarrollo de una sola aplicación como un conjunto de servicios pequeños, estrechamente definidos y de implementación independiente. Cada microservicio se ejecuta en su propio proceso independiente y se comunica con un mecanismo ligero, generalmente una interfaz de programación de aplicaciones HTTP. Estos servicios se centrarán en funciones comerciales específicas y se implementarán de forma independiente utilizando mecanismos totalmente automatizados.
Como analogía, podemos usar una casa antigua para comprender la transición a los microservicios. La transición es como derribar la pared entre la cocina y la sala de esta casa, quitando los gabinetes hechos a mano y reemplazándolos con sistemas modulares de grandes marcas, y agregando electrodomésticos de cocina y televisores que se comunican a través de la LAN doméstica e Internet. Nada ha cambiado en el exterior de la casa, y el interior todavía tiene una cocina y una sala de estar, pero estos son más modernos, más cómodos y tienen una variedad de características nuevas.
En este proceso de refactorización de una aplicación heredada, otras partes (es decir, la comunidad) mantienen partes del código heredado y, por lo tanto, generalmente se reemplazan por código fuente abierto, lo que significa que quienes usan el código no tienen que asumir todos los costos de mantenimiento. . Además, el código fuente abierto tiene un mayor uso por parte de los usuarios y cubre más casos que el código heredado al que reemplaza: en otras palabras, también es más confiable.
La transición al modelo arquitectónico de microservicios debe apuntar a reemplazar el 70 % (o más) del software heredado con software de código abierto equivalente. De esta manera, los esfuerzos pueden enfocarse en el 30% restante (o menos) del software que marcará la diferencia clave y, por lo tanto, creará valor agregado para la empresa.
Cómo lidiar con puntos únicos de falla
El software de alta disponibilidad está diseñado para identificar puntos únicos de falla (SPOF). SPOF es una parte del sistema, si deja de funcionar, hará que todo el sistema deje de funcionar. Por ejemplo, un avión monomotor no puede despegar si su motor falla, mientras que un avión comercial bimotor puede despegar si uno de sus motores falla durante el despegue. El uso de una aplicación con un diseño de microservicio facilita la identificación de los SPOF y trata de eliminarlos. Hay varias formas de eliminar SPOF: duplicación, balanceo de carga, replicación, autorreparación y más. El propósito de este artículo no es entrar en detalles, pero el punto es que la industria de TI utiliza diseños de alta disponibilidad para garantizar la tolerancia a fallas del servidor y un tiempo de actividad del 99,9 %. Además, puede realizar el mantenimiento, las actualizaciones y los experimentos del servidor inmediatamente sin apagarse. ¿No se supone que el vehículo es tolerante a fallas y funciona y tiene un alto tiempo de actividad la mayor parte del tiempo? ¿No deberíamos poder mejorar sin estacionamiento? Cuando los trabajadores de la industria de TI establecen estos objetivos, están llenos de espíritu de lucha. Pero la realización de estos objetivos es muy beneficiosa y debe aplicarse a la industria automotriz.
Resulta que Internet es estable y funciona las 24 horas del día, los 7 días de la semana. El software de alta disponibilidad y las arquitecturas de aplicaciones basadas en microservicios son los pilares clave para que esto suceda. El software que se ejecuta en el centro de datos es en gran medida independiente del hardware. Se puede implementar fácilmente en muchos lugares del mundo y también se puede alojar en nubes públicas como Amazon Web Services, Google Cloud Platform, Microsoft Azure, etc., o incluso en las instalaciones, sin tener que volver a escribir aplicaciones/servicios al cambiar. Hospedadores. Este es solo uno de sus puntos fuertes.
Las aplicaciones de microservicios son software en contenedores: es decir, se ejecutan dentro de una "caja" (un contenedor) que contiene lo que necesitan para ejecutarse. El software en contenedores tiene varias ventajas:
• Si falla un microservicio, solo se ve afectada la parte del entorno o el contenedor en el que se ejecuta y no se cae todo el sistema.
• Para admitir la ejecución de microservicios, se configura un entorno de sistema operativo y hardware virtual en el contenedor.
Esto crea una abstracción de hardware que hace que los microservicios sean independientes del hardware físico real.
Los sitios web, los juegos web o las aplicaciones web son independientes del hardware: pueden ejecutarse en muchos dispositivos con características de hardware como tamaño de pantalla, orientación, procesador de gráficos, cámara web.
Creemos que en el software integrado de misión crítica, el paquete Snap puede lograr la abstracción de hardware requerida (haciendo que la aplicación sea independiente del hardware), mientras mejora la estabilidad del sistema en general (la falla de una sola función en la aplicación no pondrá en peligro la todo el sistema).
Un Snap es una integración en paquete de una aplicación y todas sus dependencias que se ejecutará sin modificaciones en todas las principales distribuciones de Linux, e incluso distribuciones personalizadas que integran el soporte de Snap. Millones de personas ya utilizan miles de Snaps en 41 distribuciones de Linux. Contiene tutoriales, materiales de soporte, herramientas para crear e implementar nuevas aplicaciones o parches. También es probable que los OEM y los proveedores de nivel 1 creen Snaps y los implementen en ECU antiguas y nuevas que ejecutan Linux. Todos pueden usar estos Snaps en sus computadoras Linux (y dispositivos IoT) de forma gratuita, sin pagar ni desbloquearlos.
Una de las mejores cosas de Snap son las operaciones y la gestión de aplicaciones. De hecho, no solo garantizan la seguridad inmediata, sino que también aprovechan al máximo la portabilidad del hardware sin comprometer la integridad y la confiabilidad del sistema. Snap puede ser implementado fácilmente por cualquier OEM y no necesita ser portado a ningún dispositivo para ejecutarse.
Ubuntu Core, una versión en contenedor totalmente basada en instantáneas. Ubuntu Core es seguro por diseño: el aislamiento de seguridad se proporciona a través de AppArmor y Secure Computing Mode. También ofrece compatibilidad con TPM, arranque seguro y cifrado de disco completo.
Con el enfoque holístico de seguridad de Snap, los sistemas integrados ofrecen los beneficios de seguridad, inmutabilidad, modularidad y componibilidad. El software se puede actualizar por aire a través de delta, que se revierte automáticamente si algo sale mal (desde el sistema operativo Linux a cualquier aplicación individual).
La transición de la industria automotriz de bus CAN a Ethernet tomó más de 30 años (y solo parcialmente). La construcción de sistemas resistentes a fallas es imprescindible en la industria automotriz, y hay muchas maneras de lograrlo. Además, el mantenimiento de la ciberseguridad del sistema debe diseñarse para que sea rentable. Con la implementación de las normas de ciberseguridad ISO/SAE 21434 ("Ingeniería de ciberseguridad de vehículos de carretera"), ahora es el momento apropiado para reconsiderar la arquitectura de hardware y software automotriz desde las perspectivas de seguridad, medidas de protección y escalabilidad.
Centrada en el cliente
Los sistemas de infoentretenimiento del automóvil han quedado obsoletos durante más de 4 años en comparación con el diseño y la funcionalidad de los teléfonos móviles.
Lograr la misma funcionalidad que un teléfono móvil es solo un hito, no nuestro objetivo. Los vehículos pueden desarrollar funciones mucho más allá de los teléfonos móviles (como la conducción autónoma).
Las actualizaciones inalámbricas de firmware o software (FOTA/SOTA) son un primer paso, pero no son innovadoras: se han explorado en áreas relacionadas para teléfonos y computadoras. La pregunta es qué beneficio crea la actualización para el usuario final. Si se mantiene la función o apariencia de hace 2 años, es probable que decepcione a los clientes.
Los OEM y los proveedores de nivel 1 deben aumentar la velocidad de desarrollo y entrega de software para seguir el ritmo de las innovaciones en otras industrias, como la de los teléfonos móviles. Además, los automóviles son bienes de consumo de última generación. Tienen el potencial de estar a la altura de expectativas más altas que simplemente estar a la par con otras industrias.
Para los OEM, los costos de desarrollo de software deberían ser más bajos y el tiempo de comercialización debería ser más rápido. Todo esto será posible si las partes principales del software (la parte que complacerá al cliente final y la parte que alberga servicios de terceros) pueden ejecutarse en un entorno no seguro. Al mismo tiempo, la adquisición de hardware debe ser más sencilla (al menos para el hardware que se ejecuta en entornos no seguros) y reducir el uso de SoC específicos para automóviles.
De esta forma, los OEM pueden ofrecer nuevos servicios a sus clientes y al ecosistema de terceros. Gran parte del éxito del teléfono inteligente se debe al ecosistema de aplicaciones y servicios de terceros que ofrece la plataforma (es decir, el teléfono inteligente y su tienda de aplicaciones).
La mentalidad de una empresa de software integrado
Mientras que la industria automotriz está explorando la transición de automóviles definidos por hardware a automóviles definidos por software, es importante comprender la diferencia entre los dos:
• El diseño de hardware suele ser rentable: ¿cómo se puede hacer un cambio de hardware para reducir el costo en $1? Ahorrar $1 por dispositivo ahorra $1 millón en 1 millón de dispositivos.
• El software a menudo tiene un factor de escalabilidad: ¿cómo podemos hacer que una solución de software funcione para millones de usuarios? Cobrar $1 por usuario por mes puede generar $1 millón en ingresos.
Hay una diferencia esencial entre los dos.
Los fabricantes de automóviles tradicionales han profundizado en las listas de materiales para equipos de hardware. Los automóviles requieren especificaciones claras y detalladas durante el desarrollo. Para cumplir con los requisitos de las especificaciones, los fabricantes seleccionaron el hardware más rentable. En última instancia, el vehículo está limitado por este hardware hasta cierto punto, y este efecto continúa a lo largo de su ciclo de vida.
Empresas como Tesla tienden a elegir soluciones de hardware más potentes. Pero eso no significa que no presten atención al costo de la lista de materiales. Tienen mayor libertad para considerar factores de ventaja competitiva. Tesla incluso introdujo juegos dentro del sistema coche-máquina. Estos juegos no se refieren a juegos en el dispositivo de entretenimiento a bordo, sino a juegos que deben jugarse en casa con una computadora portátil para juegos. ¿Sería posible proporcionar juegos en el automóvil? Tal vez no, pero ese no es el punto de la pregunta. La pregunta es, ¿estarán satisfechos los clientes si conocen esta característica? Porque en cualquier caso, la satisfacción del cliente es más importante que la propia función.
Dicho hardware y sistema en chips son más costosos, pero cada año se implementan nuevas funciones, que también brindan ventajas adicionales para atraer clientes. Una vez más, la satisfacción del cliente es un factor clave. Y sin duda, la mayoría de los clientes preferirían un automóvil con características en constante mejora: les daría la novedad de obtener un automóvil nuevo con regularidad. De hecho, tal elección daría como resultado un aumento de los costos de la lista de materiales en comparación con las soluciones SoC de gama baja. Pero cada OEM ha tomado decisiones estratégicas, como curvar formas de puertas complejas, agregar un alerón trasero retráctil, usar llantas específicas... elecciones que ayudan a diferenciar sus productos y establecer las respectivas percepciones de marca. Algunos fabricantes de equipos originales (OEM) creen que el poder de cómputo del hardware y software del vehículo puede mejorar efectivamente la satisfacción del cliente.
Pero hay otro factor interesante: hace 30 años, cuando un fabricante producía un dispositivo electrónico de consumo, un teléfono celular o un vehículo, no gastaba hardware electrónico durante la vida útil del producto. Pero la situación es muy diferente ahora, porque el software juega un papel importante en estos dispositivos. Hoy en día, los clientes esperan ver que se presenten constantemente nuevas funciones de productos y que se deba mantener la seguridad del sistema, lo que genera gastos anuales relacionados con el software. Por lo tanto, además del costo de la lista de materiales del hardware, también se debe evaluar y optimizar el costo total de propiedad (TCO) de la arquitectura eléctrica y electrónica. Reducir la complejidad del sistema será la clave para reducir los costos de mantenimiento.
Por último, la selección de OEM basada principalmente en arquitecturas de componentes disponibles en el mercado con requisitos mínimos de idoneidad automotriz (por ejemplo, solo calificación AEC-Q100 y disponibilidad extendida del producto en el lado de la CPU) será más susceptible a la escasez de adquisiciones: esto no solo en términos de chips. , pero también en ingeniería y reclutamiento.
Prepárese para el desarrollo futuro
Los fabricantes de equipos originales se han esforzado durante décadas por crear productos de motores de combustión interna superiores, así como por su respectivo posicionamiento e identidad de marca, pero recientemente descubrieron que la situación es muy diferente: nacen nuevas marcas, los automóviles son más rápidos y dinámicos. en el mercado Coches eléctricos, y son enormemente rentables (en términos de capitalización de mercado y ganancias de Tesla). Para atender estos cambios del mercado, han lanzado varias iniciativas. Pero solo pueden cumplir verdaderamente las resoluciones de hoy si necesitan mantener los vehículos desplegados en un campo determinado en el futuro. Nuestras recomendaciones están diseñadas para ayudar a los OEM y sus proveedores a tomar las decisiones correctas para un futuro sostenible.