Esta es una historia de dos partes: sobre una nueva ronda de desarrollo automotriz. Esta "serie" está dedicada al desarrollo propio de EPAM, la plataforma de vehículos conectados de Aos.
Alex Agizim , CTO, Automotive & Embedded Systems, explica en qué se diferencia de una solución en la nube tradicional y cómo brinda a los desarrolladores de software acceso al automóvil. Puede familiarizarse con la primera parte
aquí .
En la primera parte, hablé sobre cómo nuestros desarrollos del hipervisor XEN aíslan la parte de servicio del software automotriz del software de seguridad requerido. Esta es una de las barreras para el uso generalizado en la industria. Por primera vez, un hipervisor de código abierto se convertirá en un competidor completo para soluciones comerciales cerradas.
Pero este es solo el primer paso. Para llevar los servicios automotrices a un nuevo nivel, debe "dejar" a las empresas y desarrolladores de servicios lejos de ser integrados y automotrices. Esto requiere el siguiente nivel de abstracción. Para que un desarrollador que utiliza marcos modernos en el desarrollo de software pueda, sin volver a aprender, diseñar sus servicios para automóviles.
Quizás después de leer querrás decir: “¿Por qué tantas dificultades? Por ejemplo, compré una tableta Android para un automóvil, configuré los servicios necesarios y estoy muy contento ”. Este es un enfoque de ingeniería clásico, muy de apoyo. Pero veamos más amplio. La industria automotriz, desde el punto de vista del software, lleva mucho tiempo estancada en los enfoques clásicos. Te diré cómo vemos su futuro y qué hacemos para esto. Y al final, veamos las principales dificultades.
Entonces
¿Por qué necesita dejar que el desarrollador del servicio ingrese a la computadora a bordo del automóvil? ¿Y qué está mal ahora?
El automóvil se está convirtiendo en un dispositivo cada vez más complejo. Está repleto de sensores para todas las ocasiones, y las naves espaciales envidiarán el rendimiento de las computadoras a bordo. Con todo esto, el automóvil sigue siendo muy limitado en capacidades. El desarrollo de software está avanzando, pero el 90% pasa.
Una analogía cercana son los teléfonos inteligentes. Hasta 2007-9, escribir una aplicación que se ejecutara en diferentes teléfonos móviles era bastante difícil. Muchos sistemas operativos y frameworks lucharon en el mercado: soluciones de Symbian, Motorola, Ericsson, etc. ... El número de personas con habilidades de desarrollo para ellos era pequeño. Si una empresa deseaba que un gran número de personas usara su servicio o aplicación, un problema comenzó con el soporte en diferentes sistemas operativos y marcos.
Exactamente lo mismo está sucediendo hoy en la industria automotriz. Para que el servicio sea respaldado por diferentes fabricantes de automóviles, debe adaptarse a muchos marcos y un conjunto de reglas. Para Mercedes por separado, para Toyota por separado, etc.
Cuando apareció iOS en 2007, un año después, Android, la industria móvil inmediatamente hizo un gran avance. En AUTOMOBILE, el conflicto de dos paradigmas principales continúa.
El primero es tradicional.
Una computadora de a bordo del automóvil es un dispositivo cerrado, cuyo acceso está disponible solo para el fabricante . Los desarrolladores de terceros no tienen manera aquí: la seguridad y la protección en primer lugar. Fiable, pero no sin defectos. Por un lado, el fabricante cierra todo sobre sí mismo. No es necesario culpar a los desarrolladores de servicios de terceros. Por otro lado, uno no puede estar a la vanguardia del progreso. Un fabricante de automóviles no puede cubrir completamente la lista de deseos del cliente. El ciclo de desarrollo y lanzamiento al mercado es demasiado largo, el equipo, incluso muy publicitado, sigue siendo limitado. Y el esperado automóvil autónomo conectado se aleja más. Como la integración en una economía compartida.
El otro extremo es
considerar un automóvil como un dispositivo IoT . Es decir, simplemente recopile datos de todos los sensores automotrices, empaquételos y envíelos a la nube para su procesamiento. Repita miles de veces si es necesario. Entonces, cientos de proyectos en la nube, incluidos Google, Microsoft y Amazon, están tratando de mirar el automóvil. Pero esto está un poco mal.
Auto no es un hogar inteligente con bombillas, un termostato y un televisor. Tiene cientos de veces más sensores y su propia potencia informática. Y, lo más importante, el canal entre el automóvil y el centro es inestable. Incluso si es condicionalmente estable, es poco probable que quiera ejecutar cientos de megabytes de datos por segundo. De lo contrario, no hay forma de tal enfoque: toda la lógica empresarial del servicio funciona en la nube.
¿Qué se nos ocurrió a cambio?
Hemos elegido una ideología diferente.
Un automóvil no es solo una fuente de información de los sensores. Este es un
nodo informático completo en el que el servicio puede ejecutar su lógica empresarial .
Para esto, el automóvil necesita un elemento básico: la plataforma de vehículo conectado. Le permite abrir el automóvil como una plataforma de software. Y, por otro lado, utilice las herramientas adoptadas en los servicios en la nube para hacer frente a la implementación y la orquestación de servicios que deberían funcionar en la computadora de a bordo.
Si nuestro pronóstico es verdadero, terminaremos con un ecosistema en el que el programador puede actuar de la manera habitual e incorporar parte de la lógica de negocios en la computadora de un automóvil. De la misma manera que hoy en los servicios en la nube, presiona un botón, inicia CI / CD, despliegue de todos los componentes necesarios para todos los nodos necesarios. En nuestro caso, uno de los nodos para el despliegue será un automóvil. Y damos un marco que puede hacer esto. Por lo tanto, llamamos a nuestra plataforma en la nube "Kubernetes para automóviles".
El concepto en nuestra visión se divide en 2 partes:- aislar el software de seguridad del software de servicios conectados;
- para proporcionar el nivel de abstracción necesario para las empresas que desean desarrollar o ya están haciendo servicios de vehículos conectados. No deberían molestarse con los embebidos, sino desarrollar servicios con sus herramientas habituales y utilizar la computadora de a bordo como dispositivo de borde.
Una computadora de a bordo del automóvil debe convertirse en una computadora de borde para futuros servicios móviles. Salvamos a los fabricantes de automóviles de inventar servicios de forma independiente y abrimos el automóvil para desarrolladores. Cómo sucedió una vez con los teléfonos inteligentes.
¿Qué casos puede cerrar?
El caso raíz es la
falta de conectividad . En la versión clásica de la nube, el servicio perderá el acceso al automóvil. En la variante Connected Vehicle Platform, el desarrollador puede prever esto y pre "flashear" la lógica dentro del automóvil. Y para la parte de la nube, al menos amortiguar los datos.
La plataforma también ayudará a mejorar significativamente la gestión de la flota y la gestión de la flota y el mantenimiento predictivo. La comunicación con la nube para estos servicios se vuelve, si no opcional, mucho menos popular.
Un ejemplo completamente comprensible es el trabajo de los servicios de taxi. Ahora se implementan en teléfonos inteligentes, funcionan muy bien con tarjetas y pagos, pero no pueden tener en cuenta el estado del automóvil. Por ejemplo, llegas tarde al aeropuerto, llega Uber, y de repente resulta que el conductor tiene suficiente gasolina solo para una parte del camino. El conductor no pudo entender esto de antemano. Pero si el servicio Uber se implementó dentro de la computadora de a bordo, en la etapa de la orden, podría decirle al backend que este automóvil en particular no es adecuado. Y la
calidad del servicio sería mayor.
En el caso de la futura economía compartida, debe tener un conjunto de servicios en el automóvil que estará completamente sin una interfaz de usuario. Por ejemplo, un servicio que controlará la condición técnica del automóvil (el ejemplo con Uber y gasolina también es adecuado aquí). O un servicio que monitorea cómo conduce una persona y brinda estos datos a las compañías de seguros o de alquiler.
Al mismo tiempo, las compañías de seguros o de alquiler deben evitar que el pasajero y el conductor los retiren o desconecten. Hoy están retorcidos por servicios que funcionan solo con la ayuda de unidades de telecomunicaciones adicionales. Y esta es la compra, instalación, integración, redacción del servicio en sí. Se necesita mucho tiempo y dinero.
Por lo tanto, siempre miramos el Vehículo Conectado en dos aspectos. Un lado solo se conecta a los servicios de Internet. El segundo es auto como parte de una economía compartida. Para hacer esto, todos los elementos básicos deben integrarse en el automóvil en la etapa de su producción. Por lo tanto, estamos hablando con fabricantes de automóviles o con fabricantes de computadoras para automóviles.
Uno de los problemas de la industria es que no es posible encontrar casos de usuarios porque no hay un enfoque de plataforma suficiente. Fue lo mismo con los teléfonos móviles. Puede, por ejemplo, decir que hay 2.800 empresas que hacen soluciones para la gestión de flotas. Pero todos son muy monolíticos. Si necesita cambiar algo, debe cambiar las computadoras de a bordo y de telecomunicaciones. Después de todo, quiero hacer algo que esta unidad no puede hacer.
¿Cómo cerrar de forma segura un servicio comercial desde la nube al automóvil? ¿Qué puede evitar esto y cómo lo resolvemos?
1. ContenedoresDado que procedemos de las ideas de Kubernetes, su habilidad principal es desplegar contenedores. Pero con la computadora de un auto es difícil.
En primer lugar, incluso si en Python escribimos un par de líneas de código que imprimen "Hola, mundo", el tamaño del contenedor puede alcanzar los 50 MB. Verterlo a través de un canal celular puede o no funcionar. Incluso el místico 5G tiene los mismos problemas que cualquier otra conexión: cobertura, ancho de banda, estabilidad. Entonces necesitas aumentar las posibilidades.
En segundo lugar, la computadora del automóvil es muy buena en potencia informática, pero aún mucho más limitada que cualquier servidor más pequeño en la nube. Muchos otros programas se ejecutan en él. No puedes simplemente venir y "comer" 200 MB de RAM.
Por lo tanto, en primer lugar, describimos nuestro tipo de contenedor en el marco del estándar OCI. El problema con el tamaño se resuelve de la siguiente manera: todas las cosas básicas que un desarrollador necesita para operar un servicio no necesitan ser transportadas desde la nube. Ya están preinstalados en la computadora del automóvil. Solo necesita traer el código, que en el peor de los casos requiere cientos de kilobytes.
El problema con los recursos de la computadora de a bordo se resuelve a través de su descripción en nuestra especificación de contenedor. Debido a esto, puede determinar fácilmente las cuotas que monitoreará la computadora del automóvil. Y el servicio instalado nunca puede superarlos.
2. SeguridadKubernetes se diseñó originalmente para implementar y organizar servicios en la nube. Es decir, en un entorno controlado, respaldado y protegido del manos equivocadas. Pero tenemos un auto y los atacantes tienen una fantasía ilimitada. Pueden sacar la computadora de a bordo, descifrarla con algún dispositivo y entrar en el canal entre el automóvil y la nube. Por lo tanto, la seguridad es nuestra tarea constante de máxima prioridad.
Hemos implementado un modelo avanzado de acuerdo con las recomendaciones de la Agencia de Seguridad Nacional de EE. UU. Dice lo siguiente: al diseñar su sistema de seguridad, primero debe minimizar el número de lugares de ataque potencial y también construir la seguridad como un pastel de capas. Hackeado en algún nivel? Es necesario notar esto y hacer todo lo posible para no pasar al siguiente.
En nuestro modelo, el "pastel" se ve así:
- Utilizamos contenedores como una especie de aislador a nivel del sistema operativo Linux. Es muy difícil salir del contenedor;
- ¿Salir del contenedor? Pero la plataforma Connected Vehiclle se ejecuta en una máquina virtual separada, para lo cual necesitamos XEN. Esta máquina virtual está aislada de todos los periféricos. La comunicación con los periféricos solo puede ocurrir a través de algunas API proporcionadas por el fabricante del automóvil;
- Rompió el contenedor y la máquina virtual? Tenemos una barrera más: la introspección de la máquina virtual: análisis de patrones en los que trabaja la máquina virtual. Por ejemplo, una máquina virtual de repente intenta agresivamente llegar a algún tipo de memoria, que generalmente no toca. Puede responder: apague esta máquina virtual, regrese a la versión estable, etc.
3. Escala¿Es crítico el tiempo de actualización en los teléfonos inteligentes de los usuarios para la banca móvil condicional? No especialmente Si tan solo nada se rompiera en el camino. Para los servicios en la nube, el problema del escalado no es un gran problema.
No con un carro. Supongamos que alquiló un automóvil y desea utilizar su servicio, que le brinda una buena póliza de seguro, porque maneja bien. Pero para esto, es necesario que se instale un servicio en el automóvil que proporcione sus datos a la compañía de seguros.
Entraste al auto, insertaste la llave en la cerradura, giras y después de 3 segundos estás listo para salir. Es lógico si en estos 3 segundos el automóvil acepta todos los servicios necesarios para el viaje. ¿Pero si no hay una de esas máquinas, sino 10,000? Un sistema que despliega servicios en un automóvil debería poder hacerlo rápidamente. El tiempo de instalación debe ser constante independientemente de la cantidad de vehículos a instalar.
Resolvimos este problema con la ayuda del complemento que desarrollamos anteriormente RabbitMQ. Facilita la ampliación y la reducción de los sistemas, según la cantidad de nodos que necesite usar.
4. Canales de comunicación.Cuando se produce el despliegue desde la nube al automóvil, el canal de comunicación debe estar encriptado. Utilizamos Mutual TLS para la autenticación. Funciona en dos direcciones: el automóvil inicia sesión en la nube y la nube inicia sesión en el automóvil. Todo esto se basa en certificados. Si los certificados no se ajustan o alguien intenta reemplazarlos, no se otorgará la autorización y no se obtendrá acceso a la computadora de a bordo.
Además, cada canal a través del cual se envían contenedores desde la nube al automóvil se cifra con su propio conjunto de claves. Supongamos que alguien ha robado una llave, un certificado y pudo ingresar al canal de transferencia de contenedores. Pero solo puede llegar al canal de este auto en particular. De qué se tratará la indicación. Puede renovar los certificados, el nuevo cifrado Mutual TLS comenzará a funcionar en ellos, y todos los esfuerzos de descifrado han quedado en nada. Esto nos salva del problema de las redes IoT, cuando un certificado pirateado puede comprometer todos los dispositivos.
5. MultitenancyImagine una red de IoT doméstica inteligente regular. Cuenta con fabricantes de dispositivos y operadores de red. Como regla, las dependencias entre dispositivos y operadores son estáticas. El ciclo de vida también es bastante estable: si comienza a cambiar una bombilla inteligente por otra, no será pronto y lo hará con poca frecuencia.
En el caso del automóvil y la economía compartida, estas dependencias son muy dinámicas. Hay un
fabricante de automóviles .
Hay un comprador / propietario , digamos que se trata de una empresa que comparte autos. Hay
un operador de servicio. Y hay un
usuario final.
Propietario, operador y usuario pueden cambiar todo el tiempo. El lunes por la mañana, el automóvil pertenece a cierto banco, el operador es la compañía A. Después del almuerzo, ya es operado por la compañía B. Los usuarios de diferentes operadores también pueden ser diferentes. Pero al mismo tiempo, los servicios que les pertenecen deben migrar después de ellos para diferentes automóviles.
Esto se llama Multitenancy aquí y está respaldado por el diseño en nuestro sistema de gestión de implementación de servicios. Las funciones del proveedor de servicios y el proveedor de servicios ya se han definido; no se necesita lógica adicional. Puede asignar diferentes servicios a un automóvil. Supongamos que un automóvil se transfiere a otro propietario. Los servicios del anterior se eliminarán automáticamente y los servicios del nuevo se entregarán automáticamente. Las redes IoT de hoy y los mismos Kubernetes no son adecuados, simplemente no se encontraron con ese caso.
6. Monitorear la operación de los servicios.Para comunicarse con el servicio de automóviles, hay una API estandarizada llamada VIS - Servicios de información del vehículo. Está estandarizado por W3C. Esta API en nuestro concepto es implementada y controlada por el fabricante del automóvil. El servicio del vehículo conectado está bajo control total.
Diferentes fabricantes están comenzando a admitir esta API. Y al desarrollador no le importa para qué fabricante hace el servicio.
Por supuesto, cada fabricante de automóviles puede hacer algunas excepciones. Al igual que los teléfonos inteligentes: los Galaxy S9 y S10 tienen la misma API básica, pero cada uno tiene cosas que son justas para un modelo en particular. En un automóvil, también se puede obtener información básica independientemente de su tipo. Y para cosas específicas, sus propios matices. Esto permite a los fabricantes proponer algunas cosas únicas y distinguidas con valor agregado.
¿En qué están escritos los componentes de la plataforma? ¿Y sobre qué será posible escribir servicios para automóviles?
La plataforma en sí está escrita en Python. La gestión de nivel superior del sistema de implementación está escrita en Python. Toda la parte incrustada está escrita en C.
En cuanto a los servicios, el primero que hicimos soporte para Python, agregamos JavaScript. A pedido de varios fabricantes de automóviles, se agregó .NET. Se habla de Java.
En general, este es un problema táctico. No hay programadores de JavaScript, hay programadores. Creo que con el desarrollo de la automoción, aparecerán programadores involucrados en servicios de vehículos específicamente conectados. Una bombilla "¿qué hacer si no hay conectividad?" Siempre parpadeará en su cabeza Independientemente de lo que tengamos en el aire: 5G o 10G. La conexión inalámbrica no funciona el 100% del tiempo.
¿Cómo reaccionan los fabricantes de automóviles a la plataforma?
Cualquier fabricante de automóviles de hoy tiene una división interna que desarrolla servicios conectados. Estas personas pueden trabajar rápido. Pero se ven obstaculizados por sus propios departamentos de hardware y software internos.
Nos centramos en esto. Traemos una herramienta con la ayuda de la cual sus propios departamentos de desarrollo pueden trabajar de manera más rápida y flexible. Y los chicos de Embedded, que ahora están cambiando una línea de código durante 2 años, podrán hacer esto una vez con la plataforma, luego el sistema les permitirá ser independientes de ellos.
En general, los fabricantes miran a Aos con suficiente cuidado. Pero con interés, porque les abre nuevas oportunidades. Por ejemplo, pueden construir un modelo de negocio como Amazon, Google, Microsoft: asignar una tarifa de servicio por usar la computadora de a bordo, API, etc. Además, creo que algún día llegarán a un modelo de mercado. Es decir, los desarrolladores de software y servicios conectados pagarán una comisión por el usuario que instala su servicio.
En la industria móvil, esto sucedió rápidamente. Pero entendemos: las personas no cambian el automóvil cada año. El ciclo de desarrollo de software automotriz lleva de 4 a 6 años. Por lo tanto, lo que estamos hablando hoy con los fabricantes de automóviles comenzará a aparecer en forma de algún tipo de pilotos apenas antes de 2022.
¿Estamos tratando de copiar o competir con Tesla?
No, e incluso viceversa. Tesla, a diferencia de otros, puede actualizar por aire cualquier software que se ejecute en cualquier computadora del automóvil. Para que puedan introducir constantemente nuevas características. Pero su computadora no es una plataforma para desarrollar servicios de autos compartidos. No puedes comprar 10 autos, contratar a 2 programadores y escribir un servicio genial para compartir autos. Por lo tanto, Tesla también es uno de nuestros clientes potenciales. Y de lo más avanzado.
Con nuestra plataforma, ni Tesla ni otros fabricantes tendrán que dedicar tiempo a inventar una bicicleta. Después de todo, nadie en aplicaciones en la nube ya está desarrollando sus Kubernetes. Nuestra visión es que esto debería suceder con la plataforma Connected Vehicle.
Si hablamos de competencia en general, hasta ahora no hemos visto un solo competidor que al menos hable de lo que estamos hablando. Al final resultó que, la industria del automóvil todavía está muy cerrada. Y muchas cosas en la plataforma, el mismo soporte para FOTA y SOTA, no lo hacemos solo porque se necesitan ahora, sino antes de lo previsto.
Sin embargo, no creo que en el futuro haya una plataforma para todos los autos. , 2-3 . , . — . , .