Embedded Systems Design

Course Plan

• Intro to ES, V-model and Model-based Design

• Project intro

• Requirements and Functional Testing

• Project step1 – Requirements and test plan

• Models and systems

• FSMs part1

• Communication buses – event driven - Controller Area Network

• Project step2 – Intro to Flex, programming IDE, Erika, Device drivers

• FSMs part2

• Communication buses – time driven – FlexRay

• FSMs part3

• Extensions to FSMs – Statecharts

• Project step3 – Models

• Timed automata

• An Introduction to Uppaal and verification

• Project step4 – Verification

• Translating an FSM into code: Part 1

• Statecharts in practice – Mathworks Stateflow

• Translating an FSM into code: Part 2

• Automatic code generation with Mathworks tools

• Project step5 – Production of Code

• Conformance testing

• Structural testing – coverage

• Project step6 – Testing

• Advanced topic: semantics preservation in multiprogramming implementations

• Advanced topic: component-based design and AUTOSAR

Course organization and evaluation

• Evaluation is based on

– Project: development of simple application on Flex board

using model-based derivation techniques. Teams of 4.

Each member of the team must be capable of discussing the project steps. 40%

– Discussion of a research paper. Individual, randomly

selected paper 20%

– Final test. 40%

• Available Projects

– Elevator controller mockup (all)

– Elevator subsystem (pick one)

– Interface prototyping (Linux with Qt or Microchip)

Embedded systems

From Wikipedia

• An embedded system is a special-purpose computer

system designed to perform one or a few dedicatedfunctions, sometimes with real-time computing

constraints. It is usually embedded as part of a complete device including hardware and mechanical parts. In

contrast, a general-purpose computer, such as a

personal computer, can do many different tasksdepending on programming.

• Since the embedded system is dedicated to specifictasks, design engineers can optimize it, reducing the

size and cost of the product, or increasing the reliabilityand performance.

Embedded systems

• Embedded = Dedicated

• Interaction with physical processes

– sensors, actuators, processes

• Critical properties are not all functional

– real-time, fault recovery, power, security, robustness

• Heterogeneity

– hardware/software tradeoffs, mixed architectures

• Concurrency

– interaction with multiple processes

• Reactivity

– operating at the speed of the environment

• Resource constrained– Because of cost, energy, space

(source Edward Lee – UC Berkeley)

Timing constraints(latency, jitter)

Heterogeneous models,

methods, tools

Resource sharing,

scheduling

The V-shape development cycle (V-model)

User Requirements Validation

Functional Specifications

Functional modeling

Architecture Exploration

Component modeling

Behavior modeling

Coding

System verification

Module testing

Integration testing

A development cycle

What’s special in the V-model?

User Requirements

Functional specs

Functional design

Architecture selection

Component/Module design

Coding

Integration testing

System verification

System validation

Module testing

A cascade model highlighting correspondence between development and test

A cascade model highlighting correspondence between development and test

Model-based design

On August 19, 1418, a competition was announced in Florence, where the city’s

magnificent new cathedral, Santa Maria del Fiore, had been under construction

for more than a century

Whoever desires to make any model or design for the vaulting of the main Dome of the Cathedral under construction by the Opera del Duomo-for armature, scaffolding or other thing, or any lifting device pertaining to the construction and perfection of said cupola or vault shall do so before the end of the month of September. If the model be used he shall be entitled to a payment of 200 gold Florins.

On August 19, 1418, a competition was announced in Florence, where the city’s

magnificent new cathedral, Santa Maria del Fiore, had been under construction

for more than a century

Whoever desires to make any model or design for the vaulting of the main Dome of the Cathedral under construction by the Opera del Duomo-for armature, scaffolding or other thing, or any lifting device pertaining to the construction and perfection of said cupola or vault shall do so before the end of the month of September. If the model be used he shall be entitled to a payment of 200 gold Florins.

From Brunelleschi's Dome: How a Renaissance Genius Reinvented Architecture by Ross King

Model-based design

Engineering has made use of models since its very early days

Engineering has made use of models since its very early days

Filippo Brunelleschi's design for the dome of the cathedral

of Santa Maria del Fiore in Florence remains one of the most towering achievements of Renaissance architecture.

Completed in 1436, the dome remains a remarkable feat of design and engineering. Its span of more than 140 feet

exceeds St Paul's in London and St Peter's in Rome, and even outdoes the Capitol in Washington, D.C., making it the largest dome ever constructed using bricks and mortar.

When work on the dome began in 1420 Brunelleschi was virtually unknown. Sixteen years later the dome was built,

and its architect was a superstar.

Filippo Brunelleschi's design for the dome of the cathedral

of Santa Maria del Fiore in Florence remains one of the most towering achievements of Renaissance architecture.

Completed in 1436, the dome remains a remarkable feat of design and engineering. Its span of more than 140 feet

exceeds St Paul's in London and St Peter's in Rome, and even outdoes the Capitol in Washington, D.C., making it the largest dome ever constructed using bricks and mortar.

When work on the dome began in 1420 Brunelleschi was virtually unknown. Sixteen years later the dome was built,

and its architect was a superstar.

Model-based design

• The four tenets on the right are fundamental to model-based design

• Key is: test, verification, simulation, validation

• Why automatic code generation?

• Of course, you must select a modeling language that allows to do everything in the most natural and easy way …

by Ali Behboodian, DSP Magazine

• Design (continued): matching the logical design into the SW architecture design

Dispenser

«boundary»Valve

status

open

close

«boundary»Holster Switch

status

«boundary»Flowmeter

count

«boundary»Motor

status

stop

start

«auxiliary» {semantics = controls EH Unit}EH Unit

active

EH id

nozzle removed

dispensing authorised

halt

resume

fuel pulse

nozzle replaced

«focus»Dispenser

dispenser number

transaction fuel price

active EH id

fuel_grade

abort

get transaction details

halt

get fuel price

request service

dispensing authorised

resume

dispensing completed

«boundary»Dispenser Display

perform display check

freeze display

update display

«entity» {persistence = transitory}Fuel Transaction

litres dispensed

price per litre

total cost

create

collect details

destroy

add 5ml

«entity» {persistence = persistent}Fuel Observer

price per litre

grade

set price

get price

«boundary»Valve

status

open

close

«boundary»Holster Switch

status

«boundary»Flowmeter

count

«boundary»Motor

status

stop

start

«auxiliary» {semantics = controls EH Unit}EH Unit

active

EH id

nozzle removed

dispensing authorised

halt

resume

fuel pulse

nozzle replaced

«focus»Dispenser

dispenser number

transaction fuel price

active EH id

fuel_grade

abort

get transaction details

halt

get fuel price

request service

dispensing authorised

resume

dispensing completed

«boundary»Dispenser Display

perform display check

freeze display

update display

«entity» {persistence = transitory}Fuel Transaction

litres dispensed

price per litre

total cost

create

collect details

destroy

add 5ml

«entity» {persistence = persistent}Fuel Observer

price per litre

grade

set price

get price

Kiosk

«entity» {persistence = persistent}Fuel

price per litre

grade

set price

get price

«boundary»EPOS

process transaction

Kiosk Controller

fuel price

fuel amount

fuel grade

transaction amount

select grade

new price information

payment due

dispensing authorized

display fuel price

request service

halt dispensing

resume dispensing

select dispenser

abort transaction

collect transaction

«boundary»Keyboard Unit

«boundary»Kiosk Display

display transaction details

display dispenser idle

display dispensing authorised

dispensing suspended

display service request

display payment due

display fuel price

clear

Fuel Change Manager

notify

«entity» {persistence = persistent}Fuel

price per litre

grade

set price

get price

«boundary»EPOS

process transaction

Kiosk Controller

fuel price

fuel amount

fuel grade

transaction amount

select grade

new price information

payment due

dispensing authorized

display fuel price

request service

halt dispensing

resume dispensing

select dispenser

abort transaction

collect transaction

«boundary»Keyboard Unit

«boundary»Kiosk Display

display transaction details

display dispenser idle

display dispensing authorised

dispensing suspended

display service request

display payment due

display fuel price

clear

Fuel Change Manager

notify

1

1

fuel type available at

3

1

gets price fromtheObserver

1

1

myMotor

1

3

updated by

fuelPrice

3 1

myDispensermyEHUnits

0..1 1active

theDispenseractiveEH

1

1

sends trans. details to

theEPOS

1

1myEH

mySwitch

1

1

myMeter

0..1 1

1

1

dDisplay

11..16 controlled by

aDispenser theKiosk

1 1

myController

1

1

theDisplay

2 1

myValves

11..16

updated by

1

1

notifies

theManagerthePrice

This Class Diagram is an early, pre-task design view of class relationships, based on the Object design interaction models.

This diagram would be considerably enhanced as further implementation detail was added.

the 'active' EH Unit is one of the

aggregate EH Units of the Dispenser

RTOS

Threads (tasks)Threads (tasks)Resources

RTOS API

Task and

resource

model

Timing attributes (fromplatform deployment)

Timing constraints (fromfunctional model)

RTS and Platform-Based Design

End of introduction

• Questions/Issues?

Models and implementation: Simulink

Where are the tasks?

Models and implementation: UML

Dispenser

«boundary»Valve

status

open

close

«boundary»Holster Switch

status

«boundary»Flowmeter

count

«boundary»Motor

status

stop

start

«auxiliary» {semantics = controls EH Unit}EH Unit

active

EH id

nozzle removed

dispensing authorised

halt

resume

fuel pulse

nozzle replaced

«focus»Dispenser

dispenser number

transaction fuel price

active EH id

fuel_grade

abort

get transaction details

halt

get fuel price

request service

dispensing authorised

resume

dispensing completed

«boundary»Dispenser Display

perform display check

freeze display

update display

«entity» {persistence = transitory}Fuel Transaction

litres dispensed

price per litre

total cost

create

collect details

destroy

add 5ml

«entity» {persistence = persistent}Fuel Observer

price per litre

grade

set price

get price

«boundary»Valve

status

open

close

«boundary»Holster Switch

status

«boundary»Flowmeter

count

«boundary»Motor

status

stop

start

«auxiliary» {semantics = controls EH Unit}EH Unit

active

EH id

nozzle removed

dispensing authorised

halt

resume

fuel pulse

nozzle replaced

«focus»Dispenser

dispenser number

transaction fuel price

active EH id

fuel_grade

abort

get transaction details

halt

get fuel price

request service

dispensing authorised

resume

dispensing completed

«boundary»Dispenser Display

perform display check

freeze display

update display

«entity» {persistence = transitory}Fuel Transaction

litres dispensed

price per litre

total cost

create

collect details

destroy

add 5ml

«entity» {persistence = persistent}Fuel Observer

price per litre

grade

set price

get price

Kiosk

«entity» {persistence = persistent}Fuel

price per litre

grade

set price

get price

«boundary»EPOS

process transaction

Kiosk Controller

fuel price

fuel amount

fuel grade

transaction amount

select grade

new price information

payment due

dispensing authorized

display fuel price

request service

halt dispensing

resume dispensing

select dispenser

abort transaction

collect transaction

«boundary»Keyboard Unit

«boundary»Kiosk Display

display transaction details

display dispenser idle

display dispensing authorised

dispensing suspended

display service request

display payment due

display fuel price

clear

Fuel Change Manager

notify

«entity» {persistence = persistent}Fuel

price per litre

grade

set price

get price

«boundary»EPOS

process transaction

Kiosk Controller

fuel price

fuel amount

fuel grade

transaction amount

select grade

new price information

payment due

dispensing authorized

display fuel price

request service

halt dispensing

resume dispensing

select dispenser

abort transaction

collect transaction

«boundary»Keyboard Unit

«boundary»Kiosk Display

display transaction details

display dispenser idle

display dispensing authorised

dispensing suspended

display service request

display payment due

display fuel price

clear

Fuel Change Manager

notify

1

1

fuel type available at

3

1

gets price fromtheObserver

1

1

myMotor

1

3

updated by

fuelPrice

3 1

myDispensermyEHUnits

0..1 1active

theDispenseractiveEH

1

1

sends trans. details to

theEPOS

1

1myEH

mySwitch

1

1

myMeter

0..1 1

1

1

dDisplay

11..16 controlled by

aDispenser theKiosk

1 1

myController

1

1

theDisplay

2 1

myValves

11..16

updated by

1

1

notifies

theManagerthePrice

This Class Diagram is an early, pre-task design view of class relationships, based on the Object design interaction models.

This diagram would be considerably enhanced as further implementation detail was added.

the 'active' EH Unit is one of the

aggregate EH Units of the Dispenser

Where are the tasks?

Models and implementation: UML

Models and implementation: FSM

Some things are there … maybe not in plain sight