Do you think IIT Guwahati certified course can help you in your career?
Introduction
Azure Sphere is a set of Microsoft services and products that enables manufacturers of Internet of things devices to improve security by combining a particular system on a chip, Azure Sphere OS, with a cloud environment built on the Azure platform for ongoing monitoring. For more information about Azure sphere applications, let's dive into the article.
Overview of Azure Sphere application
Two types of programs can be run on Azure Sphere devices:
On the Azure Sphere OS, high-level programs are executed in containers.
Real-time capable (RTApps) applications can run on bare metal or real-time cores using an RTOS.
Every Azure Sphere device needs a high-level application; RTApps are optional.
High-level applications
Every Azure Sphere device has a high-level application that uses the application libraries and operates on the Azure Sphere OS. A sophisticated application may:
Configure and communicate with peripherals of the Azure Sphere, including the general-purpose input/output (GPIO) pins, universal asynchronous receiver/transmitters (UARTs), and other interfaces.
Interact with RTApps
Communicate with cloud-based services and the internet
Establish trust connections with other hardware and software through certificate-based authentication.
According to What is Azure Sphere?, a high-level application operates in a container in Normal World user mode. A subset of the POSIX environment and a collection of application libraries (Applibs) exclusive to the Azure Sphere OS are supported by the application container. Only specific libraries and functions are accessible to high-level applications to keep the platform safe and straightforward to update.
Among other restrictions, direct file I/O or shell access is unavailable; applications can only use the libraries and run-time services that Microsoft offers. The development environment provides the Azure Sphere application libraries that support device-specific functionalities and describes the underlying API set. High-level programs are designed to operate continuously; if they stop or fail, they are automatically restarted.
Real-time capable applications
In addition to its high-level application, an Azure Sphere device may include one or more real-time capable applications. RTApps can:
Configurable peripherals built into the Azure Sphere MCU, like the GPIO pins and UARTs, can be used.
Connect with advanced apps
RTApps can function either with a real-time operating system or on bare metal (RTOS). A bare-metal HelloWorld sample and a sample exhibiting inter-core communication between high-level and RTApps are included in the Azure Sphere samples repository on GitHub. An example demonstrating how to use Azure Sphere with Azure RTOS is available in the Azure Samples repository on GitHub.
MediaTek and Codethink, two Azure Sphere partners, have added drivers and examples for RTApps that target the M4 real-time cores on the MT3620 hardware. Each RTApp operates independently on a specific I/O core and can only interact with another high-level program; it is not permitted to use the Azure Sphere applibs, the internet, or any other Azure Sphere OS capabilities. More details on the functions and creation process for RTApps are available in Create a Real-Time Capable Application.
Features common to all applications
Although high-level apps and RTApps differ significantly, all Azure Sphere applications have some characteristics. Both sorts of applications can be created, assembled, and debugged using Visual Studio or Visual Studio Code, as well as by using the CLI to launch CMake and Ninja.
Additionally, both high-level and RTApps have the following security features:
Application capabilities
Device capabilities
Deployment and signing requirements
Application capabilities
Every Azure Sphere application, regardless of where it runs, must describe the external services and interfaces it needs, such as its network and I/O requirements, to prevent any illegal or unexpected use.
The resources needed by an application are called application capabilities. Among other things, an application's capabilities include the peripherals it utilizes, the internet hosts it connects to, and the ability to modify the network setup. An application manifest for each application must list these resources.
Device capabilities
A device-specific activity is made possible by a device's capability. The Azure Sphere Security Service grants permissions to devices. Azure Sphere chips lack any device features by default. The device capabilities for app development and field servicing are the two main categories of capabilities.
The device's app development capability for appDevelopment modifies the kind of signature the machine accepts. Azure Sphere devices, by default, only accept production-signed image packages and reject SDK-signed image packages. Therefore, if an Azure Sphere device lacks this feature, you cannot sideload an SDK-signed image package to it. However, the device only accepts SDK-signed image packages when the appDevelopment capability is enabled. The ability to launch, stop, debug, or delete a program from the device is also provided. In conclusion, the device must have the ability to support application development before you can:
Using the azsphere image-package command or Visual Studio, sideload an image package.
Regardless of the signed image package, you can start, stop, debug, or remove it from the Azure Sphere device.
The appDevelopment capability is created and enabled by the azsphere device enable-development command, which also stops the device from receiving updates to cloud applications.
Devices in the DeviceComplete manufacturing state can communicate with computers thanks to the fieldServicing functionality. Production-signed images can be sideloaded using this capability, but they cannot be deleted. Applications can be started and stopped but not debugged. You can also carry out routine maintenance procedures like Wi-Fi configuration. It is only meant to be used for a brief time during a servicing session, during which access to the device is permitted on an as-needed basis.
Signing and deployment requirements
All image packages must be signed to be used on an Azure Sphere device. The azsphere image-package command and the Azure Sphere SDK sign image packages for testing use an SDK signing key. Only in the presence of the appDevelopment device capability can Azure Sphere devices trust this key. When you upload image packages to the cloud, the Azure Sphere Security Service stamps them for production use. Packages of production-signed picture data can be sideloaded or cloud-loaded.
Applications can only be loaded on an Azure Sphere device in one of two methods to prevent the installation of malicious software:
Sideloading is a technique that can be utilized for device field repair, software development, and testing. The appDevelopment device feature is necessary for sideloading during program development and testing. The field Servicing device capabilities and production-signed image packages are required for sideloading for field servicing. During development and debugging, Visual Studio and Visual Studio Code both sideload programs;
Cloud update, which only the Azure Sphere Security Service can perform. Cloud deployments can be created and managed using the Azure Sphere CLI.
Partner applications
Partner applications are those that function jointly and can be sideloaded independently. If the partner application has already been installed on the Azure Sphere device and you sideload it, it stays there. In its project configuration, each application declares a list of its partners.
In the partnerComponents field of the configurations section of the launch.vs.json or.vscode/launch.json file, provide the component ID of the partner app to add them to the CMake project configuration:
Applications that work together can be considered partner applications and be sideloaded separately. When you sideload an application that has a partner, the partner application remains on the Azure Sphere device if it has already been deployed. Each application declares a list of its partners in its project configuration.
To add partners to the CMake project configuration, specify the component ID of the partner app in the partnerComponents field of the configurations section of the launch.vs.json or the .vscode/launch.json file:
Partners who interact with one another through high-level applications and RTApps must be designated. Azure Sphere does not support communication between two high-level apps or two RTApps.
Development environment
On a computer running Ubuntu 20.04 LTS or 18.04 LTS, Windows 11, Windows 10 Anniversary Update (or later), or Linux are all supported platforms for developing applications for Azure Sphere. Use the Azure Sphere SDK version 22.02 or later if you use Windows 11.
Install the Windows SDK on Windows. Applications for Windows can be created, deployed, and debugged using Visual Studio, Visual Studio Code, or the command line.
Install the Linux SDK on Linux. Applications can be developed, deployed, and debugged on Linux using Visual Studio Code or the command line.
The following are the principal elements of the Azure Sphere SDK:
Sysroots include the libraries, header files, and tools required to link and assemble a program designed to work with a specific API set.
The hardware capabilities available on different hardware devices are described in hardware definitions, which can be used to indicate in-app-manifest.json files.
CMakeFiles, which outlines the CMake extensions for Azure Sphere.
The Command-Line Interface for Azure Sphere (CLI).
Azure Sphere Application Runtime
The base APIs and the applibs APIs are two sets of libraries offered by the Azure Sphere Application Runtime for building high-level applications. The applibs APIs primarily target Azure Sphere devices, whereas the base APIs are based on libraries that don't only target Azure Sphere devices. The Azure Sphere SDK allows developers to create high-level programs that compile and link against these interfaces. Applications with real-time capabilities cannot use these APIs.
The SysrootsAPI setusrinclude folders in the Azure Sphere SDK installation directory containing the header files for the base APIs. The Sysroots\API set\usr\include\applibs folder in the Azure Sphere SDK installation directory contains the header files for the applibs APIs.
Tools
The Azure Sphere CLI is a tool for managing devices, creating and deploying apps, and interacting with cloud services that are part of the Azure Sphere SDK.
CMake and the compact Ninja build tool enable build coordination for Azure Sphere applications. CMake and Ninja are installed for you automatically if you use Visual Studio. You must set up Visual Studio Code and Azure Sphere CLI manually on Windows or Linux if you utilize them.
Azure Sphere plugins for Visual Studio and Visual Studio Code simplify developing Azure Sphere applications. You can simply create, debug, test, and deploy your Azure Sphere applications from the IDE with the help of these extensions. Both extensions fully support the CMake toolset for Azure Sphere.
Containers
A container that bundles the SDK in a standalone Linux environment is made available via Azure Sphere. You can bypass the procedures of installing (or uninstalling and then reinstalling) the appropriate SDK build environment by using a container with a pre-defined build environment. You may adapt the built environment to your specific requirements and simultaneously duplicate that environment to all of your host machines with consistent outcomes. In a continuous integration scenario, a build pipeline like GitHub Actions or Azure Pipelines can be used to employ a container to automatically rebuild your application anytime changes are made to the underlying code.
What is a container?
Containers are lightweight, portable packages that run on the host machine's kernel. Containers use shared layers, which makes them lightweight. These layers may consist of shared operating system components or applications. The overhead of a virtual machine, which includes a whole operating system and all related programs, is avoided by layers. Containers can be small and startup quickly, thanks to sharing. Containers can be downloaded through registries, such as the Microsoft Artifact Registry (MAR).
What containers bring to Azure Sphere
You get a ready-made development environment from the container for the Microsoft Azure Sphere SDK build environment. The container offers these things:
The Ubuntu Linux version used in the most recent release of Azure Sphere
The most recent iteration of the Linux Azure Sphere SDK
The SDK requires other tools like CMake and Ninja
The Docker containers used by Azure Sphere are set up using text files called Dockerfiles. To construct a unique container for developing Azure Sphere apps, you can write Dockerfiles that use a basic container image. Running the customized container generates the new customized container if necessary, downloads the most recent base image if it is not already on your host machine, develops the given application, and then terminates. The application can then be sideloaded onto a device by copying the build's output to a host computer with the Azure Sphere SDK already installed. Although interactive use of the custom build container is uncommon, it is possible, for instance, to troubleshoot build issues.
Application templates
The following templates are available in the Visual Studio and Visual Studio Code extensions for Azure Sphere to help you create your apps:
An LED blinks in the example program Blink. Similar functionality to the HelloWorld_HighLevelApp found in the Azure Sphere samples repository on GitHub.
The basic build and configuration files needed to create a high-level app are included in the HLCore Blank template, along with a main.c file that only shows a message in the debug console before exiting. Build high-level apps using this template as a foundation.
RTCore Blank is a template that contains the basic configuration and builds files needed to create a real-time capable program (RTApp). It's main.c file quits after setting up the real-time core's exception vector database. Additionally, it contains linker.ld, which configures the necessary linker data. Build RTApps using this template as a foundation.
Use a template in Visual Studio.
To utilize one of Visual Studio's templates:
Select Create a new project in Visual Studio after opening it.
To view a list of Azure Sphere templates, type "azure sphere" into the Search box.
Pick a template from the provided list.
Select Create after giving the project a name and location. Note A single CMakeLists.txt file is created in the project directory by the template if the checkbox Place solution and project in the same directory is checked. The template creates two CMakeLists.txt files, one in the project directory and one in the top-level solution directory if the checkbox is not selected.
The project is created and opened by Visual Studio in the designated location.
Use a template in Visual Studio Code
To utilize one of Visual Studio Code's templates:
Get Visual Studio Code going. The Command palette option is under View.
Enter "Azure Sphere: Generate New Project" in the text box.
From the Templates menu, pick a template.
Visual Studio Code displays File Explorer. Go to the folder where your program will be stored by navigating there.
At the prompt, type a name for your project.
The location you chose in the previous step is where Visual Studio Code builds the application project folder with that name. The files from the template are added to the folder.
Device capabilities and communication
The device's capabilities determine device-specific OS regulations for service-UART communication. The service UART is used for all communication between the host computer and any associated devices. To perform operations on an attached device, the host computer communicates with it. Capabilities are used by manufacturers, programmers, and field service technicians to open service-UART communication for the tasks they need while assuring the device is secure from malicious users.
Device manufacturers and OEMs can restrict service-UART communication to stop unauthorized use by anybody with physical access to the device. Device finalization includes locking down such communication. All other operations require a device capability; once finalization is complete, a user can only obtain a device's ID. Before the manufacturer sends the gadget to a customer site, finalization is usually done on the factory floor.
A device capability file for a single device only contains zero or more capabilities. If the capability file is used on a device other than the one for which it was designed, it will not function. The following features, which are separately explained later in this article, are possible for a device to have:
enableRfTestMode capability
appDevelopment capability
fieldServicing capability
How to determine device capabilities or manufacturing state
Use the azsphere device capability show-connected command to determine what capability configuration is kept on the attached device. The command lists some, but not all, of the capabilities pre-installed on boards and the capabilities that have been set using a capability file.
The device's manufacturing status may have an impact on its capabilities. Use the azsphere device manufacturing-state show command to find out the device's manufacturing state. The service-UART connection is locked, and you require a device capability to communicate with the device from your computer; if the command indicates that the device is in the DeviceComplete manufacturing state or returns, Device access is forbidden. Manufacturing operations are only allowed when a device is unlocked using a capability file in the DeviceComplete manufacturing stage.
Note
When installing a device at a client's location, make sure the device has reached the DeviceComplete manufacturing stage. For a development kit, the DeviceComplete manufacturing state is typically inappropriate. A dev kit should be in either the Module1Complete manufacturing state or the Blank manufacturing state to allow testing of the manufacturing operations being created by manufacturing engineers.
How devices acquire capabilities
One of three ways exists for devices to gain capabilities:
It is opened by default. Some capabilities are automatically open on a device when it is either in the Module1Complete manufacturing state or the Blank manufacturing state. This is done so that user device capability files to unlock capabilities do not need connecting devices still in the production stage to the cloud or claiming them as tenants. As production moves forward, manufacturers can alter the device's manufacturing state to lock down features that are no longer necessary, as explained in Factory-floor tasks.
Onto the gadget via side loading. A capability file from the host computer may be sideloaded onto a device. Until a new capability file—which could be a blank file with no capabilities—is sideloaded, this set of sideloaded capabilities remains in effect. This is frequently the case while developing applications, such as when the azsphere device enable-development command is used. The ability to do activities like debugging and quickly delete and distribute sideloaded versions of the application is made possible by having the device unlocked, which facilitates application development.
With each operation being passed to the apparatus. On an operation-by-operation basis, a device may have locally selected capabilities implemented. The capability file chosen by the azsphere device select command is kept locally on the host computer. Once this command has been executed, each subsequent command passes the desired capability from the computer to the device. Because the capabilities are saved on the computer rather than the device, this is the suggested method of employing capabilities for devices in the field. By remembering to disable the capability, the chance of a field engineer unintentionally leaving the equipment vulnerable is reduced.
They make changes to a device after the manufacturer explains how to download capability files from the Azure Sphere Security Service (AS3) before they can be sideloaded onto a device or passed to a device with an operation. Capability files downloaded are device-specific and can be utilized repeatedly on the connected device after they have been done.
The enableRfTestMode capability
When the device's manufacturing state is Blank, the enableRfTestMode feature is enabled by default. This functionality makes it possible to configure and test RF operations and program e-fuses. Tenant owners are unable to download this functionality to a host computer. Please get in touch with your Microsoft agent if you require this feature. The enableRfTestMode capability is shown by the azsphere device capability show-attached command while the device's manufacturing state is Blank.
The appDevelopment capability
The service-UART communication is enabled, and the appDevelopment device capability modifies the device's trusted signature. It is designed to be used for developing applications.
By default, Azure Sphere devices do not trust SDK-signed image packages, but they trust production-signed image packages obtained by the Azure Sphere Security Service. Therefore, unless your Azure Sphere device has the appDevelopment capability, you cannot sideload an image package you created with the SDK onto it for debugging. With the app development feature, you can start, stop, debug, or delete an application from the device and make the device trust the image package.
In conclusion, the appDevelopment capability permits the following operations by unlocking service-UART communication:
They are utilizing the CLI, azsphere image package, visual studio, visual studio code, or sideloading an image package.
No matter how signed the image package is, you can start, stop, debug, or remove it from the Azure Sphere device.
Take advantage of the azsphere device enable-development command to add the appDevelopment capability. This command sideloads the appDevelopment capability onto the associated device, downloads it to it, and adds it to the Development device group by default. An alternative device group can be specified by including the --device-group parameter.
The device stays unlocked after using azsphere device enable-development until you specifically lock it. Use the azsphere device enable-cloud-test command to unlock the device once more. Following the specified command-line options, this command either eliminates the capability or modifies the device group.
The commands azsphere device enable-development and azsphere device enable-cloud-test execute a series of operations that get a device ready for testing and development or cloud deployments, respectively. The azsphere device capability command can be used to download or update a device capability and to learn what capabilities a device presently has in place of using these commands.
The fieldServicing capability
When a device's manufacturing state is Blank or Module1Complete, the fieldServicing feature is automatically present on the device. The fieldServicing capability can be sideloaded when a device is in the DeviceComplete manufacturing state. However, it is usually passed to the device with each operation during a service session.
The fieldServicing capability, independent of the device's manufacturing condition, enables service-UART communication to permit the following operations:
sideloading a signed image package from production.
A production-signed image package that has been designated as temporary can be started, stopped, and deleted.
They are carrying out regular maintenance, such as setting up Wi-Fi.
The azsphere device capability show-attached command does not show the fieldServicing capability, even though it is available by default on the device when the manufacturing state is Blank or Module1Complete.
Lifecycle of an application
All Azure Sphere programs should be developed to run constantly for high-level or real-time capable cores. When an unexpected application exits, the operating system resumes it.
Peripherals are not reset upon startup by the Azure Sphere OS. Your real-time, high-level applications should make sure that peripherals are in a known-good state when they first power on. High-level programs should only terminate when the Azure Sphere OS sends a SIGTERM signal. The Azure Sphere OS terminates using the SIGKILL signal if an application doesn't shut down after receiving the SIGTERM signal. Applications must make sure SIGKILL is never necessary.
Memory available on Azure Sphere
The RAM accessible to Azure Sphere programs operating on an MT3620 chip is listed in the following table.
One MiB of flash memory is provided by Azure Sphere, which is shared by high-level and real-time applications (RTApps). The Azure Sphere OS utilizes this area to store application image packages and map RTApps for execute-in-place (XIP) or loading into TCM.
In addition, the high-level core has access to 256 KiB of RAM. Each shared buffer channel used by high-level apps and RTApps to communicate may receive up to 1 KiB of this space.
Additionally, each real-time core contains 192 KB of TCM and 64 KB of SYSRAM. Typically, data is stored in the SYSRAM, and quick code execution is performed in the TCM.
What is a Component ID?
Every Azure Sphere application needs a distinct component ID to make it easy to recognize. The component ID is a globally unique identifier (GUID), usually called a UUID, a string made up of a series of hexadecimal numbers. Like 02ce3860-3126-42af-8ac7-c2a661134129, as an illustration. To prevent potential conflicts, each application has a unique component ID.
Generate a component ID
The component ID for the application is automatically set in the app manifest.json file when you launch a CMake project for the first time in Visual Studio or Visual Studio Code. The build fails if the application is launched without a component ID. You can manually create a GUID or UUID and change the manifest application option if necessary.
Visual Studio
Select Create GUID from the Tools menu.
Select the Registry Format choice button, then select the Copy button before selecting the Exit button in the GUID generator program.
Put the generated GUID or UUID in the ComponentId column of the app manifest.json file for the application. As an illustration, "ComponentId" would be "a5e23798-9bef-4bb0-9ae9-45643e788cb7."
Find the component ID.
An application must have a component ID to be recognized. Any of the following methods will help you locate the component ID for an application:
Verify the component ID in the app manifest.json file's ComponentId field.
To list the state and component ID of the application on the attached device, issue the command azsphere device app show-status.
To view a list of the images currently installed on the associated device, use the command azsphere device image list-installed. Take note of the required application's component ID.
Terminal emulators in Azure Sphere development
A wide range of software programs are known as "terminal emulators" enable users to send instructions to a local host or remote device and then view the results on a local screen or window using a graphical user interface. Terminal emulation is used when creating applications for Azure Sphere: first, to receive output from a high-level application via a Telnet or raw TCP connection, and second, to receive output from a real-time application over a serial connection. The information to create the connection can be used to identify the connection type. You want a Telnet or TCP connection if a hostname or IP address is provided, along with a port number. If you are pointed to a serial port and provided a baud rate, you want a serial connection. Any terminal emulator can establish the necessary connections, but some do so more quickly than others.
Terminal emulators for Windows that let you define connection parameters using dialogue boxes are practical. The following are two free and open-source programs that offer this functionality:
Tera Term
PuTTY
Many packages are comparable. Linux users frequently have access to Telnet as part of the default installation; adding a straightforward serial connection tool like minicom or picocom should complete the toolset.
Frequently Asked Questions
What does the azure sphere serve?
Over secure cloud-to-device and device-to-cloud channels, the Azure Sphere Security Service offers authentication, software updates, and error reporting. As a result, your products will run on the most recent version of the Azure Sphere OS, thanks to a secure communications infrastructure.
When should I use the Azure sphere?
Azure Sphere is a set of Microsoft services and solutions that enables manufacturers of Internet of things (IoT) devices to boost security by combining a particular system on a chip, Azure Sphere OS, with a cloud environment built on the Azure platform for ongoing monitoring.
Is Azure Sphere a PaaS?
Although Azure Sphere integrates with Azure services, it is not a cloud computing solution and is not IaaS, PaaS, or SaaS. Instead, it uses cloud services that may be classified as IaaS, PaaS, or SaaS.
Conclusion
In this article, we have extensively discussed the Azure Sphere applications. We have also discussed the development environment, application templates, lifecycle of an application, and component id in detail.
250+ registered 
