The following diagram shows a high-level view of the components in a typicaledge-based IoT solution. This article focuses on the devices, assets and connectors shown in the diagram:

Assets typically have built-in firmware that implements standard protocols. For example, a robotic arm might be an OPC UA client and a security video camera might implement ONVIF. Azure IoT Operations includes various connectors that can use these protocols to communicate with assets and translate messages from the assets into MQTT messages. Some assets can receive messages enabling you to perform operations on them such as:

• Pan or tilt a security camera.
• Change the logging level on a robotic arm.
• Initiate a firmware update.

You can create your own, custom connectors to connect to assets that use protocols not natively supported by Azure IoT Operations.

The following diagram shows a high-level view of the components in a typicalcloud-based IoT solution. This article focuses on the devices and gateway shown in the diagram:

In Azure IoT, a device developer writes the code to run on the devices in the solution. This code typically:

• Establishes a secure connection to a cloud endpoint.
• Sends telemetry collected from attached sensors to the cloud.
• Manages device state and synchronizes that state with the cloud.
• Responds to commands sent from the cloud.
• Enables the installation of software updates from the cloud.
• Enables the device to keep functioning while disconnected from the cloud.

Example assets in an edge-based solution include:

• Robotic arms, conveyor belts, and elevators.
• Industrial CNC machines, lathes, saws, and drills.
• Medical diagnostic imaging machines.
• Security video cameras.
• Programmable logic controllers.

These assets typically have built-in firmware that implements standard protocols. For example, a robotic arm might be an OPC UA client and a security video camera might implement the ONVIF protocol. In an edge-based solution, you use specialized connectors to connect to these assets and translate messages from them into a common format.

For assets, there's no direct equivalent to the device developer role. Instead, an operator can configure the connectors to connect to the assets. However, you might need to develop custom connectors to connect to assets that use protocols not natively supported by your edge-based solution.

Example devices in a cloud-based solution include:

• A pressure sensor on a remote oil pump.
• Temperature and humidity sensors in an air-conditioning unit.
• An accelerometer in an elevator.
• Presence sensors in a room.

These devices are typically built using microcontrollers (MCUs) or microprocessors (MPUs):

• MCUs are less expensive and simpler to operate than MPUs.
• An MCU contains many of the functions, such as memory, interfaces, and I/O on the chip itself. An MPU accesses this functionality from components in supporting chips.
• An MCU often uses a real-time OS (RTOS) or runs bare-metal (no OS) and provides real-time responses and highly deterministic reactions to external events. MPUs generally run a general purpose OS, such as Windows, Linux, or macOS that provides a nondeterministic real-time response. There's typically no guarantee as to when a task completes.

Examples of specialized hardware and operating systems include:

Windows for IoT is an embedded version of Windows for MPUs with cloud connectivity that lets you create secure devices with easy provisioning and management.

Eclipse ThreadX is a real time operating system for IoT and edge devices powered by MCUs. Eclipse ThreadX is designed to support highly constrained devices that are battery powered and have less than 64 KB of flash memory.

FreeRTOS is a real time operating system for embedded devices. You can use FreeRTOS with the Azure IoT Middleware for FreeRTOS to connect devices to Azure IoT. For an overview of RTOS options for device development, seeC SDK and Embedded C SDK usage scenarios.

Azure Sphere (Integrated) is a secure, high-level application platform with built-in communication and security features for internet-connected devices. It comprises a secured, connected, crossover MCU, a custom high-level Linux-based operating system, and a cloud-based security service that provides continuous, renewable security.

Device primitives

A device developer typically implements the following primitives in device code to interact with the cloud:

• Device-to-cloud messages to send time series telemetry to the cloud. For example, temperature data collected from a sensor attached to the device.
• File uploads for media files such as captured images and video. Intermittently connected devices can send telemetry batches. Devices can compress uploads to save bandwidth.
• Device twins to share and synchronize state data with the cloud. For example, a device can use the device twin to report the current state of a valve it controls to the cloud and to receive a desired target temperature from the cloud.
• Digital twins to represent a device in the digital world. For example, a digital twin can represent a device's physical location, its capabilities, and its relationships with other devices.
• Direct methods to receive commands from the cloud. A direct method can have parameters and return a response. For example, the cloud can call a direct method to request the device to reboot in 30 seconds.
• Cloud-to-device messages to receive one-way notifications from the cloud. For example, a notification that an update is ready to download.

To learn more, seeDevice-to-cloud communications guidance andCloud-to-device communications guidance.

SDKs and libraries

The device SDKs provide high-level abstractions that let you use the primitives without knowledge of the underlying communications protocols. The device SDKs also handle the details of establishing a secure connection to the cloud and authenticating the device.

For MPU devices, device SDKs are available for the following languages:

• C
• Python
• C# (.NET)
• Node.js
• Java

For MCU devices, see:

• Eclipse ThreadX
• FreeRTOS Middleware
• Azure SDK for Embedded C

Samples and guidance

All of the device SDKs include samples that demonstrate how to use the SDK to connect to the cloud, send telemetry, and use the other primitives.

TheIoT device development site includes tutorials and how-to guides that show you how to implement code for a range of device types and scenarios.

You can find more samples in thecode sample browser.

Device development without a device SDK

Although you're recommended to use one of the device SDKS, there might be scenarios where you prefer not to. In these scenarios, your device code must directly use one of the communication protocols that IoT Hub and the Device Provisioning Service (DPS) support.

For more information, see:

• Using the MQTT protocol directly (as a device)
• Using the AMQP protocol directly (as a device)

In an edge-based solution, an operator configures connectors to connect to assets. This configuration includes a mapping between the asset's data and a cloud schema. For example, the OPC UA connector lets the operator map OPC UA node IDs to data points and events in a JSON message exchanged with the MQTT broker. The following screenshot shows an example in the digital operations experience web UI that defines two such mappings:

Elsewhere in the solution, an operator can refer directly to theTemperature andTag 10 tags without needing to know the details of the OPC UA node IDs.

In a cloud-based solution, IoT Plug and Play enables solution builders to integrate IoT devices with their solutions without any manual configuration. At the core of IoT Plug and Play, is a device model that a device uses to advertise its capabilities to an IoT Plug and Play-enabled application such as IoT Central. This model is structured as a set of elements that define:

• Properties that represent the read-only or writable state of a device or other entity. For example, a device serial number might be a read-only property and a target temperature on a thermostat might be a writable property.
• Telemetry that's the data emitted by a device, whether the data is a regular stream of sensor readings, an occasional error, or an information message.
• Commands that describe a function or operation that can be done on a device. For example, a command could reboot a gateway or take a picture using a remote camera.

You can group these elements in interfaces to reuse across models to make collaboration easier and to speed up development.

The model is specified by using theDigital Twins Definition Language (DTDL).

The use of IoT Plug and Play, modeling and DTDL is optional. You can use the IoT device primitives without using IoT Plug and Play or modeling. TheAzure Digital Twins service also uses DTDL models to create twin graphs based on digital models of environments such as buildings or factories.

As a device developer, when you implement an IoT Plug and Play device there are a set of conventions to follow. These conventions provide a standard way to implement the device model in code by using the primitives available in the device SDKs.

To learn more, see:

• What is IoT Plug and Play?
• IoT Plug and Play modeling guide

Azure IoT Operations containerizes all its connectors, brokers, and other components that run on the edge. Azure IoT Operations deploys to a Kubernetes cluster, which is a container orchestration platform. Deploy any custom connectors or other components that you create to the Kubernetes cluster.

You can view a solution that uses Azure IoT Edge as an edge-based gateway to IoT Hub as a hybrid solution that includes elements of both edge-based and cloud-based solutions.

If you use containers, such as in Docker, to run your device code you can deploy code to your devices by using the capabilities of the container infrastructure. Containers also let you define a runtime environment for your code with all the required library and package versions installed. Containers make it easier to deploy updates and to manage the lifecycle of your IoT devices.

Azure IoT Edge runs device code in containers. You can use Azure IoT Edge to deploy code modules to your devices. To learn more, seeDevelop your own IoT Edge modules.