model based systems engineering jonathan sprinkle center for hybrid and embedded software systems...

59
Model Based Systems Engineering Jonathan Sprinkle Center for Hybrid and Embedded Software Systems http://www.eecs.berkeley.edu/~sprinkle/

Upload: bradyn-angers

Post on 15-Dec-2015

235 views

Category:

Documents


3 download

TRANSCRIPT

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.