deliverable d3.1 z-bre4k semantic modelling › wp-content › uploads › 2019 › 09 ›...

Grant agreement nº: 768869

Call identifier: H2020-FOF-2017

Strategies and Predictive Maintenance models wrapped around physical

systems for Zero-unexpected-BRE4Kdowns and increased operating life

of Factories

Z-BRE4K

Deliverable D3.1 Z-BRE4K semantic modelling

Work Package 3

Knowledge and Predictive Modelling

Document type : Report

Version : V1.0

Date of issue : 30th December 2018

Dissemination level : Public

Lead beneficiary : 13 – EPFL

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement nº 768869. The dissemination of results herein reflects only the author’s view and the European Commission is not responsible for any use that may be made of the information it contains.

The information contained in this report is subject to change without notice and should not be construed as a commitment by any members of the Z-BRE4K Consortium. The information is provided without any warranty of any kind. This document may not be copied, reproduced, or modified in whole or in part for any purpose without written permission from the Z-BRE4K Consortium. In addition to such written permission to copy, acknowledgement of the authors of the document and all applicable portions of the copyright notice must be clearly referenced. © COPYRIGHT 2017 The Z-BRE4K Consortium. All rights reserved.

Z-BRE4K Project Grant Agreement nº 768869 – H2020-FOF-2017

D3.1 v1.0 / 91

Executive Summary

Abstract

This document reports on the results and deliverables of Task

3.1, i.e. “Semantic modelling of production assets, products

and processes”. Accordingly, it explains principles,

methodology, and all the entities of the project and model

relevant structures covering the maintenance domain.

Keywords

Semantic modelling, Ontology, Predictive maintenance,

production assets, products and processes, Strategy

implementation, Maintenance policies, Zero-breakdown,

Manufacturing


D3.1 v1.0 / 91

Revision history

Version Author(s) Changes Date

V0.1 Sangje Cho (EPFL) Deliverable outline 30/04/2018

V0.15 Sangje Cho (EPFL) Addressing comments

from Partners 11/05/2018

V0.2 Sangje Cho (EPFL) Update of contents

(Principles) 06/07/2018


(Methodology) 30/09/2018

V0.31 Alice Reina (HOLONIX) Competency

questions (SACMI) 06/11/2018

V0.32 Frauke Adam (Fraunhofer)

Competency

questions (Philips &

GESTAMP

08/11/2018


(Z-BRE4K ontology) 30/11/2018

V1.0 Sangje Cho (EPFL) First draft 12/12/2018


D3.1 v1.0 / 91

TABLE OF CONTENTS

TABLE OF CONTENTS ................................................................................................ 4

LIST OF FIGURES ....................................................................................................... 6

LIST OF TABLES ......................................................................................................... 7

ABBREVIATIONS ....................................................................................................... 8

1 INTRODUCTION ................................................................................................. 9

Objectives of Task 3.1 ............................................................................................ 9

Contents of the deliverable ................................................................................... 9

2 STATE-OF-THE-ART ON SEMANTIC MODELLING FOR MAINTENANCE ................ 11

Ontology Engineering .......................................................................................... 11

Semantic Modelling ............................................................................................. 11

2.2.1 Definition and components.......................................................................... 11

2.2.2 Ontology Languages ..................................................................................... 13

3 Z-BRE4K ONTOLOGY ........................................................................................ 16

Principles ............................................................................................................. 17

Methodology ....................................................................................................... 17

Competency Questions – SACMI .................................................................................... 18

Competency Questions – Philips .................................................................................... 19

Competency Questions – GESTAMP ............................................................................... 19

Classes.................................................................................................................. 22

Object Properties ................................................................................................. 25

Datatype Properties............................................................................................. 28

4 ONTOLOGY IMPLEMENTATION ........................................................................ 30

Functional requirements ..................................................................................... 31

Associated strategies ........................................................................................... 31

Component diagam ............................................................................................. 32

Supported APIs .................................................................................................... 32


D3.1 v1.0 / 91

5 CONCLUSION ................................................................................................... 34

6 REFERENCES .................................................................................................... 35

7 ANNEX............................................................................................................. 36


D3.1 v1.0 / 91

LIST OF FIGURES

Figure 1: Methodology to build Z-BRE4K ontology ..................................................................... 18

Figure 2: Logical diagram of Z-BRE4K semantic model ............................................................... 20

Figure 3: Hierarchy of Z-BRE4K semantic model ......................................................................... 21

Figure 4: Role and Interactions of Knowledge Base System ....................................................... 30

Figure 5: Knowledge Base System component diagram ............................................................. 32

Figure 6: Z-BRE4K ontology Class hierarchy ................................................................................ 36


D3.1 v1.0 / 91

LIST OF TABLES

Table 1: Z-BRE4K ontology classes .............................................................................................. 22

Table 2: Z-BRE4K ontology Object Properties ............................................................................. 25

Table 3: Z-BRE4K ontology Data Properties ................................................................................ 28

Table 4: Z-BRE4K ontology APIs .................................................................................................. 32

Table 5: Z-BRE4K ontology RDF implementation ........................................................................ 37


D3.1 v1.0 / 91

ABBREVIATIONS

Abbreviation Name

KB Knowledge Base

IT Information Technology

OWL Web Ontology Language

RDF Resource Description Framework

BFO Basic Formal Ontology

PLC Product Lifecycle

PSS Product Service System

CAx Computer-aided technologies

KBS Knowledge Base System


D3.1 v1.0 / 91

1 INTRODUCTION

This document describes the results of Task 3.1 defining all the entities and relations in the

context of Z-BRE4K.

WP 3 deals with the design and implementation of knowledge and predictive modelling. To

summarize, main objectives of WP3 are:

Semantic modelling to empower KBS for cognitive manufacturing.

Incorporation of risk analysis, KRIs and FMECA.

Incorporation of predictive/prescriptive analytics to support decision making and

associated Z-Strategies.

Objectives of Task 3.1

Task 3.1 develops the Z-BRE4K semantic model in the form of ontology designed to serve as a

common reference model for annotation and description of knowledge to represent

manufacturing system performance. Re-use of existing ontologies will be envisaged towards the

design of project’s ontology. The ontology will describe the basic entities of the project and

model relevant structures of manufacturing systems and processes, establishing a

methodological framework for modelling not only the actors and procedures at the shop floor,

but also machinery and their critical components, their failure modes and their criticality, their

signatures of healthy and deteriorated conditions, etc. It will be able to meet requirements for

access to different aspects of machinery and process related data and knowledge. In this

context, the ontology will be appropriately implemented using standard-based languages. The

Knowledge Base (KB) (T3.2) used for data analysis will be the central module of the system and

will include context-aware ontology to support predictive maintenance and extended operating

life of assets in production facilities and the relevant decision support engine.

Contents of the deliverable

The main purpose of this document is to present the implementation of the Z-BRE4K semantics

as an ontology. The Z-BRE4K ontology is a generalization of the business scenarios serving as an

upper template for all Z-BRE4K business cases as well as future business cases, and specific

ontologies describe the domain interests in each business scenario. The deliverable includes all

the classes and their relations together with links to existing ontologies.

As the main result of T 3.1, the Z-BRE4K ontology includes the domain of interest extracted using

the “competency questions” method which facilitates the recognition and definition of all the


D3.1 v1.0 / 91

requirements of all stake holders in the domain field. It encapsulates explicit knowledge as

ontology plays the role to add value for people who try to understand domain knowledge of Z-

BRE4K. Meanwhile, this ontology constitutes the formal representation of the Z-BRE4K semantic

model and the knowledge that this model encapsulates as the Z-BRE4K semantic component.

Therefore, to publish ontology as codification of the knowledge will allow to exchange

information regarding the maintenance context, in order to increase the added value of Z-BRE4K

platform. In addition, Z-BRE4K ontology enables integration of heterogeneous data from various

sensors. The data integration enables the Z-BRE4K platform to have semantic interoperability.

Meanwhile, the Z-BRE4K ontology has the ability to assume existence of rules expressing logics.

The Z-BRE4K ontology plays the role of defining the structure and contact of the Triple Store, to

be used to define semantic search parameters, and to be used to query triples.

The document is structured as follows. In Chapter 2, we provide a thorough state of the art

analysis of semantic technologies that comprise all the required knowledge to make the right

technical choices for implementing the Z-BRE4K Semantic Model as an ontology. In Chapter 3,

the Z-BRE4K Semantic Model is presented with a complete list of the associated concepts, object

properties and data type properties together with design principles and methodology.

Subsequently, Chapter 4 highlights relevant information concerning the actual implementation.

Finally, Chapter 5 concludes the document by highlighting the main results achieved and the

connections with future activities.


D3.1 v1.0 / 91

2 STATE-OF-THE-ART ON SEMANTIC MODELLING FOR MAINTENANCE

Ontology Engineering

Ontology engineering is the general term of methodologies and methods for building ontologies.

Ontology engineering refers to “The set of activities that concern the ontology development and

the ontology lifecycle, the methods and methodologies for building ontologies and the tool

suites and languages that support them” (Suárez-Figueroa et al., 2011). The results of ontology

engineering provide domain knowledge representation to be reused efficiently and prevent

waste of time and money which are usually caused by non-shared knowledge. It helps

Information Technology (IT) to operate with interoperability and standardization.

Semantic Modelling

2.2.1 Definition and components

Ontology represents the nature of being, becoming, existence, and so on in the way of

philosophy. One of the most well-known is: “ontology is an explicit, formal specification of a

shared conceptualization of a domain of interest” (Gruber, 1993).

Ontology represents the following ideas together (Calero at al., 1993):

Semantic modelling can help defining the data and the relationships between entities.

An information model provides the ability to abstract different kind of data and provides

an understanding of how the data elements are related.

A semantic model is a type of information model that supports the modelling of entities

and their relationships.

The total set of entities in our semantic model comprises the taxonomy of classes we

use in our model to represent the real world.

The main objective of semantic modelling techniques is to define the meaning of data within the

context of its correlation, and to model the domain world in the abstract level. The benefits of

exploiting semantic data models for business applications are mainly as follows:

Avoiding misunderstanding: by providing a clear, accessible, agreed set of terms,

relations as a trusted source and discussions, misunderstandings can easily be resolved.

Conduct reasoning: by being machine understandable and through the usage of logic

statements (rules), ontologies enable automatic reasoning and inference which leads to

automatic generation of new and implicit knowledge.

Leverage resources: by extending and relating an application ontology to external

ontological resources, via manual or automatic mapping and merging processes, the

need for repetition of entire design process for every application domain is eliminated.


D3.1 v1.0 / 91

Improve interoperability: semantic models can serve as a basis for schema matching to

support systems’ interoperability in close environments where systems, tools and data

sources have no common recognition of data type and relationships.

Ontologies provide formal models of domain knowledge exploited in different ways. Therefore,

ontology plays a significant role for many knowledge-intensive applications. Depending on

corresponding languages, a number of different knowledge representation formalisms exists.

However, they share minimal set of components as follows:

Classes represent concepts, which are taken in a broad sense. For instance, in the

Product Lifecycle domain, concepts are: Life Cycle phase, Product, Activity, Resources,

Even, and so on. Classes in ontology are usually organized in taxonomies through which

inheritance mechanisms can be applied.

Relations represent a type of association between concepts of the domain. They are

formally defined as any subset of a product of n sets, that is: R ⊂ C1 x C2 x ... x Cn.

Ontologies usually contain binary relations. The first argument is known as the domain

of the relation, and the second argument is the range.

Formal axioms serve to model sentences that are always true. They are normally used

to represent knowledge that cannot be formally defined by the other components. In

addition, formal axioms are used to verify the consistency of the ontology itself or the

consistency of the knowledge stored in a knowledge base. Formal axioms are very useful

to infer new knowledge.

For instance, Energy Efficiency at Buildings domain could be that it is not possible to build a

public building without a fire door (based on legal issues).

Instances are used to represent elements or individuals in an ontology.

As a Design Rationale (DR), ontology can be used as follows (Mizoguchi & Ikeda, 1998):

Level 1: Used as a common vocabulary for communication among distributed agents.

Level 2: Used as a conceptual schema of a relational database. Structural information of

concepts and relations among them is used. Conceptualization in a database is nothing

other than conceptual schema. Data retrieval from a database is easily done when there

is an agreement on its conceptual schema.

Level 3: Used as the backbone information for a user of a certain knowledge base. Levels

higher than this plays role of the ontology, which has something to do with "content".

Level 4: Used for answering competence questions.

Level 5: Standardization

Standardization of terminology (at the same level of Level 1)

Standardization of meaning of concepts

Standardization of components of target objects (domain ontology).

Standardization of components of tasks (task ontology)

Level 6: Used for transformation of databases considering the differences of the

meaning of conceptual schema. This requires not only the structural transformation but

also semantic transformation.


D3.1 v1.0 / 91

Level 7: Used for reusing knowledge of a knowledge base using DR information.

Level 8: Used for reorganizing a knowledge base based on DR information.

2.2.2 Ontology Languages

XML-based Ontology Exchange Language: The US bioinformatics community designed

XOL for the exchange of ontology definitions among a heterogeneous set of software

systems in their domain. Researchers developed it after studying the representational

needs of experts in bioinformatics. They selected Ontolingua (a Tool for Collaborative

Ontology Construction) and OML as the basis for creating XOL, merging the high

expressiveness of OKBC-Lite, a subset of the Open Knowledge Based Connectivity

protocol, and the syntax of OML, based on XML. There are no tools that allow the

development of ontologies using XOL. However, since XOL files use XML syntax, we can

use an XML editor to author XOL files.

Simple HTML Ontology Extension: SHOE is a small extension to HTML which allows web

page authors to annotate their web documents with machine-readable knowledge.

SHOE makes real intelligent agent software on the web possible. HTML was never meant

for computer consumption; its function is for displaying data for humans to read. The

"knowledge" on a web page is in a human-readable language (usually English), laid out

with tables and graphics and frames in ways that we as humans comprehend visually.

Unfortunately, intelligent agents aren't human. Even with state-of-the-art natural

language technology, getting a computer to read and understand web documents is

very difficult. This makes it very difficult to create an intelligent agent that can wander

the web on its own, reading and comprehending web pages as it goes. SHOE eliminates

this problem by making it possible for web pages to include knowledge that intelligent

agents can actually read.

Ontology Markup Language: OML, developed at the University of Washington, is

partially based on SHOE. In fact, it was first considered an XML serialization of SHOE.

Hence, OML and SHOE share many features. Four different levels of OML exist: OML

Core is related to logical aspects of the language and is included by the rest of the layers;

Simple OML maps directly to RDF(S); Abbreviated OML includes conceptual graphs

features; and Standard OML is the most expressive version of OML. We selected Simple

OML, because the higher layers don’t provide more components than the ones

identified in our framework. These higher layers are tightly related to the representation

of conceptual graphs. There are no other tools for authoring OML ontologies other than

existing general-purpose XML edition tools.

Ontology Interchange Language: OIL, developed in the OntoKnowledge project

(www.ontoknowledge.org/OIL), permits semantic interoperability between Web

resources. Its syntax and semantics are based on existing proposals (OKBC, XOL, and

RDF(S)), providing modeling primitives commonly used in frame-based approaches to

ontological engineering (concepts, taxonomies of concepts, relations, and so on), and

formal semantics and reasoning support found in description logic approaches (a subset


D3.1 v1.0 / 91

of first order logic that maintains a high expressive power, together with decidability

and an efficient inference mechanism). OIL, built on top of RDF(S), has the following

layers: Core OIL groups the OIL primitives that have a direct mapping to RDF(S)

primitives; Standard OIL is the complete OIL model, using more primitives than the ones

defined in RDF(S); Instance OIL adds instances of concepts and roles to the previous

model; and Heavy OIL is the layer for future extensions of OIL. OILEd, Protégé2000, and

WebODE can be used to author OIL ontologies. OIL’s syntax is not only expressed in XML

but can also be presented in ASCII. We use ASCII for our examples.

DARPA Agent Markup Language+OIL : DAML+OIL has been developed by a joint

committee from the US and the European Union (IST) in the context of DAML, a DARPA

project for allowing semantic interoperability in XML. Hence, DAML+OIL shares the

same objective as OIL. DAML+OIL is built on RDF(S). Its name implicitly suggests that

there is a tight relationship with OIL. It replaces the initial specification, which was called

DAML-ONT, and was also based on the OIL language. OILEd, OntoEdit, Protégé2000, and

WebODE are tools that can author DAML+OIL ontologies.

OWL: OWL is the result of the work of the W3C Web Ontology Working Group. This

language derived from DAML+OIL and, as the previous languages, is intended for

publishing and sharing ontologies in the Web. OWL is built upon RDF(S), has a layered

structure and is divided into three sublanguages: OWL Lite, OWL DL and OWL Full. OWL

is grounded on Description Logics and its semantics are described in two different ways:

as an extension of the RDF(S) model theory and as a direct model-theoretic semantics

of OWL. Both of them have the same semantic consequences on OWL ontologies.

OWL 2: OWL 2 is an extension and revision of OWL that adds new functionality with

respect to OWL; some of the new features are syntactic sugar (e.g., disjoint union of

classes) while others offer new expressivity. OWL 2 includes three different profiles (i.e.,

sublanguages) that offer important advantages in particular application scenarios, each

trading off different aspects of OWL's expressive power in return for different

computational and/or implementation benefits. These profiles are:

OWL 2 EL: It is particularly suitable for applications where very large ontologies are

needed, and where expressive power can be traded for performance guarantees.

OWL 2 QL: It is particularly suitable for applications where relatively lightweight

ontologies are used to organize large numbers of individuals and where it is useful or

necessary to access the data directly via relational queries (e.g., SQL).

OWL 2 RL: It is particularly suitable for applications where relatively lightweight

ontologies are used to organize large numbers of individuals and where it is useful or

necessary to operate directly on data in the form of RDF triples. OWL 2 ontologies: The

Direct Semantics that assigns meaning directly to ontology structures and the RDF-

Based Semantics that assigns meaning directly to RDF graphs.

Resource Description Framework and RDF Schema: RDF, developed by the W3C for

describing Web resources, allows the specification of the semantics of data based on

XML in a standardized, interoperable manner. It also provides mechanisms to explicitly

represent services, processes, and business models, while allowing recognition of

nonexplicit information. The RDF data model is equivalent to the semantic networks

formalism. It consists of three object types:


D3.1 v1.0 / 91

Resources are described by RDF expressions and are always named by URIs plus

optional anchor IDs

Properties define specific aspects, characteristics, attributes, or relations used

to describe a resource

Statements assign a value for a property in a specific resource (this value might

be another RDF statement)

The RDF data model does not provide mechanisms for defining the relationships between

properties (attributes) and resources—this is the role of RDFS. RDFS offers primitives for defining

knowledge models that are closer to frame-based approaches. RDF(S) is widely used as a

representation format in many tools and projects, such as Amaya, Protégé, Mozilla, SilRI, and so

on.

According to W3C, RDF model has advantages as follows:

The RDF model is made up of triples: as such, it can be efficiently implemented and

stored; other models requiring variable-length fields would require a more cumbersome

implementation

The RDF model is essentially the canonicalization of a (directed) graph and has all the

advantages (and generality) of structuring information using graphs

The basic RDF model can be processed even in absence of detailed information (an "RDF

schema") on the semantics: it already allows basic inferences to take place, since it can

be logically seen as a fact basis

The RDF model has the important property of being modular

The union of knowledge (directed graphs) is mapped into the union of the corresponding RDF

structures. Since RDF is a standard model for data interchange and is a W3C recommendation

designed to standardize the definition and use of metadata-descriptions of Web-based

resources, it is well suited to representing data. As knowledge representation, when it comes to

semantic interoperability, RDF has significant advantages (Decker at al., 2000): The object-

attribute structure provides natural semantic units because all objects are independent entities.

A domain model—defining objects and relationships—can be represented naturally in RDF. To

find mappings between two RDF descriptions, techniques from research in knowledge

representation are directly applicable. Therefore, the Z-BRE4K ontology has been implemented

in the RDF format.


D3.1 v1.0 / 91

3 Z-BRE4K ONTOLOGY

This section presents the Z-BRE4K ontology with foundations constituted on which the Z-BRE4K

Ontology is built. The main effort towards standardization is laid on the design of the semantic

model of the maintenance entities and the establishment of the reference as a means to provide

standards-based access to all the data in the domain of interest. The Z-BRE4K ontology deals

with the design and implementation of the semantic model and the mechanisms for intelligent

filtering. It provides a unified and all-spanning semantic model covering the multi-domain

knowledge of all the Z-BRE4K use cases. Therefore, the Z-BRE4K project will achieve semantic

enrichment through maintenance knowledge which deals with cross-sectoral knowledge

exploration and filtering. Thus, it requires semantic interoperability that is the ability of

information systems to exchange data unambiguously with shared meaning as a standard.

Standardization activities will be driven through involvement with Industry Ontology Foundry

(IOF) group and regular participation with their workshops. IOF is an international foundry

aiming at:

providing principles and best practices by which quality ontologies can be developed

that will support interoperability for industrial domains

creating a suite of open and principles-based ontologies from which other sub-domain

or application ontologies can be derived in a modular fashion, remaining 'generic' (i.e.,

non-proprietary, non-implementation specific)

instituting a governance mechanism to maintain and promulgate the goals and

principles

providing an organizational framework and governance processes that ensure

conformance to principles and best practices for development, sharing, maintenance,

evolution, and documentation of IOF ontologies.

The intent of these reference ontologies is to allow extensions to be progressive to more specific

or constrained sub-domains. For this reason, it has set up several domain sub-groups and one

of them is the maintenance IOF working group. By an iteration process, Z-BRE4K will provide

testbeds to build a reference semantic model in the maintenance domain, and maintenance IOF

subgroup will provide methodologies and principles for implementation of a standard semantic

model.

To summarize, main objectives of Z-BRE4K ontology are:

to identify the domain of interest, covering all relevant products, data sources,

information flow resources, design and manufacturing processes, user-interface access

points and dynamics of the entire system

to design and implementation of the semantic model

to provide a linked data integration framework that will extract, export, and harmonize

data from various sources

to enable semantic enrichment (e.g. annotations, tagging) of data originating from

disparate research or existing systems (PLM/CAx),


D3.1 v1.0 / 91

to provide an intelligent engine which will allow active exploration of the linked data

sets and implicit knowledge discovery

Principles

Entities in the Z-BRE4K semantic framework have been arranged based on the Basic Formal

Ontology (BFO) which is a formal ontology framework developed by Barry Smith and his

associates (Arp at al., 2015). In BFO, there are two varieties which are continuants

comprehending continuant entities such as three-dimensional enduring objects and occurrent

comprehending processes conceived as extended through (or as spanning) time. To adopt BFO

framework will provide availability to merge the other manufacturing domain ontology

structured by BFO of which domain is not only maintenance domain.

Originated from BFO, ontology design principles of Z-BRE4K are as follows:

use single nouns (except data) and avoid acronyms

ensure univocity of terms and relational expressions

distinguish the general from particular

provide all non-root terms with definitions

use essential features in defining terms and avoid circularity

start with the most general terms in the domain

use simpler terms than the term you are defining (to ensure intelligibility)

do not create terms for universals through logical combination

structure ontology around is_a hierarchy and ensure is_a completeness

single inheritance

Methodology

In order to design the taxonomies of describing maintenance engineering, the one of the well-

known development methodology through Competency Questions has been applied to (i) define

the application domain boundaries and (ii) capture elements definition. For generally applicable

solutions, generalization of the Z-BRE4K use cases is serving as a common reference model for

not only all the Z-BRE4K domain, but also further business scenarios which will be the application

of the Z-BRE4K platform. By composing a top-level overview, abstract concepts facilitate to

perform system architecture planning and optimization. After the extraction of entities from

Competency Questions, the list of classes was updated in a comparison with existing ontology

such as BFO, Product Lifecycle (PLC), and Product Service System (PSS) ontology. And then, all

the entities were rearranged in the BFO structure (See Fig. 1).


D3.1 v1.0 / 91

Figure 1: Methodology to build Z-BRE4K ontology

Competency question is one of the ways to determine the scope of the ontology and to sketch

a list of questions to be answered (Grüninger & Fox, 1995). These questions will serve as the

litmus test later: Does the ontology contain enough information to answer these types of

questions? Do the answers require a particular level of detail or representation of a particular

area? These competency questions are just a sketch and do not need to be exhaustive (Noy &

McGuinness, 2001). Competency questions for each Z-BRE4K use case are described below.

Competency Questions – SACMI

What machines/equipment are considered in each use cases?

What stakeholders/actors are considered for each use case?

What is BOM for each machine (as a hierarchy diagram)?

What component is critical for asset management in a specific use case?

What is the component scope?

What are the failure modes for each critical component?

What are the effects of each failure mode?

What is the criticality of each failure mode?

What kinds of actions are required before the failure?

What kinds of actions are required after the failure?

What kinds of sensor is available/required for each critical component?

What kinds of critical components are linked to a sensor?


D3.1 v1.0 / 91

What type of signals are collected from a sensor?

Which sensor/s is/are relevant to detect a specific failure mode?

Which is the signal unit of measurement?

Which is the minimum value of the signal?

Which is the maximum value of the signal?

How often signals are stored in repository?

Which is the sampling frequency of the signal?

In which working phase is included the control system?

In which working phase it is excluded the control system?

Which kind of mathematical elaboration is requested for the signal? (average, standard

deviation, RMS, …)

Competency Questions – Philips













Competency Questions – GESTAMP













Competency questions for each business scenario provide the fundamental principles for

building Z-BRE4K ontology. End-users’ requirements are interpreted in the form of competency

questions and Z-BRE4K ontology was designed by answering these questions.


D3.1 v1.0 / 91

Based on competency questions, the logical diagram (See Fig. 2) of maintenance was created

with the following contexts:

Each System as a maintainable item plays its own Role and this Role inheres in

Maintenance_Proccess_Definition

Each System consists of System_part and Embedded_Data-Source_Component

Embedded_Data-Source_Component generates Source_Data

Each System_part has Quality and Failure_Mode and Indicator presenting performance

Each Failure_Mode has Failure_Symptom and Indicator presenting its risk, probability,

and so on.

Depending on the condition, System requires Maintenance

Product_Provider provides System

Maintenance_Service_Provider provides Maintenance_Process_Definition

Business_Customer owns System

Figure 2: Logical diagram of Z-BRE4K semantic model

Entities of the maintenance domain were identified from the logical diagram, and then, entities

were aligned to a hierarchy (See Fig. 3) according to the principles in the chapter 3.1.


D3.1 v1.0 / 91

Figure 3: Hierarchy of Z-BRE4K semantic model

Classes

Table 1 lists the Z-BRE4K ontology classes, their sub-classes and their descriptions.

Table 1: Z-BRE4K ontology classes

Class SuperClass Class Name Description

1 Independent_Continuant Independent_Continuant (see BFO)

1_1 1 Material_Entity Material_Entity ( see BFO)

1_1_1 1_1 System The System is a Material_Entity which is a universal set of the target system

1_1_2 1_1 System_Component Product Component is a Material Entity which is a part of the System.

1_1_2_1 1_1_2 System_Part The System_Part is a System_Component which are a modularity subset of the system

1_1_2_5 1_1_2 Embedded_Data-Source_Component Embedded Data-Source Component is a Product Component that refers to product-embedded information devices / parts (e.g. sensors), which allows for (additional) services to be offered for the product.

1_1_3 1_1 Stakeholder Stakeholder/Actor is an entity that describes the humans (or beings) involved in a business scenario (development, deployment, use etc.).

1_1_3_1 1_1_3 Individual_Person Individual Person is a Stakeholder indicating a separate person who is not legal entity (i.e. not legally considered a corporate group, as for example a company).

1_1_3_1_1 1_1_3_1 Individual_Customer Individual Customer is an Individual Person that buys or consumes (consumer) any product/maintenance service.

1_1_3_1_2 1_1_3_1 Employee Employee is an Individual Person that works in a Company in the domain.

1_1_3_2 1_1_3 Company Company is a Stakeholder that can be one or more individuals forming a legal entity (corporate body).

1_1_3_2_1 1_1_3_2 Business_Customer Business Customer is a Company that buys and uses the products, and maintenance services. It is the (group/company) customer of the system, using the system for their own business.

1_1_3_2_2 1_1_3_2 Product_Provider Product Provider is a Supplier/ provider/vendor that both produces and sells a product, or only sells it.

1_1_3_2_3 1_1_3_2 Maintneance_Service_Provider Service_Provider is a Supplier/provider/vendor that offers a maintenance service.

2 Generally_Dependent_Continuant Generally Dependent Continuant (see BFO)

2_1 2 Resource_Entity Resource_Entity is a mean (source) that can be used for the design, development, offer and delivery of a PSS, from which benefit can be produced.

2_1_1 2_1 Source_Data Source-Data is a Resource_Entity that refers to the digitalised information coming as input from the product or the service, specifically for the scope of Project.

2_1_1_1 2_1_1 Product_Data Product Data are Source_Data used in the scope of product, and refer specifically to the system part.


D3.1 v1.0 / 91

2_1_1_1_1 2_1_1_1 Embedded_Data Embedded Data are Product Data generated from embedded data-source components.

2_1_1_1_2 2_1_1_1 Digital_Log_Data Digital Log Data are Product Data generated from a software element, part of the product.

2_2 2 Information_Entity Information_Entity is a Resource, immaterial, describing aspects affecting Project, and referring to all the (processed) data that one can acquire knowledge from, or further process.

2_2_1 2_2 Indicator The Indicator is a Information_Entity which is a observed value indicating the state or level of something

2_2_1_1 2_2_1 Key_Performance_Parameter The Key_Performance_Parameter is a indicator to measure the performance of each mode at time t

2_2_1_2 2_2_1 Key_Risk_Indicator The Key_Risk_Indicator is a indicator of risk exposures to address potential warning events

2_2_1_3 2_2_1 Risk_Probability_Indicator The Risk Probability Indicator is a indicator which is a frequency of occurrence of Failure_Effect

2_2_1_4 2_2_1 Severity_Indicator The Severity Indicator is a indicator of how serious and destructive a failure mode is

2_2_1_5 2_2_1 Detection_Indicator The Detection_Indicator is a numerical subjective estimation of the effectiveness of the controls to preven or detect the cause or failure mode before the failure (Threshold?)

2_2_1_6 2_2_1 Risk_Indicator The Risk is a indicator multipling Probability Indicator by Serverity Indicator of the failure

2_2_1_7 2_2_1 Risk_Priority_Number The Risk Priority Number is a indicator multipling Risk Indicator by Detection Indicator of the failure

2_2_2 2_2 Failure_Symptom The Failure_Symptom is a Failure_Mechanism_Entity which is a a physical feature that is regarded as indicating a condition of the failure

2_2_2_1 2_2_2 System_Failure_Symptom The System_Failure_Symptom is a Failure_Symptom described in the level of System

2_2_2_2 2_2_2 System_Part_Failure_Symptom The Subystem_Failure_Symptom is a Failure_Symptom described in the level of System_Part

2_2_3 2_2 Process_Definition

Process Definition is a structured set of activities designed to accomplish a specific objective. For example, the Process Definition can be the manufacturing process where the equipment is manufactured, or the process where the equipment is used, or the development process where products, and maintenance services are being developed etc.

2_2_3_1 2_2_3 Maintenance_Process_Definition Maintenance Process Definition is a Process Definition referring to a set of non-tangible entities (activities, software modules etc.), related to the maintenance service part, which aims to satisfy a need of the end-users.

2_2_3_1_1 2_2_3_1 Predictive_Maintenance_Process_Definition The Predictive_Maintenance_Process_Definition is a Maintenance_Process_Definition to prevent failures by monitoring

2_2_3_1_2 2_2_3_1 Correntive_Maintenance_Process_Definition The Correntive_Maintenance_Process_Definition is a Maintenance_Process_Definition to correct failures after break down or malfunction

3 Specifically_Dependent_Countinuant Specifically Dependent Countinuant (See BFO)

3_1 3 Realisable_Entity Realisable Entity (See BFO)

3_1_2 3_1 Failure_Mechanism_Entity Failure_Mechanism_Entity

3_1_2_1 3_1_2 Failure_Cause The Failure_Cause is a Failure_Mechanism_Entity which is a defect in design, process, quality, or part application, which are the underlying cause of a failure or which initiate a process which leads to failure.


D3.1 v1.0 / 91

3_1_2_1_1 3_1_2_1 System_Failure_Cause The System_Failure_Cause is a Failure_Cause described in the level of System

3_1_2_1_2 3_1_2_1 System_Part_Failure_Mode The System_Part_Failure_Mode is a Failure_Cause described in the level of System_Part

3_1_3 3_1 Quality Quality (See BFO)

3_1_3_1 3_1_3 Current_Quality The Current_Quality is a Quality at time t. If they inhere in an entity at all, they are fully exhibited or manifested or realized in that entity.

3_1_3_1_1 3_1_3_1 Current_System_Quality The Current_Quality is a Quality of an System entity at time t.

3_1_3_1_2 3_1_3_1 Current_System_Part_Quality The Current_System_Part_Quality is a Quality of an System_Part entity at time t.

3_1_3_2 3_1_3 Predicted_Quality The Predicted_Quality is a predicted Quality at future time t.

3_1_3_2_1 3_1_3_2 Predictied_System_Quality The Predictied_System_Quality is a Quality of an System entity at future time t.

3_1_3_2_2 3_1_3_2 Predictied_System_Part_Quality The Predictied_System_Part_Quality is a Quality of an System_Part entity at future time t.

3_2 3 Role (See BFO)

3_2_1 3_2 System_Role borne by a group of one or more System(s) by Maintenance_Process_Definition

3_2_2 3_2 System_Part_Role borne by a group of one or more System_Part(s) by Maintenance_Process_Definition

3_2_6 3_2 Embedded_Data-Source_Component_Role borne by a group of one or more Embedded_Data-Source_Component(s) by Maintenance_Process_Definition

4 Processual_Entity See BFO

4_1 4 Maintenance Maintenance is a Process made for, and driven by customers, with economic value, and refers to the maintenance Offer entity in conjunction with time t.


D3.1 v1.0 / 91

Object Properties

Table 2 lists the object properties of the Z-BRE4K ontology. For each property, the domain and range are defined.

Table 2: Z-BRE4K ontology Object Properties

ObjectProperty Domain Range Domain_IRI Range_IRI

has_System_Part System System_Part 1_1_1 1_1_2_1

has_System_Failure_Cause System_Role System_Failure_Cause 3_2_1 3_1_2_1_1

has_System_Part_Failure_Mode System_Part_Role System_Part_Failure_Mode 3_2_2 3_1_2_1_2

effects_System_Failure_Cause System_Part_Failure_Mode System_Failure_Cause 3_1_2_1_2 3_1_2_1_1

has_System_Failure_Symptom System_Failure_Cause System_Failure_Symptom 3_1_2_1_1 2_2_2_1

has_System_Part_Failure_Symptom System_Part_Failure_Mode System_Part_Failure_Symptom 3_1_2_1_2 2_2_2_2

has_Embedded_Data-Source_Component_of_System_Part System_Part Embedded_Data-Source_Component 1_1_2_1 1_1_2_5

generates_Embedded_Data Embedded_Data-Source_Component Embedded_Data 1_1_2_5 2_1_1_1_1

inheres_in_System_of_Current_System_Quality Current_System_Quality System 3_1_3_1_1 1_1_1

inheres_in_System_Part_of_Current_System_Part_Quality Current_System_Part_Quality System_Part 3_1_3_1_2 1_1_2_1

inheres_in_System_of_Predictied_System_Quality Predictied_System_Quality System 3_1_3_2_1 1_1_1

inheres_in_System_Part_of_Predictied_System_Part_Quality Predictied_System_Part_Quality System_Part 3_1_3_2_2 1_1_2_1

has_System_Failure_Cause_of_Current_System_Quality Current_System_Quality System_Failure_Cause 3_1_3_1_1 3_1_2_1_1

has_System_Part_Failure_Mode_of_Current_System_Part_Quality Current_System_Part_Quality System_Part_Failure_Mode 3_1_3_1_2 3_1_2_1_2

has_System_Failure_Cause_of_Predictied_System_Quality Predictied_System_Quality System_Failure_Cause 3_1_3_2_1 3_1_2_1_1

has_System_Part_Failure_Mode_of_Predictied_System_Part_Quality Predictied_System_Part_Quality System_Part_Failure_Mode 3_1_3_2_2 3_1_2_1_2

has_Detection_Indicator_of_System_Failure_Cause System_Failure_Cause Detection_Indicator 3_1_2_1_1 2_2_1_5

has_Detection_Indicator_of_System_Part_Failure_Mode System_Part_Failure_Mode Detection_Indicator 3_1_2_1_2 2_2_1_5

has_Key_Performance_Parameter_of_System System Key_Performance_Parameter 1_1_1 2_2_1_1

has_Key_Performance_Parameter_of_System_Part System_Part Key_Performance_Parameter 1_1_2_1 2_2_1_1

has_Key_Risk_Indicator_of_System_Failure_Cause System_Failure_Cause Key_Risk_Indicator 3_1_2_1_1 2_2_1_2

has_Key_Risk_Indicator_of_System_Part_Failure_Mode System_Part_Failure_Mode Key_Risk_Indicator 3_1_2_1_2 2_2_1_2

has_Risk_Probability_Indicator_of_System_Failure_Cause System_Failure_Cause Risk_Probability_Indicator 3_1_2_1_1 2_2_1_3


D3.1 v1.0 / 91

has_Risk_Probability_Indicator_of_System_Part_Failure_Mode System_Part_Failure_Mode Risk_Probability_Indicator 3_1_2_1_2 2_2_1_3

has_Severity_Indicator_of_System_Failure_Cause System_Failure_Cause Severity_Indicator 3_1_2_1_1 2_2_1_4

has_Severity_Indicator_of_System_Part_Failure_Mode System_Part_Failure_Mode Severity_Indicator 3_1_2_1_2 2_2_1_4

inheres_in_Risk_Probability_Indicator Risk_Indicator Risk_Probability_Indicator 2_2_1_6 2_2_1_3

inheres_in_Severity_Indicator Risk_Indicator Severity_Indicator 2_2_1_6 2_2_1_4

inheres_in_Risk_Indicator Risk_Priority_Number Risk_Indicator 2_2_1_7 2_2_1_6

inheres_in_Detection_Indicator Risk_Priority_Number Detection_Indicator 2_2_1_7 2_2_1_5

requires_Maintenance_of_System System Maintenance 1_1_1 4_1

requires_Maintenance_of_System_Part System_Part Maintenance 1_1_2_1 4_1

requires_Predictive_Maintenance_Process_Definition_of_System_Failure_Symptom System_Failure_Symptom Predictive_Maintenance_Process_Definition 2_2_2_1 2_2_3_1_1

requires_Predictive_Maintenance_Process_Definition_of_System_Part_Failure_Symptom System_Part_Failure_Symptom Predictive_Maintenance_Process_Definition 2_2_2_2 2_2_3_1_1

requires_Correntive_Maintenance_Process_Definition_of_System_Failure_Symptom System_Failure_Symptom Correntive_Maintenance_Process_Definition 2_2_2_1 2_2_3_1_2

requires_Correntive_Maintenance_Process_Definition_of_System_Part_Failure_Symptom System_Part_Failure_Symptom Correntive_Maintenance_Process_Definition 2_2_2_2 2_2_3_1_2

provides_Predictive_Maintenance_Process_Definition Maintneance_Service_Provider Predictive_Maintenance_Process_Definition 1_1_3_2_3 2_2_3_1_1

provides_Correntive_Maintenance_Process_Definition Maintneance_Service_Provider Correntive_Maintenance_Process_Definition 1_1_3_2_3 2_2_3_1_2

provides_System Product_Provider System 1_1_3_2_2 1_1_1

owns_System Business_Customer System 1_1_3_2_1 1_1_1

owns_System Individual_Customer System 1_1_3_1_1 1_1_1

works_in_Product_Provider Employee Product_Provider 1_1_3_1_2 1_1_3_2_2

works_in_Maintneance_Service_Provider Employee Maintneance_Service_Provider 1_1_3_1_2 1_1_3_2_3

has_System_Role System System_Role 1_1_1 3_2_1

has_System_Part_Role System_Part System_Part_Role 1_1_2_1 3_2_2

has_Embedded_Data-Source_Component_Role_of_Embedded_Data-Source_Component Embedded_Data-Source_Component Embedded_Data-Source_Component_Role 1_1_2_5 3_2_6

inheres_in_Predictive_Maintenance_Process_Definition_of_System_Role System_Role Predictive_Maintenance_Process_Definition 3_2_1 2_2_3_1_1

inheres_in_Predictive_Maintenance_Process_Definition_of_System_Part_Role System_Part_Role Predictive_Maintenance_Process_Definition 3_2_2 2_2_3_1_1

inheres_in_Predictive_Maintenance_Process_Definition_of_Embedded_Data-Source_Component_Role Embedded_Data-Source_Component_Role

Predictive_Maintenance_Process_Definition 3_2_6 2_2_3_1_1

inheres_in_Correntive_Maintenance_Process_Definition_of_System_Role System_Role Correntive_Maintenance_Process_Definition 3_2_1 2_2_3_1_2

inheres_in_Correntive_Maintenance_Process_Definition_of_System_Part_Role System_Part_Role Correntive_Maintenance_Process_Definition 3_2_2 2_2_3_1_2

consists_of_System_Part_Role_of_System_Role System_Role System_Part_Role 3_2_1 3_2_2


D3.1 v1.0 / 91

consists_of_Embedded_Data-Source_Component_Role_of_System_Role System_Role Embedded_Data-Source_Component_Role 3_2_1 3_2_6

realized_in_Embedded_Data-Source_Component_Role_of_System_Part_Failure_Mode System_Part_Failure_Mode Embedded_Data-Source_Component_Role 3_1_2_1_2 3_2_6


D3.1 v1.0 / 91

Datatype Properties

Table 3 lists the Z-BRE4K ontology dataproperties, their domain and their types.

Table 3: Z-BRE4K ontology Data Properties

DataProperty Domain Domain_IRI Type

Description_of_System_Role System_Role 3_2_1 xsd:string

Characteristics_of_System_Role System_Role 3_2_1 xsd:string

Funtion_of_System_Part_Role System_Part_Role 3_2_2 xsd:string

Redundancy_provided_of_System_Part_Role System_Part_Role 3_2_2 xsd:string

Severity_level_of_Severity_Indicator Severity_Indicator 2_2_1_4 xsd:string

predictive_actions_of_Predictive_Maintenance_Process_Definition Predictive_Maintenance_Process_Definition 2_2_3_1_1 xsd:string

corrective_actions_of_Correntive_Maintenance_Process_Definition Correntive_Maintenance_Process_Definition 2_2_3_1_2 xsd:string

Priority_of_Risk_Priority_Number Risk_Priority_Number 2_2_1_7 xsd:string

Alarm_code_of_System_Part_Failure_Mode System_Part_Failure_Mode 3_1_2_1_2 xsd:string

Description_of_System_Failure_Symptom System_Failure_Symptom 2_2_2_1 xsd:string

Description_of_System_Part_Failure_Symptom System_Part_Failure_Symptom 2_2_2_2 xsd:string

Description_of_System_Failure_Cause System_Failure_Cause 3_1_2_1_1 xsd:string

Description_of_System_Part_Failure_Mode System_Part_Failure_Mode 3_1_2_1_2 xsd:string

Signals_involved_of_Embedded_Data-Source_Component_Role Embedded_Data-Source_Component_Role 3_2_6 xsd:string

Measurability_of_System_Part_Failure_Mode System_Part_Failure_Mode 3_1_2_1_2 xsd:string

Technical_Information_CDS_Machine_of_System_Part_Role System_Part_Role 3_2_2 xsd:string

q_ty_of_Embedded_Data-Source_Component_Role Embedded_Data-Source_Component_Role 3_2_6 xsd:string

Type_of_signal_of_Embedded_Data-Source_Component_Role Embedded_Data-Source_Component_Role 3_2_6 xsd:string

sampling_frequency_before_signal_elaboration_of_Embedded_Data-Source_Component_Role Embedded_Data-Source_Component_Role 3_2_6 xsd:string

machine_part_linked_to_sensor_of_Embedded_Data-Source_Component_Role Embedded_Data-Source_Component_Role 3_2_6 xsd:string

is_it_used_for_automation_machine_of_Embedded_Data-Source_Component_Role Embedded_Data-Source_Component_Role 3_2_6 xsd:string

we_want_to_share_sansor_with_customer_of_Embedded_Data-Source_Component_Role Embedded_Data-Source_Component_Role 3_2_6 xsd:string

do_we_need_filter_or_elaborate_signal_of_Embedded_Data-Source_Component_Role Embedded_Data-Source_Component_Role 3_2_6 xsd:string

storage_frequency_after_elaboration_of_Embedded_Data-Source_Component_Role Embedded_Data-Source_Component_Role 3_2_6 xsd:string


D3.1 v1.0 / 91

Allarm_code_of_Embedded_Data-Source_Component_Role Embedded_Data-Source_Component_Role 3_2_6 xsd:string

Priority_of_Embedded_Data-Source_Component_Role Embedded_Data-Source_Component_Role 3_2_6 xsd:string


D3.1 v1.0 / 91

4 ONTOLOGY IMPLEMENTATION

The Knowledge Base System (KBS) is storing data with fundamental principles of Z-BRE4K

ontology together with semantic features and context for each individual data and ensures full

interoperability with other Z-BRE4K modules. In addition, it facilitates semantic enrichment (e.g.

annotations, tagging), active exploration of the linked data sets, and implicit knowledge

discovery.

To encourage the semantic achievement, the Z-BRE4K platform requires a special data storage

to deal with triplex collections. One of the common frameworks of implementing triple store is

the Resource Description Framework (RDF) which is a standard model for data interchange on

the web. In Z-BRE4K semantic Framework (See Fig.4), the RDF repository is in the form of

Triplestore which is designed to store and retrieve identities conducted from triplex collections

representing a subject-predicate-object relationship. The rest of the Z-BRE4K components will

communicate with the Triple store database. All the semantic data from the Z-BRE4K main

repository will be stored in RDF repository, referring to Z-BRE4K ontology. Following the

structure of Z-BRE4K ontology, semantic data individuals will be stored with a subject-predicate-

object relationship. Semantic Web Service components will support management of the RDF

repository in the way of search, authentication, dataset, revision, and SPARQL. To follow this

approach, the Z-BRE4K platform will achieve semantic enrichment. In Z-BRE4K Semantic

Framework, Z-BRE4K ontology provides:

the main structure of triplex as a reference model

semantic parameters and enables query to satisfy requirements of the maintenance

planning support tool

Figure 4: Role and Interactions of Knowledge Base System


D3.1 v1.0 / 91

Functional requirements

Main inputs:

Data from Z-BRE4K repository (data concerning machines, processes, production data

logs, actors, and activities etc.), e.g. in XML

Result of analysis from the other Z-BRE4K components (e.g. Condition monitoring,

cognitive embedded condition monitoring, machine simulators, FMEA, VRfx)

Main outputs:

Semantic enrichment of shop-floor data for modelling not only the actors and

procedures at the shop floor, but also machinery and their critical components, their

failure modes and their criticality, their signatures of healthy and deteriorated

conditions, etc. e.g. as RDF Triplets (to be used by Z-BRE4K Knowledge Base System in

T3.2)

Semantic rules (e.g. SPARQL-based rules) for data browsing/analysis

Main functionalities:

Z-BRE4K Ontology: Serves as a common reference model for annotation and description

of knowledge to represent manufacturing system performance

Give semantic annotations to data instances

Facilitate Reasoning and inference

Integration of various data sources with semantic interoperability

Enable queries to meet end users` requirements

Associated strategies

Z-Manage: Knowledge base system will serve as a common reference model for

annotation and description of knowledge to represent manufacturing system

performance and will be utilized by the Z-BRE4K Decision Support System (DSS) in T4.2

for this purpose.


D3.1 v1.0 / 91

Component diagam

Figure 5: Knowledge Base System component diagram

Supported APIs

Table 4: Z-BRE4K ontology APIs

Semantic Framework API Description

SPARQL The SPARQL Web service is used to send

custom SPARQL queries against the SF RDF

repository as a general-purpose querying web

service. Developers communicate with the

SPARQL web service using the HTTP POST

method. Each results document can be

serialized in many ways, and may be expressed

as one of the following mime types: (i)

text/xml, (ii) application/rdf+xml, (iii)

application/rdf+n3, (iv) application/ sparql-

results +xml, (v) application/sparql-

results+json or (vi) application/json. The

content returned by the web service is

serialized using the mime type requested and

the data returned depends on the parameters

selected.


D3.1 v1.0 / 91

Knowledge Management The SF RESTful web services can be accessed

directly via API or command line, or may be

controlled and interacted with using standard

content management systems (CMSs). Each

request to an individual web service returns an

HTTP status and optionally a document of

result sets. Each results document can be

serialized in many ways, and may be expressed

as RDF, pure XML or JSON.


D3.1 v1.0 / 91

5 CONCLUSION

This document presented the implementation details of the Z-BRE4K semantic model as an

ontology. The Z-BRE4K ontology has been developed including the domain of interest for all the

use cases of the Z-BRE4K project. In order to meet the requirements of stakeholders in the

domain field, Competency Question methodology has been applied.

In addition, to adopt BFO framework will provide availability to merge the other Product domain

ontology structured by BFO of which domain is not maintenance engineering. Moreover,

knowledge as ontology add value for people who try to understand domain knowledge of the Z-

BRE4K project. Furthermore, this ontology constitutes the formal representation of the Z-BRE4K

semantic model and the knowledge that this model encapsulates as the part of the Z-BRE4K

platform. Therefore, codification of the knowledge will allow information exchange regarding

the maintenance context and the desire to use it, in order to increase added value of the Z-

BRE4K platform.

Since ontology engineering requires iterative processes, in order to build a consolidated

ontology, Deliverable 3.5 will act as amendment of Deliverable 3.1 as it provides a revised

version of the Z-BRE4K semantic model, including updates to the classes and their relations in

the way of iterative feedback from end-users and technical providers.

6 REFERENCES

[Z-BRE4K 2017] Z-BRE4K Project. “Grant Agreement – 768869”, July 2017.

[Z-BRE4K 2018] Z-BRE4K Project. “D1.1: Z-BRE4K user requirements”, January 2018.

[Z-BRE4K 2018] Z-BRE4K Project. “D1.3: Z-BRE4K system architecture”, January 2018.

[Z-BRE4K 2018] Z-BRE4K Project. “D1.4: Z-BRE4K use cases”, January 2018.

Arp, R., Smith, B. and Spear, A.D., 2015. Building ontologies with basic formal ontology. Mit

Press.

Grüninger, M., & Fox, M. S. (1995). Methodology for the design and evaluation of ontologies.

Noy, N. F., & McGuinness, D. L. (2001). Ontology development 101: A guide to creating your

first ontology.

Suárez-Figueroa, M. C., & Gómez-Pérez, A. (2009). NeOn methodology for building ontology

networks: a scenario-based methodology. In Proceedings of the International Conference on

Software, Services & Semantic Technologies. Sofia.

Gruber, T. R. (1993) A translation approach to portable ontology specifications. Knowledge

acquisition, 5(2), pp. 199-220.

Calero, C., Ruiz, F., & Piattini, M. (Eds.). (2006). Ontologies for software engineering and

software technology. Springer Science & Business Media.

Mizoguchi, R. & Ikeda, M. (1998) Towards ontology engineering. Journal-Japanese Society for

Artificial Intelligence, 13, pp. 9-10.


D3.1 v1.0 / 91

7 ANNEX Figure 6: Z-BRE4K ontology Class hierarchy

D3.1 v1.0 / 91

Table 5: Z-BRE4K ontology RDF implementation

<?xml version="1.0"?>

<rdf:RDF xmlns="http://www.Z-bre4k.org/ontology#"

xml:base="http://www.Z-bre4k.org/ontology"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:owl="http://www.w3.org/2002/07/owl#"

xmlns:xml="http://www.w3.org/XML/1998/namespace"

xmlns:xsd="http://www.w3.org/2001/XMLSchema#"

xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">

<owl:Ontology rdf:about="http://www.Z-bre4k.org/ontology">

<owl:versionInfo xml:lang="en">0.1</owl:versionInfo>

<rdfs:comment xml:lang="en">Created by EPFL from work of Z-bre4k project</rdfs:comment>

</owl:Ontology>

D3.1 v1.0 / 91



<owl:AnnotationProperty rdf:about="http://www.Z-bre4k.org/ontology#description"/>



<owl:AnnotationProperty rdf:about="http://www.Z-

bre4k.org/ontology#requires_Correntive_Maintenance_Process_Definition_of_System_Part_Failure_Mode"/>



<owl:AnnotationProperty rdf:about="http://www.Z-

bre4k.org/ontology#requires_Predictive_Maintenance_Process_Definition_of_System_Part_Failure_Mode"/>

<!--

///////////////////////////////////////////////////////////////////////////////////////

//

// Object Properties

//

///////////////////////////////////////////////////////////////////////////////////////

D3.1 v1.0 / 91

-->



<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#consists_of_Embedded_Data-

Source_Component_Role_of_System_Role">

<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#TransitiveProperty"/>

<rdfs:domain rdf:resource="http://www.Z-bre4k.org/ontology#3_2_1"/>

<rdfs:range rdf:resource="http://www.Z-bre4k.org/ontology#3_2_6"/>

</owl:ObjectProperty>



<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#consists_of_System_Part_Role_of_System_Role">

D3.1 v1.0 / 91

<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#effects_System_Failure_Cause">


<rdfs:domain rdf:resource="http://www.Z-bre4k.org/ontology#3_1_2_1_2"/>

<rdfs:range rdf:resource="http://www.Z-bre4k.org/ontology#3_1_2_1_1"/>




<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#generates_Embedded_Data">


<rdfs:domain rdf:resource="http://www.Z-bre4k.org/ontology#1_1_2_5"/>





<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#has_Detection_Indicator_of_System_Failure_Cause">



<rdfs:range rdf:resource="http://www.Z-bre4k.org/ontology#2_2_1_5"/>

D3.1 v1.0 / 91



<owl:ObjectProperty rdf:about="http://www.Z-

bre4k.org/ontology#has_Detection_Indicator_of_System_Part_Failure_Mode">







<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#has_Embedded_Data-

Source_Component_Role_of_Embedded_Data-Source_Component">

D3.1 v1.0 / 91

<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#has_Embedded_Data-

Source_Component_of_System_Part">







<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#has_Key_Performance_Parameter_of_System">







<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#has_Key_Performance_Parameter_of_System_Part">

D3.1 v1.0 / 91



<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#has_Key_Risk_Indicator_of_System_Failure_Cause">








bre4k.org/ontology#has_Key_Risk_Indicator_of_System_Part_Failure_Mode">








bre4k.org/ontology#has_Risk_Probability_Indicator_of_System_Failure_Cause">

D3.1 v1.0 / 91








bre4k.org/ontology#has_Risk_Probability_Indicator_of_System_Part_Failure_Mode">







<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#has_Severity_Indicator_of_System_Failure_Cause">

D3.1 v1.0 / 91




bre4k.org/ontology#has_Severity_Indicator_of_System_Part_Failure_Mode">







<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#has_System_Failure_Cause">








bre4k.org/ontology#has_System_Failure_Cause_of_Current_System_Quality">

D3.1 v1.0 / 91







bre4k.org/ontology#has_System_Failure_Cause_of_Predictied_System_Quality">







<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#has_System_Failure_Symptom">

D3.1 v1.0 / 91



<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#has_System_Part">







<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#has_System_Part_Failure_Mode">








bre4k.org/ontology#has_System_Part_Failure_Mode_of_Current_System_Part_Quality">

D3.1 v1.0 / 91





bre4k.org/ontology#has_System_Part_Failure_Mode_of_Predictied_System_Part_Quality">







<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#has_System_Part_Failure_Symptom">

D3.1 v1.0 / 91

<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#has_System_Part_Role">







<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#has_System_Role">








bre4k.org/ontology#inheres_in_Correntive_Maintenance_Process_Definition_of_System_Part_Role">

D3.1 v1.0 / 91




bre4k.org/ontology#inheres_in_Correntive_Maintenance_Process_Definition_of_System_Role">







<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#inheres_in_Detection_Indicator">

D3.1 v1.0 / 91


bre4k.org/ontology#inheres_in_Predictive_Maintenance_Process_Definition_of_Embedded_Data-Source_Component_Role">








bre4k.org/ontology#inheres_in_Predictive_Maintenance_Process_Definition_of_System_Part_Role">








bre4k.org/ontology#inheres_in_Predictive_Maintenance_Process_Definition_of_System_Role">

D3.1 v1.0 / 91




<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#inheres_in_Risk_Indicator">







<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#inheres_in_Risk_Probability_Indicator">







<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#inheres_in_Severity_Indicator">

D3.1 v1.0 / 91








bre4k.org/ontology#inheres_in_System_Part_of_Current_System_Part_Quality">








bre4k.org/ontology#inheres_in_System_Part_of_Predictied_System_Part_Quality">

D3.1 v1.0 / 91



<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#inheres_in_System_of_Current_System_Quality">







<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#inheres_in_System_of_Predictied_System_Quality">







<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#owns_System">

D3.1 v1.0 / 91







bre4k.org/ontology#provides_Correntive_Maintenance_Process_Definition">







<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#provides_Predictive_Maintenance_Process_Definition">

D3.1 v1.0 / 91



<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#provides_System">







<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#realized_in_Embedded_Data-

Source_Component_Role_of_System_Part_Failure_Mode">








bre4k.org/ontology#requires_Correntive_Maintenance_Process_Definition_of_System_Failure_Symptom">

D3.1 v1.0 / 91







bre4k.org/ontology#requires_Correntive_Maintenance_Process_Definition_of_System_Part_Failure_Symptom">







<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#requires_Maintenance_of_System">



<rdfs:range rdf:resource="http://www.Z-bre4k.org/ontology#4_1"/>

D3.1 v1.0 / 91



<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#requires_Maintenance_of_System_Part">



<rdfs:range rdf:resource="http://www.Z-bre4k.org/ontology#4_1"/>





bre4k.org/ontology#requires_Predictive_Maintenance_Process_Definition_of_System_Part_Failure_Symptom">

D3.1 v1.0 / 91







<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#works_in_Maintneance_Service_Provider">







<owl:ObjectProperty rdf:about="http://www.Z-bre4k.org/ontology#works_in_Product_Provider">

D3.1 v1.0 / 91





<owl:DatatypeProperty rdf:about="http://www.Z-bre4k.org/ontology#Alarm_code_of_System_Part_Failure_Mode">


<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>

</owl:DatatypeProperty>



<owl:DatatypeProperty rdf:about="http://www.Z-bre4k.org/ontology#Allarm_code_of_Embedded_Data-

Source_Component_Role">

D3.1 v1.0 / 91



<owl:DatatypeProperty rdf:about="http://www.Z-bre4k.org/ontology#Characteristics_of_System_Role">






<owl:DatatypeProperty rdf:about="http://www.Z-bre4k.org/ontology#Description_of_System_Failure_Cause">






<owl:DatatypeProperty rdf:about="http://www.Z-bre4k.org/ontology#Description_of_System_Failure_Symptom">

D3.1 v1.0 / 91



<owl:DatatypeProperty rdf:about="http://www.Z-bre4k.org/ontology#Description_of_System_Part_Failure_Mode">






<owl:DatatypeProperty rdf:about="http://www.Z-bre4k.org/ontology#Description_of_System_Part_Failure_Symptom">






<owl:DatatypeProperty rdf:about="http://www.Z-bre4k.org/ontology#Description_of_System_Role">

D3.1 v1.0 / 91



<owl:DatatypeProperty rdf:about="http://www.Z-bre4k.org/ontology#Funtion_of_System_Part_Role">






<owl:DatatypeProperty rdf:about="http://www.Z-bre4k.org/ontology#Measurability_of_System_Part_Failure_Mode">






<owl:DatatypeProperty rdf:about="http://www.Z-bre4k.org/ontology#Priority_of_Embedded_Data-

D3.1 v1.0 / 91




<owl:DatatypeProperty rdf:about="http://www.Z-bre4k.org/ontology#Priority_of_Risk_Priority_Number">






<owl:DatatypeProperty rdf:about="http://www.Z-bre4k.org/ontology#Redundancy_provided_of_System_Part_Role">






<owl:DatatypeProperty rdf:about="http://www.Z-bre4k.org/ontology#Severity_level_of_Severity_Indicator">

D3.1 v1.0 / 91




<owl:DatatypeProperty rdf:about="http://www.Z-bre4k.org/ontology#Signals_involved_of_Embedded_Data-







<owl:DatatypeProperty rdf:about="http://www.Z-

bre4k.org/ontology#Technical_Information_CDS_Machine_of_System_Part_Role">

D3.1 v1.0 / 91

<owl:DatatypeProperty rdf:about="http://www.Z-bre4k.org/ontology#Type_of_signal_of_Embedded_Data-








bre4k.org/ontology#corrective_actions_of_Correntive_Maintenance_Process_Definition">




<!-- http://www.Z-bre4k.org/ontology#do_we_need_filter_or_elaborate_signal_of_Embedded_Data-



bre4k.org/ontology#do_we_need_filter_or_elaborate_signal_of_Embedded_Data-Source_Component_Role">

D3.1 v1.0 / 91




bre4k.org/ontology#machine_part_linked_to_sensor_of_Embedded_Data-Source_Component_Role">







bre4k.org/ontology#predictive_actions_of_Predictive_Maintenance_Process_Definition">

D3.1 v1.0 / 91




<owl:DatatypeProperty rdf:about="http://www.Z-bre4k.org/ontology#q_ty_of_Embedded_Data-Source_Component_Role">

D3.1 v1.0 / 91


bre4k.org/ontology#storage_frequency_after_elaboration_of_Embedded_Data-Source_Component_Role">

D3.1 v1.0 / 91



<owl:Class rdf:about="http://www.Z-bre4k.org/ontology#1">

<description>Independent_Continuant (see BFO)</description>

<rdfs:label>Independent_Continuant</rdfs:label>

</owl:Class>



<owl:Class rdf:about="http://www.Z-bre4k.org/ontology#1_1">

<rdfs:subClassOf rdf:resource="http://www.Z-bre4k.org/ontology#1"/>

<description>Material_Entity ( see BFO)</description>

<rdfs:label>Material_Entity</rdfs:label>

</owl:Class>



<owl:Class rdf:about="http://www.Z-bre4k.org/ontology#1_1_1">

<rdfs:subClassOf rdf:resource="http://www.Z-bre4k.org/ontology#1_1"/>

<description>The System is a Material_Entity which is a universal set of the target system</description>

D3.1 v1.0 / 91

<rdfs:label>System</rdfs:label>

</owl:Class>




<description>Product Component is a Material Entity which is a part of the System.</description>

<rdfs:label>System_Component</rdfs:label>

</owl:Class>



<owl:Class rdf:about="http://www.Z-bre4k.org/ontology#1_1_2_1">

<rdfs:subClassOf rdf:resource="http://www.Z-bre4k.org/ontology#1_1_2"/>

<description>The System_Part is a System_Component which are a modularity subset of the system</description>

<rdfs:label>System_Part</rdfs:label>

</owl:Class>


D3.1 v1.0 / 91



<description>Embedded Data-Source Component is a Product Component that refers to product-embedded information

devices / parts (e.g. sensors), which allows for (additional) services to be offered for the product.</description>

<rdfs:label>Embedded_Data-Source_Component</rdfs:label>

</owl:Class>




<description>Stakeholder/Actor is an entity that describes the humans (or beings) involved in a business scenario

(development, deployment, use etc.).</description>

<rdfs:label>Stakeholder</rdfs:label>

</owl:Class>




<description>Individual Person is a Stakeholder indicating a separate person who is not legal entity (i.e. not legally

considered a corporate group, as for example a company).</description>

<rdfs:label>Individual_Person</rdfs:label>

D3.1 v1.0 / 91

</owl:Class>



<owl:Class rdf:about="http://www.Z-bre4k.org/ontology#1_1_3_1_1">

<rdfs:subClassOf rdf:resource="http://www.Z-bre4k.org/ontology#1_1_3_1"/>

<description>Individual Customer is an Individual Person that buys or consumes (consumer) any product/maintenance

service. </description>

<rdfs:label>Individual_Customer</rdfs:label>

</owl:Class>




<description>Employee is an Individual Person that works in a Company in the domain.</description>

<rdfs:label>Employee</rdfs:label>

</owl:Class>


D3.1 v1.0 / 91



<description>Company is a Stakeholder that can be one or more individuals forming a legal entity (corporate

body).</description>

<rdfs:label>Company</rdfs:label>

</owl:Class>




<description>Business Customer is a Company that buys and uses the products, and maintenance services. It is the

(group/company) customer of the system, using the system for their own business. </description>

<rdfs:label>Business_Customer</rdfs:label>

</owl:Class>




<description>Product Provider is a Supplier/ provider/vendor that both produces and sells a product, or only sells

it.</description>

<rdfs:label>Product_Provider</rdfs:label>


D3.1 v1.0 / 91

</owl:Class>




<description>Service_Provider is a Supplier/provider/vendor that offers a maintenance service.</description>

<rdfs:label>Maintneance_Service_Provider</rdfs:label>

</owl:Class>



<description>Generally Dependent Continuant (see BFO)</description>

<rdfs:label>Generally_Dependent_Continuant</rdfs:label>

</owl:Class>





D3.1 v1.0 / 91

<description>Resource_Entity is a mean (source) that can be used for the design, development, offer and delivery of a PSS,

from which benefit can be produced.</description>

<rdfs:label>Resource_Entity</rdfs:label>

</owl:Class>




<description>Source-Data is a Resource_Entity that refers to the digitalised information coming as input from the product

or the service, specifically for the scope of Project.</description>

<rdfs:label>Source_Data</rdfs:label>

</owl:Class>




<description>Product Data are Source_Data used in the scope of product, and refer specifically to the system

part.</description>

<rdfs:label>Product_Data</rdfs:label>

</owl:Class>


D3.1 v1.0 / 91




<description>Embedded Data are Product Data generated from embedded data-source components.</description>

<rdfs:label>Embedded_Data</rdfs:label>

</owl:Class>




<description>Digital Log Data are Product Data generated from a software element, part of the product.</description>

<rdfs:label>Digital_Log_Data</rdfs:label>

</owl:Class>





D3.1 v1.0 / 91

<description>Information_Entity is a Resource, immaterial, describing aspects affecting Project, and referring to all the

(processed) data that one can acquire knowledge from, or further process.</description>

<rdfs:label>Information_Entity</rdfs:label>

</owl:Class>




<description>The Indicator is a Information_Entity which is a observed value indicating the state or level of

something</description>

<rdfs:label>Indicator</rdfs:label>

</owl:Class>




<description>The Key_Performance_Parameter is a indicator to measure the performance of each mode at time

t</description>

<rdfs:label>Key_Performance_Parameter</rdfs:label>

</owl:Class>


D3.1 v1.0 / 91




<description>The Key_Risk_Indicator is a indicator of risk exposures to address potential warning events</description>

<rdfs:label>Key_Risk_Indicator</rdfs:label>

</owl:Class>




<description>The Risk Probability Indicator is a indicator which is a frequency of occurrence of Failure_Effect</description>

<rdfs:label>Risk_Probability_Indicator</rdfs:label>

</owl:Class>




<description>The Severity Indicator is a indicator of how serious and destructive a failure mode is</description>


D3.1 v1.0 / 91

<rdfs:label>Severity_Indicator</rdfs:label>

</owl:Class>




<description>The Detection_Indicator is a numerical subjective estimation of the effectiveness of the controls to preven or

detect the cause or failure mode before the failure (Threshold?)</description>

<rdfs:label>Detection_Indicator</rdfs:label>

</owl:Class>




<description>The Risk is a indicator multipling Probability Indicator by Serverity Indicator of the failure</description>

<rdfs:label>Risk_Indicator</rdfs:label>

</owl:Class>



D3.1 v1.0 / 91



<description>The Risk Priority Number is a indicator multipling Risk Indicator by Detection Indicator of the

failure</description>

<rdfs:label>Risk_Priority_Number</rdfs:label>

</owl:Class>




<description>The Failure_Symptom is a Failure_Mechanism_Entity which is a a physical feature that is regarded as indicating

a condition of the failure</description>

<rdfs:label>Failure_Symptom</rdfs:label>

</owl:Class>




<description>The System_Failure_Symptom is a Failure_Symptom described in the level of System</description>

<rdfs:label>System_Failure_Symptom</rdfs:label>


D3.1 v1.0 / 91

</owl:Class>




<description>The Subystem_Failure_Symptom is a Failure_Symptom described in the level of System_Part</description>

<rdfs:label>System_Part_Failure_Symptom</rdfs:label>

</owl:Class>




<description>Process Definition is a structured set of activities designed to accomplish a specific objective. For example, the

Process Definition can be the manufacturing process where the equipment is manufactured, or the process where the equipment

is used, or the development process where products, and maintenance services are being developed etc.</description>

<rdfs:label>Process_Definition</rdfs:label>

</owl:Class>



D3.1 v1.0 / 91



<description>Maintenance Process Definition is a Process Definition referring to a set of non-tangible entities (activities,

software modules etc.), related to the maintenance service part, which aims to satisfy a need of the end-users. </description>

<rdfs:label>Maintenance_Process_Definition</rdfs:label>

</owl:Class>




<description>The Predictive_Maintenance_Process_Definition is a Maintenance_Process_Definition to prevent failures by

monitoring</description>

<rdfs:label>Predictive_Maintenance_Process_Definition</rdfs:label>

</owl:Class>




<description>The Correntive_Maintenance_Process_Definition is a Maintenance_Process_Definition to correct failures

after break down or malfunction</description>


D3.1 v1.0 / 91

<rdfs:label>Correntive_Maintenance_Process_Definition</rdfs:label>

</owl:Class>



<description>Specifically Dependent Countinuant (See BFO)</description>

<rdfs:label>Specifically_Dependent_Countinuant</rdfs:label>

</owl:Class>




<description>Realisable Entity (See BFO)</description>

<rdfs:label>Realisable_Entity</rdfs:label>

</owl:Class>




D3.1 v1.0 / 91


<description>Failure_Mechanism_Entity</description>

<rdfs:label>Failure_Mechanism_Entity</rdfs:label>

</owl:Class>




<description>The Failure_Cause is a Failure_Mechanism_Entity which is a defect in design, process, quality, or part

application, which are the underlying cause of a failure or which initiate a process which leads to failure.</description>

<rdfs:label>Failure_Cause</rdfs:label>

</owl:Class>




<description>The System_Failure_Cause is a Failure_Cause described in the level of System</description>

<rdfs:label>System_Failure_Cause</rdfs:label>

</owl:Class>


D3.1 v1.0 / 91




<description>The System_Part_Failure_Mode is a Failure_Cause described in the level of System_Part</description>

<rdfs:label>System_Part_Failure_Mode</rdfs:label>

</owl:Class>




<description>Quality (See BFO)</description>

<rdfs:label>Quality</rdfs:label>

</owl:Class>




<description>The Current_Quality is a Quality at time t. If they inhere in an entity at all, they are fully exhibited

or manifested or realized in that entity.</description>


D3.1 v1.0 / 91

<rdfs:label>Current_Quality</rdfs:label>

</owl:Class>




<description>The Current_Quality is a Quality of an System entity at time t.</description>

<rdfs:label>Current_System_Quality</rdfs:label>

</owl:Class>




<description>The Current_System_Part_Quality is a Quality of an System_Part entity at time t.</description>

<rdfs:label>Current_System_Part_Quality</rdfs:label>

</owl:Class>



D3.1 v1.0 / 91



<description>The Predicted_Quality is a predicted Quality at future time t.</description>

<rdfs:label>Predicted_Quality</rdfs:label>

</owl:Class>




<description>The Predictied_System_Quality is a Quality of an System entity at future time t.</description>

<rdfs:label>Predictied_System_Quality</rdfs:label>

</owl:Class>




<description>The Predictied_System_Part_Quality is a Quality of an System_Part entity at future time t.</description>

<rdfs:label>Predictied_System_Part_Quality</rdfs:label>

</owl:Class>


D3.1 v1.0 / 91




<description>(See BFO)</description>

<rdfs:label>Role</rdfs:label>

</owl:Class>




<description>borne by a group of one or more System(s) by Maintenance_Process_Definition</description>

<rdfs:label>System_Role</rdfs:label>

</owl:Class>




<description>borne by a group of one or more System_Part(s) by Maintenance_Process_Definition</description>

<rdfs:label>System_Part_Role</rdfs:label>


D3.1 v1.0 / 91

</owl:Class>




<description>borne by a group of one or more Embedded_Data-Source_Component(s) by

Maintenance_Process_Definition</description>

<rdfs:label>Embedded_Data-Source_Component_Role</rdfs:label>

</owl:Class>



<description>See BFO</description>

<rdfs:label>Processual_Entity</rdfs:label>

</owl:Class>



D3.1 v1.0 / 91


<description>Maintenance is a Process made for, and driven by customers, with economic value, and refers to the

maintenance Offer entity in conjunction with time t.</description>

<rdfs:label>Maintenance</rdfs:label>

</owl:Class>

</rdf:RDF>

deliverable d3.1 z-bre4k semantic modelling › wp-content › uploads › 2019 › 09 ›...

Documents