<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Device Lifecycle on Embedded Systems Development</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/device-lifecycle/</link><description>Recent content in Device Lifecycle on Embedded Systems Development</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://applied-ee.github.io/embedded/docs/iot-systems/device-lifecycle/index.xml" rel="self" type="application/rss+xml"/><item><title>OTA Firmware Updates</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/device-lifecycle/ota-firmware-updates/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/device-lifecycle/ota-firmware-updates/</guid><description>&lt;h1 id="ota-firmware-updates"&gt;OTA Firmware Updates&lt;a class="anchor" href="#ota-firmware-updates"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Over-the-air (OTA) firmware updates allow deployed devices to receive new firmware without physical access or debug probes. The update lifecycle spans far more than the actual flash write — it involves delivery infrastructure, transport protocols, image verification, partition management, and rollback strategies that determine whether a fleet of thousands stays healthy or bricks itself simultaneously. The low-level bootloader mechanics (dual-bank flash, boot swap, vector table relocation) are covered in &lt;a href="https://applied-ee.github.io/embedded/docs/development/toolchains-and-build-systems/flash-and-boot/"&gt;Flashing &amp;amp; Boot Modes&lt;/a&gt;. This page focuses on the system-level update pipeline: how firmware images move from a build server to a running device and what happens when something goes wrong along the way.&lt;/p&gt;</description></item><item><title>Device Provisioning</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/device-lifecycle/device-provisioning/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/device-lifecycle/device-provisioning/</guid><description>&lt;h1 id="device-provisioning"&gt;Device Provisioning&lt;a class="anchor" href="#device-provisioning"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Device provisioning is the process of assigning a unique identity and initial credentials to a device so it can authenticate to cloud services, peer devices, or local gateways. Provisioning spans from the factory floor — where silicon serial numbers and cryptographic keys are first bound together — through field activation, where a device autonomously enrolls itself into a fleet. A provisioning failure leaves a device either unable to connect at all or, worse, connected with weak or shared credentials that compromise the entire fleet. The low-level secure boot chain and hardware trust anchors overlap with &lt;a href="https://applied-ee.github.io/embedded/docs/iot-systems/device-lifecycle/ota-firmware-updates/"&gt;OTA Firmware Updates&lt;/a&gt;, but this page focuses on the identity lifecycle: how a device goes from bare silicon to an authenticated member of a managed fleet.&lt;/p&gt;</description></item><item><title>Fleet Monitoring</title><link>https://applied-ee.github.io/embedded/docs/iot-systems/device-lifecycle/fleet-monitoring/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/iot-systems/device-lifecycle/fleet-monitoring/</guid><description>&lt;h1 id="fleet-monitoring"&gt;Fleet Monitoring&lt;a class="anchor" href="#fleet-monitoring"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Fleet monitoring is the practice of continuously collecting, transmitting, and analyzing health telemetry from deployed embedded devices to detect failures, performance degradation, and anomalous behavior before they escalate to outages. Unlike server monitoring — where agents run on machines with gigabytes of RAM and gigabit network links — embedded fleet monitoring operates under severe constraints: microcontrollers with 64–512 KB of RAM, cellular connections billed per kilobyte, and battery budgets measured in milliamp-hours. The challenge is extracting enough observability from each device to manage a fleet of thousands without the monitoring overhead itself becoming the dominant consumer of bandwidth, power, and flash wear.&lt;/p&gt;</description></item></channel></rss>