Transcript Proposed DEVS Simulator Implementation Standard

AI and Computing in Countering Terrorism
INFORMS General Meeting
Oct 13. 2008
Modeling and Simulation Methodology: The
Challenge of Complex Endeavors
Bernard Zeigler
Arizona Center for Integrative
Modeling and Simulation,
University of Arizona,
Tucson, AZ
zeigler @ece.arizona.edu
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 microlevel/macro-level interactions.
•
Decision making and perception are heavily influenced by emotion and
culture
Layered Model of Mind (Marvin Minsky)
Values, Censors, Ideals, Taboos
Self-Conscious Reflection
Self-Reflective Thinking
Reflective Thinking
Deliberative Thinking
Learned Reactions
Learned Reactions
Innate, Instinctive, Urges, Drives
•
•
•
•
•
•
•
•
•
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.
Multiple, Concurrent
Ways to think
(Learning Processes)
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
Integration of components
•
•
•
•
•
•
participants remain autonomous and
independent
loosely coupled
interaction rules are soft coded
local data vocabularies persist
share information via mediation
•
•
•
•
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
reusability
composability
efficiency
NOT Polar Opposites!
* adapted from: J.T. Pollock, R. Hodgson, “Adaptive Information”, Wiley-Interscience, 2004
Linguistic Levels of Interoperability
pragmatic
semantic
syntactic
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 multinational 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
Fundamental Research in M&S (Cont’d)
Heterogeneous-Formalism Modeling
agents
NSF ERE Biocomplexity in the Environment program
 Knowledge Interchange Broker (KIB) provides its own
distinct formalism and realization
 Separately accounts for domain-neutral and domainspecific modeling
 Removes the need for composed models to have detailed
knowledge of each other
interactions
Discrete-event,
Models
landscape
Knowledge
Interchange
Broker
Discrete-time, Cellular
Automata Models
Design of Adaptive Service-based Software Systems
with Security and Multiple QoS Requirements
QoS Expectations
Adaptation
commands
QoS Adaptation
Simulation & QoS
measurements
NSF Science of Design Program
• 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
Produce
Events
SBS
Consume
Resources
Extrageneous
Events
Affect
QoS
QoS Monitoring
Resources
Measure changes of resource states
[Adaptable Service Based Software system]
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
Experimental Frame
Level Name
System Specification at this level
4
System built from component systems with coupling recipe.
3
2
Coupled
Systems
I/O System
Structure
I/O
Function
System with state and state transitions to generate the
behavior.
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
Simulation
Relation
Modeling
Relation
Model
message
DEVS/SOA Federation Support Infrastructure
Test Architecture
Mission Thread
DEVS Simulator
SOA
Service Discovery: UDDI
Sevice Description: WSDL
DEVS
Observer
Agent
Packaging:XML
Messaging:SOAP
Communication: HTTP
Service
Under
Test
DEVS Test
Federation
SOA
Live
Test
Player
SOAPXML
DEVS Simulator
Node
DEVS Modeling and Simulation Infrastructure supports
simultaneous testing at multiple levels
Mission Thread Test Agents
Control and Observe
collaborations
Pragmatic Level
Tests
Pragmatic Level agents inform
Semantic Level agents of the
objectives for health
monitoring
Semantic Level agents observe
message exchanges between
collaboration participants
DEVS acceptors alert higher
layer agents of network
conditions that invalidate test
results
Semantic Level
Tests
Semantic Level agents
activate probes at Syntactic
Level
network probes return
statistics and alarms to
DEVS transducers/
acceptors
Syntactic Level
Tests
DEVS Modeling Language (DEVML)
DEVS Simulator Services
Middleware (SOAP, RMI etc)
Net-centric infrastructure
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
DEVS
Simulator
DEVS
Protocol
DEVS
Model
• 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.
Concept of DEVS Standard
Single
DEVS
Simulation
Protocol
processor
Distributed
C++
Java
Simulator
DEVS
DEVS
Real-Time
Simulator
Virtual -Time
Simulator
DEVSML
Model
Core
Simulator
Interface
Interface
Non
DEVS
Other
Representation
Integrated Development and Testing Methodology
Define
Requirements
Capture
Requirements
Interpret
Structural
Aspects
Simulate
Generate
Atomic
DEVS
Models
Generate
System
Entity
Structure
Prune
Entity
Structure
(PES)
Transform PES
to hierarchical
DEVS Models
Interpret
Behavioral
Aspects
Implement
System
SimulationBased
Testing
Insert Models
into Test
Platform
Create Test
Models
DEVS/SOA Infrastructure: Supports Deployment and Execution of
DEVS Models on the Web
WEB
SERVICE
CLIENT
DEVS
Agent
(Observer)
DEVS
Agent
( Virtual User)
DEVSJAVA
DEVS Modeling Language (DEVML)
WEB
SERVICE
CLIENT
DEVS Simulator Services
Middleware (SOAP, RMI etc)
Net-centric infrastructure
•
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
Run Example
Requirements for Testing and Data Collection
Testing for
Organization and
Ontology quality
Content/Service
Content discovery
accuracy and
effectiveness
Catalogs/Registries
Verification/
Validation relative to
service
Search
Post
WSDL
find_xxx
save_xxx
(Bind)
Content/Service
XML
XML
Schema
Payload
Content/Service
Assessment of content
for pragmatic,
semantic, syntactic
correctness
Provider
Consumer
Client
SOAP
Access (& Use)
Simple Object Application Protocol
Service
Measurement of
timeliness of information
exchange
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
3. Intell Cell initiates high priority collection
against objective, and collectors post raw output
4. Intell posts products via Discovery and Storage
6. MAJ Smith pulls
estimate from Storage
NCES GIG/SOA
DEVS/SOA Infrastructure for GIG Mission Thread Testing
•
•
Test agents are DEVS models and
Experimental Frames
They are deployed to observe selected
participant via their service invokations
Observing Agent
for Major Smith
Observing Agent
for Intell Cell
1. MAJ Smith tasks Intell to
reconnoiter objective area and
provide threat estimate
Observing Agent
alerts other Agent
2. Posts taskings using
Discovery and Storage
3. Intell Cell initiates high priority collection
against objective, and collectors post raw output
4. Intell posts products via Discovery and Storage
notes time of posting
5. Intell Cell issues alert via messaging
6. MAJ Smith pulls
estimate from Storage
Computes Time for Task,
Measure Performance
NCES GIG/SOA
sends time to other Agent
Negotiation Modeling Approach
Domain-independent
behavior
FD-DEVS
Domain-dependent
structure
SES
message specializations
FD-DEVS
Market Place
~ phases
~ message types
Receive
message
Interpret
message
Send
message
Language of Encounter
Classification of the Negotiation’s Primitives
Abort
Initiators
Reactors
Completers
informative
Terminate
ContractQuery
Offer
Reject
Busy
NotMet
CapabilityQuery
CounterOffer
Accept
LinkEstablished
ItemRequest
Decline
BestProvidor
CapabilityStatement
ProvidorsChosen
DomainName
Item
ItemCheckResult
• Negotiation Scenario 1
Language of Encounter Structure
Books and Web Links
devsworld.org
acims.arizona.edu
Rtsync.com
Backup