Glossary of IoT terms
This article lists some of the common terms used in the IoT articles.
Advanced Message Queueing Protocol
Advanced Message Queueing Protocol (AMQP) is one of the messaging protocols that IoT Hub supports for communicating with devices. For more information about the messaging protocols that IoT Hub supports, see Send and receive messages with IoT Hub.
Attestation mechanisms include X.509 certificates, Trusted Platform Modules, and symmetric keys.
In IoT Edge, an automatic deployment configures a target set of IoT Edge devices to run a set of IoT Edge modules. Each deployment continuously ensures that all devices that match its target condition are running the specified set of modules, even when new devices are created or are modified to match the target condition. Each IoT Edge device only receives the highest priority deployment whose target condition it meets. Learn more about IoT Edge automatic deployment.
Automatic device configuration
Automatic device management
Automatic device management in Azure IoT Hub automates many of the repetitive and complex tasks of managing large device fleets over the entirety of their lifecycles. With Automatic Device Management, you can target a set of devices based on their properties, define a desired configuration, and let IoT Hub update devices whenever they come into scope. Consists of automatic device configurations and IoT Edge automatic deployments.
Azure Digital Twins
Azure Digital Twins is a platform as a service (PaaS) offering for creating digital representations of real-world things, places, business processes, and people. Build twin graphs that represent entire environments, and use them to gain insights to drive better products, optimize operations and costs, and create breakthrough customer experiences. To learn more, see Azure Digital Twins.
Azure Digital Twins instance
A single instance of the Azure Digital Twins service in a customer's subscription. While Azure Digital Twins refers to the Azure service as a whole, your Azure Digital Twins instance is your individual Azure Digital Twins resource.
Azure IoT device SDKs
There are device SDKs available for multiple languages that enable you to create device apps that interact with an IoT hub. The IoT Hub tutorials show you how to use these device SDKs. You can find the source code and further information about the device SDKs in this GitHub repository.
Azure IoT Explorer
The Azure IoT Explorer is used to view the telemetry the device is sending, work with device properties, and call commands. You can also use the explorer to interact with and test your devices, and to manage IoT Plug and Play devices.
Azure IoT service SDKs
There are service SDKs available for multiple languages that enable you to create back-end apps that interact with an IoT hub. The IoT Hub tutorials show you how to use these service SDKs. You can find the source code and further information about the service SDKs in this GitHub repository.
Azure IoT Tools
The Azure IoT Tools is a cross-platform, open-source Visual Studio Code extension that helps you manage Azure IoT Hub and devices in VS Code. With Azure IoT Tools, IoT developers could develop IoT project in VS Code with ease.
In the context of IoT Hub, a back-end app is an app that connects to one of the service-facing endpoints on an IoT hub. For example, a back-end app might retrieve device-to-cloud messages or manage the identity registry. Typically, a back-end app runs in the cloud, but in many of the tutorials the back-end apps are console apps running on your local development machine.
A type of endpoint that is built into IoT Hub. Every IoT hub includes a built-in endpoint that is Event Hub-compatible. You can use any mechanism that works with Event Hubs to read device-to-cloud messages from this endpoint.
A cloud gateway enables connectivity for devices that cannot connect directly to IoT Hub. A cloud gateway is hosted in the cloud in contrast to a field gateway that runs local to your devices. A typical use case for a cloud gateway is to implement protocol translation for your devices.
In IoT Central, cloud properties are part of the device template, but aren't part of the device model. Cloud properties let the solution developer specify any device metadata to store in the IoT Central application. Cloud properties don't affect the code that a device developer writes to implement the device model.
Refers to messages sent from an IoT hub to a connected device. Often, these messages are commands that instruct the device to take an action. For more information, see Send and receive messages with IoT Hub.
In IoT Plug and Play and Azure Digital Twins, components let you build a model interface as an assembly of other interfaces. A device model can combine multiple interfaces as components. For example, a model might include a switch component and thermostat component. Multiple components in a model can also use the same interface type. For example, a model might include two thermostat components.
In the context of automatic device configuration, a configuration within IoT Hub defines the desired configuration for a set of devices twins and provides a set of metrics to report status and progress.
You use connection strings in your app code to encapsulate the information required to connect to an endpoint. A connection string typically includes the address of the endpoint and security information, but connection string formats vary across services. There are two types of connection string associated with the IoT Hub service:
Device connection strings enable devices to connect to the device-facing endpoints on an IoT hub.
IoT Hub connection strings enable back-end apps to connect to the service-facing endpoints on an IoT hub.
A gateway enables connectivity for devices that cannot connect directly to IoT Hub. You can use Azure IoT Edge to build custom gateways that implement custom logic to handle messages, custom protocol conversions, and other processing on the edge.
In IoT Plug and Play, all device models have a default component. A simple device model only has a default component - such a model is also known as a no component device. A more complex model has multiple components nested underneath the default component.
In IoT Edge, the deployment manifest is a JSON document containing the information to be copied in one or more IoT Edge devices' module twin(s) to deploy a set of modules, routes, and associated module desired properties.
In the context of a device twin, desired configuration refers to the complete set of properties and metadata in the device twin that should be synchronized with the device.
In the context of a device twin, desired properties is a subsection of the device twin that is used with reported properties to synchronize device configuration or condition. Desired properties can only be set by a back-end app and are observed by the device app.
In the context of IoT, a device is typically a small-scale, standalone computing device that may collect data or control other devices. For example, a device might be an environmental monitoring device, or a controller for the watering and ventilation systems in a greenhouse. The device catalog provides a list of hardware devices certified to work with IoT Hub.
A device app runs on your device and handles the communication with your IoT hub. Typically, you use one of the Azure IoT device SDKs when you implement a device app. In many of the IoT tutorials, you use a simulated device for convenience.
A device builder uses a device model and interfaces when implementing code to run on an IoT Plug and Play device. Device builders typically use one of the Azure IoT device SDKs to implement the device client.
The IoT Plug and Play device certification program verifies that a device meets the IoT Plug and Play certification requirements. You can add a certified device to the public Certified for Azure IoT device catalog.
Refers to device state information, such as the connectivity method currently in use, as reported by a device app. Device apps can also report their capabilities. You can query for condition and capability information using device twins.
Device data refers to the per-device data stored in the IoT Hub identity registry. It is possible to import and export this data.
The device identity (or device ID) is the unique identifier assigned to every device registered in the IoT Hub identity registry.
Device management encompasses the full lifecycle associated with managing the devices in your IoT solution including planning, provisioning, configuring, monitoring, and retiring.
Device management patterns
IoT hub enables common device management patterns including rebooting, performing factory resets, and performing firmware updates on your devices.
A device model is a type of model that uses the Digital Twins Definition Language to describe the capabilities of an IoT Plug and Play device. A simple device model uses a single interface to describe the device capabilities. A more complex device model includes multiple components, each of which describe a set of capabilities. To learn more, see IoT Plug and Play components in models.
Device provisioning is the process of adding the initial device data to the stores in your solution. To enable a new device to connect to your hub, you must add a device ID and keys to the IoT Hub identity registry. As part of the provisioning process, you might need to initialize device-specific data in other solution stores.
Device Provisioning Service
IoT Hub Device Provisioning Service (DPS) is a helper service for IoT Hub that you use to configure zero-touch device provisioning to a specified IoT hub. With the DPS, you can provision millions of devices in a secure and scalable manner.
Device REST API
You can use the Device REST API from a device to send device-to-cloud messages to an IoT hub, and receive cloud-to-device messages from an IoT hub. Typically, you should use one of the higher-level device SDKs as shown in the IoT Hub tutorials.
In IoT Central, a device template is a blueprint that defines the characteristics and behaviors of a type of device that connects to your application. For example, the device template defines the telemetry that a device sends so that IoT Central can create visualizations that use the correct units and data types. A device model is part of the device template.
A device twin is JSON document that stores device state information such as metadata, configurations, and conditions. IoT Hub persists a device twin for each device that you provision in your IoT hub. Device twins enable you to synchronize device conditions and configurations between the device and the solution back end. You can query device twins to locate specific devices and for the status of long-running operations.
A digital twin is a collection of digital data that represents a physical object. Changes in the physical object are reflected in the digital twin. In some scenarios, you can use the digital twin to manipulate the physical object. The Azure Digital Twins service uses models expressed in the Digital Twins Definition Language (DTDL) to represent digital twins of physical devices or higher-level abstract business concepts, enabling a wide range of cloud-based digital twin solutions. An IoT Plug and Play device has a digital twin, described by a DTDL device model.
Digital twin change events
When an IoT Plug and Play device is connected to an IoT hub, the hub can use its routing capability to send notifications of digital twin changes. For example, whenever a property value changes on a device, IoT Hub can send a notification to an endpoint such as an Event hub.
Digital twin route
A route set up in an IoT hub to deliver digital twin change events to an endpoint such as an Event hub.
Digital Twins Definition Language (DTDL)
A JSON-LD language for describing models and interfaces for IoT Plug and Play devices and Azure Digital Twins entities. Use the Digital Twins Definition Language version 2 to describe a digital twin's capabilities and enable the IoT platform and IoT solutions to use the semantics of the entity. Digital Twins Definition Language is often abbreviated as DTDL.
A direct method is a way for you to trigger a method to execute on a device by invoking an API on your IoT hub.
A relative term describing services that receive data from the current context. For instance, if you're thinking in the context of Azure Digital Twins, Time Series Insights would be considered a downstream service if you set up your data to flow from Azure Digital Twins into Time Series Insights.
A named representation of a data routing service that can receive data from other services.
An IoT hub exposes multiple endpoints that enable your apps to connect to the IoT hub. There are device-facing endpoints that enable devices to perform operations such as sending device-to-cloud messages and receiving cloud-to-device messages. There are service-facing management endpoints that enable back-end apps to perform operations such as device identity management and device twin management. There are service-facing built-in endpoints for reading device-to-cloud messages. You can create custom endpoints to receive device-to-cloud messages dispatched by a routing rule.
This can refer to any process that is triggered by the arrival of an event and does some processing action. One way to create event handlers is by adding event processing code to an Azure function, and sending data through it using endpoints and event routing.
Event Hub-compatible endpoint
To read device-to-cloud messages sent to your IoT hub, you can connect to an endpoint on your hub and use any Event Hub-compatible method to read those messages. Event Hub-compatible methods include using the Event Hubs SDKs and Azure Stream Analytics.
The process of sending events and their data from one device or service to the endpoint of another.
In Iot Hub, you can define routing rules to describe how messages should be sent. In Azure Digital Twins, event routes are entities that are created for this purpose. Azure Digital Twins event routes can contain filters to limit what types of events are sent to each endpoint.
A gateway device enables connectivity for downstream devices that cannot connect directly to IoT Hub.
Hardware security module
A hardware security module (HSM) is used for secure, hardware-based storage of device secrets. It is the most secure form of secret storage for a device. Both X.509 certificates and symmetric keys can be stored in an HSM. In the Device Provisioning Service, an attestation mechanism can use an HSM.
The ID scope is unique value assigned to a Device Provisioning Service (DPS) instance when it's created.
IoT Central applications make use of DPS instances and make the ID Scope available through the IoT Central UI.
The identity registry is the built-in component of an IoT hub that stores information about the individual devices permitted to connect to an IoT hub.
An interactive message is a cloud-to-device message that triggers an immediate action in the solution back end. For example, a device might send an alarm about a failure that should be automatically logged in to a CRM system.
In IoT Plug and Play, an interface describes related capabilities that are implemented by a IoT Plug and Play device or digital twin. You can reuse interfaces across different device models. When an interface is used in a device model, it defines a component of the device. A simple device only contains a default interface.
In Azure Digital Twins, interface may be used to refer to the top-level code item in a DTDL model definition.
Azure IoT Edge enables cloud-driven deployment of Azure services and solution-specific code to on-premises devices. IoT Edge devices can aggregate data from other devices to perform computing and analytics before sending the data to the cloud. To learn more, see Azure IoT Edge.
IoT Edge agent
The part of the IoT Edge runtime responsible for deploying and monitoring modules.
IoT Edge device
An IoT Edge device uses containerized IoT Edge modules to run Azure services, third-party services, or your own code. On the IoT Edge device, the IoT Edge runtime manages the modules. You can remotely monitor and manage an IoT Edge device from the cloud.
IoT Edge hub
The part of the IoT Edge runtime responsible for module to module communications, upstream (toward IoT Hub) and downstream (away from IoT Hub) communications.
IoT Edge runtime
IoT Edge runtime includes everything that Microsoft distributes to be installed on an IoT Edge device. It includes Edge agent, Edge hub, and the IoT Edge security daemon.
IoT extension for Azure CLI
The IoT extension for Azure CLI is a cross-platform, command-line tool. The tool enables you to manage your devices in the identity registry, send and receive messages and files from your devices, and monitor your IoT hub operations.
IoT Hub is a fully managed Azure service that enables reliable and secure bidirectional communications between millions of devices and a solution back end. For more information, see What is Azure IoT Hub?. Using your Azure subscription, you can create IoT hubs to handle your IoT messaging workloads.
IoT Hub metrics
IoT Hub metrics give you data about the state of the IoT hubs in your Azure subscription. IoT Hub metrics enable you to assess the overall health of the service and the devices connected to it. IoT Hub metrics can help you see what is going on with your IoT hub and investigate root-cause issues without needing to contact Azure support. To learn more, see Monitor IoT Hub.
IoT Hub query language
IoT Hub Resource REST API
You can use the IoT Hub Resource REST API to manage the IoT hubs in your Azure subscription performing operations such as creating, updating, and deleting hubs.
IoT Plug and Play bridge
IoT Plug and Play bridge is an open-source application that enables existing sensors and peripherals attached to Windows or Linux gateways to connect as IoT Plug and Play devices.
IoT Plug and Play conventions
IoT Plug and Play devices are expected to follow a set of conventions when they exchange data with a solution.
IoT Plug and Play device
An IoT Plug and Play device is typically a small-scale, standalone computing device that collects data or controls other devices, and that runs software or firmware that implements a device model. For example, an IoT Plug and Play device might be an environmental monitoring device, or a controller for a smart-agriculture irrigation system. An IoT Plug and Play device might be implemented directly or as an IoT Edge module. You can write a cloud-hosted IoT solution to command, control, and receive data from IoT Plug and Play devices.
In IoT Hub, jobs let you schedule and track activities on a set of devices registered with your IoT hub. Activities include updating device twin desired properties, updating device twin tags, and invoking direct methods. IoT Hub also uses jobs to import to and export from the identity registry.
In IoT Edge, a leaf device is a device with no downstream device.
In Azure Digital Twins, this type of event is fired when a data item—such as a digital twin, a relationship, or an event handler—is created or deleted from your Azure Digital Twins instance.
Linked IoT hub
The Device Provisioning Service (DPS), can provision devices to IoT hubs that have been linked to it. Linking an IoT hub to a DPS instance lets the service register a device ID and set the initial configuration in the device twin.
A model defines a type of entity in your physical environment, including its properties, telemetries, components, and sometimes other information. Models are used to create digital twins that represent specific physical objects of this type. Models are written in the Digital Twins Definition Language.
When an IoT Plug and Play device connects to an IoT Hub, it sends the Model ID of the DTDL model it implements. This ID enables the solution to find the device model.
Model repository REST API
An API for managing and interacting with the model repository. For example, you can use the API to add and search for device models.
A module builder uses a device model and interfaces when implementing code to run on an IoT Plug and Play device. Module builders implement the code as a module or an IoT Edge module to deploy to the IoT Edge runtime on a device.
The module identity is the unique identifier assigned to every module that belongs to a device. Module identity is also registered in the identity registry.
The docker image that the IoT Edge runtime uses to instantiate module instances.
Similar to device twin, a module twin is JSON document that stores module state information such as metadata, configurations, and conditions. IoT Hub persists a module twin for each module identity that you provision under a device identity in your IoT hub. Module twins enable you to synchronize module conditions and configurations between the module and the solution back end. You can query module twins to locate specific modules and query the status of long-running operations.
On the device side, the IoT Hub device SDKs enable you to create modules where each one opens an independent connection to IoT Hub. This functionality enables you to use separate namespaces for different components on your device.
Module identity and module twin provide the same capabilities as device identity and device twin but at a finer granularity. This finer granularity enables capable devices, such as operating system-based devices or firmware devices managing multiple components, to isolate configuration and conditions for each of those components.
In IoT Edge, a module is a Docker container that you can deploy to IoT Edge devices. It performs a specific task, such as ingesting a message from a device, transforming a message, or sending a message to an IoT hub. It communicates with other modules and sends data to the IoT Edge runtime.
MQTT is one of the messaging protocols that IoT Hub supports for communicating with devices. For more information about the messaging protocols that IoT Hub supports, see Send and receive messages with IoT Hub.
A set of models for a particular domain, such as real estate, smart cities, IoT systems, energy grids, and more. Ontologies are often used as schemas for knowledge graphs like the ones in Azure Digital Twins, because they provide a starting point based on industry standards and best practices.
For more information about ontologies, see What is an ontology?
IoT Hub operations monitoring enables you to monitor the status of operations on your IoT hub in real time. IoT Hub tracks events across several categories of operations. You can opt into sending events from one or more categories to an IoT Hub endpoint for processing. You can monitor the data for errors or set up more complex processing based on data patterns.
A physical device is a real device such as a Raspberry Pi that connects to an IoT hub. For convenience, many of the IoT Hub tutorials use simulated devices to enable you to run samples on your local machine.
Primary and secondary keys
When you connect to a device-facing or service-facing endpoint on an IoT hub, your connection string includes key to grant you access. When you add a device to the identity registry or add a shared access policy to your hub, the service generates a primary and secondary key. Having two keys enables you to roll over from one key to another when you update a key without losing access to the IoT hub.
Properties are data fields defined in an interface that represent some persistent state of a digital twin. You can declare properties as read-only or writable. Read-only properties, such as serial number, are set by code running on the IoT Plug and Play device itself. Writable properties, such as an alarm threshold, are typically set from the cloud-based IoT solution.
Property change event
An event that results from a property change in a digital twin.
In the Azure Digital Twins service, relationships are used to connect digital twins into knowledge graphs that digitally represent your entire physical environment. The types of relationships that your twins can have are defined as part of the twins' model definitions—the DTDL model for a certain type of twin includes information about what relationships it can have to other twins.
In the context of a device twin, reported configuration refers to the complete set of properties and metadata in the device twin that should be reported to the solution back end.
In the context of a device twin, reported properties is a subsection of the device twin used with desired properties to synchronize device configuration or condition. Reported properties can only be set by the device app and can be read and queried by a back-end app.
You use a retry policy to handle transient errors when you connect to a cloud service.
SASL PLAIN is a protocol that the AMQP protocol uses to transfer security tokens.
Service operations endpoint
Service REST API
You can use the Service REST API from the solution back end to manage your devices. The API enables you to retrieve and update device twin properties, invoke direct methods, and schedule jobs. Typically, you should use one of the higher-level service SDKs as shown in the IoT Hub tutorials.
Shared access policy
A shared access policy defines the permissions granted to anyone who has a valid primary or secondary key associated with that policy. You can manage the shared access policies and keys for your hub in the portal.
Shared access signature
Shared Access Signatures (SAS) are an authentication mechanism based on SHA-256 secure hashes or URIs. SAS authentication has two components: a Shared Access Policy and a Shared Access Signature (often called a token). A device uses SAS to authenticate with an IoT hub. Back-end apps also use SAS to authenticate with the service-facing endpoints on an IoT hub. Typically, you include the SAS token in the connection string that an app uses to establish a connection to an IoT hub.
For convenience, many of the IoT Hub tutorials use simulated devices to enable you to run samples on your local machine. In contrast, a physical device is a real device such as a Raspberry Pi that connects to an IoT hub.
A solution can refer to a Visual Studio solution that includes one or more projects. A solution might also refer to an IoT solution that includes elements such as devices, device apps, an IoT hub, other Azure services, and back-end apps.
A solution builder creates the solution back end. A solution builder typically works with Azure resources such as IoT Hub and model repositories.
In the context of a device twin, system properties are read-only and include information regarding the device usage such as last activity time and connection state.
In the context of a device twin, tags are device metadata stored and retrieved by the solution back end in the form of a JSON document. Tags are not visible to apps on a device.
In an IoT Edge deployment, the target condition selects the target devices of the deployment, for example tag.environment = prod. The target condition is continuously evaluated to include any new devices that meet the requirements or remove devices that no longer do.
Devices collect telemetry data, such as wind speed or temperature, and use data-point messages to send the telemetry to an IoT hub.
In IoT Plug and Play and Azure Digital Twins, telemetry fields defined in an interface represent measurements. These measurements are typically values such as sensor readings that are sent by devices, like IoT Plug and Play devices, as a stream of data.
An event that indicates the arrival of telemetry data.
You can use a token service to implement an authentication mechanism for your devices. It uses an IoT Hub shared access policy with DeviceConnect permissions to create device-scoped tokens. These tokens enable a device to connect to your IoT hub. A device uses a custom authentication mechanism to authenticate with the token service. IF the device authenticates successfully, the token service issues a SAS token for the device to use to access your IoT hub.
Twin graph (or digital twin graph)
In the Azure Digital Twins service, you can connect digital twins with relationships to create knowledge graphs that digitally represent your entire physical environment. A single Azure Digital Twins instance can host many disconnected graphs, or one single interconnected graph.
Device and module twin queries use the SQL-like IoT Hub query language to retrieve information from your device twins or module twins. You can use the same IoT Hub query language to retrieve information about a Job running in your IoT hub.
A relative term describing services that feed data into the current context. For instance, if you're thinking in the context of Azure Digital Twins, IoT Hub is considered an upstream service because data flows from IoT Hub into Azure Digital Twins.