Embedded systems consist of hardware and software components designed to perform a specific function, and often have real-time and/or reliability constraints which go far beyond everyday computing.
To meet these demands on a hardware level, traditional embedded systems generally incorporate microcontrollers, digital signal processors (DSPs), and/or field programmable gate arrays (FPGAs). With regards to software, different languages or tools are traditionally required to program or configure each hardware element. As a result, traditional embedded design teams require members with a diverse multitude of proficiencies in hardware and software design capable of integrating the hardware and software in typical embedded systems.
With the explosion of embedded devices in the past few decades, many improvements have been made in both the hardware components and software tools. However, despite the innovation and growth of both software tools and hardware components, traditional embedded system design approaches have evolved little if at all and are increasingly proving to be a hurdle. Given the increasingly rapid growth of new standards and protocols as well as growing pressure on design teams to deliver to market more quickly, embedded system design is due for a disruptive change in paradigm.
To better understand the need for a revolution in embedded system design, it’s useful to consider the current process and tools. Based on a recent study of the embedded space by UBM Electronics in conjunction with EE Times and Embedded System Design, there are clearly established roles and processes in embedded system design.
To begin, an embedded system design team is on average composed of 13.5 members, in which 62% are devoted to software resources while the rest are focused on hardware development. This pattern in embedded design team structure and function has been constant over the last half decade.
Looking deeper into embedded projects, 43% are focused on developing something brand new while the remaining 57% are upgrades to existing embedded systems. The primary reasons for an upgrade are for the addition/incorporation of new or different software features and a new or different processor. On average, projects take 12 months to complete and in 2011, a staggering 57% of projects finished late or were cancelled. Furthermore, design teams reported reusing 87% of existing code, which encompasses code developed in house, acquired from open-source work, and/or purchased. These trends in embedded projects have also been extremely consistent year to year for the past half decade.
Beyond the traditional embedded design team and project, it’s also useful to note the typical design process. Once the system architecture is defined based on the specifications for the embedded system, hardware and software design teams generally begin their work separately. The hardware engineers develop the hardware architecture, synthesis, and physical design of the system.
The software engineers work to develop application software, compilers, and in some cases the operating system. As the hardware and software teams complete their work, there is an integration effort in which software drivers are developed to hardware interfaces. This integration effort is an iterative process, often resulting in updates to software drivers and/or hardware interface synthesis.
Given the current state of embedded system design, there is a clear need for change to sustain continued innovation while maintaining quick delivery of products to the marketplace. This need is underscored by the fact that the majority of respondents to the UBM/EE Times survey reported that their job function involves contributing to firmware or hardware and software integration.
With the accelerating growth of advances in hardware technologies and software tools, the challenge posed by integration is set to rise. This challenge, if unaddressed, will result in more expensive end products and can prevent experimentation, growth, and delivery of more innovative designs to the marketplace.
