cougaar overview john zinky 1 cougaar overview dr. john zinky february, 2009

Cougaar Overview John Zinky 1

Cougaar OverviewDr. John Zinky

February, 2009


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?


1. Cougaar Agent Middleware

2. Target Applications

3. Agent Programming

4. Environment Programming

5. Deployment and Operations Tools

6. Example Application

7. Management Background

Outline


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


Cougaar Agent Reference Model

componentcomponent

service

BBBB

BehaviorBehavior

effectoreffector coordinator

coordinatorsensorsensor

componentcomponent

service service

componentcomponent

librarylibrary

Agent

BBBB

BehaviorBehavior

effectoreffector

coordinator

coordinator sensorsensor

componentcomponent componentcomponent

serviceservice

librarylibrary

Agent

Abstracted Environment

• Local

• Behavior (plugin)• State (BB)

• Pub/Sub BlackBoard (BB) API

Environment • Distributed• Services• Components• Imported libraries

• Service oriented API

Agent/Env. API

• sensor• effector• coordinator

• active API

Agents

Applicationdomainspecific

Systemspecific

InfrastructureCyber ResourcePhysical

ElasticBoundary


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

Host HostIP

Node Process Node ProcessMTS

Agent AgentCoordinationBB

Behavior

BB

Behavior

Network


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)

PLATFORM OS

JAVA VMJAVA VM

COUGAAR NODE

Agent Binder

Agent Binder

PLATFORM SERVICES

COUGAAR NODE SERVICES

Agent Binder

AGENT.AGENTFRAMEWORKSVCS.

PluginBinder

PluginBinder

PluginBinder

PluginBinder

PlugInPlugIn

COUGAAR NODE

Agent Binder

COUGAAR NODE SERVICES

Agent BinderAgent Binder


PluginBinder

PluginBinder

PluginBinder

PluginBinder

Agent Binder


PluginBinder

PluginBinder

PluginBinder

PluginBinder

PlugInPlugIn

PlugInPlugIn

PlugIn

PlugIn

TRANSCOM

1BDE

2BDE


Creating a Cougaar Agent

Domain Specific AgentGeneric AgentBusiness Rules &

Processes

PlugIn

PlugIn

PlugIn

PlugIn

+Allocator

Assessor

Expander

=Weather Status

A/C Availability

Mission Assignment

Mission Planning

Mission Management Agent

+ =

Mission BehaviorsAgent Architecture


Agents Construct Dynamic Communities of Interest: Logistics Domain Example

Organization-Level (Community)

Allocator

Assessor

Expander

Air Scheduler

CENTCOM

TRANSCOM

FORSCOM

AF AMCMSC

Army AMC

Wings

Div

FSB

Domain Specific Agent

Air Scheduler

Route Planner

Rail Planner

Port Planner

Mode Selection

TRANSCOM

Transportation Planning and Execution

Logistics Planning and Execution

Society









Outline


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


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

ManagementPlane

ManagementPlane

Data Processing Plane


Properties of Extreme Applications

Application Functional Requirements

(addressed at programming/development phase) 1. Communication:

client/server vs. P2P2. Development cycle:

waterfall vs. adaptive3. Process during operational lifespan:

fixed vs. evolving• Human participation level:

none vs. sensor vs. model vs. cognitive1. Cross-cyber resource load

CPU vs. network vs. storage vs. all

System Resource Constraints

(exhibited during runtime) 1. Distributedness of cyber resources:

centralized vs. LAN vs. WAN2. Data plane speed:

batch vs. online vs. realtime (superhuman)• Survivability (reliability & performance):

non-crucial vs. exigent1. Security adversary level:

trust all vs. compartmentalized trust vs. malicious vs. insider threat

2. Scalability (hosts): 10s vs. 100s vs. 1000s vs. >10,000

Business Environment(Organizational constraints)

1. Market share: large vs. medium vs. small

2. Integration environment:standalone vs. stovepipe vs.

new functionality w/ legacy system integration

Web Service

GridData Base

Knowledge Rep DistributedHash

Cougaar









Outline


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


Java Virtual Machine (JVM)

Host “localhost”

JVM

Nodes, Agents, Plugins

• 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.

Agent A

PluginX

Node 1

PluginY

PluginZ

Node 2

More agents

Blackboard

Agent BPlugin

Q Blackboard


Blackboard service

• 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.

Agent

Plugin

Plugin Plugin

Blackboard Plugin

LocalData

Structures


Blackboard v.s. Messaging

Message Transport

Agent A

Blackboard

PluginY

Node 1

Relay Data

Message Transport

Agent B

Blackboard

Node 2

Relay Data

Message

PluginQ

PluginX Local Data

• 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”.


Servlet Service

Blackboard

Tomcat Servlet Engine

Agent A

Blackboard

Node 1

Servlet“/ping”

• Plugins can also act as “Servlets”, which listen for remote URL connections

• The “ServletService” is another built-in Cougaar service, analogous to the “BlackboardService”

• 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.

Data

HTTP


Different Logistics Services Have DifferentPerspectives About Assets

Maintenance Tasks

EquipmentTransport Tasks

Fuel Transport Tasks

S/N: A2709Model: MEP-208A

Generator

S/N: T789Model: M978

Truck

MILITARYSEALIFT

COMMAND


Truck


Generator

PRIMEPWR-ENGCO

POL-TRKCO


Truck


GeneratorMAINTCO


FrameSet Knowledge Representation

Host

Process

Object Class

• 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

Thing

Equip

Appl

Frame name value name value name value

Relationship parent-name value child-name value

Containment inheritance

Type inheritance


Provider

Blackboard

Assessor

Requester

Blackboard Predictor

Expander

Allocator

Task Allocation Decomposition

Task1

1. Task created

Allocation

2

2. Allocation predicted

T3

3. Task transferred

T

T

4

4. Task expanded

A

5

5. Local Subtask allocated

A6

6. Remote Subtask transferred

7

7. Sub-allocations assessed

A8

8. Allocation Result published

9

9. Allocation transferred


Characteristics of Programming Models

Programming Model

Ops per Second

Isolation Thread Call Crosscut Cougaar usage

Method ~107 none Caller Sync AOP Libraries

Service ~106 Bind to service

Caller Sync Binder

Aspects

Core Services

Event Listener

~105 Bind to publisher

Publisher Sync Multiple Listeners

FrameSet

Enterprise Service

Bus

~10? Bind to Topic

Independent Async Multiple Listeners

Message transport

Service

Cougaar Blackboard

~104 Independent Independent Async Multiple

subscriptions

LDM

FrameSet

OWL

Inference Engine

~104 Independent Single Async Multiple rules FrameSet

OWL

The programming model for interaction between components, should allow a range of flexibility vs efficiency tradeoffs







6. Example Applications


Outline


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


Generic SOA Life Cycle

1. Initialize

2. Register services

3. Request Service

4. Invoke Service

5. Disconnect

ClientComponent

ServerComponent

Service Instance

Service Factory

Register Service() Service Broker

Get Service()

Invoke Service()

Get Service()

Container

The interaction between client and server is regulated at key points in the life cycle.

11

2233

44

55 11 55


Security binders wrap components to enforce behavior

Client Component

Service BrokerBinder

Container

Binder

Service BrokerGet Service()

Service Component

Service

Provider

Binder

Service Instance

Service Provider

Service Broker

Register Service()

Enhanced ServiceService

ProxyClient-side

ServiceProxy

Server-side

• Security concerns Cross-Cuts Functional Decomposition

• Untrusted Domain code is implemented in components (SOA-style)

• Binders regulate interactions between components


Component

Aspect Object

QoS State

QoS Services

Work-flow between stations

Component Component Component

Aspect Object

QoS State

QoS Services

Aspect Delegates

Aspects Cross-Cutting Functionality


Incoming Email Link Protocol

Message Transport Receiver

Node

Agent

Receive

Deliver

MTS Provider

Service BrokerAgent Binder

BB

LP

MM

RecvL

Delivr

EmailInput

StreamDeliver

Service Broker Services

POP3

Node

Transport

Service Broker

Round Trip Time AspectMessage Acking Aspect

Message Ordering Aspect

Agent

BB MTS Provider

Outgoing Email Link Protocol

ServiceBroker

RouteSend

Message Transport Sender

Agent Binder

LP

MM

SendQ

Route

DestQ

DestLink

Hold

Forward

SMTP

SendL

Services

EmailOutputStream

Message Send History Aspect

Message Numbering Aspect

Adaptive Link Selection Policy

Message Acking Aspect

Round Trip Time Aspect

Cougaar Message Transport has several unique features, such as cross-cutting protocols









Outline


Supporting Adaptation in the System Life Cycle

Development Phase

Agent Environment

Program Data Driven

Blackboard

Knowledge Rep

Event Driven

SOA

Configure Plugins Components Binders/Aspects

Deploy Society Configuration Rules

Environment Configuration Rules

Run Agent Services

Coordination

Metric Service

Management Society

IDEApplicationPlugins

DeployRules

SpecTool

RunServer

CougaarMiddleware

SocietyMonitor


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.:

<society> <node name=“Node1”> <agent name=“A”> <component class=“org.cougaar.demo.hello.HelloPlugin”/> </agent> </node></society>

<society> <node name=“Node1”> <agent name=“A”> <component class=“org.cougaar.demo.hello.HelloPlugin”/> </agent> </node></society>

<runtime> <vm_parameter name=“-Dfoo” value=“bar”/> <vm_parameter value=“-Xmx500m”/></runtime>

<runtime> <vm_parameter name=“-Dfoo” value=“bar”/> <vm_parameter value=“-Xmx500m”/></runtime>

cougaar MySociety.xml MyRuntime.xmlcougaar MySociety.xml MyRuntime.xml


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!


Servlet-based Society Monitor









Outline


Overlay Networks

• 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

ArchiveCollectors

ConfigurationAssurance

StatusCollector

StatusDissemination

ArchiveStorage

ConfigurationHistory

TrendAnalysis

ConfigurationSpecification

ThresholdDetector

AlertProcessor

StatusDisplays

CapacityPlanning

ConfigurationControl

Data Processing Assets


Mission Management as Cougaar 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

MonitoringAgents

Monitor AgentMonitor Agent

Blackboard

RealtimeSystem Model

Servlets

Coordination

Control Agents

DisseminationAgents

FCAPSAgents

Mission PlanningAgents

ObservationInference

Cougaar Agents form a control society

Data processing assets


Mission Model: Sites to Mission

• 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

Resource Plane

Processing Plane

Job-flow Plane

ResourceConstraints

Data Storage

Movement Transformation

Task Processing

Mission Requirements Plane

Geographic Plane

Sites

UtilityVs Job

Latency orThroughput

Requirements

Constraints


SASSI Optimizer Analysis Environment


Plugins Implement Subsystems and GUI

Blackboard

GIS LayerViewers

Scenario.XML

D D

DD

D D

D

D

P

P

C

C

P

PB B

C

Storm.RulesSASSI

Optimizer

TableViewer

GraphViewer

ViewFilter

ExperimentControl

WindowManager

Menu

SASSIOptimizerSASSI

Optimizer

FrameSet Input Frames ResultsFrames

Layout.Rules

OptimizerStatus

AnalysisStatus

ScenarioLoader

JessEngine

OptimizerWrapper

Sept 30, 06 Implementation









Outline


Open Source Cougaar

• Release 12.2 on Mar 13, 2007• Release 12.4 on Sep 24, 2007• Release 12.6 due Spring 2009

http://cougaar.orgGoals 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

cougaar overview john zinky 1 cougaar overview dr. john zinky february, 2009

Documents

cougaar agent society

cougaar society

cougaar agent middleware

cougaar architect

cougaar overview john

core services cougaar

agent programming

cougaar design patterns