An Open-Source Simulation Environment in C++

An Open-Source Simulation Environment in C++ Peter Zipfel, Ph.D., University of Florida

Modeling and Simulation Technologies

• • •

P = Polymorphism at run-time I = Inheritance of vehicle characteristics E = Encapsulation of data tables and methods

MaSTech © 2013

2

What Is CADAC? •

CADAC – Computer Aided Design of Aerospace Concepts

MaSTech © 2013

3

What Is CADAC? •

CADAC – Computer Aided Design of Aerospace Concepts

•

An engineering tool for the development of aerospace vehicles – Focuses on high fidelity flight simulation of main vehicle

– Interacts with other secondary vehicles

MaSTech © 2013

4

What Is CADAC? •

CADAC – Computer Aided Design of Aerospace Concepts

•

An engineering tool for the development of aerospace vehicles – Focuses on high fidelity flight simulation of main vehicle

– Interacts with other secondary vehicles

•

An evaluation tool for performance studies – Fly-out performance – Flight envelopes, launch envelopes, footprints

MaSTech © 2013

5

What Is CADAC? •

CADAC – Computer Aided Design of Aerospace Concepts

•

An engineering tool for the development of aerospace vehicles – Focuses on high fidelity flight simulation of main vehicle

– Interacts with other secondary vehicles

•

An evaluation tool for performance studies – Fly-out performance – Flight envelopes, launch envelopes, footprints

•

A planning and analysis tool for flight tests – Trajectories, safety footprints – Performance prediction – Data correlation

MaSTech © 2013

6

What Is CADAC? •

CADAC – Computer Aided Design of Aerospace Concepts

•

An engineering tool for the development of aerospace vehicles – Focuses on high fidelity flight simulation of main vehicle

– Interacts with other secondary vehicles

•

An evaluation tool for performance studies – Fly-out performance – Flight envelopes, launch envelopes, footprints

•

A planning and analysis tool for flight tests – Trajectories, safety footprints – Performance prediction – Data correlation

•

A training tool – University of Florida graduate courses in M&S – Real-time integration into flight simulators 

MaSTech © 2013

7

CADAC Genesis •

1966 Litton Industries – 6 DOF missile simulation in Fortran IV – Adopted by industry and government – IBM, Control Data mainframes

•

1978 U.S. Air Force – CADAC Fortran – – – –

•

Air-to-ground and air-to-air missiles Fighter Aircraft Hypersonic vehicles Hosted on Digital VAX, IBM PC

2000 University of Florida – CADAC C++ – Conversion to C++ – ANSI / ISO 1998 Standard C++ – Microsoft Visual C++ compilers

•

Present – USAF/AFRL 5 & 6 DOF simulations – UFL and other academic institutions – Embedded in FLAMES 

MaSTech © 2013

8

CADAC++ Active Simulations FEATURES

TYPE Cruise Missile Fighter Aircraft

VEHICLE OBJECTS Missile; Target; Satellite Aircraft

DoF 5 6

EARTH Spherical Flat

Air-to-Ground Missile Air-to-Air Missile

6 6

Flat Flat

6

WGS84

Generic X30, Weather Deck, MC

Generic Defense Missile

Missile; Aircraft; Target Missile; Target Aircraft Plane + Transfer Vehicle + Interceptor; Tracking Station; Satellite Defensive Missile; Aircraft; Offensive Missile

6

Flat

MC

Three Stage Booster

Rocket with Three Stages

6

WGS84

Insertion Guidance, Weather Deck, MC

Long Range Strike Missile

Missile; Target

5

Spherical

Hypersonic, FLAMES®

Dual Role Missile

Missile; Target; Recce Aircraft

6

Flat

Two Pulse Rocket, Integral Rocket Ramjet, MC

6

WGS84

Wave Rider, MC

6

Flat

Real time, MC, FLAMES®

6

WGS84

Weather Deck, MC

6

WGS84

Scramjet, Weather Deck, MC

Hypersonic Ascent Plane

Global Strike Self Defense Missile Small Smart Bomb Hypersonic Cruise Missile

MaSTech © 2013

Booster + Waverider + Munition; Satellite; Target Defensive Missile; Aircraft; Offensive Missile Bomb; Satellite; Target Missile; Satellite; Target

Remote Targeting Generic F16 Weather Deck, MC MC

9

CADAC, an Open Source Environment • Free access to a full suite of tools • Download CADAC4 from AIAA – CADAC Studio – Fortran simulations

• Request CADAC C++ simulations from [email protected]

• Download compiler Visual C++ Express 2010 from Microsoft

MaSTech © 2013

10

CADAC Usage • USAF/AFRL since 1978 • University of Florida since 1978 • Missouri University of Science and Technology, Rolla, MO • University of Queensland, Australia • Indian Institute of Technology, Madras, India • National University of Córdoba, Argentina • Technion, Haifa, Israel

MaSTech © 2013

11

Graduate Courses at UF

Cruise Missile

Building Aerospace Vehicle Simulations in C++, 2nd Ed, 2008

MaSTech © 2013

12

Graduate Courses at UF

Cruise Missile

Building Aerospace Vehicle Simulations in C++, 2nd Ed, 2008

MaSTech © 2013

Fighter Aircraft Air-to-Air Missile

Fundamentals of Six DoF Aerospace Simulation and Analysis in FORTRAN and C++, 2004

13

Graduate Courses at UF

Cruise Missile

Building Aerospace Vehicle Simulations in C++, 2nd Ed, 2008

Fighter Aircraft Air-to-Air Missile

Hypersonic Ascent Plane

Fundamentals of Six DoF Aerospace Simulation and Analysis in FORTRAN and C++, 2004

Advanced Six DoF Aerospace Simulation and Analysis in C++, 2005

Available at www.aiaa.org MaSTech © 2013

14

• Who is out there in cyberspace ? On next slide click a number for: 1. Student 2. Aerospace engineer 3. Software engineer 4. Scientist 5. Manager 6. Just Human MaSTech © 2013

15

Requirements for Constructive Simulations

MaSTech © 2013

16

Requirements for Constructive Simulations •

Synthesis capability for multi-vehicle environments – –

MaSTech © 2013

High fidelity simulation of main vehicle Lower fidelity for supporting vehicles

17

Requirements for Constructive Simulations •

Synthesis capability for multi-vehicle environments – –

•

Encapsulation of vehicles for multiple instantiation –

MaSTech © 2013

High fidelity simulation of main vehicle Lower fidelity for supporting vehicles Binding data and functions and restricting their access

18

Requirements for Constructive Simulations •

Synthesis capability for multi-vehicle environments – –

•

Encapsulation of vehicles for multiple instantiation –

•

Binding data and functions and restricting their access

Modular structure to mirror the vehicle’s components – –

MaSTech © 2013

High fidelity simulation of main vehicle Lower fidelity for supporting vehicles

Strict interface control Re-use of code

19

Requirements for Constructive Simulations •

Synthesis capability for multi-vehicle environments – –

•

Encapsulation of vehicles for multiple instantiation –

•

Strict interface control Re-use of code

Event scheduling –

MaSTech © 2013

Binding data and functions and restricting their access

Modular structure to mirror the vehicle’s components – –

•

High fidelity simulation of main vehicle Lower fidelity for supporting vehicles

Simulating all phases of flight

20

Requirements for Constructive Simulations •

Synthesis capability for multi-vehicle environments – –

•

Encapsulation of vehicles for multiple instantiation –

•

Simulating all phases of flight

Global communication bus –

MaSTech © 2013

Strict interface control Re-use of code

Event scheduling –

•

Binding data and functions and restricting their access

Modular structure to mirror the vehicle’s components – –

•

High fidelity simulation of main vehicle Lower fidelity for supporting vehicles

Data flow between encapsulated objects

21

Requirements for Constructive Simulations •

Synthesis capability for multi-vehicle environments – –

•

Encapsulation of vehicles for multiple instantiation –

•

Data flow between encapsulated objects

Table look-up – –

MaSTech © 2013

Simulating all phases of flight

Global communication bus –

•

Strict interface control Re-use of code

Event scheduling –

•

Binding data and functions and restricting their access

Modular structure to mirror the vehicle’s components – –

•

High fidelity simulation of main vehicle Lower fidelity for supporting vehicles

1, 2, 3 – dimensional Separate files of data decks for safekeeping

22

Requirements for Constructive Simulations •

Synthesis capability for multi-vehicle environments – –

•

Encapsulation of vehicles for multiple instantiation –

•

1, 2, 3 – dimensional Separate files of data decks for safekeeping

Monte Carlo capability –

MaSTech © 2013

Data flow between encapsulated objects

Table look-up – –

•

Simulating all phases of flight

Global communication bus –

•

Strict interface control Re-use of code

Event scheduling –

•

Binding data and functions and restricting their access

Modular structure to mirror the vehicle’s components – –

•

High fidelity simulation of main vehicle Lower fidelity for supporting vehicles

Uniform, Gauss, Rayleigh, exponential, Markov distributions

23

Requirements for Constructive Simulations •

Synthesis capability for multi-vehicle environments – –

•

Encapsulation of vehicles for multiple instantiation –

•

Uniform, Gauss, Rayleigh, exponential, Markov distributions

Matrix utility operations –

MaSTech © 2013

1, 2, 3 – dimensional Separate files of data decks for safekeeping

Monte Carlo capability –

•

Data flow between encapsulated objects

Table look-up – –

•

Simulating all phases of flight

Global communication bus –

•

Strict interface control Re-use of code

Event scheduling –

•

Binding data and functions and restricting their access

Modular structure to mirror the vehicle’s components – –

•

High fidelity simulation of main vehicle Lower fidelity for supporting vehicles

Programming matrix equations directly

24

Requirements for Constructive Simulations •

Synthesis capability for multi-vehicle environments – –

•

Encapsulation of vehicles for multiple instantiation –

•

Programming matrix equations directly

Documentation and error checking – – –

MaSTech © 2013

Uniform, Gauss, Rayleigh, exponential, Markov distributions

Matrix utility operations –

•

1, 2, 3 – dimensional Separate files of data decks for safekeeping

Monte Carlo capability –

•

Data flow between encapsulated objects

Table look-up – –

•

Simulating all phases of flight

Global communication bus –

•

Strict interface control Re-use of code

Event scheduling –

•

Binding data and functions and restricting their access

Modular structure to mirror the vehicle’s components – –

•

High fidelity simulation of main vehicle Lower fidelity for supporting vehicles

Documenting all interface variables Checking interface variables, matrix compatibility, and file streams Making output compatible with CADAC-Studio 

25

Class Structure CLASS Cadac, ... Vehicle Module Variable Event Packet Datadeck Table Markov Matrix Document

MaSTech © 2013

DESCRIPTION Base class of hierarchical class structure of vehicles Hosting a pointer array of type Cadac Storing module information Declaring module-variables Storing event information Storing data packets for global communication bus Hosting a pointer array of type Table Storing tabular data Storing Markov data Declaring matrix operations Storing module-variable definitions

26

Vehicles Are Encapsulated Objects • Each aerospace vehicle is an object declared by its hierarchical class structure – Data and methods are encapsulated • Aerodynamic and propulsion data tables • Vehicle characteristics are computed in module functions

MaSTech © 2013

27

Vehicles Are Encapsulated Objects Cadac, ... Vehicle Module Variable Event Packet Datadeck Table Markov Matrix Document

• Each aerospace vehicle is an object declared by its hierarchical class structure – Data and methods are encapsulated • Aerodynamic and propulsion data tables • Vehicle characteristics are computed in module functions

• Class hierarchy

MaSTech © 2013

– Abstract base class CADAC – First derived class defines the equations of motion – Second derived class defines the vehicle modules 

28

Examples of Hierarchies

Hypersonic Ascent Plane

Cruise Missile

Fighter Aircraft

Cadac

Cadac

Round3

Flat6

Round6

Round3

Ground0

Plane

Hyper

Satellite

Radar

Cruise

MaSTech © 2013

Target

Satellite

Cadac

29

CADAC Execution modules.cpp headers.hpp compile

input.asc

aero_deck.asc prop_deck.asc

vehicle.exe

Program Execution input19PR_3.asc: Ascent and rendezvous with circular and elliptical satellite May 21 2005 16:58:56

+50 +70

+30

+90

plot.asc

traj.asc

stat.asc

main vehicle

all vehicles

stochastics

+70

+50 +150 +30

-50

+170 +10 -70 -10

-170 -90

CADAC Studio

MaSTech © 2013

30

• What is your preferred language? 1. 2. 3. 4. 5. 6.

MaSTech © 2013

Fortran C C++ C# Java English

31

The Power of Polymorphism •

Definition – Polymorphism is the capability of C++ to use many forms (polymorph) with one interface (polymorph)

MaSTech © 2013

32

The Power of Polymorphism •

Definition – Polymorphism is the capability of C++ to use many forms (polymorph) with one interface (polymorph)

•

Examples – Overloaded functions: many coding forms, but one function name – Overloaded operators: many operations, but one operator symbol

– Virtual functions: many coding forms, but one function name – Run-time polymorphism: many derived objects, but with pointers of the same type of the ‘base class’

MaSTech © 2013

33

The Power of Polymorphism •

Definition – Polymorphism is the capability of C++ to use many forms (polymorph) with one interface (polymorph)

•

Examples – Overloaded functions: many coding forms, but one function name – Overloaded operators: many operations, but one operator symbol

– Virtual functions: many coding forms, but one function name – Run-time polymorphism: many derived objects, but with pointers of the same type of the ‘base class’

•

The power of late binding (function calls are resolved at run-time) – The (virtual) function call is determined by the type of object pointed to by the pointer – The pointers to the derived objects can be stored in one array of type ‘base class’

– Late binding reduces code complexity 

MaSTech © 2013

34

Run-Time Polymorphism •

Run-time polymorphism is accomplished using inheritance and virtual functions

MaSTech © 2013

35

Run-Time Polymorphism • •

Run-time polymorphism is accomplished using inheritance and virtual functions A virtual function is a member of the base class and may be overridden by a new function of the derived class

MaSTech © 2013

36

Run-Time Polymorphism • • •

Run-time polymorphism is accomplished using inheritance and virtual functions A virtual function is a member of the base class and may be overridden by a new function of the derived class Procedure: 1. Build a branching class hierarchy 2. Dynamically allocate memory for an array of pointers to the objects; the array pointer is of type base_class pointer = new base_class *[size];

3. Place the object pointers into the array 4. At run-time, as one of the pointer array elements accesses a virtual function, the correct version of the virtual function corresponding to the object pointer will be called

MaSTech © 2013

37

Run-Time Polymorphism • • •

Run-time polymorphism is accomplished using inheritance and virtual functions A virtual function is a member of the base class and may be overridden by a new function of the derived class Procedure: 1. Build a branching class hierarchy 2. Dynamically allocate memory for an array of pointers to the objects; the array pointer is of type base_class pointer = new base_class *[size];

3. Place the object pointers into the array 4. At run-time, as one of the pointer array elements accesses a virtual function, the correct version of the virtual function corresponding to the object pointer will be called

•

A class is called an abstract class if at least one of its functions is purely virtual; it cannot be used to create an object

MaSTech © 2013

38

Run-Time Polymorphism • • •

Run-time polymorphism is accomplished using inheritance and virtual functions A virtual function is a member of the base class and may be overridden by a new function of the derived class Procedure: 1. Build a branching class hierarchy 2. Dynamically allocate memory for an array of pointers to the objects; the array pointer is of type base_class pointer = new base_class *[size];

3. Place the object pointers into the array 4. At run-time, as one of the pointer array elements accesses a virtual function, the correct version of the virtual function corresponding to the object pointer will be called

• •

A class is called an abstract class if at least one of its functions is purely virtual; it cannot be used to create an object Benefit of run-time polymorphism (late binding) – Program ‘morphs’ during execution without a large amount of contingency code – But slows down execution 

MaSTech © 2013

39

Implementation of Run-Time Polymorphism Classes

•

Cadac, ... Vehicle Module Variable Event Packet Datadeck Table Markov Matrix Document

MaSTech © 2013

All vehicle objects are stored in the pointer array vehicle_ptr of type Cadac (abstract base class) 1. Create Vehicle vehicle_list which has as private member the pointer array Cadac **vehicle_ptr 2. From ‘input.asc’ read the number and type of vehicle objects 3. Add the vehicle pointers to vehicle_ptr array in the order read from ‘input.asc’

40

Implementation of Run-Time Polymorphism Classes

•

Cadac, ... Vehicle Module Variable Event • Packet Datadeck Table Markov Matrix Document

All vehicle objects are stored in the pointer array vehicle_ptr of type Cadac (abstract base class) 1. Create Vehicle vehicle_list which has as private member the pointer array Cadac **vehicle_ptr 2. From ‘input.asc’ read the number and type of vehicle objects 3. Add the vehicle pointers to vehicle_ptr array in the order read from ‘input.asc’

During run-time the vehicle objects are accessed by their pointers – The class Vehicle declares an overloaded offset operator Cadac *operator[] that returns the vehicle pointer – The vehicle pointer is of the correct vehicle type (e.g., Cruise, Target, Satellite) although it is stored in the pointer array of type Cadac (polymorphism) 4. With this vehicle-pointer the member functions of the respective vehicle are accessed – Example: At every integration step the ‘newton’ module of the i-th vehicle is called vehicle_list[i]->newton(int_step); ♣

MaSTech © 2013

41

Cruise Missile Architecture Cadac

Abstract base class

Round3

Derived class

Derived class

MaSTech © 2013

Target

Cruise

Satellite

42

Cruise Missile Architecture Cadac

Abstract base class

Round3

Derived class

round3 [ ]

Derived class

MaSTech © 2013

Target

Cruise

target [ ]

cruise [ ]

Satellite satellite [ ]

Module-Variable arrays

43

Cruise Missile Architecture Cadac

Abstract base class

Virtual functions

Round3

Derived class

newton ( ) environment ( )

round3 [ ]

Derived class

MaSTech © 2013

Target

Cruise

target [ ]

cruise [ ]

Virtual functions

Satellite satellite [ ]

Module-Variable arrays

aerodynamics ( ) propulsion ( ) forces ( ) targeting () seeker ( ) guidance ( ) control ( ) intercept ()

44

Cruise Missile Architecture Cadac

Abstract base class

Virtual functions

Round3

Derived class

newton ( ) environment ( )

round3 [ ]

Derived class

Vehicle-objects

MaSTech © 2013

Target

Cruise

target [ ]

cruise [ ]

TARGET3

CRUISE3

Virtual functions

Satellite satellite [ ]

Module-Variable arrays

SATELLITE3

aerodynamics ( ) propulsion ( ) forces ( ) targeting () seeker ( ) guidance ( ) control ( ) intercept ()

45

Cruise Missile Architecture Cadac

Abstract base class

Virtual functions

Round3

Derived class

newton ( ) environment ( )

round3 [ ]

Derived class

Vehicle-objects

Target

Cruise

target [ ]

cruise [ ]

TARGET3

satellite [ ]

CRUISE3

Communication bus combus [ ]

MaSTech © 2013

Virtual functions

Satellite Module-Variable arrays

SATELLITE3

aerodynamics ( ) propulsion ( ) forces ( ) targeting () seeker ( ) guidance ( ) control ( ) intercept ()

46

Cruise Missile Architecture Cadac

Abstract base class

Virtual functions

Round3

Derived class

newton ( ) environment ( )

round3 [ ]

Derived class

Vehicle-objects

Target

Cruise

target [ ]

cruise [ ]

TARGET3

Virtual functions

Satellite satellite [ ]

CRUISE3

Module-Variable arrays

SATELLITE3

Communication bus combus [ ]

aerodynamics ( ) propulsion ( ) forces ( ) targeting () seeker ( ) guidance ( ) control ( ) intercept ()

environment control

aerodynamics forces

newton

intercept

propulsion guidance

MaSTech © 2013

seeker

targeting



47

CADAC++ Modularity • Classes

Cadac, ... Vehicle Module Variable Event Packet Datadeck Table Markov Matrix Document

MaSTech © 2013

CADAC’s modular structure mirrors the hardware components of an aerospace vehicle – A module is a model of a vehicle component • Examples: aerodynamics, propulsion, actuator, guidance, control

48

CADAC++ Modularity • Classes

Cadac, ... Vehicle Module Variable Event Packet Datadeck Table Markov Matrix Document

CADAC’s modular structure mirrors the hardware components of an aerospace vehicle – A module is a model of a vehicle component • Examples: aerodynamics, propulsion, actuator, guidance, control

•

MaSTech © 2013

The calling order of the modules is controlled by the input file

49

CADAC++ Modularity • Classes

Cadac, ... Vehicle Module Variable Event Packet Datadeck Table Markov Matrix Document

CADAC’s modular structure mirrors the hardware components of an aerospace vehicle – A module is a model of a vehicle component • Examples: aerodynamics, propulsion, actuator, guidance, control

•

The calling order of the modules is controlled by the input file

•

Data between modules is transferred by module-variables

MaSTech © 2013

– Module-variables, being the only interface, are strictly controlled – Each vehicle object has reserved an array for its module-variables – There is a one-to-one relationship between the module-variable name and the array location – The file doc.asc documents all module-variables

50

CADAC++ Modularity • Classes

Cadac, ... Vehicle Module Variable Event Packet Datadeck Table Markov Matrix Document

CADAC’s modular structure mirrors the hardware components of an aerospace vehicle – A module is a model of a vehicle component • Examples: aerodynamics, propulsion, actuator, guidance, control

•

The calling order of the modules is controlled by the input file

•

Data between modules is transferred by module-variables – Module-variables, being the only interface, are strictly controlled – Each vehicle object has reserved an array for its module-variables – There is a one-to-one relationship between the module-variable name and the array location – The file doc.asc documents all module-variables

•

MaSTech © 2013

Module-variables can be of type int, double, 3x1 vector, and 3x3 matrix

51

CADAC++ Modularity • Classes

Cadac, ... Vehicle Module Variable Event Packet Datadeck Table Markov Matrix Document

CADAC’s modular structure mirrors the hardware components of an aerospace vehicle – A module is a model of a vehicle component • Examples: aerodynamics, propulsion, actuator, guidance, control

•

The calling order of the modules is controlled by the input file

•

Data between modules is transferred by module-variables – Module-variables, being the only interface, are strictly controlled – Each vehicle object has reserved an array for its module-variables – There is a one-to-one relationship between the module-variable name and the array location – The file doc.asc documents all module-variables

•

Module-variables can be of type int, double, 3x1 vector, and 3x3 matrix

•

Inside a module, the module-variables are localized and, after computations, are loaded into their array location ♣

MaSTech © 2013 •

52

Fighter Aircraft Modular Structure

Class Hierarchy Cadac

Flat6

Cadac::flat6[]

Plane

Cadac::plane[] propulsion( )

Modules

plane[50-99]

actuator( )

aerodynamics( )

forces( )

euler( )

newton( )

plane[600-649]

plane[100-199]

flat6[200-209]

flat6[150-199]

flat6[210-249]

control( )

environment( )

kinematics( )

plane[500-599]

flat6[50-99]

flat6[100-149]

guidance( ) plane[400-499]

MaSTech © 2013

53

Hypersonic Plane Modular Structure rcs( ) hyper[50-99]

propulsion( ) hyper[10-49]

actuator( ) hyper[600-649]

aerodynamics( ) hyper[100-199]

control( ) hyper[500-599]

environment( ) round6[50-99]

guidance( ) hyper[400-499]

ins( ) hyper[300-349]

seeker( ) hyper[200-299]

gps( ) hyper[700-799]

datalink( ) hyper[350-399 ]

startrack( ) hyper[800-849]

6 DoF Hypersonic Vehicle HYPER6 forces( ) round6[200-209]

euler( ) round6[150-199]

newton( ) round6[210-299]

intercept( ) hyper[650-699]

kinematics( ) round6[100-149]

Class Hierarchy Cadac

Round6

Hyper

data flow on combus data flow inside object

MaSTech © 2013

54

Hypersonic Plane Modular Structure rcs( ) hyper[50-99]

propulsion( ) hyper[10-49]

actuator( ) hyper[600-649]

aerodynamics( ) hyper[100-199]

control( ) hyper[500-599]

environment( ) round6[50-99]

guidance( ) hyper[400-499]

ins( ) hyper[300-349]

seeker( ) hyper[200-299]

gps( ) hyper[700-799]

datalink( ) hyper[350-399 ]

startrack( ) hyper[800-849]

6 DoF Hypersonic Vehicle HYPER6 euler( ) round6[150-199]

forces( ) round6[200-209]

newton( ) round6[210-299] kinematics( ) round6[100-149]

Class Hierarchy Cadac

3 DoF Satellite SAT3

seeker( ) radar [10-29]

intercept( ) hyper[650-699]

0 DoF Ground Radar RADAR0 kinematics( ) ground0[10-19]

MaSTech © 2013

newton( ) round3[20-59]

forces( ) satellite[10-19]

environment( ) round3[10-19]

Round6

Round3

Ground0

Hyper

Satellite

Radar

data flow on combus data flow inside object

♣

55

Structure of Newton Module previous module

void Round3::def_newton() Definition of module-variables used in this module

void Round3::init_newton () Initial calculations

void Round3::newton(double int_step) Integrations and time-phased calculations Integration loop

next module

MaSTech © 2013

56

Code Example of Module Newton void Round3::def_newton() {

Definition of module-variables in array ‘round3[ ]’, a member of class ‘Round3’

//Definition of module-variables round3[19].init("lonx",0,"Vehicle longitude-deg","newton","diag","scrn,plot,com"); round3[20].init("latx",0,"Vehicle latitude-deg","newton","diag","scrn,plot,com"); round3[21].init("alt",0,"Vehicle altitude-m","newton","out","scrn,plot,com"); ... }void Round3::init_newton() { ........................ } void Round3::newton(double int_step) { //localizing module-variables //input from other modules double time=round3[0].real(); Matrix FSPV=round3[10].vec(); double grav=round3[11].real(); Matrix WEII=round3[27].mat(); //state variables Matrix SBII=round3[35].vec(); Matrix VBII=round3[36].vec(); Matrix ABII=round3[37].vec(); ... //------------------------------------------------------------------------//building gravitational vector in geographic coordinates GRAV.assign_loc(2,0,grav); //integrating inertial state variables ABII_NEW=TIG*((TGV*FSPV)+GRAV); VBII_NEW=integrate(ABII_NEW,ABII,VBII,int_step); SBII=integrate(VBII_NEW,VBII,SBII,int_step); ABII=ABII_NEW; VBII=VBII_NEW; ... //------------------------------------------------------------------------//loading module-variables //state variables round3[35].gets_vec(SBII); round3[36].gets_vec(VBII); round3[37].gets_vec(ABII); ... }

MaSTech © 2013

57

Code Example of Module Newton void Round3::def_newton() {

name, value, definition, module, type, out to: screen, plot file, combus

Definition of module-variables in array ‘round3[ ]’, a member of class ‘Round3’

//Definition of module-variables round3[19].init("lonx",0,"Vehicle longitude-deg","newton","diag","scrn,plot,com"); round3[20].init("latx",0,"Vehicle latitude-deg","newton","diag","scrn,plot,com"); round3[21].init("alt",0,"Vehicle altitude-m","newton","out","scrn,plot,com"); ... }void Round3::init_newton() { ........................ } void Round3::newton(double int_step) { //localizing module-variables //input from other modules double time=round3[0].real(); Matrix FSPV=round3[10].vec(); double grav=round3[11].real(); Matrix WEII=round3[27].mat(); //state variables Matrix SBII=round3[35].vec(); Matrix VBII=round3[36].vec(); Matrix ABII=round3[37].vec(); ... //------------------------------------------------------------------------//building gravitational vector in geographic coordinates GRAV.assign_loc(2,0,grav); //integrating inertial state variables ABII_NEW=TIG*((TGV*FSPV)+GRAV); VBII_NEW=integrate(ABII_NEW,ABII,VBII,int_step); SBII=integrate(VBII_NEW,VBII,SBII,int_step); ABII=ABII_NEW; VBII=VBII_NEW; ... //------------------------------------------------------------------------//loading module-variables //state variables round3[35].gets_vec(SBII); round3[36].gets_vec(VBII); round3[37].gets_vec(ABII); ... }

MaSTech © 2013

58

Code Example of Module Newton void Round3::def_newton() {

name, value, definition, module, type, out to: screen, plot file, combus

Definition of module-variables in array ‘round3[ ]’, a member of class ‘Round3’

Getting modulevariables from ‘round3[ ]’ array

//Definition of module-variables round3[19].init("lonx",0,"Vehicle longitude-deg","newton","diag","scrn,plot,com"); round3[20].init("latx",0,"Vehicle latitude-deg","newton","diag","scrn,plot,com"); round3[21].init("alt",0,"Vehicle altitude-m","newton","out","scrn,plot,com"); ... }void Round3::init_newton() { ........................ } void Round3::newton(double int_step) { //localizing module-variables //input from other modules double time=round3[0].real(); Matrix FSPV=round3[10].vec(); double grav=round3[11].real(); Matrix WEII=round3[27].mat(); //state variables Matrix SBII=round3[35].vec(); Matrix VBII=round3[36].vec(); Matrix ABII=round3[37].vec(); ... //------------------------------------------------------------------------//building gravitational vector in geographic coordinates GRAV.assign_loc(2,0,grav); //integrating inertial state variables ABII_NEW=TIG*((TGV*FSPV)+GRAV); VBII_NEW=integrate(ABII_NEW,ABII,VBII,int_step); SBII=integrate(VBII_NEW,VBII,SBII,int_step); ABII=ABII_NEW; VBII=VBII_NEW; ... //------------------------------------------------------------------------//loading module-variables //state variables round3[35].gets_vec(SBII); round3[36].gets_vec(VBII); round3[37].gets_vec(ABII); ... }

MaSTech © 2013

59

Code Example of Module Newton void Round3::def_newton() {

name, value, definition, module, type, out to: screen, plot file, combus

Definition of module-variables in array ‘round3[ ]’, a member of class ‘Round3’

Getting modulevariables from ‘round3[ ]’ array

//Definition of module-variables round3[19].init("lonx",0,"Vehicle longitude-deg","newton","diag","scrn,plot,com"); round3[20].init("latx",0,"Vehicle latitude-deg","newton","diag","scrn,plot,com"); round3[21].init("alt",0,"Vehicle altitude-m","newton","out","scrn,plot,com"); ... }void Round3::init_newton() { ........................ } void Round3::newton(double int_step) { //localizing module-variables //input from other modules double time=round3[0].real(); Matrix FSPV=round3[10].vec(); double grav=round3[11].real(); Matrix WEII=round3[27].mat(); //state variables Matrix SBII=round3[35].vec(); Matrix VBII=round3[36].vec(); Matrix ABII=round3[37].vec(); ... //------------------------------------------------------------------------//building gravitational vector in geographic coordinates GRAV.assign_loc(2,0,grav); //integrating inertial state variables ABII_NEW=TIG*((TGV*FSPV)+GRAV); VBII_NEW=integrate(ABII_NEW,ABII,VBII,int_step); SBII=integrate(VBII_NEW,VBII,SBII,int_step); ABII=ABII_NEW; VBII=VBII_NEW; ... //------------------------------------------------------------------------//loading module-variables //state variables round3[35].gets_vec(SBII); round3[36].gets_vec(VBII); round3[37].gets_vec(ABII); ...

Computations

}

MaSTech © 2013

60

Code Example of Module Newton void Round3::def_newton() {

name, value, definition, module, type, out to: screen, plot file, combus

Definition of module-variables in array ‘round3[ ]’, a member of class ‘Round3’

Getting modulevariables from ‘round3[ ]’ array

//Definition of module-variables round3[19].init("lonx",0,"Vehicle longitude-deg","newton","diag","scrn,plot,com"); round3[20].init("latx",0,"Vehicle latitude-deg","newton","diag","scrn,plot,com"); round3[21].init("alt",0,"Vehicle altitude-m","newton","out","scrn,plot,com"); ... }void Round3::init_newton() { ........................ } void Round3::newton(double int_step) { //localizing module-variables //input from other modules double time=round3[0].real(); Matrix FSPV=round3[10].vec(); double grav=round3[11].real(); Matrix WEII=round3[27].mat(); //state variables Matrix SBII=round3[35].vec(); Matrix VBII=round3[36].vec(); Matrix ABII=round3[37].vec(); ... //------------------------------------------------------------------------//building gravitational vector in geographic coordinates GRAV.assign_loc(2,0,grav); //integrating inertial state variables ABII_NEW=TIG*((TGV*FSPV)+GRAV); VBII_NEW=integrate(ABII_NEW,ABII,VBII,int_step); SBII=integrate(VBII_NEW,VBII,SBII,int_step); ABII=ABII_NEW; VBII=VBII_NEW; ... //------------------------------------------------------------------------//loading module-variables //state variables round3[35].gets_vec(SBII); round3[36].gets_vec(VBII); round3[37].gets_vec(ABII); ...

Computations

Loading modulevariables onto ‘round3[ ]’ array



MaSTech © 2013

}

61

• How do you feel about polymorphism? 1. 2. 3. 4. 5.

MaSTech © 2013

Too difficult to understand I want to get to know it better Best for multi-object modular simulations Not the best architecture I am numbed and without feelings

62

Event Scheduling •

Aerospace vehicle trajectories are divided into phases initiated by events – Rocket ascent in three stages – Aircraft take-off, cruise, landing – Missile launch, midcourse, terminal, intercept

MaSTech © 2013

63

Event Scheduling • Classes

Cadac, ... Vehicle • Module Variable Event Packet Datadeck Table Markov Matrix Document

MaSTech © 2013

Aerospace vehicle trajectories are divided into phases initiated by events – Rocket ascent in three stages – Aircraft take-off, cruise, landing – Missile launch, midcourse, terminal, intercept

Events in CADAC++ are interruptions of the trajectory for the purpose of reading new module-variables – Global dimensioning of events • NEVENT = maximum number of events • NVAR = maximum number of module-variables at each event

64

Event Scheduling • Classes

Cadac, ... Vehicle • Module Variable Event Packet Datadeck • Table Markov Matrix Document

Aerospace vehicle trajectories are divided into phases initiated by events – Rocket ascent in three stages – Aircraft take-off, cruise, landing – Missile launch, midcourse, terminal, intercept

Events in CADAC++ are interruptions of the trajectory for the purpose of reading new module-variables – Global dimensioning of events • NEVENT = maximum number of events • NVAR = maximum number of module-variables at each event

Events are introduced in the input file input.asc – Event block IF watch_variable_name relational_operator value

module-variables ENDIF

– Relational operators:

– Example: seeker is enabled at dbt = 8000 m to-go IF dbt < 8000 mseek 2 //'int' ENDIF

MaSTech © 2013

=2:Enable, =3:Acquisition, =4:Lock module seeker

♣

65

Input File of Cruise Missile ( 1 of 4 ) TITLE input1_3.asc: UAV cruising and attacking target tracked by satellite // Waypoint guidance and dive into target OPTIONS y_scrn n_comscrn y_events n_tabout y_plot y_traj n_merge y_doc MODULES environment def,init,exec aerodynamics def,exec propulsion def,init,exec forces def,exec newton def,init,exec targeting def,exec seeker def,exec guidance def,exec control def,exec intercept def,exec END TIMING scrn_step 30 plot_step 0.2 traj_step 0.5 int_step 0.05 END . . . . . . . continue MaSTech © 2013

66

Input File of Cruise Missile ( 2 of 4 ) VEHICLES 3 CRUISE3 UAV //initial conditions lonx 14.7 //Vehicle longitude - deg module newton latx 35.4 //Vehicle latitude - deg module newton alt 7000 //Vehicle altitude - m module newton psivgx 90 //Vehicle heading angle - deg module newton thtvgx 0 //Vehicle flight path angle - deg module newton dvbe 200 //Vehicle speed - m/s module newton alphax 0 //Angle of attack - deg module control phimvx 0.0 //Bank angle - deg module control //aerodynamics AERO_DECK cruise3_aero_deck.asc //mass properties and propulsion mprop 4 //'int' Mode switch - ND module propulsion PROP_DECK cruise3_prop_deck.asc //seeker //guidance //autopilot . . . . . . . . continue

MaSTech © 2013

67

Input File of Cruise Missile ( 3 of 4 ) IF wp_flag = -1 //Waypoint #1 crossed wp_lonx 15.1 //Longitude of way point - deg module guidance wp_latx 35.35 //Latitude of way point - deg module guidance psifgx 135 //Heading line-of-attack angle - deg module guidance altcom 5000 //Altitude command - m) module control ENDIF IF wp_flag = -1 //Waypoint #2 crossed …… ENDIF IF wp_flag = -1 //after Waypoint #3: hold heading at 180 and descend to 1500 m //turn-on seeker and intercept nearest target l ENDIF IF mseeker = 3 //seeker is locked on target ENDIF END (of CRUISE3) . . . . . . . . continue MaSTech © 2013

68

Input File of Cruise Missile ( 4 of 4 ) TARGET3 Tank_t1 lonx 15.4 //Vehicle longitude - deg module newton latx 35.3 //Vehicle latitude - deg module newton alt 100 //Vehicle altitude - m module newton psivgx 45 //Vehicle heading angle - deg module newton dvbe 10 //Vehicle speed - m/s module newton END SATELLITE3 Sat_s1 lonx 10 //Vehicle longitude - deg module newton latx 30 //Vehicle latitude - deg module newton alt 500000 //Vehicle altitude - m module newton psivgx 45 //Vehicle heading angle - deg module newton thtvgx 0 //Vehicle flight path angle - deg module newton dvbe 7700 //Vehicle speed - m/s module newton END

END ENDTIME 300 STOP

MaSTech © 2013

69

Console Output input1_3.asc: UAV cruising and attacking target tracked by satellite

Jan 10 2013 10:03:33

Vehicle: CRUISE3 time event_time psivgx thtvgx mprop thrust phimvx phicx

pdynmc SBEG1 mass ancomx

mach SBEG2 cl_ov_cd alcomx

lonx SBEG3 mcontrol mguidance

latx VBEG1 anx wp_grdrange

UAV 0 90.0005 4 -0.621118

0 -0.0560967 1342.26 -12.4224

11790 -4.67125e-005 999.999 1.0202

0.640464 10.0005 3.81163 -0.0206828

14.7003 0.00489589 46 30

35.4 -0.0018685 0.189791 18098.6

UAV 30 89.9982 4 -0.154728

30 -0.0169859 971.033 -0.155251

14037.7 6.92492 998.649 0.994662

0.698874 6301.06 10.008 -0.00135087

14.7697 -0.390137 46 30

35.4001 0.00697903 0.996081 11814.5

UAV 60 90.0525 4 -0.236911

60 -2.33129e-006 964.612 -0.238453

14039.9 3.00039 997.811 0.990137

0.698925 12848.7 10.0282 -0.00206247

14.8418 -0.322431 46 30

35.4 -0.200044 0.990144 5274.05

*** Missile c1 overflies waypoint at longitude = 14.9 deg, latitude = 35.4 deg at time = 84.2 sec SWBG-horizontal miss distance = 1.92061 m north = 0.00257307 m east = -1.9206 m *** Event #1 UAV . . . . . . . .

MaSTech © 2013

time = 84.2

sec;

criteria:

wp_flag = -1

***

70

UAV Trajectory Launch Altitude - m

Long 14.7o, Lat 35.4o, heading East Alt 7000 m Mach 0.7

8.00 e +3 Launch

6.00



4.00 2.00 0 Target

Waypoint # 1



 

#2

14.6

14.8

15.0

15.4 Longitude - deg

WP #1 WP #2 WP #3

35.2 35.3

# 3

35.4 35.5

35.6 15.2

Waypoints

Latitude - deg

Lon-deg Lat-deg 14.9 35.4 15.25 35.54 15.43 35.44 35.1 14.4

Cruise

-2.00

Mach 0.7 After WP #1 descend to 5000 m After WP #2 descend to 2000 m After WP #3 descend to Target

input_3.asc: UAV Cruise ' UAV ' Nov 28 2006 16:00:52

MaSTech © 2013

71

• What is your preferred format for input data? 1. 2. 3. 4.

MaSTech © 2013

Programmed into code ASCI input file Graphic user interface Namelist (Fortran)

72

Communication Bus combus

MaSTech © 2013

73

Communication Bus combus •

MaSTech © 2013

Encapsulation of vehicle-objects prevents direct data exchange

74

Communication Bus combus • •

MaSTech © 2013

Encapsulation of vehicle-objects prevents direct data exchange The communication bus combus gives global access to the modulevariables of all vehicle-objects

75

Communication Bus combus Classes

• •

Cadac, ... Vehicle • Module Variable Event Packet Datadeck Table Markov Matrix Document

MaSTech © 2013

Encapsulation of vehicle-objects prevents direct data exchange The communication bus combus gives global access to the modulevariables of all vehicle-objects Building the communication bus – Module-variables are flagged by the keyword “com” round3[19].init("lonx",0,"Vehicle longitude - deg","newton","init/diag","com");

– Every vehicle-object publishes (loads) a packet of com –variables – The packets are stored in the array combus of type Packet

76

Communication Bus combus Classes

• •

Cadac, ... Vehicle • Module Variable Event Packet Datadeck • Table Markov Matrix Document

MaSTech © 2013

Encapsulation of vehicle-objects prevents direct data exchange The communication bus combus gives global access to the modulevariables of all vehicle-objects Building the communication bus – Module-variables are flagged by the keyword “com” round3[19].init("lonx",0,"Vehicle longitude - deg","newton","init/diag","com");

– Every vehicle-object publishes (loads) a packet of com –variables – The packets are stored in the array combus of type Packet

Using the communication bus – The communication bus can be used by any vehicle-object – A vehicle-object subscribes (downloads) the variables it needs from the other vehicle-objects – Example: UAV downloads the position of the target it attacks

77

Communication Bus combus Classes

• •

Cadac, ... Vehicle • Module Variable Event Packet Datadeck • Table Markov Matrix Document •

Encapsulation of vehicle-objects prevents direct data exchange The communication bus combus gives global access to the modulevariables of all vehicle-objects Building the communication bus – Module-variables are flagged by the keyword “com” round3[19].init("lonx",0,"Vehicle longitude - deg","newton","init/diag","com");

– Every vehicle-object publishes (loads) a packet of com –variables – The packets are stored in the array combus of type Packet

Using the communication bus – The communication bus can be used by any vehicle-object – A vehicle-object subscribes (downloads) the variables it needs from the other vehicle-objects – Example: UAV downloads the position of the target it attacks

Characteristics of combus – It is an array of type Packet of size equal to the number of vehicle- objects – The slot # of a vehicle in combus[] is the same as in vehicle_list[] 

MaSTech © 2013

78

Publishing and Subscribing Module-Variables Publishing

Subscribing

CRUISE3 c1 Packets

round3[]: lonx, latx, alt cruise[]: thrust, mguidance

combus c1 c2 . .

CRUISE3 c2 round3[]: lonx, latx, alt cruise[]: thrust, mguidance

.. .

t1 t2 . .

TARGET3 t1 round3[]: lonx, latx, alt --------------------------

TARGET3 t2 round3[]: lonx, latx, alt

--------------------------

.. . MaSTech © 2013

…

CRUISE3 c2

CRUISE3 c1

t1

lonx, latx, alt

t1

lonx, latx, alt

t2

lonx, latx, alt

t2

lonx, latx, alt

 79

Publishing and Subscribing

MaSTech © 2013

80

Publishing and Subscribing •

The communication bus Packet combus enables the communication among the encapsulated vehicle objects

MaSTech © 2013

81

Publishing and Subscribing • •

The communication bus Packet combus enables the communication among the encapsulated vehicle objects Vehicles publish selected module-variables by using the keyword “com” in the definition – Every vehicle object of the same type (multiple instantiation) publishes the same module-variables – Example: All vehicle objects are derived from the round3 class and publish the same round3 module-variables

MaSTech © 2013

82

Publishing and Subscribing • •

The communication bus Packet combus enables the communication among the encapsulated vehicle objects Vehicles publish selected module-variables by using the keyword “com” in the definition – Every vehicle object of the same type (multiple instantiation) publishes the same module-variables – Example: All vehicle objects are derived from the round3 class and publish the same round3 module-variables

•

Subscription of module-variables is complicated by the fact that the subscribing vehicle object (this) is unaware of the publishing vehicle

MaSTech © 2013

83

Publishing and Subscribing • •

The communication bus Packet combus enables the communication among the encapsulated vehicle objects Vehicles publish selected module-variables by using the keyword “com” in the definition – Every vehicle object of the same type (multiple instantiation) publishes the same module-variables – Example: All vehicle objects are derived from the round3 class and publish the same round3 module-variables

• •

Subscription of module-variables is complicated by the fact that the subscribing vehicle object (this) is unaware of the publishing vehicle Subscription methodology: – Publishing vehicle must by identified by its combus slot# •

Logic is required to select the publishing vehicle from all other vehicle objects – Example: Pick target (publisher) when it is in acquisition range of missile (subscriber)

• •

Build the publishing vehicle’s ID Find this ID in combus und thus determining its slot#

– Download module-variables from the combus data packet  MaSTech © 2013

84

Console Display of combus . . . . . . . . UAV 60 60 90.0525 -2.33129e-006 4 964.612 -0.236911 -0.238453

14039.9 3.00039 997.811 0.990137

0.698925 12848.7 10.0282 -0.00206247

14.8418 -0.322431 46 30

35.4 -0.200044 0.990144 5274.05

7000.32 218.255 0 0

time = 60 ------------------------------------ combus -------------------------------------------** CRUISE3 ** mach lonx latx alt dvbe psivgx SBEG1 SBEG2 SBEG3 VBEG1 VBEG2 VBEG3 SBII1 SBII3 thrust *** c_1 3.00039 3.69465e+006

0.698925 12848.7 964.612

14.8418 -0.322431

35.4 -0.200044

7000.32 218.255

218.255 8.88049e-006

90.0525 5.01955e+0066

** TARGET3 ** SBEG1 SBII3

mach SBEG2

lonx SBEG3

latx VBEG1

alt VBEG2

dvbe VBEG3

psivgx SBII1

*** t_1 424.583 3.68193e+006

0.0294188 424.629

15.4049 -0.0634189

35.3038 7.07032

100.063 7.07142

9.99972 -0.00152751

45.0045 5.00655e+006

** SATELLITE3 SBEG1 SBII3

mach SBEG2

lonx SBEG3

latx VBEG1

alt VBEG2

dvbe VBEG3

psivgx SBII1

*** s_1 321398 3.71084e+006

26.1265 332307

13.2454 -1637.38

32.6799 5254.12

501637 5625.28

7697.56 -54.2971

46.954 5.62495e+006

----------------------------------------------------------------------------------------*** Missile c1 overflies waypoint at longitude = 14.9 deg, latitude = 35.4 deg at time = 84.2 sec *** SWBG-horizontal miss distance = 1.92061 m north = 0.00257307 m east = -1.9206 m *** Event #1 UAV time = 84.2 sec; criteria: wp_flag = -1 ***

MaSTech © 2013

85

Table Look-Up Classes

Cadac, ... Vehicle Module Variable Event Packet Datadeck Table Markov Matrix Document

MaSTech © 2013

• Aerodynamic and propulsion decks – Contain 1, 2, 3 dimensional tables – Linear interpolation adequate

• Desired features – Keep data decks separate from code – Make adding or deleting tables simple

• Architecture – – – – –

Encapsulation of data and methods Table stores tabular data Datadeck hosts pointer-arrays of type Table Tables to be accessed by pointers stored in these arrays Overloading the look-up function for 1, 2, 3 dimensions 

86

Table Look-Up Procedure

MaSTech © 2013

87

Table Look-Up Procedure •

Tables are located in files ‘cruise3_aero_deck.asc’ and ‘cruise3_prop_deck.asc’

MaSTech © 2013

88

Table Look-Up Procedure •

Tables are located in files ‘cruise3_aero_deck.asc’ and ‘cruise3_prop_deck.asc’

•

These file names are identified in ‘input.asc’ by the key words AERO_DECK or PROP_DECK

MaSTech © 2013

89

Table Look-Up Procedure •

Tables are located in files ‘cruise3_aero_deck.asc’ and ‘cruise3_prop_deck.asc’

•

These file names are identified in ‘input.asc’ by the key words AERO_DECK or PROP_DECK

•

The function look_up(…), located in the ‘utility_functions.cpp’ file, carries out the interpolation

MaSTech © 2013

90

Table Look-Up Procedure •

Tables are located in files ‘cruise3_aero_deck.asc’ and ‘cruise3_prop_deck.asc’

•

These file names are identified in ‘input.asc’ by the key words AERO_DECK or PROP_DECK

•

The function look_up(…), located in the ‘utility_functions.cpp’ file, carries out the interpolation

•

Tabular data are read and stored during initialization –

main() opens the file ‘input.asc’

–

For every vehicle-object, the function vehicle_data(…) is called

–

In vehicle_data(…) the file name of the aero-deck is read and the file is opened

–

Then the function read_tables(…) is called, which reads and stores the table

MaSTech © 2013

91

Table Look-Up Procedure •

Tables are located in files ‘cruise3_aero_deck.asc’ and ‘cruise3_prop_deck.asc’

•

These file names are identified in ‘input.asc’ by the key words AERO_DECK or PROP_DECK

•

The function look_up(…), located in the ‘utility_functions.cpp’ file, carries out the interpolation

•

Tabular data are read and stored during initialization

•

–

main() opens the file ‘input.asc’

–

For every vehicle-object, the function vehicle_data(…) is called

–

In vehicle_data(…) the file name of the aero-deck is read and the file is opened

–

Then the function read_tables(…) is called, which reads and stores the table

Using tables during integration –

Function look_up(…) is overloaded for one, two, and three dimensional table look-up

–

The table interpolation consists of two steps

–

•

Finding the index of the discrete independent variable with function find_index(…) nearest and below the input variable

•

Conducting a linear interpolation with function interpolate(…) between data points

Extrapolation is constant at the upper end and linearly sloped at the lower end ♣

MaSTech © 2013

92

One-Dimensional Table Look-Up Object name of table

Keywords

Array of discrete independent variable mach

•

1DIM cd0_vs_mach NX1 6 0.4000 0.0506 0.5500 0.0462 0.6500 0.0435 0.7700 0.0410 0.8500 0.0506 0.9500 0.1078

Number of discrete points

Array of discrete dependent variable cd0[mach]

Application in module ‘aerodynamics’, drag coefficient cd0=aerotable.look_up("cd0_vs_mach",mach);

MaSTech © 2013

93

Two-Dimensional Table Look-Up Keywords

Object name of table Number of discrete points

2DIM

tav_vs_alt_mach

NX1 3

NX2 4

0 1524 3048

0.4 0.55 0.7 0.85

// altitude - m, Mach #; thrust available - N 2168.0 1942.9 1711.6

2088.8 1891.3 1677.3

Array of second discrete independent variable mach Array of first discrete independent variable altitude

•

2043.9 1863.3 1676.0

1987.8 1846.8 1683.6

Array of discrete dependent variables tav[altitude][mach]

Application in module ‘propulsion’, thrust available tav=proptable.look_up("tav_vs_alt_mach",alt,mach);

MaSTech © 2013

94

• What do you like about Monte Carlo best? 1. 2. 3. 4. 5.

MaSTech © 2013

A vacation spot on the Côte Azure The Formal One race care event Gambling in the casinos Grace Kelly, the former princess Statistical method for nonlinear systems

95

Monte Carlo Technique •

‘Monte Carlo’ is an important technique of experimental mathematics – Statistical mechanics, nuclear physics, genetics – We use the simple direct simulation method

MaSTech © 2013

96

Monte Carlo Technique •

‘Monte Carlo’ is an important technique of experimental mathematics – Statistical mechanics, nuclear physics, genetics – We use the simple direct simulation method

•

We study the response of nonlinear systems to random inputs – Making multiple runs, drawing values from stochastic distributions – Obtaining large quantity of output for post-analysis

MaSTech © 2013

97

Monte Carlo Technique •

‘Monte Carlo’ is an important technique of experimental mathematics – Statistical mechanics, nuclear physics, genetics – We use the simple direct simulation method

•

We study the response of nonlinear systems to random inputs – Making multiple runs, drawing values from stochastic distributions – Obtaining large quantity of output for post-analysis

•

High fidelity aerospace simulations have many noise sources – Turbulence, INS, sensors, aerodynamic misalignments – With distributions like uniform, Gaussian, Rayleigh, exponential, GaussianMarkov, Dryden

MaSTech © 2013

98

Monte Carlo Technique •

‘Monte Carlo’ is an important technique of experimental mathematics – Statistical mechanics, nuclear physics, genetics – We use the simple direct simulation method

•

We study the response of nonlinear systems to random inputs – Making multiple runs, drawing values from stochastic distributions – Obtaining large quantity of output for post-analysis

•

High fidelity aerospace simulations have many noise sources – Turbulence, INS, sensors, aerodynamic misalignments – With distributions like uniform, Gaussian, Rayleigh, exponential, GaussianMarkov, Dryden

•

Output data are nearly Gaussian if there are many noise sources – Asserted by the central limit theorem – Requires at least 10 uncorrelated noise sources

MaSTech © 2013

99

Monte Carlo Technique •

‘Monte Carlo’ is an important technique of experimental mathematics – Statistical mechanics, nuclear physics, genetics – We use the simple direct simulation method

•

We study the response of nonlinear systems to random inputs – Making multiple runs, drawing values from stochastic distributions – Obtaining large quantity of output for post-analysis

•

High fidelity aerospace simulations have many noise sources – Turbulence, INS, sensors, aerodynamic misalignments – With distributions like uniform, Gaussian, Rayleigh, exponential, GaussianMarkov, Dryden

•

Output data are nearly Gaussian if there are many noise sources – Asserted by the central limit theorem – Requires at least 10 uncorrelated noise sources

•

Output is expressed in univariate or bivariate performance criteria – Univariate: mean, standard deviation, CEP (Circular Error Probable), – Bivariate: error ellipses ♣

MaSTech © 2013

100

Monte Carlo Implementation •

MaSTech © 2013

High fidelity simulations use many random variables –

Modeling noise

–

Describing uncertain phenomena

–

Environmental disturbances

101

Monte Carlo Implementation •

Classes

Cadac, ... Vehicle Module Variable Event Packet Datadeck Table Markov Matrix Document

•

MaSTech © 2013

High fidelity simulations use many random variables –

Modeling noise

–

Describing uncertain phenomena

–

Environmental disturbances

Monte Carlo methodology executes repetitive runs drawing random variables from stochastic distribution –

The number of runs and the random number seed are provided in the input file input.asc : MONTE 20 12345

–

Random variables are identified in input.asc by the key words UNI, GAUSS, RAYL, EXP, MARKOV

–

For initialization of module-variables UNI, GAUSS, RAYL, EXP are used

–

For run time noise MARKOV is used

102

Monte Carlo Implementation •

Classes

Cadac, ... Vehicle Module Variable Event Packet Datadeck Table Markov Matrix Document

•

High fidelity simulations use many random variables –

Modeling noise

–

Describing uncertain phenomena

–

Environmental disturbances

Monte Carlo methodology executes repetitive runs drawing random variables from stochastic distribution –

The number of runs and the random number seed are provided in the input file input.asc : MONTE 20 12345

–

Random variables are identified in input.asc by the key words UNI, GAUSS, RAYL, EXP, MARKOV

•

MaSTech © 2013

–

For initialization of module-variables UNI, GAUSS, RAYL, EXP are used

–

For run time noise MARKOV is used

The maximum numbers of Markov variables is set by the global integer NMARKOV

103

Monte Carlo Implementation •

Classes

Cadac, ... Vehicle Module Variable Event Packet Datadeck Table Markov Matrix Document

•

High fidelity simulations use many random variables –

Modeling noise

–

Describing uncertain phenomena

–

Environmental disturbances

Monte Carlo methodology executes repetitive runs drawing random variables from stochastic distribution –

The number of runs and the random number seed are provided in the input file input.asc : MONTE 20 12345

–

Random variables are identified in input.asc by the key words UNI, GAUSS, RAYL, EXP, MARKOV

–

For initialization of module-variables UNI, GAUSS, RAYL, EXP are used

–

For run time noise MARKOV is used

•

The maximum numbers of Markov variables is set by the global integer NMARKOV

•

Stochastic output of the main vehicle is collected in stat.asc files –

• MaSTech © 2013

Use: OPTION y_stat y_merge

CADAC-Studio analyses and displays stochastic information ♣ 104

Stochastic Distributions in CADAC pdf

UNI vname min, max

1 max  min

min

max

vname

pdf

GAUSS vname mean, sigma

0.2 0 -20

-10 mean

pdf 0.4

RAYL vname mode

density = # of events / unit (vname)

pdf 0.4

sigma

vname

0.2

0.3

0.4 vname

0.1 0.2 density

0.3

0.4

0.1 mode

0.2 0 0

MARKOV vname sigma, bcor

10

0.2 00

EXP vname density

0

Autocorrelation

sigma2

0.5

vname

Power Spectral Density

1st Order Gauss-Markov Process sec

MaSTech © 2013

bcor

Hz

♣

105

Ascent and Intercept TITLE input19_3_3.asc: X30 ascent from Cape, and seeker intercept // Monte Carlo run // X30 ascent, releasing transfer vehicle, releasing interceptor, // intercepting satellite // Error models: GPS/INS, star tracker, SAR terminal sensor MONTE 100 12345 OPTIONS y_scrn y_events y_doc n_tabout y_plot y_stat y_merge y_traj . . . . . . //GPS measurement MARKOV ucfreq_noise 0.1 100 //User clock frequency error GAUSS ucbias_error 0 3 //User clock bias error - m GAUSS pr1_bias 0 0.842 //Pseudo-range 1 bias – m MARKOV pr1_noise 0.25 0.002 //Pseudo-range 1 noise – m . . . . . . //star tracker GAUSS az1_bias 0 0.0001 //Star azimuth error 1 bias – rad MARKOV az1_noise 0.00005 50 //Star azimuth error 1 noise – rad . . . . . . //Interceptor RF seeker GAUSS biasaz 0 .0001 //Azimuth boresight error – rad MARKOV randgl1 1 0.5 //Glint Markov noise in satellite x-dir – m GAUSS esfta 0 .001 //Azimuth scale factor error – ND . . . . . . ENDTIME 1900 STOP

MaSTech © 2013

106

Ascent and Intercept Scenario SAT3 HYPER6 HYPER6

HYPER6

RADAR0

MaSTech © 2013

107

Ascent Trajectory input19_1PR.asc: Ascent from Cape Canaveral until satellite intercept May 14 2005 14:56:35

+90 +70 Intercept of +50satellite



Start of +30 hypersonic vehicle



+10 -110

-90

-70

-50

-30

+10

-10

+50 +30

-10

MaSTech © 2013

-30

108

Trajectory Traces Satellite intercept

e +3 250

25.0 15.0

150

10.0

Altitude - m 0 50.0 100

Mach # 0 5.00

-80.0-60.0-40.0-20.0 0 20.0 40.0 60.0

11.0 9.00 1.00 3.00 5.00 7.00 Angle of attack - deg

Flight path angle - deg

40.0 45.0 50.0 55.0 60.0 65.0 70.0

Heading angle - deg

Release of interceptor

input19_1PR.asc: Ascent from Cape Canaveral until satellite intercept ' Hypersonic Vehicle ' May 14 2005 14:56:35

0

MaSTech © 2013

Release of T.V.

200

20.0

8.00 4.00 2.00 0

Inertial velocity - m/s

6.00

e +3

Crossing of waypoint

0

0.20

0.40

0.60

0.80 T ime - sec

1.00

0.20

0.40

0.60

0.80 T ime - sec

1.00

e +3 1.20

e +3

1.20

109

Two Interceptors of Two Satellites 

• Two interceptors are released from the transfer vehicle to intercept two satellites in circular and elliptical orbits

Intercept Sat 1

input19PR_3.asc: Ascent and rendezvous with circular and elliptical satellite May 21 2005 16:58:56



Intercept Sat 2 +50

+30

+70 +90

+70



+50

Release of two interceptors

+150 +30

-50 

+170 +10 -70 -10

MaSTech © 2013

-170 -90

Start of hypersonic vehicle

110

Stochastic Analysis of Intercept – With INS/GPS, star tracker and seeker errors, 30 Monte Carlo runs – 20 good intercept points in 1-, 3- Hill coordinates

3H 2H

.

Intercept

0

·

-2.5

MISS_H3

2.5

input19_3_2.asc: Vandenberg AFB - South, tail-chase engagement 30 MC ' Hypersonic Vehicle ' Jun 4 2005 07:19:21

1H

50.0% Contour Ellipse ELL STG SYM 1 6

-7.5

1

-12.5

• The 20 good ascent trajectories achieved terminal guidance with the RF seeker

-17.5

• Their miss distances are plotted in the 1H, 3H coordinates, normal to the satellite trajectory

-10

-5

0

5

10

• The CEP is about 5 m

MISS_H1

MaSTech © 2013

111

• What did you like best about the trip to Monte Carlo? 1. 2. 3. 4. 5.

MaSTech © 2013

I’d rather visit the real place I don’t gamble, even in simulations A substitute for the real world Good way to model the real environment I'd rather stay in my deterministic home

112

Overloaded Matrix Operators

MaSTech © 2013

113

Overloaded Matrix Operators Classes

•

Cadac, ... Vehicle Module Variable Event Packet Datadeck Table Markov Matrix Document

MaSTech © 2013

Operators are overloaded by defining operator functions • ret_type class_name::operator#(arg_list){…} – # is a placeholder for any C++ operator (except . :: .* ?: sizeof)

–

The operator function defines the operation that the overloaded operator performs

–

Most useful to define the operations of a new class, e.g., class Matrix

114

Overloaded Matrix Operators Classes

•

Cadac, ... Vehicle Module Variable • Event Packet Datadeck Table Markov Matrix Document

MaSTech © 2013

Operators are overloaded by defining operator functions • ret_type class_name::operator#(arg_list){…} – # is a placeholder for any C++ operator (except . :: .* ?: sizeof)

–

The operator function defines the operation that the overloaded operator performs

–

Most useful to define the operations of a new class, e.g., class Matrix

Example: matrix multiplication –

Prototype

Matrix Matrix::operator*(const Matrix &B); –

Usage • Matrix AMAT(3,3),BMAT(3,3),CMAT(3,3); • CMAT=AMAT*BMAT;

115

Overloaded Matrix Operators Classes

•

Cadac, ... Vehicle Module Variable • Event Packet Datadeck Table Markov Matrix Document

Operators are overloaded by defining operator functions • ret_type class_name::operator#(arg_list){…} – # is a placeholder for any C++ operator (except . :: .* ?: sizeof)

–

The operator function defines the operation that the overloaded operator performs

–

Most useful to define the operations of a new class, e.g., class Matrix

Example: matrix multiplication –

Prototype

Matrix Matrix::operator*(const Matrix &B); –

Usage • Matrix AMAT(3,3),BMAT(3,3),CMAT(3,3); • CMAT=AMAT*BMAT;

–

Multiplication is explained by actual operator function assignment • CMAT=AMAT.operator*(BMAT); – AMAT, the left operand , is the object which initiates the function call: operator*(…)

– BMAT, the right operand, is the argument of the function – AMAT*BMAT is returned by the function

MaSTech © 2013



116

CADAC Utility Functions void print(); double absolute(); Matrix adjoint(); void assign_loc(…) Matrix & build_mat33(…); Matrix & cart_from_pol(…) Matrix col_vec(const int &col); double determinant(); Matrix diamat_vec(); Matrix diavec_mat(); void dimension(int row,int col); Matrix ellipse(); int get_cols(); int get_index(const int &row,const int &col); double get_loc(const int &r,const int &c); double * get_pbody(); int get_rows(); Matrix & identity(); Matrix inverse(); Matrix mat33_vec9(); Matrix & ones(); bool operator!=(const Matrix &B); Matrix pol_from_cart(); Matrix row_vec(const int &row); Matrix skew_sym(); Matrix sub_matrix(const int &row, const int &col); Matrix trans(); Matrix univec3(); Matrix & zero(); Matrix vec9_mat33(); MaSTech © 2013

Overloaded operators bool operator!=(const Matrix &B); Matrix operator*(const double &b); Matrix operator*(const Matrix &B); Matrix & operator*=(const double &b); Matrix & operator*=(const Matrix &B); Matrix operator+(const double &b); Matrix operator+(const Matrix &B); Matrix & operator+=(const double &b); Matrix & operator+=(const Matrix &B); Matrix operator-(const double &b); Matrix operator-(const Matrix &B); Matrix & operator-=(const double &b); Matrix & operator-=(const Matrix &B); Matrix &operator=(const Matrix &B); bool operator==(const Matrix &B); double & operator [](const int &r); double operator^(const Matrix &B); Matrix operator~(); 117

Coding 6 DoF Equations in Matrices Aircraft translational equations of motion 1 [dv / dt ]   [ ] [v ]  [ f a , p ]B  [T ]BL [ g ]L m E B

B

BE B

E B B

//integrating acceleration in body coordinates to obtain velocity Matrix VBEBD_NEW=-WBEB.skew_sym()*VBEB+FAPB*(1/vmass)+TBL*GRAVL; VBEB=integrate(VBEBD_NEW,VBEBD,VBEB,int_step); VBEBD=VBEBD_NEW;

MaSTech © 2013

118

Coding 6 DoF Equations in Matrices Aircraft translational equations of motion 1 [dv / dt ]   [ ] [v ]  [ f a , p ]B  [T ]BL [ g ]L m E B

B

BE B

E B B

//integrating acceleration in body coordinates to obtain velocity Matrix VBEBD_NEW=-WBEB.skew_sym()*VBEB+FAPB*(1/vmass)+TBL*GRAVL; VBEB=integrate(VBEBD_NEW,VBEBD,VBEB,int_step); VBEBD=VBEBD_NEW;

Aircraft attitude equation with rotary (engine) angular momentum



[d BE / dt ]B  [ I BB ]B

  [ 1





] [ I BB ]B [ BE ]B  [lR ]B  [mB ]B

BE B



//integrating the angular velocity acc wrt the inertial frame in body coord Matrix WACC_NEXT=IBBB.inverse()*(-WBEB.skew_sym()*(IBBB*WBEB+L_ENGINE)+FMB); WBEB=integrate(WACC_NEXT,WBEBD,WBEB,int_step); WBEBD=WACC_NEXT;  MaSTech © 2013

119

Documenting and Error Checking •

Emphasis is on documenting module-variables. They govern: – Input/output – Data transfer between modules – Special diagnostic needs

MaSTech © 2013

120

Documenting and Error Checking •

Emphasis is on documenting module-variables. They govern: – Input/output – Data transfer between modules – Special diagnostic needs

•

‘One definition – multiple use’ principle – Module-variables are defined in the modules – Their descriptions are used in the input.asc file – All descriptions are collected in the doc.asc file

MaSTech © 2013

121

Documenting and Error Checking •

– Input/output – Data transfer between modules – Special diagnostic needs

Classes

Cadac, ... Vehicle Module Variable Event Packet Datadeck Table Markov Matrix Document

Emphasis is on documenting module-variables. They govern:

•

‘One definition – multiple use’ principle – Module-variables are defined in the modules – Their descriptions are used in the input.asc file – All descriptions are collected in the doc.asc file

•

MaSTech © 2013

Class Document enables the sharing of the descriptions

122

Documenting and Error Checking •

– Input/output – Data transfer between modules – Special diagnostic needs

Classes

Cadac, ... Vehicle Module Variable Event Packet Datadeck Table Markov Matrix Document

Emphasis is on documenting module-variables. They govern:

•

‘One definition – multiple use’ principle – Module-variables are defined in the modules – Their descriptions are used in the input.asc file – All descriptions are collected in the doc.asc file

• •

MaSTech © 2013

Class Document enables the sharing of the descriptions Error checking – Matrix compatibility – File stream opening – Violations of the ‘one-on-one correspondence’ rule • One module-variable name for one array location

123

Documenting and Error Checking •

– Input/output – Data transfer between modules – Special diagnostic needs

Classes

Cadac, ... Vehicle Module Variable Event Packet Datadeck Table Markov Matrix Document

Emphasis is on documenting module-variables. They govern:

•

‘One definition – multiple use’ principle – Module-variables are defined in the modules – Their descriptions are used in the input.asc file – All descriptions are collected in the doc.asc file

• •

Class Document enables the sharing of the descriptions Error checking – Matrix compatibility – File stream opening – Violations of the ‘one-on-one correspondence’ rule • One module-variable name for one array location

•

Documentation package for a simulation – Modules – input.asc – doc.asc 

MaSTech © 2013

124

doc.asc File TITLE F16C12_1.ASC 3 WAYPOINTS AND TERMINAL GLIDE SLOPE TO IP // OPTIONS y_scrn n_events n_comscrn n_tabout y_doc y_plot y_traj n_merge ........ ********************************************************************************************************************* ********************************************** PLANE6 *************************************************************** ********************************************************************************************************************* *** F16C12_1.ASC 3 WAYPOINTS AND TERMINAL GLIDE SLOPE TO IP Dec 25 2012 18:10:32 *** Plane Module-Variable Array ---------------------------------------------------------------------------------------------------------------------|LOC| NAME | DEFINITION | MODULE | PURPOSE | OUTPUT | ---------------------------------------------------------------------------------------------------------------------. . . . . . . ---------------------------------------------------------------------------------------------------------------------50 mprop int =0: off,=1: manual throttle,=2: Mach hold propulsion data 51 vmachcom Commanded Mach # - ND propulsion data 52 throttle Throttle setting (0->1) ND propulsion data scrn,plot 53 gmach Gain conversion from Mach to throttle - ND propulsion data 54 thrustf Saved thrust when 'mfeeze'=1 - N propulsion save 55 thrust Turbojet thrust - N propulsion out scrn,plot 56 thrust_req Required thrust - N propulsion diag 57 mfreeze_prop int Saving m'mfreeze' value - ND propulsion save 58 powerd Derivative of achieved power setting - %/sec propulsion state 59 power Achieved power setting - % propulsion state ---------------------------------------------------------------------------------------------------------------------. . . . . . . .

MaSTech © 2013

125

• Why do you hate documenting? 1. 2. 3. 4. 5.

MaSTech © 2013

Not exiting A drudgery A necessary evil Because my boss makes me do it I don’t hate it — l love it

126

CADAC Studio •

2DIM: 2-dimensional plotting – Up to three variables in two frames (total of six variables) – Multiple vehicle plotting

•

PITA: 3-dimensional plotting in Cartesian coordinates – Up to ten vehicles

•

GLOBE: 3-dimensional plotting over the Earth (longitude, latitude, altitude) – Up to four vehicles

•

CHARTS: Strip charts – Up to 12 traces in one frame

• Stochastic processing – HIST: Histograms – BIVAR: CEP and bivariate ellipses from scatter plots – MCAP: Mean and std. deviation of trajectory fans

• Automated launch envelope and footprint generation – SWEEP and SWEEP++ for CADAC_FTN and CADAC++  MaSTech © 2013

127

KPLOT 2 – 2DIM

MaSTech © 2013

128

KPLOT – 3 DIM (1 of 2)

MaSTech © 2013

129

KPLOT – 3DIM (2 of 2)

MaSTech © 2013

130

KPLOT - GLOBE

MaSTech © 2013

131

Available CADAC Simulations • Fortran (included in CADAC4 download) – – – – – – –

3 DoF NASA hypersonic vehicle 3 DoF three stage rocket 5 DoF cruise missile with GPS, and terminal sensor 5 DoF short range air-to-air missile 6 DoF F16 aircraft simulation without flight control 6 DoF NASA hypersonic vehicle with flight control 6 DoF short range air-to-air missile

• C++ of this Webinar (request from [email protected]) – 5 DoF cruise missile – 6 DoF F16 aircraft – 6 DoF NASA hypersonic vehicle 

MaSTech © 2013

132

References – Supplement your knowledge of flight dynamics by studying: • Zipfel, Peter H., Modeling and Simulation of Aerospace Vehicle Dynamics, AIAA Education Series, 2nd Edition 2007

– Fill in the voids you may have in C++ by consulting: • Schildt, Herbert, C++: The Complete Reference, 4th Edition, McGrawHill, 2002 • Or if you need a C++ introductory tutorial, read: Schildt, Herbert, C++ From the Ground Up, 3rd Edition, McGraw-Hill, 2003

– Find more detail of the CADAC++ architecture in publication: • Zipfel, Peter H., “CADAC: Multi-Use Architecture for Constructive Aerospace Vehicle Simulations.” Journal of Defense Modeling and Simulations, Feb 2012.  MaSTech © 2013

133

Your Take-Away

MaSTech © 2013

134

Your Take-Away • Fortran is being edged out by C++ – CADAC_FTN of 1978 became CADAC++ in 2000

MaSTech © 2013

135

Your Take-Away • Fortran is being edged out by C++ – CADAC_FTN of 1978 became CADAC++ in 2000

• CADAC++ is an open source framework – For constructive aerospace simulations • Missiles, aircraft, boosters, hypersonic vehicles

– Used by government and academic institutions

MaSTech © 2013

136

Your Take-Away • Fortran is being edged out by C++ – CADAC_FTN of 1978 became CADAC++ in 2000

• CADAC++ is an open source framework – For constructive aerospace simulations • Missiles, aircraft, boosters, hypersonic vehicles

– Used by government and academic institutions

• PIE of C++ enables large net-centric modular simulations – P = Polymorphism: Late binding at run-time – I = Inheritance: Vehicles inherit the equations of motion

– E = Encapsulation: Multiple instantiation of vehicle objects 

MaSTech © 2013

137

Way Forward • Download CADAC4 from AIAA website – http://arc.aiaa.org/doi/book/10.2514/4.862182 and go to Supplemental Materials

• Send me an e-mail mastech.zipfel @ cox.net to obtain the three C++ simulations – 5 DoF cruise missile – 6 DoF fighter aircraft – 6 DoF NASA hypersonic ascent plane

• Meet me in Hampton, VA at the National Aerospace Institute on 4 & 5 March 2013 for my short course – Modeling Flight Dynamics with Tensors – https://www.aiaa.org/CourseDetail.aspx?id=14462

• Attend my next webinar 3 April 2013, 1 pm EST – UAV Conceptual Design Using Computer Simulations – https://www.aiaa.org/CourseDetail.aspx?id=15009 

MaSTech © 2013

138

• How did you like my Webinar? 1. 2. 3. 4.

MaSTech © 2013

Boring Met my expectations Exceeded my expectations I can’t get enough of it

139

MaSTech © 2013

140