trend in embedded software engineering

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


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.


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.


4/7


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.


5/7


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.


6/7


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/7


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 [email protected].

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 [email protected].

trend in embedded software engineering

Documents

Transcript of trend in embedded software engineering