conceitos de reprovisionamento de dispositivos Hub IoT

Durante o ciclo de vida de uma solução IoT, é comum mover dispositivos entre centros IoT. As razões para este movimento podem incluir os seguintes cenários:

  • Geolocalização / GeoLatency: À medida que um dispositivo se move entre locais, a latência da rede é melhorada tendo o dispositivo migrado para um hub IoT mais próximo.

  • Multi-arrendamento: Um dispositivo pode ser utilizado dentro da mesma solução IoT e reatribuído a um novo cliente, ou site do cliente. Este novo cliente pode ser reparado utilizando um hub IoT diferente.

  • Mudança de solução: Um dispositivo pode ser movido para uma nova solução IoT ou atualizada. Esta reatribuição pode exigir que o dispositivo comunique com um novo hub IoT que esteja ligado a outros componentes de back-end.

  • Quarentena: Semelhante a uma mudança de solução. Um dispositivo que esteja avariado, comprometido ou desatualizado pode ser transferido para um hub IoT que só pode atualizar e voltar a estar em conformidade. Uma vez que o dispositivo está funcionando corretamente, é então migrado de volta para o seu centro principal.

O suporte de reprovisionamento no serviço de fornecimento de dispositivos aborda estas necessidades. Os dispositivos podem ser automaticamente transferidos para novos hubs IoT com base na política de reprovisionamento configurada na entrada de inscrição do dispositivo.

Dados do estado do dispositivo

Os dados do estado do dispositivo são compostos pelas capacidades gémeas e do dispositivo do dispositivo. Estes dados são armazenados na instância do Serviço de Provisionamento de Dispositivos e no hub IoT a que um dispositivo é atribuído.

Diagram that shows how provisioning works with the Device Provisioning Service.

Quando um dispositivo é inicialmente a provisionado com uma instância do Serviço de Provisionamento de Dispositivos, são feitas as seguintes etapas:

  1. O dispositivo envia um pedido de provisionamento para uma instância do Serviço de Provisionamento de Dispositivos. A instância de serviço autentica a identidade do dispositivo com base numa entrada de inscrição e cria a configuração inicial dos dados do estado do dispositivo. A instância de serviço atribui o dispositivo a um hub IoT com base na configuração de inscrição e devolve a atribuição do hub IoT ao dispositivo.

  2. A instância de serviço de fornecimento fornece uma cópia de qualquer dado inicial do estado do dispositivo para o hub IoT atribuído. O dispositivo liga-se ao hub IoT atribuído e inicia as operações.

Com o tempo, os dados do dispositivo no hub IoT podem ser atualizados através de operações de dispositivo e operações de back-end. As informações iniciais do dispositivo armazenadas na instância do Serviço de Provisionamento de Dispositivos permanecem intocáveis. Estes dados do estado do dispositivo não tocados são a configuração inicial.

Provisioning with the Device Provisioning Service

Dependendo do cenário, à medida que um dispositivo se move entre os hubs IoT, também pode ser necessário migrar o estado do dispositivo atualizado no anterior hub IoT para o novo hub IoT. Esta migração é apoiada pela reprovisionamento de políticas no Serviço de Provisionamento de Dispositivos.

Reprovisionamento de políticas

Dependendo do cenário, um dispositivo poderia enviar um pedido para uma instância de serviço de fornecimento no reboot. Apoia igualmente um método para desencadear manualmente o provisionamento a pedido. A política de reprovisionamento de uma inscrição determina como a instância de serviço de fornecimento de dispositivos lida com estes pedidos de provisionamento. A política também determina se os dados do estado do dispositivo devem ser migrados durante a reprovisionamento. As mesmas políticas estão disponíveis para as matrículas individuais e grupos de inscrição:

  • Re-provisão e migração de dados: Esta política é o padrão para novas entradas de inscrição. Esta política toma medidas quando os dispositivos associados à inscrição apresentam um novo pedido (1). Dependendo da configuração de entrada de inscrição, o dispositivo pode ser transferido para outro hub IoT. Se o dispositivo estiver a mudar os hubs IoT, o registo do dispositivo com o hub IoT inicial será removido. A informação atualizada do estado do dispositivo a partir desse hub inicial de IoT será migrada para o novo hub IoT (2). Durante a migração, o estado do dispositivo será reportado como Atribuição.

    Diagram that shows that a policy takes action when devices associated with the enrollment entry submit a new request.

  • Re-provisão e reset ao config inicial: Esta política toma medidas quando os dispositivos associados à inscrição apresentam um novo pedido de provisionamento (1). Dependendo da configuração de entrada de inscrição, o dispositivo pode ser transferido para outro hub IoT. Se o dispositivo estiver a mudar os hubs IoT, o registo do dispositivo com o hub IoT inicial será removido. Os dados iniciais de configuração que a instância de serviço de fornecimento recebida quando o dispositivo foi fornecido são fornecidos ao novo hub IoT (2). Durante a migração, o estado do dispositivo será reportado como Atribuição.

    Esta política é frequentemente utilizada para um reset de fábrica sem alterar centros de IoT.

    Diagram that shows how a policy takes action when devices associated with the enrollment entry submit a new provisioning request.

  • Nunca reresa disposição: O dispositivo nunca é transferido para um centro diferente. Esta política está prevista para gerir a retrocompatibilidade.

Nota

O DPS irá sempre chamar o webhook de atribuição personalizada, independentemente da política de realocamento, caso haja um novo ReturnData para o dispositivo. Se a política de realocamento não for definida para nunca voltar a ser re-provisidora, o webhook será chamado, mas o dispositivo não alterará o seu hub designado.

Ao desenhar a sua solução e definir uma lógica de reprovisionamento, há algumas coisas a considerar. Por exemplo:

  • Quantas vezes espera que os seus dispositivos reiniciem
  • As quotas e limites do DPS
  • Tempo de implantação esperado para a sua frota (lançamento faseado vs todos ao mesmo tempo)
  • Capacidade de retagem implementada no seu código cliente, conforme descrito na orientação geral da Retry no Centro de Arquitetura Azure

Dica

Recomendamos que não forneça em todos os reboots do dispositivo, pois isso pode causar alguns problemas ao reprovisionar vários milhares ou milhões de dispositivos ao mesmo tempo. Em vez disso, deverá tentar utilizar a API do Estado de Registo do Dispositivo e tentar ligar-se a essa informação para Hub IoT. Se isso falhar, tente reprovisionar como a Hub IoT informação pode ter mudado. Tenha em mente que a consulta para o estado de registo contará como um novo registo do dispositivo, pelo que deve considerar o limite de registo do Dispositivo. Considere também implementar uma lógica de relírimento adequada, como o recuo exponencial com a aleatoriedade, conforme descrito na orientação geral de Retry. Em alguns casos, dependendo das capacidades do dispositivo, é possível guardar a informação Hub IoT diretamente no dispositivo para ligar diretamente a Hub IoT após o fornecimento pela primeira vez usando DPS. Se optar por fazê-lo, certifique-se de que implementa um mecanismo de recuo no caso de ocorrerem erros específicos do Hub, por exemplo, considere os seguintes cenários:

  • Reda o funcionamento do Hub se o código de resultados for 429 (Pedidos de Muitos) ou um erro na gama 5xx. Não realize repetições para outros erros.
  • Por 429 erros, só volta a tentar depois do tempo indicado no cabeceamento Retry-After.
  • Para erros de 5xx, utilize o recuo exponencial, com a primeira repetição pelo menos 5 segundos após a resposta.
  • Em erros que não 429 e 5xx, re-registre-se através de DPS
  • Idealmente, também deve apoiar um método para desencadear manualmente o provisionamento a pedido.

Recomendamos também ter em conta os limites de serviço ao planear atividades como empurrar atualizações para a sua frota. Por exemplo, atualizar a frota de uma só vez pode fazer com que todos os dispositivos se registem através de DPS (o que poderia facilmente estar acima do limite de quota de registo) - Para tais cenários, considere o planeamento de atualizações de dispositivos em fases em vez de atualizar toda a sua frota ao mesmo tempo.

Gerir a retrocompatibilidade

Antes de setembro de 2018, as atribuições de dispositivos aos centros de IoT tiveram um comportamento pegajoso. Quando um dispositivo voltasse ao processo de provisionamento, só seria atribuído de volta ao mesmo hub de IoT.

Para soluções que tenham assumido uma dependência deste comportamento, o serviço de prestação inclui retrocompatibilidade. Este comportamento é atualmente mantido para dispositivos de acordo com os seguintes critérios:

  1. Os dispositivos ligam-se a uma versão API antes da disponibilidade de suporte nativo de reprovisionamento no Serviço de Provisionamento de Dispositivos. Consulte a tabela API abaixo.

  2. A entrada de inscrição para os dispositivos não tem uma política de reprovisionamento definida neles.

Esta compatibilidade garante que os dispositivos previamente implantados experimentam o mesmo comportamento que está presente durante os testes iniciais. Para preservar o comportamento anterior, não guarde uma política de reprovisionamento para estas matrículas. Se for definida uma política de reprovisionamento, a política de reprovisionamento tem precedência sobre o comportamento. Ao permitir que a política de reprovisionamento tenha precedência, os clientes podem atualizar o comportamento do dispositivo sem terem de reimagemar o dispositivo.

O gráfico de fluxo a seguir ajuda a mostrar quando o comportamento está presente:

backwards compatibility flow chart

A tabela a seguir mostra as versões API antes da disponibilidade de suporte nativo de reprovisionamento no Serviço de Provisionamento de Dispositivos:

API REST C SDK SDK Python SDK de Node SDK Java SDK .NET
2018-04-01 e mais cedo 1.2.8 e mais cedo 1.4.2 e mais cedo 1.7.3 ou mais cedo 1.13.0 ou mais cedo 1.1.0 ou mais cedo

Nota

Estes valores e links são suscetíveis de mudar. Esta é apenas uma tentativa de determinar onde as versões podem ser determinadas por um cliente e quais serão as versões esperadas.

Passos seguintes