Esta es una historia de dos partes: sobre una nueva ronda de desarrollo automotriz. En el primero,
Alex Agizim, CTO Automotive & Embedded Systems en EPAM , habla sobre la virtualización en la computadora de un automóvil. Y también cómo y por qué el hipervisor XEN de código abierto puede convertirse en un competidor completo de soluciones comerciales para la industria automotriz.
Debo advertirte de inmediato: no arrojaré fragmentos de código y detalles de ingeniería al lector. Aquí hablaremos sobre cosas globales que creemos que cambiarán la industria automotriz en los próximos 2-4 años. Al igual que hace 12 años, los teléfonos móviles han cambiado para siempre con la llegada de Android y Apple iOS.
En EPAM Automotive, nos centramos en dos grandes bloques: virtualización y una plataforma en la nube para implementar servicios directamente en el automóvil. Esta historia es sobre la primera.
Dos enfoques
Si sigue el tema automotriz, probablemente haya notado cuán activamente Google desarrolla el tema de infoentretenimiento con su sistema operativo Android Auto. Desde finales del año pasado, la compañía ha establecido varias asociaciones estratégicas con fabricantes de automóviles para integrar Android Auto OS en el automóvil.
Pero los fabricantes aún tienen preocupaciones. La razón principal es la seguridad. En los automóviles modernos y futuros, el Grupo de infoentretenimiento y el Grupo de instrumentos, que contienen instrumentos e indicadores "vitales", se convierten en uno y utilizan los mismos recursos. Las flechas e indicadores físicos dieron paso a los pintados. Sin embargo, el conductor debería ver lecturas de velocidad real, nivel de combustible, condición del sistema de frenos, motor sin importar qué. Es inaceptable si en algún lugar de la forma en que las pantallas se congelan repentinamente y requieren un reinicio. Y por la experiencia de los teléfonos inteligentes con Android, sabemos que esto es completamente posible.
Los fabricantes de automóviles resuelven este problema de frente: ponen
dos o más computadoras. Por ejemplo, el primero se dedica a renderizar y mantener todo el tablero. En el segundo, Android Auto OS se ejecuta y muestra navegación, música, aplicaciones, etc.
Esta opción tiene varias desventajas. En primer lugar, varias computadoras son aún más caras que una. En segundo lugar, la implementación es complicada: debe garantizar el intercambio de información entre la parte de Android y el clúster instintivo, la coherencia y muchos otros aspectos.
Otra opción es
usar la virtualización usando un hipervisor, siguiendo el ejemplo de Cloud. La potencia y las capacidades de los microprocesadores modernos en las computadoras automotrices son suficientes. Un mínimo de dos pantallas están conectadas a la computadora. Uno para Android es el infoentretenimiento. El otro es para el mantenimiento del tablero. Dos sistemas operativos se ejecutan en máquinas virtuales aisladas. Incluso si Android "se cansa" y falla, solo se reiniciará la máquina virtual en la que se ejecuta.
Con tal consolidación, podemos trabajar en una computadora y facilitar la integración. Pero hay matices aquí.
Hipervisor de coche
En el centro de datos, el hipervisor solo se encarga de cortar el procesador, la memoria y el almacenamiento entre diferentes máquinas virtuales. También se asegura de que las "chicas virtuales" no se suban al espacio de las demás. Además, todos tienen el mismo conjunto de servicios que reciben de la plataforma del servidor.
En la computadora del automóvil, además de la CPU, la RAM y el almacenamiento, existen diferentes coprocesadores para tareas específicas. Por ejemplo, la misma GPU que necesitan Android y el tablero. Esto significa que la tarea del hipervisor es proporcionar una oportunidad para que ambos sistemas operativos utilicen coprocesadores. Además, asegúrese de que Android no conecte el coprocesador con algún comando ilegal o error de software.
Este es un requisito de seguridad funcional: el grupo de instrumentos debería funcionar sin tener en cuenta los bailes de Android. Por lo tanto, el hipervisor debe estar suficientemente avanzado y tener mecanismos especiales por los cuales se garantice el aislamiento completo.
El aislamiento del hardware ya lo proporcionan los procesadores modernos. Nos encargamos de la parte del software. Es decir, estamos modificando el
hipervisor XEN de código abierto para que pueda funcionar en el automóvil teniendo en cuenta todos los matices del entorno. En él, hemos proporcionado los siguientes bloques.
1. Aislamiento completo de máquinas virtuales que ejecutan infotainment y dashboard
En primer lugar, la computadora tiene muchos periféricos, botones, una red de pantalla táctil, etc. La virtualización de periféricos ya es compatible con un conjunto de controladores.
En segundo lugar, virtualizamos GPU y coprocesadores. Si una de las máquinas virtuales hace algo con alguno de los coprocesadores del sistema, esto no afectará el funcionamiento de la otra máquina virtual.
En tercer lugar, se implementa la virtualización de soporte de TEE: entorno de ejecución confiable. Esta es una zona especial protegida por hardware en el procesador, que se dedica a la ejecución de diversos procedimientos de seguridad. Pero dado que hay más de un sistema operativo, las solicitudes de estos a TEE también se dividen.
A continuación puede ver el estado de los componentes y si es interesante ver el código
2. Nutrición y rendimiento
Cualquier sistema operativo gestiona la potencia y el rendimiento y puede poner la computadora en modo de bajo consumo de acuerdo con las tareas y la carga actuales. Android Car también puede querer hacer lo mismo: si no hay tareas actuales, decide enviar el procesador al modo de ahorro de energía. Pero el sistema operativo que se ocupa de los dispositivos debería seguir funcionando. Resolvemos este conflicto con una extensión especial del hipervisor. Supervisa el estado de todo el sistema y gestiona la potencia y el rendimiento.
El siguiente momento es en tiempo real. El sistema debería funcionar con un horario garantizado. También estamos haciendo esto como parte del Programador en tiempo real de XEN.
3. Seguridad funcional
Por último, pero el primer bloque en importancia para la futura industria automotriz. Los fabricantes de automóviles de hoy se dan cuenta de que un enfoque de virtualización les ayudará a crear verdaderamente sistemas de servicio de cabina digital significativamente más flexibles y potentes. Esto requiere un hipervisor de grado automotriz.
Hay 3-4 soluciones comerciales de hipervisor de grado automotriz en el mercado. Pero todos los productos comerciales tienen desventajas:
- alto costo de una licencia;
- falta de la capacidad de cambiar fácilmente cualquier cosa en el software de acuerdo a sus necesidades
- el fabricante para esto rompe el cheque y los plazos;
- cerradura del vendedor
Todos estos problemas son eliminados por el hipervisor de código abierto. Inicial gratis. Hay acceso a la fuente, puede hacer cualquier cambio. Para hacer esto, puede organizar su equipo o contactar a las empresas de servicios. Hay total libertad, porque cuando cambia el proveedor, el código fuente permanece con el fabricante.
Lo que queda por decidir
La última barrera clave permanece en el camino hacia el código abierto. Un hipervisor de automóvil abierto debe cumplir con la seguridad funcional. Hasta hace poco, todos creían que lo hacía imposible. Ahora hay turnos.
Recientemente, hemos estado trabajando activamente con la comunidad de código abierto XEN Hypervisor. El desafío es adaptar el proceso de desarrollo para que XEN pueda ser certificado por seguridad.
A finales de marzo, se celebró una cumbre en Cambridge, donde se reunieron todas las personas interesadas. En primer lugar, todas las principales empresas que desarrollan XEN: Citrix, ARM, Xilinx, Renesas, EPAM. En segundo lugar, las compañías que se dedican a la certificación y, en tercer lugar, las compañías que proporcionan herramientas para el análisis automático del sistema e identificación de áreas problemáticas.
Como resultado de la cumbre, desarrollamos un plan según el cual es absolutamente posible hacer que un hipervisor de código abierto cumpla con la seguridad funcional. Hasta finales de este año, planeamos obtener un conjunto específico de artefactos necesarios para que cuando XEN se integre en las computadoras automotrices, se pueda certificar su seguridad.
XEN se convierte en un competidor completo para soluciones comerciales en la industria automotriz y elimina su último argumento sobre la falta de certificación de seguridad.
Desde el último, a mediados de julio, pasó la
Cumbre de Desarrolladores de Xen . La seguridad funcional fue uno de los temas principales. Presentamos el
enfoque de la solución de seguridad funcional (a través del enlace PDF).
Porque xen
Probablemente, esta pregunta surgió de algunos desde el principio.
El proyecto XEN existe desde 2003 y, en comparación con otras soluciones de código abierto, tiene una implementación muy amplia en los centros de datos. Ya se ha vuelto bastante maduro. Desde 2012, XEN tiene soporte nativo para la arquitectura ARM. Y los procesadores de esta arquitectura particular se utilizan principalmente en la industria automotriz.
Además, trabajamos mucho, analizamos varias soluciones y obtuvimos muy buenos indicadores de rendimiento. Por ejemplo, si el rendimiento de un sistema operativo que se ejecuta en un procesador sin virtualización es igual a X, en una máquina virtual es de 0.96-0.97X. Y en los hipervisores comerciales, una caída en el rendimiento puede alcanzar el 30%. La diferencia es un orden de magnitud convincente.
Por lo tanto, XEN nos parece una solución básica adecuada. Por lo tanto, EPAM está impulsando este proyecto. Ya hay varios fabricantes de automóviles europeos que están evaluando la solución basada en XEN para futuros automóviles con cabina digital, Android dentro y otras cosas que mencioné anteriormente.
Paralelamente a esta gran historia, estamos desarrollando nuestra propia plataforma de vehículos conectados Aos. Su idea principal es que, por un lado, les damos a los desarrolladores de servicios conectados la oportunidad de implementarlos directamente en la computadora de un automóvil y, por otro lado, los aislamos de las funciones críticas, garantizando la seguridad. Hablaré de esto en la próxima parte.