Compartilhar via


Sobre atualizações over-the-air

Importante

Esta é a documentação do Azure Sphere (herdado). O Azure Sphere (herdado) será desativado em 27 de setembro de 2027 e os usuários devem migrar para o Azure Sphere (integrado) até esse momento. Use o seletor de versão localizado acima do sumário para exibir a documentação do Azure Sphere (Integrado).

As atualizações são uma parte importante do modelo de segurança do Azure Sphere, pois incorporam a propriedade da segurança renovável. Garantir que as atualizações ocorram regularmente ajuda a manter a conformidade com as propriedades 7 dos seus dispositivos. Os dispositivos do Azure Sphere verificam se há atualizações quando se conectam à Internet pela primeira vez depois de ligar ou depois que o botão Redefinir é pressionado. Depois disso, as verificações ocorrem em intervalos regulares (atualmente 20 horas).

Há três tipos de atualizações: atualizações de pré-requisito, atualizações do sistema operacional e atualizações de implantação. As atualizações de pré-requisito são usadas para garantir que os componentes dos quais o próprio processo de atualização depende — atualmente o TKS (Repositório de Chaves Confiáveis) e o repositório de certificados — estejam atualizados. O TKS é usado para autenticar as imagens a serem baixadas e instaladas, enquanto o repositório de certificados valida as conexões com a Internet. Uma atualização do sistema operacional tem como alvo o software fornecido pela Microsoft no dispositivo, incluindo o sistema operacional do mundo normal em que seus aplicativos são executados, mas também firmware de nível inferior, como o subsistema Pluton e o Monitor de Segurança. As atualizações de implantação são direcionadas ao seu próprio software, seus aplicativos de alto nível e em tempo real e imagens de configuração de placa (se houver). As atualizações de pré-requisito e sistema operacional são gerenciadas pelo Azure Sphere; As atualizações de aplicativos são coordenadas pelo Azure Sphere com base nas implantações criadas por sua organização.

Para que qualquer dispositivo receba pré-requisitos ou atualizações do sistema operacional:

  • Ele deve estar conectado à Internet.
  • Os requisitos de rede devem ser configurados adequadamente.

Para que qualquer dispositivo atualize suas imagens de configuração de aplicativo e placa:

  • Ele não deve ter a capacidade de desenvolvimento de aplicativos.
  • Deve ser reivindicado por um inquilino.
  • Ele deve pertencer a um grupo de dispositivos.
  • O grupo de dispositivos ao qual ele pertence deve ser direcionado por uma implantação.
  • A implantação deve conter imagens de aplicativo (e, opcionalmente, uma imagem de configuração de placa) criadas por ou em nome de sua organização.
  • O grupo de dispositivos deve ter a política de atualização UpdateAll. Você pode desabilitar as atualizações do aplicativo para um determinado grupo de dispositivos usando o comando azsphere device-group update.

Para todos os dispositivos em um determinado grupo de dispositivos, as implantações direcionadas a esse grupo de dispositivos são consideradas a fonte da verdade para criar imagens desses dispositivos. Todas as imagens no dispositivo que não existirem na implantação serão removidas do dispositivo. A única exceção, a partir do Azure Sphere OS 21.04, é que as imagens de configuração da placa não são removidas, a menos que sejam substituídas por uma nova imagem de configuração da placa.

A verificação de atualização do dispositivo ocorre em três fases correspondentes aos três tipos de atualizações:

  • Na primeira fase, o Azure Sphere obtém um manifesto listando as versões atuais do TKS e do repositório de certificados. Se o TKS e o repositório de certificados no dispositivo estiverem atualizados, a atualização continuará com a segunda fase. Caso contrário, as imagens atuais serão baixadas e instaladas.
  • Na segunda fase, o Azure Sphere obtém um manifesto listando as versões atuais das várias imagens de componentes do sistema operacional. Se alguma imagem no dispositivo estiver desatualizada, as imagens atuais serão baixadas junto com as imagens de reversão que podem ser usadas para reverter o dispositivo para um bom estado conhecido se o processo de atualização falhar. As imagens do sistema operacional e de reversão são baixadas e armazenadas em uma área de teste no dispositivo, as imagens do sistema operacional são instaladas e o dispositivo é reinicializado.
  • Na terceira fase, o Azure Sphere verifica se há atualizações de implantação se o grupo de dispositivos as estiver aceitando. Assim como na atualização do sistema operacional, as imagens de reversão para os aplicativos também são preparadas conforme necessário. As imagens de aplicativo e reversão são baixadas e armazenadas na área de preparo e, em seguida, as imagens do aplicativo são instaladas.

Reversão de atualização

Cada parte do processo de atualização inclui uma opção de reversão. Na atualização de pré-requisito, a imagem de reversão é simplesmente um backup do estado de pré-atualização. Se a atualização falhar, o estado de pré-atualização será restaurado.

A reversão em qualquer nível força a reversão em todos os níveis mais altos: se qualquer imagem de firmware falhar ao inicializar, as partições do firmware e do aplicativo serão revertidas.

Para a atualização do sistema operacional, uma falha de verificação de assinatura ou dificuldades de tempo de execução podem disparar uma reversão. Em caso de falha na verificação da assinatura, é feita uma tentativa de corrigir a imagem; Se isso falhar, uma reversão completa será acionada. Em uma reversão completa, as imagens de reversão preparadas são instaladas para o sistema operacional e os aplicativos.

As atualizações e implantações do sistema operacional têm ciclos de lançamento independentes, portanto, é possível que várias implantações ocorram entre as atualizações do sistema operacional. Se isso acontecer, é importante observar que os destinos de reversão para a implantação não são a implantação mais recente, mas sim a implantação no momento da última atualização do sistema operacional. Isso garante que o sistema operacional e o aplicativo funcionem juntos no estado revertido.

Atualizações interrompidas

Se uma atualização for interrompida, por exemplo, por uma queda de energia ou perda de conectividade, há quatro cenários possíveis para cada tipo de atualização:

  • Se um conjunto completo de imagens tiver sido baixado e preparado com êxito, mas ainda não instalado, a instalação será concluída quando a energia for restaurada.
  • Se algumas, mas não todas, as imagens foram baixadas e preparadas, a atualização continuará baixando as imagens ausentes e, em seguida, prosseguirá para a instalação.
  • Se uma atualização for interrompida durante a instalação após a conclusão do download, a instalação será reiniciada na inicialização.
  • Se nenhuma imagem tiver sido completamente baixada, o processo de atualização começará do zero quando a energia for restaurada, pois não haverá nada pronto para instalar.

Atualizações em cenários de desligamento

O Azure Sphere dá suporte a cenários de baixo consumo de energia que permitem que os dispositivos sejam desligados por longos períodos para conservar a vida útil da bateria. Nesses cenários, é importante que o dispositivo tenha permissão para verificar se há atualizações periodicamente. O aplicativo de exemplo Power Down demonstra como reduzir corretamente o consumo de energia e, ao mesmo tempo, garantir que o dispositivo permaneça periodicamente ativo para verificar se há atualizações do sistema operacional e do aplicativo.

Atualizações adiadas

Para evitar que tarefas críticas sejam interrompidas por atualizações, os aplicativos de alto nível podem incorporar a atualização adiada. Esse recurso permite que o aplicativo conclua suas tarefas críticas e, em seguida, prepare-se para o desligamento para permitir que a atualização continue. O exemplo DeferredUpdate demonstra como implementar essa atualização adiada.