Software designed
close to the physical system.

Embedded software may directly manage hardware interfaces, events, local processing, communication between components, system state and concurrent tasks. Memory, CPU time, storage, bandwidth and power consumption become architectural constraints rather than resources that can simply be assumed to exist.

Embedded software connects the expected behavior of the product to sensors, displays, controllers, communication modules, memories, specialized peripherals or other microcontrollers. Each interface has its own frequency, data volume, latency and failure modes.

Fixed resolution, graphical resources, memory, input methods and physical usage conditions directly influence interface design. The goal remains the same: present useful information and make important actions understandable without ignoring the limits of the device.

Moving bytes from one device to another is only the beginning. The system must define what is sent, to whom, in which order, with which identity and how failures, retries, fragmentation or temporary disconnection are handled.

Devices may send local data to an API or platform and receive parameters, commands, updates or external information in return. The important design decision becomes the boundary between device software, communication infrastructure and surrounding services.

Embedded systems may run for long periods, be difficult to access once installed or operate where manual intervention is not always possible. Communication failures, unavailable peripherals, invalid data or restarts should not automatically push the product into an inconsistent state.

When a device exchanges information or accepts commands, identity, authenticity, confidentiality and authorization become architectural concerns. Security must be adapted to the capabilities of the hardware and to the actual threats faced by the product.

In embedded systems, resources are design inputs. A feature that appears trivial on a server may require a different architecture when memory, energy, bandwidth or latency are tightly constrained.

Sensors, communication modules, user interfaces and microcontroller generations can change. The objective is not to abstract everything, but to isolate responsibilities that are likely to evolve so future product revisions do not require rebuilding the entire software architecture.

Some systems need experimentation before a final architecture can be justified: communication range, microcontroller performance, interface behavior, resource usage, experimental protocols or cooperation between several devices may all need to be tested in reality.

Reproducibility, configuration, version management, diagnostics, logging, testing and update procedures become increasingly important as a project moves from an experiment to a deployable product.

Embedded expertise can support a complete new product or one specific part of an existing system when performance, communication, architecture or maintainability has become a constraint.