Achieving Force-Level Interoperability by Design
Written by Ken Haffner and Dave Leedom
MIT 2010 Volume: 14 Issue: 1 (February)
Multiple factors—budget limitations for legacy systems in ”caretaker” status, reduced time to implement and deploy system upgrades, extended deployments, and insatiable desires to field systems before they are truly integrated and the capability adequately demonstrated—conspire to create a tyranny of challenges to maintaining interoperability between legacy and new capabilities.
The Navy has responded with increasingly effective end-toend testing and work-around techniques. Yet the performance problem has increased as fast as or even outpaced solution deployment. Testing has proven necessary, but is insufficient; it is clear we must give much greater priority to interoperability performance earlier in the acquisition lifecycle, during the requirements and design efforts, as well as improve it through test and analysis.
During several recent fleet exercises, the Navy’s Second and Third Fleet observed rising combat system/data link interoperability issues. Fleet operator readiness and training to handle these new issues has not kept pace. The fleet’s concern prompted corrective action for some of the more problematic interoperability issues. An Interoperability Solutions Group was formed and estimated the cost of correcting the top five problems to be in excess of $217 million. These costs would have been much less had these issues been resolved earlier during systems development.
Lack of overarching interoperability requirements, inconsistent design standards, insufficiently documented requirements, inconsistent specification interpretations and errors in individual system implementation lead to the inability of forces to efficiently and effectively share information. Issues related to interoperability tend to be extremely complex, with the complete understanding of “cause and effect” impossible to achieve from a single system perspective.
Joint level consideration is even more complex, for example in the introduction of the Joint Strike Fighter and the associated requirement for transport of data across multiple networks. Our current focus is on Navy systems while we remain compatible with joint directives and standards. Individual system capabilities are compromised by internal flaws, which may also adversely impact other systems and contribute to secondary detrimental effects across the force. The investigation and resolution of these issues requires the support of system experts covering all related systems.
DECISION REFERENCE MODEL
Force-level interoperability for the Navy has historically been validated through test and assessment. With the development of distributed networked test venues and force-level assessment methods, many interoperability issues have been reliably identified, described sufficiently for work-around when possible, and root-caused for subsequent solutions. In spite of this success, system development and upgrades continue to produce interoperability issues—sometimes repeating issues previously identified.
While these issues are detected during subsequent test and assessment, it is at a point in the acquisition cycle that leaves the definition of limitations and work-around mitigation to the operators as the only solution compatible with schedules and budgets. Systems with interoperability problems continue to be delivered to the fleet, degrading rather than enhancing situational awareness and placing an increased burden on operators who must try to overcome the situational and operational problems created.
Interoperability must be more effectively addressed during system development to assure sustained situational awareness improvements. Naval Sea Systems Command, charged with strike force interoperability, initiated a study to recommend how interoperability assessment could be used to enhance system acquisition and development.
That study, conducted collaboratively with the Space and Naval Warfare Systems Command’s chief systems engineer for command and control, NAVSEA technical warrant holders and other warfare system and Tactical Data Link subject matter experts, resulted in the following recommended solution:
- Use of a design reference model (DRM) to complement or modify pre- and post-acquisition requirements to clarify direction regarding interoperability issues.
- Adaption of systems engineering technical reviews (SETR) to address interoperability at key system technical reviews and milestones.
The Naval SETR process commonly used by system commands should be flexed to explicitly address interoperability in greater detail during system acquisition and design.
The proposed solution addresses the problem of “context,” “direction” and “audit.” Until strike group interoperability requirements are defined, interoperable environment context is described in the form of a DRM. Providing information about the interoperable environment, physics and legacy architecture improves the developer’s understanding.
In addition, specific implementation practices derived from lessons learned during test and assessment activities are codified in adjunct “surface warfare standards” to augment existing military standards and provide a more consistent and compatible implementation. Direction from the Department of Defense and chairman, Joint Chiefs of Staff (CJCS), is augmented to ensure that program managers and developers address interoperability processing in specific ways and in specific places in pre- and post-acquisition documentation with special attention paid to unavoidable interoperability challenges.
Finally, interoperability experts on the SETR team audit interoperability aspects of system design during key design reviews, referencing the augmented acquisition and design documentation. They assure adherence to military standards and adjunct standards and use documented information as context for questions, explanations and discussions. Audits can also result in estimates of interoperability risk for the system and force, with explanation that feeds future reviews and the test and assessment process as currently defined. While subject matter expert audit is already defined in the Naval SETR process, adaptation of existing DoD and CJCS directives and instructions to support audits for “interoperability experts” is still immature.
Note that this is a long-term strategic approach. If implemented, effects of its features will only be measurable after acquisition and contractual processes have invoked its use.
OPERATIONAL CONTEXT
The interoperable operational environment is complex, and system performance is complicated by the following factors:
- Inherent uncertainties, lack of continuity in sensor data, and imperfect communication stability.
- Idiosyncrasies of legacy system processing and ambiguity when similar processes are performed concurrently by various systems on different platforms.
- Legacy communication architecture that permits concurrent transmission of the same information over different paths to the same platforms, resulting in race conditions and inducing ambiguity and conflict.
Understanding the interoperable operational context greatly helps engineers create designs that mitigate the above factors.
The proposed DRM describes the interoperable operational context, including example scenarios, force communication architectures and how these architectures potentially affect interoperable performance. These scenarios and architectures are used in test assessment, are validated through continuous comparison with fleet experience, and have demonstrated an ability to create interoperability problems similar to those experienced in actual operations. Their use provides operational relevance to the assessment process and continuity between design and test assessment.
The DRM is intended to be used in acquisitions to improve interoperability understanding among design engineers, many of whom may have never even seen a warfare system in use. The DRM also provides reference for interoperability subject matter expert discussions during key system reviews.
DRM scenarios are described in terms of the processing stress they induce in an interoperable force. Descriptions are sufficiently tutorial to inform the reader of the types of problems that have been observed with the scenario segments so that acquisition professionals and developers can better understand these effects.
DRM communication architectures (usually multiple communication networks) are described in terms of the variable combinations of platforms, warfare systems and subsystems that have demonstrated interoperability challenges during test and deployment. These descriptions inform the acquisition professional and developer of problems with the legacy networks and effective procedures for their avoidance.
DIRECTION AND AUDIT
Direction has two parts: the adjunct surface warfare standard (SWS) and the augmentation of existing DoD and CJCS instructions for documentation (“instructions”). Direction to acquisition program managers and developers is necessary because the Net Ready Key Performance Parameter (KPP), which subsumed the interoperability KPP, says little explicitly about interoperability of tactical information exchange.
CJCS direction is aimed at creating new capability and says little explicitly about preserving existing capability. Acquisition program managers and developers need to be directed at the tactical information exchange and “compatibility” part of capability creation so support for those aspects can be planned in budgets and schedules.
SWS are derived from lessons learned during interoperability test and assessment about misinterpretations, misunderstandings and omissions during system development. Lessons learned can be generalized as standards to complement military standards and CJCS-required documentation during acquisition and development.
These SWS—which are consistent and compatible with existing Navy, DoD and joint standards—include, for example:
- Generalized implementation rules that promote better automated interoperability to reduce operator interaction/burden.
- Human factor design guidelines to avoid the demonstrated pitfalls of prior interoperability implementations.
- Alerts to potentially redundant/conflicting processing areas with other systems.
In addition to standards, addressing force-level interoperability information exchange should be required in the information support plan (ISP), systems engineering plan, test and evaluation master plan and other acquisition and development documents, so that interoperability processing can be easily found in descriptions of system design. The ISP is already complex, but force-level information exchange and processing is the root of current interoperability problems; it must be better defined and addressed by systems engineering during acquisition and development.
The goal is to ensure that this information is addressed while minimizing additional impact on development cost and schedule. What to include and where to include it in key documentation is the subject of current research.
Audits conducted during SETRs are intended to assure conformance with prescribed standards. They are to be performed at key milestones and reviews by interoperability experts on the SETR assessment team. The SETR can focus on those areas of interoperability processing using the SWS and the added direction for interoperability included in key documents. SETR participants will use the DRM to provide the operational context and examples to illustrate interoperability issues that must be addressed by the design.
SOLUTION INTO ACTION
The proposed solution is being put into action. Navy system commands are working with the assistant secretary of the Navy for research, development and acquisition to revise acquisition and design documentation to address interoperability shortfalls. We continue to refine DRM, SWS and audit questions to provide information and context to developers so better decisions are made during system implementation. Interoperability is being explicitly included in system engineering technical review events for applicable systems.
Audit questions are couched as an “interoperability checklist” for use during key audits. Subject matter experts providing SETR expertise will be available as necessary for design discussions outside of key reviews.
These measures are essential to introducing more interoperable systems to the test and delivery process, cutting the cost of error correction before deployment, reducing operator workload in operations, and producing more effective means for the commanders to command and control forces. It will also leave a more interoperability-knowledgeable workforce in its wake. ♦
Ken Hafner is chief systems engineer for command and control, SPAWAR, and Dave Leedom is senior systems engineer, intelliSolutions, in support to SPAWAR.