Bernard P. Zeigler Arizona Center for Integrative Modeling and Simulation

1. Interoperability, Automation, Built-in Evolution: the DEVS Framework for Coping with Emerging Complexity Bernard P. Zeigler Arizona Center for Integrative Modeling and Simulation University of Arizona, Tucson and RTSync Corporation

2. IT Systems Developmental Complexity? • IT Systems Developmental Complexity = degrees of developmental freedom × interdependence of design decisions × special requirements of environments • IT Complexity explosion • is driven by faster, cheaper computers, networking, web middleware, …, • Emergence: each stage enables the next stage with accelerating options for further growth • Wherever choices in platform, language,…, line of code, are possible, different developers will make different choices • Underlying structure/behavior dependencies force local decisions to have global impact breaking neat design patterns • Environments impose a plethora of special situations and an exponentially growing number of parameter combinations.

3. Consequences of complexity explosion: • Proliferation of incompatible variations on same themes • Ubiquitous heterogeneity • Vertical integration - “Stove piping” Response: Model-Driven Development Methodology • is increasingly being adopted for software-intensive system development • In this context, model is an abstract representation of software code, that • is technology independent • can survive technology changes • can be implemented in multiple code instantiations • enables reuse and automation

4. UML (Unified Modeling Language) • Is the most widely used framework to support model driven development • Promoted by Object Management Group as a standard within its Model Driven Architecture (MDA) • Supported by increasingly powerful commercial tools • Enhanced by SysML supporting requirements front end • Incorporated in architectural frameworks: DoDAF, MoDAF, …

5. Issues In Developmental Complexity of IT Systems • Often development does not start from scratch • Conditioned by idiosyncratic requirements • Powered, but unconstrained, by applicable standards • Requires legacy subsystem integration • Rigorous testing is needed to cope with complexity • Methodology must scale with growth and evolution of system • UML/MDA offers only limited support to address these concerns

6. Formulate the Issues within a Formal System of System Models (SoSM) Concept • SoSM = collection of disparate system models to be federated to satisfy new simulation requirements • Each participating system model may itself be large and complex • Participant models usually have become efficient at achieving their own specialized requirements • Participant models often adhere to idiosyncratic formalisms and development approaches • Distinguish between interoperation and integration to set appropriate objectives

7. Interoperation vs Integration* Interoperation of system components • participants remain autonomous and independent • loosely coupled • interaction rules are soft coded • local data vocabularies persist • share information via mediation Integration of system 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 reusability composability efficiency NOT Polar Opposites! * adapted from: J.T. Pollock, R. Hodgson, “Adaptive Information”, Wiley-Interscience, 2004

8. DEVS Framework • Discrete Event Systems Specification (DEVS) is the basis for a formal framework for modeling and simulation • DEVS contributes to scalability by: • Offering a standard for distributed simulation to support interoperability, composability, and reuse • Exploiting the separation between model, experimental frame and simulator • Fostering model continuity and progressive development • Automating and integrating complex systems implementation and testing • Emulating the biological brain for its "built-in" correlation of activity and behavior to drive efficient evolution via component re-us DEVS is not a technique, method or technology… But it can leverage technology to add implement its contributions … in particular Web Service Technology

9. Web Service Oriented Architecture Basis for M&S • Language and platform independent => separation of specification and implementation • Loosely coupled => message based, synchronous and asynchronous interactions. • Net-Centric => No centralized control, use of established protocols, security considerations. • Inter-operable => Standards based Observable => agents can inspect service requests/responses Services Registries Data Data Type Schema and Instances XML SOAP • Transport protocol • HTTP/HTTPS request/response • Data Encoding • SOAP (Simple Object Access Protocol), • XML Schema • Interface Description • WSDL (Web Services Description Language) • Service Description and Discovery • UDDI (Universal Description, Discovery and Integration) • Security • WS-Security, XML-Signature, XML-Encryption, ... Network Layers • Emerging infrastructure => Net-Centric Enterprise Services on the Global Information Grid Basis for Model Registration and Discovery => Meta-Data Registry Basis for Simulation => Web server and service development frameworks ( .Net, AXIS) Emerging advances => Mediation services, Semantic Web

10. Approach to Current Issues in SoSM • Adopt Web-enabled M&S Concepts for composing SoSM • Exploit SOA infrastructure for Model Repository and Component Reuse • Develop Formal Dynamic SoSM Distributed Simulation Standard • Build on this foundation to support Higher Levels of Interoperability • Develop automated and integrated development and testing methodology

11. SOA-enabled Model Repository Composability and Reuse * * adapted from: ZEIGLER, B. P. 1997. A framework for modeling & simulation. Applied Modeling & Simulation: An Integrated Approach to Development & Operation, McGraw-Hill, New York.

12. Success Story: DEVS-based Joint MEASURE – Model Repository Reuse* “… the Lockheed-Martin activities may well represent the state of the art in complex model composability …”, Improving the Composability of Department of Defense Models and Simulations, P.Davis and R.AndersonRAND, 2004 GPS III Use of infrared model in JCTS project Note presence of discrete and continuous dynamic model types *Advanced Simulation Center, Lockheed Martin Corp., Sunnyvale, CA

13. pragmatic pragmatic semantic semantic syntactic syntactic Linguistic Levels of Information Exchange and Interoperability System Participant System Participant

14. DEVS Standardization Supports Higher Level Web-Centric Interoperability DEVS Simulation Concept pragmatic DEVS Model semantic syntactic DEVS Model Specification DEVS Protocol DEVS Simulation Protocol Services Schemata Registry DEVS Simulator XML SOAP Network Layers • DEVS Protocol 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 • declaring how federates exchange information • executing an iterative cycle that • controls how time advances • determines when federates exchange messages • determines when federates do internal state updating • 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.

15. Web-enabled interoperability of DEVS components Supports re-use, composability, and interoperability • DEVS Message Class is defined in the formalism • Schemata for entity classes in Message are stored in namespace • DEVS Federates can register and discover schemata for information exchange DEVS Namespace aDEVS Federate Can be automated for JAVA using Dynamic Invocation DEVSSimulator Services In C++ DEVSJAVA client DEVSJAVA Federate DEVS Model .Net DEVS coordinator DEVSSimulator Services In JAVA Microsoft web server Proxies DEVS coupled Model DEVS Model DEVS Messages AXIS2 JRE Apache tomcat server SOAP messages IP Network

16. Biologically Inspired Assessment for Component Re-use Non-DEVS Federate Simulator Services DEVS Federate DEVS Coordinator DEVS Agent DEVS Agent web server collector Http Requests/ responses DEVSSimulator Services DEVS coordinator IP Network DEVS Model Mission Thread Evaluation DEVS coupled Model Component Credit Assignment Information for Future Component Re-use Web server JRE Activity Tracking Correlations of activity with Mission Thread Success Component benefit and resource cost in context

17. DEVS-Based Net-Centric Systems Test Agent Capability T&E Instrumentation sites Pragmatic Agents users Mission Thread clients Mission Effectiveness Semantic Agents Information Exchange servers Syntactic Agents System Performance workstations networks Middleware Network Monitoring 17

18. Summary  • Model-driven methodology employs technology-independent software abstractions, e.g., in UML, to support diverse implementation platforms and enable reuse and automation • Existing interoperability standards do not provide needed separation between models and simulations and do not effectively constrain object models • System of System Modeling (SoSM) concepts go beyond UML/MDA to address issues in interoperability, composability, and reuse • DEVS system theory –based framework operationalizes SoSM concepts and supports automated, rigorous testing in realistic GIG/SOA environments

19. Books and Web Links www.acims.arizona.edu Rtsync.com devsworld.org

20. More Demos and Links http://www.acims.arizona.edu/demos/demos.shtml • 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

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

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