Fakultät für Informatik, Wirtschafts- undRechtswissenschaftenAbt. Wirtschaftsinformatik

www.wi-ol.de

Semantic Interoperability in Vertical Integration"

Ubiquitous Sensor Networks Research Center13th-16th February 2008

Hanyang University, Sunchon University

Prof. Dr.-Ing. Axel Hahn

ChallengeFlexible Cross Docking Unit

2© Axel Hahn

Cargo Handling Storage Area(high rack)

Cross-docking Area

Picking-area

Container

Swap Trailer

Semi Trailer

Swap Trailer

Semi Trailer

MaterialflowInformationflow

Integration is required

3© Axel Hahn

Conveyor (Cell)

Framework and Middleware

Drive mechanism

Sensor sund Actors

Interface speficications

Softwarecomponents

Communication

Manufacturing/Logistics Execution System

Vertical Communication

Horizont.Communic.

Horizont.Communic.

Mech..Coupling

mechan.coupling

Neighbor CellsNeighbor Cells

Actor and SensorIntegration

Fast Interface Configuration for flexibleCell Coupling

Controller ConfigurationData Aquisition andControlling

• OSGi Component and Service Platform– Flexible Lifecycle of controling componets– „Only“ fixed set of Service Interfaces

• Future Device Integration– Joins EDDL (Electronic Device Definition Language) and FDT

(Field Device Tool)– Device In formation Model (DIM) and Device Operation Model

(DOM)– Handling of extentions unspecified

• Automation Markup Language– intermediate data format for seemless automation engineering– Description of Mechatronical Objects and enrichment of

engineering data

Standardisation: The right approach - but sufficient?

4© Axel Hahn

• OSGi

• Future DeviceIntegration

• Automation MarkupLanguage

Standardisation: The right approach - but sufficient?

5© Axel Hahn

Adressing the smoothless operation and development of automation systems

Does not address component interoperability and easyand validated integration for agile production layout and controlling

Interoperability

6© Axel Hahn

Situation

Interoperability is the capability to integrate applications.by covering the integration on data, functional an process layer with respect of the semantics in the application context.

nach: IEC TC65/290/DC

Dynamic Behaviour

Application Functionality

Parameter Semantics

Data Types

Data Access

Communication Interface

Communication Protocol

Incompatible

Coexistent

Interconnectable

Interworkable

Interoperable

InterchangeableCompatibility level

x xxx

xxxx

xxxxxx

xxxxxxx

Systemfeature

Com

mun

icat

ion

App

licat

ion

Missing Interoperability

AdvancedSystemarchitec-tures(z. B. OSGi)AdvancedCommunication-technologies(z. B. ind. Ethernet)Advanced Methods(z. B. Model Driven Design)

40% of implementation costs are caused by Integration.

Hurdle for cooperation and flexibility

but

Approach

The key for interoperability is semantics

Interoperability covers• People• Methods• Organisation• Infrastructure

Hollistic semantic-oriented approach for flexible semantic based integration technologies

• Adds the semantic glue on specifications like FDI or Automation ML to make components interoperable.

Usage of Ontologies

7© Axel Hahn

Glossar

Taxonomie

Thesaurus

Topic Map

Ontology

semantic richness

An ontology describesthe concepts used indomain as system engineering

Semantische Enrichment to automate and to verifiy integration

Seite 9

Structural specification by XML-Schema

Informal speficiation by usingspecific terminology

Both typesof information are required

Ontologies

Logical DatamodelOntology

DomainOntologie

© Axel Hahn

Logical Data Model: generic Structure

Seite 10

Extentions for:XMLFDDLAutomation ML

© Axel Hahn

<?xml version="1.0" encoding="UTF-8"?><schema xmlns="http://..."> <element name=“myInvoice" type="inv:InvoiceType"/> <complexType name="InvoiceType"> … <attribute name=“myDate" type="date"/>

… <attribute name=“myCurrency" type="string"/> … </complexType>

</schema>

Transformation of the specification for Semantic Enrichment

Seite 11

Containment

my:Invoice

my:Date

my:Currency

my:Cont_I

my:Cont_II

hasD

estin

atio

nNod

e

hasS

ourc

eNod

e

date

stringhasD

ataT

ype

Node

ComplexNodeSimpleNode

isA isA

DataType

Date String

isAisA

hasDataTypehasSourceNode

hasD

estin

atio

nNod

e© Axel Hahn

Semantic Enrichment

Seite 12

my:Invoice

my:Date

my:Currency

…

…

…

BusinessUnit Document

isA isA

DateTimeUnit FinancialUnit

isA isA

Invoice

OrderisA

isA

your:Invoice

Business Ontology

Automatic detection: my:Invoice is equivalent tu your:Invoice

© Axel Hahn

Derive semantic Mapping

Seite 13

Name

ComplexType Buyer

NameSellerName

your:Buyer

Name

1:1 Combination

Concatenation

Mapping

is_a

is_a

is_a

subclass_of

subclass_ofsubclass_of

possibleautomaticreasoning

is_a

subclass_ofsubclass_of

© Axel Hahn

• Ontologies are one missing link to achive interoperability by providing the semantic glue

• Semantic allignment are the first step to understand and use interface specification bejond the expressiveness of the specification technology

• Supports alignment of specifications and exchanged information

• A building block for agility by adressing vertical and horizontal integration

Summary

14© Axel Hahn

Backup

15

The basic buidling block is the entity. Document+Entities are described by a name. The above example is displayed in the minimized form, clicking the plus-sign maximizes the entity and shows its contents. In this example the entity Document has the attributes date and revision and contains an entity Invoice

Document-date

revision

Invoice+

The basic relationship is the subset-relationship. The semantic of this relationship is dependant on the use-case. In the following example the subset-relationship denotes the subClassOf-relationship between the entities: Invoice and Bill are subclasses of Document.

Set subsetscontains

Document-date

revision

Invoice+

Bill+

Possible use cases are for example:Visualization of OWL ontologies (subsets denote subClassOf-relationships)Visualization of business documents (subsets denote containment/partOf-relationships)

Entities can be connected using named relationships. In this example Document has a relationship author to Employee and Bill has a relationship customer to Customer.

Document-daterevision

Invoice+

Bill+

Person-Given nameFamily name

Customer+

Employee+

author

customer

Document-daterevision

Invoice+Bill+

author

customerPerson-Given nameFamily name

Employee+Customer-

Mr. John Doe+

Classes:•Document

•Invoice•Bill

•Person•Employee•Customer

Instances:Mr. John Doe is_a Customer

Datatype Properties:Document:

•date•revision

Person:•Given name•Family name

Object Properties:Document has author of type EmployeeBill has customer of type Customer

Employee+Invoice+

Customer+

Mr. John Doe+Document+

Bill+

Author+

Creating an ontology 1: Unsorted terms

Employee+

Invoice+

Customer+Mr. John Doe+

Document+Bill+

Author+

Creating an ontology 2: Sorted terms, grouped together by their meaning

Employee+

Customer+Mr. John Doe+

Author+

Invoice+

Document-Bill+

Creating an ontology 3: Bill and Invoice are specific types of Documents

Mr. John Doe+

Author+Employee-Given nameFamily name

Customer-Given nameFamily name

Document-daterevision

Invoice+Bill+

Creating an ontology 4: Add date and revision to Document and Given name and Family name to Employee and Customer

Mr. John Doe+

Employee-Given nameFamily name

Customer-Given nameFamily name

Document-daterevision

Invoice+Bill+

author

Creating an ontology 5: Transform Author into a relationshop between Document and Employee

Mr. John Doe+

Document-daterevision

Invoice+Bill+author

Person-Given nameFamily name

Customer+

Employee+

Creating an ontology 6: Refactor Employee and Customer, add their attributes to a common upper class Person

Document-daterevision

Invoice+Bill+author

Person-Given nameFamily name

Employee+Customer-

Mr. John Doe+

Creating an ontology 7: Specify that Mr. John Doe is a Customer

Document-daterevision

Invoice+Bill+author

Person-Given nameFamily name

Employee+Customer-

Mr. John Doe+

customer

Creating an ontology 8: Add a relationship from Bill to Customer

Exemplary Invoice Specification in XML Schema

<?xml version="1.0" encoding="UTF-8"?><schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:inv="http://www.uni-

oldenburg.de/invoice" targetNamespace="http://www.uni-oldenburg.de/invoice"> <element name="invoice" type="inv:InvoiceType"/> <complexType name="InvoiceType"> <sequence> <element name="customer" type="inv:CustomerType"/> <sequence><element name="lineItem" type="inv:LineItemType"/> </sequence> </sequence> <attribute name="date" type="date"/> <attribute name="expected_delivery_date" type="date"/> <attribute name="currency" type="string"/> <attribute name="total_price" type="int"/> </complexType> <complexType name="CustomerType"> <attribute name="given_name" type="string"/> <attribute name="last_name" type="string"/> <attribute name="address" type="string"/> </complexType> <complexType name="LineItemType"> <attribute name="amount" type="int"/> <attribute name="description" type="string"/> <attribute name="price" type="float"/> </complexType></schema>

Invoice specification visualized

Invoice-dateexpected_delivery_date

lineItem+

currencytotal_price given_name

last_name- customer

address

• visual representation for semantic enrichment /annotation purposes

• here subsets denote the containment / partOf-relationships

Semantic annotation

• Visual presentation of the annotation subject (invoice specification) and annotating data (e.g. some domain ontology)

• Explicit specification of existing semantic relationships

Domain ontology as annotating data Annotation subject