NATO ALLIED COMMAND EUROPE AUTOMATED COMMAND, CONTROL AND INFORMATION SYSTEM (ACE ACCIS)

CASE STUDY FOR THE OPEN GROUP ARCHITECTURAL FRAMEWORK

1 NORTH ATLANTIC TREATY ORGANIZATION (NATO)

NATO uses IT in the areas of MIS, Command, Control and Communication Systems (CCIS) and in Research Oriented Systems. MIS and CCIS contain similar generic functionality, that is required for both peace and wartime, and therefore they are based on similar underlying architectures.

The key military business processes are Command Group and Crisis Management, Air, Land and Maritime Operations, Intelligence and Logistics. Crisis Management is increasing in importance as the political role of NATO evolves. Each will have their specific tasks, but all will need a core capability that provides them with generic functionality such as: Office Automation, Document and Data Base Handling, Message Handling and Processing, and Geographical Information and Multi Media Support.

Existing information systems infrastructure is ranging from legacy mainframe systems to recent client/server systems with UNIX or NT servers and PC-based client workstations. Systems extend over the whole NATO territory including Europe, US and Canada and are interconnected through a TCP/IP-based network that uses a number of different transmission media such as terrestrial lines, PTT-leased lines and satellite communication lines.

NATO acquires communication and information systems from companies in the 16 different NATO nations. The current approach is to procure open systems that are, as much as possible, based on Commercial Off The Shelf (COTS) components. For those applications, for which no COTS software exists, bespoke software will need to be developed and maintained. Although NATO-wide IT standards policy and guidance is exerted, many systems are being implemented, based on local policy or preferences, that are not fully in conformance to agreed standards. A good example is where NATO policy requires the use of OSI communications standards, but where market availability and performance requirements have resulted in TCP/IP-based solutions.

1.1 INITIATION AND FRAMEWORK

In order to help nations and NATO command staff in the acquisition of Automated Command, Control and Information System's for Allied Command Europe (ACE ACCIS), the NATO Communication and Information Systems Agency (NACISA) has developed a core architecture. This describes the hardware and software components of the required generic or core capability in terms of the essential functionality which should be acquired and the technical standards which should be applied. It also describes system attributes such as security, performance, scalability, reliability and portability and sets guidelines for system integration.

For each functional component a "shopping list" of potential products is provided that both meet the high level functional requirements and are in conformance with the required standards. There are, however, many areas were standards do not exist or are not appropriately supported with products. In these cases, mainstream products are recommended that fit best in the existing NATO product base and provide best interoperability with other products. For certain key areas, a strategic choice of a single product line is recommended, e.g. DBMS and Office Automation Suite, because NATO has made considerable investments in the product specific infrastructure that needs to be safeguarded.

For technical standards there are within NATO two initiatives that make recommendations on their applications. The NATO OSI Profile Strategy (NOSIP) document focuses on OSI and ISDN based communications and makes recommendations for ISO and ITU standards and profiles. Another, more recent activity, is the NATO Open System Environment (OSE), that addresses the wide spectrum of standards related to open systems application interoperability and portability. Under the NATO OSE initiative, a number of documents have been developed including a reference model and base standards and profiles. A NATO OSE Implementation Guidance document, that provides the mapping between required functionality and the available standards and profiles, is currently under development. The reference model is identical to the TAFIM model, and is therefore compatible with The Open Group Architectural Framework, that is based on the same model.

1.2 BASELINE DESCRIPTION

Command and control within ACE is currently performed using heterogeneous systems, but mainly PCs in LANs. Office automation and email are based on mainstream product-lines from Microsoft and Novel, while Oracle is the most commonly used DBMS. External communication between commands and national headquarters is mainly message handling based on the old ACP 127 military telex protocol, but X.400 messaging is growing in importance. In the future CCIS applications will extent beyond office automation and include services such as groupware, geographic information services and video teleconferencing.

There are a number of concerns that a target architecture would need to address:

• In the past NATO systems have been developed in a "big bang" approach that typically required 10 years before final operational use. This has lead to user dissatisfaction while in that time-period user requirements had drastically changed. An evolutionary acquisition approach is required where an initial core system based on COTS components will be installed that later can be extended resulting from evolving user requirements.

• The most important application within an military environment is message handling. The main concerns are that the message gets through under all circumstances. The recipient must be assured of authenticity and confidentiality. Due to vulnerabilities in war time, the architecture must allow for sufficient redundancy.

• Another concern is the interoperability between end user applications. Not only are different nations using different communication systems that need to be connected, but they also are using different applications that are required to exchange information. This has in the past worked well at the message text level, but with message attachments and file transfer, there is a requirement for data interchange standards.

• Security is a concern that needs special attention as it permeates all other applications. Not only should the architecture safeguard against unauthorised access to resources or information, but also prevent virus attacks.

• ACE ACCIS systems will be implemented by different vendors in different countries. This will require a strict adherence to standards for interoperability and openness of the platform to allow applications to be portable between the different implementations.

• Overall integration of the different COTS components is felt to be a major concern. Also the keeping in sync of COTS component versions from different vendors during the maintenance phase is a problem that requires careful attention.

1.3 TARGET ARCHITECTURE

1.3.1 Baseline

The baseline target architecture for an ACE ACCIS node is depicted in figure 1 below.

Figure 1. ACE ACCIS Core Architecture

Servers should be interpreted as logical components in the sense that server functions can be combined in one or more physical components. Two types of users are identified. Those that mainly require office automation and military message handling (MMH) will use PC-based workstations (reduced capability ws). Other users that also require geographical information systems (GIS) providing extensive map graphics, will use high-end PC's or RISC-based workstations (full capability ws). The core architecture will need to be flexible and extendible to allow future user requirements to be implemented in an evolutionary manner. Components will therefore need to be standardised and well dimensioned. The client server model provides the required basic flexibility. An ACE ACCIS Core Datamodel has been developed to provide interoperability at the core data level.

1.3.2 Views

The architecture can be presented in a number of views.

1.3.2.1 Command Functional View

In figure 2 below the ACE ACCIS Functional View within a Command is presented.

FASS: Functional Area Subsystem

Figure 2. Command Functional View

The different functional areas, such as Operations, Intelligence or Logistics, will be implemented in an evolutionary manner by extending the basic core architecture, utilising standard components. For each of the FASSs application specific datamodels have been defined that are consistent with the Core Datamodel. The DBMS on the database server should provide the required security access control.

1.3.2.2 Communications View

In figure 3 below the ACE ACCIS Communications View, external to the command, is presented. The different ACE ACCIS headquarters are spread over the NATO European territory, but external communications extend to the national headquarters including the US and Canada.

Figure 3. Communications View

STANAG 4406: Military version of X.400.

NIDTS: NATO Initial Data Transfer Service based on TCP/IP packet switching, using terrestrial, PTT, or satellite communication lines.

TARE: Existing ACP-127-based Military Message Handling System using low speed NATO owned communication lines.

The concern of network vulnerability is partly solved by providing a data transfer infrastructure that offers multiple communications paths. The TARE system will be replaced by a NATO-wide message handling system based on X.400. In order to ensure confidentiality the data-links are end-to-end encrypted.

1.3.2.3 Security View

The objective is to have the ACE ACCIS core architecture implementation accredited to operate in the NATO Secret System High mode but it is not possible to procure a core capability off the shelf which will be certified to the C2 security levels of functionality and assurance. The core capability is designed to be highly modular and will consist of a number of off the shelf products some of which may have been developed to meet C2 criteria and some of which may have other security features or options which can be used to help achieve the accreditation objective.

To assist in the accreditation objective the core capability must have operating systems for servers which have been designed and built to the C2 criteria. Additionally client server software for the Data Base Management System (DBMS) must have been designed and built to the C2 standard. DBMSs available at C2 level are Oracle, Ingres, Sybase and Informix. Some DBMS vendors also offer B1 level products but the C2 versions should be preferred as these are viewed for the time being as the mainstream commercial products most likely to evolve in pace with technology and most likely to be used by third party vendors providing applications which use the DBMS.

The specific security requirements of a military message handling system are defined in STANAG 4406. Mainstream E-mail products do not meet these requirements although emerging standards for message integrity and authentication are beginning to be implemented in some E-mail COTS products. The interim approach is to utilise normal X.400 and X.500 products until such time that more secure solutions become available.

Components which may serve to achieve accreditation for NATO Secret System High operation are listed in the following table cross referenced to the C2 functionality to which they are considered appropriate :

Table 1. Component C2 Functionality

1.3.2.4 Builder View

The ACE ACCIS will consist of a number of CCISs implemented in different NATO sites by different companies. Emphasis will therefore be on vendor neutral products that can be ported to a range of hardware platforms. Conformance to standards will be vital to application portability and interoperability. Prototypes and testbeds will be used to test products for their functionality, interoperability and conformance to standards.

Software for the above model has been defined in terms of functionality, standards and a list of products that should meet those standards by following the service areas of the NATO OSE Reference Model. For the selection of the standards, an approach has been developed and laid down in the NATO OSE Implementation Guidelines. This approach starts from high level Project Application Requirements that are analysed to find out what portion can be fulfilled by standard Support Applications (as defined in the detailed reference model) and what Special Applications need to be developed specifically for the project. Special Applications can partly utilise Support Applications. All Support and Special Applications are being considered for their requirement of services from each of the Reference Model Platform Service Areas, which is laid out in a Functional Table. For each of the required Service Areas an Attribute Selection Table has been developed that states all possible services in terms of technical attributes. By selecting attributes appropriate for the given Application, the system is defined in terms of required services and their underlying standards and profiles. By matching the Attribute Selection Tables with predefined Profile Attribute Characterisation Tables, an automated association process provides the list of required standards. This process is presented below in figure 4. In addition, the association process offers additional information that supports the refinement of the set, for example by eliminating inconsistent or redundant standards. This should finally lead to the Project Profile.

Figure 4: Standards and Profiles Selection Framework

1.3.3 Model Selection

The different ACE headquarters have already implemented LANs with PC and workstations. For the new ACE ACCIS, most of the existing systems will be upgraded and integrated. A client/server architecture was seen as the most flexible solution allowing relative easy extension to accommodate future needs.

Figure 5: ACE ACCIS Client/server Model

The LAN shall be laid out in a collapsed backbone, or star, configuration (Fig. 5). At the centre of the star shall be an intelligent hub and dedicated lines will run to each workstation and server. This solution provides better performance than ring configurations and are relative cheap to install. While technologies like FDDI are logically configured as a ring, every effort will be made to install cabling in a star for flexibility in transitioning to faster and greater bandwidth technologies. Multiple, separately located hubs may be installed and interconnected if required by the physical layout of the installation.

Decisions as to chose what model were made through workshop discussions. These workshops include experts that have gained experience in the different technological solutions in other NATO or National Defense projects.

1.3.4 Service Selection

For the selection of Application Platform Service standards, the method as described under 1.3.2.4 has been used. This method can of course be re-applied for any future functional area subsystem or when new requirements or standards make it necessary. The standards listed below are only a subset of the Project Profile.

The operating systems for the servers shall be POSIX.1 and POSIX.2 compliant and have a security level of C2 or higher. The product list contains operating systems that are all XPG4 compliant, except for NT. The choice of XPG4 compliant platforms should provide for the required vendor neutrality and portability of NATO specific applications.

Software engineering standards have not been defined as the core system will have to be built from COTS components only.

The user interface for POSIX-based systems will be X Window System and OSF Motif. In order to avoid divergence in screen appearance, a style guide is required to define defaults. Both Motif and NT-Windows style guides shall be used to define the look of the respective GUIs. The US DoD HCI Style Guide should be used to customise the GUIs of POSIX and NT platforms into a common look and feel. This should improve user portability and reduce training.

For data management SQL 2 shall be the query and data definition language. Oracle is expected to be the DBMS for all ACCISs.

For data interchange the formats of the standard office automation tools will be used. PDF will be used for presentation for documents for which the supporting tool is not available. SGML is expected to be used in a later stage. DIGEST will be the standard for interchange of geographical data.

Graphics services are only required within the GIS tools.

Network services standards will include TCP/IP, Ethernet, X.400, STANAG 4406 (military extension of X.400), and FTAM.

For security services the US DoD Orange Book C2 assurance level is required for a number important components. Assurance is warranted through a mixture of system architecture, integrity and security testing.

System management service standards will be SNMP for the LAN and CMIP for the WAN. This is based on product availability.

1.3.5 Business Goals and Objectives

The detailed business goals and objectives for ACE ACCIS are similar to those defined in the NATO OSE and the TAFIM. However, the main goals are interoperability, security, vendor neutrality and upgradability.

Interoperability is required with a diverse user community, geographically spread over a large area and using different communication systems.

Security is an almost obvious objective for a military organisation which bases its functioning on the authenticity and confidentiality of information.

Vendor neutrality is almost dictated by the NATO international competitive acquisition procedures to allow vendors of all nations an equal opportunity.

Upgradability is required to allow to add or change functionality based on evolving user requirements, while not having to replace the complete system.

1.4 CONCLUSION

The ACE ACCIS Core Architecture described in this example is currently in the process of being implemented. Work on it has started before The Open Group Architectural Framework existed. It has, however, been based on the NATO OSE documents, which as The Open Group Architectural Framework, is derived from the US DoD TAFIM. The implementation process could not always religiously follow the NATO OSE defined guidance. Driven by market forces practical choices have been made that were not necessarily the best from an open system's point of view. The integration of all components into a coherent system and the subsequent version control of components during the maintenance phase are still seen as a major area of concern.

Overall, however, it could be stated that the NATO OSE documents provided an appropriate support for the development of the ACE ACCIS Core Architecture and is expected to result in systems that are sufficiently flexible and adaptable to accommodate future needs.

The detailed project documentation from this case study is available here.