Post on 03-Apr-2018
7/28/2019 trend in embedded software engineering
1/7
0 7 4 0 -7 4 5 9 / 0 9 / $ 2 5 . 0 0 2 0 0 9 I E E E May/June 2009 I E E E S o f t w a r E 19
focus 1
Embedded sotware development has long been
reduced to a purely laborious task, necessary to
implement unctionality such as control algorithms
with programming languages. With embedded sot-
waresincreasing complexity and quality demands,however, sotware engineerings role is becoming
more important.
Sotware development is shiting rom man-
ual programming to model-driven development
(MDD). Here, we identiy specic characteristics
o embedded sotware, describe the paradigm o
model-driven sotware engineering, and describe
challenges and solutions to assure the quality o em-
bedded sotware.
Embedded SotwareDevelopers o modern IT systems use standardized
platorms that provide the basic inrastructure or
service-oriented architectures, distributed systems,
error recovery, and reliability. Several abstraction
layers and common platorms support platorm-
independent and distributed systems. Virtualiza-
tion techniques provide scalability through the dy-
namic scaling o (virtual) hardware platorms, and
live migration and hot-spare hardware increase IT
system reliability.
However, such an approach doesnt t the em-
bedded systems domain. Resource requirements
originating rom cost, energy, size, or weight
constraints demand the ecient use o available
hardware resources. So, heavyweight abstrac-
tion layers, platorms, and virtualization tech-
niques that require many resources or mapping
high-level platorms to concrete hardware devices
arent easible.
The diversity o embedded systems also pre-
vents the creation o a single specialized platorm.
Embedded systems take such various ormsas mo-bile phones, train-control systems based on pro-
grammable logic controllers (PLCs), and glucose
meters. Obviously, no single embedded system
exists. Moreover, embedded sotware is rarely a
stand-alone product; rather, its a single element
in a product consisting o mechanics, electrics
and electronics, and sotware. Embedded system
development always ocuses on the product, so it
must consider various constraints. For one, many
embedded systems are mass-produced products
Over the last 20 years, sotwares impact on embedded system unctionality,
as well as on the innovation and dierentiation potential o new products,
has grown rapidly. This has led to an enormous increase in sotware com-
plexity, shorter innovation cycle times, and an ever-growing demand or ex-
traunctional requirementssotware saety, reliability, and timeliness, or example
at aordable costs.
The increasingcomplexity offunctional andextrafunctional
requirements forembedded systemscalls for new softwaredevelopmentapproaches.
Peter Liggesmeyer, University o Kaiserslautern
Mario Trapp, Fraunhoer Institute or Experimental Sotware Engineering
Trends in EmbeddedSotware Engineering
e m b e d d e d s o f t w a r e
7/28/2019 trend in embedded software engineering
2/7
20 I E E E S o f t w a r E w w w . c o m p u t e r . o r g / s o f t w a r e
with tight cost restrictions. Moreover, embedded
systems developers must consider resource limita-
tions and extreme environmental conditions such
as heat, humidity, or radiation.
To meet these requirements, developers o-
ten create a product-specic hardware platorm.Consequently, embedded sotware must be tai-
lored to heterogeneous hardware platorms and
operating systems to meet high-perormance de-
mands despite limited resources (such as memory
or processing power). This yields tailored, spe-
cic sotware platorms that are either created
through the application and adaptation o plat-
orm rameworks or developed specically or
one embedded system. The need to create special-
ized hardware and sotware platorms is a key
dierence between IT systems and embedded sys-
tems. For example, developers eorts in creatingthe Automotive Open System Architecture (www.
autosar.org) development platorma common
standardized platorm or developing embedded
systems in automobilesillustrate the diculties
in establishing a common platorm or even one
domain in embedded system development.
Extraunctional requirements contribute to
these diculties. Such requirements are ar more
important in embedded systems than in IT sys-
tems. For example, IT system users are accustomed
to waiting or the system to react, but a car wont
stop moving to wait or its control system to returna calculation. Domain-specic, extraunctional re-
quirements, such as sotware saety, reliability, and
timeliness, must be integrated into the develop-
ment process. Saety-critical systems, or example,
need certicated development processes and tool
chains according to standards such as Interna-
tional Electrotechnical Commission (IEC) 61508.1
Fullling rigorous extraunctional properties is
thereore costly and time consuming. The regular
need to adapt hardware, platorms, and operating
systems also limits generic solutions applicability.
Moreover, resource, cost, and other limitationsoten confict with extraunctional requirements
(such as real-time requirements).
In addition, embedded systems developers re-
quire extensive domain knowledge. For example,
developing a vehicle stability control system is
impossible i you dont understand the physics o
vehicle dynamics. Consequently, embedded sot-
ware development has been restricted mainly to
control engineers and mechanical engineers, who
have the necessary domain expertise. With the
rapidly growing complexity o embedded sotware
systems, however, many companies have run into
sotware quality problems. Supporting seamless
cooperation between domain and sotware devel-
opment experts to combine their complementary
expertise remains a core challenge in embedded
sotware development.
From Programmingto Model-Driven EngineeringManaging the rapidly increasing complexity o em-
bedded sotware development is one o the most
important challenges or increasing product qual-
ity, reducing time to market, and reducing devel-
opment cost. MDD is one o the promising ap-
proaches that have emerged over the last decade.
Instead o directly coding sotware using pro-
gramming languages, developers model sotware
systems using intuitive, more expressive, graphi-
cal notations, which provide a higher level o ab-
straction than native programming languages. Inthis approach, generators automatically create the
code implementing the system unctionalities. To
manage embedded systems growing complex-
ity, modeling will likely replace manual coding or
application-level developmentjust as high-level
programming languages have almost completely
replaced assembly language.
Model-driven architecture (MDA; www.omg.
org/mda) is the primary driver or MDD o IT sys-
tems. Although MDA denes generic concepts o
models and model transormations, MDD o em-
bedded systems started much earlier, beore UMLand MDA were standardized. Thereore, its main
drivers have been modeling tools implementing
vendor-specic languages (or example, Matlab/
Simulink and LabView). Using these tools, devel-
opers can completely speciy embedded sotware
systems using high-level models. Researchers have
devised many approaches ocusing on the specic
aspects o model-driven embedded systems devel-
opment.2 In addition to industry approaches are
those representing ongoing researchor exam-
ple, ormal verication o hybrid systems,3 model-
ing o hybrid systems with UML,4 or modeling the
requirements o hybrid systems.5
MDD o embedded systems is, as with any other
development activity, controlled by a development
process. Figure 1 illustrates a possible iterative
MDD process or the embedded systems domain
that covers the complete sotware development lie
cycle. The literature and development standards
have proposed similar variants. These variants in-
clude the lie cycles dened in standards such as
the IEC 61508;1 the UML-based Ropes (Rapid
Object-Oriented Process or Embedded Systems),6
which is based on the spiral process model;7 and
dierent approaches based on a V-Model.8
With the rapidlygrowing
complexityo embeddedsotware
systems, manycompanies have
run into sotwarequality problems.
7/28/2019 trend in embedded software engineering
3/7
May/June 2009 I E E E S o f t w a r E 21
Requirements-engineering tools support re-
quirements specication, manage requirement
changes, and help track test case results and test
coverage. Depending on the modeling languages
used to describe requirements, developers can
also use graphical languages such as UML or theSystems Modeling Language (SysML) to model
requirementsor example, using requirements
diagrams or use cases and scenarios. Develop-
ers can create a systems unctional design based
on the system requirements. Functional designs
cover an embedded systems unctionalities
without considering any technical implementa-
tion details. Instead, they consist o a compu-
tationally independent modelor example,
a mathematical model describing the created
sotware systems core behavior. For example, a
unctional design would speciy an automotivesystems closed-loop controllers rom a control
engineers viewpoint, omitting implementation
details such as tasking or deployment. Not all
embedded sotware systems require a unctional
design, so developers might skip this step.
Developers dene the actual sotware ar-chitecture on the basis o the requirements and
unctional design. Because dening sotware
architecture is a creative process, transorm-
ing a unctional design to an architecture is a
mostly manual process. An architecture deni-
tion consists o various views covering the ar-chitectures dierent aspects.9 Because UML
supports dierent diagrams and is easily ex-
tendable, developers oten use it to speciy ar-
chitectures, including those o embedded sys-
tems. Few data-fow-oriented modeling tools
provide all required language concepts and fex-
ibility, so theyre rarely applicable to architec-
tural modeling.
Ater dening the system architecture, de-
velopers rene the dierent components and
connections identied during the architecture
specication to obtain an executable, but still
platorm-independent, system. To this end, they
identiy urther subcomponents and model the
basic components actual behavior. One solution
is to use UML to model the rened structure
and data-fow languages to model component
behaviorparticularly i they need to model
continuous or hybrid behavior such as (closed-
loop) controllers or signal-processing compo-
nents. UML supports data-fow-oriented mod-
els to dene the structure. Developers can use
additional diagramsor example, sequence
diagramsto speciy the interaction between
components. Special deployment and tasking di-
agrams support the modeling o multithreaded
and distributed applications.
In principle, these platorm-independent mod-
els are sucient or generating executable code.
Usually, however, developers must urther reneor extend platorm-independent models in the
platorm-specic design to support ecient code
generation or the target execution platorm.
An iterative sotware development process
such as that in Figure 1 supports partial imple-
mentations, with the systems most critical aspects
implemented rst, as is oten imperative in the
embedded systems domain. Early iterations and
integrations let developers react quickly to neces-
sary changes originating, or instance, rom re-
source limitations. Today, a lack o tool support
and integration makes it impossible to seamlessly
cover the complete development lie cycle using
model-driven-engineering paradigms. Particularly
or the design phase, however, automated trans-
ormation rom design models to code is already
possible. This allows rapid creation o executable
prototypes as well as early evaluation o conor-
mance to extraunctional requirements, such as
resource use and timeliness.
Following the shit rom assembly language to
high-level programming languages, and rom pro-
gramming to model-based design, comes the shit
rom MDD to domain-specic development10a
shit already on the horizon. Some industry case
Requirements
Iterative prototypes
Functionaldesign
Functionaltesting
Validationtesting
Systemarchitecture
Softwarearchitecture
Softwareintegrationand testing
Systemintegrationand testing
Software
design
Unittesting
Implementation
Figure 1. An iterative model-driven development process or an
embedded system would encompass all phases o the development lie
cycle. This process lets developers produce partial implementations
ater each iteration, with the most critical aspects implemented frst.
7/28/2019 trend in embedded software engineering
4/7
22 I E E E S o f t w a r E w w w . c o m p u t e r . o r g / s o f t w a r e
studies have already successully applied domain-
specic development. MDD is based on general-
purpose languages and code generators or dier-ent application domains. This claim or generality
contradicts the optimization o the language and
code generators to a given application context, and
to the hardware platorm used. Domain-specic
modeling lets developers use domain-specic con-
cepts, so it provides even more-intuitive modeling
languages and integrates more sotware developer
know-how and application-specic optimizations
into the code generators.
Figure 2 shows a domain-specic language
or speciying condition-monitoring systems or
hydraulic systems. Although the example looks
like a domain experts Visio drawing, its actually
a ormal model with a clear syntax and seman-
tics, enabling code generation based on this speci-
cation. Because the modeling elements have rich
semantics and the amily o possible target plat-
orms is known, the resulting tailored code gen-
erators produce ecient code. All the sotware de-
velopment expertise necessary to create a system
rom this specication is encapsulated in the code
generator, libraries, and (i required) the platorm
sotware, which might include an operating sys-
tem or a microkernel. Here, sotware engineer-
ing experts are needed primarily to create the
domain-specic language and tool chain, which
domain experts can then use to build an embed-
ded sotware system.
Although domain-specic modeling simpli-
es system specication, the modeling language
is limited to a specic class o problems. So, thedevelopment o the domain-specic language and
generators requires an initial eort, which will
only pay o i the same development environment
is applicable to several projects. In certain appli-
cation domains, such as the condition-monitoring
system example, this is certainly the case. For
these domains, domain-specic development is
an ecient, promising approach. In general, how-
ever, domain-specic development wont com-
pletely replace MDD; rather, hybrid solutions are
more likely.
For example, in UML, proles let developerstailor and extend the generic language to spe-
cic domains, thereby specializing the languageto the domain and enriching its semantics so that
it can be used more intuitively. Nonetheless, be-
cause UML is still at its base, the specialized lan-
guage can reuse existing (code generation) tool
chains. UMLs complete expressiveness is avail-
able i domain-specic extensions are insucient.
Next-generation languages and tools will provide
extended extension and tailoring mechanisms, po-
tentially combining the advantages o MDDs gen-
erality with those o specialized domain-specicmodeling languages.
Quality Assuranceo Saety-Related SystemsIn addition to the constructive phases o embed-
ded systems development, ensuring the quality o
a systems unctional and extraunctional prop-
erties is crucial in such development. This is par-
ticularly true or saety-related systems.
Beore code generation, developers can apply
static and ormal verication techniques to en-
sure sotware quality; ater code generation, they
can use dynamic-testing approaches. Regard-
ing quality assurance, dynamic testing is still a
widespread approach or determining the correct
unctioning o sotware and systems. However,
only ormal verication techniques can achieve
complete correctness proos. Still, every ormal
technique has disadvantages. Applying ormal
techniques to a complete, complex sotware sys-
tem isnt possible. Moreover, ormally proven
sotware might still be unsae, and sae sotware
might not be completely correct. Correctness
clearly supports saety, but it doesnt substitute
or saety analysis.
I0
I1
I2
I3
I4
I5
I6
I7
I8
I9
O0
O1
O2
O3
O4
O5
O6
O7
O8
O9
Figure 2. Example o a domain-specifc language. In this view o the
model, developers simply defne which sensors they use to monitor the
hydraulics system and connect them to the respective input ports o
the monitoring hardware. The complete code to confgure the sensors
and to retrieve and to interpret the sensor readings is then generated
completely automatically.
7/28/2019 trend in embedded software engineering
5/7
May/June 2009 I E E E S o f t w a r E 23
Saety analysis is thereore another central el-
ement in the development o saety-related sys-
tems, as well as or sotware. Model-based or
measurement-based approacheseach o which
has advantages and disadvantagescan address
saety and reliability issues. In practice, a combi-nation o approaches is oten necessary.
Model-based saety and reliability analysis
provides inormation at an early stagethat is,
beore the system is implemented. It might identiy
problems early and reduce rework costs. However,
developing the appropriate models requires addi-
tional eort and time, because saety models such
as ault trees11 are usually generated manually.
The measurement-based approach to saety
and reliability is only applicable ater the system
has been ully specied or implemented. Because
measurementssuch as ailure data rom systemtestingare never complete, producing depend-
able results requires statistical techniques.
Dynmic tesing
Although ormal verication techniques seem to
t saety-critical sotware requirements, many de-
velopers use dynamic testingthat is, testing by
executing dened test cases. Particularly in the
MDD context, when using iterative development
processes, developers can apply tests based on the
design models in early design phases, enabling a
continuous quality-assurance process. Unlike or-mal techniques, dynamic tests can be applied to
complex systems and are easier to realize. Basi-
cally, testing can start in the rst iteration o the
development process, directly ater code is gener-
ated rom the sotware design. As Figure 1 shows,
you can apply dynamic testing in multiple phases:
Unit testing tests specic units.
Software and system integration testing tests
the integration o sotware units and o the
sotware system with its hardware.
Validation testing ensures that all system re-
quirements have been ullled.
Optional functional testing ensures conor-
mance to the unctional design.
Although tests cant prove sotware correctness,
systematic testing can achieve sucient sotware
qualityeven in saety-critical applications. Com-
bining statistic dynamic-testing procedures with
statistic analyses based on reliability growth models
allows quantication o residual risks.
Developers can implement testing in the actual
operating environment, which lets them detect cer-
tain problems, such as those usually not detected
through ormal verication. These might include
interace problems but could also be the violation
o extraunctional properties resulting in timing,
communication, or resource-consumption prob-
lems originating rom the integration o sotware
and hardware.Testing is denitely the simplest way to evaluate
system behavior, even ater deployment, and with
respect to extraunctional properties. In addition,
dynamic testing is scalable. A thorough, system-
atic selection o test cases ensures that they appro-
priately cover the desired unctionality. Accepted
minimal criteria or testing embedded sotware are
the complete coverage o the specication with test
cases, branch coverage o the code, and reproduc-
ibility o the test (regression testing). Such criteria
are augmented with additional requirements in spe-
cial casesor example, or saety-critical sotwareor commercial aircrat (RTCA DO-178B12).
Mdel-Bsed Sey nd relibiliy anlysis
Despite the importance o standard quality-
assurance techniques such as testing and ormal
verication or embedded sotware development,
they cant replace saety analysis techniques. So,
the demand is strong or techniques and mod-
els that help developers achieve and assess saety
and reliability. These techniques include reliability
block diagrams, ault tree analysis (FTA),11 and
Markov models.FTA depicts causal chains leading to a ailure
as a tree. The system ailure to be examined is the
trees root; the basic ailurescomponent ailures,
or exampleare its leaves. This tree structure in-
herently describes a hierarchical breakdown, but
with respect to the hierarchy o ailure infuences
rather than the system architecture. In FTA, mod-
ules are subtrees. This partitioning merely repre-
sents a property o the infuence chains. The mod-
ules generally dont correspond to the sotware
components identied during system development.
In a sotware model, the connections o compo-
nents usually dene a graph structure that cant be
mapped directly to ault trees. Consequently, divi-
sion o labor is hampered during ault tree design.
Moreover, tracing ault tree elements to the corre-
sponding sotware components is dicult. Reus-
ing sotware components makes it dicult to re-
use the corresponding ault tree elements, as well.
To overcome these drawbacks, component
ault trees13 extend conventional ault trees using
real components that are connected via ports (see
Figure 3 on the next page). The ault tree struc-
ture can thereore be similar to the sotware sys-
tems structure, simpliying the denition o the
Although testscant prove
sotwarecorrectness,systematic
testingcan achievesufcientsotwarequality.
7/28/2019 trend in embedded software engineering
6/7
24 I E E E S o f t w a r E w w w . c o m p u t e r . o r g / s o f t w a r e
saety model and the traceability to the design
models. By providing a real-component concept,
component ault trees directly support the divi-
sion o labor and intensive component reuse.
Mesuemen-Bsed Sey
nd relibiliy anlysis
Saety engineers can use the modeling techniques
weve described in the early design phases to con-
structively guide the development process, and
thus prevent saety-critical design aults. However,
the results accuracy depends on the saety and
reliability models quality. Measurement-based
approaches dont suer rom modeling aults. In
addition, the validity o measurements on a real
entity is unquestionable. However, like dynamic
testing, these approaches are applicable ater code
generation at the earliest. Moreover, measure-
ments are never complete. Applying statistical
methods to obtain a statistically protected trust-
worthiness can somewhat compensate or this
disadvantage. Fault trees let you model reliability;
reliability growth models let you measure, evalu-
ate, and predict reliability. An overview o sot-
ware reliability modelinga research discipline
since the early 1970sis available elsewhere.14
Experience shows that the application o
theory is critical in sotware reliability analysis.
Reliability must be easy to measure and predict,
without the user having to completely under-stand its theoretical background. Almost all the
theories can be encapsulated in a tool that evalu-
ates whether a certain reliability growth model
ts the observed ailure data, determines model
parameters, and calculates reliability values (or
example, ailure counts and rates).
U p to now, researchers have consid-ered saety and reliability separatelyrom model-driven engineering. Evenemerging standards such as ISO/CD 26262 orthe automotive domain insuciently address
model-driven engineering o embedded sot-
ware. A challenge is thereore to systematically
dene how to ensure saety in the model-driven-
engineering contextand not only through ver-
ication and validation.
We must also clariy how dierent demands
will be applied to MDD approaches. MDD con-
cepts could be benecial in saety engineering.
Particularly or engineering saety-critical sys-
tems, isolated concepts available in research
must evolve into standard approaches acceptedby certication bodies.
Dierent approaches or the development
and quality assurance o embedded sotware
systems have been successully transerred to in-
dustry. However, techniques or systematically
developing embedded sotware can hardly keep
up with the ever-growing demand or new unc-
tionalities and technologies. In the development
o saety-critical systems, new unctionalities
are useless i you cant ensure their quality and
saety. The rapid progress o systematic sotware
engineering technologies will thereore be a key
actor in the successul uture development o
even more-complex embedded systems.
AcknowledgmentsWe thank Thomas Kuhn for his comments and con-tribution to this article. We also thank the reviewersand editors for their comments, which helped us im-prove this ar ticles quality.
Reerences1. IEC 61508, Functional Saety o Electrical/Electroni-
cal/Programmable Electronic Saety-Related Systems,Intl Electrotechnical Commission, 1998.
Self-steering:Dangerous undefinedtorque applied to motorfor more than 20 ms;
Lockedsteering
Power steering failure logic
Steering torqueprocessor
Common-causes
hardware
Pulse width modulationgeneration
DC link voltagemeasurement
Shut-off execution
Steering functions
Common-causes
software
Figure 3. Component ault trees simpliy ault tree analyses o complex
sotware systems (www.essarel.de). The ault tree describes two top
events o an active power steering systemnamely, locked steering
and sel-steering. The active power steering system is decomposed
to dierent components such as the power steering torque processor.
The component ault tree ollows the structure o the system and thus
simplifes the mapping between unctional model and saety model,
enables division o labor, and improves the reusability o ault tree
components.
7/28/2019 trend in embedded software engineering
7/7
May/June 2009 I E E E S o f t w a r E 25
2. H. Giese and S. Henkler, A Survey o Approaches orthe Visual Model-Driven Development o Next Genera-tion Sotware-Intensive Systems,J. Visu al Languagesand Computing, vol. 17, no. 6, 2006, pp. 528550.
3. R. Alur et al., Hierarchical Hybrid Modeling o Em-bedded Systems, Proc. 1st Intl Workshop EmbeddedSotware (EMSOFT 01), LNCS 2211, Springer, 2001,
pp. 1431.4. K. Berkenktter et al., Executable HybridUML and Its
Application to Train Control Systems, Integration oSotware Specifcation Techniques or Applications inEng., LNCS 3147, Springer, 2004, pp. 145173.
5. R. Grosu, I. Krger, and T. Stauner, Hybrid SequenceCharts, Proc. 3rd IEEE Intl Symp. Object-OrientedReal-Time Distributed Computing(ISORC 00), IEEEPress, 2000, p. 104.
6. B.P. Douglass, Real Time UML: Advances in the UMLor Real-Time Systems, Addison-Wesley, 2004.
7. B.W. Boehm, A Spiral Model o Sotware Developmentand Enhancement, Computer, vol. 21, no. 5, 1988, pp.6172.
8. B.W. Boehm, Guidelines or Veriying and Validat-ing Sotware Requirements and Design Specifcation,
Proc. European Con. Applied Inormation Technology(Euro IFIP), North-Holland, 1979.
9. P. Kruchten, The 4 + 1 View Model o Architecture,IEEE Sotware, vol. 12, no. 6, 1995, pp. 4250.
10. S. Kelly and J.-P. Tolvanen, Domain-Specifc Modeling:Enabling Full Code Generation, Wiley-IEEE CS Press,2008.
11. IEC 61025, Fault Tree Analysis (FTA), Intl Electro-technical Commission, 1990.
12. RTCA DO-178B, Sotware Considerations in AirborneSystems and Equipment Certifcation, Radio TechnicalCommission or Aeronautics, 1992.
13. B. Kaiser, P. Liggesmeyer, and O. Mckel, A New Com-ponent Concept or Fault Trees, Proc. 8th AustralianWorkshop Saety Critical Systems and Sotware (SCS03), Australian Computer Soc., 2003, pp. 3746.
14. M.R. Lyu, Handbook o Sotware Reliability Engineer-ing, McGraw-Hill, 1995.
For more information on this or any other computing topic, please visit ourDigital Library at www.computer.org/csdl.
About the Authors
Peter Liggesmeyer is a full professor at the University of Kaisersla utern and thedirector of the Fraunhofer Institute for Experimental Software Engineering . His researchinterests include engineering of dependable systems, softwa re quality assurance, andsoftware visualization. Liggesmeyer has a doctorate in elec trical engineering from the Uni-
versity of Bochum. Hes a member of the IEEE and the German Chapter of the ACM. Contacthim at peter.liggesmeyer@iese.fraunhofer.de.
Mario Trapp is a division manager at the Fraunhofer Institute for ExperimentalSoftware Engineering. His research interests include model-driven development of high-integrity embedded systems and safety-engineering techniques. Trapp has a doc torate incomputer science from the University of Kaiserslautern. Contact him at mario.trapp@iese.fraunhofer.de.