Initial device development article

Author: dominicbetts

articles/iot/iot-overview-connectivity.md

@@ -1,7 +1,7 @@
 ---
 title: Device infrastructure and connectivity
 titleSuffix: Azure IoT
-description: An overview of device infrastructure and connectivity in an Azure IoT solution, including protocols and gateways.
+description: An overview of device infrastructure and connectivity in an Azure IoT solution, including gateways and protocols such as MQTT and OPC-UA.
 ms.service: iot-fundamentals
 services: iot-fundamentals
 author: dominicbetts
@@ -40,7 +40,7 @@ An Azure IoT hub exposes a collection of per-device endpoints that let devices e
 - *Retrieve and update device twin properties*. A device uses this endpoint to access its device twin properties.
 - *Receive direct method requests*. A device uses this endpoint to listen for direct method requests.
 
-Every IoT hub has a unique hostname that is used to connect devices to the hub. The hostname is in the format `iothubname.azure-devices.net`. If you use one of the device SDKs, you don't need to know the full names of the individual endpoints because the SDKs provide higher level abstractions. However, the device does need to know the hostname of the IoT hub it's connecting to.
+Every IoT hub has a unique hostname that is used to connect devices to the hub. The hostname is in the format `iothubname.azure-devices.net`. If you use one of the device SDKs, you don't need to know the full names of the individual endpoints because the SDKs provide higher level abstractions. However, the device does need to know the hostname of the IoT hub to which it's connecting.
 
 A device can establish a connection to an IoT hub:
 
@@ -91,6 +91,8 @@ To learn more about how to choose a protocol for your devices to connect to the
 - [Communicate with DPS using the HTTPS protocol (symmetric keys)](../iot-dps/iot-dps-https-sym-key-support.md)
 - [Communicate with DPS using the HTTPS protocol (X.509)](../iot-dps/iot-dps-https-x509-support.md)
 
+Industrial IoT scenarios often use the [open platform communications unified architecture (OPC UA)](https://opcfoundation.org/about/opc-technologies/opc-ua/) industry standard open interface. To enable connectivity to IoT Hub, use the OPC Publisher that runs as a module on IoT Edge. To learn more, see [What is the OPC Publisher?](../industrial-iot/overview-what-is-opc-publisher.md)
+
 ## Connection patterns
 
 There are two broad categories of connection patterns that IoT devices use to connect to the cloud:

articles/iot/iot-overview-device-development.md

@@ -0,0 +1,131 @@
+---
+title: Device development introduction
+titleSuffix: Azure IoT
+description: An overview of Azure IoT device development including an introduction to the device SDKs, modeling, IoT Edge modules, and a survey of the available tools.
+ms.service: iot-fundamentals
+services: iot-fundamentals
+author: dominicbetts
+ms.author: dobett
+ms.topic: overview
+ms.date: 03/16/2023
+ms.custom: template-overview
+
+# As a solution builder or device developer I want a high-level overview of the issues around device development so that I can easily find relevant content.
+---
+
+# Device development
+
+This overview introduces some of the key concepts around developing devices to connect to a typical Azure IoT solution. Each section includes links to content that provides further detail and guidance.
+
+IoT Central applications use the IoT Hub and the Device Provisioning Service (DPS) services internally. Therefore, the concepts in this article apply whether you're using IoT Central to explore an IoT scenario or building your solution by using IoT Hub and DPS.
+
+:::image type="content" source="media/iot-overview-device-development/iot-architecture.svg" alt-text="High-level IoT solution architecture diagram that highlights device connectivity areas" border="false":::
+
+In Azure IoT, a device developer writes the code to run on the device. 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 it's disconnected from the cloud.
+
+## Device types
+
+IoT devices can be separated into two broad categories, microcontrollers (MCUs) and 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 within the chip itself. An MPU draws 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 MacOSX that provides a nondeterministic real-time response. There's typically no guarantee as to when a task will complete.
+
+[Windows for IoT](/windows/iot/product-family/windows-iot) is an embedded version of Windows for MPUs with cloud connectivity that lets you create secure devices with easy provisioning and management.
+
+[Azure RTOS](/rtos/overview-rtos) is a real time operating system for IoT and edge devices powered by MCUs. Azure RTOS is designed to support highly constrained devices that are battery powered and have less than 64 KB of flash memory.
+
+[Azure Sphere](/azure-sphere/product-overview/what-is-azure-sphere) 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.
+
+## Primitives
+
+An Azure IoT device can use the following primitives when it interacts 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.
+
+## Device SDKs
+
+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](https://github.com/Azure/azure-iot-sdk-c/)
+- [Python](https://github.com/Azure/azure-iot-sdk-python/)
+- [C# (.NET)](https://github.com/Azure/azure-iot-sdk-csharp/)
+- [Node.js](https://github.com/Azure/azure-iot-sdk-node/)
+- [Java](https://github.com/Azure/azure-iot-sdk-java/)
+
+For MCU devices, see:
+
+- [Azure RTOS Middleware](https://github.com/azure-rtos/)
+- [FreeRTOS Middleware](https://github.com/Azure/azure-iot-middleware-freertos)
+- [Azure SDK for Embedded C](https://github.com/Azure/azure-sdk-for-c)
+
+## Samples
+
+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.
+
+You can find more samples in the [code sample browser](/samples/browse/?expanded=azure&products=azure-iot%2Cazure-iot-edge%2Cazure-iot-pnp%2Cazure-rtos).
+
+## Device development without a device SDK
+
+Although you're recommended to use one of the device SDKS, there may 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)](../iot-hub/iot-hub-mqtt-support.md#using-the-mqtt-protocol-directly-as-a-device)
+- [Using the AMQP protocol directly (as a device)](../iot-hub/iot-hub-amqp-support.md#device-client)
+
+## Device modeling
+
+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 may be a read-only property and a target temperature on a thermostat may 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.
+
+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-develop/overview-iot-plug-and-play.md)
+- [IoT Plug and Play modeling guide](../iot-develop/concepts-modeling-guide.md)
+
+## Containerized device code
+
+Using containers, such as Docker, to run your device code lets you 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 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, see [Develop your own IoT Edge modules](../iot-edge/module-development.md).
+
+> [!TIP]
+> Azure IoT Edge enables multiple scenarios. In addition to running your IoT device code in containers, you can use Azure IoT Edge to run Azure services on your devices and implement field gateways. For more information, see [What is Azure IoT Edge?](../iot-edge/about-iot-edge.md).
+
+## Development tools
+
+The following table lists some of the key development tools that you can use to develop IoT devices:
+
+| Tool | Description |
+| --- | --- |
+| [Azure IoT Hub (VS Code extension)](https://marketplace.visualstudio.com/items?itemName=vsciot-vscode.azure-iot-toolkit) | This VS Code extension lets you manage your IoT Hub resources and devices from within VS Code. |
+| [Azure IoT explorer](howto-use-iot-explorer.md) | This cross-platform tool lets you manage your IoT Hub resources and devices from a desktop application. |
+| [Azure IoT extension for Azure CLI](https://learn.microsoft.com/en-gb/cli/azure/service-page/azure%20iot) | This CLI extension includes commands such as `az iot device simulate`, `az iot device c2d-message`, and `az iot hub monitor-events` that help you test interactions with devices. |
+
+## Next steps
+
+Now that you've seen an overview of device development in Azure IoT solutions, some suggested next steps include:
+
+- [Device infrastructure and connectivity](iot-overview-connectivity.md).

articles/iot/iot-overview-device-management.md

@@ -44,7 +44,7 @@ Azure IoT solutions can use the following primitives for both device management
 - *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 receive one-way notifications from the cloud. For example, a notification that an update is ready to download.
+- *Cloud-to-device* messages to receive one-way notifications from the cloud. For example, a notification that an update is ready to download.
 
 ## Device registration
 
@@ -60,9 +60,9 @@ To lean more, see [Understand the identity registry in your IoT hub](../iot-hub/
 
 ## Device provisioning
 
-You must configure each device in your solution with the details of the IoT hub it should connect to. You can manually configure each device in your solution, but this may not be practical for a large number of devices. To get around this problem, you can use the Device Provisioning Service (DPS) to automatically register each device with an IoT hub and then provision each device with the required connection information. If your IoT solution uses multiple IoT hubs, you can use DPS to provision devices to a hub based on criteria such as which is the closest hub to the device.
+You must configure each device in your solution with the details of the IoT hub it should connect to. You can manually configure each device in your solution, but this may not be practical for a large number of devices. To get around this problem, you can use the Device Provisioning Service (DPS) to automatically register each device with an IoT hub, and then provision each device with the required connection information. If your IoT solution uses multiple IoT hubs, you can use DPS to provision devices to a hub based on criteria such as which is the closest hub to the device.
 
-If your IoT solution uses IoT Hub, then using DPS is optional. If you're using IoT Central, then your solution automatically uses a DPS instance that's managed by IoT Central.
+If your IoT solution uses IoT Hub, then using DPS is optional. If you're using IoT Central, then your solution automatically uses a DPS instance that IoT Central manages.
 
 To learn more, see [Device provisioning service overview](../iot-dps/about-iot-dps.md).
 
@@ -74,17 +74,17 @@ To learn more, see [What is Azure IoT Edge?](../iot-edge/about-iot-edge.md)
 
 ## Device updates
 
-Typically, your IoT solution must include a way to update device software. In the case of an IoT Edge device, you can update the modules that run on the device by updating the deployment manifest.
+Typically, your IoT solution must include a way to update device software. For an IoT Edge device, you can update the modules that run on the device by updating the deployment manifest.
 
-In the case of a non-IoT Edge device, you need to have a way to update the device firmware. This could be a process that uses a cloud-to-device message to notify the device that a firmware update is available. Then the device runs custom code to download and install the update.
+For a non-IoT Edge device, you need to have a way to update the device firmware. This update process could use a cloud-to-device message to notify the device that a firmware update is available. Then the device runs custom code to download and install the update.
 
 The Device Update for IoT Hub service provides a managed solution for updating devices. It enables you to upload firmware updates to the cloud and then distribute them to devices. It also lets your monitor the update process and roll back to a previous version if the update fails.
 
 To learn more, see [What is Device Update for IoT Hub?](../iot-hub-device-update/understand-device-update.md)
 
 ## Device key management and rotation
 
-During the lifecycle of your IoT solution you may need to roll over the keys used to authenticate devices. For example, you may need to do this if you suspect that a key has been compromised or if a certificate expires:
+During the lifecycle of your IoT solution, you may need to roll over the keys used to authenticate devices. For example, you may need to roll over your keys if you suspect that a key has been compromised or if a certificate expires:
 
 - [Roll over the keys used to authenticate devices in IoT Hub and DPS](../iot-dps/how-to-roll-certificates.md#roll-x509-device-certificates)
 - [Roll over the keys used to authenticate devices in IoT Central](../iot-central/core/how-to-connect-devices-x509.md#roll-x509-device-certificates)
@@ -114,9 +114,13 @@ To send commands to your devices to control their behavior, use:
 
 To learn more, see [Cloud-to-device communications guidance](../iot-hub/iot-hub-devguide-c2d-guidance.md).
 
+Device control can be automated based in feedback loops. For example, if the device temperature is too high, logic running in the cloud can send a command to turn on a fan. The cloud process can then send a command to turn off the fan when the temperature is back to normal.
+
+It's also possible to run this kind of automation locally. For example, if you're using IoT Edge to implement your gateway device, you can run the logic that controls the device in an IoT Edge module. Running this kind of logic at the edge can reduce latency and provide resilience in the case of a network outage.
+
 ## Jobs
 
-You can use direct methods, desired properties, and cloud-to-device messages to send commands to individual devices. If you need to send commands to multiple devices, you can use jobs. Jobs let you to schedule and send commands and desired property updates to multiple devices at the same time. You can also use jobs to monitor the progress of the commands and to roll back to a previous state if the commands fail.
+You can use direct methods, desired properties, and cloud-to-device messages to send commands to individual devices. If you need to send commands to multiple devices, you can use jobs. Jobs let you schedule and send commands and desired property updates to multiple devices at the same time. You can also use jobs to monitor the progress of the commands and to roll back to a previous state if the commands fail.
 
 To learn more, see: