Embedded systems survey uncovers trends & concerns for engineers
Each year Embedded.com's parent company -- UBM -- conducts a survey of embedded developers to learn about their preferences and pain points, design environments and tools, and hardware and software choices. This year's study shows that, while many things remain the same, there are changes afoot in such things as processor size, operating system choices, and developer concerns as embedded development evolves. Added insight into Asian embedded development has also come out of this year's study.
The Embedded Market Study solicits responses from readers of UBM's Electronics brands, including EBN, EDN, EE Times, Embedded.com, and Planet Analog. The survey itself was developed and managed by an independent research company and covers a variety of topics. Findings include types of technology used, all aspects of the embedded development process, IoT emergence, tools used, work environments, applications, methods/processes, operating systems used, reasons for using chips and technologies, and brands and chips being considered by embedded developers. The study is adjusted each year, but many of the questions are repeated in successive studies so that trends over three to five years are revealed.
One of the important changes in this year's study has to do with demographics. Nearly 40% of the respondents reside in the US and Canada, with about 26% each for Europe and Asia. This represents a near doubling of the Asian developers represented, which highlighted some significant regional differences in several areas.
Who are you?
One such difference relates to experience levels. On a worldwide average, the study's respondents have been out of school for more than 20 years. The Asian component, however, is much younger, averaging 12 years out of school. Asian developers also put greater effort than average into maintaining or improving their professional skills, spending more days in career training as well as reading more books and technical journals.
The situation that developers find themselves in is fairly common, however. On average, more than half of current development projects (56%) involve upgrading or adding features to existing designs rather than creating something entirely new. Development project team size (including QA, test, and systems integration engineers) has held steady at around 14 engineers, typically working on at least two projects simultaneously. Engineering resources are split roughly 60-40 in favor of software over hardware. Industrial control is the most common application space teams are working in, followed by consumer and communications, although the IoT has grown substantially since last year (12% to 19%) to round out the top four.
Despite all the labor savings that new tools and products are offering, development teams stand a fairly high chance of missing their schedule. As Figure 1 shows, some 70% of development teams had a development cycle of 12 months or less on their last project, and only 38% of teams finished on or ahead of schedule.
Figure 1. Despite all the efficiency advances that today's tools provide, meeting schedule remains a significant and growing problem. Asked how well their most recently completed project went, respondents gave the dismal report that only one in three met schedule.
And the schedule shortfall has been growing over the years, even though more than half of teams now start their project with an off-the-shelf development board, 36% purchase rather than developing their own hardware, 71% re-use some of their hardware designs, and 86% re-use some part of their previous code. (The most popular language is C, by the way, used by 60% of teams worldwide and 74% of Asian teams.)
As seen in Figure 2, teams worldwide are fairly consistent in how they allocate their time during the development project. After the detailed design effort (about 30% of the time spent), most of the other development energy went into testing and debugging. This breakdown has remained steady for the last several years.
Figure 2. The amount of time spent at each stage of the design process has been fairly consistent over the years and worldwide. Next to the detailed design stage, debugging takes most of the developer's time.
As might be expected from past results and the amount of time dedicated, schedule and debugging are two of the greatest concerns in the development community, affecting one in four teams. Perhaps surprisingly, though, the desire for better debugging tools is ebbing. When asked what one thing they would like to improve in their development activities, only some 18% of respondents pointed to debugging tools. While this is still the leading request, its significance has declined from 29% five years ago. On the rise over that same time period, and poised to take over the top spot among development team concerns, is worry over the team's skill level. The desire for improvements in the team has nearly doubled from 9% to 17% of respondents since 2010.
Despite the consistency in the situation and concerns the embedded development community faces every year, design choices are seeing some slow but steady shifts, as illustrated in Figure 3. The 8-bit processor is not dead, but it is slowly dying. It has declined from 13% to 9% of projects since 2010, and 16-bit processors have also declined in use. The slack is being taken up by 32-bit processors, which have seen steady growth in use, particularly in Asia.
Figure 3. Despite many predictions, the 8-bit processor is still far from dead, although its use has been in slow decline for years. The 32-bit processor is the growing favorite for new designs.
Similarly to the smaller processors, use of commercial and in-house operating systems has been in decline. In their place, open-source operating systems without commercial support are increasingly finding their way into the 60% of embedded designs that use an OS. Unsupported open-source OSes now have a home in nearly 40% of projects, and teams expect to increase that usage. This is the second year in a row that open source took precedence over commercial operating systems in project designs.
Another thing that has been in steady decline is the processor clock speed used in embedded system designs. The average clock speed has slowed from 485 MHz in 2013 to 397 MHz, and nearly half of designs use a clock speed of 100 MHz or less.
These shifts are subtle, in part because of the inertia that development teams have when it comes to making changes. Half of the hardware teams (57% in Asia) and 61% of the software teams used the same processor and operating system for their current project as for their last one. Legacy software and tool compatibility along with the lack of a compelling reason to make a change were the main factors in choosing to stand pat in hardware. When changes were made, more features and better performance as well as improved growth path motivated the shift, which slightly favored changing processor families rather than staying with the same family or architecture. Similarly, the legacy of tools and expertise motivated staying with an operating system while better features and hardware changes motivated most OS shifts. (One in five respondents, though, indicated that the change of OS was dictated, not desired.)
The trends and results covered in this column form only a small part of what the 2015 Embedded Market Study reveals. Which processor family is the most popular? How about the operating system? What is the role of the support ecosystem in these selections? How about FPGAs and DSPs? The survey addresses all these questions and more.
Space doesn't permit me to get into all of the results here, but you will have several opportunities to learn more about the study in the coming months. I will be making presentations on it at the Embedded Systems Conference (ESC) in Silicon Valley in July, and again at ESC Minneapolis in November.
In the meantime, I am open to answering questions regarding the study. Further, I would be interested in hearing your reaction to these results. Right on or off base? Please let me know in the comments section below.