Examples of Embedded Systems: 20 Real Devices, and What Their Chips Actually Do

Most lists of examples of embedded systems are aimed at students studying for a GCSE. Washing machines, microwave ovens, traffic lights, banking terminals. They are all genuine. But none of them help you work out what embedded engineering is, or whether you need it.

But there is a second bad list, written by chip makers. In it, every gadget will soon have AI on board and all intelligence lives at the edge. Overall, that one is more marketing than engineering.

The list of examples of embedded systems you actually want lies in between. In practice, it groups devices by what the processor is doing. That, in turn, sets the architecture, the cost, the functional-safety regime, and whether you need a firmware crew at all.

What is an embedded system?

An embedded system is a computer built into a product to do one specific task, not general-purpose computing. It usually runs on a microcontroller: a CPU core such as an ARM Cortex-M, with RAM, flash and peripherals on one chip. Even so, constraints on memory, speed and power are tight. The software runs directly on the hardware with no operating system, or on a real-time OS such as FreeRTOS or Zephyr, or on a general-purpose OS like embedded Linux.

In practice, the main constraint is determinism. A web server that takes 400ms instead of 40ms is slow but functional. An airbag controller that waits 40ms before firing is a fatality. That one fact shapes the whole project: the scheduler, the ban on dynamic memory allocation in some code, the coding standard (typically MISRA C), and the test regime.

Wikipedia has a good definition. However, what it skips is that the boundary is contested. Ask ten engineers what an embedded system is and you get several answers. Show them a Raspberry Pi running Linux and some control code, and you get a debate. So the line most people draw is simple. Is the software written against the hardware (registers, interrupts, peripheral drivers), or against an OS abstraction?

Examples of embedded systems, grouped by what the compute does

These examples of embedded systems fall into four groups by purpose, not product form: closed-loop control, signal processing, connectivity and telemetry, and local inference. Naturally, closed-loop control is by far the largest, and where most professional embedded work happens. You read a sensor. The software decides what to do. You send a command to an actuator. You read the sensor again.

Closed-loop control

• Battery management systems, monitoring and balancing every cell in a large pack. Production BMS work routinely involves hundreds of individual cells, each with its own voltage and temperature limits.
• Engine control modules, airbag systems, electric power steering. Modern vehicles contain dozens of such ECUs.
• AC/DC converters for electric vehicle charging, running into the hundreds of kilowatts.
• Lift controllers, PLCs in a plant, HVAC, CNC machines, railway signalling.
• Clinical devices such as infusion pumps and ventilators, where a control loop error manifests as a medical event.

Signal processing

The chip filters, transforms, or decodes a sequence of samples.

• Hearing aids, running audio DSP inside a milliwatt envelope.
• Digital cameras, where the firmware and the PCB are the real product.
• ECG and pulse oximetry front ends.
• Vehicle HMI and instrument clusters, driving graphics libraries on a microcontroller with nothing resembling a GPU.

Connectivity and telemetry

Here the job is to move data reliably out of somewhere without a reliable connection.

• IoT gateways, collecting traffic from BLE, Zigbee, or LoRa sensors.
• CAN bus nodes throughout a vehicle.
• Fleet trackers, SCADA remote terminal units, industrial sensor networks.

Local inference

In this group, the chip runs a model.

• Wake-word detection on a smart speaker.
• Vibration anomaly detection on a motor, spotting a bearing that is about to seize.
• Basic vision classification on agricultural or security cameras.

Still, of these examples of embedded systems, that fourth group is real. It is just much smaller than the marketing implies. It is worth understanding why.

What actually runs on the chip: bare metal, RTOS, or embedded Linux

Three options. Generally, the decision is made out of necessity, not preference.

Bare metal means your code is the only code. No scheduler, no kernel beneath it, just a main loop and a few interrupt handlers. It gives maximum timing determinism and the smallest memory footprint. However, it becomes unmanageable the moment you need to multitask. A common mistake is to start bare metal on a project that later grows a GUI, a network stack and OTA updates.

An RTOS (FreeRTOS, Zephyr, ThreadX) gives you pre-emptive multitasking, priorities and deterministic scheduling. It costs a few KB of RAM. It also introduces a new category of bug: priority inversion, stack overflow when you underestimated the stack, heap fragmentation after three weeks of uptime.

Embedded Linux (built with Yocto or Buildroot) gives you drivers, a full filesystem, a TCP/IP stack and a package manager. It also needs an application processor, external RAM, boot times in seconds, and a much higher BOM. For a gateway or an HMI, it is a great choice. But for a battery sensor that must run on a coin cell for five years, it is a terrible one.

You are stuck with this choice for the life of the product, especially around over-the-air updates. An OTA mechanism you add later is an OTA mechanism you will get wrong.

The AI question: when running a model on the device is a mistake

Here is the thesis that separates this article from any vendor page. For most connected products, inference on the device is the wrong strategy. Teams that do it usually regret it, and would have been better off calling a cloud API.

The failure modes

The failure modes are common, predictable, and widely discussed. A model that fits on paper does not fit in real device memory, once the network stack, drivers and application have taken their share of the heap. For example, on chips like the ESP32-S3 this shows up as an out-of-memory error. The model is not oversized in isolation. There is just nothing left after the existing firmware runs. Similarly, a model that looked fine in a live classification tool can do poorly against the real sensor and real production data. Quantisation to INT8 does not always survive that transition. And when the model drifts, you must ship a new one to every device in the field, over a network those devices may not reliably have.

When on-device inference is worth it

None of that makes on-device inference a bad idea. Instead, it is a specific idea, justified in specific cases. On-device inference is worth the investment if any of these holds:

• A hard latency budget. You need an inference in under roughly 50ms and a round trip to a server will not get you there.
• Offline is a requirement, not a feature. The device has to work in a tunnel, a field, a factory basement, or an aircraft.
• The data cannot leave the device. Regulatory data residency, clinical data, or a privacy claim you have made to customers and intend to honour.
• Volume makes cloud cost dominate. At millions of devices running continuous inference, the per-inference arithmetic changes.
• The power budget is in milliwatts. A radio transmitting sensor data continuously will drain a battery faster than a small model running locally.

Otherwise, if you have a reliable network and can tolerate a couple of hundred milliseconds, send the data to a server. It is also faster to develop and easier to maintain. You can improve the model without visiting a single device.

Meanwhile, the tooling is good and getting better. TensorFlow Lite for Microcontrollers can run models in as little as 16KB of RAM. Edge Impulse has made the path from training to deployment much shorter. Good tooling reduces the cost of the experiment. It does not decide whether it is the right experiment.

Security and UK compliance: what the PSTI Act changed

If you make and sell a connected consumer product in the UK, this is not a nice-to-have. It is not a matter of filling in some forms.

Part 1 of the Product Security and Telecommunications Infrastructure Act 2022 came into force on 29 April 2024. It arrived alongside the Security Requirements for Relevant Connectable Products Regulations 2023. It sets three requirements for manufacturers of consumer connectable products:

1. No universal default or easily guessable passwords. Passwords must be unique per device, or set by the user on first use. This is a firmware and provisioning change, not a documentation change.
2. A published vulnerability disclosure policy, specifying both a contact point and an acknowledgement process.
3. A published minimum security update period, stating how long the product will receive security updates.

Every product must ship with a Statement of Compliance. Enforcement sits with the Office for Product Safety and Standards. The government guidance sets out duties across manufacturers, importers and distributors. Penalties reach £10 million or 4% of global turnover.

Scope: who is in, and who is exempt

Still, scope is the part teams get wrong. In scope are consumer connectable products: smart speakers, connected cameras, smart TVs, wearables, connected alarm systems. Several categories are expressly exempt: electric vehicle charge points, medical devices, certain smart meters, and computers. Assuming your industrial product is in scope wastes money. Assuming your consumer product is exempt is far worse. You find out when the product is pulled.

Other regimes sit alongside it. MISRA C as a coding standard. ISO 26262 for automotive functional safety. IEC 62304 for medical device software. The EU Cyber Resilience Act sits there too. It is separate and much wider, covering all products with digital elements, with full compliance due by December 2027. Ship into both markets and you manage two sets of duties.

Where the AI value in a device fleet actually is

Go back to those four groups of examples of embedded systems. Three of them (control, signal processing, telemetry) produce something valuable that has nothing to do with running a model on the chip. They produce a real data stream describing what machines are doing in the world.

So for most product companies, that is where the useful AI work sits. Not squeezing a quantised classifier into a Cortex-M with 256KB of RAM and two GPIO pins. Instead, take the telemetry the fleet already produces and move it somewhere with real memory, real compute, and the ability to retrain. Failure prediction across a fleet, not a single unit. Warranty claim triage based on what the device actually did. Anomaly detection with a model you can update on a Tuesday afternoon.

None of that is firmware work. Instead, it is integration work. You get device data into a warehouse, build an evaluation harness so you know whether the model is any good, and wire the output into the systems your operations team already uses.

That is where Pixelfield works. We connect device data to the systems you already run. We build the pipelines and the evaluation around it, so what comes out is something you can act on, not something we demo.

The firmware on the chip should keep doing what it has always done, and do it deterministically.

Before you put a model on a device

Embedded engineering in 2026 is not far off 2016: control loops, power management, device drivers, and an ever-growing pile of compliance work. It runs on MCUs with less RAM than your browser tab. That is not a disappointing conclusion. It is why the field is durable. Most examples of embedded systems in the field today are still exactly that.

Work out whether AI belongs on your device, in your fleet’s data, or nowhere near either. The question is answerable before you write a line of firmware. Our AI readiness audit is a structured assessment of your use case, your data and your infrastructure. Sometimes it ends with a simple answer: do not build this. We would rather tell you that in week one than in month nine.

Frequently asked questions

What are the four types of embedded systems?

Textbook definitions group them by performance and functionality: standalone, real-time, networked and mobile. Those groupings are not much use in practice. A more useful split is what the compute does: closed-loop control, signal processing, connectivity and telemetry, or local inference. That grouping sets the architecture, the safety regime and the testing method. The textbook version does not.

Is a washing machine an embedded system?

Yes, and it is a good illustration of a control loop. It has inputs (water level, temperature, drum load) and an embedded computer choosing the next step of the cycle. The outputs are motors and valves. It is a poor example of professional embedded work, though. The hard problems sit in battery management, automotive, industrial automation and medical devices, where a control failure means more than a wet t-shirt.

What is the difference between firmware and embedded software?

Most engineers use the terms interchangeably. Where a line is drawn, firmware runs on a microcontroller and talks directly to the hardware, written in C, C++ or increasingly Rust. Embedded software sits further up the stack, on an embedded Linux system with an OS underneath. The real difference is what you write against: registers and interrupts, or an OS abstraction.

Do embedded systems use AI?

Some do, though far fewer than the hype suggests. Most embedded AI is on-device inference for wake-word detection, vibration anomaly detection or simple vision, running heavily quantised models in a few kilobytes of RAM. For the rest of the connected product market, the model belongs on a server. It is cheaper to run, easier to update, and does not fight the network stack for heap.

Does the PSTI Act apply to my product?

The PSTI Act applies to consumer connectable products sold in the UK: devices that connect to a network and are sold to consumers. Electric vehicle charge points, medical devices, certain smart meters and computers are expressly excluded. For in-scope products you need unique or user-set passwords, a published vulnerability disclosure policy, a declared security update period, and a Statement of Compliance with the product.

We build hardware and we are being told we need an AI strategy. Where do we start?

Start with the data your product already ships, not with the chip. For most fleets, the value in the telemetry (failures, usage patterns, warranty exposure) beats anything a model could do on-device. An AI readiness audit tells you which is true for your fleet, and whether the honest answer is that you do not need a model at all yet.

Written by Michal Vavra, Head of AI and Development at Pixelfield.