Visão geral dos aplicativos do Azure Sphere

Os dispositivos do Azure Sphere podem executar dois tipos de aplicativos:

  • Aplicativos de alto nível são executados em contêineres no sistema operacional do Azure Sphere
  • Os aplicativos com capacidade para tempo real (RTApps) são executados em bare-metal ou com um RTOS (sistema operacional em tempo real) nos núcleos em tempo real

Um aplicativo de alto nível é necessário para cada dispositivo do Azure Sphere; RTApps são opcionais.

Aplicativos de alto nível

Cada dispositivo do Azure Sphere tem um aplicativo de alto nível, que é executado no sistema operacional do Azure Sphere e pode usar as bibliotecas de aplicativos. Um aplicativo de alto nível pode:

  • Configure e interaja com periféricos do Azure Sphere, como os pinos GPIO (entrada/saída de uso geral), UARTs (receptores/transmissores assíncronos universais) e outras interfaces

  • Comunicar-se com RTApps

  • Comunicar-se com os serviços baseados na Internet e na nuvem

  • Relações de confiança do agente com outros dispositivos e serviços por meio da autenticação baseada em certificado

Um aplicativo de alto nível é executado em um contêiner no modo de usuário Normal World, conforme descrito em O que é o Azure Sphere?. O contêiner de aplicativos dá suporte a um subconjunto do ambiente POSIX e a um conjunto de bibliotecas de aplicativos (Applibs) que são específicas para o sistema operacional do Azure Sphere. As bibliotecas e funções que estão disponíveis para aplicativos de alto nível são restritas para garantir que a plataforma permaneça segura e possa ser facilmente atualizada. Os aplicativos podem acessar apenas as bibliotecas e os serviços em tempo de execução que a Microsoft fornece; nem a E/S direta de arquivo nem o acesso ao shell estão disponíveis, entre outras restrições. O ambiente de desenvolvimento descreve o conjunto de APIs base e apresenta as bibliotecas de aplicativos do Azure Sphere que dão suporte a recursos específicos do dispositivo.

Os aplicativos de alto nível devem ser executados continuamente e são reiniciados automaticamente se eles param ou falham.

Criar um aplicativo de alto nível fornece mais informações sobre recursos.

Aplicativos com capacidade para tempo real

Um dispositivo do Azure Sphere também pode ter um ou mais aplicativos com capacidade para tempo real, além de seu aplicativo de alto nível. Um RTApp pode:

  • Configurar e interagir com periféricos integrados à MCU do Azure Sphere, como os pinos GPIO e UARTs
  • Comunicar-se com aplicativos de alto nível

O RTApps pode ser executado em bare-metal ou com um RTOS (sistema operacional em tempo real). O repositório de exemplos do Azure Sphere no GitHub inclui uma amostra HelloWorld bare-metal, bem como um exemplo que demonstra a comunicação entre núcleos entre RTApps e alto nível. O repositório de Exemplos do Azure no GitHub contém um exemplo que mostra como usar o Azure Sphere com o Azure RTOS.

Drivers e exemplos adicionais para RTApps direcionados aos núcleos em tempo real M4 no chip MT3620 estão disponíveis no GitHub de parceiros do Azure Sphere MediaTek e Codethink.

Cada RTApp é executado isolado em um núcleo de E/S específico e pode se comunicar somente com um aplicativo de alto nível; ele não pode usar a Internet, o applibs do Azure Sphere ou outros recursos do sistema operacional do Azure Sphere.

Criar um aplicativo com capacidade para tempo real fornece mais informações sobre os recursos e o processo de desenvolvimento para RTApps.

Recursos comuns a todos os aplicativos

Apesar das diferenças significativas entre aplicativos de alto nível e RTApps, todos os aplicativos do Azure Sphere têm algumas coisas em comum. Você pode desenvolver, compilar e depurar os dois tipos de aplicativos usando o Visual Studio ou o Visual Studio Code ou invocando o CMake e o Ninja usando a CLI.

Além disso, os seguintes recursos de segurança se aplicam a RTApps e de alto nível:

Funcionalidades do aplicativo

Independentemente de onde ele é executado, cada aplicativo do Azure Sphere deve especificar os serviços e interfaces externos que ele requer , por exemplo, seus requisitos de rede e E/S, para evitar qualquer uso não autorizado ou inesperado.

As funcionalidades do aplicativo são os recursos que um aplicativo requer. As funcionalidades do aplicativo incluem os periféricos que o aplicativo usa, os hosts da Internet aos quais um aplicativo de alto nível se conecta e a permissão para alterar a configuração de rede, entre outros. Cada aplicativo deve ter um manifesto do aplicativo que identifique esses recursos.

Funcionalidades do dispositivo

Uma funcionalidade de dispositivo habilita uma atividade específica do dispositivo. As funcionalidades do dispositivo são concedidas pelo Serviço de Segurança do Azure Sphere. Por padrão, os chips do Azure Sphere não têm funcionalidades de dispositivo. Há dois tipos principais de funcionalidades de dispositivo: a funcionalidade do dispositivo appDevelopment e a funcionalidade do dispositivo fieldServicing .

A funcionalidade do dispositivo appDevelopment altera o tipo de assinatura em que o dispositivo confia. Por padrão, os dispositivos do Azure Sphere confiam em pacotes de imagem assinados por produção, mas não confiam em pacotes de imagem assinados pelo SDK. Como resultado, você não pode fazer sideload de um pacote de imagem assinado pelo SDK para um dispositivo do Azure Sphere que não tenha essa funcionalidade. Quando a funcionalidade appDevelopment está presente, no entanto, o dispositivo confia em pacotes de imagem assinados pelo SDK. Além disso, ele permite iniciar, parar, depurar ou remover um aplicativo do dispositivo. Em resumo, a funcionalidade de desenvolvimento de aplicativos deve estar presente no dispositivo antes que você possa:

  • Fazer sideload de um pacote de imagem criado pelo Visual Studio ou pelo comando azsphere image-package .
  • Iniciar, parar, depurar ou remover um pacote de imagem do dispositivo do Azure Sphere, independentemente de como o pacote de imagem é assinado.

O comando azsphere device enable-development cria e aplica a funcionalidade appDevelopment e impede que o dispositivo receba atualizações de aplicativos na nuvem.

A funcionalidade fieldServicing permite comunicações de dispositivo para computador em dispositivos que estão no estado de fabricação DeviceComplete. Com essa funcionalidade, você pode realizar sideload de imagens assinadas em produção, mas não excluí-las. Você pode iniciar e parar aplicativos, mas não depurá-los. Você também pode executar tarefas de manutenção rotineiras, como configurar o Wi-Fi. Ele destina-se ao uso de curto prazo durante uma sessão de manutenção , um período limitado durante o qual o acesso ao dispositivo é concedido por operação.

Requisitos de assinatura e implantação

Todos os pacotes de imagem implantados em um dispositivo do Azure Sphere devem ser assinados. O SDK do Azure Sphere e os pacotes de imagem de sinal do comando azsphere image-package para teste usando uma chave de assinatura do SDK. Os dispositivos do Azure Sphere confiarão nessa chave somente se a funcionalidade do dispositivo appDevelopment também estiver presente.

O Serviço de Segurança do Azure Sphere assina pacotes de imagem quando você os carrega na nuvem. Os pacotes de imagem assinados por produção podem ser carregados ou carregados na nuvem.

Para impedir a instalação de software não autorizado, os aplicativos podem ser carregados em um dispositivo do Azure Sphere de apenas duas maneiras:

  • Sideload, que pode ser usado para desenvolvimento e teste de software e para manutenção de campo de dispositivos. O sideload para desenvolvimento e teste de software requer a funcionalidade do dispositivo appDevelopment. O sideload para manutenção de campo requer a funcionalidade do dispositivo fieldServicing e os pacotes de imagem assinados por produção. Os aplicativos de sideload do Visual Studio e do Visual Studio Code durante o desenvolvimento e a depuração; você também pode fazer sideload manualmente usando a CLI do Azure Sphere.

  • Atualização de nuvem, que pode ser executada somente pelo Serviço de Segurança do Azure Sphere. Use a CLI do Azure Sphere para criar e gerenciar implantações de nuvem.

Aplicativos de parceiros

Os aplicativos que trabalham juntos podem ser considerados aplicativos parceiros e, em seguida, podem ser carregados separadamente. Quando você faz sideload de um aplicativo que tem um parceiro, o aplicativo parceiro permanece no dispositivo do Azure Sphere se ele já tiver sido implantado. Cada aplicativo declara uma lista de seus parceiros em sua configuração de projeto.

Para adicionar parceiros à configuração do projeto do CMake, especifique a ID do componente do aplicativo parceiro no campo partnerComponents da seção de configurações do arquivo launch.vs.json ou .vscode/launch.json:

"partnerComponents": [ "25025d2c-66da-4448-bae1-ac26fcdd3627" ]

Aplicativos de alto nível e RTApps que se comunicam entre si devem ser identificados como parceiros. O Azure Sphere não dá suporte à comunicação entre pares de aplicativos de alto nível ou pares de RTApps.