See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/288446125

Command and Control Information Systems Interoperability in NATO

Conference Paper · May 2010

CITATION READS

1 5,469

1 author:

Ladislav Burita
University of Defence
43 PUBLICATIONS   58 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

PRO-209 University of Defence View project

DZRO-209 University of Defence View project

All content following this page was uploaded by Ladislav Burita on 28 December 2015.

The user has requested enhancement of the downloaded file.

 COMMAND AND CONTROL INFORMATION SYSTEMS
INTEROPERABILITY IN NATO
Ladislav BUŘITA1

SUMMARY: The paper deals with concept and importance of NATO Command and Control
Information Systems (C2IS) interoperability. There are shown ways of achieving C2IS
interoperability in NATO; bodies, documents and interoperability stages. NATO Architecture
Framework with the support of NATO Network Enabled Capability concept, data
management strategy. The contribution of the University of Defence to C2IS interoperability
development in the outcomes of the Faculty of Military Technology projects of the Research
Program. The verification of architectural approaches with application of the Unified
Modeling Language; system of data and metadata management in the Czech Armed Forces
(CAF) information systems, and the creation of the Interoperability Dictionary application.

Keywords: Interoperability, information system, command and control, architecture, NAF,

NID, NIP, NNEC, NTA, UML, data and information, CAF.

1. INTRODUCTION
The importance of the Command and Control Information Systems (C2IS) interoperability is
continuously growing both within NATO due to its enlargement and expanding collaboration,
and outside NATO when cooperating with civilian organizations in solving crisis situations.
The article introduces essential concepts, demands on C2IS interoperability and the measures
ensuring interoperability. Some of the NATO documents dealing with C2IS interoperability
are NATO Architecture Framework (NAF), NATO Interoperability Policy (NIP) and NATO
Interoperability Directive (NID). Achieving C2IS interoperability supports the concept of
NATO military transformation, NATO Network Enabled Capability (NNEC).
At the University of Defense the Research Program of the Faculty of Military Technology
called “Development, integration, administration and security of communication and
information systems (CIS) in NATO environment” is conducted. Carrying out the projects of
the Research Program [3] gave rise to a number of partial contributions to C2IS
interoperability development; the article introduces some of them: the outcomes of
verification of architectural approaches with the application of the Unified Modeling
Language (UML), the system of data and metadata management in the Czech Armed Forces
(CAF) information systems, and Interoperability Dictionary application.
2. INTEROPERABILITY CONCEPT AND THE OBJECTIVES OF ITS
DEVELOPMENT
The term “interoperability” is stated in several NATO documents; in (AAP-6), (AAP-31) and
(ADatP-02) respectively:
1. “The ability of Alliance forces and, when appropriate, forces of Partner and other nations
to train, exercise and operate effectively together in the execution of assigned missions
and tasks”.

1
Prof. Ladislav BUŘITA, UNIVERSITY of DEFENCE, Faculty of Military Technology, Department of CIS,
Kounicova. 65, 612 00 Brno and TOMAS BATA UNIVERSITY, Faculty of Management and Economics,
Department of IEIS, Mostni 5139, 760 01 Zlin, Czech Republic; ladislav.burita@unob.cz

1
2. “Interoperability is the ability of systems, units, or forces to provide services to and
accept services from other systems, units or forces and to use the services so exchanged to
enable them to operate effectively together”.
3. “The capability to communicate, execute programs, or transfer data among various
functional units in a manner that requires the user to have little or no knowledge of the
unique characteristics of those units”.
From the definitions above it can be inferred that the aim of interoperability is:
 To act in synergy when carrying out tasks assigned within units, equipment and
personnel.
 To conduct joint operations, communicate mutually and cooperate effectively, exercise
together, share data and information provided by C3 systems and services.
 In terms of the systems, to provide information and services and accept them from
other systems, and to use the exchanged information and services.
3. C2IS INTEROPERABILITY
NATO C2IS Interoperability Environment (NIE) comprises four levels organized in a
hierarchical structure (see Fig. 1). It encompasses (from the top to bottom levels) policy,
directives, guidance and enablers. It represents a base of the systems development in NAF
architectural framework including NATO Technical Architecture (NTA). NATO Common
Standards Profile and NATO Common Operating Environment support the C2IS
implementation.
Other elements contributing to interoperability development are the NATO Interoperability
Environment Testing Infrastructure and NATO Information Exchange Guidance Document.
Currently, according to the stated principles, the Bi-Strategic Command Automated
Information System and Air Command and Control System projects are carried out in NATO.

Fig. 1: The environment for achieving C2IS systems interoperability in NATO

To facilitate C2IS interoperability NATO has adopted an architectural approach the purpose
of which is not only to achieve its own objectives throughout NATO but also outside NATO;
towards state bodies, governmental and non-governmental organizations. The basic
architectural documents are as follows.
 NIP_NATO Interoperability Policy [7] – it determines the demands on C2IS
interoperability, the roles and responsibility for implementation.

2
  NID_NATO Interoperability Directive [6] – the description of the process in which the
C2IS interoperability of is accomplished in the projects life-cycle. The list of
obligatory architectures, views and subviews (templates).
 NAF_NATO Architecture Framework [5] – it also includes NATO Architecture
Framework Metamodel.
 NTA_NATO Technical Architecture [8] – the description of the C2IS technical
architecture, components and functions.
 NNEC_NATO Network Enabled Capability [9] – ensures the effective conduct of
campaigns and combat operations, interconnection of sensors, decision making and
weapon systems.
3.1 NATO INTEROPERABILITY DEGREE
NATO C2IS interoperability degrees represent technical and system levels of interconnection.
Four degrees have been specified.
 Degree 0 – Isolated Interoperability in a Manual Environment. The key feature is
human intervention to provide interoperability where systems are isolated from each
other.
 Degree 1 – Connected Interoperability in a Peer-to-Peer Environment. The key feature
is physical connectivity providing direct interaction between systems.
 Degree 2 – Functional Interoperability in a Distributed Environment. The key feature
is the ability of independent applications to exchange and use independent data
components in a direct or distributed manner among systems.
 Degree 3 – Domain Interoperability in an Integrated Environment. The key feature is a
domain perspective that includes domain data models and procedures where data is
shared among the independent applications which may begin to work together in an
integrated fashion.
 Degree 4 – Enterprise Interoperability in a Universal Environment. The key feature is
a top-level perspective that includes enterprise data models and procedures, where
data is seamlessly shared among the applications that work together across domains in
a universal access environment.
According to NATO demands, for an unambiguous interpretation of information in C2IS it is
necessary to ensure interoperability at the following levels.
1. Physical – standard connectors, cables and other equipment.
2. Empirical – signal transmission, protocols.
3. Syntactical – data interpretation quality, their format significance.
4. Semantical – representation of symbols, their explicitness, completeness, exactness.
5. Pragmatical – the importance for users (timeliness, comprehensiveness, access,
acceptance).
6. Social – the whole understanding by a given community.
3.2 NATO ARCHITECTURE FRAMEWORK
The document “NATO Architecture Framework (NAF) version 3, Enabling NATO NEC”
was issued in fall 2007 by the NC3B agency [5]. In the previous version (2004) there were

3
some shortages and ambiguity. We belonged among its critics (see [1] and [2]), and thus we
possibly contributed to the fast change to the better.
The architecture according to NAF is a formal description of reality; it includes people,
processes, systems and organizations. Is presents an overview of the described environment.
It expresses the results of static and dynamic analysis; it is an outcome of experimenting.
NAF represents a structural approach to the achievement of complexity, leads to the expenses
saving, supports prime planning, remedies duplicity and develops interoperability. The types
of NAF architectures (see Fig. 2) are Overarching (What?), Reference (How?), Target (With
what?).

Fig. 2: Architectures according to NAF

NATO Architectural Views:

1. All View – overlapping aspects, the relations to all other views, it comprises context
(doctrines, objectives, operations, scenarios, techniques, procedures, and
environment).
2. Capability View – processes of analysis and optimization of military capabilities
according to nato strategy. Decomposition of capabilities, measurements of efficiency.
3. Operational View – operational tasks and elements, information exchange.
Identification of operational nodes and elements, assignments of tasks and activities,
information flows.
4. Service-oriented View – Service Oriented Architecture (SOA) support, description of
operation domain services. Service as a work unit, service taxonomy, orchestration,
mapping on operational activities.
5. System View – description of the system and its interconnection. System sources for
operational view (operational activities, nodes, information exchange).
6. Technical View – rules for system elements. Guidelines for the technical system
implementation, standards, conventions.
7. Program View – relations between requirements on military capabilities and programs
and projects implemented. Interconnection with acquisition processes.

4
NATO Architectural Subviews:
Architectural Subviews elaborate on the content of a given view. They specify the purpose,
definition, development guidance, and supporting NNEC architecture elements.
3.3 NATO DATA STRATEGY
The capability of sharing information is a key factor to military success. NATO and NATO
members’ C2IS must be able to exchange information when carrying out a task in an arbitrary
environment. Considering the growth in data volume it is necessary to handle them in the
same way as any other important source. Data management in NATO deals with the standards
and procedures to ensure the requirements on C2IS. It pays attention to architectures, data and
metadata management and standardization of data elements. NATO Data Administration
Group is responsible for the development and maintenance of the NATO Data Management
Policy as well as:
 Providing guidance on the implementation of data management,
 establishing Standard Data Elements,
 and developing and maintaining NATO Data Administration Repository.
Standardized Information Exchange Gateway (IEG) defines the requirements on information
exchange between domains with a different degree of security (see Figure 3) for Information
Exchange Services (IES). The IEG interface ensures data sharing at strategic, operational and
tactical levels with respect to the procedures concerning C2IS accreditation for the protection
required by the assigned classification.

Fig. 3: NATO Information Exchange Gateway

4.UML, UNIFIED PROCESS AND NATO ARCHITECTURE FRAMEWORK
“The Unified Modeling Language (UML) is a visual language for specifying, constructing
and documenting the artifacts of systems. The artifacts are any outputs provided during
system creation (documents, graphs, source code)”.
“Unified Process (UP) is an approach to building, deploying and maintaining software. The
UP is an iterative process, which means that development is organized into series of a short,
fixed in length mini-projects called iterations. The outcome of the each iteration is a tested,
integrated and executable partial system”.
It has been mentioned that UP is primarily used for software building, but the idea of iterative
and incremental development can be applied to architecture building easily. We studied the
above-mentioned standards and documents and we identified the following difficulties that

5
make it almost impossible to understand the whole area properly and start building
architecture:
 There are too many views and layers that exist at present time.
 Documents and guidelines use different notations; so it’s difficult to read and
understand such diagrams in the whole content.
Several views on system architecture are defined in UML: logical, process, deployment, and
implementation. These views reflect the system from a particular perspective that emphasizes
the key information or ideas, and ignores the rest. In UML we look at the system from four
basic perspectives. It is known as a 4+1 view model. In this context ‘+1’ means the use case
view, a summary of the most architecturally significant use cases or scenarios.
The previous chapter described the fragments of current approaches to architecture
construction area. There is a large amount of layers, models, and views. The research team
was questioning itself over what exactly should be defined as architecture for system
integration. We went through these documents and we really did not know where to start. We
would like to see an example of the architecture created on the basis of these standards. At the
moment we cannot see any way of using these documents and standards to produce a
comprehensive architecture at national level that would satisfy current stakeholders’ needs.
To unify existing approaches in architecture construction, we would like to suggest the
following:
 The unification of the used notation; probably the best would be to use UML wherever
it is possible. A set of new stereotypes can be defined in UML for architecture
construction.
 The creation of templates for typical applications of architecture in the areas like
system integration, system development, acquisition etc.
 Decreasing the number of artifacts at all levels to simplify architecture construction,
readability and usability.
 The development of methodology for architecture creation. We suggest building
methodology based on Unified Process, especially for iterative and incremental
approaches.
 It would be useful to find a team at NATO level which will focus on unification in this
area.
The team of the Research Program [3] contributed to the architecture approach in the CAF.
The team members cooperated in the creation of the Overarching Architecture of the Ministry
of Defense (MoD) Cross-Sectional IS and Reference Architecture of the C2IS system for the
CAF.
5. PROBLEM OF DATA AND ITS SOLUTION IN MILITARY ENVIRONMENT
The individual IS of the CAF were not designed to complement each other. Sometimes, it was
not known that a particular area of interest of an IS had already been covered by another one.
Even though the government has announced its interest in coordination, the MoD stood aside,
and for some time, it neglected the integration process.
There was no system of the central information about the CAF IS data structure, and there is
no tradition of data maintenance. The CAF history of the automated data processing is nearly
50 years old, but the data available for the integration information solution are only several
years old. After each CAF transformation the electronic data were lost. So far, the data have

6
been used only in operational IS, but there is a very good chance to use the data for decision
support.
Our experience comes from a prototype solution in personnel area. The goal of research
project was to obtain, analyze and transform data that could be useful for the MoD decision
support process. We would like to trace military carriers of the University of Defense
students, first in the IT branch, and then in all armed forces. The problems of data made us
change our original intention: originally we planned to use data of a 30-year interval, but
finally we changed it into a 10-year interval.
The current situation provides no information support for metadata management. The roles
and responsibilities are not correctly identified, and the access to metadata registry is not
provided. When a user needs some information from the metadata registry, the most common
way is to phone a person that is expected to be familiar with the IS (local helpdesk, network
administrator), and follow the route of informal contacts to someone who is responsible for
the registry. The same approach is applied when changes and updates are needed. Such a lack
of system approach leads to unacceptable delays: the requirements for metadata update time
range from 1 to 3 days, but the process itself takes about one month and the user has no
feedback on the process status.
5.1 METADATA REPOSITORY CONCEPT
The metadata management within the CAF is a typical area of IT that has been negatively
affected by the transformations and hasty unsystematic implementation of individual IS. The
metadata among the systems are not unified, the redundancy of information is high, and the
systems are unable to interpret historical data. The process of change within the metadata is
measured in weeks, while the demand according to the process model is hours or days.
The Metadata Repository IS (MRIS), developed by researchers at the University of Defense
within the Research Program [3], is the intranet application that covers all identified processes
bound up with the metadata management. The system is being built straight upon the
collected requirements (by the IT Development Agency, the MoD). The requirements had
been analyzed and the business process model was built, followed by the directive by the
MoD that defines the processes, rules and liability. Such support of the generality has
contributed to the implementation (or better enforcement of use) of the system significantly.
The aim of the joint team from the University of Defense and Information Development
Agency of the Ministry of Defense is to introduce a system approach to the redesigning of the
processes and implementation of Metadata Registry Information System (MRIS).
The system is designed to offer export capabilities into common data exchange formats
(according to the current state in the CAF), which are Excel-based formats (xls, csv), and to
be connected to NATO allied metadata management based upon the XML open format
structure.
5.2 METADATA REPOSITORY MODELING AND SYSTEM IMPLEMENTATION
Even though the metadata in the information systems already exist, we began to implement
the information support from scratch. We decided to use progressive methods of modeling
and data processing to achieve universal solution that would be open to enlargement and
modification as much as possible. The use of the methods has also served as a kind of
verification of their suitability for software engineering teaching at the CIS Department.
After the research of the existing information systems we set basic parameters for the system,
such as the use of the Intranet of the Czech Armed Forces (i.e. application thin client –
server), no classification demands on data, input and output formats, estimated amount of
data.

7
The following step was the business process modeling. The key processes of the metadata
management were identified and modeled. The business process model (BPM) was useful
during the evolution and review of the Directive of the Metadata Management, issued by the
MoD, and during UML modeling. The level of detail in the model was varying. Generally, we
can say that processes bound with the system, such as user management, system backup and
recovery or output transformations were modeled only briefly, while key metadata
management processes were modeled in full detail. During the UML modeling, the level of
detail of BPM proved to be unnecessarily high because some of the features depended on the
implementation of the database scheme and application logic.
The design of the MRIS was derived from the BPM and UML models, jointly developed by
two teams. It has been proven that even non-professional personnel gets familiar with UML
diagrams easily, and is able to cooperate during the creation of most of the diagrams. Before
the development of the application, it was decided, that a perspective multi-tier approach
would be applied. When the requirements from the Cross-Sectional IS emerged, our system
complied with them without any need for modification.
Having the key features identified, we built a prototype that served as a demonstration of the
concept. It provided no internal logic, it was just a set of static web pages that were designed
to identify control elements, the way the users wish to interact with the application, and also
helped the team at the Information Development Agency to imagine a possible view of the
suggested application. The expectation was further developing for some time, until the control
elements and output format were established. These characteristics were transferred to the
actual application and then the application logic was added.
MRIS itself is based upon Java Server Pages, technology of dynamic server pages, which
modifies the Apache web server with Java Runtime Environment. The database interface is
Java Database Connectivity, a technology supported by the major vendors of the relational
database management systems, which also features JDBC-ODBC bridges to ODBC-only
databases. MRIS uses Oracle 9i database, but was already tested even with others, including
PostgreSQL. The metadata that are managed by the MRIS are stored in the tables. Rules and
rights are assigned, backup and recovery procedures are established.
During the testing of the application, we deployed an online "report a bug" system on each
web page that helped us gather the instant feedback from the testers. MRIS covers all phases
of the process of metadata acquisition or metadata change requirement. The registered users
may use email-based notification of the status of their requests, all users may use different
download formats to get an offline version of any metadata registry or metadata themselves.
The system features web-services support for online access to the metadata. We believe that
the designed web-based IS will not have its own copy of the metadata (such as a list of the
military ranks or commercial bank codes), but it will be able to get this information online via
web-service invocation. Multi-tier architecture of MRIS and model-view-controller design
enable further enlargement according to the demands of the Ministry of Defense. We believe
that the development of the MRIS helped us prove the advantage of the system approach and
extensive use of contemporary modeling skills, as well as the maturity, complexity and
strength of the Java-based solutions.
5.3 LESSONS LEARNED
The management of metadata within the modern and perspective information systems must be
an IT-based process that supports the online retrieval of metadata from users and applications,
as well as it has to have the full coverage of metadata lifecycle. There exists a simple
commercial application that meets these requirements, and it is advisable to consider the
option of the development of such an application using the resources of the Ministry of
Defense.

8
The BPM and UML are crucial technologies able to satisfy the demands of customers, and
even the end-users are able to cooperate in monitoring their demands, and understand the
models and diagrams easily. The forward-code engineering based upon the UML model
decreases the time-requirements for the development of the application.
The debugging and testing of the applications in near real-life conditions might be a long and
demanding process. The use of the multiplatform and multi-tier based on applications and
languages can help during the development of the systems. It also reduces the price of the
whole system, since many of the free (or General Public License based) database management
and operating systems are already approved by NATO, and seem to be ideal for (web) server
and remote management purposes.
6. INTEROPERABILITY DICTIONARY PROJECT AND ITS RELEVANCE IN
MILITARY IS MANAGEMENT
The project is primarily intended for the C2 IS interoperability systems support in the Czech
Armed Forces (CAF). It is a part of the Research Program [3].
The aim of the project was to create the “C2IS Interoperability Dictionary” in electronic
version, which will:
 Contribute to the unification of terms used in the MoD in the field of C2IS
interoperability.
 Facilitate the filing and management of interoperability terms predominantly chosen
from available norms, standards and publications, but also the creation of new terms.
 Provide a simple and user-friendly access to the terms and enable the discussion on the
recorded terms and achieve their unification in the CAF and business sector.

Fig. 4: Interoperabilita vocabulary - Alphabet index

In the dictionary, an arbitrary number of interest domains might be considered; as a starting
point, four areas have been specified: Interoperability general terms, C2IS architectures,
Network Enabled Capability and Multilateral Interoperability Programme. For the time being,
the terms are recorded in Czech and English, and, if needed, terms in French will be added.
Each entry contains a definition of the term in Czech and English and its source.
Unregistered users can access the dictionary too; registered users can have the role of a
reader, contributor, editor and administrator. A contributor can look through the dictionary
and send comments on terms, an editor can insert and update terms, and, in addition to that,
an administrator is responsible for conducting user accounts. All of them can trace selected

9
 terms and their history; they receive changes and comments by email. The technology
environment has been chosen on the basis of free SW.
Terms insertion includes the incorporation of internal and external links, which enables fine
user environment when using the dictionary. Besides, it is possible to insert pictures. The
history of all changes is recorded, and the project notifies persons concerned that a certain
term has been changed or a comment recorded. The preview of the dictionary user
environment includes the alphabet index (Fig. 4). So far, the dictionary has only been filled in
with general interoperability terms, which serve as a basis for the user utilization and
functionality. In the next stage, the terms of other selected domains are supposed to be
gradually added, according to the requirements of the users in defense and business sectors.
7. CONCLUSION
The article focuses on providing a complex view of C2IS interoperability solution in NATO
environment. The area includes a large range of documentation; however, this fact must not
discourage us from studying it in depth and implementing all the requirements thoroughly
into the defense sector and the Czech Republic security community. The partial outcomes of
our Research Program [3] we have contributed to the development of the C2IS CAF and
NATO interoperability.

ACKNOWLEDGEMENT
The article is prepared as a component of the Research Program [3] and Research Project [4].
It introduces some outcomes of the solutions in C2IS interoperability field. Our results are
part of the education process in subject “Interoperability and NATO” at the University of
Defence and subject “Information management” at the Tomas Bata University.

REFERENCES
[1] BURITA Ladislav, HLAVACEK Martin, ONDRYHAL Vojtech. NATO C3
Interoperability Themes and the Czech Armed Forces’ Contribution to their Solution. In
International Conference Joint & Coalition Interoperability. Prague: The SMI Group, 17th
& 18th May 2006, 13 pp.
[2] BURITA Ladislav, ONDRYHAL Vojtech. NATO C3 Architectures and Difficulties of
Application in National Environment. In 16th European-Japanese Conference on
Information Modelling and Knowledge Bases. Trojanovice, Czech Republic: Technical
University Ostrava, May 29th – June 2nd 2006, ISBN 80-248-1023-9, pp. 98-105.
[3] Development, integration, administration and security of CIS in NATO environment.
Faculty of Military Technology Research Program FVT0000403. Brno: UoD, 2004-2010
[4] Knowledge management in NEC CAF (MENTAL). Ministry of Defence Research Project.
Prague: MoD, 2008-2011.
[5] NATO C3 Architecture Framework v3. NATO C3 Board, 2007, 11 books.
[6] NATO C3 System Interoperability Directive. NATO C3 Board, 2007, 4 books.
[7] NATO C3 System Interoperability Policy. NATO C3 Board, 2007, 21 s.
[8] NATO C3 Technical Architecture v7. NATO C3 Board, 2005, 5 books.
[9] NATO Network Enabled Capability Feasibility Study, Version 2. Brussels: NC3A, 2005,
623 pp.

10

View publication stats