Embedded System Architecture

Introduction

An embedded system is more than a microcontroller and a few wires. It is a structured combination of hardware, firmware, connectivity, and documentation that senses the physical world, acts on it, and often exchanges data with other systems. Whether you build a weather station, a robot controller, or a connected IoT device, you need a clear architecture: a description of what each part does and how the parts connect, both electrically and in software.

Without architecture, projects tend to grow into a tangle of copy-pasted example code and undocumented wiring. With architecture, you can explain your design to teammates, verify that requirements are met, and rebuild the prototype months later from your wiring diagram and bill of materials.

This page is the overview. Each layer has its own article with more detail:

• Hardware architecture — MCU, sensors, actuators, power, buses
• Firmware architecture — code structure, modules, timing
• Connectivity architecture — networks, protocols, APIs
• Documenting your design — diagrams, BOM, requirements

The four layers

In backend or front-end development, "architecture" often means services, APIs, and databases. In embedded work, architecture spans four layers that you design together:

A good architecture answers three questions before you solder or upload:

1. What hardware is on the board, and how is it powered?
2. What software runs on the MCU, and in what order?
3. How does the device communicate with the outside world — and how do you verify that it works?

Not every project needs all four layers. A bare-metal LED blinker has physical and firmware layers only. A connected sensor node adds connectivity and integration. Decide early which layers your project actually needs.

How the layers connect

Data and control flow through the stack in a predictable direction:

1. Sensors produce raw electrical signals on the physical layer.
2. Firmware reads those signals, applies your rules, and drives actuators.
3. Connectivity sends summaries or events outward, and may receive commands back.
4. Integration defines what those messages mean to a backend, mobile app, or other device.

When something fails, a clear architecture tells you which layer to inspect first. A stuck LED is often firmware or wiring; missing cloud data is often connectivity or API design.

Worked example: room monitor

A small environmental monitor shows how layers fit together:

Application rules: sample every 60 s; if humidity exceeds a threshold, set the status LED and include a flag in the JSON payload.

Safe default: LED off and sensor polling paused if Wi-Fi is down for more than five minutes (configurable).

Your project may add actuators, a local server role, or MQTT instead of HTTP. The method stays the same: define layers, assign pins, split firmware modules, document everything.

Relevant topics

• Hardware architecture
• Firmware architecture
• Connectivity architecture
• Documenting your design
• Basics of electronics
• Lab tools for prototyping

Starting points

1. Draw a block diagram on paper — MCU in the centre, inputs on one side, outputs on the other, external systems above or below.
2. Decide which layers your project needs before buying parts or writing code.
3. Read the layer articles in order: hardware → firmware → connectivity → documentation.
4. List requirements in plain language (what must the device do?) before choosing components.
5. Prototype one layer at a time — prove sensors work on the bench before adding network code.

Focus points

• Architecture before integration — agree on pin map, data flow, and state machine before combining all modules.
• Start simple, add layers — prove physical + firmware layers before adding cloud connectivity.
• Document as you build — update the pin map and wiring diagram when wiring changes, not at the end.
• Safe defaults — define what actuators do when sensors fail or the network drops.
• One layer per debugging step — do not change wiring, firmware, and API contracts all at once when troubleshooting.

Key points

• Embedded system architecture spans hardware, firmware, connectivity, and documentation.
• Not every project needs every layer — match the architecture to the problem.
• Each layer has a dedicated article in this section with practical guidance for students.
• A block diagram plus pin map is enough to start; add detail as the prototype grows.
• When something breaks, use the layer model to narrow down where the fault lives.