Keywords

1 Introduction

Current trend towards digitalization and the fourth industrial revolution (or Industry 4.0) assumes an intensive usage of information and telecommunication technologies at all stages of the product lifecycle value chain process – from design and engineering to manufacturing, distribution and discontinuation.

As a result, a successful implementation of this concept requires a tight integration along all the processes what leads to the implementation of cyber-physical system platforms that provide possibilities of integration between the physical equipment and IT services & applications [1].

However, such an integration is usually a challenge since different PLM processes have different goals, solve different tasks, and apply different methods that assume application of information models, which fit well to the corresponding tasks, but usually are not interoperable with each other.

This would not be a problem if each PLM process had to deal with its own piece of information, however in reality these information pieces overlap and changes made during one process have to be taken into account at the others. As a result, an efficient information exchange between different PLM processes requires solving the problem of interoperability support.

Since knowledge sharing can be viewed as an enabler for almost any kind of collaborative action, one of the main problems is the problem of interoperability between independent heterogeneous information resources [2]. In Europe, this issue today is receiving a great attention.

In the concept of a new European interoperability framework (New EIF [3, 4]), interoperability is defined as the “ability of organizations to interact towards mutually beneficial goals, involving the sharing of information and knowledge between these organizations, through the business processes they support, using the exchange of data between their ICT systems”.

In Europe, the need for standardization and interoperable systems was recognized almost thirty years ago with the launch of the European Commission’s CADDIA program in 1985, the IDABC program in 1995, the ISA program in 2009 (decision 2009/922/EC) and the creation of current compatibility solutions for European e-government services (ISA2) in 2016 [5]. However, support for interoperability and integration of information resources into common ecosystems is still an unsolved interdisciplinary problem.

There are four levels of interoperability [4]: technical, semantic, organizational and legislative. Semantic interoperability is understood as semantic interpretation of data presented using meta-models such as the Unified Modeling Language (UML [6]) class diagrams and the Ontology Web Language (OWL [7]).

The semantic web (Semantic Web) is one of the ways to solve the problem of semantic interoperability, but today it does not allow working with information as seamlessly as necessary.

Ontologies are formal conceptualizations of domains of interests sharable by heterogeneous applications [8]. They provide means for machine-readable representation of domain knowledge and enable to share, exchange, and process information & knowledge based on its semantics, not just the syntax. Usually, ontologies include concepts existing in a domain, relationships between these concepts, and axioms. Ontologies have proved themselves as one of the most efficient ways to solve the problem of semantic interoperability support. Still there is a need for common ontologies of problem areas with supporting multiple modifications in a quick and simple way, as well as semantic queries in a given context; but applying ontologies to digital ecosystems is still a problem due to different terminologies and formalisms that the members of the ecosystems use.

It is generally accepted that models of specific problem areas (for example, configuration models of complex systems) can be obtained by inheriting or extending a common ontology. However, in systems with a dynamic structure, such as PLM systems, this solution does not allow to achieve the required level of flexibility, since the expansion of the general ontology with the appearance of new information objects requires ontology matching. It should be noted that the automatic ontology matching methods are still not sufficiently reliable (except in narrow domains), and manual ontology matching significantly reduces the efficiency.

The presented work is aimed to solve this problem at the level of semantic interoperability. In the previously reported work [9], different approaches have been analyzed and the apparatus of describing the PLM-related knowledge via a multi-aspect ontology was selected. The contribution of this paper is the application of the multi-aspect ontology to PLM interoperability support and sharing experience of the design process of such an ontology. The paper is structured as follows. Section 2 presents the motivation of the carried-out research. Section 3 describes the most relevant works in the area of PLM and multi-aspect ontology design. Section 4 describes the process of multi-aspect ontology building. The main results are summarized in the conclusion.

2 Motivation

The need to solve the semantic interoperability problem between different PLM stages has appeared due to a long-term collaboration with the company Festo AG & Co KG.

Festo AG & Co KG is an equipment producer providing for industrial automation technologies with a wide range of products (more than 40 000 products of approximately 700 types, with various configuration possibilities) ranging from simple products (e.g., an electric motor) to complex systems (e.g., a complete production line).

During several years of collaboration, an eco-system of software tools aimed at supporting the various PLM processes within the company has been developed as shown in Fig. 1. This eco-system covers several processes from product engineering (NOC and CONCode systems) through definition of possible configurations (CONSys) and product range segmentation (SePa) to customer-driven product configuration sales (encoway). The detailed description of these tools and supported processes can be found in [9].

Fig. 1.
figure 1

Developed eco-system of information and knowledge management systems.

Full size image

Though most of these systems were developed as a result of the same collaboration, each of these was aimed at a particular task and used the most appropriate information model with some information duplicated. The further extension of the eco-system required a complete re-thinking of the used information model that has led to the present research.

The common ontology would provide for semantic interoperability between the systems. However, in its classical form the information models appropriate for each particular task would have been lost, since they would have to be converted into the common model. The multi-aspect ontology would make it possible not only to provide for semantic interoperability between information models of each PLM process but also would preserve the existing models.

3 Some Existing PLM Ontologies

In order to build the multi-aspect PLM ontology, existing PLM ontologies have been studied. The most interesting ones are described below. There exist a number of ontologies for PLM and similar domains, however, most of them are either high-level or oriented to a narrow domain.

The authors of [1] propose an ontology for Industry 4.0, which has a slightly different perspective considering the PLM from the Industry 4.0 point of view. As a result, they introduced into the ontology such concepts as Cyber-Physical System, Internet of Things, Smart Factory, Smart Product and others. The proposed ontology supports both vertical and horizontal integrations in a distributed production system.

In [10], a very high-level PLM ontology is presented that can be instantiated for each particular application (the authors present an example for an assembly process). This approach, however, will not help in solving the interoperability problem, since newly created instances have to be transferred between all the related application ontologies.

The ontology proposed in [11] is a generic but complete solution for a high-level PLM ontology aimed at knowledge reuse in SMEs. On the one hand, it tries to cover all the main aspects of SME functions so that new applications could be developed without significant ontology modifications, and on the other hand, the limited complexity of SMEs makes it possible for the ontology to stay at a reasonable size.

The PLM ontology survey [12] considers mostly high level generic ontologies (SUMO, Cyc, Generalized Upper Model, Enterprise, TOVE, and OntoWeb). The authors point out SUMO, Enterprise and TOVE ontologies as those that had the highest potential. They also conclude that it is practically impossible to have just one ontology for PLM thus confirming the main problem addressed in this paper.

In [13], a survey of ontologies for modelling the manufacturing process as a part of the PLM cycle is presented. The authors consider the integration of three notions: Product, Process and Resource. Though the considered ontologies usually cover a wider topic than just Product or Process, they are still mainly aimed at one task. The authors notice that there still exists a lack of semantics integration between the heterogeneous systems. Among the ontologies oriented towards narrow domains, there are two that should be considered in detail.

In [14], a PLM ontology is proposed, which covers only high level classes and supports instances and reasoning for only some particular tasks such as a product (vehicle) configuration. Usage of the ontology for other tasks is possible only when corresponding instances are added and only those based on OWL-DL logic.

In [15], the proposed PLM ontology covers a wide range of domains, mainly product-centered, namely: quality, environment, after development issues, marketing, product engineering, process engineering, strategic planning and production, supply chain, costs (found in [16]) as well as two additional domains: high level abstraction (for defining generic terms) and standards and best practices. Their entire ontology is quite detailed with 624 classes; however, it still can be used only as a vocabulary for interoperability support. It cannot support the solution of specific tasks that would require specific information representation formalisms.

4 Multi-aspect PLM Ontology Building

The difficulty of supporting conciliated ontologies that capture different views of the same problem, as well as developing an ontology model for representation and processing of information used for solving problems of different nature, lies in the necessity to operate not only with different terminologies but also with different formalisms used to describe different domains. The terminologies and formalisms, in turn, depend on the tools used for efficient solving of the domains’ problems. In the previous publication [9] several paradigms of building multi-aspect ontologies have been analyzed and the granular multi-aspect ontology proposed by [17] has been selected.

The next step was to choose the notation. The most important progress in this direction was achieved by M. Hemam who in co-authorship with Z. Boufaïda proposed in 2011 a language for description of multi-viewpoint ontologies - MVP-OWL [18], which was extended in 2018 to support probabilistic reasoning [19].

In accordance with this notation, the OWL-DL language was extended in the following way (only some of the extensions are listed here; for the complete reference, please, see [18]). First, the viewpoints were introduced (in the current research they correspond to ontology aspects). Classes and properties were split into global (observed from two or several viewpoints) and local (observed only from one viewpoint). Individuals could only be local, however, taking into account the possibility of multi-instantiation, they could be described in several viewpoints and at the global level simultaneously. Also, four types of bridge rules were introduced that enable links or “communication channels” between viewpoints (only the bidirectional inclusion bridge rule stating that two concepts under different viewpoints are equal is used in the example below, indicated with the symbol \( \mathop \leftrightarrow \limits^{ \equiv } \)).

The ontology presented below is based on integration of several existing ontologies. The top-level ontology proposed in [15] was used as the basis. The described simplified but illustrative example Fig. 2 considers three aspects: “Product Engineering”, “Sales”, “Strategic Planning and Production” corresponding to different PLM stages. The three aspects are aimed at different tasks (only one per aspect is considered in the example) and, as a result, they use different formalisms (below, these are described in detail with references considering each of the aspects). However, some of the concepts (e.g., “Product”) are used across the viewpoints.

Fig. 2.
figure 2

Multi-aspect ontology for three viewpoints.

Full size image

The task considered in the Product Engineering aspect, is the definition of a new product and its possible features [20]. The formalism used in this domain is OWL, and the example classes are “Product Family”, “Product Group” (subclass of Product Family), “Product” (subclass of Product Group), and “Feature” (associated with the class Product). The product engineer needs to be able to define new classes of products and new products with their possible features and feature attributes (e.g., Cylinder XXX is a subclass of Pneumatic Cylinder and has such features as “diameter”, “stroke”, “lock in end position”, and others, that, in turn, have certain attributes). However, there still has to be a possibility to ensure the consistency of product classes that is achieved via OWL and reasoning (the Pellet reasoner is currently used).

In the Sales aspect, the task is definition of functional dependencies between parameters of products and their processing when a product or an assembly of products are being configured by/for a customer [21]. There are three main classes in this aspect: “Product”, “Parameter” (product parameter such as “mass”, “power”, etc.), and “Constraints”. The formalism of object-oriented constraint networks makes it possible to define functional dependencies (represented by constraints) between product parameters and then process these via a constraint solver when a particular product or a system is being configured. The “Parameter” in this aspect is not the same as “Feature” in the previous aspect. In certain cases, they can coincide, however, generally this is not the case.

The third aspect taken as an example, is Strategic Planning and Production where a production strategy is defined based on corresponding rules. The products are divided into three production classes: “PTO” (pick to order), “ATO” (assemble to order), and “ETO” (engineered to order) [22]. Based on this class, the lead time for each product is defined together with the plant, where it is to be produced. As a result, the following classes are considered in this aspect: “Production Class”, “Product”, “Plant”. In this view, production rules (“if … then …”) are used.

In accordance with [18] the following ontology elements have been defined:

Viewpoints (aspects): Product Engineering, Sales, Strategic Planning and Production

  • Global classes: Thing, Product, Attribute, Dependency, Group, Resource.

  • Local Classes:

    • Product Engineering: Product Family, Product Group, Product, Feature

    • Sales: Product, Parameter, Constraint

    • Strategic Planning and Production: Product, Production Class, Plant, Rule

  • Bridge Rules:

    • \( Product\mathop \leftrightarrow \limits^{ \equiv } Product_{Sales} \)

    • \( Product\mathop \leftrightarrow \limits^{ \equiv } Product_{ProductEngineering} \)

    • \( Product\mathop \leftrightarrow \limits^{ \equiv } Product_{StrategicPlanningAndProduction} \)

    • i.e., the products from different viewpoints (aspects) are the same products.

When the viewpoints and bridge rules are defined, one can use any required formalism inside each of the viewpoints. Besides, the existing models can be integrated into such a multi-view ontology without significant modification.

5 Conclusion and Future Work

The paper considers the problem of interoperability support across PLM processes via application of an ontology. The problem of heterogeneity of the processes and their respective information models is addressed through having multiple aspects within the common ontology. On the one hand, the multi-aspect ontology provides for the common vocabulary enabling the interoperability between different PLM processes and IT systems supporting these, and, on the other hand, it makes it possible to preserve internal notations and formalisms suitable for efficient solving particular tasks (e.g., configuration, planning, consistency checking, and others).

The contribution of this paper is the application of the multi-aspect ontology to PLM interoperability support and sharing experience of the design process of such an ontology. The proposed ontology is built using the OWL-MVP language aimed at support of different views (aspects) within the same ontology. It is illustrated though an example from IT projects implemented during collaboration with the automation equipment producer Festo AG&Co KG including three aspects “Product Engineering”, “Sales”, “Strategic Planning and Production”), each of them has one task.

Integration of knowledge across PLM stages is an important task and its automation is always plausible. The proposed approach has shown its efficiency for the selected case. Unfortunately, no qualitative analysis can be done to support this. Comparison of the amount of time spent for programming or the amount of code would not produce any rational results. Hence, the final decision on application of the presented approach or another, mostly depends on the goals pursued, e.g.: MBSE relies on modeling to manage systems through their entire lifecycle but does not address the semantic interoperability [23, 24], and the presented approach concentrates on the latter.

In the future, it is planned to extend the built ontology for other aspects and use it more intensively in real applications.