Making embedded systems that are reliable, secure, and maintainable
Why making embedded systems is different
Making embedded systems is not a scaled-down version of software development. The product has to control real hardware, meet timing limits, survive power loss, operate within memory and energy budgets, and remain serviceable after it leaves the lab. A reliable embedded design starts with requirements and risk, then connects hardware selection, firmware architecture, verification, security, manufacturing, and long-term maintenance into one workflow. The first prototype should be treated as evidence for design decisions, not as the architecture itself. For more coverage of smart hardware and firmware topics, visit the Embedded Systems section.
The central challenge is that embedded failures often cross boundaries. A timing bug can look like a sensor problem. A weak update process can become a field security issue. An undersized memory map can force risky late-stage rewrites. Good embedded engineering reduces these surprises before they reach production.
Start with requirements and risk before selecting parts
The first design decision should not be the microcontroller. It should be the product behavior. An embedded system needs functional requirements, non-functional requirements, environmental limits, safety assumptions, cybersecurity expectations, and service requirements. These points determine whether a simple bare-metal loop is enough or whether the product needs an RTOS, secure boot, external memory, hardware cryptography, redundancy, or embedded Linux.
Define timing, power, and operating conditions
Timing requirements should be measurable. Instead of saying the system must respond quickly, define response time, sampling frequency, interrupt latency, jitter tolerance, startup time, sleep current, and recovery behavior after brownout. Power requirements should include active, idle, sleep, and worst-case radio or actuator states. Environmental requirements should cover temperature, vibration, humidity, electromagnetic exposure, ingress protection, and expected installation conditions.
Map safety and compliance expectations early
If a device can affect human safety, equipment protection, transport, medical use, industrial control, or public infrastructure, the team should identify the applicable standard before the architecture is frozen. IEC 61508-3:2010, for example, addresses software requirements for safety-related electrical, electronic, and programmable electronic systems and emphasizes lifecycle activities during software design and development. MISRA C:2023 is commonly used as a C language guideline for critical systems. These references do not certify a product by themselves, but they influence traceability, coding rules, tool qualification, testing depth, and documentation.
Plan cybersecurity as a requirement, not a feature
Connected devices now face stronger security expectations from customers and regulators. NIST IoT guidance discusses capabilities such as device identification, secure software update, data protection, cybersecurity state awareness, and documentation across the device lifecycle. In Europe, the Cyber Resilience Act entered into force on December 10, 2024, for many products with digital elements sold in the EU market, while the UK PSTI product security regime came into force on April 29, 2024, for many consumer connectable products. For engineering teams, the practical message is clear: updateability, vulnerability handling, and secure defaults should be designed before production hardware is committed.
Choose hardware with firmware in mind
Hardware selection is often treated as a bill-of-materials decision, but the lowest-cost part can become expensive if it complicates firmware, testing, updates, or sourcing. The processor, memory, clocks, power tree, sensors, radios, debug access, nonvolatile storage, and boot architecture all affect software risk.
| Decision area | What to check | Risk if delayed |
|---|---|---|
| Processor class | MCU for deterministic control, MPU or embedded Linux for richer networking, UI, or application isolation | Architecture rewrites when performance or memory is insufficient |
| Memory margin | Flash, RAM, stack, heap, logs, certificates, file system, and future update space | No room for security patches or new features |
| Boot and update path | ROM bootloader, rollback strategy, signed image support, recovery image, and storage layout | Unrecoverable failed updates or insecure field changes |
| Debug and test access | JTAG or SWD access, production lock policy, boundary scan, test pads, and serial logs | Difficult factory diagnostics and weak post-production controls |
| Supply and lifecycle | Component availability, second sources, package stability, and vendor software support | Forced redesign during the product life |
As a practical rule, choose parts that make the normal engineering path easier. A device with enough RAM for diagnostics, enough flash for two firmware images, reliable vendor documentation, and accessible trace tools may reduce total project risk more than a lower-cost alternative with limited support.
Build firmware architecture for change
Embedded firmware should separate hardware details from product behavior. A maintainable structure usually includes a board support package, hardware abstraction layer, device drivers, middleware, application services, and product logic. This separation allows teams to test application behavior without real hardware, replace sensors or radios with less disruption, and maintain multiple board revisions from one codebase.
Bare metal, RTOS, or embedded Linux
Bare-metal firmware is suitable for small systems with simple timing and limited concurrency. It can be efficient and easy to understand when the event flow is clear. An RTOS is useful when the system has several concurrent tasks, communication stacks, timeouts, and background operations. FreeRTOS documentation describes it as a real-time operating system for microcontrollers and small microprocessors. Zephyr Project documentation describes Zephyr as a small-footprint kernel for resource-constrained and embedded systems, with board support, device drivers, Kconfig, and devicetree-based configuration. Embedded Linux is usually chosen when the product needs high-level networking, complex user interfaces, large storage, container-like separation, or extensive existing software packages.
The wrong choice is rarely obvious at the beginning. A simple device can become complex after adding wireless connectivity, encryption, logging, cloud provisioning, and over-the-air updates. Teams should make the operating model explicit: what must be deterministic, what can be asynchronous, what must survive reset, and what must be independently updateable.
Use interfaces that can be tested
Firmware interfaces should be small, clearly named, and designed around behavior rather than registers. For example, an application module should request a measurement from a sensor service instead of directly manipulating an I2C peripheral, unless the product is extremely small. This approach makes it easier to run host-based unit tests, use simulated inputs, and verify error handling without waiting for every hardware revision.
Make verification a design activity
Late testing is expensive in embedded projects because defects can involve hardware, firmware, timing, and manufacturing assumptions at the same time. Verification should begin when the requirements are written. Each critical requirement should have a verification method: inspection, analysis, unit test, integration test, hardware-in-the-loop test, environmental test, security test, or field monitoring.
| Verification layer | Purpose | Example |
|---|---|---|
| Static analysis | Find coding defects, undefined behavior, and rule violations before runtime | MISRA-oriented checks, compiler warnings, data-flow analysis |
| Unit testing | Verify pure logic and boundary conditions | Parser tests, control algorithm tests, state machine tests |
| Integration testing | Verify drivers, middleware, and task interaction | Sensor readout, radio reconnect, storage wear behavior |
| Hardware-in-the-loop | Exercise firmware on target hardware with controlled stimuli | Power cycling, fault injection, timing measurements |
| Field diagnostics | Support maintenance after shipment | Version logs, reset reasons, health counters, update status |
Traceability matters most when the product has safety, compliance, or long service-life requirements. A clear link between requirement, design decision, code change, test result, and release version helps teams answer a difficult question later: what exactly changed, and how do we know it still works? See also: BUYING GUIDES.
Security and update paths cannot be added at the end
Security is easy to weaken when it is treated as a final checklist. A practical embedded security plan starts with a threat model: who might attack the device, what access they may have, what assets matter, and what happens if the device fails. The answer may be different for a wearable sensor, a smart lock, an industrial controller, and a connected medical accessory.
Core design controls often include secure boot, signed firmware, rollback protection, protected key storage, least-privilege tasks, locked debug interfaces in production, encrypted sensitive data, rate limiting, secure provisioning, and a documented vulnerability response process. NIST SP 800-213A describes the need for IoT device software to be updateable by authorized entities through a secure and configurable mechanism. NIST SP 1800-36, finalized in 2025, focuses on trusted network-layer onboarding and lifecycle management for IoT devices. For product teams, these ideas become concrete engineering work: authenticate firmware, protect credentials, design recovery modes, log security-relevant events, and make support periods visible to customers.
Software bills of materials can also support maintenance. An SBOM does not automatically make a product secure, but it gives teams a way to know which open-source libraries, protocol stacks, and vendor components are in each firmware release. That knowledge becomes valuable when a vulnerability is disclosed months or years after shipment.
Move from prototype to production deliberately
A prototype proves that a concept can work. A production design proves that many units can be built, programmed, tested, updated, diagnosed, and supported consistently. The transition should include manufacturing test firmware, calibration procedures, serial number handling, configuration management, production key injection, final debug-lock policy, and a clear method for recovering failed units.
Documentation is part of the product, not a side task. At minimum, the engineering file should capture requirements, architecture, interfaces, memory map, power states, boot flow, update process, known limitations, release notes, test evidence, and lifecycle assumptions. For connected devices, customer-facing documentation should explain security update availability, reset behavior, account or credential handling, and safe disposal or transfer of ownership where relevant.
Maintainability also depends on version discipline. Firmware, bootloader, hardware revision, configuration data, calibration data, cloud protocol version, and mobile app compatibility can drift apart. A robust embedded system reports these versions clearly and stores enough diagnostic information to support remote triage without exposing sensitive data.
A practical workflow for making embedded systems
- Write measurable requirements. Include timing, power, environment, safety, security, manufacturing, and maintenance needs.
- Choose architecture before components. Decide whether the system is bare metal, RTOS-based, or Linux-based, then select parts that support that plan.
- Design the boot and update strategy early. Reserve memory for recovery, rollback, certificates, logs, and future growth.
- Separate hardware access from product logic. Use drivers, service interfaces, and configuration files to reduce coupling.
- Automate repeatable tests. Combine host tests, static analysis, target tests, and hardware-in-the-loop checks.
- Document traceability and release evidence. Link requirements, code, tests, known issues, and shipped firmware versions.
- Plan post-release support. Define update windows, vulnerability intake, spare component strategy, and end-of-life communication.
The strongest embedded teams do not wait for a perfect specification, but they do keep decisions visible. When assumptions are recorded, tested, and revisited, the system is easier to adapt as hardware, firmware, security expectations, and market requirements change.
Frequently asked questions
What skills are needed for making embedded systems?
Core skills include C or C++ programming, digital electronics, microcontroller peripherals, debugging, real-time design, communication protocols, power management, testing, and security basics. For larger products, knowledge of RTOS concepts, embedded Linux, manufacturing test, and compliance documentation becomes important.
Should a new embedded product use an RTOS?
Not always. A bare-metal design can be better for simple, deterministic products with limited concurrency. An RTOS becomes useful when the device has multiple tasks, communications, scheduling needs, timeouts, and background services. The decision should be based on measurable complexity, not trend or preference.
How much memory margin should an embedded system keep?
There is no universal number. The margin should account for stack growth, diagnostics, protocol updates, cryptographic material, logs, dual-image updates, and expected feature additions. Safety-related or long-life products usually need more conservative margins because late memory shortages can force risky redesigns.
Why do embedded updates need special design?
A failed desktop software update is inconvenient; a failed embedded update can brick a device in the field. Reliable update design needs authentication, power-failure recovery, rollback rules, version checks, and a safe boot path. Connected products also need a process for security patches after shipment.
