top of page

IAC: Integrated Architecture Capability Tool

Downloadable pdf file

'Right Click'

Part 2



One beneficial byproduct associated with having both operational doctrinal and unit data in a matrix format is the ability to merge such matrices in a manner that creates the ability to contrast doctrinal operational concepts with a unit’s actual Standing Operating Procedures (SOP) or ‘business practices.’


Operational doctrine is defined by both the Unit/Force Structure x Task (AULT or UJTL) and Task x Information Exchange (IE or ReMIT) matrices while the Unit x IE/ReMIT matrix defines the operational unit’s SOP/Business Practices.  Both the doctrinal matrices can be joined through the Task parameter, which is common to both.  Such a merge of the two matrices result in a Unit x IE/ReMIT product…which can then be contrasted with the unit SOP Unit x IE/ReMIT matrix (Figure 3).  Where the two matrices do not match defines a ‘gap’ between proposed doctrine and a unit’s operational SOP.


Figure 3




The generation of IERs are essential to ensure that all doctrinal commander’s operational needs/ requirements have been identified but once that has been accomplished, IERs no longer have any real relevancy and must thus be ‘converted’ into a singular ‘IE’—information exchange—to create an operational traffic/bandwidth profile for true System and Network analysis.


As defined, an IER identifies the information exchanges that must be executed to meet the commander’s needs/requirements.  That does not, however, mean that an IER is the actual information exchanged.  As noted in the previous example of Figure 2, while 2,352 IERs were generated by the IAC algorithm to ensure all operational needs/requirements were met (with traceability back to the operational requirements impacted by gaps) and to identify all system combinations for information exchanges, only one FRAGO would actually be transmitted and received, not 2,352. 


Thus, from an operational traffic/bandwidth profile perspective, 2,351 of the SuperSet IERs are ‘redundant.’  These redundancies can easily be eliminated by ‘bundling’ the IERs by Sender/Receiver/IE/Mode/Format/ System/AUTL and ‘collapsing’ it into the single ‘Information Exchanged’ (IE) element (Figure 4) where a single Sender x Receiver exchange of a specific IE made in a specific Mode, in a specific Format over a specific System will serve to meet multiple Task needs/requirements.

Figure 4


In addition to IE Mode and Format parameters, all 570 IEs have also been assigned, based on research, Data Rate and Property parameters as noted in Table 10. 

Table 10


Thus, for each IE format, there is an associated data rate as it would apply to an infantry battalion (used by IAC as the ‘baseline’ unit): Frequency of Occurrence, Speed of Service, Data Size, Data Rate/Duration.


To increase the model’s bandwidth fidelity, a ‘C4ISR functional weight’ has been assigned to each force structure unit/entity, the purpose being that as one increases in echelon of command and control (C2), generally the size or duration of a IE would correspondingly increase.


A case in point would be the Commander’s Guidance IE.  A VTC of such guidance between an infantry battalion commander and one of his company commanders may be five minutes in length, whereas a VTC of such guidance between a division commander and one of his IBCT commanders might be fifteen minutes in duration.  Thus, if we establish a C4ISR Functional Weight of ‘1’ for an infantry battalion, a C4ISR Functional Weight of ‘3’ would be appropriate for a division force structure unit/entity.  Consequently, as a function of this variable, the data rate values are increased or decreased, if necessary, as a result of the force structure unit/entity ‘C4ISR Functional Weight.’


Having now taken the ‘bundled’ IE of Figure 3 and assigned to it the properties of Table 9 (adjusted by the ‘C4ISR functional weight’), the IAC result is a fully integrated and unique set of information exchanges that can not only be used for operational, system, technical and network analysis but also ‘adjusted’ as required to create, in near real time, new outputs.


Note: It is emphasized that, at this point of development, the Traffic/Bandwidth Profile is ‘Operational’ and not ‘Network’ in design; ie. the current IER parameters will assign size, duration and frequency values associated with specific operational products—OPORDs, images, VTCs—but will not include additional system or network ‘add ons’ such as system synchronization, security/encryption, tunneling, etc.




Condition Based Maintenance Plus (CBM+) is the application and integration of appropriate processes, technologies, and knowledge-based capabilities to improve the reliability and maintenance effectiveness of DoD systems and components. At its core, CBM+ is maintenance performed based on evidence of need provided by Reliability Centered Maintenance (RCM) analysis and other enabling processes and technologies. CBM+ uses a systems engineering approach to collect data, enable analysis, and support the decision-making processes for system acquisition, sustainment, and operations.


The Services have been directed to incorporate their CBM+ strategies into appropriate guidance and directives to ensure implementation in organic (i.e., DoD in-house) maintenance capabilities and operations as well as in commercially supported DoD systems and programs for both new and legacy weapon systems.


The envisioned CBM+ operational environment will occur from the individual component to the platform level, in training courses, and the deployed environment.


Initially, Defense Acquisition Programs will exploit CBM+ opportunities as elements of system performance requirements during the design and development phase and throughout the life cycle.


CBM+ related studies and analyses should have three components:


  • Data – vehicle & system modeling

  • Operations

  • Transport


Overall, there are four primary assumptions that impact CBM+ Bandwidth:


  • MTTF = ‘Deadline’ (no CBM+ data)

  • MTTR = ‘Deadline’

  • ‘Normal Maintenance’ = max CBM+ data

  • Battle Damage = ‘Deadline’ = Reduced CBM+ data


Figure 5 represents how CBM+ data could be generated to serve as IAC data input.

Figure 5




An additional architectural modeling feature that can be added is the inclusion of grouping the Force Structure by Subnets, along with assigning waveform functions to those Subnets (Table 11).


Table 11




Architectures not only have an impact on a unit’s ability to meet its mission requirements but, also, on organizational budgets and vehicle capabilities. 


Provide an underlying system dbase of antenna, size, power, LIN, $cost, etc, IAC can execute a ‘Trade off’ Study to evaluate optimization of various vehicle configurations (Figure 6).

Figure 6




With the completion of a fully integrated, overarching architecture, the next step would be to geospatially display that architecture (Note: entity coordinates can be linked through a matrix in IAC) for connectivity and range analyses.  A TRADOC AIMD application called CAVT—CADIE Architecture Visualization Tool—does just that.


Note: CAVT is an AIMD tool and it is only the intent of this paper to highlight that IAC has the capability to interface with CAVT to perform as described below.


CAVT started as a laptop based interactive visualization and analytical tool (Windows .NET application) designed to express the details of an architecture’s force structure transport communication infrastructure and provide short term analysis based on distance and geography to aid in resource management decisions.  CAVT does not create architectures, it can only visualize an input architecture.


Along with a fully integrated architecture development process, IAC was specifically designed to interface directly and seamlessly with CAVT.  This allows CAVT’s transport communication infrastructure analyses to be accomplished at any level, be it singular entity (Soldier, platform) or node consolidation (CP—command post, TOC—tactical operations center, HHQ—higher headquarters).


CAVT focuses on the needs of the architecture, analysis, network management, M&S and testing communities:


  • Provides the design details of the waveforms down to a specified level of granularity.

  • Outputs data statistics associated with resource distributions for a variety of architectures:

o   Waveform assignments

o   Hardware distributions

o   Frequency Plans

  • Provides capability to import current force communications infrastructure to compare and contrast with Future Force resource allocations.

  • Can add additional resources to provide alternate CoAs (courses of action) to resolve connectivity gaps or excess capacity demands.

  • Provides “Back of the Envelope” calculations and/or analysis for performance context:

o   Range

o   Connectivity btw Sender/Receiver Nodes

o   Routing Paths

o   Convergence Points

o   Capacity (‘Pipe size’)

o   Network Affiliations (‘Subnets’)

o   Operational Requirements (‘Need lines’)

  • Is capable of post-processing data collected during test events to visualize the network dynamics that occurred.

  • Is a living architecture artifact that evolves with a Program’s baseline.


For each force structure represented by the architecture, there are four architecture views:


  1. Deployment view: provides operational context to aid in understanding waveform connectivity and waveform behaviors.

  2. Waveform view: shows high level attributes of waveform behaviors and their interconnectivity.

  3. Focused view:  isolates the specific waveform in question; provides greater operational context.

  4. Description view of specific waveform behaviors taken from waveform specifications.


CAVT includes a Resource Allocation section to quantify resource allocations for a chosen subset of operational platforms:


  • Channel assignments

  • Frequencies

  • Hardware


CAVT includes an Analysis Area to perform “back-of-the-envelope” calculations and to re-examine captured data from test events:


  • Short term performance analysis aids in understanding network behaviors and can influence resource distribution decisions.

  • Output from CAVT has been used in performance assessment reports on the 30-node WNW Test event in Charleston SC.

  • Provides the capability to import other current force communication infrastructure data for resource allocation comparisons by maintaining a large library of infrastructure data available for comparisons.


Current CAVT limitations are as follows:


  • Currently employs Google Earth as its data source; must eventually be transferred to Google Earth Enterprise for placement on the SIPRNET if it’s to be used for operational analyses.

  • Analysis calculations intended to aid the design of resource distribution and location, and not intended for detailed modeling and performance analysis of network (a feature that can be added later with the development of an interface with higher order network simulation models):

o   Link Margin calculations do not include losses due to foliage, atmosphere, urban structures, and fast fading effects.

o   Utilization and capacity estimates do not take into account the highly dynamic nature of the network.  Estimates are based on burst rate and

     route probabilities.

o   Routing heuristics are simplified  and are not representative of explicit protocol behaviors.

  • Given the lack of any architectural community wide methodology that provides a degree of standardization between architectural process, the seamless integration of authoritative data sources (beyond IAC) is limited.


Figure 7 is a CAVT screen capture example of connectivity links and system identification.

Figure 7




While it has been clearly demonstrated to create an integrated architecture, IAC can also be used to ‘reverse engineer’ collected data to either validate the architecture modeling process or to improve upon it.  Programs such as CERDEC’s S&TC ASEO ODCA (Operational Data Collection Analysis) or even special organizations such as Task Force ODIN (Observe, Detect, Identify, and Neutralize).  Data collected from such operations could be parsed and inputted into IAC to not only create a more realistic C4ISR model but such a model could then be used to improve on the structure and integration of said operation. 


Furthermore, the IAC/CAVT suite extends well beyond the purely engineering realm of architectural modeling and system analyses.  More importantly, this suite, given it is a Windows based application that runs on laptops, can literally be fielded to the Warfighter to execute a number of critical supporting operational tasks:


  • Task Organization Integration

  • C4ISR Resource Management

  • ‘Real Time’ Architecture Analysis

  • COA Analysis

  • Battle Damage Assessment

  • ‘Work Around’ Analysis

  • Coordinates can either be directly inputted through a matrix…or, even applied through BFT.

  • Electronic SOP: the Sender x Receiver x IE’ IAC OV matrix is, in essence, a unit’s SOP (Standing Operating Procedures).

  • ‘Automated’ Reporting System


Simulation Exercises (SIMEX) and Testing & Evaluation (T&E) are two other areas of IAC value.  Central to SIMEXs and T&Es are Mission Scenario Event Lists (MSEL) that essentially serve as ‘blueprints’ for how they are to be executed and evaluated .  Such MSELs can be designed with IAC SV-6s which, if linked to CAVT and Blue Force Tracking (BFT), would provide for an exceptionally powerful execution, tracking and evaluation and analysis tool (Figure 8).

Figure 8


In the end, fielding this suite to the Warfighter would be a ‘win/win’ for both them and the architectural/system/network engineer for the Warfighter obtains an application from the engineer with direct BC and operational network relevancy while the engineer obtains from the Warfighter the SME expertise of timely, direct data entry to perform more relevant analyses in support of the Warfighter. 




The IAC-CAVT Initiative—addresses not only customer architectural analysis needs but also has operational warfighter potential:


  1. Verify Architecture compatibility between ALL legacy and capability sets (CS).

  2. Identify ‘gaps’ between: Operational Requirements,  O/S and S/T architectures.

  3. Create Integrated O/S/T Architectural Views.

  4. Capability to create a Traffic Profile  (Background traffic).

  5. Capability to create a ‘dynamic Bandwidth Profile’ based on the Traffic Profile    [note: this profile is not inclusive of Network ‘overhead’ and thus is not an overall ‘Network Load’ profile].

  6. Overarching Battlespace ‘visualization’ of OA/SA/TA C4ISR Functions.

  7. Display time sequenced integration of information flow over network… ‘pipelines pulse’ (based on IE Matrix).

  8. Display Connectivity between Sender/Receiver Nodes.

  9. Display Capacity (‘Pipe size’).

  10. Display Network Affiliations (‘Subnets’).

  11. Capability to tie in Operational Requirements/Needs as a function of the Traffic Profile.

  12. Can be inclusive of CBM+ related Traffic/Bandwidth profiles.

  13. A Dynamic Traffic/Bandwidth Profile with integrated operational requirements will provide a ‘what if?’ analytical capability to determine ‘good enough’ and ‘cost associated’ impacts on operational needs given associated architectures.

  14. Incorporate as part of a ‘visualization suite’ to support operational, SIMEX and T&E.

  15. Commo/System ‘range fans’ – support CoA analysis.


Eventually, it is envisioned that IAC could be part of a suite of four components that will create a truly overarching and integrated architectural process (Figure 9) to perform the following:


  1. IAC to generate fully integrated DoDAF related Views that will create a dynamic Operational Load Traffic/Bandwidth Profile—in essence the ‘Operational Load.’

  2. Higher Order communications effects Network M&S to develop Network Load.

  3. CAVT (or similar) for Connectivity visualization.

  4. Seamless (relatively speaking) Data transfer in/out of CADIE which will serve as the Army’s architectural data repository.


Figure 9

bottom of page