1. DEVS-Centered Modeling and Simulation: Core Concepts for Engineering Education Bernard P. Zeigler Arizona Center for Integrative Modeling and Simulation University of Arizona, Tucson and RTSync Corporation 1 Presented to: Center for Sceince and Math Education University of Texas, Austin, April 2009.

2. 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

3. 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 4Coupled Systems System built from component systems with coupling recipe. 3I/O System Structure System with state and state transitions to generate the behavior. 2I/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. 1I/O Behavior Collection of input/output pairs constituting the allowed behavior of the system from an external Black Box view. 0I/O FrameInput and output variables and ports together with allowed values. Source System Simulator Model Experimental Frame Simulation Relation Modeling Relation message 3

4. Scuba Diver Example 4 LevelName 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 2I/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 1I/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 0I/O FrameInput and output variables and ports together with allowed values. Diver’s receivable signals (inputs) and generatable signals (output)

5. Atomic Models Ordinary Differential Equation Models Spiking Neuron Models Coupled Models Petri Net Models Cellular Automata n-Dim Cell Space Partial Differential Equations Self Organized Criticality Models Processing/ Queuing/ Coordinating Processing Networks Networks, Collaborations Physical Space can be components in a coupled model Multi Agent Systems Discrete Time/ StateChart Models Quantized Integrator Models Spiking Neuron Networks Stochastic Models Reactive Agent Models Fuzzy Logic Models Some Types of Models Represented in DEVS 5

6. 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

7. 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?

8. Interactive Tutorials – Define DEVS models within a restricted class 8 DevsTut orial http://www.cs.gsu.edu/DEVSTutorial/ Traffic Light Control System

9. DEVS Tracking – Selectable Visual Display in Real Time 9 http://acims1.eas.asu.edu/WebStarts/

10. Systems Problem Types 10 Systems ProblemDoes source of the data exist? What are we trying to learn about it? Which level transition is involved? systems analysisThe 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 designThe 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 diagnosisThe 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 inferenceThe 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

11. 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

12. 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?

13. 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

14. 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

15. Automating Test Frame Development 15 FDDEVS specification DEVSJAVA implementa- tion TEST Frame Specification DEVSJAVA implementa- tion TEST Frame Implementa- tion Legend: = automated

16. Automating Test Frame Feedback to a student experimenter DEVSJAVA implementa- tion TEST Frame Implementa- tion FDDEVS specification DEVSJAVA implementa- 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

17. 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

18. devsworld.org www.acims.arizona.eduRtsync.com Books and Web Links 18

19. More Demos and Links http://www.acims.arizona.edu/demos/demos.shtml http://www.acims.arizona.edu/demos/demos.shtml NTAC_DEMO (Marketplace_demo, MarketplaceObserver_demo)Marketplace_demoMarketplaceObserver_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