Introducción a las aplicaciones de Azure Sphere

Importante

Esta es la documentación de Azure Sphere (heredado). Azure Sphere (heredado) se retira el 27 de septiembre de 2027 y los usuarios deben migrar a Azure Sphere (integrado) en este momento. Use el selector de versiones situado encima de la TOC para ver la documentación de Azure Sphere (integrado).

Los dispositivos de Azure Sphere pueden ejecutar dos tipos de aplicaciones:

• Las aplicaciones de alto nivel se ejecutan en contenedores en el sistema operativo Azure Sphere.
• Las aplicaciones con respuesta en tiempo real (RTApp) se ejecutan en un equipo sin sistema operativo o con un sistema operativo en tiempo real (RTOS) en los núcleos en tiempo real.

Para cada dispositivo Azure Sphere se requiere una aplicación de alto nivel, las RTAapp son opciones.

Aplicaciones de alto nivel

Cada dispositivo de Azure Sphere tiene una aplicación de alto nivel, que se ejecuta en el sistema operativo Azure Sphere y puede usar las bibliotecas de aplicaciones. Una aplicación de alto nivel puede hacer lo siguiente:

• Configurar e interactuar con periféricos de Azure Sphere, como pines de entrada/salida (GPIO) de propósito general, transmisores y receptores asincrónicos universales (UART) y otras interfaces

• Comunicarse con aplicaciones con capacidad en tiempo real

• Comunicarse con Internet y con servicios basados en la nube

• Negociar las relaciones de confianza con otros dispositivos y servicios a través de la autenticación basada en certificados

Una aplicación de alto nivel se ejecuta en un contenedor en modo de usuario de Normal World, como se describe en What is Azure Sphere? (¿Qué es Azure Sphere?). El contenedor de aplicaciones admite un subconjunto del entorno POSIX y un conjunto de bibliotecas de aplicación (Applibs) que son específicos para el sistema operativo de Azure Sphere. Las bibliotecas y funciones disponibles para las aplicaciones de alto nivel están restringidas para garantizar que la plataforma se mantenga segura y se pueda actualizar fácilmente. Las aplicaciones pueden acceder solo a las bibliotecas y servicios en tiempo de ejecución que proporciona Microsoft; no están disponibles la E/S de archivos directas ni el acceso al shell, por nombrar algunas de las limitaciones. El entorno de desarrollo describe el conjunto de API base e introduce las bibliotecas de aplicaciones de Azure Sphere que admiten características específicas del dispositivo.

Se espera que las aplicaciones de alto nivel se ejecuten de manera continua y se reinicien automáticamente si se detienen o tienen un error.

Crear una aplicación de alto nivel proporciona más información sobre las características.

Aplicaciones con respuesta en tiempo real (RTApp)

Un dispositivo de Azure Sphere también puede tener una o varias aplicaciones con respuesta en tiempo real además de su aplicación de alto nivel. Una RTApp puede hacer lo siguiente:

• Configurar periféricos integrados e interactuar con ellos en el MCU de Azure Sphere, como los pines de GPIO y UART
• Comunicarse con aplicaciones de alto nivel

Las RTApp pueden ejecutarse en equipos sin sistema operativo o con un sistema operativo en tiempo real (RTOS). En el repositorio de ejemplos de Azure Sphere en GitHub se incluye un ejemplo Hola mundo completo, así como un ejemplo que muestra la comunicación entre núcleos entre las aplicaciones generales y las RTApps. El repositorio Azure Samples de GitHub contiene un ejemplo que muestra cómo usar Azure Sphere con Azure RTOS.

En GitHub hay disponibles controladores y ejemplos adicionales de RTApps para los núcleos de tiempo real M4 del chip MT3620, procedentes de los asociados de Azure Sphere MediaTek y Codethink.

Cada RTApp se ejecuta de forma aislada en un núcleo de E/S determinado y solo puede comunicarse con una aplicación de alto nivel; no puede utilizar Internet, bibliotecas de aplicaciones de Azure Sphere u otras características del SO de Azure Sphere.

Crear una aplicación con respuesta en tiempo real proporciona más información sobre las características y el proceso de desarrollo de RTApps.

Características comunes a todas las aplicaciones

A pesar de las importantes diferencias entre las aplicaciones con respuesta en tiempo real y las de alto nivel, todas las aplicaciones de Azure Sphere tienen algunos aspectos en común. Puede desarrollar, compilar y depurar ambos tipos de aplicaciones con Visual Studio o Visual Studio Code, o mediante la invocación de CMake y Ninja con la CLI.

Además, las siguientes características de seguridad se aplican tanto a las aplicaciones de alto nivel como a las RTApp.

• Funcionalidades de la aplicación
• Funcionalidades del dispositivo
• Requisitos de firma e implementación

Funcionalidades de la aplicación

Con independencia de dónde se ejecuten, todas las aplicaciones de Azure Sphere deben especificar los servicios externos y las interfaces que requieren, por ejemplo, sus requisitos de E/S y de red, para evitar cualquier uso no autorizado o inesperado.

Las funcionalidades de la aplicación son los recursos que requiere una aplicación. Las funcionalidades de la aplicación incluyen los periféricos que usa la aplicación, los hosts de Internet a los que se conecta y el permiso para cambiar la configuración de red, entre otros. Cada aplicación debe tener un manifiesto de aplicación que identifique estos recursos.

Funcionalidades del dispositivo

Una funcionalidad del dispositivo hace posible una actividad específica del dispositivo. El servicio de seguridad de Azure Sphere concede funcionalidades de dispositivo. De forma predeterminada, los chips de Azure Sphere no tienen funcionalidades del dispositivo. Hay dos tipos principales de funcionalidades de dispositivo: la funcionalidad del dispositivo appDevelopment y la funcionalidad fieldServicing device.

La funcionalidad del dispositivo appDevelopment cambia el tipo de firma en la que confía el dispositivo. De forma predeterminada, los dispositivos de Azure Sphere confían en paquetes de imágenes con firma de producción, pero no confían en paquetes de imágenes firmados por el SDK. Como consecuencia, no se puede transferir localmente un paquete de imágenes firmado por el SDK a un dispositivo de Azure Sphere que no tiene esta funcionalidad. Sin embargo, cuando la funcionalidad appDevelopment está presente, el dispositivo confía en los paquetes de imágenes firmados por el SDK. Además, le permite iniciar, detener, depurar o quitar una aplicación del dispositivo. En resumen, la funcionalidad de desarrollo de aplicaciones debe estar presente en el dispositivo antes de que pueda:

• Transferir localmente un paquete de imágenes que se creó con Visual Studio o el comando azsphere image-package.
• Iniciar, detener, depurar o quitar un paquete de imágenes del dispositivo de Azure Sphere, independientemente de cómo esté firmado el paquete de imágenes.

El comando azsphere device enable-development crea y aplica la funcionalidad appDevelopment e impide que el dispositivo reciba actualizaciones de aplicaciones en la nube.

La funcionalidad fieldServicing permite las comunicaciones de dispositivo a equipo en dispositivos que están en estado de fabricación DeviceComplete. Con esta funcionalidad, puede transferir localmente imágenes firmadas por producción, pero no eliminarlas. Puede iniciar y detener aplicaciones, pero no depurarlas. También puede realizar tareas de mantenimiento rutinarias, como configurar Wi-Fi. Está pensado para el uso a corto plazo durante una sesión de mantenimiento, un período limitado durante el cual se concede acceso al dispositivo por operación.

Requisitos de firma e implementación

Todos los paquetes de imágenes que se implementan en un dispositivo de Azure Sphere deben estar firmados. El SDK de Azure Sphere y el comando azsphere image-package firman los paquetes de imágenes para las pruebas con una clave de firma de SDK. Los dispositivos de Azure Sphere confían en esta clave solo si la funcionalidad del dispositivo appDevelopment también está presente.

El servicio de seguridad de Azure Sphere firma en producción los paquetes de imágenes al cargarlos en la nube. Los paquetes de imágenes con firma de producción pueden transferirse localmente o cargarse desde la nube.

Para evitar la instalación de software malintencionado, las aplicaciones se pueden cargar en un dispositivo de Azure Sphere solo de dos maneras:

• Instalación de prueba, que se puede usar tanto para el desarrollo de software como para las pruebas y para el mantenimiento de campos de los dispositivos. La instalación de prueba para el desarrollo y las pruebas de software requiere la funcionalidad del dispositivo appDevelopment. La instalación de prueba para el mantenimiento de campos requiere la funcionalidad del dispositivo fieldServicing y los paquetes de imágenes firmadas por producción. Las aplicaciones de instalación local de Visual Studio y Visual Studio Code durante el desarrollo y la depuración; También puede transferir localmente manualmente mediante la CLI de Azure Sphere.

• Actualización en la nube, que solo se puede realizar mediante el servicio de seguridad de Azure Sphere. Use la CLI de Azure Sphere para crear y administrar implementaciones en la nube.

Aplicaciones asociadas

Las aplicaciones que funcionan conjuntamente se pueden considerar aplicaciones asociadas y, por ello, se pueden transferir localmente por separado. Cuando transfiere localmente una aplicación que tiene otra asociada, la aplicación asociada permanece en el dispositivo de Azure Sphere si ya se ha implementado. Cada aplicación declara una lista de sus asociadas en la configuración del proyecto.

Para agregar aplicaciones asociadas a la configuración del proyecto de CMake, especifique el identificador de componente de la aplicación asociada en el campo partnerComponents de la sección configurations del archivo launch.vs.json o .vscode/launch.json:

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

Las aplicaciones de alto nivel y rtApps que se comunican entre sí deben identificarse como asociados. Azure Sphere no admite la comunicación entre pares de aplicaciones o pares de aplicaciones de alto nivel de RTApps.