Autores: Thomas Brown, Arquitecto de Soluciones de Procesado para Automoción, NXP Semiconductors y Brian Carlson, Director de Marketing Global de Productos y Soluciones, NXP Semiconductors
Los fabricantes de equipos originales (OEM) han venido suministrando tradicionalmente los productos de sus mejores proveedores, los han interconectado y han fabricado un vehículo que incorpora la tecnología que se hizo popular entre los consumidores en los cinco años anteriores. Nunca hubo la posibilidad de actualizar ningún hardware, aunque estuviera disponible en otros vehículos de la misma plataforma. Esto se debe a la complejidad de la actual cadena de suministro en el sector de la automoción y al coste y el esfuerzo que suponen la integración, la validación y la certificación. Tampoco se podía actualizar el software para aprovechar una nueva funcionalidad. En el mejor de los casos se ofrecía una actualización de software para resolver una cuestión menor. Pero las cosas están cambiando con la llegada del vehículo definido por software (software-defined vehicle, SDV).
La meta es ofrecer nuevas funcionalidades a los conductores que les permitan personalizar sus coches, de forma parecida a cómo actualizan sus smartphones. Y puede que el conductor ni siquiera sea el propietario sino que, siguiendo la tendencia de la movilidad compartida, las funcionalidades y las prestaciones acompañen al conductor en el vehículo que utilice.
Las arquitecturas eléctricas/electrónicas (E/E) de los vehículos están cambiando enormemente para lograr esta flexibilidad. Las arquitecturas por dominios y zonas (Figura 1) significan que cada producto de hardware integrado en la plataforma estará conectado a la red. Esto permite intercambiar datos a través de redes Ethernet de alta velocidad sensibles al tiempo y la colaboración entre procesadores mediante PCIe. En el centro de esta nueva arquitectura se encuentra una función de coordinación del ordenador del vehículo y la conexión con servicios en la nube. Además, las funciones se pueden dividir incluso en unidades de control electrónico (electronic control units, ECU) de modo que, tras ser fabricado, el hardware no se pueda programar para que ejecute una función determinada. En lugar de ello se tomará la decisión cuando el software esté instalado durante la fabricación del vehículo, dotándolo de los recursos más apropiados.
Figura 1: Los fabricantes de automoción están adoptando arquitecturas por dominios y zonas y están abandonando un conjunto disperso de ECU. Fuente: NXP Semiconductors
Aprender de la nube
La industria de automoción está buscando inspiración en la nube e introduciéndola en el vehículo. La virtualización y la contenedorización han fortalecido el software como servicio (software-as-a-service, SaaS) bajo cargas extremas, ciberataques y durante las actualizaciones de software. La virtualización usa un hipervisor para permitir la ejecución de varios sistemas operativos (SO) en un solo servidor, de manera que la memoria, el almacenamiento y la interconexión se comparten entre los SO. No obstante, los SO virtualizados arrancan con lentitud cuando se necesitan más recursos.
La contenedorización utiliza un solo SO que proporciona espacios de usuario por separado (contenedores) para las aplicaciones que ejecuta. En el caso de que una app funcione mal o deba ser actualizada, las otras siguen funcionando sin verse afectadas por lo que sucede en otra parte. Además, si un contenedor funciona al límite se puede iniciar rápidamente una réplica para compartir la carga, permitiendo así su orquestación dinámica o “elástica”. Las principales tecnologías en este ámbito son Kubernetes para aplicaciones contenedorizadas (Figura 2) y Docker para crear aplicaciones contenedorizadas. También están surgiendo otras aplicaciones más ligeras que cubren más adecuadamente las necesidades de los sistemas de automoción.
Figura 2: Diagrama de bloques de S32G GoldVIP. GoldVIP utiliza Kubernetes K3s para la orquestación de contenedores. Dos servicios AWS separados gestionan el tiempo de ejecución en el borde y los servicios en la nube, mientras que las actualizaciones OTA son manejadas por el cliente OTAmatic. Fuente: NXP Semiconductors
Para automoción, K3s es una versión ampliamente disponible de Kubernetes para hardware con recursos limitados que es compatible con los procesadores de Arm. Junto con los actuales procesos de desarrollo de software CI/CD (continuous integration/continuous deployment) y las actualizaciones OTA (over-the-air), ya existen todas las piezas del puzle para que el SDV se haga realidad.
La industria de automoción está cambiando
Como reconocimiento de que implementar un cambio corresponde a una comunidad, y no solo se realiza a título individual, representantes de la industria de semiconductores, la informática en la nube, los fabricantes de automóviles y otros proveedores han constituido el proyecto Scalable Open Architecture for Embedded Edge (SOAFEE). Esta colaboración liderada por la industria incluye a compañías como Arm, AWS, Bosch, CARIAD, Continental, Red Hat, SUSE y Woven by Toyota (Figura 3).
La iniciativa abarca no solo el software para el hardware del vehículo sino también para la nube a través de un enfoque de desarrollo de software nativo en la nube. Este utiliza servicios en la nube para crear una cadena CI/CD destinada a la construcción, la contenedorización, la validación y el despliegue de software que funcione en la nube y en el hardware embebido. Como es natural, el proyecto cubre la seguridad y las necesidades en tiempo real, además de ofrecer soporte para seguridad funcional por medio de la percepción del grado de criticidad mixta. Por tanto, se pueden desplegar o actualizar funciones de confort sin que afecte a los servicios relacionados con las capacidades de seguridad crítica.
Figura 3: SOAFEE lleva un enfoque nativo en la nube al desarrollo de software para automoción y cuenta con un significativo soporte de las grandes compañías de la industria de automoción. Fuente: SOAFEE
Está claro que, si la diferenciación de las funcionalidades de un vehículo llega a través del software, el software de aplicación de nivel más alto tiene como objetivo definir la diferenciación, no el software de nivel más bajo. Existen otros planteamientos similares. Uno de ellos es Vehicle OS, de Vector. Su entorno de ejecución se denomina Base Layer y se puede adaptar a los microcontroladores, los microprocesadores o el backend basado en la nube. Este entorno es suministrado por Software Factory, que automatiza el flujo de trabajo de desarrollo, la integración del software de bajo nivel, el middleware y las apps con la distribución hasta el vehículo o el backend.
TTTech Auto también considera viable en el futuro un estándar abierto como Car.OS, destacando que la mayor parte del software de infoentretenimiento se basa en una pila de software común. Este enfoque también permite un solo desarrollo y un múltiple despliegue como se ha señalado antes.
Hardware para el software
Si bien las aplicaciones en la nube puedan ser muy robustas y fiables, lo consiguen mediante la fuerza bruta de la potencia informática y una enorme redundancia elástica sobre una plataforma de hardware x86 cuyo uso es habitual en la industria. Para imitarlo en el vehículo se necesita una nueva generación de procesadores que ofrezcan estas prestaciones así como conexión a redes de alta velocidad, determinismo y seguridad funcional. Además, debido a la mayor superficie de ataque generada por estos dispositivos móviles conectados a la red, se necesita un enfoque muy cuidadoso por lo que respecta a la ciberseguridad del software y el hardware.
Una nueva generación de procesadores de red para vehículos está a la vanguardia para hacer realidad la revolución del SDV. Un ejemplo de ello es la familia S32G3 de NXP, basada en las capacidades de la generación anterior de procesadores para automoción (Figura 4). El diseño aborda los tres aspectos principales en el núcleo de la nueva arquitectura E/E.
Figura 4: La familia S32G3 se destina a aplicaciones ASIL D en nuevas arquitecturas E/E del SDV como procesadores de seguridad para conducción autónoma, nodos informáticos centrales y pasarelas orientadas a servicios. Fuente: NXP Semiconductors
El primero de ellos es el procesado funcionalmente seguro, cubierto por hasta cuatro microcontroladores Arm Cortex-M7 lockstep y hasta ocho microprocesadores Arm Cortex-A53 cluster lockstep. Estos ofrecen clusters lockstep ASIL D configurables y dos clusters independientes ASIL B. Al arrancar se realiza una prueba interna BIST (built-in self-test) de la memoria y la lógica en busca de posibles problemas mientras una unidad de recogida y control de fallos (fault collection and control unit, FCCU) monitoriza la operación, poniendo para ello el dispositivo en un estado seguro por si detectara un fallo. También se pueden asignar periféricos a unos núcleos determinados al arrancar, posibilitando así la virtualización y la contenedorización para un arranque rápido siguiendo unas reglas estrictas de orquestación. Esto garantiza, en el caso del hardware, que los recursos no se vean afectados por fallos en la ejecución de código en otro punto del dispositivo. Ya se han creado aplicaciones de demostración que usan K3s para contenedorización.
La comunicación a alta velocidad es fundamental para el SDV, desde las operaciones habituales hasta las actualizaciones OTA. Esto nos lleva hasta el segundo aspecto principal: las redes. Sin embargo, las interrupciones asociadas a CAN/CAN-FD, Ethernet y otras complica el determinismo. Para contrarrestarlo, S32G3 ofrece un motor de comunicación de baja latencia (Low Latency Communication Engine, LLCE) junto con sus propios núcleos para manejar redes antiguas (CAN, FlexRay, LIN y SPI). Incluye descarga para cifrado AES, sincronización (IEEE 802.1AS) y buffers flexibles. Para Ethernet se integran hasta tres MAC de 2,5 Gbit en un PFE (Packet Forwarding Engine) por separado que es compatible con IEEE 1588v2 y AVB/TSN para comunicaciones determinísticas. También hay disponibles otras interfaces para automoción y dos interfaces PCI Express (PCIe) 3.0 (de dos líneas en cada uno).
La tercera y última pieza es la seguridad, empezando por un motor HSE (Hardware Security Engine) avanzado. Integra las típicas funciones criptográficas (AES, SHA, ECC, RSA) y cumple las actuales especificaciones de seguridad, como EVITA (E-safety Vehicle Intrusion Protected Application). Al establecer una raíz de confianza en el arranque, el procesador asegura que dispone de todos los mecanismos modernos de seguridad que limitan los ataques y garantizan que solo se instalarán software y actualizaciones con certificación en el vehículo. Finalmente, soporte del hardware para sistemas IDPS (Intrusion Detection and Prevention Systems) con filtrado e inspección de paquetes de comunicación que ayudan a detectar ciberataques que puedan eludir los mecanismos de autenticación y cifrado.
El desarrollo se acelera gracias a una gama de plataformas de hardware (RDB3, GoldBox 3), software de NXP y de compañías asociadas (Figura 5) la plataforma GoldVIP (Vehicle Integration Platform) que agilizan el desarrollo de pasarelas conectadas y facilitan las pruebas de concepto.
Figura 5: La familia S32G3 cuenta con el soporte de un ecosistema de software propio y de compañías asociadas. Fuente: NXP Semiconductors
Procesadores listos para SDV
Los Vehículos Definidos por Software (SDV) son una gran promesa para el público, tanto para quienes quieren poseer su propio vehículo como para quienes solo desean utilizar un transporte personal. Está claro que el enfoque actual de conectar 150 ECU a hardware y software distintos de varios proveedores no está logrando este objetivo. Los OEM están asumiendo el desarrollo de software para sus vehículos, recurriendo para ello a nuevas arquitecturas E/E compatibles con los flujos de trabajo CI/CD necesarios para el continuo despliegue de nuevas funcionalidades y actualizaciones. Gran parte de este proceso se puede copiar de los procesos de desarrollo de software en la nube ya existentes. No obstante, estos procesos se han de adaptar al entorno determinístico y funcionalmente seguro del vehículo y a las necesidades únicas de la automoción en materia de ciberseguridad. Las nuevas generaciones de procesadores ASIL D con hardware que simplifica la virtualización y la contenedorización, junto con la seguridad más avanzada, están listos para afrontar este enorme reto.
