Appendix B: UTA Relationship with DII COE

B.1 JTA Mandate for DII COE

The following paragraphs are quoted from [JTA98, Section]:

The Common Operating Environment (COE) concept is described in the Integration and Runtime Specification (I&RTS), Version 3.0, 1 July 1997. The Defense Information Infrastructure COE (DII COE) is implemented with a set of modular software that provides generic functions or services, such as operating system services. These services or functions are accessed by other software through standard APIs. The DII COE may be adapted and tailored to meet the specific requirements of a domain. COE Implementations provide standard, modular software services that are consistent with the service areas identified in the DoD Technical Reference Model. Application programmers then have access to these software services through standardized APIs.

The DII COE, as defined in the DII COE I&RTS Version 3.0, is fundamental to a Joint System Architecture (JSA). In the absence of a JSA, the JTA mandates that all Command, Control, Communications, Computers, and Intelligence (C4I) systems shall use the DII COE. The strict definition of C4I, as given in JTA 1.0, is expanding to cover information technology areas that cut across JTA Version 2.0 domain boundaries. The DII COE mandate is therefore intended for all applicable systems. All applications of a system which must be integrated into the DII shall be at least DII COE I&RTS level 5-compliant (software is segmented, uses DII COE Kernel, and is installed via COE tools) with a goal of achieving level 8.

The DII COE implements the appropriate JTA standards applicable to the COE functionality. The DII COE implementation will continue to evolve in compliance with all applicable JTA specifications, standards, and source references. Additional functionality not contained in the DII COE is subject to the JTA mandate.

Be aware that use of the COE is not a complete substitute for compliance with the standards in the UTA and JTA. Services not contained in the DII COE are still subject to the UTA- and JTA- mandated standards.

The COE is still under development and many service areas are not completely compliant with the mandated JTA standards. These discrepancies are recorded in DII COE documents. Waivers documenting this non-compliance with the JTA are the responsibility of the DII COE Chief Engineer and are not required for individual programs implementing the COE.

B.2 DII COE Architecture and the UTA

The DII COE specification is presented in the DII COE Baseline Specification, Version 3.1 [COE97]. The COE architecture is shown in Figure B-1. The DII COE I&RTS describes the technical requirements for using the DII COE and SHADE to build and integrate systems [I&RTS97].

Figure B-1. DII COE Architecture

The USIGS adaptations are to two specific components of the DII COE. USIGS Mission Applications can be regarded as DII COE Mission (Figure B-2). USIGS MCG&I Services are components within the MCG&I Common Support Applications category (Figure B-3). To date, discussion of MCG&I services for the DII COE has focused on the Joint Mapping Tool Kit (JMTK). NIMA's goal is to establish a roadmap for the integration of future applications/services into the DII COE that encompass the broader needs of the IGC. These needs are currently represented by the MCG&I services.

Figure B-2. DII COE Architecture Extended to Show USIGS Mission Area Applications

Figure B-3. DII COE Architecture Extended to Show USIGS MCG&I Services

DII COE Common Support Applications (CSA) are typically stand-alone applications that have their own user interface and provide services of a general, or generic, type to any user. Descriptions of some of the DII COE CSAs are presented in Table B-1.

Table B-1. DII COE Common Support Application Categories

Office Automation Services

Alerts Services

MCG&I Services

Messaging Services

Word processing



Presentation graphics

Web browser

Workflow management

This category also includes on-line support as well as other productivity-enhancing functions.

Responsible for routing and managing alert messages throughout a system. Service areas include the delivery, display, queuing, suspension, and highlighting of system alerts

Provide a common set of services for the access, display, exploitation, analysis, exchange, and creation of geospatial and imagery-related data

Message receipt from a communications front end

Internal message routing

The generation, coordination and release of outbound messages

Data normalization

Storage and retrieval

Message profiling; and

Format validation

Previous Section Front Page Next Section

Point of Contact:
Mark Owens
Commercial (703) 808-0564
e-mail address: [email protected]

HTML last updated: 24 February 1999