Transcript PowerPoint-Präsentation

technische universität
dortmund
fakultät für informatik
informatik 12
Embedded System Design:
Embedded Systems Foundations
of Cyber-Physical Systems
Peter Marwedel
TU Dortmund,
Informatik 12
© Springer, 2010
2013年 10 月 09 日
These slides use Microsoft clip arts.
Microsoft copyright restrictions apply.
technische universität
dortmund
fakultät für informatik
informatik 12
Graphics: © Alexandra Nolte, Gesine Marwedel, 2003
Common
characteristics
Dependability
 CPS/ES must be dependable,
• Reliability R(t) = probability of system working
correctly provided that is was working at t=0
• Maintainability M(d) = probability of system working
correctly d time units after error occurred.
• Availability A(t): probability of system working at time t
• Safety: no harm to be caused
• Security: confidential and authentic communication
Even perfectly designed systems can fail if the
assumptions about the workload and possible errors turn
out to be wrong.
Making the system dependable must not be an afterthought, it must be considered from the very beginning
technische universität
dortmund
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
- 3-
Efficiency
 CPS & ES must be efficient
• Code-size efficient
(especially for systems on a chip)
• Run-time efficient
• Weight efficient
• Cost efficient
• Energy efficient
technische universität
dortmund
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
© Graphics: Microsoft, P. Marwedel,
M. Engel, 2011
- 4-
Importance of Energy Efficiency
Efficient software
design needed,
otherwise, the
price for software
flexibility cannot
be paid.
technische universität
dortmund
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
© Hugo De Man (IMEC)
Philips, 2007
- 5-
CPS & ES Hardware
CPS & ES hardware is frequently used in a loop
(“hardware in a loop“):
Cyber-physical systems (!)
technische universität
dortmund
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
© Graphics: Microsoft,
P. Marwedel, 2011
- 6-
Real-time constraints
 CPS must meet real-time constraints
• A real-time system must react to stimuli from the controlled
object (or the operator) within the time interval dictated by
the environment.
execute
t
• “A real-time constraint is called hard, if not meeting that
constraint could result in a catastrophe“ [Kopetz, 1997].
• All other time-constraints are called soft.
• A guaranteed system response has to be explained without
statistical arguments [Kopetz, 1997].
technische universität
dortmund
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
© Graphics: Microsoft
- 7-
Real-Time Systems & CPS
CPS, ES and Real-Time Systems synonymous?
 For some embedded systems, real-time behavior is less
important (smart phones)
 For CPS, real-time behavior is essential, hence RTS 
CPS
 CPS models also include a model of the physical system
technische universität
dortmund
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
- 8-
Reactive & hybrid systems
 Typically, CPS are reactive systems:
“A reactive system is one which is in continual
interaction with is environment and executes at
a pace determined by that environment“
[Bergé, 1995]
Behavior depends on input and current state.
 automata model appropriate,
model of computable functions inappropriate.
 Hybrid systems
(analog + digital parts).
technische universität
dortmund
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
© Graphics: Microsoft,
P. Marwedel, 2011
- 9-
Dedicated systems
 Dedicated towards a certain application
Knowledge about behavior at design time
can be used to minimize resources and to
maximize robustness
 Dedicated user interface
(no mouse, keyboard and screen)
 Situation is slowly changing here: systems
become less dedicated
technische universität
dortmund
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
© Graphics: P.
Marwedel, 2011
- 10 -
Security
Defending against
Cyber crime („Annual U.S. Cybercrime Costs Estimated
at $100 Billion; …[Wall Street Journal, 22.7.2013])
Cyber attacks ( Stuxnet)
Cyber terrorism
Cyber war (Cyber-Pearl-Harbor
[Spiegel Online, 13.5.2013])
Connectivity increases threats
entire production chains can be affected
local islands provide some encapsulation, but contradict idea of
global connectedness
technische universität
dortmund
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
- 11 -
Dynamics
Frequent change of environment
technische universität
dortmund
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
- 12 -
Underrepresented in teaching
 CPS & ES are underrepresented in teaching
and public discussions:
“Embedded chips aren‘t hyped in TV and
magazine ads ...” [Mary Ryan, EEDesign, 1995]
Not every CPS & ES has all of the above characteristics.
Def.: Information processing systems having most of the
above characteristics are called embedded systems.
Course on embedded systems foundations of CPS makes
sense because of the number of common characteristics.
technische universität
dortmund
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
© Graphics: Microsoft
- 13 -
Characteristics lead to corresponding challenges
 Dependability
• In particular: Energy efficiency
© Graphics: P.
Marwedel, 2011
 Efficiency
 Hardware properties, physical environment
 Meeting real time requirements
 ….
technische universität
dortmund
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
- 14 -
Challenges for implementation in hardware
 Early embedded systems frequently implemented in
hardware (boards)
 Mask cost for specialized application specific integrated
circuits (ASICs) becomes very expensive
(M$ range, technology-dependent)
 Lack of flexibility (changing standards).
 Trend towards implementation in software
(or possibly FPGAs, see chapter 3)
technische universität
dortmund
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
- 15 -
Challenges for implementation in software
If CPS/ES will be implemented mostly in
software, then why don‘t we just use
what software engineers have come up
with?
technische universität
dortmund
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
- 16 -
It is not sufficient to consider CPS/ES as a
special case of SW engineering
Knowledge from many areas must be available,
Walls between disciplines must be torn down
medicine, statistics,
ME, biology
Physics
CS
EE
technische universität
dortmund
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
- 17 -
Challenges for CPS/ES Software
 Dynamic environments
 Capture the required behaviour!
 Efficient translation of specifications
into implementations!
© Graphics: P.
Marwedel, 2011
 Validate specifications
 How do we validate embedded realtime software? (large volumes of data,
testing may be safety-critical)
technische universität
dortmund
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
© Graphics: P.
Marwedel, 2011
 How can we check that we meet realtime constraints?
- 18 -
Software complexity is a challenge
Software in a TV set
 Source 1*:
Year
1965
1979
1990
2000

  Exponential increase in
software complexity
Size
0
1 kB
64 kB
2 MB
 ... > 70% of the development cost for
complex systems such as automotive
electronics and communication systems
are due to software development
Source 2°: 10x per 6-7 years
Year
Size
1986
10 KB
1992
100 kB
1998
1 MB
2008
15 MB
technische universität
dortmund
[A. Sangiovanni-Vincentelli, 1999]
* Rob van Ommering, COPA Tutorial, as cited by: Gerrit
Müller: Opportunities and challenges in embedded
systems, Eindhoven Embedded Systems Institute, 2004
° R. Kommeren, P. Parviainen: Philips experiences in
global distributed software development, Empir
Software Eng. (2007) 12:647-660
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
- 19 -
technische universität
dortmund
fakultät für informatik
informatik 12
Graphics: © Alexandra Nolte, Gesine Marwedel, 2003
Design flows
Application Knowledge
Hypothetical design flow
Design
repository
Specification
ES-hardware
Design
Test *
Application
mapping
System software
(RTOS,
middleware, …)
Optimization
Evaluation & Validation
(energy, cost,
performance, …)
* Could be
integrated
into loop
Generic loop: tool chains differ in the number and type of iterations
technische universität
dortmund
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
- 21 -
Iterative design (1): - After unrolling loop Example:
SpecC
tools
technische universität
dortmund
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
- 22 -
Iterative design (2): - After unrolling loop Example: V-model
Requirement
analysis
System
architecture
System
design
Software
architecture
Software
design
Acceptance
& use
technische universität
dortmund
System
integration
Integration
testing
Unit
tests
Skipping some explicit repository updates;
very late integration, problems may be missed ..
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
- 23 -
Iterative design (3): - Gajski‘s Y-chart -
technische universität
dortmund
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
- 24 -
Summary
 Common characteristics
 Challenges (resulting from common characteristics)
 Design Flows
technische universität
dortmund
fakultät für
informatik
 P.Marwedel,
Informatik 12, 2013
- 25 -