Center for Hybrid and Embedded Software Systems - PowerPoint PPT Presentation

Loading...

PPT – Center for Hybrid and Embedded Software Systems PowerPoint presentation | free to view - id: 6ba277-YTU5Y



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Center for Hybrid and Embedded Software Systems

Description:

Center for Hybrid and Embedded Software Systems College of Engineering, University of California at Berkeley Presented by: Alberto Sangiovanni Vincentelli – PowerPoint PPT presentation

Number of Views:45
Avg rating:3.0/5.0
Slides: 45
Provided by: Edwar117
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Center for Hybrid and Embedded Software Systems


1
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_at_eecs.berkeley.edu Edward A. Lee,
eal_at_eecs.berkeley.edu Alberto Sangiovanni-Vincente
lli, alberto_at_eecs.berkeley.edu Shankar Sastry,
sastry_at_eecs.berkeley.edu Other key faculty Alex
Aiken, aiken_at_eecs.berkeley.edu Dave Auslander,
dma_at_me.berkeley.edu Ruzena Bajcsy,
ruzena_at_eecs.berkeley.edu Karl Hedrick,
khedrick_at_me.berkeley.edu Kurt Keutzer,
keutzer_at_eecs.berkeley.edu George Necula,
necula_at_eecs.berkeley.edu Masayoshi Tomizuka,
tomizuka_at_me.berkeley.edu Pravin Varaiya,
varaiya_at_eecs.berkeley.edu
2
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

3
Mission of Chess
  • To provide an environment for graduate research
    on the design issues necessary for supporting
    next-generation embedded software systems.
  • Model-based design
  • Tool-supported methodologies
  • For
  • Real-time
  • Fault-tolerant
  • Robust
  • Secure
  • Heterogeneous
  • Distributed
  • Software Systems

The fate of computers lacking interaction with
physical processes.
4
French Guyana, June 4, 1996
800 million embedded software failure
5
Mars, December 3, 1999
Crashed due to un-initialized variable
6
4 billion development effort
40-50 system integration validation cost
7
Complexity, Quality, Time-to-Market TODAY
TELEMATIC UNIT
INSTRUMENT CLUSTER
PWT UNIT
BODY GATEWAY
C CODE
FABIO ROMEO, Magneti-Marelli Design Automation
Conference, Las Vegas, June 20th, 2001
8
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)
Source of Industry Data Capers Jones(2000)
Software Assessments, Benchmarks, and Best
Practices, Addison-Wesley.
9
Embedded Software Architecture Today
10
Embedded Software Future?
11
The Goal
  • To create a modern computational systems science
    and systems design practice with
  • Concurrency
  • Composability
  • Time
  • Hierarchy
  • Heterogeneity
  • Resource constraints
  • Verifiability
  • Understandability

12
A Traditional Systems Science Feedback Control
Systems
  • Models of continuous-time dynamics
  • Stability analysis
  • But not accurate for software controllers

13
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 its still not accurate for software
    controllers

14
Hybrid Systems Reconciliation of Continuous
Discrete
  • UCB researchers have contributed substantially to
    the theory and practice of blended discrete
    continuous models.
  • But its still not accurate for software
    controllers

15
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?
16
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
17
Whats 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
  • Cant hide resources

Source Alex Aiken
18
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.

19
How Safe is Our Real-Time Software?
20
Another Traditional Systems Science -
Computation, Languages, and Semantics
  • Everything computable can be given by a
    terminating sequential program.
  • Functions on bit patterns
  • Time is irrelevant
  • Non-terminating programs are defective

sequence
f States ? States
States Bits
results state out
21
Current fashion Pay Attention to
Non-functional properties
  • Time
  • Security
  • Fault tolerance
  • Power consumption
  • Memory management
  • But the formulation of the question is very
    telling

22
What about real time?
23
Processes and Process Calculi
Infinite sequences of state transformations are
called processes or threads
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.
incoming message
outgoing message
24
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
25
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
ill-defined composition.
26
Compositionality
Non-compositional formalisms lead to very awkward
architectures.
27
Real-Time Multitasking?
28
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.

29
Electronics for the Car A Distributed System
InformationSystems
Today, more than 80 Microprocessors and millions
of lines of code
Mobile Communications
Navigation
Telematics
Fault Tolerant
Access to WWW
MOSTFirewire
DAB
FireWall
Body Electronics
Theft warning
AirConditioning
BodyFunctions
CANLin
Door Module
Light Module
Fail Safe
GateWay
Body Electronics
ABS
CANTTCAN
Shift by Wire
EngineManagement
Driving and VehicleDynamic Functions
GateWay
Fault Functional
Steer by Wire
Brake by Wire
FlexRay
30
Picoradio Sensor Networks (BWRC)
  • 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

31
ASV Triangles

Application Space
Application Instance
Platform Mapping
System
Platform (HW and SW)
Platform Design-Space Export
Platform Instance
Architectural Space
32
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.
33
Principles of Platform methodologyMeet-in-the-Mi
ddle
  • 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.

34
Network Design Using Platforms
Application components Requirements
Components Adaptation
Communication Refinement (Protocol Stack
Gateways)
35
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
  • Fault Tolerance
  • Synchronous-Asynchronous
  • Mobies
  • SEC
  • ISIS
  • Giotto
  • Ptolemy
  • Mescal
  • Metropolis
  • Bear

36
Impact on Education Intellectual Groupings in
EECS
Multimedia
Communications
Robotics, Vision
Information theory
Discrete-event systems
Queueing theory
Simulation
Signal processing
Real-time systems
Concurrent software
EIS
Linear systems
Networks
Control
Nonlinear systems
CS
Languages
Complexity
EE
Automata
Software engineering
Circuits
Compilers
Electronics
Operating systems
Devices
Algorithms
Process technology
Graphics
E M
User interfaces
Power systems
Databases
Plasmas
Artificial Intelligence
Quantum Optical
Architecture
CAD for VLSI
Configurable systems
37
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.
38
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.
39
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

40
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

41
Behavior Vs. Architecture
Performance models Emb. SW, comm. and comp.
resources
Models of Computation
1
HW/SW partitioning, Scheduling
2
System Behavior
System Architecture
Mapping
3
SW estimation
Performance Simulation
Synthesis
Communication Refinement
4
Flow To Implementation
42
Behavior Vs. Communication
  • Clear separation between functionality and
    interaction model
  • Maximize reuse in different environments, change
    only interaction model

43
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

44
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.
About PowerShow.com