|
Advanced
We recommend Reference Models, Architectures, Implementations--An Overview as prerequisite reading for this technology description.
The Defense Information Infrastructure (DII) Common Operating Environment
(COE) was developed in late 1993. DII COE was designed to eliminate
duplication of development (in areas such as mapping, track management, and
communication interfaces) and eliminate design incompatibility among
Department of Defense (DoD) systems. Conceptually, the COE is designed to
reduce program cost and risk through reusing proven solutions and sharing
common functionality, rather than developing systems from "scratch" every
time. The purpose of DII COE is to field systems with increasing
interoperability,
reusability,
portability, and operational capability, while reducing development time, technical obsolescence, training requirements, and life-cycle cost.
DII COE reuses proven software components contributed by services and programs
to provide common Command, Control, Communication, Computer and Intelligence
(C4I) functions. For more details on DII COE see the Defense Information
Infrastructure (DII) Common Operating Environment (COE) Integration and
Runtime Specification and the DII COE Style Guide
[DII
COE 96a, DII COE 96b].
DII COE technically is
- an architecture (including a set of guidelines and standards)
- a runtime environment
- software (including reusable components)
- a definition for acceptable application programming interfaces
The four major areas are described in further detail below:
- Architecture. The DII COE architecture is fully compliant with
the Department of Defense's Technical Architecture for Information Management
(TAFIM Reference Model). The DII COE architecture, presented in Figure 9, is a "plug and play," client/server architecture (implemented and running) that defines COE interfaces and how system components will fit together and interact.
- Runtime environment. A runtime operating environment that includes a standard user system interface, operating system, and windowing environment. The DII COE architecture facilitates a developer in establishing the environment such that there is no conflict with other developers' products.
Figure 9: Defense Information Infrastructure Common Operating
Environment
[DII COE 96]
- Software. A defined set of reusable functions that are already
built (available commercially or as government products).
Software (with the exception of the operating system and basic windowing
software) is packaged in self-contained, manageable units called segments. Segments are the DII COE building block for
constructing COE systems. Segments (mission applications and components) may
consist of one or more Computer Software Configuration Items (CSCIs). Segments
that are part of the reusable (by many mission applications) COE are referred
to as COE
component segments. Segments are named according to their meaning to operators, rather than internal software structures. Structuring the software into segments allows functionality to be easily added or removed from the target system to meet specific mission and site needs. DII COE databases are divided among segments (as are mission applications) according to the data they contain and the mission applications they support.
- The kernel COE (light gray shading in Figure 9) is the minimal set of software that is required on every workstation. It includes operating system, windowing services, and external environment interfaces. There are normally five other services also included in the COE kernel: system administration, security administration, executive manager, and two templates, one for creating privileged operator accounts, and one for creating non-privileged operator accounts. A subset of the kernel COE (defined as Bootstrap COE) is used during initial installation of COE. DII COE is hardware-independent and will run on any open system platform with a standards-based operating system, such as POSIX-compliant UNIX and Windows NT.
- APIs. Two types of Application Programming Interfaces (APIs) are defined for accessing COE segments:
- public APIs (COE interfaces that will be supported for the COE life cycle)
- private APIs (interfaces that are supported for a short period of time to allow legacy systems to migrate to full COE compliance)
- Newly-developed software (segments) must use public APIs to be COE compliant. The incremental implementation strategy for DII COE is to protect legacy system functionality while migrating to fully-compliant COE design by evolving from private APIs to public APIs.
There is only one COE available for use by other systems. This COE is
currently being used by GCCS (Global Command and Control
System) and
GCSS (Global Combat Support System). Any system built to the COE infrastructure
must access the services using the COE APIs. This improves interoperability
between systems because the integration approach, the tool sets, and the
segments (software components, not just algorithms) are used by each system
[DII COE 96a].
Conceptually, compliance to COE standards ensures that software that is
developed or modified for use within COE meets the intended requirements and
goals and will evolve with the COE system. Another perspective is that
compliance measures the degree to which "plug and play" is possible
[Perry 96]. Owners of legacy systems should be familiar with COE compliance requirements to ensure that scoping and planning for future legacy enhancement includes COE requirements and goals.
There are a number of tradeoffs an organization must address when determining evolution of a legacy system to a system that meets COE compliance.
- What are the goals of the legacy system, and will migrating to COE compliance support achievement of the long range goals?
- What level of COE compliance will best and most cost effectively achieve the legacy system's long range goals?
- What is the current state of the legacy system- how compliant is it today?
- Given the current state of the legacy system, what resources are available to begin and follow through on the migration of the code to COE compliance?
- Does the organization want/need to control the legacy system code, and if not, when in the migration to COE is turning it over to DISA desirable?
Based on this analysis, the appropriate level and strategy for compliance can be determined. The four DII COE compliance categories are described in
Table 6:
Table 6: DII COE Compliance Categories
|
Category
|
Name
|
Description
|
|
1
|
Runtime
Environment
|
Measures compliance of the proposed segment's fit within the COE executing environment, the amount it reuses COE segments, whether it will run on a COE platform, and whether it will interfere with other segments. This can be done by prototyping within the COE.
|
|
2
|
Style Guide
|
Measures compliance of the proposed segment's user interface to the Style
Guide
[DII COE 96b]. This is to ensure that proposed segment will appear consistent with the rest of the COE-based system to minimize training and maintenance cost. Style Guide compliance can be done via a checklist based on the Style Guides requirements.
|
|
3
|
Architectural Compatibility
|
Measures compliance of the proposed segment's fit within the COE architecture, and the segment's potential life cycle as COE evolves. This can be done by evaluating the segment's use of TAFIM and COE standards and guidelines, and it's internal software structures.
|
|
4
|
Software
Quality
|
Assesses a proposed segment's program risk and software maturity through the
use of traditional software metrics. This can be done using measurements such
as lines of code and McCabe complexity metrics (see Cyclomatic Complexity).
|
Category 1 (Runtime) compliance progresses through eight (8) levels of
integration from a state of coexistence (agreement on a set of standards and
ensure non-interference) with other COE segments, to federated
(non-interference when on the same workstation), to fully integrated (share
the same software and data). For a segment to be COE compliant, it must be
qualified with a category name and compliance level. The following summarizes
Category 1's eight levels of compliance; Appendix B of
[DII
COE 96a] provides a compliance checklist for each of the eight
levels. Checklists are the current means of assessing progress toward compliance.
- Standards Compliance Level One - A proposed segment shares only a common set of standards with the rest of the COE environment, data sharing is undisciplined, and software reuse is minimal other than use of Commercial-Off-The Shelf (COTS) software products. Level 1 allows simultaneous execution of two systems.
- Network Compliance Level Two - Two segments will coexist on the same Local Area Network (LAN), but on different CPUs. There is limited data sharing and there may be common user interface "look and feel" if common user interface standards are applied.
- Workstation Compliance Level Three - Two applications can reside on the same LAN, share data, and coexist on the same workstation (environmental conflict have been resolved). The kernel COE, or its functional equivalent, resides on the workstation. Some COE components may be reused, but segmenting may not be done. Segments may not interoperate, and do not use the COE services.
- Bootstrap Compliance Level Four - Segment formatting is used in all applications. Segments share the bootstrap COE. Some segment conflicts can be automatically checked by the COE system. COE services are not being used. To switch between segments, users may still require separate login accounts. To submit a prototype to DISA for consideration of use, Bootstrap Compliance is required, although these segments will not be fielded or put in the DISA maintained online library.
- Minimal COE Compliance Level Five - All segments share the same kernel COE (equivalent functionality is not acceptable at Level Five). Functionality is available through the COE Executive Manager. Segments may be successfully installed and removed through COE installation tools. Segment descriptor files describe boot, background, and local processes. Segments are registered and available through the online library. Applications appear integrated to the user, but there may be duplication of functionality. Interoperability is not guaranteed. DISA may allow Minimal COE Compliance segments to be installed and used as prototypes at a few sites for evaluation. They can be placed in the library. Currently, Level 5 appears to be the level many legacy systems are targeting.
- Intermediate COE Compliance Level Six - Segments use existing
account groups, and reuse one or more COE segments. Minor differences may
exist between the Style Guide
[DII COE 96b] and the segment's graphical user interface implementation.
- Interoperability Compliance Level Seven - To ensure interoperability, proposed segments must reuse COE segments, including communication interfaces, message parsers, database tables, track data elements, and logistic services. Public APIs provide access with very few, if any, private APIs. There is no duplicate functionality in the COE segments. DISA requires Interoperability Compliance, for fieldable products and a migration strategy to full COE Compliance (Level 8). A migration strategy is not needed if the proposed segment will be phased out in the near term.
- Full COE Compliance Level Eight - All proposed new segments use
COE services to the maximum extent possible. New segments are available
through the Executive Manager and are completely integrated into the
system. All segments fully comply with the Style Guide.
[DII COE 96b]. All segments use only public APIs. There is no duplication of functionality any where in the system (as COE or as a mission application).
Two important resources for COE developers and operational sites are the
online
COE Software Repository System (CSRS) that is used to disseminate and
manage software, and the COE Information Server (CINFO) that is used for
documentation, meeting notices and general COE information.
[DII COE 96a]
COE initial proof of concept was created and installed in 1994 with Global
Command and Control System (GCCS) Version 1.0. GCCS version 1.1 was used to
monitor events during the 1994 Haiti crisis. In 1995, GCCS version 2.0 began
fielding to a number of operational sites. There are two systems currently
using DII COE: GCCS (developed in 1994 for a near term replacement for
World-Wide Military Command and Control System) and GCSS (already fielded at a
number of operational CINCs). It is expected that DII COE will be enhanced to
include more functionality in such areas as Electronic Commerce/Electronic
Data Interchange (EC/EDI), transportation, base support, personnel, health
affairs, and finance.
[DII COE 96a]
DII COE is relatively new; actual cost, benefit, and risk information is still being collected.
DII COE is dependent of the evolution of TAFIM to ensure compatibility. (see TAFIM Reference Model). An
additional dependency could be the
Joint Technical Architecture (JTA). The JTA
is now being mandated as a set of standards and guidelines for C4I systems,
specifically in the area of interoperability, to supersede TAFIM Volume 7,
which did not appear to go far enough to ensure interoperability
[JTA 96].
Under conditions where the TAFIM reference model and DII COE compliance is not
required, an alternative model would be the Reference Model for Frameworks of
Software Engineering Environments (known as the ECMA reference model
[ECMA 93]) that is promoted in Europe, and used commercially and
world-wide. Commercially-available Hewlett-Packard products use this model
[HP 96]. Another alternative would be the Common Object Request Broker
Architecture (CORBA) if the design called for object-oriented infrastructure
(see Common Object Request Broker Architecture).
Open systems (see COTS and Open Systems--An Overview) would be a complementary technology to DII COE because work done in open system supports the COE goal of achieving interoperable systems.
This technology is classified under the following categories. Select a
category for a list of related topics.
|
[DII COE 96a]
|
Defense Information Infrastructure (DII) Common Operating Environment
(COE) Integration and Runtime Specification (I&RTS)
[online]. Available WWW
<URL:
http://spider.osfl.disa.mil/dii>
(1996).
|
|
[DII COE 96b]
|
DII COE Style Guide, Version 2.0 [online]. Available WWW
<URL:
http://spider.osfl.disa.mil/dii>
(1996).
|
|
[ECMA 93]
|
Reference Model for Frameworks of Software Engineering Environments,
3rd Edition (NIST Special Publication 500-211/Technical Report ECMA
TR/55). Prepared jointly by NIST and the European Computer Manufacturers
Association (ECMA). Washington, DC: U.S. Government Printing Office, 1993.
|
|
[HP 96]
|
Integrated Solutions Catalog for the SoftBench Product Family. Palo
Alto, CA: Hewlett-Packard, 1996.
|
|
[JTA 96]
|
U.S. Department of Defense. Joint Technical Architecture (JTA)
[online]. Available WWW
<URL:
http://www-jta.itsi.disa.mil/>(1996).
|
|
[Perry 96]
|
Perry, Frank. Defense Information Infrastructure Common Operating
Environment (briefing). April 17, 1996. Arlington, VA: Defense
Information Systems Agency.
|
Darleen Sadoski, GTE
10 Jan 97 (original)
The Software
Engineering Institute (SEI) is a federally funded research and
development center sponsored by the U.S. Department of Defense
and operated by Carnegie Mellon University.
Copyright
2007
by Carnegie Mellon University
Terms of Use
URL: http://www.sei.cmu.edu/str/descriptions/diicoe_body.html
Last Modified: 11 January 2007
|
