Management. ABS. Steer by. Wire. Brake by Wire. MOST. Firewire. CAN. Lin. CAN. TTCAN. FlexRay. Today, more than 80. Micr
Design of Embedded Systems: Methodologies, Tools and Applications Alberto Sangiovanni-Vincentelli Dept. of EECS University of California Berkeley
NSF UC Berkeley: Chess Vanderbilt University: ISIS University of Memphis: MSI
Foundations of Hybrid and Embedded Software Systems
Disaggregation:
Electronic Systems Design Chain
Design Science System Design Platforms
Implementation Fabrics
IP Interfaces
Manufacturing
Chess/ISIS/MSI 2
1
Outline • Automotive Applications • Distributed System Design Methodology and Flow • Platform-based Design • UAV Control Example • Metropolis
Chess/ISIS/MSI 3
The Automotive Electronic Design Chain
Product Product Definition Definition Platforms Design Design And And Assembly Assembly
IP IP Interfaces
Chess/ISIS/MSI 4
2
Automotive Supply Chain: Car Manufacturers
y Product Specification & Architecture Definition (e.g., determination of Protocols and Communication standards) y System Partitioning and Subsystem Specification y Critical Software Development y System Integration Chess/ISIS/MSI 5
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/ISIS/MSI 6
3
Automotive Supply Chain: Tier 1 Subsystem Providers 1 2 3 4 5 6/7 8 9 10 11
Transmission ECU Actuation group Engine ECU DBW Active shift display Up/Down buttons City mode button Up/Down lever Accelerator pedal position sensor Brake switch
Subsystem Partitioning Subsystem Integration Software Design: Control Algorithms, Data Processing Physical Implementation and Production Chess/ISIS/MSI 7
Automotive Supply Chain: Tier 2 Platform & IP Providers Application Application Platform Platform layer layer (≅ (≅ 10% 10% of of total total SW) SW)
SW SW Platform Platform layer layer (> (> 60% 60% of of total total SW) SW)
OSEK RTOS
--------------Water temp. Odometer Tachometer Tachometer Speedometer Speedometer
Application Libraries
Customer Libraries Application Specific Software
CCP KWP 2000 Transport
OSEK COM I/O drivers & handlers Sys. Config. (> 20 configurable modules) Boot Loader Application Programming Interface
µControllers Library HW HW layer layer
Nec78k Nec78k
HC08 HC08
HC12 HC12
H8S26 H8S26
MB90 MB90
ST10 ST10
“Software” platform: RTOS and communication layer “Hardware” platform: Hardware and IO drivers Chess/ISIS/MSI 8
4
Complexity, Quality, Time-to-Market: TODAY INSTRUMENT CLUSTER
TELEMATIC UNIT
128 KB
184 KB
8 MB
50.000
30.000
45.000
300.000
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
PWT UNIT
BODY GATEWAY
MEMORY
256 KB
LINES OF CODE PRODUCTIVITY RESIDUAL DEFECT RATE @ END OF DEV
* C++ CODE
FABIO ROMEO, Magneti-Marelli Design Automation Conference, Las Vegas, June 20th, 2001
Chess/ISIS/MSI 9
Embedded Software Design: Our 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/ISIS/MSI 10
5
Outline • Automotive Applications • Distributed System Design Methodology and Flow • Platform-based Design • UAV Control Example • Metropolis
Chess/ISIS/MSI 11
Virtual Integration is key for Distributed System Design Functionalanalysis Network Definition and Fctn Fct1 Validation (Timed and un-Timed)
Fctn
Fct1
ECU SW Scheduling Adoption Spec Spec and Validation & & Sim. Sim.
Spec & Sim.
specification
Spec & Sim.
Virtual
virtual
Communication Protocol Adoption and Validation
ECU1
Integration
Integration
implementation
real
Safety Concept Proof via Fault Injection
system design
ECUn
ECU Optimization/Derivative Integration ECU1 calibration Design
ECUk
production & after sales
now
tomorrow Source BMW
Chess/ISIS/MSI 12
6
Design Flow
Requirement Requirement Specification Specification
Algorithm Specifications
Algorithm Algorithm Analysis Analysis
Environment-Test Environment-Test Bench Bench Modeling Modeling
Algorithm Algorithm Design Design Algorithms
Behavioral Modeling
Architectural Architectural Modeling Modeling
Behavior IPs
Architectural IPs
Virtual Prototyping
Architecture Architecture IP IP Authoring Authoring
Mapping Mapping Distributed Distributed Architecture Architecture Analysis Analysis ECU ECU Scheduling Scheduling Analysis Analysis Algorithm Algorithm Performance Performance
Performance Performance Simulation Simulation
Synthesis Synthesis Export Export
System Model
SW platform
SW tasks
Physical Prototyping Communication Protocol Configuration
Load Load
Compile/Link Compile/Link /Load /Load
Chess/ISIS/MSI 13
Focus on Safety-Critical Real Time • Most challenging problem • Needs tight integration between algorithms and implementation • Constraints include timing and fault tolerance • Fault tolerance can be addressed at all levels of abstraction
Chess/ISIS/MSI 14
7
Safety Critical Issues: Fault Analysis
CPU+
Sensors Actuators
RAM
Safety Concept Proof via Fault Injection (HW, SW, Bus..) Bus Interface Tasks
HW Int.
OS Host (uC)
Task1
Communication Controller (CC)
Task2
Dev. Driv.
Bus Guardian (BG)
I/O CPU
f f fNetwork f
Bus Driver (BD)
f
Chess/ISIS/MSI 15
DRAFTS: Distributed Real-time Applications Fault Tolerant Scheduling • Automatic (off-line) synthesis of fault tolerant schedules for periodic algorithms on a distributed architecture • Automatic (off-line) verification that all intended faults are covered Long-term goals: • Design Methodology for Safety Critical Distributed Systems • Manage the design complexity of modern DriveBy-Wire applications C. Pinello, UCB, T. Demmeler and J. Ehret, BMW Chess/ISIS/MSI 16
8
DRAFTS Strategy • Identify critical functionality and possible faults • Replicate critical functionality to withstand faults • Exploit architecture redundancy to speedup execution (in absence of faults) • Functional Verification that all intended faults are covered
Chess/ISIS/MSI 17
Outline • Automotive Applications • Distributed System Design Methodology and Flow • Platform-based Design • UAV Control Example • Metropolis
Chess/ISIS/MSI 18
9
ASV Triangles Application Space Application Instance
Platform Mapping
System Platform (HW and SW)
Platform Design-Space Export
Platform Instance
Architectural Space
Chess/ISIS/MSI 19
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/ISIS/MSI 20
10
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/ISIS/MSI 21
Outline • Automotive Applications • Distributed System Design Methodology and Flow • Platform-based Design • UAV Control Example • Metropolis
Chess/ISIS/MSI 22
11
Platform-Based Design of Unmanned Aerial Vehicles (source: J. Liebman)
I
PlatformBased Design
II
III
UAV System
Synchronous Embedded Control
Synchronous Platform Based UAV Design Chess/ISIS/MSI 23
UAV System: R-50 Hovering
GPS Card
GPS Antenna
Sensor Overview
• Goal: basic autonomous flight • Need: UAV with allowable payload • Need: combination of GPS and Inertial Navigation System (INS) • GPS (senses using triangulation) • Outputs accurate position data • Available at low rate & has jamming • INS (senses using accelerometer and rotation sensor) • Outputs estimated position with unbounded drift over time • Available at high rate • Fusion of GPS & INS provides needed high rate and accuracy
INS
Chess/ISIS/MSI 24
12
UAV System:
Sensor Configurations
• Sensors may differ in: • Data formats, initialization schemes (usually requiring some bit level coding), rates, accuracies, data communication schemes, and even data types • Differing Communication schemes requires the most custom written code per sensor Software Request
Software Shared memory
d INS
d GPS
Pull Configuration
INS
GPS
Push Configuration Chess/ISIS/MSI 25
Platform Based Design for UAVs • Goal – Abstract details of sensors, actuators, and vehicle hardware from control applications
Control Applications (Matlab) Synchronous Embedded Programming (Giotto) Application Space
• How? - Synchronous Embedded Programming Language (i.e. Giotto) Platform
Architectural Space Sensors: INS, GPS Actuators: Servo Interface Vehicles: Yamaha R-50/RMax
Chess/ISIS/MSI 26
13
Platform Based Design for UAVs •
•
Device Platform
– Isolates details of sensor/actuators from embedded control programs – Communicates with each sensor/actuator according to its own data format, context, and timing requirements – Presents an API to embedded control programs for accessing sensors/actuators
Language Platform
– Provides an environment in which synchronous control programs can be scheduled and run – Assumes the use of generic data formats for sensors/actuators made possible by the Device Platform
Control Applications (Matlab) Synchronous Embedded Programming (Giotto) Application Space
Language Platform
Architectural Space
Device Platform
Virtual Avionics Sensors: INS, GPS Platform Actuators: Servo Interface Vehicles: Yamaha R-50/RMax
Chess/ISIS/MSI 27
Outline • Automotive Applications • Distributed System Design Methodology and Flow • Platform-based Design • UAV Control Example • Metropolis
Chess/ISIS/MSI 28
14
Metropolis Framework Application-specific methodologies Multi-media, wireless communication, mechanical controls, processors Meta-model Library • Models of computation
Meta-model Library
Infrastructure • Metropolis meta-model
• Architecture platforms
- language - modeling mechanisms • Meta-model compiler
Tools Simulator
QSS
PIG
STARS
SPIN
…
Chess/ISIS/MSI 29
Metropolis Project: main participants etropolis
• UC Berkeley (USA): methodologies, modeling, formal methods • Cadence Berkeley Labs (USA): methodologies, modeling, formal methods • Politecnico di Torino (Italy): modeling, formal methods • Universitat Politecnica de Catalunya (Spain): modeling, formal methods • Philips Research (Netherlands): methodologies (multi-media) • Nokia (USA, Finland): methodologies (wireless communication) • BWRC (USA): methodologies (wireless communication) • BMW (USA): methodologies (fault-tolerant automotive controls) • Intel (USA): methodologies (microprocessors) • STMicroelectronics (France, Italy): methodologies (wireless platforms) • Cypress (USA): methodologies (network processors, pSOC, all projects) Chess/ISIS/MSI 30
15
Metropolis meta-model Concurrent specification with a formal execution semantics: • Computation
: f:X Z
- process : generates a sequence of events
Key difference with respect to • Communication evaluation and manipulation UML,: state SystemC, …!!! - medium : defines states and methods • Coordination
: constraints over concurrent actions
- quantity : annotation of each event (time, energy, memory, …) - logic
: relates events and quantities, defines axioms on quantities
- quantity-manager : algorithm to realize annotation subject to relational constraints Chess/ISIS/MSI 31
Metropolis Meta-Model • Must describe objects at different levels of abstraction – Do not commit to the semantics of any particular model of computation
• Define a set of “building blocks” – specifications with many useful MoCs can be described using the building blocks – Processes, communication media and schedulers separate computation, communication and coordination
Computation
P1 pX
Communication
pZ
M
M’
P2 pX
pZ
M’ S
P1.pZ.write( ) ◆ P2.pX.read( )
Coordination Chess/ISIS/MSI 32
16
Supporting Theory • Provide a semantic foundations for integrating different models of computation – Independent of the design language – Not just specific to the Metropolis meta-model
• Maximize flexibility for using different levels of abstraction – For different parts of the design – At different stages of the design process – For different kinds of analysis
• Support many forms of abstraction – Model of computation (model of time, synchronization, etc.) – Scoping – Structure (hierarchy)
Chess/ISIS/MSI 33
Concluding Remarks • Applications are critical to drive research and to test quality of results • Safety-critical Real Time emphasis • Rigorous methodology for distributed systems • General framework to express designs at all levels of hierarchy and to support integration of foreign tools and designs
Chess/ISIS/MSI 34
17
Embedded Software: Today
Chess/ISIS/MSI 35
Embedded Software: Future?
Chess/ISIS/MSI 36
18