creating distributed simulations: the triad website: bernard p. zeigler hessam s. sarjoughian...

Creating Distributed Simulations: The <DEVS, HLA, CORBA> Triad

website: www.acims.arizona.edu

Bernard P. ZeiglerHessam S. Sarjoughian

University of Arizona, Tucson, USA

Tom LakeInterGlossa, Ltd, UK

Copyright: University of ArizonaArizona Center for Integrative Modeling and Simulation

All rights reserved, SIW 2000

DEVS/HLA/CORBA Tutorial SIW(fall 2000) 2

Navigating Course Modules

M&S in DoD& Industry

Module 1

SystemConcepts

Module 2

BasicDEVS

ConceptsModule 3

DEVS Formalism

Module 4

DEVS OO Computational

EnvironmentModule 5

Creating DEVS-C++/Java

ModelsModule 6

Part 2HLA/CORBA


Navigating Course Modules (Cont.)

HLA FederationDevelopment

Module 8

HLABasics

Module 7

Creating Federationsin DEVS/HLA

Module 11

Efficient Large-ScaleDistributed Simulation

Module 17

DEVS/HLADesign & Implementation

Module10

Modeling & SimulationFoundation (Modules 1:6)

DEVS/HLARequirements

Module 9

DEVS/HLA Joint MEASURE

Module 18

DEVS-basedTOOLS

Module 20

Zero Lookahead Simulation

Module19


Navigating Course Modules (Cont.)

DEVS/CORBARequirements, Design, Impl.

Module13

CORBABasics

Module 12

Modeling & SimulationFoundation (Modules 1:6)

SESConcepts

Module14

Distributed Co-DesignM&S

Module 16

Collaborative/DistributedDEVS M&S

Module 15

DEVS-basedTOOLS

Module 20

Efficient Large-ScaleDistributed Simulation

Module 17

DEVS/HLAJoint MEASURE

Module18

Zero Lookahead Simulation

Module19

Summary,More Info,

AZ Center for M&S

Rise of M&S in DoD Rationale and Overview of HLA M&S Current and Future: SBA Enabling Role of Discrete Event M&S (DEVS) Comprehensive Architecture for M&S

Module1:M&S in DoD: Roles of HLA and DEVS


HLA M&SInfrastructureCommon tools

Common Software Modules

Communications

Intellectual Model and DataRepositories

Support for Collaboration

HLA and Simulation Based Acquisition

ConceptAnalysis

Research,Development,& Engineering

Test &Evaluation

PolicyDevelopment

Training

On-line Control

Source: NRC Modeling and Simulation, Vol. 9, National Academy Press


Network

RTIExecutive

DEVSFederate

RTIAmbasador

JointMeasure

DEVSFederate

RTIAmbasador

OPNetCommModel

DEVSFederate

RTIAmbasador

DD21(WarshipModel)

Example: HLA Distributed Simulation


• DEVS = Discrete Event System Specification

• Provides sound M&S framework

• Dynamic system representation capability

• Supports hierarchical, modular modeling

• DEVS/HLA User Friendly HLA-Compliant Environment

DEVS Modeling & Simulation Framework

• HLA enables interoperability of existing simulations

• DEVS supports developing new simulation models


Layered Architecture for M&S

NetworkSupports all Hardware aspects of M&S

SimulationExecutes models

ModelingModels::Attributes and Dynamics

SearchSearches, Evaluates Design Space

DecisionDecision Making in Application domains

CollaborationEnable cooperation among participants

Source: NRC Modeling and Simulation, Vol. 9, National Academy Press

HLA

DEVS

Module2:Fundamentals of Modeling & Simulation

Basic Systems Concepts M&S Entities and Relations Systems Models DEVS Bus


M&S Entities and Relations

Real WorldReal World SimulatorSimulator

modelingrelation

simulationrelation

Each entity is represented as a dynamic system

Each relation is represented by a homomorphism or other equivalence

Data: Input/output relation pairs

structure for generating behaviorclaimed to represent real world

Device forexecuting model

Model


M&S Entities and Relation(cont’d)

Real WorldReal World SimulatorSimulator

modelingrelation

simulationrelation

SimulatorSimulatorSimulatorSimulator

Distributed Simulation

Model should be easily migrated fromSingle Workstation to Distributed Simulation Environment

ModelModelModel


M&S Entities and Relation(cont’d)

Real WorldReal World

modelingrelation

simulationrelation

Experimental frame specifies conditions under which the system is experimented with and observed

Experimental Frame

SimulatorSimulator

ModelModelModel


DESS: differential equation

DEVS: discrete event

DTSS: difference equation

System Specification:

Dynamic Systems

System

Simulator:EventProcessor

DEVS model

time to next event,

state at next event ...

Simulator:RecursiveAlgorithm

System

DTSS model:

q(t+1) = a*q(t)+ b*x(t)

System

Simulator:NumericalIntegrator

DESS model:

dq/dt = a*q +bx


DEVS Bus Concept

RTIRTI

messagemessage

DEVSDEVS

HLAHLA

DEVSDEVS

HLAHLA

messagemessage messagemessage

DEVSDEVS

HLAHLA

Diff Eq.SystemsDiff Eq.Systems

Discrete TimeSystems

Discrete Event

Formalisms

Module 3: Basic DEVS Concepts

Atomic Models Coupled Models Dynamics Components Coupling


Two Fundamental Model Types

Atomic: lowest level model, contains structural dynamics -- model level modularity HLA federate

Coupled: composed of one or more atomic and/or coupled models HLA federation


Models Capture System’s Dynamic Behavior

Simulation models capture a systems’ dynamic behavior how it organizes itself over time in response to imposed conditions and stimuli.

Such modeling is required in order to be able to predict how a system will react to external inputs and proposed structural changes.


Components

• A component can be viewed as a system with inputs and outputs.• An atomic component an internal structure which dictates how inputs/states are transformed to outputs.

statesfunctions

INTERNAL STRUCTURE

inputs outputs

• components are coupled together to create coupled models which themselves can be components in larger systems


Component Discrete Event Dynamics

To capture system’s dynamics, we need to represent its states and how they change over time, autonomously and in response to external events::

» Inputs

» States

» Outputs

» Time advance

» Internal Dynamics


Example of Atomic Component: Repair Shop

A repair shop receives devices for repair from a customer. Each device requires a certain length of time for it to be repaired. Upon the repair of the device, it is sent to the customer.

faulty device

new partsStates:

busyidle

Functions:seal-crackreplace-part

INTERNAL STRUCTURE

repaired device

order parts


Component Discrete Event Dynamics(cont’d)

External Event Transition Function: transforms a state and an input event into another state

(e.g., when a faulty device arrives and if idle then start repairing It )

Output Function that maps a state into an output

(e.g., when the number of parts available falls below a minimum number, issue an order to restock the part.)

Time Advance Function: determines the time to remain in a state(e.g., schedule an operation to fix a device using available part.)

Internal Event Transition Function: transforms a state into another state after the time advance has elapsed

(e.g., given that there are 10 parts available and a broken part requiring 7 of them, after fixing the broken part, 3 parts will remain.)


Experimental Frame

Example: Coupled Model

faulty device

new parts

States:busyidle

Functions:seal-crackreplace-part

Repair Shop repaired device

orderparts

TransducerGenerator

Parts Supplier

orderparts

Module 4: DEVS Formalism

Discrete-event System Specification Basic DEVS for atomic models DEVS Coupled Models Closure Under Coupling Hierarchical Model Construction


The DEVS Framework for M&S

Generic Dynamic Systems Formalism Well Defined Coupling of Components Hierarchical Construction Stand Alone Testing Repository Reuse Event-Based, Efficient Simulation Includes Continuous and Discrete Time Systems Object-Oriented Implementation


DEVS Atomic Model

input events

output events

state variables

state transition functions

output function

timing function

Elements of an atomic model:


DEVS = X, S, Y, int, ext, con, ta, X: a set of input events

Y: a set of output events

S: a set of states

ta: S R+0, time advance function

int: S S internal transition function

ext: Q x Xb S external transition function

con: Q x Xb S confluent transition function

where Xb is a set of bags over elements in X Q = {(s,e) | s S, 0 e ta(s)}

: S Y output function

Atomic Model Specification


Internal Transition Function/Output Function

ta(s)s

(s)

y

s’ = int (s)

DEVS = X, S, Y, int, ext, con, ta,


ta(s)s


x

s’ = ext (s, e, x)

External Transition Function

e


ta(s)s


x

s’ = con (s, ta(s), x)

Confluent Transition Function

e


Coupled Model

Components

Interconnections

– Internal Couplings

– External Input Couplings

– External Output Couplings

Elements of coupled model:


Coupled Model Specification

DN = X , Y, D, {Mi }, {Ii }, {Zi,j }

X : a set of input events.

Y : a set of output events.

D : an index set (names) for the components of the coupled model.

For each i D ,

Mi is a component DEVS model.

For each i D self , Ii is the set of influencees of i .

For each j D self ,

Zi,j is output translation mapping


DN X , Y, D, {Mi }, {Ii }, {Zi,j }

DEVS X, S, Y, int, ext, con, ta,

DEVS X, S, Y, int, ext, con, ta,

Every DEVS coupled model has a DEVS Basic equivalent

Closure Under Coupling


EFA

ARCH

EF

GEN TRANSD

EF

ARCH

COORD

PROC

PROC

Hierarchical Model Construction


Coupled Model

gpt

processor(proc)

out

arrived

solved

outin

generator(genr)

transducer(transd)

out

out

stop

startstart


Hierarchical Coupled Model

efP

processor(proc)

out

arrived

solved

outin

generator(genr)

transducer(transd)

out

out

stop

startstart

ef

solved

startout

out


Experimental Frame/Model Modularity

efP

ProcessorWith

Queue(procQ)

out

solved

outin

out

out

startstart

ef

Module 5: DEVS OO Computational Environment

Container Classes Object Oriented DEVS DEVS Simulator Principles DEVS M&S Environments


Heterogeneous Container Class Library

container

entity

function

relation

set

bag

liststackqueue

order

• is in?• size?• add• ask_all• tell_all

• num_of?• remove

• add

• add• remove• assoc_all?

• replace• assoc?

• name?• equal?

• max?• greater_than?• remove

• add• remove• front? • push

• pop• top?

• insert• remove• list_ref?


ENTITY

Object-Oriented DEVS Classes

DEVS

CONTAINER

entity

ATOMIC

DIGRAPH

devs

MESSAGE

content port, value ENTITY

Legend

inherits

can hold


Simulator/Simulation Concepts

Simulator is responsible for executing a model’s dynamics (represented as instructions) in a given formalism.

Abstract simulator is a characterization of what needs to be done in executing a model’s instructions– atomic simulator

– coupled simulator Simulation engines enforce particular realizations of an abstract

simulator Simulations can be executed as:

– Sequential

– Parallel

– Distributed (sequential/parallel)


tL = tN

tN = tN + ta()

tL = 0

tN = ta()

initialize

Atomic DEVS Simulator

simulation cycle

External Event (Input)

ElapsedTime

•tL = time of last event

•tN = time of next event

•Elapsed time enables user to

inject input into the model

at multiples of elapsed periods


tL = tN

tN = tN + ta()

tL = 0

tN = ta()

initialize

Coupled DEVS Simulator

Coupled Modelsimulation cycle

•tL = time of last event

•tN = time of next event


1 Compute the global next event time, tN: use reduce to get minimum of component times to next event (tN)

2 Tell all components the global tN and

if component is imminent (tN == global tN),

then generate output message(using )3 Sort and distribute (using coupling) output messages.4 Tell all components

if component is imminent (tN == global tN )

or has incoming mail (external events)

or both

then execute transition function (deltfunc).

Coupled Model Simulation Cycle


simulator

Component

tN

tN. tL

After each transition tN = t + ta(), tL = t

simulator

Component

tN

tN. tL

simulator

Component

tN

tN. tL

coordinatorCoupled Model

1. nextTN

2. outTN

3 getOut

4 getOut

5 applyDelt

DEVS Simulation Protocol

NOTE: Component can be a Coupled Model in which case coordindator would be needed instead of simulator.


An object-oriented computational environment

• based on the DEVS formalism

enabling users to construct • flexible, complex, and multilevel models

• robust, user-friendly, reusable fashion

and execute them in both

• desk-top and

• distributed simulation platforms

DEVS M&S Environments

Module 6: Creating DEVS C++/Java Models

Atomic Models in DEVSJAVA Coupled Models in DEVSJAVA Examples: Job Processors, EF elements Examples: DEVS mapping of explosion Hierarchical Models


Generator Atomic Model

//Constructor for Generator Modelpublic genr(String name,int Int_arr_time){ super(name); inports.add("stop"); inports.add("start"); inports.add("setPeriod"); outports.add("out"); phases.add("busy"); int_arr_time = Int_arr_time ;}

//External Transition Function ( ext )public void deltext(int e,message x){ Continue(e); for(int i=0; i< x.get_length();i++) if(message_on_port(x,"setPeriod",i)){ entity en = x.get_val_on_port("setPeriod",i); intEnt in = (intEnt)en; int_arr_time = in.getv(); } for(int i=0; i< x.get_length();i++) if(message_on_port(x,"start",i)){ ent = x.get_val_on_port("start",i); hold_in("busy",int_arr_time); } for(int i=0; i< x.get_length();i++) if(message_on_port(x,"stop",i)) passivate(); }

Generatorout

stop

start

setPeriod

//Internal Transition Function ( int )public void deltint( ){ if(phase_is("busy")){ count = count +1; hold_in("busy",int_arr_time);} }

//Output Function: ( )public message out( ){ message m = new message(); content con = make_content("out", new entity("job" + count)); m.add(con); return m; }


Processor Atomic Model

//External Transition Function ( ext )public void deltext(int e,message x){ Continue(e); for(int i=0; i< x.get_length();i++) if(message_on_port(x,"setProcTime",i)){ entity en = x.get_val_on_port("setProcTime",i); intEnt in = (intEnt)en; processing_time = in.getv(); } if(phase_is("passive")){ for(int i=0; i< x.get_length();i++) if(message_on_port(x,"in",i)){ job = x.get_val_on_port("in",i); hold_in("busy",processing_time); state = 1; } }}

Processoroutin

setProcTime

//Output Transition Function ( ) public message out( ){ System.out.println("Output Function " + name); message m = new message(); if(phase_is("busy")){ content con = make_content("out",job); m.add(con); con = make_content("outName",new pair(this,job)); m.add(con); } return m; }

//Internal Transition Function ( int ) public void deltint( ){ passivate(); state = 0; job = new entity("none"); }


Generator/Processor/Transducer Coupled Model

//Constructor for GPT Model

//create componentsatomic am1 = new genr(“Generator”);atomic am2 = new proc(“Processor”);atomic am3 = new transd(“Transducer”);

//add componentsadd(am1);add(am2);add(am3);

//Constructor for GPT Model (Cont.)//specify couplingsshow_state(); Add_coupling(am1,"out",am2,"in"); Add_coupling(am1,"out",am3,"arrived"); …. Add_coupling(am2,"out",am3,”solved"); …. Add_coupling(this,"start",am1,"start"); Add_coupling(am2,"out",this,"out");

gpt

processor(proc)

out

arrived

solved

outin

generator(genr)

transducer(transd) out

out

stop

startstart



efP

processor(proc)

out

arrived

solved

outin

generator(genr)

transducer(transd)

out

out

stop

startstart

ef

solved

startout

out


Hierarchical Modeling (Cont.)

//Constructor for EF Model

public class EF extends digraph{

//create components atomic am1 = new genr(”Generator",procTime, numJobs); atomic am2 = new transd("transd");

//Specify Internal couplingsAdd_coupling(am1,"out",am2,”arrived");

//Specify External Input CouplingsAdd_coupling(this,”start",am2,”start");Add_coupling(this,”solved",am2,”solved");

//Specify External Output CouplingsAdd_coupling(am1,”out",this,”out");Add_coupling(am2,”out",this,”out");….}

//Constructor for pQEF Model

public class pQEF extends digraph{

//create components digraph cm1 = new EF(”EF",procTime, numJobs); atomic am1 = new pQ(”ProcessorWqueue"); add(am1); add(cm1); //Internal Couplings Add_coupling(cm1,"out",am1,”in"); Add_coupling(am1,”out",cm1,”solved"); ….}

Components:• Processor with Queue• EF


Explosion Example

//Constructor for Coupled Model

//create componentsatomic bomb = new bomb(“Bomb”);atomic counter = new counterM(“CM”);atomic target1 = new target(“Target1”);atomic target2 = new target(“Target2”);

//add componentsadd(bomb);add(counter);add(target1);add(target2);

//specify couplingsaddCoupling(this, “start”, bomb, “fuse”);...addCoupling(counter, “defuse”, bomb, “defuse”);addCoupling(bomb, “explosion”, target2, “strike”);...addCoupling(taget1, “damage”, this, “damage”);

CM

target

defuse

defuse

fuse

damagestrike

CM

bombexplosion

damage

start

start

targetstrike

damage


fuseexplosionBomb

defuse

Explosion Example (Cont’d)

a)defuse

dormant

dead

live explode

explosion

External TransitionFn

when receive fusein phase dormant hold_in(live,5)

when receive defusein phase live hold_in(dormant,150)

else continue

Internal TransitionFn

in phase livehold_in(explode,1)

in phase explodepassivate_in(dead)

Output Fn

in phase liveoutput explosion

150 1

10

fuse

b)

Module 7: HLA Basics

HLA Highlights Basic HLA terminology Federation Rules Run-Time Infrastructure (RTI) RTI Services


High Level Architecture : Highlights

Simulator interoperability and reuse

RTI implemented in C++,Java,Ada,...

live, simulated

humans, equipment, sensors

DoD mandated standard by 2001

Support Utilities

Interface

Interfaces toLive Players

Runtime Infrastructure (RTI)

Simulations


Some Terminology

Federation: a set of simulations, a common federation object model, and supporting RTI, that are used together to form a larger model or simulation

Federate: a member of a federation; one simulation– Could represent one platform, like a cockpit simulator

– Could represent an aggregate, like an entire national simulation of air traffic flow

Federation Execution: a session of a federation executing together

Source: Intro to HLA (JDITEC4_98.ppt)


Some More Terminology

Object:: An entity in the domain being simulated by a federation that

– is of interest to more than one federate

– is handled by the Runtime Infrastructure

Interaction: a non-persistent, time-tagged event generated by one federate and received by others (through RTI)

Attribute: A named datum (defined in Federation Object Model) associated with each instance of a class of objects

Parameter: A named datum (defined in Federation Object Model) associated with each instance of a class of interactions



HLA Object Models and OMT

Federation Object Model (FOM)– A description of all shared information (objects, attributes, and

interactions) essential to a particular federation

Simulation Object Model (SOM)– Describes objects, attributes and interactions in a particular simulation

which can be used externally in a federation

Object Model Template (OMT)– Provides a common framework for HLA object model documentation

– Fosters interoperability and reuse of simulations via the specification of a common representational framework



HLA Specification Elements

• Architecture specifies

- 10 Rules which define relationships among federation components

– 5 for FOM

– 5 for SOM

- An Object Model Template which specifies the form

in which simulation elements are described

- An Interface Specification which describes the way simulations

interact during operation



Federation Rules

1 Federations shall have an HLA Federation Object Model (FOM), documented in accordance with the HLA Object Model Template (OMT).

2 In a federation, all representation of objects in the FOM shall be in the federates, not in the runtime infrastructure (RTI).

3 During a federation execution, all exchange of FOM data among federates shall occur via the RTI.

4 During a federation execution, federates shall interact with the runtime infrastructure (RTI) in accordance with the HLA interface specification.

5 During a federation execution, an attribute of an instance of an object shall be owned by only one federate at any given time.


Federate Rules

6 Federates shall have an HLA Simulation Object Model (SOM), documented in accordance with the HLA Object Model Template (OMT).

7 Federates shall be able to update and/or reflect any attributes of objects in their SOM and send and/or receive SOM object interactions externally, as specified in their SOM.

8 Federates shall be able to transfer and/or accept ownership of attributes dynamically during a federation execution, as specified in their SOM.

9 Federates shall be able to vary the conditions (e.g., thresholds) under which they provide updates of attributes of objects, as specified in their SOM.

10 Federates shall be able to manage local time in a way which will allow them to coordinate data exchange with other members of a federation.


Interface Specification

Provides a specification of the functional interfaces between federates and the RTI– Interfaces are divided into six service groups

Each service specification includes:– Name and Descriptive Text

– Supplied Arguments

– Returned Arguments

– Pre-conditions

– Post-conditions

– Exceptions

– Related Services

Application Programmer Interfaces (APIs) in CORBA IDL, C++, Ada ’95 and Java


Federation:A set of federates interacting via the RTI service and its FOM.

Federate:A simulation component program and its SOM.

FED (Federation Execution Data) file:It contains information derived from the FOM and used by the RTI at runtime.

FedExec (Federation Executive):Responsible for federation management. Enables federates joining and resigning from the federation as well as facilitating data exchange among participating federates.

RTIExec (RTI Executive):A global process managing the creation and destruction of federation executives.

RID file: RTI Initialization Data. This data contains RTI vendor-specific information that is needed to run an RTI.

RTI Components


HLA RTI Service Categories

Category FunctionalityCreate and delete federation executions

Federation Management Join and resign federation executions

Control checkpoint, synchronization,restart

Establish intent to publish and subscribeDeclaration Managementto object attributes and interactions

Create and delete object reflections

Object Management

Create and delete object instances

Control attribute and interactionpublication

Transfer ownership of object attributesOwnership Management

Time Management Coordinate the advance of logical timeand its relationship to real time

Data Distribution Mgmt Supports efficient routing of data

Module 8: HLA Federation Development

Federation Development & Execution Process (FEDEP) HLA Tool Architecture OMT Object Model Development Time management interoperability


HLA Five Step Development Process

Requirements Definition

Conceptual ModelDevelopment

Federation Design

FederationIntegration and Test

Executeand Analyze

Results



HLA Tool Architecture

Object ModelDevelopment

ToolsRTIsFED

Object ModelLibrary

Object ModelData Dictionary

System

DoDData Dictionary

System

FOMsSOMs

DataDictionary

FOMsSOMs

DoD Data Stds.

HLA Object Model Integrated Tools Suite



Object Model Development

HLA Object Models:• Describe Federate (Creating HLA SOM)

PURPOSE: provide federate’s intrinsic capabilities(Note: Other means such as DEVS are needed to describe dynamics)

• Describe Federation (Creating HLA FOM)PURPOSE: provide inter-federate information exchange specification

HLA Object Model Elements:• object model identification• object class structure• interaction class structure• attributes• parameters• routing space• SOM/FOM lexicon


Sample OMT TablesObject Class Structure TableCustomer (PS)Bill (PS)Order (PS)Employee (S) Greeter (PS)

Waiter (PS)Cashier (PS)Dishwasher (PS)Cook (PS)

Food (S) Main_Course (PS)Drink (S) Water (PS)

Coffee (PS)Soda (PS)

Appetizer (S) Soup (S) Clam_Chowder (S) Manhattan (PS)New_England (PS)

… … …

Interaction Class Structure TableCustomer_ Emploee_ Transactions (I)

Customer_Seated (IS)Order_Taken_From_Kids_menu (I)Order_Taken_From_Adult_menu (I)

Order_Taken (I) Drink_Served (I)Appetizer_Served (I)

… … …


Object Model Development

Attributes & parameters

Information model contract

Object classesInteraction classes

HLA Object Models:• Describe Federates (Creating SOM)

other means are needed to describe federate design and functionality• Describe Federation (Creating FOM)

inter-federate information exchange


Challenge: Time Management Interoperability

Run Time Infrastructure (RTI)

training federate:real-time execution

constructive federate:time-stepped

executionRun Time

Infrastructure (RTI)

constructive federate:event driven execution


live component:real-time executionw/ hard deadlines


multiprocessor

parallel simulation federate:optimistic Time Warp

execution


Goal: provide services to support interoperability among federates with different local time management schemes in a single federation execution.Observation: RTI by itself cannot guarantee interoperability.


Message Ordering Services

Typical applications training, T&E analysis

Latency

Reproduce before and after relationships?All federates see same ordering of events?

Execution repeatable?

Property

low

no

no

no

ReceiveOrder

higher

yes

yes

yes

Time StampOrder (TSO)

The baseline HLA provides two types of message ordering:

• Receive Order: messages passed to federate in order of reception

• Time Stamp Order (TSO): successive messages passed to federate have non-decreasing time stamps

Receive order minimizes latency, does not prevent temporal anomalies TSO prevents temporal anomalies, but has somewhat higher latency

Module 9: DEVS/HLA Requirements

HLA-compliant M&S environment

support model construction in C++/Java

support for FEDEP

integration with HLA Tool Architecture

layered architecture for flexibility

support for time management, logic and real time integration

user orientation: shield user from HLA programming


DEVS/HLA Support for FEDEP

Requirements Definition

Conceptual ModelDevelopment

Federation Design

FederationIntegration and Test

Executeand Analyze

Results

DEVS/HLA



DEVS coupled model * structure definition * component ~ attributes quantization * coupling

DEVS/HLA Mapping Approach

* State Updating

* Interactions

Object •Declaration•Initialization•Registration•P/S

RTI-C++

MetadataClassesAttributes/Data TypesInteractions

OMDT


.

Network

RunTimeInfrastructureFedexFedex

RTIAmbasador

DEVSFederate

DEVSFederate

RTIAmbasador

RTIExecutive

DEVS Components as HLA Federates

Internal transition function

External transition function

Output function

Internal transition function

External transition function

Output function


DEVS

Parallel/ DistributedSimulation Protocol

Network

DEVS-C++DEVSJAVA

Middleware CORBA HLA/RTI

Time WarpParallel DEVS

Simulation Protocol

WAN-InternetLAN Cluster

Layer Alternatives (DEVS/HLA etc)

DEVS Distributed Simulation Layers


Time Management Integration & Migration

High performancecomponent

PC workstationcomponent

live component:real-time executionw/ hard deadlines/windows

RTI

Operator Training: fast enoughreal-time

Migration -- successively convert components of model from discrete event simulation to real time execution

Integration -- enable real time execution to inter-operate with discrete event simulation

High performancecomponent

PC workstationcomponent


DEVS/HLA High Level Automation Features

Category

Federation Management

Declaration Management

Object Management

Ownership Management

Time Management

Data Distribution Mgmt

DEVS/HLA Automates it:

Yes

Yes

Yes

No

Yes: No:

YesNo:

Create and delete federation executionsJoin and resign federation executionsControl checkpoint, synchronization, restart

Establish intent to publish and subscribeto object attributes and interactions

Create and delete object reflections

Create and delete object instances

Control attribute and interaction publication

Transfer ownership of object attributes

Coordinate the advance of logical time and its relationship to real time

Quantization and Predictive FilteringSupport efficient routing of data: HLA Routing Space

Module 10: DEVS/HLA Design and Implementation

augmented class hierarchy

interaction/updates

DEVS simulation protocol

migration and integration with real time


DEVS/HLA Class Hierarchy

entity

Devs

Atomicbase

AtomicDigraph

Coupled port

HLAport

quantizer

attribute

DevsFedAmb

FederateAmbassador

Federate


Quantization is themechanism used toautomatically execute attributed updating

Quantization and Attribute Updating

Update triggered at threshold crossing


DEVS/HLA:Pursuer-Evader Model

in

inout

out

Red Tank

drive

perceive

Blue Tank

Evader

Evader FederatePursuer Federate

fireout

firein

Red Tank(Endo Model)

position position

state update : quantized attribute (position)

interaction: HLA port (fire ) + coupling

fire

Objectclass

Objectclass


Pursuer-Evader Model:Adding Viewer

update(quantized attribute)

interaction(HLA port coupling)

ininout

out

Red Tank

drive

Red TankEndo Model

perceive

Blue Tank

Evader

EvadWEndoPursWQuant

position position

fireout

firein

Blue Tank

Red Tank

Transducer Viewer


Attribute Communication

Attribute

quantizervalue

quantattrRtiId

Devs

value

attributeList

Send Attribute Interface

attrRtiIdvalue

Attribute Message

attrRtiIdAttribute Set

size

Attribute Set Message

attributeList

Send Federate

Receive Attribute Interface

size

DevsAttribute

value

attrRtiId

Receive Federate


Interaction Communication

Devs

Send InteractionInterface

myDevsport address

Devs Message

Send Federate Receive Federate

value

Devs

Receive Interaction Interface

myClassIdParameters time

Interaction Message

tag



DEVS Distributed Simulation Layers

Network

DEVS

Middleware


DEVS/HLA Simulation Protocol

Create/join federation

timeAdvGrant

Event process

DEVS cycle

Request next timetimeAdvGrant=FALSE

Initializationcreate modelsadd coupling

setup object / interaction comm.Initialize time

TRUE

FALSE

Compute input/output

Send interactions

Execute transition functions

Update Attributes

Time advance

DEVS/HLA Tutorial University of Arizona (1998) 102

Communication Protocol between DEVS and RTI

Init

ializ

atio

n

ph

ase

DevsRTI Models

Create Models

Setup Coupling

initialize

DevsRtiId

instanceId

attrRtiId

myClassId,myParamId

Time Advance

Publish Object Class

Register Object

Pub/Sub Attributes

Pub/Sub Interaction

Create Fed. Execution

Join Fed. Execution

Federation Execution - Publish/Subscribe - Register

Federation


Communication Protocol between Devs and RTI

Devs Internal Cycle - compute input output - internal transition - external transition - quantize attributes

Cyc

lic

Exe

cuti

on

Ph

ase

Ter

min

ate

Dev

s

Ter

min

ate

Fed

. Ex.

Time AdvanceTime Advance Req

Update Update AttributesUpdate Interaction

instanceId

Termination ReqTerminate Comm.

Delete Models

Time Advance Req

Discover ObjectUpdate/receive Inter.Update/reflect Attr.

(infinite)

Grant Time

Resign Fed. ExecutionDestroy Fed. Execution

Federation Execution - advance Time - update Attributes - update Interactions


DEVS/HLA Simulation Protocol

Create/join federation

timeAdvGrant

Event process

DEVS cycle

Request next timetimeAdvGrant=FLASE

Compute input/output

Send interaction

Execute delta function

Send Attributes

Time advance

Initializationcreate modelsadd coupling

setup object / interaction comm.

Initialize time

TRUE

FALSE


interactions = Output_funct();Send interactions with time-stamp grantTime + epsilon;Int_tr_funct();

Send timeAdvanceRequest (tN); Send tick();

apply quantizers to variablesSend updateAttributeValues;}

When receive timeAdvGrant(grantTime){

tL = grantTime; tN = grantTime + time_adv_funct();

Ext_tr_funct(e,x);

When receive interactions (current time) {Extract input x from

interactionse = current time - tL

update variables

When receive reflectAtributeValues{

}

Send timeAdvanceRequest (tN); Send tick();apply quantizers to variablesSend updateAttributeValues;}

tL = current time; tN = current time + time_adv_funct();

DEVS Cycle Logic- For Cancellation-Free DEVS

DEVS/HLA tutorial SIW, 99 University of Arizona

F1

F2

NER(t1)

NER(t2)

F1

F2

TAG(t1)

F1

F2

t1

t2

t1

NER(t2’)

F1

F2

NER(t1’)

NER(t2’)

1

2

RTI Time Req’t

a) b)

c) d)

t1+g

DEVS/HLA Simulation Protocol-Problem with Cancellation Behavior


F1

F2

NER(t1)

NER(t2)

F1

F2

TAG(t1)t1

t1

NER(t2)

a) b)

c)

t1+g

t1+g

F1

F2

TAG(t1) NER(t1’) where t1’ depends on F2’s inputs so can’t immediately besent as required

t1+g

t1+g

NER(t2’)

Deadlock for communicating imminents


A Solution: DEVS w/Cancellation based on DEVS w/out Cancellation

HLA/RTI

DEVS without Cancellation*

DEVS with Cancellation

* is constrained by: ta(deltext(s,e,x)) = ta(s) - efor all s,e,x.


RTI Exec Fedex tN : Global DEVS Time tNi : Time of Next Event of Federate i

System Models

SimulatorEndo B

CoordinatorEndo

Simulator B

User Models

System Models

Model C

Model D

CoordinatorEndo

Simulator A

User Models

System Models

Model A

Model B

Federate AFederate BTime Manager

SimulatorEndo A

tN

tN

tN1

tN2

Implementing DEVS Protocol in HLA Using Quantizers

Coordinator


Compute Input/OutputSend Interactions

Execute Transition FunctionsUpdate Attributes

Send local time of next event(tNi) of the ith Federate

Coordinator tells Global DEVS time (tN)

Federate 1 Federate 2 Coordinator

Coordinator receives local times of next events (tNi)

n

n+0.1

n+0.2

n+0.3

n+1

t1

t2

RT

I T

ime

(Sim

ulat

ion

Cyc

le)

DE

VS

Tim

e (S

imul

atio

n ti

me)

Implementation (cont’d)


Migrating DEVS Models to Real Time Operation

Network

Par DEVS Sim. Protocol

HLA/RTI

DEVS-RT-Simulator

DEVS DEVS-RT

Real Time RTI

Module 11: Creating Federations in DEVS/HLA

DEVS/HLA Development Process C++ DEVS/HLA Component Templates User Interface to DEVS/HLA Examples: Pursuer/Evader C++ Implementations


DEVS/HLA Development Process

Requirements

Definition

Conceptual

Model

Development

Federation

Design

Federation

Integration

and Test

Executeand Analyze

Results


• develop DEVS-C++ (or Java) atomic and coupled models• store in model base

• decide mapping models to federates• wrap models as Federate instances• add HLA ports for inter-federate interaction• add objects and attributes for state updates• add predictive contract mechanisms

• compile model federate objects• locate federates on network nodes• start coordinator federate• start model federates

• test Models in stage-wise• bottom up fashion on workstation• test federates• test federations


User Interface to DEVS/HLA

Create FederateDEVS(FederationName)

Run FederateDEVS

Start main( )

End of main( )

Done by DEVS/HLA

Done by User

Constructor of FederateDEVS

Constructor of FederateDevs

Create RTIAmbasador

Execute Federation

Constructor of Federate



Create Fedex

Join Fedex

Set Time Management Parameters

executeFederation() of Federate

End of executeFederation()

Create DEVS Models

Add them as components

End of constructor( )

Create HLAports

set up HLAports

Coupling ports

Create object classes

Create their attributes

set up classes and attributes

Link these to DEVS models

for attribute comm

for interaction comm.

Initialize models

run( ) of Federate

Start DEVS simulator

End of run( )

Run Federate


Federate *myFederatemain( ) { ........}

Public: set *components; set *classComponents;

Public: static char *classname;

/* Create FederateDevs */ myFdereate = new FederateDevs(federationName);/* Run FederateDevs */ myFederate->run ( );

/* Create instance of DEVS */ add (new devsModel (TopModelName));/* Specify Interaction Communication */ /* for each interaction */ HLAport *hp = new HLAport (portName); add_outport(hp); or add_inport(hp); setup(hp);/* Specify Attribute Communication */ /* for each object class */ objectClass *oc = new objectClass(“atomicClassName”); /* for each attribute */ oc-> addAttribute (new attribute (…) ); classComponents->add(oc); setup(oc); /* setup env. for comm. atomic model */

/* Create component models */ setAtomicClassName( “atomicClassName”);

main

FederateDevs

devsModel

DEVS/HLA Model Templates


DEVS/HLA Example:Pursuer-Evader-Viewer Model

// constructor of FederatePursWQuant

// create the highest component

PursWQuant *PWQ = new PursWQuant(“PursWQuant”);

// create objectclasses and register them to RTI

objectClass *RedTKObj = new objectClass(“RedTank”);

RedTKObj->addAttribute(new attribute(“position”,0,NULL);

setUp(RedTKObj);

// setup HLAport

HLAport *hp = new HLAport(“fire”);

addOutport(hp); setUp(hp);

// coupling

addCoupling(PWQ, “fireout”, this, hp);

Sample code for a Federate

RedTank

(DEVS comp)

FederatePursWQuant

PursWQuant (DEVS comp)

position

firein

update(quantizer)

interaction(coupling)

BlueTank

Red Tank

Viewer

position

RedTkObj

Blue Tank

position

FederateEvadWEndo

fire

fireout

RedTankEndoModel

(DEVS comp)


DEVS/HLA Example:Pursuer Model

in

inout

out

Red Tank

Driver

PursWQuant

fout

// Constructor of PursWQuant // create components RedTank *redtank = new RedTank (“RedTank”); Driver *drver = new Driver (“Driver”);// add components add (redtank); add (drver);// define interfaces (couplings) addCoupling (redtank, “out”,driver,”in”); addCoupling (drver, “out”,redtank,”in”); addCoupling (drver, “fout”,this,”fireout”);

fireout

// constructor of RedTank// create quantizers and attributes quantizer *qt = new quantizer(name,initValue, quantum); attribute *at = new attribute(“position”, &myPosition, qt); attributeList->add(at);

myPosition

Module 12: Basic CORBA Concepts

CORBA - Common Object Request Broker Architecture Basic Features and Services Interfacing to Objects Connecting to Distributed Objects via Naming Service Event Channel and Real Time CORBA Interoperability of Vendor Orbs CORBA relative to other middleware


CORBAFeature

Brief Description

Language-neutralData Types

Marshalling and de-marshalling of method argumentsgreatly simplify message exchange among objectsover the network

Local/remoteTransparency

Objects can communicate in the same way whetheron a single processor or over a network betweenprocessors with different bit-level architectures

High LevelBinding

Use of IDL interfaces enables objects expressed inarbitrary languages to communicate with each otherand easy wrapping of legacy code.

Self DescribingMeta Data

CORBA offers access to configuration meta data

CORBAServices

Name service, Event Service, Time Service, etc.provide utilities for distributed computing

CORBA Basic Features and Service

CORBA:• an open standard for distributed object computing• defines a set of components that allow client applications to invoke operations with arguments on remote object implementations


CORBA Overview (See Notes Below)


Language Transparency Via Interface

interface servant

CORBA IDL

(InterfacceDefinition

Language)

Implementation--C++--Java

OBJECT

invocation

Internal call


Example: Object Invocation Via Interface

//java

omg.omg.CORBA.Counter c;

//get reference to c via

//naming service using “cntr”

int i = c.getCount();

getCount

//IDL

Module Example{

interface Counter{

int getCount()

};

//C++

class Counter {

int i;

//methods

public:

int getCount(){return i++;}

};

main (){

Counter c = new Counter(“cntr”);

//give reference to naming

//service

}


Connecting to Objects Through Naming Service

Client Server

• initialize ORB

• create new objects and connect to ORB

• get reference to naming service

• register objects with naming service

• get references to server objects via their names

ORB ORB

Naming ServiceThe Naming Service allows clients to find objects based on names using Naming Context specification --providing object location transparency.


Eventconsumer

Eventsupplier

Event Channel 2

Event Channel 1

CORBA Event Service

Common Object Service (COS) Event Service

Eventsupplier

Eventconsumer

• The Event Service provides basic asynchronous communication in ORB, de-coupling event suppliers from the event consumers. • The supplier-consumer model allows an object to communicate an event to any other objects that might be interested in such an event. • Both “pull” and “push” communication mechanism are specified.


• part of Real-Time CORBA Specification • events go through one channel• filtering at consumer is done by producer id• priority and urgency-scheduling is supported•ACE (Adaptive Communication Environment) TAO provides End-to-End QoS

Event Channel

Real-Time Event Service Scheduling Service

CORBA Real Time Event Service

Eventconsumer

Eventsupplier

Eventsupplier

Eventconsumer


TAO (The ACE ORB)

ACE

NamingService

TimeService

EventService

Client

Visibroker ORB

CORBA

NETWORK

Server

Visibroker ORB

Example of CORBA Interoperabilty: TAO Real-Time ORB’s work with Visibroker ORB’s

Internals of services are not standardized, but ORBs can use other ORBs services


CORBA in relation to other Middleware

Java– Java Virtual Machine (JVM)

» cross platform interoperability– JINI technology

» alternative middleware to CORBA

– both require Java as the primary programming language – can work with CORBA

» to provide convenient development environment (e..g Visiboker)

» to support lower layer to set up CORBA run-time environment

DCOM– For Microsoft components

Module 13: DEVS/CORBA Requirements, Design and Implementation

DEVS/CORBA Overview Requirements for Distributed Simulation/Execution DEVS and CORBA: complementary match-up DEVS/CORBA Design and Implementation Applications


Basic DEVS/CORBA Overview

DEVS : - Discrete Event System Specification- Sound formal modeling and simulation framework

CORBA:- Common Object Request Broker Architecture- Open standard as a middleware (network software)

DEVS/CORBA:- Parallel and distributed M&S environment- Improves performance (computing power, execution speed )

- Provides high scalability and availability (infinite resources)

- Lowers the cost of development


• Open, Expressive Environment

• Distributed/Networked (Intra/Inter)

• Model Reuse

• Scalable Performance

Requirements for DEVS/CORBA Distributed Simulation Environment


• Include Simulation as subset

• Interact with other business objects

• Extend to Real time control/management

• Model Continuity thru Development Phases

• Simplify Distributed Programing and Set-up

Requirements for DEVS/CORBA Distributed Real Time Execution Environment


• Hierarchical federations

• Heterogeneous Federations: Logical, Real-time, speed-ahead

• Implement SES at CORBA level

• Automated mapping of pruned SES to hierarchical federations

• Automated distribution of components

Requirements for DEVS/SES/CORBA


CORBAFeature

Benefit for DEVS Implementation

Language-neutralData Types

Together with container specification, this can provide alanguage neutral form of DEVS model specification

Local/remoteTransparency

Supports DEVS-based simulation over heterogeneousplatforms

High LevelBinding

Use of IDL interfaces enables coupling of DEVScomponents in arbitrary languages and DEVS-basedwrapping of legacy code.

Self DescribingMeta Data

CORBA offers access to configuration meta data that maybe exploited for understanding model behavior andmonitoring simulation progress.

CORBAServices

Name service, Event Service, Time Service, etc. offerfunctionality for integration into DEVS/CORBA

DEVS and CORBA: The Match

DEVS : a generic dynamic simulation formalismCORBA: a generic IDL for concretizing DEVS


DEVS/CORBA Implementation

DEVSCorba

SimEngine

System

Util

IDL

FederationManagerFederationCoordinatorImplSimulatorImpl

ActivatorImplDeployerDaemonDEVSNamingServiceLauncher

ObjectSerializerIOProcessSemaphoreStreamThread

AnyPortComponent

Examples

= JavaPackages


DEVS/CORBA Implementation

Genr Proc

Control messages

Simulator(ModelServer)

Network

Transd

data messages



Coordinator

GPT

DEVS/CORBA Interfaces

DEVS models

out

in ariv

solvedout

CORBAName Server

------------------ORB


Example: Distribution over Internet

Genr Proc

Simulators

LAN

Transd

Coordinator

GPT

CORBAName Server

------------------ORB

CoordThread

Internet

LAN

ORB


Distributed Real-Time DEVS Execution Environment

Network

ACE-TAO CORBA

DEVS

SEARCH

RT-DEVS Execution Engine

DEVS Processors/ActivitiesSimulation/execution layer


Proc

Eventconsumer

Eventsupplier

in out

Transd

Eventsupplier

ariv stop

Eventconsumer

solv

Eventconsumer

Genr

Eventconsumer

Eventsupplier

stop out

Event Channel 3

Event Channel 2

Event Channel 1

CORBA Event Service

Mapping DEVS coupling to COS EventService


Proc

Eventconsumer

Eventsupplier

in out

Transd

Eventsupplier

ariv stop

Eventconsumer

solv

Eventconsumer

Genr

Eventconsumer

Eventsupplier

stop out

Coupling Mapping with TAO’s Real-Time EventService

Event Channel

Real-Time Event Service Scheduling Service

SourceID 1

SourceID 1 SourceID 1

SourceID 2

SourceID 2

SourceID 3

SourceID 3

Events are filtered by the associated SourceID


Migrating Simulation Models to Real Time Operation

Network

Par DEVS Sim. Protocol

Visibroker CORBA

DEVS-RT-Simulator

DEVS DEVS-RT

TAO CORBA

ACE Real Time


Real-Time DEVS Formalism Implementation

~ activity

simActivity~tN~myModel~resultMessage

• activity: a wrapper class that specifies a job to be done, the time it requires, and the result (where the latter may be computed as a result of execution)• the base class specifies the parameters explicitly• procActivity: a devs model that can execute an activity as just described

procActivity

procAlwaysActivity

~ alwaysActivity

inputActivity

~processing_time~result

simStepActivity

~tL~iter

~myDevs~resultMessage~passivate

• alwaysAcivity: an activity that can be continually executed• procAlwaysAcivity: processor for alwaysAcitivty that outputs its message• inputActivity: an activity for responding to external events

• simActivity: an activity that is given a devs model. The model is executed until its first non-null output is obtained, which is the result of execution; the actual real time to execute is the time of the activity• simStepAcivity: an activity that is executed in stepwise fashion

atomicentity


parSearch

makeProc procActivitys compActivity

procActivity

~ activity

simActivity~myDevs

•makeProc : gets activity instances as inputs and creates procActivity instances to work on them•compActivity : gets processed activities with their results and keeps track of the best so far, using metric specified in the activity. Outputs the best so far when its allowed time has elapsed.

• parSearch : coupled model for parallel search. SimActivity instances can be alternative devs models generated by automatically pruning an SES (or generated in some other manner)

Real-time Execution of Parallel Search


TAO (The ACE ORB)

ACE

NamingService

TimeService

EventService

Coordinator

Visibroker ORB

CORBA

NETWORK

Simulator

Visibroker ORB

Simulator

Visibroker ORB

Interoperation between TAO Real-Time ORB’s and Visibroker ORB’s

- ACE (Adaptive Communication Environment) Layer provides End-to-End QoS


DEVSCORBA

FederationManager

Activator Pool Federation Pool

[email protected]

[email protected]

GPTFed TerraFed

Genr Proc TransCoord@GPTFed

TS TS”Coord@TerraFed

DEVS-CORBA Naming Tree


GPT Federation :FastSimulation

TS1 TS2

TS3

FactoryFederation: RTExecution

EF

DEVS-CORBA Naming Repository

RTExecCoordinator

DEVS-CORBA Federation Pool

FedName

Coord@GPTFedGPTFed

Components

GenrProcTrans

FactoryFed Coord@FactoryFed

TS1TS2TS3EF

NSFFed Coord@TerraFed

RT1RT2RT3

Type

FastSimulation

RTExecution

RTSimulation

Genr Transd

Proc

FastSimCoordinator

EF@TerraFed

FastSim Simulator

RT Exec


simulatorsimulator

Run Time System (RTS) Setup

acims4.acims.arizona.eduacims11.acims.arizona.edupisces.acims.arizona.edu

.hosts

RTS Manager

daemon

acims4.acims.arizona.edu

Activator simulator1

3

2

simulatorsimulatordaemon

acims11.acims.arizona.edu

Activator simulator

simulatorsimulatordaemon

pisces.acims.arizona.edu

Activator simulator

DEVS Naming and Directory

Service

4Create a daemon

for a processor(using Java rsh)

Create an activatorCreate

Simulator pool

Read a file containing

host addresses

run RTS

Build DEVS NDS


Deploy a Model to Federation

FederationReference

User

Deploy(gpt)1

Activator@acims4

Activator@acims11

Activator@pisces

Simulator(G)

Simulator(P)

Simulator(T)

Coord@GPTFed

G

P

T

Model Partitioning

AndDispatching

2 3 Assign a model to a simulator

5register simulators

to coordinator

DEVS-CORBANamingService

4Bind to

DEVS-CORBA Naming Service

HostBoundary

GPT

G

P

T


Hierarchical Heterogeneous Federations

RTExecutionFastSimulation

Alternative1

Alternativen

Factory Component

Model

Candidate Schedules

Best Schedule

Supervisor


Real world Modelcontrol

Simulatefaster then real-time

Recommendedvalues

Observe in real-time

Parametersettings

Real-time, simulation-based control


DEVS/CORBA

Factory

Data B

ase

Control

Mod

el

of Fact

ory

updates

commands

summariesrecom

mendations

Real-time, simulation-based control (cont’d)

Son, Y., et al. (1999).A Multi-Pass Simulation-Based, Real-Time Scheduling and Shop Floor Control System. Trans. of SCS 16(4): 159-172.


GPT Example executed in DEVS/CORBA Real-Time Environment

Genr Proc Transd LLC

gpt

HLCGenr Proc Transd LLC

gpEndo

LLC (Low Level Control): • queries Transd for TA and Thru• incrementally adjusts Genr rate and Proc #machines toward given thruput goal• Transd represents online DB

DesiredThruput

HLC (High Level Control): • starts gpt and gptEndo with same conditions and thruput goal (gptEndo is executed faster than real time via simulation)• waits for LLC in gptEndo to reach desired thruput and sends setting back to LLC in gpt

Module 14: System Entity Structure


EFA

ARCH

EF

GEN TRANSD

EF

ARCH

COORD

PROC

PROC

Hierarchical Model Construction



efP

processor(proc)

out

arrived

solved

outin

generator(genr)

transducer(transd)

out

out

stop

startstart

ef

solved

startout

out


EFAEFA

EFA-DECEFA-DEC

GENRGENR

COORDCOORD

EFEF

EFA-DECEFA-DEC

TRANSDTRANSD

PROCSPROCS

PROCPROC

ARCHARCH

ARCH-SPECARCH-SPEC

MULTMULT

MULT-DECMULT-DEC

PROCPROC

SYSTEM ENTITY STRUCTURE

specializationdecomposition

multipledecomposition


PRUNING

GENRGENR

EFAEFA

EFA-DECEFA-DEC

EFEF

EFA-DECEFA-DEC

TRANSDTRANSD

ARCHARCH

ARCH-SPECARCH-SPEC

PROCPROC

TRANSFORMING

EFA

PROC

EFGENR

TRANSD

EFAEFA

EFA-DECEFA-DEC

GENRGENR

COORDCOORD

EFEF

EFA-DECEFA-DEC

TRANSDTRANSD

PROCSPROCS

PROCPROC

ARCHARCHARCH-SPECARCH-SPEC

MULTMULT

MULT-DECMULT-DECPROCPROC

Generating Family of Models

Module 15: Collaborative/Distributed DEVS M&S Environment

Distributed Modeling Conceptual View for Collaborative/Distributed M&S


HLA/OMT vs. DEVS/SES

HLA/OMT DEVS System EntityStructure

SOM Atomic Model N/A

FOM Coupled Model Decomposition

Not supported Not supported Specialization & Aspect

Routing Partial routing Not supported


Simulation Engine Simulation EngineHLA/OMT:

FOM & SOM

HLA/Object Model Template

Federate A

Dynamic Model

Federate B

Dynamic Model

Network

RTI RTI


StructureFrame (CDM) +

DEVSModel

(DEVS/HLA)

Collaborative DEVS Modeling

HLA Object Model

yields

translates into

Legend

Dynamics


Setting: A Mountainous region of Yugoslavia. Objective: Maintain a track on the hyper-velocity Red Tank. Platform: Blue Helicopter is a standard variable speed air vehicle.

Equipped with a Ku band radar sensor with a constrained field of regard. Environment Models: Tank traverses the surface of a 1km resolution global terrain database.

quantized

Pitch/AltitudeUpdates

Start/stop @ sensor scan rate

Log-in messages

Start/stop

emissions

High-ResolutionTerrain

GRASSGIS

Red Tank

BlueHelicopter

Space Manager(Emission Propagation)

Logger(Spatial Event Prediction)

EndomorphicRed Tank

HLA

DEVS/HLA Simulation Scenario


TANKEMMISION

PROPAGATION

HELICOPTERTERRAIN

radaremission

radarreturn

radarreturn

radarreturnAttributes:

• position• pitch

position elevation

radarpropagated

estPosition

radarreturn

radaremission

radarpropagated

elevation

DEVS/HLA Federates


position

estPosition

track quality

EXPERIMENTALFRAME

Experimentation with Model


TANK TERRAINEndo

TANKEMMISION

PROPHELI

COPTER

TERRAINTANKEMMISIONPROPAGATION HELICOPTEREndo

TANK

Alternative Federations


Modeling

Collaborative DEVS Modeler(HLA/OMT)

UA Federate

LMSS Federate

UARTI-Executive

Simulation

DEVS/HLASimulator

Host Name PiscesLocation TucsonPort 12357IP Address 128.196.27.96… …

UATucson, AZ

UATucson, AZ

GOSTOP Suspend

Host Name NexusLocation SunnyvalePort 12357IP Address xxx.xxx.xx.xx… …

LMSSSunnyvale, CA

GOSTOP Suspend


CDM & DEVS/HLA ScenarioN

etw

ork

UA/LMMSSimulation Federation

Federate LMMS(Simulation Federate)

Federate UA(Simulation Federate)

DistributedSimulation

UA/YVPGSimulation Federation

Federate YVPG(Simulation Federate)

Federate UA(Simulation Federate)

DEVS/SESModel (Radar)

CollaborativeModeling

Model (Aircraft)

Model (Aircraft)

Model (Terrain)


Component-based M&S Architecture

NetworkHardware (Computing)

Platforms

Database (Persistence Object Store)

DistributedObject Management

Graphical UserInterface

Auxiliary Components(e.g., Genetic Algorithm)

CollaborationEnvironment

DEVS/DESS Simulation

DEVS/DESS Modeling

CDMS Environment

Model ConstructionModel Composition Analysis


Place

differentsame

Time

same

different

conventional meeting

synchronous collaboration

asynchronouscollaboration

Basic Modes of Collaboration


clarifyobjectives

CM

collectdata

AC

Distributed Source

buildmodelbuild

modelCM, SC, AC

validatemodel CM, SC

CM: Conventional MeetingSC: Synchronous CollaborationAC: Asynchronous Collaboration

Collaborative Model Construction


clarifyobjectives

CM

search for components

AC

distributedrepository

sites

build hierarchical

modelAC, SC

executehierarchical

modelAC

CM: Conventional (Electronic) MeetingSC: Synchronous CollaborationAC: Asynchronous Collaboration

Collaborative Model Composition


Collaborative Configuration System

Human Factors Div.San Francisco, CA

Development Div.Boston, MA Collaborative DEVS

Modeler

Electronics Div.Tucson, AZ

XYZ Corporation Four dispersed divisions collaborate to produce Model for “Aircraft Flight in a Synthetic Natural Environment”

Manufacturing Div.Houston, TX


Collaborative Configuration System

SunnyvaleCA

GESNJ

HLA/RTI

UofATucson

SunnyvaleCA

GESNJCollaborative Distributed

Network System

UofATucson

UofATucson

• DEVS/HLA— Distributed Simulation

• Collaborative Configuration System— Configuration— Management/Monitoring


CDM Architecture

CDMenvironment

Knowledge Worker

DM

CDNS

Knowledge Worker

DM

CDNS

Networking Tasks:• connect client to server• receive updates from server• send model to server• etc.

Modeling Tasks:• add component• add link• etc.

Knowledge Manager

DM

CDNS

Modeling Tasks:• update model• etc.

Networking Tasks:• grant/deny client access• broadcst model updates• etc.

DM: DEVS ModelerCDNS: Collaborative DistributedNetwork System

internet


Client Window


Graphical Model


Modeling Window


Distributed Object Computing (DOC)

Technologies enabling distributed software systems– DOC sits at the confluence of two major software technology areas:

» Distributed computing systems» Object-oriented design and programming

– DOC Challenges» Inherent complexities from the fundamental problem of distribution» Accidental complexities from limitations with tools and techniques used

to build distributed software

DOC Design Problem– Even simple Client/Server DOC systems consist of multi-vendor and

heterogeneous components that present non-deterministic performance and capacity planning behaviors

– How to tractably evaluate design performance, alternatives, and tradeoffs

Module 16: Distributed Codesign Methodology

CORBA - Common Object Request Broker Architecture Basic Features and Services Interfacing to Objects Connecting to Distributed Objects via Naming Service Event Channel and Real Time CORBA Interoperability of Vendor Orbs CORBA relative to other middleware


Distributed Cooperative Objects

ObjectSystemMapping

arc

Loosely Coupled Network

processor

link

gate

softwareobject domain

DEVS-DOC Models

DEVS:– Formal systems-theoretic M&S

framework

– Dynamic system representation

– Hierarchical, modular modeling DOC:

– Distributed Codesign approach

– Independent SW & HW modeling

– Coupling SW & HW models (OSM) produces dynamic model

Distributed Cooperative Objects

arc

softwareobject domain

Distributed Cooperative Objects (DCO)

The software architecture component Object-oriented paradigm

– A set of attributes– A set of methods

Software objects interact via arcs

– Peer-to-peer: messaging arcs– Client-server: invocation arcs

Software interactions invoke methods, which create jobs

– Synchronous interactions block jobs– Software object thread mode setting dictates job

execution concurrency» None: only one active job at a time

» Object: only one active job per object method

» Method: an active job for every interaction

Software objects “load” the LCN via – Active software objects: memory loading– Interactions: communications loading

– Jobs: computational loading


Modeling Software Objects

Defining software methods:– Quantum modeling

» Name

» Computational Workload

» Invocation Probability

– Directed modeling» Name

» Task sequences of Computational Workloads Arcs

Defining software arcs:– Name– Destinations– Size– Return Size– Message Type

synchronous, asynchronous, return, message

– Time Out– Firing Frequency

(quantum modeling)

– Method Called (directed modeling)

Defining DCO software objects:– Name of object for reference– Size of object for memory loading

– Thread Mode of object: none, object, method

– Methods a set of methods– Arcs a set of interaction arcs

– Duty Cycle for defining initializer objects– Initialization Method for directed modeling of

initializer objects

Modeling concepts– Quantum modeling: for any one invocation, the

method selected is irrelevant as long as the invocation is in correct proportion to the aggregate invocations of all methods

– Directed modeling: each invocation specifies a method for execution


Software Object Structure

swObjectstate variables initial value range

sigma: 0, [0 .. ]phase: fire, {passive,active,fire}activeJobs: empty relation 0 or more thread-Job pairscommJobs: empty function 0 or more Job-blockedStatus pairsqueuedJobs: empty relation 0 or more thread-Job pairstimerMsgs: empty relation 0 or more timeOut-Msg pairsfireJobs: empty set 0 or more JobsfireMsgs: empty set 0 or more MsgsloadStatus: unloaded, {unloaded,onDisk,inMem}

parameters default value rangeobjectSize: 0 bytes [0 .. ]threadMode: none, {none, object, method}methods: empty set 0 or more methodsarcs: empty set 0 or more dcoArcsdutyCycle: [0 .. ]initMsg: null msg a Msg

inMsgs

inJobs

outMsgs

outJobs

outSW


Software Object Dynamics

fire,0 activeJobs={(O1 J1)}firingJobs={J1(A,O1,50,100,M1)}

X

S

e

Y(outSW, (A,Mem,1000,load))(outJobs,J1(A,O1,50,100,M1))

(inMsgs, M1)M1.returnSize=10

passive,

active, activeJobs={(O1 J1)}

(doneJobs,J1(A,O1,50,100,M1))

(outJobs,J1(A,O1,50,50,M1))(outMsgs,M2.A1)

fire,0 activeJobs={(O1 J1)}firingJobs= {J1(A,O1,50,50,M1)}firingMsgs={M2.A1}

active, activeJobs={(O1 J1)}

fire,0 firingMsgs={returnM1,M3.A2}

(doneJobs,J1(A,O1,50,50,M1))

(outSW,(A,Mem,1000,unload)(outMsgs,returnM1)(outMsgs,M3.A2)

passive,

Loosely Coupled Networks (LCN)

Loosely Coupled Network

processor

link

gate

The hardware architecture component Processors

– Invoked software objects load memory

– Software object jobs load cpu

– Software object interaction messages converted to packets for routing across LCN

Gates– Interconnect two or more network links

– Two types of gates» Routers switch LCN traffic between links

» Hubs broadcast LCN traffic across links

Links– Provide a communications path

between processors and gates


Modeling Processors, Gates, & Links Defining Processors

– Name of processor

– CPU Speed of processor

– Memory Size of processor

– Swap Time Penalty associated with memory swaps

Defining Gates– Routers

» Name of router

» Header Size for wrapping local packets

» Link Speeds for each incident link

» Bandwidth internal to router

» Buffer Size internal to router

– Ethernet Hubs» Name of hub

» Link Speeds for each incident link

» Bandwidth internal to router

» Buffer Size internal to router

Defining Ethernet Links– Name of ethernet– Number of Segments for determining worst case

propagation


LCN Processor Structure

Processor

cpu

transportinMsgs

inLink

inSW

inJobs

inMsgs outMsgs outMsgs

inLink1 outLink1 outLink

inLoop

inSW

router

inJobs outJobs outJobs

inPkts outPkts

outLoop inLoop

The processor is a DEVS coupled model

– Transport component» Converts outgoing DCO

messages into packets and incoming packets to DCO messages

– Router component» Inspects destination of packets

and routes accordingly

– CPU component» Invoked DCO software loads

memory» DCO jobs are received,

executed, and released


LCN Gate Structure

Gate

Hether1

Hether2

HT1

RouterIN0 / OUT0

IN1 / OUT1

IN2 / OUT2

ININ0

IN1

IN2

OUT0

OUT1

OUT2

IN

IN OUT

OUT

OUT

INLOOP OUTLOOP

INLOOP OUTLOOP

INLOOP OUTLOOP


Modeling Framework: OSM

Maps DCO objects onto LCN processors

Defines communication modes: message segmentation into packets– Packet size

– Packet overhead

– Packet acknowledgement size

– Acknowledgement timeout Maps invocation and message

arcs onto communications modesLoosely Coupled Network

linknode

Distributed CooperativeObjects

software object

arc

ObjectSystemMapping


DEVS-DOC Experimental Frame


DEVS-DOC Modeling Process

Map software onto processors

(OSM)

Define processors, routers, hubs, links,

and network topology (LCN)

Define software objects and

interactions (DCO)

DOC

Configure simulation control and data collection components

(Experimental Frame)

Run simulation and analyze results

Desired performance &

behavior?

no

Refine distribution?

stopyes

Refine software design?

Refine hardware design?State M&S objectives


DEVS/HLA and Predictive Contracts Case-Study DEVS/HLA

– DoD HLA-compliant M&S environment – Mapping of DEVS-C++ to DMSO RTI (C++)

Predictive Contract Research– How to reduce message traffic exchanged between distributed simulation federates with a

marginal addition to computational overhead?

Three predictive contract mechanisms studied– Non-predictive quantization: send a real-valued variable update for each threshold crossing

– Predictive quantization: send a single bit variable update to signal next higher, or lower, threshold crossing

– Multiplexed predictive quantization: send a set of single bit variable updates in one message between federates

» Applicability: large number of models per federate


Pursuer-Evader Federation

Pursuer Federate Evader Federate

Pursuer

Pursuer

Pursuer

Evader

Evader

Evader

DEVS/HLA

EvaderWEndoPursuer

Red Tank

position

Red TankEndo Model

position

drive

in out

fireOutfireIn

update (quantizer)

interaction (coupling)

Evader

perceive

BlueTank

out in


DEVS/HLA Federation Infrastructure

CoordinatorEndo

Simulator A

System Models

User Models

Federate P

CoordinatorEndo

Simulator B

System Models

User Models

Federate E

Coordinator

SimulatorEndo A

System Models

Time Manager

SimulatorEndo B

tN

tN1

tN

tN2

RTI Exec Fedex

tN: Global DEV TimetNi: Time of Next Event of Federate i

ModelP1

ModelP1

ModelP1

ModelP1 Model

E1

ModelE1

ModelE1

ModelE1


Real System Predictive Contract Results


DEVS-DOC Simulated Results For DEVS/HLA Predictive Contracts

Comparing Quantization - Simulated Run Time

10

100

1000

10000

100000

1000000

1 10 100 1000 10000

Number of Sender/Receiver Pairs

Se

co

nd

s

Non-Predictive

Predictive

Multiplexed

Comparing Quantization - Ethernet Busy Time

0

1

10

100

1000

10000

1 10 100 1000 10000


Se

co

nd

s

Non-Predictive

Predictive

Multiplexed


DEVS-DOC Runtime Performance

Comparing Quantization - Real Execution Time

1

10

100

1000

10000

100000

1 10 100 1000 10000


Min

ute

s

Non-Predictive

Predictive

Multiplexed


DEVS Modeling Constructs

Operating System

Distributed Object Computing Modeling Constructs

Persistent Object Store Middleware (CORBA)

AuxiliaryModules

(GUI)

Distributed Simulation (DEVS/CORBA) Uniprocessor Simulation

Parallel DEVS (DEVSJAVA)

Modeling Layer

Simulation Layer

DE

VS

-DO

C

DEVS-DOC M&S Environment

Module 17: DEVS/HLA Support of Joint Measure TM *

Joint MEASURETM: Motivations, Objectives, Applications

Joint MEASURETM Background

–Joint MEASURE Overview

–The Distributed Joint MEASURE Architecture.

DARPA/ASTT Technology Demonstration

Joint MEASURETM Benefits to Systems-of-Systems Analysis

* Mission Effectiveness Analysis Simulator for Utility, Research and Evaluation developed by Lockheed Martin Missiles and Space Systems


Mission Effectiveness

SBA: early assessment of new system’s expected mission effectiveness

Assess contribution to overall ability to counter an enemy threat: ability to gather and share information, survive service hostile targets.

Difficulty: large impacts due Subtle design decisions modest alterations use of the system minor modifications of the scenario


Goals and Objectives:

Assist in evaluating a proposed system’s mission effectiveness, wrt specified set of possible design variations operational utilization patterns engagement scenarios

Need for High Performance: It is easy to generate a requirement to simulate a multi-hour analysis scenario thousands of times.

Repeatability: based on DEVS, a logical model formalism with a well-defined state concept, Joint MEASURETM has the ability to exactly replicate simulation runs

Maintainability and Reusability: The modular aspect of DEVS models enforces a software engineering practice that simplifies code reuse and simplifies the construction of new federations from existing components

Portability at a high level. The high-level of abstraction provided by the DEVS formalism subsequently facilitated porting the system to DEVS/C++ and later to DEVS/HLA


Applications:

JCTN - Utility of measurement-based sensor fusion.

– Access to remote (I.e., non-LMMS) Lockheed Martin models.

– End run around ‘proprietary’ concerns.

DD21/Deepwater - Analysis of system-of-system options.

– Complex scenario modeling requirements (with concomitant performance requirements).

– Need to integrate/interface models developed by number of team mates.

– Eventual need to integrate person-in-the-loop simulation with analytically simulation.


RTIExecutive

DEVSFederate

RTIAmbasador

JointMEASURE

DEVSFederate

RTIAmbasador

OPNetCommModel

DEVSFederate

RTIAmbasador

DD21(WarshipModel)

DEVS/HLA Joint MEASURE Federations

Internet


Joint MEASURETM Overview

• Mission Effectiveness Simulator Generator– Intended for Monte-Carlo analytical work.– High performance is a priority.– Expected to be used by broad community.

• Provides an infrastructure composed of:– DEVS-Compliant Models/DEVS Simulation Engine

- Emission Propagation- Spatial Encounter Prediction

– Geographical Information System (GIS).– Data Modeling and Analysis Toolkit.– Graphical User Interface (GUI)

• Archives a library of reusable models:– Sensors – Weapons– C2– Environment


• Scenario SpecificationCan be specified interactively.

Specification includes: variable routes, behaviors and subsystems and the attributes of those subsystems.

Scenarios can be stored, retreived and concatenated.

Provides full access to underlying GIS.

Provides most useful map projections. • Runtime Visualization/Animation

Optional 2d-3d run-by-run animation.

Display clutter controls.

Runtime data analysis updates.

Start/Stop/Pause.

• Data AnalysisCollects and displays a variety of

mission effectiveness data.

Integrated with Prophet (a statistical and modeling package with report generation capabilities.)

Joint MEASURETM Overview

User Interface, Graphics and Animation


Joint MEASURETM Architecture

SimulationEngine

InfrastructureComponents

GIS GUI

DataAnalysis

Reusable Models

Alternative Models

Hierarchical Decomposition

Emission Propagation

Encounter Prediction


The Non-Distributed Joint MEASURETM Architecture

Logger

PropagatorPlatform

Sensors

Weapons

C3

Hull

Platform

Sensors

Weapons

C3

Hull

GIS

GIS dB


The Non-Distributed Joint MEASURETM Architecture

Platform(s) - Top Level Modeling Components

– Encapsulate Sub System Models:

(Hull, Sensors, Weapons, Comms, C2)

– Interact with other Platforms via ‘Emissions’ Spatial Encounter Predictor (Logger) - Infrastructure Component

– Calculates when events could occur.

– Publish and Subscribe oriented.

– Handles detection, firing and collision events.

Propagator - Infrastructure Component– Determines signal and noise strength and latencies.

– Interfaces to GIS system for environment models.



DEVS/HLA and Support of Joint Measure

Network

DEVS

HLA/RTI

Joint Measure


Logger

PropagatorPlatform

Sensors

Weapons

C3

Hull

Platform

Sensors

Weapons

C3

Hull

GIS

GIS dB

Logger

PropagatorPlatform

Sensors

Weapons

C3

Hull

Platform

Sensors

Weapons

C3

Hull

GIS

GIS dB

Hull Hull

HLA/RTI over Internet

Endomorphs Endomorphs

LMMS

The Distributed Joint MEASURETM Architecture

The Distributed Joint MEASURETM Architecture

Infrastructure components are replicated.

Endomorphs are created in remote Federates.

Remote Loggers announce when updates are relevant via ‘events’.

Models update their endomorphs via ‘object updates’.


The Goal of DEVS/HLA Joint MEASURE Validation Test Bed

Establish the practicality of using the DEVS/HLA approach in an industrial strength application.

Demonstrate that remote models can be accessed for analytically demanding purposes.

Explore the impact of alternative distribution strategies on performance and fidelity.

Quantify the resulting performance and fidelity improvements and/or tradeoffs.


quantized:•altitude•pitch

radaremissions

radarXsection

LAN

SpaceModel

• emissions prop agation• spatial encounter prediction

Endomorphic model preserves radar reflective properties

Lockheed/UA Joint Measure: Space Based Radar Detection

HLAInternet

Federate UA Federate LM


ASTT Test Bed Scenario Features(A Distributed HEL Weapon Architecture Evaluation Test Bed)

Approach– Distribute models to processors on the basis of affiliation.

» Enemy Threat platforms execute on Processor ‘A’

» Friendly HEL Architecture(s) execute on Processor ‘B’.

– All models are responsible for maintaining remote endomorph(s).

– All detection/tracking is performed locally against endomorphs.

– Other interactions (e.g. detonations) are transmitted over the network.

Model’s Update Algorithm for maintenance of Endomorphs– Models maintain their own (possible dynamic) signature databases.

– Models monitor (with local logger support) position of possible detectors.

– Models update selected signature cell values in response to:» Dynamic changes in their own signature cell values.

» Motion derived changes in detector bearing and elevation.

– Updates are quantized in order to control the update frequency.

Test Bed Support for Algorithm Evaluation– Quantization parameters can be easily manipulated.

– Number of processors distributed over can be increased.

– Endomorphs can be eliminated for baseline case


Summary: DEVS Framework and DEVS/HLA

DEVS provides sound system-based modeling framework DEVS/HLA (implemented in C++/Java) provides

sound/user-friendly environment for developing HLA-Compliant simulations

DEVS/HLA supports integration of common modeling approaches

DEVS/HLA supports Hierarchical Modeling as well as efficient parallel/distributed simulation

DEVS/HLA supports Predictive Contract Methodology Collaborative DEVS Modeler and other DEVS tools

support FEDEP development

Module 18: Efficient Large Scale Distributed Simulation

Predictive Contract Methodology DEVS Bus Concepts Representing Discrete-time and Differential Equation

Systems Coupling Agents and Environments Developing Efficient Distributed Simulations


Component Model

Simulator

Messaging

CoupledModel

Coordinator

Messaging

Communication is bottleneck due to large number of interacting entities

Limitedbandwidthchannel

Bandwidth Constraints on Distributed Simulation

Coordinatormanages timeand messagerouting

Simulator interfaces modelto coordinator

HLAmiddleware

Component Model

Simulator

Messaging

Component Model

Simulator

Messaging


Overcoming Bandwidth Constraints

Simulators use local models of remote federates to reduce need for updates e.g. Dead Reckoning

Publish/Subscribe routes updates within classes

Spatial Encounter Prediction (routing space) reduces message exchange to pairs that are (dynamically) close

Component Model

Simulator

Messaging

Component Model

Simulator

Messaging

Component Model

Simulator

Messaging

Quantization reduces update message volume and size


Local Computation Tradeoffs and Scalability

Localcomputationoverhead

Communicationreduction

high

low

low high

Quantization

Predictive quantization

Spatial EncounterPrediction

LocalModels


DEVS Bus Concept

RTIRTI

messagemessage

DEVSDEVS

HLAHLA

DEVSDEVS

HLAHLA

messagemessage messagemessage

DEVSDEVS

HLAHLA

Diff Eq.SystemsDiff Eq.Systems

Discrete TimeSystems

Discrete Event

Formalisms


Quantization Predictive Filtering

quantization– non-predictive

– predictive

– scalability

error characterization– error/message reduction tradeoff


Quantization


Non-predictive Quantization

• sender generates fixed time step outputs• quantizer demon is applied to sender output• reduce number of messages sent• but not their size• quantizer incurs some computation• sender’s computation unaffected• receiver must persist attribute values

Sender Receiver

Quantizer


Predictive Quantization

• sender employs own model to predict next boundary crossing• sends one-bit message at crossings• Advantage: reduce both number of messages and size• multiplex messages together to exploit small message size• prediction can also reduce sender’s computation• time stamping: background (logical) or absent (real time)

Receiver

Sender

(t1,1) (t2,1) (t3,1)

t1 t2 t3


X,Y: predictive attributes

Z: non-predictive attribute

X Y

D

Z

DZ

Combined Predictive/non Pred. Quantization

Z

X

Y

x: Px X:

y: Py Y:

z: Qz Z:

+1,-1

+1,-1

real

x: Px X:

z: Z:

y: Py Y:

D (when changed)


Predictive Quantization: Detail

• employed model can be very simple– standard integrator :: linear extrapolation

• time = quantum size/input (derivative)• boundary = up/down according to sign(derivative)• map Diff. Eq. system component-wise using memory-less

equivalents (see next figure)

– double integrator :: 2nd order extrapolation (used in Dead Reckoning)

• (time, boundary) determined by smallest positive root of algebraic solution (quantum size, p, v, a)


Scalability of Predictive Quantization

Sender

#computations(D)Receiver

#messages(D)

#bits(D)

0

#bits(D)

Quantum size, D

#messages(D)

non-predictive

predictive predictive

Quantum size, D0

#computations(D)

non-predictive2-3Orders of

Magnitude


Error Characterization

• local– federate-measured difference between hi fi and 2nd order model

– cannot guarantee control on global error

• global– deviation from true global state

– propagation, feedback

– theory developed and validated

– error can be reduced to below any given tolerance level with small enough quantum size

– typically, require quantum size no smaller than 10% to 0.1% of range of variable


Favorable Tradeoff in Quantization

#messages

Avg Transit Time

Saturationlevel

Execution Time

CAN EXPECT extremely favorable tradeoff in execution time (or number of concurrent entities) near system saturation level

• If tolerance = 1% of Full Scale, Dtol = Full Scale /100 c, ranging from Full Scale/1000 to Full Scale/50

#messages(D) = #messages(1)/D

Error tolerance

0 1Quantum size, D

Error = c D

Dtol = tolerance / c

Full Scale

•Experiments with a variety of examples show that c ranges from 0.5 to 10.


Quantization Test Cases

A variety of examples have been investigated classical ODEs (orbiting body,predator/prey, slow/fast system,

chaotic system) spatially distributed system (heat seeker in diffusion field) multi-entity systems (pursuer/evader pairs,urban traffic, follow the

leader)

Results confirm the theoretical predictions and provide estimates of parameters and tradeoff relations


Visualized Examples of Quantization

Heat Seeker in Diffusion Field• source• seeker (sensitivity = .05)• temperature (colors)

0.00

001

0.00

01

0.00

1

0.04 0.1 K Messages

020406080

100K Messages

execution time

Quantum size

tolerableerror level

Can increase quantum size to seeker sensitivity level while still getting samequalitative behavior


Mapping DESS Directly into DEVS

d s1/dt s1f1x

d s2/dt s2f2

d sn/dt snfn

sx

sx

sx

...

DEVS

DEVS

DEVS

F

F

F

d s1/dt s1f1x

d s2/dt s2f2

d sn/dt snfn

sx

sx

sx

...Component-wise mappingbased on predictive quantization

Persistent Function Element

Predictive Quantizer Integrator


Stress Test: Rossler Choatoic ODE

Advanced Simulation Technology Thrust

21

+

y x- 1

- 1

f z

f z ( x , z ) = b + ( x – c ) * z

z+

- a

Stress Test : Rossler Chaotic ODE

Theory: Global error of non-predictive quantizationwith time step h, should be same as predictivequantization with h = D/max derivative.


Quantum size and DEVS/HLA Federate Assignment

a)

b) c)

fireOut

fireIn

a)

fireOut

fire

fireIn

ExecutionTime (secs.) forcase

Quantum_size

a) b) c)

0.01 5,237 4,856 6,6840.05 1,050 942 * 1,0290.1 757 845 997


Baseline Quantization for Multi-entity Federates

Qvalue

value

value

value

value

value

value

value

Q

Q

Q

Federate A Federate B

model An

model An-1

model A2

model A1

model Bn

model Bn-1

model B2

model B1

double(64 bits)

Network


Predictive Quantization Multiplexer

PQvalue

value

value

value

value

value

value

value

PQ

PQ

PQ

network

Federate A Federate B

model An

model An-

1

model A2

model A1

model Bn

model Bn-

1

model B2

model B1model M model M’

2bits foractive/+1 /-1

D

D

D D


Predictive Multiplexer vs Baseline Performance


Three types of component coupling• physical to physical -> environment• agents to environment• agents to agent

agents -- system components with perceptual, decision and usually mobility capabilities

• micro satellites• urban traffic• robot colonies• mobots

environment -- spatial layered variables with energy propagation capabilities

Coupling Agents and Environments


Component-to-component

AtmosphereOcean

SeaSurfaceTemps

WindStressheat fluxes

water fluxes

Daily at noon Daily at midnight

Coupling of physical components• different resolutions• synchronization• load balancing


Agents-to-Agents

SpatialModel

Agents

locations couplings

Agents interact through• sensing each other• communicating with each other

Spatial Encouner Prediction reasons whether pairs of agents can interactEmissions Propagation

Both kinds of interactioncan employ endomorphicmodels, i.e., models of self or other components in the system


Communicating Agent Interaction

SendingAgent

Endomodel

Sending Agent

Receiving Agent

InfoAbout My

State

ReceivingAgent

Endomodel

Endomodels used within agents to enable them to communicate about their internal states


Perceiving-Reflective Agent Interaction

ReflectiveAgent

Endomodel

Reflective Agent

Perceiving Agent

How I look

Perceiving

Agent Endomodel

LANInternet

Endomodels used by simulators •to reduce message traffic• to overcome latency in real time operation


Endomodel

Sending/ReflectiveAgent

Experimental Frame defined byNeeds of Receiving/Perceiving Agent

Endo-morphism

Sending/ReflectiveAgent

Endomodel

State transition

homomorphism

Endomorphic Model Construction

LEGEND

Summary

Scalability

– local computation overhead

– ability to reduce bandwidth requirements Quantization, especially, predictive quantization

– scalable mechanism

– good message filtering properties

– multiplexing can exploit the message size reduction for large numbers of entities,

– providing high communication reduction

– with low computation overhead. Quantization methods can be combined with other schemes

– local models

– spatial encounter prediction

– potentially provide greater load reduction

– cost of increased local computation.

Module 19: Zero Lookahead Simulation: DEVS and HLA


Mapping DEVS Models to HLA

Maybe transformbefore mapping?

Parallel DEVS model

C++/HLAJava HLA

Mapping must preserveSimulation logic in themapped space for observables

Tom. Lake(a)glossa.co.uk


HLA Logical Simulation Constructs

* The shared part of the simulation NOT the implementation*HLA provides a distributed whiteboard on which these things evolve

* Objects instances of classes

* Attributes of objects

* Interactions instances of classes

* Parameters of interactions

All seen by all subject to Interest Mgmt


Logical Evolution in HLA

Ownership exchange

Register Object DiscoverObject

UpdateAttributeValues* ReflectAttributeValues*DeleteObject * RemoveObject *

SendInteraction * ReceiveInteraction *

* Only these have logical times attachedOthers must happen “early enough”


What are Federates For?

Federates host objectsFederates keep time for objectsFederates manage interest for objectsFederates send and receive interaction for objectsFederates send and receive object attribute changes

One software system can have many federate interfaces to a federation

Of course HLA started by assembling federates….


Some surprising Things….

Interactions are not like messages.Interactions are seen by all subject to interest Mgmt

• Register object is not a timestamped operation in HLA• Change of attribute value cause objects to be discovered


Distributed Computing is HARD

Heterogeneous platforms with different data formatsDelays in networks make it costly and slow to coordinate the components

Cause of delays:Speed of lightRouter delays, lossesATM queues, lossesTelcos can switch routes….


The time ordering problem

We are committed to taking events in logical time order

But events can happen remotely.

How can we be sure that we have not missed any?

RTI cannot advance beyond LBTS

Least Bound on (incoming) Time Stamp


Time Ordering -- Some Solutions

Optimistic techniques -- correct ordering faults when they occur

Conservative techniques -- don’t let problems ariseRequires (for efficient large-scale operation):-Lookahead -- give output events to RTI early.Or Synchronous timestepping

Smart mappings of the problem may help give lookahead


Lookahead -- what is it?

You have lookahead L if your output is complete up to time t-L at time t

Output means output attribute changes (predicted) and interactions that you give rise to and object deletions that you perform.

Can get lookahead in models as:reaction time, minimum travel time, processing time, inertia, etc.

Sometimes transform models to move lookahead around( Paper 160 this meeting).


Conditional Advance With Lookahead

I can go without smoking until 10pm but if someone else lights up I can only hold out 5 minutes

I can hold out without smoking until 9pmSetLookahead(0min)TimeAdvanceRequest(9pm)

Lights up at 9:00pm

SetLookahead(5min)NextEventRequest(10pm)

Lights up at 9:05pm

Global LBTS is 9:00pm then 9:05pm


Zero Lookahead Simulations, DEVS and HLA

DEVS -- lookahead is not automatically presentWe can sometimes transform it in .E.g. map DEVS phases to RTI time, time to an interaction

RTI -- Normally gives all events up to AND INCLUDING time t before giving TimeAdvanceGrant(t) and parallel DEVS needs this guarantee( in the obvious mapping) to outputBut RTI can only guarantee “up to time t” for federates with zero lookahead (and will only do this in response to NextEventRequestAvailable)

Solution: Smart mappingor communicate “ output at time t complete” explicitly


Without Lookahead?

Not a problem for small scale simulations

Not a problem if time is coarsely “chunked” so that many events are simultaneous.


Mapping Models to HLA

Some of the cases are hard because distributed computing is hard

Where we need smart mappings it is essential to start with a sound definition of the model.

The tools to solve the problems, whether through optimistic simulation or smart mappings can only arise in a well-defined framework for modeling AND simulation.


Some Open Issues & Research Directions

• Characterize the class of logical-time models that HLA/RTI can support

• Simulation algorithms interoperability• DEVS/HLA migration to real-time and its integration with its logical-time counterpart

• Predictive contract methodology • model/simulation dependent characterization• the best mix of schemes for a given application context


• Research Mission

– basic for improved infrastructure

– applied to challenging problems

• Education Mission

– degree programs in M&S discipline

– training of M&S professionals

– short courses, tutorials

• Service Mission

– support M&S needs of government and industry

AZ Center for Integrative M&S

Module 20: DEVS-based Tools in Supportof HLA-Compliant Simulations

DEVS/HLA C++/Java DEVS/CORBA Joint MEASURETM

Collaborative DEVS Modeler DEVSJAVA DEVS-DOC


DEVS-Based HLA Tools

TOOLS FEDEPPhase

Dvlp.Org

DEVS/HLA C++/Java 3,4,5,6 UA*/LM

Joint MEASURETM

3,4,5,6 LM

Collaborative DEVS Modeler 2,3 UA

DEVSJAVA 2,3,4 UA

DEVS-DOC 2,3 UA


DEVS/HLA

Purpose: Generic Environment for DEVS-based M&S Major Functions:

– System-theory and formal M&S concepts– Enables developing components in DEVS C++/Java– Supports predictive contract methodology &

parallel/distributed execution of federations– Industrial strength capability (e.g. Joint MEASURETM)

HLA FEDEP Support: Phases 3, 4, 5 and 6


DEVS/HLA (cont.)

HW/SW Specification:

– Computing HW platforms: Unix workstation & PC

– OS: Unix Solaris & Windows NT

– Languages: C++ & Java

– Versions 1.3 (supports RTI 1.3) Organization: University of Arizona (with help from Lockheed Martin)

POC: – Bernard Zeigler

– Ph: 520-626-4846

– Email: [email protected]

– URL: www.acims.arizona.edu


Joint MEASURETM

Purpose: Assess Sensor-weapon, System of Systems Mission Effectiveness

Major Functions: – DEVS/HLA compliant hierarchical, modular models

– Extensive model libraries (e.g., C4ISR, lasers and targets)

– Integrates GIS, rich visualization, & statistical analysis

– GUI supports analyst-friendly interactivity HLA FEDEP Support: Phases 3,4,5 and 6


Joint MEASURETM (cont.)

HW/SW Specification: – Computing HW platforms: Unix workstations– OS: Solaris – Language: C/C++– Version: 1.1

Organization: Lockheed Martin Missile Space

POC: – Steven Hall

– Ph: 407-742-2903



Collaborative DEVS Modeler

Purpose: Anytime/anyplace model development Major Functions:

– Facilitates collaborative hierarchical, modular model development

– Model-based modeling (component model reuse)– Supports single/multiple users – User-friendly Interface

HLA FEDEP Support: Phases 2 and 3


Collaborative DEVS Modeler (cont.)

HW/SW Specification: – Computing HW platforms: Unix workstation, PC, & Mac– OS: Solaris, Windows, Mac-OS, Linux – Language: Java

Organization: University of Arizona POC:

– Hessam Sarjoughian

– Ph: 520-626-4846




DEVSJAVA

Purpose: Prototyping of Distributed Simulations Major Functions:

– Enables design of HLA federates and federations

– Seamless transition to DEVS/HLA and DEVS/CORBA

– Supports M&S Education

– Easy to use DEVS-Based M&S Environment

– Object-oriented

HLA FEDEP Support: Phases 2, 3, and 4


DEVSJAVA (cont.)

HW/SW Specification: – Computing HW platforms: Unix workstation & PC– OS: Unix Solaris & Windows

Organization: University of Arizona

POC: – Bernard Zeigler/Hessam Sarjoughian

– Ph: 520-626-4846

– Email: {hessam|zeigler}@ece.arizona.edu



DEVS-DOC (Distributed Object Computing)

Purpose: Distributed M&S Co-Design Environment Major Functions:

– Supports distributed co-design (e.g., DEVS/HLA Federation Design)

– Supports concurrent HW and SW layers HLA FEDEP Support: Phases 2 and 3 HW/SW Specification:

– Computing HW platforms: Unix workstations and PCs

– OS: Solaris and Windows

– Language: Java Organization: University of Arizona POC: Daryl Hild, Hessam Sarjoughian Email: [email protected], [email protected]


DEVS/CORBA

Purpose: Generic Environment for DEVS-based M&S Major Functions:

– System-theory and formal M&S concepts– Enables developing components in DEVSJAVA– Business strength capability


DEVS/CORBA (cont.)

HW/SW Specification:

– Computing HW platforms: Unix workstation & PC

– OS: Unix Solaris & Windows NT

– Languages: Java

– Visibroker (Version ?) Organization: University of Arizona

POC: – Bernard Zeigler

– Ph: 520-626-4846




More Information

Many more publications and downloadable softwareare available from Website: www.acims.arizona.edu

Committee on Technology for Future Naval Forces, N. R. C. (1997). Technology for the United States Navy and Marine Corps, 2000-2035 Becoming a 21st-Century Force: Volume 9: Modeling and Simulation. Washington, DC, National Academy Press.

Zeigler, B. P. (1998). A Framework for Modeling & Simulation. In Applied Modeling & Simulation: An Integrated Approach to Development & Operation. D. Cloud and L. Rainey, (Eds)McGraw Hill.

Zeigler, B. P., H. Praehofer, T. G. Kim (2000). Theory of Modeling and Simulation. Second Edition, New York, NY, Academic Press.

creating distributed simulations: the triad website: bernard p. zeigler hessam s. sarjoughian...

Documents

roles of hla

dod simulations

dod modeling

ms module1

msrise of ms

us defense hla policy

distributed simulations

dod industrymodule