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
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
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
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:
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.
- 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
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:
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:
- Hardware and software interfaces identified.
- Interface standards based upon open specification and standards where practical.
- Proprietary and unique system interfaces identified.
- Minimal use of options or extensions to interface standards.
- Supportability, upgrade or technology insertion plans considered in standards selection.
- Market analysis of commercial items or non-developmental items interface standards used.
- Assessment of customers using the selected interface(s).
- Assessment of suppliers providing products compliant with the interface(s) selected.
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.
- Define and describe a system architecture that is traceable to the Operational Requirements
- A preferred architecture is modular, hierarchical and layered, and is based on open standards
at its interfaces.
- Selection of an architecture should be a cooperative process between government and industry.
- Specify key performance attributes of system building blocks including internal interface
standards where necessary.
- Where a new system is contemplated, consensus among potential contractors and their key
suppliers on application of widely accepted standards is desirable.
- Identify aspects of the program that might limit the use of an open systems approach.
- Determine the level at which the architecture will be defined for the system.
- The architecture approach resulting from a system engineering process should be linked to a
business case analysis.
- Decisions about architecture should be linked to performance, life cycle cost, schedule,
- Identify opportunities for reuse of hardware and software configuration items and dependence
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.
- Identify the risk(s) to the program as a result of implementing open systems.
- Determine the risk mitigation approach for handling the risk(s).
- Determine which hardware and software areas present potential risks when using open
systems.Determine which hardware and software will be reused which impedes open systems.
- Establish contract incentives to facilitate an open systems approach.
- Establish a teaming arrangement conducive to implementing impartial interfaces.
- Establish a process supported by a "Make or Buy" plan for choosing between development
or purchase of end items within the system.
- Assure that the contract imposes necessary open system interface requirements
upon the developer.
- Support planning and execution should consider how an open system environment will
- 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.
- Assess the change in maintenance approach via upgrade verses traditional repair
- Assess the support infrastructure ability to accomplish technology insertion vice
traditional repair and reuse.
Public specifications that are maintained by an open, public consensus process to accommodate new technologies over
time and that are consistent with international 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.
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:
Open Systems Architecture (OSA)
- 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.
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.