DEVS-Centered Modeling and Simulation: Core Concepts for Engineering Education

Bernard P. Zeigler Arizona Center for Integrative Modeling and Simulation

University of Arizona, Tucsonand

RTSync Corporation

1

Presented to: Center for Sceince and Math EducationUniversity of Texas, Austin, April 2009.

Outline and Claims • Intro to Discrete Event Systems Specification (DEVS)• Why it is a good basis for generic, domain independent

education in modeling and simulation • How can we foster such generic abstraction-based concepts

while providing concrete tool-based experience?• Inherent hurdles can be overcome with appropriate concept

sequencing and user-friendly feedback tools• Can we learn from recent video game trends?• Recent DEVS-based environments provide some clues

2

Background: DEVS M&S Framework

Discrete Event Systems Specification (DEVS)• Based on mathematical formalism using

system theoretic principles• Separation of Model, Simulator and

Experimental Frame• Atomic and Coupled types• Hierarchical modular composition

Level Name System Specification at this level

4 Coupled Systems

System built from component systems with coupling recipe.

3 I/O System Structure

System with state and state transitions to generate the behavior.

2 I/O Function

Collection of input/output pairs constituting the allowed behavior partitioned according to initial state of the system. The collection of I/O functions is infinite in principle because typically, there are numerous states to start from and the inputs can be extended indefinitely.

1 I/O Behavior

Collection of input/output pairs constituting the allowed behavior of the system from an external Black Box view.

0 I/O Frame Input and output variables and ports together with allowed values.

Source System Simulator

Model

Experimental Frame

SimulationRelation

ModelingRelation

message

3

Scuba Diver Example

4

Level Name System Specification at this level

4 Coupled Systems

System built from component systems with coupling recipe.

System consisting of diver, diver’s air supply, dive boat, and water environment

3 I/O System Structure

System with state and state transitions to generate the behavior.

Diver’s decision algorithm to execute planned dive

2 I/O Function Collection of input/output pairs constituting the allowed behavior partitioned according to initial state of the system.

Diver’s planned dive trajectory – levels and time at each level starting on surface

1 I/O Behavior Collection of input/output pairs constituting the allowed behavior of the system from an external Black Box view.

Diver’s outputs under the surface over time in response to external inputs

0 I/O Frame Input and output variables and ports together with allowed values.

Diver’s receivable signals (inputs) and generatable signals (output)

Atomic Models

OrdinaryDifferential

EquationModels

Spiking NeuronModels

Coupled Models

Petri NetModels

Cellular Automata

n-Dim Cell Space

PartialDifferentialEquations

Self Organized CriticalityModels

Processing/Queuing/

Coordinating

ProcessingNetworks

Networks,Collaborations Physical

Space

can becomponents in a coupled model

MultiAgent

Systems

Discrete Time/

StateChartModels

QuantizedIntegrator

Models

Spiking Neuron

Networks

StochasticModels

ReactiveAgent

Models

Fuzzy LogicModels

Some Types of Models Represented in DEVS

5

Co-Model Development Methodology*

6

Recognizes Domain, M&S, and Computational Engineers

Collaborative Development

* Tag Gon Kim, “Co-modeling method for the development of domain-specific models”, DEVS Symposium, SpringSim, 2009

Sequencing the Introduction to DEVS with Finite DEVS

• Finite DEVS : Atomic models– Ports: input, output– States, including starting state– Functions: time advance, internal transition, external transition, output

• Behavior of Finite DEVS– Injecting inputs– Observing state transitions, outputs

• Compositions of Finite DEVS – Coupled models via automated port-matching coupling

• Behavior of Coupled Models: – Message exchange – State trajectory– Output trajectory

7

Can we develop student-friendly feedback tools that support progress from step to step?Can we develop student-friendly feedback tools that support progress from step to step?

Interactive Tutorials – Define DEVS models within a restricted class

8

DevsTutorialhttp://www.cs.gsu.edu/DEVSTutorial/

Traffic Light Control SystemTraffic Light Control System

DEVS Tracking – Selectable Visual Display in Real Time

9http://acims1.eas.asu.edu/WebStarts/

Systems Problem Types

10

Systems Problem Does source of the data exist? What are we trying to learn about it?

Which level transition is involved?

systems analysis The system being analyzed may exist or may be planned. In either case we are trying to understand its behavioral characteristics.

moving from higher to lower levels, e.g., using simulation to generate a model’s behavior

systems design The system being designed does not yet exist in the form that is being contemplated. We are trying to come up with a good design for it.

moving from lower to higher levels, e.g. having a means to generate observed data, synthesizing it with components taken off the shelf.

systems diagnosis The system exists but is not behaving correctly. We are trying to infer what is wrong by observations of its responses to selected inputs or structure changes

moving from errant behavior to the possible causes as departures from the correct structure

systems inference The system exists. We are trying to infer how it works from observations of its behavior.

moving from lower to higher levels, e.g., having data, finding a means to generate it

More radical approaches: Figuring out the Video Game

• Recent games are challenging players to figure out what the rules are, rather then developing the skill

• Serious games seek to teach traditional subjects• Can we learn from these trends to develop

educational technology?

11

• Different from – debugging in that the system was not of your making– diagnosing in that there are no prescribed inference patterns to follow

• Try something and see what happens – Continue experimenting until exhausted or convinced that you need some help

• Consult with others– Go to the knowledge base web site– Google to see if prior issue like this has been discussed

• Read the manual – as a last resort – it has too much that is irrelevant to immediate concern

12

Incidental Learning in trying to figure out how it works and why it is not working

The result is knowledge about the system that is not of the classical lecture or book study variety

Can we foster this kind of “learning by experimenting” in a more deliberate way?

But what kind of knowledge could this be?

• Surface knowledge– Rule-based/ condition/action– Procedural/ how to knowledge– case based reasoning – does not go far beyond the base, like knowing only a few routes though a

city– so can’t take alternative routes, can’t get outside familiar limits

• Deep knowledge– integrative – Understands global structures and relationships– can go beyond the base, like having put together a conceptual map of a city,– so can take detours, navigate in general directions

13

Fostering “learning by experimenting” or “active learning”

• Objective: foster acquisition of deep knowledge about systems and models

• Use the conceptual framework of systems concepts and M&S• Provide computer environment and software tool set that

– illustrates abstract concepts in concrete terms– make it easy to experiment– provide rich visualization– provide extensive feedback

• Encourage experimentation through incentive structures that reward learning from mistakes (without overly encouraging mistakes)

14

Automating Test Frame Development

15

FDDEVSspecification

DEVSJAVAimplementa-

tion

TESTFrame

Specification

DEVSJAVAimplementa-

tion

TESTFrame

Implementa-tion

Legend:

= automated

Automating Test Frame Feedback to a student experimenter

DEVSJAVAimplementa-

tion

TESTFrame

Implementa-tion

FDDEVSspecification

DEVSJAVAimplementa-

tion

30

Student can edit the original

The test frame remains the same

The test frame reports differences in the behavior resulting from student's edits

Text is displayed in progressive order with state related lines grouped together for easier understanding

FDDEVS

Summary • DEVS-based instruction provides a generic, domain

independent approach to education in modeling and simulation

• The inherent hurdles can be overcome with appropriate concept sequencing and user-friendly feedback tools

• The major benefits include:– ability to understand systems and develop transdisciplinary models– provide M&S support for Systems (and systems of systems) engineering

approaches– openness to creative approaches to highly complex problems

• Can we foster video game “learning by experimenting” in a more deliberate way?

17

devsworld.org www.acims.arizona.edu Rtsync.com

Books and Web Links

18

More Demos and Links http://www.acims.arizona.edu/demos/demos.shtml

• NTAC_DEMO (Marketplace_demo, MarketplaceObserver_demo)• Integrated Development and Testing Methodology: • AutoDEVS (ppt) & DEMO

– Natural language-based Automated DEVS model generation – BPMN/BPEL-based Automated DEVS model generation

– Net-centric SOA Execution of DEVS models

– DEVS Unified Process for Integrated Development and Testing of SOA

• Intrusion Detection System on DEVS/SOA

19