Embedded Processing

I keep hearing people say that applications are becoming more embedded and that the line between applications and embedded systems is blurring. I think statements like these are a symptom of a lack of a clear distinction of what constitutes an embedded system. I believe the time has come that we should clarify the distinction between embedded and application-level software because we, as an industry, are now more visibly paying a price for this confusion.

An online search using the query "What is an embedded system" yielded a few definitions. The first definition on the list (from BDTI) includes a significant ambiguity. It says that an embedded system is "A system containing a processor where the processor is not generally reprogrammable by the end user. For example, a cell phone containing a DSP processor is an embedded system." The ambiguity is whether the cell phone is an embedded system because it contains a DSP processor, or whether the DSP portion of the cell phone is part of an embedded system within the cell phone.

I highlight this ambiguity because it is not unique to this example; rather it is common in many of the proffered definitions for "embedded system." For example, the Wikipedia definition (as of the time of this post) includes the following statement: "In general, 'embedded system' is not an exactly defined term, as many systems have some element of programmability. For example, handheld computers share some elements with embedded systems—such as the operating systems and microprocessors which power them—but are not truly embedded systems, because they allow different applications to be loaded and peripherals to be connected."

My goal here is to highlight the symptoms of this uncertainty, which is becoming more obvious, and to solicit and establish from both the application-level and the embedded development community the collective wisdom of what is similar and different between these two types of systems. I believe the lack of clarity over what makes embedded systems/processing different from "normal" or application-level systems/processing goes beyond a discussion of mere semantic significance.

I suspect that because there is no clear distinction between the needs of application-level and embedded software that we, as an industry, have assumed that as we continue to solve the development-productivity needs of the application-software development community, we are also solving the development-productivity needs of the embedded development community. I believe we are headed to a growing skills and tools crisis because my personal experience indicates that there are material differences in how each of these types of systems is conceptualized, designed, built, tested, and supported. I am not alone with this observation.

Separate articles recently posted by Jack Ganssle and Mike Anderson touch on how or why universities are not meeting the needs of the embedded community because they are not developing appropriate skills training that would allow graduates to be more productive more quickly when they join the embedded development community. I believe clarifying the salient differences between these two types of development can help solve this condition. Interestingly, robotic studies may provide the push to make this happen, because I think developing functional robotics embodies many of the same skills as embedded design.

The most recent annual Embedded Systems Design survey continues to show that embedded developers feel that the most important improvement needed for their work is better debugging tools. The authors of the analysis of the survey expressed surprise at this result. In contrast, the percentage of embedded developers that said improving programming tools was most important has steadily dropped each of the survey's three years. I believe this disparity is a symptom of the debugging tools including features and innovations that better address the needs of developing and testing application code rather than embedded code (more on this in a future post).

It seems that the needs of the application-development community also overwhelm the focus at multicore conferences, including the Multi-core Expo. A community that uses multiple processors clocked in the GHz range is probably not concerned about the same issues as the community that is using multiple 100-MHz (or slower) processors in its designs. Even a simple appliance such as a washing machine can use three small processors; this is not the same multicore/processor problem that application developers worry about. Based on my recent conversation with Markus Levy, chairman of the Multicore Expo, I expect that the conference will become more relevant to embedded developers.

Another apparent symptom of the ambiguity between application-level and embedded systems is that the differences are a matter of size, response speed, and limited functionality. The major differences between the normal and embedded versions of Windows, Linux, and Java appear to be that the embedded version are leaner, meaner, and faster with fewer supported functions so that they can deliver more deterministic behavior. Are these really the salient differences between developing application-level and embedded systems?

What do you think?

I have tried to identify a number of independent, relevant, and related symptoms of how the ambiguity between developing application-level and embedded systems is directly and indirectly affecting our community. I do not believe this is a complete list. I have four things that I would like to ask you to think about and share by commenting.

1. What other examples of symptoms have you seen where the ambiguity between application-level and embedded designs is causing disconnects in resources, tools, and innovations that embedded developers need to maintain development productivity?
2. Is a clear, unambiguous description of an embedded system a useful tool? I think it would help us to leverage the differences in needs for embedded development from those of application-level designs.
3. Defining the boundaries of an embedded system does not necessarily capture the impact of dealing with real-world inputs and outputs versus user inputs and outputs. I am thinking that distinguishing between human-in-the-loop (application) versus no-human-in-the-loop (embedded) can provide a set of useful care-abouts and needs that can help tool and curriculum developers to better meet the needs of the embedded design community. I ask that you think about these distinctions because I will be addressing them in a follow up post.
4. I think we can have some fun with this exercise and capture subtle, yet important concepts that embody what embedded design is about. Look for a future post where I'll introduce a "You know you're an embedded developer when …" survey.