ptolemy ii the automotive challenge problems version 4.1
DESCRIPTION
Ptolemy II The automotive challenge problems version 4.1. Johan Eker Edward Lee with thanks to Jie Liu, Paul Griffiths, and Steve Neuendorffer. Overview. Yellowstone recap Selected challenge problems 1.1 Multiple-view modeling 1.2 Automated composition of subcomponents - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Ptolemy II The automotive challenge problems version 4.1](https://reader036.vdocument.in/reader036/viewer/2022062808/56815367550346895dc16c86/html5/thumbnails/1.jpg)
MoBIES Working group meeting, 27-28 September 2001, Dearborn
Ptolemy II The automotive challenge
problems version 4.1
Johan Eker
Edward Lee
with thanks to Jie Liu,
Paul Griffiths, and Steve Neuendorffer
![Page 2: Ptolemy II The automotive challenge problems version 4.1](https://reader036.vdocument.in/reader036/viewer/2022062808/56815367550346895dc16c86/html5/thumbnails/2.jpg)
Eker & Lee, UC Berkeley 2
Overview
Yellowstone recap Selected challenge problems
1.1 Multiple-view modeling 1.2 Automated composition of subcomponents 3.3 Code generation
![Page 3: Ptolemy II The automotive challenge problems version 4.1](https://reader036.vdocument.in/reader036/viewer/2022062808/56815367550346895dc16c86/html5/thumbnails/3.jpg)
Eker & Lee, UC Berkeley 3
Yellowstone recap:Design of embedded control systems
Different phases, different tools, different people makes it difficult to debug: Control engineer view
plant dynamics, stability, phase margins, rise time, etc. assumes: equidistant sampling with no or little latency
Embedded system engineer view scheduling, priorities, memory usage, communication
setup, etc assumes: fixed controller design
A good toolset supports close interaction between the different phases/teams
The only interesting performance metric is the behavior of the controlled system
![Page 4: Ptolemy II The automotive challenge problems version 4.1](https://reader036.vdocument.in/reader036/viewer/2022062808/56815367550346895dc16c86/html5/thumbnails/4.jpg)
Eker & Lee, UC Berkeley 4
“Classical” development cycle
Sign-offs are expensive Feedback slow
Specifications
Contro l a lgorithmdesign
Contro l designsign-off
Softw are design
Functionaltesting
Softw are designsign-off
![Page 5: Ptolemy II The automotive challenge problems version 4.1](https://reader036.vdocument.in/reader036/viewer/2022062808/56815367550346895dc16c86/html5/thumbnails/5.jpg)
Eker & Lee, UC Berkeley 5
Closing the “system design/control design” loop
system design
control design
hardware setupcommunication prioritiesRTOS tuning
controller parametersdelay compensationreviewing specs
evaluate system performance
evaluate system performance
![Page 6: Ptolemy II The automotive challenge problems version 4.1](https://reader036.vdocument.in/reader036/viewer/2022062808/56815367550346895dc16c86/html5/thumbnails/6.jpg)
Eker & Lee, UC Berkeley 6
Idealized Model
Assumes equidistant sampling constant latency
More realistic model
Multitasking
jitter, execution time
RTOS domain
Communication
Transport, routing, medium access
![Page 7: Ptolemy II The automotive challenge problems version 4.1](https://reader036.vdocument.in/reader036/viewer/2022062808/56815367550346895dc16c86/html5/thumbnails/7.jpg)
Eker & Lee, UC Berkeley 7
1.1 Multi-view modeling
Different granularity models Level 1: Hybrid automata w/ cont. dynamics Level 2: Discrete controllers and some scheduling info Level 3: Platform specific info
Component refinement Start with a naïve implementation and make it gradually
more complex Ptolemy II
Component based Hierarchical & heterogeneous Functional behavior & control flow decoupled through
the use of directors Composite actors treated like atomic
![Page 8: Ptolemy II The automotive challenge problems version 4.1](https://reader036.vdocument.in/reader036/viewer/2022062808/56815367550346895dc16c86/html5/thumbnails/8.jpg)
Eker & Lee, UC Berkeley 8
Multi-view modeling in Ptolemy II
continuous time
finite-state machine
discrete time
Hierarchical, heterogeneous model
![Page 9: Ptolemy II The automotive challenge problems version 4.1](https://reader036.vdocument.in/reader036/viewer/2022062808/56815367550346895dc16c86/html5/thumbnails/9.jpg)
Eker & Lee, UC Berkeley 9
Component refinement in Ptolemy IIExample model 1
![Page 10: Ptolemy II The automotive challenge problems version 4.1](https://reader036.vdocument.in/reader036/viewer/2022062808/56815367550346895dc16c86/html5/thumbnails/10.jpg)
Eker & Lee, UC Berkeley 10
Component refinement in Ptolemy IIExample model 2
![Page 11: Ptolemy II The automotive challenge problems version 4.1](https://reader036.vdocument.in/reader036/viewer/2022062808/56815367550346895dc16c86/html5/thumbnails/11.jpg)
Eker & Lee, UC Berkeley 11
Composite actors
From top level view: the behavioral semantics of the component has not changed!
Aggregation not just syntactical Composite actor is opaque
![Page 12: Ptolemy II The automotive challenge problems version 4.1](https://reader036.vdocument.in/reader036/viewer/2022062808/56815367550346895dc16c86/html5/thumbnails/12.jpg)
Eker & Lee, UC Berkeley 12
1.2 Automated composition of sub-components
What is the actual problem? Example: Many states and many signals in a Stateflow +
Simulink gets means and whole lot of wiring
Lack of proper aggregation! Ptolemy addresses the problem through
hierarchy Smarter editor vs. new languages
![Page 13: Ptolemy II The automotive challenge problems version 4.1](https://reader036.vdocument.in/reader036/viewer/2022062808/56815367550346895dc16c86/html5/thumbnails/13.jpg)
Eker & Lee, UC Berkeley 13
The ModalModel in Ptolemy II
Wiring of the state refinements is done automatically,
All wires are hidden under the hood
![Page 14: Ptolemy II The automotive challenge problems version 4.1](https://reader036.vdocument.in/reader036/viewer/2022062808/56815367550346895dc16c86/html5/thumbnails/14.jpg)
Eker & Lee, UC Berkeley 14
3.3 Code generation
From Java to Java & Java to C at Maryland Actor libraries are built and maintained in Java
polymorphic libraries are rich and small
Collapsing composite actors to atomic actors Director + actors => actor
Efficiency gotten through code transformations specialization of polymorphic types code substitution using MoC semantics removal of unnecessary code
![Page 15: Ptolemy II The automotive challenge problems version 4.1](https://reader036.vdocument.in/reader036/viewer/2022062808/56815367550346895dc16c86/html5/thumbnails/15.jpg)
Eker & Lee, UC Berkeley 15
Outline of our Approach
Model of Computation semantics defines communication, flow of control
Ptolemy II model
scheduler
Schedule:
- fire Gaussian0
- fire Ramp1
- fire Sine2
- fire AddSubtract5
- fire SequenceScope10
parser
method call
if
block
method call
block
…
for (int i = 0; i < plus.getWidth(); i++) {
if (plus.hasToken(i)) {
if (sum == null) {
sum = plus.get(i);
} else {
sum = sum.add(plus.get(i));
}
}
}
…
All actors are given in Java, then translated to embedded Java, C, VHDL, etc. target codeabstract syntax tree
Jeff Tsay, Christopher Hylands, Steve Neuendorffer
![Page 16: Ptolemy II The automotive challenge problems version 4.1](https://reader036.vdocument.in/reader036/viewer/2022062808/56815367550346895dc16c86/html5/thumbnails/16.jpg)
Eker & Lee, UC Berkeley 16
Conclusions
Hierarchically heterogeneous modeling matches the applications well.
Component based technologies and hierarchical heterogeneity gives good support for Multi-view modeling Piecewise refinement
Tool integration as a more fundamental problem About designing the proper protocol for communication
between subsystems