Embedded Software Engineering
Term Paper
By: Teri Williams
CSC532 Fall 2008
Louisiana Tech University
In today’s society, people rely heavily on technology. Whether using a cell phone to
make a call while away from home or driving a car to work, the dependence on
complex systems is prevalent. In addition, the abilities of these gadgets have
advanced exponentially in the past few years, and people have become dependent
on ‘get it now’ features. Now everyday items are expected to perform a multitude of
tasks simultaneously with minimal effort from the user. In order to execute these
functions, these products use software contained in the system packaging. This
computer software, known as embedded software, is written for equipment whose
primary function is not computing; such as cars, cell phones, airplanes, robots, and
medical devices. The market for items with embedded software is growing at an
accelerated rate and it is imperative that designers and developers understand the
challenges of the embedded software development environment in order to meet the
high quality standards on time as end users have come to expect.
The increased demand for embedded software engineers is prevalent globally. The
growth in the embedded software market is steadily increasing, largely due to
advances in consumer electronics, and continued increases in spending for the
military and aerospace industry, industrial automation, and telecommunication
industries (Figure 1). An independent marketing company, Venture Development
Corporation, estimated that in 2004 the market for embedded software reached $905
million, which was an increase of 20.9% over the previous year. They also estimated
the Average Annual Growth Rate (AAGR) of this market would be 16% from 2004 to
2009. (1)
Figure 1: Global Embedded Software Revenue by Application, Source: BBC (4)
Embedded Software Engineering – by: Teri Williams
Page 1
According to the 2007 Japanese software industry survey report, issued from the
Ministry of Economy, Trade and Industry in Japan, 40% of the revenue in software
developments stems from embedded software. The number of embedded software
engineers in 2006 was estimated to be 235,000, which falls short of the required
personnel by an estimated 99,000. (2) In China, 30% of software revenue is realized
through embedded software. Embedded software products provide 35.3% of the
total revenue for the top 100 software companies, while six of the top ten software
companies are dedicated to embedded software. (3)
The British Broadcasting Corporation’s (BBC) research into embedded software
found that in 2004, the United States owned the majority of revenue at 48%, with
Europe, Japan and Asia comprising the remaining percentages (Figure 2). The
annual growth rate in this market was estimated to be 15% for all parties, except for
China which was estimated at 25%. (4) This overall growth trend supports the need
to develop qualified embedded software engineers (ESE).
Figure 2: Global Embedded Software Revenue by Region, Source BBC (4)
Embedded software has specific needs that differ from the normal software
development and poses quite a number of challenges for the software engineer. In
non-embedded software development, the application is developed for computational
machinery, with a known operating system and known hardware that stays constant
during multiple iterations of development. The focus for this engineer is the
application, not the environment. However, the ESE is not so lucky. While the
general concept and design of the hardware and packaging is known, it is not
concrete and most likely will change during development. Added to this, the ESE is
responsible for designing and integrating the operating system into the hardware.
Another issue the ESE must face is that most designs are proprietary and different
Embedded Software Engineering – by: Teri Williams
Page 2
from design to design and very specific to the product. To make everything more
complex, there are timing constraints, limited memory and power use, and many
times concurrent software implementations. (5)
It is important to understand the motivation behind embedded software development.
Unlike traditional software, embedded software is not for resell. It is designed for a
specific purpose designated to a product slated for market. The software is only a
part of the whole concept, and is a sub-process of systems engineering. Many times,
the embedded systems are often systems of systems and are acting together in
larger systems such as the anti-lock braking system in a car. As technologies are
becoming more advanced and interactions among components are more intricate,
current development procedures are becoming ineffective. As of 2003, existing
development technologies did not address specific impacts or allow for customization
in the embedded domain. The software constraints due to hardware and packaging
were usually not considered. These development technologies did not address
specific application to the product domain, such as automotive systems,
telecommunications, or consumer electronics. (6) It is very challenging for ESE’s to
coordinate their sub-process with the mechanical and electrical engineering subprocess. However, the increased complexity of embedded products do not allow for
insular development. The embedded domain needs specially designed development
technologies.
Project MOOSE (2003), a study aimed at improving embedded software
development, was performed by Software Engineering Methodologies for Embedded
Systems as a part of Information Technology for European Advancement (ITEA).
The first report from this project explained why many companies were not using
current development software. The first problem was compliance with legacy
systems. In order to ensure compliance, older components were used with little
additional design or adaptation, which creates a bottom-up approach to design and
most software development tools use a top-down approach. The second problem
was that the design process for interacting components between requirements and
other artifacts was not clear and easy to use. Also, integrating the tools with current
solutions was difficult to accomplish. The third problem was that the complex
environment of the embedded design required experienced and skilled software
engineers, but the development process included shareholders that did not
understand the meaning of formal development languages. Lastly, the embedded
software’s nonfunctional properties were not explicitly stated in the requirements
specification, which can be detrimental if the requirements do not take into
consideration for real-time requirements or power consumption and memory use. (6)
Since this project, the focus on finding a suitable development process for embedded
engineering increased and more solutions were found. However, there were still
problems.
Embedded Software Engineering – by: Teri Williams
Page 3
In recent years, the increased dependence on embedded software to provide a
multitude of functions on a common execution platform, many times with commercial
off the shelf (COTS) hardware has resulted in a variety of system difficulties. Many of
these difficulties are related to mismatched assumptions between system engineers
and software engineers. Many systems faults and failures are not captured by
traditional fault tolerance techniques, which are attributed to a lack of understanding
the impacts of transferring tested software to different runtime architectures and the
complexity of integrating many components into the physical environment and
packaging. One of the causes of this problem can be traced back to improper and
incomplete documentation.
Another source is due to having different parts
integrating together and sharing resources which many times results in mismatched
assumptions in both the functional and non-functional requirements. The lack of
proper system analysis during the design phase is evident as these problems usually
are discovered during integration and testing. (7)
Many of these problems are significant and lead to increased development, which in
the big picture decreases profit margins. The following examples help illustrate the
magnitude of this issue:
a. Mismatched Assumptions: The Ariane 5 is a launch system, manufactured by
the European Space Agency, used to deliver payloads into space. During the
testing phase, the rocket exploded 37 seconds after launch on the first flight.
Upon investigation, it was discovered that a malfunction in the computer
software caused the problem. This “most expensive computer bug in history”
was due to mismatched assumptions about computing precision and
measurement units when the software system was moved from Ariane 4 to
Ariane 5. A data conversion from a 64-bit floating point number to a 16-bit
integer caused a rounding error when the domain value exceeded the 16-bit
capacity. (8)
b. Resource Sharing Errors: Daimler-Benz automotive industries experienced
difficulties with one of their auto model configurations. A shared bus between
the navigation system and proximity warning system occasionally caused a
delayed response from the warning system. (7)
c. Scheduling Issues: The Mars Pathfinder is a spacecraft whose mission was to
take observations concerning the Martian environment. Overall, the mission
was successful. However, the information initially sent from the Pathfinder
reported unexplainable system crashes. Upon many hours of analysis, the
error was attributed to priority inversion. The Pathfinder had an information
bus, which was a shared memory area used for passing information to
different spacecraft components. Access to use the bus was handled with
mutual exclusion locks. To manage the system, a bus management task was
performed regularly, with a high priority. A communications task was assigned
a medium priority. Experimental data was passed and published less
Embedded Software Engineering – by: Teri Williams
Page 4
frequently and so was assigned a lower priority. The problem occurred when
a lower priority task was in progress and a higher priority task came due to run
at the same time the medium task was due to run. The mutual exclusion locks
had issues at this point, causing the medium priority task to interrupt the low
priority task and the low priority task did not complete the release of the lock to
the high priority task. Since the high priority task was deemed time critical and
did not run, after a certain amount of time, the system would determine that an
unrecoverable error occurred and reboot the system. (9)
d. Migration Issues:
When migrating applications to different runtime
architectures and hardware, it was observed that the F16 fighter jet
experienced an unexpected latency leading to instability. This latency
displayed blurred targets on the cockpit display. (7)
What actions should the embedded software industry take to mitigate these issues?
Based on the research articles presented in this paper, the consensus is that
software engineers must be involved in the initial stages of the product development
along with the system engineers and they must be consulted and kept in constant
communication throughout the product life cycle. In addition, a unified and consistent
language is essential to prevent miscommunication and false assumptions. The way
ahead is to standardize development vocabularies and to embrace model base
engineering (MBE) practices.
The International Organization for Standardization/International Electrotechnical
Commission (ISO/IEC) recognizes the need for a standardized vocabulary and is
progressing in standardizing terminology and processes between the system and
software engineering communities. (7)
MBE allows for earlier predictability in the development lifecycle, which can help
alleviate mismatched assumptions, resource sharing problems, scheduling and
migration issues. Traditionally, the system integration was focused on system
engineering with emphasis on the hardware and its operational environment. With
MBE, the focus is on embedded software which is then integrated with its
environment, which highlights the shared computing platform use, multiple
components and multiple tasks. Now, the total system is broken down into software
components, which is logically integrated into the system via real-time tasks. The
runtime architecture is deployed on a common platform within the system packaging.
This process allows the system engineers and software engineers more interaction
and communication throughout the lifecycle. (7)
The engineering models are more than just pictures, they express to all parties
involved, including the stakeholders, the overall process. These models can help
reduce development costs. By analyzing these models and their interaction, risks
Embedded Software Engineering – by: Teri Williams
Page 5
can be identified earlier in the development process and action can be taken to
reduce the risks, lowering the overall product cost. Many model checking techniques
have been shown to easily discover subtle error in the complex environment that was
previously difficult to find during traditional testing approaches. (6) System fidelity is
increased by using quantitative analysis during integration testing. Constantly
updating the models as development progresses within a single modeling package
ensures workability, eliminating additional validation steps, which reduces
development time and costs. Having integrated models provide more flexibility,
ensures intercommunication, and reduces maintenance and evolution costs by
having standardized historical data. Finally, by using MBE, there is minimal
overdesign as each team is not recreating the design, but working with existing
design and integrating it within their part. (7)
The embedded software industry recognizes that MBE development technology has
matured enough to be of benefit. These benefits include: a common modeling
notation, model reuse, improved communications between developers and
subcontractors through model integration ability, analyzable models and analysis
results, a main source model for system architecture, improved system validation. (7)
In addition, the investment in MBE training pays off immensely due to interoperability
and time savings. As these MBE technologies are utilized in industry, user
experience increases as well as the comfort of use. Not only are the benefits of MBE
realized, the development of product standards and historical references are created.
As today’s technology advances, the burden of the embedded software engineer will
not abate. Products will have more features, more integration, and much more
complexity. To mitigate the multitude of development errors experienced in the past
and to ease the workload of the engineer, industry language standards and MBE
should be universally adopted and utilized. The more prevalent MBE becomes in
society, the better embedded software engineers can meet the needs of the industry.
Embedded Software Engineering – by: Teri Williams
Page 6
Works Cited
1. http://cordis.europa.eu/ist/embedded/software.htm.
2. Ministry of Economy, Trade and Industry, Committee of Promoting Embedded Software.
Software Industry Survey Report. Japan : s.n., 2007.
3. Yimei, Kang. A Graduate Program on Embedded Software Engineering in China. s.l. : 20th
Conference on Software Engineering Education & Training, IEEE, 2007.
4. BBC Research, The Hipeac Roadmap on Embedded Systems. European Network of Excellence on
High-Performance Embedded Architecture and Compilation. Chapter 3. Market.
5. Day, Robert. The Challenges of an Embedded Software Engineer. s.l. : Embedded Technology
Journal, 2005.
6. Graaf, Bas. Embedded Software Engineering: The State of the Practice. s.l. : IEEE Computer Society,
2003.
7. Feller, Peter H. ASSIP Study of Real-Time Safety-Critical Embedded Software-Intensive System
Engineering Practices. s.l. : Carnegie Mellon University, February 2008. CMU/SCI-2008-SR-001.
Embedded Software Engineering – by: Teri Williams
Page 7