 |
 |
 |
 |
| |
|||||
|
|
|
MITRE is defining the AITS architecture for moving advanced technology from DARPA to the Defense Information Infrastructure (DII). This advanced, adaptive, and interoperable architecture needs to be based on sound engineering principles and industry standards, and at the same time include such technological advances as mobile intelligent agents. The architecture is object-oriented. It supports object-based distributed computing, and it will support collaborative planning in an unreliable bandwidth environment, battlefield and situation awareness, intelligent dissemination of information to the warfighter, course of action analysis, and integration with the simulation community. This MITRE effort is sponsored by the DARPA Information Systems Office (ISO) and the AITS Joint Program Office. MITRE, in support of the DARPA Information Systems Office (ISO) and the Advanced Information Technology Services (AITS) Joint Program Office (JPO), is helping to develop an architecture to facilitate the transition of advanced technology from DARPA, to the Defense Information Infrastructure (DII). A fundamental objective of this effort is the specification of an architecture that enables transition to the DII Common Operating Environment (COE), integration across ISO programs, and reuse of components. ISO and JPO see this effort as critical for rapid technology insertion as required in the Joint Vision (JV 2010) and the Advanced Battlespace Information System (ABIS) study. A primary challenge is the development of an advanced adaptive and interoperable architecture which is based on sound engineering principles and industry standards, but at the same time is built on and responsive to technological advances, such as knowledge representation systems and mobile intelligent agents. Building on fundamental building blocks of object-orientation and distributed object computing, the architecture supports collaborative planning in an unreliable bandwidth environment, focused just-in-time logistics, battlefield and situation awareness, intelligent dissemination of information to the warfighter, course of action analysis, and integration with the simulation community. By providing an internationalized information grid spanning multiple echelons utilizing a unified schema and ontology, the AITS architecture aims to provide the standards, infrastructure, and building blocks for future C4I systems. Compliance with future versions of the DOD's Joint Technical Architecture (JTA) and the DII Common Operational Environment (COE) is a fundamental requirement of the architecture. In fact, it is envisioned that this effort will be a primary motivator for future versions of the JTA and the DII COE. The initial architecture effort will support strategic ISO programs such as: Advanced Logistics Planning (ALP), Project GENOA, Dynamic Multi-user Information Fusion (DMIF), Joint Force Air Component Commander (JFACC), Advanced Joint Planning (AJP) Advanced Concept Technology Demonstration (ACTD), Joint Task Force (JTF) Advanced Technology Demonstration (ATD), and the Battlefield Awareness and Data Dissemination (BADD) ACTD. The technology transition from ATD/ACTD to fielded systems is a complex and frequently costly task with entire systems or components of systems becoming part of either the DII COE, the Global Command and Control System (GCCS), or the Global Combat Support System (GCSS). Therefore, DARPA and the JPO have jointly decided to focus effort on the development and implementation of a common architecture which facilitates ease of transition, promotes reuse, provides interoperability, and anticipates and easily accepts technological change in a cost effective manner. The architecture effort has several activities including architectural definition and implementation guidance. An overview of the DOD architectures and how they relate to the AITS architecture follows. DOD Architectures and the AITS The meaning of the word architecture varies widely; in the literature we find the definition: "The structure of components, their relationships, and the principles governing their use over time" has been used extensively. The C4ISR architecture program divides architectures into three component architectures: Operational Architecture, Systems Architecture, and Technical Architecture. Operational Architecture defines the information flows, tasks, and elements, which support joint and service warfighting doctrine. It identifies the activities and the interaction between activities. The operational architecture from the perspective of our effort is reflected in the JV 2010 and ABIS documents, as well as reviewing more specific logistics, C4I, finance, disaster relief, and medical operational architectures. Systems Architecture defines the physical systems and system/component performance criteria. It defines how multiple systems interoperate. From the AITS architecture perspective, the systems architecture must support multiple command organizations and missions; support the GCCS and GCSS which ride on the DII COE; and provide a "Plug and Play" capability which will provide a hedge against changing implementations and technology. Technical Architecture defines standards, interfaces, services, and emerging technologies. The AITS architecture effort supports the efforts of the JTA and the DII COE standards activities, as well as defining implementation guidelines previously discussed. A major focus of the effort is in the area of the definition of generic reusable services and together with the definition of common APIs for these services, provides the "Plug and Play" capabilities of the operational architecture. The following figure illustrates 3 component architectures and provides the context for the AITS. The picture depicts enhanced components and capabilities as one moves from the center to the outer circles.
In general, the systems architecture shows how multiple systems interoperate per standards defined in the technical architecture, in order to meet the requirements of the operational architecture. In order to meet the requirements of the JV2010, it appears that particular attention needs to be paid to the integration within and between these architectural views. The AITS architects have taken the position that taking slices through all of the operational areas is important, in order to fully understand and define a comprehensive architectural view. The AITS Framework and Initial Architecture The below diagram illustrates the state of the current AITS framework. On the left, applications share little of a common infrastructure while on the right there are applications with a high level of interoperability and integration. For integrated operations, we strive to develop applications and infrastructure that fit on the right of the chart while still having a level of interoperability with other architectures.
The AITS Framework encompasses a variety of systems architectures and will, over time, address the definition of how various architectures work together. To date, considerable work has been done in the area of planning for Command and Control. Within ISO, several applications are at the right of the Framework, sharing a common schema and common services. The architecture activity is now more focused on elaborating the means for applications to work across frameworks and with applications based on other architectural paradigms. The reference architecture for Command and Control Planning is an object-oriented service based architecture which uses the Common Object Request Broker Architecture (CORBA) to provide distributed object computing capabilities. From the view below it can be seen that the initial architecture is an implementation of the Object Management Group (OMG) architecture (OMA). Common services provide capabilities to higher-level domain specific horizontal and vertical services, which in turn provide capabilities to applications and users. Security is being built into the architecture via many mechanisms such as hardware, tunneling, cryptography, and OMG security service implementations, with the implementation of security policy a major theme. This component-based approach is used to achieve higher levels of reuse, interoperability, and capability. This approach supports the concept of distributed planning and sharing of products via the common services. An example of this is a military plan. The capability to distribute and collaborate on a plan via common services is a powerful capability, which is a cornerstone of the architecture.
Common services include the Data Server, Event Services, Communication Server, and Information Dissemination Server. Higher layer servers include the Map Server, Situation Server, Plan Server, and Model Server. These services provide capabilities for distributed planning and decision making, situation visualization and assessment, course of action analysis through modeling and intelligent dissemination of information to the warfighter. A fundamental integrating technology shown on this diagram is the Common Object Repository (COR), which provides a common schema and ontology definition which spans the vertical domains. This common schema is being defined and managed by DARPA's Object Management Working Group (OMWG) and provides a common language with which to communicate within and between projects. The management of the COR is being transitioned to the JPO. With respect to distributed computing, the architecture supports DCOM and ActiveX through a bridge (OMG compliant) to CORBA. This provides an architectural link to the desktop community. Java based programs can use the Remote Method Invocation (RMI) in order to have interoperability with the common services via IIOP. Ideally, a high level of application interoperability can come through the use of common services. The AITS architecture guidance is encouraging the reuse of fielded services. However, in our efforts, we have found several roadblocks to application integration. First, DARPA projects want to push the state-of-the-art in their domain areas. Using new and inventive technologies tend to make interoperability more difficult. Second, there are other systems, started before the architecture was defined, which are not using the common services or schema. The Advanced Logistics Program (ALP) is taking the lead in developing a dynamic component-based architecture based on Java intraspection and JavaBeans. Applications can be dynamically built and configured on-the-fly and have access to the rest of the services via RMI/IIOP. The ALP design, together with BADD's InfoSleuth's project, is providing an intelligent agent based addition to the fundamental service-based architecture, providing a great deal of new capabilities to the AITS architecture. Implementation Guidance The AITS architecture is continuously evolving over time. An architecture guidance document serves many purposes: providing guidelines to developers of systems and components, information for managers with near-term objectives of transitioning their work to the AITS, and requirements to bidders and procurement officers. The notion of increasing both interoperability and capability of components is addressed using Interoperability and Capability Tiers (ICTs). As functional components progress up through the tiers, they become successively closer to achieving our architectural goals for effective and affordable C3I systems. Details of the implementation guidance, including the ICTs, are contained in the AITS Reference Architecture Implementation Guidance, dated September 12, 1997. Summary The emerging AITS architecture will identify common services for distributed planning in a CORBA based environment. Additionally the architecture effort is defining an object model for collaborative planning, automated replanning, focused logistics, and execution, readiness, situation assessment, intelligent information dissemination and dynamic information and sensor fusion. A specific goal of the architecture framework is to integrate emerging technologies and a present effort is to define the approach for incorporating intelligent agent based systems. The AITS architecture will continue to evolve as information technologies emerge. For more information, please contact John McKim using the employee directory. |
Solutions That Make a Difference.® |
|
|
