An Agent-Based Modeling Approach to Creating More
Resilient Littoral Combat Architectures
James Behmer, Kolawole Ogunsina, Parth Shah, Suhas Srinivasan
School of Aeronautics and Astronautics, Purdue University
West Lafayette, IN, USA
Email: jbehmer@purdue.edu, kogunsin@purdue.edu, shah66@purdue.edu, suhas@purdue.edu
Abstract—Littoral combat is a critical component of naval war-
fare that has gained importance since the late 20th century due
to a shift from matched blue-water combat to agile, asymmetric
warfare near the coast. With the increased relevance of this
type of naval combat, the ability of a networked naval warfare
System-of-Systems (SoS) to operate effectively given the chal-
lenges of operations in the littoral zone becomes imperative.
Resilience in an SoS in the face of a variety of threats is vital.
These threats may take various forms: traditional warfare,
cyber attacks, or communications breakdowns. The challenge
for any SoS practitioner is identifying such architectures from a
vast design space. We define an architecture as the constituent
systems in the SoS and the connections among these systems.
We seek to apply an agent-based modeling approach to create an
architecture evaluation tool that leverages the modular nature of
an SoS to quickly conduct trade studies and analyses to identify
architectures that are resilient to a variety of threats. The
simulation tool is built on the principles of the Open Systems
Architecture put forth by the Department of Defense (DoD). We
present an analysis that seeks to find a suitable SoS architecture
configuration that maintains operability and performance dur-
ing the loss of command authorities. This loss can be attributed
to battle casualties or other forms of threats including commu-
nications failures. We demonstrate that distributing managerial
control in the architecture improves, to some extent, SoS perfor-
mance in terms of time to threat elimination. This single analysis
demonstrates how SoS practitioners can use agent-based models
to quickly construct and evaluate potential architectures against
a variety of threats and disruptions, ultimately building resilient
SoS architectures that perform to prescribed levels even in the
face of network failures and attacks.
TABLE OF C ONTENTS
1. I NTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2. B UILDING THE M ODEL . . . . . . . . . . . . . . . . . . . . . . . . . .
3. A NALYSIS - A RCHITECTURE P ERFORMANCE . . .
4. R ESULTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5. C ONCLUSION , S UMMARY AND F UTURE D E -
VELOPMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1. I NTRODUCTION
Designing a suitable System-of-Systems (SoS) architecture
poses strong challenges owing to the need to balance the
independent managerial control of constituent elements as
well as their operational interdependence. To gain a better
idea of what makes SoS architecture design challenging, it
may be necessary to understand what constitutes an SoS and
how it differs from a system. A system is defined by Gibson
et al. in [1] as “a set of elements so interconnected so as to aid
in driving toward a defined goal.” In comparison the Defense
Acquisition Handbook (DAG) (2008)[2] seeks to describe an
SoS as “a set or arrangement of systems that results when
978-1-4673-7676-1/16/$31.00 2016
c IEEE
independent and useful systems are integrated into a larger
system that delivers unique capabilities.” Additionally, the
following characteristic traits were proposed by Maier [3] to
aid in identification of what might distinguish an SoS from a
monolithic system:
Operational Independence Constituent systems may have
their own tasks to fulfill outside of the context of the SoS.
Managerial Independence Units may have a unique tasking
by their respective operators/owners.
Some heuristics were also proposed in [3] on the effective ar-
chitecture of SoS namely the concept of stable intermediate
forms– the SoS must be able to perform its functions even
if not at its complete/optimal configuration, policy triage–
the designers need to exact just the right amount of control
over the model design, leveraging at the interfaces– with
the components having their own independence the design of
the SoS boils down to how they communicate with each other,
and finally ensuring cooperation among the constituent sys-
tems. Keeping these in mind, we aim to look at the premise
of littoral combat from an SoS perspective.
Context and Motivation
The term ‘Littoral Combat’ refers to naval engagements close
to the shoreline generally in support of or related to amphibi-
ous operations. While by no means a new aspect of naval
warfare2 it has gained increased relevance in the late 20th and
21st century. This could possibly be due to a shift from evenly
matched blue-water engagements to a more asymmetric form
against smaller or non-state actors. This could make an
already challenging scenario all the more difficult especially
1 when one considers the possibility of civilian traffic in the
2 same waters.
5
6 To realize this increased relevance, the US Navy has com-
missioned the Freedom[5] and Independence[6] classes of
7 Littoral Combat ships (LCS). Along with the ’Sea Lance
System’ [7] the LCS is expected to feature prominently in
the Navy’s future engagements. In this context, our proposed
objective is to develop a model and simulation for potential
littoral engagements that implements both directed and ac-
knowledged forms of managerial control. The acknowledged
variant of the SoS would require that subsystems maintain
their own management akin to the SoS. This should ensure
cooperation among subsystems as each is now incentivized
to perform more effectively.
Our motivation for this project is the belief that a major
challenge for a littoral combat naval warfare SoS is the
2 Notable examples include the Gallipoli landings(1915), the invasion of
Normandy (1944), and the invasion and counter-invasion of the Falkland
Islands (1982)[4].
1
 Table 1. ROPE Table for the proposed SoS 2. B UILDING THE M ODEL
Agent-Based Modeling
Levels Resources Operations Policy Economics
α Sensors, Commun- Communi- Unit Systems-of-systems and large-scale complex systems such as
Con- icate with cations Operat- the stock market are difficult to model analytically due to the
trollers, other Rules ing and complex nature of interactions among constituent systems.
Com- agents to Training Additionally, the observed behavior in these systems adheres
manders, generate Cost to the notion, “the whole is greater than the sum of its
Weapons a threat parts”. Agent-based modeling (ABM) strives to capture
map the complex behaviors using a bottom-up approach where
individual systems in the SoS are expressed as agents in the
β Platforms: Maneu- Rules of Mainte- model. This approach provides a more natural description
LCS, vering engage- nance of the system, is flexible, and captures emergent phenomena
Aircraft, and ment and that an SoS practitioner would be most interested in[9]. An
Sub- engaging operating agent model receives information from the environment and
marines targets costs acts using a set of internal rules and principles. These basic
principles are replicated for all agents in a system. Axtell
γ Theater Deploy- Strategic Defense identifies three potential cases where agent-based modeling
Com- ment Policy, Budget can be beneficial[10]:
mand deci- Order of
Authority sions, site Battle 1. The model can be expressed using analytical means. In
planning this case, the agent-based model can serve to verify the results
obtained from analytical means. This however is not the most
effective use of agent-based modeling and is rarely employed.
2. The model can only partially be expressed analytically.
In this case, a numerical agent-based model can help comple-
ment the analytical expression of the system to obtain a result
decentralization of Command & Control (C2 ). If all control that is otherwise unattainable.
of the SoS is delegated to one unit (for example a single 3. The model is intractable. This case is especially true in
LCS), the risk of complete system failure would be very large-scale complex systems. Using an agent-based model
high if that particular system is removed from the scenario. can give insight into key behaviors and a better understanding
Distributing control among similar C2 capable systems might of the system as whole.
help mitigate this risk. This shift in control is also in line
with the US Navy’s initiative to move towards a net-centric Case #3 is directly applicable to SoS as it is difficult to capture
warfare (NCW) model as described by its four tenets [8]: the independent behaviors of each individual system and the
interactions among them. Additionally, many different types
of agents can easily be constructed by changing internal
1. Robust networking improves information sharing parameters that govern how they make decisions. This makes
2. Collaboration and information sharing improves the qual- ABM particularly well-suited for littoral combat applications
ity of data and shared situational awareness where an SoS practitioner as able to perturb specific agent
3. Shared situational awareness enables self-synchronization parameters or methods from a baseline and observe the im-
4. Which leads to an increase in mission effectiveness pact on overall performance. The advantages of ABM in this
domain do not render other methods (e.g. system dynamics,
model-based systems engineering) ineffective. In the realm of
Table 1 shows our layout of the hierarchy of constituent
systems (Resources), their functions within the context of
the SoS (Operations), their controlling rules (Policy) and the
Economics of operation.

In this project, we look at networking multiple β level plat-

forms to produce architectures with different properties.The
architecture design spectrum adopted from [3] is divided as
follows

Directed Constituent systems participate solely to fulfill SoS

objective.
Acknowledged Constituent systems help accomplish SoS
goals, but systems maintain independent objectives as well.
Collaborative Constituent systems contribute voluntarily to Figure 1. An example BMDS scenario illustrating potential
achieve SoS objective platforms
Virtual No central authority or clear SoS objective and all
systems are not always known
defense, a few distinct platforms exist that can be represented
Our main focus is the transition from a Directed to a more by discrete agents in a simulation. Per the Department
Acknowledged architecture and a comparison between them. of Defense Architecture Framework (DoDAF) definition, a
The setup is explained in Section 2 and the performance platform is “a physical structure that hosts systems or system
comparison in Section 4 hardware or software items”[11]. The need to distinguish
2
between a platform and agent will become evident in the
following section. Consider the notional defense scenario
shown in Figure 1. An enemy threat is launched and detected
by ground and space based sensors. Once all tracking require-
ments are met, an interceptor can be launched to intercept
the threat at a future time. This scenario can be represented
by four distinct platforms containing several agents that
perform critical functions that allow a platform to function
as desired. The combination of these platforms and the
interactions among onboard agents construes an architecture.
For example, at minimum, the space-based radar platform
must contain a sensor (agent) that gathers measurements from
its surroundings. Additional onboard agents can leverage the
measurements to estimate a track for a detected threat or the
raw measurements can be relayed to other platforms. Often
times, space-based assets can also serve as communications
relays to other platforms. The following section discusses the
Discrete Agent Framework, an ABM modeling framework
used for TRITON.
DAF
Numerous agent-based modeling tools exist to simulate large-
scale systems. Net- Logo, Swarm, MASON, and Repast are
just a few examples of ABM tools available to any designer.
These tools employ a framework and library paradigm [12]
that provide a framework to design the agent-based model
and a library of tools to implement the design. Discrete Agent
Framework (DAF) is an agent-based modeling tool developed
and maintained at Purdue University’s System-of-Systems
Laboratory [13]. DAF is built on the Open Systems Architec-
ture (OSA) approach, which emphasizes code flexibility and
openness [14] and possesses many unique characteristics that
make it useful in modeling SoS problems. Built in object-
oriented MATLAB, DAF provides a generic class of methods
and functions that can support domain-specific applications3 .
DAF can be broken into four main components: agents,
platforms, messages, and architecture structure. By default,
only one agent exists in DAF as it serves as the foundation for
domain- specific applications to allow developers to create
their own agents. Agents are initialized as new classes that
inherit base properties and methods from the DAF base agent
class. Other agents can access some of these properties and
methods while others are private. An agent in DAF contains
methods and properties that perform a specific function on a
platform. Platforms in DAF are a physical instantiation of a
group of agents. DAF is capable of executing the methods
on all agents and platforms at discrete time intervals, but can
also trigger execution based on messages. Messages in DAF
dictate how information flows among agents. DAF supports
two types of messages: broadcast and directed. Much like
agents, no specific DAF messages exist, but developers are
able to leverage DAF to create messages that are domain-
specific. Once a message structure is specified, agents can
send and receive messages, effectively communicating as
they would in an SoS application. Additionally, agents can
be restricted to receive only certain types of messages and
latency models help simulate the real-world delay associated
with information transfer between two agents. Agents in
specific applications are often reactive in nature and thus
only execute when input is provided. This behavior can be
mimicked in DAF by dictating that agents execute only when
messages are received.
Finally, an architecture in DAF is formed by defining which
3 An in-depth analysis of DAF and its structure falls out of the scope of
this work. For a more detailed analysis, please refer to Fry, Campbell,
DeLaurentis, 2015 [14]
3
Figure 2. Potential DAF Architecture
agents are connected to each other. A link allows agents
to communicate and limits the interaction solely to those
agents that are connected to one another and performance
hinges on how the architecture is built. Figure 2 illustrates
a potential architecture that can be created using DAF. Three
distinct platforms have agents that serve distinct functions.
The arrows indicate links among agents governing how in-
formation flows in the architecture. Additionally, the ar-
chitecture can easily be modified to include new agents or
even redistributed to change information flow. One of the
most attractive features of DAF is the ability to evaluate
many different architecture options quickly which makes it
a tractable modeling framework for our application.
TRITON
TRITON was created as a tool that uses DAF’s existing
framework for agent based modeling. Our model is devel-
oped to look at changing communication architectures and
DAF provides a suitable method for that by having reac-
tive agents activate upon receipt of messages. In essence,
the content of these messages between agents, their routing
comprises our idea and implementation of communication
architecture. The model was designed in a manner conform-
ing to the strategy outlined in Table 1. The base agents
(sensors, weapons, controllers) at the α level are grouped
into different classes of β level platforms (Submarine, At-
tack/Recon aircraft and LCS) referred to as the ‘units’ in the
simulations. It should be noted that while there are three main
classes of platforms, they all bear base properties that can be
customized a priori to represent either an air, sea or sub sea
unit. Additionally, many of our candidate metrics– outlined
in Table 3 in Section 3 use the time to major events within the
simulation to characterize SoS performance.
ABM uses different types of agents, which make up different
types of platforms, in an attempt to identify patterns in their
behavior. Our model uses the following types of agents:
Commanders : process threat information; send orders; carry
out orders
Controllers : relay threat information to commanders; carry
out orders
Sensors : identify threats and send information to controllers
or commanders
Each platform in our model consists of a sensor and either a
commander or a controller. Our platforms and the motivation
 Table 2. Generic Platform Properties
Platform Type Properties
Speed :30kts
Submarine pkill :0.9
Model Basis :Los Angeles
Class
Armament :ASM, Torpedoes
Speed :50kts
Littoral Com- pkill :0.2
bat Ships Model Basis :Independence
Class
Armament :ASM, SAM, Tor-
pedoes
Speed :500kts
Aircraft pkill :0.44
Model Basis :F/A-18 E/F
Armament :ASM,AAM
for their design are listed in Table 2.
In addition to these, two single-role platforms are defined,
namely the anti-ship mines and mine sweeping platform.
The mine sweeping platform is based on the MH-53E Sea
Dragon platform [15] and the anti-ship mines are based on the
Stonefish influence mine [16]. In this scenario, the mines are
deployed by the red force and the MH-53E mine sweeper by
the blue force. This arrangement allows for more metrics to
measure effectiveness – the percentage of simulations where
all mines are destroyed (Figure 8 and Equation 1) and the
average destruction per simulation (Figure 9 and Equation 2).
Further details are described in Section 4
Because agent interfaces define the baseline of the model,
agents can quickly be added or removed as either comman-
ders or controllers. Furthermore, agents can easily be re-
wired to represent different networks. This modularity is
critical during the analysis phase for it allows us to test
multiple network configurations.
Modeling Assumptions
In order to build a suitable model that captures desirable
dynamics of the SoS while being modular and computation-
ally simple, some assumptions are made. Although these
assumptions would not hold in a real-life scenario we believe
them to be reasonable enough to make modeling possible
without ruining the integrity of our results.
Weapon dynamics are modeled probabilistically using range,
weapon type, and the target platform’s expected defen-
sive/evasive capability. Each platform is capable of carrying
a mix of one or more of Anti-Ship Missile (ASM), Torpedo,
Surface-to-Air Missile (SAM), and Air-to-Air Missile types.
Depending on the currently targeted threat, the appropriate
platform is tasked to engage it with the suitable weapon
type. The effectiveness of the engagement is modeled as a
Total Kill Probability (tpk). Clearly tpk would be smaller
for a target further away. This is compounded by the
weapon accuracy and defensive capabilities of the target.
The calculated value of tpk is compared against a randomly
generated threshold value (0, 1] to account for the chance that
an engagement may succeed in difficult conditions as well as
it failing under very good conditions.
The sensor effectiveness is similarly modeled. Given a ball
4
around the sensor’s range, the detection capability (pDetect)
is modeled as a Gaussian surface centered at the platform’s
location at each instance.
 
−(distance2 )
pDetect = exp
2 × Sensor Range
This too is compared against a randomly generated threshold
to account for unmodeled dynamics that might affect the
sensor’s detection of a threat. Additionally the following
assumptions are made:
• Red forces move only when provoked
• A platform is disabled and removed from the simulation if
hit by a weapon
• Platforms hold constant altitude when maneuvering
• All messages are relayed at equal cost
• Messages between platforms never fail to send
• Sensors have full field of view
Networking, Architectures
The network architectures used in the analysis of the littoral
combat scenario of the Falklands War [17] are discussed in
this section. According to Maier, operational and managerial
independence are vital in establishing the uniqueness of an
SoS network architecture [3]. In this vein, three network
architectures namely Directed, Acknowledged and Mixed
architectures are adopted, based on their operational and man-
agerial form of control, in modeling the littoral combat sce-
nario. Currently, most integrated defense systems, especially
those involving naval warfare, utilize a strictly directed SoS
architecture as their main form of managerial control. The
component systems are designed and centrally regulated such
that they carry out specific tasks geared towards the overall
goal of the SoS [3]. However, a directed architecture runs a
high risk of being overly controlling, and this may dissuade
existing or potential subsystems from effectively fulfilling
their roles in the SoS. An acknowledged SoS architecture
comprises of constituent systems that help to accomplish the
SoS goal, but the systems maintain their own management
and authority akin to the SoS. This ensures cooperation
amongst subsystems, as each subsystem is incentivized to
perform efficiently with the knowledge that its successful
operations ultimately benefit the SoS. The mixed architecture
combines the properties of both directed and acknowledged
architectures [3].
We focus our efforts on defensive littoral combat site plan-
ning, which includes two separate force (red and blue)
compositions. The attacking red force maintains a constant
network configuration in the analysis as shown in Figure 3,
with 2 commanders and 10 controllers representing a strictly
directed SoS network architecture. Two of the four littoral
combat ships (LCS) are command and control (C2 ) agents,
with each C2 agent having a connection with three of the
six attack aircraft (AA), one LCS, and both submarines in
the SoS network. The red force network loses half of its
effectiveness if one of the C2 agents is destroyed. Hence, the
C2 s in the network exhibit high levels of situational aware-
ness to maintain adequate red force effectiveness. While
the blue force composition remains constant, the links and
number of C2 agents within each platform change to allow for
the network architecture evolution. Figures 4,5,6 represent
the directed, acknowledged, and mixed network architectures
for the defending blue force respectively. The directed blue
force network consists of two LCS, three attack aircraft, one
reconnaissance aircraft (RA), and one submarine. However,
 Figure 3. Red Force Architecture Figure 5. Acknowledged Blue Force Structure

Figure 4. Directed Blue Force Structure Figure 6. Mixed Blue Force Structure

objective is to design an SoS for littoral combat site planning,

one of the two LCS is a C2 agent directly connected to the we decided to use reachability to define our metrics. Three
remaining assets in the network. The C2 (LCS) agent has metrics are used in the model:
complete operational control of the SoS, and its elimination
results in zero network effectiveness. The acknowledged
blue force network composition is similar to the directed one, 1. Time to Threat Elimination
except that both LCS, the submarine, and the reconnaissance 2. Number of Red Force (attacking force) platforms remain-
aircraft are all C2 agents. This reduces the susceptibility of ing
the SoS network to point failures as operational control is 3. Number of Blue Force (defending force) platforms re-
distributed among all four C2 agents. Finally, the mixed blue maining
force architecture and acknowledged blue force architectures
are compositionally similar and contain the same number of As stated earlier in Section 1 our goal for the development
C2 agents. However, the C2 agents in the mixed architecture of TRITON is to assess the effectiveness of shifting from a
are less connected to other assets in the SoS network, result- directed architecture to a more acknowledged state on the
ing in a lower level of situational awareness for the command combat resilience of the ‘blue’ force. We’ve mentioned
and control agents. previously in Section 2 that the variable being controlled
for the analysis is the set of interfaces between platforms
for the blue force, replicating the shift from directed to
3. A NALYSIS - A RCHITECTURE
P ERFORMANCE Table 3. SoS Metrics
Approach and Analysis Set-up
Before choosing a modeling approach it is important to Meta-Metric Area SoS Metric
develop a pool of metrics to be measured by our computer Reachability Average time to threat
elimination; time to first
model. These metrics are used to form a rudimentary hy- threat detection
pothesis concerning the behavior of the SoS. The most low- Robustness Time to recognize failure,
level, bare bones metric area is reachability. Reachability where failure is defined as
determines our SoS ability to identify the best performance a percentage of assets elim-
configuration with the given constraints: rules of engage- inated; Recover from nodal
ment, bandwidth, firepower, and mobility. The next area con- failure (resiliency)
cerns uncertainty and is called robustness. The main source Scalability Ratio of time to threat elim-
of uncertainty is nodal failure. If a subordinate system fails ination vs cost of oper-
(i.e. destroyed by enemies), a robust SoS will quickly identify ation; Probabilistic threat
this fact and allocate resources accordingly. In regards to detection based on thresh-
efficiency, scalability can help maintain costs at a level just old (conservatism)
high enough to deal with threats. This is an important area Versatility Ability to adapt to differ-
in minimizing cost. Our SoS must also be applicable to ent types of threats; Change
the general coastline. Therefore, versatility is critical not in threat elimination time
necessarily within a specific conflict, but throughout various over multiple coastal battle
conflicts at different geographical locations. Table 3 summa- spaces
rizes candidates for littoral warfare SoS metrics. Since our
5
acknowledged architectures. This boils down to deciding
which platforms have C2 authority and which platforms the
C2 platforms command.
Each run of the tool covered 2000 seconds of simulation
time in approximately 25 minutes. This experiment was
repeated 150 using Monte-Carlo methods totaling to 48 hours
of computing time. Although the model performs well for
our purposes, there is room for significant improvement with
regards to the computational cost. One thing that becomes
apparent is that the C2 units in more acknowledged struc-
tures can get by with lower situational awareness owing to
other similarly capable units operating semi-independently
and directing their subordinate controllers (and platforms) to
multiple threats.
Asset Placement
Figure 7. Asset Placement in the Scenario Zone
The location chosen for our scenario zone was the Strait of
Juan de Fuca that straddles the border between the USA and
Canada on the west coast. Our reasons for choosing this
are twofold. The first reason being that it provides a good
representation of potential real world operating locations.
The strait appears to be a route of movement for assets
stationed at the Bremerton and Kitsap-Bangor naval bases.
Secondly, the operating zone seems to be fairly uncluttered
in landmasses in and around the area of movement of the
platforms. This is important to us as TRITON does not yet
include capabilities for the platforms to detect and maneuver
against landmasses. Figure 7 shows an example of how the
forces will be laid out. Figure 7 also shows the architecture
types of the red and blue forces for the directed architecture
simulations.
4. R ESULTS
This investigation strives to assess the effectiveness of dif-
ferent blue force architecture types (directed, mixed, and
acknowledged) against a static red force composition. Each
simulation contained 40 mines (modeled after Stonefish
mines). In addition to the three metrics (Time to threat
elimination, red and blue forces remaining), the number of
mines destroyed in each simulation serves as an analog to
assessing architecture effectiveness. With added command
authorities (C2 capable platforms) the MH-53E helicopter can
receive additional tasking commands to remove mines. This
notion suggests that added situational awareness (in more
mixed and acknowledged architectures) would maximize the
number of mines destroyed in the simulation. Figure 8
shows the percentage of simulations where all 40 mines are
eliminated as captured in Equation 1.
6

Sims. All mines destroyed
Complete Destruction = (1)
N Simulations
Somewhat counter intuitive is the behavior seen where the
mixed SoS combat architecture destroys all 40 mines more
often than the acknowledged architecture. Figure 9 analyzes
this result one level deeper by examining the average de-
struction across all simulations. For each architecture type,
50 Monte Carlo simulations where used to average out the
probabilistic calculations in the simulation (Equation 2).
N
i=1Mines destroyed
Average Destruction = (2)
N Simulations
Unlike Figure 8, in this decomposition, we see the behavior
adheres to the initial suspected behavior that average de-
struction increases when moving to a more acknowledged
state. Correlating back to the meta-metric areas discussed
in the prior sections, this behavior speaks to the robustness
of the SoS architecture. By including more C2 authorities,
more mines are destroyed on average, but at the cost of
reduced situational awareness. This can become costly when
considering the dynamic nature of littoral combat. Consider
a situation where two commanding authorities hold engage-
ment orders for a singular aircraft platform. Conflicting
engagement orders can potentially reduce the effectiveness
of the platform. If the order from Commander A asks the
aircraft to move away from a potential target with engage-
ment probabilities at time t1 and Commander B asks the
target to return shortly after, a split second deviation can
potentially nullify the more promising engagement. The
analysis team suspected such a case when considering why
the mixed architecture displayed more complete destruction
of mines compared to the acknowledged architecture.
Figure 8. Percent of Simulations where all mines are
destroyed
These two figures offered a glimpse into the static effec-
tiveness of the architecture at the end of the simulation,
but does not speak to the effectiveness of the architecture
over the duration of the simulation. Figure 10 displays the
blue force, red force, and mine fraction as a function of
both time and architecture type. The directed architecture
structure is represented using circle markers, mixed with
square markers, and acknowledged with x markers. Several
interesting behaviors are seen from this decomposition of the

Figure 9. Average Destruction per Simulation
data. There is increased blue force survival when transition-
ing to a more Acknowledged SoS architecture, potentially
due to the presence of more command capable units in the
architecture overall. Additionally, the increased blue force
survival is complemented by a decreased red force survival
or increased red force destruction. The mixed and acknowl-
edged architectures perform comparably as approximately
60% of all red force platforms are destroyed by the end of
the simulation as compared to 30% destruction in a directed
SoS architecture. As noted from Figures 8 and 9, there is
increased mine force destruction when transitioning to a more
Acknowledged configuration.
Figure 10. Force Composition over Simulation Time
This figure supports the initial notion that shifting to a more
Acknowledged SoS architecture will yield a decrease in the
average time to threat elimination as well as increased blue
force survival.
5. C ONCLUSION , S UMMARY AND F UTURE
D EVELOPMENT
Hearkening back to the original goals presented in this
paper, TRITON strives to model and build more resilient
7
littoral combat architectures using an agent-based modeling
approach. The authors believe that the results shown illustrate
the capability of TRITON in its infancy and also reveal many
avenues for exploration and development. The modular,
adaptable nature of the software tool offers SoS practitioners
a top-level modeling tool to analyze the effectiveness of po-
tential architectures quickly. Potentially viable architectures
identified using TRITON can then be evaluated using higher
fidelity simulations. Often, a goal of agent-based modeling is
to identify emergent behavior from the simulation. Emergent
behavior is seen only when analyzing the interactions among
agents rather than pairing the agents together themselves.
The authors find it enticing to claim emergence regarding the
behavior seen in the analysis, but it is premature given the ma-
turity of the software tool TRITON. Moving forward, several
potential avenues have been identified for development:
Sensor FOV/FOR + Intelligent Tasking Algorithms
Currently all sensors are omni-directional and capable of
detecting enemy platforms provided they fall in the specified
sensor range. By imposing field-of-view (FOV) and field-of-
regard (FOR) limits in conjunction with intelligent tasking
algorithms, the authors hope to see the effects of slewing and
other congestive effects as multiple threats pass with a single
sensor’s FOV/FOR.
Ballistic/Seeking Missile trajectories
In it’s current state, engagements fly a straight line course to
an intended target utilizing it’s current position, rather than
projecting a future location. The authors hope to imple-
ment seeking trajectories to reflect the capabilities of existing
fielded missiles.
Intelligent avoidance maneuvering
All platforms, regardless of terrain or obstacles adopt a short-
est distance approach to target. This behavior is not reflective
when considering that submarines may pass through mine
fields and other obstacles in littoral waters. By implement-
ing intelligent movement algorithms, the authors hope that
simulate more robust engagements.
Engagement Plan Updates
Related to seeking trajectories, engagement plan updates
allow platforms to reassess the scenario prior to executing
engagements. Often, due to the dynamic nature of the battle
space, platforms will no longer be engageable based on the
initial estimate. By updating the engagement plan at multiple
time steps, faulty engagements can be eliminated from the
simulation.
ACKNOWLEDGMENTS
The authors would like to thank their professor, Daniel De-
Laurentis for his unwavering support and guidance. TRITON
was initially built as a final course project for AAE 560 -
System-of-Systems Modeling and Analysis taught at Purdue
University. Using the concepts and modeling principles
taught in the course, TRITON evolved to its current state and
will continue to evolve.
 B IOGRAPHY
James Behmer is a Member of the Tech-
nical Staff at the Aerospace Corporation
in El Segundo, CA. Jim recently com-
pleted an internship at the Commercial
Spaceflight Federation in Washington,
D.C. where he wrote space policy briefs,
supported meetings on Capitol Hill and
with various government agencies, and
assisted with the advocacy of commer-
cial spaceflight. Prior to CSF, Behmer
spent four months at SpaceX supporting Falcon 9 second
stage engine tests. He also has flight test and systems en-
gineering experience through internships with Boeing Com-
mercial Airplanes in Seattle and Rockwell Collins in Cedar
Rapids, IA. Jim holds Bachelor’s and Master’s degrees in
Aeronautics and Astronautics from Purdue University.
Kolawole Ogunsina was admitted to
Obafemi Awolowo University, Nigeria
to study Electrical and Electronic En-
gineering at age fifteen. Driven by his
passion for innovation in aviation, he
transferred to Embry Riddle Aeronau-
tical University, Daytona Beach FL to
study Aerospace Engineering and grad-
uated with a Bachelor of Science de-
gree in May 2014. Kolawole worked as
an intern at Gulfstream Aerospace Corporation and South-
west Airlines during his undergraduate education. At the
Southwest Airlines Flight Operations Engineering (FLOE)
department, he developed One Engine Inoperative proce-
dures that increased the Maximum Takeoff Weight (MTOW)
capacity of the Boeing 737 fleet, which translated to airlifting
three to twenty six additional passengers. In recognition of
his exceptional support to the flight operations engineering
department, he was presented with the Southwest Airlines
Outstanding Performance Award. He is currently pursuing
a Master of Science degree in Aeronautics and Astronautics
Engineering at Purdue University. His primary research area
is in Aerospace Systems; specifically, appraising the impact
of airline operations and competition on future environmental
emissions.
Parth Shah is currently pursuing a
Masters of Science at Purdue Univer-
sity under Professor Daniel DeLauren-
tis in system-of-systems. His research
interests are architecture asset selection
using portfolio optimization and regres-
sion techniques, agent-based modeling,
and system-of-systems applications in
the defense domain. He graduated from
Purdue University in May 2014 with a
Bachelors of Science in Aeronautical/Astronautical Engi-
neering. He has held several internships in industry with GE
Aviation, The Boeing Company, and NASA.
8
Suhas Srinivasan completed his Bach-
elor of Engineering in Mechanical En-
gineering at NIT-Trichy, India in 2014.
He is currently pursuing an MS in Aero-
nautics & Astronautics at Purdue Uni-
versity, Indiana specializing in Dynam-
ics and Control and Systems Engineer-
ing, focusing on nonlinear control tech-
niques and design optimization. His pri-
mary area of interest is in the guidance
and control of Unmanned Aerial Vehicles and is currently
working on GPS-denied navigation and localization of Un-
manned Systems.
R EFERENCES
[1] J. E. Gibson, W. T. Scherer, and W. F. Gibson, How
to Do Systems Analysis. Hoboken, NJ, USA: John
Wiley & Sons, Inc., may 2007. [Online]. Available:
http://doi.wiley.com/10.1002/9780470130599
[2] O. A and T. Sse, Systems Engineering Guide for
Systems of Systems, 2008, vol. 36, no. August. [Online].
Available: http://www.acq.osd.mil/se/docs/SE-Guide-
for-SoS.pdf
[3] M. W. Maier, “Architecting Principles for Systems-of-
Systems,” Systems Engineering, vol. 1, pp. 267–284,
1998.
[4] D. Wheeland, “Synchronization of Littoral Operations,”
Naval War College, Newport, RI, Tech. Rep. February,
1994.
[5] R. Burke, “LCS Freedom Commissioned,” 2008.
[Online]. Available: http://www.navy.mil/submit/
display.asp?story{ }id=40822
[6] Surface Forces Public Affairs, “USS Independence
Commissioned,” 2010. [Online]. Available: www.navy.
mil
[7] C. Calvano, D. Byers, R. Harney, F. Papoulias, J. Ciezki,
L. T. H. Markle, L. T. R. Trevisan, L. T. T. Barney,
L. T. K. Eimers, L. G. Farman, L. T. C. Nash, L. A. Al-
tekin, and L. T. R. Kompatzki, ““SEA LANCE” Littoral
Warfare Small Combatant System,” Naval Postgraduate
School, Tech. Rep. January 2001, 2001.
[8] D. Alberts, Information Age Transformation: Getting
to a 21st Century Military, 1996. [Online]. Available:
http://oai.dtic.mil/
[9] E. Bonabeau, “Agent-Based Modeling : Methods
and Techniques for Simulating Human Systems Eric
Bonabeau Proceedings of the National Academy of
Sciences of the United States of America , Vol . 99 , No
. 10 , Supplement 3 : Arthur M . Sackler Colloquium
of the National Ac,” in National Academy of Sciences of
the United States of America, vol. 99, no. 10, 2002, pp.
7280–7287.
[10] R. Axtell, “Why agents?: on the varied motivations
for agent computing in the social sciences,” Center
on Social and Economics Dynamics - The Brookings
Institution, no. 17, pp. 1–23, 2000. [Online].
Available: http://www.brookings.edu/{∼}/media/
research/files/reports/2000/11/technologyaxtell/agents.
pdf$\delimiter”026E30F$nhttp://www.brook.edu/{∼}
/media/Files/rc/reports/2000/11technology{ }axtell/
agents.pdf
[11] U. S. DoD, “DoD Architecture Framework Volume 1:
Definitions and Guidelines,” Departmnet of Defense,
Tech. Rep., 2007.
[12] S. F. Railsback, S. L. Lytinen, and S. K. Jackson,
“Agent-based Simulation Platforms: Review and Devel-
 opment Recommendations,” Simulation, vol. 82, no. 9,
pp. 609–623, 2006.
[13] D. A. DeLaurentis, “System-of-Systems Laboratory.”
[Online]. Available: https://engineering.purdue.edu/
people/daniel.a.delaurentis.1/html/SoSL.html
[14] D. N. Fry, R. Campbell, and D. A. DeLaurentis,
“Modeling Systems-of-Systems from Multiple Design
Perspectives: Agents, Interfaces, and Architectures,”
AIAA Modeling and Simulation Technologies Confer-
ence, vol. 1, pp. 1–15, 2015.
[15] “Sizing up the beast: The MH-53E Sea
Dragon in action,” jan 2014. [Online]. Available:
http://ic.galegroup.com/ic/ovic/NewsDetailsPage/
NewsDetailsWindow?failOverType={&}query=
{&}prodId=OVIC{&}windowstate=normal{&}
contentModules={&}display-query={&}mode=
view{&}displayGroupName=News{&}limiter=
{&}currPage={&}disableHighlighting=false{&}
displayGroups={&}sortBy={&}search
[16] S. B. T. D. E. Galatowitsch, “Undersea
mines grow smarter and deadlier,” vol. 23,
no. 3, pp. 57+, jan 1991. [Online]. Available:
http://go.galegroup.com.ezproxy.lib.purdue.edu/ps/
i.do?id=GALE{%}7CA10506741{&}v=2.1{&}u=
purdue{ }main{&}it=r{&}p=PPMI{&}sw=w{&}
asid=de7b1148d143a99cf2a0eeedebb9367f
[17] UK MoD, “Falklands 25: Background Briefing,”
1997. [Online]. Available: http://webarchive.
nationalarchives.gov.uk/20100503141944/http:
//www.mod.uk/DefenceInternet/FactSheets/
Falklands25BackgroundBriefing.htm