Interoperability and Dependencies (I&D)

Overview

Almost all DoD systems operate in a system of systems (SoS) context relying upon other systems to provide desired user capabilities -- making it vital that interoperability needs and external dependencies are identified early and incorporated into system requirements. When identifying system requirements, it is critical to consider the operational and SoS context (see Systems Engineering (SE) Guidebook, Section 2.1 Application of Systems Engineering to Systems of Systems). These include, but are not limited to, physical requirements (e.g., size, power limits, etc.), electronic requirements (e.g., signature, interference, etc.) and information exchange/management (e.g., network, bandwidth, information needs, etc.). These system requirements also include interdependencies with other systems. For efficiency, systems often rely on either services provided by other systems during operations or reuse of system elements developed by other programs.

Interoperability is the requirement that the program???s system interact with other systems through transport of information, energy or matter. For example, an air-launched missile is required to be interoperable with its delivery platform(s). Information is exchanged. A mechanical interface secures the missile until launch and so on. Usually, interoperability involves external interfaces (see SE Guidebook, Section 4.1.8 Interface Management Process) and is essential for the creation of systems of systems (SoS). Every system is required to be certified interoperable before it is fielded. The Joint Interoperability Test Command (JITC) is responsible for this certification.

Dependencies are relationships between different programs that cause one program to rely on another program???s actions or products to successfully meet its requirements. As examples, a ship development program may require prototypes of mission modules being developed by another program in the course of developmental testing, or a weapon may depend on new sensor capabilities provided by another system. The program depends on the mission module or sensor program to enable it to meet its testing schedule. A schedule issue could occur if the needed prototypes are not available in time for the tests. A performance issue could occur if the designs of the two systems do not support the needed end-to-end capability.

The common element linking interoperability and dependencies (I&D) is the need for cooperation and/or coordination between separate programs. Two common ways to meet this need are memoranda of agreements (MOAs) and invited attendance at program technical reviews and other technical meetings. MOAs are agreements between programs that specify expectations as to performance, resources, management and schedules. Interchange between engineers and managers at technical meetings opens lines of communication, which permits risk identification and early mitigation.

Role of the PM and SE

The Program Manager (PM) is responsible for ensuring that the operational and SoS context for the system are well understood. The PM is also responsible for establishing required MOAs and managing relationships with other programs.

The Systems Engineer has the responsibility for ensuring all interoperability and dependency impacts are analyzed and collaborated with the appropriate internal/external stakeholders and translated into system requirements and design considerations.

Analysis conducted for the SoS contexts for the system -- where the system is dependent on other systems and where the system needs to interact with other systems -- enables translation of interoperability and dependencies (I&D) into system requirements. I&D requirements call for collaborative implementation approaches with external organizations, including identification, management and control of key interfaces. Areas of dependency and interoperability should be reviewed for risks to the program and plans made to manage and mitigate those risks. This review includes system interdependencies (e.g., a weapon may depend on new sensor capabilities provided by another system) and information exchanges with other systems required to support mission capabilities.

For efficiency, systems may rely on system elements developed by others for key functionality, either through services (e.g., weather information) provided by other systems or through reuse of system elements (e.g., engines, radios) developed by other programs. These contexts are analyzed to identify system requirements and risks, including actions needed by external parties (e.g., other systems or infrastructure) for the system to meet user requirements.

Additional DoD policy and guidance regarding I&D, summarized below, are directed at ensuring that systems work effectively with other systems:

Products and Tasks

Product Tasks
10-13-1: Document System of Systems (SoS) engineering activity
  1. Identify the particular system of systems (SoS) requirements and apply the DoD architecture framework (DoDAF) architecture in accordance with guidelines.
  2. Utilizing the architectural views, assess the ability of nodes and interfaces to adequately exchange and use information.
  3. Utilizing the architectural views, assess the impact of configuration changes to externally interfacing systems.
  4. Identify SoS elements incorporating net ready key performance parameter (NR KPP) requirements.
  5. Identify architecture elements maximizing use of open standards.
  6. Review areas of dependency and interoperability, and identify associated risks.
  7. Incorporate architectural views and SoS documentation into the information support plan (ISP).
  8. Document and update SoS elements in the program???s systems engineering plan (SEP).

Source: AWQI eWorkbook

Resources

Key terms

Policy and Guidance

DAU Training Courses

Media

On this page

  1. Overview
  2. Role of the PM and SE
  3. Resources
Back to top