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

Este artigo apresenta uma solução e orientação para o desenvolvimento de operações de dados offline e gerenciamento de dados (DataOps) para um sistema de condução automatizada. A solução DataOps é construída com base na estrutura descrita no guia de design Operações de veículos autônomos (AVOps). DataOps é um dos blocos de construção do AVOps. Outros blocos de construção incluem operações de aprendizado de máquina (MLOps), operações de validação (ValOps), DevOps e funções AVOps centralizadas.

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

Arquitetura

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

Fluxo de dados

1. Os dados de medição têm origem 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 registadores de dados no veículo armazenam os dados de medição em dispositivos de armazenamento do registador. Os dados de armazenamento do registrador são carregados em um data lake de pouso. 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 Armazenamento do Azure Data Lake: MDF4 (Measurement Data Format versão 4), TDMS (Technical Data Management Systems) 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 é acionado em um intervalo agendado para processar os dados na conta de armazenamento de destino. 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 rastreamento 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 medição, há um fluxo de dados brutos.
   • Copia os dados para uma conta de armazenamento chamada Raw no Armazenamento Data Lake.
   • 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 Azure Batch processam os dados na zona bruta para extrair informações que os sistemas downstream podem consumir:

   • O Batch lê os dados de tópicos no arquivo bruto e produz os dados em tópicos selecionados nas respetivas 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. Estas funções extraem processamento de imagem, lidar, radar e dados GPS. Eles também realizam o processamento de metadados. O Data Factory e o Batch fornecem uma maneira de executar paralelismo de forma escalável.
   • Os dados são reduzidos para reduzir a quantidade de dados que precisam ser rotulados e anotados.

4. Se os dados do registrador de veículos não estiverem sincronizados entre os vários sensores, um pipeline do Data Factory será acionado sincronizando os dados para criar um conjunto de dados válido. O algoritmo de sincronização é executado em lote.

5. Um pipeline do Data Factory é executado para enriquecer os dados. Exemplos de melhorias incluem telemetria, dados do registrador de veículos e outros dados, como dados meteorológicos, de mapas ou de objetos. 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 que são 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 terceirizados realizam etiquetagem manual ou automática. Os dados são partilhados com os parceiros terceiros através da Partilha de Dados do Azure e estão integrados no Microsoft Purview. O Compartilhamento de Dados usa uma conta de armazenamento dedicada chamada Rotulada no Armazenamento Data Lake para retornar os dados rotulados à organização.

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

8. Além de metadados para os dados de enriquecimento e cenas detetadas, o repositório de metadados no Azure Cosmos DB armazena metadados para as medições, como dados de unidade. Esse armazenamento também contém metadados para a linhagem dos dados à medida que eles passam pelos processos de extração, redução da amostragem, sincronização, enriquecimento e deteção de cena. A API de metadados é usada para acessar as medições, a linhagem e os dados da cena e para procurar onde os dados estão armazenados. Como resultado, a API de metadados serve como um gerenciador de camada 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 armazenamento de metadados é um componente centralizado que oferece rastreabilidade e linhagem em todo o 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 forma rápida, barata e confiável. Nesta solução, o Data Box é utilizado para transferir os dados recolhidos do veículo para o Azure através de uma transportadora regional.
• dispositivos de do Azure Stack Edge fornecem a funcionalidade do Azure em pontos de presença. Exemplos de recursos do Azure incluem computação, armazenamento, rede e aprendizado de máquina acelerado por hardware.
• ExpressRoute estende uma rede local para o Microsoft Cloud através de uma conexão privada.
• Data Lake Storage contém uma grande quantidade de dados em seu formato nativo 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 de extração, transformação, carregamento (ETL) e extração, carga, transformação (ELT). Aqui, o Data Factory executa ETL por meio de de computação em lote e cria fluxos de trabalho orientados por dados para orquestrar a movimentação de dados e transformá-los.
• Batch executa trabalhos em lote paralelos e de computação de alto desempenho (HPC) em grande escala de forma eficiente no Azure. Essa solução usa o Batch para executar aplicativos de grande escala para tarefas como disputa 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 medições armazenadas.
• Data Share partilha dados com organizações parceiras com segurança melhorada. Usando o compartilhamento in-loco, os provedores de dados podem compartilhar dados onde eles residem sem copiar os dados ou tirar instantâneos. Nesta solução, a Data Share partilha dados com empresas de rotulagem.
• Azure Databricks fornece um conjunto de ferramentas para manter soluções de dados de nível empresarial em escala. É necessário para operações de longa duração em grandes quantidades de dados do veículo. Os engenheiros de dados usam o Azure Databricks como uma bancada de análise.
• Azure Synapse Analytics reduz o tempo de perceção em armazéns de dados e sistemas de big data.
• de Pesquisa Cognitiva do Azure fornece serviços de pesquisa de 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 em todas as organizações.
• de Registro de Contêiner do Azure é um serviço que cria um registro gerenciado de imagens de contêiner. Esta solução usa o Registro de Contêiner para armazenar contêineres para tópicos de processamento.
• Application Insights é uma extensão do Azure Monitor que fornece gerenciamento de desempenho de aplicativos. Nesse cenário, o Application Insights ajuda você a criar observabilidade em torno da extração de medição: você pode usar o Application Insights para registrar eventos personalizados, métricas personalizadas e outras informações enquanto a solução processa cada medição para extração. Você também pode criar consultas no Log Analytics para obter informações detalhadas sobre cada medição.

Detalhes do cenário

Projetar uma estrutura robusta de DataOps para veículos autônomos é crucial para usar seus dados, rastrear sua linhagem e disponibilizá-los em toda a 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 tenham uma linhagem clara. Também facilita a gestão e análise dos dados, levando a uma tomada de decisão mais informada e a um melhor desempenho do veículo.

Um processo de DataOps eficiente fornece uma maneira de distribuir dados facilmente em toda a sua organização. Várias equipes podem então acessar as informações de que precisam 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:

• Gestão do volume diário de dados de medição em escala de terabytes ou petabytes de veículos de investigação 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 perceção crítica de segurança que captura o versionamento e a linhagem de dados de medição.
• Metadados e descoberta de dados para melhorar a segmentação semântica, a classificação de imagens e os modelos de deteção de objetos.

Esta solução AVOps DataOps fornece orientação sobre como enfrentar esses desafios.

Casos de uso potenciais

Esta solução beneficia os fabricantes de equipamento original (OEM) para automóveis, os fornecedores de nível 1 e os fornecedores independentes de software (ISVs) que desenvolvem soluções para a condução automatizada.

Operações de dados federados

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

• Descentralização orientada para o 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 produto. Cada domínio de dados tem várias zonas em contêineres de armazenamento implementados pelo data-lake. Existem 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.
• Dados de autoatendimento como uma plataforma para habilitar equipes de dados autônomas e orientadas a domínios.
• Governança federada para permitir a interoperabilidade e o acesso entre domínios de dados AVOps que exigem um armazenamento centralizado de metadados 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 de análise em escala de nuvem .

Exemplo de estrutura para domínios de dados AVOps

A tabela a seguir fornece algumas ideias para estruturar domínios de dados 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 tempos de execução 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, são necessários dois componentes:

• Um repositório de metadados que persiste metadados sobre arquivos de medição processados e fluxos de dados, como sequências de vídeo. Esse componente torna os dados detetáveis e rastreáveis com anotações que precisam ser indexadas, como para pesquisar os metadados de arquivos sem rótulo. Por exemplo, talvez você queira que o repositório de metadados retorne todos os quadros para números de identificação de veículos (VINs) 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 AVOps e quais armazenamentos de dados estão envolvidos no loop de dados AVOps. Um exemplo de um catálogo de dados é Microsoft Purview.

Você pode usar o Azure Data Explorer ou a Pesquisa Cognitiva do Azure 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 a Pesquisa Cognitiva do Azure para recursos de pesquisa semântica.

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

Partilha de dados

O compartilhamento de dados é um cenário comum em um loop de dados AVOps. Os usos incluem 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 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 a troca de dados de rótulos incluem conjuntos de dados Common Objects in Context (COCO) e conjuntos de dados OpenLABEL da Association for Standardization of Automation and Measuring Systems (ASAM).

Nesta solução, os conjuntos de dados rotulados são usados em processos de MLOps para criar algoritmos especializados, como modelos de perceção e fusão de sensores. Os algoritmos podem detetar cenas e objetos em um ambiente, como o carro mudando de faixa, estradas bloqueadas, tráfego de pedestres, semáforos e sinais 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 oferece eficiência, escalabilidade, consistência, reprodutibilidade, adaptabilidade e benefícios de tratamento de erros. Melhora o processo de desenvolvimento global, acelera o progresso e apoia a 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 deve estruturar suas contas de armazenamento.

Estrutura hierárquica de pastas

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

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

região/raw/<measurement ID>/<data-stream-ID>/AAAA/MM/DD

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

região/extraído/<ID de medição>/<>de identificação de fluxo de dados /AAAA/MM/DD

Usando estruturas hierárquicas semelhantes, você pode aproveitar o recurso de namespace hierárquico do Armazenamento Data Lake. As estruturas hierárquicas ajudam a criar armazenamento de objetos escalável e econômico. Essas estruturas também melhoram a eficiência da busca e recuperação de objetos. O 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 destino para conta de armazenamento bruto

Um pipeline do Data Factory é acionado com base em uma programação. Depois que o pipeline é acionado, os dados são copiados da conta de armazenamento de destino para a conta de armazenamento bruto.

O pipeline recupera todas as pastas de medição e itera através delas. A cada medição, a solução realiza as seguintes atividades:

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

2. Uma chamada de API da Web é feita para uma API que cria uma medição, e a carga JSON do arquivo JSON do manifesto de medição é passada para a API. Se a chamada for bem-sucedida, a resposta será analisada para recuperar o ID de medição. Se a chamada falhar, a medição será movida para a atividade no erro para tratamento de erros.

   Observação

   Essa solução DataOps é criada com base na suposição de que você limita o número de solicitações ao serviço do aplicativo. Se sua solução pode fazer um número indeterminado de solicitações, considere um padrão de limitação de taxa de .

3. Uma chamada de API da Web é feita para uma API que cria um fluxo de dados criando a carga JSON necessária. 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 medição será movida para a atividade no erro.

4. Uma chamada de API da 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 medição para o local do fluxo de dados. Se a chamada falhar, a medição será movida para a atividade no erro.

5. Um pipeline do Data Factory invoca o Batch para copiar os arquivos de medição da conta de armazenamento de destino para a conta de armazenamento bruto. Um módulo de cópia de um aplicativo orchestrator cria um trabalho com as seguintes tarefas para cada medição:

   • Copie os arquivos de medição para a conta de armazenamento bruto.
   • Copie os arquivos de medição para uma conta de armazenamento de arquivamento.
   • Remova os arquivos de medição da conta de armazenamento de destino.

   Observação

   Nessas tarefas, o Batch usa um pool de orquestradores e a ferramenta AzCopy para copiar e remover dados. 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 de API da Web é feita para atualizar o estado do fluxo de dados para Copy Complete. Se a chamada for bem-sucedida, a sequência prossegue para a próxima atividade. Se a chamada falhar, a medição será movida para a atividade no erro.

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

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

Observe os seguintes pontos:

• Esses pipelines são acionados com base em um cronograma. Esta abordagem ajuda a melhorar a rastreabilidade das corridas de condutas 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 terminem antes que a próxima execução agendada seja iniciada.
• Cada pipeline é configurado para copiar medições em paralelo. Por exemplo, se uma execução programada pegar 10 medições para copiar, as etapas do pipeline podem ser executadas simultaneamente para todas as dez medições.
• 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 medições parciais, por exemplo, medições com arquivos rosbag ausentes.

Projeto de lote

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

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 Linux sem suporte a tempo de execução de contêiner. O pool executa código Python que usa a API em 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 Linux com tempos de execução de contêiner para suportar cargas de trabalho de contêiner em execução. Para este pool, trabalhos e tarefas são agendados através do pool orchestrator. 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 está configurado para se conectar a esse registro e extrair as imagens necessárias.

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

Invocar lote do Data Factory

No pipeline de extração, o gatilho passa o caminho do arquivo de metadados e o caminho do fluxo de dados brutos nos parâmetros do pipeline. O Data Factory usa uma atividade de Pesquisa para analisar o JSON do arquivo de manifesto. O ID do fluxo de dados brutos pode ser extraído do caminho do fluxo de dados brutos 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ídos. O caminho extraído é adicionado ao objeto atual e o Data Factory invoca Batch por meio de uma atividade personalizada passando o objeto atual, depois de anexar 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 gradual

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

   • O ID da medição
   • A localização dos arquivos de medição do tipo MDF4, TDMS ou rosbag que precisam ser extraídos
   • O caminho de destino do local de armazenamento do conteúdo extraído
   • O 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 medição que faz parte da medição. Cada trabalho contém as seguintes tarefas:

   Tarefa	Finalidade	Observação
   Validação	Valida que os dados podem ser extraídos do arquivo de medição.	Todas as outras tarefas dependem desta tarefa.
   Processar metadados	Deriva metadados do arquivo de medição e enriquece os metadados do arquivo usando uma API para atualizar os metadados do arquivo.
   Processo StructuredTopics	Extrai dados estruturados de um determinado arquivo de medição.	A lista de tópicos dos quais extrair dados estruturados é passada como um objeto de configuração.
   Processo CameraTopics	Extrai dados de imagem de um determinado arquivo de medição.	A lista de tópicos dos quais extrair imagens é passada como um objeto de configuração.
   Processo LidarTopics	Extrai dados lidar de um determinado arquivo de medição.	A lista de tópicos dos quais extrair dados lidar é passada como um objeto de configuração.
   Processo CANTopics	Extrai dados de rede de área controladora (CAN) de um determinado arquivo de medição.	A lista de tópicos dos quais 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 medição, o pool invocará uma API para atualizar o fluxo de dados e definir seu status como Completed.

5. O orquestrador sai gracioso.

   Observação

   Cada tarefa é uma imagem de contêiner separada que tem lógica definida apropriadamente 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 medição processar. Uma matriz de tipos de tópicos, 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ê assume com 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 dentro da mesma região do Azure.
• Planeje a recuperação de desastres e o failover de de conta.

Segurança

A segurança oferece 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 se movem para a nuvem, algumas responsabilidades são transferidas para a Microsoft. As camadas de plataforma como serviço (PaaS) 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 Azure Policy.
• Governança de dados que usa Microsoft Purview.
• Criptografia de dados em repouso que usa o Armazenamento do Azure nativo e serviços de banco de dados. Para obter mais informações, consulte Considerações sobre proteção de dados.
• A salvaguarda de chaves criptográficas e segredos. Use do Azure Key Vault para essa finalidade.

Otimização de custos

A otimização de custos procura formas 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 dos OEMs e fornecedores de nível 1 que operam DataOps para veículos automatizados é o custo de operação. Esta solução utiliza as seguintes práticas para ajudar a otimizar custos:

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

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

• Ryan Matsumura | Gerente de Programa Sênior
• Jochen Schroeer | Arquiteto Líder (Service Line Mobility)
• 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, faça login no LinkedIn.

Próximos passos

• O que é o Azure Batch?
• O que é o Azure Data Factory?
• Introdução ao Azure Data Lake Storage Gen2
• Bem-vindo ao Azure Cosmos DB
• Visão geral do Serviço de Aplicativo
• O que é o Compartilhamento de Dados do Azure?
• O que é o Azure Data Box?
• de 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 Grande Escala para Veículos Autónomos

Recursos relacionados

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

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

• Guia de design do 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 mensagens automotivas, dados & análises