If an embedded system can move while operating, is it still an embedded system, or is it now a mobile device?

This is a question I wouldn’t have even thought to ask except that it randomly came up within the last month and I found myself alone in the answer I gave. I thought, “Yes.” No one else did; they created a separate market for mobile.

Now there are a couple of reasons why mobile might deserve its own market. The most obvious is that the mobile market may have grown so large that it merits its own category. This wouldn’t necessarily say that mobile devices aren’t embedded; it’s just that they have earned their own keyword and hashtag so that you can delve into all things mobile without being distracted by issues relating to other kinds of embedded systems. It would be, in effect, saying that mobile devices are still embedded, but they’ve been granted their own separate corner; they’re a distinct subset of embedded.

The other possibility, however, is that they don’t share the characteristics of embedded systems, that they are in fact technically different. In order to explore that possibility, we have to ask the question, “What is an embedded system?”

We’ve been running stories about embedded systems for well over 6 years now. So… it might seem like it’s a bit late to be asking this question. But, based on some conversations I had in the last couple of years, that question might be harder to answer than you think. Experienced engineers can argue for hours about this. I’ve seen it happen. So let’s start by surveying the differences between embedded systems and… well, non-embedded (which themselves have multiple incarnations).

There are obvious systems that we would all agree are embedded. A printer or one of those handheld thingies that the UPS guys carries or a network router blade or an advanced POS (point-of-sale, not the other POS which, if you aren’t familiar with it, your innocence won’t be shattered by me) can all pretty well be said to be embedded.

Why? Well, because they are all devices that we don’t think of as computers, and yet they use computing technology to accomplish some of their tasks. So, compared to “dumb” versions of a similar device (say, one of those awesome-looking old-school mechanical cash registers), they have software content as well as hardware content.

But, of course, not every system that runs software is an embedded system. Clearly, desktop computers aren’t, at least given how you and I would use them at our desks. There are a number of distinctions that readily come to mind:

• Desktop computers have a more or less regularized architecture (or two of them – even three if you consider Wintel, Apple, and Linux-on-PC). The physical shape may vary slightly, but it’s all about getting the latest versions of everything that goes in a PC into a nice, sleek box or reducing power or weight in laptops, and so forth. And reducing cost.
• Embedded systems have purpose-built form factors; they’re like dogs, with numerous breeds that look completely different. This extends as well to peripherals: connectivity expectations will be determined strictly by the intended function of the system. An industrial control unit may not have a Compact Flash slot – unless the designer specifically intended for programs or updates to be delivered by CF. It’s certainly not likely to have the multiplicity of choices that your average desktop will have.
• Desktops are rich in resources. Memory is cheap (well, until you try to buy some to upgrade an old machine). Processors are big and fast and have multiple cores. Hard disk space is growing by leaps and bounds. Operating systems and software take advantage of this, with bloatware being the rule more than the exception. Applications are overwhelmingly written using object-oriented programming in high-level languages.
• Embedded systems have a huge range of resource limits. On some devices, you may still measure memory in thousands of bytes. A system is unlikely to have a hard disk at all. And the C language reigns, having yielded to C++ only where resources permit and complexity mandates.

But these characteristics are more descriptive of, rather than definitive of, embedded systems.  They almost fit in the “I know one when I see one” school of taxonomy.

There is, however, one critical characteristic that would seem to capture the essential nature of embedded systems as compared to non-embedded: they are intended to do one thing (or a small, well-defined number of things) and that’s it. When the user buys a unit, all of the necessary software is already inside the system, and, updates aside, the user has no further impact on software content.

Desktop computers, by contrast, are “blank slates” when you buy them. (Well, in theory anyway… in real life they are shipped with numerous programs pre-installed that you probably don’t want, some of which may not even operate properly – and you can’t get help because they’re OEM versions and  you’re on your own, and most of which you can’t readily uninstall. But that’s a detail – the machine could be shipped without all the extra “goodies.”) They’re, at their heart, simply computing devices, and you select what computation you want them to do by loading and running the applications of your choice.

This difference is fundamentally distinct from the characteristics we first looked at. Those original ones were based on things like hardware and form factor. This new characteristic has nothing to do with that; it has to do with how the device is used.

So any kind of general-purpose server or desktop, whether operated alone or in a super-computing cluster or in the cloud, would not be considered embedded because it’s not performing a single pre-defined function.

Which raises a thorny question, and this is where we depart the potentially obvious and get to the area where there may be debate. What happens if you have a dedicated function that needs to be performed and the best way to do that is to load specialized software on a desktop machine and then locate it, say, on the factory floor near a machine that it controls?

By the first set of definitions, this would not be an embedded application because it involves a desktop system. But by the last definition, it would be embedded because it’s not used as a general-purpose computer; it’s supposed to do only the one thing. I suspect there’s no “official” answer to this part of the question, but, at the very least, some engineers would consider this an embedded system or application.

So where do mobile devices fit into this? The hardware-related definitions don’t say anything about whether the device can operate untethered or move from place to place or anything like that. The UPS tracking box is clearly a mobile device, but it’s typically considered embedded.

Older cell phones would also qualify as embedded based on the “usage” definition: when you bought a cellphone, the software running internally was completely invisible to the user. The phone made calls, sent texts, accessed the internet, and that was all it could ever do. It just so happened that it used the cellular infrastructure to do that.

Even from a hardware standpoint, different phones were different: they might have different computing architectures, they might use different processors, and they might have different I/O (other than the radio). Here again, they fit the classic hardware characteristics of embedded systems.

That all changed with the app, however. For the first time, the smartphone could act as a general-purpose computing platform on which users could install and run applications that weren’t loaded in the factory. Of course, smartphones don’t fit into the general computing category because they are still highly specialized units. They may be able to run applications, but that’s but a portion of what the unit does; it’s not the sole function in the way that it is with a desktop system.

Tablets have further blurred the lines. They’re like dumbed-down laptops that run the kinds of programs you might find on a phone (only now you can actually see or read what’s going on). They may be connected to the cellular infrastructure, but their main function is no longer to make phone calls (ignoring the inconvenient fact that smartphones do phone calling less than other things). You would look rather silly walking down the road with a tablet held up to your ear.

So both smartphones and tablets violate the use definition of an embedded system. But they’re also not general-purpose computers. They’re something in between. Validating mobile as a separate category.

This still leaves a question around specifically what gets called “mobile.” Is it simply the fact that a device hooks into the cellular infrastructure? Is it that it can communicate with other devices while moving around (in which case a music device with Bluetooth connectivity might qualify)? What about that UPS tracking device, which communicates with the mothership over the air while, in all other regards, acting like an embedded system? The ability to handle apps – which is what really gives mobile its own category – isn’t clearly comprehended in the word “mobile.”

Who knows how decisions get made about which devices get put in which category. Perhaps the mobile market was in fact defined as distinct due to its size and concentration before there were smartphones. But, even if it was, from the advent of the smartphone on, some mobile devices have clearly earned their own niche as neither embedded nor computer. So instead of arguing about whether to create a new category, we can instead argue about which devices on the fringes should be considered embedded and which should be considered mobile.

Photograph ©Andrew Dunn, 5 September 2004
Website: http://www.andrewdunnphoto.com/