Partilhar via


Funções e operações

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

O provisionamento também impõe requisitos ao 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 depois que o provisionamento automático já está estabelecido.

Uma série de Quickstarts é fornecida no índice à esquerda, para ajudar a explicar o aprovisionamento automático através da experiência prática. A fim de facilitar/simplificar o processo de aprendizagem, um software é usado para simular um dispositivo físico para matrícula e registro. Alguns Quickstarts exigem que você cumpra operações para várias funções, incluindo operações para funções inexistentes, devido à natureza simulada dos Quickstarts.

Funções Funcionamento Descrição
Fabricante Codificar identidade e URL de 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 Dispositivo.

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

Arranque rápido: como o dispositivo é simulado, não há nenhum 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 na instância do Serviço de Provisionamento de Dispositivo.
Operador Configurar o provisionamento automático Esta operação corresponde à primeira fase do provisionamento automático.

Inícios Rápidos: como Operador, executa a função de configurar o Serviço de Provisionamento de Dispositivos e as instâncias do Hub IoT na sua subscrição do Azure.
Registrar identidade do dispositivo Esta operação corresponde à segunda fase do provisionamento automático.

Guia de início rápido: você executa a função de Operador, registrando seu dispositivo simulado na instância do Serviço de Provisionamento de Dispositivo. O método de atestado simulado no Início Rápido (TPM ou X.509) determina a identidade do dispositivo. Consulte a função Desenvolvedor para obter detalhes sobre o atestado.
Serviço de provisionamento de dispositivos,
Hub IoT
<todas as operações> Para uma implementação de produção com dispositivos físicos e Quickstarts com dispositivos simulados, essas funções são cumpridas por meio dos serviços IoT que você configura 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 Esta 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.

Guia de início rápido: o aplicativo de registro de exemplo que você cria simula um dispositivo real, para sua plataforma/idioma 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 um implantado em um dispositivo físico. Você especifica o método de atestado (certificado TPM ou X.509), além da URL de registro e do "Escopo de ID" da instância do Serviço de Provisionamento de Dispositivo. A lógica de atestado do SDK em tempo de execução determina a identidade do dispositivo, com base no método especificado:
  • Atestado TPM - sua estação de trabalho de desenvolvimento executa um aplicativo de simulador TPM. Uma vez executado, um aplicativo separado é usado para extrair a "Chave de endosso" e o "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. Uma vez 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.
Dispositivo Inicialização e registo Esta operação corresponde à terceira fase do autoprovisionamento, realizada pelo software de registro de dispositivos construído 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 Dispositivo, de acordo com a URL global e o "Escopo de ID" do serviço especificados durante o desenvolvimento.
  2. Uma vez conectado, o dispositivo é autenticado em relação ao método de atestado e à identidade especificada 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 registo bem-sucedido, um ID de dispositivo exclusivo e um ponto de extremidade do Hub IoT são retornados à aplicação de registo para comunicação com o Hub IoT.
  5. A partir daí, o dispositivo pode puxar para baixo seu estado gêmeo inicial do dispositivo para configuração e iniciar o processo de relatório de dados de telemetria.
Guia de início rápido: 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 das operações durante o provisionamento automático do dispositivo:

Diagrama de sequência que mostra as funções e o sequenciamento das 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 Dispositivo (em vez de por meio do Operador). Para obter uma discussão detalhada sobre esse sequenciamento e muito mais, consulte o vídeo Registro de dispositivo zero touch com o Azure IoT (a partir do 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 estar 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 introduz segurança em módulos de segurança de hardware (HSMs). Essa segurança pode incluir o fabricante obtendo chaves, certificados, etc. de clientes em potencial que já têm instâncias DPS e grupos de registro configurados. O fabricante também poderia gerar essas informações de segurança para seus clientes.

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

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

  • Conta #2: Utilizadores finais, clientes de segundo nível podem ter os seus próprios hubs IoT. A entidade associada à Conta #1 apenas redireciona os dispositivos alugados para o hub correto nesta 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.

OEM tudo-em-um

O fabricante poderia ser um "OEM tudo-em-um" onde apenas uma única conta de fabricante seria necessária. O fabricante lida com segurança e provisionamento de ponta a ponta.

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

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

Próximos passos

Você pode achar útil marcar este artigo como um ponto de referência, enquanto percorre os Quickstarts de provisionamento automático correspondentes.

Comece por completar um "Início rápido para configurar o provisionamento automático" que melhor se adeque à sua preferência de ferramenta de gestão, orientando-o pela fase "Configuração do serviço".

Em seguida, continue com um "Início Rápido: Provisionar um dispositivo" que se adapte ao seu mecanismo de atestado do dispositivo e à sua preferência de SDK/língua do Serviço de Provisionamento de Dispositivos. Neste Início Rápido, você percorre as fases "Inscrição do dispositivo" e "Registro e configuração do dispositivo":

Mecanismo de certificação do dispositivo Início Rápido
Chave simétrica Provisionar um dispositivo de chave simétrica simulada
certificado X.509 Provisionar um dispositivo X.509 simulado
Módulo de plataforma confiável simulado (TPM) Provisionar um dispositivo TPM simulado