DEVSTENA Distributed Simulation

1
DEVS/TENA Distributed Simulation

• ECE 676

2
Contents

• TENA
• DEVS/TENA System
• DEMO

3
TENA
4
Test and Training Enabling Architecture (TENA)

• TENA
• Primary goal is to bring affordable
  interoperability to US test and training ranges
  and their customers.
• Supports the implementation of the Joint Vision
  2020 by promoting integrated testing and
  simulation-based acquisition through the use of
  the concept of a Logical Range.
• (Logical Range a suite of TENA Resources,
  sharing a common object model, that work together
  for a given range event.)
• Is a product of the Foundation Initiative 2010
  (FI2010) project, sponsored by the Central Test
  and Evaluation Investment Program (CTEIP)
• The core of TENA is the TENA Common
  Infrastructure, including the TENA Middleware,
  the TENA Repository, and the TENA Logical Range
  Data Archive.

5
TENA Architecture Overview
TENA Applications
TENA Tools
TENA Middleware
Range Resource Application
RangeResource Application
ReusableApplications
RangeResource Application
ReusableApplications
TENA Object
TENA Object
TENA Object
TENA Repository
LogicalRangeDataArchive
TENA Middleware
TENA Common Infrastructure
TENA
Logical Range Planning Utilities
DataCollectors
Gateway
Repository Utilities
Non-TENA Communications
Object Model Utilities
Non-TENA System
Non-TENA System
Non-TENA Applications
TENA Utilities
6
Technical Driving Requirements

• Interoperability
• The characteristic of a suite of
  independently-developed components, applications,
  or systems that implies that they can work
  together, as part of some business process, to
  achieve the goals defined by a user or users.
• Reusability
• The characteristic of a given component,
  application, or system that implies that it can
  be used in arrangements, configurations, or in
  enterprises beyond those for which it was
  originally designed.
• Composability
• The ability to rapidly assemble, initialize,
  test, and execute a system from members of a pool
  of reusable, interoperable elements.
• Composability can occur at any scalereusable
  components can be combined to create an
  application, reusable applications can be
  combined to create a system, and reusable systems
  can be combined to create an enterprise.

7
TENA Meta-Model

• TENA object services fall into three broad
  categories
• Stateful Distributed Objects (SDOs) a
  combination of a CORBA-like distributed object
  with a distributed publish and subscribe system
• Messages transient pieces of information
  flowing from one application to potentially many
  subscribing applications
• Local Classes extend data structs into server
  and client side objects with implementation
  behavior
• SDOs are real software objects with both
  interfaces and state information.
• Messages are used to exchange information
  concerning one-time events.
• Local Classes support server and client side
  behavior to provide interoperability helper
  objects

8
Stateful Distributed Objects

• An SDO is a combination of two powerful concepts
• a distributed object paradigm (like the one used
  in CORBA)
• a distributed publish and subscribe paradigm.
• Benefits of this combination
• A conventional distributed object-oriented system
  offers no direct support to the user for
  disseminating data from a single source to
  multiple destinations.
• A conventional publish-subscribe system does not
  provide the abstraction of objects with a set of
  methods in their interface.
• Interface to SDOs is a lot simpler and more
  usable than the combination of interfaces to
  their underlying technologies.

9
Clients and Proxies,Servers and Servants

• Remote Method Invocation

Client Process
Server Process
Proxy Object on Client
Servant Object on Server
Proxy for Object 27
Object 27
UserApplication
UserApplication
Remote Interface Publication State
Interface
Remote Interface
RemoteInterfaceImplementation
Publication State Cache Local Methods
Interface
Publication State Local Methods Interface
Local MethodsImplementation
Local MethodsImplementation
TENA Middleware
TENA Middleware
Network
10
Clients and Proxies,Servers and Servants

• Publication State Dissemination and Access

Client Process
Server Process
Proxy Object on Client
Servant Object on Server
Proxy for Object 27
Object 27
UserApplication
UserApplication
Remote Interface Publication State
Interface
Remote Interface
RemoteInterfaceImplementation
Publication State Cache Local Methods
Interface
Publication State Local Methods Interface
Local MethodsImplementation
Local MethodsImplementation
TENA Middleware
TENA Middleware
Network
11
Clients and Proxies,Servers and Servants

• Local Methods used on both Client and Server

Client Process
Server Process
Proxy Object on Client
Servant Object on Server
Proxy for Object 27
Object 27
UserApplication
UserApplication
Remote Interface Publication State
Interface
Remote Interface
RemoteInterfaceImplementation
Publication State Cache Local Methods
Interface
Publication State Local Methods Interface
Local MethodsImplementation
Local MethodsImplementation
TENA Middleware
TENA Middleware
Network
12
TENA Objects are Compiled In

• Why use compiled-in object definitions?
• Strong type-checking
• Dont wait until runtime to find errors that a
  compiler could detect.
• Performance
• Interpretation of methods/attributes has
  significant impact.
• Ability to easily handle complex object
  relationships
• Conforms to current best software engineering
  practices
• How do you support compiled-in object
  definitions?
• Use a formal language like CORBA IDL to define
  object interface and object state structure -
  TENA Definition Language (TDL)
• Use code generation to implement the required
  functionality
• In the future, users define their LROM
  graphically using UML tools Requires the use of
  UML Profiles with the XML Meta-Data Interchange
  (XMI) standard to tailor UML to the TENA
  meta-model
• A prototype UML ? XMI ? TDL conversion utility
  exists today

13
Purpose of the StandardTENA Object Model

• To enable semantic interoperability among range
  resource applications
• To provide the common language that all range
  resource applications use to communicate
• It will eventually encode almost all information
  communicated among range resource applications.
• Initial work is being done by the AMT to
  standardize
• Time-Space-Position Information (TSPI)
• GPS information
• Radar information

14
TENA MiddlewareUser Interaction Layers
User Code
Object Model (BasicImpl)
Object Model (API)
TENA Middleware (API)
ACE TAO (COTS)
System Hardware
Learn more about ACETAO at www.cs.wustl.edu/schm
idt/ or www.ociweb.com/but always get it from
the development team
15
DEVS/TENA System
16
DEVS/TENA System Overview
17
Structure of DEVS/TENA Application
18
The Functions which Each parts use

• TENA Cord
• Session
• Multi Servants (publish)
• - PublicationInfoPtr create the remote methods
  and local methods factories
• ServantFactoryPtr create a servantFactory in
  session
• ServantPtr publish all the states (update
  Servant)
• Multi Proxies (subscribe)
• CallbackInfoPtr keep a ProxyPtr to a discovered
  SDO
• SubscriptionInfoPtr create a holder for the
  FactoryHolderImpl and callback factory objects
• evokeMultipleCallbacks execute callbacks
  (subscribe published information)

19
The Functions which Each parts use(2)

• Multi Message senders
• FactoryHolderPtr create the factories that will
  define the behavior for all the sent messages
• MessageSenderPtr Create a MessageSender in the
  Session
• MessageSenderPtr-gtsend(Message) send a message
• Multi message receivers
• CallbackInfoPtr construct the message
  CallbackInfo object
• SubscriptionInfoPtr
• StdlistltLesson_07PickupFarePointergt

20
Message Passing with TENA message

• Each simulator has one message storage
• Any simulator can send a message to the other
  simulators according to coupling information
• We should make a TENA model according to the new
  model for making a message storage

21
Message Passing with RMI

• We insert a method for sending a message in the
  simulator
• Each simulator invokes a method for sending a
  message after an output method
• This method does not change the TENA models
  though using different DEVS models

22
DEVS message to TENA message and vice versa

• We do not need to change a TENA model to simulate
  the DEVS models.
• Value type in the message is object type in
  adevs, so some modification are needed to get
  information of the message for encoding to TENA
  Message.
• It is hard to implement TENA message if the DEVS
  message is complicated (e.g. hierarchical
  structure message)

23
TENA Model for distributed DEVS simulation
24
TDL File
class Simulator double timeNext string
doneM void initialize() double getTN()
void createOutput(in double minTN) void
sendMessage(in Msg output) void
executeDeltfunc() message OutMessages
Msg Mess

• package DEVS
• local class Msg
• string portName
• vector ltstringgt value
• class Coordinator
• double minTN
• string conSig
• void finishInit()
• void finishPassmsg()
• void finishDeltafunc()

25
Simulation protocol
26
DEMO
27
GPT Model
Generator Generating signals per 5
Processor Holding signals from the Generator
during 10
Transducer Analyzing signals from two models
during 200
28
Distributed models
29
Connecting TENA middleware
30
executionManager
31
Session Execution

• Session
• Instances of publish subscribe
• Execution
• The bridge among the applications

32
Starting the simulation
33
Simulation Result

• The Output of DEVS/TENA Distributed simulation

• The Output of DEVS simulation

34

• Questions