Keywords

1 Introduction

The forth industrial revolution (or Industry 4.0) and digitalization that are currently going on require intensive application of information and telecommunication technologies that are widely used at basically all companies’ departments: engineering, design, production, sales, service and other.

This means that efficient application of such concepts requires a tight integration of software information systems along all the business processes of the company. But such integration is subject to multiple challenges arising due to the fact that different business processes in a company often have different goals, are aimed at solving different tasks, and apply different methods that assume application of different information models. These models have been developed as a result of multiple year experience and fit very well to the corresponding tasks, but usually they are not interoperable with each other.

This was not a problem as long as they were dealing with their own pieces of information and until the IT system integration took place. However, the integration assumes that these information pieces often overlap and if one piece is modified as a result of a certain business process, this modification has to be taken into account in other processes. This causes a necessity to provide for interoperability support between various processes occurring in a company.

The research is motivated by a long-time collaboration with a worldwide provider of automation technology for factory and process automation with a wide assortments of products (more than 40 000 products of approximately 700 types, with various configuration possibilities) ranging from simple products to complex systems [1, 2].

During a number of years of collaboration, an eco-system of software tools aimed at support of various company business processes has been developed as shown in Fig. 1. Below, the elements of the figure are described in detail.

Fig. 1.
figure 1

Information and knowledge management systems developed by the moment.

Full size image

One of the first projects of the considered company related to this problem was launched in 2010 [3]. It was aimed at modification of work and information flows related to configuration of product combinations. The business process reorganization started with setting up a product ontology in a semi-automatic way originally aimed at product codification (order code scheme) by the NOC tool [3]. The resulting ontology (described in detail in [4]) consisted of more than 1000 classes organized into a four level taxonomy, based on the VDMA (Verband Deutscher Maschinen- und Anlagenbau/Mechanical Engineering Industry Association) classification [5].

The same taxonomy was used in the company’s PDM (Product Data Management) and ERP (Enterprise Resource Planning) systems. The ontology structure enabled separation of various types of entities (e.g., physical products and software services) what made it possible to easily deal with it even though it was rather large. Different specialists could work with different parts of the ontology without the need to overview and manage the whole ontology at once (CONBase Product Information Management). Overall, application of the common ontologies in this particular project has proved itself as a convenient and reliable way of product and system knowledge organisation.

However, extension of the support of different processes has caused appearance of extensions of the central ontology aimed at particular processes (e.g., CONCode to support products, which have descriptions incompatible with the ontology). Complex product modelling and design system (CONSys tool) together with product segmentation policy definition tool (SePa) also introduced additional information to be managed. E.g., application data (an auxiliary component used for introduction of some additional characteristics and requirements to the product, for example, operating temperatures, certification, electrical connection, etc.) had to be added for marketing purposes and combined with other features through defined rules. Development of the product configuration tool (CONFig) was aimed at testing the possibility to configure systems based on the rules stored in the CONBase. The tool supported the configuration process in terms used within the company.

Business and information technology (IT) alignment (BITA) is aimed at developing models and methods for improvement of the interrelations between business and IT. In accordance with BITA alignment sequences presented in [6] this development would fall into the alignment sequence class of Functional Integration (Fig. 2). On the one hand this process is natural and evolutional, but on the other hand it leads to fragmentation of business processes and IT systems.

Fig. 2.
figure 2

Functional alignment prospective of BITA.

Full size image

Although some integration results have been achieved in the area of complex product and system information management and configuration, still a lot has to be done to support the whole set of business-processes. One of the key tasks is to provide a coherent way of integration of different extensions into the common ontology. Ontologies are not only used in software tools but also often represent various aspects of enterprise architecture and business processes. As a result, they can help to shift the development approach of model-driven engineering to continuous alignment of business and IT [7].

Having a number of ontologies is not an efficient way due to the necessity to continuously translate information and knowledge between them. However, plain integration is not possible either. For example, the customers are used to operate different terminology, which does not correspond one-to-one to that used within the company. Besides, customers from different industries also operate different terms.

Research results presented in this paper are aimed at solving this problem at the level of semantic interoperability. In the previously reported work [8] different approaches have been analyzed and the apparatus of describing fragmented company knowledge via multi-aspect ontology was selected. This paper describes the process of building a multi-aspect ontology. The paper is structured as follows Sect. 2 presents some existing efforts in the area of interoperability support. Section 3 describes the process of multi-aspect ontology building. The main results are summarized in the conclusion.

2 Interoperability Support

It is now widely recognized that knowledge sharing is a key enabler for most collaborative actions and the problem of interoperability support between independent heterogeneous information resources steps forward [9]. In Europe, this issue is currently receiving significant attention.

In the concept of a new European interoperability framework (New EIF [10, 11]), 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 [12]. However, support for interoperability and integration of information resources into common ecosystems is still an unsolved interdisciplinary problem.

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

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 [15]. 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 this solution does not allow to achieve the required 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 narrow domains), and manual ontology matching significantly reduces the efficiency.

3 Multi-aspect Ontology Building

The difficulty of supporting conciliated ontologies that capture different views on 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 to effectively solve the domains’ problems. In the previous publication [8] several paradigms of building multi-aspect ontologies have been analyzed and granular multi-aspect ontology proposed by [16] have been selected.

The next step was choosing the notation. The most progress in this direction is achieved by Hemam who in co-authorship with Boufaïda proposed in 2011 a language for description of multi-viewpoint ontologies - MVP-OWL [17] extended in 2018 with probability support [18].

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 [17]). 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 presented below ontology is based on integration of several existing ontologies. The top-level ontology proposed in [19] was used as the basis. The described simplified but illustrative example Fig. 3 considers three aspects: “Product Engineering”, “Sales”, “Strategic Planning and Production” corresponding to different processes. 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 with references considering each of the aspects in detail). However, some of the concepts (e.g., “Product”) are used across the viewpoints.

Fig. 3.
figure 3

Multi-aspect ontology for three viewpoints.

Full size image

The task considered in the Product Engineering aspect is definition of a new product and its possible features [3]. 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 a possibility 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 endure 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 [1]. 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 example aspect 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) [20]. 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”, “Rule”, “PTO”, “ATO”, “ETO”. In this view production rules (“if … then …”) are used.

In accordance with [17] 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, PTO, ATO, ETO

Bridge Rules:

Product \( \mathop \leftrightarrow \limits^{ \equiv } \) ProductSales

Product \( \mathop \leftrightarrow \limits^{ \equiv } \) ProductProductEngineering

Product \( \mathop \leftrightarrow \limits^{ \equiv } \) ProductStrategicPlanningAndProduction

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.

4 Conclusion and Future Work

The paper considers the problem of interoperability support of different company business-processes and related IT tools with the help of an ontology. The problem of heterogeneity and overlapping of the knowledge and information models used in the various processes is addresses by application of different views (referred to as “aspects”) within the same ontology. On one side, the multi-aspect ontology provides the common vocabulary what enables the interoperability between different company business-processes and supporting them IT systems. On the other side, the aspects preserve the internal notations and formalisms that have proved their efficiency for solving particular tasks (e.g., consistency checking, configuration, planning).

The presented ontology has been built using the OWL-MVP language that is aimed at support of different views (aspects) within the same ontology. The ontology is illustrated through an example from IT projects implemented during collaboration with the automation equipment producer including three aspects “Product Engineering”, “Sales”, “Strategic Planning and Production”), with each of them having one task.

The suggested approach can significantly facilitate the functional BITA alignment, where IT infrastructure development follows the evolution of business processes. Due to its capability to preserve most convenient information models for particular business processes, a seamless integration of different business processes in the part of information exchange can be achieved.

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