Modeling and Simulation Methodology: The Challenge of Complex Endeavors Bernard Zeigler Arizona Center for Integrative Modeling and Simulation, University of Arizona, Tucson, AZ AI and Computing in Countering Terrorism INFORMS General Meeting Oct

Outline What are Complex Endeavors? We need adequate models of – humans – human-human interactions What such models might be based on Complex Endeavors as Systems of Systems M&S Environment to Support SoS Levels of Interoperability SOA-based Integration and Testing of SoS

Marvin Minsky, The Emotion Machine: Commonsense Thinking, Artificial Intelligence, and the Future of the Human Mind, Simon Schuster Richard E. (Dick) Hayes, Complex Endeavors as Challenges to the Modeling and Simulation Community, Military Modeling and Simulation Conference, Singapore Suiping Zhou, Human Behavior Modeling and Simulation For Military Operations, Military Modeling and Simulation Conference, Singapore

Complex Endeavors (Richard Hayes) Formed when a large number of disparate entities form an association for a limited time to achieve a shared objective No single leader or commander – Neither unity of purpose nor unity of command – Composed of independent entities Different traditions, cultures, goals, priorities, and processes Interdependence – No single actor is capable of achieving its relevant goals independently – Actors bring different expertise and resources to the endeavor Increasing need for international peace operations information technology enables collaboration multinational, interagency, governmental, non-governmental organizations, private industry, and local authorities

Complex Endeavors are characterized by Human-Human Interactions Perceptions of actors about others o trust o competence o cross-cultural biases Interoperability: share o information and knowledge o awareness (situation characterization) o understanding (cause and effect, temporal dynamics) Collaboration about purposes, decisions, planning, and execution o coalitions without common doctrine o involving a variety of actors (e.g. Tsunami, Katrina relief) r

Limitations of Current Models and Reuse Models Classic Rule Based and Algorithmic Models -- ignore soft factors Human in the Loop Models —generalization limited to the types of people who participate Simulation Models – Systems Dynamics, Agent-Based, etc., difficult for a policy or decision maker to comprehend, must have faith in black box Problems in Reuse: must know the original purposes and assumptions (Experimental frame) models operate at different levels of abstraction – they cannot communicate with each other built in biases of developers, new forms e.g., cultural biases

Behavior Modeling Principles (Suiping Zhou) Humans are social animals. The social aspect and the animal aspect of a human being are inhibitory to each other. Behavior is largely determined by experiences rather than by complex decision rules. Behavior is greatly affected by social context, family, friends, colleagues, etc Human’s decision-making process consists of multiple layers of micro- level/macro-level interactions. Decision making and perception are heavily influenced by emotion and culture

Layered Model of Mind (Marvin Minsky) Self-Conscious Reflection Self-Reflective Thinking Reflective Thinking Deliberative Thinking Learned Reactions Values, Censors, Ideals, Taboos Innate, Instinctive, Urges, Drives Multiple, Concurrent Ways to think (Learning Processes) We are born with many mental resources. We learn more from interacting with others. Emotions are different Ways to Think. We learn to think about our recent thoughts. We learn to think on multiple levels. We accumulate huge stores of commonsense knowledge. We switch among different Ways to Think. We find multiple ways to represent things. We build multiple models of ourselves.

Federations of Models No single model or approach to modeling will be adequate to meet the needs for validity, reliability, and scalability. Federations of models will be needed for different: – Levels of Analysis – Functions (Communications, Logistics, Decision Making, etc.) Models in Federations should: – Be developed and tested together – Be modular and inform one another Be based on compatible underlying assumptions and parameters Be transparent

Interoperation vs Integration* Interoperation of components participants remain autonomous and independent loosely coupled interaction rules are soft coded local data vocabularies persist share information via mediation Integration of components participants are assimilated into whole, losing autonomy and independence tightly coupled interaction rules are hard coded global data vocabulary adopted share information conforming to strict standards * adapted from: J.T. Pollock, R. Hodgson, “Adaptive Information”, Wiley-Interscience, 2004 NOT Polar Opposites! reusability composability efficiency

Linguistic Levels of Interoperability Linguistic Level Interoperability Demonstrated if: Example Pragmatic – How information in message is used The receiver reacts to the message in a manner that the sender intends A commander’s order is obeyed by the troops in the field as the commander intended. (This assumes semantic interoperability.) Semantic – Shared understanding of meaning of messages The receiver assigns the same meaning as the sender did to the message. An order from a commander to multi- national participants in a coalition operation is understood in the same manner despite translation into different languages. Syntactic – Common rules governing composition and transmitting of messages The consumer is able to receive and parse the sender’s message A common network protocol (e.g., IPv4) ensures that all nodes on the network can send and receive data bit arrays while adhering to a prescribed format.

Fundamental Research in M&S Discrete Event System Specification (DEVS ) Provides sound M&S framework Derived from Mathematical dynamical system theory Supports hierarchical, modular composition System Entity Structure: ontology framework for M&S Distributed simulation, web-based, SOA-based Linguistic levels of interoperability (syntactic, semantic, pragmatic) M&S Simulation interoperability standards

Heterogeneous-Formalism Modeling agents Discrete-event, Models landscape Discrete-time, Cellular Automata Models Knowledge Interchange Broker interactions  Knowledge Interchange Broker (KIB) provides its own distinct formalism and realization  Separately accounts for domain-neutral and domain- specific modeling  Removes the need for composed models to have detailed knowledge of each other NSF ERE Biocomplexity in the Environment program NSF Science of Design Program Design of Adaptive Service-based Software Systems with Security and Multiple QoS Requirements Develop a SOA-based DEVS simulator to aid design and evaluation of flexible and configurable SOA-based software systems support design of SOA systems able to adapt to changing tradeoffs among timeliness, throughput, accuracy, and security Fundamental Research in M&S (Cont’d)

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 LevelName 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

DEVS Test Federation DEVS/SOA Federation Support Infrastructure SOA Live Test Player Service Under Test DEVS Simulator Node SOAP- XML DEVS Observer Agent Service Discovery: UDDI DEVS Simulator Test Architecture Sevice Description: WSDL Packaging:XML Messaging:SOAP Communication: HTTP SOA Mission Thread

DEVS Modeling and Simulation Infrastructure supports simultaneous testing at multiple levels Syntactic Level Tests Semantic Level Tests Pragmatic Level Tests network probes return statistics and alarms to DEVS transducers/ acceptors Mission Thread Test Agents Control and Observe collaborations Semantic Level agents activate probes at Syntactic Level DEVS acceptors alert higher layer agents of network conditions that invalidate test results Pragmatic Level agents inform Semantic Level agents of the objectives for health monitoring Semantic Level agents observe message exchanges between collaboration participants Middleware (SOAP, RMI etc) - Net-centric infrastructure DEVS Simulator Services DEVS Modeling Language (DEVML)

DEVS Simulation Concept Specifies the abstract simulation engine that correctly simulates DEVS atomic and coupled models Gives rise to a general protocol that has specific mechanisms for: declaring who takes part in the simulation: o format for referencing federates (participants) declaring how federates exchange information: o format for their message exchange patterns executing an iterative cycle that controls how time advances: o updating the clock based on next event times determines when federates exchange messages: o the point in the cycle when all interchange takes place determines when federates do internal state updating o the point in the cycle when next event times are collected Note: If the federates are DEVS compliant then the simulation is provably correct in the sense that the DEVS closure under coupling theorem guarantees a well-defined resulting structure and behavior. DEVS Simulator DEVS Model DEVS Protocol

Concept of DEVS Standard DEVS Core Simulator Interface Single processor Distributed Simulator Real-Time Simulator C++ Non DEVS Model Interface Java Other Representation DEVS Simulation Protocol Virtual-Time Simulator DEVSML

Integrated Development and Testing Methodology Define Requirements Interpret Structural Aspects Interpret Structural Aspects Capture Requirements Generate Atomic DEVS Models Generate Atomic DEVS Models Generate System Entity Structure Prune Entity Structure (PES) Prune Entity Structure (PES) Transform PES to hierarchical DEVS Models Transform PES to hierarchical DEVS Models Create Test Models Insert Models into Test Platform Insert Models into Test Platform Simulate Interpret Behavioral Aspects Interpret Behavioral Aspects Implement System Implement System Simulation- Based Testing Simulation- Based Testing

DEVS/SOA Infrastructure: Supports Deployment and Execution of DEVS Models on the Web WEB SERVICE CLIENT Middleware (SOAP, RMI etc) Net-centric infrastructure DEVS Simulator Services DEVS Modeling Language (DEVML) DEVSJAVA DEVS Agent ( Virtual User) DEVS Agent (Observer) WEB SERVICE CLIENT Run ExampleExample Service Oriented Architecture (SOA) consists of various W3C standards Client server framework XML Message encapsulated in SOAP wrapper Machine-to-machine interoperability over the network based on WSDL interface descriptions

Search find_xxx Post save_xxx Content/Service Catalogs/Registries Content/Service Consumer Content/Service Provider ServiceSOAP XML Schema WSDL Client Access (& Use) (Bind) XML Payload Simple Object Application Protocol Verification/ Validation relative to service Testing for Organization and Ontology quality Assessment of content for pragmatic, semantic, syntactic correctness Measurement of timeliness of information exchange Content discovery accuracy and effectiveness Requirements for Testing and Data Collection

DEVS/SOA Infrastructure for GIG Mission Thread Testing 1.MAJ Smith tasks Intell to reconnoiter objective area and provide threat estimate 2. Posts taskings using Discovery and Storage 6.MAJ Smith pulls estimate from Storage 3. Intell Cell initiates high priority collection against objective, and collectors post raw output 4. Intell posts products via Discovery and Storage NCES GIG/SOA

DEVS/SOA Infrastructure for GIG Mission Thread Testing 1.MAJ Smith tasks Intell to reconnoiter objective area and provide threat estimate 2. Posts taskings using Discovery and Storage 5. Intell Cell issues alert via messaging 6.MAJ Smith pulls estimate from Storage 3. Intell Cell initiates high priority collection against objective, and collectors post raw output 4. Intell posts products via Discovery and Storage Observing Agent for Major Smith Observing Agent for Intell Cell NCES GIG/SOA Test agents are DEVS models and Experimental Frames They are deployed to observe selected participant via their service invokations notes time of posting Observing Agent alerts other Agent Computes Time for Task, Measure Performance sends time to other Agent

Negotiation Modeling Approach Domain-dependent structure Domain-independent behavior FD-DEVS SES ~ phases ~ message types message specializations FD-DEVS Market Place Receive message Interpret message Send message

Language of Encounter Classification of the Negotiation’s Primitives AbortInitiatorsReactorsCompletersinformative Terminate ContractQuery OfferRejectBusy NotMet CapabilityQuery CounterOfferAcceptLinkEstablished ItemRequestDeclineBestProvidor CapabilityStatement ProvidorsChosen DomainName Item ItemCheckResult

Negotiation Scenario 1 Language of Encounter Structure

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

Backup