Center for Hybrid and Embedded
Software Systems
College of Engineering, University of California at Berkeley
Presented by: Alberto Sangiovanni Vincentelli
Industrial Advisory Board Meeting, March 19th, 2003
Board of Directors
Tom Henzinger, tah@eecs.berkeley.edu
Edward A. Lee, eal@eecs.berkeley.edu
Alberto Sangiovanni-Vincentelli, alberto@eecs.berkeley.edu
Shankar Sastry, sastry@eecs.berkeley.edu
Other key faculty
Alex Aiken, aiken@eecs.berkeley.edu
Dave Auslander, dma@me.berkeley.edu
Ruzena Bajcsy, ruzena@eecs.berkeley.edu
Karl Hedrick, khedrick@me.berkeley.edu
Kurt Keutzer, keutzer@eecs.berkeley.edu
George Necula, necula@eecs.berkeley.edu
Masayoshi Tomizuka, tomizuka@me.berkeley.edu
Pravin Varaiya, varaiya@eecs.berkeley.edu
Hybrid & Embedded Software Systems
• Computational systems
– but not first-and-foremost a computer
• Integral with physical processes
– sensors, actuators
• Reactive
– at the speed of the environment
• Heterogeneous
– hardware/software, analog/digital, mixed
architectures
• Networked
– adaptive software, shared data, resource
discovery
Chess/IAB 2
Mission of Chess
To provide an environment for graduate research on
the design issues necessary for supporting nextgeneration embedded software systems.
– Model-based design
– Tool-supported methodologies
For
–
–
–
–
–
–
Real-time
Fault-tolerant
Robust
Secure
Heterogeneous
Distributed
The fate of
computers
lacking
interaction with
physical
processes.
Software Systems
Chess/IAB 3
French Guyana, June 4, 1996
$800 million embedded software failure
Chess/IAB 4
Mars, December 3, 1999
Crashed due to un-initialized variable
Chess/IAB 5
$4 billion development effort
40-50% system integration & validation cost
Chess/IAB 6
Complexity, Quality, Time-to-Market:
TODAY
BODY GATEWAY
PWT UNIT
INSTRUMENT
CLUSTER
TELEMATIC
UNIT
MEMORY
256 KB
128 KB
184 KB
8 MB
LINES OF CODE
50.000
30.000
45.000
300.000
PRODUCTIVITY
6 LINES/DAY
10 LINES/DAY
6 LINES/DAY
10 LINES/DAY*
3000 PPM
2500 PPM
2000PPM
1000 PPM
CHANGING RATE
3 YEARS
2 YEARS
1 YEAR
< 1 YEAR
DEV. EFFORT
40 MAN-YEAR
12 MAN-YEAR
30 MAN-YEAR
200 MAN-YEAR
VALIDATION TIME
5 MONTHS
1 MONTH
2 MONTHS
2 MONTHS
TIME TO MARKET
24 MONTHS
18 MONTHS
12 MONTHS
< 12 MONTHS
RESIDUAL DEFECT
RATE @ END OF DEV
* C++ CODE
FABIO ROMEO, Magneti-Marelli
Design Automation Conference, Las Vegas, June 20th, 2001
Chess/IAB 7
The Software Development Problem
• Product Quality is POOR
• Development Productivity is LOW
• Development Cycle-time is TOO LONG
Source: Roger G. Fordham
Motorola, Global Software
Group
DAC 2001, June 6, 2001
System Software (of size 10,000 Function Points)
QUALITY
PRODUCTIVITY
CYCLETIME
Industry Average
Industry Average
Industry Average
0.44
4.13
36
Ind. Best-in-Class
Ind. Best-in-Class
Ind. Best-in-Class
0.08
8.76
25
Customer Expectation
Customer Expectation
Customer Expectation
<0.00044
>40
<3-6
Function Point per Staff
Delivered Defects per
Schedule in Months
Month
Function Point
Source of Industry Data: Capers Jones(2000) Software Assessments, Benchmarks, and Best Practices, Addison-Wesley.
Chess/IAB 8
Embedded Software Architecture Today
Chess/IAB 9
Embedded Software: Future?
Chess/IAB 10
The Goal
• To create a modern
computational systems
science and systems
design practice with
–
–
–
–
–
–
–
–
Concurrency
Composability
Time
Hierarchy
Heterogeneity
Resource constraints
Verifiability
Understandability
Chess/IAB 11
A Traditional Systems Science –
Feedback Control Systems
• Models of continuous-time dynamics
• Stability analysis
• But not accurate for software controllers
Chess/IAB 12
Discretized Model –
A Step Towards Software
• Numerical integration techniques provided ways to get from the
continuous idealizations to computable algorithms.
• Discrete-time signal processing techniques offer the same
sophisticated stability analysis as continuous-time methods.
• But it’s still not accurate for software controllers
Chess/IAB 13
Hybrid Systems –
Reconciliation of Continuous & Discrete
• UCB researchers have
contributed substantially
to the theory and
practice of blended
discrete & continuous
models.
• But it’s still not accurate
for software controllers
Chess/IAB 14
Timing in Software is More Complex Than
What the Theory Deals With
An example, due to Jie Liu, models two
controllers sharing a CPU under an RTOS.
Under preemptive multitasking, only one
can be made stable (depending on the
relative priorities). Under non-preemptive
multitasking, both can be made stable.
Where is the theory for this?
Chess/IAB 15
The Standard Software Design Trick
For scarce resource X
– Manage X as best we can
– Any correct heuristic is OK, no matter how
complex
– If we need more, fall back to secondary
strategy
– Focus on average case behavior
– Give the programmer a nice abstraction
Source: Alex Aiken
Chess/IAB 16
What’s Wrong with This?
• Embedded systems have limited resources
• Meaning hard limits
– Cannot use more time
– Cannot use more registers
• The compiler must either
– Produce code within these limits
– Report failure
• The standard trick is anathema to embedded
systems
– Can’t hide resources
Source: Alex Aiken
Chess/IAB 17
Embedded Software Design: My Take
• Embedded Software Design must not be seen
as a problem in isolation, it is an, albeit
essential, aspect of EMBEDDED SYSTEM
DESIGN
• Our vision is to change the way in which ESW
is developed today by linking it:
– Upwards in the abstraction layers to system
functionality
– Downwards in the programmable platforms that
support it thus providing the means to verify whether
the constraints posed on Embedded Systems are met.
Chess/IAB 18
How Safe is Our Real-Time Software?
Chess/IAB 19
Another Traditional Systems Science Computation, Languages, and Semantics
Everything “computable” can be given by a
terminating sequential program.
Alan Turing
sequence
• Functions on bit patterns
• Time is irrelevant
• Non-terminating programs are defective
f : States  States
States = Bits*
results + state out
Chess/IAB 20
Current fashion – Pay Attention to “Nonfunctional properties”
•
•
•
•
•
Time
Security
Fault tolerance
Power consumption
Memory management
But the formulation of the question is very telling:
How is it that when a braking system applies the
brakes is any less a function of the braking system
than how much braking it applies?
Chess/IAB 21
What about “real time”?
Make it faster!
Chess/IAB 22
Processes and Process Calculi
Infinite sequences of
state transformations
are called “processes”
or “threads”
incoming message
outgoing message
Various messaging
protocols lead to
various formalisms.
In prevailing software
practice, processes are
sequences of external
interactions (total
orders).
And messaging protocols
are combined in ad hoc
ways.
Chess/IAB 23
Prevailing Practice in Embedded Software –
Interacting Processes
Software
realizing these
interactions is
written at a
very low level
(semaphores
and mutexes).
Very hard to
get it right.
stalled by precedence
timing dependence
stalled for rendezvous
Chess/IAB 24
Interacting Processes –
Not Compositional
An aggregation
of processes is
not a process
(a total order
of external
interactions).
What is it?
Many software
failures are
due to this illdefined
composition.
Chess/IAB 25
Compositionality
Non-compositional formalisms lead to very awkward architectures.
Chess/IAB 26
Real-Time Multitasking?
Prioritize and Pray!
Chess/IAB 27
Promising Alternatives
•
•
•
•
•
•
Synchronous languages (e.g. Esterel)
Time-driven languages (e.g. Giotto)
Hybrid systems
Timed process networks
Discrete-event formalisms
Timed CSP
We are working on interface
theories and meta models that
express dynamic properties of
components, including timing.
Chess/IAB 28
Fault Tolerant
Mobile Communications
MOST
Firewire
Fail Safe
CAN
Lin
Navigation
Access to
WWW
DAB
Fire
Wall
Today, more
than 80
Microprocessors
and millions of
lines of code
Theft warning
Air
Conditioning
Door Module
Gate
Way
Light Module
ABS
CAN
TTCAN
Gate
Way
Fault
Functional
Body
Electronics
Body
Functions
Body
Electronics
Driving and Vehicle
Dynamic Functions
Information
Systems
Telematics
Electronics for the Car: A Distributed System
Steer by
Wire
Shift by
Wire
Engine
Management
Brake
by Wire
FlexRay
Chess/IAB 29
Picoradio Sensor Networks (BWRC)

Control Environmental parameters (temperature, humidity…)
Minimize Power consumption
Cheap (<0.5$) and small ( < 1 cm3)

Large numbers of nodes — between 0.05 and 1 nodes/m2

Limited operation range of network — maximum 50-100 m
Low data rates per node — 1-10 bits/sec average
Low mobility (at least 90% of the nodes stationary)

actuator
sensor
controller



• Key challenges
– Satisfy tight performance and cost constraints (especially power
consumption)
– Identify Layers of Abstraction (Protocol Stack)
– Develop distributed algorithms (e.g. locationing, routing) for
ubiquitous computing applications
– Design Embedded System Platform to implement Protocol Stack
efficiently
Chess/IAB 30
ASV Triangles
Application Space
Application Instance
Platform
Mapping
System
Platform (HW and SW)
Platform
Design-Space
Export
Platform Instance
Architectural Space
Chess/IAB 31
Platforms: Evolution
In general, a platform is an abstraction layer that
covers a number of possible refinements into a
lower level. The platform representation is a
library of components including interconnects
from which the lower level refinement can choose.
Platform stack
{
Platform
Mapping Tools
Platform
Chess/IAB 32
Principles of Platform methodology:
Meet-in-the-Middle
• Top-Down:
– Define a set of abstraction layers
– From specifications at a given level, select a
solution (controls, components) in terms of
components (Platforms) of the following layer
and propagate constraints
• Bottom-Up:
– Platform components (e.g., micro-controller,
RTOS, communication primitives) at a given level
are abstracted to a higher level by their
functionality and a set of parameters that help
guiding the solution selection process. The
selection process is equivalent to a covering
problem if a common semantic domain is used.
Chess/IAB 33
Network Design Using Platforms
Application components
Requirements
Components Adaptation
Communication Refinement
(Protocol Stack + Gateways)
Embedded System Platform
On-Chip Networks
Chess/IAB 34
Current Research Focus Areas
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Interfaces theories for component-based design
Meta-modeling (models of modeling strategies)
Principles of actor-oriented design
Software architectures for actor-oriented design
Automotive systems design
Avionics systems design
Virtual machines for embedded software
Semantic models for time and concurrency
Design transformation technology (code generation)
Visual syntaxes for design
Application-specific processors
Platform-based Design
• Mobies • Ptolemy
• SEC
• Mescal
Fault Tolerance
• ISIS
• Metropolis
Synchronous-Asynchronous
• Giotto • Bear
Chess/IAB 35
Impact on Education –
Intellectual Groupings in EECS
Multimedia
Robotics, Vision
Discrete-event systems
Simulation
Real-time systems
Concurrent software
Networks
Communications
Information theory
Queueing theory
Signal processing
EIS
Languages
CS
Complexity
Automata
Software engineering
Compilers
Operating systems
Algorithms
Graphics
User interfaces
Databases
Artificial Intelligence
Linear systems
Control
Nonlinear systems
EE
Circuits
Electronics
Devices
Process technology
E&M
Power systems
Plasmas
Quantum & Optical
Architecture
CAD for VLSI
Configurable systems
Chess/IAB 36
Education Changes –
The Starting Point
Berkeley has a
required sophomore
course that
addresses
mathematical
modeling of signals
and systems from a
computational
perspective.
The web page at the
right illustrates a broad
view of feedback, where
the behavior is a fixed
point solution to a set of
equations. This view
covers both traditional
continuous feedback and
discrete-event systems.
Chess/IAB 37
Themes of the Course
• The connection between imperative
and declarative descriptions of
signals and systems.
• The use of sets and functions as a
universal language for declarative
descriptions of signals and
systems.
• State machines and frequency
domain analysis as complementary
tools for designing and analyzing
signals and systems.
• Early and often discussion of
applications.
Brain response when seeing a
discrete Fourier series.
Chess/IAB 38
A set of Graduate Courses
•
•
•
•
•
EE249: Design of Embedded Systems
EE290O: Embedded Software Design
EE291E: Hybrid Systems
EE290N: Concurrent Models of Computation
CS298-4: Formal Methods for Software
Reliability
• CS290A: Ubiquitous Systems
• CS290D: Oceanic Systems
• EECS290F: Dependable Computing and
National Security
Chess/IAB 39
EE249: “Embedded System Design”
A graduate 4 unit system design course:
• Emphasis on understanding of system design
– The basic mathematical models representing system
behavior independent of implementation
– Implementation as choice of architecture
– Architecture as platform
– Mapping of behavior into architecture as an exercise in
design exploration
– Software and hardware seen uniformly
Chess/IAB 40
Behavior Vs. Architecture
Performance models:
Emb. SW, comm. and
comp. resources
Models of
Computation
1
System
Behavior
System 2
Architecture
HW/SW
partitioning
,
Scheduling
SW
estimation
Mapping
Synthesis
3
Performance
Simulation
Communication
Refinement
4
Flow To Implementation
Chess/IAB 41
Behavior Vs. Communication
• Clear separation between functionality and
interaction model
• Maximize reuse in different environments,
change only interaction model
Chess/IAB 42
Outline of the course
• Part 1: Introduction: Future of Information
Technology, System Design, IP-based Design,
System-on-Chip and Industrial Trends
• Part 2: Design Methodology
• Part 3: Models of Computation
• Part 4: The Ptolemy, POLIS, Matlab and VCC
Systems
• Part 5: Verification and Synthesis, Hardware
and Software
• Part 6: Communication-based Design
Chess/IAB 43
Conclusion
We are on the line to build a new system
science that is at once physical and
computational.
It will form the foundation for our
understanding of computational systems
that engage the physical world.
And it will change how we teach, research
and engineer systems.
Chess/IAB 44