Design of Embedded Systems: Methodologies ... - Semantic Scholar

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


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


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


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


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