Break The Stove-Pipe Stranglehold On Capability With An Open Systems Approach

Introduction

It is a fact that when ADF programs run late and over budget there are capability shortfalls and the inevitable strong criticism in the press that discredits the procurement process. There are many reasons for an overrun, however one significant issue is the stove-piped closed nature of programs that makes capability integration difficult to achieve.

Vertically integrated programs in any enterprise including the ADF tend to suffer from tunnel vision and contribute to the formation of stove-piped silos of excellence. It is too easy to lose focus on the future and concentrate on the immediate problems at hand related to capability delivery. This can be avoided by establishing an open systems approach derived from the fundamentals of good system engineering practice as already demonstrated by a number of international defence agencies.

The concept of an open system has come about because of a drive in the commercial and military markets towards standardisation by both technology buyers and technology sellers. From the buyer’s point of view, open systems provide the ability to select from a wider range of interoperable products and solutions - mixing and matching these to best meet the buyer’s overall needs and budgets. From the seller’s point of view, an open systems approach can maximise mutual benefit with other sellers through collaboration in an open competitive market that is focused on meeting the buyer’s needs, thereby providing a greater overall opportunity.

In order to understand the rationale behind the adoption of an OSA, one first needs a clear definition.

Reference [1] provides a welcome insight regarding the specification of open systems to improve system interoperability and flexibility in defence information and technology systems. It proposes a definition of an open system and an open standard and provides a list of very useful resources – in particular the five principle based Modular Open Systems Approach (MOSA) that has been in use by the US DoD since 2004 [2].

A key aspect of being truly “open” requires that there are no barriers to integration by third parties. This concept is often misunderstood especially when vendors make claims about the openness of their solution—which may the case in terms of the technologies used—but offer no means for third party integration.

The key advantages offered by an OSA derived from [1–3] are summarised as:

• Provides the framework to develop agile, robust, and adaptive systems and integrated architectures needed for assembling a joint, network-centric, and reconfigurable force.
• Allows vendor independence enabling a “best of breed” selection to maximise capability.
• Modular elements can be combined for a cohesive purpose, enabling system developers to synthesise a system using an inventory of pre-implemented elements. This allows elements to be swapped out and replaced with other elements of superior capability as required to address rapidly evolving threats and requirements thereby future-proofing the solution.
• Eliminates vendor lock-in that can otherwise significantly constrain maintenance and upgrade. Vendors will be more motivated to perform knowing they can be easily replaced.
• Improves system interoperability and flexibility.
• Reduces development cycle time because systems can be built with “plug and play” building blocks that use open standards interfaces.
• Reduces total cost of ownership - users can be trained across a range of systems as they are based on open standards and allows the ability to use materiel from multiple competing vendors when cost effective.
• Allows effective integration and/or retrofit of earlier increments with later increments within an evolutionary acquisition context.
• Promotes reuse of functional components, which creates commonality and mitigates the risk of obsolescence.

Issues With Australian Land Programs

This section identifies a number of ADF LAND projects that are clearly interrelated and lists some of the potential stove-pipe issues. Reference [1] warns that “the current landscape of information and technology systems in the Australian Defence Force (ADF) consists of many monolithic or stove-piped sub-systems with inefficient and awkward integration into the larger infrastructure. This situation could continue under the ADF’s focus on procuring Commercial Off-The-Shelf (COTS) and Military Off-The-Shelf (MOTS) products, which are often encumbered by proprietary technologies and arms traffic restrictions, resulting in vendor lock-in for through life support.”

Adopting an OSA within the scope of these programs will improve the ability to support and upgrade these systems to meet the evolving requirements of the ADF throughout the capability life cycle - breaking the stove-pipe stranglehold.

A Sample of Relevant Programs

A sample of interconnected ADF LAND programs is illustrated in Figure 1.

A key feature is that these programs have unclear or overlapping boundaries—represented by the overlap and dotted lines in the figure—resulting in unclear responsibilities and requirements. This constitutes a significant integration risk to the ADF and the contractors involved. The result is not only higher cost but also loss of reputation.

LAND 2072 Phase 3 seeks to provide the mobile elements of the battlespace communications system for army. This includes communications equipment for dismounted soldiers and vehicles. The scope includes new LOS and BLOS transmission equipment and the necessary switching and routing software and hardware including an access interface for current and future applications. It also requires interfaces to the deployed wide area and local area systems being provided by LAND 2072 Phase 2B and JP2030 with interfaces back to the strategic networks being provided by JP2008 and JP2047.

LAND 75 provides the principle battle management system (BMS) for the ADF land forces. It has been implemented as a vertical stove-piped integration model right from the BMS application itself through the middleware layer including switching and routing all the way down to the physical radio. The identification and opening of the key interfaces through this vertical structure will be important to allow the integration of new applications, transmission bearers and other services necessary to meet the network centric capability goals.

The vehicle programs LAND 121 Phase 3, 121 Phase 4, 400 and 500 will provide their own internal systems but will need to identify and open interfaces to support hosting of the hardware and/or software equipment being provided by LAND 2072 Phase 3 and LAND 75.

JP2008, 2047 and LAND 2072 Phase 2B respectively provide the satellite terrestrial infrastructure, the fixed terrestrial communications network and the deployed battlefield telecommunication network. These particular programs have reasonably well defined boundaries with open interfaces operating at the lower layers of the communications service protocols. Therefore they do support interoperability and are capable of integrating future services. One example illustrating openness is the Tactical Interface (TACINT) concept that connects the fixed networks through the satellite system to the deployed networks.

The above is a subset of issues, there are many more key interfaces across the various systems that are required to deliver the overall integrated capability. Each interface needs to be identified, understood, defined and assessed to determine its impact on current and future integration efforts. Those with high impact should be designated as requiring to be “open” with clearly defined and open standards. Section III will discuss more details about how other international defence agencies are using an OSA to address these issues.

Problems Can Arise

Without clear direction and requirements regarding an OSA, vendors will not necessarily implement these standards but rather provide least effort solutions and will deliver only to the contract requirements. This could hide key interfaces from the ADF that should remain open making cross-program integration efforts very challenging and expensive to achieve. Vendors may be inclined to make claims regarding the “openness” of their solutions, however if integration cannot be performed unencumbered by third parties, the claim is false and the vendor has achieved a locked-in position they can exploit.

THE INTERNATIONAL TRENDS

This section describes some of the key factors that support an effective use of an OSA in ADF CIS programs. We describe the general trend to standardise and then provide specific examples with the UK MOD and NATO Generic Vehicle Architecture (GVA), the US DoD MOSA and the NATO C3 Technical Services Taxonomy. This provides a summary of some important international initiatives and serves as a framework to identify the key attributes that could support the OSA in the ADF. The clear message emerging from this significant body of work is that serious effort is being applied to break the stranglehold on capability by applying an open systems approach.

A General Trend to Standardise

A fundamental approach in systems engineering is to decompose a higher level system into a number of modular subsystems and define the internal and external interfaces. In military systems, the need for interoperability for information sharing across platforms such as ships and aircraft led to the standardisation of interfaces and concepts such as network centric, or network enabled warfare. Two important examples are the tactical data links (TDL) Link 11 and Link 16. The requirements for these TDL interfaces are well documented in a range of military standards and can be considered “open” because they are widely accepted and used by competing vendors and system developers. Typically country defence agencies establish a certification and test facility where products developed to the required standards can be certified for use. Once this is completed, cooperating platforms are able to exchange a wide range of tactical data even though the equipment has been produced by several different vendors. This approach and outcome captures the essence of an OSA.

The UK MOD, EDA LAVOSAR and NATO GVA

Throughout the period from 2011 to 2015 A number of important OSA initiatives were undertaken relating to military land vehicle architecture. These all had a common thread driving towards modular open systems to achieve the associated benefits.

The opening paragraph of [4] states that the purpose of the standard “is to enable the MOD to realise the benefits of an open architecture approach to Land platform design and integration” and “to improve operational effectiveness, reduce integration risks, and reduce the cost of ownership across the fleet, by mandating and applying the appropriate interface standards and design constraints”.

Reference [5] discusses the architecture and standardisation efforts to achieve a Common Vehicle Architecture (CVA) and identifies a key concern with the proliferation of stove-piped electronic systems that drive an increase in size, weight, power and cooling (SWaP-C). The reference states: “Today the truck is full, and when the need arises to add new capability, the first question we face is: What can we remove in order to accommodate the new sub-system?” The reference concludes with a recommendation that a CVA is necessary in Australia to address the needs of future land forces, clearly reinforcing the benefits of an OSA as a means to achieve the architecture outcome. A similar position can be stated for the more extreme case associated with soldier systems.

In 2013 the European Defence Agency (EDA) commissioned a study of the technical and financial aspects of a common European Land Vehicle approach to Mission System open architecture (LAVOSAR). A final report [6] was produced in 2014. The results of this study serve as guidelines for the areas to be standardised and to support the development of the NATO Generic Vehicle Architecture (NGVA). The report provides an excellent catalogue of the important issues, relevant standards and technologies appropriate for vehicle systems and an OSA.

The aim of the NATO standardisation agreement [7] is to define a NATO NGVA standard “to enable the member nations to realise the benefits of an open architecture approach to land vehicle platform design and integration, especially in regard to the vehicle platform electronic and power infrastructure. The intended benefits for each nation are improved operational effectiveness and reduced integration risks and cost of ownership by mandating and applying the appropriate interface standards and design constraints for procurement”.

The US DoD MOSA

Since 2004, the US DoD has mandated the use of a Modular Open Systems Approach (MOSA) for acquisition programs. Reference [8] defines MOSA as “the basic elements to capture the benefits of an open architecture and an open business model. The essence of Open Systems Architecture (OSA) is organised decomposition, using carefully defined execution boundaries, layered onto a framework of software and hardware shared services and a vibrant business model that facilitates competition.” MOSA is composed of five fundamental principles:

• modular designs based on standards, with loose coupling and high cohesion, that allow for independent acquisition of system components;
• enterprise investment strategies, based on collaboration and trust, that maximise reuse of proven hardware system designs and ensure we spend the least to get the best;
• transformation of the life cycle sustainment strategies for software intensive systems through proven technology insertion and software product upgrade techniques;
• dramatically lower development risk through transparency of system designs, continuous design disclosure, and Government, academia, and industry peer reviews; and
• strategic use of data rights to ensure a level competitive playing field and access to alternative solutions and sources, across the lifecycle.

An effort is underway in the US with the Vehicular Integration for C4ISR/EW Interoperability (VICTORY) program. Based upon OSA principles, the key aim of VICTORY is to reduce SWaP-C requirements of platforms, and to accommodate system modification and upgrades.

The NATO C3 Technical Services Taxonomy

Reference [9] provides a comprehensive framework and definition of a suite of technical services that expresses the requirements for a set of related software and hardware functionality relevant for the implementation of NATO CIS solutions. This has been developed to overcome issues associated with “a patchwork quilt of systems, applications, services, standards, vocabularies and taxonomies. Even simple English words, such as service or capability, have become highly ambiguous. As a result of this stove-piping, NATO now faces a very complex CIS fabric that is not interoperable and attempts to solve this problem are often hampered by lack of mutual understanding.” These technical services “provide the foundation for the NATO Network Enabled Capability (NNEC).” A high-level diagram illustrating the taxonomy framework is shown in Figure 2.

The framework is broken down several more levels forming a comprehensive layered structure of building block technical services. Each service is then defined to provide a basis for a clear understanding on the scope or capability it provides. The development of this taxonomy is ongoing with the specification of functional and non-functional requirements for each service along with the identification of protocols and standards for the service interface.

This structure allows NATO procurement activities to clearly define the services needed in a modular layered approach. Interfaces between layers can be defined as appropriate to the program of work in a way that facilitates initial capability introduction, while also enabling subsequent upgrade or replacement with minimal impact on the surrounding layers.

An Opens Systems Approach Proposal

This section proposes a high level model based on the NATO C3 technical services framework. A generalized structure such as this could be used as a reference model when developing program requirements and provide a systematic means to identify and allocate all the services and equipment needed to meet the functional and performance requirements of the capability needed. This could assist in determining key interfaces and boundaries by using the structured layers and so be a useful tool to break the stove-pipe stranglehold on capability.

The Platform Concept

A platform concept is a general term for a system or device to which third parties can add applications or services to deliver a specific capability. One good example is the Android phone. Some defence agencies have even considered the development of the app store concept where Defence users and developers could implement new apps for example to address new capability areas or better manage emerging threats. The concept is that these apps are fully implemented by third parties completely independently of the original platform manufacturer.

Using an OSA, Defence could manage its procurement programs to deliver open platforms for soldier and vehicle systems that could keep up with new capability demands and be more future-proof.

A Model for Defence Programs

Reference [2] advises “The MOSA is not a panacea, and programs shouldn’t blindly follow the concept. Programs should make a business case for implementing open systems solutions after carefully analysing capabilities and strategies contained in capability development documents and their acquisition strategy to ensure they lend themselves to the development of an open architecture.”

There are arguments against open systems in cases where the vertical integration is able to be completed by a single vendor cost effectively and ensures a successful end-to-end integrated capability. This needs to be considered carefully to balance the needs to delivering a capability to efficiently meet a near term need in the case where the system is relatively isolated from other associated programs and on-going interoperability with joint, allied and coalition forces is limited.

However, even in such cases an OSA may identify certain key interfaces that should be acquired as open that allows a level of future horizontal integration supporting interoperability and future capability extensions.

An initial high level reference model supporting OSA is proposed in Figure 3. It is based on the NATO C3 Technical Services Taxonomy specifically around CIS capabilities. A sub-set sample of typical equipment and capability mapping is shown for illustrative purposes. A real case of mapping is likely to have many more elements. The model allows equipment items to be identified as either User Equipment, Information Systems Equipment or Communications Equipment. It allows the associated software to be organised and managed in structured layers alongside the relevant equipment layers.

The comprehensive definition of terms provided by the NATO Taxonomy can be used as a reference to place capability functionality within the appropriate layer. For simplicity, much of the detail is not shown in Figure 3. Some functionality may cross a number of layers and not all the service definitions would be necessary for a specific functionality. Reference [9] illustrates that some functionality will have elements at most layers, for example information assurance (IA) and service monitoring and control (SMC).

Benefits the Model Could Realise

During the early program or project definition phases a suite of Capability Options Documentation (COD) is generally produced including:

• an Operational Concept Document (OCD) that expresses the need in warfighter terms,
• a Functional and Performance Specification (FPS) that expresses the need in engineering terms that can be procured, and
• a Test Concept Document that identifies the means by which the capability would go through a test and evaluation program to achieve acceptance into service.

The OSA reference model would provide a framework upon which the desired equipment, services and overall functionality of a program or suite of associated programs as detailed in the COD can be systematically mapped. Further analysis may identify missing layer functionality that needs to be included and also it will assist in the identification of key interfaces that should be defined as open. With such an approach, the benefits of OSA that are listed earlier could be better realised.

CONCLUSION

This paper discussed the general concept of an OSA within the context of ADF CIS related programs. It has provided an overview of the current state of the art with the examples of what international Defence agencies are doing to achieve their capability goals. The paper discussed a set of specific ADF programs and potential issues and we propose that an OSA model adopted early as part of project definition would provide beneficial outcomes for the ADF to maximise its return on investment. There is no doubt that the body of evidence is clearly in favour of an OSA to capability enhancement resulting in stove-piping in the ADF being consigned to its rightful place as an historical footnote.

ACKNOWLEDGEMENT

The authors acknowledge the positive efforts of the DSTO team with their useful report [1] advocating an open systems approach for ADF procurement. That work provided a foundation for this paper. This has been extended further by referencing specific ADF programs and issues, commenting on more recent international OSA efforts and proposing a platform concept reference model.

References

Author

Arthur Ollett is a Technical Expert in Communications Systems at Thales. He has over 25 years of experience in electronic systems development and integration and specialises in communication system solution architectures.

John Coleman is a retired NZ Army officer. He has over 25 years of experience in the development of and procurement of capability for the NZDF and specialises in the integration of capability into operational mode.