Compartilhar via

Funções e operações

As fases de desenvolvimento de uma solução de IoT podem se estender por semanas ou meses, devido a realidades de produção, como tempo de fabricação, envio, processo alfandegário etc. Além disso, eles podem abranger atividades em várias funções, considerando as várias entidades envolvidas. Este artigo analisa mais detalhadamente as várias funções e operações relacionadas a cada fase e ilustra o fluxo em um diagrama de sequência.

O provisionamento também coloca requisitos no fabricante do dispositivo, específicos para habilitar o mecanismo de atestado. As operações de fabricação também podem ocorrer independentemente do tempo das fases de provisionamento automático, especialmente nos casos em que novos dispositivos são adquiridos após o autoprovisionamento já estar estabelecido.

Uma série de Inícios Rápidos é fornecida no sumário à esquerda, para ajudar a explicar o provisionamento automático por meio da experiência prática. Para facilitar/simplificar o processo de aprendizagem, o software é usado para simular um dispositivo físico para inscrição e registro. Alguns inícios rápidos exigem que você cumpra operações para várias funções, incluindo operações para funções inexistentes, devido à natureza simulada dos Inícios Rápidos.

Função Operation Description
Fabricante Codificar a URL de identidade e registro Com base no mecanismo de atestado usado, o fabricante é responsável por codificar as informações de identidade do dispositivo e a URL de registro do Serviço de Provisionamento de Dispositivos.

Início Rápido: como o dispositivo é simulado, não há funções de fabricante. Consulte a função Desenvolvedor para obter detalhes sobre como obter essas informações, que são usadas na codificação de um aplicativo de registro de exemplo.
Fornecer identidade do dispositivo Como o criador das informações de identidade do dispositivo, o fabricante é responsável por comunicá-lo ao operador (ou a um agente designado) ou registrá-lo diretamente no Serviço de Provisionamento de Dispositivos por meio de APIs.

Inícios rápidos: como o dispositivo é simulado, não há papel de Fabricante. Consulte a função Operador para obter detalhes sobre como obter a identidade do dispositivo, que é usada para registrar um dispositivo simulado em sua instância do Serviço de Provisionamento de Dispositivos.
Operator Configurar o provisionamento automático Essa operação corresponde à primeira fase do provisionamento automático.

Inícios Rápidos: você executa a função Operador, configurando as instâncias do Serviço de Provisionamento de Dispositivos e do Hub IoT em sua assinatura do Azure.
Registrar a identidade do dispositivo Essa operação corresponde à segunda fase do provisionamento automático.

Inícios Rápidos: você executa a função Operador, registrando seu dispositivo simulado na instância do Serviço de Provisionamento de Dispositivos. O método de atestado simulado no Início Rápido (TPM ou X.509) determina a identidade do dispositivo. Consulte o papel de Desenvolvedor para obter detalhes de confirmação.
Serviço de Provisionamento de Dispositivos,
Hub IoT		 <todas as operações> Para uma implementação de produção com dispositivos físicos e inícios rápidos com dispositivos simulados, essas funções são atendidas por meio dos serviços de IoT configurados em sua assinatura do Azure. As funções/operações funcionam exatamente da mesma forma, pois os serviços de IoT são indiferentes ao provisionamento de dispositivos físicos versus simulados.
Desenvolvedor Criar/implantar software de registro Essa operação corresponde à terceira fase do provisionamento automático. O Desenvolvedor é responsável por criar e implantar o software de registro no dispositivo, usando o SDK apropriado.

Inícios Rápidos: o aplicativo de registro de exemplo que você cria simula um dispositivo real, para sua plataforma/linguagem de escolha, que é executado em sua estação de trabalho (em vez de implantá-lo em um dispositivo físico). O aplicativo de registro executa as mesmas operações que uma implantada em um dispositivo físico. Você especifica o método de atestado (certificado X.509 ou TPM), a URL de registro e o "Escopo da ID" da sua instância do Serviço de Provisionamento de Dispositivos. A lógica de atestado do SDK em runtime determina a identidade do dispositivo, com base no método especificado:
  • Atestado do TPM – sua estação de trabalho de desenvolvimento executa um aplicativo simulador do TPM. Após a execução, um aplicativo separado é usado para extrair a "Chave de Endosso" e a "ID de Registro" do TPM para uso no registro da identidade do dispositivo. A lógica de atestado do SDK também usa o simulador durante o registro para apresentar um token SAS assinado para autenticação e verificação de registro.
  • Atestado X509 – você usa uma ferramenta para gerar um certificado. Depois de gerado, você cria o arquivo de certificado necessário para uso no registro. A lógica de atestado do SDK também usa o certificado durante o registro, para apresentar para autenticação e verificação de registro.
Device Inicialização e registro Essa operação corresponde à terceira fase do provisionamento automático, atendida pelo software de registro de dispositivo criado pelo Desenvolvedor. Consulte a função Desenvolvedor para obter detalhes. Após a primeira inicialização:
  1. O aplicativo se conecta com a instância do Serviço de Provisionamento de Dispositivos, de acordo com a URL global e o "ID Scope" do serviço especificados durante o desenvolvimento.
  2. Uma vez conectado, o dispositivo é autenticado em relação ao método de atestado e à identidade especificados durante o registro.
  3. Depois de autenticado, o dispositivo é registrado com a instância do Hub IoT especificada pela instância do serviço de provisionamento.
  4. Após o registro, uma ID de dispositivo exclusiva e o ponto de extremidade do Hub IoT são retornados para o aplicativo de registro para se comunicar com o Hub IoT.
  5. A partir daí, o dispositivo pode extrair seu estado de dispositivo gêmeo inicial para configuração e iniciar o processo de reportar dados telemétricos.
Inícios rápidos: como o dispositivo é simulado, o software de registro é executado em sua estação de trabalho de desenvolvimento.

O diagrama a seguir resume as funções e o sequenciamento de operações durante o provisionamento automático do dispositivo:

Diagrama de sequência que mostra as funções e o sequenciamento de operações durante o provisionamento automático do dispositivo.

Observação

Opcionalmente, o fabricante também pode executar a operação "Registrar identidade do dispositivo" usando APIs do Serviço de Provisionamento de Dispositivos (em vez de por meio do Operador). Para uma discussão detalhada sobre esse sequenciamento e mais, consulte o vídeo Registro de dispositivos sem toque com Azure IoT (começando no marcador 41:00)

Funções e contas do Azure

A forma como cada função é mapeada para uma conta do Azure depende do cenário e há alguns cenários que podem ser envolvidos. Os padrões comuns a seguir devem ajudar a fornecer uma compreensão geral sobre como as funções são mapeadas para uma conta do Azure.

Fabricante de chips fornece serviços de segurança

Nesse cenário, o fabricante gerencia a segurança para clientes de nível um. Esse cenário pode ser preferível para esses clientes de nível um, pois eles não precisam gerenciar a segurança detalhada.

O fabricante apresenta a segurança nos HSMs (Módulos de Segurança de Hardware). Essa segurança pode incluir o fabricante obtendo chaves, certificados etc. de clientes potenciais que já têm instâncias DPS e grupos de registro configurados. O fabricante também pode gerar essas informações de segurança para seus clientes.

Nesse cenário, pode haver duas contas do Azure envolvidas:

  • Conta nº 1: provavelmente compartilhada entre as funções de operador e desenvolvedor até certo ponto. Essa parte pode comprar os chips HSM do fabricante. Esses chips são direcionados para instâncias DPS associadas à Conta número 1. Com registros de DPS, essa parte pode conceder a dispositivos para vários clientes de nível dois reconfigurando as configurações de registro de dispositivo no DPS. Essa parte também pode ter hubs IoT alocados para que os sistemas de back-end do usuário-final interajam, a fim de acessar a telemetria do dispositivo, etc. Neste último caso, uma segunda conta pode não ser necessária.

  • Conta nº 2: usuários finais, clientes de nível dois podem ter seus próprios hubs IoT. Parte associada com a Conta N. 1 apenas aponta dispositivos concedidos para o hub correto nessa conta. Essa configuração requer a vinculação de hubs DPS e IoT entre contas do Azure, o que pode ser feito com modelos do Azure Resource Manager.

Tudo-em-um OEM

O fabricante pode ser um "All-in-one OEM" em que apenas uma única conta de fabricante seria necessária. O fabricante manipula a segurança e o provisionamento de ponta a ponta.

O fabricante pode fornecer um aplicativo baseado em nuvem para clientes que compram dispositivos. Esse aplicativo interface com o hub IoT alocado pelo fabricante.

Máquinas de venda automática ou máquinas de café automatizadas representam exemplos nesse cenário.

Próximas etapas

Pode ser útil marcar esse artigo como um ponto de referência, enquanto você analisa o Início Rápido de provisionamento automático correspondente.

Comece concluindo o Guia de início rápido "Configurar o provisionamento automático" que melhor se adapte à sua preferência de ferramenta de gerenciamento, que o orienta através da fase "Configuração do serviço":

Em seguida, continue com um Início Rápido de "Provisionamento de um dispositivo" que atenda ao seu mecanismo de atestado do dispositivo e à preferência de idioma/SDK do Serviço de Provisionamento de Dispositivos. Neste Início Rápido, você percorrerá as fases "Registro de dispositivo" e "Registro e configuração do dispositivo":

Mecanismo de atestado do dispositivo Início Rápido
Chave simétrica Provisionar um dispositivo de chave simétrica simulado
certificado X.509 Provisionar um dispositivo X.509 simulado
Módulo de plataforma confiável simulado (TPM) Provisionar um dispositivo TPM simulado
  • Last updated on