Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Lecture 1 Introduction To System Interoperability

Download as pdf or txt
Download as pdf or txt
You are on page 1of 45

TEMPUS PROJECT MSC.

ESE
530260-TEMPUS-1-2012-1-DE-TEMPUS-JPCR

Interoperability Systems
teached by Ms Lamia EL ABED, ISG Tunis
This content is provided by Dr. Ashraf Ahmad
Other contents will be deserved by Lamia EL ABED
Lecture 1: Introduction to System Interoperability
Lamia.Labed@isg.rnu.tn
Module content

• Interoperability
• Levels of Conceptual Interoperability Model
• Enterprise Interoperability
• Architecture of Interoperable Information
Systems
• Model Driven Interoperability

2
Interoperability

• Interoperability is the ability of making


systems and organizations work together
(inter-operate) according to Wikipedia.
• According to lousy definition by me and
unknown system developers Interoperability
is to make different type of systems easily
work together by system we mean any
system HW device, ERP, DB or any other
system
3
Interoperability

• While the term was initially defined for IT or SE


services to allow for information exchange a more
broad definition takes into account social, political,
and organizational factors that impact system to
system performance.
• Task of building coherent services for users when the
individual components are technically different and
manage by different organizations

4
Interoperability Benefits

• The benefits of interoperability more striking


than in the ongoing development of the World
Wide Web.
• Internet web become the biggest player on
earth due to being a member of the world’s
largest and most interoperable network.

5
Interoperability Benefits

• With exponentially developing opportunities,


new e-companies sprung up like eBay,
Amazon, LinkedIn and Facebook. Early adapter
hardware and software suppliers, whose new
products were based on the W3C standards,
literally drove the market and were hugely
successful. The bonus to Web customers was
increasingly seamless and global
communications interoperability.
6
Interoperability Future Benefits

• In 1987, the conversation was about how


many people in a business could access a
computer. By 1991, the conversation was how
to network all of the computers that the
business controlled. Today, a computational
device that is not networked-enabled is
irrelevant. In the future, all devices will be
networked and interoperable.

7
Interoperability Not Limited to Computers

• Healthcare
• eGoverment
• Public safety
• Highway Interoperability Example
In preparation for the massive roll-out of the interstate system, government
agencies and highway developers agreed to national standards as the
foundation of the new transportation network. These standards included:
minimum heights for overpasses and tunnels; safe design of on/off ramps;
lane widths and contours that could support higher speed limits, and signage
that drivers would recognize quickly.

8
Conceptual Interoperability Model
qConceptual interoperability is used be presented as matter
of simulation.
qIt is a product that which is composite of different parts
needed to be simulated first to verify its ability to work
together.
qSystem designer think of it as making product’s
components interoperate together simulation.
q This method of thinking results several levels of
interoperability.

9
Conceptual Interoperability Model

• Research at the Virginia Modeling, Analysis and Simulation


Center (VMASC) refined these layers to define the Levels of
Conceptual Interoperability Model (LCIM)
• This definition has undergone gradual improvement since the
first discussion in [inolk, A. and Muguira, J.A. (2003). The Levels of
Conceptual Interoperability Model (LCIM). Proceedings IEEE Fall Simulation
Interoperability Workshop, IEEE CS Press]
• The current version of LCIM was first documented in [Turnitsa,
C.D. (2005). Extending the Levels of Conceptual Interoperability Model. Proceedings
IEEE Summer Computer Simulation Conference, IEEE CS Press]

10
Levels of Interoperability (1/10)

q Level 0: Stand-alone systems have No


Interoperability.
qLevel 1: On the level of Technical Interoperability, a
communication protocol exists for exchanging data
between participating systems. On this level, a
communication infrastructure is established
allowing systems to exchange bits and bytes, and
the underlying networks and protocols are
unambiguously defined

11
Levels of Interoperability (2/10)

qLevel 2: The Syntactic Interoperability level


introduces a common structure to exchange
information; i.e., a common data format is applied.
On this level, a common protocol to structure the
data is used; the format of the information
exchange is unambiguously defined.
qThis layer defines structure.

12
Levels of Interoperability (3/10)

q Level 3: If a common information exchange reference model


is used, the level of Semantic Interoperability is reached.
• On this level, the meaning of the data is shared; the content
of the information exchange requests are unambiguously
defined. This layer defines (word) meaning.
• There is a related but slightly different interpretation of the
phrase semantic interoperability, which is closer to what is
here termed Conceptual Interoperability, i.e. information in a
form whose meaning is independent of the application
generating or using it.

13
Levels of Interoperability (4/10)

qLevel 4: Pragmatic Interoperability is reached when


the interoperating systems are aware of the
methods and procedures that each system is
employing.
qIn other words, the use of the data – or the context
of its application – is understood by the
participating systems; the context in which the
information is exchanged is unambiguously defined.
This layer puts the (word) meaning into context.

14
Levels of Interoperability (5/10)

q Level 5: As a system operates on data over time, the state of that


system will change, and this includes the assumptions and
constraints that affect its data interchange.
• If systems have attained Dynamic Interoperability, they are able to
comprehend the state changes that occur in the assumptions and
constraints that each is making over time, and they are able to take
advantage of those changes.
• When interested specifically in the effects of operations, this
becomes increasingly important; the effect of the information
exchange within the participating systems is unambiguously defined.

15
Levels of Interoperability (6/10)

q Level 6: Finally, if the conceptual model – i.e. the assumptions and


constraints of the meaningful abstraction of reality – are aligned, the
highest level of interoperability is reached: Conceptual
Interoperability.
• This requires that conceptual models are documented based on
engineering methods enabling their interpretation and evaluation by
other engineers.
• In essence, this requires a “fully specified, but implementation
independent model” as requested by Davis and Anderson; this is not
simply text describing the conceptual idea.

16
Levels of Interoperability (7/10)

q This figure combine all levels of interoperability based on it domain from network
to modeling and its classification from integrity to highest interoperability degree
“Composability”

17
18
Levels of Interoperability (8/10)

• LCIM focuses on technical support by information systems, such as


command and control information systems in the military context.
• It is proven that the organizational and social aspects are often even
more important.
• This layered framework help measuring the merits dealing with
questions like tactical or strategic alignment of objectives or even
political will of coalition partners in.
• however, the focus will be on the information system aspects.

19
Levels of Interoperability (9/10)
q Strong types of integratability coping with the hardware-side and
configuration side of connectivity.
q In short, definition of interoperability can be classified into three
categories:
q Integratability contends with the physical/ technical realms of
connections between systems, which include hardware and firmware,
protocols, etc.
q Interoperability contends with the software- and implementation
details of interoperations, including exchange of data elements based
on a common data interpretation, etc.
q Composability contends with the alignment of issues on the
modeling level.
20
Levels of Interoperability (10/10)
• [Wenguang Wang, Andreas Tolk, and Weiping Wang. 2009. The levels of conceptual interoperability model: applying
systems engineering principles to M&S. In Proceedings of the 2009 Spring Simulation Multiconference (SpringSim '09]
presented Prescriptive Role of LCIM in very neat context.

21
Enterprise interoperability

• It qualifies the faculty of enterprise to establish a


partnership activity (in product design, organization
of the activities of production, supply chains piloting)
in an efficient and competitive way in an
environment of unstable market.
• Also, inside a company, the need in interoperability
of the various services is very generally identified.

22
Enterprise interoperability

• The interoperability can be considered either


as a principal, requirement or constraint that
impact the definition of patterns to compose
building blocks in the definition of targeted
architectural roadmap.
• Enterprise aims to reconcile interoperability
requirements with potential solutions in order
to enhance the capability of developed
systems to be interoperable..
23
Enterprise interoperability Requirements

• In order to achieve Enterprise Interoperability


several aspects are addressed in viewpoints or
abstraction levels:
• Business
• Process
• Knowledge
• Application
• Technology
• Data

24
Enterprise interoperability Frameworks

• In order set-up and apply the guidelines and


methodologies developed within these
frameworks, modeling efforts are required to
identify and connect artifacts:
• 2003: IDEAS: Interoperability Developments for Enterprise Application and Software.
• 2004: EIF: The European Interoperability Framework
• 2004: e-GIF: e-Government Interoperability Framework
• 2006: FEI: The Framework for Enterprise Interoperability
• 2006: C4IF: Connection, Communication, Consolidation, Collaboration Interoperability
Framework
• 2007: AIF: Athena Interoperability Framework
• 2007:Enterprise Architecture Framework for Agile and Interoperable Virtual Enterprises

25
Architecture of Interoperable Information
Systems (AIOS)
qIt is a reference architecture for the development of
interoperable enterprise information systems
qThe AIOS represents a generic building plan for
the organizations to develop interoperable
information systems by systematically adjusting
and extending their internal information
systems.

26
AIOS

• AIOS need to be independent from specific


products or vendors but describes generically
the different layers, views, relationships and
technical means needed to efficiently
establish interoperable information systems.
• It combines concepts from Service-oriented
Architecture, Collaborative Business
and Business Process Modeling.

27
AIOS

• the collaborating information systems should


be able to work together but retain as much
independency as possible. This characteristic
is also called interoperability, or in the context
of collaborating organizations, Business
Interoperability, i.e. the capability of
autonomous organizations to execute a
collaborative business process among them.

28
AIOS

• AIOS describes how internal information


system elements can be systematically
connected with the information systems of
collaboration partners

29
Elements of the AIOS

• Description of the different data types


comprised in interoperable information
system as well as their relationships.
• This is also called the static part, or
the structure of the architecture.
• “It tells organizations which information elements (e.g.
descriptions of messages, exchange sequences, roles and
services) they have to provide to collaboration partners and
how they can optimally correlate these to internal elements”

30
Elements of the AIOS

• Description of different building paths for


implementing or adjusting interoperable
information systems.
• This is also called the dynamic part of the
architecture.
• It tells organization, how to iteratively develop
the elements mentioned above.

31
Elements of the AIOS

• Concept for the technical components needed


to implement the architecture, for example
design tools, internal and externally visible
repositories.
• One element comprised in the third category
is a "BII-repository", in which each
organization publishes the content of
its Business Interoperability Interface (BII) to
collaboration partners.
32
AIOS Structure

• The static part of the architecture builds on


three orthogonal axes:
• Enterprise Dimensions
• Levels of technical Granularity
• Collaborative Views.

33
Enterprise dimensions

• organizational dimension, roles, units and other organization


elements relevant for the collaboration are described and
related to internal elements. This ensures for example, that
the collaboration partners have a common understanding of
the interacting roles.
• data dimension, document types used in the collaboration
are defined and related to internally used document types.
• function dimension, business functions and services offered
in the collaboration are described.
• process dimension, the processes that each organization
offers are described as well as how these public processes are
related to adjacent processes of partner organizations.
34
Collaborative views

• The private view comprises the only internally visible


information system elements.
• The public view acts as an interface to the internal, private
system elements; it protects internal systems and enables
interoperability without the need for a significant change to
the internal systems. This public view describes the
information system boundaries of an organization to its
collaboration partners and connects internal and external
information systems, thereby also providing the content of
the Business Interoperability Interface of an organization.
• The global view can be used to correlate and connect the
public views of different systems.
35
Levels of technical granularity

• Business Level: Here the processes to be automated are


described from a technique independent level. In MDA this
level is referred to as CIM level.
• Technical Level: Here the IT concept is described. Therefore,
the models from the first level are technically enriched, for
example, instead of business functions now components are
described, but still on a coarse-grained, conceptual level.
Since the models on the second level represent the basis for
an automated generation of executable code, they might have
to be further adapted to fit implementation level constraints.
• Execution Level: Here the models are machine interpretable
and can be used during runtime in the execution of processes.
36
Model Driven Interoperability

• Model Driven Interoperability (MDI) is a


methodological framework, which provides a
conceptual and technical support to make
interoperable enterprises using ontologies and
semantic annotations, following Model Driven
Development (MDD) principles.

37
MDI Ideas

• The three main ideas of Model Driven


Interoperability (MDI) approach are:
• Interoperability should be achieved at different levels: Business,
Knowledge, Application and Data.
• The main idea is to follow a Model Driven Engineering (MDE)[approach.
Therefore, it is promoted a systematic use of models as primary
engineering artifacts throughout the engineering life cycle combined with
both Domain Specific Modeling Languages and transformation engines
and generators.
• The use of ontologies and semantic annotations is needed in order to
perform model transformation from enterprise level to code level.

38
MDI projects and frameworks

• MDI was initiated in 2004 with the beginning of two


important research projects:
• INTEROP NoE (Interoperability Research for
Networked Enterprises Applications and Software
Network of Excellence, FP6-IST 508011).
• ATHENA IP (Advanced Technologies for
interoperability of Heterogeneous Enterprise
Networks and their Applications Integrated Project)
(FP6-IST-507849).

39
Model Driven Interoperability Method

• Conceptual integration, which focuses on concepts,


metamodels, languages and model relationships. It provides
us with a foundation for systematising various aspects of
software model interoperability.
• Technical integration, which focuses on the software
development and execution environments. It provides us with
development tools for developing software models and
execution platforms for executing software models.
• Applicative integration, which focuses on methodologies,
standards and domain models. It provides us with guidelines,
principles and patterns that can be used to solve software
interoperability issues.
40
Semantic Support

• The following services: verification of the


consistency of models, support to automatic
mapping discovery among heterogeneous
models, and definition of semantic preserving
transformation can support MDI to tackle
both vertical and horizontal issues.

41
Vertical issues:

• Giving a logic-based formalization of portions of


models via semantic annotations easing reuse, cross-
reference, and unambiguous terminology.
• Tracing the changes (among the different layers of
MDD transformations).
• Formalizing the delta-knowledge used in semantic
enriching transformations (i.e. the transformations
from more abstract models to more detailed ones).

42
Horizontal issues

• Performing semantic mismatches analysis


among the models of different enterprises.
• Representing model correspondences across
enterprises through semantic annotations.
• Creating reconciliation rules for performing
data, service and business process
reconciliation.

43
References

1-http://en.wikipedia.org // so many text were


extracted from wikipedia pages
2- Institute of Electrical and Electronics Engineers. IEEE
Standard Computer Dictionary: A Compilation of IEEE
Standard Computer Glossaries. New York, NY: 1990.
3- Slater, T. "What is Interoperability?", Network Centric
Operations Industry Consortium - NCOIC, 2012
4- Willium y Arms 2000(afifa iqbal)

44
Thanks for your kind attention!

Acknowledgement: This work is part of the MSC.ESE Tempus Project (Exporting Master Programme in Enterprise Systems Engineering
to Jordan, Syria, Tunisia and Egypt ). This project is funded by the European Commission under the TEMPUS IV – Fifth call for Proposals
(Project Number is: 530260-TEMPUS-1-2012-1-DE-TEMPUS-JPCR).

Contact: Dr. Ashraf Ahmad


Princess Sumaya University for Technology
Computer Graphics and Animation Department
Email: a.ahmad@psut.edu.jo

You might also like