What Is an Embedded System? Parts and Examples

Concept render

Embedded systems are small computers built into a product to do one job. Each has a processor, memory, interfaces to sensors and actuators, a power supply and firmware, and often a radio. Wearables, trackers, smart speakers and car controllers all run one. Most battery devices use a microcontroller with an RTOS. Larger ones run embedded Linux.

Almost every connected device has a computer inside that reads sensors, runs a radio and sleeps between tasks to save the battery. That computer and its firmware make up an embedded system. This guide explains what embedded systems are, the parts they are built from, the main types, real examples from consumer devices, how one is designed and tested, and what a product team should own at the end.

This is an engineering summary. Chip specifications come from vendor product pages, and all sources were read on November 12, 2026. The chips named are examples. They are not recommendations for your design.

What are embedded systems?

An embedded system is a computer that is part of a larger product and does a fixed set of jobs. Arm describes embedded system design as the process of developing specialized computing systems that perform dedicated functions, and says these systems integrate hardware and software under real-time, power and resource constraints. It lists reliability, low power consumption and minimal size as typical goals (Arm glossary, embedded system design, as of November 2026).

Three things set an embedded system apart from a laptop or phone:

• A dedicated job. The firmware is written for one product. Users do not install programs on it.
• Tight limits. Memory is measured in kilobytes or a few megabytes, power in microamps while asleep, and size in millimeters.
• Timing. Many tasks must finish within a known time, such as reading a sensor at a fixed rate or answering a radio event.

The code that runs on it is called firmware. For how firmware relates to app and cloud software, see firmware vs software vs hardware.

What are the parts of an embedded system?

Arm lists the key components as a microcontroller or microprocessor, memory, input and output interfaces, power management, firmware and software, and the printed circuit board (Arm glossary, as of November 2026). A connected device adds a radio and security hardware. The table uses Nordic's nRF52840, a common Bluetooth LE chip in wearables, as a worked example.

nRF52840 figures are from Nordic's product page, which also lists a 3.5 mm × 3.6 mm WLCSP package among its options (nRF52840, as of November 2026). A whole computer with its radio fits on a chip smaller than a fingernail. That is what makes a ring or a pendant possible.

What types of embedded systems are there?

Embedded systems range from a few kilobytes of code on a microcontroller to a full Linux system. The software platform is the main split. The rows below are engineering reasoning, and none describes a specific project.

Vendor pages show how wide the range is, as of November 2026:

• Microcontroller with Bluetooth LE. The nRF52840 runs a 64 MHz Cortex-M4 with 1 MB flash and 256 KB RAM (Nordic).
• Microcontroller with Wi-Fi and Bluetooth LE. Espressif's ESP32-S3 is a dual-core Xtensa LX7 MCU at up to 240 MHz with 512 KB of internal SRAM, support for octal SPI flash and PSRAM, 2.4 GHz Wi-Fi and Bluetooth 5 (LE). Espressif says its vector instructions accelerate neural network and signal processing workloads (Espressif).
• Embedded Linux module. Raspberry Pi's Compute Module 5 has a quad-core 64-bit Arm Cortex-A76 at 2.4 GHz, 2 to 16 GB of LPDDR4 RAM and up to 64 GB of eMMC. Raspberry Pi calls it the new standard for embedded computing and says it will stay in production until at least January 2036 (Raspberry Pi).

The middle tier, a microcontroller with a real-time operating system, covers most battery devices. The Zephyr project describes its kernel as designed for resource-constrained and embedded systems, from simple environmental sensors and LED wearables to embedded controllers, smart watches and IoT wireless applications (Zephyr introduction, as of November 2026). For how an RTOS schedules work and how FreeRTOS and Zephyr compare, see what is an RTOS. For the microcontroller vs Linux choice in a voice or AI wearable, see MCU or Linux SoC for an AI wearable.

What does real-time mean in an embedded system?

Real-time means the answer must arrive within a known time, and a late answer counts as a failure. In a wearable, that can be an audio buffer that must be read before the next one fills, a sensor sampled at a fixed rate for a heart rate algorithm, or a radio event that must be answered in its time slot.

Zephyr lists the kernel services a real-time system leans on: priority-based and preemptive threads, interrupt handling, memory allocation, semaphores and mutexes, message queues, and system and device power management (Zephyr introduction, as of November 2026). The design question is the worst case. Measure the time from each event to its response on the real board, over long runs, with the radio busy.

What are examples of embedded systems in connected devices?

Arm lists application areas such as IoT, automotive, healthcare and industrial automation, with examples including pacemakers and diagnostic tools, driver assistance, infotainment and battery management (Arm glossary, as of November 2026). In consumer connected devices, typical examples are:

• Health wearables. A band or ring samples motion, PPG and temperature sensors, runs algorithms on the microcontroller and syncs over Bluetooth LE. See health wearable development.
• Trackers. A GNSS receiver and an LTE-M or Cat-1bis modem report location on a schedule and sleep the rest of the time. See LTE and GNSS trackers.
• Voice and recording devices. Microphones feed a wake word or voice activity detector on the device, and audio goes to an app or the cloud. See audio and voice hardware.
• Companions and smart home devices. A speaker, screen or sensor hub with Wi-Fi, often on an application processor.

How is an embedded system designed?

Arm lists the steps of embedded system design as requirement analysis, system architecture, hardware and firmware design, prototyping and integration, testing and validation, and deployment and maintenance (Arm glossary, as of November 2026). In a device program, each step produces something you can review:

• Requirements. What the device must do, its battery life, size, environment and regulatory targets. Arm says to define limits such as latency, cost and power at this stage.
• Architecture. The processor, radio, sensors, power tree, firmware platform and update path, with the reasons for each choice.
• Hardware and firmware design. Schematic, board layout, drivers and application code, built in parallel and joined early on development boards.
• Prototyping and integration. First boards, bring-up, then the full device in its enclosure.
• Testing and validation. Functional, timing, power, radio and environmental tests, and pre-compliance before certification.
• Deployment and maintenance. Manufacturing test firmware, signed release images and over-the-air updates for the life of the product.

Arm lists power techniques such as dynamic voltage scaling, sleep modes, efficient coding and low-power components. In a battery device, power is a design input from the first step. For the regulator choices, see LDO vs buck converter.

How is an embedded system tested?

Arm names functional, real-time and environmental testing (Arm glossary, as of November 2026). For a connected device, a working list looks like this:

• Unit tests for logic that can run on a computer, and hardware-in-the-loop tests for drivers.
• Timing measurements with a logic analyzer for each deadline.
• Current measurements in every power state, over full days of use.
• Radio range and coexistence tests in the final enclosure.
• Update tests, including power loss in the middle of an update. See firmware OTA failures that brick devices.
• Temperature, drop and humidity tests on complete units.

What should a product team own at the end?

The embedded system is your product. If only a vendor can build or update its firmware, you depend on that vendor for every fix. Ask for these at every handover:

• The full firmware source, in a repository you control, with a build that reproduces the shipped image.
• The schematic, board layout and bill of materials in their native formats.
• The signing keys, or a documented process where you hold them.
• A software bill of materials. CISA describes an SBOM as a nested inventory, a list of ingredients that make up software components, and calls it a key building block in software security and supply chain risk management (CISA SBOM page, as of November 2026).

Our SBOM and source file handover checklist lists what to check. For how Duobay handles firmware work and handover, see firmware development.

Bring these questions to your hardware team:

• Which processor and which SDK version are we on, and who updates the SDK when the vendor ships a fix?
• Do we use bare metal, an RTOS or Linux, and why?
• Which tasks have deadlines, and how were they measured on the real board?
• How much flash and RAM is used today, and how much headroom is left for updates?
• How does a field update work, and what happens if power fails in the middle of one?
• Where are the signing keys kept, and who can use them?
• Do we receive an SBOM with every release, and does it list every library and its license?

If you are planning a connected device and want the embedded system scoped from chip choice to handover, tell us about your device.

Sources. All pages accessed November 12, 2026. Vendors update product pages, so confirm current values before you decide.

• Arm, Glossary: What is embedded system design (ESD)? (link)
• Nordic Semiconductor, nRF52840 product page (link)
• Espressif, ESP32-S3 product page (link)
• Zephyr Project, Introduction (link)
• Raspberry Pi, Compute Module 5 product page (link)
• CISA, Software Bill of Materials (SBOM) (link)