Operaciones de datos para operaciones de vehículos autónomos

En este artículo se presenta una solución e instrucciones para desarrollar operaciones de datos sin conexión y administración de datos (DataOps) para un sistema de conducción automatizado. La solución DataOps se basa en el marco que se describe en guía de diseño de operaciones de vehículos autónomos (AVOps). DataOps es uno de los bloques de creación de AVOps. Otros bloques de creación incluyen operaciones de aprendizaje automático (MLOps), operaciones de validación (ValOps), DevOps y funciones de AVOps centralizadas.

Apache®, Apache Sparky apache Parquet son marcas comerciales registradas o marcas comerciales de Apache Software Foundation en Estados Unidos y/o en otros países. El uso de estas marcas no implica ninguna aprobación de Apache Software Foundation.

Arquitectura

Descargar un archivo de Visio que contiene los diagramas de arquitectura de este artículo.

Flujo de datos

1. Los datos de medición se originan en los flujos de datos de un vehículo. Las fuentes incluyen cámaras, telemetría del vehículo y sensores radar, ultrasónicos y lidar. Los registradores de datos del vehículo almacenan los datos de medición en los dispositivos de almacenamiento del registrador. Los datos de almacenamiento del registrador se cargan en un lago de datos de aterrizaje. Un servicio como Azure Data Box o Azure Stack Edge, o una conexión dedicada, como Azure ExpressRoute, ingiere los datos en Azure. Los datos de medición en los siguientes formatos llegan a Azure Data Lake Storage: Formato de datos de medida versión 4 (MDF4), sistemas de administración de datos técnicos (TDMS) y rosbag. Los datos cargados escriben una cuenta de almacenamiento dedicada denominada landing que se designa para recibir y validar los datos.

2. Una canalización de Azure Data Factory se desencadena a intervalos programados para procesar los datos en la cuenta de almacenamiento de aterrizaje. La canalización controla los pasos siguientes:

   • Realiza una comprobación de calidad de datos, como una suma de comprobación. Este paso quita los datos de baja calidad para que solo los datos de alta calidad pasen a la siguiente fase. Azure App Service se usa para ejecutar el código de comprobación de calidad. Los datos que se consideran incompletos se archivan para su procesamiento futuro.
   • Para el seguimiento de linaje, llama a una API de metadatos mediante App Service. Este paso actualiza los metadatos almacenados en Azure Cosmos DB para crear un flujo de datos. Para cada medida, hay un flujo de datos sin procesar.
   • Copia los datos en una cuenta de almacenamiento denominada sin procesar en Data Lake Storage.
   • Llama a la API de metadatos para marcar el flujo de datos como completo para que otros componentes y servicios puedan consumir el flujo de datos.
   • Archiva las medidas y las quita de la cuenta de almacenamiento de aterrizaje.

3. Data Factory y Azure Batch procesan los datos de la zona sin procesar para extraer información que los sistemas de bajada pueden consumir:

   • Batch lee los datos de temas del archivo sin procesar y genera los datos en temas seleccionados en las carpetas correspondientes.
   • Dado que los archivos de la zona sin procesar pueden tener más de 2 GB de tamaño, las funciones de extracción de procesamiento paralelo se ejecutan en cada archivo. Estas funciones extraen el procesamiento de imágenes, lidar, radar y datos GPS. También realizan el procesamiento de metadatos. Data Factory y Batch proporcionan una manera de realizar paralelismo de forma escalable.
   • Los datos se reducen para reducir la cantidad de datos que se deben etiquetar y anotar.

4. Si los datos del registrador del vehículo no se sincronizan entre los distintos sensores, se desencadena una canalización de Data Factory que sincroniza los datos para crear un conjunto de datos válido. El algoritmo de sincronización se ejecuta en Batch.

5. Una canalización de Data Factory se ejecuta para enriquecer los datos. Algunos ejemplos de mejoras son la telemetría, los datos del registrador de vehículos y otros datos, como el tiempo, el mapa o los datos de objetos. Los datos enriquecidos ayudan a proporcionar a los científicos de datos información que pueden usar en el desarrollo de algoritmos, por ejemplo. Los datos generados se conservan en archivos Apache Parquet que son compatibles con los datos sincronizados. Los metadatos sobre los datos enriquecidos se almacenan en un almacén de metadatos de Azure Cosmos DB.

6. Los asociados de terceros realizan el etiquetado manual o automático. Los datos se comparten con los asociados de terceros a través de Azure Data Share y se integran en Microsoft Purview. Data Share usa una cuenta de almacenamiento dedicada denominada etiquetada en Data Lake Storage para devolver los datos etiquetados a la organización.

7. Una canalización de Data Factory realiza la detección de escenas. Los metadatos de la escena se conservan en el almacén de metadatos. Los datos de la escena se almacenan como objetos en archivos Parquet o Delta.

8. Además de los metadatos de los datos de enriquecimiento y las escenas detectadas, el almacén de metadatos de Azure Cosmos DB almacena metadatos para las medidas, como los datos de unidad. Este almacén también contiene metadatos para el linaje de los datos a medida que pasa por los procesos de extracción, reducción del muestreo, sincronización, enriquecimiento y detección de escenas. La API de metadatos se usa para acceder a las medidas, el linaje y los datos de la escena y para buscar dónde se almacenan los datos. Como resultado, la API de metadatos actúa como administrador de capas de almacenamiento. Distribuye los datos entre cuentas de almacenamiento. También proporciona a los desarrolladores una manera de usar una búsqueda basada en metadatos para obtener ubicaciones de datos. Por ese motivo, el almacén de metadatos es un componente centralizado que ofrece rastreabilidad y linaje en el flujo de datos de la solución.

9. Azure Databricks y Azure Synapse Analytics se usan para conectarse con la API de metadatos y acceder a Data Lake Storage y realizar investigaciones sobre los datos.

Componentes

• Data Box proporciona una manera de enviar terabytes de datos a Azure de una manera rápida, económica y confiable. En esta solución, Data Box se usa para transferir los datos recopilados del vehículo a Azure a través de un operador regional.
• dispositivos Azure Stack Edge proporcionan funcionalidad de Azure en ubicaciones perimetrales. Algunos ejemplos de funcionalidades de Azure son el proceso, el almacenamiento, las redes y el aprendizaje automático acelerado por hardware.
• expressRoute extiende una red local a Microsoft Cloud a través de una conexión privada.
• Data Lake Storage contiene una gran cantidad de datos en su formato nativo y sin procesar. En este caso, Data Lake Storage almacena datos basados en fases, por ejemplo, sin procesar o extraídas.
• Data Factory es una solución totalmente administrada y sin servidor para crear y programar flujos de trabajo de extracción, transformación, carga (ETL) y extracción, carga, transformación (ELT). En este caso, Data Factory realiza ETL a través de de proceso por lotes y crea flujos de trabajo controlados por datos para orquestar el movimiento de datos y transformar los datos.
• Batch ejecuta trabajos por lotes paralelos y de alto rendimiento (HPC) a gran escala de forma eficaz en Azure. Esta solución usa Batch para ejecutar aplicaciones a gran escala para tareas como la limpieza y transformación de datos, el filtrado y la preparación de datos y la extracción de metadatos.
• de Azure Cosmos DB es una base de datos de varios modelos distribuida globalmente. Aquí, almacena los resultados de metadatos, como las medidas almacenadas.
• Data Share comparte datos con organizaciones asociadas con seguridad mejorada. Mediante el uso compartido en contexto, los proveedores de datos pueden compartir datos donde reside sin copiar los datos ni tomar instantáneas. En esta solución, Data Share comparte datos con empresas de etiquetado.
• azure Databricks proporciona un conjunto de herramientas para mantener soluciones de datos de nivel empresarial a escala. Es necesario para las operaciones de larga duración en grandes cantidades de datos de vehículos. Los ingenieros de datos usan Azure Databricks como un área de trabajo de análisis.
• Azure Synapse Analytics reduce el tiempo de información sobre los almacenes de datos y los sistemas de macrodatos.
• Azure Cognitive Search proporciona servicios de búsqueda de catálogos de datos.
• App Service proporciona una instancia de App Service basada en servidor. En este caso, App Service hospeda la API de metadatos.
• microsoft Purview proporciona gobernanza de datos entre organizaciones.
• azure Container Registry es un servicio que crea un registro administrado de imágenes de contenedor. Esta solución usa Container Registry para almacenar contenedores para temas de procesamiento.
• application Insights es una extensión de azure Monitor que proporciona administración del rendimiento de las aplicaciones. En este escenario, Application Insights le ayuda a crear observabilidad en torno a la extracción de medidas: puede usar Application Insights para registrar eventos personalizados, métricas personalizadas y otra información mientras la solución procesa cada medida para la extracción. También puede crear consultas en Log Analytics para obtener información detallada sobre cada medida.

Detalles del escenario

Diseñar un marco de DataOps sólido para vehículos autónomos es fundamental para usar los datos, rastrear su linaje y hacer que esté disponible en toda la organización. Sin un proceso de DataOps bien diseñado, la gran cantidad de datos que generan los vehículos autónomos puede convertirse rápidamente en abrumador y difícil de administrar.

Al implementar una estrategia eficaz de DataOps, le ayudará a asegurarse de que los datos se almacenan correctamente, son accesibles fácilmente y tienen un linaje claro. También facilita la administración y el análisis de los datos, lo que conduce a una toma de decisiones más informada y un mejor rendimiento del vehículo.

Un proceso eficaz de DataOps proporciona una manera de distribuir fácilmente los datos en toda la organización. A continuación, varios equipos pueden acceder a la información que necesitan para optimizar sus operaciones. DataOps facilita la colaboración y el uso compartido de información, lo que ayuda a mejorar la eficacia general de su organización.

Entre los desafíos típicos para las operaciones de datos en el contexto de los vehículos autónomos se incluyen:

• Gestión del volumen diario de medición a escala de terabytes o petabyte de datos de medición de vehículos de investigación y desarrollo.
• Uso compartido de datos y colaboración entre varios equipos y asociados, por ejemplo, para etiquetar, anotaciones y comprobaciones de calidad.
• Rastreabilidad y linaje de una pila de percepción crítica para la seguridad que captura el control de versiones y el linaje de los datos de medición.
• Metadatos y detección de datos para mejorar la segmentación semántica, la clasificación de imágenes y los modelos de detección de objetos.

Esta solución avOps DataOps proporciona instrucciones sobre cómo abordar estos desafíos.

Casos de uso potenciales

Esta solución beneficia a los fabricantes de equipos originales de automoción (OEM), proveedores de nivel 1 y proveedores de software independientes (ISV) que desarrollan soluciones para la conducción automatizada.

Operaciones de datos federados

En una organización que implementa AVOps, varios equipos contribuyen a DataOps debido a la complejidad necesaria para AVOps. Por ejemplo, un equipo podría estar encargado de la recopilación de datos y la ingesta de datos. Otro equipo podría ser responsable de la gestión de la calidad de los datos lidar. Por ese motivo, los siguientes principios de una arquitectura de malla de datos de son importantes tener en cuenta para DataOps:

• Descentralización orientada a dominio de la propiedad y la arquitectura de los datos. Un equipo dedicado es responsable de un dominio de datos que proporciona productos de datos para ese dominio, por ejemplo, conjuntos de datos etiquetados.
• Datos como producto. Cada dominio de datos tiene varias zonas en contenedores de almacenamiento implementados por data-lake. Hay zonas para el uso interno. También hay una zona que contiene productos de datos publicados para otros dominios de datos o uso externo para evitar la duplicación de datos.
• Autoservicio de datos como plataforma para habilitar equipos de datos autónomos orientados a dominio.
• Gobernanza federada para habilitar la interoperabilidad y el acceso entre dominios de datos de AVOps que requieren un almacén de metadatos centralizado y un catálogo de datos. Por ejemplo, un dominio de datos de etiquetado podría necesitar acceso a un dominio de recopilación de datos.

Para obtener más información sobre las implementaciones de malla de datos, consulte análisis a escala en la nube.

Estructura de ejemplo para dominios de datos de AVOps

En la tabla siguiente se proporcionan algunas ideas para estructurar dominios de datos de AVOps:

Cada dominio de datos de AVOps se configura en función de una estructura de plano técnico. Esa estructura incluye data Factory, Data Lake Storage, bases de datos, batch y entornos de ejecución de Apache Spark a través de Azure Databricks o Azure Synapse Analytics.

Metadatos y detección de datos

Cada dominio de datos está descentralizado y administra individualmente sus productos de datos de AVOps correspondientes. Para la detección central de datos y saber dónde se encuentran los productos de datos, se requieren dos componentes:

• Un almacén de metadatos que conserva los metadatos sobre los archivos de medida procesados y los flujos de datos, como las secuencias de vídeo. Este componente hace que los datos sean reconocibles y rastreables con anotaciones que deben indexarse, como para buscar los metadatos de archivos sin etiquetar. Por ejemplo, es posible que desee que el almacén de metadatos devuelva todos los fotogramas de números de identificación de vehículos específicos (VIN) o marcos con peatones u otros objetos basados en enriquecimiento.
• Catálogo de datos que muestra el linaje, las dependencias entre dominios de datos de AVOps y qué almacenes de datos participan en el bucle de datos de AVOps. Un ejemplo de catálogo de datos es microsoft Purview.

Puede usar Azure Data Explorer o Azure Cognitive Search para ampliar un almacén de metadatos basado en Azure Cosmos DB. La selección depende del escenario final que necesita para la detección de datos. Use Azure Cognitive Search para funcionalidades de búsqueda semántica.

El siguiente diagrama del modelo de metadatos muestra un modelo de metadatos unificado típico que se usa en varios pilares del bucle de datos de AVOps:

Uso compartido de datos

El uso compartido de datos es un escenario común en un bucle de datos de AVOps. Entre los usos se incluyen el uso compartido de datos entre dominios de datos y el uso compartido externo, por ejemplo, para integrar asociados de etiquetado. Microsoft Purview proporciona las siguientes funcionalidades para un uso compartido eficaz de datos en un bucle de datos:

• detección de datos de autoservicio y acceso
• de uso compartido de datos en contexto

Los formatos recomendados para el intercambio de datos de etiquetas incluyen objetos comunes en conjuntos de datos de contexto (COCO) y Asociación para la normalización de los conjuntos de datos openLABEL (ASAM) de Automatización y Medición (ASAM).

En esta solución, los conjuntos de datos etiquetados se usan en procesos de mlOps para crear algoritmos especializados, como modelos de percepción y fusión de sensores. Los algoritmos pueden detectar escenas y objetos en un entorno, como los carriles cambiantes del coche, las carreteras bloqueadas, el tráfico peatonal, las luces de tráfico y los signos de tráfico.

Canalización de datos

En esta solución DataOps, el movimiento de datos entre distintas fases de la canalización de datos se automatiza. A través de este enfoque, el proceso proporciona ventajas de eficiencia, escalabilidad, coherencia, reproducibilidad, adaptación y control de errores. Mejora el proceso general de desarrollo, acelera el progreso y apoya la implementación segura y eficaz de tecnologías de conducción autónoma.

En las secciones siguientes se describe cómo puede implementar el movimiento de datos entre fases y cómo debe estructurar las cuentas de almacenamiento.

Estructura jerárquica de carpetas

Una estructura de carpetas bien organizada es un componente fundamental de una canalización de datos en el desarrollo de conducción autónoma. Esta estructura proporciona una organización sistemática y fácilmente navegable de los archivos de datos, lo que facilita la administración y recuperación de datos eficientes.

En esta solución, los datos de la carpeta sin procesar tienen la siguiente estructura jerárquica:

region/raw/<measurement-ID>/<data-stream-ID>/AAAA/MM/DD

Los datos de la cuenta de almacenamiento de zona extraída usan una estructura jerárquica similar:

region/extracted/<measurement-ID>/<data-stream-ID>/AAAA/MM/DD

Mediante estructuras jerárquicas similares, puede aprovechar la funcionalidad de espacio de nombres jerárquico de Data Lake Storage. Las estructuras jerárquicas ayudan a crear almacenamiento de objetos escalable y rentable. Estas estructuras también mejoran la eficacia de la búsqueda y recuperación de objetos. La creación de particiones por año y VIN facilita la búsqueda de imágenes relevantes de vehículos específicos. En el lago de datos, se crea un contenedor de almacenamiento para cada sensor, como una cámara, un dispositivo GPS o un sensor lidar o radar.

Cuenta de almacenamiento de aterrizaje en la cuenta de almacenamiento sin procesar

Una canalización de Data Factory se desencadena en función de una programación. Una vez desencadenada la canalización, los datos se copian de la cuenta de almacenamiento de aterrizaje en la cuenta de almacenamiento sin procesar.

La canalización recupera todas las carpetas de medida y las recorre en iteración. Con cada medida, la solución realiza las actividades siguientes:

1. Una función valida la medida. La función recupera el archivo de manifiesto del manifiesto de medida. A continuación, la función comprueba si todos los archivos de medida de MDF4, TDMS y rosbag para la medida actual existen en la carpeta de medida. Si la validación se realiza correctamente, la función continúa con la siguiente actividad. Si se produce un error en la validación, la función omite la medida actual y se mueve a la siguiente carpeta de medida.

2. Se realiza una llamada api web a una API que crea una medida y la carga JSON del archivo JSON del manifiesto de medida se pasa a la API. Si la llamada se realiza correctamente, se analiza la respuesta para recuperar el identificador de medida. Si se produce un error en la llamada, la medida se mueve a la actividad on-error para el control de errores.

   Nota

   Esta solución dataOps se basa en la suposición de que se limita el número de solicitudes al servicio de aplicaciones. Si la solución puede realizar un número indeterminado de solicitudes, considere un patrón de limitación de velocidad de .

3. Se realiza una llamada api web a una API que crea un flujo de datos mediante la creación de la carga JSON necesaria. Si la llamada se realiza correctamente, la respuesta se analiza para recuperar el identificador del flujo de datos y la ubicación del flujo de datos. Si se produce un error en la llamada, la medida se mueve a la actividad en caso de error.

4. Se realiza una llamada api web para actualizar el estado del flujo de datos a Start Copy. Si la llamada se realiza correctamente, la actividad de copia copia los archivos de medida en la ubicación del flujo de datos. Si se produce un error en la llamada, la medida se mueve a la actividad en caso de error.

5. Una canalización de Data Factory invoca a Batch para copiar los archivos de medida de la cuenta de almacenamiento de aterrizaje en la cuenta de almacenamiento sin procesar. Un módulo de copia de una aplicación de orquestador crea un trabajo con las siguientes tareas para cada medida:

   • Copie los archivos de medida en la cuenta de almacenamiento sin procesar.
   • Copie los archivos de medida en una cuenta de almacenamiento de archivo.
   • Quite los archivos de medida de la cuenta de almacenamiento de aterrizaje.

   Nota

   En estas tareas, Batch usa un grupo de orquestadores y la herramienta AzCopy para copiar y quitar datos. AzCopy usa tokens de SAS para realizar tareas de copia o eliminación. Los tokens de SAS se almacenan en un almacén de claves y se hace referencia a los términos landingsaskey, archivesaskeyy rawsaskey.

6. Se realiza una llamada api web para actualizar el estado del flujo de datos a Copy Complete. Si la llamada se realiza correctamente, la secuencia continúa con la siguiente actividad. Si se produce un error en la llamada, la medida se mueve a la actividad en caso de error.

7. Los archivos de medida se mueven de la cuenta de almacenamiento de aterrizaje a un archivo de aterrizaje. Esta actividad puede volver a ejecutar una medida determinada si la mueve a la cuenta de almacenamiento de aterrizaje a través de una canalización de copia hidratada. La administración del ciclo de vida está activada para esta zona para que las medidas de esta zona se eliminen o archiven automáticamente.

8. Si se produce un error con una medida, la medida se mueve a una zona de error. Desde allí, se puede mover a la cuenta de almacenamiento de aterrizaje para que se vuelva a ejecutar. Como alternativa, la administración del ciclo de vida puede eliminar o archivar automáticamente la medida.

Tenga en cuenta los siguientes puntos:

• Estas canalizaciones se desencadenan en función de una programación. Este enfoque ayuda a mejorar la rastreabilidad de las ejecuciones de canalización y a evitar ejecuciones innecesarias.
• Cada canalización se configura con un valor de simultaneidad de uno para asegurarse de que las ejecuciones anteriores finalicen antes de que se inicie la siguiente ejecución programada.
• Cada canalización está configurada para copiar medidas en paralelo. Por ejemplo, si una ejecución programada recoge 10 medidas para copiar, los pasos de canalización se pueden ejecutar simultáneamente para las diez medidas.
• Cada canalización está configurada para generar una alerta en Monitor si la canalización tarda más de lo esperado en finalizar.
• La actividad on-error se implementa en casos posteriores de observabilidad.
• La administración del ciclo de vida elimina automáticamente medidas parciales, por ejemplo, medidas con archivos rosbag que faltan.

Diseño por lotes

Toda la lógica de extracción se empaqueta en diferentes imágenes de contenedor, con un contenedor para cada proceso de extracción. Batch ejecuta las cargas de trabajo de contenedor en paralelo cuando extrae información de los archivos de medida.

Batch usa un grupo de orquestadores y un grupo de ejecución para procesar cargas de trabajo:

• Un grupo de orquestadores tiene nodos de Linux sin compatibilidad con el entorno de ejecución del contenedor. El grupo ejecuta código de Python que usa batch API para crear trabajos y tareas para el grupo de ejecución. Este grupo también supervisa esas tareas. Data Factory invoca al grupo de orquestadores, que organiza las cargas de trabajo de contenedor que extraen datos.
• Un grupo de ejecución tiene nodos de Linux con entornos de ejecución de contenedor para admitir la ejecución de cargas de trabajo de contenedor. Para este grupo, los trabajos y las tareas se programan a través del grupo de orquestadores. Todas las imágenes de contenedor necesarias para el procesamiento en el grupo de ejecución se insertan en un registro de contenedor mediante JFrog. El grupo de ejecución está configurado para conectarse a este registro y extraer las imágenes necesarias.

Las cuentas de almacenamiento en las que se leen y escriben los datos se montan a través de NFS 3.0 en los nodos por lotes y los contenedores que se ejecutan en los nodos. Este enfoque ayuda a los nodos por lotes y los contenedores a procesar datos rápidamente sin necesidad de descargar los archivos de datos localmente en los nodos por lotes.

Invocación de Batch desde Data Factory

En la canalización de extracción, el desencadenador pasa la ruta de acceso del archivo de metadatos y la ruta de acceso del flujo de datos sin procesar en los parámetros de canalización. Data Factory usa una actividad de búsqueda para analizar el JSON del archivo de manifiesto. El identificador de flujo de datos sin procesar se puede extraer de la ruta de acceso del flujo de datos sin procesar mediante el análisis de la variable de canalización.

Data Factory llama a una API para crear un flujo de datos. La API devuelve la ruta de acceso para el flujo de datos extraído. La ruta de acceso extraída se agrega al objeto actual y Data Factory invoca Batch a través de una actividad personalizada pasando el objeto actual, después de anexar la ruta de acceso del flujo de datos extraído:

{
"measurementId":"210b1ba7-9184-4840-a1c8-eb£397b7c686",
"rawDataStreamPath":"raw/2022/09/30/KA123456/210b1ba7-9184-4840-
alc8-ebf39767c68b/57472a44-0886-475-865a-ca32{c851207",
"extractedDatastreamPath":"extracted/2022/09/30/KA123456
/210bIba7-9184-4840-a1c8-ebf39767c68b/87404c9-0549-4a18-93ff-d1cc55£d8b78",
"extractedDataStreamId":"87404bc9-0549-4a18-93ff-d1cc55fd8b78"
}

Proceso de extracción paso a paso

1. Data Factory programa un trabajo con una tarea para que el grupo de orquestadores procese una medida para la extracción. Data Factory pasa la siguiente información al grupo de orquestadores:

   • Identificador de medida
   • Ubicación de los archivos de medida de tipo MDF4, TDMS o rosbag que se deben extraer.
   • Ruta de acceso de destino de la ubicación de almacenamiento del contenido extraído
   • Identificador de flujo de datos extraído

2. El grupo de orquestadores invoca una API para actualizar el flujo de datos y establecer su estado en Processing.

3. El grupo de orquestadores crea un trabajo para cada archivo de medida que forma parte de la medida. Cada trabajo contiene las siguientes tareas:

   Tarea	Propósito	Nota
   Validación	Valida que los datos se pueden extraer del archivo de medida.	Todas las demás tareas dependen de esta tarea.
   Procesar metadatos	Deriva metadatos del archivo de medida y enriquece los metadatos del archivo mediante una API para actualizar los metadatos del archivo.
   Proceso StructuredTopics	Extrae datos estructurados de un archivo de medida determinado.	La lista de temas para extraer datos estructurados de se pasa como un objeto de configuración.
   Proceso CameraTopics	Extrae datos de imagen de un archivo de medida determinado.	La lista de temas de los que extraer imágenes de se pasa como un objeto de configuración.
   Proceso LidarTopics	Extrae datos lidar de un archivo de medida determinado.	La lista de temas de los que extraer datos lidar de se pasa como un objeto de configuración.
   Proceso CANTopics	Extrae datos de red de área de controlador (CAN) de un archivo de medida determinado.	La lista de temas de los que extraer datos de se pasa como un objeto de configuración.

4. El grupo de orquestadores supervisa el progreso de cada tarea. Una vez finalizados todos los trabajos de todos los archivos de medida, el grupo invoca una API para actualizar el flujo de datos y establecer su estado en Completed.

5. El orquestador se cierra correctamente.

   Nota

   Cada tarea es una imagen de contenedor independiente que tiene lógica que se define correctamente para su propósito. Las tareas aceptan objetos de configuración como entrada. Por ejemplo, la entrada especifica dónde escribir la salida y el archivo de medida que se va a procesar. Una matriz de tipos de tema, como sensor_msgs/Image, es otro ejemplo de entrada. Dado que todas las demás tareas dependen de la tarea de validación, se crea una tarea dependiente para ella. Todas las demás tareas se pueden procesar de forma independiente y se pueden ejecutar en paralelo.

Consideraciones

Estas consideraciones implementan los pilares de Azure Well-Architected Framework, que es un conjunto de principios rectores que se pueden usar para mejorar la calidad de una carga de trabajo. Para obtener más información, consulte Microsoft Azure Well-Architected Framework.

Fiabilidad

La confiabilidad garantiza que la aplicación pueda cumplir los compromisos que realice para sus clientes. Para obtener más información, consulte Información general sobre el pilar de confiabilidad.

• En la solución, considere la posibilidad de usar zonas de disponibilidad de Azure, que son ubicaciones físicas únicas dentro de la misma región de Azure.
• Planee la recuperación ante desastres y la de conmutación por error.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de sus valiosos datos y sistemas. Para obtener más información, consulte Información general sobre el pilar de seguridad.

Es importante comprender la división de responsabilidades entre un OEM de automoción y Microsoft. En un 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. Las capas de plataforma como servicio (PaaS) de Azure proporcionan seguridad integrada en la pila física, incluido el sistema operativo. Puede agregar las siguientes funcionalidades a los componentes de seguridad de infraestructura existentes:

• Administración de identidades y acceso que usa identidades de Microsoft Entra y directivas de acceso condicional de Microsoft Entra.
• Gobernanza de infraestructura que usa Azure Policy.
• Gobernanza de datos que usa Microsoft Purview.
• Cifrado de datos en reposo que usa azure Storage nativo y servicios de base de datos. Para obtener más información, consulte Consideraciones de protección de datos.
• Protección de claves criptográficas y secretos. Use de Azure Key Vault para este propósito.

Optimización de costos

La optimización de costos examina formas de reducir los gastos innecesarios y mejorar la eficiencia operativa. Para obtener más información, consulte Información general sobre el pilar de optimización de costos.

Una preocupación clave para los OEM y los proveedores de nivel 1 que operan DataOps para vehículos automatizados es el costo del funcionamiento. Esta solución usa los procedimientos siguientes para ayudar a optimizar los costos:

• Aprovechar las distintas opciones que Ofrece Azure para hospedar código de aplicación. Esta solución usa App Service y Batch. Para obtener instrucciones sobre cómo elegir el servicio adecuado para la implementación, consulte Elegir un servicio de proceso de Azure.
• Uso de uso compartido de datos en contexto de Azure Storage.
• Optimización de los costos mediante administración del ciclo de vida.
• Ahorro de costos en App Service mediante instancias reservadas.

Colaboradores

Microsoft mantiene este artículo. Originalmente fue escrito por los siguientes colaboradores.

Autores principales:

• Ryan Matsumura | Jefe de programas sénior
• jochen Schroeer | Arquitecto principal (Movilidad de línea de servicio)
• Brij Singh | Ingeniero principal de software
• Ginette Vellera | Jefe sénior de ingeniería de software

Para ver perfiles de LinkedIn no públicos, inicie sesión en LinkedIn.

Pasos siguientes

• ¿Qué es Azure Batch?
• ¿Qué es Azure Data Factory?
• Introducción a azure Data Lake Storage Gen2
• bienvenido a Azure Cosmos DB
• información general de App Service
• ¿Qué es Azure Data Share?
• ¿Qué es Azure Data Box?
• documentación de Azure Stack Edge
• ¿Qué es Azure ExpressRoute?
• ¿Qué es Azure Machine Learning?
• ¿Qué es Azure Databricks?
• ¿Qué es Azure Synapse Analytics?
• información general de Azure Monitor
• archivos de registro ros (rosbags)
• plataforma de operaciones de datos a gran escala para vehículos autónomos

Recursos relacionados

Para obtener más información sobre cómo desarrollar ValOps para un sistema de conducción autónomo, consulte:

También puede estar interesado en estos artículos relacionados:

• guía de diseño de AVOps
• Análisis de datos para flotas de pruebas automotrices
• bloques de creación para entornos de simulación de conducción autónoma
• mensajería automotriz, arquitectura de referencia de análisis de datos &