Proceedings of the 2009 Ground Vehicle System Engineering and Technology Symposium (GVSETS)
Conditional Based Maintenance Plus (CBM+) Communications Architecture
Modeling and Simulation with Decision Support Technology
Jack Li
Walter Lucchesi
Peter Johnson
US Army RDECOM CERDEC Space and Terrestrial Communications Directorate (S&TCD)
Fort Monmouth, New Jersey 07703
Dr. Stanley Smith, S. H. Smith Associates, Montville, NJ
Dr. Jeffrey Halle, EOIR Technologies, Eatontown, NJ
Joseph Pasirstein, Systems Automation Associates (SAA) LLC, Parsippany, NJ
ABSTRACT
Architecture, Modeling & Simulations (AMS) in conjunction with decision support technologies are crucial to ensure successful
execution on the CBM+ vision. Currently, stove-pipe CBM+ enabled platforms compete for inadequate network resources
creating risks for Global Combat Support System - Army (GCSS-A) network availability, creating the inability for CBM+ data to
reach the Logistics Support Activity (LOGSA). The inability of server replication could result in missing or conflicting CBM+ data
for weapon system health management status reporting. A fundamental CBM+ Communications infrastructure/architecture is
needed to bridge the gaps between the network and applications. This paper will discuss the high level methodology evolutionary
approach to this problem in terms of architecture engineering, architectural modeling and simulation (M&S), decision support,
and information assurance in detail based on the CBM+ efforts that we have accomplished so far.
INTRODUCTION
CBM+ is a proactive equipment maintenance process that
uses sensors and system health indicators to predict
functional failure prior to a failure event, thereby enabling
maintenance personnel to take appropriate preemptive
action. CBM+ improves equipment combat effectiveness,
enhances safety and reduces life-cycle costs. The US Army
REDCOM CERDEC S&TCD provides subject matter
expertise (SME) in System of Systems (SoS)
communications architecture integrated into the tactical
Army, Information Assurance (IA), and tool sets to design,
model, and analyze the communications architectures and
networks to support developing CBM+ applications. This
continuous and dynamic effort will change to support
increased CBM+ density of applications, platforms, and
equipment. The architecture development will support
existing
data
strategies,
LOGSA
Taxonomy,
Ontology/Semantic Web efforts, and Machinery Information
Management Open Systems Alliance (MIMOSA). The
results will bring a coherent integration to diverse data
application efforts that lack SoS integration &
interoperability. Results will be engineered through DODAF
based architectural artifacts and set up on a web portal for
the
CBM+
stakeholders
and
consumers.
This
communications architecture and related engineering efforts
will support an efficient, effective, and successful CBM+
implementation.
The objective of our effort is to develop a communications
architecture that will integrate with the Army Integrated
Logistics Architecture (AILA) and meet CBM+
requirements such as improving operational availability,
reducing logistic footprint, reducing O&M cost, speeding up
decision support cycle using high level methodology
evolutionary approaches such as Architecture Engineering,
Modeling and Simulation, and Decision Support shown in
Figure 1. We initiated investigation of existing CBM+
Architectural issues, gaps, existing architectures, and tools.
As a result, we identified several communications and
communications-related architectural issues that require
architecture engineering analysis either prior to or
Conditional Based Maintenance Plus (CBM+)
Communications Architecture Modeling and Simulation with Decision Support Technology
Page 1 of 7
Proceedings of the 2009 Ground Vehicle System Engineering and Technology Symposium (GVSETS)
concurrent with the development of the communications
architecture. These issues [4] lie in the areas of (1) above
platform infrastructure ownership and composition; (2) Very
Small Aperture Terminal (VSAT) and satellite bandwidth
requirements; (3) Service Oriented Architecture (SOA)/
Enterprise Service Bus (ESB) definition and ownership; (4)
data requirements including methods for efficient
transmission such as compression for
platform data
collection; (5) validity of existing Department of Defense
Architecture Framework (DODAF) architectures (e.g.,
network communications architecture); (6) Cross-Domain
Guard issues and (7) other information assurance (IA) issues
ensuring the confidentiality, integrity, authentication,
availability, and non-repudiation of the platform data. These
issues are to be analyzed and socialized by applying
engineering principals and rigor to Engineering of
communications architectural related artifacts as well as the
development and socialization of solutions sets. We believe
this effort can make significant contributions to the CBM+
program beyond the development of communications
architecture. Working relationships have been established
with key stakeholders for our CBM+ efforts to ensure their
requirements are met. We have participated in on-going
Common Logistic Operating Environment (CLOE)
Threshold Capability Integration (TCI) workgroup meetings
as well as upcoming meetings such as the Communications
Workgroup meetings.
ARCHITECTURE ENGINEERING
Using the Department of Defense Architecture Framework
(DoDAF) 2.0 released on May 28, 2009, we have created
front-end architecture requirement definition matrices such
as (1) intended use and applicable artifacts, (2) artifacts and
consumers and (3) artifacts and developers or maintainers to
gather the requirements for DoDAF views (e.g. AV-1, SV-1,
and SV-2) as shown in Figure 2. Along with the existing
architecture analyses, this approach not only leads to
integrated design with the existing architecture, but also
identifies gaps and issues. This methodology requires use of
modeling and simulation (M&S) and Decision Support tools
to assist in the architecture design and optimization.
Figure 2: CBM+ Communications Architecture
Development Approach [1]
Based on the initial AILA CBM+ architectural assessment
[3], the following gaps have been identified:
Completeness Gaps: (1) difficult to extract CBM+ specific
IERs; (2) several important artifacts still need to be
developed; (3) difficult to identify CBM+ specific
information/data in the logical data model (OV-7), the
physical data schema (SV-11) and the integrated dictionary
(AV-2).
Figure 1: High Level Methodology Evolutionary Approach
[1]
Consistency Gaps: (1) appears to be inconsistencies between
several artifacts; (2) appears to be gaps between IERs and
CBM+ needlines; (3) not all the Organizational Units’
platform sensor data needlines could be traced end-to-end
Conditional Based Maintenance Plus (CBM+)
Communications Architecture Modeling and Simulation with Decision Support Technology
Page 2 of 7
Proceedings of the 2009 Ground Vehicle System Engineering and Technology Symposium (GVSETS)
(e.g., to the CBM+ data warehouse); (4) not all the CBM+
IERs that are identified in operational activities have
operational Node-Node Connectivity.
Finally, the preliminary gap impact assessments are: (1)
AILA needs updates/enhancement in order for seamless
CBM+ communications architecture development and
integration; (2) it is essential to align & integrate CBM+
communications system views with AILA Architectures.
Partnership opportunities exist to work these issues jointly
with the CLOE and CBM+ communities.
aircraft associated with them, and thus contain equipment for
gathering and transmitting the CBM+ data obtained from the
aircraft. There are three types of links in this network,
Ethernet within a unit, wireless 802.11x links
interconnecting the CAISI bridges, and SATCOM links
between the units and the Enterprise HQ.
ARCHITECTURAL MODELING & SIMULATION
Aviation Baseline – Bde and Below
The analysis of a complete network can be quite extensive.
Based on earlier work [2], an initial estimation of what this
architecture looks like was made. A preliminary analysis
has been conducted using this architecture and estimates of
traffic data we have obtained from the Ground and Aviation
Node Baseline – BDE & Below [2]. In doing so, the source
and location of bottlenecks in this network have been
identified. It is anticipated that our further study will enable
us to identify a methodology to alleviate the congestion
enabling information to be passed and analyzed more
efficiently.
For this paper, we will describe the preliminary analysis of
one portion of the CBM+ network, specifically the Aviation
Brigade (BDE) and below. This architecture is illustrated in
the top portion of Figure 3. The objective for this analysis is
to understand the capacities of the network with respect to
the CBM+ data, to identify the bottlenecks, and to find ways
to alleviate these bottlenecks by modeling different traffic
patterns, thereby, addressing the bandwidth requirement gap
described in the introductory section.
This network consists of several units at Brigade, Battalion,
and Company level. All of the units have wireless 802.11x
capability provided via Combat Service Support Automated
Information Interface (CAISI) equipment to enable
connectivity for Line of Sight (LOS) up to approximately 32
miles. Additionally, several units have VSAT capability to
enable communications with the Enterprise HQ. Each unit
contains various workstations, servers, LAN switches, and
routers. Additionally, the Flight Companies have multiple
Combat Aviation Bde HQ
Figure 3: CBM+ Aviation Baseline – BDE and Below
The primary tool utilized for this preliminary analysis is the
JCSS (Joint Communications Simulation System) 9.0
(formerly known as NETWARS) from Defense Information
Systems Agency (DISA). A high-level architecture structure
of the network to be studied was created. It is shown in the
middle portion of Figure 3. Each unit contains the detailed
design of the particular architecture and connectivity for that
unit. The Architecture Combat Aviation BDE HQ is
displayed as an example in the bottom portion in Figure 3.
Also in Figure 3, the arrow indicates how in each step the
architecture has been modeled and simulated in successively
Conditional Based Maintenance Plus (CBM+)
Communications Architecture Modeling and Simulation with Decision Support Technology
Page 3 of 7
Proceedings of the 2009 Ground Vehicle System Engineering and Technology Symposium (GVSETS)
more detail. Next, communication links among the units
were created. For units equipped with VSAT, SATCOM
links were created to the Enterprise HQ. IEEE 802.11x
wireless links between CAISIs we employed to provide the
remaining connectivity. Since these units could potentially
be interconnected in a variety of routing schemes, several
scenarios that differ by the routing schema were developed.
Figure 4 illustrates this architecture with the connectivity
displayed for one such scenario.
analyze the effect of these modifications and to generate a
protocol for managing the congestion.
This preliminary work has identified some of the bottlenecks
contained in this network, as well as providing an initial
model and framework for continuing study.
Further
modeling and simulation studies will include propagation,
terrain, background traffic effects, information assurance
issues, etc.
DECISION SUPPORT
Figure 4: Baseline Architecture with Links and Traffic
Flows
The primary source of traffic on the network is the data
gathered from each aircraft. The volume of data from each
source is so large as to completely fill a VSAT circuit for
several minutes, so the cause of bottlenecks is quite
apparent. Fortunately, this data is not transmitted to the
Enterprise HQ in real time, so various steps can be taken to
lessen the impact. Among these measures to reduce the high
data rate are spreading out the data transmission in time,
data compression, traffic shaping to the interfaces to throttle
the traffic flow from this data, and rerouting some of the
traffic to use otherwise underutilized links.
The next step of this modeling process was to create traffic
flows from the sources to the destinations. These are
illustrated by the dotted lines in Figure 4. (Note that there
are also flows that are obscured by the solid lines that show
connectivity.) Next, the parameters for these flows are
modified to model the variants described in the previous
paragraph, and a capacity analysis is conducted for each set.
This process is repeated several times for each scenario to
The System of System (SoS) enterprise architectural
decision making processes are extremely complex,
uncertain, and dynamic and led to unstructured and illdefined decision making.
We have developed and
implemented a rigorous, structured methodology to improve
the decision making process. For architecture decision
making process to be effective the process must be flexible
(must be able to adjust the criteria, weights, etc), adaptable,
provide for what-if and sensitivity-type analysis and provide
the documentation supporting the decision. Everyday
decision-making often seems trivial and typically follows
little to no structure. This is usually acceptable for minor
problems but insufficient for large scale, critical decisions,
especially at an enterprise level. Turban [7] defines a
Decision support system (DSS) as computer based
information systems that combine models and data in an
attempt to solve non-structured problem. The method
described in this paper, allows for the combination of
qualitative and quantitative data in it’s’ approach to
decision-making. DSS are designed to be an accessory to
decision makers, extend their capabilities, but not to replace
their judgment. In turn, it uses these judgments to support
the underlying algorithm which will compute best alternative
for a given situation. A DSS multi-objective decision
support tools based on the Analytical Hierarchical Process
(AHP) developed by Dr Saaty [8, 9] was used for this paper.
The AHP is designed to facilitate the decision making
process by using both empirical data and subjective. The
AHP implementation provides the subject matter experts
(SMEs) with a structured means to organize and evaluate the
importance of various objectives and the preferences of
alternative solutions.
Conditional Based Maintenance Plus (CBM+)
Communications Architecture Modeling and Simulation with Decision Support Technology
Page 4 of 7
Proceedings of the 2009 Ground Vehicle System Engineering and Technology Symposium (GVSETS)
The use of decision support technology [5, 6] is ideally
suited for this type of decision making. An IDEF model of
the seven steps in the decision support methodology is
shown in figure 5.
to derive the overall weight for the alternatives. The best
alternative is that with the highest priority.
Figure 6 illustrates an example of applying the key
capabilities such as the decision hierarchy, criteria and sub
criteria with their associated weights, and several sensitivity
and comparative analysis modes.
Figure 5: Top level Decision Support Methodology
Step 1: Problem Identification and Research – the first step
of the decision making process typically involves identifying
the problem, objectives and alternatives and researching the
alternatives. The suggestions that are discussed by Saaty [6]
were followed, and were expanded upon, to eliminate
possible pitfalls.
Step 2: Eliminating Infeasible Alternatives – During this part
of the process all the potential alternative are discussed. The
SMEs determine the “Musts” for determining the criteria
that must be met.
Step 3: Building a Model - there is no one "correct" model
for a decision. Different SMEs informed about a specific
problem may structure the hierarchically differently, but if
the judgments are similar, the overall answers will be
similar.
Step 4: Making Judgments – After the model was
constructed, the architectural SMEs compared the elements
at each level of the hierarchy. Several different techniques
were used to capture the SME tacit knowledge.
Step 5: Synthesizing – During this step the judgments that
are made by the SMEs are synthesized (consolidated)
throughout the model using a weighing and adding process
Figure 6: An example of a possible Decision Support
Hierarchy
Step 6: Examining and verifying the Decision – This is a
crucial step and often under emphasized. That is, verify that
the intuition about the best alternative agrees with the chosen
alternative. If not, re-examine the structure, objectives and
judgments of the model. At this point a What-If or Sensitivity
Analysis may be performed.
Step 7: Presenting and Documenting the Decision – Once
the results have been examined and verified, it is often
important to be able to document the reasoning that went
into a decision. The documentation may be used to justify
the conclusion to others, or to reflect on the decision in the
future. Figure 7 illustrates four typical sensitivity analysis
diagrams, that is, an Overall Criteria Diagram, a Criteria
Specific diagram, a Dynamic Sensitivity diagram and a Head
to Head sensitivity diagram
Applying this methodology to the CBM+ domain has been
shown to be beneficial and has numerous advantages which
span the entire process and life cycle (AS-IS to TO-BE
evolution). This methodology is being applied to current &
future
architectural
decisions.
Without
question,
incorporating the DSS is enhancing the decision making
Conditional Based Maintenance Plus (CBM+)
Communications Architecture Modeling and Simulation with Decision Support Technology
Page 5 of 7
Proceedings of the 2009 Ground Vehicle System Engineering and Technology Symposium (GVSETS)
process and will ensure a better understanding of the
decision being made. In fact, complex decisions based on a
combination of qualitative and quantitative measure (with
different levels of maturity) are benefiting significantly both
in understanding the problem and identification of the “best”
solution. Since the process lends itself to capturing, refining
and synergizing the tacit knowledge that is typically used by
the SMEs it is ideal for continual process improvement
Figure 7: An example of various sensitivity analysis reports
from the Decision Support System (DSS)
INFORMATION ASSURANCE
Information Assurance (IA) is an integral component of the
Army’s communications infrastructure. Its purpose is to
protect and defend the information infrastructure and the
information within it, in order to provide confidentiality,
integrity, authentication, non-repudiation, and availability.
IA covers a wide area of protection and defense that include
operations security (OPSEC), communications security
(COMSEC), transmission security (TRANSEC), information
security (INFOSEC), personnel security, and physical
security. An implementation of IA must not only ensure
proper protection and defenses, it must also be developed in
compliance with appropriate standards and regulations, risk
mitigation, minimize network performance degradation, and
cost effectiveness. A balance must be found among many
variables such that the end result will produce the desired
architectural design. This will be accomplished through
experienced architectural engineering, modeling and
simulation (M&S), and Decision Support disciplines.
Architectural Engineering discipline provides a systematic
approach to the development of communications and
information systems’ architectures.
The Architectural
Engineering approach ensures that the information and
communications architectures are compliant with the many
IA standards, regulations, policies, and directives. It assists
in the development of IA protective and defensive
architecture in a manner that reflects the Army’s Defense-inDepth (DiD) strategy. The resulting architecture design uses
IA devices and functionalities that will be placed
appropriately at strategic locations in the communications
networks and the information systems. Additionally, such
architecture will place the information systems at their
appropriate networks and enclaves and ensure their physical
separation by their relative classification levels. The
Architectural Engineering methodologies will also assist in
early identification of issues and gaps such that there will be
ample time for their resolution.
The Modeling and Simulation (M&S) engineering will put
to test the developed architectures. This discipline is used to
confirm the architectural design and the decision support
through quantitative analysis. Using modeling tools, such as
the JCSS and/or OPNET, the IA devices and functionalities
will be modeled in ways that reflect their real performance
and behavioral characteristics. The modeled IA objects will
be inserted into the modeled architectures, and then will
participate in simulations runs under various traffic and
environmental conditions. Results of the simulation runs
will provide relatively realistic quantitative information
regarding the network performance associated with the
individual or aggregated IA objects.
Further, each
individual IA object will also be drilled down to provide
various levels of performance details, relative to its
configuration.
The Decision Support methodology is part of the
evolutionary process of the architecture development
process. It provides the capability to perform comparisons
and analyses of architectures, and assist in decisions
regarding the selection of architecture based on various
considerations or criteria. Any architecture that includes IA
would be excellent candidates for analysis using the
Conditional Based Maintenance Plus (CBM+)
Communications Architecture Modeling and Simulation with Decision Support Technology
Page 6 of 7
Proceedings of the 2009 Ground Vehicle System Engineering and Technology Symposium (GVSETS)
Decision Support Tool. IA architecture implementation is
complex due to the numerous implementation variables;
selection and placement of protective and defense
mechanisms, their relative network/throughput performance,
and cost considerations, are just a few variables that are
worth mentioning.
In conclusion, the Architectural engineering, Modeling and
Simulation (M&S), and Decision Support disciplines are key
in the evolutionary process of development of
communications and information architectures with
integrated IA functionalities. They clearly provide the most
effective engineering methodologies, DoDAF compliance
and are effective in providing the necessary developmental
tools and solutions.
SUMMARY
We identified, established, and leveraged expertise across
CBM+ Community and CERDEC subject matter expertise.
We are leveraging the existing system of system (SoS)
architectures and modeling and simulation. Both areas are
critical in developing CBM+ communications architecture.
We have established communications architecture web
portals (e.g. architecture analysis methodology, gaps, issues,
DSS hierarchy) to facilitate communications among
stakeholders.
Currently, we are coordinating issues,
analyses, reports and architecture evolution with
stakeholders, and working with them to close the gaps.
REFERENCES
[1] W. Lucchesi, “Final CERDEC S&TCD CBM+ Brief to
Mr. Terry Edwards, SES - Communication Architecture and
Analysis Initial Kick-Off Meeting Plus”, 2009
FUTURE RESEARCH
The areas of future research include the following:
(1) Application of Measurement and Classification Theory
to the Architectural Engineering Domain – System of
System (SoS) Enterprise architecture (EA) engineering is a
relatively new field. As such, an architectural quality
taxonomy using proven measurement and classification
theory needs to be developed and validated. This taxonomy
would provide the insights (i.e., data, information,
knowledge, and wisdom transformations) to support the
development of appropriate quality and process metrics to
measure (i.e., completeness, consistency, correctness,
complexity.) the AS-IS → TO-BE architectural evolution.
(2) Architectural Product Metrics – A common set of metrics
to measure the quality (i.e., complexity, consistency,
completeness, etc.) of the various artifacts is needed. In
addition, metrics which capture the reusability, extendibility,
complexity, cohesion, coupling and interdependencies would
be valuable. Similar process metrics should be developed.
3) Decision Processes, Methods and technologies. – Further
studies for applying advanced decision support technologies
to the SoS EA are needed to model and validate the
numerous types of decisions that are made during the EA
life cycle. Furthermore, the traceability to the architectural
metric and the fundamental purpose(s) are critical to the
success of the EA.
[2] S. Butcher, J. White, “Ground and Aviation Node
Baseline Brief”, 2009
[3] S. Butcher, J. White, “Army Integrated Logistics
Architecture (AILA) Architecture Assessment Brief”, 2009
[4] S. Butcher, J. White, “CBM+ Overview CERDEC
Kickoff meeting to discuss CBM+ Communication
Architecture Development Brief”, 2009
[5] A Decision Support System (DSS) based methodology to
support the engineering of net centric architectural solutions,
Walter M. Lucchesi, MILCOM 2005.
[6] A Study of the Processes by which Enterprise
Architecture Decisions are made, Utako Tanigawa, 2004,
PhD Dissertation NSU
[7] E. Turban, “Decision Support and Expert Systems”, 1995
[8] T. Saaty, “The Analytical Hierarchy Process”, 1980
[9] T. Saaty, “Fundamentals of Decision Making and
Priority Theory”, 2000
Conditional Based Maintenance Plus (CBM+)
Communications Architecture Modeling and Simulation with Decision Support Technology
Page 7 of 7