Cougaar Overview Dr. John Zinky February, 2009

1. Cougaar Overview Dr. John Zinky February, 2009

2. Multiple Roles Need to Understand Cougaar • Architect • What are Cougaar’s subsystems? • How can Cougaar be interface to existing subsystems? • Researcher • How does Cougaar push the State-of-the art? • Is Cougaar an agent system, adaptive middleware, a knowledge sharing system, or an aspect-oriented programming environment? • Developer • What Cougaar Design patterns and services are available? • How do I get Cougaar to work in my Eclipse IDE? • Installer • How do I configure a Cougaar Agent Society • Which feature should I add to the Environment to handle my situation? • Operator • How do I know if Cougaar Society is working? • How do I change a Cougaar Society dynamically? • Manager • How can Cougaar save development effort or time to market? • Who else is using Cougaar and for what purpose?

3. Outline Cougaar Agent Middleware Target Applications Agent Programming Environment Programming Deployment and Operations Tools Example Application Management Background

4. What Is Cougaar? • Cougaar is an open-source agent architecture. • Agents are autonomous software entities which communicate with other agents or external services to achieve domain-specific functionality. • Agent-based computing is a programming methodology which facilitates straightforward decomposition of complex tasks. • Cougaar includes the infrastructure and core services • Cougaar supports highly distributed, survivable applications

5. Cougaar Agent Reference Model Application domain specific Behavior Behavior BB BB Agent Agent Elastic Boundary coordinator coordinator sensor sensor effector effector Infrastructure Cyber Resource Physical service service service service service System specific component component component component component library library Abstracted Environment • Environment • Distributed • Services • Components • Imported libraries • Service oriented API • Agent/Env. API • sensor • effector • coordinator • active API Agents • Local • Behavior (plugin) • State (BB) • Pub/Sub Black Board (BB) API

6. Behavior Behavior Agent Coordination Agent BB BB MTS Node Process Node Process IP Host Host Separation of Application from Environment Agents handle Application Behavior Environment handles Systemic Adaptation Agents and Environment can be independently developed, tested, and configured, but run together Network

7. TRANSCOM 1BDE 2BDE Cougaar Agent Architecture Innovations Two levels of agent interactions • Intra-agent publish/subscribe blackboard for tightly-coupled interactions between an agents components (“plugins”) • Inter-agent message passing for scalable, loosely-coupled interactions Multiple Domain Knowledge Representation • Prototype/delegation data model • Capability-based representations • Frame-based knowledge representation Reusable Component framework • Components advertise and obtain local services from their peer components • Binders can block or modify service requests (for security or aspects) • All agent capabilities are pluggable components and services (message transport, naming, logging, etc)

8. Creating a Cougaar Agent Domain Specific Agent Generic Agent Business Rules & Processes + = Mission Planning PlugIn Allocator Expander Mission Assignment + = PlugIn Assessor Weather Status PlugIn A/C Availability PlugIn Agent Architecture Mission Behaviors Mission Management Agent

9. CENTCOM TRANSCOM Agents Construct Dynamic Communities of Interest: Logistics Domain Example Domain Specific Agent Allocator Expander Assessor Organization-Level (Community) TRANSCOM Air Scheduler Air Scheduler Route Planner Society Mode Selection Port Planner Army AMC Rail Planner Transportation Planning and Execution FSB FORSCOM Div MSC AF AMC Logistics Planning and Execution Wings

10. Outline Cougaar Agent Middleware Target Applications Agent Programming Environment Programming Deployment and Operations Tools Example Application Management Background

11. Successful Uses of Cougaar • Agent and Blackboard Programming Model • Large Logistics Application decomposed using agent and blackboard • Task/Allocation coordination abstractions built-in • Asset knowledge representation abstractions built-in • Distributed Application Overlays • Extensible infrastructure pluggable adaptation and survivability components • Flexible Layout of application functionality to distributed resources. • Embedding into Legacy Environment • Easy integration with libraries and other platforms • component-based middleware lighter weight than J2EE • Emulation -> Field • Create reference implementation of application • Test application under test bed stresses. • Field by enhancing the environment, not the application

12. Target Applications have Extreme Requirements Realtime distributed P2P applications with severe resource constraints and with Scalability, Survivability, Security (S3) requirements • Examples of Extreme Applications • Mission Management • Global network management and optimization • Information Assurance Control • Surveillance on UAV mobile sensor platforms • Proactive content distribution Management Plane Data Processing Plane

13. Properties of Extreme Applications • System Resource Constraints • (exhibited during runtime) • Distributedness of cyber resources: centralized vs. LANvs. WAN • Data plane speed: batch vs. online vs. realtime (superhuman) • Survivability (reliability & performance): non-crucial vs. exigent • Security adversary level: trust all vs. compartmentalized trust vs. malicious vs. insider threat • Scalability (hosts): 10s vs. 100s vs. 1000s vs. >10,000 • Application Functional Requirements • (addressed at programming/development phase) • Communication: client/server vs. P2P • Development cycle: waterfall vs. adaptive • Process during operational lifespan: fixed vs. evolving • Human participation level: none vs. sensor vs. model vs. cognitive • Cross-cyber resource load CPU vs. network vs. storage vs. all Web Service Cougaar • Business Environment • (Organizational constraints) • Market share: large vs. medium vs. small • Integration environment: standalone vs. stovepipe vs. new functionality w/ legacy system integration Data Base Grid Knowledge Rep Distributed Hash

14. Outline Cougaar Agent Middleware Target Applications Agent Programming Environment Programming Deployment and Operations Tools Example Application Management Background

15. Agent services • Cougaar Agent Abstraction includes many advanced, built-in services • A publish/subscribe blackboard for plugin communication within an agent and between agents • A Servlet engine for HTTP-based UIs • Knowledge Representation • Logistics Assets • FrameSets • OWL • Coordination between Agents via Blackboard • Task Allocation • Relay • Coordination Plugins

16. A Cougaar Agent runs on a Cougaar Node (Java Virtual Machine), which runs on a host. An agent is comprised of one or more Plugins, which define that agent's behavior. An agent with zero Plugins does nothing. Nodes, Agents, Plugins Host “localhost” Java Virtual Machine (JVM) JVM Node 1 Node 2 Agent A More agents Blackboard Plugin X Plugin Z Plugin Y Agent B Plugin Q Blackboard

17. In contrast to other, entirely message-based architectures, Cougaar’s blackboard-based plugins are primarily data-driven Plugins react to blackboard data add/change/remove notifications in a transactional “execute()” method All inter-plugin coordination is performed through these asynchronous data subscriptions As previously noted, the infrastructure translates certain blackboard data operations into inter-agent messages, but this is hidden from the plugin developer Blackboard add/change/remove notifications are batched by the infrastructure, which improves system performance, robustness, and scalability. Note that all state is saved on the blackboard, which is used to support persistence and crash recovery. Blackboard service Local Data Structures Agent Plugin Blackboard Plugin Plugin Plugin

18. Blackboard v.s. Messaging • Each agent has a private publish/subscribe “blackboard” shared memory for use by its local Plugins. • Plugins (should) only communicate with each other through their local blackboard. • Certain blackboard objects (e.g. Relays) are observed by the infrastructure and turned into inter-agent messages. • The messaging is transparent to the Plugins. • This is a Cougaar-specific “design pattern”. Node 1 Agent A Node 2 Plugin X Local Data Agent B Plugin Q Plugin Y Relay Data Relay Data Blackboard Blackboard Message Transport Message Transport Message

19. Servlet Service • In the example below, agent A has a Servlet/Plugin that will listen for browser requests to: • http://localhost:8800/$A/ping • This Servlet queries the blackboard and prints the data as HTML, for display in the browser. • As another example, it could return XML or Java Objects to a Swing UI. This is Cougaar’s preferred “UI” design pattern. • Plugins can also act as “Servlets”, which listen for remote URL connections • The “ServletService” is another built-in Cougaar service, analogous to the “BlackboardService” Node 1 Agent A Servlet “/ping” Data Blackboard Blackboard Tomcat Servlet Engine HTTP

20. Different Logistics Services Have DifferentPerspectives About Assets S/N: A2709 Model: MEP-208A Generator MILITARY SEALIFT COMMAND S/N: T789 Model: M978 Truck Equipment Transport Tasks S/N: A2709 Model: MEP-208A Generator PRIMEPWR- ENGCO POL- TRKCO S/N: T789 Model: M978 Truck Fuel Transport Tasks Maintenance Tasks S/N: A2709 Model: MEP-208A Generator MAINTCO S/N: T789 Model: M978 Truck

21. FrameSet Knowledge Representation Host Equip • Java Objects are code generated • Frames and relationships defined using XML • Support multiple Java interfaces • Cougaar Blackboard, • JESS Shadow Facts, • Java Beans • Applet viewer • Slot inference (Real-time) • Type (is-a) • Containment (has-a) • Visitor Pattern (composed-of) • Aggregation (summary-of) • Relationships are also Frames • Benefits from Frame inheritance • Meta-data tags • Defined at compile-time • Slots, frames, framesets • Example Slot meta-data • Type, default-value, units, path, doc, member, warn, immutable, notify-blackboard, notify-listeners, transient Process Appl Thing Object Class Type inheritance Containment inheritance Frame name value name value name value Relationship parent-name value child-name value

22. Requester Provider Expander Allocator 5 Blackboard Blackboard 1 T 4 3 T Task A Predictor 2 T Allocation A 9 6 A 8 7 Assessor 5. Local Subtask allocated 1. Task created 6. Remote Subtask transferred 2. Allocation predicted 7. Sub-allocations assessed 3. Task transferred 8. Allocation Result published 4. Task expanded 9. Allocation transferred Task Allocation Decomposition

23. Characteristics of Programming Models The programming model for interaction between components, should allow a range of flexibility vs efficiency tradeoffs

24. Outline Cougaar Agent Middleware Target Applications Agent Programming Environment Programming Deployment and Operations Tools Example Applications Management Background

25. Cougaar Core Services • Too many to cover: • Agent mobility between nodes (including across hosts) • Agent state persistence and crash recovery • Distributed, replicated naming service • Message Transport with multiple protocol support • Metric Service with gossip • Threading Service with CPU monitoring and control • Logging • Directory services (UDDI) • Agent communities and “ABA” group messaging • Embedding a Cougaar node in an Applet, Bean Container, etc • But they are all have a Component-based implementation

26. Generic SOA Life Cycle Client Component Server Component 4 • Initialize • Register services • Request Service • Invoke Service • Disconnect Invoke Service() 1 5 Service Instance 1 5 3 Service Factory 2 Get Service() Container Service Broker Get Service() Register Service() The interaction between client and server is regulated at key points in the life cycle.

27. Enhanced Service Service Component Service Proxy Client-side Service Proxy Server-side Client Component Service Instance Service Provider Service Broker Service Provider Service Broker Binder Binder Binder Service Broker Get Service() Register Service() Container Security binders wrap components to enforce behavior • Security concerns Cross-Cuts Functional Decomposition • Untrusted Domain code is implemented in components (SOA-style) • Binders regulate interactions between components

28. Work-flow between stations Component Component Component Component Aspect Delegates Aspect Object Aspect Object QoS State QoS State QoS Services QoS Services Aspects Cross-Cutting Functionality

29. Cougaar Message Transport has several unique features, such as cross-cutting protocols Message Transport Sender Forward S e n d L Dest Link Email Output Stream S e n d Q D e s t Q R o u t e SMTP Send Hold B B Route M M L P Outgoing Email Link Protocol MTS Provider Message Send History Aspect Round Trip Time Aspect Transport Adaptive Link Selection Policy Message Acking Aspect Agent Services Message Numbering Aspect ServiceBroker Agent Binder Node Service Broker Message Transport Receiver Deliver D e l i v r R e c v L Email Input Stream POP3 L P M M B B Receive Deliver Incoming Email Link Protocol MTS Provider Round Trip Time Aspect Agent Message Acking Aspect Services Message Ordering Aspect Agent Binder Service Broker Node Service Broker

30. Outline Cougaar Agent Middleware Target Applications Agent Programming Environment Programming Deployment and Operations Tools Example Application Management Background

31. Supporting Adaptation in the System Life Cycle Cougaar Middleware IDE Application Plugins Spec Tool Deploy Rules Society Monitor Run Server

32. <society> <node name=“Node1”> <agent name=“A”> <component class=“org.cougaar.demo.hello.HelloPlugin”/> </agent> </node> </society> Cougaar XML-based configuration • Cougaar agents are configured in XML society files, e.g.: • Java System Properties are defined in XML runtime files, e.g.: • The Cougaar node is typically started on the command line, e.g.: <runtime> <vm_parameter name=“-Dfoo” value=“bar”/> <vm_parameter value=“-Xmx500m”/> </runtime> • cougaar MySociety.xml MyRuntime.xml

33. Cougaar XML-based configuration (continued) • In addition to the node/agent/plugin XML files, Cougaar uses separate XSL “template” files to define the infrastructure components • All Cougaar infrastructure components are pluggable, such as: • The “StandardBlackboard” component, which advertises the per-agent BlackboardService • The “RootServletServiceComponent”, which advertises the ServletService • The Cougaar message transport, naming service, etc • Template variables can be used to turn on/off components that are listed in the XSL template file • These XSL files can be modified to add custom services or replace the standard Cougaar services implementations • For details, see the template documentation. • This componentization of the Cougaar infrastructure is a key strength – it makes it easy to tailor the Cougaar Node/Agent definitions to fit new environments!

34. Servlet-based Society Monitor

35. Outline Cougaar Agent Middleware Target Applications Agent Programming Environment Programming Deployment and Operations Tools Example Applications Management Background

36. Overlay Networks Status Collector Status Dissemination Status Displays • Same raw Instrumentation is used by multiple end-applications • Systemic properties can not be met by single society • Multiple societies customized to QoS-requirements and resource constraints Threshold Detector Alert Processor Archive Collectors Archive Storage Data Processing Assets Trend Analysis Capacity Planning Configuration History Configuration Assurance Configuration Specification Configuration Control

37. Mission Management as Cougaar Society Monitor Agent Cougaar Agents form a control society • A Shared Blackboard is used to decompose task, manage inventories, and monitor to execution of subordinates • High-level Ontologies and business rules represent domain knowledge • Adaptable Knowledge Sharing converts raw data to application knowledge within the constraints imposed by resources • Component Architecture allows easy insertion of domain knowledge and adaptive code Coordination Mission Planning Agents FCAPS Agents Blackboard Dissemination Agents Servlets Realtime System Model Monitoring Agents Control Agents Observation Inference Data processing assets

38. Mission Model: Sites toMission Mission Requirements Plane Requirements • Mission • Generic Task Graph • Utility vs Latency • Job-Flow • Route • Priority, deadline, CoS • Processing • Service time by task • In/out Rate, backlog • Equipment • Bandwidth • CPU • Storage • Geographic • Location • Distance Utility Vs Job Latency or Throughput Job-flow Plane Task Processing Processing Plane Data Storage Movement Transformation Resource Plane Resource Constraints Geographic Plane Constraints Sites

39. SASSI Optimizer Analysis Environment

40. C D D P P D D D P C D D D P C B B Plugins Implement Subsystems and GUI Menu Graph Viewer View Filter Table Viewer GIS Layer Viewers Experiment Control Window Manager Blackboard FrameSet Analysis Status Optimizer Status Input Frames ResultsFrames Jess Engine Optimizer Wrapper Scenario Loader SASSI Optimizer SASSI Optimizer SASSI Optimizer Layout.Rules Storm.Rules Scenario.XML Sept 30, 06 Implementation

41. Outline Cougaar Agent Middleware Target Applications Agent Programming Environment Programming Deployment and Operations Tools Example Applications Management Background

42. Open Source Cougaar Goals for Cougaar 12.6 • Consistent set of high maturity features • Restrict new features in favor of making old features more robust and understandable • Remove chaff and mark low maturity subsystems • Full-cycle Support for Couguaar roles • Developer, Installer, Operator, Architect • Example Applications • Update Documentation • Release 12.2 on Mar 13, 2007 • Release 12.4 on Sep 24, 2007 • Release 12.6 due Spring 2009 http://cougaar.org