Autor: Steve McAslan, Director Técnico en NXP Semiconductors.
Es evidente, incluso para el propietario medio de un vehículo, que el panorama automovilístico está cambiando. Más allá de la gasolina y el gasóleo, también hay opciones de electrificación. Entre ellas están los híbridos, los que funcionan totalmente con baterías y los de hidrógeno. Pero no son los únicos cambios. La arquitectura eléctrica y electrónica (E/E) subyacente del vehículo también está cambiando. Esto conlleva cambios significativos en el diseño de la electrónica del vehículo y en la experiencia del conductor y el pasajero en su interior.
Los microprocesadores se han ido incorporando poco a poco en el automóvil desde los años 70, cuando los fabricantes de equipos originales empezaron a integrar sistemas de inyección electrónica de combustible (EFI) y diagnósticos a bordo. Año tras año han contribuido a la seguridad, eficiencia y comodidad del automóvil, con uno o varios de ellos, integrados en cada una de las cada vez más numerosas unidades de control electrónico (ECU). Esto ha dado lugar a una arquitectura plana desde el punto de vista de las redes y a poco margen para ofrecer actualizaciones de funciones una vez fabricado el vehículo. Todo lo necesario para implementar una función, desde la detección hasta el accionamiento, está conectado a una única ECU. Normalmente, las ECU están conectadas a través de un bus, como CAN, a sistemas centrales de control, programación y diagnóstico. Una vez implantado, el software sólo se actualiza si se detecta un problema y sólo después de un esfuerzo considerable, pruebas y una llamada a revisión del vehículo.
La influencia del smartphone en la automoción
Sin embargo, una generación de usuarios de smartphones está influyendo en las expectativas en torno a la experiencia del producto. Los consumidores ya no esperan comprar un producto acabado; compran plataformas que puedan modificarse y configurarse según sus necesidades, requisitos y estilo de vida. El rígido enfoque actual del diseño de vehículos no encaja en este molde. Esto ha obligado a la industria del automóvil a replantearse su enfoque de la electrónica del vehículo y el software que implementa la mayor parte de su funcionalidad.
En la actualidad existen dos corrientes de pensamiento sobre la arquitectura E/E, que reducen el número de ECU, simplifican el cableado y la conexión en red y permiten las actualizaciones por aire (OTA). También proporcionan la estructura necesaria para que funciones como la calefacción de los asientos, puedan adquirirse como una aplicación de smartphone mucho después de que el vehículo haya sido configurado y entregado a su propietario original.
Uno de ellos son las arquitecturas de dominio que siguen la convención actual de denominación de los distintos dominios del vehículo, como el tren de transmisión, el chasis, los frenos y la carrocería, por citar algunos (Figura 1). Una función que antes se implementaba en una única ECU se despliega junto a muchas otras funciones de dominio en una única ECU dotada de un potente procesador multinúcleo (Figura 2).
El otro enfoque es la arquitectura zonal. Aquí la ubicación de la ECU es más relevante, con un pequeño número de cajas de hardware situadas alrededor del vehículo más cerca de los sensores y actuadores instalados. De nuevo, las ECU contienen potentes procesadores multinúcleo con redes redundantes de alta velocidad adecuadas para el control en tiempo real que intercambian datos con otros controladores zonales. En el centro se encuentra un ordenador de alto rendimiento (HPC) y una pasarela telemática que proporciona conectividad a Internet.
Mientras que las arquitecturas de dominio ofrecen lo que podría considerarse un paso sencillo hacia una mayor integración, las arquitecturas zonales dan la vuelta al planteamiento de desarrollo de software. Esto se debe a que las funciones, como el control de los faros y los intermitentes, se reparten entre las ECUs zonales en lugar de estar dedicadas a una sola caja. En su lugar, las funciones se implementan como ECUs virtuales en potentes procesadores multinúcleo.
Tanto en las arquitecturas de dominio como en las zonales, esto también significa que el software que cumple los distintos niveles de integridad de la seguridad en automoción (ISO 26262 ASIL) debe funcionar en paralelo en el mismo procesador sin afectarse mutuamente en caso de fallo. Esto se conoce en la industria del automóvil como «libertad de interferencia». Por lo tanto, independientemente de la arquitectura utilizada, está claro que el software es el centro de la definición de las capacidades del vehículo y un aspecto central de esto es la virtualización.
Figura 2: En un controlador de dominio, cada función del vehículo se implementa en una ECU virtual, con sistemas operativos que comparten el rendimiento de procesamiento bajo la atenta mirada de un hipervisor.
Breve incursión en la virtualización
La virtualización ha sido fundamental para el éxito del Cloud Computing, ya que permite ejecutar varias instalaciones de sistemas operativos (SO) en un único servidor, compartiendo así su rendimiento entre muchos usuarios. La virtualización de metal al descubierto se ejecuta en el nivel más bajo del hardware del servidor, sin que ningún sistema operativo invitado instalado sepa que está virtualizado, que comparte recursos de hardware o que otros sistemas operativos se están ejecutando junto a él. En su forma más pura, la plataforma de virtualización, conocida como hipervisor, básicamente atrapa las llamadas al SO y las traduce al sistema virtualizado, como los accesos a disco y memoria. Lo mismo ocurre con las interfaces de hardware, como la conectividad Ethernet.
Como es de esperar, la virtualización tiene una sobrecarga inevitable al gestionar estos accesos de hardware. Para combatirlo, los desarrolladores pueden optar por el enfoque alternativo de la paravirtualización. En este caso, los accesos a los recursos de hardware se implementan en software de forma similar a como se harían si sólo existiera un sistema operativo. Aunque esto proporciona un aumento del rendimiento con respecto a la virtualización, el beneficio varía con la carga de trabajo y requiere que los SO se modifiquen adecuadamente. Este nivel de variación no es aceptable para el mundo en tiempo real del control en automoción.
Procesadores en tiempo real para sistemas operativos virtualizados
Los procesadores dedicados a aplicaciones de automoción deben hacer frente a estos retos, como es el caso de una nueva generación de procesadores en tiempo real de NXP. Por ejemplo, un ingeniero de desarrollo suele esperar que los pines de E/S de propósito general (GPIO) se configuren y controlen a través de una serie de amplios registros, en los que cada bit se dedica a establecer la dirección, el uso de pull-ups, proporcionar control de salida y ofrecer el estado de las entradas. A cada uno de estos registros se le asigna una única dirección en memoria. Debido a esto, los mecanismos típicos de protección de memoria no pueden asignar bits individuales de un registro a una instancia específica del SO. Por lo tanto, es responsabilidad del hipervisor gestionar esto por software.
El S32Z y el S32E proporcionan una alternativa inteligente que renuncia a este requisito, permitiendo el soporte de virtualización núcleo a pin para combinaciones arbitrarias de pines GPIO por cada SO invitado. El soporte se proporciona a través de hardware adicional que asigna, durante el arranque, los pines GPIO requeridos a un SO cliente o partición de sistema específicos. Como esto se implementa en hardware, las pérdidas de rendimiento típicamente asociadas a la virtualización desaparecen. Dado que cada sistema operativo sólo ve su propio número arbitrario de GPIOs, gracias a la partición a nivel de hardware, casi no hay necesidad de paravirtualización.
La certificación ASIL también se simplifica gracias a este soporte de virtualización a nivel de hardware. Cualquier fallo en el hardware sólo afecta al sistema operativo relacionado y a su aplicación, y una sola máquina virtual puede elegir resetearse o reiniciarse a sí misma sin impacto en otros sistemas operativos o configuraciones de hardware del dispositivo. Los procesos fuera de control no afectan a otras partes del sistema. Otra ventaja son las garantías de calidad de servicio resultantes para el ancho de banda y el rendimiento.
Adaptación a las necesidades del vehículo definido por software
El acceso núcleo a núcleo a los recursos GPIO es sólo uno de los aspectos de la familia S32E y S32Z de procesadores de tiempo real que satisfacen las demandas de los vehículos definidos por software. Las 24 interfaces de red FlexCAN FD se pueden etiquetar con un identificador que permite asignarlas también a sistemas operativos invitados específicos, lo que minimiza de nuevo la sobrecarga de software. Pero esto no es todo. Las redes CAN pueden ser especialmente intensivas en interrupciones, lo que da lugar a muchos cambios de contexto que dificultan el cumplimiento de los requisitos de tiempo real en el resto del código de la aplicación.
Para gestionar esto, los periféricos CAN forman parte de un bloque dedicado de aceleración automática de la comunicación con dos núcleos dedicados Arm Cortex-M33 lockstep y 768 KB de SRAM (Figura 3). El nuevo estándar CAN-XL también es compatible con el bloque Conectividad/Interfaz. CAN-XL ofrece velocidades de transmisión de datos de hasta 20 Mbits/s y un campo de datos mayor, de 2048 bytes. Sigue siendo interoperable con las redes CAN-FD, pero también admite la canalización de protocolos de capa superior, como el Protocolo de Internet (IP), algo que se utilizará cada vez más a medida que se implante Ethernet para automoción como red troncal.
También incluye Ethernet para automoción, con dos interfaces 10/100/1000Mbit y un conmutador Ethernet integrado en un bloque de aceleración Ethernet. En el futuro, los procesos que controlan las funciones del vehículo emitirán órdenes a través de Ethernet a procesos de software que implementen el control o proporcionen datos de sensores. Sin embargo, esa función puede estar ejecutándose en el mismo hardware de procesador, pero en una ECU virtual diferente. Para ello, el switch Ethernet también puede pasar datos entre ECUs virtuales del procesador. Esto significa que pueden crearse funciones de software que se comuniquen a través de Ethernet sin necesidad de saber si el software homólogo se encuentra en el mismo procesador o en un controlador zonal diferente en algún otro lugar de la red.
Figura 3: Una pequeña muestra de la conectividad disponible para automoción, a veces con soporte de aceleración, que ofrecen el S32E y el S32Z.
Desarrollo de software para el vehículo definido por software
La forma de desarrollar software en automoción también está cambiando. La ruptura más significativa con la tradición se produce en los OEM de los vehículos. Aquí la visión de conjunto es fundamental, ya que garantiza que las funciones necesarias estén bien definidas y que el hardware del procesador elegido ofrezca el rendimiento necesario para satisfacer las expectativas actuales y las de los futuros conductores a lo largo de la vida útil del vehículo (Figura 4).
Figura 4: En una arquitectura zonal, las funciones se distribuyen en ECUs virtuales por todo el vehículo, como en este caso, en el que el sistema de frenado delantero y trasero y el ESC relacionado con el sistema de frenado se despliegan de forma centralizada.
Los proveedores de primer nivel también desempeñarán un papel importante en este caso, gracias a su profundo conocimiento de los distintos aspectos del vehículo y de cómo se han implementado históricamente. Más abajo en la cadena, es más probable que los proveedores de automoción de nivel 2/3 experimenten menos cambios, aparte del paso al desarrollo de software para una ECU virtual, en lugar de hardware. Recibirán acceso a un sistema operativo y a periféricos con poca información sobre qué más está funcionando en el mismo hardware. De hecho, es posible que ni siquiera se hayan tomado esas decisiones. Tal es la flexibilidad del enfoque definido por software.
Lo esencial es que los procesadores elegidos ofrezcan un gran rendimiento para el presente y margen para el futuro, junto con la capacidad de admitir actualizaciones OTA seguras. Los S32E y S32Z proporcionan ocho núcleos Arm Cortex-R52 que funcionan a una frecuencia de hasta 1 GHz, fabricados en un proceso de 16 nm y con una hoja de ruta hacia los 5 nm. Pueden configurarse de forma flexible como núcleos individuales o en bloque para adaptarse a las exigencias de seguridad de las funciones que se ejecutan en ellos. Para responder a las exigencias de los sistemas avanzados de asistencia al conductor (ADAS) y las funciones de conducción autónoma, también hay un procesador DSP/Machine Learning de 25 GFLOPS.
Un motor de seguridad de hardware (HSE), certificado según la norma ISO 21434, proporciona aceleradores criptográficos seguros para una comunicación segura y actualizaciones de software firmadas digitalmente que se comparten mediante una infraestructura de clave pública (PKI).
El futuro del automóvil es el software
Vistos desde fuera, los coches siguen siendo maravillas mecánicas, desde su diseño y forma hasta sus asientos y motorización. Pero todo lo demás, desde el movimiento hasta las prestaciones que ofrecen a sus ocupantes, lo definirá el software, unido a la electrónica, oculto a la vista. La automoción siempre ha sido un mercado único, que requiere algo más que los procesadores más rápidos que puede ofrecer la industria de semiconductores, sino que exige productos que también cumplan amplios requisitos de fiabilidad y seguridad. Se necesita una nueva clase de procesadores en tiempo real, ya que el vehículo definido por software impulsa arquitecturas de sistemas que se basan en enfoques típicamente asociados al Cloud Computing, como la virtualización. Dispositivos como la familia S32E y S32Z, que admiten la asignación granular de hardware de núcleo a pin para soportar ECUs virtualizadas, se convertirán en un elemento básico de las nuevas arquitecturas E/E de automoción que se desplieguen. Esto permitirá a los fabricantes de equipos originales consolidar el hardware y ofrecer funciones de tipo «smartphone como servicio», aplicaciones y actualizaciones OTA, sin perder la fiabilidad y la seguridad en las que se basan sus marcas.
