About Open Systems


Under Secretary of Defense for Acquisition, Technology and Logistics (AT&L) Memo Amplifying DoDD 5000.1 Guidance Regarding Modular Open Systems Approach Implementation [ PDF ]

On 5 April, 2004 the Under Secretary of Defense for Acquisition, Technology and Logistics signed a memo that amplified and expanded the policy for implementation of Modular Open Systems Approach (MOSA) as set forth in DoDD 5000.1, dated May 12, 2003. Based on this direction "Commencing October 1, 2004, all programs subject to milestone review shall brief their programs MOSA implementation status to the Milestone Decision Authority (MDA) to determine compliance. Programs not complying with MOSA implementation guidelines shall provide justification or a migration plan to the MDA for achieving compliance."

Instructions for Modular Open Systems Approach Implementation [ PDF ]

On 7 July 2004, the Director of Defense Systems signed a memo that describes how the requirements stipulated within the abovementioned memo (i.e., the USD (AT&L) memo) should be addressed for systems and systems-of-systems in the formal acquisition process. Based on the instructions contained in the memo, all DoD acquisition programs should address Modular Open Systems Approach (MOSA) early in their program and acquisition planning, and should discuss MOSA implementation in the context of their overall Acquisition Strategy and to the extent feasible in the Technology Development Strategy. MOSA implementation issues should be identified and addressed via the IPT process and presented as issues to the MDA only when unresolved at a lower level.

New Guidance for Modular Open Systems Approach Implementation

The Open Systems Joint Task Force has established detailed guidance for MOSA implementation at various chapters of the newly established DoD Acquisition Guide. Based on the new implementation guidance, MOSA is one of the principal elements of the Acquisition Strategy and an important consideration for preparation of the Systems Engineering Plans.


Background & Historical Information

On 29 November 1994, the Honorable Paul G. Kaminski, Under Secretary of Defense for Acquisition and Technology, directed Acquisition Executives in the Department of Defense to use "open systems" specifications and standards (electrical, mechanical, thermal, etc.) for acquisition of all weapon systems electronics to the greatest extent practical.

The Open Systems Joint Task Force (OS-JTF) was formed in September 1994 to: "Sponsor and accelerate the adoption of open systems in weapons systems and subsystems electronics to reduce life-cycle costs and facilitate effective weapon system intra- and interoperability."

An open systems approach is a business and engineering strategy, implemented by the IPT process, to choose commercially supported specifications and standards for selected system interfaces (logical and physical), products, practices, and tools. Selection of commercial specifications and standards is based on:

  • those adopted by industry consensus based standards bodies or de facto standards (those successful in the market place);
  • market research that evaluates the short and long term availability of products built to industry accepted specifications and standards;
  • a disciplined systems engineering process that examines tradeoffs of performance, supportability and upgrade potential within defined cost constraint; and
  • allowance for continued access to technological innovation supported by many customers and broad industrial base.

An open systems approach for weapon systems electronics provides a foundation for lower life cycle costs and improved weapons systems performance through use of standards-based architectures and greater access to commercial electronics technology, products and processes. A framework for open systems implementation is achieved by addressing the key considerations of interfaces, architecture, risks and supportability.

A. Interfaces. Interface management is an important element to open systems design. A process should be used to select interface standards which employ minimal criteria (openness, maturity, performance, conformance and future needs) in making the standards selection. Typical guidelines for choosing interface standards are:

  1. Hardware and software interfaces identified.
  2. Interface standards based upon open specification and standards where practical.
  3. Proprietary and unique system interfaces identified.
  4. Minimal use of options or extensions to interface standards.
  5. Supportability, upgrade or technology insertion plans considered in standards selection.
  6. Market analysis of commercial items or non-developmental items interface standards used.
  7. Assessment of customers using the selected interface(s).
  8. Assessment of suppliers providing products compliant with the interface(s) selected.

B. Architecture. An architecture identifies components, the relationship between components, and the rules for the architecture's composition. An Open System Approach is based on an architecture that uses open standards to describe these relationships and rules. Typical guidelines for addressing architecture are:

  1. Define and describe a system architecture that is traceable to the Operational Requirements Document (ORD).
  2. A preferred architecture is modular, hierarchical and layered, and is based on open standards at its interfaces.
  3. Selection of an architecture should be a cooperative process between government and industry.
  4. Specify key performance attributes of system building blocks including internal interface standards where necessary.
  5. Where a new system is contemplated, consensus among potential contractors and their key suppliers on application of widely accepted standards is desirable.
  6. Identify aspects of the program that might limit the use of an open systems approach.
  7. Determine the level at which the architecture will be defined for the system.
  8. The architecture approach resulting from a system engineering process should be linked to a business case analysis.
  9. Decisions about architecture should be linked to performance, life cycle cost, schedule, and risk.
  10. Identify opportunities for reuse of hardware and software configuration items and dependence upon interfaces.

C. Risks. An open systems approach should facilitate the management of risks associated with the use of commercial items or non-developmental items. Although the open systems approach, through the use of open specifications and standards, serves to mitigate risks on one hand, it also carries its own unique risks. The risks associated with products implementing open systems may be varied, but potential issues such as product availability, supportability, standards conformance and configuration control may need to be addressed. The following are guidelines for consideration.

  1. Identify the risk(s) to the program as a result of implementing open systems.
  2. Determine the risk mitigation approach for handling the risk(s).
  3. Determine which hardware and software areas present potential risks when using open systems.
  4. Determine which hardware and software will be reused which impedes open systems.
  5. Establish contract incentives to facilitate an open systems approach.
  6. Establish a teaming arrangement conducive to implementing impartial interfaces.
  7. Establish a process supported by a "Make or Buy" plan for choosing between development or purchase of end items within the system.
  8. Assure that the contract imposes necessary open system interface requirements upon the developer.

D. Supportability. The use of open standards based commercial items or non-developmental items brings a host of new support considerations. Baselines will continue to migrate because industry releases new products in a shorter timeframe than what is customary in the traditional DoD systems acquisition process. With inexpensive product availability and the ease of insertion that is facilitated by the employment of open standards based products, the maintenance approach for an open system changes dramatically.

  1. Support planning and execution should consider how an open system environment will be accommodated.
  2. Support drivers (product uniqueness, spares, redundancy, graceful degradation, fault detection and isolation, and design stability) influencing the maintenance philosophy and the interdependencies with open system implementation should be examined.
  3. Assess the change in maintenance approach via upgrade verses traditional repair and reuse.
  4. Assess the support infrastructure ability to accomplish technology insertion vice traditional repair and reuse.

E. Definitions:

Open Specifications

Public specifications that are maintained by an open, public consensus process to accommodate new technologies over time and that are consistent with international standards.

Open Standards

Guideline documentation that reflects consensus based agreements on products, practices, or operations by nationally or internationally recognized industrial, professional, trade associations or governmental bodies. These standards support interoperability, portability, and scalability and are equally available to the general public at no cost or with a moderate license fee.

Open System

A system that implements sufficient open specifications for interfaces, services, and supporting formats to enable properly engineered components to be utilized across a wide range of systems with minimal changes, to interoperate with other components on local and remote systems, and to interact with users in a style that facilitates portability. An open system is characterized by the following:

- Well defined, widely used, non-proprietary interfaces/protocols, and

- Use of standards which are developed/adopted by industrially recognized standards bodies, and

- Definition of all aspects of system interfaces to facilitate new or additional systems capabilities for wide range of applications, and

- Explicit provision for expansion or upgrading through the incorporation of additional or higher performance elements with minimal impact on the system.

Open Systems Architecture (OSA)

A system architecture produced by an open systems approach and employing open systems specifications and standards to an appropriate level.

Open Systems Standards

Standards which control and fully define attributes for software, hardware, interface design, network protocol, circuit board design, etc.. These standards have been developed and maintained in a commercial consortium or higher organization such as ISO or IEEE group consensus process. Standards have requirements for compatibility and interoperability at the interface, but they do not define the performance of a given product. A commercial manufacturer may change the performance of a product without government knowledge (consent is not required since we are now only another customer) and still comply with the standard.

Standards Based Architecture

An architecture based on an acceptable set of standards governing the arrangement, interaction, and interdependence of the parts or elements that together may be used to form a Weapons Systems, and whose purpose is to insure that a conformant system satisfies a specified set of requirements.

 

 

 

 





Click here to return to the main page Click here to jump to the 'help' page

Last Modified: 16 June 2011

Please contact the WebMaster with questions or comments.