Operações de dados para operações de veículos autônomos

Este artigo apresenta uma solução e diretrizes para o desenvolvimento de operações de dados offline e gerenciamento de dados (DataOps) para um sistema de condução automatizado. A solução DataOps baseia-se na estrutura descrita no guia de design AVOps (operações de veículos autônomos). O DataOps é um dos blocos de construção do AVOps. Outros blocos de construção incluem operações de machine learning (MLOps), operações de validação (ValOps), DevOps e funções centralizadas do AVOps.

Apache®, Apache Sparke Apache Parquet são marcas registradas ou marcas comerciais do Apache Software Foundation nos Estados Unidos e/ou em outros países. Nenhum endosso do Apache Software Foundation está implícito pelo uso dessas marcas.

Arquitetura

Baixe um arquivo visio que contém os diagramas de arquitetura neste artigo.

Fluxo

1. Os dados de medida se originam nos fluxos de dados de um veículo. As fontes incluem câmeras, telemetria de veículos e sensores de radar, ultrassônicos e lidar. Os agentes de dados no veículo armazenam os dados de medida em dispositivos de armazenamento do agente. Os dados de armazenamento do agente são carregados em um data lake de aterrissagem. Um serviço como o Azure Data Box ou o Azure Stack Edge ou uma conexão dedicada como o Azure ExpressRoute ingere os dados no Azure. Os dados de medição nos seguintes formatos chegam ao Azure Data Lake Storage: MDF4 (Formato de Dados de Medida versão 4), TDMS (sistemas técnicos de gerenciamento de dados) e rosbag. Os dados carregados entram em uma conta de armazenamento dedicada chamada Landing designada para receber e validar os dados.

2. Um pipeline do Azure Data Factory é disparado em um intervalo agendado para processar os dados na conta de armazenamento de aterrissagem. O pipeline lida com as seguintes etapas:

   • Executa uma verificação de qualidade de dados, como uma soma de verificação. Esta etapa remove dados de baixa qualidade para que apenas dados de alta qualidade passem para o próximo estágio. O Serviço de Aplicativo do Azure é usado para executar o código de verificação de qualidade. Os dados considerados incompletos são arquivados para processamento futuro.
   • Para acompanhamento de linhagem, chama uma API de metadados usando o Serviço de Aplicativo. Esta etapa atualiza os metadados armazenados no Azure Cosmos DB para criar um novo fluxo de dados. Para cada medida, há um fluxo de dados bruto.
   • Copia os dados para uma conta de armazenamento chamada Raw no Data Lake Storage.
   • Chama a API de metadados para marcar o fluxo de dados como concluído para que outros componentes e serviços possam consumir o fluxo de dados.
   • Arquiva as medidas e as remove da conta de armazenamento de aterrissagem.

3. O Data Factory e o Lote do Azure processam os dados na zona bruta para extrair informações que os sistemas downstream podem consumir:

   • O Lote lê os dados de tópicos no arquivo bruto e gera os dados em tópicos selecionados nas respectivas pastas.
   • Como os arquivos na zona bruta podem ter mais de 2 GB de tamanho, as funções de extração de processamento paralelo são executadas em cada arquivo. Essas funções extraem o processamento de imagens, lidar, radar e dados GPS. Eles também executam o processamento de metadados. O Data Factory e o Lote fornecem uma maneira de executar o paralelismo de maneira escalonável.
   • Os dados são reduzidos para reduzir a quantidade de dados que precisam ser rotulados e anotados.

4. Se os dados do agente do veículo não forem sincronizados entre os vários sensores, um pipeline do Data Factory será disparado que sincroniza os dados para criar um conjunto de dados válido. O algoritmo de sincronização é executado no Lote.

5. Um pipeline do Data Factory é executado para enriquecer os dados. Exemplos de aprimoramentos incluem telemetria, dados do agente do veículo e outros dados, como clima, mapa ou dados de objeto. Dados enriquecidos ajudam a fornecer aos cientistas de dados insights que eles podem usar no desenvolvimento de algoritmos, por exemplo. Os dados gerados são mantidos em arquivos Apache Parquet compatíveis com os dados sincronizados. Os metadados sobre os dados enriquecidos são armazenados em um repositório de metadados no Azure Cosmos DB.

6. Parceiros de terceiros executam rotulagem manual ou automática. Os dados são compartilhados com os parceiros de terceiros por meio do Azure Data Share e integrados ao Microsoft Purview. O Data Share usa uma conta de armazenamento dedicada chamada Labeled no Data Lake Storage para retornar os dados rotulados para a organização.

7. Um pipeline do Data Factory executa a detecção de cena. Os metadados de cena são mantidos no repositório de metadados. Os dados de cena são armazenados como objetos em arquivos Parquet ou Delta.

8. Além dos metadados dos dados de enriquecimento e das cenas detectadas, o repositório de metadados no Azure Cosmos DB armazena metadados para as medidas, como dados de unidade. Esse repositório também contém metadados para a linhagem dos dados à medida que passam pelos processos de extração, downsampling, sincronização, enriquecimento e detecção de cena. A API de metadados é usada para acessar as medidas, a linhagem e os dados da cena e pesquisar onde os dados são armazenados. Como resultado, a API de metadados serve como um gerenciador de camadas de armazenamento. Ele espalha dados entre contas de armazenamento. Ele também fornece aos desenvolvedores uma maneira de usar uma pesquisa baseada em metadados para obter locais de dados. Por esse motivo, o repositório de metadados é um componente centralizado que oferece rastreabilidade e linhagem no fluxo de dados da solução.

9. O Azure Databricks e o Azure Synapse Analytics são usados para se conectar à API de metadados e acessar o Data Lake Storage e realizar pesquisas sobre os dados.

Componentes

• Data Box fornece uma maneira de enviar terabytes de dados para dentro e para fora do Azure de maneira rápida, barata e confiável. Nesta solução, o Data Box é usado para transferir dados de veículo coletados para o Azure por meio de uma transportadora regional.
• dispositivos do Azure Stack Edge fornecem funcionalidade do Azure em locais de borda. Exemplos de recursos do Azure incluem computação, armazenamento, rede e machine learning acelerado por hardware.
• do ExpressRoute estende uma rede local para o Microsoft Cloud por meio de uma conexão privada.
• Data Lake Storage contém uma grande quantidade de dados em seu formato nativo e bruto. Nesse caso, o Data Lake Storage armazena dados com base em estágios, por exemplo, brutos ou extraídos.
• data factory é uma solução totalmente gerenciada e sem servidor para criar e agendar fluxos de trabalho ELT (extrair, transformar, carregar, carregar, transformar). Aqui, o Data Factory executa o ETL por meio de de computação em lote e cria fluxos de trabalho controlados por dados para orquestrar a movimentação de dados e transformar dados.
• lote executa trabalhos em lote de HPC (computação em larga escala) e paralelos de alto desempenho com eficiência no Azure. Essa solução usa o Lote para executar aplicativos em grande escala para tarefas como estruturação de dados, filtragem e preparação de dados e extração de metadados.
• do Azure Cosmos DB é um banco de dados de vários modelos distribuído globalmente. Aqui, ele armazena resultados de metadados, como medidas armazenadas.
• Data Share compartilha dados com organizações parceiras com segurança aprimorada. Usando o compartilhamento in-loco, os provedores de dados podem compartilhar dados onde residem sem copiar os dados ou tirar instantâneos. Nesta solução, o Data Share compartilha dados com empresas de rotulagem.
• a do Azure Databricks fornece um conjunto de ferramentas para manter soluções de dados de nível empresarial em escala. Ele é necessário para operações de longa execução em grandes quantidades de dados do veículo. Os engenheiros de dados usam o Azure Databricks como um workbench de análise.
• do Azure Synapse Analytics reduz o tempo de insights entre data warehouses e sistemas de Big Data.
• do Azure Cognitive Search fornece serviços de pesquisa do catálogo de dados.
• Serviço de Aplicativo fornece um Serviço de Aplicativo Web baseado em servidor. Nesse caso, o Serviço de Aplicativo hospeda a API de metadados.
• Microsoft Purview fornece governança de dados entre organizações.
• Registro de Contêiner do Azure é um serviço que cria um registro gerenciado de imagens de contêiner. Essa solução usa o Registro de Contêiner para armazenar contêineres para tópicos de processamento.
• Application Insights é uma extensão do do Azure Monitor que fornece gerenciamento de desempenho do aplicativo. Nesse cenário, o Application Insights ajuda você a criar a observabilidade em torno da extração de medidas: você pode usar o Application Insights para registrar eventos personalizados, métricas personalizadas e outras informações enquanto a solução processa cada medida para extração. Você também pode criar consultas no Log Analytics para obter informações detalhadas sobre cada medida.

Detalhes do cenário

Criar uma estrutura de DataOps robusta para veículos autônomos é crucial para usar seus dados, rastrear sua linhagem e disponibilizá-los em toda a sua organização. Sem um processo de DataOps bem projetado, a enorme quantidade de dados que os veículos autônomos geram pode rapidamente se tornar esmagadora e difícil de gerenciar.

Ao implementar uma estratégia de DataOps eficaz, você ajuda a garantir que seus dados sejam armazenados corretamente, facilmente acessíveis e tenha uma linhagem clara. Você também facilita o gerenciamento e a análise dos dados, levando a uma tomada de decisão mais informada e melhor desempenho do veículo.

Um processo eficiente do DataOps fornece uma maneira de distribuir facilmente dados em toda a sua organização. Várias equipes podem acessar as informações necessárias para otimizar suas operações. O DataOps facilita a colaboração e o compartilhamento de insights, o que ajuda a melhorar a eficácia geral da sua organização.

Os desafios típicos para operações de dados no contexto de veículos autônomos incluem:

• Gerenciamento do volume diário de dados de medição em escala de terabyte ou petabyte de veículos de pesquisa e desenvolvimento.
• Compartilhamento de dados e colaboração entre várias equipes e parceiros, por exemplo, para rotulagem, anotações e verificações de qualidade.
• Rastreabilidade e linhagem para uma pilha de percepção crítica de segurança que captura o controle de versão e a linhagem de dados de medida.
• Metadados e descoberta de dados para melhorar a segmentação semântica, a classificação de imagem e os modelos de detecção de objetos.

Esta solução AVOps DataOps fornece diretrizes sobre como lidar com esses desafios.

Possíveis casos de uso

Essa solução beneficia os OEMs (fabricantes de equipamentos originais automotivos), fornecedores de camada 1 e ISVs (fornecedores de software independentes) que desenvolvem soluções para condução automatizada.

Operações de dados federadas

Em uma organização que implementa o AVOps, várias equipes contribuem para o DataOps devido à complexidade necessária para o AVOps. Por exemplo, uma equipe pode ser responsável pela coleta de dados e ingestão de dados. Outra equipe pode ser responsável pelo gerenciamento de qualidade de dados de dados lidar. Por esse motivo, os seguintes princípios de uma arquitetura de malha de dados são importantes de considerar para DataOps:

• Descentralização orientada ao domínio da propriedade e arquitetura de dados. Uma equipe dedicada é responsável por um domínio de dados que fornece produtos de dados para esse domínio, por exemplo, conjuntos de dados rotulados.
• Dados como um produto. Cada domínio de dados tem várias zonas em contêineres de armazenamento implementados no data lake. Há zonas para uso interno. Há também uma zona que contém produtos de dados publicados para outros domínios de dados ou uso externo para evitar a duplicação de dados.
• Autoatendimento de dados como uma plataforma para habilitar equipes de dados autônomas orientadas ao domínio.
• Governança federada para habilitar a interoperabilidade e o acesso entre domínios de dados do AVOps que exigem um armazenamento de metadados centralizado e um catálogo de dados. Por exemplo, um domínio de dados de rotulagem pode precisar de acesso a um domínio de coleta de dados.

Para obter mais informações sobre implementações de malha de dados, consulte análise de escala de nuvem.

Estrutura de exemplo para domínios de dados do AVOps

A tabela a seguir fornece algumas ideias para estruturar domínios de dados do AVOps:

Cada domínio de dados AVOps é configurado com base em uma estrutura de blueprint. Essa estrutura inclui Data Factory, Data Lake Storage, bancos de dados, batch e runtimes do Apache Spark por meio do Azure Databricks ou do Azure Synapse Analytics.

Metadados e descoberta de dados

Cada domínio de dados é descentralizado e gerencia individualmente seus produtos de dados AVOps correspondentes. Para a descoberta central de dados e para saber onde os produtos de dados estão localizados, dois componentes são necessários:

• Um repositório de metadados que persiste metadados sobre arquivos de medida processados e fluxos de dados, como sequências de vídeo. Esse componente torna os dados detectáveis e rastreáveis com anotações que precisam ser indexadas, como pesquisar os metadados de arquivos sem rótulo. Por exemplo, talvez você queira que o repositório de metadados retorne todos os quadros para VINs (números de identificação de veículos) específicos ou quadros com pedestres ou outros objetos baseados em enriquecimento.
• Um catálogo de dados que mostra a linhagem, as dependências entre domínios de dados do AVOps e quais armazenamentos de dados estão envolvidos no loop de dados do AVOps. Um exemplo de um catálogo de dados é Microsoft Purview.

Você pode usar o Azure Data Explorer ou o Azure Cognitive Search para estender um repositório de metadados baseado no Azure Cosmos DB. Sua seleção depende do cenário final necessário para a descoberta de dados. Use o Azure Cognitive Search para recursos de pesquisa semântica.

O diagrama de modelo de metadados a seguir mostra um modelo de metadados unificado típico usado em vários pilares de loop de dados do AVOps:

Compartilhamento de dados

O compartilhamento de dados é um cenário comum em um loop de dados AVOps. Os usos incluem o compartilhamento de dados entre domínios de dados e compartilhamento externo, por exemplo, para integrar parceiros de rotulagem. O Microsoft Purview fornece os seguintes recursos para o compartilhamento eficiente de dados em um loop de dados:

• de acesso e descoberta de dados de autoatendimento
• de compartilhamento de dados in-loco

Os formatos recomendados para troca de dados de rótulo incluem objetos comuns em conjuntos de dados COCO (contexto) e Association for Standardization of Automation and Measurement Systems (ASAM) OpenLABEL datasets.

Nesta solução, os conjuntos de dados rotulados são usados em processos MLOps para criar algoritmos especializados, como modelos de percepção e fusão de sensores. Os algoritmos podem detectar cenas e objetos em um ambiente, como o carro mudando de faixa, estradas bloqueadas, tráfego de pedestres, semáforos e placas de trânsito.

Pipeline de dados

Nesta solução DataOps, a movimentação de dados entre diferentes estágios no pipeline de dados é automatizada. Por meio dessa abordagem, o processo fornece eficiência, escalabilidade, consistência, reprodutibilidade, adaptabilidade e benefícios de tratamento de erros. Ele aprimora o processo de desenvolvimento geral, acelera o progresso e dá suporte à implantação segura e eficaz de tecnologias de condução autônoma.

As seções a seguir descrevem como você pode implementar a movimentação de dados entre estágios e como você deve estruturar suas contas de armazenamento.

Estrutura de pasta hierárquica

Uma estrutura de pastas bem organizada é um componente vital de um pipeline de dados no desenvolvimento de condução autônoma. Essa estrutura fornece uma disposição sistemática e facilmente navegável de arquivos de dados, facilitando o gerenciamento e a recuperação de dados eficientes.

Nesta solução, os dados na pasta bruta têm a seguinte estrutura hierárquica:

>de ID de medida/</<data-stream-ID>/YYYYY/MM/DD

Os dados na conta de armazenamento de zona extraída usam uma estrutura hierárquica semelhante:

região/extraída/<measurement-ID>/<data-stream-ID>/YYYY/MM/DD

Usando estruturas hierárquicas semelhantes, você pode aproveitar a funcionalidade de namespace hierárquico do Data Lake Storage. Estruturas hierárquicas ajudam a criar armazenamento de objetos escalonável e econômico. Essas estruturas também melhoram a eficiência da pesquisa e recuperação de objetos. Particionamento por ano e VIN facilita a pesquisa de imagens relevantes de veículos específicos. No data lake, um contêiner de armazenamento é criado para cada sensor, como uma câmera, um dispositivo GPS ou um sensor lidar ou radar.

Conta de armazenamento de aterrissagem para a conta de armazenamento bruto

Um pipeline do Data Factory é disparado com base em um agendamento. Depois que o pipeline é disparado, os dados são copiados da conta de armazenamento landing para a conta de armazenamento Bruto.

diagrama de arquitetura de

O pipeline recupera todas as pastas de medida e itera por meio delas. Com cada medida, a solução executa as seguintes atividades:

1. Uma função valida a medida. A função recupera o arquivo de manifesto do manifesto de medida. Em seguida, a função verifica se todos os arquivos de medida MDF4, TDMS e rosbag para a medida atual existem na pasta de medida. Se a validação for bem-sucedida, a função prosseguirá para a próxima atividade. Se a validação falhar, a função ignorará a medida atual e passará para a próxima pasta de medida.

2. Uma chamada à API Web é feita para uma API que cria uma medida e o conteúdo JSON do arquivo JSON do manifesto de medida é passado para a API. Se a chamada for bem-sucedida, a resposta será analisada para recuperar a ID de medida. Se a chamada falhar, a medida será movida para a atividade on-error para tratamento de erros.

   Nota

   Essa solução DataOps baseia-se na suposição de que você limita o número de solicitações ao serviço de aplicativo. Se sua solução puder criar um número indeterminado de solicitações, considere um padrão de limitação de taxa de .

3. Uma chamada à API Web é feita para uma API que cria um fluxo de dados criando o conteúdo JSON necessário. Se a chamada for bem-sucedida, a resposta será analisada para recuperar a ID do fluxo de dados e o local do fluxo de dados. Se a chamada falhar, a medida será movida para a atividade no erro.

4. Uma chamada à API Web é feita para atualizar o estado do fluxo de dados para Start Copy. Se a chamada for bem-sucedida, a atividade de cópia copiará os arquivos de medida para o local do fluxo de dados. Se a chamada falhar, a medida será movida para a atividade no erro.

5. Um pipeline do Data Factory invoca o Lote para copiar os arquivos de medida da conta de armazenamento landing para a conta de armazenamento bruto. Um módulo de cópia de um aplicativo orquestrador cria um trabalho com as seguintes tarefas para cada medida:

   • Copie os arquivos de medida para a conta de armazenamento bruto.
   • Copie os arquivos de medida para uma conta de armazenamento de arquivos.
   • Remova os arquivos de medida da conta de armazenamento landing.

   Nota

   Nessas tarefas, o Lote usa um pool de orquestradores e a ferramenta AzCopy para copiar e remover dados. O AzCopy usa tokens SAS para executar tarefas de cópia ou remoção. Os tokens SAS são armazenados em um cofre de chaves e são referenciados usando os termos landingsaskey, archivesaskeye rawsaskey.

6. Uma chamada à API Web é feita para atualizar o estado do fluxo de dados para Copy Complete. Se a chamada for bem-sucedida, a sequência prosseguirá para a próxima atividade. Se a chamada falhar, a medida será movida para a atividade no erro.

7. Os arquivos de medida são movidos da conta de armazenamento landing para um arquivo de aterrissagem. Essa atividade pode executar novamente uma medida específica movendo-a de volta para a conta de armazenamento de aterrissagem por meio de um pipeline de cópia hidratada. O gerenciamento do ciclo de vida é ativado para essa zona para que as medidas nessa zona sejam excluídas ou arquivadas automaticamente.

8. Se ocorrer um erro com uma medida, a medida será movida para uma zona de erro. A partir daí, ele pode ser movido para a conta de armazenamento de aterrissagem para ser executado novamente. Como alternativa, o gerenciamento do ciclo de vida pode excluir ou arquivar automaticamente a medida.

Observe os seguintes pontos:

• Esses pipelines são disparados com base em um agendamento. Essa abordagem ajuda a melhorar a rastreabilidade de execuções de pipeline e a evitar execuções desnecessárias.
• Cada pipeline é configurado com um valor de simultaneidade de um para garantir que todas as execuções anteriores sejam concluídas antes do início da próxima execução agendada.
• Cada pipeline é configurado para copiar medidas em paralelo. Por exemplo, se uma execução agendada pegar 10 medidas para copiar, as etapas do pipeline poderão ser executadas simultaneamente para todas as dez medidas.
• Cada pipeline é configurado para gerar um alerta no Monitor se o pipeline demorar mais do que o tempo esperado para ser concluído.
• A atividade on-error é implementada em histórias de observabilidade posteriores.
• O gerenciamento do ciclo de vida exclui automaticamente medidas parciais, por exemplo, medidas com arquivos rosbag ausentes.

Design do lote

Toda a lógica de extração é empacotada em imagens de contêiner diferentes, com um contêiner para cada processo de extração. O Lote executa as cargas de trabalho de contêiner em paralelo quando extrai informações de arquivos de medida.

diagrama de arquitetura

O Lote usa um pool de orquestradores e um pool de execução para processar cargas de trabalho:

• Um pool de orquestradores tem nós do Linux sem suporte para runtime de contêiner. O pool executa o código Python que usa a API do Lote para criar trabalhos e tarefas para o pool de execução. Esse pool também monitora essas tarefas. O Data Factory invoca o pool de orquestradores, que orquestra as cargas de trabalho de contêiner que extraem dados.
• Um pool de execução tem nós do Linux com runtimes de contêiner para dar suporte à execução de cargas de trabalho de contêiner. Para esse pool, trabalhos e tarefas são agendados por meio do pool de orquestradores. Todas as imagens de contêiner necessárias para processamento no pool de execução são enviadas por push para um registro de contêiner usando JFrog. O pool de execução é configurado para se conectar a esse registro e efetuar pull das imagens necessárias.

As contas de armazenamento das quais os dados são lidos e gravados são montadas por meio do NFS 3.0 nos nós do lote e nos contêineres executados nos nós. Essa abordagem ajuda nós em lotes e contêineres a processar dados rapidamente sem a necessidade de baixar os arquivos de dados localmente para os nós do lote.

Invocar o Lote do Data Factory

No pipeline de extração, o gatilho passa o caminho do arquivo de metadados e o caminho de fluxo de dados brutos nos parâmetros de pipeline. O Data Factory usa uma atividade de pesquisa para analisar o JSON do arquivo de manifesto. A ID do fluxo de dados bruto pode ser extraída do caminho bruto do fluxo de dados analisando a variável de pipeline.

O Data Factory chama uma API para criar um fluxo de dados. A API retorna o caminho para o fluxo de dados extraído. O caminho extraído é adicionado ao objeto atual e o Data Factory invoca o Lote por meio de uma atividade personalizada passando o objeto atual, depois de acrescentar o caminho do fluxo de dados 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"
}

Processo de extração passo a passo

1. O Data Factory agenda um trabalho com uma tarefa para o pool de orquestradores processar uma medida para extração. O Data Factory passa as seguintes informações para o pool de orquestradores:

   • A ID da medida
   • O local dos arquivos de medida do tipo MDF4, TDMS ou rosbag que precisam ser extraídos
   • O caminho de destino do local de armazenamento do conteúdo extraído
   • A ID do fluxo de dados extraído

2. O pool de orquestradores invoca uma API para atualizar o fluxo de dados e definir seu status como Processing.

3. O pool de orquestradores cria um trabalho para cada arquivo de medida que faz parte da medida. Cada trabalho contém as seguintes tarefas:

   Tarefa	Propósito	Nota
   Validação	Valida se os dados podem ser extraídos do arquivo de medida.	Todas as outras tarefas dependem dessa tarefa.
   Metadados de processo	Deriva metadados do arquivo de medida e enriquece os metadados do arquivo usando uma API para atualizar os metadados do arquivo.
   StructuredTopics de processo	Extrai dados estruturados de um determinado arquivo de medida.	A lista de tópicos de onde extrair dados estruturados é passada como um objeto de configuração.
   CameraTopics de processo	Extrai dados de imagem de um determinado arquivo de medida.	A lista de tópicos de onde extrair imagens é passada como um objeto de configuração.
   LidarTopics de processo	Extrai dados lidar de um determinado arquivo de medida.	A lista de tópicos de onde extrair dados lidar é passada como um objeto de configuração.
   CANTopics de processo	Extrai dados de rede de área do controlador (CAN) de um determinado arquivo de medida.	A lista de tópicos de onde extrair dados é passada como um objeto de configuração.

4. O pool de orquestradores monitora o progresso de cada tarefa. Depois que todos os trabalhos forem concluídos para todos os arquivos de medida, o pool invocará uma API para atualizar o fluxo de dados e definir seu status como Completed.

5. O orquestrador sai normalmente.

   Nota

   Cada tarefa é uma imagem de contêiner separada que tem uma lógica definida adequadamente para sua finalidade. As tarefas aceitam objetos de configuração como entrada. Por exemplo, a entrada especifica onde gravar a saída e qual arquivo de medida processar. Uma matriz de tipos de tópico, como sensor_msgs/Image, é outro exemplo de entrada. Como todas as outras tarefas dependem da tarefa de validação, uma tarefa dependente é criada para ela. Todas as outras tarefas podem ser processadas de forma independente e podem ser executadas em paralelo.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Fiabilidade

A confiabilidade garante que seu aplicativo possa atender aos compromissos que você faz aos seus clientes. Para obter mais informações, consulte Visão geral do pilar de confiabilidade.

• Em sua solução, considere usar zonas de disponibilidade do Azure, que são locais físicos exclusivos na mesma região do Azure.
• Planejar a recuperação de desastres e a conta de failover.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de segurança.

É importante entender a divisão de responsabilidade entre um OEM automotivo e a Microsoft. Em um veículo, o OEM possui toda a pilha, mas à medida que os dados são movidos para a nuvem, algumas responsabilidades são transferidas para a Microsoft. As camadas de PaaS (plataforma como serviço) do Azure fornecem segurança interna na pilha física, incluindo o sistema operacional. Você pode adicionar os seguintes recursos aos componentes de segurança de infraestrutura existentes:

• Gerenciamento de identidade e acesso que usa identidades do Microsoft Entra e políticas de de Acesso Condicional do Microsoft Entra.
• Governança de infraestrutura que usa do Azure Policy.
• Governança de dados que usa Microsoft Purview.
• Criptografia de dados inativos que usam o Armazenamento do Azure nativo e os serviços de banco de dados. Para obter mais informações, consulte Considerações sobre proteção de dados.
• A proteção de chaves e segredos criptográficos. Use do Azure Key Vault para essa finalidade.

Otimização de custo

A otimização de custos analisa maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.

Uma das principais preocupações para OEMs e fornecedores de camada 1 que operam o DataOps para veículos automatizados é o custo de operação. Esta solução usa as seguintes práticas para ajudar a otimizar os custos:

• Aproveitando várias opções que o Azure oferece para hospedar o código do aplicativo. Essa solução usa o Serviço de Aplicativo e o Lote. Para obter diretrizes sobre como escolher o serviço certo para sua implantação, consulte Escolha um serviço de computação do Azure.
• Usando compartilhamento de dados in-loco no Armazenamento do Azure.
• Otimizando os custos usando de gerenciamento do ciclo de vida.
• Economizando custos no Serviço de Aplicativo usando instâncias reservadas.

Contribuintes

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos colaboradores a seguir.

Autores principais:

• Ryan Matsumura | Gerenciador de Programas Sênior
• Jochen Schroeer | Arquiteto líder (Mobilidade de Linha de Serviço)
• Brij Singh | Engenheiro de Software Principal
• Ginette Vellera | Líder sênior de engenharia de software

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas

• O que é o Lote do Azure?
• O que é o Azure Data Factory?
• Introdução ao Azure Data Lake Storage Gen2
• bem-vindo ao do Azure Cosmos DB
• Visão geral do Serviço de Aplicativo
• O que é o Azure Data Share?
• O que é o Azure Data Box?
• documentação do Azure Stack Edge
• O que é o Azure ExpressRoute?
• O que é o Azure Machine Learning?
• O que é o Azure Databricks?
• O que é o Azure Synapse Analytics?
• visão geral do Azure Monitor
• arquivos de log ROS (rosbags)
• plataforma de operações de dados em larga escala para veículos autônomos

Recursos relacionados

Para obter mais informações sobre como desenvolver o ValOps para um sistema de condução autônoma, consulte:

Você também pode estar interessado nestes artigos relacionados:

• guia de design AVOps
• análise de dados para frotas de testes automotivos
• blocos de construção para ambientes de simulação de condução autônoma
• arquitetura de referência de análise de & de dados e mensagens automotivas