CSC-532 Advanced Topics in Software Engineering
Term Paper
INTEROPERABILITY MODELS
Hitesh Nagda
Louisiana Tech University
26th October, 2004.
Table of Contents:
Abstract…………………………………………………………………………….1
Introduction………………………………………………………………………..1
Levels of Information System (LISI) Model……………………………………..2
System of Systems Interoperability (SOSI) Model………………………………4
Problems……………………………………………………………………………6
Recommendations…………………………………………………………………7
References………………………………………………………………………….8
Table of Figures:
Figure 1:
Figure 2:
LISI Interoperability Maturity Model…………………………...3
Different Types of Interoperability……………………………….5
Abstract:
Interoperability has become critical as technology becomes more interconnected
and grows across the globe. Interoperability is a broad and complex subject. This
paper will document two different models of interoperability, “Levels of
Information System Interoperability” (LISI) Model and “System of Systems
Interoperability” (SOSI) Model. The research method consists of the review of
related topics and papers. In addition to exploring the various complex issues
related to the interoperability models, the main causes for the problem of
interoperability along with recommendations for further exploration will also be
presented.
Introduction:
The IEEE has four definitions of interoperability. According to one of them
interoperability is defined as [1] “the ability of two or more systems or elements
to exchange information and to use the information that has been exchanged”.
The Department of Defense defines interoperability as [2] “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”. Due to the varying expectations of people we may never be
able to agree upon a precise definition.
A very common myth is that interoperability is the same as connectivity. But the
fact of the matter is that interoperability is related to the conceptual basics,
processes and functionality as well. More often than not we tend to concentrate on
the mechanisms used for interoperation by the various systems. Changes need to
be brought about at various levels if we need to improve interoperability.
Interoperability is often considered to be a goal which we would really want, but
cannot achieve, rather than a quantifiable condition.
New systems are usually a collection of heterogeneous custom and commercial
products, and are seldom expected to function independently. By this we mean
that all the new systems need to interact with the already existing systems, which
often undergo changes. Interoperability can only exist if there is some form of
compatibility among all the elements that need to coexist for some common
purpose.
The architecture of a system consists of the system components, their externally
visible properties and the relationships among them. The underlying reasons for
more detailed design and implementation decisions about the components of a
system are provided by the architecture. Developers can be guided by using an
architectural design to minimize the application-layer incompatibilities that arise
when systems with different purposes must communicate with each other.
Interoperability consists of 3 different views.
1. Operational view, which identifies relationships and information needs.
2. Technical view, which prescribes standards and conventions.
3. Systems view, which relates capabilities and characteristics to operational
requirements
Interoperability is being used in the various fields of technology and science, from
future public safety wireless communication to global navigation systems and
geographical information systems. Interoperability systems are becoming an
increasingly important part of the armed forces of many countries around the
world. Command, control, communications, computers and intelligence (C4I)
systems relay critical information to U.S. forces during joint operations making
use of the interoperability among systems.
Many medium and large-scale industries usually have a heterogeneous computing
environment. The cost of building and supporting a heterogeneous infrastructure
reduces due to the ability of systems to interoperate. The future only promises a
growth in the trend of shifting towards interoperable systems. Specific
applications or platforms are required for many business requirements. Many a
times a large and diverse range of systems are installed in the same environment,
leading to the increasing importance of interoperability.
Levels of Information System Interoperability (LISI) Model:
LISI focuses on the increasing levels of sophistication of system of systems
interoperability. It assesses the level of interoperability attained between systems
and not the users.
Level 4
Enterprise
Level 3
Domain
Level 2
Functional
Level 1
Connected
Level 0
Isolated
Figure1:
LISI Interoperability Maturity Model
The five levels can be described as follows.
1. Level 0
Isolated interoperability exists in a manual environment between stand-alone
systems. It relies on the manual extraction and integration of data from
multiple systems. Information is shared using diskettes, tapes etc.
2. Level 1
Connected interoperability exists in a peer-to-peer environment. It relies on
some form of a simple electronic exchange of data using electronic links.
There is hardly any capability to blend information. Simple, homogeneous
data types such as voice, text files, messages or e-mails are shared.
3. Level 2
Functional interoperability exists in a distributed environment. Systems are
connected by local area networks. Information can be exchanged between
these systems. It provides for increasingly complex information exchange.
Logical data models are shared across systems. Heterogeneous data from the
fusion of many simple formats is shared.
4. Level 3
Domain based interoperability exists in an integrated environment.
Information is exchanged between independent applications running on
systems connected via wide area networks using the shared data models. It
allows direct database-to-database interactions as well as supports teamwork
on the combined information.
5. Level 4
Enterprise based interoperability exists in a universal environment. Systems
are capable of using a global information space across multiple domains.
Complex data can be simultaneously accessed by multiple users. Advanced
forms of collaboration are possible because the data and applications are fully
distributed and shared.
The ability of the system is influenced by various factors, which are identified by
LISI at each level. The four attributes which comprise these factors are
Procedures, Applications, Infrastructure and Data (PAID). Policies and
procedures govern the development of a system through established standards and
the processes and procedures influencing functional operational requirements and
system integration. Applications are the functions a system is intended to perform.
These usually perform or support a specific set of processes or procedures.
Infrastructure is required to support the system operations. The functional
applications and the system infrastructure are supported by data.
LISI focuses on technical interoperability and the complexity of interoperations
between systems. The environmental and organizational issues that contribute to
the construction and maintenance of the interoperable systems are not addressed
by this model.
System of Systems Interoperability (SOSI) Model:
SOSI addresses technical interoperability, covered by LISI too, as well as
operational and programmatic interoperability. There goes a significant amount of
effort and expense in achieving interoperation among systems. Many a times, the
approaches used do not facilitate extension to other systems. Large-scale and
consistent interoperability can be achieved if the addition of new and upgraded
systems to a growing interoperability web can be supported by consistently
applying a set of management, constructive and operational practices. The ways
of identification of the current and future interoperability needs, and how
organizations pursue interoperability must be developed in parallel.
The full scope of interoperability between organizations that participate in the
acquisition of the system must be addressed in order to have interoperability
between them. All the relevant organizations responsible for any part of a system
of systems must be considered for interoperability. A set of compatible models
that collectively address all the dimensions of interoperability is the need of the
day. However, this model is not complete, as it does not take into consideration
the issues beyond the scope of the programs.
While considering the interaction between two programs we need to work in three
different domains of interoperability. This is depicted in the following figure.
[3] Figure 2: Different Types of Interoperability
Programmatic InteroperabilityIt is the interoperability between two different program offices. We tend to easily
give up on the interoperability issues of a system when faced by problems as it is
a relatively new domain and not much is known about it. Programs must expect to
depend on each other. Interoperability requirements are not often identified until
after the system has been deployed into the market. As a result of this
compromise, in order to achieve the desired interoperability levels some systems
will have to settle for reduced capability.
Nobody is willing to spend more in order to achieve interoperability and most
program offices and contractors are happy to promote a program which is able to
just do the things it is set for. This mentality has often brought them success and
they do not want to look towards better solutions like interoperability. Money
needs to be spent in this field as we need to develop a process that would help
reach agreements and be technology agnostic.
Constructive InteroperabilityIt is the interoperability between the organizations that are responsible for the
construction and maintenance of the systems. Most of our current interoperability
needs can be supported by already existent technology, the only exceptions being
real-time applications and multilevel security. As the existing technologies do not
lend themselves to simple, maintainable interoperability solutions and are inept in
their usage, there is quite some room for improvement.
Communication between the management, technical and operational communities
is also a critical problem which needs to be resolved. Interoperability between
systems is caused by the lack of system of systems architectures. The basic
problem that will be confronted by creating architectures is that some systems
might fit within the prescribed boundaries while others would require some form
of extensive and expensive rework.
Operational InteroperabilityIt is the interoperability between systems. There are limited findings in this area
due to the lack of access to system users. The user interface is not instinctive to
the users while sharing between systems. Users need to play a much larger part
from the inception to deployment of the system in order to achieve better
interoperability. Interoperability between two systems can be achieved by
following innovative solutions like reconfiguring system settings or configuration,
but this might in turn lead to interoperability problems with other systems.
Problems:
Interoperability is a difficult challenge. There is not a clear distinction between a
system and a system of systems. The distinguishing factor lies more where the
control lies and not at the boundaries as is the general misconception. Systems
need to grow or develop in order to remain useful. The changing demands placed
on a system by its immediate owners, and those by the system of systems of
which they form a part are often different and sometimes incompatible.
Building new systems, designed to interoperate, is as difficult as increasing
interoperability between systems that originally did not interoperate. Greater
levels of interoperability cannot be achieved between newer users because of the
conflicts arising to maintain compatibility with older systems. Interoperability is
often falsely assumed to be transitive in nature. Developing standards and models
has often been seen as a way to increase interoperability, but these alone are
insufficient for achieving the goal. Often a lot of trouble is caused due to the
difference in the use of terms across organizations.
The number of organizations and initiatives that are attempting to provide
solutions to the interoperability problem only help in complicating the situation.
Interoperability is not solely a technical problem. Common agreements are still
needed with respect to the meaning of shared data and messages. The programs
will have to be compromised and some systems will have to be reworked on or
completely rebuilt to reach these agreements.
A lack of centralized or coordinated ownership is a major barrier for
interoperability. Single system views are promoted at the expense of other
systems due to the shortsighted decisions made by different organizations.
Interoperability concerns may vary across domains, whereas the policy decisions
often reflect a single domain. Implementation of a policy becomes very difficult
as the policies are not being monitored for their effectiveness.
It is almost impossible to satisfy the expectations for interoperability. The legacy
systems and technologies need to be eliminated in order to achieve the desired
levels of interoperability. New technologies tend to break the old. But today’s
systems are the result of the development of technology over a period of decades.
Neither the schedule nor cost prompts the redevelopment of high number of
systems quickly and simultaneously. A vicious circle will be created as these
systems will be part of tomorrow’s legacy.
Recommendations:
One of the recommendations is that interoperability message must be presented
from the point of view of the end users of the interoperable systems. Another
view is specific to the activities that need to occur in each iteration phase in order
to achieve interoperability.
A unified model of interoperability has also been proposed. The aggregate degree
of coupling in an interoperating system should be defined as it has implications
for the requirements needed to operate the entire system of systems. Both
syntactic and semantic complexities together give the degree of difficulty in
maintaining actions between pairs. The rate at which individual systems undergo
changes will affect the sustainability of the aggregate interoperability among
systems. The nature and extent of the internal and external boundaries need to be
clearly defined. There should be different levels of authority over systems and
system of systems. The aggregate degree of conflict and harmony of the
conformity between the intended and actual usage patterns throughout the system
determines the usability and robustness of the overall system.
The current state of interoperable systems can be summed up as a combination of
tight and loose coupling between various system of systems components. Tight
coupling tends to occur between systems that perform closely related functions.
Loose coupling tends to arise when systems not initially intended for
interoperation get an opportunity to do so. A practical way to achieve enhanced
interoperability is to distinguish a tightly connected cluster of systems and
connect them loosely to other independently developed systems.
References:
[1]
IEEE Standards Information Network. IEEE 100, The Authoritative
Dictionary of IEEE Standards Terms, Seventh Edition. New York, NY:
IEEE, 2000.
[2]
Department of Defense. Joint Pub 1-02, DoD Dictionary of Military and
Associated Terms. Washington, DC: 2001.
<http://www.dtic.mil/doctrine/jel/new_pubs/jp1_02.pdf> (2001).
[3]
http://www.sei.cmu.edu/pub/documents/04.reports/pdf/04tr004.pdf
http://www.sei.cmu.edu/pub/documents/04.reports/pdf/04tn003.pdf
http://www.dtic.mil/ndia/2003interop/Mora.pdf
http://www.defenselink.mil/nii/org/cio/i3/lisirpt.pdf
http://www.sei.cmu.edu/products/events/acquisition/2003presentations/kasunic.pdf
http://www.sei.cmu.edu/isis/presentations/sstc-incose/sstc-incose.pdf