D6 - scalable40.eu€¦ · D6.2 Ontology-based Reference Data Model Ref. Ares(2018)2813496 -...

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 723658

D6.2 Ontology-based Reference Data

Model

Ref. Ares(2018)2813496 - 30/05/2018

2

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement 723658

Public

Scalable automation for flexible production systems

Deliverable D6.2

Project Acronym: ScalABLE 4.0

Project full title: Scalable Automation for Flexible Production Systems

Project No: 723658

Call: H2020-FOF-2016

Coordinator: INESC TEC

Project start date: January 1st, 2017

Project duration: 48 months

Abstract This document presents the ontology-based reference data model and the process for creating this model.

Document control sheet

Title of Document D6.2 Ontology-based Reference Data Model

Work Package WP6 – Simulation and Decision Support Systems

Last version date 25/05/2018

Status Final

Document Version: v.5

File Name ScalABLE 4.0 D6.2

Dissemination Level Public

Partner Responsible INESC TEC

Versioning and contribution history

Version Date Revision Description Partner

v.1 20/02/2018 Document Creation FhG, Michael Oberle

v.2 15/03/2018 Initial Draft FhG, Michael Oberle

v.3 12/05/2018 Internal Review Version FhG, Michael Oberle & Ahmad Issah

v.4 25/05/2018 Final Version FhG, Michael Obelre & Ahmad Issah

v.5 25/05/2018 Final Review INESC TEC, Joana Dias

Disclaimer

This document is provided « as is » with no warranties whatsoever, including any warranty or merchantability, noninfringement, fitness for any particular purpose, or any warranty otherwise arising out of any proposal, specification or sample. No license, express or implied, by estoppels or otherwise, to any intellectual property rights are granted herein. The members of the project ScalABLE 4.0 do not accept any liability for actions or omissions of ScalABLE 4.0 members or third parties and disclaim any obligation to enforce the use of this document. This document reflects only the authors' view and the Commission is not responsible for any use that may be made of the information it contains. This document is subject to change without notice.

3


Public


Deliverable D6.2

Contents

1. Introduction ................................................................ 6

1.1. Scope and objectives ................................................................................. 6

1.2. Document Structure ................................................................................... 6

2. Definitions .................................................................. 6

2.1. Semantic Data Model .................................................................................. 6

2.2. Semantic Reference Data Model .................................................................... 7

2.3. Ontology-based Data Model .......................................................................... 7

3. Methodology ............................................................... 8

4. Analysis of Existing Standards .......................................... 9

4.1. ISO/IEC 62246 ......................................................................................... 10

4.2. STEP-NC ................................................................................................ 12

4.3. Core Product Model .................................................................................. 13

4.4. Industrial Foundation Classes ....................................................................... 14

4.5. Virtual Factory Data Model .......................................................................... 15

5. Scalable Ontology Architecture ...................................... 17

5.1. Resource Layer ........................................................................................ 17

5.2. Core Layer ............................................................................................. 18

5.3. Interoperability Layer ................................................................................ 24

5.4. Domain Layer .......................................................................................... 31

6. Summary .................................................................. 33

7. References ............................................................... 34

4


Public


Deliverable D6.2

List of Tables Table 1 Macro areas in the VFDM ..................................................................................... 16

Table 2 Scalable ontology architecture .............................................................................. 17

Table 3 ScaProduct object properties ................................................................................ 20

Table 4 ScaPart object properties .................................................................................... 20

Table 5 StepNcWorkpiece object properties ........................................................................ 20

Table 6 StepNcManufacturingFeature object properties .......................................................... 21

Table 7 StepNcOperation object properties ......................................................................... 21

Table 8 StepNcToolpath object properties .......................................................................... 21

Table 9 StepNcWorkingStep object properties ...................................................................... 21

Table 10 StepNcWorkplan object properties ........................................................................ 21

Table 11 CpmSpecification object properties ....................................................................... 22

Table 12 CpmRequirement object properties ....................................................................... 22

Table 13 ScaProcess object properties ............................................................................... 22

Table 14 ScaProductionResource object properties ................................................................ 23

Table 15 ScaEquipment object properties ........................................................................... 23

Table 16 ScaRobot object properties ................................................................................. 24

Table 17 ScaOperator object properties ............................................................................. 24

Table 18 ScaContainer object properties ............................................................................ 24

Table 19 ScaPackingProcess object properties ...................................................................... 25

Table 20 ScaMachine object properties .............................................................................. 25

Table 21 ScaConveyorBelt object properties ........................................................................ 26

Table 22 ScaDockingStation object properties ...................................................................... 26

Table 23 ScaTool object properties .................................................................................. 26

Table 24 ScaManufacturingFacility object properties .............................................................. 27

Table 25 ScaManufacturingArea object properties ................................................................. 27

Table 26 ScaProductionLine object properties ...................................................................... 27

Table 27 ScaWorkstation object properties ......................................................................... 28

Table 28 ScaProductionOrder object properties .................................................................... 29

Table 29 ScaLot object properties .................................................................................... 29

Table 30 ScaProductionScheduling object properties .............................................................. 29

Table 31 ScaKeyPerformanceIndicator object properties ......................................................... 30

Table 32 ScaSkill object properties ................................................................................... 30

Table 33 ScaStandardOperatingProcedure object properties ..................................................... 30

Table 34 ScaManufacturingTask object properties ................................................................. 30

Table 35 ScaMachineTool object properties ......................................................................... 31

Table 36 ScaMold object properties .................................................................................. 32

Table 37 ScaManufacturingProcess object properties.............................................................. 32

Table 38 ScaInjectionMoldingProcess object properties ........................................................... 32

Table 39 ScaAuxiliaryEquipment object properties ................................................................ 33

Table 40 ScaAssemblyProcess object properties .................................................................... 33

5


Public


Deliverable D6.2

List of Figures Figure 1 Semantic reference data model development methodology ............................................ 8

Figure 2 Advanced Plant Model from WP5 ........................................................................... 10

Figure 3 ISO/IEC 62246-1 function hierarchy model ................................................................ 11

Figure 4 Simplified STEP-NC data model ............................................................................. 12

Figure 5 Class Diagram of Core Product Model ...................................................................... 13

Figure 6 IFC data schema architecture with conceptual layers .................................................. 14

Figure 7 VFDM architecture ............................................................................................ 16

Figure 8 IfcKernel ontology class hierarchy ......................................................................... 19

Figure 9 ScaProduct ontology class hierarchy ....................................................................... 19

Figure 10 ScaProcess ontology class hierarchy ...................................................................... 22

Figure 11 ScaProductionResource ontology class hierarchy ....................................................... 23

Figure 12 ScaSharedProcess ontology class hierarchy .............................................................. 25

Figure 13 ScaSharedProductionResources ontology class hierarchy .............................................. 25

Figure 14 ScaManufacturingFacility ontology class hierarchy ..................................................... 26

Figure 15 ScaSharedProductionManagement ontology class hierarchy .......................................... 28

Figure 16 ScaManufacturingDomain ontology class hierarchy ..................................................... 31

Figure 17 ScaAssemblyDomain ontology class hierarchy ........................................................... 33

6


Public


Deliverable D6.2

1. Introduction

1.1. Scope and objectives

In the ScalABLE4.0 project, production flexibility and resource efficiency of manufacturing systems shall be improved by implementing a simulation-based optimisation software. This software would provide decision support for associating machines/operators to manufacturing tasks with the goal of reducing costs and increasing performance of the manufacturing system.

In order to enable simulation data from various manufacturing entities on the shop floor is required. To provide data from these entities, they need to be virtually represented with their specific characteristics, skills and properties. One way of leveraging data form these entities, while ensuring interoperability with the various heterogeneous entities and the simulation engine, is the use of a semantic reference data model.

The semantic data model describes the meaning of its instances. This enables parties that exchange information to interpret the semantics of the data without requiring a separately described meta-model. Static and dynamic data from the shop floor should be represented as instances of the model and stored in a semantic database which has been selected in deliverable 6.1.

1.2. Document Structure

The goal of this deliverable is to document the development of a semantic reference data model that can support the data exchange between shop floor and simulation engine. The deliverable is structured as following. In the next chapter, terms such a semantic model, semantic reference data model and ontology-based model are defined and explained. The following chapter details the methodology that structures the development of the semantic reference data model. Chapter 4 contains an analysis of existing standards related to the problem area. Chapter 5 describes the developed semantic reference data model. Finally, the deliverable is concluded with a summary.

2. Definitions The development of the semantic reference data model makes assumptions about the usage of some terms that are related but need to be defined for a correct interpretation.

2.1. Semantic Data Model

The foundational essence of the deliverable is to create a data model. A data model is a convention for specification of a structure of real-world information as it is perceived by the creator [1]. Data models can be created concerning different aspects such as logic, physical structure or conceptualization. Physical data models describe the means by which data are stored. They are concerned with partitions, tablespaces and CPUS. Logical data models are concerned with the representation of data by a specific technology such as tables, columns or classes and tags. The semantic type of the model concerns the concepts of the model scope (the area of interest e.g. an industry area or organization). It consists of the things that are significant in the domain and the relationship assertions between two entity classes. This allows the specification of allowed facts and propositions that is possible to express with the model [2]. This is the type of the model developed for this deliverable.

7


Public


Deliverable D6.2

2.2. Semantic Reference Data Model

The introduction of a Semantic Data Model does not imply a ‘single standard’ immediately but, more precisely, a progressive convergence towards a single semantic reference data model. This model would be used by existing solutions as they progress through development lifecycles, recognising that there will be a required period of time before new common solutions can be adopted.

The semantic data model developed in this deliverable is not only a particular data model for one very specific instance of an information system, rather a reference data model that aims at providing a common and consistent way of describing the domain facilitating exchange of data between multiple heterogeneous information systems.

2.3. Ontology-based Data Model

The semantic reference data model is constructed in a very specific way. It is based on ontologies. An ontology is a formal, explicit specification of a conceptualization. Conceptualizations are an abstract model including objects, concepts and entities that are presumed to exist in a specific area of interest and their relationships that are presumed to exist [3]. Ontologies are described with a representational set of terms, making it formal and thus machine interpretable and define constraints with axioms on the terms explicitly to limit their interpretation and use [4].

This results only in the general framework for creating the semantic reference data model but does not impose any specific language (such as RDF or OWL) used for the model implementation.

Ontologies embody a promising means to produce an adaptable reference data model that incorporates and integrates various, yet related, domains. Traditionally, ontologies have been built and studied within the AI domain as well as NLP field in order to enable easy knowledge sharing and reuse [5]. In fact, ontologies have been facilitators for knowledge sharing amongst different applications as well as data flow between various objects (entities) [6]. The advantage of using ontologies, compared with traditional data models such as UML and ERD diagrams, is that they introduce means and methods in order to incorporate and integrate disjointed models into one without dropping the original style and notation of each data model [7]. Moreover, using ontologies facilitates (semantic) data consistency and enables reasoning. The data and its associated relationships that will come from the shop floor in the different use cases within this project can be modelled using ontologies.

Existing ontologies have been derived in order to support the modelling of virtual enterprises, such as MISSION [8] and FDM [9], but they were not designed for the manufacturing domain. MSE ontology [10] on the other hand have been specifically developed for semantic interoperability across extended manufacturing teams, and proposed seven main classes based on manufacturing system information models: Project, Process, Resource, Flow, Enterprise, Extended Enterprise, and Strategy. MASON1 ontology [11] have proposed three main concepts: entities, operations and resources. Similarly, “Product-Process” Integration ontology [12] used only Resource, Product and Process main concepts.

Even though the domain of these ontologies is usually wider than the ones normally covered by the technical standards, it can be observed that the entities and classes within these ontologies are not extending or importing the concepts of the available standards, which hinders their suitability for our semantic reference model.

1 MASON : Manufacturing's Semantics Ontology

8


Public


Deliverable D6.2

3. Methodology The development of the semantic reference data model in the context of the ScalABLE4.0 project calls for a specific methodology that considers the given frame conditions. The semantic reference data model needs to be applicable to two different use cases. Although both of them aim at assembling products, the Simoldes use case differs from the PSA use case by including some sort of manufacturing (injection moulding) and packing of the products. As this is difficult to address in a single ontology, the considered approach is to develop different ontologies within a generic ontology that describes underlying semantics that can be applied to both use cases. Then, a domain ontology instances that cover the specific aspects required for each use case would be populated by instances of classes from the generic ontology. In the following sections, the development method of the generic ontology is described. An overview of the applied methodology is visualized in Figure 1.

The general problem statement of the work package serves as a starting point for the generic Scalable ontology. The project aims at enabling manufacturing enterprises to dynamically scale production lines to current production volume and variant as demanded by the market, through a tight integration of enterprise information systems and transformable equipment. For this purpose, production lines have to be effectively visualized, virtualized, constructed, controlled, maintained and optimized. All of this is only feasible if data from the shop floor can be leveraged by enterprise information systems in general and for optimization more specifically by simulation engines. This requires that manufacturing entities on the shop floor and enterprise information systems can effectively and efficiently exchange data. However, typically simulation engines and manufacturing entities on the shop floor have a varying representation of the data that can be provided or respectively are required to perform a specific task (e.g. search for an optimal production plan). In a traditional simple way, this problem is solved by implementing converters or interpreters that allow to transform or interpret the data retrieved from a data source. The goal of the ontology is, however, to facilitate this communication by providing semantic meaning that allows the interpretation of data provided without the need of an explicit meta-model.

Figure 1 Semantic reference data model development methodology

9


Public


Deliverable D6.2

For the creation of the generic Scalable ontology, the semantic model must be able to represent an entire manufacturing system. Clearly, this includes all the actors on the shop floor, such as machines, robots and workers as well as the tools that are used by these actors. Additionally, material consumed by these actors must be considered. Less obvious, but just as important, is the consideration of organizational constructs that are required for managing production lines effectively. This includes, for example, constructs such as orders or production plans. Entities that are candidates for consideration in the generic ontology are identified through analysis of relevant standards. From all the available standards, only those that are in wide use such as STEP-NC, ANSI/ISA95, Core Product Model, Industry Foundation Classes and Virtual Factory Data Model are selected in order to consider only relevant standards.

Besides deriving entities from the problem definition, a class model for the development of the Advanced Plant Model developed in WP5 serves as input for the generic Scalable ontology. This class model describes key entities required for the communication between different systems and robots within the ScalABLE4.0 project. Analysing the class diagram allows to verify and complement the entities identified from the standards.

The resulting generic ontology would be, as it is names suggests, the basis for populating (instantiating) the specific ontologies for the specific use cases and/or simulation engines within the ScalABLE4.0 project. For this purpose, two information sources are used:

Both Use Cases are described in a Use Case document (D2.1) which is analysed to identify the key entities and their instances represented in the domain. These are then matched with a general classes in the generic ontology and instances are developed for the specific factories/use cases.

A second source of information is represented by Simulation sample data provided in a semi-structured files. These files are further analysed to verify and extend the instances identified through analysing the use cases.

4. Analysis of Existing Standards The first input for the generic ontology represents the class diagram created in WP5 for the Advanced Plant Model (APM). It is analysed with respect to the general problem definition. The APM is visualized in Figure 2. The APM provides already several entities that are relevant for the ontologies. However, the ontology needs to be more detailed and requires a hierarchical structure that supports the integration of standards. Though, the class model serves as valuable input for modelling the properties of entities.

The fundamental problem of exchanging information between shop floor and enterprise systems has been addressed by the manufacturing information systems research community already with different approaches. Two main approaches can be found in literature: one approach aims at creating a standard data models and reference frameworks for information representation based on ontologies. The mostly cited models for the standard models are ISO/IEC 62264, STEP-NC and the Core Product Model. Industrial Foundation Classes and the Virtual Factory Data Model are the mostly wide known examples of reference frameworks for information presentation based on ontologies. All of these standards and reference frameworks are introduced and explained in the following.

10


Public


Deliverable D6.2

Figure 2 Advanced Plant Model from WP5

4.1. ISO/IEC 62246

The ISO/IEC 62246 is a standard for enterprise-control system integration which is based on ANSI/ISA-95. The standard aims at providing consistent terminology for facilitating communication and analysis between suppliers and manufacturers, models defining the structure of exchanged information and activity models that assist in clarifying the usage of information. The standard consists of 5 parts that focus on specific enterprise control integration aspects from different perspectives.

Part 1 contain standard terminology and object models that can be used for defining which information is exchanged between enterprise and control systems. One of the most important models in his part is the functional hierarchy model (see Figure 3). The model shows different functional layers from Business Planning & Logistics (level 4), over Manufacturing Operations and Control (level 3) to the Process Control layer (levels 2,1,0). Part addresses the interface between level 3 and 4 with the equipment hierarchy model, functional enterprise control-model, object models and categories of exchanged information model.

11


Public


Deliverable D6.2

Figure 3 ISO/IEC 62246-1 function hierarchy model

Part 2 expands on the object models in part 1 by providing detailed description in the form of attributes. Thereby the standard only describes the principle structure of exchanged information but it does not define the applied information exchange technology or the data type of the attributes.

Part 3 focuses entirely on level 3 of the hierarchy model. It presents models and terminology for manufacturing operations. It defines the manufacturing operations model that clarifies the focus of this part by highlighting for group of activities, production activities, inventory activities, maintenance activities and quality activities, and defines a border to the functions of the enterprise introduced in part 1. An additional generic activity model for manufacturing operations management serves a basis for describing activities in these four areas. The models on this levels can be used for specifying and comparing level 3 software systems functionalities.

Part 4 defines objects models and attributes that describe the information that is exchanged between activities on level 3. These can serve as input for the definition of interfaces between different systems on level 3.

Part 5 further details the information exchange escribed in part 1 and part 2 by adding in how this data is handled in the receiving system on levels 3 and 4. For this purposes several transactions are defined based on the exchange of messages. Messages can be either based on a pull model in which a system request information, a push model in which data is send to a system and a publish model for communicating to multiple systems [13].

As outlined in the introduction, the goal of the semantic reference model is the exchange of information between the shop floor and enterprise information systems, the focus on leveraging this standard lies on part 1 and 2. Shop Floor Information is typically collected on level 3 and the simulation within the ScalABLE4.0 project aims at scheduling a production plan, which is located on level 4 according to part 3 of the standard.

12


Public


Deliverable D6.2

4.2. STEP-NC

STEP-NC, the ISO 10303-238, is a standard for industrial automation systems and integration with the focus on product data representation and exchange. It specifies the information requirements for manufacturing using numerical controlled (NC) machining and related processes. The scope of the standard includes information on part shape (AS-IS and TO-BE), features, tolerances, description of manufacturing processes, tool requirements and tool paths. It does not include composite material parts, operations not executed by NC, design features manufacturing preplanning or catalogues on machines on the shop floor or available tools (ISO 10303-238).

STEP-NC provides an extensive data model including several different entities for describing the product and the manufacturing process. A simplified version of the data model is presented in Figure 4.

Figure 4 Simplified STEP-NC data model (Source: [14, 15])

Geometry of the workpiece, individual machining feature and the toolpath allow the precise and machine and organization independent description of manufacturing operations and the product in different stages. This enables the communication between application and NC machine as well as between two different application (e.g. Computer Aided Design and Computer Aided Process Planning). In STEP-NC a part program is defined as a series of operations that remove material defined by features. A feature defines 3D surfaces and represent either a hole, a slot, a pocket or a volume. An operation defines a volume of material that needs to be removed, tolerances, tool type required and additional operation characteristics (e.g. finishing operation). Operations are sequenced as a work plan. A work plan can include several control statements such as conditions when probing operations are used or parallel instructions if multiple tools can be used in one machine at the same time [15].

This standard is in particular relevant for describing details about the product and its processing on the shop floor actors.

13


Public


Deliverable D6.2

4.3. Core Product Model

The Core Product Model (CPM) is a product model developed by NIST aimed at supporting the entire range of PLM activities. It is a generic, open and extendable model that is not tied to a specific vendor or a specific product development process [16].

A product in CPM is described by form, function and behaviour aspect. Function models the product by what it is supposed to do. Form models the proposed design solution specified by its function. In CPM, geometry and material properties are considered by the form models. Behaviour models the implementation of the products function [17].

CPM is modelled using UML. A diagram of the model is represented in Figure 5.

Figure 5 Class Diagram of Core Product Model (Source: [17])

CPM is based on four categories of classes [17]:

(Abstract) Classes providing supporting information for the objects.

Conceptual or physical object classes: Artifact, Feature, Port, Specification, Requirement, Function, TransferFunction, Flow, Behavior, Form, Geometry, Material

Association or relationship classes (derived form CommonCoreRelationship): Constraint, EntityAssocation, Usage, Trace

Utility classes used by other classes (not shown in the diagram): Information, ProcessInformation and Rationale

14


Public


Deliverable D6.2

The CPM Model goes beyond STEP-NC by providing aspects from other phases of the product life-cycle. In particular, requirements and specification are relevant as this can have also an effect on handling the product on the shop floor.

4.4. Industrial Foundation Classes

The Industrial Foundation Classes (IFC) international standard is a standard for the computer-interpretable representation of construction and facility management information and for the exchange of building data. The IFC specifications is a “neutral” format normally used within the Construction and facility management sector. IFC is the international standard by buildingSMART [18] for openBIM and with IFC4 an ISO standard (ISO 16739).

The IFC was built partially on the STEP standard and represents the data that is exchanged between various construction (and facility management) projects’ participants.

The data schema architecture of this International Standard defines four conceptual layers, where each individual schema is assigned to exactly one conceptual layer. Figure 6 shows the schema architecture.

Figure 6 IFC data schema architecture with conceptual layers

15


Public


Deliverable D6.2

The four layers are:

Core Layer: The abstract concepts are defined in this layer. All entities defined at the core layer, or above carry a globally unique id and optionally owner and history information.

Resource Layer: The low level (or general purpose) concepts are defined in this layer. Those definitions do not include a globally unique identifier and are used depending on a definition declared at a higher layer.

Interoperability Layer: Concepts that are common to more than one domain are defined in this layer. Those definitions are typically utilized for inter-domain exchange and sharing of construction information.

Domain/Application Layer: specialisations of products, processes or resources specific to a certain discipline, those definitions are typically utilized for intra-domain exchange and sharing of information.

Although IFC was mainly developed for construction industry domain (e.g. Structural Analysis and Building Control), the data schemas and structures defined in this standard can be extended and specialised for other industry domains, as in our case the manufacturing domain. The Virtual Factory Data Model (VFDM) [19], for example, has adopted part of this standard for developing its model.

4.5. Virtual Factory Data Model

The Virtual Factory Data Model (VFDM) was established as a part of a bigger framework known as the Virtual Factory Framework (VFF) [20], which have been introduced to provide a “collaborative virtualized environment”. The goal of this environment was to facilitate the knowledge sharing and factory resources and supports the planning phases of the factory. At the core of VFF is the Virtual Factory Manager (VFM) [21], which orchestrates Virtual Factory modules and govern the shared repository that stores the data and knowledge defined in VFDM, which can be seen as the common “meta-language” in this context and creates the hierarchical structure of the underlying ontologies.

The goal of Virtual Factory Data Model (VFDM) is to formalise and integrate the main entities of the factory, which are called “Macro Areas” in VFDM (Table 1). These concepts are managed and processed by the digital tools that maintain the factory lifecycle. The data within this lifecycle is related to multiple domains [19], namely:

Factory: This domain represents the factory through its lifecycle;

Process: This domain represents the manufacturing processes implemented by the system;

Product: This domain represents the output of the factory;

Production Resource: This domain represents the resources used by the factory to perform the process to provide the output, i.e. the product. These resources cover all human and non-human resources, such as machines and AGVs;

Production System: This domain represents the transformation system, such as manufacturing or assembly systems, that would alter the product within the process using a physical resource.

Building: This domain represents the actual physical factory structure.

The VFDM is a highly relevant model for creating the ontology-based reference data model as it shows how an existing standard out of the manufacturing domain can be customized for an application in the manufacturing domain. However, the model cannot be directly applied as it is not publicly available on one hand and is concerned with different use cases on the other hand.

16


Public


Deliverable D6.2

Table 1 Macro areas in the VFDM (source: [19])

VFDM – Macro Area Ontologies

Commons

VffCommons; IfcActorResource, IfcCostResource, IfcDateTimeResource, IfcUtilityResource, IfcRepresentationResource, IfcExternalReferenceResource, IfcTopologyResource, IfcGeometricConstraintResource, IfcGeometricModelResource, IfcGeometryResource, IfcMaterialResource, IfcMeasureResource, IfcPropertyResource, IfcQuantityResource; IfcKernel, IfcProductExtension, IfcProcessExtension, IfcControlExtension; VffStochasticResource, VffFailureResource

Building IfcSharedBldgElements

Product StepNcAP10, VffProduct

Process VffProcess

Production Resources VffProductionResource

Production System VffSystem

Factory VffFactory

Figure 7 VFDM architecture (Source: [19])

17


Public


Deliverable D6.2

5. Scalable Ontology Architecture Although it has adopted the IFC and STEP standards as a basis for its data model, VFDM has abandoned in their architecture the four conceptual layers used by IFC standard for its data schema architecture. In the proposed reference data model, the various knowledge domains of the ontology would be organized into the same layers as IFC, where each layer would include a number of ontologies and, therefore, providing a hierarchical structure for the reference data model.

Table 2 shows the four-level architecture of the ontology and the ontologies contained in all data schema layers. Overall, the ontology has 30 classes, 159 object properties and 7 enumerations. The following sections detail the ontology layers and the included ontologies, while stressing their main characteristics. The basis for the architecture is the owl representation of IFC standard (ifcOWL) [22].

Two main assumptions were used when developing this architecture:

“Sca” prefix is used for ontologies that contain new classes definitions (e.g. ScaCore), while imported (existing) ontologies and/or international standards would use their own source acronym, such as “Ifc” for Industrial Foundation Classes standard.

New classes follow the same rule, where new classes are named using “Sca” prefix (e.g. ScaProcess), where imported (existing) classes from international standards would be using their own source acronym as a prefix, such as “Ifc” (e.g. IfcMaterial).

Table 2 Scalable ontology architecture

Ontology Layer Ontologies

Resource Layer ScaUtilities

Core Layer ScaCore: ScaProduct, ScaProcess, ScaProductionResource

Interoperability Layer ScaInteroperability: ScaSharedProcesses, ScaManufacturingFacility, ScaSharedResource, ScaSharedProdcutionManagement

Applications/Domains Layer

ScaDomain: ScaAssemblyDomain, ScaManufacturingDomain

5.1. Resource Layer

Within this layer, there is the Scalable ScaUtilities ontology that introduces the main definitions used by other ontologies in other layers. Within the ScaUtilties, two sub-areas are defined:

IFC Resources: resource ontology derived from the IFC standard.

SCA Performance Indicators Resource: The novel ontology for process performance indicators.

5.1.1. IFC Resources

IfcResource layer contains 21 ontologies that define the supporting data structures, out of which 15 ontologies were imported into ScaUtilities ontology and are used by other ontologies in other layers. The imported ontologies are:

IfcDateTimeResource

IfcMaterialResource

IfcExternalReferenceResource

IfcGeometricConstraintResource,

18


Public


Deliverable D6.2

IfcGeometricModelResource

IfcGeometryResource

IfcActorResource

IfcPropertyResource

IfcQuantityResource

IfcTopologyResource

IfcUtilityResource

IfcCostResource

IfcMeasureResource

IfcConstraintResource

IfcRepresentationResource

5.1.2. SCA Resources

The SCA Resources layer defines the performance indicators types that can be applied to amounts and ratios related to entities within a scalable factory. The type of the performance indicator is defined by the enumeration ScaPerformanceIndicatorTypeEnum. The enumeration includes:

ScaUtilizationPerformance represents the proportion of utilization of the available time, expressed as a percentage that a resource is operating.

ScaEfficiencyPerformance is the ratio of useful output to total input (i.e. resources in terms of material energy and time).

ScaProductivityPerformance is the rate at which an output is produced by one unit of input.

ScaScrapPerformance is the amount of defective products.

ScaDownPerformance is the amount of time a resource is not available due to maintenance, breakdown or setup.

5.2. Core Layer

The Scalable core ontology defines the fundamental structure and relationships as well as the main concepts within the ontology that are used by other areas. This ontology extends IfcKernel ontology, which defines the main abstract classes based on the generic concepts, such as object property and relationship. As can IfcObjectDefinition class, which is the specialization of IfcRoot, is the generalization of any semantically treated thing or process, either being a type (i.e. IfcTypeObject) or an occurrence (i.e. IfcObject). IfcRelationship class is the generalization of all relationships between things that are treated as objectified relationships, while IfcPropertyDefinition is the generalization of all characteristics that may be assigned to objects. The ontology class hierarchy is represented in Figure 8.

Within IFC standard, IfcKernel ontology is imported by the other extension ontologies in the core layer (IfcProductExtension, IfcProcessExtension, and IfcControlExtension).

19


Public


Deliverable D6.2

Figure 8 IfcKernel ontology class hierarchy

5.2.1. ScaProduct

ScaProduct is a new ontology that defines the main concepts of the Scalable factory product through adopting and merging STEP and relevant concept of the Core Product Model. The main class defined in this is ScaProduct. This class is extending IfcProduct and is a representation of any product produced by a Scalable factory. As ScaProduct can consist of multiple components the new class ScaPart is introduced. This class also extends IfcProduct, too.

Adapting from the StepNcAP10, this ontology creates several classes related to the workpiece, such as StepNcWorkpiece, StepNcManufacturingFeature, StepNcOperation, StepNcWorkingstep and StepNcToolpath. These classes contain descriptions related to the workpiece, such as material and geometric data, as well as the general data necessary for all operations, such as machining. In addition two enumerations, StepNcToolpathTypeEnum (approach, lift, connect, non-contact, contact, trajectory path) and StepNcToolDirectionEnum (two axes or three axes) are defined.

From the Core Product Model the concept of requirements and specification are adopted. This is represented by two new classes CpmRequirement that are contained in CpmSpecification. These classes are subclasses of IfcObject and are used to describe what requirements a product has to satisfy. To distinguish the nature of the requirement an enumeration CpmRequirementTypeEnum (form or function) is introduced. The ontology class hierarchy is visualized in Figure 9.

Figure 9 ScaProduct ontology class hierarchy

20


Public


Deliverable D6.2

In the following tables (Table 3 to Table 12) object properties of these classes are described. The tables contain the name of the object property, the range and the description of its intent. The domain of the object property is the respective class.

Table 3 ScaProduct object properties

ScaProduct

Object Property Name Range Description

Description IfcText Human readable characterization

Name IfcLabel Human readable name

Identification IfcIdentifier Machine readable identifier

Part ScaPart Parts a Product may consist of

Workpiece StepNCworkpiece Workpiece the product is geometrically represented with

Specification CPMSpecification Specification of the product pointing to specific requirements

Table 4 ScaPart object properties

ScaPart





Part ScaPart Parts a Product may consist of

Workpiece StepNCworkpiece Workpiece the product is geometrically represented with

Table 5 StepNcWorkpiece object properties

StepNcWorkpiece





Material IfcMaterial Material of Workpiece

BoundingVolume IfcShapeRepresentation Volume that is bounded by workpiece (box or cylinder)

Geometry IfcShapeRepresentation Geometry of the final workpiece

ManufacturingFeature StepNCManufacturingFeature Manufacturing the workpiece requires to be carried out

21


Public


Deliverable D6.2

Table 6 StepNcManufacturingFeature object properties

StepNcManufacturingFeature



Operation StepNCOperation Operations required for manufacturing the feature

FeatureType StepManufacturingFeatureTypeEnum Type of the manufacturing feature as one value of the enumeration

Table 7 StepNcOperation object properties

StepNcOperation


Toolpath StepToolPath Toolpath the tool

ToolDirection StepToolDirectionENum Type of Tool direction

Table 8 StepNcToolpath object properties

StepNcToolpath


Toolpath IfcShapeRepresentation Shape of the Toolpath

ToolpathType StepToolPathTypeEnum Type of Toolpath

Table 9 StepNcWorkingStep object properties

StepNcWorkingStep


ManufacturingFeature IfcText Human readable characterization

Operation StepNcOperation Operations included in WorkingStep

Table 10 StepNcWorkplan object properties

StepNcWorkplan





WorkingStep StepNcWorkingStep Sequence of WorkingSteps required to create the product

22


Public


Deliverable D6.2

Table 11 CpmSpecification object properties

CpmSpecification





Requirement CpmRequirement Requirement the specification includes

Table 12 CpmRequirement object properties

CpmRequirement



Identification IfcIdentifier Machine readable identifier of the production scheduling

Value IFCReal Value of the requirement

Unit IFCDerivedValue Unit in which requirement is measured

RequirementType CpmRequirementTypeEnum Type of the requirement

5.2.2. ScaProcess

ScaProcess is the ontology that models the information that represents the “transformation” processes within the Scalable factory carried out by either human operators or robots. This ontology imports the IfcProcessExtension and creates two new classes ScaProcess and ScaProcessType. ScaProcess extends IfcProcess and is a representative of a generic scalable factory’s transformation process. The ontology class hierarchy is visualized in Figure 10.

Figure 10 ScaProcess ontology class hierarchy

As in the previous section (5.2.1), in Table 13, object properties of the class are described.

Table 13 ScaProcess object properties

ScaProcess





StandardOperationProcedure SCAStandardOperatingProcedure Standard Operation Procedure the process is associated with

23


Public


Deliverable D6.2

5.2.3. ScaProductionResource

The ScaProductionResource ontology models the information associated with the production resources in a Scalable Factory that are used in order to produce the product, such as human operators and robots. Two main classes are defined in this ontology: ScaProductionResource. ScaProductionResource class extends IfcResource class. ScaProductionResource instances correspond to a single item (e.g. person, machine). ScaProductionResource is specialized by ScaEquipment, ScaRobot, ScaHumanOperator, ScaContainer classes. These classes are the representation of the main four production resources in Scalable factory: robots, human operators, equipment, and containers.

In addition, an enumeration ScaResourceStateEnum is defined for defining the state of the resource (NonScheduled, UnscheduledDown, ScheduledDown, Standby, Engineering, Productive).

The ontology class hierarchy is visualized in Figure 11.

Figure 11 ScaProductionResource ontology class hierarchy

In the following tables (Table 14 to Table 18), object properties of these classes are described.

Table 14 ScaProductionResource object properties

ScaProductionResource




BoundingVolume IfcShapeRepresentation Volume bound by the resource can be cylinder or box

Location IfcObjectPlacement Location of the object relative to the world coordination system

Table 15 ScaEquipment object properties

ScaEquipment


ManufacturingDate IfcDate Human readable characterization

Manufacturer IfcLabel Human readable name

SerialNumber IfcIdentification Serial number of equipment

Skill ScaSkill Skill an equipment has in order to fulfil a task

State ScaResourceStateEnum Current state of the resource

24


Public


Deliverable D6.2

Table 16 ScaRobot object properties

ScaRobot




SerialNumber IfcIdentification Serial number of equipment

Skill ScaSkill Skill an equipment has in order to fulfils a task

State ScaResourceStateEnum Current state of the resource

Table 17 ScaOperator object properties

ScaOperator




SerialNumber IFCIdentification Serial number of equipment

Skill SCASkill Skill a robot has in order to fulfil a task

Table 18 ScaContainer object properties

ScaContainer




SerialNumber IFCIdentification Serial number of equipment

5.3. Interoperability Layer

In this layer, classes that are common to more than one domain are defined. Entities defined in this layer can be referenced and specialized by all entities above in the hierarchy.

5.3.1. ScaSharedProcesses

The ScaSharedProcesses ontology defines classes for processes that can exist across domains. ScaProcessType is subclassed by ScaPackingProcess. The packing process can exist in manufacturing domain as well in the assembly domain. For defining the packing type the new enumeration ScaPackingTypeEnum (pallet or bulk) is defined.


25


Public


Deliverable D6.2

Figure 12 ScaSharedProcess ontology class hierarchy

In Table 19, object properties of these classes are described.

Table 19 ScaPackingProcess object properties

ScaPackingProcess


PackingType ScaPackingTypeEnum Standard cycle time of machine for processing a product on the machine

5.3.2. ScaSharedProductionResources

The ScaSharedProductionResources ontology defines basic classes of production resources that can exist across different domains. ScaEquipment is subclassed by ScaMachine, ScaConveyorBelt, ScaDockingStation and ScaTool. All of these can exist in all manufacturing domains.


Figure 13 ScaSharedProductionResources ontology class hierarchy


Table 20 ScaMachine object properties

ScaMachine


CycleTime IfcTimeMeasure Standard cycle time of machine for processing a product on the machine

ModelNumber IfcText The model information

26


Public


Deliverable D6.2

Table 21 ScaConveyorBelt object properties

ScaConveyorBelt


ConveyingVelocity IfcLinearVelocityMeasure Standard speed at which the conveyor belt is capable of moving parts

MaximumConveyingWidth IfcLengthMeasure Maximum width of parts the conveyor belt is capable of moving

Table 22 ScaDockingStation object properties

ScaDockingStation


CompatibleRobot ScaAGV AGV that is able to be charged on docking station

Port IfcPort Port for connecting to the docking station

Table 23 ScaTool object properties

ScaTool


Weight IfcMassMeasure Weight of the tool

Handle IfcPort Handle for gripping the tool

5.3.3. ScaManufacturingFacility

This ontology defines the classes that represents the main elements within the manufacturing facility that constitutes the main areas of the factory structure. ScaManufacturingFacility, ScaManufacturingArea, ScaWorkstation, ScaProductionLine subclass IfcObject. They represent the organizational structure within the Scalable factory.


Figure 14 ScaManufacturingFacility ontology class hierarchy

In the following tables (Table 24 to Table 27) , object properties of these classes are described.

27


Public


Deliverable D6.2

Table 24 ScaManufacturingFacility object properties

ScaManufacturingFacility







ContainedManufacturingArea ScaManufacturingArea Manufacturing areas contained in manufacturing facility

Table 25 ScaManufacturingArea object properties

ScaManufacturingArea







ContainedWorkstation ScaWorkstation Workstations contained in manufacturing area

Table 26 ScaProductionLine object properties

ScaProductionLine







ContainedProductionLine SCAProductionLine Production line contained in manufacturing area

28


Public


Deliverable D6.2

Table 27 ScaWorkstation object properties

ScaProductionLine







5.3.4. ScaSharedProdcutionManagement

The ScaSharedProductionManagement ontology defines basic concepts that are common to management throughout the various stages of the production lifecycle. There are two key superclases in this ontology: IfcControl and IfcProcess.

ScaProductionOrder, ScaLot, ScaSkill, ScaProductionScehduling, and ScaKeyPerformanceIndicator classes subclass IfcControl. These classes represent the main management elements that are shared by various domains. A production schedule as it is required for scheduling tasks within the Scalable factory is subclasses from IfcWorkSchedule.

ScaManufacturingTask which describes a single task as a part of a Standard Operating Procedure is sublcassed by IfcTask which itself is a subclass of IfcTask.

As many of production management classes require a status regarding completion, the enumeration ScaCompletionStatus (Planned,InProgress,Completed) is created.


Figure 15 ScaSharedProductionManagement ontology class hierarchy


29


Public


Deliverable D6.2

Table 28 ScaProductionOrder object properties

ScaProductionOrder


Name IfcLabel Human Readable Name


DueDate IfcDate Due data of the order

PlannedStartDate IfcDate Planned start date of production order

PlannedEndDate IfcDate Planned end date of production order

Lot ScaLot Lot associated with production order

Product ScaProduct Product that is ordered

CompletionStatus ScaCompletionEnum Indicating the status of the completion

ActualStartDate IfcDate Actual start date

ActualEndDate IfcDate Actual end date

Table 29 ScaLot object properties

ScaLot




Progress IfcReal Percentage of progress measured by the number of SOPs completed in production scheduling

ProductAmount IfcInteger Number of products in the lot




Table 30 ScaProductionScheduling object properties

ScaProductionScheduling





ProductionSequence ScaStandardOperationProcedure Sequence of procedures involved in production scheduling of a lot

30


Public


Deliverable D6.2

Table 31 ScaKeyPerformanceIndicator object properties

ScaKeyPerformanceIndicator



IndicatorValue IfcReal Value of the Performance Indicator

PredefinedType ScaPerformanceIndicatorEnum Predefined Type of Perforamnce Indicator

Table 32 ScaSkill object properties

ScaSkill





Table 33 ScaStandardOperatingProcedure object properties

ScaStandardOperatingProcedure



Workstation ScaWorkstation Workstation the Standard Operating Procedure is conducted at




StandardDuartion IfcTimeMeasure Standard time of the Standard Operation Procedure requires

ProcessType ScaProcessType Process type of the Standard Operation Procedure

Table 34 ScaManufacturingTask object properties

ScaManufacturingTask






StandardDuartion IfcTimeMeasure Standard time the task requires

Skill ScaSkill Skill required for the task

31


Public


Deliverable D6.2

5.4. Domain Layer

The domain layer includes two layers with classes that are specifically used only in a particular domain. The ontology domains defined for the scalable ontology are manufacturing and assembly. These have been derived from analysing the two use cases.

5.4.1. ScaManufacturingDomain

The ontology ScaManufacturingDomain defines ontologies for the manufacturing domain. Together with ontologies on the ScaCore and ScaUtilities classes on this ontology allow to define models that are used in manufacturing as defined as the physical transformation of a product created from solid materials. Within the domain, ScaProductionRessources are further subclasses by specific classes.

ScaTool is subclassed by ScaMachineTool, which represents the class of tools that are specifically used for machines. This is further subclassed by the type ScaMold, which is a special tool that is required by injection molding machines for defining the shape of the product.

ScaProcessType is specialized by subclasses ScaManufacturingProcess, which is subclassed by the new class ScaInjectionMoldingProcess. This a type for all injection molding processes.


Figure 16 ScaManufacturingDomain ontology class hierarchy


Table 35 ScaMachineTool object properties

ScaMachineTool





Machine ScaMachine Machine the tool is used for

32


Public


Deliverable D6.2

Table 36 ScaMold object properties

ScaMold


Shape IfcShapeRepresentation Shape of the part including

Port IfcPort Port for handling the device

FillingVolume IfcVolumeMeasure Volume of material that is injected into mold

FillingMaterial IfcMaterial Materials allowed to fill the Mold

MaintenanceInterval IfcCountMeasure Number of times the mold can be used before maintenance is required

Table 37 ScaManufacturingProcess object properties

ScaManufacturingProcess





Table 38 ScaInjectionMoldingProcess object properties

ScaInjectionMoldingProcess


AllowedMaterial IfcMaterial Material allowed for the injection molding process

HollowMoldAllowed IfcBoolean Possibility to create hollow molds

5.4.2. ScaAssemblyDomain

Similar to the manufacturing domain the ScaAssemblyDomain ontology defines classes for the assembly domain which is defined as the physical transformation of product in which components are joined together to form a greater artifact fulfilling a purpose.

ScaAuxiliaryEquipment subclasses ScaEquipment. It represents an equipment that is used for assisting in assembling a product.

ScaProcessType is specialized by subclasses ScaAssemblyProcess, which can be used for creating individuals of assembly processes. For defining the joining type used in assembly process the enumeration ScaJoiningType (ultrasound, glued, mechanical) is introduced.


33


Public


Deliverable D6.2

Figure 17 ScaAssemblyDomain ontology class hierarchy

In the following tables (Table 39 and Table 40), object properties of these classes are described.

Table 39 ScaAuxiliaryEquipment object properties

ScaAuxiliaryEquipment


AssistedEquipment ScaEquipment Equipment the auxiliary equipment is used with in conjunction

Port IfcPort Ports the auxiliary equipment can be used to connect with

Table 40 ScaAssemblyProcess object properties

ScaAssemblyProcess


JoiningType ScaJoiningEnum Equipment the auxiliary equipment is used with in conjunction

6. Summary It is essential for the factories and their associated production systems to evolve constantly in order to face and exploit changes in both markets and technologies. The current approaches for addressing effectively the complexity within the factory lifecycle phases do not meet the industry’s needs and do not provide all the required support, essentially due to the lack of interoperability. Therefore, this deliverable founds a standardized and expansible reference data model to represent the factory main objects that are related to products, processes, and resources. This reference data model can be seen as the shared “meta-language”, which offers shared definition of the data and knowledge in this context.

Through analysing existing standards (STEP-NC, IFC, CPM, ISO/IEC 62246), it was found that each of these standards focuses on a particular part of the factory. Therefore, it was essential to integrate these various viewpoints and contributions in order to cover the knowledge domains within the Scalable factory.

Ontologies were chosen as the structure for the reference data model since they provide the means and methods to integrate the various standards’ data models into one unique reference model without dropping the original notation of the individual standards. In addition, using ontologies ensures that data consistency is done on a semantic level and that semantic reasoning and inference can be carried out.

34


Public


Deliverable D6.2

This process resulted in creating a generic ontology that has 30 new classes, 159 object properties and 7 enumerations, in addition to existing classes from the aforementioned standards. This ontology-based reference data model will enable the data interoperability not only between different legacy system and tools, but also with the smart objects available along the shop floor. This model will be also used to infer knowledge about the current state of the manufacturing system. Based on this inferred knowledge, the Simulation and optimizer platform will be able to propose and evaluate the design and operation of complex real world manufacturing systems.

7. References

[1] N. Rishe, Database design: the semantic modeling approach., New York, NY, USA: McGraw-Hill, Inc., 1992.

[2] D. W. Embley , "Semantic Data Model," in Encyclopedia of Database Systems, L. Liu and M. T. Özsu, Eds., Boston, MA, Springer, 2009, pp. 2559-2561.

[3] T. R. Gruber, "A translation approach to portable ontology specifications," Knowledge acquisition, vol. 5, no. 2, pp. 199-220, 1993.

[4] I. F. Cruz and H. Xiao, "The role of ontologies in data integration," Engineering intelligent systems for electrical engineering and communications, vol. 13, no. 4, pp. 245-262, 2005.

[5] B. S. Kulvatunyou, H. Cho and Y. J. Son, "A semantic web service framework to support intelligent distributed manufacturing.," International Journal of Knowledge-based and Intelligent Engineering Systems, vol. 9, no. 2, pp. 107-127, 2005.

[6] T. Moser, W. D. Sunindyo, M. Merdan and S. Biffl, "Supporting Runtime Decision Making in the Production Automation Domain Using Design Time Engineering Knowledge," in Ontology and Semantic Web for Manufacturing, Crete, Greece, 2011.

[7] M. Hepp, P. De Leenheer, A. de Moor and Y. Sure, Ontology management: semantic web, semantic web services, and business applications, Springer Science & Business Media, 2007.

[8] J. A. Harding, K. Popplewell and D. Cook, "A manufacturing system engineering moderator: an aid for multi-discipline project teams," International Journal of Production Research, vol. 41, pp. 1973-1986, 2003.

[9] J. A. Harding, A. R. Omar and K. Popplewell, "Applications of QFD within a concurrent engineering environment," International Journal of Agile Management Systems, vol. 1, no. 2, pp. 88-98, 1999.

[10] H.-K. Lin, J. A. Harding and M. Shahbaz, "Manufacturing system engineering ontology for semantic interoperability across extended project teams," International journal of production research, vol. 42, no. 24, pp. 5099-5118, 2004.

[11] A. Léger, J. Heinecke, L. J. Nixon, P. Shvaiko, J. Charlet, P. Hobson and F. Goasdoué, "The semantic web from an industry perspective," in Reasoning Web International Summer School, P. Barahona, F. Bry, E. Franconi, N. Henze and U. Sattler, Eds., Heidelberg, Springer, 2006, pp. 232-268.

[12] P. Martin and A. D'Acunto, "Design of a production system: an application of integration product-process," International Journal of Computer Integrated Manufacturing, vol. 16, no. 7-8, pp. 509-516, 2003.

35


Public


Deliverable D6.2

[13] B. Scholten, The road to integration: A guide to applying the ISA-95 standard in manufacturing, Durham, USA: The International Society of Automation (ISA), 2007.

[14] WZL Aachen, "STEP-NC: Data-Model for intelligent NC-Machine Tools," [Online]. Available: http://www.step-nc.org/frames/iso14649_frames.htm. [Accessed 17 March 2018].

[15] STEP Tools Inc., "The STEP Standard - ISO 10303," [Online]. Available: http://www.steptools.com/stds/step/step_4.html. [Accessed 20 April 2018].

[16] S. Rachuri, Y.-H. Han, S. C. Feng, U. Roy, F. Wang, R. D. Sriram and K. W. Lyons, "Object-Oriented Representation of Electro- Mechanical Assemblies Using UML," NIST, 2003.

[17] S. FouFou, S. J. Fenves, C. Bock, S. Rachuri and R. D. Sriram, "A Core Product Model for PLM with an illustrative XML implementation," International Conference on Product Lifecycle Management, 1 1 2005.

[18] buildingSMART, "IFC Overview," 2016. [Online]. Available: http://buildingsmart-tech.org/specifications/ifc-overview. [Accessed 8 January 2018].

[19] W. Terkaj, G. Pedrielli and M. Sacco, "Virtual factory data model," in Proceedings of the workshop on ontology and semantic web for manufacturing, Graz, Austria, 2012.

[20] K. Efthymiou, K. Sipsas, D. Mourtzis and G. Chryssolouris, "On knowledge reuse for manufacturing systems design and planning: A semantic technology approach," CIRP Journal of Manufacturing Science and Technology, vol. 8, pp. 1-11, 2015.

[21] M. Sacco, G. Dal Maso, F. Milella, P. Pedrazzoli, D. Rovere and W. Terkaj, "Virtual Factory Manager. , vol 6774.," in Virtual and Mixed Reality - Systems and Applications, Lecture Notes in Computer Science, Berlin, Heidelberg, Springer, 2011, pp. 397-406.

[22] P. Pauwels and W. Terkaj, W. , "EXPRESS to OWL for construction industry: Towards a recommendable and usable ifcOWL ontology.," Automation in Construction, vol. 63, pp. 100-133, 2016.

Date post:	07-Jul-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

D6 - scalable40.eu€¦ · D6.2 Ontology-based Reference Data Model Ref. Ares(2018)2813496 -...

Documents