DEVS Simulation Engines as Software Components

1
DEVS Simulation Engines as Software Components

• Jim Nutaro
• Arizona Center for Integrative Modeling and
  Simulation
• Email nutaro_at_ece.arizona.edu

2
Focus

• The focus of the proposed standard is to make
  simulation engines into interchangeable software
  components
• Simulation engines should usable as components
  within a larger software system (e.g., to provide
  a prediction capability to a decision making
  system)
• Similar (DEVS) simulation engines can be made to
  interoperate in the context of a larger
  simulation
• Emphasize interoperability and reuse of
  simulation engines, and not models themselves

3
Why this focus?

• Discrete event models are software intensive
• Extensive use of modern software development
  methods (inheritance, complex data structures,
  etc)
• Compels developers to use modern, general purpose
  languages for building DEVS simulations (why is
  there no DEVS-MATLAB? DEVS-FORTRAN?)
• Different languages suitable for different
  purposes
• Will be hard to standardize a model description
  language

4
What has worked?

• Standardized APIs have help to create widely
  reused software components
• Standardized thread APIs
• OpenGL
• Promotes use of advanced technology (e.g.,
  sophisticated computer graphics) as components in
  large software systems

5
Requires a new viewpoint

• Traditional view of a simulation framework
• The software being developed is primarily
  concerned with MS
• The simulation framework defines the software
  architecture
• All models will be constructed in the same
  framework

• Component oriented view
• MS is one functional aspect of a larger software
  system
• The simulation framework must fit into an
  existing architecture
• Some of the model will be constructed in the
  framework

6
Simulation in a larger context
Software system
Software system
Networking
Planning
Real-time scheduling
Multimedia
Target system for most simulation packages.
Simulation framework is dominant, other features
fit into or around it.
Simulations frameworks designed for use in a
larger context are relatively rare.
7
Basic approach

• Simulation engines are represented by a single
  object
• The simulation engine object interface has
  methods for
• Obtaining outputs
• Injecting inputs
• Obtaining the time of next event
• Computing the next state
• Methods are applied to the top of a
  hierarchical model

8
Next event time
Compute next state
Get output
Inject input
9
Example DEVSJAVA
Interface exported by the DEVSJAVA simulator
classes
10
Example ADEVS
Interface exported by the adevs xdevsim class
11
What to standardize?

• Standardize the simulation engine API
• Similar to other API standards (pthreads, OpenGL,
  MPI, OpenMP, etc.)

12
What are the benefits?

• Allows software system designers to include
  simulation components in their high level designs
• Selection of a simulator implementation can be
  done later, in the implementation phase
• Selection can match the modeling problem, and not
  be driven by integration requirements (e.g., as
  imposed by high level software architecture)
• Standardized API helps to minimize integration
  risks

13
Applications

• General purpose middleware tools (e.g., a generic
  HLA hook for DEVS simulation engines)
• Code reuse (e.g., can wrap a model implemented in
  one DEVS simulator as an atomic component in
  another simulator)

14
Applications

• Using DEVS simulation engines in otherwise DEVS
  unaware software
• In multimedia focused computer games (e.g., using
  DEVS to build a physics engine or character
  model)
• Performance models in planning or optimization
  tools or other AI applications

15
Conclusions

• A standard approach to packaging DEVS simulation
  engines as software components could promote the
  use of DEVS in large software projects
• Allows DEVS advocates to promote DEVS for
  simulation specific aspects of a software system
  while allowing software architects to think only
  of a simulation capability