Date post: | 31-Dec-2015 |
Category: |
Documents |
Upload: | angelina-simon |
View: | 217 times |
Download: | 1 times |
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