Los fabricantes de equipos originales (OEM) de automoción necesitan soluciones para minimizar el tiempo entre realizar las versiones de prueba y ofrecer datos de diagnóstico de la versión de prueba para los ingenieros de R&D. A medida que los vehículos se vuelven más automatizados, los ciclos de vida de desarrollo de software son más cortos, lo que requiere bucles de comentarios digitales más rápidos. La nueva tecnología puede democratizar el acceso a los datos y proporcionar a los ingenieros de investigación y desarrollo información casi en tiempo real sobre los datos de diagnóstico de la versión de prueba. Use Copilot para Ciencia de datos e Ingeniería de datos para el análisis de datos para reducir aún más el tiempo de obtención de información. El uso compartido seguro de datos puede mejorar la colaboración entre los OEM y los proveedores, y reducir la duración de los ciclos de desarrollo.
La guía de este artículo es para escenarios de telemetría y escenarios de ingesta de datos de la versión de prueba por lotes. Esta arquitectura se centra en la plataforma de datos que procesa los datos de diagnóstico y los conectores para la visualización e informes de datos.
Arquitectura
Descargue un archivo de PowerPoint con todos los diagramas de este artículo.
Flujo de datos
El siguiente flujo de trabajo corresponde al diagrama anterior:
El dispositivo de captura de datos está conectado a las redes del vehículo y recopila datos de señal y vídeo en alta resolución del vehículo. (1a) El dispositivo publica mensajes de telemetría en tiempo real o (1b) solicita la carga de archivos de datos registrados en la funcionalidad del agente MQTT de Azure Event Grid mediante un cliente MQTT. Esta funcionalidad usa un patrón de comprobación de notificaciones.
(2a) Event Grid enruta los datos de señal del vehículo activo a una aplicación de Azure Functions. Esta aplicación descodifica las señales del vehículo al formato de notación de objetos JavaScript (JSON) y los envía a una secuencia de eventos.
(2b) Event Grid coordina la carga de archivos desde el cliente del dispositivo al almacén de lago. Una carga de archivo completada desencadena una canalización que descodifica los datos y escribe el archivo descodificado en OneLine en un formato adecuado para la ingesta, como parquet o CSV.
(3a) El flujo de eventos enruta las señales de vehículo JSON descodificadas para la ingesta en el centro de eventos.
(3b) Una canalización de datos desencadena la ingesta de archivos descodificados desde el almacén de lago.
El centro de eventos usa directivas de actualización para enriquecer los datos y expandir los datos JSON en un formato de fila adecuado, por ejemplo, los datos de ubicación pueden estar agrupados para alinearse con el análisis geoespacial. Cada vez que se ingiere una nueva fila, el motor de análisis en tiempo real invoca una función
Update()
asociada.Los ingenieros de datos y los científicos de datos usan el Lenguaje de consulta Kusto (KQL) para crear casos de uso de análisis. Los usuarios almacenan los casos usados con frecuencia como funciones compartidas definidas por el usuario. Los ingenieros usan funciones de KQL integradas, como agregación, análisis de series temporales, agrupación en clústeres geoespaciales, ventanas y complementos de aprendizaje automático con compatibilidad con Copilot.
Los ingenieros de R&D y los científicos de datos usan cuadernos para analizar datos y crear casos de uso de prueba y validación.
Los ingenieros de R&D usan conjuntos de consultas KQL y Copilot para inteligencia en tiempo real para realizar análisis interactivos de datos.
Los ingenieros de datos y los científicos de datos usan cuadernos para almacenar y compartir sus procesos de análisis. Con los cuadernos, los ingenieros pueden usar Azure Spark para ejecutar análisis y usar Git para administrar el código del cuaderno. Los usuarios pueden aprovechar Copilot para Ciencia de datos e Ingeniería de datos para admitir su flujo de trabajo con sugerencias de código contextual.
Los ingenieros de R&D y los científicos de datos pueden usar Power BI con consultas dinámicas o paneles de análisis en tiempo real para crear visualizaciones para compartirlas con usuarios empresariales. Estas visualizaciones invocan funciones definidas por el usuario para facilitar el mantenimiento.
Los ingenieros también pueden conectar más herramientas a Microsoft Fabric. Por ejemplo, pueden conectar Azure Managed Grafana al centro de eventos o crear una aplicación web que consulte directamente el centro de eventos.
Los ingenieros de datos y los ingenieros de R&D usan Data Activator para crear elementos Reflex para supervisar las condiciones y desencadenar acciones, como desencadenar flujos de Power Automate para la integración empresarial. Por ejemplo, Data Activator puede notificar a un canal de Teams si el estado de un dispositivo se degrada.
La configuración del recopilador de datos permite a los ingenieros cambiar las directivas de recopilación de datos del dispositivo de captura de datos. Azure API Management abstrae y protege la API de configuración de asociados y proporciona observabilidad.
Esquema de base de datos de KQL
Al diseñar el esquema de tabla, tenga en cuenta la diferencia entre las tablas fact
y las tablas dimension
. La telemetría es una tabla fact
porque las señales del vehículo se anexan progresivamente de forma de streaming o como parte de una grabación completa, y la telemetría no cambia. Puede clasificar los metadatos de flota como una tabla fact
que se actualiza lentamente.
La telemetría del vehículo llega a tablas sin procesar. Puede usar los siguientes conceptos de procesamiento de mensajes para organizar los datos para el análisis y los informes:
Cree directivas de actualización para expandir los archivos de telemetría JSON en registros de señal de vehículo individuales mediante métodos como:
-
mv-expand()
expande valores complejos almacenados en estructuras JSON en filas con señales individuales. -
geo_point_to_h3cell()
ogeo_point_to_geohash()
convierte la latitud y longitud en geohashes para el análisis geoespacial. -
todouble()
ytostring()
convierten valores extraídos de objetos JSON dinámicos en los tipos de datos adecuados. -
lookup
extiende los registros con valores de una tabla de dimensiones.
-
Cree una vista materializada de señales desduplicadas mediante la función de agregación
take_any()
en la clave única y la marca de tiempo. Esta vista materializada desduplica las señales.Cree una vista materializada de los últimos valores conocidos de señales mediante la función de agregación
arg_max()
en la marca de tiempo. Esta vista materializada proporciona un estado actualizado de los vehículos.Cree una vista materializada de señales de tamaño reducido mediante el operador summarize con intervalos de tiempo, como cada hora y diariamente. Esta vista materializada agrega señales y simplifica la generación de informes en toda la flota.
Cree funciones definidas por el usuario que proporcionen la detección de anomalías o el análisis de la causa principal.
Use funciones de serie temporal para la detección y previsión de anomalías para detectar posibles problemas y predecir errores.
Use el operador scan para examinar, buscar coincidencias y generar secuencias a partir de los datos. Los ingenieros pueden usar el operador
scan
para detectar secuencias. Por ejemplo, si se produce un evento específico, se debe producir un evento posterior dentro de una determinada cantidad de tiempo.Utilice complementos de aprendizaje automático como autocluster para encontrar patrones comunes de atributos discretos.
Realice análisis geoespaciales con funciones definidas por el usuario. Use las funciones de análisis geoespacial para convertir coordenadas en un sistema de cuadrícula adecuado y realizar agregaciones en los datos.
Cree una tabla de metadatos de flota para almacenar los cambios en los metadatos y la configuración del vehículo. Cree una vista materializada de los últimos valores conocidos de los metadatos de la flota para almacenar el estado más reciente de la flota de vehículos en función de una columna modificada por última vez.
Componentes
Las siguientes tecnologías clave implementan esta carga de trabajo. Para cada componente de la arquitectura, use la guía de servicio pertinente del Marco de buena arquitectura cuando esté disponible. Para obtener más información, consulte Guías de servicio del Marco de buena arquitectura.
Fabric Real-Time Intelligence permite la extracción de información y visualización de la telemetría del vehículo en movimiento. Puede usar secuencias de eventos y bases de datos KQL de serie temporal para almacenar y analizar datos y usar reflejos para reaccionar a los eventos.
Data Activator es una herramienta sin código que se puede usar para automatizar acciones cuando cambian patrones o condiciones en los datos.
Event Grid es un servicio de distribución de mensajes de publicación y suscripción totalmente administrado y altamente escalable que admite los protocolos MQTT. Los vehículos pueden usar Event Grid para publicar y suscribirse a temas, por ejemplo, pueden publicar telemetría y suscribirse a mensajes de comando y control.
Azure Event Hubs es una plataforma de streaming de datos en tiempo real que es adecuada para transmitir millones de eventos de vehículo por segundo con baja latencia.
Functions es una solución sin servidor que simplifica el procesamiento de eventos de telemetría del vehículo a escala con desencadenadores y enlaces controlados por eventos mediante el lenguaje que prefiera.
Azure Managed Grafana es una plataforma de visualización de datos basada en el software de Grafana Labs. Microsoft administra y admite Azure Managed Grafana.
Azure App Service le permite crear y hospedar aplicaciones web, back-ends móviles y API RESTful que proporcionan acceso a los datos de telemetría del vehículo almacenados en Fabric. Este enfoque simplifica el consumo.
API Management es una plataforma híbrida de varias nubes para administrar las API.
Alternativas
También puede usar los siguientes servicios de Azure para implementar esta arquitectura:
Azure Blob Storage almacena grandes cantidades de datos no estructurados, como grabaciones, registros y vídeos de los vehículos. Reemplaza el almacenamiento de OneLake.
Azure Data Explorer es un servicio de análisis de datos rápido y totalmente administrado que permite analizar grandes volúmenes de datos en tiempo real. Reemplaza la base de datos KQL de Fabric Real-Time Intelligence.
Azure Batch es una alternativa que puede usar para descodificar archivos complejos. Este escenario implica un gran número de archivos que tienen más de 300 megabytes cada uno. Los archivos requieren algoritmos de descodificación diferentes en función de la versión del archivo o el tipo de archivo. Puede usar Fabric o usar Blob Storage y Azure Data Explorer para implementar el siguiente enfoque.
El usuario o el dispositivo de grabación carga un archivo de datos grabado en el almacén de lago. Cuando finaliza la carga, desencadena una aplicación de Functions que programa la descodificación.
El programador inicia una aplicación de Functions que crea un trabajo por lotes basado en el tipo de archivo, el tamaño de archivo y el algoritmo de descodificación necesario. La aplicación selecciona una máquina virtual con un tamaño adecuado del grupo e inicia el trabajo.
Batch vuelve a escribir el archivo descodificado resultante en almacén de lago cuando finaliza el trabajo. Este archivo debe ser adecuado para la ingesta directa en un formato que admita el centro de eventos.
El almacén de lago desencadena una función que ingiere los datos en el centro de eventos tras la escritura de archivos. Esta función crea la tabla y la asignación de datos si es necesario e inicia el proceso de ingesta.
La base de datos KQL ingiere los archivos de datos del almacén de lago.
Este enfoque proporciona las ventajas siguientes:
Functions y los grupos de Batch pueden controlar las tareas de procesamiento de datos escalables de forma sólida y eficaz.
Los grupos de Batch proporcionan información sobre el procesamiento de estadísticas, colas de tareas y estado del grupo de lotes. Puede visualizar el estado, detectar problemas y volver a ejecutar tareas con errores.
La combinación de Functions y Batch admite el procesamiento plug-and-play en contenedores de Docker.
Puede usar máquinas virtuales de acceso puntual para procesar archivos durante las horas de poca actividad. Este enfoque ahorra dinero.
Detalles del escenario
Los OEM de automoción utilizan grandes flotas de vehículos prototipos y de prueba para probar y comprobar varias funciones del vehículo. Los procedimientos de prueba son costosos, ya que los conductores y vehículos reales deben participar, y ciertos escenarios específicos de pruebas de carreteras reales deben pasar varias veces. Las pruebas de integración son especialmente importantes para evaluar las interacciones entre componentes eléctricos, electrónicos y mecánicos en sistemas complejos.
Para validar las funciones del vehículo y analizar anomalías y errores, debe capturar petabytes de datos de diagnóstico desde unidades de control electrónico (ECU), los nodos de equipo, los buses de comunicación de vehículos, como la red de área de controlador (CAN) y Ethernet, y los sensores.
En el pasado, los servidores de registradores de datos pequeños de los vehículos almacenaban datos de diagnóstico localmente como formato de datos de medición (MDF), extensión de fusión multimedia (MFX), CSV o archivos JSON. Una vez completadas las versiones de prueba, los servidores cargaron datos de diagnóstico en centros de datos, que los procesaron y los enviaron a los ingenieros de R&D para el análisis. Este proceso puede tardar horas o a veces días. Los escenarios más recientes usan patrones de ingesta de telemetría como flujos de datos sincrónicos basados en Message Queuing (MQTT) o cargas de archivos casi en tiempo real.
Posibles casos de uso
La administración de vehículos evalúa el rendimiento y los datos recopilados por vehículo en varios escenarios de prueba.
La validación del sistema y componente usa datos recopilados del vehículo para comprobar que el comportamiento de los componentes del vehículo se encuentra dentro de los límites operativos entre viajes.
La detección de anomalías localiza patrones de desviación de un valor de sensor en relación con su patrón de línea base típico en tiempo real.
El análisis de la causa principal usa complementos de aprendizaje automático, como algoritmos de agrupación en clústeres, para identificar los cambios en la distribución de valores en varias dimensiones.
El mantenimiento predictivo combina varios orígenes de datos, datos de ubicación enriquecidos y señales del vehículo para predecir el tiempo de los componentes en caso de error.
La evaluación de la sostenibilidad utiliza el comportamiento de los conductores y el consumo de energía para evaluar el impacto ambiental de las operaciones del vehículo.
Carreras automovilísticas para comprender y mejorar el rendimiento de los vehículos antes, durante y después de una carrera.
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 obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.
Las zonas de disponibilidad de Azure son ubicaciones físicas únicas dentro de la misma región de Azure. Las zonas de disponibilidad pueden proteger los clústeres de proceso y los datos de Azure Data Explorer de un error parcial en la región.
La continuidad empresarial y recuperación ante desastres (BCDR) en Azure Data Explorer permite que la empresa continúe en funcionamiento en caso de que se produzca una interrupción.
Las bases de datos de seguidores separan los recursos de proceso entre los casos de uso de producción y no producción.
Seguridad
La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para obtener más información, consulte Lista de comprobación de revisión de diseño para seguridad.
Es importante comprender la división de responsabilidad entre el OEM automotriz y Microsoft. En el vehículo, el OEM posee toda la pila, pero a medida que los datos se mueven a la nube, algunas responsabilidades se transfieren a Microsoft. La plataforma como servicio (PaaS) de Azure proporciona seguridad integrada en la pila física, incluido el sistema operativo.
Use Azure Policy para aplicar barreras de seguridad.
Consulte la introducción a la gobernanza y las instrucciones de Fabric.
Use puntos de conexión privados para proporcionar seguridad de red para todos los servicios.
Cifrar los datos en reposo y los datos en tránsito.
Use las identidades de Microsoft Entra y las directivas de acceso condicional de Microsoft Entra.
Use la seguridad de nivel de fila (RLS) para las bases de datos KQL y Azure Data Explorer.
Use la instrucción restrict cuando implemente aplicaciones de middleware con acceso a la base de datos KQL. Esta configuración crea un modelo lógico que restringe el acceso de usuario a los datos.
Todas estas características ayudan a los OEM de automoción a crear un entorno seguro para sus datos de telemetría del vehículo. Para obtener más información, consulte Seguridad en Fabric.
Optimización de costos
La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costes.
Esta solución usa los procedimientos siguientes para ayudar a optimizar los costos:
Configure correctamente las cachés activas y el almacenamiento en frío para las tablas de datos sin procesar y de señales. La caché de datos activas se almacena en RAM o SSD y proporciona un rendimiento mejorado. Sin embargo, los datos en frío son 45 veces más baratos. Establezca una directiva de caché activa adecuada para su caso de uso, como 30 días.
Configure una directiva de retención en las tablas de datos sin procesar y señales. Determine cuándo los datos de señal ya no son relevantes, por ejemplo después de 365 días, y establezca la directiva de retención en consecuencia.
Tenga en cuenta qué señales son de interés para el análisis.
Use vistas materializadas al consultar los últimos valores conocidos de las señales, las señales desduplicadas y las señales desactivadas. Las vistas materializadas consumen menos recursos que realizar agregaciones de tabla de origen en cada consulta.
Tenga en cuenta las necesidades de análisis de datos en tiempo real. Configure la ingesta de streaming para la tabla de telemetría en directo para proporcionar una latencia de menos de un segundo entre la ingesta y la consulta. Este enfoque aumenta los ciclos de CPU y el coste.
Eficiencia del rendimiento
La eficiencia del rendimiento es la capacidad que tiene la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan realizado sobre ella. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.
Considere la posibilidad de usar Batch para la descodificación si el número y el tamaño de los archivos de datos registrados son mayores que 1000 archivos o 300 MB al día.
Considere la posibilidad de realizar cálculos y análisis comunes después de ingerirlos y almacenarlos en tablas adicionales.
Use los procedimientos recomendados de consulta de KQL para que la consulta se ejecute más rápido.
Use una cláusula
where
para definir un período de tiempo para reducir la cantidad de datos que se consultan. Considere la posibilidad de cambiar la directiva de partición de datos de la tabla de señales si los criterios de búsqueda comunes no se basan en el tiempo, por ejemplo, si filtra por identificador de grabación y nombre de señal. Cuando la base de datos KQL se expande para contener miles de millones o billones de registros, la filtración de datos adecuada se vuelve esencial, especialmente teniendo en cuenta la directiva de partición activa.
Advertencia
Consulte con el equipo de soporte técnico antes de modificar una directiva de partición de datos.
Implementación de este escenario
Use el tutorial paso a paso para implementar este escenario. En la guía se muestra cómo implementar una instancia gratuita, analizar archivos MDF, ingerir datos y realizar varias consultas básicas.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Creadores de entidad de seguridad:
- Boris Scholl | Socio, arquitecto jefe
- Frank Kaleck | Asesor del sector automotriz
- Henning Rauch | Administrador de programas principal
- Mario Ortegon-Vega | Jefe de programa principal
Otros colaboradores:
- Devang Shah | Administrador de programas principal
- Hans-Peter Bareiner | Arquitecto de soluciones en la nube
- Jason Bouska | Ingeniero de software sénior
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
- Característica de agente MQTT en Event Grid
- Adición de un destino de base de datos KQL a Eventstream
- Obtener datos de OneLake
- Vistas materializadas
- Creación de paneles en tiempo real
- Creación de alertas de Data Activator desde un panel en tiempo real
- Informe de Power BI
- Visualización de datos desde Azure Data Explorer en Grafana
- Arquitectura de referencia de automoción, datos y análisis