Embedded Systems Designretis.sssup.it/~marco/files/lesson0-introduction.pdf · Course Plan •...
Transcript of Embedded Systems Designretis.sssup.it/~marco/files/lesson0-introduction.pdf · Course Plan •...
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