Sobre atualizações over-the-air

Importante

Esta é a documentação do Azure Sphere (Legado). O Azure Sphere (Legado) 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 seus dispositivos compatíveis com 7 propriedades . 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. A partir daí, os controlos são efetuados a 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é-requisitos são usadas para garantir que os componentes nos quais o próprio processo de atualização se baseia — atualmente o Trusted Key Store (TKS) e o armazenamento de certificados — estejam atualizados. O TKS é usado para autenticar as imagens a serem baixadas e instaladas, enquanto o armazenamento de certificados valida conexões com a Internet. Uma atualização do SO destina-se ao software fornecido pela Microsoft no dispositivo, incluindo o sistema operativo do mundo normal em que as suas aplicações são executadas, mas também firmware de nível inferior, como o subsistema Pluton e o Monitor de Segurança. As atualizações de implantação visam seu próprio software — seus aplicativos de alto nível e capacidade em tempo real e imagens de configuração da placa (se houver). Os pré-requisitos e as atualizações do SO são geridos pelo Azure Sphere; as atualizações de aplicativos são coordenadas pelo Azure Sphere com base em implantações criadas pela sua organização.

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

• 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 aplicativos (e, opcionalmente, uma imagem de configuração de quadro) criadas por ou em nome da sua organização.
• O grupo de dispositivos deve ter a política de atualização UpdateAll. Você pode desabilitar as atualizações de aplicativos 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 a criação de 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 armazenamento de certificados. Se o TKS e o armazenamento de certificados no dispositivo estiverem atualizados, a atualização continuará com a segunda fase. Caso contrário, as imagens atuais sã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 juntamente com 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 da reversão são baixadas e armazenadas em uma área de preparo no dispositivo, em seguida, 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 estiver aceitando-as. Assim como acontece com a 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 superiores: se alguma imagem de firmware falhar na inicialização, tanto o firmware quanto as partições do aplicativo serão revertidas.

Para a atualização do sistema operacional, uma falha na verificação de assinatura ou dificuldades de tempo de execução podem desencadear uma reversão. Em caso de falha na verificação da assinatura, tenta-se corrigir a imagem; Se isso falhar, uma reversão completa será acionada. Em uma reversão completa, as imagens de reversão em estágios 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 trabalhem 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 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 foi completamente baixada, o processo de atualização começará de novo quando a energia for restaurada, pois não haverá nada pronto para instalar.

Atualizações em cenários de desativação

O Azure Sphere suporta 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 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 acordado 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 atualizações adiadas. 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 prossiga. O exemplo DeferredUpdate demonstra como implementar essa atualização adiada.