01 Trends in Embedded Software Engineering

8/2/2019 01 Trends in Embedded Software Engineering

1/46

Prof. Dr. Wolfgang Pree

Department of Computer Science

Universitt Salzburg

cs.uni-salzburg.at

MoDECS.ccPREEtec.com

Trends in

Embedded Software Engineering


2/46

W. Pree: Trends in Embedded Software Engineering2 LASER 2005

Contents

Why focus on embedded software?

Better abstractions

timing & concurrency

transparent distribution

Modularization (component models)

Further challenges


3/46


What are we talking about?

Information processing that is tightly

integrated with physical processes is

called

embedded computing


4/46


Many innovations in embedded systems will result

from software features


5/46


A special breed: real-time embedded computing


6/46


Hard versus soft real-time systems


7/46


Sample hard RT system: engine controller

10 ms for 360 at 6000 rpm

temporal accuracy of of 3 sec required

up to 100 concurrent software tasks

=> a hard real-time system is only correct if

the concurrent tasks meet the strict real-time

deadlines


8/46


Priority scheduling anomalies

reducing task execution times

adding a processor to a distributed computing system

relaxing precedence constraints

can all increase processing time.


9/46


Priority inversion problem

low-priority process keeps high-priority process from

running

might cause deadlocks


10/46


Most existing programming models are not sufficient

In order to overcome the inherent problems of

concurrent, real-time software development,

new abstractions,

methods and

tools

are required.


11/46


Automotive sector: more software ...

More than 80% of innovations in the automotive

industry are expected to result from embedded

software over the next decade.

key goal: ultra-reliable embedded software

The challenge:

up to some millions (!) LOC

complex distributed computing platform

20 80 computing nodes

several bus systems

massively concurrent software tasks


12/46


... less tailored to hardware/OS-platforms

Dr. Hans-Georg Frischkorn (Senior Vice President

Electric/Electronics, BMW Group):

Whereas today, software is developed for and

tailored to the delivered electronic control unit

[processor], a main paradigm shift is expected:Software in cars will become much more

independent of specific hardwarea similar

development to that started in the computer industry

30 years ago.

Thus, radically new abstractions, methods and

tools are required.


13/46


Abstractions


14/46


Lifting the level of abstraction for general-purpose

programming

HW + OS

assembly language

C

C++

Java C#Oberon Eiffel

LISP Prolog

comp

ilation


15/46


Abstractions for embedded systemsa missing link

HW + OS

general-purpose programming languages

mathematical modeling (eg, Simulink)

embedded software model


16/46


Abstractions for embedded systemsa missing link

HW + OS

general purpose programming languages

mathematical modeling (eg, Simulink)

embedded software model timing & concurrency

efficient to implement reusable components


17/46


Key question: What are appropriate

abstractions?

Do they cover the relevant aspects of a design?

Which embedded software properties do they

deliver?

Do they scale?

Are the resulting designs understandable? Can compilers generate efficient code?


18/46


Caveat: visual representations are often

associated with good abstractions

Real-Time UML: priorities (widely misued in practice), etc.

Simulink: offers only functions for modularization


19/46


Required embedded softwareproperties

focus: ultra-reliable embeddedcontrol


20/46


Determinism

If a software component is called twice with the

same input values at the same time instants, it

should both times produce the same output

values at the same time instants.

Example: If a control component receives thesame sensor values and the same driver input, it

should always react exactly in the same way.

Consequences:

Testability: each behavior can be reproduced.

Minimal jitter.


21/46


Portability (= software standardization)

The behavior of a software component should be

specified independent of its implementation.

Example: The hardware, operating system, or bus

architecture can be changed without changing the

behavior of the application components.

Consequences:

Upgradability of hardware.

Portability of software.


22/46


better quality, reduced costs

deterministic timing behavior

portability

automatic code generation

computing platform,

for example, MPC555+OSEK

embedded control software

plantA S


23/46




portability


M1


24/46




portability


M1


25/46




portability


M1

M2


26/46




portability


M1 M2


27/46


Sample abstraction:Logical Execution Time (LET)


28/46


Task 1

t

State-of-the-art programming model leads to

non-deterministic, non-portable software

only constraint: calculation finishes before a deadline

PROBLEM: results are available as soon as calculation is

finished => NO determinism, NO portability

Task 2


29/46


Logical Execution Time (LET),

an abstraction invented at UC Berkeley

results are available EXACTLY after the LET of a taskTask 1

t

Task 2

LET >= WCET

LET1

LET2


30/46


LET delivers the required software properties

for ultra-reliable embedded systems

determinism => testability, minimal jitter compositionality => extensibility, reuse

software standardization=>portability, upgradability of HW

timetask invocation

Logical Execution Time (LET)

logical

view

physicalview

release terminate

running running


31/46


platform first ...?


32/46


LET allows Transparent Distribution

M1

comm1

comm2

time

LET1

bus

LET2

node1

node2M2

message sent according to bus schedule (TDMA)


33/46


LET might be appropriate for the time-triggered

and event-triggered programming models

xGiotto: has generalized fixed LET

requires event scoping


34/46


Towards embedded softwarecomponents


35/46


Hierarchical structuring is only a first step

A subsystem (= function) in Simulink

input

parameters

output

parameters


36/46


37/46


required: domain-adequate language

constructs for modularization

M1

M2

module M2 {

import M1;

...

start mode main [period= M1.refPeriod] {task

[freq=1] sum(M1.inc.o, M1.dec.o);

...

}

}


38/46


Compositionality

The behavior of a software component should beindependent of the overall system load and

configuration.

Example: A new component can be added to a

system without changing the behavior of theoriginal components.

Consequences:

Extensibility of systems.

Reuse of components.


39/46


Next-generation tools forembedded software

development


40/46


We have developed a modeling language and a set of tools

based on LET www.MoDECS.cc PREEtec.com

modularization

separation of concerns:

timing | functionalityplatform | functional and temporal behavior

language construct for modules embedded software properties


portability (automatic platform code generation)

compositionality transparent distribution


41/46


Tools for developing ultra-reliable embedded

software require solid foundations

abstractions LET, module

development methodsGiotto/Timing

Definition Language

tool supportvisual/interactive

editor, compiler, etc.


42/46


Timeline of beating the concepts into

their shapes ...

1999 2000 2001 2002 2003 2004

Giotto

UC BerkeleyTiming Definition Language (TDL)

MoDECS

2005


43/46


LET-based tool chain

MoDECS.cc PREEtec.com

S

S

A

A

S

A

starting point: LET/Giotto (UC Berkeley)

TDL module

component model

M1

M2

M3

VisualTDL in Simulink

platform spec.

M1M2M3

TDL compiler +

schedule generator

E-Code

S-Code

INtime, OSEK,

TTA, RT-Linux

E-/S-Machines+TDLComm


44/46


Further embedded softwarechallenges


45/46


Orthogonal challenges

appropriate software abstractions as basis ofmodel-based development

support of multiple models of computation

reengineering of existing systems

requirements engineering process management

risk analysis and error management

usability

security . . .


46/46


The end

Thank you for your attention!

Documents

01 Trends in Embedded Software Engineering