SAL SAL Architectures, Command Centers, and Adversaries: Design and Modeling Alexander H. Levis alevis@gmu.edu 1 System Architectures Laboratory 5/22/2006 Outline SAL • The Systems Architecture Lab – Mission – Approach – Research Projects • Research Areas – Architectures – Command Centers – Adversarial Modeling and Effects Based Operations • Conclusion System Architectures Laboratory 2 5/22/2006 5/22/2006 1 A. H. Levis
Mission SAL • The System Architectures Laboratory conducts basic and applied research in the modeling, analysis, design, and evaluation of – System Architectures – Organizational Architectures (coalition, adversarial) – Effects-based Operations – Information Operations • In all cases, the emphasis is on Command and Control applications. System Architectures Laboratory 3 5/22/2006 SAL Approach • The research focus is on temporal aspects and dynamics: – Adaptive Organizations / Command Centers – Executable models of C4ISR Architectures – Timed Influence nets and Dynamic Influence nets – Planning and Execution Monitoring – Dynamic Assessment • We use discrete event system theory in general and Colored Petri nets in particular to develop algorithms and then embed the algorithms in tools • We are taking a systems engineering approach; one of the objectives is to understand systems of systems • We are building a test bed that contains tools, data, and models and is accessible remotely by collaborating institutions System Architectures Laboratory 4 5/22/2006 5/22/2006 2 A. H. Levis
SAL Current Research Projects • ONR: Adaptive Organization Design for Effects Based Operations • AFOSR: Interactive Planning for Capability Driven Air and Space Operations • AFOSR: Computational Modeling of Adversary Attitudes and Behaviors (with Carnegie Mellon) • AFOSR: Human Centric Design Environments for C2 (with Berkeley and Vanderbilt) • AFRL/IF: Dynamic Air and Space Effects Assessment (Critical Experiment) (DASEA) • Raytheon: Timed Influence Nets support System Architectures Laboratory 5 5/22/2006 Architecting… SAL DoD Arch. The Complete Framework Process M DoD AF I Operational Product Concept S Architecture Generation S Design I O Executable Architecture N Model Analysis and Construction Evaluation • Alternative approaches and tools can be used to design the Architecture views – Structured Analysis or Object Orientation • The executable model is used for logical, behavior and performance evaluation • The main challenge is the development of measures and procedures for the evaluation of architectures System Architectures Laboratory 6 5/22/2006 5/22/2006 3 A. H. Levis
On Architectures SAL • Current research on Architectures is focused on the development of executable models that represent an architecture. – Both structured analysis and object oriented approaches are used. – The resulting discrete event dynamical system models are expressed as Colored Petri Nets. – Analytical, algorithmic, and simulation tools are used to analyze the behavior of the modeled architecture . and to evaluate performance. � While there are methodologies, tools, and techniques for the design of architectures for individual system, there is very little theory and virtually no tools for the design of Systems of Systems � Systems of Systems are currently assembled together in an ad hoc manner; they are not designed. System Architectures Laboratory 7 5/22/2006 Evolution of Systems SAL Engineering SoS SE and Enterprise SE focus for R&D Complexity • Since WW II, systems engineering has continued to evolve addressing increasingly complex systems • Since the mid 50s we have been focusing on increasingly large integrated systems • The challenge is now to address loosely coupled Systems of Systems System Architectures Laboratory 8 5/22/2006 5/22/2006 4 A. H. Levis
SoS Examples SAL • Air Traffic Control (NGATS) Multiple Carriers FAA Multiple Airport Authorities • Allied and Coalition Operations System Architectures Laboratory 9 5/22/2006 System of Systems* SAL � A system will be called a System of Systems (SoS) when: – The component systems achieve well-substantiated purposes in their own right even if detached from the overall system; – The components systems are managed in large part for their own purposes rather than the purposes of the whole; – It exhibits behavior, including emergent behavior, not achievable by the component systems acting independently – Component systems, functions, and behaviors may be added or removed during its use * Definition evolved from Sage, Maier, Levis, … System Architectures Laboratory 10 5/22/2006 5/22/2006 5 A. H. Levis
SAL A Key Challenge • In the Systems of Systems, many humans are inside the SoS • But our methodology and procedures really consider the human as being outside; we design “interfaces” • We do the Task Allocation too early along traditional lines • The Task Allocation problem requires some new thought and algorithms; adaptation requires the ability to change dynamically the allocation (morphing) Systems Engineering Man-Machine Humans Human-Computer Hardware Software Integration System Architectures Laboratory 11 5/22/2006 SAL Degree of Integration IMINT IMINT SIGINT SIGINT Air Air Intel Intel Intel Defense Defense Defense Defense Suppression Suppression Interoperating Other Other Other HUMINT HUMINT Domains Domains Domains System of Systems (systems enter and leave) SOF SOF Mobility Mobility Combat Combat Ops Ops IMINT IMINT SIGINT SIGINT Air Air Defense Intel Intel Intel Defense Defense Defense Suppression Suppression Other Other Other HUMINT HUMINT Current Stovepipes Domains Domains Domains Netw ork/Information Sharing Infrastructure Netw ork/Information Sharing Infrastructure Combat Combat Combat Mobility Mobility Mobility Ops Ops Ops SOF Degree of Coupling Fully Loosely Uncoupled Tightly Coupled Integrated Coupled (Monolithic) Integration covers the spectrum from tight integration into a single large scale system to interoperation in a loosely coupled system of systems System Architectures Laboratory 12 5/22/2006 5/22/2006 6 A. H. Levis
Traditional Systems Engineering SAL Approach The SE Design Problem: Map Operational Activities to Systems Functions Activity 3 Activity 4 Operational Activity 5 Activity 6 Activity 8 Activity 9 Activity 1 Activity 2 Activities Activity 7 Function t Function w System Functions Function r Function S Function v Function x Function z Function y Function u System d System d System b System h Systems System f System c System a System g System e � In a systems-centric viewpoint, functions are tightly coupled to systems System Architectures Laboratory 13 5/22/2006 Service Oriented Architecture SAL (SOA) • In a service-oriented viewpoint, activities drive services and services drive systems – effectively decoupling operational activities from systems Activity 3 Activity 4 Operational Activity 6 Activity 9 Activity 1 Activity 2 Activity 5 Activity 8 Activities Activity 7 Service K Service F Service L Service B Enterprise Service O Loosely Service D Service E Service I Service J Service M Services Service A Service N Coupled Service C Service G Service H Function t Function w Functions Function x Function r Function S Function v Function z Function y Function u System d System b System h Systems System f System c System a This is counter to System g System e traditional systems engineering System Architectures Laboratory 14 5/22/2006 5/22/2006 7 A. H. Levis
A Layered Architecture SAL for Virtual Integration • To achieve loose integration, a layered SOA architecture is needed that includes the nine Net Centric Enterprise Services Mission 1 Mission 2 9 Net-Centric Mission Enterprise Services Application COIs IA/Security Services Domains Discovery Services Messaging Infrastructure Collaboration Storage Mediation User Assistant Enterprise Systems Management System Architectures Laboratory 15 5/22/2006 SAL Command Centers and EBO • This research effort focuses on several problems: – Adaptive architecture for coalition command center organization – Integration of conventional and information operations – Course of Action development and evaluation tools – Dynamic Assessment of effects – Modeling an adversary’s attitudes and behaviors • An organization may need to adapt because: – The task load (adversary action) has changed – The mission has changed – The resources available have changed • A key example is the Navy’s Expeditionary Strike Group • Development of courses of action that integrate all elements of national power (DIME; PMEESI) requires models that describe an adversary’s attitudes and behaviors System Architectures Laboratory 16 5/22/2006 5/22/2006 8 A. H. Levis
Recommend
More recommend
