This first lecture starts from a simple question - what is an embedded system - and builds, step by step, the vocabulary that carries the whole rest of the semester: dedicated functionality, limited resources, real time, reliability and the design trade-offs that tie them all together. By the end you will be able to recognize an embedded system wherever you meet one, and you will understand why it is designed in a fundamentally different way from the computer on your desk.
1The subject and structure of the course6 min
Reach into your pocket. The telephone contains at least five or six distinct embedded systems - the battery controller, the modem, the motion sensors, the audio chip - each running its own firmware, independently of the operating system you see on the screen. The car you came to the faculty in contains at least fifty more. The refrigerator at home, at least one. The thermostat, likewise.
All of these are computers - they have a processor, memory, a program that runs - but none of them resembles, in the way it is designed, the laptop on which you write an essay. This course explains why, and what that difference means in practice.
An embedded system is a computer hidden inside another product, designed to do a single job (or a few, well defined ones) - not any job at all, like a PC. The word "embedded" does not refer to size, but to the fact that the computing system is an integral part of the product, not a product in itself. The user of a washing machine does not know, and does not need to know, that the buttons they press command a microcontroller.
Learning outcomes
- To define an embedded system and distinguish it from a general-purpose computer
- To list and explain the four fundamental characteristics of embedded systems
- To recognize the main fields of application and the requirements specific to each
- To classify an embedded system by complexity, by its real-time constraints and by its power source
- To explain the design trade-offs (performance, cost, power, reliability) and why there is no universally optimal solution
- To describe, at the conceptual level, how embedded systems relate to the Internet of Things, Edge Computing and OTA updates
2What an embedded system is10 min
The essential observation is the one about visibility: in the case of a personal computer, the computing system is the product. In the case of an embedded system, the computer becomes an invisible component, hidden behind the final product. The driver of a modern car interacts with pedals, a steering wheel and a screen - they do not "see" the hundred-odd electronic control units (ECUs) that run the car.
Structurally, almost any embedded system is described by the same four blocks, whatever the application:
| Block | Role | Typical examples |
|---|---|---|
| Processing unit | runs the program, takes decisions | microcontroller, microprocessor, SoC |
| Memory | stores the program and the data | Flash (program), RAM (working data) |
| I/O peripherals | read sensors, command actuators | GPIO, ADC, PWM, timers |
| Communication | exchanges data with other systems | UART, SPI, I2C, CAN, BLE, Wi-Fi |
Depending on the complexity of the application, hardware accelerators, external memories, a real-time operating system (RTOS) or dedicated security modules may be added to these four blocks - subjects you will meet, one by one, in the lectures that follow.
3The characteristics of embedded systems13 min
Although embedded systems cover an enormous range of applications - from a thermostat costing a few euros to the on-board computer of an aircraft - almost all of them share four fundamental characteristics. They are not absolute rules (complex exceptions do exist), but they explain why an embedded engineer thinks differently from a desktop application developer.
1. Dedicated functionality
An embedded system is designed to carry out one or a few well-determined functions - not a varied range of applications, as a personal computer does. This specialization allows the whole system to be optimized: the hardware and the software are chosen to be exactly as much as is needed, with no useless resources, which reduces the cost, the size and the power consumption.
The controller of a washing machine permanently carries out the same functions: it reads the water level sensors, commands the motor, manages the solenoid valves, monitors the washing programme. It does not have - and has no reason to have - a browser, a text editor or games.
2. Limited hardware resources
Most embedded systems run on microcontrollers with resources far more modest than a PC: RAM from a few kilobytes up to a few megabytes, Flash memory that must hold both the program and the permanent data. This limitation forces simple algorithms and careful management of memory and of execution time - one of the most important differences from software development for personal computers.
3. Low energy consumption
Numerous embedded systems run on batteries or other autonomous sources, so reducing consumption is a central design requirement, not a detail of later optimization. The usual techniques: sleep modes, switching off unused peripherals, adapting the frequency of the processor to the real workload. In many modern applications, the system stays "asleep" most of the time and wakes up only for a measurement or a transmission.
4. Reliability and continuous operation
Many embedded systems must run without interruption for long periods, and in industrial, medical or automotive applications a software failure may affect the safety of users, not merely lose some data. That is why reliability is a design criterion as important as performance, and critical fields observe dedicated standards such as ISO 26262 (the automotive industry) or IEC 61508 (critical control systems).
4Fields of application9 min
Embedded systems are present in almost every category of modern technological product. The reason is simple: a great many products need monitoring, control, communication or local processing of information, and these functions are today implemented through dedicated computing systems integrated directly into the product - not through purely electromechanical mechanisms, as a few decades ago.
| Field | Examples | Dominant requirement |
|---|---|---|
| Consumer electronics | smart televisions, telephones, cameras, consoles | cost, user experience |
| Domestic appliances | washing machines, refrigerators, microwave ovens | energy efficiency, cost |
| Automotive | engine ECU, ABS, airbag, driver assistance | functional safety, real time |
| Industrial equipment | robots, production lines, control and monitoring | robustness, availability |
| Medical devices | ECG monitors, insulin pumps, ventilators | reliability, clinical validation |
| Telecommunications | routers, switches, base stations, IoT gateways | availability, low latency |
| Aerospace and defence | on-board computers, navigation, satellites, drones | extreme reliability |
| Internet of Things | smart sensors, smart home, smart meters | low power, connectivity |
The ABS of a car permanently monitors the speed of the wheels and commands the braking pressure so that the wheels do not lock under sudden braking. What happens if the control algorithm reacts "only" a few hundred milliseconds late?
See the answer
The safety function becomes useless: the wheel has already locked, and the car has gone into a skid before the correct decision reaches the brake. It does not matter how correct the decision of the algorithm is if it does not arrive in time - this is exactly why ABS is classified as a hard real-time system: missing the deadline does not merely reduce performance, it cancels the purpose of the safety function.
Notice something common to all the examples above: in every case, the user interacts with the product (the car, the appliance, the telephone) and almost never directly with the computing system behind it. This remains, whatever the field, the signature of an embedded system.
5Differences from general-purpose computers10 min
At first sight, an embedded system and a personal computer look alike: both have a processor, memory, input-output devices, and both run software. The real difference is not in the components, but in the purpose for which they were designed - and that purpose influences absolutely everything else about the design.
| Characteristic | General-purpose computer | Embedded system |
|---|---|---|
| Purpose | running a varied range of applications | running a dedicated function |
| Hardware | configurable and extensible | fixed at the design stage |
| Operating system | Windows, Linux, macOS | bare-metal or an RTOS |
| Energy consumption | high | low |
| Hardware resources | abundant | limited |
| Cost per unit | high | optimized for series production |
| Reliability | important | critical in safety applications |
| Interaction with the user | direct | as a rule indirect |
Match each statement with the category of system it fits better:
6Design constraints10 min
Designing an embedded system is a process of optimization with several simultaneous, often contradictory requirements. Unlike development for general-purpose computers - where the hardware resources can be extended relatively easily - in embedded systems the choice of hardware and the design of the software are closely interdependent.
- Response time. Many embedded systems must react within a well-defined interval of time after an external event (see the ABS example above). Execution time has to be analysed at the design stage, not verified afterwards.
- Energy consumption. For battery-powered systems, an autonomy of months or years depends on sleep modes, switching off unused peripherals and efficient algorithms.
- Cost. At a production run of hundreds of thousands or millions of units, a difference of a few euros per component means significant savings - hence the care with which the microcontroller and the peripherals are chosen.
- Reliability. Systems must keep behaving correctly under difficult conditions of temperature, vibration or electromagnetic interference, observing, in critical applications, standards such as ISO 26262, IEC 61508 or DO-178C.
- Physical size and heat dissipation. The space available in the final product and the heat generated by the components often limit what hardware may be used.
- Cyber security. More and more embedded systems are connected to local networks or to the Internet, so authentication, encryption of communications and secure firmware updating have become standard requirements, not optional ones.
A smart sensor for monitoring an agricultural crop must run for years on a single battery. Which design strategy best resolves this constraint?
See the solution
The microcontroller stays in sleep mode almost all the time and is woken only periodically - for example, once every few minutes or hours - in order to take a quick measurement and transmit the data, returning to sleep at once. Here reducing energy consumption matters far more than maximizing the performance of the processor: a "slower" microcontroller with efficient sleep modes beats a "faster" one that is always awake.
7Classifying embedded systems12 min
The diversity of embedded applications makes a single classification covering every case impossible. In practice, the same systems are grouped simultaneously by several independent criteria - each criterion brings out a different characteristic relevant to the choice of the hardware and software solution.
By hardware complexity
| Category | Hardware basis | Examples |
|---|---|---|
| Low complexity | 8- or 16-bit microcontrollers, limited resources | remote controls, thermostats, simple appliances |
| Medium complexity | 32-bit microcontrollers, multiple peripherals and interfaces | most automotive, industrial and IoT systems |
| High complexity | multicore processors or SoC platforms, running Linux/Android Embedded | infotainment, advanced medical equipment |
By real-time constraints
| Category | What happens when the deadline is missed | Example |
|---|---|---|
| Hard real-time | failure of the system or a dangerous situation | ABS, airbag |
| Firm real-time | performance drops, but the system does not fail | a real-time video stream |
| Soft real-time | the quality of service drops, but operation carries on | a responsive user interface |
By power source
Systems permanently powered from the mains can use more capable microcontrollers, at higher frequencies, with no worry about autonomy. Systems powered from a battery or from autonomous sources (energy harvesting) must be designed from the outset for minimum consumption - the choice of the microcontroller, the operating frequency and the software strategies for saving energy are all influenced by that decision.
The controller of a washing machine may fall into low complexity, with no severe real-time constraints. An ABS controller is hard real-time. Both may use microcontrollers from a similar family - but the requirements of design, testing and validation are fundamentally different.
A real system usually belongs to several categories at once: a battery-powered IoT node is, at the same time, of low complexity, with very low consumption and soft real-time; an industrial controller may be of high complexity, permanently powered, with strict real-time requirements. The classifications above are complementary perspectives on the same system, not mutually exclusive boxes.
8Modern trends and the Internet of Things9 min
Over the last two decades, embedded systems have evolved from isolated devices designed for a single fixed function towards platforms able to communicate, to process large volumes of data and, more and more often, to take autonomous decisions. Four directions dominate the current evolution.
IoT describes the interconnection of physical objects through communication networks. Embedded devices collect information with sensors, process part of the data locally and transmit what is relevant to other devices or to cloud platforms.
Edge Computing and TinyML
As the computing power of microcontrollers has grown, more and more applications run advanced algorithms directly on the device, instead of sending all the raw data to the cloud. This approach, called Edge Computing, reduces latency, cuts down data traffic and allows operation even without a permanent connection to the Internet. A related direction, TinyML, aims at running machine-learning algorithms directly on microcontrollers with limited resources - for example recognizing a keyword or detecting a vibration anomaly, with no need of a connection to a server.
Over-the-air updates (OTA)
Over-the-Air Updates allow the functionality of a device to be improved or its vulnerabilities to be corrected without physical intervention on it - widely used in automotive, IoT and connected industrial equipment.
Cyber security
Connectivity brings risks as well: modern embedded systems must authenticate devices, encrypt communications, protect memory and update firmware securely. In critical applications, cyber security is treated together with functional safety - the two become complementary, not separate subjects.
A weather station uses sensors for temperature, humidity and pressure. The data are processed locally by a microcontroller, and the relevant values are transmitted periodically to the cloud over Wi-Fi or LoRaWAN. The user sees the data in real time on a telephone, receives notifications when thresholds are crossed and can update the firmware remotely, without touching the device physically. This example combines, in a single product, IoT, Edge Computing and OTA.
9Case study: a smart irrigation node9 min
Let us now tie everything discussed so far into a single example, analysed completely: a controller for a smart irrigation system, battery-powered and installed in a greenhouse.
The device measures the humidity of the soil every 30 minutes, opens a solenoid valve if the humidity falls below a threshold, transmits a report once a day to a LoRaWAN gateway and must run for at least a year on an AA battery.
We go through the requirement with each conceptual tool of this lecture, in turn.
| Question | The answer for this system |
|---|---|
| Dedicated functionality? | Yes - a single loop: measure, decide, command the valve, report. No other program ever runs on this microcontroller. |
| Hardware resources? | Deliberately limited - a small-class 32-bit microcontroller, a few KB of RAM. It needs no more. |
| Dominant constraint? | Energy consumption: a year on an AA battery means an average current budget of the order of tens of microamperes. |
| Real-time class? | Soft real-time - a delay of a few minutes in opening the valve produces no failure, merely slightly late watering. |
| Complexity? | Low - a single microcontroller, a few peripherals, no complex operating system (probably bare-metal or a minimal RTOS). |
| Modern trends present? | IoT (reporting to a gateway), possibly OTA for updating the humidity threshold remotely, Edge (the watering decision is taken locally, not in the cloud). |
Notice how one single requirement - "a year on an AA battery" - determined, in cascade, almost all the other decisions: the choice of a modest microcontroller, the classification as soft real-time (because the system can "wait" without danger), the architecture based on periodic wakings from sleep. This is exactly the kind of reasoning that designing an embedded system demands repeatedly - and which you will practise in the laboratory, in the lectures that follow and in every project of this semester.
10Case study: the energy analysis8 min
If the same greenhouse had, instead of a single humidity sensor, a video camera that has to detect in real time the presence of a pest animal and immediately trigger a scaring system, what would change in the table above?
See the answer
Almost everything changes: the complexity goes up (image processing demands far more computing power, probably a SoC rather than a simple 32-bit microcontroller), the real-time class moves towards firm or even hard (too slow a reaction means the animal has already done the damage), and the energy consumption becomes much harder to control - the camera and the image processing cannot stay "asleep" in the same way as a humidity sensor. The one-year battery budget would probably become unrealistic without an external power source.
11Frequent mistakes5 min
- "All embedded systems are 8-bit and very simple." False - the category covers both an 8-bit thermostat and a multicore SoC running Embedded Linux in an infotainment system. The complexity varies enormously with the application. Always classify by the concrete requirements of the application, not by a generic picture in your head.
- "An embedded system never has an operating system." Many run bare-metal, but others run an RTOS (FreeRTOS, Zephyr) or even Embedded Linux - the choice depends on the complexity of the application and on the real-time constraints. Ask yourself rather "what level of temporal determinism does the application need", not "does it or does it not have an operating system".
- "Real time means fast." Real time means deterministic - the system meets a guaranteed deadline, even if that deadline is relatively generous (seconds, not microseconds). A hard real-time system with a 500 ms deadline is not necessarily "faster" than a non-real-time system. Check whether there is a deadline and what happens when it is missed - that decides the classification, not absolute speed.
- "Reducing the cost is always possible without compromises." The cost is directly linked to the hardware resources available; reducing it excessively limits the memory, the frequency or the peripherals, which complicates or even blocks the implementation of the desired software. Treat the four factors (performance, cost, power, reliability) as a system of trade-offs, not as independent targets.
12Summary and glossary5 min
An embedded system is a computer integrated into a product, designed for a dedicated function, not for maximum flexibility. Designing it means, almost always, finding a balance between four factors that influence one another: performance, cost, energy consumption and reliability - and that balance always depends on the concrete application.
13Self-check questions10 min
A few self-check questions, adapted from the corresponding chapter of the book - use them for revision before the laboratory or the seminar.
- What is an embedded system and how does it differ from a general-purpose computer?
- What are the main hardware components of an embedded system?
- What are the four fundamental characteristics of embedded systems?
- Why does energy consumption represent an important constraint in embedded systems?
- What are the differences between hard real-time and soft real-time systems?
- List at least five fields of application of embedded systems.
- How does cost influence the design process of an embedded system?
- What does the concept of the Internet of Things represent?
- What is Edge Computing and what advantages does it bring over processing exclusively in the cloud?
14Where to go next2 min
The next lecture continues directly from here, with the hardware architecture proper: what an embedded computing system looks like on the inside - processing units, the memory hierarchy and the particularities of the ARM architectures used today in most microcontrollers and systems on chip.
For the practical application of the concepts of this lecture, go on to Laboratory 01, where you build a first working embedded system on a Raspberry Pi 5 and measure, concretely, some of the trade-offs discussed here (performance vs. power).