Modeling and Simulation Links with Command & Control (C2) Systems

Modeling and Simulation Links with
Command & Control (C2) Systems
Considerations in Architecture Designs
Kevin Brandt
The MITRE Corporation
Joint Warfighting Center
PO Box 51037
Hampton, VA 23651-0037
757-726-6896
brandtk@mitre.org
Keywords:
Command and Control Systems, Modeling and Simulation Systems, C4ISR,
Architectures, Design Criteria,
Mission, Security, Feasibility,
Coherence, Usability, Robustness, Affordability, Sustainability,
Modularity, Cohesiveness, Connectivity, Economy, Extensibility
ABSTRACT: This concept paper explores objectives and requirements and proposes evaluation criteria for
architectures linking command and control (C2) systems with modeling and simulation (M&S) systems. It focuses on
design requirements for data flows between Joint training models and mission applications or segments within the
Defense Information Infrastructure Common Operating Environment (DII COE) including the DII COE Shared Data
Environment (SHADE).
1. Introduction
2. Rationale
The paper opens with the rationale for establishing
Links between C2 systems and M&S will sustain
links between command and control (C2) systems and
current uses and foster new applications. Today,
modeling and simulation (M&S) systems. It then
connections between these domains drive computer
provides a brief review of the Joint-training mission
aided training exercises. In the near future, automated
domain. Next, it postulates design considerations for
links will provide embedded training environments for
establishing data exchanges between M&S and C2
command, control, communications, computers,
systems. Afterward, it uses these proposed attributes to
intelligence, surveillance, and reconnaissance (C4ISR)
review an architecture prototype and to assess their
systems. On the acquisition front, connections may
impact on other designs and on end users in training
stimulate testing of emerging systems over a range of
exercises. As a by-product, it evaluates potential
operational missions and can provide extensive load
strengths and weaknesses of one prototype architecture.
tests (feasible with automated links between domains).
In conclusion, the paper explores potential implications
In addition, tighter links can aid in course of action
for model designs and modular development within the
(COA) development and analysis. Automated links
DII COE.
also foster mission planning and wargaming analysis.
Moreover, they extend the planning environment to aid
However, this paper does not attempt to review
in the coordination and synchronization of mission
methods for representing or modeling C4ISR systems
tasks and actions for multiple subordinates. Over the
within simulations. Moreover, it does not develop
long term, integrated links will enable full-scale
operational architectures for specific use cases or
mission rehearsals in mixed environments with
training scenarios.
constructive, virtual, and live forces.

---

3. Training and Mission Analysis
partner during a combined exercise. Similarly, resource
constraints may drive long-term automation of tasks to
In the era of legacy training models and emerging
gain efficiencies and improve response times or may
semi-automated command and control systems, links
limit network capacities and links available for specific
between M&S and C4ISR domains are layered. In a
events or within specific geographic areas. Likewise,
traditional operational architecture, the training
technical approaches may present new obstacles while
audience and mission analysts are in the top layer with
solving old problems.
limited direct access to the M&S tools – in the bottom
layer – that are adjudicating synthetic events.
In operational domains, requirements can limit the
introduction of new technologies unless both evolve in
parallel. For example, users now expect full-duplex
data exchanges over tactical networks to core data
Training Audience
or
Mission Analyst
GCCS
servers. If architectures are to fully exploit global
C2 System
Consolidated
(Training/Analysis
broadcast system and other wireless technologies, the
Plans, Orders
Reports,
Information Layer)
and
Messages,
technical requirement for full-duplex links must be
Information
and
Requests
Digital Data
(formatted messages)
eased. New technical architectures will be needed to
GCCS
C2 System
Response Cell
enable parallel simplex pathways over multiple
(Information Development
and Integration Layer)
channels to fully exploit potentials for improved data
Game
Game Reports, Messages,
distribution over wide areas. In addition, these changes
Orders
Graphics, and Digital Data
(Simulation & Data
will impact the development and application of new
Production Layer)
Joint Simulation
tactics, techniques, and procedures. Likewise, current
links from M&S systems that exploit text-only message
Figure 1: Layered Operational Architecture
protocols will not suffice for long. As users' C2 systems
expand to incorporate web-based video data streams,
interactive, distributed collaborative planning systems,
Training audiences interact with supporting simulations
and robust data warehousing and mining technology,
through an information development and integration
they will demand full-dimensional multi-media links.
layer comprised of mission-area response cells. These
cells translate training audience commands or requests
As these simple examples show, the desired or required
for information and relay them to the appropriate
level of connectivity may be pushed or constrained by
supporting simulation. In addition, these cells
policy, technology, or costs. In contrast, actual
consolidate and filter simulation-generated information
connectivity is constrained by the realm of the
and insert it into the target C4ISR system. Today some
practicable or the feasible.
of these links are automated but most rely on manual
intervention.
C4I connectivity may be classified into one of the five
categories developed by CISA to codify C4I systems
Future links between these domains may follow the
interoperability. These five levels 1: range from isolated
traditional layered approach while seeking to automate
(0) to connected (1) to distributed (2) and then to
services in the information development and
integrated (3) before culminating at universal (4).
integration layer. Alternatives seek to eliminate the
need for this middle layer with fundamental changes in
While not explicitly developed to codify cross-domain
the supporting simulations and/or targeted C4ISR
links to M&S, the LISI metric provides a reasonable
systems. Regardless of the approach, the quest for a
framework to scope the needed level of connectivity. In
fuzzy “seamless integration” fails to provide definitive
general, lower levels of interoperability require
criteria for architecture development. Within the C4ISR
increased manual intervention to maintain links.
domain, the quest for the “seamless” grail has been
However, higher levels of interoperability are not free.
supplanted by a more realistic move toward specified
In general, they impose requirements for recurrent
levels of interoperability.

4. Levels of Interoperability
1 The C4I Integration Support Activity (CISA) has led the
development of an extensive schema to codify levels of
Policies, technology, and resources can drive or
interoperability between C4I systems. Their Level of
restrain information architectures linking M&S with C2
Information System Interoperability (LISI) metric provides
systems. For example, links may be constrained by
the basis for an assessment of interoperability potential.
security policies that limit interconnections or they may
While this scheme was not explicitly developed to address
be driven by a political dictum to connect to a coalition
cross-domain links to models and simulations, the results are
generally applicable to these cross-domain links.

---

coordination between independent programs, increased
objective. However, some interface challenges may be
levels of engineering development, and robust
met only if the JTA is extended to incorporate new
configuration management.
technologies. In these areas, interface developers
Incremental Levels of System Interaction
should leverage the C4ISR standards development
process to foster reuse of new engineering solutions.2
EUCOM
JAC
Was hington D.C.
Level 4
DIA, NMIC
“Universal”
Second, given the DoD strategy to migrate most C2I
Shared Systems
CENTCOM
USACOM
systems into the DII COE, potential links with M&S
stand to provide the greatest benefit by targeting these
Level 3
“Integrated”
Data
Shared Applications, Data
mission applications or other common DII COE
Apps
NIDR, Common Displays, Shared Apps, ...
segments. In addition, reuse of DII COE hardware, data
Level 2
standards, network infrastructures, and technical
“Distributed” Heterogeneous Product Exchange
HTTP, NITF, ...
support personnel for M&S applications may be
practical if equivalent environments are maintained for
Level 1
“Connected”
Telnet, FTP,
Homogeneous Product Exchange
each domain. System reuse lowers resource
E-Mail, Chatter
requirements and promotes reduced maintenance,
Level 0
“Isolated”
No Electronic Connection (Manual)
fielding, and training costs. Moreover, reuse can
Figure 2: LISI Levels of Interoperability
shorten development timelines. However, M&S
applications and interface links must target DII COE
Level3 5 compliance (or higher) to gain these benefits.
Given the LISI model was not developed to classify
links between the M&S and C4ISR domains, these
Third, in the M&S domain, DoD has promoted reuse
connections may drive extensions to the LISI metric.
by fostering development of standards-based links
Potential expansion of LISI warrants further study –
between simulations. Christened the high-level
especially in the classification of links between M&S
architecture (HLA), this standard defines required
components and standard gateways. Extension should
services in the runtime interface (RTI) between models
allow the LISI metric to fully capture potential
within an HLA federation, sets metadata standards, and
connections between systems built to common
provides supporting tool sets. The RTI layer and
standards.
services also provide a conduit to command and
control systems. DoD policy stops short of mandating
5. Standards and Specifications
use of the HLA RTI as the single gateway to C4ISR
systems. However, such an approach fosters reuse of
Adoption of common standards promotes reuse of
links established for one component by other DII COE
system architectures and component software.
components or other mission applications.
Emerging industry standards combine with evolving
DoD specifications to dominate potential approaches.
Potential conflicts between DII COE guidelines4 and
However, the rapid introduction of new technologies
HLA rule sets5 should be considered in the
within the commercial sector must stimulate
development of technical architectures and software
reevaluation of derived architectures to ensure past

solutions continue to be efficient and effective.
2 GCCS CM Policy, CJCSI 6722.01, 1 July 97.
3 DII COE compliance is measured at 8 levels of
Four pillars are poised to sustain the design of
conformance: levels 1 - 8. Joint agencies have established
interfaces between C4ISR systems and M&S domains.
Level 5 compliance as the minimum acceptable level for
• The DoD Joint Technical Architecture (JTA)
Joint interoperability. Compliance has four measurement
• Defense Information Infrastructure (DII)
categories: runtime environment, style guide, architectural
Common Operating Environment (COE)
compatibility, and software quality. Compliance ratings are
•
based on three factors.

DoD High Level Architecture (HLA) for
1.
The degree a system (or software segment) achieves in
Modeling and Simulation
conformance to rules, standards, and specifications.
• POSIX and Industry Software Standards
2.
The degree of suitability that a segment has for integration into
the DII COE.
3.
First, JTA compliance is a major consideration. If
The extent the segment makes use of COE services or
duplicates them.
potential solutions do not comply, then interoperability
4 DII COE guidelines push for reuse of services to avoid
with C4ISR components may suffer. If solutions fail to
duplication of effort and to secure efficiencies.
achieve interoperability with the targeted C4ISR
5 HLA rules specify a loose data coupling scheme for
systems, they will fail to achieve their primary
federates that does not appear to align with some of the more
tightly-coupled DII COE SHADE concepts.

---

segments. However, these standards may need to be
organizations. Production of a conceptual model of the
redefined and/or refined when M&S components are
mission space can augment this assessment and provide
integrated into the DII COE.
more detail. Without a comprehensive mission
analysis, a review of existent systems and common
Fourth, development to POSIX and other open
data protocols can produce a quick estimate of critical
standards enables portability of software modules
data flows. However, reverse engineering breaks if
across platforms (at source code levels). This flexibility
missions or organizations radically change, if new
supports placement of modules within the C4ISR
technologies alter established data flows, or if
domain even when the native operating systems cannot
operational architectures radically shift to adapt to
host all of the core components of the simulation.
threats or other stimulus.
Moreover, these standards promote reuse of common
libraries and services and provide well-defined
6.2
Secure
interfaces. Thus, they can speed development, reduce
maintenance, mitigate technical support burdens, and
Security defines the ability to tailor access to system
ease user-training requirements.
components in concert with policy to enable forces to
meet mission and/or training requirements. Security
In addition to these four standards, several DoD
structures within the architecture should facilitate
directives or planning handbooks guide the
protection of data from intentional harm, misuse, or
development of integrated architectures and
compromise. Concurrently they protect against natural
promulgate integration and testing requirements.6
disasters and accidental loss. Good security features
facilitate rather than impede authorized access to
6. Design Considerations
information. In addition, they also establish dynamic
methods to monitor and record transactions across the
Mission requirements dominate the design constraints
networks. Data records capture both authorized uses
for operational architectures and thus drive the
(baseline data) and illicit attempts to gain improper
underlying system architecture and its technical
access to network segments or data structures. Good
foundation. However, mission does not define the
features also include automated methods to notify
entire environment. Other considerations include:
security personnel when unusual activity occurs or
• Security
•
Feasibility
when users attempt to access or modify critical data.
•
Security begins with focused assessments of

Usability
•
Coherence
•
vulnerability and risk for each specific use case. But, it

Robustness
•
Affordability
•
is dependent on features constructed within the

Sustainability
•
Modularity
•
architecture that facilitate data redundancy, data

Cohesiveness
•
Connectivity
partitioning, program layering, network segmentation,
• Economy
•
Extensibility
data filtering, data encryption, network traffic analysis
and control, network gateways or firewalls, intrusion
6.1 Mission Focused
detection and response, and disaster recovery. 9
Critical mission requirements dominate development
Heretofore, security has been largely ignored in linking
and selection of architectures. Data flows between
M&S and C4ISR domains. Our focus has been on
domains must satisfy critical operational requirements
enabling connections not establishing access security.
driven by the mission, the users, and their
As more systems are linked and more users added, the
organizations.
“The ultimate reason why a system is to
importance of security grows. In the future, security
exist is the filter through which all design decisions
will be a major consideration in designing links
must successfully pass.”7 In the initial stages of
between M&S and C2ISR domains. Training objectives
analysis, comprehensive assessments8 determine
and political goals grow demands to link federations to
critical mission needs for users within diverse
multi-national forces while each coalition force uses its

native C2 systems. Operational, system, and technical
6 The bibliography provides a non-exhaustive list of both
architectures must support security features to permit
directives and handbooks.
authorized access while enhancing protection.
7 Andriole, Information System Design, p48
8 Production of the Universal Joint Task Lists (UJTL)
provides generalized mission sets. However, it does not
include a metric for data flows between organizations

or staff elements nor does it develop supporting
9 Sun Microsystems, Securing Networked
operational architectures.
Environments, Rev A, July 1997.

---

6.3
Feasible
may not equate to perfect "ground truth". Coherency
simply requires that the correct perception be fed
Feasibility encompasses the state of the possible. In
consistently to establish the proper environment at the
combination with mission needs and security, it
receiving segment of the target C4ISR system.
completes the trio of the absolutes for potential
architectures. While mission focuses on getting the
Why is coherency important?
right information to users to allow them to perform
their tasks and security controls access to data and
Uncoordinated data flows, conflicting data from
network segments, feasibility determines if the
multiple sources, and non-standard data formats
architecture is viable. In short, can all necessary
degrade the utility of linking M&S and C4ISR systems.
components and connections be built? In addition, will
the structure support requisite capacities?
In today’s environment, simulations produce abundant
data. Unfortunately, extraction and correlation of
The remaining ten considerations are subservient to the
seemingly incoherent data from multiple simulation
first three, but they are still extremely important to the
sources or data feeds is a major burden borne by
success and long-term user acceptance of the final
support teams or response cells in the information
architectures.
development and integration layer (Figure 1).
6.4
Usable
Coherent data stems from the extraction of the correct
information from authoritative sources, processing the
Usability metrics extend beyond the bare-bones
datum with verifiable and proven techniques, and
functions captured by mission needs or feasibility
delivering the information via a synchronized schema.
measures and reaches into “ease of use” and latency.
Considerations include:
Ease of use issues include user training; user interface
• Data ownership
devices; re-use of well-accepted components, and
• Data flows
system configuration for unique user or mission
• Metadata (data about the data)
requirements. Latency measures overall system
• Data formats
performance and its responsiveness to user demands
• Data development algorithms
within mission parameters and resource constraints.
Usability also balances automation and manual
In tomorrow’s environment, delivery of coherent data
controls and proper distribution of tasks and allocation
may be enhanced by M&S designs or by developing
of control. However, all of these aspects of usability
modules within C2 systems to support information
are tied back to basic requirements and mission needs.
flows. However, neither can assure coherence if the
connecting links and underlying architectures do not
"Unless we measure the extent to which the
provide a synchronized delivery schema.
system satisfies user requirements and is
compatible with the organization it is intended
6.6
Robust
to support, then we really know very little
about how good the thing is. Unfortunately,
Robustness considers the amount and scope of external
there is no correlation between the integrity of
change or internal component failure that the
system algorithms and its ability to enhance
architecture can accommodate. The dynamic challenge
human performance."10
presented by shifting states of nature can be mastered
by a combination of two approaches. First, flexible
6.5
Coherent
architectures can absorb changes and component
failures without the need to shift the basic structure or
Coherency combines the drive for consistent
to add unforeseen components. Second, adaptable
authoritative data, coordinated information flows, and a
architectures can quickly change to meet changing
synchronized, unified data schema. This does not imply
conditions in a timely fashion. In either case, the
that perfect information will always be dispatched from
architecture must sustain external interfaces and
the M&S applications to all segments of the C4ISR
support requisite data flows. Flexible architectures tend
system. Coordination and synchronization require that
to be larger and support a wide range of known or
designated links provide consistent information in a
expected situations. In contrast, adaptive ones are
temporal and geospatial context. At times, simulations
generally less extensive but quickly mutate to meet
may feed data developed with a specific perception that
unforeseen circumstances.

10 Andriole, Information System Design, p39

---

Regardless of the intended approach, the drive for
6.9
Modular
robustness forces architects to design for changing
conditions knowing that change is normal. Over time,
Modularity captures an ability to repeatedly decompose
system components wear out or degrade. Mission
the network and its components into smaller and
requirements evolve. New technologies emerge.
smaller sub-systems until the parts are intellectually
Enabling technologies spread. Workload allocation
and technically manageable as independent units.
strategies shift. Moreover, COTS and GOTS software
Architectures may use spatial, functional, temporal,
follow separate development tracks. Hence, robustness
and/or logical modularity. “A modular system is
– the ability to handle change – provides critical
composed of well-defined, conceptually simple, and
capability and fosters affordability.
independent parts interacting through well-defined
interfaces.”12
6.7
Affordable
Common modular designs include client-server
Affordability measures the cost to install, operate, and
and/or subnet architectures. Advantages of these
maintain (IOM) the system architecture that
modular schemes include:
implements the technical architecture and enables the
• Easier to understand individual modules
operational architecture. These costs include
• Easier to understand relationships between
organizational, political, financial, training, and/or
modules
opportunity expenses. Affordability also encompasses
• Easier to document
other constraints placed on the design or development
• Easier to build
process and includes overall timeliness 11 in the
• Easier to test and integrate
delivery of potential solutions. It may compel the use
• Easier to maintain
of off-the-shelf software (COTS or GOTS) or re-use of
other systems. It may drive prespecification of
6.10
Cohesive
hardware and/or software components or limit design
options for user interface modules. In addition,
Cohesion marks the strength of the bonds among
affordability may limit introduction of new
subordinate elements within a module. Modules with
technologies and thus dampen system performance or
strong cohesion perform better. Moreover,
precipitate a reallocation of tasks to limit costs.
implementations with highly cohesive modules
generally have lower fault rates and lower costs than
6.8
Sustainable
those with less cohesive modules.13 From levels of high
cohesion to levels of lower cohesion, a common
Sustainability encompasses a handful of subordinate
scheme progresses through six layers.
factors. Most of these factors focus on the system
• Data-type cohesion
architecture, but some overlap into the operational or
• Object structure cohesion
technical architectures.
•
• Functional cohesion

Reliable – All system components complete
• Logical cohesion
essential tasks to established standards of
•
performance over the requisite timeframe.
Sequential cohesion
•
•


Available – The system and its components are
Incidental cohesion
fully operational and accessible.
• Maintainable – System and its critical
6.11
Connected
components are well designed and well
documented to support repairs, upgrades, and
Connectivity encompasses both physical and logical
migration to new platforms and/or operating
links between modules. Physical connections enable
systems.
electromagnetic transmission of data streams. Logical
•
links establish the protocols for data exchanges.
Observable – The actions and performance of
the system and its components are open to
inspection, assessment, and re-evaluation.
Physical bonds can employ a range of methods that are
•
established by the operational requirements and the

Verifiable – The system and its components
system constraints. For example, links can be
perform actions that are credible and traceable to
established as point-to-point connections or network
the underlying mission requirements.
backbone hookups. In general, the physical


12 Frakes, Software Engineering, pp27-28.
11 Simmons, Software Measurement, pp192
13 ibid. pp28-29.

---

connections determine if data flows are unidirectional
potential for reuse of system components and builds
(simplex), bi-directional (duplex), or multi-directional
upon adaptive attributes. Considerations include:
(multi-cast or broadcast). Selection of physical options
• Implementation of network topologies and
balances reliability, robustness, maintainability,
communication protocols
economy, efficiency, and reuse.
• Application of open system standards
• Adherence to interface standards
In contrast to the physical links, coupling measures the
• Adoption of programming standards
strength of the logical linkages between modules based
• Extent and accuracy of documentation
on information exchanges between them. In general,
• Quality and scope of training materials and
loosely coupled modules are better; they are easier to
technical support
understand, document, code, test, and maintain.14 One
usable scheme defines the degree of coupling over
These thirteen design attributes form a basis for
range of six levels (from loosely to tightly coupled).
development and evaluation of potential architectures.
• Data definition coupling
The next section shifts the focus to an exemplary
• Data element coupling
application of these factors. Byproducts include a crude
• Object coupling
evaluation of one prototype architecture. A definitive
• Control coupling
evaluation of this prototype is properly deferred to an
• Global coupling
interdisciplinary team of users, developers, and experts.
• Content coupling
7. Application of Design Attributes
Most current links implement loose coupling at the
data element level with information passed through
An architecture that overcomes common constraints
standard interface protocols. HLA links embody both
employs a persistent domain data server (DDS) as the
data element and data definition coupling. In contrast,
gateway to the C2 domain. This gateway collects and
the DIS standard relied on object-level coupling. Most
holds data in a central location after it has been
DII COE mission applications exhibit data definition
transmitted over the HLA RTI from the M&S domain.
coupling, but SHADE applications could inherit more
tightly coupled schemes. Hence, SHADE modules can
range from simple object coupling to control coupling
DII COE / C2 Domain Data Server
to global coupling or even content coupling depending
DII COE Mission Applications
on specific methods used to make database exchanges.
Other C2
DMS
GCCS-M
GCCS
GCSS
Open Link
API
6.12
Economical
SHADE
Standard
DII COE
Protocol
Public API
SHADE
DXM
DXM
SHADE
DII COE
Economy complements feasibility. It extends the
DX Modules
SHADE
SHADE
Applications
DDS
feasibility concepts beyond determining if the
C2 Domain Data Server
Data Module
architecture has the necessary capacity. It embraces the
Interface
JTC
JSIMS
JTLS
DMI
JCATS
quest for the most effective, most efficient structure
RTI
RTI
RTI
RTI
RTI
with sufficient capacity to meet mission and/or training
HLA RTI
requirements and considers the contributions made by
all usable attributes of the system. Finding the optimum
Figure 3: HLA RTI with Domain Data Server
economical architecture does not equate to finding the
cheapest. It balances performance against costs. It
This structure defines a demarcation line for developers
values usable features up to, but not beyond, their level
on either side of the domain data server. Each can
of utility. In summary, it seeks the most effective
program an interface to well-known data protocols to
operational value.
insert datum into or extract information from the
domain data server. This physically connected but
6.13
Extensible
loosely coupled structure encourages development of
reusable modular components and provides structures
Extensibility captures the level of difficulty
to support implementation of security firewalls and
encountered when extending the architecture to add
gateways to network segments.
capacity, clients, and/or functions. It ties into the
A coherent C2 domain data server can promote reuse of
common services and links to DII COE mission

14 ibid. pp29-30.

---

applications. Over time, the best of these links may be
observable, and verifiable data. However,
segmented into the DII COE as standard services.
production and maintenance of the C2 domain
data server may add expense and development
7.1
Potential Strengths
effort.
• Mission, user, organization requirements —
Provides structure for data integration and
7.3
Potential Weaknesses
coherent structure for data development for Joint
• Affordability — Building and maintaining the
training exercises.
C2 domain data server adds development effort
• Security — Provides structure to support
and expense.
development of gateways, firewalls, network
segmentation, and network monitoring.
8. Implications
• Usability — Standard connections mitigate
training and support burdens.
Links between C2 and M&S domains are critical, but
• Coherence — Structure provides capability to
they should focus on obtainable and definable levels of
ensure data coherence prior to entry into target
interoperability. Links should leverage and adhere to
C2 systems.
established standards and specifications (if possible).
• Robustness— Standard interfaces promote
Proposed design factors allow users to differentiate
reusable links that improve flexibility,
between architectures. Using a mission-based focus
adaptability, and reuse. The data server's links to
versus a technology-led approach, critical differences
client applications within the C2 domain are not
in architectures are captured in terms that relate to
constrained to use the HLA RTI. This flexibility
users, organizations, and missions. In addition,
opens the door for new topologies and adaptive
implications for architectures within the context of the
structures.
DII COE emerge as a byproduct
• Modularity — Reduces maintenance. Supports
client-server structures and network segments.
8.1
Mission Focus
• Cohesiveness —Favors cohesive modules
focused on single, reusable services.
Links between domains must establish and maintain a
• Connectivity — Loosely coupled via the HLA
focus on mission requirements. These links must
RTI to M&S. Domain data server is coupled via
facilitate both training and operational environments,
data protocols to DII COE mission applications
and they must support all critical mission tasks.
and other C2 systems. DDS may increase some
Information exchanges must provide mission-critical
development costs but should reduce operating
data in an integrated, coherent environment. In short,
costs. Design promotes reuse of links.
they must support an integrated operational
• Economy — Higher costs for development and
architecture. In addition, solutions must be secure and
maintenance of domain data server can be offset
sufficiently robust to handle dynamic shifts – not just
by reduction in operating costs and replacement
evolution – in the operational architectures.
of manual data integration with automated tools.
• Extensibility — Flexible and extensible. Links
8.2
Secure
between C2 and M&S leverage reusable and
extendable protocols and pathways and can
Security is fundamental to all levels of the architecture:
implement unique point-to-point links from
operational, system, and technical. Connections
between the domain data server and DII COE
between C4ISR and M&S domains will expose
mission applications or other C2 systems.
underlying requirements to support multiple levels of
security and multi-level security. In this context,
7.2
Neutral Attributes
multiple levels of security and multi-level security
• Feasibility — Although the technology isn't
extend beyond the formal divisions of the DoD security
new, DoD C2 data standards are still not
classifications (i.e., unclassified, confidential, secret,
completely defined and a domain data server has
top secret, and/or special access). It also includes
not been constructed. If these obstacles are
subdivisions of users based on permissible time and
overcome, remaining aspects of the architecture
type of access to data. However, these distinctions rely
are low risk and mitigate other development
on supporting information. The operational architecture
obstacles.
must provide time-dependent, dynamic user groups tied
• Sustainability— Potential for reduced software
to their specific data requirements. In addition,
maintenance burdens. Best guarantee for
metadata must identify attributes that allow
production and delivery of reliable, available,
differentiation of data items at the requisite level of

---

fidelity. In turn, secure technical and system
adherence to standards. Both of these attributes also
architectures implement schemes to protect data
contribute to the architecture’s long-term viability.
integrity and to responsively deliver the right data –
and only that data – to each authorized user.
8.4
Sustainable
Within the operational architecture, security stems
The long-term viability of any proposed architecture
from the ability to identify user groups that must
hinges on its sustainability. The overall health of each
exchange or access common data. These activities
interface module depends on its connections into both
include groups authorized to read data, write data,
the C2 domain and the M&S domain. Failure in either
and/or monitor metadata. Secure designs exploit
domain causes a connection failure.
operational modularity to limit information flow to a
set of common, authorized users. In addition,
Over the program lifecycle, loosely coupled
catastrophic failures and inadvertent errors must be
connections using standard protocols are easier to
balanced by redundancy and data verification cells
maintain in comparison to unique point-to-point
within the operational architecture. Status monitoring
connections. For the M&S domain, this approach
and response options must also be incorporated into the
translates into stipulating reuse of a common
operational architecture. (In general, these features may
Simulation Object Model (SOM) for links with C2
be incorporated in the design of system architectures
systems.
but are rarely considered in the development of the
operational schemes.)
At the other end of the bridge, the C2 environment
hinges on the DII COE and compliant mission
At the implementation level, viable security hinges on
applications. Hence, long-term sustainability of
aligning system-architecture segments with
interface modules would be enhanced by their
operational-architecture domains. Each virtual domain
integration into the COE. Thus, all components on the
should be designed to align with one level of security
C2 side of the HLA RTI should be considered for
access. However, a given level of access may map
migration into the DII COE as M&S support modules.
multiple physical segments to its virtual domain.
In addition, system architects should specifically
Likewise, a common physical segment may service
consider integration of a coherent domain data server
more than one virtual domain by employing switches,
into the DII COE SHADE.
switching routers, encryption techniques, and/or
software filters. These (or other) methods are employed
Integration of M&S modules into the DII COE implies
to establish boundaries between domains to create
movement toward common data structures and data
virtual networks of common users arrayed by their
definitions. Over time, use of common terms and
authorized access.
structures can evolve into a comprehensive, enterprise-
level, data model encompassing M&S, C2, and other
Within the technical architecture, security rests on
information system domains. In the near term, simple,
inclusion of structures that facilitate access control,
common structures will enable the production of
modular segmentation, and data coherency. Gateway
reusable data-exchange modules. These modules
and firewall structures between cohesive interface
leverage a collection of base-object models (BOM) to
modules facilitate these goals. In turn, client-server
map C2 data items to objects and attributes within the
structures facilitate reliable implementation of robust
simulation domain. Collectively, a set of base-object
security structures and enhance coherent data flows
models combine to form a hierarchical-object model
across these boundaries. Given these goals, several
(HOM) that fuses multiple BOM to produce data
design options are feasible.
streams in standard formats and protocols. In terms of
the proposed Simulation Interoperability Standards
8.3
Feasible and Robust
Organization (SISO) definition, the data items that feed
a comprehensive set of hierarchical-object models for
The logical and physical gateways between M&S and
C2 interfaces could provide the template for a reference
C2 domains must be both feasible and robust.
federation object model (RFOM). Data model reuse
Robustness requires, as a minimum, that the
couples with standardization to enhance sustainability.
architectures be both extensible and reusable.
Moreover, they should be adaptable and/or flexible. In
9. Conclusion.
this context, flexibility and adaptability must permit the
structure to meet dynamic requirements without
In conclusion, the specified factors allow users to make
reengineering basic components. Likewise,
meaningful operational distinctions between technical
extensibility and reusability imply modularity and

---

and system architectures. Good designs can enhance
[13] Department of Defense Directive, Defense
security and mitigate overhead workloads in response
Information Management (IM) Program, No.
cells in training exercises. Moreover, a mission-based
8000.1, 27 October 1992, Department of Defense,
focus also implies closer ties to the DII COE (for Joint
Washington, D.C.
forces) and emphasizes the need for standardization of
[14] Department of Defense Directive, DoD Data
data between M&S and C2 domains.
Administration, No. 8320.1, 26 September 1991,
Department of Defense, Washington, D.C.
10. References
[15] Department of Defense Directive, Management
and Control of Information Requirements, No.
[1] Andriole, S. J., Information System Design
8910.1, 11 June 1993, Department of Defense,
Principles for the 90’s—Getting It Right! 1990,
Washington, D.C.
Fairfax, VA, AFCEA International Press
[16] Ferraby, L., 1991, Change Control, Hertferdshire,
[2] Carpenter, H., 11 July 1997, “Methodology for
UK, Prentice-Hall International (UK) Ltd.
Assessment of C4I Architectures,” MITRE
[17] Frakes, W. B., and C. J. Fox, B. A. Nejmeh, 1991,
Technical Report No. W150-M-083, The MITRE
Software Engineering in the Unix/C Environment,
Corporation, Reston, VA
Englewood Cliffs, NJ, Prentice-Hall, Inc.
[3] Chairman Joint Chiefs of Staff Instruction, Global
[18] JIEO/JITC Circular, Requirements Assessment and
Command and Control System Configuration
Interoperability Certification of C4I and AIS
Management Policy, CJCSI 6722.01, 1 July 1997,
Equipment and Systems, JIEO/JITC Circular 9002,
Joint Staff, Washington, D.C.
23 January 1995, Defense Information Systems
[4] Chairman Joint Chiefs of Staff Instruction, Joint
Agency, DOD, Washington, D.C.
Modeling and Simulation Management, CJCSI
[19] Knoefel, J. O., July 1992, C4I For The Warrior,
8510.01, 22 December 1995, Joint Staff,
Briefing by Naval Electronic Systems Engineering
Washington, D.C.
Activity, NESA Code 2400, St. Inigoes, MD
[5] Chairman Joint Chiefs of Staff Instruction, Joint
[20] Roetzheim, W. H., 1991, Developing Software to
Strategic Planning System, CJCSI 3100.01, 1
Government Standards, Englewood Cliffs, NJ,
September 1997, Joint Staff, Washington, D.C.
Prentice-Hall, Inc.
[6] Chairman Joint Chiefs of Staff Instruction,
[21] Simmons, D. B., and N. C. Ellis, H. Fujihara, W.
Procedures for Compatibility, Interoperability,
Kuo, 1998, Software Measurement: A
and Integration of C3I Systems, No. 4630.8,
Visualization Toolkit for Project Control and
Assistant Secretary of Defense, DOD,
Process Improvement, Upper Saddle River, NJ,
Washington, D.C.
Prentice-Hall, Inc.
[7] Chairman Joint Chiefs of Staff Instruction,
[22] Theater Battle Management Design Team, The
Requirements Generation System (Formerly MOP
MITRE Corporation, July 1992, Technical
77), CJCSI 3170.01, 13 June 1997, Joint Staff,
Approach to the Future Theater Battle
Washington, D.C.
Management C4I Architecture for Deployable
[8] Chairman Joint Chiefs of Staff Instruction,
Operations, Briefing No. M92B0000073,
Verification, Validation, and Accreditation of Joint
Electronic Systems Center, Hanscom AFB, MA
Models and Simulations, JSI 8104.01, 12 January
[23] Thompson, B., The MITRE Corporation, 23 June
1995, Joint Staff, Washington, D.C.
1997, Levels of Information Systems
[9] Chairman Joint Chiefs of Staff Manual, Employing
Interoperability (LISI), Briefing for Program
Joint Tactical Communications—Joint Network
Sponsor: C4I ISA Architectures Directorate
Management and Control, CJCSM 6231.07A, 24
January 1997, Joint Staff, Washington, D.C.
Author Biography
[10] Chairman Joint Chiefs of Staff Manual, Joint
Training for the Armed Forces of the United
KEVIN BRANDT is a lead engineer for modeling and
States, CJCSM 3500.03, 1 June 1996, Joint Staff,
simulation for MITRE at USACOM Joint Warfighting
Washington, D.C.
Center. His focus centers on user requirements and
[11] Chairman Joint Chiefs of Staff Manual, Universal
development of models for Joint training simulations.
Joint Task List, Version 3.0, CJCSM 3500.04A, 13
He has designed and executed Joint and coalition
September 1996, Joint Staff, Washington, D.C.
training exercises and demonstrations with data feeds
[12] Department of Defense Directive, Compatibility,
between training simulations and C2 systems. He is
Interoperability, and Integration of C3I Systems,
currently developing architectures for the Distributed
No. 4630.5, 12 November 1992, Assistant
Joint Training (DJT) program.
Secretary of Defense, DOD, Washington, D.C.

---