An insider's view of the 2008 Embedded Market Study

9/10/2008 4:25 PM EDT

Perhaps the reason why chip is so important is because of the peripheral mix available on a particular chip - E.g. the number of counter-timer channels available could be crucial to somebody off-loading the waveform-generation portion of a BLDC motor-control algorithm onto hardware?

9/10/2008 4:42 PM EDT

It is interesting how "ecosystem" has been a concern right from the beginning! For example, search for "system concept" or "concept" in this interview with Masatoshi Shima: http://www.ieee.org/portal/cms_docs_iportals/iportals/aboutus/history_center/oral_history/pdfs/Shima197.pdf

2/13/2009 6:52 PM EST

The following was e-mailed to Richard Nass on 12/29/08:

Richard,

I just read "An Insider's view of the 2008 Embedded Market Study" (Embedded Systems Design, September 2008, pages 18-26), and have a few comments to offer.

Figure 1: This never changes, because the business people will always squeeze engineering until the wheels fall off. The business people, being unversed in engineering, know no other way to discover what's possible. And debugging difficulties are always a large part of the problems with keeping within schedule and budget. Exceeded only by unrealistic expectations.

Figure 1(a): It would be interesting to know what "none of the above" included. Clearly, the question needs work, as it missed ~60% of the story. The form needs a way to enter free text so responders can tell us what's missing.

Figure 2(b): On UML, I have the opposite reaction to Michael Barr. I read the very low uptake of UML as the result of developers (and their bosses) voting with their feet on the cost-benefit ratio of UML. I've seen many other well-touted and/or mandated methodologies and languages fail in the same way, and for the same reason.

If mandates were the answer, Ada would be Queen and ISO/OSI would be
King.

Figure 3(a): Nor have source-code analysis tools proved all that useful in practice, with the possible exception of lint. The classic problem with analysis tools is floods of false alarms, which take significant effort to assess. Another classic problem is false negatives - problems not caught, despite the considerable effort.

What is almost universal and very useful is to require a clean compile and link before proceeding, but this is not what people mean by the term "source-code analysis tools", even though that's exactly what's being done.

Figure 3(b): As for Test Tools, it does not follow that because people don't buy test tools that no test tools are used. Most people roll their own, and always have, by one name or another. The COTS tools tend to be too generic to be cost effective in any specific application domain, and it's pretty easy to write one's own tools using script languages and bits of C/C++.

Figure 3(c): Oscilloscopes are hardly a "distant third" in the pecking order of tools. In round numbers, compilers, assemblers, and debuggers are mentioned by one half of the respondents, scopes are mentioned by one third of respondents, IDEs by about one quarter, and so on. I was surprised that scopes outranked IDEs, for one thing. Perhaps a better dichotomy would be software tools versus hardware tools. In any event, what's distant are all those thing with less than 10% of responses.

Figure 4: In-house code reuse has always been practiced, long before code reuse became a theology. And design reuse long preceded code reuse, as code developed in the days before floating-point hardware became common generally could not be ported without re-coding to match the fixed-point scaling used in the next project. This was a consequence of the small, slow computers of that day, where one had to optimize the scaling of fixed-point variables on a project-by-project bases.

I first ran into this reuse issue in the late 1970s, when my then project manager called us all together to hear about this new cost-saving approach, code reuse. It died in its crib when we realized that we could not reuse even a Sin routine. Because everybody had different scalings and accuracy requirements, every project had developed their own trig function library. What was reused was the general design (usually table lookup plus interpolation), the flowchart, and the documentation, but the code was new each time.

Figure 5(a): A plot of *achieved* median time-to-market of projects (stratified by project size) versus date of inception would be useful. My sense is that this has hardly changed over the years. The good news is that the project sizes have increased by a factor of about ten over the last three decades. When I started in the 1970s, 100,000 lines of code was considered large for a realtime system, and much of this was assembly language. Now days, large projects are of order 1,000,000 lines, the bulk being C/C++. The human effort per line of delivered working source code (regardless of language) has not changed much over the years. Instead, a larger fraction of system complexity is in the software.

Of course, people have many definitions of "realtime", with characteristic response times ranging from microseconds to minutes, so one must always ask a few questions to nail down their definition of the term. The systems I have worked on have had critical-path response times of tens of microseconds to a millisecond or so.

Figure 5(b): A simpler explanation for the low score of "Professionalism and standards" may be that nobody quite knew what to make of the term, and so either didn't answer or provided essentially random answers. Note that the response rate is about half that of other questions. Nor are "professionalism" and "standards" related concepts, making it even harder to parse the combined term.

Figure 6: The reason that "OS takes too much processor power" has declined as a reason to avoid the OS is very simple - even cheap processors are so much more powerful than before that one can now afford to waste some CPU on the conveniences of an OS.

In the 1970s there were roughly five categories of operating system, sorted by the log of response time. The quickest had typical claimed response times of 1-10 microseconds (these were not really operating systems, but never mind). The other regimes were 10-100 uSec (typical of small RTOSs), 100-1000 uSec (typical of large RTOSs and process-control midicomputers), 1-10 millisecond (typical of general-purpose midicomputers), and 10-100 mSec (typical of UNIX boxes used for lab automation, and other non-realtime computers).

In the 2000s, thirty years later, these same categories largely endure, except that the fifth (10-100mSec) has vanished, and the first (1-10 uSec) now has real RTOSs in it. Now, by Moore's Law, in 30 years computers have become 2^(30/1.5)= ~10^6 times faster, so why didn't the above categories simply change from microseconds to femtoseconds? The short answer is that the core requirement of realtime is to keep up with the real world, and the real world didn't get faster. So the added CPU power was instead spent on conveniences like fancy operating systems and TCP/IP networking and GUIs and so on.

Figure 7: I'm not sure I believe that use of operating systems has declined, and the stated decline rate (13% in 4 years) is too slight to be reliably measured by such a survey. More likely, there has been no change over the four years. If plotted on a bar chart (like the other figures), this becomes immediately apparent.

Figure 8: I think the reason Figure 8 ended up as a head-scratcher is that the wrong questions were asked. The main reason to use an OS (commercial or not) is to cut time to market (and development expense and risk) by reusing a major lump of infrastructure, versus building it from scratch one more time. However, use of any OS exacts a price in size, performance, and functionality compared to code custom designed for a specific purpose. If one cannot afford the added overhead of an OS, then one rolls ones own on-the-metal code. Production volume weighs heavy in the decision. If the product will be made by the millions, every resistor counts, development cost is amortized over millions of units, and use of an OS is unlikely. If the product will be made by the tens, development cost and schedule risk are paramount, and an OS will most likely be used.

Figure 9: I would suggest that one disregard Figure 8. Figure 9 looks plausible to me, although my personal ranking is a bit different. In particular, I would rate tech support far higher. And again, production volume matters a lot. If one is making a few systems, OS purchase price is far less important (if the OS sufficiently reduces development effort) than if one is making millions of units.

Figure 10: Who picks the OS is a fraught issue for sure, and the process was different on every project I have ever been on. Until C/C++ won the day, only picking an implementation language was a bigger fight. Lately, in the systems that I have been involved in, what has been chosen was the main platform (Sun, SGI, IBM, et al), and the OS was always a UNIX dialect (including Linux in non-realtime areas like displays), with traditional RTOSs (VxWorks et al) used to interface big boxes to special hardware.

Figure 11: I always wonder how well outsourcing hardware and software development can work, as it's hard enough to get development right even under the best of conditions. But again it depends a lot on volume, and also on product complexity. And of course outsourcing development to China often results in the creation of a competitor.



It would be useful to stratify responses by the log of production volume and by the log of product size in lines of code. Log of critical response time could also be used, but this may not be as informative as it once was, so long as projects where minutes are OK are excluded.

I no longer recall the survey in detail, but it is very useful to provide a place to enter free text comments. For one thing, this allows one to know how the questions are being read, and also if they harbor an unspoken but incorrect assumption.


Joe Gwinn