Si comparan con las funciones con los Sistemas Avanzados de Ayuda a la Conducción (ADAS) de Nivel 1, las funciones de Nivel 2 proporcionan un mayor nivel de sofisticación, como por ejemplo la combinación del control adaptativo de la velocidad de crucero con el asistente de mantenimiento de carril. Estas funciones son una verdadera ayuda para el conductor y representan la oportunidad de generar más márgenes a los fabricantes de automóviles. Pese al mayor rendimiento que ofrecen las funciones del Nivel 2, aún se considera que es el conductor quien maneja el vehículo y sigue siendo el responsable de la seguridad de los pasajeros y del vehículo.
Empezando por los sistemas de Nivel 3, el conductor renuncia de manera condicional a la responsabilidad del sistema ADAS. Un ejemplo es el “chófer en atascos de tráfico”, donde el vehículo se conduce a sí mismo a través de la congestión. Al tratarse de una automatización condicional, el conductor todavía ha de estar preparado para asumir el control del vehículo. En el Nivel 4, las condiciones bajo las cuales el conductor debe tomar el control se ven reducidas, en algunos casos hasta tal punto que cede por completo el control del vehículo.
Figura 1. Los seis niveles de automatización de la conducción de SAE (Fuente: SAE International)
Al pasar del Nivel 2 al Nivel 3 o 4 es necesario dar un importante salto tecnológico para dotar al vehículo de la percepción sensorial y del procesamiento algorítmico suficientes o incluso de Inteligencia Artificial (IA) con el fin de moverse con éxito en el entorno de conducción y de diferenciar qué o quién es el responsable de conducir el vehículo.
Riesgo más elevado
Al desarrollar sistemas de Niveles 3 o 4, el resultado es que la seguridad del pasajero se ve determinada en mucha mayor medida por la eficacia del sistema ADAS de los fabricantes. Estos sistemas serán alabados o criticados por su fiabilidad y confianza, que aumentarán o dañarán la reputación del modelo del vehículo y de su fabricante.
Sin embargo, la seguridad es tan sólo uno de los aspectos que afectan a las ventas y el éxito del vehículo. Los fabricantes de vehículos han de mantener y potenciar su reputación por lo que se refiere al infoentretenimiento del vehículo (IVI). Los modernos sistemas IVI se parecen a un smartphone y utilizan apps para ofrecer contenidos útiles y atractivos. El número de apps y servicios de transmisión de contenidos al vehículo está creciendo, al igual que el nivel de automatización del conductor.
Muchas funciones de un coche nuevo, como la seguridad, el infoentretenimiento y las prestaciones del vehículo (manejo, aceleración, emisiones) son cada vez más el resultado de un software complejo. Esto ha dado lugar al concepto de Vehículo Definido por Software (SDV), según el cual un vehículo se puede actualizar a lo largo de su vida útil, mejorando las funciones existentes y añadiendo otras nuevas. No obstante, la gran mayoría de los sistemas instalados en los vehículos actuales utilizan módulos de hardware especializados para una función determinada. Esto incluye prácticamente a todos los sistemas ADAS más nuevos de Nivel 1 y Nivel 2. Los sistemas que no son definibles por software y carecen de la capacidad de aceptar software avanzado están destinados a realizar únicamente las funciones para las que fueron diseñados. Por tanto ofrecen al fabricante una capacidad limitada o nula de actualización de las funciones del vehículo. La auténtica implantación del SDV exige instalar un hardware capaz de aceptar software nuevo. Son las funciones definibles por software las que crean el potencial de generar nuevas vías de ingresos durante las sucesivas inversiones en el vehículo por parte de los consumidores.
El centro de datos sobre ruedas
Un vehículo moderno suele contener hasta 100 unidades de control electrónico o ECU (Electronic Control Units) que, a su vez, pueden incluir hasta 100 millones de líneas de código de software (a modo de comparación, un avión comercial tiene unos 14 millones). Las principales ECU del vehículo se destinan al motor, la transmisión, la tracción, el freno antibloqueo y el control del airbag. Otras menos relevantes se encargan de controlar la climatización, las ventanas y los asientos, por ejemplo.
Este elevado número de ECU, y su distribución por el vehículo, hace que la arquitectura sea muy compleja. Esta arquitectura no es especialmente eficiente, ni por lo que se refiere a su consumo de energía ni a su capacidad de procesamiento, pues la mayoría de estas ECU no se pueden actualizar o utilizar para otro fin que no sea la tarea para las que fueron diseñadas. La innovación gradual de las prestaciones y las funciones del vehículo se halla tras la proliferación de sistemas basados en ECU. Sin embargo, pasar a un “Vehículo Definido por Software” consiste principalmente en introducir una serie de mejoras y exige evolucionar hacia una arquitectura informática y centralizada de alto rendimiento (high-performance computing, HPC) con algunos añadidos específicos para el automóvil.
Así pues, se puede pensar en el SDV como un centro de datos móvil basado en una HPC. Como la HPC incluye funcionalidades potentes de la CPU, tanto para aplicaciones informáticas en general como de tipo especializado (p.ej., procesamiento de vídeo), se pueden añadir funciones incluso años después de que el vehículo haya salido de la línea de producción, lo cual disminuirá la velocidad a la que se ha depreciado históricamente los vehículos. Las funciones aportadas por el software y disponibles en un vehículo nuevo se puede añadir los vehículos más antiguos siempre que su núcleo HPC sea compatible.
Figura 2. El SDV del mañana será un centro de datos sobre ruedas basado en una estructura informática de alto rendimiento y en interfaces de alta velocidad para la conexión a los sensores distribuidos. Como plataforma, el SDV tendrá conectividad a la nube y admitirá actualizaciones en tiempo real.
En la periferia del vehículo habrá componentes como sensores inteligentes que pueden realizar procesamiento de manera distribuida pero cuya utilidad suele ser limitada, por lo que actualizar su software es menor relevante. Además el paso hacia un procesamiento más centralizado podría anular la necesidad de procesamiento en la periferia del vehículo dependiendo del coste del ancho de banda para transmitir los datos en bruto al compararlo con el coste de preprocesar los datos. RADAR, cámaras de visión, LiDAR, acelerómetros y GPS son sensores que proporcionarán información al vehículo acerca de su entorno. Los datos procedentes de estos sensores pueden servir para realizar diversas tareas de seguridad, prestaciones o entretenimiento, y podrían ser aprovechados por una nueva función añadida al vehículo. Tal función, así como las funciones ADAS y de infoentretenimiento existentes, se hallarían en la HPC.
Dado que la automatización de Nivel 3 y Nivel 4 exige un fuerte aumento del rendimiento informático, es lógico que la implementación de la HPC coincida con la introducción de tales sistemas. La implementación de HPC con ADAS de Nivel 2 (a veces se denomina Nivel 2+) permite ofrecer actualizaciones del sistema ADAS tras la venta del vehículo. El infoentretenimiento ya es en gran parte una función informática con periféricos especializados repartidos por el vehículo (altavoces, micrófonos, pantallas) y por tanto también es lógico incluir el procesamiento de los datos de infoentretenimiento en la HPC.
Los argumentos que se oponen a la HPC en el vehículo suelen ser de dos tipos: complejidad/riesgo y coste del sistema. Ambos se pueden abordar recurriendo a estrategias aplicadas con éxito en otros sectores. El hardware HPC, aunque sus funciones varíen, es una tecnología conocida en los centros de datos. Los servicios de diseño de hardware ya están siendo ofrecidos por los fabricantes de servidores y muchos proveedores directos de los fabricantes de automóviles ya han invertido en sistemas HPC con el fin de cubrir las crecientes necesidades de sus clientes. El uso de arquitecturas de hardware ya existentes permite a los fabricantes centrarse en el desarrollo de software y el suministro de aplicaciones ADAS. Para disminuir la complejidad del software, los fabricantes de componentes ADAS como SoC (System-On-Chips) y conmutadores de red están ampliando su software para liberar del desarrollo al fabricante del automóvil o el integrador de sistemas. Esto permite al desarrollador del sistema centrarse en la integración del sistema y en la normativa, y no en los algoritmos de procesamiento o los drivers de bajo nivel.
El hardware optimizado con estructuras de coste superiores se encuentra en fase de desarrollo para varios niveles de la cadena de suministro, tanto para los sistemas existentes de Nivel 2 como para los sistemas proyectados de Nivel 3. El uso de software estandarizado y común dentro de una arquitectura HPC reduce los costes de desarrollo al fabricante y aporta escalabilidad a las plataformas del vehículo. También disminuye enormemente el riesgo de retiradas provocadas por fallos del software provocados por paquetes de software exclusivos desarrollados para un determinado conjunto de funciones o una plataforma del vehículo.
Los fabricantes de automóviles históricamente han establecido una sola transacción financiera con sus clientes. No existen ingresos tras la venta excepto en los centros de mantenimiento y reparación. Con la llegada del SDV, un factor añadido a la ecuación coste-beneficio es si el sistema puede generar ingresos tras la venta y si esos ingresos se suman a los resultados financieros del fabricante.
El segmento del teléfono móvil ha creado modelos reutilizables para el desarrollo y la distribución de aplicaciones (apps) que mejoran y personalizan sus productos para los consumidores. Lo más importante es que ese sector se beneficia financieramente por el enorme número de desarrolladores de software cuyos productos a menudo son valiosos para un conjunto muy reducido de consumidores, pero que una vez sumados dan como resultado un gigantesco número de propuestas para un número de clientes aún mayor. La industria del automóvil aún tiene que abrir la posibilidad de desarrollar funciones a terceros en forma de apps, si bien varios fabricantes ya disponen de un pequeño número de apps. Por motivos de responsabilidad es necesario garantizar la separación de ciertas capacidades de control. No obstante, tomando como ejemplo el control de crucero, ya se ha demostrado una implementación exitosa de acceso al acelerador en los sistemas del vehículo y sólo queda instalarla de manera controlada dentro de una arquitectura HPC. La generación de nuevas funciones / aplicaciones para vehículos ha permanecido hasta la fecha en gran parte dentro del ámbito de los fabricantes de vehículos, cuyos procesos de desarrollo de software no han sido designados ni optimizados para pequeños grupos de consumidores. Ofrecer una amplia gama de aplicaciones complementarias en el vehículo y generar ingresos de consumidores con especiales intereses o gustos exigirá crear una “tienda de apps” a disposición de desarrolladores y consumidores, así como la posibilidad de acceder a la interfaz estándar para funciones dentro de un sistema HPC.
Un ejemplo de posible función que no es ni ADAS ni infoentretenimiento es que los vehículos puedan recoger datos de los sensores y utilizarlos para el seguimiento, el control y el análisis del desgaste de las piezas (p.ej., del sistema de suspensión) y prever su mantenimiento. Estas previsiones se pueden basar en los resultados de algoritmos avanzados de detección de anomalías que identifican tendencias. Esto permite programar el mantenimiento en función del desgaste en lugar del planteamiento tradicional basado en el tiempo transcurrido o la distancia recorrida. Incluso puede ser posible ajustar de inmediato uno o más parámetros operativos a través de un parche de software en tiempo real.
La capacidad de los fabricantes de cargar las actualizaciones de funciones por software ya es habitual en algunos casos. Las actualizaciones suelen exigir devolver el vehículo a un taller en el que se efectúa la transferencia a través de un cable de datos, si bien ya se pueden encontrar algunos ejemplos de actualizaciones realizadas por el usuario mediante puertos USB. Las actualizaciones inalámbricas están llamadas a convertirse en la norma para las actualizaciones de software en el futuro. Si se comparan con los requisitos actuales para llevar a cabo las actualizaciones en un centro de servicio certificado, las actualizaciones inalámbricas por retiradas por motivos de seguridad, emisiones o rendimiento ofrecen una oportunidad destacable de reducir los costes del fabricante siempre que el vehículo inicial contenga el hardware adecuado para admitir este tipo de actualizaciones y la incorporación de nuevas funciones.
Resumen
Los sistemas avanzados de ayuda a la conducción con un elemento crítico en el diseño del automóvil. Además de ofrecer seguridad, los fabricantes de automóviles tratan de potenciar las prestaciones de los ADAS para elevar aún más los niveles de autonomía de los vehículos para razones de seguridad y facilidad de uso. Esto, junto con las expectativas del usuario sobre infoentretenimiento, personalización y experiencia del usuario, significa que los coches están evolucionando de productos definidos tradicionalmente por su manejo, potencia, velocidad y estética a definidos por su experiencia en el habitáculo y su capacidad de mejora mediante actualizaciones y apps de terceros.
Para proporcionar los niveles requeridos de rendimiento/seguridad y funciones que marquen diferencias en el mercado, los vehículos se están convirtiendo en centros de datos HPC definidos por software sobre ruedas. Esta transición está llevando a los fabricantes a adoptar modelos de coste de forma distinta ya que algunas inversiones en hardware se amortizarán a más largo plazo. El sector de la automoción ha contemplado históricamente la venta de cada vehículo como un solo ingreso que cubre los gastos de capital correspondientes al desarrollo y la fabricación con el fin de cumplir los objetivos de crecimiento de los beneficios y del negocio. Los SDV con conectividad a los servidores del fabricante mediante la nube ofrecen la oportunidad de introducir modelos de suscripción y descargas de aplicaciones.
Autor: Daniel Leih, Director de Marketing de Producto del Grupo de USB y Redes de Microchip Technology
