1. Fakultät für Informatik, Wirtschafts- und Rechtswissenschaften Abt. Wirtschaftsinformatik www.wi-ol.de Semantic Interoperability in Vertical Integration" Ubiquitous Sensor Networks Research Center 13th-16th February 2008 Hanyang University, Sunchon University Prof. Dr.-Ing. Axel Hahn

2. Challenge Flexible 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 Materialflow Informationflow

3. 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. Mech.. Coupling mechan. coupling Neighbor Cells Actor and Sensor Integration Fast Interface Configuration for flexible Cell Coupling Controller ConfigurationData Aquisition and Controlling

4. 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

5. OSGi Future Device Integration Automation Markup Language Standardisation: The right approach - but sufficient? 5 © Axel Hahn Adressing the smoothless operation and development of automation systems Does not address component interoperability and easy and validated integration for agile production layout and controlling

6. 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 Interchangeable Compatibility level x x x x x x x x x x x x x x x x x x x x x Systemfeature Communication Application Missing Interoperability Advanced Systemarchitec- tures (z. B. OSGi) Advanced Communication- 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

7. 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 describes the concepts used in domain as system engineering

8. To learn from another domain An example von eBiz (STASIS Project) Seite 8 © Axel Hahn

9. Semantische Enrichment to automate and to verifiy integration Seite 9 Structural specification by XML-Schema Informal speficiation by using specific terminology Both types of information are required Ontologies Logical Datamodel Ontology Domain Ontologie © Axel Hahn

10. Logical Data Model: generic Structure Seite 10 Extentions for: XML FDDL Automation ML © Axel Hahn

11. … … … Transformation of the specification for Semantic Enrichment Seite 11 Containment my:Invoice my:Date my:Currency my:Cont_I my:Cont_II hasDestinationNode hasSourceNode date string hasDataType Node ComplexNode SimpleNode isA DataType DateString isA hasDataType hasSourceNode hasDestinationNode © Axel Hahn

12. Semantic Enrichment Seite 12 my:Invoice my:Date my:Currency … … … BusinessUnitDocument isA DateTimeUnit FinancialUnit isA Invoice Order isA your:Invoice Business Ontology  Automatic detection: my:Invoice is equivalent tu your:Invoice © Axel Hahn

13. Derive semantic Mapping Seite 13 Name Complex Type Buyer Name Seller Name your:Buyer Name 1:1Combination Concatenation Mapping is_a subclass_of possible automatic reasoning is_a subclass_of © Axel Hahn

14. 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

15. Backup 15

16. 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 +

17. 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. Setsubsetscontains 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)

18. 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 - date revision Invoice + Bill + Person - Given name Family name Customer + Employee + author customer

19. Document - date revision Invoice + Bill + author customer Person - Given name Family 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 Employee Bill has customer of type Customer

20. Employee + Invoice + Customer + Mr. John Doe + Document + Bill + Author + Creating an ontology 1: Unsorted terms

21. Employee + Invoice + Customer + Mr. John Doe + Document + Bill + Author + Creating an ontology 2: Sorted terms, grouped together by their meaning

22. Employee + Customer + Mr. John Doe + Author + Invoice + Document - Bill + Creating an ontology 3: Bill and Invoice are specific types of Documents

23. Mr. John Doe + Author + Employee - Given name Family name Customer - Given name Family name Document - date revision Invoice + Bill + Creating an ontology 4: Add date and revision to Document and Given name and Family name to Employee and Customer

24. Mr. John Doe + Employee - Given name Family name Customer - Given name Family name Document - date revision Invoice + Bill + author Creating an ontology 5: Transform Author into a relationshop between Document and Employee

25. Mr. John Doe + Document - date revision Invoice + Bill + author Person - Given name Family name Customer + Employee + Creating an ontology 6: Refactor Employee and Customer, add their attributes to a common upper class Person

26. Document - date revision Invoice + Bill + author Person - Given name Family name Employee + Customer - Mr. John Doe + Creating an ontology 7: Specify that Mr. John Doe is a Customer

27. Document - date revision Invoice + Bill + author Person - Given name Family name Employee + Customer - Mr. John Doe + customer Creating an ontology 8: Add a relationship from Bill to Customer

28. Exemplary Invoice Specification in XML Schema

29. Invoice specification visualized Invoice - date expected_delivery_date lineItem + currency total_price given_name last_name - customer address visual representation for semantic enrichment /annotation purposes here subsets denote the containment / partOf-relationships

30. 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