model based systems engineering
DESCRIPTION
Model Based Systems Engineering. Jonathan Sprinkle Center for Hybrid and Embedded Software Systems http://www.eecs.berkeley.edu/~sprinkle/. Overview. Nature/Nurture Motivation Methods Domain-specific modeling Generative techniques Applications (Previous/Possible) Avionics Autonomy - PowerPoint PPT PresentationTRANSCRIPT
Model BasedSystems Engineering
Jonathan SprinkleCenter for Hybrid and Embedded Software Systemshttp://www.eecs.berkeley.edu/~sprinkle/
2
22 May 2006Jonathan Sprinkle, UC Berkeley
Overview
• Nature/Nurture• Motivation• Methods
• Domain-specific modeling• Generative techniques
• Applications (Previous/Possible)• Avionics Autonomy• Toolchain Constraints
• Wrap up, & looking forward
3
22 May 2006Jonathan Sprinkle, UC Berkeley
Nature/Nurture
• Originally from Northeast TN, Southwest VA• Graduated from Tennessee Tech, 1999
• Double major: EE, CompE (1st ever)• Earned stripes as an engineer
• Graduate School at Vanderbilt University• Masters Degree, 2000• PhD, 2003• Learned science of formal modeling
• Postdoc at UC Berkeley• Cut teeth on application problems• Executive Director of Center for Hybrid and
Embedded Software Systems (Chess)• Earned perspective on “big picture”
BerkeleyUniver sit y of Cal ifornia
4
22 May 2006Jonathan Sprinkle, UC Berkeley
These computers these days…
• Embedded systems are used for many kinds of purposes and products
• Fault diagnostics• Onboard/autonomous
strategies• Medical devices• Sensor networks• Mobile phones
• Tricky part: software isI. NontrivialII. UnpredictableIII. UncomposableIV. I and IIV. II and IIIVI. I, II, and III
Thanks to Gabor Karsai and Janos Sztipanovits for the inspiration for this slide.
5
22 May 2006Jonathan Sprinkle, UC Berkeley
Back when I was a kid...
• Managing system level code from the code itself is an intractable problem
• Too many crosscutting req’ts (power, cache, ‘correctness’)• Tight coupling between
– System and (physical) environment– Language and (logical) encoding
• Small changes to requirements translate into large changes to implementation (i.e., large cost)
“Why, back when I was a budding programmer, we didn’t even have keyboards!! We had to discover our own tools! And we worked our hairy little fingers to the bone. AND WE LIKED IT!”
2001: A Space Odyssey
6
22 May 2006Jonathan Sprinkle, UC Berkeley
Proposed solution: Domain-Specific Models!
• Create model of the system• Perform
• Analysis• Architecture exploration• Simulation
• Generate• Configuration• Code• Executables
From the same models!
Example Domains & Environments: - VLSI Layout (e.g., Altera) - Engg Drawing (e.g., AutoCAD) - Physical Modeling (e.g., SolidWorks) - Signal Processing (e.g., LabVIEW) - Controls (e.g., Simulink)
ModelInterpretation
Model Builder
Model Interpreters
Models
DS ModelingEnvironment
ApplicationDomain
App.1
App.2
App.3
ApplicationEvolution
7
22 May 2006Jonathan Sprinkle, UC Berkeley
Domain-Specific Design: An abstract view
Domain Concepts Unrestricted Implementation
8
22 May 2006Jonathan Sprinkle, UC Berkeley
Domain-Specific Design: An abstract view
Domain Concepts Defns of Domain Assumptions and Givens
9
22 May 2006Jonathan Sprinkle, UC Berkeley
Domain-Specific Code Generators
Domain “Instance”
DS CodeGenerator
10
22 May 2006Jonathan Sprinkle, UC Berkeley
Domain-Specific Design: Analysis
Domain “Instance”
DS CodeGenerator
Advantages:• Infer execution structure from domain assumptions• Reduce implementation-layer design/input errors• Keep implementation details flexible• Check design constraints during design• Restrict User’s Implementation Space
Disadvantages:• Learning curve for design environment• Time to build design environment• Re-use cost
11
22 May 2006Jonathan Sprinkle, UC Berkeley
Closing the loop: Metamodels
ModelInterpretation
Model Builder
Model Interpreters
Models
DS ModelingEnvironment
ApplicationDomain
App.1
App.2
App.3
ApplicationEvolution
EnvironmentEvolution
Meta-LevelTranslation
MetamodelingEnvironment
Formal Specifications
12
22 May 2006Jonathan Sprinkle, UC Berkeley
Metamodels
ModelInterpretation
Model Builder
Model Interpreters
Models
ModelingEnvironment
ApplicationDomain
App.1
App.2
App.3
ApplicationEvolution
EnvironmentEvolution
Meta-LevelTranslation
MetamodelingEnvironment
Formal Specifications
ModelInterpretation
Model Builder
Model Interpreters
Models
ModelingEnvironment
ApplicationDomain
App.1
App.2
App.3
ApplicationEvolution
EnvironmentEvolution
Meta-LevelTranslation
MetamodelingEnvironment
Formal Specifications
• Allows:• Rapid creation of Modeling Environment• Formal structure of Model Builder• Strong typing and constraint checking• Automatic Modeling Environment Generation
• Advantages:• Definition of metamodel strongly reflects system domain• Language can be visually defined and implemented• Documentation is the metamodel
• End results:• System design can be managed by domain experts, not
software experts• Complex interdependencies checked through structural
analysis, not enforced through style guides or memoranda
13
22 May 2006Jonathan Sprinkle, UC Berkeley
Structure—Instance
Sequence—meta
Sequence—Instance
Structure—meta
Metamodel: Hierarchical Finite State Machines
State<<Model>>
StartState : bool
Transition<<Connection>>
Event : field
srcdst
s1
s3
s2e2 e5
e4
e3
e1
e2 e3 e5e4e1
Events<<Atom>>
Delay : field
InputSequence<<Model>>
Sequence<<Connection>>
0..* 0..*
src0..1
dst 0..1
14
22 May 2006Jonathan Sprinkle, UC Berkeley
Execution Semantics
• While Event ei, and in State, sc
• After, ei.delay, and in State, sc,– Stop clock– If exists Transition te: (src=sc, dst=sn), set sc = sn
– Else if sc.parent=null, set ei = ei.amSrc.sequence.dst– Else transition through sc.parent– Advance clock
15
22 May 2006Jonathan Sprinkle, UC Berkeley
Modeling example: HFSM
16
22 May 2006Jonathan Sprinkle, UC Berkeley
Power of Modeling: Example
OutputParam<<Atom>>
Param<<Atom>>
Global : boolInitValue : field
Processing<<Model>>
Compound<<Model>>
Primitive<<Model>>
Firing : enumScript : fieldPriority : field
Folder<<Folder>>
DataflowConn<<Connection>>
InputParam<<Atom>>
ParameterBase<<Atom>>
DataType : enumSize : field
OutputSignal<<Atom>>
InputSignal<<Atom>>
Signal<<Atom>>
ParameterConn<<Connection>>
eters0..*
PC0..*
src0..*
src 0..*
dst0..*
DFC 0..*
Parts0..*
s 0..*
dst 0..*
17
22 May 2006Jonathan Sprinkle, UC Berkeley
Power of Modeling: Example
18
22 May 2006Jonathan Sprinkle, UC Berkeley
Generative Techniques
Design
IDE1
Transformer1
Transformer2
Com/Link1
Design
IDE1
Transformer1
Transformer2
Com/Link1
Using the structure of the model, transform domain objects into executable objects, or into other transformable objects. Decide which static domain concepts, structural simplifications, requirements/constraints can be globally or locally determined during transformation, rather than during design.
19
22 May 2006Jonathan Sprinkle, UC Berkeley
Domain-specific modeling w/ Generative Techniques
AbstractModel
ExecutableModel
Solv
e p
roble
m in d
om
ain
term
sAssembler
Map to code, implement
Software ModelMap to UML
Generate,Add bodies
ComponentsDomainModel
Generate callsto components
No map!
CodeMap to code, implement
Slide created by Juha Pekka Tolvanen, Matti Rossi, Jonathan Sprinkle
20
22 May 2006Jonathan Sprinkle, UC Berkeley
Modeling language: formal definition
L =< C;A;S;Ms;Mc >
Thanks to Janos Sztipanovits for the inspiration of this slide.
AbstractSyntax,A
SemanticDomain,
S
ConcreteSyntax,C
Semantics
Mc
Ms
State<<Model>>
StartState : bool
Transition<<Connection>>
Event : field
srcdst
s1
s3
s2e2 e5
e4
e3
e1
Design
IDE1
Transformer1
Transformer2
Com/Link1
21
22 May 2006Jonathan Sprinkle, UC Berkeley
Performing abstraction is…
• Removing • Detail• Implementation• Specificity
• Adding• Generality• Paradigm-independence• “Universal” meaning
Extracting common elements into a parameterizable representation that can be used to recover the original representation, and possibly other archetypally equivalent representations.
22
22 May 2006Jonathan Sprinkle, UC Berkeley
DomainIdea
FinishedProduct
Solv
e p
roble
m in d
om
ain
term
s
AssemblerMap to code, implement
AssemblerMap to code, implement
Software ModelMap to UML
Generate,Add bodies
Software ModelMap to UML
Generate,Add bodies
ComponentsDomainModel
Generate callsto components
No map!Components
DomainModel
Generate callsto components
No map!
CodeMap to code, implement
CodeMap to code, implement
Where do they all fit?
IDE
1
Tra
nsfo
rm1
Tra
nsfo
rm2
DS
ME
1
Des
ign
.cpp.cpp
Com
pile
/Lin
k
exe
IDE
1
Tra
nsfo
rm1
Tra
nsfo
rm2
DS
ME
2
Des
ign
Com
pile
/Lin
k
exe.cpp.cpp
GenerativeTechniquesDomain-specific
modeling
EmbeddedControls Applications
xx
x
(b) (c) (d) (e)(a) (f)
23
22 May 2006Jonathan Sprinkle, UC Berkeley
With J. Mikael Eklund, H. Jin Kim, Shankar Sastry
Applications
• SEC Capstone Demonstration• Pursuit/Evasion of fixed-wing aircraft
• Joint work with Dr. Mike Eklund, Dr. Jin Kim, Prof. Shankar Sastry
dconedcone
qcone
qcone
Tai
l Con
e Nose C
one
Evader’s Cone Pursuer’s Cone
[1] J. Mikael Eklund, Jonathan Sprinkle, S. Shankar Sastry, "Implementing and Testing a Nonlinear Model Predictive Tracking Controller for Aerial Pursuit Evasion Games on a Fixed Wing Aircraft", Proceedings of American Control Conference (ACC) 2005, 1509–1514, Portland, OR, Jun., 8–10, 2005.
[2] Jonathan Sprinkle, J. Mikael Eklund, H. Jin Kim, S. Shankar Sastry, "Encoding Aerial Pursuit/Evasion Games with Fixed Wing Aircraft into a Nonlinear Model Predictive Tracking Controller", Proceedings of the 43rd IEEE Conference on Decision and Control, vol. 3, 2609–2614, Nassau, Bahamas, Dec., 14–17, 2004.
24
22 May 2006Jonathan Sprinkle, UC Berkeley
With J. Mikael Eklund, H. Jin Kim, Shankar Sastry
End
Aircraft Control
L(¢) , xTk X 0xk +uT
k U 0uk + bTm1
B01bm1
(1)
Begin
25
22 May 2006Jonathan Sprinkle, UC Berkeley
With J. Mikael Eklund, H. Jin Kim, Shankar Sastry
End
Aircraft Control
L(¢) , xTk X 0xk +uT
k U 0uk + bTm1
B01bm1
(1)
+ bTm2
B02bm2
(2)
Begin
Obstacle
26
22 May 2006Jonathan Sprinkle, UC Berkeley
With J. Mikael Eklund, H. Jin Kim, Shankar Sastry
End
Aircraft Control
L(¢) , xTk X 0xk +uT
k U 0uk + bTm1
B01bm1
(1)
+ bTm2
B02bm2
(2)
+ bTm3
B03bm3
(3)
Obstacle
Boundary
Begin
27
22 May 2006Jonathan Sprinkle, UC Berkeley
With J. Mikael Eklund, H. Jin Kim, Shankar Sastry
End
Aircraft Control?
Enemy…
L(¢) , xTk X 0xk +uT
k U 0uk + bTm1
B01bm1
(1)
+ bTm2
B02bm2
(2)
+ bTm3
B03bm3
(3)
+ bTm?
B0?bm?
(4)
Begin
Boundary
Obstacle
Whatsa Matter? Are ya Chicken?
J =N ¡ 1P
k=0L(xk ;uk ;b
1k : :M k) = 0
28
22 May 2006Jonathan Sprinkle, UC Berkeley
With J. Mikael Eklund, H. Jin Kim, Shankar Sastry
Constraints/Rules
Ingress
Endpoint“Win” Point
for Friendly
Adversary Ingress Waypoint
Friendly Ingress Waypoint
10 Minutes Time Limitation for Adversary
Win Condition Pursuer has targeted Evader
Boundary for all vehicles
29
22 May 2006Jonathan Sprinkle, UC Berkeley
With J. Mikael Eklund, H. Jin Kim, Shankar Sastry
Op
en S
ource
ITA
R R
estr
icte
d
System Architecture
ControlsAPI
Control Algorithm(s) 1 2 3 4 … NC
Communications Layer
Platform Testbed
Platform IndependentTestbed Configurable
Core OCP
Configured for OCPby OCP Developer
Deployment Layerby OCP Developer
Development (Algorithm)by Technology Developer
Core OCP
1 … NT1 … NP
x86 Laptop, Linux RH9(perfctr-kernel 2.4)
Boeing T-33 Trainer Jetca. 1953
API Exposedu =
hu_v;u _Ã ;u_z
i
Dynamics Abstracted
_x = f (x;u)= DemoSim(u)
DemoSimu _x
Pursuit/EvasionLogic +
map(u_v) =
8<
:
¡ 50[f/ s][¡ 50;50][f/ s]50[f/ s]
¡ 1 < u_v < ¡ 1¡ 16 u_v 6 11< u_v < 1
map(u _Ã) =
8<
:
¡ ¼=50[s¡ 1][¡ ¼=50;¼=50][s¡ 1]¼=50[s¡ 1]
¡ 1 < u _Ã< ¡ 1
¡ 16 u _Ã6 1
1< u _Ã< 1
map(u_z ) =
8<
:
¡ 10[ft/ s][¡ 10;10][ft/ s]10[ft/ s]
¡ 1 < u_z < ¡ 1¡ 16 u_z 6 11< u_z < 1
;
Control Input Constraints
Ingress
Endpoint
Ingress
Endpoint“Win” Point
for Friendly
AdversaryIngress Waypoint
FriendlyIngress Waypoint
10 MinutesTime Limitation for Adversary
10 MinutesTime Limitation for Adversary
Win ConditionPursuer has targeted Evader
Win ConditionPursuer has targeted Evader
Boundary for all vehicles
Game Constraints
Enabled by Component technology
30
22 May 2006Jonathan Sprinkle, UC Berkeley
With J. Mikael Eklund, H. Jin Kim, Shankar Sastry
Methodology
qa
d
qt
dconedcone
qcone
qcone
Tai
l Con
e Nose C
one
Evader’s Cone Pursuer’s Cone
Ingress
Endpoint
31
22 May 2006Jonathan Sprinkle, UC Berkeley
With J. Mikael Eklund, H. Jin Kim, Shankar Sastry
Application Results: Pre-VIP Testing
32
22 May 2006Jonathan Sprinkle, UC Berkeley
With J. Mikael Eklund, H. Jin Kim, Shankar Sastry
Application Results: VIP Day
Pilot comment: “Plane reacted just like pilots are trained to do”
Sprinkle Translation: “I couldn’t tell whether it was a computer or person controlling plane.”
33
22 May 2006Jonathan Sprinkle, UC Berkeley
With Aaron D. Ames, J. Mikael Eklund, Ian M. Mitchell, Shankar Sastry
Applications
• SEC Capstone Demonstration• Landing/Wave-off scenario (safety calculation)
• Joint work with Dr. Mike Eklund, Dr. Ian Mitchell, Prof. Shankar Sastry
xx
x
(b) (c) (d) (e)(a) (f)
[3] Jonathan Sprinkle, Aaron D. Ames, J. Mikael Eklund, Ian Mitchell, S. Shankar Sastry, "Online Safety Calculations for Glideslope Recapture", Innovations in Systems and Software Engineering, vol. 1, no. 2, pp. 157–175 , Sep. 2005.
[4] Jonathan Sprinkle, J. Mikael Eklund, S. Shankar Sastry, "Deciding to Land a UAV Safely in Real Time", Proceedings of American Control Conference (ACC) 2005, 3506–3511, Portland, OR, Jun. 8–10, 2005.
34
22 May 2006Jonathan Sprinkle, UC Berkeley
With Aaron D. Ames, J. Mikael Eklund, Ian M. Mitchell, Shankar Sastry
Landing Scenario
• Consider a fixed-wing UAV following its glideslope
35
22 May 2006Jonathan Sprinkle, UC Berkeley
With Aaron D. Ames, J. Mikael Eklund, Ian M. Mitchell, Shankar Sastry
Motivating Example
• It is directed off its landing path
x
36
22 May 2006Jonathan Sprinkle, UC Berkeley
With Aaron D. Ames, J. Mikael Eklund, Ian M. Mitchell, Shankar Sastry
Motivating Example
• And after some time redirected to land
Can the decision to safely land:Can the decision to safely land: - be made in real time?- be made in real time?
- be guaranteed as true?- be guaranteed as true?
xx
x
37
22 May 2006Jonathan Sprinkle, UC Berkeley
With Aaron D. Ames, J. Mikael Eklund, Ian M. Mitchell, Shankar Sastry
Engineering Problems
• Answering “in time”
Question asked
Now
xx
x
timesteps
38
22 May 2006Jonathan Sprinkle, UC Berkeley
With Aaron D. Ames, J. Mikael Eklund, Ian M. Mitchell, Shankar Sastry
Engineering Problems
Question asked
Now
xx
x
timesteps
39
22 May 2006Jonathan Sprinkle, UC Berkeley
With Aaron D. Ames, J. Mikael Eklund, Ian M. Mitchell, Shankar Sastry
Engineering Problems
Question asked
Now
xx
x
timesteps
40
22 May 2006Jonathan Sprinkle, UC Berkeley
With Aaron D. Ames, J. Mikael Eklund, Ian M. Mitchell, Shankar Sastry
Engineering Problems
Question asked
Now timesteps
xx
x
Answer given Action will be taken
The computation interval should influence the state data
used for the calculation (derived from validation
interval)
i.e., you should use the validation interval to ask about the time at which you would actually be able to do
something
Computation Interval
Validation Interval
41
22 May 2006Jonathan Sprinkle, UC Berkeley
With Aaron D. Ames, J. Mikael Eklund, Ian M. Mitchell, Shankar Sastry
Technology and Analysis Solutions for Reachability
Figures by Ian Mitchell
future target(safe)
backward reach set(controllably safe)
unsafe (no safe control to reach target)
current statetest(s)
initial(current)
forward reach set(controllably safe)
unsafe (out of appropriate control)
future statetest(s)
• Forward:• Must be recomputed
for each start point
Both dimensionally exponentialBoth dimensionally exponential5 dimen: ~hours to compute5 dimen: ~hours to compute6 dimen: ~weeks6 dimen: ~weeks
• Backward:• Must be recomputed for each
end point
42
22 May 2006Jonathan Sprinkle, UC Berkeley
With Aaron D. Ames, J. Mikael Eklund, Ian M. Mitchell, Shankar Sastry
Implementation and Results
InitialInitial
RunwayRunway
43
22 May 2006Jonathan Sprinkle, UC Berkeley
With Aaron D. Ames, J. Mikael Eklund, Ian M. Mitchell, Shankar Sastry
Implementation and Results
All pieces fit All pieces fit together, step size together, step size changes by power changes by power of 10 to match of 10 to match required resolutionrequired resolution
[0,3[0,3))
[3,10[3,10))
44
22 May 2006Jonathan Sprinkle, UC Berkeley
With Aaron D. Ames, J. Mikael Eklund, Ian M. Mitchell, Shankar Sastry
Implementation and Results
01000
20003000
40005000
60007000
-40
-20
0
20
40
60-3000
-2000
-1000
0
1000
2000
3000
x distance
[x,y,] Safe Set from [0,1) nautical miles
angle
y di
stan
ce
0.60.8
11.2
1.41.6
1.82
x 104
-100
-50
0
50
100-2
-1.5
-1
-0.5
0
0.5
1
1.5
2
x 104
x distance
[x,y,] Safe Set from [1,3) nautical miles
angle
y di
stan
ce
12
34
56
7
x 104
-100
-50
0
50
100-1
-0.5
0
0.5
1
x 105
x distance
[x,y,] Safe Set from [3,10) nautical miles
angle
y di
stan
ce
All pieces fit All pieces fit together, step size together, step size changes by power changes by power of 10 to match of 10 to match required resolutionrequired resolution
[0,1[0,1))
[1,3[1,3))
[3,10[3,10))
45
22 May 2006Jonathan Sprinkle, UC Berkeley
With Aaron D. Ames, J. Mikael Eklund, Ian M. Mitchell, Shankar Sastry
Reach-Set Generator
Compilation/Linking
01000
20003000
40005000
60007000
-40
-20
0
20
40
60-3000
-2000
-1000
0
1000
2000
3000
x distance
[x,y,] Safe Set from [0,1) nautical miles
angle
y di
stan
ce
0.60.8
11.2
1.41.6
1.82
x 104
-100
-50
0
50
100-2
-1.5
-1
-0.5
0
0.5
1
1.5
2
x 104
x distance
[x,y,] Safe Set from [1,3) nautical miles
angle
y di
stan
ce1
23
45
67
x 104
-100
-50
0
50
100-1
-0.5
0
0.5
1
x 105
x distance
[x,y,] Safe Set from [3,10) nautical miles
angle
y di
stan
ce
Generative Strategy
Decision Controller Generator
G0 =
8>>>>>><
>>>>>>:
µG 2 [2:85±;3:15±];
ÃG 2 [¡ 0:2±;+0:2±];
x2 2 [¡ 100;+100] ft;
x3 2 [¡ 15;+15] ft;
x1 = 0
Testbed Deployment
onlinequery
real-timeresult
pipi+1
z
x(x0,y0,z0){x
c
Computation Interval
Validation Interval
Question asked
Answer given
Action will be taken
timesteps
c
c
pipi+1
z
x(x0,y0,z0){x
H(~x;p) = minu2U
pT ~f (~x;u)fx1
(~x)0
@_x1_x3_µ
1
A = f (x1;x3;µ;K (x1;x3;µ))
Design
IDE1
Transformer1
Transformer2
Com/Link1
46
22 May 2006Jonathan Sprinkle, UC Berkeley
With Aaron D. Ames, J. Mikael Eklund, Ian M. Mitchell, Shankar Sastry
Analysis
• Safety of ground and vehicle increased• reduced stress and decision load for pilot• aircraft training less of a factor than before• hyper-accurate safe set calculations
• Design lends itself to multiple aircraft• simply create new sets based on constraints• no increase in computation (simple lookup)• uniform integration strategy
• Level of autonomy increased• multiple sets for different scenarios (hazardous weather, wartime,
etc.)• guaranteed within operational parameters
49
22 May 2006Jonathan Sprinkle, UC Berkeley
Modeling Agenda: Toolchain Support
Simulation
Center for Hybrid andEmbedded Software Systems
Exploration
Generation
per
Construction
Verification
Platform
50
22 May 2006Jonathan Sprinkle, UC Berkeley
Conclusions
• Applications of Embedded Systems are cool!• Complexity and interconnectedness require
theoretical understanding in order to succeed• Only with high-confidence systems can
autonomous, assistive, and x-by-wire systems be deployed in society
• Through model-based design, high-confidence systems can be built by domain experts
51
22 May 2006Jonathan Sprinkle, UC Berkeley
More Reading
[1] J. Mikael Eklund, Jonathan Sprinkle, S. Shankar Sastry, "Implementing and Testing a Nonlinear Model Predictive Tracking Controller for Aerial Pursuit Evasion Games on a Fixed Wing Aircraft", Proceedings of American Control Conference (ACC) 2005, 1509–1514, Portland, OR, Jun. 8–10, 2005.
[2] Jonathan Sprinkle, J. Mikael Eklund, H. Jin Kim, S. Shankar Sastry, "Encoding Aerial Pursuit/Evasion Games with Fixed Wing Aircraft into a Nonlinear Model Predictive Tracking Controller", Proceedings of the 43rd IEEE Conference on Decision and Control, vol. 3, 2609–2614, Nassau, Bahamas, Dec. 14–17, 2004.
[3] Jonathan Sprinkle, Aaron D. Ames, J. Mikael Eklund, Ian Mitchell, S. Shankar Sastry, "Online Safety Calculations for Glideslope Recapture", Innovations in Systems and Software Engineering, vol. 1, no. 2, pp. 157–175 , Sep. 2005.
[4] Jonathan Sprinkle, J. Mikael Eklund, S. Shankar Sastry, "Deciding to Land a UAV Safely in Real Time", Proceedings of American Control Conference (ACC) 2005, 3506–3511, Portland, OR, Jun. 8–10, 2005.
[5] Jonathan Sprinkle, "Model-Integrated Computing", IEEE Potentials, vol. 23, no. 1, pp. 28–30, Feb. 2004.
[6] Jonathan Sprinkle, "Generative Components for Hybrid Systems Tools", J. of Obj. Tech., vol. 4, no. 3, pp. 35–40, Apr. 2005.
52
22 May 2006Jonathan Sprinkle, UC Berkeley
Thanks!
http://www.eecs.berkeley.edu/~sprinkle/ http://sprinkletoday.com/
[email protected]@IEEE.org [email protected]
53
22 May 2006Jonathan Sprinkle, UC Berkeley
54
22 May 2006Jonathan Sprinkle, UC Berkeley
Backup slides...
55
22 May 2006Jonathan Sprinkle, UC Berkeley
Fixed wing application
• MPC as a supervisory controller already operational on rotary UAVs
• Dynamics and constraints are quite different than for rotary wing aircraft
• Entirely new aircraft model required
• Tactics• Function of constraints
on fixed wing aircraft, in particular
– Minimum airspeed – Maximum turn rate
56
22 May 2006Jonathan Sprinkle, UC Berkeley
Pursuit/Evasion Game Rules
• Goals• Evader: get to final waypoint or avoid evader for 10 minutes• Pursuer goal: ‘target’ evader
• Targeting• Evader and Pursuer cones are aligned
• Wrinkles• Evader can become Pursuer, if “target of opportunity” is
recognized• Pursuer may not know Evader’s state
• Technicals• 3000’+ of vertical separation at all times (safety)• Pursuer (F-15) “pretends” performance constraints
59
22 May 2006Jonathan Sprinkle, UC Berkeley
With J. Mikael Eklund, H. Jin Kim, Shankar Sastry
Early simulation results
60
22 May 2006Jonathan Sprinkle, UC Berkeley
With J. Mikael Eklund, H. Jin Kim, Shankar Sastry
Early simulation results
61
22 May 2006Jonathan Sprinkle, UC Berkeley
With J. Mikael Eklund, H. Jin Kim, Shankar Sastry
Early simulation results
63
22 May 2006Jonathan Sprinkle, UC Berkeley
Design
IDE1
Transformer1
Transformer2
Com/Link1
Design
IDE1
Transformer1
Transformer2
Com/Link1
65
22 May 2006Jonathan Sprinkle, UC Berkeley
Generative Techniques
• Arguably, a model is nothing more than documentation unless it is directly useful in the design and/or implementation of the final system
• Generative techniques move you from “art history” to “systems science”
Ahh, Magritte’s pipe. The complex expression of realism combined with the birth of abstract art and the (arguable) founding of post-modernist expression through paradox.
This is not Magritte’s Pipe.