Software sobre A2B: cómo la A2B está cambiando las reglas del juego para la SOTA en las aplicaciones de automoción

Resumen

El software en el aire (SOTA) está emergiendo rápidamente como una capacidad vital para que los OEMs de automoción lo desarrollen y desplieguen. La posibilidad de actualizar los módulos, dar soporte a los clientes y monetizar las funciones adicionales hace que dominar el SOTA sea una propuesta atractiva. Este artículo explica por qué ha surgido la SOTA en el entorno de la automoción, cómo puede desplegarse y cómo A²B^® puede utilizarse para implementar el SOTA en las redes de audio e infoentretenimiento.

Introducción

Si un consumidor tuviera que clasificar la complejidad del software de sus productos, ¿qué encabezaría la lista? ¿Su portátil? ¿Su smartphone? ¿Su consola de juegos? El hecho de que el vehículo que tienen en la entrada de su casa probablemente supere en un orden de magnitud a todos estos dispositivos puede resultar sorprendente. El coche moderno medio tiene hasta 150 unidades de control electrónico (ECU) que ejecutan hasta 100 millones de líneas de código. En comparación, el avión de combate F-35 tiene menos de 25 millones de líneas de código, el sistema operativo Android menos de 15 millones de líneas de código y Google Chrome menos de 10 millones de líneas de código.¹

La abundancia de software que surge en las aplicaciones de automoción requiere un método para mantener y controlar la miríada de versiones y revisiones de software presentes en todo el vehículo. Los beneficios resultantes para un fabricante de automóviles, u OEM, que aprovecha las actualizaciones de SOTA pueden ir desde la resolución de problemas menores del vehículo hasta la respuesta a catástrofes naturales. Tesla demostró una de las aplicaciones más reconocidas de las actualizaciones de SOTA en respuesta al huracán Irma en septiembre de 2017. Mientras la tormenta azotaba el estado norteamericano de Florida, Tesla respondió a las peticiones de los clientes publicando una actualización de la SOTA para desbloquear la autonomía adicional de sus vehículos y ayudar a los propietarios que intentaban apartarse del camino del inminente huracán.² Otros fabricantes de equipos originales han visto expuestas las deficiencias en las capacidades SOTA de sus vehículos, lo que ha provocado daños en la reputación y la pérdida de confianza de los consumidores.

Con las megatendencias emergentes, como la electrificación de los vehículos y la conducción autónoma, que aumentan aún más el número de ECUs y de líneas de código en el vehículo, también se acelera la importancia de garantizar unas capacidades SOTA robustas y eficientes en cada área del vehículo.

Las ECUs han formado parte del paisaje automovilístico desde que se utilizó por primera vez un microcontrolador para controlar la sincronización del encendido en el Oldsmobile Toronado de 1977.³ Las primeras implementaciones de actualizaciones de software requerían la retirada de la ECU del vehículo para su reprogramación, un proceso potencialmente largo y laborioso. Retirar una ECU de gestión del motor de un vano motor puede ser sencillo. En comparación, desmontar una unidad principal de radio puede requerir un extenso desmontaje del salpicadero, la consola central y otros adornos. Una vez extraídas del vehículo, las primeras ECUs requerían una reprogramación con herramientas complicadas, como los programadores de cama, que son caros, complejos y a veces temperamentales. Estos factores se combinaron para que la emisión de actualizaciones de software para las primeras ECUs fuera menos atractiva que la simple sustitución de la unidad por otro módulo.

Software por aire

La SOTA es un punto álgido en el desarrollo de las actualizaciones de software en la industria del automóvil, salvando la distancia entre las primeras ECUs y la infraestructura automovilística actual, flexible y altamente conectada. La posibilidad de actualizar las ECUs in situ en el vehículo no sólo es atractiva, sino que se está convirtiendo en una capacidad cada vez más importante para los fabricantes de automóviles. Ya hemos visto cómo los fabricantes de equipos originales pueden utilizar la SOTA para ofrecer una funcionalidad que puede salvar vidas de forma ágil y con capacidad de respuesta. Uno de los casos de uso más obvios de la SOTA es permitir a los fabricantes de equipos originales resolver los problemas críticos de software de sus vehículos en función de las necesidades. Se trata de una capacidad excepcionalmente poderosa, ya que puede eliminar la necesidad de realizar retiradas de vehículos relacionadas con el software, mejorando la experiencia de propiedad para el consumidor y reduciendo los costes de retirada para el OEM. La posibilidad de aplicar actualizaciones de software de forma controlada, sin que el vehículo tenga que acudir a un concesionario, añade un valor significativo al OEM.

La SOTA tiene el potencial de simplificar muchos otros elementos del ciclo de vida del vehículo, no sólo de agilizar la administración de las retiradas de software. El SOTA puede utilizarse durante el proceso de producción para garantizar que el firmware del vehículo es correcto antes de que el coche se complete y se envíe. Dado que los plazos de envío de los vehículos oscilan entre unos días (por ejemplo, el mercado nacional del OEM) y varias semanas (por ejemplo, los mercados de ultramar), existe un riesgo importante de que sea necesario actualizar el software cuando el vehículo llegue a su mercado de destino. La posibilidad de actualizar eficazmente las ECUs de un vehículo durante su inspección previa a la entrega (PDI), en el puerto de recepción o en el concesionario proveedor, garantiza que el vehículo llegue a las instalaciones de su nuevo propietario funcionando exactamente como desea. Esto es especialmente valioso para los modelos en las primeras fases de su ciclo de vida, que pueden sufrir frecuentes actualizaciones de software.

Pueden existir otras oportunidades para la SOTA cuando los fabricantes de equipos originales busquen crear la posibilidad de que los consumidores desbloqueen temporal o permanentemente funciones adicionales en sus vehículos. Tomemos como ejemplo el sistema de infoentretenimiento; en el futuro, los OEM podrían ofrecer a los clientes la posibilidad de actualizar el software que se ejecuta en su vehículo según sus necesidades. Para la conducción diaria, una configuración de audio estándar puede ser suficiente para escuchar la radio o hacer llamadas de manos libres mientras conduces. Para los viajes largos o las vacaciones, el OEM podría ofrecer opciones de actualización a un sistema de audio de alta definición o algoritmos de procesamiento de audio para optimizar la distribución del sonido en el vehículo. La SOTA podría utilizarse para facilitar estas actualizaciones a los pocos minutos de la transacción, creando lucrativas fuentes de ingresos adicionales para los OEM.

Consideraciones sobre la SOTA

Antes de que un OEM considere la posibilidad de implantar la SOTA en un vehículo, hay que tener en cuenta varias características del sistema, como la cantidad de ancho de banda que se necesita, cómo se coordinará la transmisión entre los nodos y si se necesita seguridad.

El ancho de banda que ofrece la solución SOTA debe considerarse en el contexto del tamaño típico del archivo de actualización del software y del tiempo que se dispondrá para transferir la actualización del software por la red. Aunque muchas descargas de software se proporcionan en formato delta, que contiene sólo los componentes del software que hay que cambiar, el tamaño del archivo puede seguir siendo de decenas de megabytes. Si el ancho de banda disponible es del orden de unos pocos kilobytes, la descarga de una actualización de software puede llevar decenas de minutos en lugar de los minutos o segundos que pueden ser más prácticos en un contexto de servicio.

Las consideraciones sobre la coordinación de la transmisión incluyen los aspectos del protocolo necesarios para garantizar la transferencia fiable de la información a través de la red: el handshaking, la detección y la corrección de errores. El Handshaking es el proceso por el que los nodos SOTA negocian y confirman la transferencia de datos a través del enlace, por ejemplo, asegurándose de que cada bloque de la transferencia se ha completado con éxito antes de transferir el siguiente. La detección de errores es el proceso por el que los nodos SOTA controlan los datos transferidos por el enlace para identificar los errores que se han producido durante la transmisión. Por ejemplo, los valores de Comprobación de Redundancia Cíclica (CRC) calculados en los nodos de origen y destino suelen utilizarse para cumplir estos requisitos. La corrección de errores es el proceso por el que los nodos SOTA responden a las condiciones de error y las recuperan, si es posible. Existen varias técnicas para aplicar la corrección de errores, desde pedir al nodo fuente que retransmita el bloque de datos recibido erróneamente hasta utilizar esquemas como la corrección de errores hacia delante (FEC) para reparar los datos corruptos.

Dependiendo del ancho de banda que ofrezca la solución SOTA y de los requisitos de coordinación de la transmisión, puede ser necesario implementar la transferencia de datos y la coordinación de la transmisión a través de diferentes redes. Dado que las ECUs de los automóviles suelen estar equipadas con varias interfaces de comunicación (A²B, CAN, LIN, CXPI, Ethernet, FlexRay, etc.) con una carga variable, esto no suele ser un problema. Sin embargo, obviamente es preferible acomodar tanto la transmisión de datos como la coordinación de la transmisión en el mismo enlace, si es posible.

Las consecuencias de una debilidad de seguridad en una red de automoción se han puesto de manifiesto en varias ocasiones, cuando hackers éticos han tomado el control de las redes de los vehículos y han demostrado los riesgos que conlleva la realización de funciones como los limpiaparabrisas, los equipos de música e incluso el frenado. Estas deficiencias podrían ser calamitosas para la seguridad de los ocupantes del vehículo y de otros usuarios de la carretera. Los fabricantes de equipos originales deben tomar medidas para garantizar que una autenticación adecuada en todas las redes de los vehículos impida el acceso de nodos o usuarios no autorizados.

Varias de las redes de automoción ya mencionadas pueden utilizarse en las arquitecturas SOTA, por ejemplo CAN o Ethernet. En los últimos años, A²B de Analog Devices se ha establecido como la elección de facto para satisfacer las demandas de un sistema de audio cada vez más complejo. Al ofrecer importantes ventajas de ancho de banda de audio respecto a otras soluciones de conectividad, A²B también ofrece la posibilidad de transferir datos, lo que permite a los fabricantes de equipos originales integrar las capacidades SOTA en sus redes de audio sin necesidad de hardware adicional.

A2Resumen B

A²B es un bus digital bidireccional de gran ancho de banda, diseñado originalmente para resolver los problemas de distribución de audio que surgen en las aplicaciones de automoción. Las arquitecturas de audio existentes en los automóviles suelen implicar múltiples conexiones analógicas punto a punto entre unidades principales, amplificadores, altavoces y micrófonos. A²B aborda muchos de los retos que caracterizan a las conexiones analógicas punto a punto: el peso del cable, su coste, las dificultades de encaminamiento y los problemas de fiabilidad asociados a las conexiones múltiples. A²B facilita el transporte de datos de audio totalmente sincronizados (I²S/TDM/PDM) y los datos de control (I²C/SPI) a lo largo de un sistema de audio distribuido de varios nodos utilizando una infraestructura de cables y conectores de par trenzado no apantallado (UTP).

Se admiten hasta 32 canales de audio en el A²B en sentido ascendente y descendente, lo que supone un ancho de banda total de 50 Mbps. A²B tiene una latencia determinista inferior a 50 μs, lo que la hace muy atractiva para aplicaciones sensibles a la latencia, como la cancelación activa del ruido (ANC), la cancelación del ruido de la carretera (RNC), la cancelación del eco acústico y la reducción del ruido (AEC-NR), y la formación del haz (BF).

A²B admite varias topologías diferentes, como punto a punto, en cadena y en rama, lo que lo hace adecuado para una amplia variedad de aplicaciones de automoción, que van desde los sistemas de infoentretenimiento de nivel básico con una unidad principal y un módulo de micrófono hasta sistemas de audio más complejos, como el RNC con una ECU combinada con varios micrófonos, altavoces y acelerómetros.

Una A²La red B está formada por un nodo principal y hasta 16 subnodos, con una longitud máxima de cable entre los nodos de 15 m y una longitud máxima de cable entre el nodo principal y el último subnodo de 80 m (incluidas las ramas). Un nodo principal contiene un A²Transceptor B conectado a un procesador anfitrión que puede enviar datos de audio, datos de control e I²Los datos de C/SPI sobre A²Bus de audio B. Los subnodos, cuya complejidad varía desde complejos amplificadores de potencia con amplio procesamiento hasta simples nodos de micrófono, contienen A²B que interactúan con una amplia gama de periféricos, como micrófonos, procesadores de señales digitales (DSP), altavoces, sensores (por ejemplo, un acelerómetro) o amplificadores de clase D.

Los dispositivos transceptores primario y secundario admiten diversas funciones de valor añadido, como las entradas de micrófono de multiplexación por división de tiempo (TDM) y de modulación por densidad de impulsos (PDM). Los derivados de bajo coste de A²Hay transceptores B con conjuntos de características optimizadas, como un transceptor de subnodos finales (sin soporte TDM) y un transceptor de nodo principal optimizado (longitud de cable reducida, menos subnodos).

Además de apoyar a A²Los nodos B, que se abastecen localmente, A²B proporciona alimentación de bus para facilitar las arquitecturas de sistemas de audio más exigentes, como los sintonizadores remotos motorizados y las funciones de audio innovadoras, como los altavoces de reposacabezas compatibles con la Clase D. La última generación de A²B (AD243x) es capaz de soportar el modo de potencia estándar del bus (hasta 2,7 W) o el modo de alta potencia (hasta 50 W).

Diseñado desde el principio como un eslabón del automóvil, A²B tiene un rendimiento EMI/EMC de primera clase con varias consideraciones de diseño específicas (por ejemplo, niveles de potencia de salida configurables) integradas en el transceptor para facilitar los retos de EMC a los que suelen enfrentarse los OEM y los fabricantes de automóviles. A²B se ha sometido a todas las pruebas de compatibilidad electromagnética de los automóviles, por ejemplo, CISPR 25 Clase 5 (emisiones), ISO 11452-2/ISO 11452-4/ISO 11452-9, ISO 7637-3 (inmunidad) e ISO 10605 (ESD).

Transmisión de datos en A2B

Además de soportar la transmisión de audio, A²B también facilita varios mecanismos para transmitir otras formas de datos a través del bus. Una de las construcciones fundamentales de A²B que permite la transmisión de audio y datos en el bus es la supertrama, una estructura formada por varias ranuras de datos síncronos descendentes y ascendentes, tramas de control de sincronización y tramas de respuesta de sincronización. Mientras que las ranuras de datos síncronos llevan I²Aunque los canales S y TDM se utilizan en aplicaciones de audio, también pueden usarse para transportar otros tipos de datos para cumplir los requisitos de las aplicaciones SOTA.

El nodo principal inicia la transmisión de una supertrama, añadiendo la sincronizada (audio) y la asincrónica (I²C/SPI) después de la trama de control de sincronización. Cada subnodo puede utilizar o consumir parte de los datos descendentes y añadir datos para otros nodos descendentes. El último subnodo del bus construye la parte ascendente de la supertrama, y cada nodo añade cualquier dato sincrónico adicional después de la trama de respuesta de sincronización. Cada nodo puede utilizar o consumir los datos anteriores.

Otro mecanismo de transporte de datos soportado por varias generaciones de A²B es el buzón. Los buzones pueden ser utilizados por los nodos primarios y secundarios para enviar I²C a través de la red: del nodo principal al subnodo o del subnodo al nodo principal. Los buzones se suelen utilizar para establecer el handshaking entre el host del nodo principal (por ejemplo, una unidad principal) y el procesador del subnodo (por ejemplo, un amplificador).

El procesador anfitrión puede iniciar la comunicación con un procesador de subnodo cargando los datos deseados, a través del A²B, en los registros del buzón del subnodo A²Transceptor B. El transceptor A²El transceptor del subnodo avisa al procesador del subnodo de la presencia de una I²C a través del pin de interrupción. El procesador del subnodo puede leer el mensaje directamente a través de I²C de la A²Transceptor B. El procesador del subnodo puede iniciar la comunicación con el host del nodo principal cargando los datos deseados para su transmisión en el I²C en el transceptor del subnodo. La A²El transceptor B del nodo cabeza alerta al anfitrión de la presencia de una I²C en el transceptor del subnodo a través del pin de interrupción. A continuación, el host puede optar por leer los datos de los registros del buzón del subnodo a través del A²Autobús B.

Un tercer mecanismo de transporte, introducido en la última generación del A²B de la familia de transceptores (AD243x), es la transferencia de datos SPI a lo largo de la distancia en las ranuras síncronas del A²Superframe B. EL A²La interfaz SPI del transceptor B puede utilizarse para varias aplicaciones diferentes: para configurar el A²B a velocidades de reloj SPI de hasta 10 MHz, para acceder directamente a los registros y a la información de estado de un transceptor de un subnodo, para comunicarse con un dispositivo habilitado para SPI en un subnodo, o incluso para facilitar la comunicación SPI a SPI entre subnodos sin la intervención del nodo principal. Las generaciones anteriores de A²Los transceptores B, que no tienen interfaz SPI, pueden transmitir de forma transparente supertramas con datos SPI ascendentes y descendentes a otros nodos de la red.

A2B Software de referencia

A²B tiene unos requisitos mínimos de procesamiento en toda la red, y el controlador anfitrión tiene la capacidad de realizar una inicialización completa de toda la red de forma remota. Para apoyar la configuración de la red y la interacción con la red configurada (por ejemplo, control de eventos/interrupciones, sondeo de registros), ADI ofrece un completo paquete de software acreditado por la ISO/IEC 15504 (SPICE automotive). El software está disponible en varias variantes, incluidas las compatibles con Embedded C, Linux^®android y QNX, para ayudar a reducir el tiempo de comercialización de los clientes y garantizar la coherencia con las mejores prácticas de configuración del transceptor.

Además del software propuesto para apoyar el funcionamiento básico del A²B, existe un software opcional para ayudar a los clientes a realizar funciones como la transmisión de datos a través de A²B. Existen paquetes de software para aprovechar la A²B ya comentadas y como se muestra en la figura 3. EL A²El software complementario del canal de comunicación B aprovecha el A²El buzón B transfiere información entre los nodos de la red. EL A²El software complementario de la tubería de datos B aprovecha el A²B ranuras síncronas para transferir información entre los nodos de la red. EL A²El software complementario del túnel de datos B aprovecha el A²B Datos SPI sobre la distancia de transferencia de información entre los nodos de la red.

La combinación de A²La función de buzón B con el software complementario del canal de comunicación ofrece una velocidad de datos de hasta 15 kbps. Aunque es útil para aplicaciones como el diagnóstico, la velocidad de datos que ofrece la función de buzón es insuficiente para aplicaciones que requieren un gran ancho de banda, como la SOTA.

La combinación de A²Las ranuras B síncronas con la extensión de software de la tubería de datos pueden proporcionar una velocidad de datos de más de 1 Mbps. Esto permite unas velocidades de comunicación más atractivas para las aplicaciones SOTA, por ejemplo transfiriendo un archivo de 20 MB en 20 segundos. La combinación de datos SPI a distancia con A²El software adicional del túnel de datos B puede proporcionar una velocidad de datos de más de 16 Mbps. Esto proporciona la mayor velocidad de transmisión de datos posible en el A²B - por ejemplo, transferir un archivo de 100 MB en menos de 7 segundos.

A2Herramientas B

A²B también es compatible con SigmaStudio^®la herramienta de diseño de algoritmos y redes líder del sector de Analog Devices. SigmaStudio soporta todos los aspectos de A²Proceso de diseño B - arrastrar y soltar el diseño de la red desde A²B y los dispositivos auxiliares, la configuración de los nodos, el análisis de la tasa de error de bits, el cálculo del ancho de banda y el cálculo de la potencia. SigmaStudio combina los datos suministrados y genera archivos .c y .h para su integración en el software de aplicación del cliente.

Los equipos de prueba son una parte importante del ecosistema de cualquier tecnología de automoción, y A²B no es diferente. Analog Devices se unirá a otros proveedores de equipos de prueba de confianza que ya ofrecen A²B analizadores y monitores con función completa A²Analizador de bus B desarrollado para soportar todas las características de la nueva familia de productos AD243x

Una A²El analizador B puede emular un nodo primario o secundario en un nodo A²Red B. Esto puede ayudar a la hora de diseñar y crear el prototipo de una red A²Red B. Una red A²El monitor B funciona como un nodo de vigilancia pasiva en una red A²Red B, observador A²B de audio y datos que pasan por el nodo, mientras que soporta la entrada y salida de audio. Estas herramientas ayudan a reducir el tiempo de comercialización y la complejidad del diseño para los clientes. También aceleran la depuración y la investigación de cualquier problema observado en cualquier fase de A²Diseño B.

A²B tiene varios socios de servicios de diseño de terceros con un historial probado de proporcionar A²B en el mercado. Estos socios ofrecen una serie de servicios que van desde módulos de hardware listos para usar hasta el diseño de hardware personalizado y el apoyo al diseño de software.

Se recomiendan cuatro genéricos de la familia AD243x para aplicaciones de automoción, con un resumen en la Tabla 1.

EL A²B se apoya en una gama de placas de evaluación de productos de Analog Devices que cubren los distintos genéricos de A²Transceptores B. Estas tarjetas se complementan con otras A²Mapas B ofrecidos por una serie de servicios de diseño de terceros.

Resumen

A²B está ampliamente reconocida como la opción de facto para las redes de audio en el mercado del automóvil. Tanto si se trata de un sistema de distribución de audio como de funciones acústicas, como la cancelación del ruido de la carretera o la reducción del ruido, las numerosas ventajas que ofrece A²B, como la baja latencia y el excelente rendimiento de la EMC, son bien conocidos y comprendidos. La A²La Cartera B también tiene la capacidad de transportar datos que no sean de audio en la misma red, lo que abre varias opciones nuevas para los diseñadores de sistemas, incluida la capacidad de soportar fácil y eficazmente el SOTA a través de la red de audio.

Para más información sobre la Serie A²Tecnología B, descubre A²B de garantía, y aprender más sobre A²B, consulta analog.com/a2b. Para más información sobre la A²B que ofrece Analog Devices, consulta analog.com/es/design-center/evaluation-hardware-and-software/software/a2b-software.html.

Referencias

¹Bases de código: millones de líneas de código. La información es preciosa.

² Simon Usborne. "¿Cómo consiguió Tesla que algunos de sus coches viajaran más lejos durante el huracán Irma?" The Guardianseptiembre de 2017.

³ Robert Charette. "Este coche funciona con un código." IEEE Spectrum, febrero de 2009.