athabasca university force protection: response...
TRANSCRIPT
ATHABASCA UNIVERSITY
FORCE PROTECTION: RESPONSE
COORDINATION USING THE CONTRACT NET
PROTOCOL
BY
RICHARD MARTELLI
A project submitted in partial fulfillment
Of the requirements for the degree of
MASTER OF SCIENCE in INFORMATION SYSTEMS
Athabasca, Alberta
August, 2007
© Richard Martelli, 2007
DEDICATION
I dedicate this thesis to my much-loved children, Samual and Alexandra, in hopes that it
inspires them towards greater achievement and learning. As I always remind them, “to be the
best, the only person you must do better than is you”. I also want to dedicate this thesis to my
parents who were always my inspiration.
ABSTRACT
The survivability of a naval surface combatant depends largely on the effective
management of combat resources. In terms of platform-centric self-protection, situation
assessment strategies and engagement policies governing weapon usage influence effective
management. These situation assessment strategies enable the surface combatant to adapt to
changes in the battlespace. In the case of network-centric operations, the task force’s ability to
adapt to changes in the battlespace relies on the information superiority gained through shared
awareness. Although shared awareness enables surface combatants to apply situation
assessment strategies to self-synchronize to the situation, engagement policies governing
weapons usage typically remain platform-centric and rely on centralized command structures
to provide overall coordination.
The research presented, herein, examines the implementation of intelligent agents to create
a partially centralized, distributed command structure using Contract Nets to coordinate tactical
responses across the task force. In support of this implementation, the NetScheduler application
was developed to support Monte Carlo based simulations of engagements involving anti-ship
missiles against a naval task force. Simulation results demonstrated improved survivability
with increased effectiveness in the management of combat resources.
i
ACKNOWLEDGEMENTS
I would like to thank my sponsor at Defence Research & Development Canada Ottawa,
Barbara Ford, for the opportunity to have joined her team in the development of simulation
tools and for allowing me to evolve that work as part of this project. I would also like to thank
my supervisor, Dr. Larbi Esmahi, and committee member Dr. Chunsheng Yang, for their
support and encouragement.
ii
TABLE OF CONTENTS
CHAPTER I ..................................................................................................... 1 Introduction .................................................................................................................... 1
Advances in Self-Protection ..................................................................................... 2
Significance of the Problem ...................................................................................... 5
Challenges for Coordination ..................................................................................... 7
Definition of Terms .................................................................................................. 8
Organization of the Project ....................................................................................... 9
CHAPTER II ................................................................................................. 10 Review of Related Literature ........................................................................................ 10
Command and Control (C2) ................................................................................... 11
Market-Based Approaches ...................................................................................... 14
Other Approaches ................................................................................................... 18
Summary ................................................................................................................ 21
CHAPTER III ................................................................................................ 22 Simulating Response Coordination ............................................................................... 22
Gaia as an Agent-Oriented Methodology ............................................................... 22
Analysis Results Using Gaia ................................................................................... 24
Implementing The Agent Model ............................................................................. 29
Implementing Agent Communications ................................................................... 34
CHAPTER IV ................................................................................................ 39 Methodology ................................................................................................................ 39
Experimentation Goal ............................................................................................. 39
Measures of Merit ................................................................................................... 44
Establishing The Number Of Simulation Runs Required ....................................... 48
CHAPTER V ................................................................................................. 49 Results .......................................................................................................................... 49
Kill Effectiveness ................................................................................................... 49
iii
Battlespace Efficiency Ratio (BER) ....................................................................... 50
Engagement Effectiveness ...................................................................................... 51
Hard-Kill Effectiveness .......................................................................................... 52
Soft-Kill Effectiveness ............................................................................................ 54
Summary Discussion .............................................................................................. 55
CHAPTER VI ................................................................................................ 57 Conclusions and Recommendations ............................................................................. 57
REFERENCES .............................................................................................. 60
APPENDIX A ................................................................................................ 64 XML Schema for FIPA ACL ....................................................................................... 64
APPENDIX B ................................................................................................ 70 Determining the Run Sample Size ................................................................................ 70
APPENDIX C ................................................................................................ 72 The NetScheduler Application ...................................................................................... 72
iv
LIST OF TABLES
PAGE
1. Abstracted Environment Model........................................................................25
2. Engagement Scenarios Used for Experimentation............................................42
3. Engagement Policy Settings............................................................................43
4. Measured Kill Effectiveness.............................................................................50
5. Measured Battlespace Efficiency Ratio............................................................51
6. Engagement Effectiveness................................................................................52
7. MOM for Non-Coordinated Hard-Kill Engagements.......................................53
8. MOM for Coordinated Hard-Kill Engagements...............................................53
9. MOM for Soft-Kill Engagements.....................................................................54
10. Soft-Kill Engagements as a Percentage of All Engagements............................55
11. Measures of Merit (MOM) Summary...............................................................55
v
LIST OF FIGURESPAGE
1. The Contract Net Interaction Protocol..............................................................17
2. The Role Schema for the Mission Commander Role........................................27
3. The Role Schema for the Mission Support Role...............................................28
4. Protocol Definitions for the Mission Commander Role....................................29
5. Vessel Class Dependencies (Platform-Centric Application).............................31
6. Vessel Class Dependencies (Network-Centric Application).............................32
7. Environment Classes for Network Operations..................................................33
8. Command Link Agent......................................................................................35
9. FIPA ACL XML Schema Layout.....................................................................37
10. Experimental Engagement Scenario.................................................................41
11. Scenario A (No Coordination) Results With Varied Number of Runs..............70
12. Scenario B (With Coordination) Results With Varied Number of Runs...........71
13. The Engagement Scenario Editor.....................................................................73
14. The Attack Scenario Editor..............................................................................74
15. The Defence Scenario Editor............................................................................76
16. Weapons Configuration Dialog........................................................................77
17. Simulation Execution Window.........................................................................78
18. Network-Centric Visualization.........................................................................79
19. Platform-Centric Visualization (Status View)..................................................80
20. Platform-Centric Visualization (Command & Control View)...........................81
21. Simulation Propagation Cycle..........................................................................82
22. Missile State Transition Diagram.....................................................................83
23. Weapons Manager Propagation Cycle..............................................................84
24. Weapon State Transition Diagram....................................................................85
25. Weapon Class Hierarchy..................................................................................85
vi
CHAPTER I
INTRODUCTION
Information is critical to meaningful interactions between individuals, communities,
businesses, and governments. In fact, information is vital to any endeavour where people must
collaborate to accomplish specific goals. Information systems aim to facilitate this
collaboration by providing capabilities such as collection, storage, processing, and
dissemination.
Prevalent in business communities, information systems support day-to-day operations
while also sustaining strategic planning and decision-making. In fact, an information system
can provide a significant competitive advantage whereby a business can respond more quickly
to changes in the marketplace than its competitors. Military organizations have recognized the
strategic advantage afforded by information systems and have been moving towards
information-enabled, network-centric operations for more than a decade (Cebrowski and
Garstka, 1998).
Network-centric operations aim to achieve information superiority. Information
superiority claims a strategic and tactical advantage, thereby increasing the agility that
determines the networked combatant’s response to changes in the battlespace that might
otherwise jeopardize mission success.
Force protection, the defensive ability of a battle group, is a key element to mission
success. Current network-centric operations rely on shared awareness to enable individual
combatants to self-synchronize (respond to new information in kind rather than through
external direction) in a cooperative response to new threats. However, poor quality or
1
conflicting information can hinder the self-synchronization process resulting in a less than
optimal response across the networked force.
The project detailed in this report examined an approach for the coordination and
collaboration of networked combatants that does not rely on self-synchronization. This
approach features intelligent agents that, fitted with appropriate goal-oriented behaviour, can
achieve optimal response coordination through negotiation using Contract Nets. The remainder
of this chapter discusses the transition within the Canadian Forces (CF) from self-protection
policies to force protection as well as the significance and challenges associated with this
transition. Lastly, this chapter outlines the paper’s organization.
Advances in Self-Protection
Studies at Defence Research & Development Canada (DRDC) focus on introducing
technologies that can facilitate effective operations of combatants within the CF. In particular,
increasing the survivability of the Canadian Patrol Frigate during a missile attack is paramount
to on-going research at DRDC Ottawa. This research examines current practices that affect the
selection and operation of onboard weapon systems and seeks to improve self-protection
through the effective management of combat resources. An integral component of the research
includes the development of models and simulations to analyse engagement policies that
govern weapons usage as well as evaluate newer, better-integrated policies that use sensor and
weapon information to support situation assessment.
The Dynamic Engagement Scheduler (DEScheduler) application developed at DRDC
Ottawa features a java-based simulation that incorporates simple models of combat systems
and anti-ship missile threats. Using the DEScheduler application, a threat analyst constructs
scenarios that define the specific attack profiles of the missile threats posed against a single
2
surface combatant, while separately defining the composition of the platform’s combat
resources. In this manner, the threat analyst can evaluate the survivability of the surface
combatant under various combinations of missile threats and combat system configurations.
An attack scenario captures the attack profile defining the initial location and simulation
time of detection for each missile threat in the battlespace. The attack scenario includes the
surface combatant’s speed and course as well as environmental conditions (i.e., wind speed and
direction). The attack scenario also allows the threat analyst to specify each missile threat’s
initial angle of attack.
A defence scenario captures the availability and configuration of each weapon system
comprising the surface combatant’s defence. This configuration includes the initial inventory
of munitions, the engagement ranges and delays associated with the weapon, and, if applicable,
the option to use enhanced capabilities specific to the weapon system. The threat analyst
creates an engagement scenario that associates a defence scenario with a specific attack
scenario for simulation.
Through the engagement scenario, the threat analyst controls the engagement policies and
situation assessment strategies governing the scheduling of combat resources. Policies
considered fundamental to current practice apply rudimentary rules of engagement to create a
layered defence strategy against anti-ship missile threats prioritized according to the time-to-go
(TTG) before impact. This layered defence strategy differentiates hard-kill weapon systems
from soft-kill weapons.
A hard-kill weapon expends munitions with the ultimate goal of physically destroying the
threat, whereas soft-kill weapon systems attempt to lure the threat away from its intended
target. The fundamental policies, as described above, favour the physical destruction of the
3
missile rather than its avoidance. With destruction as the goal, weapons are assigned to the
highest priority threat. Operational and weapon-specific engagement delays constrain the
ability to re-deploy weapons once assigned thereby limiting the combatant’s ability to respond
to new information.
In contrast to layered defence strategies, better-integrated policies leverage available
sensor and weapons data to provide greater coordination between hard-kill and soft-kill assets.
For example, rather than basing threat prioritization solely on the TTG value, enhanced polices
further rank the missile threats based on the probability of success estimated from resources
already assigned to the threat. This ranking not only serves to limit the number of resources
that are committed to any given missile threat, but also assures that a sufficient probability of
success is attained.
While certain performance predictors provide an estimate for the probability of success
and, hence, the optimum selection of weapons, others are used to assess the success or failure
of a weapon engagement as early as possible in the engagement’s life cycle. Assessing the
effectiveness of engagements supports situation assessment and enables the deployment/re-
deployment of combat resources more effectively and efficiently. For example, hard-kill
weapons, can be re-assigned or, at the very least, ammunitions can be conserved upon
confirmation of a soft-kill (threat has been decoyed and is unable to re-engage the ship).
The advanced policies implemented by DEScheduler provide dynamic and effective
management of the battlespace, thereby yielding better outcomes for self-protection
specifically during attacks that saturate the surface combatant’s defences, or where reaction
time is a limiting factor. However, these policies are platform-centric and designed to boost
survivability of a single combatant. As the CF expands its maritime role to provide greater
4
support to joint operations, platform-centric policies must complement techniques that provide
for the coordination of defences across networked combatants.
The evolution of platform-centric policies to network-centric policies presents certain
challenges. For example, the possibility of competing goals (i.e., self-survival versus force
protection) exists. Although force protection implies an equal degree of importance for
individual combatants, a task force can comprise high-value assets that may require protection
at all costs based on the impact to mission success should the high-value asset be lost.
Another challenge rests with the prioritization of threats. Each combatant relies on local
information to determine threat prioritization and may have to make assumptions regarding the
intended target of the missile threat. Given self-protection focuses on survival at all costs,
platform-centric policies need not concentrate on competing goals or conflicting priorities.
However, force protection must address these conditions and perhaps use negotiation as a
means to resolve them.
Significance of the Problem
DRDC Ottawa is committed to demonstrating the benefits of coordinating hard-kill and
soft-kill tactics for increased survivability of a surface combatant in the event of a missile
attack. In addition to increased survivability, other benefits include better battlespace
management as well as improvements to resource usage. Improving resource usage promotes
the conservation of munitions; something that could be a factor in subsequent encounters
where replenishment is unavailable.
The Defence Policy Statement issued by the Department of National Defence (DND) is
available at http://www.forces.gc.ca/site/reports/dps/index_e.asp. The Defence Policy
Statement outlines a vision of a “better integrated” forces augmented with the “rapid
5
acquisition and sharing of information”. As the role of Canadian surface combatants expands in
support of joint (i.e., maritime, land, and air) and naval task group manoeuvres, network-
centric operations will dictate the ability to sustain a “unified approach to operations”.
Furthermore, emphasis must shift from platform-centric, self-protection to mission-critical
force protection.
Alberts, Gartska, and Stein (2000) remark that organization and doctrine must co-evolve
with the introduction of new technologies to exploit network-centric operations fully. In fact,
these authors provide examples of co-evolution wherein platform-level performance
advantages drive changes to organization and doctrine.
In relation to work performed by DRDC, the benefits of coordinating hard-kill and soft-
kill tactics at the platform-centric level must extend to networked combatants. In this manner,
response coordination could not only realize overall improvements to battlespace management
across networked combatants, but also enhance stability.
Shared awareness characterizes network-centric operations, and plays a major role in the
self-synchronization of individual combatants. However, conflicting information can interfere
in the self-synchronization process and promote chaos that can cause delays that might place
force protection at risk. Coordinating responses through negotiation rather than shared
awareness could promote stability in these situations while preserving the reaction time
advantage afforded by shared situation awareness.
As the Canadian navy embraces network-centric operations, advanced platform-centric
self-protection policies must migrate over to network-centric operations and stimulate the
evolution of organization and doctrine within the CF.
6
Challenges for Coordination
Network-centric operations aim to fashion information superiority by establishing shared
awareness and, thus, achieve faster and better responses (Cebrowski & Garstka, 1998). Even
within a platform-centric context, as current research at DRDC demonstrates, networking
information between own-ship sensors and weapon systems improves reaction times under
changing circumstances to yield greater resource scheduling effectiveness. Platforms utilizing
integrated sensors and weapon systems can formulate plans based on performance predictors
and provide dynamic situation assessments of committed resources.
Extending this concept across a network adds to the shared awareness of the task group;
however, the global formulation and coordination of plans may not achieve the same degree of
efficiency due to possibly overwhelming amounts of information, and the greater scope of
decision processing required (Lee & Ghosh, 1996). In fact, Kaufman (2004) argues that
information superiority within network-centric operations may be a fallacy arguing, “it
overestimates man’s capacity to deal with contradictory information and it underestimates the
enemy’s ability for deadly mischief” (p. 62).
Kaufman believes that information superiority relies heavily on the information veracity,
something not guaranteed simply by networking information. Kaufman asserts that the role of
individual combatants should not be dependent on the network’s ability to act collectively such
that a compromise to the information flow renders individual fighters ineffective.
Similarly, Lee and Ghosh (1996) recognize the need to minimize communications across
the network, and promote independence through decentralized decision-making. However, Lee
and Ghosh rely on shared awareness to maintain the “unity of effort” across networked
combatants. Maintaining sufficient independence to allow for decentralized decision-making
7
requires a shared awareness but also insight into the engagements that other combatants are
planning as well as a status of all on-going engagements.
This project seeks to evolve performance advantages from platform-centric self-protection
policies to network-centric force protection by introducing a negotiation protocol that
minimizes the dependency of shared awareness while supporting global, yet decentralized
decision-making.
Definition of Terms
Battlespace: Battlespace encompasses all factors and activities within the sphere of
operations that influence the ability to engage or protect the force to ensure mission success.
These factors include environmental conditions as well as the distribution of friendly and
hostile forces and assets. Activities include manoeuvres, communications, surveillance,
identification, and the application of force by friendly or hostile forces.
Command and Control: Command and Control (C2) encompasses the organizations,
resources, and processes necessary for the formulation and execution of military force. As
applied to this project, “command” refers to the process of tactical decision-making while
“control” refers to the execution of tactics.
Force Protection: Force protection consists of the measures necessary to counter hostile
actions taken against personnel, facilities, and assets that might otherwise jeopardize the
force’s ability to conduct its mission.
High-Value Asset: A high-value asset (HVA) is a resource considered vital to mission
success. For example, an aircraft carrier used to provide air support is considered a HVA.
Network-Centric Operations: Based on a network of distributed resources, information
superiority can be established and exploited into a strategic and tactical advantage.
8
Organization of the Project
Chapter II of this document introduces studies conducted for Command and Control (C2)
as well as market-based approaches that might benefit the military domain. Chapter III
discusses the implementation of the simulation used for demonstrating the proposed response
coordination concepts. Chapter IV discusses the simulation methodology, the results of which
are presented in Chapter V. Although the BER for the network-centric response is lower than
that of the platform-centric response, the time spent on deliberation and communications does
not show any adverse effect on the networked combatant’s defensive ability. In fact, based on
the average number of engagements (see Table 10) and remaining inventory, the resource
consumption is lower for the network-centric response. presents a summary of the project in
terms of conclusions and recommendations.
9
CHAPTER II
REVIEW OF RELATED LITERATURE
As an agency of DND, DRDC operates six research centres across Canada and provides
the scientific expertise to ensure the timely adaptation and adoption of new technologies into
the CF. Current Research & Development (R&D) activities include:
1. Command & Control Information Systems (C2IS) Performance and Experimentation
– As part of the Sensors and Information Systems portfolio, DRDC is investigating
new concepts including the frameworks and architectures supporting new automated
or semi-automated technologies that will support military command and control
operations.
2. Autonomous Intelligent Systems – This activity in the Sensors and Information
Systems portfolio focuses on introducing self-learning, adaptable, and autonomous
capability for shared awareness and increased effectiveness among military platforms.
3. Weapon Performance and Countermeasures – As part of the Combat Systems portfolio
this activity focuses on examining the interaction between weapon and target from both
attack and defence perspectives.
DRDC is not alone in its R&D initiatives. Other agencies such as the Defence Advanced
Research Project Agency (DARPA) of the United States’ Department of Defence (DoD), and
the Defence Science and Technology Organization (DSTO) of Australia’s DoD seek to
introduce new technologies, and doctrine into military applications. DARPA programs include
the Taskable Agent Software Kit (TASK) focusing on frameworks and methodologies for
10
agent-oriented development, Coordination Decision Support Assistants that provide automated
decision support to military units, and Integrated Battle Command focusing on network-centric
operations.
DSTO is also heavily involved in the area of network-centric warfare with numerous
programs in sensor, weapon, and engagement system integrations, as well as how to best utilize
decision aid tools in support of network-centric operations. These and other organizations such
as DoD’s Command and Control Research Program (CCRP) offer articles available in the
public domain that provide general information into research regarding network-centric
operations and C2.
This chapter presents a literature review focused specifically on identifying coordination
issues faced by command and control systems and introduces techniques that may address
these issues.
Command and Control (C2)
The aspects of decision-making and command execution within C2 are distinct thereby
allowing for some degree of distribution of authority. For example, a command centre issues
orders to combatants within its command. These combatants execute the orders thereby
decentralizing command execution. Lee and Ghosh (1996) characterize the various C2
organizations noting that the traditional form of centralized command with centralized or
decentralized control is inferior to a complete decentralized solution commonly associated with
network-centric warfare. The attack vulnerability of a single command centre feeds this
assumption of inferiority. However, the authors note that having a central command provides
an effective vehicle for synchronizing combatants where the command centre acts as the
information and decision gateway.
11
Dekker (2003) poses key questions for determining the best combination of centralized
and decentralized decision-making as part of C2. In particular, Dekker explains that although a
centralized headquarters typically provides adequate facilities for collecting information and
issuing globally optimal solutions, time constraints and communications infrastructure may
hinder the ability to develop a globally optimal solution and, thus, favour decentralized
decision-making. Furthermore, Dekker notes that the transmission of orders is typically more
compact than the transmission of information required to formulate the orders.
Cebrowski and Garstka (1998) also maintain that “battle time” is a critical factor in the
decision-making and execution of tactics recognizing that network-centric operations can
provide a significant advantage in terms of reacting to changes in the battlespace. Cebrowski
and Gartska use analogies from the commercial sector as motivation for moving to network-
centric operations. For example, Cebrowski and Gartska comment:
Network-centric warfare, where battle time plays a critical role, is analogous to
the new economic model, with potentially increasing returns on investment. Very
high and accelerating rates of change have a profound impact on the outcome,
"locking-out" alternative enemy strategies and "locking-in" success. (p. 5)
Cebrowski and Gartska believe networked combatants can synchronize themselves to the
mission based on shared awareness. Where centralized command is a top-down method of
synchronization and control, Cebrowski and Gartska believe that a bottom-up process, such as
self-synchronization through shared awareness, can be just as effective.
Lee and Ghosh (1996) take the notion of synchronization a step further. They believe that
within the chaos of battle, events occur asynchronously with respect to individual combat units.
Hence, rather than focusing on synchronization through centralization, Lee and Ghosh examine 12
algorithms that promote cooperation between decentralized command and control centers.
Mission objectives and common rules of engagement form the basis for cooperation.
In this manner, combatants are free to take independent actions based on beliefs derived
predominantly from locally available information but also on information gained through
shared awareness. Decisions formed from these beliefs must adhere to the established mission
objectives and rules of engagement. A combatant communicates its beliefs and decisions only
to those combatants that are within its sphere of influence as a means of reducing the risk of
information saturation that might otherwise interfere with decision-making. Lee and Ghosh use
simulations to demonstrate the superiority of this approach against the more traditional model
of centralized command.
The simulation implements scenarios featuring both evenly matched and unevenly
matched forces. In each scenario, one force utilizes a decentralized command and control
structure while the opposing force uses a centralized command and control structure. The
opposing force must process all changes in the battlefield at the command centre, which, due to
inherent delays in communications, results in less responsive manoeuvring and targeting, and
ultimately fewer kills.
Lee and Ghosh claim faster reaction times to dynamic information using the decentralized
command structure but do not discuss the role of centralized command in providing an optimal
response. One might assume that by reducing processing and communications delays the
centralized force could approach or exceed the level of effectiveness of the decentralized
command. This observation suggests that decentralized command could benefit by
coordinating resources for an optimal response. This optimization would involve an allocation
of assets to specific targets that best increases mission success.
13
.
Market-Based Approaches
Centralized command organizations are most likely to develop globally optimal solutions.
However, time constraints warrant a decentralized approach wherein the decentralized
approach must provide for coordination between local command centres to achieve some
degree of optimization. When considering optimization as essential to allocating assets to
specific targets of opportunity, coordination can becomes a resource allocation problem. In
view of coordination as a resource allocation problem, techniques from other domains, such as
market-based approaches, may be applicable to decentralized command.
Market-based approaches deal with the concept of global good in an environment where
self-interested agents apply strategies that would otherwise maximize their own good. The
following sections discuss various market-based approaches and their influence on the global
good.
Auctions. Auctions are a means for mutually beneficial exchanges ensuring that the
seller receives fair market value while bidders obtain items at or below their valuation.
Typical to most forms of auctions, bidders continue to place ascending bids until no other
bids are tendered. The final bid establishes the price that, based on the type of auction, is paid
by the winner or all subsequent buyers.
The seller can choose the form of auction to influence a better price but it is incumbent on
individual bidders to establish a valuation of the auctioned item and implement a bidding
strategy supporting that valuation and compliant with the form of auction. For example, in an
English (Ascending) auction each bidder must bid a higher amount than the last accepted bid to
remain in the competition. To reduce the risk of having to bid an amount greater than the
14
item’s perceived valuation, bidders will implement a dominant strategy whereby bids are
intentionally lower than the bidder’s valuation of the item and, using small increments, higher
than the leading bid. In certain situations, the demand for an item may drive bids above the
item’s true valuation.
Wellman, Walsh, Wurman, and MacKie-Mason (1998) examine the application of the
English auction for decentralized scheduling of computational resources. In this context, agents
formulate bids for resources using independently established bidding strategies. Resources are
allocated based on fixed time slots where each time slot is auctioned to the highest bidder.
Agents bid for time slots in accordance with tasks to be completed. Here, an agent’s bidding
strategy aims to allocate tasks to specific time slots to maximize the surplus value across all
jobs - the difference between the agent’s maximum valuation of a particular time slot and the
actual bid.
The auctioneer establishes a reserve price for a particular time slot based on demand. The
reserve price encourages agents to reassess preferences for particular time slots based on the
agent’s goal of maximizing surplus value. This self-centric approach enables agents to
communicate their preferences for resources using market valuations, while the reserve price
encourages global optimization. Wellman, et al. notes that this approach works better when
agents compete for a single unit. In other words, if an agent requires multiple time slots to
complete a task, no globally optimal solution may arise through the auction of individual time
slots.
Combinatorial auctions specifically support bidding on a preferred bundle of items. Conen
and Sandholm note that a bidder may need to provide valuations for multiple combinations of
items in order to fully communicate preferences (Conen & Sandholm, 2003). This approach
15
can create a significant burden on agents; hence, Conen and Sandholm propose a method
whereby bidders communicate preferences by ranking bundles and providing a differential
value between a bidder’s preferred bundle and other combinations considered.
Kutangolu and Wu (1999) propose a pricing mechanism for combinatorial auctions that
recasts reserve prices between successive rounds of bidding. By increasing reserve prices
where conflicts occur, preferences are communicated globally without revealing bidder
information. Bidders rethink preferred combinations and bid accordingly until arriving at an
optimal or near-optimal solution.
A common consideration to the application of auctions is the role of the auctioneer. The
auctioneer acts as a mediator and attempts to resolve conflicts while driving towards a globally
optimal solution. Using auctions as a coordination technique in network-centric operations
would require a similar form of mediation as well as mandate a more centralized command
organization that would promote the global good.
Contract Nets. Contract nets were first proposed as a means for distributed problem
solving (Smith, 1980; Smith & Davis, 1981; Davis & Smith 1983). Through negotiation,
contracts are formed between the contract initiator and selected contractors. Initial contract
announcements include terms and conditions that contractors must satisfy in order to
participate. The initiator evaluates the submitted bids and selects one or more contractors, as
necessary.
The Foundation for Intelligent Physical Agents (FIPA, 2002) maintains the specification
regarding the interaction protocol illustrated in Figure 1.
16
Figure 1. The Contract Net Interaction Protocol
Applications of contract nets include earlier work proposed by Davis and Smith (1983). In
this work, Davis and Smith use contract nets as a form of cooperation for task sharing across
interconnected nodes. Nodes with tasks awaiting execution establish connections with those
nodes available to execute the tasks. With each connection, a contracted node can further
subdivide the task and establish additional connections with idle nodes offering the necessary
services.
17
Other applications of contract nets include work by Harker and Ungar (1996). These
authors support market-based approaches noting that bidding takes place asynchronously and
allows agents to “communicate their capabilities, utilities, and availabilities” while at the same
time agents hide details associated with the contract implementation. Harker and Ungar
propose using contract nets to control workflow, adaptively.
Task-sharing and adaptive workflow control lends itself well to the C2 domain. In fact,
Beaumont (2004) specifically examines the contract net interaction protocol, among other
coordination techniques, as means for coordinating and managing resources across multiple
surface combatants. The various mechanisms evaluated by Beaumont rely primarily on a
centralized C2 organization regarding resource allocation.
Experimentation conducted by Beaumont finds the contract net interaction protocol better
suited in situations not constrained by response time. However, this observation may simply be
a symptom of the centralized approach used in initiating contracts. Furthermore, allowing only
one networked combatant to assume the role of contractor for the force exposes this approach
to the centralized command issues raised by Dekker (2003).
Other Approaches
Other approaches not based on market economies also apply to coordination. These range
from negotiation or bargaining strategies to cooperative approaches such as blackboard and
voting systems. Although negotiation and bargaining strategies apply to cooperative settings,
the participants are typically constrained at two, whereas blackboard or voting systems are not
so constrained and warrant further investigation.
18
Blackboard Systems. Blackboard systems support distributed specialists or contributors
that cooperate to solve problems by adding to a common solution space. A contributor must
monitor this common space and determine if a role exists for that particular contributor. In
this manner, contributions occur centrally while the independence of contributors provides
for decentralization.
To apply this concept to force protection, blackboards would provide a common solution
space for one or more missile threats. The combatants, acting as contributors, would examine
the blackboard and independently allocate resources to counter the threat(s). The blackboard
system would require a controller for coordination of the submitted responses.
The communications required to maintain the shared awareness across all combatants in
terms of the threats and responses cared for on the blackboard could be prohibitive.
Voting. In auctions used for resource allocation, bids and reserve prices convey
preferences for specific resources. Published bids and reserve prices enable bidders to
formulate local strategies without requiring other bidders to reveal their preferences directly.
This allows bidders to select options in a decentralized fashion, while the auctioneer provides
the necessary coordination. Voting differs from auctions in that participants reveal their
preferences at the onset.
Used as a means to manage trade-offs between various solutions voting can overcome the
strengths and weaknesses associated with any given problem solver by merging all results
submitted. For example, differing algorithms for hand-printed character recognition may
produce conflicting results. Voting merges the results and determines the outcome based on the
majority winner (Parker, 1995). However, a clear majority may not emerge as part of the
voting process. In these cases, a ranking mechanism is necessary.
19
The Borda count (Parker, 1995; Sandholm, 1999) scores the submitted vote based on each
individual voter’s ranking of the options. The highest score determines the winner. However,
ties remain a possibility even when implementing a Borda count. Successive votes that discard
the least favoured choice of voters can eliminate ties. However, Sandholm (1999) notes when
using this approach, votes can shift to the least favoured ranking such that the least ranked
choice may achieve preferred status.
Applications of fault tolerance and data replication tend to dominate research regarding
voting algorithms. However, Pit, et al. (2005), presents a voting protocol based on Robert’s
Rules of Order Newly Revised (Robert, 2000) that applies generally to agent-based virtual
organizations. Rules of order form the basis for the protocol and detail the procedure necessary
for collective decision-making within an assembly or organization. For example, a simplified
process could consist of the following steps: open a session, table a motion, cast votes, and
declare results.
Applied to force protection, the voting process could establish agreements on plans
submitted by combatants within the task force. However, the communication and coordination
required to form an agreement presents a significant challenge. An alternate approach would be
to adapt the procedures as follows.
1. Open a session for a specific missile threat.
2. Each combatant raises one or more motions representing the resources that the
combatant can allocate to counter the threat.
3. Combatants vote by providing a ranking of the motions tabled.
4. Declare a plan and close the session.
20
As in the case of the blackboard system, voting presents a feasible approach. However, the
level of communications required to conduct a voting session may be prohibitive.
Summary
In general, market-based approaches use bidding strategies to establish globally optimal
solutions for resource allocation while the non market-based approaches reviewed tend to focus
more on collective problem solving. Auctions require a mediator and successive rounds to
develop an optimal solution whereas non market-based approaches require some form of
centralization. Hence, neither of these approaches lends itself very well to decentralized
command and presents levels of communications that might prove unaffordable.
Contract nets may best minimize the exchange of information and provide roles (i.e.,
contractor and participant) and messages to support decentralization and coordination. By
allowing more than one networked combatant to assume the role of contractor while preventing
more than one contractor for any given missile threat a dynamic, partially centralized
organization can by achieved while also supporting the distribution of command. Similar
approaches used to coordinate large groups of agents found a reduction in the overall
complexity of coordination when using dynamic, partial centralization (Scerri, Vincent, and
Mailler, 2004).
21
CHAPTER III
SIMULATING RESPONSE COORDINATION
The focus of this research is to examine, through simulation, the use of contract nets for
coordinating responses across a networked task force. This simulation involves the use of low-
fidelity models for both self-directed anti-ship missile threats and for surface combatants. The
Java-based platform-centric, Dynamic Engagement Scheduler (DEScheduler) developed at
DRDC Ottawa provides the necessary low-fidelity models. To extend the platform-centric
nature of the simulation to integrate force protection and coordinated responses, combatants
must employ goal-directed behaviour that specifically supports mission success. Equipping
each combatant with an intelligent agent provides the necessary goal-directed behaviour and
establishes a means for communication.
This chapter presents the approach used in extending the DEScheduler simulation to apply
intelligent agents and the contract net interaction protocol in an examination of response
coordination for force protection. This chapter describes the methodology used to build up the
agent model, as well as details the resulting model. Finally, this chapter presents the
implementation of the agent model and describes the communication language used to conduct
the contract net interaction protocol. The resulting extension to the DEScheduler application is
herein referred to as the NetScheduler application. For more information regarding the
NetScheduler application refer to Appendix C.
Gaia as an Agent-Oriented Methodology
The Gaia methodology for agent-oriented analysis and design (Wooldridge, Jennings, and
Kinny, 2000; Zambonelli, Jennings, and Wooldridge, 2003) offers a methodology for
22
analyzing the roles and communication protocols needed to create an agent-based society.
Selected based on its neutrality to functional domains and agent architectures, Gaia offers an
agent-oriented methodology focused on developing agents that interact within an organized
society. The organizational focus, intrinsic to Gaia, embraces the concept proposed by
Zambonelli et al., regarding the modeling of agents as human organizations. This approach
attempts to overcome the limitation inherent with object-oriented systems where execution
flows are strictly administered forming somewhat static architectures or creating dependencies
on middleware to provide greater functionality (2003). The authors argue, “an organization-
based design may reduce the conceptual distance between the software system and the real-
world system it has to support” (Zombonelli, et al., p. 326).
The organization-based design uses models to depict agent roles and interactions, as well
as the environment within which the agent society functions. A Role model applies a set of
attributes for each role, which include protocols, activities, permissions, and responsibilities.
An Interaction model elaborates the communication and protocols necessary for roles to act
together, while an Environmental model captures the domain in terms of entities and resources
available to the agents.
Developed during the analysis phase, organizational rules capture global constraints
associated with the interactions between roles and the environment. These organizational rules
support the development of an organizational structure during the architectural design phase
where the Role and Interaction models become more concrete.
Note this project presupposes an organizational structure for the implementation based on
a typical C2 organization (i.e., centralized mission command). Hence, the purpose for applying
23
the Gaia methodology reverts from one of evolving an organizational structure to that of
substantiating the given structure and documenting the required organizational behaviour.
Analysis Results Using Gaia
With dynamic, partially centralized C2 organizations as the goal, the analysis focuses on
the primary roles of Mission Commander and Mission Support. In response to threats,
identified using sensor information, missions arise to neutralize threats to the task force. The
Mission Commander, who also determines the extent of support required from other
combatants, announces a mission specific to a confirmed threat.
The Mission Commander role provides the centralized command capability, defines the
mission parameters, and establishes and controls mission support. The Mission Support role
interacts with the Mission Commander forming a hierarchical organizational structure where
the Mission Commander serves as the “master role” and governs the activities performed by
the Mission Support “slave roles”.
The organizational rules are defined as follows where s refers to system track information
representing a missile threat, and i refers to the agent:
1. ))(,())(,(, sportMissionSupiPlayssmanderMissionComiPlaysis ¬∧∀⋅∀
2.
))(,())((),( smanderMissionComiPlayssmanderMissionComisiCanEngageif →¬ ∃∧
3. )()())(),,((,, iSuccessjSuccessiffsmanderMissionComjiSupercedePlaysji >∀
The first rule simply states that for all system tracks s, agent i cannot play the roles of
Mission Commander and Mission Support concurrently. The second organizational rule
indicates that an agent can assume the role of Mission Commander if the agent can engage the
threat and no other agent is currently in that role. However, the third rule allows an agent to 24
supersede the Mission Commander if that agent deems its success criteria offer a greater
chance of mission success. This is necessary due to delays in communication that would allow
more than one agent to satisfy the second rule. In this case, a means for arbitrating which agent
should assume the role is necessary. Note, an agent may base its success criteria differently
(i.e., self-protection versus protection of consort) resulting in that agent assuming its own
mission and agenda.
The contract net interaction protocol defines the interaction between the Mission
Commander and Mission Support roles. Using this protocol, the Mission Commander solicits
support via a “Call for Proposals (CFP)”. Agents acting in the Mission Support role submit
plans (proposals) in response to the CFP. Contracts commit the support and instruct the
receiving agents to execute the proposed plan. Table 1 summarizes the resources that form the
environment within which the agents operate.
Table 1. Abstracted Environment Model
Reads System Track [ i ], i = 0, total number of threats identifiedChanges Mission [ i ], i = 0, total number of missions announcedChanges Call For Proposal [ i ], i = 0, total number submitted against a missionChanges Proposal [ i ], i = 0, total number submitted against a missionChanges Contract [ i ], i = 0, total number awarded against a mission
With an understanding of the environment, the roles can be elaborated using a schema
depicting the associated protocols, activities, permissions, and responsibilities. Protocols
identified in the schemas originate from the contract net interaction protocol whereby the
protocols determine the type of communication that occurs between roles. Activities (denoted
by an underline) are actions performed within the context of a role, while permissions refer to
the role’s access to resources in support of activities and communication protocols.
25
The terms “Liveness” and “Safety” describe a role‘s responsibility where Liveness (the
desirable path) expresses the logical flow of protocols and activities, and safety (avoiding the
undesirable) denotes the conditions needed to maintain operational integrity.
Figure 2 presents the schema for the Mission Commander role. Part of the Mission
Commander’s role is to identify missions based on sensor reports of detected missile threats.
The organizational rules are enforced as part of the activity for identifying new threats. If
satisfied, the Mission Commander creates a mission and announces the mission to other
combatants. The Mission Commander applies a delay subsequent to the announcement before
attempting to initiate the mission. This delay allows other combatants to assume the Mission
Commander role if they can demonstrate a better chance for mission success. Adding the
“Announce” message to the contract net interaction protocol supports this specific
communication.
Subsequent to the delay, the Mission Commander initiates the plan put forth with the
announcement. The Mission Commander reviews the mission objectives against engagement
policies and uses the ranking and prioritization of the system track representing the missile
threat to determine if additional combat resources are warranted. If warranted, the Mission
Commander raises a CFP. The Mission Commander will submit a proposal against the CFP
and wait for proposals to be received from other agents before finalizing the plan. As part of
mission execution, the Mission Commander will review proposals and accept or reject support
offered by other agents acting in the Mission Support role.
26
Figure 2. The Role Schema for the Mission Commander Role
Role Schema: MISSION COMMANDER (MC)Description: This role involves announcing the command of a mission, and soliciting support as
required.Protocols and Activities:
IdentifyNewMissions, ExecuteMission, ReviewMissionObjectives, Announce, CallForProposal,
FormulatePlan, ReviewProposals, RejectProposal, AcceptProposal, CancelPermissions: reads System Tracks // All evaluated and prioritized sensor
reportschanges Mission // All active missions
changes Call for Proposals // Raises CFPs as required
consumes Proposals // All proposals receivedchanges Contracts // Generates contracts as required
ResponsibilitiesLiveness: MISSION COMMANDER = (ASSESS || COMMAND)ω
ASSESS = (IdentifyNewMissions.Announce)
COMMAND = (ExecuteMission. (ReviewProposals.(AcceptProposal || RejectProposal) || Cancel ) || ReviewMissionObjectives.CallForProposals.FormulatePlan)
Safety: All threats (system tracks) have a mission commander assigned
Figure 3 contains the schema for the Mission Support role. As part of Mission Support,
mission announcements are received and processed to ensure that the best candidate is selected
for the Mission Commander role. The agent acting in the Mission Support role will not take
independent action to neutralize the threat unless the need for self-protection prevails.
However, under normal conditions the Mission Support agent will respond to a CFP by
attempting to formulate a plan based on the agents own ranking and prioritization of the sensor
information. If available, the agent will propose the plan, otherwise, the agent will refuse the
CFP. Once a proposal has been accepted and a contract issued, the Mission Support agent will
inform mission command of the success or failure of the plan.
27
Figure 3. The Role Schema for the Mission Support Role
Role Schema: MISSION SUPPORT (MS)Description: This role involves responding to changes to missile threats and on-going contracts. In
some cases, new proposals may be required, or contracts terminated based on new information.Protocols and Activities:
ProcessMissionAnnouncement, FormulatePlan, Refuse, Propose, SupportMission, InformPermissions: reads System Tracks // All evaluated and prioritized sensor
reportsreads Mission // All active missions
reads Call for Proposals // All active calls for proposals
changes Proposals // Submits proposals as necessaryreads Contracts // All contracts issued
ResponsibilitiesLiveness: MISSION SUPPORT = (ProcessMissionAnnouncement || SUPPORT)ω
SUPPORT = (SupportMission. (Refuse || FormulatePlan.Propose || Inform))
Safety: Response provided to all active calls for proposals
The Interaction model consists of a series of protocol definitions that simply indicate the
interaction initiator and participants, as well as the resources used or supplied by the protocol.
Figure 4 illustrates the protocol definitions for the Mission Commander and Mission Support
roles.
28
Figure 4. Protocol Definitions for the Mission Commander Role
(a) Mission Announcement (b) Issue Request for ProposalsProtocol Name: Announce Request
Initiator:MC
Partner: MS
Input:System Track
MC MS
Description: Announce a mission for a specific threat that has no active mission associated with it.
Output:Mission
If deemed necessary, broadcast a request for proposals after the announcement. Establish criteria for submission.
Request for Proposals
↓Propose
MS MC ProposalEvaluate the proposal.
(c) Accept Proposal (d) Reject Proposal
Accept RejectMC MS Proposal ID MC MS Proposal ID
Accept the proposal Contract ID Reject the proposal
↓ (e) Send Cancellation
Inform CancelMS MC Result MC MS
Update the contract status
Cancel the contract if warranted by changes in situation.
Contract ID
Implementing The Agent Model
The Agent Model defines the class architecture of the agent system. However, the existing
class architecture of the DEScheduler application constrains the implementation of the agent
model. This constraint can best be understood via a common understanding of an agent’s
composition. Wooldridge (2002) defines an agent as follows:
29
An agent is a computer system that is situated in some environment, and that is
capable of autonomous action in this environment in order to meet its design
objectives. (p. 15)
Wooldridge’s definition does not suggest an architectural composition as a requirement
that must be satisfied before declaring a computer system as an agent. However, Wooldridge
(2002) does distinguish intelligent agents by attributes that include reactivity, proactiveness,
and social ability. Wooldridge defines an intelligent agent’s reactivity by its ability to react to
changes in the environment, while proactiveness indicates the agent’s ability to pursue goal-
directed behaviour. Finally, an agent’s social ability refers to the agent’s ability to participate in
an agent community to satisfy its goal-directed behaviour.
An assessment of the legacy classes from the DEScheduler application (Figure 5) reveals
an architecture that does not support Wooldridge’s description of intelligent agents. In
particular, the Vessel class depends heavily on the simulation controller (SimController class)
to interact with the environment. Furthermore, the simulation only provides for a single
instance of a Vessel class, which propagates certain assumptions (e.g., missile threat will
always acquire the single combatant) and leads to an architecture that does not map well to the
agent roles model.
30
Figure 5. Vessel Class Dependencies (Platform-Centric Application)
Adapting the legacy architecture to support network-centric operations results not only in
classes that are better able to distinguish and interact with the environment but also facilitate
the mapping of the agent roles. In this new configuration, the simulation controller deals
exclusively with coordinating the simulation rather than servicing the environment for the
Vessel object. Figure 6 illustrates the revised class architecture for the network-centric
application, which incorporates the Weapons Manager and Sensor Manager Agents that better
fit the definition of intelligent agents proposed by Wooldridge (2002).
31
Figure 6. Vessel Class Dependencies (Network-Centric Application)
The Sensor Manager agent serves to monitor the simulation environment, and maintain
and prioritize system tracks for missile threats within sensor range. The Environmental Model
proposed using Gaia specifically refers to system tracks as resources available to agents. The
Weapons Manager agent monitors the resulting system tracks and formulates a response based
on the engagement policies in use (i.e., platform-centric versus network-centric). Therefore, the
Weapons Manager agent must perform the roles of Mission Commander and Mission Support.
32
To fulfill the roles of Mission Command and Mission Support the Weapons Manager
agent requires access to the resources defined in the Environmental Model. Figure 7 illustrates
the complete set of classes used to represent resources available to the Weapons Manager
agent.
Figure 7. Environment Classes for Network Operations
When operating in a platform-centric mode, the Weapons Manager agent monitors system
tracks (i.e., SensorTrack objects) and initiates one or more engagements against the sensor
track using a reactive planner. For network-centric operations, the Weapons Manager agent
implements a deliberative planner that uses proposals submitted against the mission to
determine the best response against the threat.
Reactive Versus Deliberative Planning. When operating in a platform-centric, self-
protection mode the Weapons Manager agent implements a reactive planner. The reactive
planner only considers the local prioritization of the missile threats and the weapon availability
33
at that instance in time, choosing the available weapon system with the higher probability of
success. Once a candidate weapon system has been selected, the reactive planner immediately
initiates the engagement.
In contrast, the deliberative planner considers all plans submitted by combatants within a
fixed period where a plan constitutes a proposed weapon system selected from the combatant’s
available candidates. The Mission Commander restricts eligible candidates by including in the
CFP information regarding the use of soft-kill, and the estimated time before impact. When
soft-kill is active, no further plans for soft-kill are considered, while a hard-kill tactic must
provide a firing solution with a time of intercept that satisfies the time before impact.
Furthermore, plans submitted for deliberation must account for inherent communications and
engagement delays such that the plan maintains its validity upon execution.
In all cases, the planners use local system track information for threat prioritization and
ranking, and ultimately, candidate selection. For network-centric operations, the local system
track includes the most likely target of a particular attack so that threats to HVAs are given
higher priority than threats to other combatants, including own ship. Based on established
priorities, the planners review each local system track in decreasing order of priority to
determine the requirement and nature of a response.
Implementing Agent Communications
The revised architecture satisfies Wooldridge’s reactivity and proactiveness. However, the
Weapons Manager agent must also establish a social ability to commune with other agents.
Using the CIAgent framework proposed by Bigus and Bigus (2001), an agent responsible for
linking the Weapons Manger to the command network was created. The Command Link Agent
34
(Figure 8) specifically deals with the implementation of the contract net interaction protocol
and provides the ability for Weapons Manager agents to communicate.
Figure 8. Command Link Agent
The CIAgent framework provides asynchronous, event-driven communications as well as
an ability to queue messages (events) for subsequent processing. Although the framework does
not provide a communication language, the messaging framework is sufficiently generalized to
support any of the message-based languages for agent communication such as DARPA’s
Knowledge Query and Manipulation Language (KQML) and FIPA’s own Agent
Communication Language (ACL). Both standards detail the message structure and speech acts
that form the basis of the communication. However, the FIPA ACL purposely complements
35
the FIPA Contract Net Interaction Protocol. Hence, the FIPA ACL was adopted as the
communication language for the Command Link Agent, and incorporated into the protocol
definitions referred to in the role schemas.
Similar to KQML the FIPA ACL details the “outer” message structure (the message
envelope) but not the “inner” message content. Note agents typically operate in a shared
knowledge domain. Therefore, the language that defines the content must be able to express the
concepts, terms, and relationships familiar to that knowledge domain and thereby promote
interoperability between agents using common semantics. FIPA also provides the Semantic
Language (SL) specifically for constructing message content.
The FIPA SL uses symbolic expression (referred to as s-expression) for creating human-
readable, well-formed content interpretable by agents. Equipping agents with the ability to
interpret human-readable content is fundamental to the enabling technologies applied for
semantic web principles. The World Wide Web Consortium (W3C) develops technologies for
interoperability between data available on the Web. The semantic web aims to create an
environment that presents information or knowledge in a machine-workable format. This goal
requires the ability to represent information using a standard syntax as well as being able to
convey the properties of the data and communicate relationships with other data. Hence, the
choice of content language is not limited to the FIPA SL but can take advantage of newer
technologies or standards supporting the semantic web concept. In particular, the Extensible
Markup Language (XML) Schema standard offers significant advantages to this project.
An XML Schema deals with defining the structure and content of XML documents used to
exchange information. In fact, an XML Schema can detail the outer message structure as well
36
as the inner message content. This simplifies the simulation requirements due to the use of an
XML document to provide the communications between agents.
Converting the FIPA Document Type Definition (DTD) for representing the FIPA ACL in
XML format (FIPA – XML, 2002) provides an initial configuration for the XML Schema
describing the outer and inner message structure (see Figure 9). Note the choices for content
type, as shown in Figure 9, correspond to the protocols identified in the Role Schemas (Figure
2 and Figure 3). Appendix A includes further details regarding the implementation of content
types.
Figure 9. FIPA ACL XML Schema Layout
37
The DEScheduler simulation tool applies an XML Schema to support the scenario
database. Using the Java Architecture for XML Binding (JAXB), the DEScheduler simulation
tool can easily maintain XML documents containing the scenario database. Similarly,
incorporating the XML Schema and JAXB technologies for the construction or parsing of
XML documents containing FIPA ACL messages simplifies the implementation.
A further simplification of the implementation involves the use of a transmission delay.
Modeling the communications network is not necessary for the purpose of this research. In
practice, wireless tactical data links maintain the shared awareness across the networked
combatants. Although a simulation of this network using distributed processes across a local
area network (LAN) is possible, for the purpose of this research the simulation uses a simple
processing wait state to represent delays inherent in typical transport mechanisms.
38
CHAPTER IV
METHODOLOGY
The NetScheduler application, developed for experimentation, supports Monte Carlo
simulation methods for investigating the efficacy of engagement policies used for self-
protection as well as for force protection. This chapter discusses the methodology applied to
the conduct of the simulation including an overview of the engagement scenario, the
engagement policies applied, and the measures of merit employed in reporting results.
Experimentation Goal
Experimentation using the NetScheduler application focuses on evaluating the contract net
interaction protocol for coordinating force protection and not on evaluating tactics or
combination of tactics resulting from a coordinated response. The evaluation considers the
effective use of weapons in scenarios involving a coordinated response versus scenarios
lacking any form of response coordination and relying instead on common rules of
engagement. Furthermore, the evaluation must consider if the use of contract nets compromises
the ability of the task force to defend itself.
The Engagement Scenario. The NetScheduler application supports Monte Carlo
simulation methods that apply user-defined scenarios. For the purpose of this project, the
experiments feature an attack scenario containing two groups of subsonic missile threats with
the two missile groups appearing within a short period of each other (approximately two
seconds) and approaching the task force from orthogonal directions. The engagement scenario
attempts to saturate the task force’s defences by introducing multiple threats from two different
sectors.
39
The defence scenario contains a task force consisting of four combatants and two HVAs
acting in a non-combatant capacity (see Figure 10). The task force’s formation involves a
defensive screen created by surrounding the HVAs with the four combatants. Approximately
two kilometres separates the combatants from the nearest HVA. This formation attempts to
represent a situation where a task force might navigate along a prescribed shipping lane in
constrained waters (i.e., littoral conditions). All combatants sport the full complement of
weapons granted by the simulation, which includes soft-kill and hard-kill weaponry.
The ability of a combatant to defeat a missile threat is largely dependent on the available
battlespace. In other words, as the missile threat’s time-to-go (time before impact) decreases,
the combatant has less time to mount a defence and possibly fewer options with which to
engage the missile threat. Time-to-go is dependent on the range and speed of the missile threat.
Hence, to determine the sensitivity of time-to-go as a factor of mission success, the
experiments vary the initial distance of the missile threats from the task force wherein the
values vary from beyond the programmed sensor range of 35 km to a distance where reaction
time is seriously handicapped (e.g., 15 seconds to impact).
40
Figure 10. Experimental Engagement Scenario
Table 2 lists the engagement scenarios created for experimentation based on the attack and
defence scenarios described. Note, the engagement scenario determines the engagement
policies used and determines if the task force operates in non-coordinated mode (no
coordinated response) or uses response coordination using the contract net interaction protocol.
The initial range (measures form a common point of origin) given in Table 2 determines at
what range the missile threat first appears in the simulation. Missiles in the simulation will
travel along the initial heading defined by the attack scenario until a target has been acquired at
which point heading corrections will be introduced into the missile’s flight path. Target 41
acquisition does not occur until the missile’s seeker has been activated. Table 2 specifies the
activation point, measured as a distance from the point of origin. Note for initial ranges less
than 30 km (well inside ship’s sensor range) the missile appears with its seeker activated from
the onset.
Table 2. Engagement Scenarios Used for Experimentation
Engagement Scenario
Coordinated Response Initial Range Range
VarianceSeeker
ActivationActivation Variance
Scenario A No 40 km 1 km 20 km 1.5 km
Scenario B Yes 40 km 1 km 20 km 1.5 km
Scenario C No 30 km 1 km 20 km 1.5 km
Scenario D Yes 30 km 1 km 20 km 1.5 km
Scenario E No 20 km 1 km 20 km 1 km
Scenario F Yes 20 km 1 km 20 km 1 km
Scenario G No 10 km 0.5 km 10 km 0.5 km
Scenario H Yes 10 km 0.5 km 10 km 0.5 km
Engagement Policy Settings. Combatants within a non-coordinated task force utilize a
reactive planner that determines the combatant’s response to a threat whereas the coordinated
response employed by the mission commander within the task force utilizes a deliberative
planner. The engagement scenario defines the engagement policy thresholds used by both the
reactive and deliberative planners for non-coordinated and coordinated defence, respectively.
In particular, policies controlling threat ranking and weapon assignment determine the level at
which the planner can respond to a given threat.
42
Table 1 denotes constraints applied for threat ranking and response planning based on the
planner type employed. The TTG values determine the threat ranking and establish regions
wherein ranking increases as the threat missile enters into a particular region. Note the
deliberative planner extends the regions to provide coverage for HVAs or other combatants
within the deliberative planner’s sphere of influence.
The required PSuccess is also higher for force protection as is the number of concurrent
engagements allowed. Note in the case of the reactive planner, each combatant is equipped
with at most five weapon systems. However, the deliberative planner has access to resources
offered by other combatants. Hence, the deliberative planner can increase the allowable
number of engagements without committing all of the combatant’s own resources and thus
rendering the combatant unable to defend itself.
Table 3. Engagement Policy Settings
Threat Ranking
Time-To-Go (TTG)
(sec)
Required Probability of Success ( PSuccess )
Maximum Number of Concurrent Engagements
Reactive Deliberative Reactive Deliberative Reactive Deliberative
Low 40>t 60>t 50% 95% 1 3
Medium 4010 ≤< t 6015 ≤< t 75% 95% 2 5
High 10≤t 15≤t 90% 99% 4 7
In addition to engagement policies that determine the response level, other policies define
situation assessment conditions surrounding when the planner can consider the missile threat as
neutralized by a soft-kill tactic. These conditions assess the lethality of the threat as well as its
ability to re-orient onto its intended target. The lethality condition monitors the closest point of
43
approach (CPA). An increasing CPA indicates that the threat is moving away thus reducing its
potential lethality.
For platform-centric self-protection, the reactive planner assesses the threat’s lethality over
a specified period of time and if the threat’s CPA increases beyond 500 metres, no further
weapon engagements against the threat are initiated. To prevent this condition from hastily
reducing the planner’s response wherein another combatant in the task force would be under
attack, the CPA threshold was increased to 2,000 metres – effectively disabling the condition.
Similarly, the assessment of the missile threat’s ability to re-orient onto its intended target
was also effectively disabled by increasing the assessment period from three seconds to four
seconds, and by increasing the tolerance by a factor of 20%.
Measures of Merit
The measures of merit (MOM) used for evaluation aim to quantify the outcomes in terms
of overall effectiveness and resource usage. Overall effectiveness refers to the task force’s
ability to defeat incoming missile threats while not compromising the task force’s ability to
defend itself through poor management of the battlespace or over-expenditure of munitions.
Kill Effectiveness. The kill effectiveness EKill , given in Equation (1), measures the total
number of kills against the total number of missile threats across all simulation runs. A kill
includes the destruction of the missile threat or its seduction away from the task force such that
the missile threat cannot engage the task force. Ideally, the kill effectiveness should be 100%,
indicating the task force’s ability to neutralize all missile threats.
44
RunsNN
E Threats
Kills
Runs
Kill
100×=
∑ (1)
Battlespace Efficiency Ratio. The battlespace efficiency ratio (BER) given in Equation (2)
compares the actual amount of time spent by the task force engaging the missile threat versus
the window of opportunity or the period commencing at the missile’s earliest time of detection
by the task force. In typical scenarios, combatants have a short time to assess a threat and
initiate a response. Increasing the amount of time spent engaging the threat within the given
window of opportunity increases the probability of success and is, hence, a desirable situation.
Runs
x
x
BERRuns TrackedHostile
Engaged
TT∑ ∆
∆ ×
=
100)(
)(
_(2)
Engagement Effectiveness. The engagement effectiveness E sEngagement , given in Equation
(3) measures the total number of successful engagements (i.e., Joys) against the total number of
engagements initiated by the task force’s combatants. Non-successful engagements are those
that fail outright, such as when the counter missile fails to strike the incoming missile threat, or
those aborted when another engagement is successful, or when the weapon system can no
longer sustain the engagement (i.e., threat enters a blind zone).
RunsRuns sEngagement
Joys
sEngagement
NN
E∑ ×
=
100 (3)
45
Hard-Kill Effectiveness. The hard-kill effectiveness E KillHard − , given in Equation (4)
measures the number of successful hard-kill engagements against the total number of hard-kill
engagements initiated across the task force.
RunsRuns sEngagementKillHard
KillsHardSuccessful
KillHard
NN
E∑ ×
= −
−
−
100_
_
(4)
Soft-Kill Effectiveness. The soft-kill effectiveness E KillSoft − , given in Equation (5)
measures the number of successful soft-kill engagements against the total number of soft-kill
engagements initiated across the task force. Note for a soft-kill engagement to be successful,
the missile threat must not make contact with the task force, nor should the task force destroy
it.
RunsRuns sEngagementKillSoft
KillsSoftSuccessful
KillSoft
NN
E∑ ×
= −
−
−
100_
_
(5)
Long-Range Inventory. The long-range inventory given in Equation (6) reflects the usage
of long-range weaponry (i.e., Surface-to-Air Missile, SAM) by providing a measure of the
remaining inventory across the task force.
RunsRuns InventorySAM
mainingSAM
RangeLong
NN
I∑ ×
=−
100_
Re_
(6)
46
Mid-Range Inventory. The mid-range inventory given in Equation (7) reflects the usage of
mid-range weaponry (i.e., 57 mm gun) by providing a measure of the remaining inventory
across the task force.
RunsRuns InventoryAmmoGun
mainingAmmoGun
RangeMid
NN
I∑ ×
=−
100__
Re__
(7)
Short-Range Inventory. The short-range inventory given in Equation (8) reflects the usage
of close-in weapon systems by providing a measure of the remaining inventory across the task
force.
RunsRuns InventoryCIWS
mainingAmmoCIWS
RangeShort
NN
I∑ ×
=−
100_
Re__
(8)
Chaff Inventory. The chaff inventory given in Equation (9) reflects the usage of off-board
counter-measures by providing a measure of the remaining inventory across the task force.
RunsRuns InventoryChaff
mainingChaff
Chaff
NN
I∑ ×
=
100_
Re_
(9)
Establishing The Number Of Simulation Runs Required
The simulation uses the Probability of Success ( PSuccess ) associated with a particular
weapon system to determine an engagement’s outcome. Conducting multiple simulation runs
creates a population size that approximates all possible outcomes thereby establishing a form of
47
consistency across simulation results. Simulations were conducted wherein the number of runs
per simulation was varied across a range of 20 to 140 runs. Appendix B illustrates the results
for both Scenario A and Scenario B, which show the MOM converging at approximately 140
runs. Therefore, the simulations outlined in Table 2 were conducted using 140 runs per
experiment.
48
CHAPTER V
RESULTS
To determine the viability of using contract nets to establish response coordination for task
force protection it is necessary to compare results where coordination relies on a platform-
centric response (i.e., common rules of engagement) with those obtained as part of a network-
centric (i.e., coordinated task force) response. This chapter presents the results in terms of the
MOM acquired via Monte Carlo simulation techniques using air defence scenarios featuring
four separate missile threats appearing at distances exceeding sensor range to distances that
significantly reduce TTG (e.g., 10 km). The MOM presented, summarize the recorded
experimentation results denoting the number and duration of engagements, engagement types
(i.e., hard-kill, soft-kill), engagement outcomes (i.e., success, fail, or aborted), results (i.e., hit,
miss, soft-kill, hard-kill), and weapon inventory usage. In addition to the MOM, this chapter
includes a discussion of the results.
Kill Effectiveness
The Kill Effectiveness score measures the ability of the task force to defeat missile threats.
Table 4 compares kill effectiveness measures for scenarios involving platform-centric and
network-centric responses to missile threats appearing at ranges varying from 10 to 40
kilometers. The kill effectiveness measured for platform-centric responses shows a variation of
<1% from the overall score across simulations where the missile threat appears at close range,
to when the missile threat appears beyond sensor range.
49
Similarly, the kill effectiveness measured for network-centric responses shows a variation
of <1% across the initial ranges while also demonstrating a slight improvement (~2%) over the
platform-centric measures.
Table 4. Measured Kill Effectiveness
Kill Effectiveness
Initial Range
Platform-Centric
Response
Network-Centric
(Coordinated) Response
40 Kilometres 96.6% 98.9%30 Kilometres 96.4% 98.9%20 Kilometres 95.9% 98.8%10 Kilometres 97.5% 98.2%
Overall 96.6% 98.7%
Battlespace Efficiency Ratio (BER)
The BER measures the ability of the task force to exploit the window of opportunity
available to engage the missile threat. Table 5 compares the BER measured for platform-
centric and network-centric responses while varying the initial range at which missile threats
appear. The results show that at ranges of 30 and 40 kilometres, there is no significant
difference in BER for platform-centric and network-centric responses. However, at 10 and 20
kilometres, the platform-centric response shows a better use of the battlespace. Overall, the
platform-centric response shows a significant advantage over the network-centric response.
50
Table 5. Measured Battlespace Efficiency Ratio
Battlespace Efficiency Ratio
Initial Range
Platform-Centric
Response
Network-Centric
(Coordinated) Response
40 Kilometres 41.0% 41.3%30 Kilometres 56.9% 56.4%20 Kilometres 95.5% 80.6%10 Kilometres 90.8% 74.1%
Overall 71.1% 63.1%
Engagement Effectiveness
The engagement effectiveness measures the number of successful engagements compared
with the actual number of engagements initiated. Table 6 compares the engagement
effectiveness for platform-centric responses with network-centric responses while varying the
initial range at which the missile threats appear. The engagement effectiveness does not vary
significantly across the various ranges for the platform-centric response, showing a variation of
less than 3%. The network-centric response shows a variation of 16%. However, in all cases
the network-centric response exceeds the platform-centric response in terms of engagement
effectiveness.
51
Table 6. Engagement Effectiveness
Engagement Effectiveness
Initial Range
Platform-Centric
Response
Network-Centric
(Coordinated) Response
40 Kilometres 22.2% 46.1%30 Kilometres 22.3% 41.5%20 Kilometres 21.7% 38.5%10 Kilometres 19.4% 30.9%
Overall 21.4% 39.3%
Note the average number of engagements initiated per run for platform-centric responses
was 18.5 engagements, whereas the average number of engagements per run for network-
centric responses was 10.7 engagements. Hence, network-centric responses achieved a greater
percentage of successful engagements with fewer engagements actually initiated.
Hard-Kill Effectiveness
The hard-kill effectiveness measures the number of successful hard-kill engagements over
the total number of hard-kill engagements initiated. Table 7 denotes the hard-kill effectiveness
for non-coordinated hard-kill engagements (platform-centric response). In addition to the
rundown of hard-kill effectiveness values for platform-centric responses, Table 7 also shows
the remaining inventory for all hard-kill weapon types. On average, only 35% of the hard-kill
engagements initiated as part of a platform-centric response were successful. Furthermore, the
remaining inventories show a greater usage of long-range weaponry (i.e., SAM).
52
Table 7. MOM for Non-Coordinated Hard-Kill Engagements
Initial RangeHard-Kill
EffectivenessLong-Range
InventoryMid-Range Inventory
Short-Range Inventory
40 Kilometres 35.6% 82.5% 99.9% 100%30 Kilometres 35.8% 82.8% 100% 100%20 Kilometres 37.1% 84.1% 99.2% 99.9%10 Kilometres 30.9% 89.1% 98.4% 94.9%
Overall 34.9% 84.6% 99.4% 98.7%
Table 8 contains the hard-kill effectiveness and inventory values for coordinated (network-
centric) responses. In this case, 47% of hard-kill engagements were successful with inventory
values showing usage generally spread across the range categories.
Table 8. MOM for Coordinated Hard-Kill Engagements
Initial RangeHard-Kill
EffectivenessLong-Range
InventoryMid-Range Inventory
Short-Range Inventory
40 Kilometres 62.9% 95.3% 86.0% 99.1%30 Kilometres 42.4% 91.4% 91.0% 99.2%20 Kilometres 43.5% 93.2% 92.3% 97.2%10 Kilometres 37.7% 94.3% 96.0% 92.8%
Overall 46.6% 93.6% 91.3% 97.1%
Note that although the overall hard-kill effectiveness is below 50% in both the platform-
centric and network-centric scenarios, a review of the recorded data showed that the percentage
of missiles that were actually hard-killed is 97.3% for platform-centric responses and 99.7%
for network-centric responses. Hence, the lower hard-kill effectiveness values do not reflect an
inability to defeat the missile threat using hard-kill tactics, rather the scores reflect the over-
deployment of hard-kill tactics.
53
Soft-Kill Effectiveness
The soft-kill effectiveness measures the number of successful soft-kill engagements over
the total number of soft-kill engagements initiated. Table 9 shows the soft-kill effectiveness for
platform-centric and network-centric responses, as well as the remaining chaff inventory in
each case. The values for soft-kill effectiveness are extremely low in both cases where 4% of
the soft-kill engagements are successful under platform-centric conditions while 3% are
successful for network-centric conditions.
Table 9. MOM for Soft-Kill Engagements
Platform-Centric Response Network-Centric (Coordinated) Response
Initial RangeSoft-Kill
EffectivenessChaff
InventorySoft-Kill
EffectivenessChaff
Inventory
40 Kilometres 4.5% 89.4% 6.4% 96.6%30 Kilometres 4.8% 90.0% 2.0% 97.3%20 Kilometres 4.3% 78.7% 3.3% 94.4%10 Kilometres 2.4% 63.1% 0.02% 95.1%
Overall 4.0% 80.3% 2.9% 95.9%
Although the platform-centric response provided a higher success factor for soft-kill,
Table 9 also shows that 20% of the chaff inventory was spent during the platform-centric
response versus the 4% of inventory spent for the network-centric response. Hence, five times
the inventory was spent for the platform-centric response with only a 1% gain of effectiveness.
Table 10 provides context for the soft-kill effectiveness results by identifying the
percentage of soft-kill engagements versus the average number of engagements initiated per
simulation run. The data shows that platform-centric responses produce more engagements
overall of which a larger percentage of the engagements, as compared to network-centric
responses, are soft-kill.
54
Table 10. Soft-Kill Engagements as a Percentage of All Engagements
Initial Range
Platform-Centric Response Network-Centric ResponseAverage no. of
engagements
% Soft-Kill Average no. of
engagements
% Soft-Kill
40 Kilometres 18.1 37.0% 9.3 37.0%30 Kilometres 18.3 36.8% 9.8 16.5%20 Kilometres 18.1 40.5% 10.9 27.7%10 Kilometres 19.7 41.0% 12.7 27.7%
Overall 18.6 38.8% 10.7 27.2%
Summary Discussion
The network-centric response was shown to provide higher effectiveness scores than
platform-centric responses, with the noted exception of soft-kill effectiveness (see Table 11).
The low score of soft-kill effectiveness is a direct result of the simultaneous deployment of
hard-kill tactics.
Table 11. Measures of Merit (MOM) Summary
Initial Range
Platform-Centric
Response
Network-Centric
(Coordinated) Response
Kill Effectiveness 96.6% 98.9%BER 71.1% 63.1%Engagement Effectiveness 21.4% 39.3%Hard-Kill Effectiveness 34.9% 46.6%Soft-Kill Effectiveness 4.0% 2.9%
The destruction of a missile threat by a hard-kill weapon results in the suspension of any
soft-kill assessment. The cancellation of the soft-kill assessment results in the soft-kill
engagement being flagged as a failure. Hence, the soft-kill effectiveness value does not provide
an indication of the efficacy of soft-kill tactics but viewed in conjunction with the chaff 55
inventory can give some indication to the coordination provided by the network-centric
response. This coordination produced fewer soft-kill engagements and ultimately expended
fewer munitions.
Although the network-centric response demonstrated better effectiveness, the efficiency
score provided by the BER was below that of the platform-centric response. The BER values
favour the platform-centric response where BER is a measure of the task force’s ability to
make use of the window of opportunity to engage a missile threat. The lower BER for network-
centric responses is an indication of the time spent on deliberation and coordination of the task
force’s resources.
While the missile threat is beyond weapon range, the difference in BER values is
negligible (see Table 5) because deliberation and coordinating communications takes place
before the threat has entered weapon ranges. When missile threats appear within weapon range,
the time spent on deliberation and coordination occurs within the window of opportunity to
engage the threat thereby reducing the actual time spent engaging the threat and, thus, reducing
the BER.
Although the BER for the network-centric response is lower than that of the platform-
centric response, the time spent on deliberation and communications does not show any
adverse effect on the networked combatant’s defensive ability. In fact, based on the average
number of engagements (see Table 10) and remaining inventory, the resource consumption is
lower for the network-centric response.
56
CHAPTER VI
CONCLUSIONS AND RECOMMENDATIONS
The project detailed in this report examined the use of Contract Nets for the coordination
and collaboration of networked combatants against anti-ship missile threats. This examination
involved the development of a simulated environment wherein each surface combatant uses
intelligent agents to formulate plans and negotiate a coordinated response. Simulation results
demonstrated improved survivability with increased effectiveness in the management of
combat resources.
The simulation involved a comparison of surface combatants using platform-centric
engagement policies versus those using intelligent agents for network-centric response
coordination. Combatants operating in platform-centric mode formed a completely
decentralized C2 structure while the combatants using intelligent agents created a dynamic,
partially centralized organization. The resulting comparison focused on ship survivability,
battlespace management, and resource usage. In particular, it was necessary to determine if
using Contract Nets for response coordination compromised the task force’s defensive ability.
The results of the comparison did not reveal any compromise to force protection. In fact,
the results revealed an improvement in survivability in the form of kill effectiveness while also
demonstrating a reduction in resource consumption. A reduction in resource consumption
increases the task force’s ability to react to new situations. In other words, as new threat
detections occur, the availability of resources enables the task force to respond with a broader
range of options (i.e., long-range or mid-range weapons). This broader range of options
increase the task force’s agility.
57
The command structure also influences the task force’s agility. In the approach examined
in this project, the intelligent agents implemented a dynamic, partially centralized command
structure through roles facilitated by the contract net interaction protocol. Beaumont’s use of a
central coordinator with Contract Nets found good survivability results. However, Beaumont
noted that communications and TTG were critical factors (2004).
This project’s results did not reflect this observation. In fact, results based on the dynamic,
partially centralized organization showed consistent scores across all TTG values (represented
as ranges). In the case of communications, a partial centralization could compensate in the
event of failure. This compensation would manifest as multiple Mission Command roles being
assumed. In addition, the intelligent agent’s goal-directed behaviour maintains the surface
combatant’s ability to take independent action. This independence enables the surface
combatant to rely on local information to set priorities, formulate plans, and, when necessary,
to give all priority to defending itself.
Although the proposed dynamic, partially centralized command structure was an attempt
to evolve organization and doctrine, as suggested by Alberts (Alberts, et al, 2000), in line with
advances in self-protection, it was necessary to circumvent some of the situation assessment
algorithms developed specifically for self-protection. Due to the platform-centric nature of
these algorithms (i.e., lethality and soft-kill kill-assessments), a surface combatant could
prematurely assign a non-threat status to an anti-ship missile based on its own self-centric
evaluation and not consider the threat to other combatants. Hence, further work is required to
progress concepts used in self-protection towards more inclusive task force policy.
Coordination of tactics is another area that warrants further work. Investigating how the
deliberative planner could decide upon which tactics to initiate from proposed plans was not
58
within the scope of this project. However, based on the feasibility of Contract Nets
demonstrated by the results, there would be merit in growing the deliberative planner used in
the NetScheduler tool to include tactical coordination.
As a tool, NetScheduler has proven effective in conducting simulations to support
platform-centric and network-centric studies of engagement policies. However, NetScheduler’s
ability to display situational information and present planner information to the user exhibits a
decision-aid quality. Hence, NetScheduler serves also as a prototype for a decision-aid tool
using intelligent agents to negotiate a solution for the global good.
As a decision-aid tool, response coordination using Contract Nets would be more readily
accepted into operational use rather than introducing this approach into operational doctrine.
Before any operational doctrine can be adapted, significant development and experimentation
must occur. This development and experimentation could involve the use of higher fidelity
models as well as intelligent agents that derive beliefs from local information, coordinate plans,
and adjust roles and engagement policies to promote mission success. Thus, the project’s
contribution of the NetScheduler application can be extended further to investigate inclusive
engagement policies and examine the role of Contract Nets as part of evolving organizational
doctrine or implementing agent-based decision-aids.
59
REFERENCES
Alberts, D., Gartstka, J.J. and Stein, F.P. (2000). Network-Centric Warfare: Developing and
Leveraging Information Superiority 2nd Edition (Revised), CCRP Publications. Retrieved
on March 1, 2007 from http://www.dodccrp.org/html3/pubs_download.html.
Beaumont, P. (2004). Multi-Platform Coordination and Resource Management in Command
and Control, Master Thesis, Laval University. Retrieved on November 29, 2006 from
http://damas.ift.ulaval.ca/projets/TeamWork/publications.en.html.
Bigus, J.P. and Bigus, J. (2001). Constructing Intelligent Agents Using Java, Second Edition.
New York, NY: John Wiley & Sons.
Cebrowski, A. and Garstka, J.J. (1998). Network-Centric Warfare: Its Origins and Future,
Proceedings of the Naval Institute 124:1, January 1998, p. 35. Retrieved on October 19,
2006 from http://www.oft.osd.mil/initiatives/ncw/docs/NCW_Origins_and_Future.doc
Conen, W. and Sandholm, T. (2003). Differential-revelation VCG mechanisms for
combinatorial auctions. In Proceedings of the 4th ACM Conference on Electronic
Commerce (San Diego, CA, USA, June 09 - 12, 2003). EC '03. ACM Press, New York,
NY, pp. 196-197. Retrieved on November 21, 2006 from DOI= http://0-
doi.acm.org.aupac.lib.athabascau.ca:80/10.1145/779928.779956
Davis, R. and Smith, R.G. (1983). Negotiation as a metaphor for distributed problem solving.
Artificial Intelligence, 20, pp. 63-109. Retrieved on October 27, 2006 from
http://citeseer.ist.psu.edu/zhang93negotiation.html.
Dekker, A.H. (2003). Centralisation and Decentralisation in Network Centric Warfare, Journal
of Battlefield Technology, 6, 2, pp. 23-28, July 2003. Retrieved on March 2, 2007 from
http://members.ozemail.com.au/~dekker/Dekker.JBT.2003.pdf
60
FIPA – Foundation for Intelligent Physical Agents (2002). FIPA ACL Message Representation
in XML Specification, Retrieved on March 22, 2006 from http://www.fipa.org
FIPA – Foundation for Intelligent Physical Agents (2002). FIPA ACL Message Structure
Specification, Retrieved on March 22, 2006 from http://www.fipa.org
FIPA - Foundation for Intelligent Physical Agents (2002). FIPA Contract Net Interaction
Protocol, Retrieved on June 14, 2006 from http://www.fipa.org/assets/XC00029G.pdf.
Harker, T.H. and Ungar, L.H. (1996). A Market-Based Approach to Workflow Automation,
Presented at NSF Workshop in Information Systems (Athens, GA, May 8-10). Retrieved
on October 1, 2006 from http://www.cis.upenn.edu/~ungar/NSF.html
Kaufman, A. I. (2004). Curbing Innovation: How Command Technology Limits Network
Centric Warfare. Argos Press, Canberra. Retrieved on June 23, 2006 from
http://www.argospress.com/books/Kaufman-CI/Chapter%205.pdf
Kutanoglu, E. and Wu, S.D. (1999). On Combinatorial Auction And LaGrangean Relaxation
For Distributed Resource Scheduling. IIE Transactions, 31, pp. 813-826. Retrieved on
November 16, 2006 from
http://www.me.utexas.edu/~erhank/papers/journal/KutanogluWu-IIETrans-1999.pdf
Lee, T. and Ghosh, S. (1996). Simulating Asynchronous, Decentralized Military Command
and Control. IEEE Computational Science and Engineering, 3, 4, pp.
69-79. Winter, 1996.
Parker, J.R. (1995). Voting Methods for Multiple Autonomous Agents, ANZIIS '95, Perth,
Australia. Nov. 27, 1995, Retrieved on December 9, 2006 from
http://citeseer.ist.psu.edu/339155.html
61
Robert, H. and Others. (2000). Robert’s Rules of Order Newly Revised 10th edition.
Cambridge, Mass.: Perseus Publishing.
Sandholm, T. (1999). Distributed Rational Decision Making, In the textbook Multiagent
Systems: A Modern Introduction to Distributed Artificial Intelligence, Weiß, G., ed., MIT
Press. Pp. 201-258., Retrieved on November 19, 2006 from
http://www.cs.cmu.edu/~sandholm/
Scerri, P., Vincent, R. and Mailler, R. (2004). Comparing Three Approaches to Large Scale
Coordination. Proceedings of the First Workshop on the Challenges in the Coordination
of Large Scale Multi-agent Systems. July 2004 Retrieved on March 5, 2007, from
ftp://mas.cs.umass.edu/pub/mailler/LSMAS-2003.pdf
Smith, R.G. (1980). The Contract Net Protocol: High Level Communication and Control in a
Distributed Problem Solver. IEEE Transactions on Computers, 29, 12, pp. 1104-1113.
Smith, R.G. and Davis, R. (1981). Frameworks for Cooperation in Distributed Problem
Solving, IEEE Transactions On Systems, Man, And Cybernetics, 11, 1, January 1981,
Retrieved on October 31, 2006 from
http://www.rgsmithassociates.com/Frameworks_for_Cooperation_in_Distributed_Probl
em_Solving_Jan-1981.pdf
Wellman, M., Walsh, W., Wurman, P. and MacKie-Mason, J. (2001). Auction Protocols for
Decentralized Scheduling, Technical report, University of Michigan, July 1998
Wooldridge, M. (2002). An Introduction to MultiAgent Systems. West Sussex, England: Wiley
& Sons.
62
Wooldridge, M. J., Jennings, N. R. and Kinny, K. (2000). The Gaia Methodology for Agent-
Oriented Analysis and Design. Autonomous Agents and Multi-AgentSystems, 3, 3, pp.
285-312. Retrieved September 12, 2006 from The ACM Digital Library
Zambonelli, F., Jennings, N. R. and Wooldridge, M. J. (2003). Developing Multi-Agent
Systems: The Gaia Methodology. ACM Transactions on Software Engineering and
Methodology, 12, 3, pp. 317-369. July 2003. Retrieved on March 5, 2007 from
http://www.cs.mu.oz.au/682/tosem2003.pdf
63
APPENDIX A
XML SCHEMA FOR FIPA ACLelement fipa-message
diagram
attributes Name Type Use act xs:NMTOKEN required conversation-id xs:ID
source <xs:element name="fipa-message"> <xs:complexType> <xs:choice maxOccurs="unbounded"> <xs:element name="receiver" type="receiverType"/> <xs:element name="sender" type="senderType"/> <xs:element name="content" type="contentType" minOccurs="0"/> <xs:element name="language" type="languageType" minOccurs="0"/> <xs:element name="encoding" type="encodingType" minOccurs="0"/> <xs:element name="ontology" type="ontologyType" minOccurs="0"/> <xs:element name="protocol" type="protocolType" minOccurs="0"/> <xs:element name="reply-with" type="reply-withType" minOccurs="0"/> <xs:element name="in-reply-to" type="in-reply-toType" minOccurs="0"/> <xs:element name="reply-by" type="reply-byType" minOccurs="0"/> <xs:element name="reply-to" type="reply-toType" minOccurs="0"/> <xs:element name="conversation-id" type="conversation-idType" minOccurs="0"/> <xs:element name="user-defined" type="user-definedType" minOccurs="0"/> </xs:choice> <xs:attribute name="act" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="accept-proposal"/> <xs:enumeration value="announcement"/>
64
<xs:enumeration value="cancel"/> <xs:enumeration value="cfp"/> <xs:enumeration value="failure"/> <xs:enumeration value="inform"/> <xs:enumeration value="not-understood"/> <xs:enumeration value="propose"/> <xs:enumeration value="refuse"/> <xs:enumeration value="reject-proposal"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="conversation-id" type="xs:ID"/> </xs:complexType></xs:element>
element fipa-message/contentdiagram
source <xs:element name="content" type="contentType" minOccurs="0"/>
element contentType/Announcediagram
65
source <xs:element name="Announce" type="AnnounceType"/>
element AnnounceType/IntendedTargetdiagram
attributes Name Type Use Default threatType xs:NMTOKEN required threatTo xs:string unknown
source <xs:element name="IntendedTarget"> <xs:complexType> <xs:attribute name="threatType" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="unknown"/> <xs:enumeration value="self"/> <xs:enumeration value="high-value-asset"/> <xs:enumeration value="escort"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="threatTo" type="xs:string" default="unknown"/> </xs:complexType></xs:element>
element contentType/AcceptProposaldiagram
attributes Name Type Use proposalID xs:string
source <xs:element name="AcceptProposal" type="AcceptProposalType"/>
element contentType/Canceldiagram
attributes Name Type Use Action xs:NMTOKEN required
source <xs:element name="Cancel" type="CancelType"/>
66
element contentType/CallForProposaldiagram
source <xs:element name="CallForProposal" type="CallForProposalType"/>
element contentType/Informdiagram
attributes Name Type Use Result xs:NMTOKEN required
source <xs:element name="Inform" type="InformType"/>
complexType InformTypediagram
attributes Name Type Use Result xs:NMTOKEN required
source <xs:complexType name="InformType"> <xs:sequence> <xs:element name="contractID" type="contractIDType"/> </xs:sequence> <xs:attribute name="Result" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="Joy"/> <xs:enumeration value="No-Joy"/> <xs:enumeration value="Abort"/> </xs:restriction> </xs:simpleType> </xs:attribute></xs:complexType>
element contentType/Proposediagram
67
attributes Name Type Use ProposalID xs:string required WeaponType xs:NMTOKEN required InterceptTime xs:double optional AcceptanceRequired
xs:boolean required
source <xs:element name="Propose"> <xs:complexType> <xs:complexContent> <xs:extension base="ProposeType"/> </xs:complexContent> </xs:complexType></xs:element>
complexType ProposeTypediagram
attributes Name Type Use ProposalID xs:string required WeaponType xs:NMTOKEN required InterceptTime xs:double optional AcceptanceRequired
xs:boolean required
source <xs:complexType name="ProposeType"> <xs:sequence> <xs:element name="PKill" type="PKillType"/> <xs:element name="TimeToKill" type="TimeValueType"/> </xs:sequence> <xs:attribute name="ProposalID" type="xs:string" use="required"/> <xs:attribute name="WeaponType" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="hard-kill"/> <xs:enumeration value="soft-kill"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="InterceptTime" type="xs:double" use="optional"/> <xs:attribute name="AcceptanceRequired" type="xs:boolean" use="required"/></xs:complexType>
element contentType/Refusediagram
attributes Name Type Use Action xs:NMTOKEN
source <xs:element name="Refuse" type="RefuseType"/>
complexType RefuseTypediagram
attributes Name Type Use Action xs:NMTOKEN
68
source <xs:complexType name="RefuseType"> <xs:sequence> <xs:element name="ThreatID" type="ThreatIDType"/> </xs:sequence> <xs:attribute name="Action"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="Announcement"/> <xs:enumeration value="Contract"/> </xs:restriction> </xs:simpleType> </xs:attribute></xs:complexType>
element contentType/RejectProposaldiagram
attributes Name Type Use ProposalID xs:string required
source <xs:element name="RejectProposal" type="RejectProposalType"/>
complexType RejectProposalTypediagram
attributes Name Type Use ProposalID xs:string required
source <xs:complexType name="RejectProposalType"> <xs:sequence> <xs:element name="DecisionCode" type="xs:int"/> </xs:sequence> <xs:attribute name="ProposalID" type="xs:string" use="required"/></xs:complexType>
69
APPENDIX B
DETERMINING THE RUN SAMPLE SIZE
Figure 11. Scenario A (No Coordination) Results With Varied Number of Runs
Results converge after approximately 80 runs.
70
Figure 12. Scenario B (With Coordination) Results With Varied Number of Runs
Results converge after approximately 120 runs.
71
APPENDIX C
THE NETSCHEDULER APPLICATION
The netScheduler application supports the evaluation of situation assessment algorithms
and engagement policies in multi-threat, multi-platform scenarios. The application’s object-
oriented design establishes an extendable framework for developing combat system models
and for conducting simulations. The simulation executes user-defined engagement scenarios
detailing the attack profile of anti-ship missiles, the configuration of surface platforms, and the
situations assessment and engagement policies applied.
The features supported by the tool include:
• Scenario Explorer - used to access editors and simulation features
• Engagement Scenario Editor - combines an attack scenario with a defence scenario
and establishes the type of policies and constraints used during simulation.
• Attack Scenario Editor - defines missile threats and associated information
establishing the attack profile.
• Defence Scenario Editor – defines the surface platforms and configures the
available weapon systems.
• Damage Assessment – establishes a simple probability model for disabling
systems in the event of a missile hit against own ship.
• Simulation Execution – provides control over simulation execution.
• Visualization Displays – includes Network-centric and Platform-centric views.
• Data Logging - records data and event information for post analysis
72
• Scenario Database - a central repository of all engagement scenarios, attack
scenarios, and defence scenarios.
The Engagement Scenario Editor
The Engagement Scenario Editor (see Figure 13) enables the user to create or modify an
engagement scenario. This involves the selection of an attack and defence scenario, choosing
platform-centric versus network-centric operations, choosing the type of planner (i.e., reactive
or baseline), and configuring thresholds used in situation assessment and engagement control.
The engagement scenario also contains simulation control information (i.e., random seed type,
number of runs, etc.).
Figure 13. The Engagement Scenario Editor
73
The Attack Scenario Editor
The Attack Scenario Editor (see Figure 14) enables the user to build a scenario consisting
of one or more anti-ship missiles. Missiles are added to the scenario and provided an initial
range and bearing with respect to the centre of origin. The missile information includes: Home-
On-Jam Search Type (Near-to-far or Far-to-near), acquisition mode (HVA, 1st in survey, 2nd in
survey, 3rd in survey), range at which to activate the missile’s seeker, and the simulation time of
insertion. Variances can also be added to range, activation range, and insertion time.
The attack scenario also enables the user to specify missile characteristics such as speed,
turning rate, and seeker lock-on cell-size. This provides a rudimentary ability to model specific
missile types. Lastly, the attack scenario indicates the wind speed and direction (relative to true
north) that will be applied during the simulation.
Figure 14. The Attack Scenario Editor
74
The Defence Scenario Editor
The Defence Scenario Editor (see Figure 15) enables the user to build a scenario
consisting one or more naval platforms. To add a platform the user must enter a platform name,
select the type of platform (i.e., surface combatant, HVA, HVA-combatant, or non-combatant),
indicate the initial range and azimuth from the centre of origin, the size or hit radius of the
platform, and the initial speed and course. The user can then configure the platform for weapon
systems.
In addition to specifying platforms, the user can indicate default priorities for a layered
defence strategy. Note the engagement scenario overrides the defence scenarios priorities based
on the user-selected engagement policies contained in the engagement scenario. The defence
scenario also contains values used to introduce operational delays thereby approximating the
operator response times for specific situations.
Figure 16 illustrates the weapons configuration dialog displayed when the user elects to
configure a platform for defence. The dialog allows the user to enable/disable weapon systems,
identify weapon-specific delays and engagement ranges, and provide damage assessment data.
Some weapons and fire control radars also allow the allocation of zones where the system is
unable to operate (blind-zones).
Hard-kill weapon systems also accept salvo information such as salvo size, hits required
for kill, hit probability, and projectile speed.
75
Figure 15. The Defence Scenario Editor
76
Figure 16. Weapons Configuration Dialog
Simulation Execution
Simulation execution allows the user to specify a simulation series and monitor the
execution of that series (see Figure 17). The series is saved to the log directory using the
engagement scenario name and the series name provided by the user. A tabular display
captures the summary results of each simulation execution. The results include the random
seed, the total simulation time, the weapon system status and remaining inventory, as well as
the number of missile hits, misses, kills (hard-kill and soft-kill), and engagement outcomes
(successes, failures, and aborts).
77
Figure 17. Simulation Execution Window
Where a particular simulation run reveals unexpected results, that run can be repeated by
providing the random seed to the engagement scenario and executing the engagement scenario
using the preview mode.
The preview mode allows engagement scenarios to be viewed through the visualization
displays as part of scenario creation or on playback of a particular simulation run.
Visualization
Visualization supports a network-centric view and a platform-centric view. The network-
centric view (see Figure 18) contains a polar display of the engagement scenario, missile status
information, and the coordinated response, if applicable. A platform-centric view is created for
78
each platform specified in the scenario. The platform-centric views created for the task force is
visible on the network-centric display as tabs.
Figure 18. Network-Centric Visualization
The platform-centric view consists of a status view, Figure 19, and a C2 view, . The status
view contains system track information and weapon status. The C2 view displays the reasoning
used by the planner for weapons selection as well as the engagement status. Both views
provide a TTG display that shows status information including the missile’s ranking relative to
its TTG as determined by the given platform. The minimum and maximum TTG boundaries
79
drawn in the TTG display is set by the engagement ranking policies defined in the engagement
scenario.
Figure 19. Platform-Centric Visualization (Status View)
80
Figure 20. Platform-Centric Visualization (Command & Control View)
The Simulation Architecture
The fundamental architecture of the netScheduler application was provided in Figure 6.
This section adds to that description by outlining the simulation’s propagation cycle and the
state machines governing the behaviour of the primary classes.
The Simulation Controller (SimController class) uses the simulation propagation
cycle (see Figure 21) to control simulation execution. The Simulation Controller issues
Advance messages to each of the platform objects (i.e., Vessel, Missile, and
ChaffCloud classes).
81
Figure 21. Simulation Propagation Cycle
A Missile advances its position based on the missile state machine given in Figure 22.
With the exception of the HIT or HARD-KILLED states, the Missile advances its position at
each propagation cycle and checks if its position has intersected that of a surface vessel. State-
specific activities are performed as shown in Figure 22.
The Vessel hosts the Sensor Manager and the Weapons Manager. The Sensor Manager
updates system track data based on ground-truth data. Note Sensor Manager updates occur at
irregular intervals and lag behind the Missile’s true updates as an approximation of sensor
input. The Sensor Manager calculates additional information during these update intervals
producing range and heading rates, Closest-Point-of-Approach (CPA) data, and Estimated
Time of Arrival (ETA) data. It is the calculated information that determines the threat ranking
and prioritization of each system track.
82
Figure 22. Missile State Transition Diagram
The Missile status determines the system track status wherein operational time delays are
used to approximate system and operator processing. For example, the Sensor Manager cannot
report that a Missile has locked-on until the Lock-on Report delay has transpired. Similarly, the
Sensor Manager will not report the kill or hit of a missile until the Hard-Kill Report delay has
been processed.
On each Advance cycle of the vessel, the Weapons Manager performs the activities given
in Figure 23. The reactive planner evaluates each threat based on the prioritization of the
system track. As part of this evaluation, the Weapons Manager determines if a weapon
assignment is required. If required, the Weapons Manager searches for available weapon
systems for candidates and selects the candidate with the highest probability of success.
83
Figure 23. Weapons Manager Propagation Cycle
The deliberative planner performs weapon assignments based on mission needs. Plans are
formulated during the mission identification, its execution, or its review based on the role of
the Weapons Manager. The formulation of plans uses the same candidate selection process as
the reactive planner. An Engagement (Engagement class) object advances the Weapon state,
Figure 24, as part of engagement control. While Engaged the weapon will inform the
Engagement object of salvos fired and the probability of hit. The Engagement object informs
the targeted missile of each successful salvo.
The Weapon class hierarchy provides the Weapons Manager and Engagement object with
the ability to interact with any type of weapon system. Figure 25 illustrates the Weapon class
hierarchy.
84
Figure 24. Weapon State Transition Diagram
Figure 25. Weapon Class Hierarchy
85