There are two different types of people who will end up at this page. The first is someone who needs a quick definition of embedded systems, and, because I’m nothing if not accommodating, here’s a definition for that type of person:
Embedded systems are software products that run on constrained hardware inside a physical device. These systems are designed to survive on their own, as they are deployed to environments that preclude human intervention, and their life-cycles are fundamentally different than those of more general software products.
The other type of person who will end up at this page is open to being taken on a journey, and is excited to learn COOL ANIMAL FACTS in service of a definition. It is to that type of person that I dedicate the remainder of this article.
The animal kingdom is a fascinating study in what it means to be baby. Sparrows, along with the rest of the passerines, are altricial, meaning that they require a lot of care after hatching. They come out of the egg tiny, featherless, eyes closed, and floppy, which are all characteristics that a stoat might find more than a little enticing.
Compare that minuscule nugget with, say, a giraffe. Giraffes are precocial, meaning that their young require far less care. A recently birthed calf will survive a six-foot drop and be standing and nursing within an hour. Within a day it will be running with the herd. After a full week it will have its CPA license and be committing tax fraud.
Extremely precocial species, like rattlesnakes, offer their young no food at all. A newly born1 snake is loaded with both venom and hunting instincts. The neonates will hang around the mother for a week or two until their first shed, but will hunt for themselves from birth using their already-developed heat-sensing pits to track prey; the mother only offers minimal protection from predators that might be attracted by birthing scents.
Your software product falls somewhere on a line between precocial and altricial, and where it lands depends on what kind of parent you plan to be after its release. Can you let your product do its own hunting on day one, or do you need to force-feed it mashed beetles and keep stoats out of the nest?
What are “embedded systems”?
When trying to get an intuitive sense of what an embedded system is, it’s easy to be distracted by the very real, very loud signal of scarcity: these are systems with too little RAM, too little CPU, too little power, too few features of modern programming languages. Let’s take that as a given without letting it take center stage.
Embedded systems are software products that run on minimal-resource, sometimes custom-created circuit boards inside a real, physical device. These systems often have a hard constraint, such as minimal power consumption (is it operated by coin-cell battery?) or size (does it have to fit under a human collarbone?), and typically you have to manage both a software and a hardware product lifecycle. On our altricial/precocial axis, embedded systems can fall anywhere between kiwis and hares, which is the single weirdest clause I’ve ever written.
Kiwis are precocial but costly. The kiwi egg can be anywhere from 15 to 25 percent the mass of the mother. It grows to a size that requires that mom go without food, as her insides simply can’t contain both the egg and a meal. Once hatched, the infant kiwi is fully feathered and bright-eyed, and will coast for days on the yolk still in its body. It will be able to forage on its own when the yolk is used up.
Kiwi systems are large-effort-up-front products that are self-contained and hardened. Success hinges on the quantity and quality of work put into them prior to release, and there are no do-overs or takebacks. Medical implantables, infusion pumps, and engine control units in cars are things that cannot fail without causing real harm, and you can’t easily recall, say, a pacemaker. You will invest a lot of effort before release to make sure the product is correct, safe, and resilient to failure, because once hatched that kiwi is gone and you don’t get to parent it.
Hares2 are precocial but less costly. The mother drops3 two to four leverets, three or four times per year. These infants are furred, wide-eyed, and scampering on their own almost immediately, counting on mom once a day for a few minutes of milk. After that they’re independent: hare today, gone tomorrow.
Hare systems are disposable sensors and home automation devices like connected lightbulbs, faucets, thermostats, and so forth. Most of the consumer IoT (Internet of Things) products you may be familiar with live here. These are systems that have upfront investment, but the young products still have a thin channel to get updates they might need to thrive. Many Hare products are constrained by per-unit cost, or bill of materials (BOM), so the product can be competitively priced. Often the hardware and enclosure are designed before the software side gets started. It’s hard to add features after-the-fact when there’s only 3KB of space left on the device because the BOM couldn’t justify the cost of the upgraded flash chip.
How embedded systems are different from web applications
Let’s take a step back and look at an altricial software product for comparison. I’ve already mentioned how sparrows hatch as pinky-sized, bald, and blind; let’s run that forward a bit. After about a week they’ll open their eyes and start to grow pin feathers. It only takes another couple of weeks before they fledge and start taking care of themselves. They’re still going to hang around their parents4 for a few more weeks as they hone their foraging and flight skills; then it’s off to make a name for themselves.
Sparrow systems are the modern, get-it-out-and-iterate products that are perfectly exemplified by web-based applications. They require a quick initial delivery in the form of an MVP5, and there are many feedings from bird-mom when customer feedback drives new features or bug fixes.
This supportive environment is exactly what is lacking in the Kiwi and Hare systems, and it’s the reason altricial systems are capable of incredible growth. A sparrow emerges from its egg quite floppy, but it grows into a beautiful, flying, singing creature; a giraffe will grow up to be a bigger giraffe. No matter how successful your Kiwi or Hare products become, you’ll never be able to add a temperature-sensing feature if they didn’t ship with a thermometer on board.
IoT products have their own Sparrow system riding alongside the Hare system: the cloud infrastructure that the device connects to. The altricial nature of cloud development means you can add reports, features, and interactions in your own time. But your cloud updates can’t change the contract between cloud and device. Someone out there has one of your locks sitting in a drawer, unpowered and unable to receive updates. If that lock is put on their front door in a year it still has to work. Otherwise that’s a very angry phone call.
Why embedded development is difficult
Have you ever hand-drawn a deeply hierarchical state machine diagram that covers every possible flow through your software, covering entire office walls? Do you long to sit in a room for hours at a stretch with other engineers and daydream catastrophes that may befall your software, up to and including “what if a cosmic ray flips a bit somewhere in RAM”? Have you often dreamed of developing software on experimental hardware where you can never truly know if a defect is due to your software, the new iteration of the hardware, or both?
Then you are a weirdo. No, that’s not nice. Backspace backspace backspace. Then you might enjoy embedded software development!
Typically a developer doesn’t have to worry about managing lower-level concerns because the operating system tends to take care of them. For example, if I screw up an array index on a desktop machine, the process will segfault and control will be returned to the terminal (or whatever process spawned my application). That’s the operating system watching your back. In embedded space, where operating systems are drastically minimized or missing altogether, segfaults can just … stop execution. Forever. With no recovery, unless the user notices and power-cycles, if that’s even a possibility. Thus we have “watchdog timers”, hardware-level monitors that the software needs to poke occasionally or risk the watchdog barking (i.e. soft-resetting the device).
The “no recovery” diagnosis isn’t just confined to issues that can be mitigated with a watchdog timer. Imagine releasing an update only to find that, oopsie, you left in a debug check that fails and now the application crashes during startup. On the desktop it’s inconvenient but not impossible to fix: ship a new installer that corrects the issue, or at worst ask the user to uninstall through the operating system and then reinstall with the new installer. Easy peasy6. On embedded devices, though, you often have to write your own software update function as part of your embedded application, so if the device doesn’t start up all the way, it can’t get to the software update feature. Which means your meticulously crafted device is now a poorly made brick, and potentially a whole fleet of bricks, depending on how many units are in the field and how quickly you are able to ship a fix.
And, of course, developing on a moving hardware target can be a bottomless pit for money and time. Unless your teams are structured to make collaboration across hardware and software as frictionless as possible, a single defect can take weeks to correct. Software thinks it’s hardware’s fault; hardware thinks it’s software’s. Each volley launched in that battle can take days to resolve, and even then it rarely resolves to a clear picture with obvious next steps. Then the negotiation of scope. Then the implementation and re-release, during which time the other team has also introduced changes which themselves can introduce more defects, or make it impossible to tell if the original defect was fixed in the first place. Pretty soon Q3 is over with your product unshipped. You gaze upon your two dozen revisions of prototype boards and two engineering teams bloodied and covered in solder, and weep.
Getting help with embedded and IoT systems
SEP has decades of experience raising kiwis, hares, sparrows, and myriad other animals, which is a sentence I’m very excited to expose to search engine crawlers. From tractor displays to infusion pumps, we’ve delivered them all. Even the kitchen sink, as part of a whole-home smart water product and the cloud architecture that supports it. If you’re planning your parenting strategy for an upcoming critter, or if you have a warehouse full of bricks that look suspiciously like they used to be door locks, our embedded engineers would love to talk.
✨ AI Post Recap
Embedded systems are software products that run on constrained, often custom hardware inside physical devices. Unlike web applications, which ship early and improve through continuous updates, embedded products range from fully sealed at release (medical implantables, engine control units) to lightly updatable (consumer IoT devices), so most of the engineering investment must happen before launch. That fixed-at-birth constraint is what makes embedded development uniquely difficult.
What is an embedded system? An embedded system is software that runs on minimal-resource, sometimes custom-created circuit boards inside a physical device. These systems face hard constraints such as power consumption and size, and they must run reliably in environments where no human can intervene.
How are embedded systems different from web applications? Web applications can launch as a minimum viable product and grow through frequent updates. Embedded systems must be largely correct at release, because devices in the field often have thin update channels or none at all, and hardware capabilities are fixed once the product ships.
Why is embedded software development difficult? Embedded devices often lack an operating system to catch failures, so a crash can halt a device permanently. Update mechanisms must be built into the application itself, and developing against evolving hardware makes defects hard to isolate and slow to fix.
- Rattlesnakes are viviparous, meaning they give live birth to their young. ↩︎
- ‘Hares’ being the “I’ve been through An Ordeal and come out the other side tougher, leaner, and slightly haunted” cousin of the rabbit: different species entirely, far less cuddly. ↩︎
- ‘Drop’ is an instructive word here, as there’s no burrow or warren; they’re basically shoved out of a moving car onto the highway, which goes a long way in explaining their slightly haunted vibe. ↩︎
- … for entirely bird-related reasons, although the state of the economy and housing market certainly don’t help. ↩︎
- “Minimum Viable Passerine” ↩︎
- Here, “easy peasy” should be taken to mean something like “solvable yet unpleasant”, but that doesn’t rhyme. ↩︎
