Product Engineering & Embedded Software — Firmware & IoT

Embedded software is written to control a specific hardware device. This is different from general-purpose software that runs on a computer or phone. The word 'embedded' means the software lives inside the hardware product itself. It is usually stored in flash memory on a microcontroller or microprocessor and runs when the device powers on. Embedded software controls the hardware's behaviour: reading sensor inputs, making decisions, controlling actuators and outputs, managing power states, and communicating with other devices or cloud services. Devices that run embedded software include thermostats, medical monitors, industrial controllers, automotive ECUs, smart home devices, wearables, industrial robots, and consumer electronics.

Unlike application software, embedded software typically runs without a conventional operating system — or with a minimal real-time operating system. It has strict memory and processing constraints. It must meet deterministic timing requirements. In many cases it cannot be easily updated after deployment, so correctness at the point of release is critical. Embedded software is mainly written in C and C++. Rust is growing in use for safety-critical applications.

Product engineering is the end-to-end process of designing, developing, and maintaining a technology product. It covers the full software stack from conception through to production-grade deployment and ongoing iteration. For hardware products, this typically means all software layers: embedded firmware on the device, cloud backend processing device data, APIs connecting device and application, and the mobile or web application users interact with. For software-only products, it covers architecture, full-stack development, quality assurance, DevOps infrastructure, and ongoing iteration. The key difference from project-based development is continuity. Product engineering means ongoing ownership of the product's quality and evolution — not just delivery of a defined scope.

Medical device software faces regulatory requirements in every major market. In the US, the FDA classifies Software as a Medical Device (SaMD) under the Federal Food, Drug, and Cosmetic Act. The classification — Class I, II, or III — sets the pathway (510(k), De Novo, or PMA) and the level of evidence required. In the EU, SaMD is regulated under the Medical Device Regulation (MDR 2017/745). In vitro diagnostic software falls under IVDR 2017/746. The main software-specific standard across all markets is IEC 62304 — the software lifecycle process standard for medical device software. It defines requirements for development planning, requirements analysis, architecture, detailed design, unit implementation and testing, integration testing, system testing, and software release. ISO 14971 governs risk management for software. Cybersecurity for connected devices is increasingly regulated. The FDA's 2023 cybersecurity guidance and the EU's Cyber Resilience Act both impose specific requirements on networked medical devices.

Protocol selection for IoT devices depends on three constraints: range, power budget, and data rate required.

For consumer products in the home, Bluetooth LE for local control and Wi-Fi for cloud connectivity is the most common combination. For industrial or outdoor devices that need to work without existing network infrastructure, LTE-M or NB-IoT with a SIM is usually the right choice. Thread and Matter are the emerging standards for smart home interoperability. These matter if compatibility with Apple Home, Google Home, and Amazon Alexa is a product requirement.