Share via


Arquitectura de referencia de análisis y datos y mensajería automotriz

Esta arquitectura de referencia está diseñada para admitir OEM de automoción y proveedores de movilidad en el desarrollo de aplicaciones avanzadas de vehículos conectados y servicios digitales. Su objetivo es proporcionar una infraestructura de mensajería, datos y análisis confiable y eficaz. La arquitectura incluye funcionalidades de procesamiento de mensajes, procesamiento de comandos y almacenamiento de estado para facilitar la integración de varios servicios a través de API administradas. También describe una solución de datos y análisis que garantiza el almacenamiento y la accesibilidad de los datos de forma escalable y segura para la ingeniería digital y el uso compartido de datos con el ecosistema de movilidad más amplio.

Architecture

Diagrama de la arquitectura de alto nivel.

En el diagrama de arquitectura de alto nivel se muestran los principales bloques lógicos y servicios de una solución de mensajería automotriz de análisis y datos. Encontrará más detalles en las secciones siguientes.

  • El vehículo contiene una colección de dispositivos. Algunos de estos dispositivos están definidos por software y pueden ejecutar cargas de trabajo de software administradas desde la nube. El vehículo recopila y procesa una amplia variedad de datos, desde la información del sensor de dispositivos electromecánicos, como el sistema de administración de baterías hasta archivos de registro de software.
  • Los servicios de mensajería del vehículo administran la comunicación hacia y desde el vehículo. Se encarga de procesar mensajes, ejecutar comandos mediante flujos de trabajo y mediar el vehículo, el back-end de administración de usuarios y dispositivos. También realiza un seguimiento del registro y el aprovisionamiento de vehículos, dispositivos y certificados.
  • El back-end de administración de vehículos y dispositivos es el sistemas de OEM que realiza un seguimiento de la configuración del vehículo desde la fábrica hasta la reparación y el mantenimiento.
  • El operador dispone de TI y operaciones para asegurar la disponibilidad y el rendimiento tanto de los vehículos como del back-end.
  • Los servicios de análisis y datos proporcionan almacenamiento de datos y permiten el procesamiento y el análisis de todos los usuarios de datos. Convierte los datos en conclusiones que impulsan mejores decisiones empresariales.
  • El fabricante del vehículo proporciona servicios digitales como valor añadido al cliente final, desde aplicaciones complementarias hasta aplicaciones de reparación y mantenimiento.
  • Varios servicios digitales requieren integración empresarial en sistemas de back-end, como administración de distribuidores (DMS), administración de relaciones con clientes (CRM) o sistemas de planificación de recursos empresariales (ERP).
  • El back-end de administración de consentimiento forma parte de la administración de clientes y realiza un seguimiento de la autorización del usuario para la recopilación de datos según la legislación geográfica de la región y del país.
  • Los datos recopilados de los vehículos son una entrada al proceso de ingeniería digital , con el objetivo de mejorar continuamente los productos mediante el análisis y el aprendizaje automático.
  • El ecosistema de movilidad inteligente puede suscribirse y consumir datos de telemetría activos, así como información agregada para proporcionar más productos y servicios.

Microsoft es miembro del grupo de trabajo Eclipse Software Defined Vehicle, un foro para la colaboración abierta mediante código abierto para plataformas de software de vehículos.

Flujo de datos

La arquitectura usa el patrón de mensajería del publicador o suscriptor para desacoplar los vehículos de los servicios.

Mensajes de vehículo a nube

El flujo de datos del vehículo a la nube se usa para procesar los datos de telemetría del vehículo. Los datos de telemetría se pueden enviar periódicamente (estado del vehículo, recopilación de sensores del vehículo) o en función de un evento (desencadenadores en condiciones de error, reacción a una acción del usuario).

Diagrama del flujo de datos de mensajería.

  1. El vehículo está configurado para un cliente en función de las opciones seleccionadas mediante las API de administración. La configuración contiene:
    1. Información de aprovisionamiento para vehículos y dispositivos.
    2. Configuración inicial de recopilación de datos de vehículos en función de las consideraciones empresariales y de mercado.
    3. Almacenamiento de la configuración inicial del consentimiento del usuario en función de las opciones del vehículo y la aceptación del usuario.
  2. El vehículo publica los mensajes de telemetría y eventos a través de un cliente MQTT (Transporte de telemetría de cola de mensajes) con temas definidos a la característica de agente MQTT de Event Grid en los servicios de mensajería del vehículo.
  3. Event Grid enruta los mensajes a distintos suscriptores en función de los atributos de tema y mensaje.
    1. Los mensajes de prioridad baja que no requieren procesamiento inmediato (por ejemplo, mensajes de análisis) se enrutan directamente al almacenamiento mediante una instancia de Event Hubs para el almacenamiento en búfer.
    2. Los mensajes de prioridad alta que requieren procesamiento inmediato (por ejemplo, los cambios de estado que se deben visualizar en una aplicación orientada al usuario) se enrutan a una función de Azure mediante una instancia de Event Hubs para almacenar en búfer.
  4. Los mensajes de prioridad baja se almacenan directamente en el lago de datos mediante la captura de eventos. Estos mensajes pueden usar la descodificación y el procesamiento por lotes para obtener costos óptimos.
  5. Los mensajes de prioridad alta se procesan con una función de Azure. La función lee la configuración del vehículo, el dispositivo y el consentimiento del usuario desde el Registro de dispositivos y realiza los pasos siguientes:
    1. Comprueba que el vehículo y el dispositivo están registrados y activos.
    2. Comprueba que el usuario ha dado su consentimiento para el tema del mensaje.
    3. Descodifica y enriquece la carga.
    4. Agrega más información de enrutamiento.
  6. El Centro de eventos de telemetría en directo de la solución de datos y análisis recibe los mensajes descodificados. Azure Data Explorer usa la ingesta de streaming para procesar y almacenar mensajes a medida que se reciben.
  7. La capa de servicios digitales recibe mensajes descodificados. Service Bus proporciona notificaciones a las aplicaciones sobre cambios o eventos importantes en el estado del vehículo. Azure Data Explorer proporciona el último estado conocido del vehículo y el historial a corto plazo.

Mensajes de nube a vehículo

El flujo de datos de la nube al vehículo se usa a menudo para ejecutar comandos remotos en el vehículo desde un servicio digital. Estos comandos incluyen casos de uso como el bloqueo/desbloqueo de la puerta, la climatización (establecer la temperatura preferida del habitáculo) o cambios en la configuración. La ejecución correcta depende del estado del vehículo y puede requerir algún tiempo para completarse.

Según las capacidades del vehículo y el tipo de acción, hay varios enfoques posibles para la ejecución de comandos. Trataremos dos variaciones:

  • Mensajes directos de la nube al dispositivo (A) que no requieren una comprobación del consentimiento del usuario y con un tiempo de respuesta predecible. Esto abarca los mensajes tanto a vehículos individuales como a varios. Un ejemplo incluye notificaciones meteorológicas.
  • Comandos del vehículo (B) que usan el estado del vehículo para determinar el éxito y requieren el consentimiento del usuario. La solución de mensajería debe tener una lógica de flujo de trabajo de comandos que compruebe el consentimiento del usuario, realice un seguimiento del estado de ejecución del comando y notifique al servicio digital cuando haya terminado.

Los siguientes comandos de usuarios de flujo de datos emitidos desde un servicio digital de aplicación complementaria como ejemplo.

Diagrama del flujo de datos de mando y control.

Los mensajes directos se ejecutan con la cantidad mínima de saltos para obtener el mejor rendimiento posible (A)::

  1. La aplicación complementaria es un servicio autenticado que puede publicar mensajes en Event Grid.
  2. Event Grid comprueba la autorización del servicio de la aplicación complementaria para determinar si puede enviar mensajes a los temas proporcionados.
  3. La aplicación complementaria se suscribe a las respuestas de la combinación de comandos o vehículo específica.

Cuando los comandos dependientes del estado del vehículo que requieren el consentimiento del usuario (B)::

  1. El propietario o el usuario del vehículo dan su consentimiento para la ejecución de funciones de comando y control en un servicio digital (en este ejemplo, una aplicación complementaria). Esto se hace normalmente cuando el usuario descarga o activa la aplicación y el OEM activa su cuenta. Esto desencadena un cambio de configuración en el vehículo para suscribirse al tema de comandos asociado en el agente MQTT.
  2. La aplicación complementaria usa el comando y la API administrada de control para solicitar la ejecución de un comando remoto.
    1. La ejecución del comando puede tener más parámetros para configurar opciones como el tiempo de espera, las opciones de almacenamiento y reenvío, etc.
    2. La lógica de comandos decide cómo procesar el comando en función del tema y otras propiedades.
    3. La lógica de flujo de trabajo crea un estado para realizar un seguimiento del estado de la ejecución.
  3. La lógica del flujo de trabajo de comandos comprueba la información de consentimiento del usuario para determinar si se puede ejecutar el mensaje.
  4. La lógica del flujo de trabajo de comandos publica un mensaje en Event Grid con el comando y los valores de parámetro.
  5. El módulo de mensajería del vehículo se suscribe al tema de comandos y recibe la notificación. Enruta el comando a la carga de trabajo correcta.
  6. El módulo de mensajería supervisa la carga de trabajo para su finalización (o error). Una carga de trabajo se encarga de la ejecución (física) del comando.
  7. El módulo de mensajería publica informes de estado de comandos en Event Grid.
  8. El módulo de flujo de trabajo se suscribe a las actualizaciones de estado del comando y actualiza el estado interno de la ejecución del comando.
  9. Una vez completada la ejecución del comando, la aplicación de servicio recibe el resultado de la ejecución sobre el comando y la API de control.

Aprovisionamiento de dispositivos y vehículos

Este flujo de datos abarca el proceso para registrar y aprovisionar vehículos y dispositivos en los servicios de mensajería de vehículos. El proceso se inicia normalmente como parte de la fabricación de vehículos.

Diagrama del flujo de datos de aprovisionamiento.

  1. El sistema de fábrica encarga el dispositivo del vehículo al estado de construcción deseado. Esto puede incluir la instalación inicial y la configuración del firmware y el software. Como parte de este proceso, el sistema de fábrica obtendrá y escribirá el certificado de dispositivo, creado a partir del proveedor de Infraestructura de clave pública .
  2. El Sistema de fábrica registra el vehículo y el dispositivo usando la API de aprovisionamiento de vehículos y dispositivos.
  3. El sistema de fábrica desencadena el cliente de aprovisionamiento de dispositivos para conectarse al registro de dispositivos y aprovisionar el dispositivo. El dispositivo recupera información de conexión para el agente MQTT.
  4. La aplicación de registro de dispositivos crea la identidad del dispositivo con el agente MQTT.
  5. El sistema de fábrica desencadena el dispositivo para establecer una conexión con el agente MQTT por primera vez.
    1. El agente de MQTT autentica el dispositivo mediante el certificado raíz de CA y extrae la información del cliente.
  6. El agente MQTT administra la autorización para los temas permitidos usando el registro local.
  7. En caso de sustitución de piezas, el sistema de distribuidores de OEM puede desencadenar el registro de un nuevo dispositivo.

Nota:

Los sistemas de fábrica suelen ser locales y no tienen conexión directa con la nube.

Análisis de datos

Este flujo de datos abarca el análisis de los datos del vehículo. Puede usar otros orígenes de datos, como los operadores de fábrica o taller, para enriquecer y proporcionar contexto a los datos del vehículo.

Diagrama de análisis de datos.

  1. El nivel de servicios de mensajería del vehículo proporciona telemetría, eventos, comandos y mensajes de configuración desde la comunicación bidireccional al vehículo.
  2. La capa TI y operaciones proporciona información sobre el software que se ejecuta en el vehículo y los servicios en la nube asociados.
  3. Varias canalizaciones proporcionan procesamiento de los datos en un estado más refinado
    • Procesamiento de datos sin procesar a datos enriquecidos y desduplicados del vehículo.
    • Agregación de datos de vehículos, indicadores clave de rendimiento e información.
    • Generación de datos de entrenamiento para el aprendizaje automático.
  4. Las diferentes aplicaciones consumen datos refinados y agregados.
    • Visualización mediante Power BI.
    • Flujos de trabajo de integración empresarial mediante Logic Apps con integración en Dataverse.
  5. Los datos de entrenamiento generados se consumen mediante herramientas como ML Studio para generar modelos de aprendizaje automático.

Escalabilidad

Una solución de datos y vehículos conectados se puede escalar a millones de vehículos y miles de servicios. Se recomienda usar el patrón de sellos de implementación para lograr escalabilidad y elasticidad.

Diagrama del concepto de escalabilidad.

Cada unidad de escalado de mensajería de vehículos admite una población de vehículos definida (por ejemplo, vehículos en una región geográfica específica, particionada por año modelo). La unidad de escalado de aplicaciones se usa para escalar los servicios que requieren enviar o recibir mensajes a los vehículos. El servicio común es accesible desde cualquier unidad de escalado y proporciona servicios de administración y suscripción de dispositivos para aplicaciones y dispositivos.

  1. La unidad de escalado de aplicaciones suscribe las aplicaciones a los mensajes de interés. El servicio común controla la suscripción a los componentes de la unidad de escalado de mensajería del vehículo.
  2. El vehículo utiliza el servicio de administración de dispositivos para detectar su asignación a una unidad de escalado de mensajería de vehículos.
  3. Si es necesario, el vehículo se aprovisiona usando el flujo de trabajo Aprovisionamiento de dispositivos y vehículos.
  4. El vehículo publica un mensaje en el agente MQTT.
  5. Event Grid enruta el mensaje mediante la información de suscripción.
    1. En el caso de los mensajes que no requieren procesamiento y comprobación de notificaciones, se enruta a un centro de entrada en la unidad de escalado de aplicaciones correspondiente.
    2. Los mensajes que requieren procesamiento se enrutan a la lógica de procesamiento D2C para descodificar y autorizar (consentimiento del usuario).
  6. Las aplicaciones consumen eventos de la instancia de Event Hubs de entrada de la aplicación .
  7. Las aplicaciones publican mensajes para el vehículo.
    1. Los mensajes que no requieren más procesamiento se publican en el agente MQTT.
    2. Los mensajes que requieren más procesamiento, control de flujo de trabajo y autorización se enrutan a la lógica de procesamiento de C2D pertinente a través de una instancia de Event Hubs.

Componentes

Esta arquitectura de referencia hace referencia a los siguientes componentes de Azure.

Conectividad

  • Azure Event Grid permite la incorporación de dispositivos, AuthN/Z y pub-sub a través de MQTT v5.
  • Azure Functions procesa los mensajes del vehículo. También se puede usar para implementar las API de administración que requieren una ejecución de corta duración.
  • Azure Kubernetes Service (AKS) es una alternativa cuando la funcionalidad detrás de las API administradas consta de cargas de trabajo complejas implementadas como aplicaciones en contenedor.
  • Azure Cosmos DB almacena la configuración de consentimiento del vehículo, el dispositivo y el usuario.
  • Azure API Management proporciona una puerta de enlace de API administrada a los servicios back-end existentes, como la administración del ciclo de vida del vehículo (incluido OTA) y la administración del consentimiento del usuario.
  • Azure Batch ejecuta grandes tareas de proceso intensivo de forma eficaz, como la ingesta de seguimiento de la comunicación del vehículo.

Datos y análisis

  • Azure Event Hubs permite procesar e ingerir grandes cantidades de datos de telemetría.
  • Azure Data Explorer proporciona exploración, curación y análisis de datos de telemetría de vehículos basados en series temporales.
  • Azure Blob Storage almacena documentos grandes (como vídeos y seguimientos) y datos mantenidos del vehículo.
  • Azure Databricks proporciona un conjunto de herramientas para mantener soluciones de datos de nivel empresarial a escala. Necesario para las operaciones de larga duración con grandes cantidades de datos de vehículos.

Integración de back-end

  • Azure Logic Apps ejecuta flujos de trabajo automatizados para la integración empresarial en función de los datos del vehículo.
  • Azure App Service proporciona aplicaciones web orientadas al usuario y back-ends móviles, como la aplicación complementaria.
  • Azure Cache for Redis proporciona almacenamiento en caché en memoria de datos que a menudo usan las aplicaciones orientadas al usuario.
  • Azure Service Bus proporciona agentes que desacoplan la conectividad del vehículo de los servicios digitales y la integración empresarial.

Alternativas

La selección del tipo correcto de proceso para implementar el procesamiento de mensajes y las API administradas depende de multitud de factores. Seleccione el servicio correcto mediante la guía Elegir un servicio de proceso de Azure .

Ejemplos:

  • Azure Functions para procesos controlados por eventos, como la ingesta de telemetría.
  • Azure Batch para tareas de informática de alto rendimiento como descodificar archivos de seguimiento CAN o vídeos de gran tamaño.
  • Azure Kubernetes Service para la orquestación administrada y completa de lógicas complejas, como la administración de flujos de trabajo de comando y control.

Como alternativa al uso compartido de datos basado en eventos, también es posible usar Azure Data Share si el objetivo es realizar la sincronización por lotes en el nivel de lago de datos.

Detalles del escenario

Diagrama de la vista de alto nivel.

Los OEM automotrices están experimentando una transformación significativa a medida que cambian de producir productos fijos a ofrecer vehículos conectados y definidos por software. Los vehículos ofrecen una variedad de características, como actualizaciones inalámbricas, diagnósticos remotos y experiencias de usuario personalizadas. Esta transición permite a los OEM mejorar continuamente sus productos en función de los datos y la información en tiempo real, a la vez que amplían sus modelos de negocio para incluir nuevos servicios y flujos de ingresos.

Esta arquitectura de referencia permite a los fabricantes de automóviles y a los proveedores de movilidad:

  • Usar los datos de los comentarios como parte del proceso de ingeniería digital para impulsar la mejora continua del producto, abordar de forma proactiva las causas de los problemas y crear un nuevo beneficio para el cliente.
  • Proporcionar nuevos productos y servicios digitales y digitalizar operaciones con integración empresarial con sistemas back-end como Enterprise Resource Planning (ERP) y Customer Relationship Management (CRM).
  • Compartir los datos de forma segura y abordar los requisitos específicos de cada país o región en cuanto al consentimiento de los usuarios con los ecosistemas más amplios de Movilidad inteligente.
  • La integración con sistemas de back-end para la administración del ciclo de vida de los vehículos y la administración de consentimiento simplifica y acelera la implementación y administración de soluciones de vehículos conectados mediante una cadena de herramientas de DevOps de vehículo definida por software.
  • Almacenar y proporcionar proceso a escala para vehículos y análisis.
  • Administrar la conectividad del vehículo a millones de dispositivos de forma rentable.

Posibles casos de uso

Los casos de uso de OEM Automotive consisten en mejorar el rendimiento del vehículo, la seguridad y la experiencia del usuario.

  • Mejora continua del producto: mejora del rendimiento del vehículo mediante el análisis de datos en tiempo real y la aplicación de actualizaciones de forma remota.
  • Validación de flota de pruebas de ingeniería: garantizar la seguridad y la confiabilidad de los vehículos mediante la recopilación y el análisis de datos de flotas de prueba.
  • Aplicación complementaria y Portal del usuario: habilitación del acceso y control remotos del vehículo a través de una aplicación personalizada y un portal web.
  • Reparación proactiva y mantenimiento: predicción y programación del mantenimiento de vehículos en función de la información controlada por datos.

Los casos de uso más amplios del ecosistema amplían las aplicaciones de vehículos conectados para mejorar las operaciones de flota, el seguro, el marketing y la asistencia en carretera en todo el panorama de transporte.

  • Operaciones de flota comercial conectadas: optimización de la administración de flotas a través de la supervisión en tiempo real y la toma de decisiones controladas por datos.
  • Seguro de vehículo digital: personalización de las primas de seguros en función del comportamiento de la conducción y proporcionar informes inmediatos de accidentes.
  • Marketing basado en la ubicación: entrega campañas de marketing dirigidas a los conductores en función de su ubicación y preferencias.
  • Asistencia en carretera: proporcionar asistencia y asistencia en tiempo real a los conductores que necesitan, utilizando la ubicación del vehículo y los datos de diagnóstico.

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Confiabilidad

La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para más información, consulte Resumen del pilar de fiabilidad.

  • Considere la posibilidad de escalar horizontalmente para agregar confiabilidad.
  • Use unidades de escalado para aislar regiones geográficas con diferentes regulaciones.
  • Escalado automático e instancias reservadas: administre los recursos de proceso mediante el escalado dinámico en función de la demanda y la optimización de los costos con instancias asignadas previamente.
  • Redundancia geográfica: replique los datos en varias ubicaciones geográficas para la tolerancia a errores y la recuperación ante desastres.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.

  • Protección de la conexión de vehículos: consulte la sección sobre la administración de certificados para comprender cómo usar certificados X.509 para establecer comunicaciones seguras de vehículos.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

  • Consideraciones sobre el costo por vehículo: los costos de comunicación deben depender del número de servicios digitales ofrecidos. Calcule el RoI de los servicios digitales con respecto a los costos de operación.
  • Establezca prácticas para el análisis de costos en función del tráfico de mensajes. El tráfico del vehículo conectado tiende a aumentar con el tiempo a medida que se agregan más servicios.
  • Considere los costos móviles y de red
    • Use el alias de tema MQTT para reducir el volumen de tráfico.
    • Use un método eficaz para codificar y comprimir mensajes de carga.
  • Control del tráfico
    • Prioridad del mensaje: los vehículos tienden a tener patrones de uso repetidos que crean picos de demanda diarios o semanales. Use las propiedades del mensaje para retrasar el procesamiento de mensajes no críticos o analíticos para suavizar la carga y optimizar el uso de recursos.
    • Realice escalado automático basado en la demanda.
  • Tenga en cuenta cuánto tiempo se deben almacenar los datos en caliente o frío.
  • Considere el uso de instancias reservadas para optimizar los costos.

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para más información, consulte Introducción al pilar de excelencia operativa.

  • Considere la posibilidad de supervisar el software del vehículo (registros, métricas y seguimientos), los servicios de mensajería, los servicios de análisis y datos, y los servicios back-end relacionados como parte de las operaciones unificadas de TI.

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan ejercido sobre ella. Para obtener más información, vea Resumen del pilar de eficiencia del rendimiento.

  • Considere la posibilidad de usar el concepto de escalado para las soluciones que escalan más de 50 000 dispositivos, especialmente si se requieren varias regiones geográficas.
  • Considere detenidamente la mejor manera de ingerir datos (mensajería, streaming o por lotes).
  • Considere la mejor manera de analizar los datos en función del caso de uso.

Pasos siguientes

En los artículos siguientes se tratan algunos de los conceptos usados en la arquitectura:

En los artículos siguientes se describen las interacciones entre los componentes de la arquitectura: